From jayathirth.d.v at oracle.com Mon Aug 1 08:26:25 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 1 Aug 2016 01:26:25 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8160943 : skipImage() in JPEGImageReader class throws IIOException if we have gaps between markers in Jpeg image Message-ID: <1dccad2c-3348-447b-b132-2cc2a242a9c3@default> Hi, Please review the following fix in JDK9 at your convenience: Bug : https://bugs.openjdk.java.net/browse/JDK-8160943 Webrev : http://cr.openjdk.java.net/~jdv/8160943/webrev.00/ Root cause : While fixing JDK-8152672 we considered that there can be no data in Jpeg image which can be like "FF FF" and we threw IIOException if we find data as "FF FF" and considered it as invalid marker. Solution : According to https://www.w3.org/Graphics/JPEG/itu-t81.pdf there can be gaps between markers in Jpeg image and it can contain fill bits like "X FF". In this case if a fill bit is followed by any valid maker in Jpeg it will contain sequence of data which will be "FF FF". So we should not consider "FF FF" as invalid marker and just parse through it. Added check to consider "FF FF" as normal data in Jpeg. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Mon Aug 1 09:06:46 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 1 Aug 2016 14:36:46 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6575247: Banner checkbox in PrinterJob print dialog doesn't work In-Reply-To: <361e6046-dd03-b524-061e-955e8da3658b@oracle.com> References: <578CBD19.6000303@oracle.com> <578F9832.1080906@oracle.com> <5791FBF7.2050800@oracle.com> <579886BF.30600@oracle.com> <5798BC1F.2010605@oracle.com> <5799D5B1.4090808@oracle.com> <361e6046-dd03-b524-061e-955e8da3658b@oracle.com> Message-ID: <579F1126.4020801@oracle.com> On 7/28/2016 9:19 PM, Phil Race wrote: > right .. when we talked off-line yesterday I said that if IPP is > reporting > a default we should honour it. The default of standard/on is only for > the case we do not use IPP or it reports nothing. > > if (noJobSheet) { > 885 pFlags |= NOSHEET; > 886 ncomps+=1; > 887 } else { > 888 ncomps+=1; > 889 } > > .... > 905 if ((pFlags & NOSHEET) != 0) { > 906 execCmd[n++] = "-o nobanner"; > 907 } else if (getPrintService(). > 908 isAttributeCategorySupported(JobSheets.class)) { > 909 execCmd[n++] = "-o job-sheets=standard"; > 910 } > > So shouldn't the else at line 887 have the same condition > as at line 907 ? Yes. Have modified the webrev to add the check http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.04/ > > 2750 JobSheets js = (JobSheets)asCurrent.get(jsCategory); > 2751 if (js == null) { > 2752 js = > (JobSheets)psCurrent.getDefaultAttributeValue(jsCategory); > 2753 if (js == null) { > 2754 js = JobSheets.STANDARD; > 2755 } > > Please make sure this isn't causing a surprise on OSX or Windows .. > ie that we report correctly a value there so that "null" doesn't > end up causing us to print a banner page where we did not before. > Tested on osx and windows too where it behaves as it is now ie no banner page is printed by default. Regards Prasanta > -phil. > > On 7/28/2016 2:51 AM, Prasanta Sadhukhan wrote: >> The banner checkbox is not enabled initially as it calls >> getDefaultAttributeValue() and it seems printer is reporting the >> default job-sheet value as "none" so the below check is not satisfied. >> cbJobSheets.setSelected(js != JobSheets.NONE); >> >> When IPPPrintService#readIPPResponse() is called, it invokes /new >> AttributeClass(attribStr, valTagByte, outArray); >> /and stored the value corresponding to each attribute. >> >> I saw that IPP response has >> *job-sheets-default => job-sheets-default *and* >> **job-sheets-supported => job-sheets-supported* >> >> When AttributeClass constructor is called with ("job-sheets-default", >> 66, value) the value is >> [ 0] = (byte) 4 [ 1] = (byte) 110 [ 2] = (byte) 111 [ 3] = >> (byte) 110 [ 4] = (byte) 101 [ 5] = (byte) 4 [ 6] = (byte) >> 110 [ 7] = (byte) 111 [ 8] = (byte) 110 [ 9] = (byte) 101 >> [10] = (byte) 2 >> which basically translates to '',n,o,n,e,'',n,o,n,e,'' >> >> so when ServiceDialog calls >> IPPPrintService#getDefaultAttributeValue(JobSheets) >> ---------------- >> if (attribClass != null && >> attribClass.getStringValue().equals("none")) { >> return JobSheets.NONE; >> } else { >> return JobSheets.STANDARD; >> } >> -------------- >> we have attribClass.getStringValue() as "none" so default job sheet >> value is coming out to be NONE. >> Since it is coming out from IPP response, I think we should not >> change default value of JobSheets to STANDARD. Do you think otherwise? >> >> In the modified webrev, I have made the jobsheet default value >> STANDARD, only when IPP does not report any default value. >> >> http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.03/ >> >> Tested in ubuntu & solaris11. >> >> Regards >> Prasanta >> On 7/27/2016 7:20 PM, Philip Race wrote: >>> 883 } else { >>> 884 Class[] supportedCats = getPrintService(). >>> 885 getSupportedAttributeCategories(); >>> 886 for (int i=0;i>> 887 if (JobSheets.class == supportedCats[i]) { >>> 888 pFlags |= JOBSHEET; >>> 889 ncomps+=1; >>> 890 break; >>> 891 } >>> 892 } >>> >>> What is wrong with >>> >>> getPrintService().isAttributeCategorySupported(JobSheets.class) ? >>> >>> https://docs.oracle.com/javase/8/docs/api/javax/print/PrintService.html#isAttributeCategorySupported-java.lang.Class- >>> >>> >>> I am also very confused about why you added JOBSHEET >>> which seems to duplicate the functionality of NOSHEET. >>> >>> Also it seems to me like it was intentional that the banner page be >>> printed by default .. which is why the variable was called >>> "*no*JobSheet .. >>> so as to over-ride that behaviour. >>> >>> It is kind of what you'd want if you walk over to the shared printer in >>> your office to have a banner page which declares it as yours ... >>> >>> So the checkbox should probably be enabled in that case. >>> >>> Also you should verify that we report the default value for JobSheets >>> as being STANDARD, not NONE. >>> >>> >>> -phil. >>> >>> On 7/27/16, 3:02 AM, Prasanta Sadhukhan wrote: >>>> Modified webrev to take care of a problem in webrev.01 whereby >>>> banner page was getting printed by default. >>>> Now, banner page will get printed only if the checkbox is checked >>>> in printer dialog. >>>> >>>> http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.02/ >>>> >>>> Regards >>>> Prasanta >>>> On 7/22/2016 4:26 PM, Prasanta Sadhukhan wrote: >>>>> Hi Phil, >>>>> >>>>> I have modified the code to check if job-sheets is supported and >>>>> then only proceed to print the banner page. >>>>> Also, rectified the jobTitle and banner confusion by adding >>>>> jobsheet check. >>>>> Also added the same code in UnixPrintJob even though I found its >>>>> printExecCmd() does not get executed in linux and solaris >>>>> PSPrinterJob's printExecCmd() is executed instead. In mac, neither >>>>> UnixPrinterJob#printExecCmd() nor PSPrinterJob#printExecCmd() gets >>>>> executed. >>>>> >>>>> Tested on ubuntu and solaris 11 with the fix and banner page is >>>>> printed with the fix. In mac, cover page gets printed without any >>>>> change. >>>>> >>>>> http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.01/ >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 7/20/2016 8:56 PM, Philip Race wrote: >>>>>> In my evaluation of that bug (which was 9 yrs ago so I do not have >>>>>> any memory of it :-)), I note that we first need to check >>>>>> that job-sheets is supported .. you are not doing that .. >>>>>> what happens if we pass an unsupported option ? >>>>>> "-o foobar" ?? This needs testing on Linux, OS X, and Solaris 11. >>>>>> >>>>>> Also -J (job-title) is something you can see in the queue when >>>>>> you do lpq. I don't know why it is tied to banner here but >>>>>> removing it seems wrong. Perhaps this should be renamed from >>>>>> "banner" and "BANNER" to jobTitle ?? Please examine this. >>>>>> >>>>>> In fact you seem to be conflicting with the -o nobanner. >>>>>> >>>>>> So in general we have some lack of clarity around job title and >>>>>> banner page >>>>>> (aka job sheet). >>>>>> >>>>>> Also we have PSPrinterJob and UnixPrinterJob with similar code. >>>>>> Please examine it to make sure no similar case is going missed. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 7/18/16, 4:27 AM, Prasanta Sadhukhan wrote: >>>>>>> Hi All, >>>>>>> >>>>>>> Please review a fix for an issue where it is seen that Banner >>>>>>> page in linux does not get printed despite user selecting the >>>>>>> Banner page checkbox in Printer dialog. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6575247 >>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.00/ >>>>>>> >>>>>>> It seems if we pass "-J " option to lpr command, it >>>>>>> has no effect. >>>>>>> To print Banner page, we need to pass >>>>>>> "-o job-sheets=>>>>>> "secret", "standard", "topsecret", or "unclassified">" >>>>>>> >>>>>>> Since we support only standard banner or none via a checkbox, >>>>>>> the proposed fix passes option "-o job-sheets=standard" to lpr >>>>>>> command to print the banner page. >>>>>>> >>>>>>> Regards >>>>>>> PRasanta >>>>> >>>> >> > From philip.race at oracle.com Mon Aug 1 13:48:06 2016 From: philip.race at oracle.com (Philip Race) Date: Mon, 01 Aug 2016 06:48:06 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6575247: Banner checkbox in PrinterJob print dialog doesn't work In-Reply-To: <579F1126.4020801@oracle.com> References: <578CBD19.6000303@oracle.com> <578F9832.1080906@oracle.com> <5791FBF7.2050800@oracle.com> <579886BF.30600@oracle.com> <5798BC1F.2010605@oracle.com> <5799D5B1.4090808@oracle.com> <361e6046-dd03-b524-061e-955e8da3658b@oracle.com> <579F1126.4020801@oracle.com> Message-ID: <579F5316.7080407@oracle.com> Ok. +1 -phil On 8/1/16, 2:06 AM, Prasanta Sadhukhan wrote: > > > On 7/28/2016 9:19 PM, Phil Race wrote: >> right .. when we talked off-line yesterday I said that if IPP is >> reporting >> a default we should honour it. The default of standard/on is only for >> the case we do not use IPP or it reports nothing. >> >> if (noJobSheet) { >> 885 pFlags |= NOSHEET; >> 886 ncomps+=1; >> 887 } else { >> 888 ncomps+=1; >> 889 } >> >> .... >> 905 if ((pFlags & NOSHEET) != 0) { >> 906 execCmd[n++] = "-o nobanner"; >> 907 } else if (getPrintService(). >> 908 isAttributeCategorySupported(JobSheets.class)) { >> 909 execCmd[n++] = "-o job-sheets=standard"; >> 910 } >> >> So shouldn't the else at line 887 have the same condition >> as at line 907 ? > Yes. Have modified the webrev to add the check > http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.04/ >> >> 2750 JobSheets js = (JobSheets)asCurrent.get(jsCategory); >> 2751 if (js == null) { >> 2752 js = >> (JobSheets)psCurrent.getDefaultAttributeValue(jsCategory); >> 2753 if (js == null) { >> 2754 js = JobSheets.STANDARD; >> 2755 } >> >> Please make sure this isn't causing a surprise on OSX or Windows .. >> ie that we report correctly a value there so that "null" doesn't >> end up causing us to print a banner page where we did not before. >> > Tested on osx and windows too where it behaves as it is now ie no > banner page is printed by default. > > Regards > Prasanta >> -phil. >> >> On 7/28/2016 2:51 AM, Prasanta Sadhukhan wrote: >>> The banner checkbox is not enabled initially as it calls >>> getDefaultAttributeValue() and it seems printer is reporting the >>> default job-sheet value as "none" so the below check is not satisfied. >>> cbJobSheets.setSelected(js != JobSheets.NONE); >>> >>> When IPPPrintService#readIPPResponse() is called, it invokes /new >>> AttributeClass(attribStr, valTagByte, outArray); >>> /and stored the value corresponding to each attribute. >>> >>> I saw that IPP response has >>> *job-sheets-default => job-sheets-default *and* >>> **job-sheets-supported => job-sheets-supported* >>> >>> When AttributeClass constructor is called with >>> ("job-sheets-default", 66, value) the value is >>> [ 0] = (byte) 4 [ 1] = (byte) 110 [ 2] = (byte) 111 [ 3] = >>> (byte) 110 [ 4] = (byte) 101 [ 5] = (byte) 4 [ 6] = (byte) >>> 110 [ 7] = (byte) 111 [ 8] = (byte) 110 [ 9] = (byte) >>> 101 [10] = (byte) 2 >>> which basically translates to '',n,o,n,e,'',n,o,n,e,'' >>> >>> so when ServiceDialog calls >>> IPPPrintService#getDefaultAttributeValue(JobSheets) >>> ---------------- >>> if (attribClass != null && >>> attribClass.getStringValue().equals("none")) { >>> return JobSheets.NONE; >>> } else { >>> return JobSheets.STANDARD; >>> } >>> -------------- >>> we have attribClass.getStringValue() as "none" so default job sheet >>> value is coming out to be NONE. >>> Since it is coming out from IPP response, I think we should not >>> change default value of JobSheets to STANDARD. Do you think otherwise? >>> >>> In the modified webrev, I have made the jobsheet default value >>> STANDARD, only when IPP does not report any default value. >>> >>> http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.03/ >>> >>> Tested in ubuntu & solaris11. >>> >>> Regards >>> Prasanta >>> On 7/27/2016 7:20 PM, Philip Race wrote: >>>> 883 } else { >>>> 884 Class[] supportedCats = getPrintService(). >>>> 885 getSupportedAttributeCategories(); >>>> 886 for (int i=0;i>>> 887 if (JobSheets.class == supportedCats[i]) { >>>> 888 pFlags |= JOBSHEET; >>>> 889 ncomps+=1; >>>> 890 break; >>>> 891 } >>>> 892 } >>>> >>>> What is wrong with >>>> >>>> getPrintService().isAttributeCategorySupported(JobSheets.class) ? >>>> >>>> https://docs.oracle.com/javase/8/docs/api/javax/print/PrintService.html#isAttributeCategorySupported-java.lang.Class- >>>> >>>> >>>> I am also very confused about why you added JOBSHEET >>>> which seems to duplicate the functionality of NOSHEET. >>>> >>>> Also it seems to me like it was intentional that the banner page be >>>> printed by default .. which is why the variable was called >>>> "*no*JobSheet .. >>>> so as to over-ride that behaviour. >>>> >>>> It is kind of what you'd want if you walk over to the shared >>>> printer in >>>> your office to have a banner page which declares it as yours ... >>>> >>>> So the checkbox should probably be enabled in that case. >>>> >>>> Also you should verify that we report the default value for JobSheets >>>> as being STANDARD, not NONE. >>>> >>>> >>>> -phil. >>>> >>>> On 7/27/16, 3:02 AM, Prasanta Sadhukhan wrote: >>>>> Modified webrev to take care of a problem in webrev.01 whereby >>>>> banner page was getting printed by default. >>>>> Now, banner page will get printed only if the checkbox is checked >>>>> in printer dialog. >>>>> >>>>> http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.02/ >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 7/22/2016 4:26 PM, Prasanta Sadhukhan wrote: >>>>>> Hi Phil, >>>>>> >>>>>> I have modified the code to check if job-sheets is supported and >>>>>> then only proceed to print the banner page. >>>>>> Also, rectified the jobTitle and banner confusion by adding >>>>>> jobsheet check. >>>>>> Also added the same code in UnixPrintJob even though I found its >>>>>> printExecCmd() does not get executed in linux and solaris >>>>>> PSPrinterJob's printExecCmd() is executed instead. In mac, >>>>>> neither UnixPrinterJob#printExecCmd() nor >>>>>> PSPrinterJob#printExecCmd() gets executed. >>>>>> >>>>>> Tested on ubuntu and solaris 11 with the fix and banner page is >>>>>> printed with the fix. In mac, cover page gets printed without any >>>>>> change. >>>>>> >>>>>> http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.01/ >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> On 7/20/2016 8:56 PM, Philip Race wrote: >>>>>>> In my evaluation of that bug (which was 9 yrs ago so I do not have >>>>>>> any memory of it :-)), I note that we first need to check >>>>>>> that job-sheets is supported .. you are not doing that .. >>>>>>> what happens if we pass an unsupported option ? >>>>>>> "-o foobar" ?? This needs testing on Linux, OS X, and Solaris 11. >>>>>>> >>>>>>> Also -J (job-title) is something you can see in the queue when >>>>>>> you do lpq. I don't know why it is tied to banner here but >>>>>>> removing it seems wrong. Perhaps this should be renamed from >>>>>>> "banner" and "BANNER" to jobTitle ?? Please examine this. >>>>>>> >>>>>>> In fact you seem to be conflicting with the -o nobanner. >>>>>>> >>>>>>> So in general we have some lack of clarity around job title and >>>>>>> banner page >>>>>>> (aka job sheet). >>>>>>> >>>>>>> Also we have PSPrinterJob and UnixPrinterJob with similar code. >>>>>>> Please examine it to make sure no similar case is going missed. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 7/18/16, 4:27 AM, Prasanta Sadhukhan wrote: >>>>>>>> Hi All, >>>>>>>> >>>>>>>> Please review a fix for an issue where it is seen that Banner >>>>>>>> page in linux does not get printed despite user selecting the >>>>>>>> Banner page checkbox in Printer dialog. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6575247 >>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.00/ >>>>>>>> >>>>>>>> It seems if we pass "-J " option to lpr command, it >>>>>>>> has no effect. >>>>>>>> To print Banner page, we need to pass >>>>>>>> "-o job-sheets=>>>>>>> "secret", "standard", "topsecret", or "unclassified">" >>>>>>>> >>>>>>>> Since we support only standard banner or none via a checkbox, >>>>>>>> the proposed fix passes option "-o job-sheets=standard" to lpr >>>>>>>> command to print the banner page. >>>>>>>> >>>>>>>> Regards >>>>>>>> PRasanta >>>>>> >>>>> >>> >> > From philip.race at oracle.com Mon Aug 1 13:51:36 2016 From: philip.race at oracle.com (Philip Race) Date: Mon, 01 Aug 2016 06:51:36 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8160943 : skipImage() in JPEGImageReader class throws IIOException if we have gaps between markers in Jpeg image In-Reply-To: <1dccad2c-3348-447b-b132-2cc2a242a9c3@default> References: <1dccad2c-3348-447b-b132-2cc2a242a9c3@default> Message-ID: <579F53E8.5030606@oracle.com> +1 - assuming you have run the jtreg tests for imageio .. -phil. On 8/1/16, 1:26 AM, Jayathirth D V wrote: > > Hi, > > Please review the following fix in JDK9 at your convenience: > > Bug : https://bugs.openjdk.java.net/browse/JDK-8160943 > > Webrev : http://cr.openjdk.java.net/~jdv/8160943/webrev.00/ > > > Root cause : While fixing JDK-8152672 we considered that there can be > no data in Jpeg image which can be like "FF FF" and we threw > IIOException if we find data as "FF FF" and considered it as invalid > marker. > > Solution : According to https://www.w3.org/Graphics/JPEG/itu-t81.pdf > there can be gaps between markers in Jpeg image and it can contain > fill bits like "X FF". > > In this case if a fill bit is followed by any valid maker in Jpeg it > will contain sequence of data which will be "FF FF". So we should not > consider "FF FF" as invalid marker and just parse through it. Added > check to consider "FF FF" as normal data in Jpeg. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From torgeir.veimo at gmail.com Mon Aug 1 14:28:58 2016 From: torgeir.veimo at gmail.com (Torgeir Veimo) Date: Tue, 2 Aug 2016 00:28:58 +1000 Subject: [OpenJDK 2D-Dev] JDK bug 8078516 Message-ID: Is there any more work done on JDK bug 8078516? -- -Tor -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Mon Aug 1 14:39:57 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 01 Aug 2016 07:39:57 -0700 Subject: [OpenJDK 2D-Dev] JDK bug 8078516 In-Reply-To: References: Message-ID: <579F5F3D.6040203@oracle.com> Are you sure you have the right Bug ID? That bug (which is not publicly visible), is closed as a duplicate of 8087201, which was fixed in JDK 9 and 8u66 over a year ago. -- Kevin Torgeir Veimo wrote: > Is there any more work done on JDK bug 8078516? > > -- > -Tor From torgeir.veimo at gmail.com Mon Aug 1 14:47:07 2016 From: torgeir.veimo at gmail.com (Torgeir Veimo) Date: Tue, 2 Aug 2016 00:47:07 +1000 Subject: [OpenJDK 2D-Dev] Fwd: JDK bug 8078516 In-Reply-To: References: <579F5F3D.6040203@oracle.com> Message-ID: I'm fairly sure it's the correct bug id, although I don't have access to view it myself. Bug 8078526 is about supporting (without artifacts) subpixel rendering to transparent surfaces. Bug 8087201 is about speeding up subpixel rendering. On 2 August 2016 at 00:39, Kevin Rushforth wrote: > Are you sure you have the right Bug ID? That bug (which is not publicly > visible), is closed as a duplicate of 8087201, which was fixed in JDK 9 and > 8u66 over a year ago. > > -- Kevin > > > > Torgeir Veimo wrote: > >> Is there any more work done on JDK bug 8078516? >> -- >> -Tor > > -- -Tor -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Mon Aug 1 14:49:44 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 01 Aug 2016 07:49:44 -0700 Subject: [OpenJDK 2D-Dev] Fwd: JDK bug 8078516 In-Reply-To: References: <579F5F3D.6040203@oracle.com> Message-ID: <579F6188.6030207@oracle.com> Phil will be able to comment on this further. All I can confirm is that 8078526 is closed as a duplicate of 8087201, so it is no longer an open bug. -- Kevin Torgeir Veimo wrote: > I'm fairly sure it's the correct bug id, although I don't have access > to view it myself. > > Bug 8078526 is about supporting (without artifacts) subpixel rendering > to transparent surfaces. > > Bug 8087201 is about speeding up subpixel rendering. > > On 2 August 2016 at 00:39, Kevin Rushforth > wrote: > > Are you sure you have the right Bug ID? That bug (which is not > publicly visible), is closed as a duplicate of 8087201, which was > fixed in JDK 9 and 8u66 over a year ago. > > -- Kevin > > > > Torgeir Veimo wrote: > > Is there any more work done on JDK bug 8078516? > -- > -Tor > > > > -- > -Tor -------------- next part -------------- An HTML attachment was scrubbed... URL: From torgeir.veimo at gmail.com Mon Aug 1 14:55:11 2016 From: torgeir.veimo at gmail.com (Torgeir Veimo) Date: Tue, 2 Aug 2016 00:55:11 +1000 Subject: [OpenJDK 2D-Dev] Fwd: JDK bug 8078516 In-Reply-To: <579F6188.6030207@oracle.com> References: <579F5F3D.6040203@oracle.com> <579F6188.6030207@oracle.com> Message-ID: Ok, am asking since subpixel rendering works and is usable in most situations, except for the odd corner case when drawing over existing content in transparent surfaces. See eg. this screenshot of netbeans, with nice subpixel rendered text in the editor, while the labels on the buttons at the bottom have artifacts since they for some reason are drawn twice. [image: Inline images 1] On 2 August 2016 at 00:49, Kevin Rushforth wrote: > Phil will be able to comment on this further. All I can confirm is that > 8078526 is closed as a duplicate of 8087201, so it is no longer an open bug. > > -- Kevin > > > Torgeir Veimo wrote: > > I'm fairly sure it's the correct bug id, although I don't have access to > view it myself. > > Bug 8078526 is about supporting (without artifacts) subpixel rendering to > transparent surfaces. > > Bug 8087201 is about speeding up subpixel rendering. > > On 2 August 2016 at 00:39, Kevin Rushforth > wrote: > >> Are you sure you have the right Bug ID? That bug (which is not publicly >> visible), is closed as a duplicate of 8087201, which was fixed in JDK 9 and >> 8u66 over a year ago. >> >> -- Kevin >> >> >> >> Torgeir Veimo wrote: >> >>> Is there any more work done on JDK bug 8078516? >>> -- >>> -Tor >> >> > > -- > -Tor > > -- -Tor -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2016-08-02 at 12.51.00 AM.png Type: image/png Size: 50236 bytes Desc: not available URL: From philip.race at oracle.com Mon Aug 1 15:03:20 2016 From: philip.race at oracle.com (Philip Race) Date: Mon, 01 Aug 2016 08:03:20 -0700 Subject: [OpenJDK 2D-Dev] Fwd: JDK bug 8078516 In-Reply-To: References: <579F5F3D.6040203@oracle.com> <579F6188.6030207@oracle.com> Message-ID: <579F64B8.1060602@oracle.com> Transparency of the surface has always disabled LCD sub-pixel in Java 2D. Same happens on windows. The labels at the bottom are drawn in greyscale. -phil. On 8/1/16, 7:55 AM, Torgeir Veimo wrote: > Ok, am asking since subpixel rendering works and is usable in most > situations, except for the odd corner case when drawing over existing > content in transparent surfaces. > > See eg. this screenshot of netbeans, with nice subpixel rendered text > in the editor, while the labels on the buttons at the bottom have > artifacts since they for some reason are drawn twice. > > Inline images 1 > > On 2 August 2016 at 00:49, Kevin Rushforth > wrote: > > Phil will be able to comment on this further. All I can confirm is > that 8078526 is closed as a duplicate of 8087201, so it is no > longer an open bug. > > -- Kevin > > > Torgeir Veimo wrote: >> I'm fairly sure it's the correct bug id, although I don't have >> access to view it myself. >> >> Bug 8078526 is about supporting (without artifacts) subpixel >> rendering to transparent surfaces. >> >> Bug 8087201 is about speeding up subpixel rendering. >> >> On 2 August 2016 at 00:39, Kevin Rushforth >> > >> wrote: >> >> Are you sure you have the right Bug ID? That bug (which is >> not publicly visible), is closed as a duplicate of 8087201, >> which was fixed in JDK 9 and 8u66 over a year ago. >> >> -- Kevin >> >> >> >> Torgeir Veimo wrote: >> >> Is there any more work done on JDK bug 8078516? >> -- >> -Tor >> >> >> >> -- >> -Tor > > > > > -- > -Tor -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 50236 bytes Desc: not available URL: From jayathirth.d.v at oracle.com Mon Aug 1 15:49:37 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 1 Aug 2016 08:49:37 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8160943 : skipImage() in JPEGImageReader class throws IIOException if we have gaps between markers in Jpeg image In-Reply-To: <579F53E8.5030606@oracle.com> References: <1dccad2c-3348-447b-b132-2cc2a242a9c3@default> <579F53E8.5030606@oracle.com> Message-ID: Hi Phil, Thanks for your review. I have run all jtreg tests under imageio and there are no side effects. Thanks, Jay From: Philip Race Sent: Monday, August 01, 2016 7:22 PM To: Jayathirth D V Cc: Jim Graham; Prasanta Sadhukhan; 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9] RFR: JDK-8160943 : skipImage() in JPEGImageReader class throws IIOException if we have gaps between markers in Jpeg image +1 - assuming you have run the jtreg tests for imageio .. -phil. On 8/1/16, 1:26 AM, Jayathirth D V wrote: Hi, Please review the following fix in JDK9 at your convenience: Bug : https://bugs.openjdk.java.net/browse/JDK-8160943 Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8160943/webrev.00/"http://cr.openjdk.java.net/~jdv/8160943/webrev.00/ Root cause : While fixing JDK-8152672 we considered that there can be no data in Jpeg image which can be like "FF FF" and we threw IIOException if we find data as "FF FF" and considered it as invalid marker. Solution : According to https://www.w3.org/Graphics/JPEG/itu-t81.pdf there can be gaps between markers in Jpeg image and it can contain fill bits like "X FF". In this case if a fill bit is followed by any valid maker in Jpeg it will contain sequence of data which will be "FF FF". So we should not consider "FF FF" as invalid marker and just parse through it. Added check to consider "FF FF" as normal data in Jpeg. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Mon Aug 1 16:13:10 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 1 Aug 2016 09:13:10 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8160736 : KSS : unnecessary class.forName in TIFFJPEGCompressor.java Message-ID: <78981446-253a-4dd7-aa89-9cda0e773705@default> Hi, Please review the following fix in JDK9 at your convenience : Bug : https://bugs.openjdk.java.net/browse/JDK-8160736 Webrev : http://cr.openjdk.java.net/~jdv/8160736/webrev.00/ Root Cause : KSS tool has detected usage of class.forName where it can be avoided. Solution : Use instead of using class.forName. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Aug 1 16:24:48 2016 From: philip.race at oracle.com (Philip Race) Date: Mon, 01 Aug 2016 09:24:48 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8160736 : KSS : unnecessary class.forName in TIFFJPEGCompressor.java In-Reply-To: <78981446-253a-4dd7-aa89-9cda0e773705@default> References: <78981446-253a-4dd7-aa89-9cda0e773705@default> Message-ID: <579F77D0.4020808@oracle.com> +1 -phil On 8/1/16, 9:13 AM, Jayathirth D V wrote: > > Hi, > > Please review the following fix in JDK9 at your convenience : > > Bug : https://bugs.openjdk.java.net/browse/JDK-8160736 > > Webrev : http://cr.openjdk.java.net/~jdv/8160736/webrev.00/ > > > Root Cause : KSS tool has detected usage of class.forName where it can > be avoided. > > Solution : Use instead of using class.forName. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vadim.pakhnushev at oracle.com Mon Aug 1 17:19:11 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Mon, 1 Aug 2016 20:19:11 +0300 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8160736 : KSS : unnecessary class.forName in TIFFJPEGCompressor.java In-Reply-To: <78981446-253a-4dd7-aa89-9cda0e773705@default> References: <78981446-253a-4dd7-aa89-9cda0e773705@default> Message-ID: <29774aba-9a37-939d-40d2-a6369e1a2ab3@oracle.com> Why not just registry.getServiceProviders(ImageReaderSpi.class, ? Vadim On 01.08.2016 19:13, Jayathirth D V wrote: > > Hi, > > Please review the following fix in JDK9 at your convenience : > > Bug : https://bugs.openjdk.java.net/browse/JDK-8160736 > > Webrev : http://cr.openjdk.java.net/~jdv/8160736/webrev.00/ > > > Root Cause : KSS tool has detected usage of class.forName where it can > be avoided. > > Solution : Use instead of using class.forName. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Aug 1 17:13:44 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 01 Aug 2016 10:13:44 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8074843: Resolve disabled warnings for libmlib_image and libmlib_image_v In-Reply-To: References: <579A95D6.3090604@oracle.com> <8ef6de35-011d-5218-3bdd-f3547e65ee29@oracle.com> <579B5A03.7000801@oracle.com> <4e04aa2a-da69-7983-2644-c1e7a5d23af3@oracle.com> <579B6885.6070706@oracle.com> <776d0e58-dff7-3b88-a1ca-480c806e42a4@oracle.com> <579C23B0.2030301@oracle.com> Message-ID: <579F8348.60009@oracle.com> Looking for another "+1" ... -phil. On 07/29/2016 10:13 PM, Vadim Pakhnushev wrote: > Looks good! > > Vadim > > On 30.07.2016 6:49, Philip Race wrote: >> See http://cr.openjdk.java.net/~prr/8074843.1/ >> >> Also passes JPRT >> >> -phil. >> >> On 7/29/16, 7:35 AM, Vadim Pakhnushev wrote: >>> On 29.07.2016 17:30, Philip Race wrote: >>>> >>>> >>>> On 7/29/16, 7:00 AM, Vadim Pakhnushev wrote: >>>>> On 29.07.2016 16:28, Philip Race wrote: >>>>>> >>>>>> >>>>>> On 7/29/16, 3:23 AM, Vadim Pakhnushev wrote: >>>>>>> Phil, >>>>>>> >>>>>>> I guess you wanted to remove the lines in the Awt2dLibraries.gmk? >>>>>> >>>>>> Ah, yes. Not just disable them >>>>>>> >>>>>>> Do you think it's worth it to rewrite these assignments as >>>>>>> separate assignment and a condition? >>>>>>> Especially long ones with a lot of parentheses? >>>>>>> Like this one, instead of >>>>>>> if ((j = ((mlib_s32) ((mlib_addr) psrc_row & 4) >> 2))) { >>>>>>> >>>>>>> j = (mlib_s32) ((mlib_addr) psrc_row & 4) >> 2; >>>>>>> if (j != 0) { >>>>>> >>>>>> I don't know. Where would I stop ? >>>>> >>>>> Where it doesn't feel weird anymore? >>>>> For example, is this line correct? >>>>> if (j = (((mlib_addr) pdst_row & 2) != 0)) { >>>>> It seems very weird for me that we assign a boolean value to the >>>>> loop variable. >>>>> It looks like there's an error in parentheses and it should >>>>> instead look like: >>>>> if ((j = (((mlib_addr) pdst_row & 2) != 0) { >>>>> Yeah, in this particular case it doesn't even matter but still >>>>> assignments in conditions can very easily lead to errors. >>>> >>>> OK I will take a *limited* look at this. >>> >>> Yeah it's just 2 identical lines in the mlib_c_ImageCopy.c >>> >>>>> >>>>>> >>>>>>> >>>>>>> Also seeing macro calls without a semicolon is weird. >>>>>>> I don't see any need in parentheses in the definition of >>>>>>> FREE_AND_RETURN_STATUS so maybe it's possible to rewrite it >>>>>>> without trailing semicolon? >>>>>> >>>>>> I anticipated the question and it is already addressed in my last >>>>>> paragraph right at the very bottom of the review request. >>>>> >>>>> Oops, missed that. >>>>> >>>>>> Basically that pattern has an "if (x==NULL) return". If you don't >>>>>> have that "if" then the compiler would have objected to that too ! >>>>> >>>>> I'm not sure I undestand this. >>>> >>>> I mean I without the condition the compiler can tell you *never* reach >>>> the while (0) and so objected on those grounds. I tried this. >>> >>> Got it. >>> >>>>> >>>>> I mean why not rewrite the macro like this: >>>>> #define FREE_AND_RETURN_STATUS \ >>>>> if (pbuff != buff) mlib_free(pbuff); \ >>>>> if (k != akernel) mlib_free(k); \ >>>>> return status >>>>> #endif /* FREE_AND_RETURN_STATUS */ >>>>> >>>>> Yes it's prone to errors like if (foo) FREE_AND_RETURN_STATUS; but >>>>> all its usages are separate statements. >>>> >>>> hmm .. I suppose could .. but not pretty either. >>>> Also if going that route it could be >>>> >>>> #define FREE_AND_RETURN_STATUS \ >>>> { \ >>>> if (pbuff != buff) mlib_free(pbuff); \ >>>> if (k != akernel) mlib_free(k); \ >>>> } \ >>>> return status >>>> #endif /* FREE_AND_RETURN_STATUS */ >>>> >>>> ?? >>> >>> What's the point of parentheses here? >>> I thought that the whole point of curly braces and do .... while(0) >>> stuff was to enable the macro calls in conditions like if (foo) >>> CALL_MACRO; without the curly braces around CALL_MACRO. >>> But if you put curly braces around only part of the macro definition >>> this would be broken anyway. >>> >>> Vadim >>> >>>> >>>> -phil. >>>>> >>>>> Vadim >>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Vadim >>>>>>> >>>>>>> On 29.07.2016 2:31, Philip Race wrote: >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074843 >>>>>>>> Fix: http://cr.openjdk.java.net/~prr/8074843/ >>>>>>>> >>>>>>>> Here's a sampling of the warnings that I think covers most, >>>>>>>> maybe all, of the cases >>>>>>>> LINUX >>>>>>>> mlib_ImageAffine_NN_Bit.c:87:81: error: suggest parentheses >>>>>>>> around '-' in operand of '&' [-Werror=parentheses] >>>>>>>> res = (res & ~(1 << bit)) | (((srcPixelPtr[X >> >>>>>>>> (MLIB_SHIFT + 3)] >> (7 - (X >> MLIB_SHIFT) & 7)) & 1) << >>>>>>>> ^ >>>>>>>> mlib_ImageAffine_NN_Bit.c:153:81: error: suggest parentheses >>>>>>>> around '-' in operand of '&' [-Werror=parentheses] >>>>>>>> res = (res & ~(1 << bit)) | (((srcPixelPtr[X >> >>>>>>>> (MLIB_SHIFT + 3)] >> (7 - (X >> MLIB_SHIFT) & 7)) & 1) << bit); >>>>>>>> >>>>>>>> ----------------- >>>>>>>> mlib_c_ImageCopy.c: In function 'mlib_c_ImageCopy_s16': >>>>>>>> mlib_c_ImageCopy.c:439:5: error: suggest parentheses around >>>>>>>> assignment used as truth value [-Werror=parentheses] >>>>>>>> STRIP(pdst, psrc, src_width, src_height, mlib_u16); >>>>>>>> ^ >>>>>>>> - >>>>>>>> MAC ... >>>>>>>> >>>>>>>> mlib_c_ImageCopy.c:331:5: error: using the result of an >>>>>>>> assignment as a condition without parentheses >>>>>>>> [-Werror,-Wparentheses] >>>>>>>> STRIP(pdst, psrc, src_width, src_height, mlib_u8); >>>>>>>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>>>>> mlib_c_ImageCopy.c:185:11: note: expanded from macro 'STRIP' >>>>>>>> if (j = w & 1) \ >>>>>>>> ~~^~~~~~~ >>>>>>>> mlib_c_ImageCopy.c:331:5: note: place parentheses around the >>>>>>>> assignment to silence this warning\ >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> >>>>>>>> --- >>>>>>>> SOLARIS >>>>>>>> mlib_ImageConv_16ext.c", line 532: statement not reached >>>>>>>> (E_STATEMENT_NOT_REACHED) >>>>>>>> >>>>>>>> This last one was not nice just the ";" was considered a statement >>>>>>>> after the {XX; YY; return Z} macro expansion >>>>>>>> and turning into "do { {....} } while (0)" did not help since >>>>>>>> then it said "loop terminator not reached - other cases we have >>>>>>>> like this have at least a condition in the macro. >>>>>>>> >>>>>>>> -phil. >>>>>>> >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Aug 1 17:15:14 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 01 Aug 2016 10:15:14 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8160736 : KSS : unnecessary class.forName in TIFFJPEGCompressor.java In-Reply-To: <29774aba-9a37-939d-40d2-a6369e1a2ab3@oracle.com> References: <78981446-253a-4dd7-aa89-9cda0e773705@default> <29774aba-9a37-939d-40d2-a6369e1a2ab3@oracle.com> Message-ID: <579F83A2.8090102@oracle.com> That would be fine too. The main thing was getting rid of Class.forName -phil. On 08/01/2016 10:19 AM, Vadim Pakhnushev wrote: > Why not just registry.getServiceProviders(ImageReaderSpi.class, ? > > Vadim > > On 01.08.2016 19:13, Jayathirth D V wrote: >> >> Hi, >> >> Please review the following fix in JDK9 at your convenience : >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8160736 >> >> Webrev : http://cr.openjdk.java.net/~jdv/8160736/webrev.00/ >> >> >> Root Cause : KSS tool has detected usage of class.forName where it >> can be avoided. >> >> Solution : Use instead of using class.forName. >> >> Thanks, >> >> Jay >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Mon Aug 1 18:41:35 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 1 Aug 2016 11:41:35 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8160736 : KSS : unnecessary class.forName in TIFFJPEGCompressor.java In-Reply-To: <579F83A2.8090102@oracle.com> References: <78981446-253a-4dd7-aa89-9cda0e773705@default> <29774aba-9a37-939d-40d2-a6369e1a2ab3@oracle.com> <579F83A2.8090102@oracle.com> Message-ID: <86CAB8B5-EC04-4516-A574-343FB7CFC2B6@oracle.com> +1 for the review with a preference for Vadim?s suggestion. Brian On Aug 1, 2016, at 10:15 AM, Phil Race wrote: > That would be fine too. The main thing was getting rid of Class.forName > > -phil. > > On 08/01/2016 10:19 AM, Vadim Pakhnushev wrote: >> Why not just registry.getServiceProviders(ImageReaderSpi.class, ? >> >> Vadim >> >> On 01.08.2016 19:13, Jayathirth D V wrote: >>> Hi, >>> >>> Please review the following fix in JDK9 at your convenience : >>> >>> Bug :https://bugs.openjdk.java.net/browse/JDK-8160736 >>> Webrev :http://cr.openjdk.java.net/~jdv/8160736/webrev.00/ >>> >>> Root Cause : KSS tool has detected usage of class.forName where it can be avoided. >>> Solution : Use instead of using class.forName. >>> >>> Thanks, >>> Jay >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Mon Aug 1 20:00:00 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 1 Aug 2016 13:00:00 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8160943 : skipImage() in JPEGImageReader class throws IIOException if we have gaps between markers in Jpeg image In-Reply-To: <1dccad2c-3348-447b-b132-2cc2a242a9c3@default> References: <1dccad2c-3348-447b-b132-2cc2a242a9c3@default> Message-ID: Hi Jay, This looks good... ...jim On 8/1/16 1:26 AM, Jayathirth D V wrote: > Hi, > > > > Please review the following fix in JDK9 at your convenience: > > > > Bug : https://bugs.openjdk.java.net/browse/JDK-8160943 > > Webrev : http://cr.openjdk.java.net/~jdv/8160943/webrev.00/ > > > > Root cause : While fixing JDK-8152672 we considered that there can be no data in Jpeg image which can be like ?FF FF? > and we threw IIOException if we find data as ?FF FF? and considered it as invalid marker. > > > > Solution : According to https://www.w3.org/Graphics/JPEG/itu-t81.pdf there can be gaps between markers in Jpeg image and > it can contain fill bits like ?X FF?. > > In this case if a fill bit is followed by any valid maker in Jpeg it will contain sequence of data which will be ?FF > FF?. So we should not consider ?FF FF? as invalid marker and just parse through it. Added check to consider ?FF FF? as > normal data in Jpeg. > > > > Thanks, > > Jay > From bourges.laurent at gmail.com Mon Aug 1 21:17:37 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Mon, 1 Aug 2016 23:17:37 +0200 Subject: [OpenJDK 2D-Dev] RFR 8159638: Improve array caches and renderer stats in Marlin renderer In-Reply-To: <5480c2b9-a8fd-bc42-6e75-1b17c129dd59@oracle.com> References: <8d819ad0-342b-15cb-8afc-bdda5da52a5d@oracle.com> <5480c2b9-a8fd-bc42-6e75-1b17c129dd59@oracle.com> Message-ID: Hi Jim, Here is an updated webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8159638.1/ Changes: - merge Clean/Dirty Xxx ArrayCache using the flag 'clean' to indicate if the cache is clean or dirty + the putArray method always performs the array cleanup - ArrayCache renamed to ArrayCacheConst + simplified thresholds More comments, below: 2016-07-21 23:41 GMT+02:00 Jim Graham : > > On 07/21/2016 06:56 AM, Laurent Bourg?s wrote: > >> I don't have any issues with those numbers, but the way that they >> are calculated makes it look like they are supposed to be unique >> numbers and yet through the obscurity of the loops used to populate >> the sizes they just end up all being the same numbers - it makes me >> wonder if there was a mistake in there or not...? >> >> >> Initially these values have different values / meanings but it can be >> simplified now. >> > > To be clear, I wasn't complaining about the multitude of thresholds, but > rather that the way they were apportioned - sort of as a side effect of the > computations in a loop - ended up accidentally squashing a couple of them > out of existence. Another option would be to make sure that the thresholds > make sense, but keep all 4 threshold ranges, but you are the one who knows > the details of how these sizes impact performance... > Simplified a bit + fixed comments. > > It feels odd to have all of the cache classes import the static >> members of ArrayCache rather than just subclassing it. Is there a >> reason it wasn't just subclassed? >> >> >> As all the members are static, I prefer having an explicit static import >> instead of subclasses. >> Moreover, I deliberately avoided any class inheritance to avoid the >> performance penalty of bimorphic / megamorphic method calls (abstract or >> overriden methods). >> > > First, I would have expected MumbleArrayCache classes to be a subclass of > the ArrayCache class in the first place. If it is not going to be the base > class then it should have the name "ArrayCacheUtils" or "Const" or > something. > Renamed to ArrayCacheConst. > > Second, wildcard imports are recommended against. > > Finally, if you are going to use static methods from another class I would > much rather see explicit naming rather than importing them. While static > imports work for methods as well as constants, they are typically used for > constants and it is confusing to apply them to methods. > Fixed. > The only reason is performance: I want to ensure straightforward method >> calls ie no bimorphic or virtual calls to be inlined by hotspot. Maybe >> such fear or approach is too conservative i.e. the performance penalty >> is too small to consider such optimization. I made many tests with jmh >> (in june) but I agree the design can be simpler: >> - abstract [Byte/Int/Float]ArrayCache (where putArray() is abstract) >> - Clean[Byte/Int/Float]ArrayCache and Dirty[Byte/Int/Float]ArrayCache >> implements properly the putArray method but also the createArray() >> method (new array or Unsafe.allocateUninitializedArray) >> >> I could try again but I prefer the current design as it is (overly) >> strongly typed. >> Please propose an alternative / simpler design ! >> > > That's something that can be investigated later as it would be a big > disruption for the current task. Generally, though, as long as the leaf > classes are final and the cache classes are strongly typed then HS should > inline freely. > I adopted a simple boolean flag 'clean' to perform the optional cleanup and renamed classes to Byte/Float/Int ArrayCache. > > Also, since you never put the initial arrays, they aren't >> automatically cleaned...? >> >> Exactly: initial arrays are allocated by the Reference class and >> directly used by callers (fill / clean) and the XxxArrayCache never >> touch them. >> > > What I was getting at was that this was potentially a bug? If you carry > over use of an initial array in a clean setting without calling to the > cache object, then who clears the used portion? > > All cases are manually cleaned in MarlinCache.resetTileLine(), >> Renderer.dispose() and MarlinCache.copyAARowNoRLE...() for alphaLine and >> blkFlags arrays with several cleanup patterns (optimized and >> performance-critical). >> > > I see. Is this really a noticeable performance issue to rely on the cache > to do the cleaning and have much more readable code? > I adopted your proposal and simplified the code in Renderer: the Reference.putArray() clears the array portion if needed in all cases. The performance impact is very low: only 3% when the shape count is huge. Cheers, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Mon Aug 1 23:55:54 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 1 Aug 2016 16:55:54 -0700 Subject: [OpenJDK 2D-Dev] RFR 8159638: Improve array caches and renderer stats in Marlin renderer In-Reply-To: References: <8d819ad0-342b-15cb-8afc-bdda5da52a5d@oracle.com> <5480c2b9-a8fd-bc42-6e75-1b17c129dd59@oracle.com> Message-ID: Hi Laurent, A tip on webrevs, if you supply a file of filenames then you can tell it to diff a file with a name change against its former name by using 2 filenames on the same line, as in: -------- filetodiff1.java filetodiff2.java filetodiff3.java filetodiff3oldname.java filetodiff4.java -------- In Renderer.java, you create the alphaLine and blkFlags refs as Clean, but then you always put them back using indices of (0, 0) so they will never actually be cleaned - is there a reason you don't just use a dirty ref there? Other than that question, I don't see any problems with the fix... ...jim On 08/01/2016 02:17 PM, Laurent Bourg?s wrote: > Hi Jim, > > Here is an updated webrev: > http://cr.openjdk.java.net/~lbourges/marlin/marlin-8159638.1/ > > Changes: > - merge Clean/Dirty Xxx ArrayCache using the flag 'clean' to indicate if > the cache is clean or dirty + the putArray method always performs the > array cleanup > - ArrayCache renamed to ArrayCacheConst + simplified thresholds > > More comments, below: > > 2016-07-21 23:41 GMT+02:00 Jim Graham >: > > > On 07/21/2016 06:56 AM, Laurent Bourg?s wrote: > > I don't have any issues with those numbers, but the way that > they > are calculated makes it look like they are supposed to be unique > numbers and yet through the obscurity of the loops used to > populate > the sizes they just end up all being the same numbers - it > makes me > wonder if there was a mistake in there or not...? > > > Initially these values have different values / meanings but it > can be > simplified now. > > > To be clear, I wasn't complaining about the multitude of thresholds, > but rather that the way they were apportioned - sort of as a side > effect of the computations in a loop - ended up accidentally > squashing a couple of them out of existence. Another option would > be to make sure that the thresholds make sense, but keep all 4 > threshold ranges, but you are the one who knows the details of how > these sizes impact performance... > > > Simplified a bit + fixed comments. > > > > It feels odd to have all of the cache classes import the static > members of ArrayCache rather than just subclassing it. Is > there a > reason it wasn't just subclassed? > > > As all the members are static, I prefer having an explicit > static import > instead of subclasses. > Moreover, I deliberately avoided any class inheritance to avoid the > performance penalty of bimorphic / megamorphic method calls > (abstract or > overriden methods). > > > First, I would have expected MumbleArrayCache classes to be a > subclass of the ArrayCache class in the first place. If it is not > going to be the base class then it should have the name > "ArrayCacheUtils" or "Const" or something. > > > Renamed to ArrayCacheConst. > > > > Second, wildcard imports are recommended against. > > Finally, if you are going to use static methods from another class I > would much rather see explicit naming rather than importing them. > While static imports work for methods as well as constants, they are > typically used for constants and it is confusing to apply them to > methods. > > > Fixed. > > > The only reason is performance: I want to ensure straightforward > method > calls ie no bimorphic or virtual calls to be inlined by hotspot. > Maybe > such fear or approach is too conservative i.e. the performance > penalty > is too small to consider such optimization. I made many tests > with jmh > (in june) but I agree the design can be simpler: > - abstract [Byte/Int/Float]ArrayCache (where putArray() is abstract) > - Clean[Byte/Int/Float]ArrayCache and > Dirty[Byte/Int/Float]ArrayCache > implements properly the putArray method but also the createArray() > method (new array or Unsafe.allocateUninitializedArray) > > I could try again but I prefer the current design as it is (overly) > strongly typed. > Please propose an alternative / simpler design ! > > > That's something that can be investigated later as it would be a big > disruption for the current task. Generally, though, as long as the > leaf classes are final and the cache classes are strongly typed then > HS should inline freely. > > > I adopted a simple boolean flag 'clean' to perform the optional cleanup > and renamed classes to Byte/Float/Int ArrayCache. > > > > Also, since you never put the initial arrays, they aren't > automatically cleaned...? > > Exactly: initial arrays are allocated by the Reference class and > directly used by callers (fill / clean) and the XxxArrayCache never > touch them. > > > What I was getting at was that this was potentially a bug? If you > carry over use of an initial array in a clean setting without > calling to the cache object, then who clears the used portion? > > All cases are manually cleaned in MarlinCache.resetTileLine(), > Renderer.dispose() and MarlinCache.copyAARowNoRLE...() for > alphaLine and > blkFlags arrays with several cleanup patterns (optimized and > performance-critical). > > > I see. Is this really a noticeable performance issue to rely on the > cache to do the cleaning and have much more readable code? > > > I adopted your proposal and simplified the code in Renderer: the > Reference.putArray() clears the array portion if needed in all cases. > The performance impact is very low: only 3% when the shape count is huge. > > > Cheers, > Laurent From prasanta.sadhukhan at oracle.com Tue Aug 2 05:48:24 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 2 Aug 2016 11:18:24 +0530 Subject: [OpenJDK 2D-Dev] RFR: 8074843: Resolve disabled warnings for libmlib_image and libmlib_image_v In-Reply-To: <579F8348.60009@oracle.com> References: <579A95D6.3090604@oracle.com> <8ef6de35-011d-5218-3bdd-f3547e65ee29@oracle.com> <579B5A03.7000801@oracle.com> <4e04aa2a-da69-7983-2644-c1e7a5d23af3@oracle.com> <579B6885.6070706@oracle.com> <776d0e58-dff7-3b88-a1ca-480c806e42a4@oracle.com> <579C23B0.2030301@oracle.com> <579F8348.60009@oracle.com> Message-ID: <57A03428.3060501@oracle.com> +1. Only one thing, mlib_c_ImageCopy.c#185 do we really need that extra parentheses, ((j = (w & 1))). I guess this should just do if (j = (w & 1)), isn't it? Regards Prasanta On 8/1/2016 10:43 PM, Phil Race wrote: > Looking for another "+1" ... > > -phil. > > On 07/29/2016 10:13 PM, Vadim Pakhnushev wrote: >> Looks good! >> >> Vadim >> >> On 30.07.2016 6:49, Philip Race wrote: >>> See http://cr.openjdk.java.net/~prr/8074843.1/ >>> >>> Also passes JPRT >>> >>> -phil. >>> >>> On 7/29/16, 7:35 AM, Vadim Pakhnushev wrote: >>>> On 29.07.2016 17:30, Philip Race wrote: >>>>> >>>>> >>>>> On 7/29/16, 7:00 AM, Vadim Pakhnushev wrote: >>>>>> On 29.07.2016 16:28, Philip Race wrote: >>>>>>> >>>>>>> >>>>>>> On 7/29/16, 3:23 AM, Vadim Pakhnushev wrote: >>>>>>>> Phil, >>>>>>>> >>>>>>>> I guess you wanted to remove the lines in the Awt2dLibraries.gmk? >>>>>>> >>>>>>> Ah, yes. Not just disable them >>>>>>>> >>>>>>>> Do you think it's worth it to rewrite these assignments as >>>>>>>> separate assignment and a condition? >>>>>>>> Especially long ones with a lot of parentheses? >>>>>>>> Like this one, instead of >>>>>>>> if ((j = ((mlib_s32) ((mlib_addr) psrc_row & 4) >> 2))) { >>>>>>>> >>>>>>>> j = (mlib_s32) ((mlib_addr) psrc_row & 4) >> 2; >>>>>>>> if (j != 0) { >>>>>>> >>>>>>> I don't know. Where would I stop ? >>>>>> >>>>>> Where it doesn't feel weird anymore? >>>>>> For example, is this line correct? >>>>>> if (j = (((mlib_addr) pdst_row & 2) != 0)) { >>>>>> It seems very weird for me that we assign a boolean value to the >>>>>> loop variable. >>>>>> It looks like there's an error in parentheses and it should >>>>>> instead look like: >>>>>> if ((j = (((mlib_addr) pdst_row & 2) != 0) { >>>>>> Yeah, in this particular case it doesn't even matter but still >>>>>> assignments in conditions can very easily lead to errors. >>>>> >>>>> OK I will take a *limited* look at this. >>>> >>>> Yeah it's just 2 identical lines in the mlib_c_ImageCopy.c >>>> >>>>>> >>>>>>> >>>>>>>> >>>>>>>> Also seeing macro calls without a semicolon is weird. >>>>>>>> I don't see any need in parentheses in the definition of >>>>>>>> FREE_AND_RETURN_STATUS so maybe it's possible to rewrite it >>>>>>>> without trailing semicolon? >>>>>>> >>>>>>> I anticipated the question and it is already addressed in my last >>>>>>> paragraph right at the very bottom of the review request. >>>>>> >>>>>> Oops, missed that. >>>>>> >>>>>>> Basically that pattern has an "if (x==NULL) return". If you don't >>>>>>> have that "if" then the compiler would have objected to that too ! >>>>>> >>>>>> I'm not sure I undestand this. >>>>> >>>>> I mean I without the condition the compiler can tell you *never* >>>>> reach >>>>> the while (0) and so objected on those grounds. I tried this. >>>> >>>> Got it. >>>> >>>>>> >>>>>> I mean why not rewrite the macro like this: >>>>>> #define FREE_AND_RETURN_STATUS \ >>>>>> if (pbuff != buff) mlib_free(pbuff); \ >>>>>> if (k != akernel) mlib_free(k); \ >>>>>> return status >>>>>> #endif /* FREE_AND_RETURN_STATUS */ >>>>>> >>>>>> Yes it's prone to errors like if (foo) FREE_AND_RETURN_STATUS; >>>>>> but all its usages are separate statements. >>>>> >>>>> hmm .. I suppose could .. but not pretty either. >>>>> Also if going that route it could be >>>>> >>>>> #define FREE_AND_RETURN_STATUS \ >>>>> { \ >>>>> if (pbuff != buff) mlib_free(pbuff); \ >>>>> if (k != akernel) mlib_free(k); \ >>>>> } \ >>>>> return status >>>>> #endif /* FREE_AND_RETURN_STATUS */ >>>>> >>>>> ?? >>>> >>>> What's the point of parentheses here? >>>> I thought that the whole point of curly braces and do .... while(0) >>>> stuff was to enable the macro calls in conditions like if (foo) >>>> CALL_MACRO; without the curly braces around CALL_MACRO. >>>> But if you put curly braces around only part of the macro >>>> definition this would be broken anyway. >>>> >>>> Vadim >>>> >>>>> >>>>> -phil. >>>>>> >>>>>> Vadim >>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vadim >>>>>>>> >>>>>>>> On 29.07.2016 2:31, Philip Race wrote: >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074843 >>>>>>>>> Fix: http://cr.openjdk.java.net/~prr/8074843/ >>>>>>>>> >>>>>>>>> Here's a sampling of the warnings that I think covers most, >>>>>>>>> maybe all, of the cases >>>>>>>>> LINUX >>>>>>>>> mlib_ImageAffine_NN_Bit.c:87:81: error: suggest parentheses >>>>>>>>> around '-' in operand of '&' [-Werror=parentheses] >>>>>>>>> res = (res & ~(1 << bit)) | (((srcPixelPtr[X >> >>>>>>>>> (MLIB_SHIFT + 3)] >> (7 - (X >> MLIB_SHIFT) & 7)) & 1) << >>>>>>>>> ^ >>>>>>>>> mlib_ImageAffine_NN_Bit.c:153:81: error: suggest parentheses >>>>>>>>> around '-' in operand of '&' [-Werror=parentheses] >>>>>>>>> res = (res & ~(1 << bit)) | (((srcPixelPtr[X >> >>>>>>>>> (MLIB_SHIFT + 3)] >> (7 - (X >> MLIB_SHIFT) & 7)) & 1) << bit); >>>>>>>>> >>>>>>>>> ----------------- >>>>>>>>> mlib_c_ImageCopy.c: In function 'mlib_c_ImageCopy_s16': >>>>>>>>> mlib_c_ImageCopy.c:439:5: error: suggest parentheses around >>>>>>>>> assignment used as truth value [-Werror=parentheses] >>>>>>>>> STRIP(pdst, psrc, src_width, src_height, mlib_u16); >>>>>>>>> ^ >>>>>>>>> - >>>>>>>>> MAC ... >>>>>>>>> >>>>>>>>> mlib_c_ImageCopy.c:331:5: error: using the result of an >>>>>>>>> assignment as a condition without parentheses >>>>>>>>> [-Werror,-Wparentheses] >>>>>>>>> STRIP(pdst, psrc, src_width, src_height, mlib_u8); >>>>>>>>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>>>>>> mlib_c_ImageCopy.c:185:11: note: expanded from macro 'STRIP' >>>>>>>>> if (j = w & 1) \ >>>>>>>>> ~~^~~~~~~ >>>>>>>>> mlib_c_ImageCopy.c:331:5: note: place parentheses around the >>>>>>>>> assignment to silence this warning\ >>>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> >>>>>>>>> --- >>>>>>>>> SOLARIS >>>>>>>>> mlib_ImageConv_16ext.c", line 532: statement not reached >>>>>>>>> (E_STATEMENT_NOT_REACHED) >>>>>>>>> >>>>>>>>> This last one was not nice just the ";" was considered a statement >>>>>>>>> after the {XX; YY; return Z} macro expansion >>>>>>>>> and turning into "do { {....} } while (0)" did not help since >>>>>>>>> then it said "loop terminator not reached - other cases we have >>>>>>>>> like this have at least a condition in the macro. >>>>>>>>> >>>>>>>>> -phil. >>>>>>>> >>>>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vadim.pakhnushev at oracle.com Tue Aug 2 06:58:43 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Tue, 2 Aug 2016 09:58:43 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8074843: Resolve disabled warnings for libmlib_image and libmlib_image_v In-Reply-To: <57A03428.3060501@oracle.com> References: <579A95D6.3090604@oracle.com> <8ef6de35-011d-5218-3bdd-f3547e65ee29@oracle.com> <579B5A03.7000801@oracle.com> <4e04aa2a-da69-7983-2644-c1e7a5d23af3@oracle.com> <579B6885.6070706@oracle.com> <776d0e58-dff7-3b88-a1ca-480c806e42a4@oracle.com> <579C23B0.2030301@oracle.com> <579F8348.60009@oracle.com> <57A03428.3060501@oracle.com> Message-ID: That's what warning said: "place parentheses *around the assignment *to silence this warning" Vadim On 02.08.2016 8:48, Prasanta Sadhukhan wrote: > +1. Only one thing, > > mlib_c_ImageCopy.c#185 do we really need that extra parentheses, > ((j = (w & 1))). I guess this should just do if (j = (w & 1)), isn't it? Regards > Prasanta > On 8/1/2016 10:43 PM, Phil Race wrote: >> Looking for another "+1" ... >> >> -phil. >> >> On 07/29/2016 10:13 PM, Vadim Pakhnushev wrote: >>> Looks good! >>> >>> Vadim >>> >>> On 30.07.2016 6:49, Philip Race wrote: >>>> See http://cr.openjdk.java.net/~prr/8074843.1/ >>>> >>>> Also passes JPRT >>>> >>>> -phil. >>>> >>>> On 7/29/16, 7:35 AM, Vadim Pakhnushev wrote: >>>>> On 29.07.2016 17:30, Philip Race wrote: >>>>>> >>>>>> >>>>>> On 7/29/16, 7:00 AM, Vadim Pakhnushev wrote: >>>>>>> On 29.07.2016 16:28, Philip Race wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 7/29/16, 3:23 AM, Vadim Pakhnushev wrote: >>>>>>>>> Phil, >>>>>>>>> >>>>>>>>> I guess you wanted to remove the lines in the Awt2dLibraries.gmk? >>>>>>>> >>>>>>>> Ah, yes. Not just disable them >>>>>>>>> >>>>>>>>> Do you think it's worth it to rewrite these assignments as >>>>>>>>> separate assignment and a condition? >>>>>>>>> Especially long ones with a lot of parentheses? >>>>>>>>> Like this one, instead of >>>>>>>>> if ((j = ((mlib_s32) ((mlib_addr) psrc_row & 4) >> 2))) { >>>>>>>>> >>>>>>>>> j = (mlib_s32) ((mlib_addr) psrc_row & 4) >> 2; >>>>>>>>> if (j != 0) { >>>>>>>> >>>>>>>> I don't know. Where would I stop ? >>>>>>> >>>>>>> Where it doesn't feel weird anymore? >>>>>>> For example, is this line correct? >>>>>>> if (j = (((mlib_addr) pdst_row & 2) != 0)) { >>>>>>> It seems very weird for me that we assign a boolean value to the >>>>>>> loop variable. >>>>>>> It looks like there's an error in parentheses and it should >>>>>>> instead look like: >>>>>>> if ((j = (((mlib_addr) pdst_row & 2) != 0) { >>>>>>> Yeah, in this particular case it doesn't even matter but still >>>>>>> assignments in conditions can very easily lead to errors. >>>>>> >>>>>> OK I will take a *limited* look at this. >>>>> >>>>> Yeah it's just 2 identical lines in the mlib_c_ImageCopy.c >>>>> >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Also seeing macro calls without a semicolon is weird. >>>>>>>>> I don't see any need in parentheses in the definition of >>>>>>>>> FREE_AND_RETURN_STATUS so maybe it's possible to rewrite it >>>>>>>>> without trailing semicolon? >>>>>>>> >>>>>>>> I anticipated the question and it is already addressed in my last >>>>>>>> paragraph right at the very bottom of the review request. >>>>>>> >>>>>>> Oops, missed that. >>>>>>> >>>>>>>> Basically that pattern has an "if (x==NULL) return". If you don't >>>>>>>> have that "if" then the compiler would have objected to that too ! >>>>>>> >>>>>>> I'm not sure I undestand this. >>>>>> >>>>>> I mean I without the condition the compiler can tell you *never* >>>>>> reach >>>>>> the while (0) and so objected on those grounds. I tried this. >>>>> >>>>> Got it. >>>>> >>>>>>> >>>>>>> I mean why not rewrite the macro like this: >>>>>>> #define FREE_AND_RETURN_STATUS \ >>>>>>> if (pbuff != buff) mlib_free(pbuff); \ >>>>>>> if (k != akernel) mlib_free(k); \ >>>>>>> return status >>>>>>> #endif /* FREE_AND_RETURN_STATUS */ >>>>>>> >>>>>>> Yes it's prone to errors like if (foo) FREE_AND_RETURN_STATUS; >>>>>>> but all its usages are separate statements. >>>>>> >>>>>> hmm .. I suppose could .. but not pretty either. >>>>>> Also if going that route it could be >>>>>> >>>>>> #define FREE_AND_RETURN_STATUS \ >>>>>> { \ >>>>>> if (pbuff != buff) mlib_free(pbuff); \ >>>>>> if (k != akernel) mlib_free(k); \ >>>>>> } \ >>>>>> return status >>>>>> #endif /* FREE_AND_RETURN_STATUS */ >>>>>> >>>>>> ?? >>>>> >>>>> What's the point of parentheses here? >>>>> I thought that the whole point of curly braces and do .... >>>>> while(0) stuff was to enable the macro calls in conditions like if >>>>> (foo) CALL_MACRO; without the curly braces around CALL_MACRO. >>>>> But if you put curly braces around only part of the macro >>>>> definition this would be broken anyway. >>>>> >>>>> Vadim >>>>> >>>>>> >>>>>> -phil. >>>>>>> >>>>>>> Vadim >>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vadim >>>>>>>>> >>>>>>>>> On 29.07.2016 2:31, Philip Race wrote: >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074843 >>>>>>>>>> Fix: http://cr.openjdk.java.net/~prr/8074843/ >>>>>>>>>> >>>>>>>>>> Here's a sampling of the warnings that I think covers most, >>>>>>>>>> maybe all, of the cases >>>>>>>>>> LINUX >>>>>>>>>> mlib_ImageAffine_NN_Bit.c:87:81: error: suggest parentheses >>>>>>>>>> around '-' in operand of '&' [-Werror=parentheses] >>>>>>>>>> res = (res & ~(1 << bit)) | (((srcPixelPtr[X >> >>>>>>>>>> (MLIB_SHIFT + 3)] >> (7 - (X >> MLIB_SHIFT) & 7)) & 1) << >>>>>>>>>> ^ >>>>>>>>>> mlib_ImageAffine_NN_Bit.c:153:81: error: suggest parentheses >>>>>>>>>> around '-' in operand of '&' [-Werror=parentheses] >>>>>>>>>> res = (res & ~(1 << bit)) | (((srcPixelPtr[X >> >>>>>>>>>> (MLIB_SHIFT + 3)] >> (7 - (X >> MLIB_SHIFT) & 7)) & 1) << bit); >>>>>>>>>> >>>>>>>>>> ----------------- >>>>>>>>>> mlib_c_ImageCopy.c: In function 'mlib_c_ImageCopy_s16': >>>>>>>>>> mlib_c_ImageCopy.c:439:5: error: suggest parentheses around >>>>>>>>>> assignment used as truth value [-Werror=parentheses] >>>>>>>>>> STRIP(pdst, psrc, src_width, src_height, mlib_u16); >>>>>>>>>> ^ >>>>>>>>>> - >>>>>>>>>> MAC ... >>>>>>>>>> >>>>>>>>>> mlib_c_ImageCopy.c:331:5: error: using the result of an >>>>>>>>>> assignment as a condition without parentheses >>>>>>>>>> [-Werror,-Wparentheses] >>>>>>>>>> STRIP(pdst, psrc, src_width, src_height, mlib_u8); >>>>>>>>>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>>>>>>> mlib_c_ImageCopy.c:185:11: note: expanded from macro 'STRIP' >>>>>>>>>> if (j = w & 1) \ >>>>>>>>>> ~~^~~~~~~ >>>>>>>>>> mlib_c_ImageCopy.c:331:5: note: place parentheses around the >>>>>>>>>> assignment to silence this warning\ >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> SOLARIS >>>>>>>>>> mlib_ImageConv_16ext.c", line 532: statement not reached >>>>>>>>>> (E_STATEMENT_NOT_REACHED) >>>>>>>>>> >>>>>>>>>> This last one was not nice just the ";" was considered a >>>>>>>>>> statement >>>>>>>>>> after the {XX; YY; return Z} macro expansion >>>>>>>>>> and turning into "do { {....} } while (0)" did not help since >>>>>>>>>> then it said "loop terminator not reached - other cases we have >>>>>>>>>> like this have at least a condition in the macro. >>>>>>>>>> >>>>>>>>>> -phil. >>>>>>>>> >>>>>>> >>>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajit.ghaisas at oracle.com Tue Aug 2 09:01:45 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Tue, 2 Aug 2016 02:01:45 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] Fix for JDK-6427331 : NullPointerException in LookupOp.filter(Raster, WritableRaster) Message-ID: <6a19c251-121c-4bcd-917b-e86af7e41134@default> Hi, Bug : https://bugs.openjdk.java.net/browse/JDK-6427331 Issue : If destination raster is provided as null to java.awt.image.LookupOp.filter(Raster src, WritableRaster dest), according to Javadoc, a new raster should be created. Instead, it results in NullPointerException. Fix : http://cr.openjdk.java.net/~aghaisas/6427331/webrev.00/ Request you to review. Regards, Ajit -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Tue Aug 2 09:29:20 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 2 Aug 2016 14:59:20 +0530 Subject: [OpenJDK 2D-Dev] [9] Fix for JDK-6427331 : NullPointerException in LookupOp.filter(Raster, WritableRaster) In-Reply-To: <6a19c251-121c-4bcd-917b-e86af7e41134@default> References: <6a19c251-121c-4bcd-917b-e86af7e41134@default> Message-ID: <57A067F0.5080803@oracle.com> +1. Just check other op file like Rescale, Convolve if similar problem exists there too. Regards Prasanta On 8/2/2016 2:31 PM, Ajit Ghaisas wrote: > > Hi, > > Bug : https://bugs.openjdk.java.net/browse/JDK-6427331 > > Issue : If destination raster is provided as null to > java.awt.image.LookupOp.filter(Raster src, WritableRaster dest), > > according to Javadoc, a new raster should be created. > Instead, it results in NullPointerException. > > Fix : http://cr.openjdk.java.net/~aghaisas/6427331/webrev.00/ > > > Request you to review. > > Regards, > > Ajit > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Tue Aug 2 09:56:49 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 2 Aug 2016 02:56:49 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8160736 : KSS : unnecessary class.forName in TIFFJPEGCompressor.java In-Reply-To: <86CAB8B5-EC04-4516-A574-343FB7CFC2B6@oracle.com> References: <78981446-253a-4dd7-aa89-9cda0e773705@default> <29774aba-9a37-939d-40d2-a6369e1a2ab3@oracle.com> <579F83A2.8090102@oracle.com> <86CAB8B5-EC04-4516-A574-343FB7CFC2B6@oracle.com> Message-ID: <27832b40-5f80-41bb-8116-04ce6964c96c@default> Hi, Thanks for the review. Yes we can use it directly in the argument of getServiceProviders() API. Please find updated webrev for reference: http://cr.openjdk.java.net/~jdv/8160736/webrev.01/ I will be pushing the updated change into repo. Regards, Jay From: Brian Burkhalter Sent: Tuesday, August 02, 2016 12:12 AM To: Phil Race Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-8160736 : KSS : unnecessary class.forName in TIFFJPEGCompressor.java +1 for the review with a preference for Vadim's suggestion. Brian On Aug 1, 2016, at 10:15 AM, Phil Race wrote: That would be fine too. The main thing was getting rid of Class.forName -phil. On 08/01/2016 10:19 AM, Vadim Pakhnushev wrote: Why not just registry.getServiceProviders(ImageReaderSpi.class, ? Vadim On 01.08.2016 19:13, Jayathirth D V wrote: Hi, Please review the following fix in JDK9 at your convenience : Bug :https://bugs.openjdk.java.net/browse/JDK-8160736 Webrev :HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8160736/webrev.00/"http://cr.openjdk.java.net/~jdv/8160736/webrev.00/ Root Cause : KSS tool has detected usage of class.forName where it can be avoided. Solution : Use instead of using class.forName. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajit.ghaisas at oracle.com Tue Aug 2 12:50:01 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Tue, 2 Aug 2016 05:50:01 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] Fix for JDK-6427331 : NullPointerException in LookupOp.filter(Raster, WritableRaster) In-Reply-To: <57A067F0.5080803@oracle.com> References: <6a19c251-121c-4bcd-917b-e86af7e41134@default> <57A067F0.5080803@oracle.com> Message-ID: Thanks Prasanta. I checked filter() methods of following classes - AffineTransformOp, ColorConvertOp, ConvolveOp, LookupOp, RescaleOp and BandCombineOp. They do not have this issue of accessing null destination buffer/raster. From: Prasanta Sadhukhan Sent: Tuesday, August 02, 2016 2:59 PM To: Ajit Ghaisas; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [9] Fix for JDK-6427331 : NullPointerException in LookupOp.filter(Raster, WritableRaster) +1. Just check other op file like Rescale, Convolve if similar problem exists there too. Regards Prasanta On 8/2/2016 2:31 PM, Ajit Ghaisas wrote: Hi, Bug : https://bugs.openjdk.java.net/browse/JDK-6427331 Issue : If destination raster is provided as null to java.awt.image.LookupOp.filter(Raster src, WritableRaster dest), according to Javadoc, a new raster should be created. Instead, it results in NullPointerException. Fix : HYPERLINK "http://cr.openjdk.java.net/%7Eaghaisas/6427331/webrev.00/"http://cr.openjdk.java.net/~aghaisas/6427331/webrev.00/ Request you to review. Regards, Ajit -------------- next part -------------- An HTML attachment was scrubbed... URL: From bourges.laurent at gmail.com Tue Aug 2 12:57:03 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 2 Aug 2016 14:57:03 +0200 Subject: [OpenJDK 2D-Dev] RFR 8159638: Improve array caches and renderer stats in Marlin renderer In-Reply-To: References: <8d819ad0-342b-15cb-8afc-bdda5da52a5d@oracle.com> <5480c2b9-a8fd-bc42-6e75-1b17c129dd59@oracle.com> Message-ID: Hi Jim, A tip on webrevs, if you supply a file of filenames then you can tell it to > diff a file with a name change against its former name by using 2 filenames > on the same line, as in: > > -------- > filetodiff1.java > filetodiff2.java > filetodiff3.java filetodiff3oldname.java > filetodiff4.java > -------- > Thanks for the tip, I made another webrev (for archive) that shows the proper diffs in ArrayCache / ArrayCacheConst: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8159638.1_bis/ > In Renderer.java, you create the alphaLine and blkFlags refs as Clean, but > then you always put them back using indices of (0, 0) so they will never > actually be cleaned - is there a reason you don't just use a dirty ref > there? > Both alphaLine and blkFlags arrays must be zero-filled as these arrays are storing accumulated values: - get an initial zero-filled array from a Clean Reference (new array and Not Unsafe.allocateUninitializedArray) - compute values (accumulators) - copy data and reset dirty part of these arrays in copyAARowNoRLE() or copyAARowRLE_WithBlockFlags() at every pixel row ! (iterate on all pixel rows) - dispose: these arrays are already 'clean' i.e. zero-filled so I explicitely skip the cleanup by indicating an empty dirty range: alphaLine = alphaLine_ref.putArray(alphaLine, 0, 0); // already zero filled blkFlags = blkFlags_ref.putArray(blkFlags, 0, 0); // already zero filled It is not possible to use a dirty reference in this case as both allocated and returned array may contain garbage data (from the IntArrayCache). > Other than that question, I don't see any problems with the fix... > Ready to go ? or I need another reviewer, phil ? Cheers, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Tue Aug 2 16:07:03 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 2 Aug 2016 19:07:03 +0300 Subject: [OpenJDK 2D-Dev] Fwd: JDK bug 8078516 In-Reply-To: <579F64B8.1060602@oracle.com> References: <579F5F3D.6040203@oracle.com> <579F6188.6030207@oracle.com> <579F64B8.1060602@oracle.com> Message-ID: I suppose that this is why JDK-8078516 was filed, and it was closed as a duplicate, because another bug provided a way to use LCD rendering on OSX to opaque surface + workaround in swing, fixed the bug of the submitter. Probably we should file another bug as a replacement of 8078516. On 01.08.16 18:03, Philip Race wrote: > Transparency of the surface has always disabled LCD sub-pixel in Java 2D. > Same happens on windows. The labels at the bottom > are drawn in greyscale. > > -phil. > > On 8/1/16, 7:55 AM, Torgeir Veimo wrote: >> Ok, am asking since subpixel rendering works and is usable in most >> situations, except for the odd corner case when drawing over existing >> content in transparent surfaces. >> >> See eg. this screenshot of netbeans, with nice subpixel rendered text >> in the editor, while the labels on the buttons at the bottom have >> artifacts since they for some reason are drawn twice. >> >> Inline images 1 >> >> On 2 August 2016 at 00:49, Kevin Rushforth > > wrote: >> >> Phil will be able to comment on this further. All I can confirm is >> that 8078526 is closed as a duplicate of 8087201, so it is no >> longer an open bug. >> >> -- Kevin >> >> >> Torgeir Veimo wrote: >>> I'm fairly sure it's the correct bug id, although I don't have >>> access to view it myself. >>> >>> Bug 8078526 is about supporting (without artifacts) subpixel >>> rendering to transparent surfaces. >>> >>> Bug 8087201 is about speeding up subpixel rendering. >>> >>> On 2 August 2016 at 00:39, Kevin Rushforth >>> > >>> wrote: >>> >>> Are you sure you have the right Bug ID? That bug (which is >>> not publicly visible), is closed as a duplicate of 8087201, >>> which was fixed in JDK 9 and 8u66 over a year ago. >>> >>> -- Kevin >>> >>> >>> >>> Torgeir Veimo wrote: >>> >>> Is there any more work done on JDK bug 8078516? >>> -- >>> -Tor >>> >>> >>> >>> -- >>> -Tor >> >> >> >> >> -- >> -Tor -- Best regards, Sergey. From philip.race at oracle.com Tue Aug 2 16:27:47 2016 From: philip.race at oracle.com (Philip Race) Date: Tue, 02 Aug 2016 09:27:47 -0700 Subject: [OpenJDK 2D-Dev] Fwd: JDK bug 8078516 In-Reply-To: References: <579F5F3D.6040203@oracle.com> <579F6188.6030207@oracle.com> <579F64B8.1060602@oracle.com> Message-ID: <57A0CA03.3080208@oracle.com> Yes ... offline to Torgeir I questioned the closing as a dup. Need to look at these carefully to see if we should reopen or file a new issue but it would be an enhancement request, not a bug. -phil. On 8/2/16, 9:07 AM, Sergey Bylokhov wrote: > I suppose that this is why JDK-8078516 was filed, and it was closed as > a duplicate, because another bug provided a way to use LCD rendering > on OSX to opaque surface + workaround in swing, fixed the bug of the > submitter. Probably we should file another bug as a replacement of > 8078516. > > On 01.08.16 18:03, Philip Race wrote: >> Transparency of the surface has always disabled LCD sub-pixel in Java >> 2D. >> Same happens on windows. The labels at the bottom >> are drawn in greyscale. >> >> -phil. >> >> On 8/1/16, 7:55 AM, Torgeir Veimo wrote: >>> Ok, am asking since subpixel rendering works and is usable in most >>> situations, except for the odd corner case when drawing over existing >>> content in transparent surfaces. >>> >>> See eg. this screenshot of netbeans, with nice subpixel rendered text >>> in the editor, while the labels on the buttons at the bottom have >>> artifacts since they for some reason are drawn twice. >>> >>> Inline images 1 >>> >>> On 2 August 2016 at 00:49, Kevin Rushforth >> > wrote: >>> >>> Phil will be able to comment on this further. All I can confirm is >>> that 8078526 is closed as a duplicate of 8087201, so it is no >>> longer an open bug. >>> >>> -- Kevin >>> >>> >>> Torgeir Veimo wrote: >>>> I'm fairly sure it's the correct bug id, although I don't have >>>> access to view it myself. >>>> >>>> Bug 8078526 is about supporting (without artifacts) subpixel >>>> rendering to transparent surfaces. >>>> >>>> Bug 8087201 is about speeding up subpixel rendering. >>>> >>>> On 2 August 2016 at 00:39, Kevin Rushforth >>>> > >>>> wrote: >>>> >>>> Are you sure you have the right Bug ID? That bug (which is >>>> not publicly visible), is closed as a duplicate of 8087201, >>>> which was fixed in JDK 9 and 8u66 over a year ago. >>>> >>>> -- Kevin >>>> >>>> >>>> >>>> Torgeir Veimo wrote: >>>> >>>> Is there any more work done on JDK bug 8078516? >>>> -- >>>> -Tor >>>> >>>> >>>> >>>> -- >>>> -Tor >>> >>> >>> >>> >>> -- >>> -Tor > > From Sergey.Bylokhov at oracle.com Tue Aug 2 17:36:05 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 2 Aug 2016 20:36:05 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8160124 SunGraphics2D.hitClip() can give wrong result for floating point scale In-Reply-To: <3dca1571-a32d-3d35-5b44-51a42f1c80b5@oracle.com> References: <7de7d230-3f62-272e-437a-ea42bd739e88@oracle.com> <5e4a062a-a552-85c2-d6af-9c21b3616278@oracle.com> <57c555af-061f-8b6c-fe13-d9b294d9aa99@oracle.com> <5775AFF8.5060006@oracle.com> <54e2524f-2c0e-03f6-610d-ef55c27102b5@oracle.com> <9199112a-838d-377e-a86a-ce31b1a64aef@oracle.com> <3dca1571-a32d-3d35-5b44-51a42f1c80b5@oracle.com> Message-ID: <65417599-32e1-a377-d703-ede314833f35@oracle.com> On 27.07.16 1:56, Jim Graham wrote: > Rectangle2D rClip = (Rectangle2D) usrClip; > int x0 = (int) Math.ceil(rClip.getMinX() - 0.5); > int y0 = (int) Math.ceil(rClip.getMinY() - 0.5); > int x1 = (int) Math.ceil(rClip.getMaxX() - 0.5); > int x1 = (int) Math.ceil(rClip.getMaxY() - 0.5); > clipRegion = devClip.getIntersectionXYXY(x0, y0, x1, y1); > > Some work and testing should be done to see what happens when any of the > min/max/xy coordinates overflow an integer, but that would be the basic > gist of what we should be doing in that case in validateCompClip()... Should we really take care about negative minXY/maxXY here? I assume that negative coordinates will be skipped anyway when we interact them with devClip. So it seems we can simply cast double to int here? > ...jim > > On 07/26/2016 02:50 PM, Sergey Bylokhov wrote: >> On 13.07.16 5:42, Jim Graham wrote: >>> What does the compClip end up being in that case? >> >> BufferedImage bi = new >> BufferedImage(10,10,BufferedImage.TYPE_INT_ARGB); >> SunGraphics2D graphics = (SunGraphics2D) bi.createGraphics(); >> graphics.scale(1.5, 1.5); >> graphics.setClip(1, 1, 0, 0); >> System.out.println("clip = " + graphics.getClip().getBounds2D()); >> System.out.println("clip.isEmpty = " + >> graphics.getClip().getBounds2D().isEmpty()); >> boolean hit = graphics.hitClip(1, 1, 1, 1); >> System.out.println("hit = " + hit); >> System.out.println("compClip = " + graphics.getCompClip()); >> System.out.println("compClip.isEmpty = " + >> graphics.getCompClip().isEmpty()); >> >> The output: >> clip = java.awt.geom.Rectangle2D$Double[x=1.0,y=1.0,w=0.0,h=0.0] >> clip.isEmpty = true >> hit = true >> compClip = Region[[1, 1 => 2, 2]] >> compClip.isEmpty = false >> >> So the graphics.getClip() returns empty clip, but compClip is not empty. >> >> It seems this occurs when we intersect usrClip >> =[x=1.5,y=1.5,w=0.0,h=0.0] and devClip=Region[[0, 0 => 10, 10]] because >> result is clipRegion=Region[[1, 1 => 2, 2]] >> >> The code in question is: >> protected void validateCompClip() { >> ..... >> clipRegion = devClip.getIntersection(usrClip.getBounds()); >> ..... >> } >> The usrClip.getBounds() method will change [x=1.5,y=1.5,w=0.0,h=0.0] to >> [x=1,y=1,w=1,h=1], so the empty Rectangle2D became non-empty. >> >> >>> >>> ...jim >>> >>> On 7/4/16 1:12 AM, Sergey Bylokhov wrote: >>>> On 01.07.16 2:49, Jim Graham wrote: >>>>> How is it returning true? If the clip really is empty, then >>>>> intersectsQuickCheck() should never return true. Or are you saying >>>>> that >>>>> an empty clip shape produces a non-empty composite clip region? >>>> >>>> >>>> This code will test such situation: >>>> BufferedImage bi = new >>>> BufferedImage(10,10,BufferedImage.TYPE_INT_ARGB); >>>> Graphics2D graphics = bi.createGraphics(); >>>> graphics.scale(1.5, 1.5); >>>> graphics.setClip(1, 1, 0, 0); >>>> System.out.println("empty = " + >>>> graphics.getClip().getBounds2D().isEmpty()); >>>> boolean hit = graphics.hitClip(1, 1, 1, 1); >>>> System.out.println("hit = " + hit); >>>> >>>> if "graphics.scale(1.5, 1.5);" will be removed then correct false will >>>> be printed. In both cases the clip will be empty >>>> but hitCLip will return different result in case of scaled SG2D. >>>> >>>>> >>>>> ...jim >>>>> >>>>> On 06/30/2016 10:02 AM, Sergey Bylokhov wrote: >>>>>> It looks strange that the empty clip became "non-empty"(at least >>>>>> hitClip >>>>>> reports this) when we apply transform to it, no? I guess that at the >>>>>> beginning of hitClip() we should check that the clip.isEmpty(), >>>>>> and we >>>>>> should return "false" in this case(I think this is not strictly >>>>>> related >>>>>> to this bug)? >>>>>> >>>>>> On 24.06.16 1:14, Jim Graham wrote: >>>>>>> Think of this method as asking: >>>>>>> >>>>>>> I don't want you to waste a lot of time, but tell me if it is silly >>>>>>> for >>>>>>> me to even consider rendering something with these bounds. >>>>>>> >>>>>>> And the answer is either "Oh, yeah, it is inconceivable that those >>>>>>> bounds would be rendered", or "Not sure, maybe, just render it and >>>>>>> see". There may be some cases where it knows "I know for sure that >>>>>>> lots >>>>>>> of stuff will render through the clip", but that is not where the >>>>>>> divining line is here in terms of when the answer becomes true - it >>>>>>> becomes true when there is a chance that it might render something. >>>>>>> >>>>>>> Arguably, the user-space comparison against the user-space clip >>>>>>> that you >>>>>>> added here can never be accurate even if you allow for "false >>>>>>> positives". The clip is rasterized and whole pixels are chosen >>>>>>> based on >>>>>>> various criteria that affect clip rasterization. Thus, while the >>>>>>> theoretical clip is at N.5, our rasterization choice has us render >>>>>>> anything that hits pixel N, even if the contribution of the rendered >>>>>>> primitive is only for the first half of N. That pixel might be >>>>>>> rendered >>>>>>> if anything hits any part of it, depending on what rendering >>>>>>> operation >>>>>>> is being done. >>>>>>> >>>>>>> So, your "fix" actually breaks the functionality because it is quite >>>>>>> possible that something with a bounding box that stops before N.5 >>>>>>> might >>>>>>> affect pixel N and cause it to be rendered even though your new >>>>>>> answer >>>>>>> suggested that it wouldn't happen. Your code might actually cause a >>>>>>> bug, not fix one. >>>>>>> >>>>>>> (There are also some potential theoretical failures related to >>>>>>> how AA >>>>>>> and STROKE_CONTROL might perturb our rendering, effects which are >>>>>>> ignore >>>>>>> by the current implementation of hitClip(), however I believe that >>>>>>> all >>>>>>> of those effects fit within the current implementation - it's just >>>>>>> that >>>>>>> I don't think anyone has ever proven this, or written an exhaustive >>>>>>> test >>>>>>> suite to verify that none of our rendering hints can perturb >>>>>>> rendering >>>>>>> by enough to create some surprises here...) >>>>>>> >>>>>>> ...jim >>>>>>> >>>>>>> On 6/23/16 3:00 PM, Jim Graham wrote: >>>>>>>> Since "return true" would be a compliant implementation of >>>>>>>> Graphics.hitClip(), this is not a bug... >>>>>>>> >>>>>>>> Read the documentation, it is allowed to use fast math that can >>>>>>>> return >>>>>>>> true when technically the answer is false... >>>>>>>> >>>>>>>> ...jim >>>>>>>> >>>>>>>> On 6/23/16 5:04 AM, Alexandr Scherbatiy wrote: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Could you review the fix: >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160124 >>>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8160124/webrev.00 >>>>>>>>> >>>>>>>>> Let's set the clip [x=5, y=5, width=5, height=5] to a graphics >>>>>>>>> and >>>>>>>>> call the hitClip() with the passed rectangle [x=0, >>>>>>>>> y=0, width=5, height=5]. >>>>>>>>> >>>>>>>>> The result is false for the graphics with scale 1 and true if >>>>>>>>> the >>>>>>>>> scale is floating point 1.5. >>>>>>>>> >>>>>>>>> This is because the transformed clip which has floating point >>>>>>>>> bounds [7.5, 7.5, 7.5, 7.5] for the scale 1.5 has bounds >>>>>>>>> with rounded down upper-left and rounded up lower-right corners >>>>>>>>> [7, >>>>>>>>> 7, 8, 8] which now intersects with the transformed >>>>>>>>> rectangle [0, 0, 7.5, 7.5]. >>>>>>>>> >>>>>>>>> The proposed fix adds additional check for the user clip and the >>>>>>>>> user rectangle intersection if the intersection with >>>>>>>>> the region clip passes. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> >>>>>> >>>>>> >>>> >>>> >> >> -- Best regards, Sergey. From philip.race at oracle.com Tue Aug 2 17:38:55 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 02 Aug 2016 10:38:55 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8074843: Resolve disabled warnings for libmlib_image and libmlib_image_v In-Reply-To: <57A03428.3060501@oracle.com> References: <579A95D6.3090604@oracle.com> <8ef6de35-011d-5218-3bdd-f3547e65ee29@oracle.com> <579B5A03.7000801@oracle.com> <4e04aa2a-da69-7983-2644-c1e7a5d23af3@oracle.com> <579B6885.6070706@oracle.com> <776d0e58-dff7-3b88-a1ca-480c806e42a4@oracle.com> <579C23B0.2030301@oracle.com> <579F8348.60009@oracle.com> <57A03428.3060501@oracle.com> Message-ID: <57A0DAAF.3050803@oracle.com> On 08/01/2016 10:48 PM, Prasanta Sadhukhan wrote: > +1. Only one thing, > > mlib_c_ImageCopy.c#185 do we really need that extra parentheses, > ((j = (w & 1))). I guess this should just do > if (j = (w & 1)), isn't it? I originally tried exactly that but the compiler still complained and did insist on what you see. Just to prove it I just now (temporarily) changed the code to what you suggest and the result is this :- libmlib_image/mlib_c_ImageCopy.c: In function 'mlib_c_ImageCopy_u8': mlib_c_ImageCopy.c:331:5: error: suggest parentheses around assignment used as truth value [-Werror=parentheses] STRIP(pdst, psrc, src_width, src_height, mlib_u8); ^ -phil. > > > Regards > Prasanta > On 8/1/2016 10:43 PM, Phil Race wrote: >> Looking for another "+1" ... >> >> -phil. >> >> On 07/29/2016 10:13 PM, Vadim Pakhnushev wrote: >>> Looks good! >>> >>> Vadim >>> >>> On 30.07.2016 6:49, Philip Race wrote: >>>> See http://cr.openjdk.java.net/~prr/8074843.1/ >>>> >>>> Also passes JPRT >>>> >>>> -phil. >>>> >>>> On 7/29/16, 7:35 AM, Vadim Pakhnushev wrote: >>>>> On 29.07.2016 17:30, Philip Race wrote: >>>>>> >>>>>> >>>>>> On 7/29/16, 7:00 AM, Vadim Pakhnushev wrote: >>>>>>> On 29.07.2016 16:28, Philip Race wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 7/29/16, 3:23 AM, Vadim Pakhnushev wrote: >>>>>>>>> Phil, >>>>>>>>> >>>>>>>>> I guess you wanted to remove the lines in the Awt2dLibraries.gmk? >>>>>>>> >>>>>>>> Ah, yes. Not just disable them >>>>>>>>> >>>>>>>>> Do you think it's worth it to rewrite these assignments as >>>>>>>>> separate assignment and a condition? >>>>>>>>> Especially long ones with a lot of parentheses? >>>>>>>>> Like this one, instead of >>>>>>>>> if ((j = ((mlib_s32) ((mlib_addr) psrc_row & 4) >> 2))) { >>>>>>>>> >>>>>>>>> j = (mlib_s32) ((mlib_addr) psrc_row & 4) >> 2; >>>>>>>>> if (j != 0) { >>>>>>>> >>>>>>>> I don't know. Where would I stop ? >>>>>>> >>>>>>> Where it doesn't feel weird anymore? >>>>>>> For example, is this line correct? >>>>>>> if (j = (((mlib_addr) pdst_row & 2) != 0)) { >>>>>>> It seems very weird for me that we assign a boolean value to the >>>>>>> loop variable. >>>>>>> It looks like there's an error in parentheses and it should >>>>>>> instead look like: >>>>>>> if ((j = (((mlib_addr) pdst_row & 2) != 0) { >>>>>>> Yeah, in this particular case it doesn't even matter but still >>>>>>> assignments in conditions can very easily lead to errors. >>>>>> >>>>>> OK I will take a *limited* look at this. >>>>> >>>>> Yeah it's just 2 identical lines in the mlib_c_ImageCopy.c >>>>> >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Also seeing macro calls without a semicolon is weird. >>>>>>>>> I don't see any need in parentheses in the definition of >>>>>>>>> FREE_AND_RETURN_STATUS so maybe it's possible to rewrite it >>>>>>>>> without trailing semicolon? >>>>>>>> >>>>>>>> I anticipated the question and it is already addressed in my last >>>>>>>> paragraph right at the very bottom of the review request. >>>>>>> >>>>>>> Oops, missed that. >>>>>>> >>>>>>>> Basically that pattern has an "if (x==NULL) return". If you don't >>>>>>>> have that "if" then the compiler would have objected to that too ! >>>>>>> >>>>>>> I'm not sure I undestand this. >>>>>> >>>>>> I mean I without the condition the compiler can tell you *never* >>>>>> reach >>>>>> the while (0) and so objected on those grounds. I tried this. >>>>> >>>>> Got it. >>>>> >>>>>>> >>>>>>> I mean why not rewrite the macro like this: >>>>>>> #define FREE_AND_RETURN_STATUS \ >>>>>>> if (pbuff != buff) mlib_free(pbuff); \ >>>>>>> if (k != akernel) mlib_free(k); \ >>>>>>> return status >>>>>>> #endif /* FREE_AND_RETURN_STATUS */ >>>>>>> >>>>>>> Yes it's prone to errors like if (foo) FREE_AND_RETURN_STATUS; >>>>>>> but all its usages are separate statements. >>>>>> >>>>>> hmm .. I suppose could .. but not pretty either. >>>>>> Also if going that route it could be >>>>>> >>>>>> #define FREE_AND_RETURN_STATUS \ >>>>>> { \ >>>>>> if (pbuff != buff) mlib_free(pbuff); \ >>>>>> if (k != akernel) mlib_free(k); \ >>>>>> } \ >>>>>> return status >>>>>> #endif /* FREE_AND_RETURN_STATUS */ >>>>>> >>>>>> ?? >>>>> >>>>> What's the point of parentheses here? >>>>> I thought that the whole point of curly braces and do .... >>>>> while(0) stuff was to enable the macro calls in conditions like if >>>>> (foo) CALL_MACRO; without the curly braces around CALL_MACRO. >>>>> But if you put curly braces around only part of the macro >>>>> definition this would be broken anyway. >>>>> >>>>> Vadim >>>>> >>>>>> >>>>>> -phil. >>>>>>> >>>>>>> Vadim >>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vadim >>>>>>>>> >>>>>>>>> On 29.07.2016 2:31, Philip Race wrote: >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074843 >>>>>>>>>> Fix: http://cr.openjdk.java.net/~prr/8074843/ >>>>>>>>>> >>>>>>>>>> Here's a sampling of the warnings that I think covers most, >>>>>>>>>> maybe all, of the cases >>>>>>>>>> LINUX >>>>>>>>>> mlib_ImageAffine_NN_Bit.c:87:81: error: suggest parentheses >>>>>>>>>> around '-' in operand of '&' [-Werror=parentheses] >>>>>>>>>> res = (res & ~(1 << bit)) | (((srcPixelPtr[X >> >>>>>>>>>> (MLIB_SHIFT + 3)] >> (7 - (X >> MLIB_SHIFT) & 7)) & 1) << >>>>>>>>>> ^ >>>>>>>>>> mlib_ImageAffine_NN_Bit.c:153:81: error: suggest parentheses >>>>>>>>>> around '-' in operand of '&' [-Werror=parentheses] >>>>>>>>>> res = (res & ~(1 << bit)) | (((srcPixelPtr[X >> >>>>>>>>>> (MLIB_SHIFT + 3)] >> (7 - (X >> MLIB_SHIFT) & 7)) & 1) << bit); >>>>>>>>>> >>>>>>>>>> ----------------- >>>>>>>>>> mlib_c_ImageCopy.c: In function 'mlib_c_ImageCopy_s16': >>>>>>>>>> mlib_c_ImageCopy.c:439:5: error: suggest parentheses around >>>>>>>>>> assignment used as truth value [-Werror=parentheses] >>>>>>>>>> STRIP(pdst, psrc, src_width, src_height, mlib_u16); >>>>>>>>>> ^ >>>>>>>>>> - >>>>>>>>>> MAC ... >>>>>>>>>> >>>>>>>>>> mlib_c_ImageCopy.c:331:5: error: using the result of an >>>>>>>>>> assignment as a condition without parentheses >>>>>>>>>> [-Werror,-Wparentheses] >>>>>>>>>> STRIP(pdst, psrc, src_width, src_height, mlib_u8); >>>>>>>>>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>>>>>>> mlib_c_ImageCopy.c:185:11: note: expanded from macro 'STRIP' >>>>>>>>>> if (j = w & 1) \ >>>>>>>>>> ~~^~~~~~~ >>>>>>>>>> mlib_c_ImageCopy.c:331:5: note: place parentheses around the >>>>>>>>>> assignment to silence this warning\ >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> SOLARIS >>>>>>>>>> mlib_ImageConv_16ext.c", line 532: statement not reached >>>>>>>>>> (E_STATEMENT_NOT_REACHED) >>>>>>>>>> >>>>>>>>>> This last one was not nice just the ";" was considered a >>>>>>>>>> statement >>>>>>>>>> after the {XX; YY; return Z} macro expansion >>>>>>>>>> and turning into "do { {....} } while (0)" did not help since >>>>>>>>>> then it said "loop terminator not reached - other cases we have >>>>>>>>>> like this have at least a condition in the macro. >>>>>>>>>> >>>>>>>>>> -phil. >>>>>>>>> >>>>>>> >>>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Tue Aug 2 20:44:08 2016 From: philip.race at oracle.com (Philip Race) Date: Tue, 02 Aug 2016 13:44:08 -0700 Subject: [OpenJDK 2D-Dev] [9] Fix for JDK-6427331 : NullPointerException in LookupOp.filter(Raster, WritableRaster) In-Reply-To: <6a19c251-121c-4bcd-917b-e86af7e41134@default> References: <6a19c251-121c-4bcd-917b-e86af7e41134@default> Message-ID: <57A10618.3000209@oracle.com> +1. -phil. On 8/2/16, 2:01 AM, Ajit Ghaisas wrote: > > Hi, > > Bug : https://bugs.openjdk.java.net/browse/JDK-6427331 > > Issue : If destination raster is provided as null to > java.awt.image.LookupOp.filter(Raster src, WritableRaster dest), > > according to Javadoc, a new raster should be created. > Instead, it results in NullPointerException. > > Fix : http://cr.openjdk.java.net/~aghaisas/6427331/webrev.00/ > > > Request you to review. > > Regards, > > Ajit > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Tue Aug 2 21:04:36 2016 From: philip.race at oracle.com (Philip Race) Date: Tue, 02 Aug 2016 14:04:36 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-5080098: Page Range must be disabled on the common print dlg for Non serv-formatted flvrs In-Reply-To: <579AE97B.6090403@oracle.com> References: <577B791F.4020900@oracle.com> <5798E06A.5030909@oracle.com> <5799DDF7.30900@oracle.com> <579A0B4A.1060400@oracle.com> <579AE97B.6090403@oracle.com> Message-ID: <57A10AE4.4050002@oracle.com> +1 -phil On 7/28/16, 10:28 PM, Prasanta Sadhukhan wrote: > Yes, right. Please find the modified webrev: > http://cr.openjdk.java.net/~psadhukhan/5080098/webrev.02/ > > Regards > Prasanta > On 7/28/2016 7:10 PM, Philip Race wrote: >> This can now be written more succinctly (and clearly) as : >> prPgRngSupported = psCurrent.isAttributeValueSupported(prAll, docFlavor,asCurrent); >> >> -phil. >> >> On 7/28/16, 3:27 AM, Prasanta Sadhukhan wrote: >>> Trying to be extra cautious. Please find modified webrev: >>> http://cr.openjdk.java.net/~psadhukhan/5080098/webrev.01/ >>> >>> Regards >>> Prasanta >>> On 7/27/2016 9:55 PM, Phil Race wrote: >>>> prAll is final and initalised. So why are you testing !=null ? >>>> >>>> -phil. >>>> >>>> On 07/05/2016 02:08 AM, Prasanta Sadhukhan wrote: >>>>> Hi All, >>>>> >>>>> Please review a fix for an issue where it is seen "Page range >>>>> (From/To) " field is not disabled for flavors such as postscript, >>>>> image flavors. >>>>> PageRanges attribute is supported only for Service Formatted >>>>> flavors such as Pageable and Printable and so for >>>>> other flavors such as postscript, image flavors page ranges fields >>>>> must be disabled on the print dialog so as not to allow the user >>>>> to select the same >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-5080098 >>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/5080098/webrev.00/ >>>>> >>>>> Proposed fix is to check for attribute against the specified doc >>>>> flavor >>>>> and not against attribute category to decide whether to enable / >>>>> disable it. >>>>> >>>>> Regards >>>>> Prasanta >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Tue Aug 2 21:56:50 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 2 Aug 2016 14:56:50 -0700 Subject: [OpenJDK 2D-Dev] RFR 8159638: Improve array caches and renderer stats in Marlin renderer In-Reply-To: References: <8d819ad0-342b-15cb-8afc-bdda5da52a5d@oracle.com> <5480c2b9-a8fd-bc42-6e75-1b17c129dd59@oracle.com> Message-ID: Thanks Laurent, On 08/02/2016 05:57 AM, Laurent Bourg?s wrote: > Thanks for the tip, I made another webrev (for archive) that shows the > proper diffs in ArrayCache / ArrayCacheConst: > http://cr.openjdk.java.net/~lbourges/marlin/marlin-8159638.1_bis/ > Thanks! > In Renderer.java, you create the alphaLine and blkFlags refs as > Clean, but then you always put them back using indices of (0, 0) so > they will never actually be cleaned - is there a reason you don't > just use a dirty ref there? > > Both alphaLine and blkFlags arrays must be zero-filled as these arrays > are storing accumulated values: > > It is not possible to use a dirty reference in this case as both > allocated and returned array may contain garbage data (from the > IntArrayCache). D'oh! I guess that was obvious. I wasn't thinking of the fact that dirty caches can initially return a non-zero-filled array - the fact that they clean on "put" is only half of their zero guarantee... > Other than that question, I don't see any problems with the fix... > > Ready to go ? > or I need another reviewer, phil ? Ready from my end. Phil? ...jim From james.graham at oracle.com Tue Aug 2 22:02:27 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 2 Aug 2016 15:02:27 -0700 Subject: [OpenJDK 2D-Dev] [9] Review request for 8160124 SunGraphics2D.hitClip() can give wrong result for floating point scale In-Reply-To: <65417599-32e1-a377-d703-ede314833f35@oracle.com> References: <7de7d230-3f62-272e-437a-ea42bd739e88@oracle.com> <5e4a062a-a552-85c2-d6af-9c21b3616278@oracle.com> <57c555af-061f-8b6c-fe13-d9b294d9aa99@oracle.com> <5775AFF8.5060006@oracle.com> <54e2524f-2c0e-03f6-610d-ef55c27102b5@oracle.com> <9199112a-838d-377e-a86a-ce31b1a64aef@oracle.com> <3dca1571-a32d-3d35-5b44-51a42f1c80b5@oracle.com> <65417599-32e1-a377-d703-ede314833f35@oracle.com> Message-ID: <3d021f11-600d-2c38-a21d-0ff213d7ff14@oracle.com> On 08/02/2016 10:36 AM, Sergey Bylokhov wrote: > On 27.07.16 1:56, Jim Graham wrote: >> Rectangle2D rClip = (Rectangle2D) usrClip; >> int x0 = (int) Math.ceil(rClip.getMinX() - 0.5); >> int y0 = (int) Math.ceil(rClip.getMinY() - 0.5); >> int x1 = (int) Math.ceil(rClip.getMaxX() - 0.5); >> int x1 = (int) Math.ceil(rClip.getMaxY() - 0.5); >> clipRegion = devClip.getIntersectionXYXY(x0, y0, x1, y1); >> >> Some work and testing should be done to see what happens when any of the >> min/max/xy coordinates overflow an integer, but that would be the basic >> gist of what we should be doing in that case in validateCompClip()... > > Should we really take care about negative minXY/maxXY here? I assume > that negative coordinates will be skipped anyway when we interact them > with devClip. So it seems we can simply cast double to int here? That might be possible if we were using floor(), but we are using ceil() so casting is not a suitable substitute. I'd still rather see explicit floor being used in cases like this that aren't in some sort of per-pixel loop, but in either case, when we need a ceil() operation, we can't rely on casting anyway... ...jim From james.graham at oracle.com Tue Aug 2 22:04:48 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 2 Aug 2016 15:04:48 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8074843: Resolve disabled warnings for libmlib_image and libmlib_image_v In-Reply-To: <57A0DAAF.3050803@oracle.com> References: <579A95D6.3090604@oracle.com> <8ef6de35-011d-5218-3bdd-f3547e65ee29@oracle.com> <579B5A03.7000801@oracle.com> <4e04aa2a-da69-7983-2644-c1e7a5d23af3@oracle.com> <579B6885.6070706@oracle.com> <776d0e58-dff7-3b88-a1ca-480c806e42a4@oracle.com> <579C23B0.2030301@oracle.com> <579F8348.60009@oracle.com> <57A03428.3060501@oracle.com> <57A0DAAF.3050803@oracle.com> Message-ID: In that case, then I'd write it as "if ((j = (w & 1)) != 0)" to make it clear that the LHS is an assignment. A casual reading of the code might see this as a comparison with an extra set of parentheses until someone counts the equal signs... ...jim On 08/02/2016 10:38 AM, Phil Race wrote: > On 08/01/2016 10:48 PM, Prasanta Sadhukhan wrote: >> +1. Only one thing, >> >> mlib_c_ImageCopy.c#185 do we really need that extra parentheses, >> ((j = (w & 1))). I guess this should just do if (j = (w & 1)), isn't it? > > I originally tried exactly that but the compiler still complained and > did insist on what you see. > > Just to prove it I just now (temporarily) changed the code to what you > suggest and the result is this :- > > libmlib_image/mlib_c_ImageCopy.c: In function 'mlib_c_ImageCopy_u8': > mlib_c_ImageCopy.c:331:5: error: suggest parentheses around assignment used as truth value [-Werror=parentheses] > STRIP(pdst, psrc, src_width, src_height, mlib_u8); > ^ > > > -phil. > >> Regards >> Prasanta >> On 8/1/2016 10:43 PM, Phil Race wrote: >>> Looking for another "+1" ... >>> >>> -phil. >>> >>> On 07/29/2016 10:13 PM, Vadim Pakhnushev wrote: >>>> Looks good! >>>> >>>> Vadim >>>> >>>> On 30.07.2016 6:49, Philip Race wrote: >>>>> See http://cr.openjdk.java.net/~prr/8074843.1/ >>>>> >>>>> Also passes JPRT >>>>> >>>>> -phil. >>>>> >>>>> On 7/29/16, 7:35 AM, Vadim Pakhnushev wrote: >>>>>> On 29.07.2016 17:30, Philip Race wrote: >>>>>>> >>>>>>> >>>>>>> On 7/29/16, 7:00 AM, Vadim Pakhnushev wrote: >>>>>>>> On 29.07.2016 16:28, Philip Race wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 7/29/16, 3:23 AM, Vadim Pakhnushev wrote: >>>>>>>>>> Phil, >>>>>>>>>> >>>>>>>>>> I guess you wanted to remove the lines in the Awt2dLibraries.gmk? >>>>>>>>> >>>>>>>>> Ah, yes. Not just disable them >>>>>>>>>> >>>>>>>>>> Do you think it's worth it to rewrite these assignments as >>>>>>>>>> separate assignment and a condition? >>>>>>>>>> Especially long ones with a lot of parentheses? >>>>>>>>>> Like this one, instead of >>>>>>>>>> if ((j = ((mlib_s32) ((mlib_addr) psrc_row & 4) >> 2))) { >>>>>>>>>> >>>>>>>>>> j = (mlib_s32) ((mlib_addr) psrc_row & 4) >> 2; >>>>>>>>>> if (j != 0) { >>>>>>>>> >>>>>>>>> I don't know. Where would I stop ? >>>>>>>> >>>>>>>> Where it doesn't feel weird anymore? >>>>>>>> For example, is this line correct? >>>>>>>> if (j = (((mlib_addr) pdst_row & 2) != 0)) { >>>>>>>> It seems very weird for me that we assign a boolean value to the >>>>>>>> loop variable. >>>>>>>> It looks like there's an error in parentheses and it should >>>>>>>> instead look like: >>>>>>>> if ((j = (((mlib_addr) pdst_row & 2) != 0) { >>>>>>>> Yeah, in this particular case it doesn't even matter but still >>>>>>>> assignments in conditions can very easily lead to errors. >>>>>>> >>>>>>> OK I will take a *limited* look at this. >>>>>> >>>>>> Yeah it's just 2 identical lines in the mlib_c_ImageCopy.c >>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Also seeing macro calls without a semicolon is weird. >>>>>>>>>> I don't see any need in parentheses in the definition of >>>>>>>>>> FREE_AND_RETURN_STATUS so maybe it's possible to rewrite it >>>>>>>>>> without trailing semicolon? >>>>>>>>> >>>>>>>>> I anticipated the question and it is already addressed in my last >>>>>>>>> paragraph right at the very bottom of the review request. >>>>>>>> >>>>>>>> Oops, missed that. >>>>>>>> >>>>>>>>> Basically that pattern has an "if (x==NULL) return". If you don't >>>>>>>>> have that "if" then the compiler would have objected to that too ! >>>>>>>> >>>>>>>> I'm not sure I undestand this. >>>>>>> >>>>>>> I mean I without the condition the compiler can tell you *never* >>>>>>> reach >>>>>>> the while (0) and so objected on those grounds. I tried this. >>>>>> >>>>>> Got it. >>>>>> >>>>>>>> >>>>>>>> I mean why not rewrite the macro like this: >>>>>>>> #define FREE_AND_RETURN_STATUS \ >>>>>>>> if (pbuff != buff) mlib_free(pbuff); \ >>>>>>>> if (k != akernel) mlib_free(k); \ >>>>>>>> return status >>>>>>>> #endif /* FREE_AND_RETURN_STATUS */ >>>>>>>> >>>>>>>> Yes it's prone to errors like if (foo) FREE_AND_RETURN_STATUS; >>>>>>>> but all its usages are separate statements. >>>>>>> >>>>>>> hmm .. I suppose could .. but not pretty either. >>>>>>> Also if going that route it could be >>>>>>> >>>>>>> #define FREE_AND_RETURN_STATUS \ >>>>>>> { \ >>>>>>> if (pbuff != buff) mlib_free(pbuff); \ >>>>>>> if (k != akernel) mlib_free(k); \ >>>>>>> } \ >>>>>>> return status >>>>>>> #endif /* FREE_AND_RETURN_STATUS */ >>>>>>> >>>>>>> ?? >>>>>> >>>>>> What's the point of parentheses here? >>>>>> I thought that the whole point of curly braces and do .... >>>>>> while(0) stuff was to enable the macro calls in conditions like if >>>>>> (foo) CALL_MACRO; without the curly braces around CALL_MACRO. >>>>>> But if you put curly braces around only part of the macro >>>>>> definition this would be broken anyway. >>>>>> >>>>>> Vadim >>>>>> >>>>>>> >>>>>>> -phil. >>>>>>>> >>>>>>>> Vadim >>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vadim >>>>>>>>>> >>>>>>>>>> On 29.07.2016 2:31, Philip Race wrote: >>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074843 >>>>>>>>>>> Fix: http://cr.openjdk.java.net/~prr/8074843/ >>>>>>>>>>> >>>>>>>>>>> Here's a sampling of the warnings that I think covers most, >>>>>>>>>>> maybe all, of the cases >>>>>>>>>>> LINUX >>>>>>>>>>> mlib_ImageAffine_NN_Bit.c:87:81: error: suggest parentheses >>>>>>>>>>> around '-' in operand of '&' [-Werror=parentheses] >>>>>>>>>>> res = (res & ~(1 << bit)) | (((srcPixelPtr[X >> >>>>>>>>>>> (MLIB_SHIFT + 3)] >> (7 - (X >> MLIB_SHIFT) & 7)) & 1) << >>>>>>>>>>> >>>>>>>>>>> ^ >>>>>>>>>>> mlib_ImageAffine_NN_Bit.c:153:81: error: suggest parentheses >>>>>>>>>>> around '-' in operand of '&' [-Werror=parentheses] >>>>>>>>>>> res = (res & ~(1 << bit)) | (((srcPixelPtr[X >> >>>>>>>>>>> (MLIB_SHIFT + 3)] >> (7 - (X >> MLIB_SHIFT) & 7)) & 1) << bit); >>>>>>>>>>> >>>>>>>>>>> ----------------- >>>>>>>>>>> mlib_c_ImageCopy.c: In function 'mlib_c_ImageCopy_s16': >>>>>>>>>>> mlib_c_ImageCopy.c:439:5: error: suggest parentheses around >>>>>>>>>>> assignment used as truth value [-Werror=parentheses] >>>>>>>>>>> STRIP(pdst, psrc, src_width, src_height, mlib_u16); >>>>>>>>>>> ^ >>>>>>>>>>> - >>>>>>>>>>> MAC ... >>>>>>>>>>> >>>>>>>>>>> mlib_c_ImageCopy.c:331:5: error: using the result of an >>>>>>>>>>> assignment as a condition without parentheses >>>>>>>>>>> [-Werror,-Wparentheses] >>>>>>>>>>> STRIP(pdst, psrc, src_width, src_height, mlib_u8); >>>>>>>>>>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>>>>>>>> mlib_c_ImageCopy.c:185:11: note: expanded from macro 'STRIP' >>>>>>>>>>> if (j = w & 1) \ >>>>>>>>>>> ~~^~~~~~~ >>>>>>>>>>> mlib_c_ImageCopy.c:331:5: note: place parentheses around the >>>>>>>>>>> assignment to silence this warning\ >>>>>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> SOLARIS >>>>>>>>>>> mlib_ImageConv_16ext.c", line 532: statement not reached >>>>>>>>>>> (E_STATEMENT_NOT_REACHED) >>>>>>>>>>> >>>>>>>>>>> This last one was not nice just the ";" was considered a >>>>>>>>>>> statement >>>>>>>>>>> after the {XX; YY; return Z} macro expansion >>>>>>>>>>> and turning into "do { {....} } while (0)" did not help since >>>>>>>>>>> then it said "loop terminator not reached - other cases we have >>>>>>>>>>> like this have at least a condition in the macro. >>>>>>>>>>> >>>>>>>>>>> -phil. >>>>>>>>>> >>>>>>>> >>>>>> >>>> >>> >> > From vadim.pakhnushev at oracle.com Tue Aug 2 22:06:45 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Wed, 3 Aug 2016 01:06:45 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8074843: Resolve disabled warnings for libmlib_image and libmlib_image_v In-Reply-To: References: <579A95D6.3090604@oracle.com> <8ef6de35-011d-5218-3bdd-f3547e65ee29@oracle.com> <579B5A03.7000801@oracle.com> <4e04aa2a-da69-7983-2644-c1e7a5d23af3@oracle.com> <579B6885.6070706@oracle.com> <776d0e58-dff7-3b88-a1ca-480c806e42a4@oracle.com> <579C23B0.2030301@oracle.com> <579F8348.60009@oracle.com> <57A03428.3060501@oracle.com> <57A0DAAF.3050803@oracle.com> Message-ID: <0d99258d-f580-e905-0be8-bc3ecf1398c8@oracle.com> Or as j = w & 1; if (j != 0) { as in other longer cases. Too much parentheses to my taste. Vadim On 03.08.2016 1:04, Jim Graham wrote: > In that case, then I'd write it as "if ((j = (w & 1)) != 0)" to make > it clear that the LHS is an assignment. A casual reading of the code > might see this as a comparison with an extra set of parentheses until > someone counts the equal signs... > > ...jim > > On 08/02/2016 10:38 AM, Phil Race wrote: >> On 08/01/2016 10:48 PM, Prasanta Sadhukhan wrote: >>> +1. Only one thing, >>> >>> mlib_c_ImageCopy.c#185 do we really need that extra parentheses, >>> ((j = (w & 1))). I guess this should just do if (j = (w & 1)), isn't >>> it? >> >> I originally tried exactly that but the compiler still complained and >> did insist on what you see. >> >> Just to prove it I just now (temporarily) changed the code to what you >> suggest and the result is this :- >> >> libmlib_image/mlib_c_ImageCopy.c: In function 'mlib_c_ImageCopy_u8': >> mlib_c_ImageCopy.c:331:5: error: suggest parentheses around >> assignment used as truth value [-Werror=parentheses] >> STRIP(pdst, psrc, src_width, src_height, mlib_u8); >> ^ >> >> >> -phil. >> >>> Regards >>> Prasanta >>> On 8/1/2016 10:43 PM, Phil Race wrote: >>>> Looking for another "+1" ... >>>> >>>> -phil. >>>> >>>> On 07/29/2016 10:13 PM, Vadim Pakhnushev wrote: >>>>> Looks good! >>>>> >>>>> Vadim >>>>> >>>>> On 30.07.2016 6:49, Philip Race wrote: >>>>>> See http://cr.openjdk.java.net/~prr/8074843.1/ >>>>>> >>>>>> Also passes JPRT >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 7/29/16, 7:35 AM, Vadim Pakhnushev wrote: >>>>>>> On 29.07.2016 17:30, Philip Race wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 7/29/16, 7:00 AM, Vadim Pakhnushev wrote: >>>>>>>>> On 29.07.2016 16:28, Philip Race wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 7/29/16, 3:23 AM, Vadim Pakhnushev wrote: >>>>>>>>>>> Phil, >>>>>>>>>>> >>>>>>>>>>> I guess you wanted to remove the lines in the >>>>>>>>>>> Awt2dLibraries.gmk? >>>>>>>>>> >>>>>>>>>> Ah, yes. Not just disable them >>>>>>>>>>> >>>>>>>>>>> Do you think it's worth it to rewrite these assignments as >>>>>>>>>>> separate assignment and a condition? >>>>>>>>>>> Especially long ones with a lot of parentheses? >>>>>>>>>>> Like this one, instead of >>>>>>>>>>> if ((j = ((mlib_s32) ((mlib_addr) psrc_row & 4) >> 2))) { >>>>>>>>>>> >>>>>>>>>>> j = (mlib_s32) ((mlib_addr) psrc_row & 4) >> 2; >>>>>>>>>>> if (j != 0) { >>>>>>>>>> >>>>>>>>>> I don't know. Where would I stop ? >>>>>>>>> >>>>>>>>> Where it doesn't feel weird anymore? >>>>>>>>> For example, is this line correct? >>>>>>>>> if (j = (((mlib_addr) pdst_row & 2) != 0)) { >>>>>>>>> It seems very weird for me that we assign a boolean value to the >>>>>>>>> loop variable. >>>>>>>>> It looks like there's an error in parentheses and it should >>>>>>>>> instead look like: >>>>>>>>> if ((j = (((mlib_addr) pdst_row & 2) != 0) { >>>>>>>>> Yeah, in this particular case it doesn't even matter but still >>>>>>>>> assignments in conditions can very easily lead to errors. >>>>>>>> >>>>>>>> OK I will take a *limited* look at this. >>>>>>> >>>>>>> Yeah it's just 2 identical lines in the mlib_c_ImageCopy.c >>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Also seeing macro calls without a semicolon is weird. >>>>>>>>>>> I don't see any need in parentheses in the definition of >>>>>>>>>>> FREE_AND_RETURN_STATUS so maybe it's possible to rewrite it >>>>>>>>>>> without trailing semicolon? >>>>>>>>>> >>>>>>>>>> I anticipated the question and it is already addressed in my >>>>>>>>>> last >>>>>>>>>> paragraph right at the very bottom of the review request. >>>>>>>>> >>>>>>>>> Oops, missed that. >>>>>>>>> >>>>>>>>>> Basically that pattern has an "if (x==NULL) return". If you >>>>>>>>>> don't >>>>>>>>>> have that "if" then the compiler would have objected to that >>>>>>>>>> too ! >>>>>>>>> >>>>>>>>> I'm not sure I undestand this. >>>>>>>> >>>>>>>> I mean I without the condition the compiler can tell you *never* >>>>>>>> reach >>>>>>>> the while (0) and so objected on those grounds. I tried this. >>>>>>> >>>>>>> Got it. >>>>>>> >>>>>>>>> >>>>>>>>> I mean why not rewrite the macro like this: >>>>>>>>> #define FREE_AND_RETURN_STATUS \ >>>>>>>>> if (pbuff != buff) mlib_free(pbuff); \ >>>>>>>>> if (k != akernel) mlib_free(k); \ >>>>>>>>> return status >>>>>>>>> #endif /* FREE_AND_RETURN_STATUS */ >>>>>>>>> >>>>>>>>> Yes it's prone to errors like if (foo) FREE_AND_RETURN_STATUS; >>>>>>>>> but all its usages are separate statements. >>>>>>>> >>>>>>>> hmm .. I suppose could .. but not pretty either. >>>>>>>> Also if going that route it could be >>>>>>>> >>>>>>>> #define FREE_AND_RETURN_STATUS \ >>>>>>>> { \ >>>>>>>> if (pbuff != buff) mlib_free(pbuff); \ >>>>>>>> if (k != akernel) mlib_free(k); \ >>>>>>>> } \ >>>>>>>> return status >>>>>>>> #endif /* FREE_AND_RETURN_STATUS */ >>>>>>>> >>>>>>>> ?? >>>>>>> >>>>>>> What's the point of parentheses here? >>>>>>> I thought that the whole point of curly braces and do .... >>>>>>> while(0) stuff was to enable the macro calls in conditions like if >>>>>>> (foo) CALL_MACRO; without the curly braces around CALL_MACRO. >>>>>>> But if you put curly braces around only part of the macro >>>>>>> definition this would be broken anyway. >>>>>>> >>>>>>> Vadim >>>>>>> >>>>>>>> >>>>>>>> -phil. >>>>>>>>> >>>>>>>>> Vadim >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Vadim >>>>>>>>>>> >>>>>>>>>>> On 29.07.2016 2:31, Philip Race wrote: >>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074843 >>>>>>>>>>>> Fix: http://cr.openjdk.java.net/~prr/8074843/ >>>>>>>>>>>> >>>>>>>>>>>> Here's a sampling of the warnings that I think covers most, >>>>>>>>>>>> maybe all, of the cases >>>>>>>>>>>> LINUX >>>>>>>>>>>> mlib_ImageAffine_NN_Bit.c:87:81: error: suggest parentheses >>>>>>>>>>>> around '-' in operand of '&' [-Werror=parentheses] >>>>>>>>>>>> res = (res & ~(1 << bit)) | (((srcPixelPtr[X >> >>>>>>>>>>>> (MLIB_SHIFT + 3)] >> (7 - (X >> MLIB_SHIFT) & 7)) & 1) << >>>>>>>>>>>> >>>>>>>>>>>> ^ >>>>>>>>>>>> mlib_ImageAffine_NN_Bit.c:153:81: error: suggest parentheses >>>>>>>>>>>> around '-' in operand of '&' [-Werror=parentheses] >>>>>>>>>>>> res = (res & ~(1 << bit)) | (((srcPixelPtr[X >> >>>>>>>>>>>> (MLIB_SHIFT + 3)] >> (7 - (X >> MLIB_SHIFT) & 7)) & 1) << >>>>>>>>>>>> bit); >>>>>>>>>>>> >>>>>>>>>>>> ----------------- >>>>>>>>>>>> mlib_c_ImageCopy.c: In function 'mlib_c_ImageCopy_s16': >>>>>>>>>>>> mlib_c_ImageCopy.c:439:5: error: suggest parentheses around >>>>>>>>>>>> assignment used as truth value [-Werror=parentheses] >>>>>>>>>>>> STRIP(pdst, psrc, src_width, src_height, mlib_u16); >>>>>>>>>>>> ^ >>>>>>>>>>>> - >>>>>>>>>>>> MAC ... >>>>>>>>>>>> >>>>>>>>>>>> mlib_c_ImageCopy.c:331:5: error: using the result of an >>>>>>>>>>>> assignment as a condition without parentheses >>>>>>>>>>>> [-Werror,-Wparentheses] >>>>>>>>>>>> STRIP(pdst, psrc, src_width, src_height, mlib_u8); >>>>>>>>>>>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>>>>>>>>> mlib_c_ImageCopy.c:185:11: note: expanded from macro 'STRIP' >>>>>>>>>>>> if (j = w & 1) \ >>>>>>>>>>>> ~~^~~~~~~ >>>>>>>>>>>> mlib_c_ImageCopy.c:331:5: note: place parentheses around the >>>>>>>>>>>> assignment to silence this warning\ >>>>>>>>>>>> >>>>>>>>>>>> --- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> --- >>>>>>>>>>>> SOLARIS >>>>>>>>>>>> mlib_ImageConv_16ext.c", line 532: statement not reached >>>>>>>>>>>> (E_STATEMENT_NOT_REACHED) >>>>>>>>>>>> >>>>>>>>>>>> This last one was not nice just the ";" was considered a >>>>>>>>>>>> statement >>>>>>>>>>>> after the {XX; YY; return Z} macro expansion >>>>>>>>>>>> and turning into "do { {....} } while (0)" did not help since >>>>>>>>>>>> then it said "loop terminator not reached - other cases we >>>>>>>>>>>> have >>>>>>>>>>>> like this have at least a condition in the macro. >>>>>>>>>>>> >>>>>>>>>>>> -phil. >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>> >>> >> From james.graham at oracle.com Tue Aug 2 22:08:57 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 2 Aug 2016 15:08:57 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8074843: Resolve disabled warnings for libmlib_image and libmlib_image_v In-Reply-To: <0d99258d-f580-e905-0be8-bc3ecf1398c8@oracle.com> References: <579A95D6.3090604@oracle.com> <8ef6de35-011d-5218-3bdd-f3547e65ee29@oracle.com> <579B5A03.7000801@oracle.com> <4e04aa2a-da69-7983-2644-c1e7a5d23af3@oracle.com> <579B6885.6070706@oracle.com> <776d0e58-dff7-3b88-a1ca-480c806e42a4@oracle.com> <579C23B0.2030301@oracle.com> <579F8348.60009@oracle.com> <57A03428.3060501@oracle.com> <57A0DAAF.3050803@oracle.com> <0d99258d-f580-e905-0be8-bc3ecf1398c8@oracle.com> Message-ID: I agree as well. Assignments really aren't ever needed inside if statements... ...jim On 08/02/2016 03:06 PM, Vadim Pakhnushev wrote: > Or as > j = w & 1; > if (j != 0) { > as in other longer cases. Too much parentheses to my taste. > > Vadim > > On 03.08.2016 1:04, Jim Graham wrote: >> In that case, then I'd write it as "if ((j = (w & 1)) != 0)" to make >> it clear that the LHS is an assignment. A casual reading of the code >> might see this as a comparison with an extra set of parentheses until >> someone counts the equal signs... >> >> ...jim >> >> On 08/02/2016 10:38 AM, Phil Race wrote: >>> On 08/01/2016 10:48 PM, Prasanta Sadhukhan wrote: >>>> +1. Only one thing, >>>> >>>> mlib_c_ImageCopy.c#185 do we really need that extra parentheses, >>>> ((j = (w & 1))). I guess this should just do if (j = (w & 1)), isn't >>>> it? >>> >>> I originally tried exactly that but the compiler still complained and >>> did insist on what you see. >>> >>> Just to prove it I just now (temporarily) changed the code to what you >>> suggest and the result is this :- >>> >>> libmlib_image/mlib_c_ImageCopy.c: In function 'mlib_c_ImageCopy_u8': >>> mlib_c_ImageCopy.c:331:5: error: suggest parentheses around >>> assignment used as truth value [-Werror=parentheses] >>> STRIP(pdst, psrc, src_width, src_height, mlib_u8); >>> ^ >>> >>> >>> -phil. >>> >>>> Regards >>>> Prasanta >>>> On 8/1/2016 10:43 PM, Phil Race wrote: >>>>> Looking for another "+1" ... >>>>> >>>>> -phil. >>>>> >>>>> On 07/29/2016 10:13 PM, Vadim Pakhnushev wrote: >>>>>> Looks good! >>>>>> >>>>>> Vadim >>>>>> >>>>>> On 30.07.2016 6:49, Philip Race wrote: >>>>>>> See http://cr.openjdk.java.net/~prr/8074843.1/ >>>>>>> >>>>>>> Also passes JPRT >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 7/29/16, 7:35 AM, Vadim Pakhnushev wrote: >>>>>>>> On 29.07.2016 17:30, Philip Race wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 7/29/16, 7:00 AM, Vadim Pakhnushev wrote: >>>>>>>>>> On 29.07.2016 16:28, Philip Race wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 7/29/16, 3:23 AM, Vadim Pakhnushev wrote: >>>>>>>>>>>> Phil, >>>>>>>>>>>> >>>>>>>>>>>> I guess you wanted to remove the lines in the >>>>>>>>>>>> Awt2dLibraries.gmk? >>>>>>>>>>> >>>>>>>>>>> Ah, yes. Not just disable them >>>>>>>>>>>> >>>>>>>>>>>> Do you think it's worth it to rewrite these assignments as >>>>>>>>>>>> separate assignment and a condition? >>>>>>>>>>>> Especially long ones with a lot of parentheses? >>>>>>>>>>>> Like this one, instead of >>>>>>>>>>>> if ((j = ((mlib_s32) ((mlib_addr) psrc_row & 4) >> 2))) { >>>>>>>>>>>> >>>>>>>>>>>> j = (mlib_s32) ((mlib_addr) psrc_row & 4) >> 2; >>>>>>>>>>>> if (j != 0) { >>>>>>>>>>> >>>>>>>>>>> I don't know. Where would I stop ? >>>>>>>>>> >>>>>>>>>> Where it doesn't feel weird anymore? >>>>>>>>>> For example, is this line correct? >>>>>>>>>> if (j = (((mlib_addr) pdst_row & 2) != 0)) { >>>>>>>>>> It seems very weird for me that we assign a boolean value to the >>>>>>>>>> loop variable. >>>>>>>>>> It looks like there's an error in parentheses and it should >>>>>>>>>> instead look like: >>>>>>>>>> if ((j = (((mlib_addr) pdst_row & 2) != 0) { >>>>>>>>>> Yeah, in this particular case it doesn't even matter but still >>>>>>>>>> assignments in conditions can very easily lead to errors. >>>>>>>>> >>>>>>>>> OK I will take a *limited* look at this. >>>>>>>> >>>>>>>> Yeah it's just 2 identical lines in the mlib_c_ImageCopy.c >>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Also seeing macro calls without a semicolon is weird. >>>>>>>>>>>> I don't see any need in parentheses in the definition of >>>>>>>>>>>> FREE_AND_RETURN_STATUS so maybe it's possible to rewrite it >>>>>>>>>>>> without trailing semicolon? >>>>>>>>>>> >>>>>>>>>>> I anticipated the question and it is already addressed in my >>>>>>>>>>> last >>>>>>>>>>> paragraph right at the very bottom of the review request. >>>>>>>>>> >>>>>>>>>> Oops, missed that. >>>>>>>>>> >>>>>>>>>>> Basically that pattern has an "if (x==NULL) return". If you >>>>>>>>>>> don't >>>>>>>>>>> have that "if" then the compiler would have objected to that >>>>>>>>>>> too ! >>>>>>>>>> >>>>>>>>>> I'm not sure I undestand this. >>>>>>>>> >>>>>>>>> I mean I without the condition the compiler can tell you *never* >>>>>>>>> reach >>>>>>>>> the while (0) and so objected on those grounds. I tried this. >>>>>>>> >>>>>>>> Got it. >>>>>>>> >>>>>>>>>> >>>>>>>>>> I mean why not rewrite the macro like this: >>>>>>>>>> #define FREE_AND_RETURN_STATUS \ >>>>>>>>>> if (pbuff != buff) mlib_free(pbuff); \ >>>>>>>>>> if (k != akernel) mlib_free(k); \ >>>>>>>>>> return status >>>>>>>>>> #endif /* FREE_AND_RETURN_STATUS */ >>>>>>>>>> >>>>>>>>>> Yes it's prone to errors like if (foo) FREE_AND_RETURN_STATUS; >>>>>>>>>> but all its usages are separate statements. >>>>>>>>> >>>>>>>>> hmm .. I suppose could .. but not pretty either. >>>>>>>>> Also if going that route it could be >>>>>>>>> >>>>>>>>> #define FREE_AND_RETURN_STATUS \ >>>>>>>>> { \ >>>>>>>>> if (pbuff != buff) mlib_free(pbuff); \ >>>>>>>>> if (k != akernel) mlib_free(k); \ >>>>>>>>> } \ >>>>>>>>> return status >>>>>>>>> #endif /* FREE_AND_RETURN_STATUS */ >>>>>>>>> >>>>>>>>> ?? >>>>>>>> >>>>>>>> What's the point of parentheses here? >>>>>>>> I thought that the whole point of curly braces and do .... >>>>>>>> while(0) stuff was to enable the macro calls in conditions like if >>>>>>>> (foo) CALL_MACRO; without the curly braces around CALL_MACRO. >>>>>>>> But if you put curly braces around only part of the macro >>>>>>>> definition this would be broken anyway. >>>>>>>> >>>>>>>> Vadim >>>>>>>> >>>>>>>>> >>>>>>>>> -phil. >>>>>>>>>> >>>>>>>>>> Vadim >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Vadim >>>>>>>>>>>> >>>>>>>>>>>> On 29.07.2016 2:31, Philip Race wrote: >>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074843 >>>>>>>>>>>>> Fix: http://cr.openjdk.java.net/~prr/8074843/ >>>>>>>>>>>>> >>>>>>>>>>>>> Here's a sampling of the warnings that I think covers most, >>>>>>>>>>>>> maybe all, of the cases >>>>>>>>>>>>> LINUX >>>>>>>>>>>>> mlib_ImageAffine_NN_Bit.c:87:81: error: suggest parentheses >>>>>>>>>>>>> around '-' in operand of '&' [-Werror=parentheses] >>>>>>>>>>>>> res = (res & ~(1 << bit)) | (((srcPixelPtr[X >> >>>>>>>>>>>>> (MLIB_SHIFT + 3)] >> (7 - (X >> MLIB_SHIFT) & 7)) & 1) << >>>>>>>>>>>>> >>>>>>>>>>>>> ^ >>>>>>>>>>>>> mlib_ImageAffine_NN_Bit.c:153:81: error: suggest parentheses >>>>>>>>>>>>> around '-' in operand of '&' [-Werror=parentheses] >>>>>>>>>>>>> res = (res & ~(1 << bit)) | (((srcPixelPtr[X >> >>>>>>>>>>>>> (MLIB_SHIFT + 3)] >> (7 - (X >> MLIB_SHIFT) & 7)) & 1) << >>>>>>>>>>>>> bit); >>>>>>>>>>>>> >>>>>>>>>>>>> ----------------- >>>>>>>>>>>>> mlib_c_ImageCopy.c: In function 'mlib_c_ImageCopy_s16': >>>>>>>>>>>>> mlib_c_ImageCopy.c:439:5: error: suggest parentheses around >>>>>>>>>>>>> assignment used as truth value [-Werror=parentheses] >>>>>>>>>>>>> STRIP(pdst, psrc, src_width, src_height, mlib_u16); >>>>>>>>>>>>> ^ >>>>>>>>>>>>> - >>>>>>>>>>>>> MAC ... >>>>>>>>>>>>> >>>>>>>>>>>>> mlib_c_ImageCopy.c:331:5: error: using the result of an >>>>>>>>>>>>> assignment as a condition without parentheses >>>>>>>>>>>>> [-Werror,-Wparentheses] >>>>>>>>>>>>> STRIP(pdst, psrc, src_width, src_height, mlib_u8); >>>>>>>>>>>>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>>>>>>>>>> mlib_c_ImageCopy.c:185:11: note: expanded from macro 'STRIP' >>>>>>>>>>>>> if (j = w & 1) \ >>>>>>>>>>>>> ~~^~~~~~~ >>>>>>>>>>>>> mlib_c_ImageCopy.c:331:5: note: place parentheses around the >>>>>>>>>>>>> assignment to silence this warning\ >>>>>>>>>>>>> >>>>>>>>>>>>> --- >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> --- >>>>>>>>>>>>> SOLARIS >>>>>>>>>>>>> mlib_ImageConv_16ext.c", line 532: statement not reached >>>>>>>>>>>>> (E_STATEMENT_NOT_REACHED) >>>>>>>>>>>>> >>>>>>>>>>>>> This last one was not nice just the ";" was considered a >>>>>>>>>>>>> statement >>>>>>>>>>>>> after the {XX; YY; return Z} macro expansion >>>>>>>>>>>>> and turning into "do { {....} } while (0)" did not help since >>>>>>>>>>>>> then it said "loop terminator not reached - other cases we >>>>>>>>>>>>> have >>>>>>>>>>>>> like this have at least a condition in the macro. >>>>>>>>>>>>> >>>>>>>>>>>>> -phil. >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> > From james.graham at oracle.com Tue Aug 2 22:10:47 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 2 Aug 2016 15:10:47 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8074843: Resolve disabled warnings for libmlib_image and libmlib_image_v In-Reply-To: <0d99258d-f580-e905-0be8-bc3ecf1398c8@oracle.com> References: <579A95D6.3090604@oracle.com> <8ef6de35-011d-5218-3bdd-f3547e65ee29@oracle.com> <579B5A03.7000801@oracle.com> <4e04aa2a-da69-7983-2644-c1e7a5d23af3@oracle.com> <579B6885.6070706@oracle.com> <776d0e58-dff7-3b88-a1ca-480c806e42a4@oracle.com> <579C23B0.2030301@oracle.com> <579F8348.60009@oracle.com> <57A03428.3060501@oracle.com> <57A0DAAF.3050803@oracle.com> <0d99258d-f580-e905-0be8-bc3ecf1398c8@oracle.com> Message-ID: <0cb46acd-fc22-093b-7b4b-c120f651bf4b@oracle.com> Also, fix the line of "\" at the right edge of the source and add {} around the body of the if statement... ...jim On 08/02/2016 03:06 PM, Vadim Pakhnushev wrote: > Or as > j = w & 1; > if (j != 0) { > as in other longer cases. Too much parentheses to my taste. > > Vadim > > On 03.08.2016 1:04, Jim Graham wrote: >> In that case, then I'd write it as "if ((j = (w & 1)) != 0)" to make >> it clear that the LHS is an assignment. A casual reading of the code >> might see this as a comparison with an extra set of parentheses until >> someone counts the equal signs... >> >> ...jim >> >> On 08/02/2016 10:38 AM, Phil Race wrote: >>> On 08/01/2016 10:48 PM, Prasanta Sadhukhan wrote: >>>> +1. Only one thing, >>>> >>>> mlib_c_ImageCopy.c#185 do we really need that extra parentheses, >>>> ((j = (w & 1))). I guess this should just do if (j = (w & 1)), isn't >>>> it? >>> >>> I originally tried exactly that but the compiler still complained and >>> did insist on what you see. >>> >>> Just to prove it I just now (temporarily) changed the code to what you >>> suggest and the result is this :- >>> >>> libmlib_image/mlib_c_ImageCopy.c: In function 'mlib_c_ImageCopy_u8': >>> mlib_c_ImageCopy.c:331:5: error: suggest parentheses around >>> assignment used as truth value [-Werror=parentheses] >>> STRIP(pdst, psrc, src_width, src_height, mlib_u8); >>> ^ >>> >>> >>> -phil. >>> >>>> Regards >>>> Prasanta >>>> On 8/1/2016 10:43 PM, Phil Race wrote: >>>>> Looking for another "+1" ... >>>>> >>>>> -phil. >>>>> >>>>> On 07/29/2016 10:13 PM, Vadim Pakhnushev wrote: >>>>>> Looks good! >>>>>> >>>>>> Vadim >>>>>> >>>>>> On 30.07.2016 6:49, Philip Race wrote: >>>>>>> See http://cr.openjdk.java.net/~prr/8074843.1/ >>>>>>> >>>>>>> Also passes JPRT >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 7/29/16, 7:35 AM, Vadim Pakhnushev wrote: >>>>>>>> On 29.07.2016 17:30, Philip Race wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 7/29/16, 7:00 AM, Vadim Pakhnushev wrote: >>>>>>>>>> On 29.07.2016 16:28, Philip Race wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 7/29/16, 3:23 AM, Vadim Pakhnushev wrote: >>>>>>>>>>>> Phil, >>>>>>>>>>>> >>>>>>>>>>>> I guess you wanted to remove the lines in the >>>>>>>>>>>> Awt2dLibraries.gmk? >>>>>>>>>>> >>>>>>>>>>> Ah, yes. Not just disable them >>>>>>>>>>>> >>>>>>>>>>>> Do you think it's worth it to rewrite these assignments as >>>>>>>>>>>> separate assignment and a condition? >>>>>>>>>>>> Especially long ones with a lot of parentheses? >>>>>>>>>>>> Like this one, instead of >>>>>>>>>>>> if ((j = ((mlib_s32) ((mlib_addr) psrc_row & 4) >> 2))) { >>>>>>>>>>>> >>>>>>>>>>>> j = (mlib_s32) ((mlib_addr) psrc_row & 4) >> 2; >>>>>>>>>>>> if (j != 0) { >>>>>>>>>>> >>>>>>>>>>> I don't know. Where would I stop ? >>>>>>>>>> >>>>>>>>>> Where it doesn't feel weird anymore? >>>>>>>>>> For example, is this line correct? >>>>>>>>>> if (j = (((mlib_addr) pdst_row & 2) != 0)) { >>>>>>>>>> It seems very weird for me that we assign a boolean value to the >>>>>>>>>> loop variable. >>>>>>>>>> It looks like there's an error in parentheses and it should >>>>>>>>>> instead look like: >>>>>>>>>> if ((j = (((mlib_addr) pdst_row & 2) != 0) { >>>>>>>>>> Yeah, in this particular case it doesn't even matter but still >>>>>>>>>> assignments in conditions can very easily lead to errors. >>>>>>>>> >>>>>>>>> OK I will take a *limited* look at this. >>>>>>>> >>>>>>>> Yeah it's just 2 identical lines in the mlib_c_ImageCopy.c >>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Also seeing macro calls without a semicolon is weird. >>>>>>>>>>>> I don't see any need in parentheses in the definition of >>>>>>>>>>>> FREE_AND_RETURN_STATUS so maybe it's possible to rewrite it >>>>>>>>>>>> without trailing semicolon? >>>>>>>>>>> >>>>>>>>>>> I anticipated the question and it is already addressed in my >>>>>>>>>>> last >>>>>>>>>>> paragraph right at the very bottom of the review request. >>>>>>>>>> >>>>>>>>>> Oops, missed that. >>>>>>>>>> >>>>>>>>>>> Basically that pattern has an "if (x==NULL) return". If you >>>>>>>>>>> don't >>>>>>>>>>> have that "if" then the compiler would have objected to that >>>>>>>>>>> too ! >>>>>>>>>> >>>>>>>>>> I'm not sure I undestand this. >>>>>>>>> >>>>>>>>> I mean I without the condition the compiler can tell you *never* >>>>>>>>> reach >>>>>>>>> the while (0) and so objected on those grounds. I tried this. >>>>>>>> >>>>>>>> Got it. >>>>>>>> >>>>>>>>>> >>>>>>>>>> I mean why not rewrite the macro like this: >>>>>>>>>> #define FREE_AND_RETURN_STATUS \ >>>>>>>>>> if (pbuff != buff) mlib_free(pbuff); \ >>>>>>>>>> if (k != akernel) mlib_free(k); \ >>>>>>>>>> return status >>>>>>>>>> #endif /* FREE_AND_RETURN_STATUS */ >>>>>>>>>> >>>>>>>>>> Yes it's prone to errors like if (foo) FREE_AND_RETURN_STATUS; >>>>>>>>>> but all its usages are separate statements. >>>>>>>>> >>>>>>>>> hmm .. I suppose could .. but not pretty either. >>>>>>>>> Also if going that route it could be >>>>>>>>> >>>>>>>>> #define FREE_AND_RETURN_STATUS \ >>>>>>>>> { \ >>>>>>>>> if (pbuff != buff) mlib_free(pbuff); \ >>>>>>>>> if (k != akernel) mlib_free(k); \ >>>>>>>>> } \ >>>>>>>>> return status >>>>>>>>> #endif /* FREE_AND_RETURN_STATUS */ >>>>>>>>> >>>>>>>>> ?? >>>>>>>> >>>>>>>> What's the point of parentheses here? >>>>>>>> I thought that the whole point of curly braces and do .... >>>>>>>> while(0) stuff was to enable the macro calls in conditions like if >>>>>>>> (foo) CALL_MACRO; without the curly braces around CALL_MACRO. >>>>>>>> But if you put curly braces around only part of the macro >>>>>>>> definition this would be broken anyway. >>>>>>>> >>>>>>>> Vadim >>>>>>>> >>>>>>>>> >>>>>>>>> -phil. >>>>>>>>>> >>>>>>>>>> Vadim >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Vadim >>>>>>>>>>>> >>>>>>>>>>>> On 29.07.2016 2:31, Philip Race wrote: >>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074843 >>>>>>>>>>>>> Fix: http://cr.openjdk.java.net/~prr/8074843/ >>>>>>>>>>>>> >>>>>>>>>>>>> Here's a sampling of the warnings that I think covers most, >>>>>>>>>>>>> maybe all, of the cases >>>>>>>>>>>>> LINUX >>>>>>>>>>>>> mlib_ImageAffine_NN_Bit.c:87:81: error: suggest parentheses >>>>>>>>>>>>> around '-' in operand of '&' [-Werror=parentheses] >>>>>>>>>>>>> res = (res & ~(1 << bit)) | (((srcPixelPtr[X >> >>>>>>>>>>>>> (MLIB_SHIFT + 3)] >> (7 - (X >> MLIB_SHIFT) & 7)) & 1) << >>>>>>>>>>>>> >>>>>>>>>>>>> ^ >>>>>>>>>>>>> mlib_ImageAffine_NN_Bit.c:153:81: error: suggest parentheses >>>>>>>>>>>>> around '-' in operand of '&' [-Werror=parentheses] >>>>>>>>>>>>> res = (res & ~(1 << bit)) | (((srcPixelPtr[X >> >>>>>>>>>>>>> (MLIB_SHIFT + 3)] >> (7 - (X >> MLIB_SHIFT) & 7)) & 1) << >>>>>>>>>>>>> bit); >>>>>>>>>>>>> >>>>>>>>>>>>> ----------------- >>>>>>>>>>>>> mlib_c_ImageCopy.c: In function 'mlib_c_ImageCopy_s16': >>>>>>>>>>>>> mlib_c_ImageCopy.c:439:5: error: suggest parentheses around >>>>>>>>>>>>> assignment used as truth value [-Werror=parentheses] >>>>>>>>>>>>> STRIP(pdst, psrc, src_width, src_height, mlib_u16); >>>>>>>>>>>>> ^ >>>>>>>>>>>>> - >>>>>>>>>>>>> MAC ... >>>>>>>>>>>>> >>>>>>>>>>>>> mlib_c_ImageCopy.c:331:5: error: using the result of an >>>>>>>>>>>>> assignment as a condition without parentheses >>>>>>>>>>>>> [-Werror,-Wparentheses] >>>>>>>>>>>>> STRIP(pdst, psrc, src_width, src_height, mlib_u8); >>>>>>>>>>>>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>>>>>>>>>> mlib_c_ImageCopy.c:185:11: note: expanded from macro 'STRIP' >>>>>>>>>>>>> if (j = w & 1) \ >>>>>>>>>>>>> ~~^~~~~~~ >>>>>>>>>>>>> mlib_c_ImageCopy.c:331:5: note: place parentheses around the >>>>>>>>>>>>> assignment to silence this warning\ >>>>>>>>>>>>> >>>>>>>>>>>>> --- >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> --- >>>>>>>>>>>>> SOLARIS >>>>>>>>>>>>> mlib_ImageConv_16ext.c", line 532: statement not reached >>>>>>>>>>>>> (E_STATEMENT_NOT_REACHED) >>>>>>>>>>>>> >>>>>>>>>>>>> This last one was not nice just the ";" was considered a >>>>>>>>>>>>> statement >>>>>>>>>>>>> after the {XX; YY; return Z} macro expansion >>>>>>>>>>>>> and turning into "do { {....} } while (0)" did not help since >>>>>>>>>>>>> then it said "loop terminator not reached - other cases we >>>>>>>>>>>>> have >>>>>>>>>>>>> like this have at least a condition in the macro. >>>>>>>>>>>>> >>>>>>>>>>>>> -phil. >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> > From philip.race at oracle.com Tue Aug 2 22:34:19 2016 From: philip.race at oracle.com (Philip Race) Date: Tue, 02 Aug 2016 15:34:19 -0700 Subject: [OpenJDK 2D-Dev] RFR 8159638: Improve array caches and renderer stats in Marlin renderer In-Reply-To: References: <8d819ad0-342b-15cb-8afc-bdda5da52a5d@oracle.com> <5480c2b9-a8fd-bc42-6e75-1b17c129dd59@oracle.com> Message-ID: <57A11FEB.7020302@oracle.com> I have not yet looked at everything but no issues except that I find checking in the shell script a bit weird. Not to mention its technically a "source file" so should have a license. -phil. On 8/2/16, 2:56 PM, Jim Graham wrote: > Thanks Laurent, > > On 08/02/2016 05:57 AM, Laurent Bourg?s wrote: >> Thanks for the tip, I made another webrev (for archive) that shows the >> proper diffs in ArrayCache / ArrayCacheConst: >> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8159638.1_bis/ >> > > Thanks! > >> In Renderer.java, you create the alphaLine and blkFlags refs as >> Clean, but then you always put them back using indices of (0, 0) so >> they will never actually be cleaned - is there a reason you don't >> just use a dirty ref there? >> >> Both alphaLine and blkFlags arrays must be zero-filled as these arrays >> are storing accumulated values: >> >> It is not possible to use a dirty reference in this case as both >> allocated and returned array may contain garbage data (from the >> IntArrayCache). > > D'oh! I guess that was obvious. I wasn't thinking of the fact that > dirty caches can initially return a non-zero-filled array - the fact > that they clean on "put" is only half of their zero guarantee... > >> Other than that question, I don't see any problems with the fix... >> >> Ready to go ? >> or I need another reviewer, phil ? > > Ready from my end. Phil? > > ...jim > From philip.race at oracle.com Tue Aug 2 22:35:27 2016 From: philip.race at oracle.com (Philip Race) Date: Tue, 02 Aug 2016 15:35:27 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8074843: Resolve disabled warnings for libmlib_image and libmlib_image_v In-Reply-To: <0cb46acd-fc22-093b-7b4b-c120f651bf4b@oracle.com> References: <579A95D6.3090604@oracle.com> <8ef6de35-011d-5218-3bdd-f3547e65ee29@oracle.com> <579B5A03.7000801@oracle.com> <4e04aa2a-da69-7983-2644-c1e7a5d23af3@oracle.com> <579B6885.6070706@oracle.com> <776d0e58-dff7-3b88-a1ca-480c806e42a4@oracle.com> <579C23B0.2030301@oracle.com> <579F8348.60009@oracle.com> <57A03428.3060501@oracle.com> <57A0DAAF.3050803@oracle.com> <0d99258d-f580-e905-0be8-bc3ecf1398c8@oracle.com> <0cb46acd-fc22-093b-7b4b-c120f651bf4b@oracle.com> Message-ID: <57A1202F.3040603@oracle.com> Well I already checked in but I did notice that alignment issue and fixed that before pushing. -phil. On 8/2/16, 3:10 PM, Jim Graham wrote: > Also, fix the line of "\" at the right edge of the source and add {} > around the body of the if statement... > > ...jim > > On 08/02/2016 03:06 PM, Vadim Pakhnushev wrote: >> Or as >> j = w & 1; >> if (j != 0) { >> as in other longer cases. Too much parentheses to my taste. >> >> Vadim >> >> On 03.08.2016 1:04, Jim Graham wrote: >>> In that case, then I'd write it as "if ((j = (w & 1)) != 0)" to make >>> it clear that the LHS is an assignment. A casual reading of the code >>> might see this as a comparison with an extra set of parentheses until >>> someone counts the equal signs... >>> >>> ...jim >>> >>> On 08/02/2016 10:38 AM, Phil Race wrote: >>>> On 08/01/2016 10:48 PM, Prasanta Sadhukhan wrote: >>>>> +1. Only one thing, >>>>> >>>>> mlib_c_ImageCopy.c#185 do we really need that extra parentheses, >>>>> ((j = (w & 1))). I guess this should just do if (j = (w & 1)), isn't >>>>> it? >>>> >>>> I originally tried exactly that but the compiler still complained and >>>> did insist on what you see. >>>> >>>> Just to prove it I just now (temporarily) changed the code to what you >>>> suggest and the result is this :- >>>> >>>> libmlib_image/mlib_c_ImageCopy.c: In function 'mlib_c_ImageCopy_u8': >>>> mlib_c_ImageCopy.c:331:5: error: suggest parentheses around >>>> assignment used as truth value [-Werror=parentheses] >>>> STRIP(pdst, psrc, src_width, src_height, mlib_u8); >>>> ^ >>>> >>>> >>>> -phil. >>>> >>>>> Regards >>>>> Prasanta >>>>> On 8/1/2016 10:43 PM, Phil Race wrote: >>>>>> Looking for another "+1" ... >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 07/29/2016 10:13 PM, Vadim Pakhnushev wrote: >>>>>>> Looks good! >>>>>>> >>>>>>> Vadim >>>>>>> >>>>>>> On 30.07.2016 6:49, Philip Race wrote: >>>>>>>> See http://cr.openjdk.java.net/~prr/8074843.1/ >>>>>>>> >>>>>>>> Also passes JPRT >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> On 7/29/16, 7:35 AM, Vadim Pakhnushev wrote: >>>>>>>>> On 29.07.2016 17:30, Philip Race wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 7/29/16, 7:00 AM, Vadim Pakhnushev wrote: >>>>>>>>>>> On 29.07.2016 16:28, Philip Race wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 7/29/16, 3:23 AM, Vadim Pakhnushev wrote: >>>>>>>>>>>>> Phil, >>>>>>>>>>>>> >>>>>>>>>>>>> I guess you wanted to remove the lines in the >>>>>>>>>>>>> Awt2dLibraries.gmk? >>>>>>>>>>>> >>>>>>>>>>>> Ah, yes. Not just disable them >>>>>>>>>>>>> >>>>>>>>>>>>> Do you think it's worth it to rewrite these assignments as >>>>>>>>>>>>> separate assignment and a condition? >>>>>>>>>>>>> Especially long ones with a lot of parentheses? >>>>>>>>>>>>> Like this one, instead of >>>>>>>>>>>>> if ((j = ((mlib_s32) ((mlib_addr) psrc_row & 4) >> 2))) { >>>>>>>>>>>>> >>>>>>>>>>>>> j = (mlib_s32) ((mlib_addr) psrc_row & 4) >> 2; >>>>>>>>>>>>> if (j != 0) { >>>>>>>>>>>> >>>>>>>>>>>> I don't know. Where would I stop ? >>>>>>>>>>> >>>>>>>>>>> Where it doesn't feel weird anymore? >>>>>>>>>>> For example, is this line correct? >>>>>>>>>>> if (j = (((mlib_addr) pdst_row & 2) != 0)) { >>>>>>>>>>> It seems very weird for me that we assign a boolean value to >>>>>>>>>>> the >>>>>>>>>>> loop variable. >>>>>>>>>>> It looks like there's an error in parentheses and it should >>>>>>>>>>> instead look like: >>>>>>>>>>> if ((j = (((mlib_addr) pdst_row & 2) != 0) { >>>>>>>>>>> Yeah, in this particular case it doesn't even matter but still >>>>>>>>>>> assignments in conditions can very easily lead to errors. >>>>>>>>>> >>>>>>>>>> OK I will take a *limited* look at this. >>>>>>>>> >>>>>>>>> Yeah it's just 2 identical lines in the mlib_c_ImageCopy.c >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Also seeing macro calls without a semicolon is weird. >>>>>>>>>>>>> I don't see any need in parentheses in the definition of >>>>>>>>>>>>> FREE_AND_RETURN_STATUS so maybe it's possible to rewrite it >>>>>>>>>>>>> without trailing semicolon? >>>>>>>>>>>> >>>>>>>>>>>> I anticipated the question and it is already addressed in my >>>>>>>>>>>> last >>>>>>>>>>>> paragraph right at the very bottom of the review request. >>>>>>>>>>> >>>>>>>>>>> Oops, missed that. >>>>>>>>>>> >>>>>>>>>>>> Basically that pattern has an "if (x==NULL) return". If you >>>>>>>>>>>> don't >>>>>>>>>>>> have that "if" then the compiler would have objected to that >>>>>>>>>>>> too ! >>>>>>>>>>> >>>>>>>>>>> I'm not sure I undestand this. >>>>>>>>>> >>>>>>>>>> I mean I without the condition the compiler can tell you >>>>>>>>>> *never* >>>>>>>>>> reach >>>>>>>>>> the while (0) and so objected on those grounds. I tried this. >>>>>>>>> >>>>>>>>> Got it. >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I mean why not rewrite the macro like this: >>>>>>>>>>> #define FREE_AND_RETURN_STATUS \ >>>>>>>>>>> if (pbuff != buff) mlib_free(pbuff); \ >>>>>>>>>>> if (k != akernel) mlib_free(k); \ >>>>>>>>>>> return status >>>>>>>>>>> #endif /* FREE_AND_RETURN_STATUS */ >>>>>>>>>>> >>>>>>>>>>> Yes it's prone to errors like if (foo) FREE_AND_RETURN_STATUS; >>>>>>>>>>> but all its usages are separate statements. >>>>>>>>>> >>>>>>>>>> hmm .. I suppose could .. but not pretty either. >>>>>>>>>> Also if going that route it could be >>>>>>>>>> >>>>>>>>>> #define FREE_AND_RETURN_STATUS \ >>>>>>>>>> { \ >>>>>>>>>> if (pbuff != buff) mlib_free(pbuff); \ >>>>>>>>>> if (k != akernel) mlib_free(k); \ >>>>>>>>>> } \ >>>>>>>>>> return status >>>>>>>>>> #endif /* FREE_AND_RETURN_STATUS */ >>>>>>>>>> >>>>>>>>>> ?? >>>>>>>>> >>>>>>>>> What's the point of parentheses here? >>>>>>>>> I thought that the whole point of curly braces and do .... >>>>>>>>> while(0) stuff was to enable the macro calls in conditions >>>>>>>>> like if >>>>>>>>> (foo) CALL_MACRO; without the curly braces around CALL_MACRO. >>>>>>>>> But if you put curly braces around only part of the macro >>>>>>>>> definition this would be broken anyway. >>>>>>>>> >>>>>>>>> Vadim >>>>>>>>> >>>>>>>>>> >>>>>>>>>> -phil. >>>>>>>>>>> >>>>>>>>>>> Vadim >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Vadim >>>>>>>>>>>>> >>>>>>>>>>>>> On 29.07.2016 2:31, Philip Race wrote: >>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074843 >>>>>>>>>>>>>> Fix: http://cr.openjdk.java.net/~prr/8074843/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Here's a sampling of the warnings that I think covers most, >>>>>>>>>>>>>> maybe all, of the cases >>>>>>>>>>>>>> LINUX >>>>>>>>>>>>>> mlib_ImageAffine_NN_Bit.c:87:81: error: suggest parentheses >>>>>>>>>>>>>> around '-' in operand of '&' [-Werror=parentheses] >>>>>>>>>>>>>> res = (res & ~(1 << bit)) | (((srcPixelPtr[X >> >>>>>>>>>>>>>> (MLIB_SHIFT + 3)] >> (7 - (X >> MLIB_SHIFT) & 7)) & 1) << >>>>>>>>>>>>>> >>>>>>>>>>>>>> ^ >>>>>>>>>>>>>> mlib_ImageAffine_NN_Bit.c:153:81: error: suggest parentheses >>>>>>>>>>>>>> around '-' in operand of '&' [-Werror=parentheses] >>>>>>>>>>>>>> res = (res & ~(1 << bit)) | (((srcPixelPtr[X >> >>>>>>>>>>>>>> (MLIB_SHIFT + 3)] >> (7 - (X >> MLIB_SHIFT) & 7)) & 1) << >>>>>>>>>>>>>> bit); >>>>>>>>>>>>>> >>>>>>>>>>>>>> ----------------- >>>>>>>>>>>>>> mlib_c_ImageCopy.c: In function 'mlib_c_ImageCopy_s16': >>>>>>>>>>>>>> mlib_c_ImageCopy.c:439:5: error: suggest parentheses around >>>>>>>>>>>>>> assignment used as truth value [-Werror=parentheses] >>>>>>>>>>>>>> STRIP(pdst, psrc, src_width, src_height, mlib_u16); >>>>>>>>>>>>>> ^ >>>>>>>>>>>>>> - >>>>>>>>>>>>>> MAC ... >>>>>>>>>>>>>> >>>>>>>>>>>>>> mlib_c_ImageCopy.c:331:5: error: using the result of an >>>>>>>>>>>>>> assignment as a condition without parentheses >>>>>>>>>>>>>> [-Werror,-Wparentheses] >>>>>>>>>>>>>> STRIP(pdst, psrc, src_width, src_height, mlib_u8); >>>>>>>>>>>>>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>>>>>>>>>>> mlib_c_ImageCopy.c:185:11: note: expanded from macro 'STRIP' >>>>>>>>>>>>>> if (j = w & 1) \ >>>>>>>>>>>>>> ~~^~~~~~~ >>>>>>>>>>>>>> mlib_c_ImageCopy.c:331:5: note: place parentheses around the >>>>>>>>>>>>>> assignment to silence this warning\ >>>>>>>>>>>>>> >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> SOLARIS >>>>>>>>>>>>>> mlib_ImageConv_16ext.c", line 532: statement not reached >>>>>>>>>>>>>> (E_STATEMENT_NOT_REACHED) >>>>>>>>>>>>>> >>>>>>>>>>>>>> This last one was not nice just the ";" was considered a >>>>>>>>>>>>>> statement >>>>>>>>>>>>>> after the {XX; YY; return Z} macro expansion >>>>>>>>>>>>>> and turning into "do { {....} } while (0)" did not help >>>>>>>>>>>>>> since >>>>>>>>>>>>>> then it said "loop terminator not reached - other cases we >>>>>>>>>>>>>> have >>>>>>>>>>>>>> like this have at least a condition in the macro. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -phil. >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> From james.graham at oracle.com Wed Aug 3 00:28:15 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 2 Aug 2016 17:28:15 -0700 Subject: [OpenJDK 2D-Dev] RFR 8159638: Improve array caches and renderer stats in Marlin renderer In-Reply-To: <57A11FEB.7020302@oracle.com> References: <8d819ad0-342b-15cb-8afc-bdda5da52a5d@oracle.com> <5480c2b9-a8fd-bc42-6e75-1b17c129dd59@oracle.com> <57A11FEB.7020302@oracle.com> Message-ID: <62ab4e4f-a035-59b8-7fa7-2c32511076ba@oracle.com> How about instead of the shell script we put a comment up at the top of the files (after the copyright header), with the appropriate command line? Something like: /* * Note that the Byte/Int/Float files are nearly identical except * for a few type and name differences. Typically, the Byte version * is edited manually and then the Int and Float versions are * generated with the following command lines: * % sed ... Float ... * % sed ... Int ... */ The only issue is trying to word this in a way that prevents the "Byte" in this comment from being converted. It gets even tricker when we have the strings being substituted appear in the command lines. Perhaps escapes would avoid the issue? And upper case? Something like this (but it looks kind of gross): /* * Note that the BYTE/INT/FLOAT files are nearly identical except * for a few type and name differences. Typically, the BYTE version * is edited manually and then the INT and FLOAT versions are * generated with the following command lines: * % sed ... \b\y\t\e ... float ... \B\y\t\e ... Float ... * % sed ... \b\y\t\e ... int ... \B\y\t\e ... Int ... */ A developer could either cut and paste the commands to a command line, or write their own shell script... ...jim On 08/02/2016 03:34 PM, Philip Race wrote: > I have not yet looked at everything but no issues except that > I find checking in the shell script a bit weird. > Not to mention its technically a "source file" so should have a license. > > -phil. > > On 8/2/16, 2:56 PM, Jim Graham wrote: >> Thanks Laurent, >> >> On 08/02/2016 05:57 AM, Laurent Bourg?s wrote: >>> Thanks for the tip, I made another webrev (for archive) that shows the >>> proper diffs in ArrayCache / ArrayCacheConst: >>> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8159638.1_bis/ >>> >> >> Thanks! >> >>> In Renderer.java, you create the alphaLine and blkFlags refs as >>> Clean, but then you always put them back using indices of (0, 0) so >>> they will never actually be cleaned - is there a reason you don't >>> just use a dirty ref there? >>> >>> Both alphaLine and blkFlags arrays must be zero-filled as these arrays >>> are storing accumulated values: >>> >>> It is not possible to use a dirty reference in this case as both >>> allocated and returned array may contain garbage data (from the >>> IntArrayCache). >> >> D'oh! I guess that was obvious. I wasn't thinking of the fact that >> dirty caches can initially return a non-zero-filled array - the fact >> that they clean on "put" is only half of their zero guarantee... >> >>> Other than that question, I don't see any problems with the fix... >>> >>> Ready to go ? >>> or I need another reviewer, phil ? >> >> Ready from my end. Phil? >> >> ...jim >> From philip.race at oracle.com Wed Aug 3 00:53:39 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 2 Aug 2016 17:53:39 -0700 Subject: [OpenJDK 2D-Dev] RFR 8159638: Improve array caches and renderer stats in Marlin renderer In-Reply-To: <62ab4e4f-a035-59b8-7fa7-2c32511076ba@oracle.com> References: <8d819ad0-342b-15cb-8afc-bdda5da52a5d@oracle.com> <5480c2b9-a8fd-bc42-6e75-1b17c129dd59@oracle.com> <57A11FEB.7020302@oracle.com> <62ab4e4f-a035-59b8-7fa7-2c32511076ba@oracle.com> Message-ID: <2AFDF873-28D8-46D0-ABDC-6AD641092F4F@oracle.com> I think that sounds reasonable. -Phil. > On Aug 2, 2016, at 5:28 PM, Jim Graham wrote: > > How about instead of the shell script we put a comment up at the top of the files (after the copyright header), with the appropriate command line? Something like: > > /* > * Note that the Byte/Int/Float files are nearly identical except > * for a few type and name differences. Typically, the Byte version > * is edited manually and then the Int and Float versions are > * generated with the following command lines: > * % sed ... Float ... > * % sed ... Int ... > */ > > The only issue is trying to word this in a way that prevents the "Byte" in this comment from being converted. It gets even tricker when we have the strings being substituted appear in the command lines. Perhaps escapes would avoid the issue? And upper case? Something like this (but it looks kind of gross): > > /* > * Note that the BYTE/INT/FLOAT files are nearly identical except > * for a few type and name differences. Typically, the BYTE version > * is edited manually and then the INT and FLOAT versions are > * generated with the following command lines: > * % sed ... \b\y\t\e ... float ... \B\y\t\e ... Float ... > * % sed ... \b\y\t\e ... int ... \B\y\t\e ... Int ... > */ > > A developer could either cut and paste the commands to a command line, or write their own shell script... > > ...jim > >> On 08/02/2016 03:34 PM, Philip Race wrote: >> I have not yet looked at everything but no issues except that >> I find checking in the shell script a bit weird. >> Not to mention its technically a "source file" so should have a license. >> >> -phil. >> >>> On 8/2/16, 2:56 PM, Jim Graham wrote: >>> Thanks Laurent, >>> >>>> On 08/02/2016 05:57 AM, Laurent Bourg?s wrote: >>>> Thanks for the tip, I made another webrev (for archive) that shows the >>>> proper diffs in ArrayCache / ArrayCacheConst: >>>> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8159638.1_bis/ >>>> >>> >>> Thanks! >>> >>>> In Renderer.java, you create the alphaLine and blkFlags refs as >>>> Clean, but then you always put them back using indices of (0, 0) so >>>> they will never actually be cleaned - is there a reason you don't >>>> just use a dirty ref there? >>>> >>>> Both alphaLine and blkFlags arrays must be zero-filled as these arrays >>>> are storing accumulated values: >>>> >>>> It is not possible to use a dirty reference in this case as both >>>> allocated and returned array may contain garbage data (from the >>>> IntArrayCache). >>> >>> D'oh! I guess that was obvious. I wasn't thinking of the fact that >>> dirty caches can initially return a non-zero-filled array - the fact >>> that they clean on "put" is only half of their zero guarantee... >>> >>>> Other than that question, I don't see any problems with the fix... >>>> >>>> Ready to go ? >>>> or I need another reviewer, phil ? >>> >>> Ready from my end. Phil? >>> >>> ...jim >>> From jayathirth.d.v at oracle.com Wed Aug 3 08:59:10 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 3 Aug 2016 01:59:10 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6575247: Banner checkbox in PrinterJob print dialog doesn't work In-Reply-To: <579F1126.4020801@oracle.com> References: <578CBD19.6000303@oracle.com> <578F9832.1080906@oracle.com> <5791FBF7.2050800@oracle.com> <579886BF.30600@oracle.com> <5798BC1F.2010605@oracle.com> <5799D5B1.4090808@oracle.com> <361e6046-dd03-b524-061e-955e8da3658b@oracle.com> <579F1126.4020801@oracle.com> Message-ID: <1a825abe-894a-40ca-a2ae-75add8f28f62@default> Hi Prasanta, Changes are working fine. Please add @Override annotation for methods in test case and increase sleep time little bit more for test case before pushing. No need for one more review. Thanks, Jay -----Original Message----- From: Prasanta Sadhukhan Sent: Monday, August 01, 2016 2:37 PM To: Phil Race Cc: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-6575247: Banner checkbox in PrinterJob print dialog doesn't work On 7/28/2016 9:19 PM, Phil Race wrote: > right .. when we talked off-line yesterday I said that if IPP is > reporting a default we should honour it. The default of standard/on is > only for the case we do not use IPP or it reports nothing. > > if (noJobSheet) { > 885 pFlags |= NOSHEET; > 886 ncomps+=1; > 887 } else { > 888 ncomps+=1; > 889 } > > .... > 905 if ((pFlags & NOSHEET) != 0) { > 906 execCmd[n++] = "-o nobanner"; > 907 } else if (getPrintService(). > 908 isAttributeCategorySupported(JobSheets.class)) { > 909 execCmd[n++] = "-o job-sheets=standard"; > 910 } > > So shouldn't the else at line 887 have the same condition as at line > 907 ? Yes. Have modified the webrev to add the check http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.04/ > > 2750 JobSheets js = (JobSheets)asCurrent.get(jsCategory); > 2751 if (js == null) { > 2752 js = > (JobSheets)psCurrent.getDefaultAttributeValue(jsCategory); > 2753 if (js == null) { > 2754 js = JobSheets.STANDARD; > 2755 } > > Please make sure this isn't causing a surprise on OSX or Windows .. > ie that we report correctly a value there so that "null" doesn't end > up causing us to print a banner page where we did not before. > Tested on osx and windows too where it behaves as it is now ie no banner page is printed by default. Regards Prasanta > -phil. > > On 7/28/2016 2:51 AM, Prasanta Sadhukhan wrote: >> The banner checkbox is not enabled initially as it calls >> getDefaultAttributeValue() and it seems printer is reporting the >> default job-sheet value as "none" so the below check is not satisfied. >> cbJobSheets.setSelected(js != JobSheets.NONE); >> >> When IPPPrintService#readIPPResponse() is called, it invokes /new >> AttributeClass(attribStr, valTagByte, outArray); >> /and stored the value corresponding to each attribute. >> >> I saw that IPP response has >> *job-sheets-default => job-sheets-default *and* >> **job-sheets-supported => job-sheets-supported* >> >> When AttributeClass constructor is called with ("job-sheets-default", >> 66, value) the value is >> [ 0] = (byte) 4 [ 1] = (byte) 110 [ 2] = (byte) 111 [ 3] = >> (byte) 110 [ 4] = (byte) 101 [ 5] = (byte) 4 [ 6] = (byte) >> 110 [ 7] = (byte) 111 [ 8] = (byte) 110 [ 9] = (byte) 101 >> [10] = (byte) 2 >> which basically translates to '',n,o,n,e,'',n,o,n,e,'' >> >> so when ServiceDialog calls >> IPPPrintService#getDefaultAttributeValue(JobSheets) >> ---------------- >> if (attribClass != null && >> attribClass.getStringValue().equals("none")) { >> return JobSheets.NONE; >> } else { >> return JobSheets.STANDARD; >> } >> -------------- >> we have attribClass.getStringValue() as "none" so default job sheet >> value is coming out to be NONE. >> Since it is coming out from IPP response, I think we should not >> change default value of JobSheets to STANDARD. Do you think otherwise? >> >> In the modified webrev, I have made the jobsheet default value >> STANDARD, only when IPP does not report any default value. >> >> http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.03/ >> >> Tested in ubuntu & solaris11. >> >> Regards >> Prasanta >> On 7/27/2016 7:20 PM, Philip Race wrote: >>> 883 } else { >>> 884 Class[] supportedCats = getPrintService(). >>> 885 getSupportedAttributeCategories(); >>> 886 for (int i=0;i>> 887 if (JobSheets.class == supportedCats[i]) { >>> 888 pFlags |= JOBSHEET; >>> 889 ncomps+=1; >>> 890 break; >>> 891 } >>> 892 } >>> >>> What is wrong with >>> >>> getPrintService().isAttributeCategorySupported(JobSheets.class) ? >>> >>> https://docs.oracle.com/javase/8/docs/api/javax/print/PrintService.h >>> tml#isAttributeCategorySupported-java.lang.Class- >>> >>> >>> I am also very confused about why you added JOBSHEET which seems to >>> duplicate the functionality of NOSHEET. >>> >>> Also it seems to me like it was intentional that the banner page be >>> printed by default .. which is why the variable was called >>> "*no*JobSheet .. >>> so as to over-ride that behaviour. >>> >>> It is kind of what you'd want if you walk over to the shared printer >>> in your office to have a banner page which declares it as yours ... >>> >>> So the checkbox should probably be enabled in that case. >>> >>> Also you should verify that we report the default value for >>> JobSheets as being STANDARD, not NONE. >>> >>> >>> -phil. >>> >>> On 7/27/16, 3:02 AM, Prasanta Sadhukhan wrote: >>>> Modified webrev to take care of a problem in webrev.01 whereby >>>> banner page was getting printed by default. >>>> Now, banner page will get printed only if the checkbox is checked >>>> in printer dialog. >>>> >>>> http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.02/ >>>> >>>> Regards >>>> Prasanta >>>> On 7/22/2016 4:26 PM, Prasanta Sadhukhan wrote: >>>>> Hi Phil, >>>>> >>>>> I have modified the code to check if job-sheets is supported and >>>>> then only proceed to print the banner page. >>>>> Also, rectified the jobTitle and banner confusion by adding >>>>> jobsheet check. >>>>> Also added the same code in UnixPrintJob even though I found its >>>>> printExecCmd() does not get executed in linux and solaris >>>>> PSPrinterJob's printExecCmd() is executed instead. In mac, neither >>>>> UnixPrinterJob#printExecCmd() nor PSPrinterJob#printExecCmd() gets >>>>> executed. >>>>> >>>>> Tested on ubuntu and solaris 11 with the fix and banner page is >>>>> printed with the fix. In mac, cover page gets printed without any >>>>> change. >>>>> >>>>> http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.01/ >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 7/20/2016 8:56 PM, Philip Race wrote: >>>>>> In my evaluation of that bug (which was 9 yrs ago so I do not >>>>>> have any memory of it :-)), I note that we first need to check >>>>>> that job-sheets is supported .. you are not doing that .. >>>>>> what happens if we pass an unsupported option ? >>>>>> "-o foobar" ?? This needs testing on Linux, OS X, and Solaris 11. >>>>>> >>>>>> Also -J (job-title) is something you can see in the queue when >>>>>> you do lpq. I don't know why it is tied to banner here but >>>>>> removing it seems wrong. Perhaps this should be renamed from >>>>>> "banner" and "BANNER" to jobTitle ?? Please examine this. >>>>>> >>>>>> In fact you seem to be conflicting with the -o nobanner. >>>>>> >>>>>> So in general we have some lack of clarity around job title and >>>>>> banner page (aka job sheet). >>>>>> >>>>>> Also we have PSPrinterJob and UnixPrinterJob with similar code. >>>>>> Please examine it to make sure no similar case is going missed. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 7/18/16, 4:27 AM, Prasanta Sadhukhan wrote: >>>>>>> Hi All, >>>>>>> >>>>>>> Please review a fix for an issue where it is seen that Banner >>>>>>> page in linux does not get printed despite user selecting the >>>>>>> Banner page checkbox in Printer dialog. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6575247 >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~psadhukhan/6575247/webrev.00/ >>>>>>> >>>>>>> It seems if we pass "-J " option to lpr command, it >>>>>>> has no effect. >>>>>>> To print Banner page, we need to pass "-o job-sheets=>>>>>> "classified", "confidential", "secret", "standard", "topsecret", >>>>>>> or "unclassified">" >>>>>>> >>>>>>> Since we support only standard banner or none via a checkbox, >>>>>>> the proposed fix passes option "-o job-sheets=standard" to lpr >>>>>>> command to print the banner page. >>>>>>> >>>>>>> Regards >>>>>>> PRasanta >>>>> >>>> >> > From jayathirth.d.v at oracle.com Wed Aug 3 09:45:45 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 3 Aug 2016 02:45:45 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-5080098: Page Range must be disabled on the common print dlg for Non serv-formatted flvrs In-Reply-To: <579AE97B.6090403@oracle.com> References: <577B791F.4020900@oracle.com> <5798E06A.5030909@oracle.com> <5799DDF7.30900@oracle.com> <579A0B4A.1060400@oracle.com> <579AE97B.6090403@oracle.com> Message-ID: <95248b82-aa78-45c0-a86f-1dd9f5bc91b3@default> Hi Prasanta, ? I tested your changes in linux and windows and it is effecting both the platforms(Page range is disabled). Please clarify whether your changes are specific to linux or it is generic. If it is generic please remove jtreg tag @requires (os.family == "linux") else please verify why it is effecting windows also. ? Also in jtreg comments use complete words and not short-forms(flvrs -> flavors, serv-formatted -> service-formatted). At some places lines are more than 80 chareacters in test case. Please update fix version to 9 in JBS. ? Thanks, Jay ? From: Prasanta Sadhukhan Sent: Friday, July 29, 2016 10:58 AM To: Philip Race Cc: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-5080098: Page Range must be disabled on the common print dlg for Non serv-formatted flvrs ? Yes, right. Please find the modified webrev: http://cr.openjdk.java.net/~psadhukhan/5080098/webrev.02/ Regards Prasanta On 7/28/2016 7:10 PM, Philip Race wrote: This can now be written more succinctly (and clearly) as : prPgRngSupported = psCurrent.isAttributeValueSupported(prAll, docFlavor, asCurrent); -phil. On 7/28/16, 3:27 AM, Prasanta Sadhukhan wrote: Trying to be extra cautious. Please find modified webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/5080098/webrev.01/"http://cr.openjdk.java.net/~psadhukhan/5080098/webrev.01/ Regards Prasanta On 7/27/2016 9:55 PM, Phil Race wrote: prAll is final and initalised. So why are you testing !=null ? -phil. On 07/05/2016 02:08 AM, Prasanta Sadhukhan wrote: Hi All, Please review a fix for an issue where it is seen "Page range (From/To) " field is not disabled for flavors such as postscript, image flavors. PageRanges attribute is supported only for Service Formatted flavors such as Pageable and Printable and so for other flavors such as postscript, image flavors page ranges fields must be disabled on the print dialog so as not to allow the user to select the same Bug: https://bugs.openjdk.java.net/browse/JDK-5080098 webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/5080098/webrev.00/"http://cr.openjdk.java.net/~psadhukhan/5080098/webrev.00/ Proposed fix is to check for attribute against the specified doc flavor and not against attribute category to decide whether to enable / disable it. Regards Prasanta ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bourges.laurent at gmail.com Wed Aug 3 09:58:38 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 3 Aug 2016 11:58:38 +0200 Subject: [OpenJDK 2D-Dev] RFR 8159638: Improve array caches and renderer stats in Marlin renderer In-Reply-To: <62ab4e4f-a035-59b8-7fa7-2c32511076ba@oracle.com> References: <8d819ad0-342b-15cb-8afc-bdda5da52a5d@oracle.com> <5480c2b9-a8fd-bc42-6e75-1b17c129dd59@oracle.com> <57A11FEB.7020302@oracle.com> <62ab4e4f-a035-59b8-7fa7-2c32511076ba@oracle.com> Message-ID: Jim & Phil, I added the following class header in Byte/Int/Float ArrayCache classes and removed the shell script: /* * Note that the [BYTE/INT/FLOAT]ArrayCache files are nearly identical except * for a few type and name differences. Typically, the [BYTE]ArrayCache.java file * is edited manually and then [INT]ArrayCache.java and [FLOAT]ArrayCache.java * files are generated with the following command lines: */ // % sed -e 's/(b\yte)[ ]*//g' -e 's/b\yte/int/g' -e 's/B\yte/Int/g' < B\yteArrayCache.java > IntArrayCache.java // % sed -e 's/(b\yte)[ ]*/(float) /g' -e 's/b\yte/float/g' -e 's/B\yte/Float/g' < B\yteArrayCache.java > FloatArrayCache.java I tested the commands and it works well. Here is the updated webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8159638.2/ Cheers, Laurent 2016-08-03 2:28 GMT+02:00 Jim Graham : > How about instead of the shell script we put a comment up at the top of > the files (after the copyright header), with the appropriate command line? > Something like: > > /* > * Note that the Byte/Int/Float files are nearly identical except > * for a few type and name differences. Typically, the Byte version > * is edited manually and then the Int and Float versions are > * generated with the following command lines: > * % sed ... Float ... > * % sed ... Int ... > */ > > The only issue is trying to word this in a way that prevents the "Byte" in > this comment from being converted. It gets even tricker when we have the > strings being substituted appear in the command lines. Perhaps escapes > would avoid the issue? And upper case? Something like this (but it looks > kind of gross): > > /* > * Note that the BYTE/INT/FLOAT files are nearly identical except > * for a few type and name differences. Typically, the BYTE version > * is edited manually and then the INT and FLOAT versions are > * generated with the following command lines: > * % sed ... \b\y\t\e ... float ... \B\y\t\e ... Float ... > * % sed ... \b\y\t\e ... int ... \B\y\t\e ... Int ... > */ > > A developer could either cut and paste the commands to a command line, or > write their own shell script... > > ...jim > > > On 08/02/2016 03:34 PM, Philip Race wrote: > >> I have not yet looked at everything but no issues except that >> I find checking in the shell script a bit weird. >> Not to mention its technically a "source file" so should have a license. >> >> -phil. >> >> On 8/2/16, 2:56 PM, Jim Graham wrote: >> >>> Thanks Laurent, >>> >>> On 08/02/2016 05:57 AM, Laurent Bourg?s wrote: >>> >>>> Thanks for the tip, I made another webrev (for archive) that shows the >>>> proper diffs in ArrayCache / ArrayCacheConst: >>>> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8159638.1_bis/ >>>> >>>> >>> >>> Thanks! >>> >>> In Renderer.java, you create the alphaLine and blkFlags refs as >>>> Clean, but then you always put them back using indices of (0, 0) so >>>> they will never actually be cleaned - is there a reason you don't >>>> just use a dirty ref there? >>>> >>>> Both alphaLine and blkFlags arrays must be zero-filled as these arrays >>>> are storing accumulated values: >>>> >>>> It is not possible to use a dirty reference in this case as both >>>> allocated and returned array may contain garbage data (from the >>>> IntArrayCache). >>>> >>> >>> D'oh! I guess that was obvious. I wasn't thinking of the fact that >>> dirty caches can initially return a non-zero-filled array - the fact >>> that they clean on "put" is only half of their zero guarantee... >>> >>> Other than that question, I don't see any problems with the fix... >>>> >>>> Ready to go ? >>>> or I need another reviewer, phil ? >>>> >>> >>> Ready from my end. Phil? >>> >>> ...jim >>> >>> -- -- Laurent Bourg?s -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Wed Aug 3 09:59:46 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 3 Aug 2016 15:29:46 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-5080098: Page Range must be disabled on the common print dlg for Non serv-formatted flvrs In-Reply-To: <95248b82-aa78-45c0-a86f-1dd9f5bc91b3@default> References: <577B791F.4020900@oracle.com> <5798E06A.5030909@oracle.com> <5799DDF7.30900@oracle.com> <579A0B4A.1060400@oracle.com> <579AE97B.6090403@oracle.com> <95248b82-aa78-45c0-a86f-1dd9f5bc91b3@default> Message-ID: <57A1C092.1070006@oracle.com> On 8/3/2016 3:15 PM, Jayathirth D V wrote: > > Hi Prasanta, > > I tested your changes in linux and windows and it is effecting both > the platforms(Page range is disabled). > > Please clarify whether your changes are specific to linux or it is > generic. If it is generic please remove jtreg tag @requires (os.family > == "linux") else please verify why it is effecting windows also. > It is generic and I will remove @requires tag. > > Also in jtreg comments use complete words and not short-forms(flvrs -> > flavors, serv-formatted -> service-formatted). > > At some places lines are more than 80 chareacters in test case. Please > update fix version to 9 in JBS. > > Thanks, > > Jay > > *From:*Prasanta Sadhukhan > *Sent:* Friday, July 29, 2016 10:58 AM > *To:* Philip Race > *Cc:* 2d-dev > *Subject:* Re: [OpenJDK 2D-Dev] [9] RFR JDK-5080098: Page Range must > be disabled on the common print dlg for Non serv-formatted flvrs > > Yes, right. Please find the modified webrev: > http://cr.openjdk.java.net/~psadhukhan/5080098/webrev.02/ > > > Regards > Prasanta > > On 7/28/2016 7:10 PM, Philip Race wrote: > > This can now be written more succinctly (and clearly) as : > > prPgRngSupported = psCurrent.isAttributeValueSupported(prAll, > docFlavor, asCurrent); > > > -phil. > > On 7/28/16, 3:27 AM, Prasanta Sadhukhan wrote: > > Trying to be extra cautious. Please find modified webrev: > http://cr.openjdk.java.net/~psadhukhan/5080098/webrev.01/ > > > Regards > Prasanta > On 7/27/2016 9:55 PM, Phil Race wrote: > > prAll is final and initalised. So why are you testing > !=null ? > > -phil. > > On 07/05/2016 02:08 AM, Prasanta Sadhukhan wrote: > > Hi All, > > Please review a fix for an issue where it is seen > "Page range (From/To) " field is not disabled for > flavors such as postscript, image flavors. > PageRanges attribute is supported only for Service > Formatted flavors such as Pageable and Printable and > so for > other flavors such as postscript, image flavors page > ranges fields must be disabled on the print dialog so > as not to allow the user to select the same > > Bug: https://bugs.openjdk.java.net/browse/JDK-5080098 > webrev: > http://cr.openjdk.java.net/~psadhukhan/5080098/webrev.00/ > > > > Proposed fix is to check for attribute against the > specified doc flavor > and not against attribute category to decide whether > to enable / disable it. > > Regards > Prasanta > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Wed Aug 3 12:00:32 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 3 Aug 2016 05:00:32 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8160456 : KSS : resource loading issue in TIFFMetadataFormat.java Message-ID: <706fe47d-bb35-465e-ac59-d5f63e226e70@default> Hi, Please review the following fix in JDK 9 at your convenience: Bug : https://bugs.openjdk.java.net/browse/JDK-8160456 Webrev : http://cr.openjdk.java.net/~jdv/8160456/webrev.00/ This is a KSS tool issue. We are not loading resource bundle from specific module in TIFFMetadataFormat.getResource() function, made changes to get resource bundle with respect to current module. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Aug 3 14:38:56 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 3 Aug 2016 07:38:56 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8160456 : KSS : resource loading issue in TIFFMetadataFormat.java In-Reply-To: <706fe47d-bb35-465e-ac59-d5f63e226e70@default> References: <706fe47d-bb35-465e-ac59-d5f63e226e70@default> Message-ID: <7006B541-E927-45F5-90DA-F76EFD462BAA@oracle.com> Hi Jay, This looks good to me. Thanks, Brian On Aug 3, 2016, at 5:00 AM, Jayathirth D V wrote: > Hi, > > Please review the following fix in JDK 9 at your convenience: > > Bug : https://bugs.openjdk.java.net/browse/JDK-8160456 > Webrev :http://cr.openjdk.java.net/~jdv/8160456/webrev.00/ > > This is a KSS tool issue. We are not loading resource bundle from specific module in TIFFMetadataFormat.getResource() function, made changes to get resource bundle with respect to current module. > > Thanks, > Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Aug 3 14:54:37 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 03 Aug 2016 07:54:37 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8160456 : KSS : resource loading issue in TIFFMetadataFormat.java In-Reply-To: <7006B541-E927-45F5-90DA-F76EFD462BAA@oracle.com> References: <706fe47d-bb35-465e-ac59-d5f63e226e70@default> <7006B541-E927-45F5-90DA-F76EFD462BAA@oracle.com> Message-ID: <57A205AD.2030303@oracle.com> +1 -phil On 8/3/16, 7:38 AM, Brian Burkhalter wrote: > Hi Jay, > > This looks good to me. > > Thanks, > > Brian > > On Aug 3, 2016, at 5:00 AM, Jayathirth D V > wrote: > >> Hi, >> Please review the following fix in JDK 9 at your convenience: >> Bug :https://bugs.openjdk.java.net/browse/JDK-8160456 >> Webrev :http://cr.openjdk.java.net/~jdv/8160456/webrev.00/ >> >> This is a KSS tool issue. We are not loading resource bundle from >> specific module in TIFFMetadataFormat.getResource() function, made >> changes to get resource bundle with respect to current module. >> Thanks, >> Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Wed Aug 3 15:04:49 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 3 Aug 2016 17:04:49 +0200 Subject: [OpenJDK 2D-Dev] RFR: JDK-8163102: Fix headless only configuration option Message-ID: Hello, The current --disable-headful option is weird. Even worse, it doesn't work since the makefiles still uses the legacy BUILD_HEADLESS_ONLY variable, which configure never touches. In this patch I'm replacing the configure option with --enable-headless-only. Default is disabled, where both headless and GUI support is built. When enabled, only headless support is built. These are the two variants we are ever interested in. On the makefile side, I redefined the variable as ENABLE_HEADLESS_ONLY=true/false. I also needed to change jawt.c to get a headless only build to actually work. The requirement that -DJAVASE_EMBEDDED is set seems unnecessary and unrelated to me. Bug: https://bugs.openjdk.java.net/browse/JDK-8163102 Webrev: http://cr.openjdk.java.net/~erikj/8163102/webrev.01 /Erik From tim.bell at oracle.com Wed Aug 3 15:33:50 2016 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 3 Aug 2016 08:33:50 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8163102: Fix headless only configuration option In-Reply-To: References: Message-ID: <57A20EDE.1090505@oracle.com> Erik: > The current --disable-headful option is weird. Even worse, it doesn't > work since the makefiles still uses the legacy BUILD_HEADLESS_ONLY > variable, which configure never touches. > > In this patch I'm replacing the configure option with > --enable-headless-only. Default is disabled, where both headless and > GUI support is built. When enabled, only headless support is built. > These are the two variants we are ever interested in. > > On the makefile side, I redefined the variable as > ENABLE_HEADLESS_ONLY=true/false. > > I also needed to change jawt.c to get a headless only build to > actually work. The requirement that -DJAVASE_EMBEDDED is set seems > unnecessary and unrelated to me. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163102 > > Webrev: http://cr.openjdk.java.net/~erikj/8163102/webrev.01 Looks good to me. /Tim From philip.race at oracle.com Wed Aug 3 16:32:11 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 03 Aug 2016 09:32:11 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8163102: Fix headless only configuration option In-Reply-To: References: Message-ID: <57A21C8B.3020406@oracle.com> Erik, David is already cleaning up the jawt.c file here :- http://cr.openjdk.java.net/~dholmes/8140723/webrev.jdk/src/java.desktop/unix/native/libjawt/jawt.c.sdiff.html Not sure who should win :-) -phil. On 8/3/16, 8:04 AM, Erik Joelsson wrote: > Hello, > > The current --disable-headful option is weird. Even worse, it doesn't > work since the makefiles still uses the legacy BUILD_HEADLESS_ONLY > variable, which configure never touches. > > In this patch I'm replacing the configure option with > --enable-headless-only. Default is disabled, where both headless and > GUI support is built. When enabled, only headless support is built. > These are the two variants we are ever interested in. > > On the makefile side, I redefined the variable as > ENABLE_HEADLESS_ONLY=true/false. > > I also needed to change jawt.c to get a headless only build to > actually work. The requirement that -DJAVASE_EMBEDDED is set seems > unnecessary and unrelated to me. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163102 > > Webrev: http://cr.openjdk.java.net/~erikj/8163102/webrev.01 > > /Erik > From james.graham at oracle.com Wed Aug 3 18:56:23 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 3 Aug 2016 11:56:23 -0700 Subject: [OpenJDK 2D-Dev] RFR 8159638: Improve array caches and renderer stats in Marlin renderer In-Reply-To: References: <8d819ad0-342b-15cb-8afc-bdda5da52a5d@oracle.com> <5480c2b9-a8fd-bc42-6e75-1b17c129dd59@oracle.com> <57A11FEB.7020302@oracle.com> <62ab4e4f-a035-59b8-7fa7-2c32511076ba@oracle.com> Message-ID: <303caadc-cacd-7ec9-31f7-14f8e60636c5@oracle.com> If that's the only change then it looks good to me... ...jim On 08/03/2016 02:58 AM, Laurent Bourg?s wrote: > Jim & Phil, > > I added the following class header in Byte/Int/Float ArrayCache classes > and removed the shell script: > > /* > * Note that the [BYTE/INT/FLOAT]ArrayCache files are nearly identical > except > * for a few type and name differences. Typically, the > [BYTE]ArrayCache.java file > * is edited manually and then [INT]ArrayCache.java and > [FLOAT]ArrayCache.java > * files are generated with the following command lines: > */ > // % sed -e 's/(b\yte)[ ]*//g' -e 's/b\yte/int/g' -e 's/B\yte/Int/g' < > B\yteArrayCache.java > IntArrayCache.java > // % sed -e 's/(b\yte)[ ]*/(float) /g' -e 's/b\yte/float/g' -e > 's/B\yte/Float/g' < B\yteArrayCache.java > FloatArrayCache.java > > I tested the commands and it works well. > > Here is the updated webrev: > http://cr.openjdk.java.net/~lbourges/marlin/marlin-8159638.2/ > > Cheers, > Laurent > > 2016-08-03 2:28 GMT+02:00 Jim Graham >: > > How about instead of the shell script we put a comment up at the top > of the files (after the copyright header), with the appropriate > command line? Something like: > > /* > * Note that the Byte/Int/Float files are nearly identical except > * for a few type and name differences. Typically, the Byte version > * is edited manually and then the Int and Float versions are > * generated with the following command lines: > * % sed ... Float ... > * % sed ... Int ... > */ > > The only issue is trying to word this in a way that prevents the > "Byte" in this comment from being converted. It gets even tricker > when we have the strings being substituted appear in the command > lines. Perhaps escapes would avoid the issue? And upper case? > Something like this (but it looks kind of gross): > > /* > * Note that the BYTE/INT/FLOAT files are nearly identical except > * for a few type and name differences. Typically, the BYTE version > * is edited manually and then the INT and FLOAT versions are > * generated with the following command lines: > * % sed ... \b\y\t\e ... float ... \B\y\t\e ... Float ... > * % sed ... \b\y\t\e ... int ... \B\y\t\e ... Int ... > */ > > A developer could either cut and paste the commands to a command > line, or write their own shell script... > > ...jim > > > On 08/02/2016 03:34 PM, Philip Race wrote: > > I have not yet looked at everything but no issues except that > I find checking in the shell script a bit weird. > Not to mention its technically a "source file" so should have a > license. > > -phil. > > On 8/2/16, 2:56 PM, Jim Graham wrote: > > Thanks Laurent, > > On 08/02/2016 05:57 AM, Laurent Bourg?s wrote: > > Thanks for the tip, I made another webrev (for archive) > that shows the > proper diffs in ArrayCache / ArrayCacheConst: > http://cr.openjdk.java.net/~lbourges/marlin/marlin-8159638.1_bis/ > > > > Thanks! > > In Renderer.java, you create the alphaLine and > blkFlags refs as > Clean, but then you always put them back using > indices of (0, 0) so > they will never actually be cleaned - is there a > reason you don't > just use a dirty ref there? > > Both alphaLine and blkFlags arrays must be zero-filled > as these arrays > are storing accumulated values: > > It is not possible to use a dirty reference in this case > as both > allocated and returned array may contain garbage data > (from the > IntArrayCache). > > > D'oh! I guess that was obvious. I wasn't thinking of the > fact that > dirty caches can initially return a non-zero-filled array - > the fact > that they clean on "put" is only half of their zero guarantee... > > Other than that question, I don't see any problems > with the fix... > > Ready to go ? > or I need another reviewer, phil ? > > > Ready from my end. Phil? > > ...jim > > > > > -- > -- > Laurent Bourg?s From bourges.laurent at gmail.com Wed Aug 3 19:14:11 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 3 Aug 2016 21:14:11 +0200 Subject: [OpenJDK 2D-Dev] RFR 8159638: Improve array caches and renderer stats in Marlin renderer In-Reply-To: <303caadc-cacd-7ec9-31f7-14f8e60636c5@oracle.com> References: <8d819ad0-342b-15cb-8afc-bdda5da52a5d@oracle.com> <5480c2b9-a8fd-bc42-6e75-1b17c129dd59@oracle.com> <57A11FEB.7020302@oracle.com> <62ab4e4f-a035-59b8-7fa7-2c32511076ba@oracle.com> <303caadc-cacd-7ec9-31f7-14f8e60636c5@oracle.com> Message-ID: Jim, Yes it is the only change. Phil, is it ok for you ? Thanks, Laurent Le 3 ao?t 2016 8:56 PM, "Jim Graham" a ?crit : > > If that's the only change then it looks good to me... > > ...jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Aug 3 19:18:19 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 03 Aug 2016 12:18:19 -0700 Subject: [OpenJDK 2D-Dev] RFR 8159638: Improve array caches and renderer stats in Marlin renderer In-Reply-To: References: <8d819ad0-342b-15cb-8afc-bdda5da52a5d@oracle.com> <5480c2b9-a8fd-bc42-6e75-1b17c129dd59@oracle.com> <57A11FEB.7020302@oracle.com> <62ab4e4f-a035-59b8-7fa7-2c32511076ba@oracle.com> <303caadc-cacd-7ec9-31f7-14f8e60636c5@oracle.com> Message-ID: <57A2437B.60302@oracle.com> +1 -phil On 8/3/16, 12:14 PM, Laurent Bourg?s wrote: > > Jim, > > Yes it is the only change. > > Phil, is it ok for you ? > > Thanks, > Laurent > > Le 3 ao?t 2016 8:56 PM, "Jim Graham" > a ?crit : > > > > If that's the only change then it looks good to me... > > > > ...jim > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Aug 3 20:37:50 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 4 Aug 2016 06:37:50 +1000 Subject: [OpenJDK 2D-Dev] RFR: JDK-8163102: Fix headless only configuration option In-Reply-To: References: Message-ID: <5266d499-2d2c-6d8b-81eb-a459568efe4b@oracle.com> Hi Erik, On 4/08/2016 1:04 AM, Erik Joelsson wrote: > Hello, > > The current --disable-headful option is weird. Even worse, it doesn't > work since the makefiles still uses the legacy BUILD_HEADLESS_ONLY > variable, which configure never touches. The confusion around that variable due to its legacy always makes me worried that something is misunderstood. It was originally to deal with a build platform that had no headful support (no X11 libs and headers etc) and so could not build headful no matter what. The flag but not the functionality was carried into the new build system. What you have now is a different beast entirely. > In this patch I'm replacing the configure option with > --enable-headless-only. Default is disabled, where both headless and GUI > support is built. When enabled, only headless support is built. These > are the two variants we are ever interested in. > > On the makefile side, I redefined the variable as > ENABLE_HEADLESS_ONLY=true/false. This all seems reasonable. Though of course you have to ensure that a headless build can still execute all the necessary functionality. Even for headless some of the AWT API's still have to be available (printing support for one IIRC). > I also needed to change jawt.c to get a headless only build to actually > work. The requirement that -DJAVASE_EMBEDDED is set seems unnecessary > and unrelated to me. The JAVASE_EMBEDDED stuff has now all been removed, but that change hasn't reached dev yet. Thanks, David > Bug: https://bugs.openjdk.java.net/browse/JDK-8163102 > > Webrev: http://cr.openjdk.java.net/~erikj/8163102/webrev.01 > > /Erik > From philip.race at oracle.com Wed Aug 3 21:02:30 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 03 Aug 2016 14:02:30 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6574279: validatePage from PrinterJob returns argument under linux In-Reply-To: <5784DD01.4040309@oracle.com> References: <5784DD01.4040309@oracle.com> Message-ID: <57A25BE6.3080305@oracle.com> High-level question. Why is this not an over-ride in PSPrinterJob ? I'm afraid I did not get much past the first line of the change : 1662 MediaPrintableArea mpa = 1663 (MediaPrintableArea)getPrintService(). 1664 getDefaultAttributeValue(MediaPrintableArea.class); Read the docs for MediaPrintableArea :- --- To query for the printable area, a client must supply a suitable context. Without specifying at the very least the size of the media being used no meaningful value for printable area can be obtained. --- .. not to mention you assume a non-null return. and then you use new Paper() .. which is a constructor which knows nothing about the printer. It is *speced* to return US letter with one inch margins. Another reason why this seems like it should be a sub-class over-ride. Also this looks wrong --- 1672 if ((imgX*2) + imgWid > wid) { 1673 imgWid = wid - imgX*2; 1674 } You can't assume equal margins. -phil. On 7/12/16, 5:05 AM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix for an issue where it is seen that if user sets > invalid imageablearea via Paper.setImageableArea and > then calls PrinterJob.validatePage() in linux, then it does not get a > valid pageformat > > Bug: https://bugs.openjdk.java.net/browse/JDK-6574279 > webrev: http://cr.openjdk.java.net/~psadhukhan/6574279/webrev.00/ > > Fix is to check for margin as noted via CUPS ppdPageSize() and then > calculate to find the valid margin in validatePaper() > similar to what we do in native validatePaper() in windows. > > Regards > Prasanta From brian.burkhalter at oracle.com Wed Aug 3 22:58:02 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 3 Aug 2016 15:58:02 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8155960: TIFF javadoc contains HTML entities inside {@code} tags Message-ID: <31F85148-81E0-4208-883E-97DA4421AB69@oracle.com> Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8155960 Patch: [1] Note that the portion of this issue in javax.imageio.plugins.tiff was resolved as part of the fix for https://bugs.openjdk.java.net/browse/JDK-8149016. Thanks, Brian [1] diff --- a/src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFColorConverter.java +++ b/src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFColorConverter.java @@ -47,7 +47,7 @@ * @throws NullPointerException if {@code result} is * {@code null}. * @throws ArrayIndexOutOfBoundsException if - * {@code result.length < 3}. + * {@code result.length < 3}. */ public abstract void fromRGB(float r, float g, float b, float[] result); @@ -63,7 +63,7 @@ * @throws NullPointerException if {@code rgb} is * {@code null}. * @throws ArrayIndexOutOfBoundsException if - * {@code rgb.length < 3}. + * {@code rgb.length < 3}. */ public abstract void toRGB(float x0, float x1, float x2, float[] rgb); } --- a/src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFDecompressor.java +++ b/src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFDecompressor.java @@ -353,7 +353,7 @@ *

The pixels in the source region to be copied are * those with X coordinates of the form {@code activeSrcMinX + * k*subsampleX}, where {@code k} is an integer such - * that {@code 0 ≤ k < dstWidth}. + * that {@code 0 <= k < dstWidth}. */ protected int activeSrcMinX; @@ -365,7 +365,7 @@ *

The pixels in the source region to be copied are * those with Y coordinates of the form {@code activeSrcMinY + * k*subsampleY}, where {@code k} is an integer such - * that {@code 0 ≤ k < dstHeight}. + * that {@code 0 <= k < dstHeight}. */ protected int activeSrcMinY; -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Aug 3 23:33:59 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 03 Aug 2016 16:33:59 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8155960: TIFF javadoc contains HTML entities inside {@code} tags In-Reply-To: <31F85148-81E0-4208-883E-97DA4421AB69@oracle.com> References: <31F85148-81E0-4208-883E-97DA4421AB69@oracle.com> Message-ID: <57A27F67.3050909@oracle.com> +1 (and one reviewer is enough for this minor doc fix). -phil. On 8/3/16, 3:58 PM, Brian Burkhalter wrote: > Please review at your convenience. > > Issue:https://bugs.openjdk.java.net/browse/JDK-8155960 > Patch:[1] > > Note that the portion of this issue in javax.imageio.plugins.tiff was > resolved as part of the fix for > https://bugs.openjdk.java.net/browse/JDK-8149016. > > Thanks, > > Brian > > [1] diff > > --- > a/src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFColorConverter.java > +++ > b/src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFColorConverter.java > @@ -47,7 +47,7 @@ > * @throws NullPointerException if {@code result} is > * {@code null}. > * @throws ArrayIndexOutOfBoundsException if > - * {@code result.length < 3}. > + * {@code result.length < 3}. > */ > public abstract void fromRGB(float r, float g, float b, float[] > result); > > > @@ -63,7 +63,7 @@ > * @throws NullPointerException if {@code rgb} is > * {@code null}. > * @throws ArrayIndexOutOfBoundsException if > - * {@code rgb.length < 3}. > + * {@code rgb.length < 3}. > */ > public abstract void toRGB(float x0, float x1, float x2, float[] > rgb); > } > > --- > a/src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFDecompressor.java > +++ > b/src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFDecompressor.java > @@ -353,7 +353,7 @@ > *

The pixels in the source region to be copied are > * those with X coordinates of the form {@code activeSrcMinX + > * k*subsampleX}, where {@code k} is an integer such > - * that {@code 0 ≤ k < dstWidth}. > + * that {@code 0 <= k < dstWidth}. > */ > protected int activeSrcMinX; > > > @@ -365,7 +365,7 @@ > *

The pixels in the source region to be copied are > * those with Y coordinates of the form {@code activeSrcMinY + > * k*subsampleY}, where {@code k} is an integer such > - * that {@code 0 ≤ k < dstHeight}. > + * that {@code 0 <= k < dstHeight}. > */ > protected int activeSrcMinY; -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Thu Aug 4 08:24:23 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 4 Aug 2016 10:24:23 +0200 Subject: [OpenJDK 2D-Dev] RFR: JDK-8163102: Fix headless only configuration option In-Reply-To: <5266d499-2d2c-6d8b-81eb-a459568efe4b@oracle.com> References: <5266d499-2d2c-6d8b-81eb-a459568efe4b@oracle.com> Message-ID: <2a7a8cee-d121-06da-5aa5-dfba4992e5c4@oracle.com> Hello, New webrev: http://cr.openjdk.java.net/~erikj/8163102/webrev.02 The difference is in libraries.m4, where there was still a reference to SUPPORT_HEADFUL. I tried building a headless configuration without X11 configured, but it unfortunately failed. libawt.so still requires X11 headers to compile. I suppose we could differentiate between headers and libs being available, but I will leave that for another time. On 2016-08-03 22:37, David Holmes wrote: > Hi Erik, > > The confusion around that variable due to its legacy always makes me > worried that something is misunderstood. It was originally to deal > with a build platform that had no headful support (no X11 libs and > headers etc) and so could not build headful no matter what. The flag > but not the functionality was carried into the new build system. What > you have now is a different beast entirely. > Right, but unfortunately it still requires X11 headers as said above, and tracing through history, this must always have been true for a long time. >> In this patch I'm replacing the configure option with >> --enable-headless-only. Default is disabled, where both headless and GUI >> support is built. When enabled, only headless support is built. These >> are the two variants we are ever interested in. >> >> On the makefile side, I redefined the variable as >> ENABLE_HEADLESS_ONLY=true/false. > > This all seems reasonable. Though of course you have to ensure that a > headless build can still execute all the necessary functionality. Even > for headless some of the AWT API's still have to be available > (printing support for one IIRC). As far as I can see, this should be fine, but perhaps someone from 2d/awt should comment. This is what --enable-headless-only removes: * policytool - a gui application which does not seem to have any functionality without a gui * appletviewer - seems pointless without a gui * libsplashscreen - seems pointless without a gui * libawt_xawt - the X11 specific parts of awt that links to libX11 * A placeholder libjawt is built which just doesn't do anything These are also exactly the libraries and executables that link to X11. Regardless of if we can use this option at Oracle, I believe it's a good fix for OpenJDK. > >> I also needed to change jawt.c to get a headless only build to actually >> work. The requirement that -DJAVASE_EMBEDDED is set seems unnecessary >> and unrelated to me. > > The JAVASE_EMBEDDED stuff has now all been removed, but that change > hasn't reached dev yet. > Right, and that change conflicts with mine since it also removed the possibility of building a "headless" libjawt. This means I should hold on this change until hs gets into dev. /Erik From david.holmes at oracle.com Thu Aug 4 11:24:23 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 4 Aug 2016 21:24:23 +1000 Subject: [OpenJDK 2D-Dev] RFR: JDK-8163102: Fix headless only configuration option In-Reply-To: <2a7a8cee-d121-06da-5aa5-dfba4992e5c4@oracle.com> References: <5266d499-2d2c-6d8b-81eb-a459568efe4b@oracle.com> <2a7a8cee-d121-06da-5aa5-dfba4992e5c4@oracle.com> Message-ID: On 4/08/2016 6:24 PM, Erik Joelsson wrote: > Hello, > > New webrev: http://cr.openjdk.java.net/~erikj/8163102/webrev.02 > > The difference is in libraries.m4, where there was still a reference to > SUPPORT_HEADFUL. I tried building a headless configuration without X11 > configured, but it unfortunately failed. libawt.so still requires X11 > headers to compile. I suppose we could differentiate between headers and > libs being available, but I will leave that for another time. Ok. > On 2016-08-03 22:37, David Holmes wrote: >> Hi Erik, >> >> The confusion around that variable due to its legacy always makes me >> worried that something is misunderstood. It was originally to deal >> with a build platform that had no headful support (no X11 libs and >> headers etc) and so could not build headful no matter what. The flag >> but not the functionality was carried into the new build system. What >> you have now is a different beast entirely. >> > Right, but unfortunately it still requires X11 headers as said above, > and tracing through history, this must always have been true for a long > time. >>> In this patch I'm replacing the configure option with >>> --enable-headless-only. Default is disabled, where both headless and GUI >>> support is built. When enabled, only headless support is built. These >>> are the two variants we are ever interested in. >>> >>> On the makefile side, I redefined the variable as >>> ENABLE_HEADLESS_ONLY=true/false. >> >> This all seems reasonable. Though of course you have to ensure that a >> headless build can still execute all the necessary functionality. Even >> for headless some of the AWT API's still have to be available >> (printing support for one IIRC). > As far as I can see, this should be fine, but perhaps someone from > 2d/awt should comment. This is what --enable-headless-only removes: > > * policytool - a gui application which does not seem to have any > functionality without a gui > * appletviewer - seems pointless without a gui > * libsplashscreen - seems pointless without a gui > * libawt_xawt - the X11 specific parts of awt that links to libX11 > * A placeholder libjawt is built which just doesn't do anything > > These are also exactly the libraries and executables that link to X11. > Regardless of if we can use this option at Oracle, I believe it's a good > fix for OpenJDK. > >> >>> I also needed to change jawt.c to get a headless only build to actually >>> work. The requirement that -DJAVASE_EMBEDDED is set seems unnecessary >>> and unrelated to me. >> >> The JAVASE_EMBEDDED stuff has now all been removed, but that change >> hasn't reached dev yet. >> > Right, and that change conflicts with mine since it also removed the > possibility of building a "headless" libjawt. This means I should hold > on this change until hs gets into dev. I'm not sure when my changes will hit jdk9/dev unfortunately. Otherwise if you push this Alejandro will have to resolve the conflict in jdk9/hs. David > /Erik From christoph.langer at sap.com Thu Aug 4 11:49:08 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 4 Aug 2016 11:49:08 +0000 Subject: [OpenJDK 2D-Dev] RFR(XS): 8163177: Fix for 8152971 breaks builds with VS2010 Message-ID: <4a4fbcfd7c3441a8bbda54c9ed8a4e3b@DEWDFE13DE11.global.corp.sap> Hi, please review this little fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8163177 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8163177.1/ The changes for https://bugs.openjdk.java.net/browse/JDK-8152971 break the build with older Microsoft compilers, e.g. MS Visual Studio 2010 and this can be fixed quite easily. Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Thu Aug 4 11:55:47 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 4 Aug 2016 04:55:47 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8160455 : KSS : class.forName issue in TIFFImageMetadata.java Message-ID: Hi, Please review the following fix in JDK9 at your convenience: Bug : https://bugs.openjdk.java.net/browse/JDK-8160455 Webrev : http://cr.openjdk.java.net/~jdv/8160455/webrev.00/ Root cause : We are directly getting string present in XML DOM tree from attribute "tagSets" and creating class from it using class.forName(). XML DOM tree string can be an invalid also which we don't check. Solution : Verify whether the string from XML DOM tree maps to any of the subclasses of "TIFFTagSet" before initializing the class using isAssignableFrom(). This adds tighter check before initializing the class from XML DOM tree string. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Thu Aug 4 12:15:32 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 4 Aug 2016 17:45:32 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6574279: validatePage from PrinterJob returns argument under linux In-Reply-To: <57A25BE6.3080305@oracle.com> References: <5784DD01.4040309@oracle.com> <57A25BE6.3080305@oracle.com> Message-ID: <57A331E4.8000907@oracle.com> I will override in PSPrinterJob but 1662 MediaPrintableArea mpa = 1663 (MediaPrintableArea)getPrintService(). 1664 getDefaultAttributeValue(MediaPrintableArea.class); is returning imageable area of default media of chosen printer from CUPS [ all supported media printable area is obtained from CUPSPrinter#getPageSizes(printer) & then initMedia() populates cupsMediaPrintables which is returned in getMediaPrintableArea()] as IPPPrintService#getDefaultAttributeValue() does ---------- if (category == MediaPrintableArea.class) { MediaPrintableArea[] mpas; if ((cps != null) && ((mpas = *cps.getMediaPrintableArea()*) != null)) { if (defaultMediaIndex == -1) { // initializes value of defaultMediaIndex getDefaultAttributeValue(Media.class); } return mpas[*defaultMediaIndex*]; } -------------- by which mpas[defaultMediaIndex] returns default media printable area. In else block, we instantiate mpa of Letter for US locale and A4 for other locales so I was not checking for null as in both if and else block , I was getting MediaPrintableArea instance. Regarding considering equal margins, I am not sure if there was any way I could get right and left margin separately. Please let me know if there is any way you know of. Regards Prasanta On 8/4/2016 2:32 AM, Philip Race wrote: > High-level question. Why is this not an over-ride in PSPrinterJob ? > > > I'm afraid I did not get much past the first line of the change : > 1662 MediaPrintableArea mpa = > 1663 (MediaPrintableArea)getPrintService(). > 1664 getDefaultAttributeValue(MediaPrintableArea.class); > > Read the docs for MediaPrintableArea :- > --- > To query for the printable area, a client must supply a suitable context. > Without specifying at the very least the size of the media being used > no meaningful value for printable area can be obtained. > --- > > .. not to mention you assume a non-null return. > > and then you use new Paper() .. which is a constructor which > knows nothing about the printer. It is *speced* to return > US letter with one inch margins. > > Another reason why this seems like it should be a sub-class over-ride. > > > Also this looks wrong --- > 1672 if ((imgX*2) + imgWid > wid) { > 1673 imgWid = wid - imgX*2; > 1674 } > > You can't assume equal margins. > > -phil. > > On 7/12/16, 5:05 AM, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a fix for an issue where it is seen that if user sets >> invalid imageablearea via Paper.setImageableArea and >> then calls PrinterJob.validatePage() in linux, then it does not get a >> valid pageformat >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-6574279 >> webrev: http://cr.openjdk.java.net/~psadhukhan/6574279/webrev.00/ >> >> Fix is to check for margin as noted via CUPS ppdPageSize() and then >> calculate to find the valid margin in validatePaper() >> similar to what we do in native validatePaper() in windows. >> >> Regards >> Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From prahalad.kumar.narayanan at oracle.com Thu Aug 4 12:23:52 2016 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Thu, 4 Aug 2016 05:23:52 -0700 (PDT) Subject: [OpenJDK 2D-Dev] RFR(XS): 8163177: Fix for 8152971 breaks builds with VS2010 In-Reply-To: <4a4fbcfd7c3441a8bbda54c9ed8a4e3b@DEWDFE13DE11.global.corp.sap> References: <4a4fbcfd7c3441a8bbda54c9ed8a4e3b@DEWDFE13DE11.global.corp.sap> Message-ID: Hi Christoph The changes are correct. +1 Previously, the changes were built with JPRT and it reported successful build. Looks like JPRT system uses latest VS compilers. Thanks Have a good day Prahalad N. From: Langer, Christoph [mailto:christoph.langer at sap.com] Sent: Thursday, August 04, 2016 5:19 PM To: 2d-dev at openjdk.java.net Cc: Volker Simonis; Prahalad Kumar Narayanan Subject: RFR(XS): 8163177: Fix for 8152971 breaks builds with VS2010 Hi, please review this little fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8163177 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8163177.1/ The changes for https://bugs.openjdk.java.net/browse/JDK-8152971 break the build with older Microsoft compilers, e.g. MS Visual Studio 2010 and this can be fixed quite easily. Thanks Christoph From volker.simonis at gmail.com Thu Aug 4 13:46:23 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 4 Aug 2016 15:46:23 +0200 Subject: [OpenJDK 2D-Dev] RFR(XS): 8163177: Fix for 8152971 breaks builds with VS2010 In-Reply-To: <4a4fbcfd7c3441a8bbda54c9ed8a4e3b@DEWDFE13DE11.global.corp.sap> References: <4a4fbcfd7c3441a8bbda54c9ed8a4e3b@DEWDFE13DE11.global.corp.sap> Message-ID: Hi Christoph, the change looks good. Thanks for fixing it. Regards, Volker On Thu, Aug 4, 2016 at 1:49 PM, Langer, Christoph wrote: > Hi, > > > > please review this little fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163177 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8163177.1/ > > > > The changes for https://bugs.openjdk.java.net/browse/JDK-8152971 break the > build with older Microsoft compilers, e.g. MS Visual Studio 2010 and this > can be fixed quite easily. > > > > Thanks > > Christoph > > From christoph.langer at sap.com Thu Aug 4 14:04:37 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 4 Aug 2016 14:04:37 +0000 Subject: [OpenJDK 2D-Dev] RFR(XS): 8163177: Fix for 8152971 breaks builds with VS2010 In-Reply-To: References: <4a4fbcfd7c3441a8bbda54c9ed8a4e3b@DEWDFE13DE11.global.corp.sap> Message-ID: Thanks Prahalad and Volker. I pushed: http://hg.openjdk.java.net/jdk9/client/jdk/rev/bf97a92e5de6 And yes, I think JPRT is using higher level compilers - but we at SAP like to be able to also build with older compiler versions, if possible. :) Best regards Christoph > -----Original Message----- > From: Prahalad Kumar Narayanan > [mailto:prahalad.kumar.narayanan at oracle.com] > Sent: Donnerstag, 4. August 2016 14:24 > To: Langer, Christoph ; 2d-dev at openjdk.java.net > Cc: Volker Simonis > Subject: RE: RFR(XS): 8163177: Fix for 8152971 breaks builds with VS2010 > > Hi Christoph > > The changes are correct. +1 > > Previously, the changes were built with JPRT and it reported successful build. > Looks like JPRT system uses latest VS compilers. > > Thanks > Have a good day > > Prahalad N. > > > From: Langer, Christoph [mailto:christoph.langer at sap.com] > Sent: Thursday, August 04, 2016 5:19 PM > To: 2d-dev at openjdk.java.net > Cc: Volker Simonis; Prahalad Kumar Narayanan > Subject: RFR(XS): 8163177: Fix for 8152971 breaks builds with VS2010 > > Hi, > > please review this little fix: > Bug: https://bugs.openjdk.java.net/browse/JDK-8163177 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8163177.1/ > > The changes for https://bugs.openjdk.java.net/browse/JDK-8152971 break the > build with older Microsoft compilers, e.g. MS Visual Studio 2010 and this can be > fixed quite easily. > > Thanks > Christoph From philip.race at oracle.com Thu Aug 4 14:22:42 2016 From: philip.race at oracle.com (Philip Race) Date: Thu, 04 Aug 2016 07:22:42 -0700 Subject: [OpenJDK 2D-Dev] RFR(XS): 8163177: Fix for 8152971 breaks builds with VS2010 In-Reply-To: References: <4a4fbcfd7c3441a8bbda54c9ed8a4e3b@DEWDFE13DE11.global.corp.sap> Message-ID: <57A34FB2.5030004@oracle.com> We need to ensure it always builds with the "official" compiler of the day, but at the same time, it should also build with the widest possible array of compilers. Not just on Windows. So fixes like this are welcome. -phil. On 8/4/16, 7:04 AM, Langer, Christoph wrote: > Thanks Prahalad and Volker. > > I pushed: http://hg.openjdk.java.net/jdk9/client/jdk/rev/bf97a92e5de6 > > And yes, I think JPRT is using higher level compilers - but we at SAP like to be able to also build with older compiler versions, if possible. :) > > Best regards > Christoph > > >> -----Original Message----- >> From: Prahalad Kumar Narayanan >> [mailto:prahalad.kumar.narayanan at oracle.com] >> Sent: Donnerstag, 4. August 2016 14:24 >> To: Langer, Christoph; 2d-dev at openjdk.java.net >> Cc: Volker Simonis >> Subject: RE: RFR(XS): 8163177: Fix for 8152971 breaks builds with VS2010 >> >> Hi Christoph >> >> The changes are correct. +1 >> >> Previously, the changes were built with JPRT and it reported successful build. >> Looks like JPRT system uses latest VS compilers. >> >> Thanks >> Have a good day >> >> Prahalad N. >> >> >> From: Langer, Christoph [mailto:christoph.langer at sap.com] >> Sent: Thursday, August 04, 2016 5:19 PM >> To: 2d-dev at openjdk.java.net >> Cc: Volker Simonis; Prahalad Kumar Narayanan >> Subject: RFR(XS): 8163177: Fix for 8152971 breaks builds with VS2010 >> >> Hi, >> >> please review this little fix: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8163177 >> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8163177.1/ >> >> The changes for https://bugs.openjdk.java.net/browse/JDK-8152971 break the >> build with older Microsoft compilers, e.g. MS Visual Studio 2010 and this can be >> fixed quite easily. >> >> Thanks >> Christoph From philip.race at oracle.com Thu Aug 4 15:31:44 2016 From: philip.race at oracle.com (Philip Race) Date: Thu, 04 Aug 2016 08:31:44 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8160455 : KSS : class.forName issue in TIFFImageMetadata.java In-Reply-To: References: Message-ID: <57A35FE0.3040208@oracle.com> +1 -phil On 8/4/16, 4:55 AM, Jayathirth D V wrote: > > Hi, > > Please review the following fix in JDK9 at your convenience: > > Bug : https://bugs.openjdk.java.net/browse/JDK-8160455 > > Webrev : http://cr.openjdk.java.net/~jdv/8160455/webrev.00/ > > > Root cause : We are directly getting string present in XML DOM tree > from attribute "tagSets" and creating class from it using > class.forName(). XML DOM tree string can be an invalid also which we > don't check. > > Solution : Verify whether the string from XML DOM tree maps to any of > the subclasses of "TIFFTagSet" before initializing the class using > isAssignableFrom(). This adds tighter check before initializing the > class from XML DOM tree string. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Aug 4 15:35:46 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 4 Aug 2016 08:35:46 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8160455 : KSS : class.forName issue in TIFFImageMetadata.java In-Reply-To: <57A35FE0.3040208@oracle.com> References: <57A35FE0.3040208@oracle.com> Message-ID: <1E5D7B13-BB02-42D8-83E8-7742C67820E6@oracle.com> +2 Brian On Aug 4, 2016, at 8:31 AM, Philip Race wrote: > +1 > > -phil > > On 8/4/16, 4:55 AM, Jayathirth D V wrote: >> >> Hi, >> >> Please review the following fix in JDK9 at your convenience: >> >> Bug :https://bugs.openjdk.java.net/browse/JDK-8160455 >> Webrev :http://cr.openjdk.java.net/~jdv/8160455/webrev.00/ >> >> Root cause : We are directly getting string present in XML DOM tree from attribute ?tagSets? and creating class from it using class.forName(). XML DOM tree string can be an invalid also which we don?t check. >> Solution : Verify whether the string from XML DOM tree maps to any of the subclasses of ?TIFFTagSet? before initializing the class using isAssignableFrom(). This adds tighter check before initializing the class from XML DOM tree string. >> >> Thanks, >> Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Aug 4 15:37:29 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 4 Aug 2016 18:37:29 +0300 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8160455 : KSS : class.forName issue in TIFFImageMetadata.java In-Reply-To: <57A35FE0.3040208@oracle.com> References: <57A35FE0.3040208@oracle.com> Message-ID: Is it possible that TIFFTagSet will be extended by the user and passed via xml? In this case will we able to load the user's class via forName? On 04.08.16 18:31, Philip Race wrote: > +1 > > -phil > > On 8/4/16, 4:55 AM, Jayathirth D V wrote: >> >> Hi, >> >> >> >> Please review the following fix in JDK9 at your convenience: >> >> >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8160455 >> >> Webrev : http://cr.openjdk.java.net/~jdv/8160455/webrev.00/ >> >> >> >> >> Root cause : We are directly getting string present in XML DOM tree >> from attribute ?tagSets? and creating class from it using >> class.forName(). XML DOM tree string can be an invalid also which we >> don?t check. >> >> Solution : Verify whether the string from XML DOM tree maps to any of >> the subclasses of ?TIFFTagSet? before initializing the class using >> isAssignableFrom(). This adds tighter check before initializing the >> class from XML DOM tree string. >> >> >> >> Thanks, >> >> Jay >> -- Best regards, Sergey. From brian.burkhalter at oracle.com Thu Aug 4 16:01:29 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 4 Aug 2016 09:01:29 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8160455 : KSS : class.forName issue in TIFFImageMetadata.java In-Reply-To: References: <57A35FE0.3040208@oracle.com> Message-ID: <73E69F78-AD31-473A-82CB-AD96F6D7E67D@oracle.com> That was the original intent of the design way back when, but it is unknown as to whether anyone actually availed themselves of this capability. Brian On Aug 4, 2016, at 8:37 AM, Sergey Bylokhov wrote: > Is it possible that TIFFTagSet will be extended by the user and passed via xml? In this case will we able to load the user's class via forName? -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Aug 4 16:35:40 2016 From: philip.race at oracle.com (Philip Race) Date: Thu, 04 Aug 2016 09:35:40 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8160455 : KSS : class.forName issue in TIFFImageMetadata.java In-Reply-To: <73E69F78-AD31-473A-82CB-AD96F6D7E67D@oracle.com> References: <57A35FE0.3040208@oracle.com> <73E69F78-AD31-473A-82CB-AD96F6D7E67D@oracle.com> Message-ID: <57A36EDC.3020600@oracle.com> That would not have worked anyway, would it ? Class.forName(String) was searching using the bootstrap class loader. It presumably also would not have worked when the plugin was (in the past) loaded as a standard extension either. -phil. On 8/4/16, 9:01 AM, Brian Burkhalter wrote: > That was the original intent of the design way back when, but it is > unknown as to whether anyone actually availed themselves of this > capability. > > Brian > > On Aug 4, 2016, at 8:37 AM, Sergey Bylokhov > > wrote: > >> Is it possible that TIFFTagSet will be extended by the user and >> passed via xml? In this case will we able to load the user's class >> via forName? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Aug 4 16:37:26 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 4 Aug 2016 09:37:26 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8160455 : KSS : class.forName issue in TIFFImageMetadata.java In-Reply-To: <57A36EDC.3020600@oracle.com> References: <57A35FE0.3040208@oracle.com> <73E69F78-AD31-473A-82CB-AD96F6D7E67D@oracle.com> <57A36EDC.3020600@oracle.com> Message-ID: <8236AD57-236E-41B3-89F2-5CEDE61AC1E2@oracle.com> Perhaps not. I can?t recall whether it was tested and I doubt that anyone tried to use it. The tag sets we provide by default are pretty comprehensive. Brian On Aug 4, 2016, at 9:35 AM, Philip Race wrote: > That would not have worked anyway, would it ? > Class.forName(String) was searching using the bootstrap class loader. > > It presumably also would not have worked when the plugin was > (in the past) loaded as a standard extension either. > > -phil. > > On 8/4/16, 9:01 AM, Brian Burkhalter wrote: >> >> That was the original intent of the design way back when, but it is unknown as to whether anyone actually availed themselves of this capability. >> >> Brian >> >> On Aug 4, 2016, at 8:37 AM, Sergey Bylokhov wrote: >> >>> Is it possible that TIFFTagSet will be extended by the user and passed via xml? In this case will we able to load the user's class via forName? >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Aug 4 16:40:11 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 4 Aug 2016 19:40:11 +0300 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8160455 : KSS : class.forName issue in TIFFImageMetadata.java In-Reply-To: <57A36EDC.3020600@oracle.com> References: <57A35FE0.3040208@oracle.com> <73E69F78-AD31-473A-82CB-AD96F6D7E67D@oracle.com> <57A36EDC.3020600@oracle.com> Message-ID: <573d4221-71e6-41e7-a1d9-3d5808a5cda0@oracle.com> On 04.08.16 19:35, Philip Race wrote: > That would not have worked anyway, would it ? > Class.forName(String) was searching using the bootstrap class loader. Inside jdk it does not work, but should it? I do not know. > > It presumably also would not have worked when the plugin was > (in the past) loaded as a standard extension either. I am not familiar with extension loader, but probably it was possible to load them from the application class loader? > On 8/4/16, 9:01 AM, Brian Burkhalter wrote: >> That was the original intent of the design way back when, but it is >> unknown as to whether anyone actually availed themselves of this >> capability. >> >> Brian >> >> On Aug 4, 2016, at 8:37 AM, Sergey Bylokhov >> > wrote: >> >>> Is it possible that TIFFTagSet will be extended by the user and >>> passed via xml? In this case will we able to load the user's class >>> via forName? >> -- Best regards, Sergey. From philip.race at oracle.com Thu Aug 4 16:56:42 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 04 Aug 2016 09:56:42 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8160455 : KSS : class.forName issue in TIFFImageMetadata.java In-Reply-To: <573d4221-71e6-41e7-a1d9-3d5808a5cda0@oracle.com> References: <57A35FE0.3040208@oracle.com> <73E69F78-AD31-473A-82CB-AD96F6D7E67D@oracle.com> <57A36EDC.3020600@oracle.com> <573d4221-71e6-41e7-a1d9-3d5808a5cda0@oracle.com> Message-ID: <57A373CA.4010303@oracle.com> On 08/04/2016 09:40 AM, Sergey Bylokhov wrote: > On 04.08.16 19:35, Philip Race wrote: >> That would not have worked anyway, would it ? >> Class.forName(String) was searching using the bootstrap class loader. > > Inside jdk it does not work, but should it? I do not know. > >> >> It presumably also would not have worked when the plugin was >> (in the past) loaded as a standard extension either. > > I am not familiar with extension loader, but probably it was possible > to load them from the application class loader? you could have put it on the application class path but a common way this was installed was in jre/lib/ext .. -phil. > >> On 8/4/16, 9:01 AM, Brian Burkhalter wrote: >>> That was the original intent of the design way back when, but it is >>> unknown as to whether anyone actually availed themselves of this >>> capability. >>> >>> Brian >>> >>> On Aug 4, 2016, at 8:37 AM, Sergey Bylokhov >>> > wrote: >>> >>>> Is it possible that TIFFTagSet will be extended by the user and >>>> passed via xml? In this case will we able to load the user's class >>>> via forName? >>> > > From prasanta.sadhukhan at oracle.com Fri Aug 5 10:20:02 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 5 Aug 2016 15:50:02 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6574279: validatePage from PrinterJob returns argument under linux In-Reply-To: <57A331E4.8000907@oracle.com> References: <5784DD01.4040309@oracle.com> <57A25BE6.3080305@oracle.com> <57A331E4.8000907@oracle.com> Message-ID: <57A46852.4050801@oracle.com> On 8/4/2016 5:45 PM, Prasanta Sadhukhan wrote: > I will override in PSPrinterJob but > 1662 MediaPrintableArea mpa = > 1663 (MediaPrintableArea)getPrintService(). > 1664 getDefaultAttributeValue(MediaPrintableArea.class); > > is returning imageable area of default media of chosen printer from > CUPS [ all supported media printable area is obtained from > CUPSPrinter#getPageSizes(printer) & then initMedia() populates > cupsMediaPrintables which is returned in getMediaPrintableArea()] > as IPPPrintService#getDefaultAttributeValue() does > ---------- > if (category == MediaPrintableArea.class) { > MediaPrintableArea[] mpas; > if ((cps != null) && > ((mpas = *cps.getMediaPrintableArea()*) != null)) { > if (defaultMediaIndex == -1) { > // initializes value of defaultMediaIndex > getDefaultAttributeValue(Media.class); > } > return mpas[*defaultMediaIndex*]; > } > -------------- > by which mpas[defaultMediaIndex] returns default media printable area. > In else block, we instantiate mpa of Letter for US locale and A4 for > other locales so I was not checking for null as in both if and else > block , I was getting MediaPrintableArea instance. > > Regarding considering equal margins, I am not sure if there was any > way I could get right and left margin separately. > Please let me know if there is any way you know of. I have modified to do the change in PSPrinterJob. Regarding the equal margin, we do the same in http://hg.openjdk.java.net/jdk9/client/jdk/file/abb2a39948fe/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java#l688 http://cr.openjdk.java.net/~psadhukhan/6574279/webrev.01/ Regards Prasanta > > Regards > Prasanta > On 8/4/2016 2:32 AM, Philip Race wrote: >> High-level question. Why is this not an over-ride in PSPrinterJob ? >> >> >> I'm afraid I did not get much past the first line of the change : >> 1662 MediaPrintableArea mpa = >> 1663 (MediaPrintableArea)getPrintService(). >> 1664 getDefaultAttributeValue(MediaPrintableArea.class); >> >> Read the docs for MediaPrintableArea :- >> --- >> To query for the printable area, a client must supply a suitable >> context. >> Without specifying at the very least the size of the media being used >> no meaningful value for printable area can be obtained. >> --- >> >> .. not to mention you assume a non-null return. >> >> and then you use new Paper() .. which is a constructor which >> knows nothing about the printer. It is *speced* to return >> US letter with one inch margins. >> >> Another reason why this seems like it should be a sub-class over-ride. >> >> >> Also this looks wrong --- >> 1672 if ((imgX*2) + imgWid > wid) { >> 1673 imgWid = wid - imgX*2; >> 1674 } >> >> You can't assume equal margins. >> >> -phil. >> >> On 7/12/16, 5:05 AM, Prasanta Sadhukhan wrote: >>> Hi All, >>> >>> Please review a fix for an issue where it is seen that if user sets >>> invalid imageablearea via Paper.setImageableArea and >>> then calls PrinterJob.validatePage() in linux, then it does not get >>> a valid pageformat >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-6574279 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/6574279/webrev.00/ >>> >>> Fix is to check for margin as noted via CUPS ppdPageSize() and then >>> calculate to find the valid margin in validatePaper() >>> similar to what we do in native validatePaper() in windows. >>> >>> Regards >>> Prasanta > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Fri Aug 5 13:13:58 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 5 Aug 2016 16:13:58 +0300 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8160455 : KSS : class.forName issue in TIFFImageMetadata.java In-Reply-To: <57A373CA.4010303@oracle.com> References: <57A35FE0.3040208@oracle.com> <73E69F78-AD31-473A-82CB-AD96F6D7E67D@oracle.com> <57A36EDC.3020600@oracle.com> <573d4221-71e6-41e7-a1d9-3d5808a5cda0@oracle.com> <57A373CA.4010303@oracle.com> Message-ID: On 04.08.16 19:56, Phil Race wrote: > you could have put it on the application class path but a common way > this was installed was in jre/lib/ext .. If everybody agreed it is an ok, then the fix looks fine. > > -phil. > >> >>> On 8/4/16, 9:01 AM, Brian Burkhalter wrote: >>>> That was the original intent of the design way back when, but it is >>>> unknown as to whether anyone actually availed themselves of this >>>> capability. >>>> >>>> Brian >>>> >>>> On Aug 4, 2016, at 8:37 AM, Sergey Bylokhov >>>> > wrote: >>>> >>>>> Is it possible that TIFFTagSet will be extended by the user and >>>>> passed via xml? In this case will we able to load the user's class >>>>> via forName? >>>> >> >> > -- Best regards, Sergey. From brian.burkhalter at oracle.com Fri Aug 5 15:44:55 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 5 Aug 2016 08:44:55 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8160455 : KSS : class.forName issue in TIFFImageMetadata.java In-Reply-To: References: <57A35FE0.3040208@oracle.com> <73E69F78-AD31-473A-82CB-AD96F6D7E67D@oracle.com> <57A36EDC.3020600@oracle.com> <573d4221-71e6-41e7-a1d9-3d5808a5cda0@oracle.com> <57A373CA.4010303@oracle.com> Message-ID: +1 On Aug 5, 2016, at 6:13 AM, Sergey Bylokhov wrote: > On 04.08.16 19:56, Phil Race wrote: >> you could have put it on the application class path but a common way >> this was installed was in jre/lib/ext .. > > If everybody agreed it is an ok, then the fix looks fine. > >> >> -phil. >> >>> >>>> On 8/4/16, 9:01 AM, Brian Burkhalter wrote: >>>>> That was the original intent of the design way back when, but it is >>>>> unknown as to whether anyone actually availed themselves of this >>>>> capability. >>>>> >>>>> Brian >>>>> >>>>> On Aug 4, 2016, at 8:37 AM, Sergey Bylokhov >>>>> > wrote: >>>>> >>>>>> Is it possible that TIFFTagSet will be extended by the user and >>>>>> passed via xml? In this case will we able to load the user's class >>>>>> via forName? >>>>> >>> >>> >> > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Aug 5 20:33:17 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 05 Aug 2016 13:33:17 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8163238: Upgrade to harfbuzz 1.3.0 in JDK 9 Message-ID: <57A4F80D.7070807@oracle.com> Bug : https://bugs.openjdk.java.net/browse/JDK-8163238 webrev: http://cr.openjdk.java.net/~prr/8163238/ Not easily reviewable .. it is basically the diff between harfbuzz 1.0.6 and 1.3 I have included all the files that we use and some of them you will see have zero changes. But I wanted all the files listed for completeness. I have built using JPRT on all platforms and run complex text tests. -phil. From brian.burkhalter at oracle.com Fri Aug 5 23:45:10 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 5 Aug 2016 16:45:10 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8150154: AIOOB Exception during sequential write of TIFF images Message-ID: <67197B64-FFC4-4226-8CCF-EB83BC10DD3D@oracle.com> Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8150154 Patch: http://cr.openjdk.java.net/~bpb/8150154/ Needed to reset the ?isRescaling? instance variable when resetting the TIFF ImageWriter. Also, the test is changed to remover @ignore and to suppress four failing image checks for TIFF only. A separate issue is filed to track fixing this separate problem later. [1] Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8163323 From philip.race at oracle.com Sat Aug 6 15:51:24 2016 From: philip.race at oracle.com (Philip Race) Date: Sat, 06 Aug 2016 08:51:24 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8150154: AIOOB Exception during sequential write of TIFF images In-Reply-To: <67197B64-FFC4-4226-8CCF-EB83BC10DD3D@oracle.com> References: <67197B64-FFC4-4226-8CCF-EB83BC10DD3D@oracle.com> Message-ID: <57A6077C.1090606@oracle.com> +1 -phil. On 8/5/16, 4:45 PM, Brian Burkhalter wrote: > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8150154 > Patch: http://cr.openjdk.java.net/~bpb/8150154/ > > Needed to reset the ?isRescaling? instance variable when resetting the TIFF ImageWriter. Also, the test is changed to remover @ignore and to suppress four failing image checks for TIFF only. A separate issue is filed to track fixing this separate problem later. [1] > > Thanks, > > Brian > > [1] https://bugs.openjdk.java.net/browse/JDK-8163323 From Sergey.Bylokhov at oracle.com Mon Aug 8 12:18:56 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 8 Aug 2016 15:18:56 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8163238: Upgrade to harfbuzz 1.3.0 in JDK 9 In-Reply-To: <57A4F80D.7070807@oracle.com> References: <57A4F80D.7070807@oracle.com> Message-ID: Looks fine. FYI: after release 1.3 there is a fix for coretext crash on osx < 10.10: https://cgit.freedesktop.org/harfbuzz/commit/?id=489acf6c3180d3726158864fa0e1adeea3c23fae On 05.08.16 23:33, Phil Race wrote: > Bug : https://bugs.openjdk.java.net/browse/JDK-8163238 > webrev: http://cr.openjdk.java.net/~prr/8163238/ > > Not easily reviewable .. it is basically the diff between harfbuzz 1.0.6 > and 1.3 > > I have included all the files that we use and some of them you will see > have zero changes. But I wanted all the files listed for completeness. > > I have built using JPRT on all platforms and run complex text tests. > > -phil. -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Mon Aug 8 12:32:08 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 8 Aug 2016 18:02:08 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8161264: RasterPrinterJob.updateAttributesWithPageFormat does redundant check In-Reply-To: <578FA471.3090106@oracle.com> References: <5745D4BB.5040900@oracle.com> <574DBF01.5080101@oracle.com> <0703d17a-9e36-94a2-93f8-80c56d0250f3@oracle.com> <5761E7A9.1010805@oracle.com> <48d2a342-851a-0a79-1443-c7bf82958f7b@oracle.com> <576AB0BD.7050506@oracle.com> <57860199.8010208@oracle.com> <578F9468.6020805@oracle.com> <578FA471.3090106@oracle.com> Message-ID: <57A87BC8.2090305@oracle.com> Gentle Reminder to review.. Regards Prasanta On 7/20/2016 9:48 PM, Prasanta Sadhukhan wrote: > No, rest of it is needed as if iw/ih is -ve, then if we do not have > this lines > if (iw <= 0) iw = (float)(page.getPaper().getWidth()/DPI) - (ix*2); > if (ih <= 0) ih = (float)(page.getPaper().getHeight()/DPI) - (iy*2); > then MediaPrintable constructor will throw IAE ((ignoring valid > ix/iy) and we end up with Java default 1" margin without even trying > to rectify iw/ih. > > So, what we did was to TRY to rectify the -eve iw/ih to proper value > first time > and even after that, if iw/ih is -ve then this webrev says that no > need to reset to 0 as having iw/ih as -ve OR 0 will result in IAE. > > Regards > Prasanta > On 7/20/2016 8:40 PM, Philip Race wrote: >> By that logic all the rest of it is unneeded too ... and >> the original bug was not a bug or the fix was not quite right. >> This is not adding up to me. >> >> -phil >> >> On 7/13/16, 1:53 AM, Prasanta Sadhukhan wrote: >>> Hi All, >>> >>> Please review a code cleanup for a redundant code introduced in the >>> below 6601097 fix via webrev.03. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161264 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8161264/webrev.00/ >>> >>> This code is redundant because irrespective of iw/ih being >>> *negative* or *0*, MediaPrintableArea constructor called just after >>> @line 692 will throw IAE which is consumed >>> and thereafter this invalid mpa value is not propagated anymore and >>> we will fallback to Java default paper margin of 1". >>> So, there is no need of checking for iw/ih for negative and set it >>> to 0 . >>> >>> Regards >>> Prasanta >>> On 6/22/2016 9:07 PM, Philip Race wrote: >>>> +1 .. they won't get any output with a zero-width imageable area >>>> but this is last ditch fix up of excessively bad values. >>>> >>>> -phil. >>>> >>>> On 6/16/16, 11:32 PM, prasanta sadhukhan wrote: >>>>> >>>>> Hi Phil, >>>>> >>>>> Ok. I have added a check for this case in which it will fall back >>>>> to default values since >>>>> if ix/iy is too large then we probably will not get anything to >>>>> print inside printable area if we have to leave same margin on the >>>>> right/bottom of the paper. >>>>> validatePaper() does not check for ix/iy too large case. >>>>> >>>>> Modified webrev >>>>> http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.03/ >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 6/16/2016 5:11 AM, Philip Race wrote: >>>>>> I did say so long as the "ix/iy" are also valid. Which means not >>>>>> just positive but that they >>>>>> are not too large. Consider >>>>>> if (iw <= 0) iw = (float)(page.getPaper().getWidth()/DPI) - (ix*2); >>>>>> >>>>>> if we have ix = 500 and iw = -20 for a paper with width 800 this >>>>>> will result >>>>>> in iw = 800 - (500*2) = -200 .. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 6/8/16, 4:42 AM, prasanta sadhukhan wrote: >>>>>>> Hi Phil, >>>>>>> >>>>>>> As discussed offline, regarding mpa modification in both >>>>>>> setAttributes() and updateAttributesWithPageFormat, I found that >>>>>>> updateAttributesWithPageFormat() will be called during >>>>>>> pageDialog() and setPrintable() >>>>>>> whereas setAttributes() will be called during print() and >>>>>>> setAttributes() called validatePaper() to validate imageable >>>>>>> values, so in that regard, setAttributes() has final say in >>>>>>> validating and updating invalid mpa values. >>>>>>> >>>>>>> Regarding bug, I found that if we have -ve width/height, >>>>>>> MediaPrintable constructor throws IAE if width/height is -ve so >>>>>>> mpa values set by user will not be added to pageAttributes (even >>>>>>> if there was valid x,y mpa values) >>>>>>> therefore we fallback to Java default paper size and so we will >>>>>>> get mpa values as ix=72 iy=72 iw=451 ih=697 in validatePaper() >>>>>>> so to avoid IAE and to use user-set valid values, I have >>>>>>> modified the code to constrain iw/ih with requested ix/iy as you >>>>>>> suggested. >>>>>>> >>>>>>> Please find the modified webrev: >>>>>>> http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.02/ >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>> On 5/31/2016 10:12 PM, Phil Race wrote: >>>>>>>> Well ... few printers can print on the entire paper. Photo >>>>>>>> printers are >>>>>>>> the ones that can do this. So Paper dimension minus the >>>>>>>> "hardware margins" >>>>>>>> are the maximum imageable width. >>>>>>>> And then supposing imageable x/y is some perfectly reasonable >>>>>>>> value like 1" each >>>>>>>> then you've set iw/ih such that even a printer with zero >>>>>>>> hardware margins has >>>>>>>> an imageable area that goes off the bottom and right off the >>>>>>>> paper. >>>>>>>> >>>>>>>> More reasonable would be to constrain iw/ih such that they work >>>>>>>> with the >>>>>>>> requested ix/iy - assuming they are also valid. >>>>>>>> >>>>>>>> If all else fails then just using the "default" set of values >>>>>>>> as if the application >>>>>>>> had not set any values would be better. >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> On 05/26/2016 03:26 AM, prasanta sadhukhan wrote: >>>>>>>>> Hi Phil, >>>>>>>>> >>>>>>>>> I got it rectified. >>>>>>>>> >>>>>>>>> Please find the modified webrev >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.01/ >>>>>>>>> >>>>>>>>> Regarding using entire width/height pf paper, I thought since >>>>>>>>> imageable width/height is invalid we should make the entire >>>>>>>>> paper as the imageable area.For invalid x,y we were making it >>>>>>>>> to paper's top/left. >>>>>>>>> Else what option do we have, should we calculate >>>>>>>>> width[height]=abs(image[width][height]) instead? >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Prasanta >>>>>>>>> On 5/25/2016 10:07 PM, Philip Race wrote: >>>>>>>>>> It seems to me that you are using the wrong units. >>>>>>>>>> You have not divided by DPI to get inches. >>>>>>>>>> >>>>>>>>>> Also I am not sure that the *entire* width/height of the >>>>>>>>>> paper is what you want here >>>>>>>>>> but that is secondary to the first issue >>>>>>>>>> >>>>>>>>>> -phil >>>>>>>>>> >>>>>>>>>> On 5/19/16, 2:59 AM, prasanta sadhukhan wrote: >>>>>>>>>>> Hi All, >>>>>>>>>>> >>>>>>>>>>> Please review a fix for jdk9 which is a continuation of the >>>>>>>>>>> fix of JDK-6543815. >>>>>>>>>>> >>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6601097 >>>>>>>>>>> webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> 6543815 fix resets the x,y to 0 if they are negative before >>>>>>>>>>> creating a MediaPrintableArea and the platform replaces it >>>>>>>>>>> with hardware margins when printing. >>>>>>>>>>> This works only if x/y is negative. >>>>>>>>>>> But, If either width/height is negative alongwith x or y, >>>>>>>>>>> then the margin is set to the java def 1 inch margin and not >>>>>>>>>>> hardware margins. >>>>>>>>>>> >>>>>>>>>>> This is because width/height -ve results in IAE in >>>>>>>>>>> MediaPrintableArea constructor and so values are ignored. >>>>>>>>>>> Added a check for -ve width/height to make sure width/height >>>>>>>>>>> are set to minimum paper width/height. >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> Prasanta >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Mon Aug 8 19:48:06 2016 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 8 Aug 2016 23:48:06 +0400 Subject: [OpenJDK 2D-Dev] [9] Review request for 8151303 [macosx] [hidpi] JButton's low-res. icon is visible when clicking on it In-Reply-To: References: <56E01777.1030202@oracle.com> <56E01DE7.9040103@oracle.com> <56E2CB4F.6040301@oracle.com> <56E3277B.3000309@oracle.com> <56E815C3.40208@oracle.com> <56E816E9.1010308@oracle.com> <56E839DC.2040904@oracle.com> <56F01921.6060305@oracle.com> <56F03E0B.1080703@oracle.com> <5734B8AB.7070908@oracle.com> <0f87bf94-13c3-160b-d1f6-c95b959299bb@oracle.com> Message-ID: <6c50a4f1-b2e6-f447-18a9-57843a6a517e@oracle.com> Just a friendly reminder. Thanks, Alexandr. On 27/06/16 22:17, Alexander Scherbatiy wrote: > > Hello, > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8151303/webrev.02 > > The fix does not use a new public API to apply filters to > multi-resolution images. > > Thanks, > Alexandr. > > > On 14/05/16 02:54, Jim Graham wrote: >> Another reason to avoid new API is that we don't have to involve the >> CCC to get this "bug fix" in... >> >> ...jim >> >> On 5/13/16 3:50 PM, Jim Graham wrote: >>> That looks very tight. The only issue I'd have is that it would be >>> better if this could be done with non-public API for >>> now - the map() methods could live on one of the sun.awt.image >>> classes or even in a Swing implementation utility class >>> and still work just fine. When we have more time to figure out how >>> we're going to handle filtering of MRIs in general >>> we can decide if this API should live on the base MRI interface. >>> >>> The only thing we'd lose is BaseMRI having an optimized >>> implementation of the map() method, but I don't think it's >>> implementation represents enough of an optimization to matter when >>> we are creating and loading dozens of images... >>> >>> ...jim >>> >>> On 5/12/16 10:08 AM, Alexander Scherbatiy wrote: >>>> >>>> Hello, >>>> >>>> Could you review the updated fix: >>>> http://cr.openjdk.java.net/~alexsch/8151303/webrev.01 >>>> >>>> There was a suggestion to postpone the fix for the issue 8152309 >>>> Seamless way of using image filters with >>>> multi-resolution images >>>> and continue with the current one: >>>> http://mail.openjdk.java.net/pipermail/2d-dev/2016-April/006766.html >>>> >>>> The new version of the fix introduces a mapper method which allows >>>> to map all resolution variants of one >>>> multi-resolution image to another: >>>> ------------ >>>> Image image = // original image >>>> Image filteredImage = MultiResolutionImage.map(image, (img) -> >>>> /* return filtered image */); >>>> ------------ >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 21/03/16 22:31, Jim Graham wrote: >>>>> We could do that for our own filters, but any random custom filter >>>>> could run into the same issue, so it might not make >>>>> sense to upgrade the existing filter mechanism to always attempt >>>>> to do MR filtering. We could either create a >>>>> parallel set of MR-aware filter mechanisms (such as the previously >>>>> suggested new method on Toolkit, or a new MR-aware >>>>> version of FilteredImageSource for instance) and leave the >>>>> existing mechanism as clearly documented as MR-unaware. >>>>> Another idea is to tag a filter with an interface that indicates >>>>> that it is MR aware? In any case, some thought needs >>>>> to be given to feeding an MR image to a filter that (potentially >>>>> or demonstrably) cannot deal with MR images. >>>>> >>>>> Alternately, we could then recommend that the old image filtering >>>>> code isn't combined with multi-resolution images. >>>>> It seems to me that the programmer is mostly in control over this >>>>> happening since they've either manually created the >>>>> MR image using the custiom MR image mechanism or they've supplied >>>>> media with multiple resolution files (i.e. "@2x"). >>>>> Is that really the case? >>>>> >>>>> Whether it is a new filtering mechanism that must be adopted or >>>>> simply declaring the old filtering mechanism as >>>>> "obsolete with respect to MR images"... >>>>> >>>>> That recommendation then "restricts forward" in that, for example, >>>>> since Swing relies on the old mechanism, Swing then >>>>> becomes "not recommended for use with MR images", or "not MR >>>>> aware". That's probably not a restriction we want to >>>>> promote so it should be viewed as a temporary restriction reality >>>>> and a bug that we'll fix soon, whether by using some >>>>> other mechanism to achieve the desired affects, or creating a new >>>>> MR-aware filtering mechanism and using it in Swing. >>>>> >>>>> Similarly, other 3rd party libraries that accept images and do >>>>> anything more than display them will have to be >>>>> upgraded as well before they become "MR aware" or "MR accepting" >>>>> or whatever term applies here... >>>>> >>>>> ...jim >>>>> >>>>> On 3/21/16 8:54 AM, Alexander Scherbatiy wrote: >>>>>> >>>>>> The one more thing is that image filters should also be updated >>>>>> to use >>>>>> them with multi-resolution images. >>>>>> For example, consider the case: >>>>>> ---------- >>>>>> Image mrImage = getMultiResolutionImage(); >>>>>> ImageProducer mriProducer = new >>>>>> FilteredImageSource(mrImage.getSource(), new CropImageFilter(0, >>>>>> 0, w, h)); >>>>>> Toolkit.getDefaultToolkit().createImage(mriProducer); >>>>>> ---------- >>>>>> >>>>>> The crop image filter applied to each resolution variant just cuts >>>>>> images with the same size. >>>>>> It seems that there should be added API which allows to set a >>>>>> scale for >>>>>> a provided image filter to be properly used with the given >>>>>> resolution >>>>>> variant. >>>>>> >>>>>> I have created a separated issue for multi-resolution images >>>>>> filtering >>>>>> support: >>>>>> JDK-8152309 Seamless way of using image filters with >>>>>> multi-resolution >>>>>> images >>>>>> https://bugs.openjdk.java.net/browse/JDK-8152309 >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> On 15/03/16 20:35, Alexander Scherbatiy wrote: >>>>>>> On 15/03/16 18:06, Sergey Bylokhov wrote: >>>>>>>> On 15.03.16 17:01, Alexander Scherbatiy wrote: >>>>>>>> >>>>>>>>> One update will be that FilteredImageSource should implement >>>>>>>>> MultiResolutionImageProducer even it is used for non >>>>>>>>> multi-resolution >>>>>>>>> images. >>>>>>>>> >>>>>>>>> The MRI can be created using two general ways: using fixed >>>>>>>>> number of >>>>>>>>> resolution variants or generating a resolution variant with >>>>>>>>> necessary >>>>>>>>> quality on demand. >>>>>>>>> >>>>>>>>> The current implementation is rely on that MRToolkitImage >>>>>>>>> contains a >>>>>>>>> fixed number of resolution variants. In this case MediaTracker >>>>>>>>> can >>>>>>>>> iterate over resolution variants and load them all. >>>>>>>>> >>>>>>>>> Using MultiResolutionImageProducer leads that MRToolkitImage >>>>>>>>> will not >>>>>>>>> know about number of resolution variants in case when they are >>>>>>>>> generated >>>>>>>>> on the fly and there will be no way to load all of them by >>>>>>>>> MediaTracker. >>>>>>>> >>>>>>>> Just an idea to thinking about, can we save this filter to the MRI >>>>>>>> itself and apply it after some resolution variant will be >>>>>>>> created on >>>>>>>> the fly? >>>>>>> >>>>>>> Do you mean that it helps to leave the code in the AquaUtils class >>>>>>> unchanged: >>>>>>> --------------- >>>>>>> 124 static Image generateLightenedImage(final Image image, >>>>>>> final >>>>>>> int percent) { >>>>>>> 125 final GrayFilter filter = new GrayFilter(true, >>>>>>> percent); >>>>>>> 126 final ImageProducer prod = new >>>>>>> FilteredImageSource(image.getSource(), filter); >>>>>>> 127 return Toolkit.getDefaultToolkit().createImage(prod); >>>>>>> 128 } >>>>>>> --------------- >>>>>>> >>>>>>> or it is just an a better way for a filtered multi-resolution >>>>>>> image >>>>>>> generation? >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>>> >>>>>>>>> >>>>>>>>> As I see, the way to solve it is only using >>>>>>>>> MRI.getResolutionVariants() >>>>>>>>> method for the MultiResolutionImageProducer creation. So the >>>>>>>>> result of >>>>>>>>> the call >>>>>>>>> toolkit.createImage(new >>>>>>>>> FilteredImageSource(mrImage.getSource(), >>>>>>>>> filter)); >>>>>>>>> will be a MRToolkitImage which is based on fixed number of >>>>>>>>> filtered >>>>>>>>> resolution variants from the original MRI. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>>> ...jim >>>>>>>>>> >>>>>>>>>> On 3/11/16 5:42 AM, Alexander Scherbatiy wrote: >>>>>>>>>>> On 09/03/16 16:58, Sergey Bylokhov wrote: >>>>>>>>>>>> Probably we should enhance >>>>>>>>>>>> ImageProducer/Tk.createImage/ImageFilter to >>>>>>>>>>>> support this functionality? It seems that the number of >>>>>>>>>>>> usage of >>>>>>>>>>>> this >>>>>>>>>>>> check "image instanceof MultiResolutionImage" will grow >>>>>>>>>>>> over time. >>>>>>>>>>> ImageProducer produces pixels for an image and is not >>>>>>>>>>> able to >>>>>>>>>>> take >>>>>>>>>>> an information about the image resolution variants. >>>>>>>>>>> >>>>>>>>>>> May be we can add Toolkit.createImage(Image image, >>>>>>>>>>> ImageFilter >>>>>>>>>>> imageFilter) method which takes MultiResolutionImage into >>>>>>>>>>> account to >>>>>>>>>>> cover the common case where filtered image is created. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>>> I think that at least our own API should support >>>>>>>>>>>> MultiResolutionImage >>>>>>>>>>>> w/o such checks, otherwise the user will need to do the same. >>>>>>>>>>>> >>>>>>>>>>>> cc 2d-dev >>>>>>>>>>>> >>>>>>>>>>>> On 09.03.16 15:30, Alexander Scherbatiy wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> >>>>>>>>>>>>> Could you review the fix: >>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8151303 >>>>>>>>>>>>> webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8151303/webrev.00 >>>>>>>>>>>>> >>>>>>>>>>>>> The AquaUtils does not take into account >>>>>>>>>>>>> MultiResolutionImage >>>>>>>>>>>>> for >>>>>>>>>>>>> selected/disabled/lightened images generation. >>>>>>>>>>>>> The fix also leaves the MultiResolutionCachedImage >>>>>>>>>>>>> check because >>>>>>>>>>>>> the >>>>>>>>>>>>> base system icon size can be differ from the requested >>>>>>>>>>>>> painted >>>>>>>>>>>>> size. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> > From philip.race at oracle.com Mon Aug 8 21:20:48 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 08 Aug 2016 14:20:48 -0700 Subject: [OpenJDK 2D-Dev] [9] Review request for 8151303 [macosx] [hidpi] JButton's low-res. icon is visible when clicking on it In-Reply-To: <6c50a4f1-b2e6-f447-18a9-57843a6a517e@oracle.com> References: <56E01777.1030202@oracle.com> <56E01DE7.9040103@oracle.com> <56E2CB4F.6040301@oracle.com> <56E3277B.3000309@oracle.com> <56E815C3.40208@oracle.com> <56E816E9.1010308@oracle.com> <56E839DC.2040904@oracle.com> <56F01921.6060305@oracle.com> <56F03E0B.1080703@oracle.com> <5734B8AB.7070908@oracle.com> <0f87bf94-13c3-160b-d1f6-c95b959299bb@oracle.com> <6c50a4f1-b2e6-f447-18a9-57843a6a517e@oracle.com> Message-ID: <57A8F7B0.5050900@oracle.com> Looks good to me .. +1 -phil. On 08/08/2016 12:48 PM, Alexander Scherbatiy wrote: > > Just a friendly reminder. > > Thanks, > Alexandr. > > On 27/06/16 22:17, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8151303/webrev.02 >> >> The fix does not use a new public API to apply filters to >> multi-resolution images. >> >> Thanks, >> Alexandr. >> >> >> On 14/05/16 02:54, Jim Graham wrote: >>> Another reason to avoid new API is that we don't have to involve the >>> CCC to get this "bug fix" in... >>> >>> ...jim >>> >>> On 5/13/16 3:50 PM, Jim Graham wrote: >>>> That looks very tight. The only issue I'd have is that it would be >>>> better if this could be done with non-public API for >>>> now - the map() methods could live on one of the sun.awt.image >>>> classes or even in a Swing implementation utility class >>>> and still work just fine. When we have more time to figure out how >>>> we're going to handle filtering of MRIs in general >>>> we can decide if this API should live on the base MRI interface. >>>> >>>> The only thing we'd lose is BaseMRI having an optimized >>>> implementation of the map() method, but I don't think it's >>>> implementation represents enough of an optimization to matter when >>>> we are creating and loading dozens of images... >>>> >>>> ...jim >>>> >>>> On 5/12/16 10:08 AM, Alexander Scherbatiy wrote: >>>>> >>>>> Hello, >>>>> >>>>> Could you review the updated fix: >>>>> http://cr.openjdk.java.net/~alexsch/8151303/webrev.01 >>>>> >>>>> There was a suggestion to postpone the fix for the issue 8152309 >>>>> Seamless way of using image filters with >>>>> multi-resolution images >>>>> and continue with the current one: >>>>> http://mail.openjdk.java.net/pipermail/2d-dev/2016-April/006766.html >>>>> >>>>> The new version of the fix introduces a mapper method which allows >>>>> to map all resolution variants of one >>>>> multi-resolution image to another: >>>>> ------------ >>>>> Image image = // original image >>>>> Image filteredImage = MultiResolutionImage.map(image, (img) -> >>>>> /* return filtered image */); >>>>> ------------ >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 21/03/16 22:31, Jim Graham wrote: >>>>>> We could do that for our own filters, but any random custom >>>>>> filter could run into the same issue, so it might not make >>>>>> sense to upgrade the existing filter mechanism to always attempt >>>>>> to do MR filtering. We could either create a >>>>>> parallel set of MR-aware filter mechanisms (such as the >>>>>> previously suggested new method on Toolkit, or a new MR-aware >>>>>> version of FilteredImageSource for instance) and leave the >>>>>> existing mechanism as clearly documented as MR-unaware. >>>>>> Another idea is to tag a filter with an interface that indicates >>>>>> that it is MR aware? In any case, some thought needs >>>>>> to be given to feeding an MR image to a filter that (potentially >>>>>> or demonstrably) cannot deal with MR images. >>>>>> >>>>>> Alternately, we could then recommend that the old image filtering >>>>>> code isn't combined with multi-resolution images. >>>>>> It seems to me that the programmer is mostly in control over this >>>>>> happening since they've either manually created the >>>>>> MR image using the custiom MR image mechanism or they've supplied >>>>>> media with multiple resolution files (i.e. "@2x"). >>>>>> Is that really the case? >>>>>> >>>>>> Whether it is a new filtering mechanism that must be adopted or >>>>>> simply declaring the old filtering mechanism as >>>>>> "obsolete with respect to MR images"... >>>>>> >>>>>> That recommendation then "restricts forward" in that, for >>>>>> example, since Swing relies on the old mechanism, Swing then >>>>>> becomes "not recommended for use with MR images", or "not MR >>>>>> aware". That's probably not a restriction we want to >>>>>> promote so it should be viewed as a temporary restriction reality >>>>>> and a bug that we'll fix soon, whether by using some >>>>>> other mechanism to achieve the desired affects, or creating a new >>>>>> MR-aware filtering mechanism and using it in Swing. >>>>>> >>>>>> Similarly, other 3rd party libraries that accept images and do >>>>>> anything more than display them will have to be >>>>>> upgraded as well before they become "MR aware" or "MR accepting" >>>>>> or whatever term applies here... >>>>>> >>>>>> ...jim >>>>>> >>>>>> On 3/21/16 8:54 AM, Alexander Scherbatiy wrote: >>>>>>> >>>>>>> The one more thing is that image filters should also be updated >>>>>>> to use >>>>>>> them with multi-resolution images. >>>>>>> For example, consider the case: >>>>>>> ---------- >>>>>>> Image mrImage = getMultiResolutionImage(); >>>>>>> ImageProducer mriProducer = new >>>>>>> FilteredImageSource(mrImage.getSource(), new CropImageFilter(0, >>>>>>> 0, w, h)); >>>>>>> Toolkit.getDefaultToolkit().createImage(mriProducer); >>>>>>> ---------- >>>>>>> >>>>>>> The crop image filter applied to each resolution variant just cuts >>>>>>> images with the same size. >>>>>>> It seems that there should be added API which allows to set a >>>>>>> scale for >>>>>>> a provided image filter to be properly used with the given >>>>>>> resolution >>>>>>> variant. >>>>>>> >>>>>>> I have created a separated issue for multi-resolution images >>>>>>> filtering >>>>>>> support: >>>>>>> JDK-8152309 Seamless way of using image filters with >>>>>>> multi-resolution >>>>>>> images >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152309 >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> On 15/03/16 20:35, Alexander Scherbatiy wrote: >>>>>>>> On 15/03/16 18:06, Sergey Bylokhov wrote: >>>>>>>>> On 15.03.16 17:01, Alexander Scherbatiy wrote: >>>>>>>>> >>>>>>>>>> One update will be that FilteredImageSource should implement >>>>>>>>>> MultiResolutionImageProducer even it is used for non >>>>>>>>>> multi-resolution >>>>>>>>>> images. >>>>>>>>>> >>>>>>>>>> The MRI can be created using two general ways: using fixed >>>>>>>>>> number of >>>>>>>>>> resolution variants or generating a resolution variant with >>>>>>>>>> necessary >>>>>>>>>> quality on demand. >>>>>>>>>> >>>>>>>>>> The current implementation is rely on that MRToolkitImage >>>>>>>>>> contains a >>>>>>>>>> fixed number of resolution variants. In this case >>>>>>>>>> MediaTracker can >>>>>>>>>> iterate over resolution variants and load them all. >>>>>>>>>> >>>>>>>>>> Using MultiResolutionImageProducer leads that >>>>>>>>>> MRToolkitImage will not >>>>>>>>>> know about number of resolution variants in case when they are >>>>>>>>>> generated >>>>>>>>>> on the fly and there will be no way to load all of them by >>>>>>>>>> MediaTracker. >>>>>>>>> >>>>>>>>> Just an idea to thinking about, can we save this filter to the >>>>>>>>> MRI >>>>>>>>> itself and apply it after some resolution variant will be >>>>>>>>> created on >>>>>>>>> the fly? >>>>>>>> >>>>>>>> Do you mean that it helps to leave the code in the AquaUtils class >>>>>>>> unchanged: >>>>>>>> --------------- >>>>>>>> 124 static Image generateLightenedImage(final Image image, >>>>>>>> final >>>>>>>> int percent) { >>>>>>>> 125 final GrayFilter filter = new GrayFilter(true, >>>>>>>> percent); >>>>>>>> 126 final ImageProducer prod = new >>>>>>>> FilteredImageSource(image.getSource(), filter); >>>>>>>> 127 return Toolkit.getDefaultToolkit().createImage(prod); >>>>>>>> 128 } >>>>>>>> --------------- >>>>>>>> >>>>>>>> or it is just an a better way for a filtered multi-resolution >>>>>>>> image >>>>>>>> generation? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> As I see, the way to solve it is only using >>>>>>>>>> MRI.getResolutionVariants() >>>>>>>>>> method for the MultiResolutionImageProducer creation. So the >>>>>>>>>> result of >>>>>>>>>> the call >>>>>>>>>> toolkit.createImage(new >>>>>>>>>> FilteredImageSource(mrImage.getSource(), >>>>>>>>>> filter)); >>>>>>>>>> will be a MRToolkitImage which is based on fixed number of >>>>>>>>>> filtered >>>>>>>>>> resolution variants from the original MRI. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>>> ...jim >>>>>>>>>>> >>>>>>>>>>> On 3/11/16 5:42 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>> On 09/03/16 16:58, Sergey Bylokhov wrote: >>>>>>>>>>>>> Probably we should enhance >>>>>>>>>>>>> ImageProducer/Tk.createImage/ImageFilter to >>>>>>>>>>>>> support this functionality? It seems that the number of >>>>>>>>>>>>> usage of >>>>>>>>>>>>> this >>>>>>>>>>>>> check "image instanceof MultiResolutionImage" will grow >>>>>>>>>>>>> over time. >>>>>>>>>>>> ImageProducer produces pixels for an image and is not >>>>>>>>>>>> able to >>>>>>>>>>>> take >>>>>>>>>>>> an information about the image resolution variants. >>>>>>>>>>>> >>>>>>>>>>>> May be we can add Toolkit.createImage(Image image, >>>>>>>>>>>> ImageFilter >>>>>>>>>>>> imageFilter) method which takes MultiResolutionImage into >>>>>>>>>>>> account to >>>>>>>>>>>> cover the common case where filtered image is created. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>>> I think that at least our own API should support >>>>>>>>>>>>> MultiResolutionImage >>>>>>>>>>>>> w/o such checks, otherwise the user will need to do the same. >>>>>>>>>>>>> >>>>>>>>>>>>> cc 2d-dev >>>>>>>>>>>>> >>>>>>>>>>>>> On 09.03.16 15:30, Alexander Scherbatiy wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Could you review the fix: >>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8151303 >>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8151303/webrev.00 >>>>>>>>>>>>>> >>>>>>>>>>>>>> The AquaUtils does not take into account >>>>>>>>>>>>>> MultiResolutionImage >>>>>>>>>>>>>> for >>>>>>>>>>>>>> selected/disabled/lightened images generation. >>>>>>>>>>>>>> The fix also leaves the MultiResolutionCachedImage >>>>>>>>>>>>>> check because >>>>>>>>>>>>>> the >>>>>>>>>>>>>> base system icon size can be differ from the requested >>>>>>>>>>>>>> painted >>>>>>>>>>>>>> size. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >> > From james.graham at oracle.com Mon Aug 8 23:49:46 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 8 Aug 2016 16:49:46 -0700 Subject: [OpenJDK 2D-Dev] [9] Review request for 8151303 [macosx] [hidpi] JButton's low-res. icon is visible when clicking on it In-Reply-To: <6c50a4f1-b2e6-f447-18a9-57843a6a517e@oracle.com> References: <56E01777.1030202@oracle.com> <56E01DE7.9040103@oracle.com> <56E2CB4F.6040301@oracle.com> <56E3277B.3000309@oracle.com> <56E815C3.40208@oracle.com> <56E816E9.1010308@oracle.com> <56E839DC.2040904@oracle.com> <56F01921.6060305@oracle.com> <56F03E0B.1080703@oracle.com> <5734B8AB.7070908@oracle.com> <0f87bf94-13c3-160b-d1f6-c95b959299bb@oracle.com> <6c50a4f1-b2e6-f447-18a9-57843a6a517e@oracle.com> Message-ID: <331c7407-0f8c-205c-f3a5-db3ac2f32398@oracle.com> Does MultiResolutionCachedImage.map() work if the Image hasn't been loaded yet (where getWidth/Height(Observer) can return -1)? Can it ever be called in a case like that? ...jim On 08/08/2016 12:48 PM, Alexander Scherbatiy wrote: > > Just a friendly reminder. > > Thanks, > Alexandr. > > On 27/06/16 22:17, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8151303/webrev.02 >> >> The fix does not use a new public API to apply filters to >> multi-resolution images. >> >> Thanks, >> Alexandr. >> >> >> On 14/05/16 02:54, Jim Graham wrote: >>> Another reason to avoid new API is that we don't have to involve the >>> CCC to get this "bug fix" in... >>> >>> ...jim >>> >>> On 5/13/16 3:50 PM, Jim Graham wrote: >>>> That looks very tight. The only issue I'd have is that it would be >>>> better if this could be done with non-public API for >>>> now - the map() methods could live on one of the sun.awt.image >>>> classes or even in a Swing implementation utility class >>>> and still work just fine. When we have more time to figure out how >>>> we're going to handle filtering of MRIs in general >>>> we can decide if this API should live on the base MRI interface. >>>> >>>> The only thing we'd lose is BaseMRI having an optimized >>>> implementation of the map() method, but I don't think it's >>>> implementation represents enough of an optimization to matter when >>>> we are creating and loading dozens of images... >>>> >>>> ...jim >>>> >>>> On 5/12/16 10:08 AM, Alexander Scherbatiy wrote: >>>>> >>>>> Hello, >>>>> >>>>> Could you review the updated fix: >>>>> http://cr.openjdk.java.net/~alexsch/8151303/webrev.01 >>>>> >>>>> There was a suggestion to postpone the fix for the issue 8152309 >>>>> Seamless way of using image filters with >>>>> multi-resolution images >>>>> and continue with the current one: >>>>> http://mail.openjdk.java.net/pipermail/2d-dev/2016-April/006766.html >>>>> >>>>> The new version of the fix introduces a mapper method which allows >>>>> to map all resolution variants of one >>>>> multi-resolution image to another: >>>>> ------------ >>>>> Image image = // original image >>>>> Image filteredImage = MultiResolutionImage.map(image, (img) -> >>>>> /* return filtered image */); >>>>> ------------ >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 21/03/16 22:31, Jim Graham wrote: >>>>>> We could do that for our own filters, but any random custom filter >>>>>> could run into the same issue, so it might not make >>>>>> sense to upgrade the existing filter mechanism to always attempt >>>>>> to do MR filtering. We could either create a >>>>>> parallel set of MR-aware filter mechanisms (such as the previously >>>>>> suggested new method on Toolkit, or a new MR-aware >>>>>> version of FilteredImageSource for instance) and leave the >>>>>> existing mechanism as clearly documented as MR-unaware. >>>>>> Another idea is to tag a filter with an interface that indicates >>>>>> that it is MR aware? In any case, some thought needs >>>>>> to be given to feeding an MR image to a filter that (potentially >>>>>> or demonstrably) cannot deal with MR images. >>>>>> >>>>>> Alternately, we could then recommend that the old image filtering >>>>>> code isn't combined with multi-resolution images. >>>>>> It seems to me that the programmer is mostly in control over this >>>>>> happening since they've either manually created the >>>>>> MR image using the custiom MR image mechanism or they've supplied >>>>>> media with multiple resolution files (i.e. "@2x"). >>>>>> Is that really the case? >>>>>> >>>>>> Whether it is a new filtering mechanism that must be adopted or >>>>>> simply declaring the old filtering mechanism as >>>>>> "obsolete with respect to MR images"... >>>>>> >>>>>> That recommendation then "restricts forward" in that, for example, >>>>>> since Swing relies on the old mechanism, Swing then >>>>>> becomes "not recommended for use with MR images", or "not MR >>>>>> aware". That's probably not a restriction we want to >>>>>> promote so it should be viewed as a temporary restriction reality >>>>>> and a bug that we'll fix soon, whether by using some >>>>>> other mechanism to achieve the desired affects, or creating a new >>>>>> MR-aware filtering mechanism and using it in Swing. >>>>>> >>>>>> Similarly, other 3rd party libraries that accept images and do >>>>>> anything more than display them will have to be >>>>>> upgraded as well before they become "MR aware" or "MR accepting" >>>>>> or whatever term applies here... >>>>>> >>>>>> ...jim >>>>>> >>>>>> On 3/21/16 8:54 AM, Alexander Scherbatiy wrote: >>>>>>> >>>>>>> The one more thing is that image filters should also be updated >>>>>>> to use >>>>>>> them with multi-resolution images. >>>>>>> For example, consider the case: >>>>>>> ---------- >>>>>>> Image mrImage = getMultiResolutionImage(); >>>>>>> ImageProducer mriProducer = new >>>>>>> FilteredImageSource(mrImage.getSource(), new CropImageFilter(0, >>>>>>> 0, w, h)); >>>>>>> Toolkit.getDefaultToolkit().createImage(mriProducer); >>>>>>> ---------- >>>>>>> >>>>>>> The crop image filter applied to each resolution variant just cuts >>>>>>> images with the same size. >>>>>>> It seems that there should be added API which allows to set a >>>>>>> scale for >>>>>>> a provided image filter to be properly used with the given >>>>>>> resolution >>>>>>> variant. >>>>>>> >>>>>>> I have created a separated issue for multi-resolution images >>>>>>> filtering >>>>>>> support: >>>>>>> JDK-8152309 Seamless way of using image filters with >>>>>>> multi-resolution >>>>>>> images >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152309 >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> On 15/03/16 20:35, Alexander Scherbatiy wrote: >>>>>>>> On 15/03/16 18:06, Sergey Bylokhov wrote: >>>>>>>>> On 15.03.16 17:01, Alexander Scherbatiy wrote: >>>>>>>>> >>>>>>>>>> One update will be that FilteredImageSource should implement >>>>>>>>>> MultiResolutionImageProducer even it is used for non >>>>>>>>>> multi-resolution >>>>>>>>>> images. >>>>>>>>>> >>>>>>>>>> The MRI can be created using two general ways: using fixed >>>>>>>>>> number of >>>>>>>>>> resolution variants or generating a resolution variant with >>>>>>>>>> necessary >>>>>>>>>> quality on demand. >>>>>>>>>> >>>>>>>>>> The current implementation is rely on that MRToolkitImage >>>>>>>>>> contains a >>>>>>>>>> fixed number of resolution variants. In this case MediaTracker >>>>>>>>>> can >>>>>>>>>> iterate over resolution variants and load them all. >>>>>>>>>> >>>>>>>>>> Using MultiResolutionImageProducer leads that MRToolkitImage >>>>>>>>>> will not >>>>>>>>>> know about number of resolution variants in case when they are >>>>>>>>>> generated >>>>>>>>>> on the fly and there will be no way to load all of them by >>>>>>>>>> MediaTracker. >>>>>>>>> >>>>>>>>> Just an idea to thinking about, can we save this filter to the MRI >>>>>>>>> itself and apply it after some resolution variant will be >>>>>>>>> created on >>>>>>>>> the fly? >>>>>>>> >>>>>>>> Do you mean that it helps to leave the code in the AquaUtils class >>>>>>>> unchanged: >>>>>>>> --------------- >>>>>>>> 124 static Image generateLightenedImage(final Image image, >>>>>>>> final >>>>>>>> int percent) { >>>>>>>> 125 final GrayFilter filter = new GrayFilter(true, >>>>>>>> percent); >>>>>>>> 126 final ImageProducer prod = new >>>>>>>> FilteredImageSource(image.getSource(), filter); >>>>>>>> 127 return Toolkit.getDefaultToolkit().createImage(prod); >>>>>>>> 128 } >>>>>>>> --------------- >>>>>>>> >>>>>>>> or it is just an a better way for a filtered multi-resolution >>>>>>>> image >>>>>>>> generation? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> As I see, the way to solve it is only using >>>>>>>>>> MRI.getResolutionVariants() >>>>>>>>>> method for the MultiResolutionImageProducer creation. So the >>>>>>>>>> result of >>>>>>>>>> the call >>>>>>>>>> toolkit.createImage(new >>>>>>>>>> FilteredImageSource(mrImage.getSource(), >>>>>>>>>> filter)); >>>>>>>>>> will be a MRToolkitImage which is based on fixed number of >>>>>>>>>> filtered >>>>>>>>>> resolution variants from the original MRI. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>>> ...jim >>>>>>>>>>> >>>>>>>>>>> On 3/11/16 5:42 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>> On 09/03/16 16:58, Sergey Bylokhov wrote: >>>>>>>>>>>>> Probably we should enhance >>>>>>>>>>>>> ImageProducer/Tk.createImage/ImageFilter to >>>>>>>>>>>>> support this functionality? It seems that the number of >>>>>>>>>>>>> usage of >>>>>>>>>>>>> this >>>>>>>>>>>>> check "image instanceof MultiResolutionImage" will grow >>>>>>>>>>>>> over time. >>>>>>>>>>>> ImageProducer produces pixels for an image and is not >>>>>>>>>>>> able to >>>>>>>>>>>> take >>>>>>>>>>>> an information about the image resolution variants. >>>>>>>>>>>> >>>>>>>>>>>> May be we can add Toolkit.createImage(Image image, >>>>>>>>>>>> ImageFilter >>>>>>>>>>>> imageFilter) method which takes MultiResolutionImage into >>>>>>>>>>>> account to >>>>>>>>>>>> cover the common case where filtered image is created. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>>> I think that at least our own API should support >>>>>>>>>>>>> MultiResolutionImage >>>>>>>>>>>>> w/o such checks, otherwise the user will need to do the same. >>>>>>>>>>>>> >>>>>>>>>>>>> cc 2d-dev >>>>>>>>>>>>> >>>>>>>>>>>>> On 09.03.16 15:30, Alexander Scherbatiy wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Could you review the fix: >>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8151303 >>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8151303/webrev.00 >>>>>>>>>>>>>> >>>>>>>>>>>>>> The AquaUtils does not take into account >>>>>>>>>>>>>> MultiResolutionImage >>>>>>>>>>>>>> for >>>>>>>>>>>>>> selected/disabled/lightened images generation. >>>>>>>>>>>>>> The fix also leaves the MultiResolutionCachedImage >>>>>>>>>>>>>> check because >>>>>>>>>>>>>> the >>>>>>>>>>>>>> base system icon size can be differ from the requested >>>>>>>>>>>>>> painted >>>>>>>>>>>>>> size. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >> > From philip.race at oracle.com Tue Aug 9 00:34:45 2016 From: philip.race at oracle.com (Philip Race) Date: Mon, 08 Aug 2016 17:34:45 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8163238: Upgrade to harfbuzz 1.3.0 in JDK 9 In-Reply-To: References: <57A4F80D.7070807@oracle.com> Message-ID: <57A92525.5060505@oracle.com> Yes. I saw that (I reviewed the list of fixes that were made after the 1.3.0 release) but JDK9 won't be supporting 10.9 so I figured it was not critical. But also the function that is fixed is not used in our current code. We do use hb_coretext_face_create but that is implemented differently. So in all I did not think it worth an add-on patch to 1.3.0 -phil On 8/8/16, 5:18 AM, Sergey Bylokhov wrote: > Looks fine. > > FYI: after release 1.3 there is a fix for coretext crash on osx < 10.10: > https://cgit.freedesktop.org/harfbuzz/commit/?id=489acf6c3180d3726158864fa0e1adeea3c23fae > > > > On 05.08.16 23:33, Phil Race wrote: >> Bug : https://bugs.openjdk.java.net/browse/JDK-8163238 >> webrev: http://cr.openjdk.java.net/~prr/8163238/ >> >> Not easily reviewable .. it is basically the diff between harfbuzz 1.0.6 >> and 1.3 >> >> I have included all the files that we use and some of them you will see >> have zero changes. But I wanted all the files listed for completeness. >> >> I have built using JPRT on all platforms and run complex text tests. >> >> -phil. > > From vadim.pakhnushev at oracle.com Tue Aug 9 10:36:33 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Tue, 9 Aug 2016 13:36:33 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8163238: Upgrade to harfbuzz 1.3.0 in JDK 9 In-Reply-To: <57A92525.5060505@oracle.com> References: <57A4F80D.7070807@oracle.com> <57A92525.5060505@oracle.com> Message-ID: <76569ec2-3772-a5ff-2c08-7192dde5c32c@oracle.com> +1 Vadim On 09.08.2016 3:34, Philip Race wrote: > Yes. I saw that (I reviewed the list of fixes that were made after the > 1.3.0 release) > but JDK9 won't be supporting 10.9 so I figured it was not critical. > > But also the function that is fixed is not used in our current code. > We do use hb_coretext_face_create but that is implemented differently. > > So in all I did not think it worth an add-on patch to 1.3.0 > > -phil > > On 8/8/16, 5:18 AM, Sergey Bylokhov wrote: >> Looks fine. >> >> FYI: after release 1.3 there is a fix for coretext crash on osx < 10.10: >> https://cgit.freedesktop.org/harfbuzz/commit/?id=489acf6c3180d3726158864fa0e1adeea3c23fae >> >> >> >> On 05.08.16 23:33, Phil Race wrote: >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8163238 >>> webrev: http://cr.openjdk.java.net/~prr/8163238/ >>> >>> Not easily reviewable .. it is basically the diff between harfbuzz >>> 1.0.6 >>> and 1.3 >>> >>> I have included all the files that we use and some of them you will see >>> have zero changes. But I wanted all the files listed for completeness. >>> >>> I have built using JPRT on all platforms and run complex text tests. >>> >>> -phil. >> >> From prasanta.sadhukhan at oracle.com Wed Aug 10 08:59:41 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 10 Aug 2016 14:29:41 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6357887: selected printertray is ignored under linux Message-ID: <57AAECFD.2030802@oracle.com> Hi All, Please review a fix for an issue where it is seen that the selected printer tray is ignored in linux and default standard tray is used for printing. Bug: https://bugs.openjdk.java.net/browse/JDK-6357887 webrev: http://cr.openjdk.java.net/~psadhukhan/6357887/webrev.00/ Issue was lpr command needs "-o InputSlot=" to select the printertray which was not being passed to lpr command. Proposed fix added InputSlot option to lpr command to select the printertray. Tested in ubuntu and solaris11. Regards Prasanta From ajit.ghaisas at oracle.com Wed Aug 10 11:15:01 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Wed, 10 Aug 2016 04:15:01 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9]Fix for JDK-8158356 : SIGSEGV when attempting to rotate BufferedImage using AffineTransform by NaN degrees Message-ID: Hi, Bug : https://bugs.openjdk.java.net/browse/JDK-8158356 Issue : AffineTransform using NaN value as input parameter results in SIGSEGV. Fix : Transformation matrix is checked for NaN values in AffineTransformOp.validateTransform(). Also, at native level a separate check is made to return error in case of NaN values. Webrev : http://cr.openjdk.java.net/~aghaisas/8158356/webrev.00/ Request you to review. Regards, Ajit From alexandr.scherbatiy at oracle.com Wed Aug 10 12:35:45 2016 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 10 Aug 2016 16:35:45 +0400 Subject: [OpenJDK 2D-Dev] [9] Review request for 8151303 [macosx] [hidpi] JButton's low-res. icon is visible when clicking on it In-Reply-To: <331c7407-0f8c-205c-f3a5-db3ac2f32398@oracle.com> References: <56E01777.1030202@oracle.com> <56E01DE7.9040103@oracle.com> <56E2CB4F.6040301@oracle.com> <56E3277B.3000309@oracle.com> <56E815C3.40208@oracle.com> <56E816E9.1010308@oracle.com> <56E839DC.2040904@oracle.com> <56F01921.6060305@oracle.com> <56F03E0B.1080703@oracle.com> <5734B8AB.7070908@oracle.com> <0f87bf94-13c3-160b-d1f6-c95b959299bb@oracle.com> <6c50a4f1-b2e6-f447-18a9-57843a6a517e@oracle.com> <331c7407-0f8c-205c-f3a5-db3ac2f32398@oracle.com> Message-ID: <3dcd98ac-18cd-dfc4-b3f9-276b72aea9a2@oracle.com> On 09/08/16 03:49, Jim Graham wrote: > Does MultiResolutionCachedImage.map() work if the Image hasn't been > loaded yet (where getWidth/Height(Observer) can return -1)? Can it > ever be called in a case like that? Could we rely on the fact that getWidth/Height(Observer) returns -1 only for ToolkitImage? If so, the passed MultiResolutionToolkitImage is handled in MultiResolutionToolkitImage.map() method. If no, the fix should be updated to load the image size in some way. Thanks, Alexandr. > > ...jim > > On 08/08/2016 12:48 PM, Alexander Scherbatiy wrote: >> >> Just a friendly reminder. >> >> Thanks, >> Alexandr. >> >> On 27/06/16 22:17, Alexander Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8151303/webrev.02 >>> >>> The fix does not use a new public API to apply filters to >>> multi-resolution images. >>> >>> Thanks, >>> Alexandr. >>> >>> >>> On 14/05/16 02:54, Jim Graham wrote: >>>> Another reason to avoid new API is that we don't have to involve the >>>> CCC to get this "bug fix" in... >>>> >>>> ...jim >>>> >>>> On 5/13/16 3:50 PM, Jim Graham wrote: >>>>> That looks very tight. The only issue I'd have is that it would be >>>>> better if this could be done with non-public API for >>>>> now - the map() methods could live on one of the sun.awt.image >>>>> classes or even in a Swing implementation utility class >>>>> and still work just fine. When we have more time to figure out how >>>>> we're going to handle filtering of MRIs in general >>>>> we can decide if this API should live on the base MRI interface. >>>>> >>>>> The only thing we'd lose is BaseMRI having an optimized >>>>> implementation of the map() method, but I don't think it's >>>>> implementation represents enough of an optimization to matter when >>>>> we are creating and loading dozens of images... >>>>> >>>>> ...jim >>>>> >>>>> On 5/12/16 10:08 AM, Alexander Scherbatiy wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Could you review the updated fix: >>>>>> http://cr.openjdk.java.net/~alexsch/8151303/webrev.01 >>>>>> >>>>>> There was a suggestion to postpone the fix for the issue 8152309 >>>>>> Seamless way of using image filters with >>>>>> multi-resolution images >>>>>> and continue with the current one: >>>>>> http://mail.openjdk.java.net/pipermail/2d-dev/2016-April/006766.html >>>>>> >>>>>> The new version of the fix introduces a mapper method which allows >>>>>> to map all resolution variants of one >>>>>> multi-resolution image to another: >>>>>> ------------ >>>>>> Image image = // original image >>>>>> Image filteredImage = MultiResolutionImage.map(image, (img) -> >>>>>> /* return filtered image */); >>>>>> ------------ >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> On 21/03/16 22:31, Jim Graham wrote: >>>>>>> We could do that for our own filters, but any random custom filter >>>>>>> could run into the same issue, so it might not make >>>>>>> sense to upgrade the existing filter mechanism to always attempt >>>>>>> to do MR filtering. We could either create a >>>>>>> parallel set of MR-aware filter mechanisms (such as the previously >>>>>>> suggested new method on Toolkit, or a new MR-aware >>>>>>> version of FilteredImageSource for instance) and leave the >>>>>>> existing mechanism as clearly documented as MR-unaware. >>>>>>> Another idea is to tag a filter with an interface that indicates >>>>>>> that it is MR aware? In any case, some thought needs >>>>>>> to be given to feeding an MR image to a filter that (potentially >>>>>>> or demonstrably) cannot deal with MR images. >>>>>>> >>>>>>> Alternately, we could then recommend that the old image filtering >>>>>>> code isn't combined with multi-resolution images. >>>>>>> It seems to me that the programmer is mostly in control over this >>>>>>> happening since they've either manually created the >>>>>>> MR image using the custiom MR image mechanism or they've supplied >>>>>>> media with multiple resolution files (i.e. "@2x"). >>>>>>> Is that really the case? >>>>>>> >>>>>>> Whether it is a new filtering mechanism that must be adopted or >>>>>>> simply declaring the old filtering mechanism as >>>>>>> "obsolete with respect to MR images"... >>>>>>> >>>>>>> That recommendation then "restricts forward" in that, for example, >>>>>>> since Swing relies on the old mechanism, Swing then >>>>>>> becomes "not recommended for use with MR images", or "not MR >>>>>>> aware". That's probably not a restriction we want to >>>>>>> promote so it should be viewed as a temporary restriction reality >>>>>>> and a bug that we'll fix soon, whether by using some >>>>>>> other mechanism to achieve the desired affects, or creating a new >>>>>>> MR-aware filtering mechanism and using it in Swing. >>>>>>> >>>>>>> Similarly, other 3rd party libraries that accept images and do >>>>>>> anything more than display them will have to be >>>>>>> upgraded as well before they become "MR aware" or "MR accepting" >>>>>>> or whatever term applies here... >>>>>>> >>>>>>> ...jim >>>>>>> >>>>>>> On 3/21/16 8:54 AM, Alexander Scherbatiy wrote: >>>>>>>> >>>>>>>> The one more thing is that image filters should also be updated >>>>>>>> to use >>>>>>>> them with multi-resolution images. >>>>>>>> For example, consider the case: >>>>>>>> ---------- >>>>>>>> Image mrImage = getMultiResolutionImage(); >>>>>>>> ImageProducer mriProducer = new >>>>>>>> FilteredImageSource(mrImage.getSource(), new CropImageFilter(0, >>>>>>>> 0, w, h)); >>>>>>>> Toolkit.getDefaultToolkit().createImage(mriProducer); >>>>>>>> ---------- >>>>>>>> >>>>>>>> The crop image filter applied to each resolution variant just cuts >>>>>>>> images with the same size. >>>>>>>> It seems that there should be added API which allows to set a >>>>>>>> scale for >>>>>>>> a provided image filter to be properly used with the given >>>>>>>> resolution >>>>>>>> variant. >>>>>>>> >>>>>>>> I have created a separated issue for multi-resolution images >>>>>>>> filtering >>>>>>>> support: >>>>>>>> JDK-8152309 Seamless way of using image filters with >>>>>>>> multi-resolution >>>>>>>> images >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152309 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>> On 15/03/16 20:35, Alexander Scherbatiy wrote: >>>>>>>>> On 15/03/16 18:06, Sergey Bylokhov wrote: >>>>>>>>>> On 15.03.16 17:01, Alexander Scherbatiy wrote: >>>>>>>>>> >>>>>>>>>>> One update will be that FilteredImageSource should implement >>>>>>>>>>> MultiResolutionImageProducer even it is used for non >>>>>>>>>>> multi-resolution >>>>>>>>>>> images. >>>>>>>>>>> >>>>>>>>>>> The MRI can be created using two general ways: using fixed >>>>>>>>>>> number of >>>>>>>>>>> resolution variants or generating a resolution variant with >>>>>>>>>>> necessary >>>>>>>>>>> quality on demand. >>>>>>>>>>> >>>>>>>>>>> The current implementation is rely on that MRToolkitImage >>>>>>>>>>> contains a >>>>>>>>>>> fixed number of resolution variants. In this case MediaTracker >>>>>>>>>>> can >>>>>>>>>>> iterate over resolution variants and load them all. >>>>>>>>>>> >>>>>>>>>>> Using MultiResolutionImageProducer leads that MRToolkitImage >>>>>>>>>>> will not >>>>>>>>>>> know about number of resolution variants in case when they are >>>>>>>>>>> generated >>>>>>>>>>> on the fly and there will be no way to load all of them by >>>>>>>>>>> MediaTracker. >>>>>>>>>> >>>>>>>>>> Just an idea to thinking about, can we save this filter to >>>>>>>>>> the MRI >>>>>>>>>> itself and apply it after some resolution variant will be >>>>>>>>>> created on >>>>>>>>>> the fly? >>>>>>>>> >>>>>>>>> Do you mean that it helps to leave the code in the AquaUtils >>>>>>>>> class >>>>>>>>> unchanged: >>>>>>>>> --------------- >>>>>>>>> 124 static Image generateLightenedImage(final Image image, >>>>>>>>> final >>>>>>>>> int percent) { >>>>>>>>> 125 final GrayFilter filter = new GrayFilter(true, >>>>>>>>> percent); >>>>>>>>> 126 final ImageProducer prod = new >>>>>>>>> FilteredImageSource(image.getSource(), filter); >>>>>>>>> 127 return >>>>>>>>> Toolkit.getDefaultToolkit().createImage(prod); >>>>>>>>> 128 } >>>>>>>>> --------------- >>>>>>>>> >>>>>>>>> or it is just an a better way for a filtered multi-resolution >>>>>>>>> image >>>>>>>>> generation? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> As I see, the way to solve it is only using >>>>>>>>>>> MRI.getResolutionVariants() >>>>>>>>>>> method for the MultiResolutionImageProducer creation. So the >>>>>>>>>>> result of >>>>>>>>>>> the call >>>>>>>>>>> toolkit.createImage(new >>>>>>>>>>> FilteredImageSource(mrImage.getSource(), >>>>>>>>>>> filter)); >>>>>>>>>>> will be a MRToolkitImage which is based on fixed number of >>>>>>>>>>> filtered >>>>>>>>>>> resolution variants from the original MRI. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>>> ...jim >>>>>>>>>>>> >>>>>>>>>>>> On 3/11/16 5:42 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>> On 09/03/16 16:58, Sergey Bylokhov wrote: >>>>>>>>>>>>>> Probably we should enhance >>>>>>>>>>>>>> ImageProducer/Tk.createImage/ImageFilter to >>>>>>>>>>>>>> support this functionality? It seems that the number of >>>>>>>>>>>>>> usage of >>>>>>>>>>>>>> this >>>>>>>>>>>>>> check "image instanceof MultiResolutionImage" will grow >>>>>>>>>>>>>> over time. >>>>>>>>>>>>> ImageProducer produces pixels for an image and is not >>>>>>>>>>>>> able to >>>>>>>>>>>>> take >>>>>>>>>>>>> an information about the image resolution variants. >>>>>>>>>>>>> >>>>>>>>>>>>> May be we can add Toolkit.createImage(Image image, >>>>>>>>>>>>> ImageFilter >>>>>>>>>>>>> imageFilter) method which takes MultiResolutionImage into >>>>>>>>>>>>> account to >>>>>>>>>>>>> cover the common case where filtered image is created. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>> I think that at least our own API should support >>>>>>>>>>>>>> MultiResolutionImage >>>>>>>>>>>>>> w/o such checks, otherwise the user will need to do the >>>>>>>>>>>>>> same. >>>>>>>>>>>>>> >>>>>>>>>>>>>> cc 2d-dev >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 09.03.16 15:30, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Could you review the fix: >>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8151303 >>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8151303/webrev.00 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The AquaUtils does not take into account >>>>>>>>>>>>>>> MultiResolutionImage >>>>>>>>>>>>>>> for >>>>>>>>>>>>>>> selected/disabled/lightened images generation. >>>>>>>>>>>>>>> The fix also leaves the MultiResolutionCachedImage >>>>>>>>>>>>>>> check because >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> base system icon size can be differ from the requested >>>>>>>>>>>>>>> painted >>>>>>>>>>>>>>> size. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>> >> From philip.race at oracle.com Wed Aug 10 21:15:55 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 10 Aug 2016 14:15:55 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8139176: [macosx] java.awt.TextLayout does not handle correctly the bolded logical fonts Message-ID: <57AB998B.5060104@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-8139176 webrev: http://cr.openjdk.java.net/~prr/8139176/ Equals was returning true because the full name is the same for all members of the family. That in itself seems wrong .. no two fonts should have the same name, but that will be addressed in a follow-on fix. Here I am just making CFont check the style as well. Note that the super.equals() checks the class so I do not need to do so here. -phil. From philip.race at oracle.com Wed Aug 10 21:22:31 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 10 Aug 2016 14:22:31 -0700 Subject: [OpenJDK 2D-Dev] [9]Fix for JDK-8158356 : SIGSEGV when attempting to rotate BufferedImage using AffineTransform by NaN degrees In-Reply-To: References: Message-ID: <57AB9B17.3030709@oracle.com> 1) The spec for the constructors needs to be updated to include this reason for throwing ImagingOpException. A CCC request will be needed. 2) The C usage of "isnan()" may be problematic in some compilation environments. For example I believe this will not compile with VS2010, and many folks still use that. Instead you could use matrix[j] != matrix[j] as the two values should not compare equal if it is NaN. -phil. On 08/10/2016 04:15 AM, Ajit Ghaisas wrote: > Hi, > > Bug : https://bugs.openjdk.java.net/browse/JDK-8158356 > > Issue : AffineTransform using NaN value as input parameter results in SIGSEGV. > > Fix : Transformation matrix is checked for NaN values in AffineTransformOp.validateTransform(). > Also, at native level a separate check is made to return error in case of NaN values. > > Webrev : http://cr.openjdk.java.net/~aghaisas/8158356/webrev.00/ > > Request you to review. > > Regards, > Ajit > From philip.race at oracle.com Wed Aug 10 21:35:56 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 10 Aug 2016 14:35:56 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6574279: validatePage from PrinterJob returns argument under linux In-Reply-To: <57A46852.4050801@oracle.com> References: <5784DD01.4040309@oracle.com> <57A25BE6.3080305@oracle.com> <57A331E4.8000907@oracle.com> <57A46852.4050801@oracle.com> Message-ID: <57AB9E3C.80302@oracle.com> There does not seem to be a link to the new webrev in here. Is it this : http://cr.openjdk.java.net/~psadhukhan/6574279/webrev.01/ ? > to default Paper (Letter in US, A4 otherwise) imageable area I don't think that will ever be A4. Where is that coming from ? And you still have not fixed the problem with how you retrieve the MPA :- 512 MediaPrintableArea mpa = (MediaPrintableArea) 513 getPrintService().getDefaultAttributeValue(MediaPrintableArea.class); It is not supposed to be the MPA of the *default* paper. You want the MPA of *this* paper. Only if origPaper is not a supported paper do you go look for the default paper. -phil. On 08/05/2016 03:20 AM, Prasanta Sadhukhan wrote: > > > On 8/4/2016 5:45 PM, Prasanta Sadhukhan wrote: >> I will override in PSPrinterJob but >> 1662 MediaPrintableArea mpa = >> 1663 (MediaPrintableArea)getPrintService(). >> 1664 getDefaultAttributeValue(MediaPrintableArea.class); >> >> is returning imageable area of default media of chosen printer from >> CUPS [ all supported media printable area is obtained from >> CUPSPrinter#getPageSizes(printer) & then initMedia() populates >> cupsMediaPrintables which is returned in getMediaPrintableArea()] >> as IPPPrintService#getDefaultAttributeValue() does >> ---------- >> if (category == MediaPrintableArea.class) { >> MediaPrintableArea[] mpas; >> if ((cps != null) && >> ((mpas = *cps.getMediaPrintableArea()*) != null)) { >> if (defaultMediaIndex == -1) { >> // initializes value of defaultMediaIndex >> getDefaultAttributeValue(Media.class); >> } >> return mpas[*defaultMediaIndex*]; >> } >> -------------- >> by which mpas[defaultMediaIndex] returns default media printable area. >> In else block, we instantiate mpa of Letter for US locale and A4 for >> other locales so I was not checking for null as in both if and else >> block , I was getting MediaPrintableArea instance. >> >> Regarding considering equal margins, I am not sure if there was any >> way I could get right and left margin separately. >> Please let me know if there is any way you know of. > I have modified to do the change in PSPrinterJob. Regarding the equal > margin, we do the same in > http://hg.openjdk.java.net/jdk9/client/jdk/file/abb2a39948fe/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java#l688 > http://cr.openjdk.java.net/~psadhukhan/6574279/webrev.01/ That does not seem to be the same case as this. -phil. > > Regards > Prasanta >> >> Regards >> Prasanta >> On 8/4/2016 2:32 AM, Philip Race wrote: >>> High-level question. Why is this not an over-ride in PSPrinterJob ? >>> >>> >>> I'm afraid I did not get much past the first line of the change : >>> 1662 MediaPrintableArea mpa = >>> 1663 (MediaPrintableArea)getPrintService(). >>> 1664 getDefaultAttributeValue(MediaPrintableArea.class); >>> >>> Read the docs for MediaPrintableArea :- >>> --- >>> To query for the printable area, a client must supply a suitable >>> context. >>> Without specifying at the very least the size of the media being used >>> no meaningful value for printable area can be obtained. >>> --- >>> >>> .. not to mention you assume a non-null return. >>> >>> and then you use new Paper() .. which is a constructor which >>> knows nothing about the printer. It is *speced* to return >>> US letter with one inch margins. >>> >>> Another reason why this seems like it should be a sub-class over-ride. >>> >>> >>> Also this looks wrong --- >>> 1672 if ((imgX*2) + imgWid > wid) { >>> 1673 imgWid = wid - imgX*2; >>> 1674 } >>> >>> You can't assume equal margins. >>> >>> -phil. >>> >>> On 7/12/16, 5:05 AM, Prasanta Sadhukhan wrote: >>>> Hi All, >>>> >>>> Please review a fix for an issue where it is seen that if user sets >>>> invalid imageablearea via Paper.setImageableArea and >>>> then calls PrinterJob.validatePage() in linux, then it does not get >>>> a valid pageformat >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6574279 >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6574279/webrev.00/ >>>> >>>> Fix is to check for margin as noted via CUPS ppdPageSize() and then >>>> calculate to find the valid margin in validatePaper() >>>> similar to what we do in native validatePaper() in windows. >>>> >>>> Regards >>>> Prasanta >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Wed Aug 10 21:46:25 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 10 Aug 2016 14:46:25 -0700 Subject: [OpenJDK 2D-Dev] [9] Review request for 8151303 [macosx] [hidpi] JButton's low-res. icon is visible when clicking on it In-Reply-To: <3dcd98ac-18cd-dfc4-b3f9-276b72aea9a2@oracle.com> References: <56E01777.1030202@oracle.com> <56E01DE7.9040103@oracle.com> <56E2CB4F.6040301@oracle.com> <56E3277B.3000309@oracle.com> <56E815C3.40208@oracle.com> <56E816E9.1010308@oracle.com> <56E839DC.2040904@oracle.com> <56F01921.6060305@oracle.com> <56F03E0B.1080703@oracle.com> <5734B8AB.7070908@oracle.com> <0f87bf94-13c3-160b-d1f6-c95b959299bb@oracle.com> <6c50a4f1-b2e6-f447-18a9-57843a6a517e@oracle.com> <331c7407-0f8c-205c-f3a5-db3ac2f32398@oracle.com> <3dcd98ac-18cd-dfc4-b3f9-276b72aea9a2@oracle.com> Message-ID: <2bd157b4-3bfc-032b-498a-d5f00645cb8c@oracle.com> Ah, yes, only ToolkitImages can be "not yet loaded" in that manner. A quick look suggests that a MRCI should not be an instance of MRTI, but MRCI.map() does not force its argument to be an instance of MRCI, just MRI, so it would be possible for someone to pass an MRTI to MRCI.map() and then it would have this problem. Should we change the argument of MRCI.map() to MRCI? (And then you don't need to cast to Image and use getWidth/Height(Observer) to get its dimensions.) If that is not feasible, we should have it do something different for a non-MRCI... ...jim On 8/10/16 5:35 AM, Alexander Scherbatiy wrote: > On 09/08/16 03:49, Jim Graham wrote: >> Does MultiResolutionCachedImage.map() work if the Image hasn't been loaded yet (where getWidth/Height(Observer) can >> return -1)? Can it ever be called in a case like that? > > Could we rely on the fact that getWidth/Height(Observer) returns -1 only for ToolkitImage? > > If so, the passed MultiResolutionToolkitImage is handled in MultiResolutionToolkitImage.map() method. > If no, the fix should be updated to load the image size in some way. > > Thanks, > Alexandr. > >> >> ...jim >> >> On 08/08/2016 12:48 PM, Alexander Scherbatiy wrote: >>> >>> Just a friendly reminder. >>> >>> Thanks, >>> Alexandr. >>> >>> On 27/06/16 22:17, Alexander Scherbatiy wrote: >>>> >>>> Hello, >>>> >>>> Could you review the updated fix: >>>> http://cr.openjdk.java.net/~alexsch/8151303/webrev.02 >>>> >>>> The fix does not use a new public API to apply filters to >>>> multi-resolution images. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> >>>> On 14/05/16 02:54, Jim Graham wrote: >>>>> Another reason to avoid new API is that we don't have to involve the >>>>> CCC to get this "bug fix" in... >>>>> >>>>> ...jim >>>>> >>>>> On 5/13/16 3:50 PM, Jim Graham wrote: >>>>>> That looks very tight. The only issue I'd have is that it would be >>>>>> better if this could be done with non-public API for >>>>>> now - the map() methods could live on one of the sun.awt.image >>>>>> classes or even in a Swing implementation utility class >>>>>> and still work just fine. When we have more time to figure out how >>>>>> we're going to handle filtering of MRIs in general >>>>>> we can decide if this API should live on the base MRI interface. >>>>>> >>>>>> The only thing we'd lose is BaseMRI having an optimized >>>>>> implementation of the map() method, but I don't think it's >>>>>> implementation represents enough of an optimization to matter when >>>>>> we are creating and loading dozens of images... >>>>>> >>>>>> ...jim >>>>>> >>>>>> On 5/12/16 10:08 AM, Alexander Scherbatiy wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Could you review the updated fix: >>>>>>> http://cr.openjdk.java.net/~alexsch/8151303/webrev.01 >>>>>>> >>>>>>> There was a suggestion to postpone the fix for the issue 8152309 >>>>>>> Seamless way of using image filters with >>>>>>> multi-resolution images >>>>>>> and continue with the current one: >>>>>>> http://mail.openjdk.java.net/pipermail/2d-dev/2016-April/006766.html >>>>>>> >>>>>>> The new version of the fix introduces a mapper method which allows >>>>>>> to map all resolution variants of one >>>>>>> multi-resolution image to another: >>>>>>> ------------ >>>>>>> Image image = // original image >>>>>>> Image filteredImage = MultiResolutionImage.map(image, (img) -> >>>>>>> /* return filtered image */); >>>>>>> ------------ >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> On 21/03/16 22:31, Jim Graham wrote: >>>>>>>> We could do that for our own filters, but any random custom filter >>>>>>>> could run into the same issue, so it might not make >>>>>>>> sense to upgrade the existing filter mechanism to always attempt >>>>>>>> to do MR filtering. We could either create a >>>>>>>> parallel set of MR-aware filter mechanisms (such as the previously >>>>>>>> suggested new method on Toolkit, or a new MR-aware >>>>>>>> version of FilteredImageSource for instance) and leave the >>>>>>>> existing mechanism as clearly documented as MR-unaware. >>>>>>>> Another idea is to tag a filter with an interface that indicates >>>>>>>> that it is MR aware? In any case, some thought needs >>>>>>>> to be given to feeding an MR image to a filter that (potentially >>>>>>>> or demonstrably) cannot deal with MR images. >>>>>>>> >>>>>>>> Alternately, we could then recommend that the old image filtering >>>>>>>> code isn't combined with multi-resolution images. >>>>>>>> It seems to me that the programmer is mostly in control over this >>>>>>>> happening since they've either manually created the >>>>>>>> MR image using the custiom MR image mechanism or they've supplied >>>>>>>> media with multiple resolution files (i.e. "@2x"). >>>>>>>> Is that really the case? >>>>>>>> >>>>>>>> Whether it is a new filtering mechanism that must be adopted or >>>>>>>> simply declaring the old filtering mechanism as >>>>>>>> "obsolete with respect to MR images"... >>>>>>>> >>>>>>>> That recommendation then "restricts forward" in that, for example, >>>>>>>> since Swing relies on the old mechanism, Swing then >>>>>>>> becomes "not recommended for use with MR images", or "not MR >>>>>>>> aware". That's probably not a restriction we want to >>>>>>>> promote so it should be viewed as a temporary restriction reality >>>>>>>> and a bug that we'll fix soon, whether by using some >>>>>>>> other mechanism to achieve the desired affects, or creating a new >>>>>>>> MR-aware filtering mechanism and using it in Swing. >>>>>>>> >>>>>>>> Similarly, other 3rd party libraries that accept images and do >>>>>>>> anything more than display them will have to be >>>>>>>> upgraded as well before they become "MR aware" or "MR accepting" >>>>>>>> or whatever term applies here... >>>>>>>> >>>>>>>> ...jim >>>>>>>> >>>>>>>> On 3/21/16 8:54 AM, Alexander Scherbatiy wrote: >>>>>>>>> >>>>>>>>> The one more thing is that image filters should also be updated >>>>>>>>> to use >>>>>>>>> them with multi-resolution images. >>>>>>>>> For example, consider the case: >>>>>>>>> ---------- >>>>>>>>> Image mrImage = getMultiResolutionImage(); >>>>>>>>> ImageProducer mriProducer = new >>>>>>>>> FilteredImageSource(mrImage.getSource(), new CropImageFilter(0, >>>>>>>>> 0, w, h)); >>>>>>>>> Toolkit.getDefaultToolkit().createImage(mriProducer); >>>>>>>>> ---------- >>>>>>>>> >>>>>>>>> The crop image filter applied to each resolution variant just cuts >>>>>>>>> images with the same size. >>>>>>>>> It seems that there should be added API which allows to set a >>>>>>>>> scale for >>>>>>>>> a provided image filter to be properly used with the given >>>>>>>>> resolution >>>>>>>>> variant. >>>>>>>>> >>>>>>>>> I have created a separated issue for multi-resolution images >>>>>>>>> filtering >>>>>>>>> support: >>>>>>>>> JDK-8152309 Seamless way of using image filters with >>>>>>>>> multi-resolution >>>>>>>>> images >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152309 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> On 15/03/16 20:35, Alexander Scherbatiy wrote: >>>>>>>>>> On 15/03/16 18:06, Sergey Bylokhov wrote: >>>>>>>>>>> On 15.03.16 17:01, Alexander Scherbatiy wrote: >>>>>>>>>>> >>>>>>>>>>>> One update will be that FilteredImageSource should implement >>>>>>>>>>>> MultiResolutionImageProducer even it is used for non >>>>>>>>>>>> multi-resolution >>>>>>>>>>>> images. >>>>>>>>>>>> >>>>>>>>>>>> The MRI can be created using two general ways: using fixed >>>>>>>>>>>> number of >>>>>>>>>>>> resolution variants or generating a resolution variant with >>>>>>>>>>>> necessary >>>>>>>>>>>> quality on demand. >>>>>>>>>>>> >>>>>>>>>>>> The current implementation is rely on that MRToolkitImage >>>>>>>>>>>> contains a >>>>>>>>>>>> fixed number of resolution variants. In this case MediaTracker >>>>>>>>>>>> can >>>>>>>>>>>> iterate over resolution variants and load them all. >>>>>>>>>>>> >>>>>>>>>>>> Using MultiResolutionImageProducer leads that MRToolkitImage >>>>>>>>>>>> will not >>>>>>>>>>>> know about number of resolution variants in case when they are >>>>>>>>>>>> generated >>>>>>>>>>>> on the fly and there will be no way to load all of them by >>>>>>>>>>>> MediaTracker. >>>>>>>>>>> >>>>>>>>>>> Just an idea to thinking about, can we save this filter to the MRI >>>>>>>>>>> itself and apply it after some resolution variant will be >>>>>>>>>>> created on >>>>>>>>>>> the fly? >>>>>>>>>> >>>>>>>>>> Do you mean that it helps to leave the code in the AquaUtils class >>>>>>>>>> unchanged: >>>>>>>>>> --------------- >>>>>>>>>> 124 static Image generateLightenedImage(final Image image, >>>>>>>>>> final >>>>>>>>>> int percent) { >>>>>>>>>> 125 final GrayFilter filter = new GrayFilter(true, >>>>>>>>>> percent); >>>>>>>>>> 126 final ImageProducer prod = new >>>>>>>>>> FilteredImageSource(image.getSource(), filter); >>>>>>>>>> 127 return Toolkit.getDefaultToolkit().createImage(prod); >>>>>>>>>> 128 } >>>>>>>>>> --------------- >>>>>>>>>> >>>>>>>>>> or it is just an a better way for a filtered multi-resolution >>>>>>>>>> image >>>>>>>>>> generation? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> As I see, the way to solve it is only using >>>>>>>>>>>> MRI.getResolutionVariants() >>>>>>>>>>>> method for the MultiResolutionImageProducer creation. So the >>>>>>>>>>>> result of >>>>>>>>>>>> the call >>>>>>>>>>>> toolkit.createImage(new >>>>>>>>>>>> FilteredImageSource(mrImage.getSource(), >>>>>>>>>>>> filter)); >>>>>>>>>>>> will be a MRToolkitImage which is based on fixed number of >>>>>>>>>>>> filtered >>>>>>>>>>>> resolution variants from the original MRI. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>>> ...jim >>>>>>>>>>>>> >>>>>>>>>>>>> On 3/11/16 5:42 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>> On 09/03/16 16:58, Sergey Bylokhov wrote: >>>>>>>>>>>>>>> Probably we should enhance >>>>>>>>>>>>>>> ImageProducer/Tk.createImage/ImageFilter to >>>>>>>>>>>>>>> support this functionality? It seems that the number of >>>>>>>>>>>>>>> usage of >>>>>>>>>>>>>>> this >>>>>>>>>>>>>>> check "image instanceof MultiResolutionImage" will grow >>>>>>>>>>>>>>> over time. >>>>>>>>>>>>>> ImageProducer produces pixels for an image and is not >>>>>>>>>>>>>> able to >>>>>>>>>>>>>> take >>>>>>>>>>>>>> an information about the image resolution variants. >>>>>>>>>>>>>> >>>>>>>>>>>>>> May be we can add Toolkit.createImage(Image image, >>>>>>>>>>>>>> ImageFilter >>>>>>>>>>>>>> imageFilter) method which takes MultiResolutionImage into >>>>>>>>>>>>>> account to >>>>>>>>>>>>>> cover the common case where filtered image is created. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>> I think that at least our own API should support >>>>>>>>>>>>>>> MultiResolutionImage >>>>>>>>>>>>>>> w/o such checks, otherwise the user will need to do the same. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> cc 2d-dev >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 09.03.16 15:30, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Could you review the fix: >>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8151303 >>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8151303/webrev.00 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The AquaUtils does not take into account >>>>>>>>>>>>>>>> MultiResolutionImage >>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>> selected/disabled/lightened images generation. >>>>>>>>>>>>>>>> The fix also leaves the MultiResolutionCachedImage >>>>>>>>>>>>>>>> check because >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> base system icon size can be differ from the requested >>>>>>>>>>>>>>>> painted >>>>>>>>>>>>>>>> size. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>> >>> > From james.graham at oracle.com Wed Aug 10 21:47:53 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 10 Aug 2016 14:47:53 -0700 Subject: [OpenJDK 2D-Dev] [9]Fix for JDK-8158356 : SIGSEGV when attempting to rotate BufferedImage using AffineTransform by NaN degrees In-Reply-To: <57AB9B17.3030709@oracle.com> References: <57AB9B17.3030709@oracle.com> Message-ID: <3bbfa84f-36ae-69aa-cd07-912d1d1fa181@oracle.com> This does address the specific test case directly, but I'd be happier if we dug down and figured out where it went wrong in trying to transform the image and put in a fix that addressed the root problem whether it comes from the inputs being NaN or from some other similar condition that could also trigger the same poorly written transform code... ...jim On 8/10/16 2:22 PM, Phil Race wrote: > 1) The spec for the constructors needs to be updated to include this > reason for throwing ImagingOpException. A CCC request will be needed. > > 2) The C usage of "isnan()" may be problematic in some compilation environments. > For example I believe this will not compile with VS2010, and many folks still use that. > Instead you could use matrix[j] != matrix[j] as the two values should not compare > equal if it is NaN. > > -phil. > > On 08/10/2016 04:15 AM, Ajit Ghaisas wrote: >> Hi, >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8158356 >> >> Issue : AffineTransform using NaN value as input parameter results in SIGSEGV. >> >> Fix : Transformation matrix is checked for NaN values in AffineTransformOp.validateTransform(). >> Also, at native level a separate check is made to return error in case of NaN values. >> >> Webrev : http://cr.openjdk.java.net/~aghaisas/8158356/webrev.00/ >> >> Request you to review. >> >> Regards, >> Ajit >> > From philip.race at oracle.com Wed Aug 10 21:52:10 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 10 Aug 2016 14:52:10 -0700 Subject: [OpenJDK 2D-Dev] [9]Fix for JDK-8158356 : SIGSEGV when attempting to rotate BufferedImage using AffineTransform by NaN degrees In-Reply-To: <3bbfa84f-36ae-69aa-cd07-912d1d1fa181@oracle.com> References: <57AB9B17.3030709@oracle.com> <3bbfa84f-36ae-69aa-cd07-912d1d1fa181@oracle.com> Message-ID: <57ABA20A.2060403@oracle.com> Agreed, I had previously asked for that too (off-line). ie. root cause why a NaN would cause a crash .. -phil. On 8/10/16, 2:47 PM, Jim Graham wrote: > This does address the specific test case directly, but I'd be happier > if we dug down and figured out where it went wrong in trying to > transform the image and put in a fix that addressed the root problem > whether it comes from the inputs being NaN or from some other similar > condition that could also trigger the same poorly written transform > code... > > ...jim > > On 8/10/16 2:22 PM, Phil Race wrote: >> 1) The spec for the constructors needs to be updated to include this >> reason for throwing ImagingOpException. A CCC request will be needed. >> >> 2) The C usage of "isnan()" may be problematic in some compilation >> environments. >> For example I believe this will not compile with VS2010, and many >> folks still use that. >> Instead you could use matrix[j] != matrix[j] as the two values should >> not compare >> equal if it is NaN. >> >> -phil. >> >> On 08/10/2016 04:15 AM, Ajit Ghaisas wrote: >>> Hi, >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8158356 >>> >>> Issue : AffineTransform using NaN value as input parameter >>> results in SIGSEGV. >>> >>> Fix : Transformation matrix is checked for NaN values in >>> AffineTransformOp.validateTransform(). >>> Also, at native level a separate check is made to >>> return error in case of NaN values. >>> >>> Webrev : http://cr.openjdk.java.net/~aghaisas/8158356/webrev.00/ >>> >>> Request you to review. >>> >>> Regards, >>> Ajit >>> >> From brian.burkhalter at oracle.com Thu Aug 11 02:36:32 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 10 Aug 2016 19:36:32 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8145014: "IIOException: Couldn't seek!" when calling TIFFImageReader.getNumImages() Message-ID: <5DAD551E-3290-465A-8D70-2E266A99656D@oracle.com> Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8145014 Patch: http://cr.openjdk.java.net/~bpb/8145014/webrev.00/ In the locateImage() method handle zero-entry IFDs and EOFExceptions, hopefully returning the correct viable number of leading images in the stream with any bogus ones at the end being ignored. Thanks, Brian From philip.race at oracle.com Thu Aug 11 05:28:00 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 10 Aug 2016 22:28:00 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8145014: "IIOException: Couldn't seek!" when calling TIFFImageReader.getNumImages() In-Reply-To: <5DAD551E-3290-465A-8D70-2E266A99656D@oracle.com> References: <5DAD551E-3290-465A-8D70-2E266A99656D@oracle.com> Message-ID: <57AC0CE0.3010605@oracle.com> +1 -phil. On 8/10/16, 7:36 PM, Brian Burkhalter wrote: > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8145014 > Patch: http://cr.openjdk.java.net/~bpb/8145014/webrev.00/ > > In the locateImage() method handle zero-entry IFDs and EOFExceptions, hopefully returning the correct viable number of leading images in the stream with any bogus ones at the end being ignored. > > Thanks, > > Brian From prahalad.kumar.narayanan at oracle.com Thu Aug 11 06:00:38 2016 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Wed, 10 Aug 2016 23:00:38 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] Review Request: JDK-8158524: Test file added for VolatileImage -vs- BufferedImage output comparison Message-ID: Hello Everyone Good day to you. I 'm planning to add a test file into jdk/test/ repository. The webrev changes for the test file is presented herewith. Link: http://cr.openjdk.java.net/~pnarayanan/8158524/webrev.00/ Brief on the test & its objectives: . As we know, VolatileImage utilizes accelerated rendering using GPU while BufferedImage utilizes software rendering . The objective of this test-case is to check whether the rendered 2d primitives appear same on VolatileImage and BufferedImage . In rare cases, the rendering on VolatileImage might differ by few pixels from BufferedImage due to D3D/OpenGL driver 's handling of primitives . Java2D pipelines for D3D/OpenGL APIs use fudge factors to fine tune rendering calls so that output matches with output of BufferedImage. . Thus the test case will help in checking for consistent rendering across pipelines and also in identifying scenarios where pipelines need to be fine-tuned. Kindly review the test file and share your views at your convenience Thank you Have a good day Prahalad N. From prasanta.sadhukhan at oracle.com Thu Aug 11 07:31:35 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 11 Aug 2016 13:01:35 +0530 Subject: [OpenJDK 2D-Dev] [9] Review Request: JDK-8158524: Test file added for VolatileImage -vs- BufferedImage output comparison In-Reply-To: References: Message-ID: <57AC29D7.90605@oracle.com> You need to use @Override annotation for paint() method. Also, you can use specific imports rather than package imports. Also, I guess it's better to throw RuntimeException than Error for failure, not sure how jtreg will react to it. Lastly, I am not sure if you can use duke.gif image which maynot be licensed although we have similar duke.gif in java/awt/print/PrinterJob. Regards Prasanta On 8/11/2016 11:30 AM, Prahalad Kumar Narayanan wrote: > Hello Everyone > > Good day to you. > > I 'm planning to add a test file into jdk/test/ repository. > The webrev changes for the test file is presented herewith. > Link: http://cr.openjdk.java.net/~pnarayanan/8158524/webrev.00/ > > Brief on the test & its objectives: > . As we know, VolatileImage utilizes accelerated rendering using GPU while BufferedImage utilizes software rendering > . The objective of this test-case is to check whether the rendered 2d primitives appear same on VolatileImage and BufferedImage > . In rare cases, the rendering on VolatileImage might differ by few pixels from BufferedImage due to D3D/OpenGL driver 's handling of primitives > . Java2D pipelines for D3D/OpenGL APIs use fudge factors to fine tune rendering calls so that output matches with output of BufferedImage. > . Thus the test case will help in checking for consistent rendering across pipelines and also in identifying scenarios where pipelines need to be fine-tuned. > > Kindly review the test file and share your views at your convenience > > Thank you > Have a good day > > Prahalad N. From alexandr.scherbatiy at oracle.com Thu Aug 11 08:32:32 2016 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 11 Aug 2016 12:32:32 +0400 Subject: [OpenJDK 2D-Dev] [9] Review request for 8151303 [macosx] [hidpi] JButton's low-res. icon is visible when clicking on it In-Reply-To: <2bd157b4-3bfc-032b-498a-d5f00645cb8c@oracle.com> References: <56E01777.1030202@oracle.com> <56E01DE7.9040103@oracle.com> <56E2CB4F.6040301@oracle.com> <56E3277B.3000309@oracle.com> <56E815C3.40208@oracle.com> <56E816E9.1010308@oracle.com> <56E839DC.2040904@oracle.com> <56F01921.6060305@oracle.com> <56F03E0B.1080703@oracle.com> <5734B8AB.7070908@oracle.com> <0f87bf94-13c3-160b-d1f6-c95b959299bb@oracle.com> <6c50a4f1-b2e6-f447-18a9-57843a6a517e@oracle.com> <331c7407-0f8c-205c-f3a5-db3ac2f32398@oracle.com> <3dcd98ac-18cd-dfc4-b3f9-276b72aea9a2@oracle.com> <2bd157b4-3bfc-032b-498a-d5f00645cb8c@oracle.com> Message-ID: <850cefda-57f4-8dfb-66ad-907d050b04fa@oracle.com> Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8151303/webrev.03 MultiResolutionToolkitImage handing is added to the MultiResolutionCachedImage.map() method. Thanks, Alexandr. On 11/08/16 01:46, Jim Graham wrote: > Ah, yes, only ToolkitImages can be "not yet loaded" in that manner. > > A quick look suggests that a MRCI should not be an instance of MRTI, > but MRCI.map() does not force its argument to be an instance of MRCI, > just MRI, so it would be possible for someone to pass an MRTI to > MRCI.map() and then it would have this problem. > > Should we change the argument of MRCI.map() to MRCI? (And then you > don't need to cast to Image and use getWidth/Height(Observer) to get > its dimensions.) > > If that is not feasible, we should have it do something different for > a non-MRCI... > > ...jim > > On 8/10/16 5:35 AM, Alexander Scherbatiy wrote: >> On 09/08/16 03:49, Jim Graham wrote: >>> Does MultiResolutionCachedImage.map() work if the Image hasn't been >>> loaded yet (where getWidth/Height(Observer) can >>> return -1)? Can it ever be called in a case like that? >> >> Could we rely on the fact that getWidth/Height(Observer) returns -1 >> only for ToolkitImage? >> >> If so, the passed MultiResolutionToolkitImage is handled in >> MultiResolutionToolkitImage.map() method. >> If no, the fix should be updated to load the image size in some way. >> >> Thanks, >> Alexandr. >> >>> >>> ...jim >>> >>> On 08/08/2016 12:48 PM, Alexander Scherbatiy wrote: >>>> >>>> Just a friendly reminder. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 27/06/16 22:17, Alexander Scherbatiy wrote: >>>>> >>>>> Hello, >>>>> >>>>> Could you review the updated fix: >>>>> http://cr.openjdk.java.net/~alexsch/8151303/webrev.02 >>>>> >>>>> The fix does not use a new public API to apply filters to >>>>> multi-resolution images. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> >>>>> On 14/05/16 02:54, Jim Graham wrote: >>>>>> Another reason to avoid new API is that we don't have to involve the >>>>>> CCC to get this "bug fix" in... >>>>>> >>>>>> ...jim >>>>>> >>>>>> On 5/13/16 3:50 PM, Jim Graham wrote: >>>>>>> That looks very tight. The only issue I'd have is that it would be >>>>>>> better if this could be done with non-public API for >>>>>>> now - the map() methods could live on one of the sun.awt.image >>>>>>> classes or even in a Swing implementation utility class >>>>>>> and still work just fine. When we have more time to figure out how >>>>>>> we're going to handle filtering of MRIs in general >>>>>>> we can decide if this API should live on the base MRI interface. >>>>>>> >>>>>>> The only thing we'd lose is BaseMRI having an optimized >>>>>>> implementation of the map() method, but I don't think it's >>>>>>> implementation represents enough of an optimization to matter when >>>>>>> we are creating and loading dozens of images... >>>>>>> >>>>>>> ...jim >>>>>>> >>>>>>> On 5/12/16 10:08 AM, Alexander Scherbatiy wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> Could you review the updated fix: >>>>>>>> http://cr.openjdk.java.net/~alexsch/8151303/webrev.01 >>>>>>>> >>>>>>>> There was a suggestion to postpone the fix for the issue 8152309 >>>>>>>> Seamless way of using image filters with >>>>>>>> multi-resolution images >>>>>>>> and continue with the current one: >>>>>>>> http://mail.openjdk.java.net/pipermail/2d-dev/2016-April/006766.html >>>>>>>> >>>>>>>> >>>>>>>> The new version of the fix introduces a mapper method which allows >>>>>>>> to map all resolution variants of one >>>>>>>> multi-resolution image to another: >>>>>>>> ------------ >>>>>>>> Image image = // original image >>>>>>>> Image filteredImage = MultiResolutionImage.map(image, (img) -> >>>>>>>> /* return filtered image */); >>>>>>>> ------------ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>> On 21/03/16 22:31, Jim Graham wrote: >>>>>>>>> We could do that for our own filters, but any random custom >>>>>>>>> filter >>>>>>>>> could run into the same issue, so it might not make >>>>>>>>> sense to upgrade the existing filter mechanism to always attempt >>>>>>>>> to do MR filtering. We could either create a >>>>>>>>> parallel set of MR-aware filter mechanisms (such as the >>>>>>>>> previously >>>>>>>>> suggested new method on Toolkit, or a new MR-aware >>>>>>>>> version of FilteredImageSource for instance) and leave the >>>>>>>>> existing mechanism as clearly documented as MR-unaware. >>>>>>>>> Another idea is to tag a filter with an interface that indicates >>>>>>>>> that it is MR aware? In any case, some thought needs >>>>>>>>> to be given to feeding an MR image to a filter that (potentially >>>>>>>>> or demonstrably) cannot deal with MR images. >>>>>>>>> >>>>>>>>> Alternately, we could then recommend that the old image filtering >>>>>>>>> code isn't combined with multi-resolution images. >>>>>>>>> It seems to me that the programmer is mostly in control over this >>>>>>>>> happening since they've either manually created the >>>>>>>>> MR image using the custiom MR image mechanism or they've supplied >>>>>>>>> media with multiple resolution files (i.e. "@2x"). >>>>>>>>> Is that really the case? >>>>>>>>> >>>>>>>>> Whether it is a new filtering mechanism that must be adopted or >>>>>>>>> simply declaring the old filtering mechanism as >>>>>>>>> "obsolete with respect to MR images"... >>>>>>>>> >>>>>>>>> That recommendation then "restricts forward" in that, for >>>>>>>>> example, >>>>>>>>> since Swing relies on the old mechanism, Swing then >>>>>>>>> becomes "not recommended for use with MR images", or "not MR >>>>>>>>> aware". That's probably not a restriction we want to >>>>>>>>> promote so it should be viewed as a temporary restriction reality >>>>>>>>> and a bug that we'll fix soon, whether by using some >>>>>>>>> other mechanism to achieve the desired affects, or creating a new >>>>>>>>> MR-aware filtering mechanism and using it in Swing. >>>>>>>>> >>>>>>>>> Similarly, other 3rd party libraries that accept images and do >>>>>>>>> anything more than display them will have to be >>>>>>>>> upgraded as well before they become "MR aware" or "MR accepting" >>>>>>>>> or whatever term applies here... >>>>>>>>> >>>>>>>>> ...jim >>>>>>>>> >>>>>>>>> On 3/21/16 8:54 AM, Alexander Scherbatiy wrote: >>>>>>>>>> >>>>>>>>>> The one more thing is that image filters should also be updated >>>>>>>>>> to use >>>>>>>>>> them with multi-resolution images. >>>>>>>>>> For example, consider the case: >>>>>>>>>> ---------- >>>>>>>>>> Image mrImage = getMultiResolutionImage(); >>>>>>>>>> ImageProducer mriProducer = new >>>>>>>>>> FilteredImageSource(mrImage.getSource(), new CropImageFilter(0, >>>>>>>>>> 0, w, h)); >>>>>>>>>> Toolkit.getDefaultToolkit().createImage(mriProducer); >>>>>>>>>> ---------- >>>>>>>>>> >>>>>>>>>> The crop image filter applied to each resolution variant just >>>>>>>>>> cuts >>>>>>>>>> images with the same size. >>>>>>>>>> It seems that there should be added API which allows to set a >>>>>>>>>> scale for >>>>>>>>>> a provided image filter to be properly used with the given >>>>>>>>>> resolution >>>>>>>>>> variant. >>>>>>>>>> >>>>>>>>>> I have created a separated issue for multi-resolution images >>>>>>>>>> filtering >>>>>>>>>> support: >>>>>>>>>> JDK-8152309 Seamless way of using image filters with >>>>>>>>>> multi-resolution >>>>>>>>>> images >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152309 >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>> On 15/03/16 20:35, Alexander Scherbatiy wrote: >>>>>>>>>>> On 15/03/16 18:06, Sergey Bylokhov wrote: >>>>>>>>>>>> On 15.03.16 17:01, Alexander Scherbatiy wrote: >>>>>>>>>>>> >>>>>>>>>>>>> One update will be that FilteredImageSource should >>>>>>>>>>>>> implement >>>>>>>>>>>>> MultiResolutionImageProducer even it is used for non >>>>>>>>>>>>> multi-resolution >>>>>>>>>>>>> images. >>>>>>>>>>>>> >>>>>>>>>>>>> The MRI can be created using two general ways: using fixed >>>>>>>>>>>>> number of >>>>>>>>>>>>> resolution variants or generating a resolution variant with >>>>>>>>>>>>> necessary >>>>>>>>>>>>> quality on demand. >>>>>>>>>>>>> >>>>>>>>>>>>> The current implementation is rely on that MRToolkitImage >>>>>>>>>>>>> contains a >>>>>>>>>>>>> fixed number of resolution variants. In this case >>>>>>>>>>>>> MediaTracker >>>>>>>>>>>>> can >>>>>>>>>>>>> iterate over resolution variants and load them all. >>>>>>>>>>>>> >>>>>>>>>>>>> Using MultiResolutionImageProducer leads that >>>>>>>>>>>>> MRToolkitImage >>>>>>>>>>>>> will not >>>>>>>>>>>>> know about number of resolution variants in case when they >>>>>>>>>>>>> are >>>>>>>>>>>>> generated >>>>>>>>>>>>> on the fly and there will be no way to load all of them by >>>>>>>>>>>>> MediaTracker. >>>>>>>>>>>> >>>>>>>>>>>> Just an idea to thinking about, can we save this filter to >>>>>>>>>>>> the MRI >>>>>>>>>>>> itself and apply it after some resolution variant will be >>>>>>>>>>>> created on >>>>>>>>>>>> the fly? >>>>>>>>>>> >>>>>>>>>>> Do you mean that it helps to leave the code in the AquaUtils >>>>>>>>>>> class >>>>>>>>>>> unchanged: >>>>>>>>>>> --------------- >>>>>>>>>>> 124 static Image generateLightenedImage(final Image image, >>>>>>>>>>> final >>>>>>>>>>> int percent) { >>>>>>>>>>> 125 final GrayFilter filter = new GrayFilter(true, >>>>>>>>>>> percent); >>>>>>>>>>> 126 final ImageProducer prod = new >>>>>>>>>>> FilteredImageSource(image.getSource(), filter); >>>>>>>>>>> 127 return >>>>>>>>>>> Toolkit.getDefaultToolkit().createImage(prod); >>>>>>>>>>> 128 } >>>>>>>>>>> --------------- >>>>>>>>>>> >>>>>>>>>>> or it is just an a better way for a filtered multi-resolution >>>>>>>>>>> image >>>>>>>>>>> generation? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> As I see, the way to solve it is only using >>>>>>>>>>>>> MRI.getResolutionVariants() >>>>>>>>>>>>> method for the MultiResolutionImageProducer creation. So the >>>>>>>>>>>>> result of >>>>>>>>>>>>> the call >>>>>>>>>>>>> toolkit.createImage(new >>>>>>>>>>>>> FilteredImageSource(mrImage.getSource(), >>>>>>>>>>>>> filter)); >>>>>>>>>>>>> will be a MRToolkitImage which is based on fixed number of >>>>>>>>>>>>> filtered >>>>>>>>>>>>> resolution variants from the original MRI. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>> >>>>>>>>>>>>>> ...jim >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 3/11/16 5:42 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>> On 09/03/16 16:58, Sergey Bylokhov wrote: >>>>>>>>>>>>>>>> Probably we should enhance >>>>>>>>>>>>>>>> ImageProducer/Tk.createImage/ImageFilter to >>>>>>>>>>>>>>>> support this functionality? It seems that the number of >>>>>>>>>>>>>>>> usage of >>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>> check "image instanceof MultiResolutionImage" will grow >>>>>>>>>>>>>>>> over time. >>>>>>>>>>>>>>> ImageProducer produces pixels for an image and is not >>>>>>>>>>>>>>> able to >>>>>>>>>>>>>>> take >>>>>>>>>>>>>>> an information about the image resolution variants. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> May be we can add Toolkit.createImage(Image image, >>>>>>>>>>>>>>> ImageFilter >>>>>>>>>>>>>>> imageFilter) method which takes MultiResolutionImage into >>>>>>>>>>>>>>> account to >>>>>>>>>>>>>>> cover the common case where filtered image is created. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>> I think that at least our own API should support >>>>>>>>>>>>>>>> MultiResolutionImage >>>>>>>>>>>>>>>> w/o such checks, otherwise the user will need to do the >>>>>>>>>>>>>>>> same. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> cc 2d-dev >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 09.03.16 15:30, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Could you review the fix: >>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8151303 >>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8151303/webrev.00 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The AquaUtils does not take into account >>>>>>>>>>>>>>>>> MultiResolutionImage >>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>> selected/disabled/lightened images generation. >>>>>>>>>>>>>>>>> The fix also leaves the MultiResolutionCachedImage >>>>>>>>>>>>>>>>> check because >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> base system icon size can be differ from the requested >>>>>>>>>>>>>>>>> painted >>>>>>>>>>>>>>>>> size. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>> >>>> >> From prasanta.sadhukhan at oracle.com Thu Aug 11 08:38:27 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 11 Aug 2016 14:08:27 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6574279: validatePage from PrinterJob returns argument under linux In-Reply-To: <57AB9E3C.80302@oracle.com> References: <5784DD01.4040309@oracle.com> <57A25BE6.3080305@oracle.com> <57A331E4.8000907@oracle.com> <57A46852.4050801@oracle.com> <57AB9E3C.80302@oracle.com> Message-ID: <57AC3983.7020504@oracle.com> Hi Phil, On 8/11/2016 3:05 AM, Phil Race wrote: > There does not seem to be a link to the new webrev in here. > > Is it this : http://cr.openjdk.java.net/~psadhukhan/6574279/webrev.01/ ? > > > to default Paper (Letter in US, A4 otherwise) imageable area > > I don't think that will ever be A4. Where is that coming from ? > > And you still have not fixed the problem with how you retrieve the MPA :- > 512 MediaPrintableArea mpa = (MediaPrintableArea) > 513 getPrintService().getDefaultAttributeValue(MediaPrintableArea.class); > > > It is not supposed to be the MPA of the *default* paper. You want the > MPA of *this* paper. > Only if origPaper is not a supported paper do you go look for the > default paper. > As you suggested, I have modified to check if mpa of origPaper is amongst supported mpa(s) of the printer, if not, then go for mpa of default paper. However, it seems among 61 mpas returned by CUPSPrinter , origPaper of 0,0,8.26",11.69" is within supported mpa of a paper size 0,0,11.69",16.52" so it means 0,0,8",11" comes out to be supported mpa. Can you please comment on this modified webrev on what more we can do? http://cr.openjdk.java.net/~psadhukhan/6574279/webrev.02/ I guess we need to find out the physical limitation of printer via CUPS same what we do in windows via GetDeviceCaps(printDC, PHYSICALOFFSETX); and use that in calculation for valid margin but I could not find equivalent cups function. Can you suggest anyways? Regards Prasanta > -phil. > > On 08/05/2016 03:20 AM, Prasanta Sadhukhan wrote: >> >> >> On 8/4/2016 5:45 PM, Prasanta Sadhukhan wrote: >>> I will override in PSPrinterJob but >>> 1662 MediaPrintableArea mpa = >>> 1663 (MediaPrintableArea)getPrintService(). >>> 1664 getDefaultAttributeValue(MediaPrintableArea.class); >>> >>> is returning imageable area of default media of chosen printer from >>> CUPS [ all supported media printable area is obtained from >>> CUPSPrinter#getPageSizes(printer) & then initMedia() populates >>> cupsMediaPrintables which is returned in getMediaPrintableArea()] >>> as IPPPrintService#getDefaultAttributeValue() does >>> ---------- >>> if (category == MediaPrintableArea.class) { >>> MediaPrintableArea[] mpas; >>> if ((cps != null) && >>> ((mpas = *cps.getMediaPrintableArea()*) != null)) { >>> if (defaultMediaIndex == -1) { >>> // initializes value of defaultMediaIndex >>> getDefaultAttributeValue(Media.class); >>> } >>> return mpas[*defaultMediaIndex*]; >>> } >>> -------------- >>> by which mpas[defaultMediaIndex] returns default media printable area. >>> In else block, we instantiate mpa of Letter for US locale and A4 for >>> other locales so I was not checking for null as in both if and else >>> block , I was getting MediaPrintableArea instance. >>> >>> Regarding considering equal margins, I am not sure if there was any >>> way I could get right and left margin separately. >>> Please let me know if there is any way you know of. >> I have modified to do the change in PSPrinterJob. Regarding the equal >> margin, we do the same in >> http://hg.openjdk.java.net/jdk9/client/jdk/file/abb2a39948fe/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java#l688 >> http://cr.openjdk.java.net/~psadhukhan/6574279/webrev.01/ > > That does not seem to be the same case as this. > > -phil. > >> >> Regards >> Prasanta >>> >>> Regards >>> Prasanta >>> On 8/4/2016 2:32 AM, Philip Race wrote: >>>> High-level question. Why is this not an over-ride in PSPrinterJob ? >>>> >>>> >>>> I'm afraid I did not get much past the first line of the change : >>>> 1662 MediaPrintableArea mpa = >>>> 1663 (MediaPrintableArea)getPrintService(). >>>> 1664 getDefaultAttributeValue(MediaPrintableArea.class); >>>> >>>> Read the docs for MediaPrintableArea :- >>>> --- >>>> To query for the printable area, a client must supply a suitable >>>> context. >>>> Without specifying at the very least the size of the media being used >>>> no meaningful value for printable area can be obtained. >>>> --- >>>> >>>> .. not to mention you assume a non-null return. >>>> >>>> and then you use new Paper() .. which is a constructor which >>>> knows nothing about the printer. It is *speced* to return >>>> US letter with one inch margins. >>>> >>>> Another reason why this seems like it should be a sub-class over-ride. >>>> >>>> >>>> Also this looks wrong --- >>>> 1672 if ((imgX*2) + imgWid > wid) { >>>> 1673 imgWid = wid - imgX*2; >>>> 1674 } >>>> >>>> You can't assume equal margins. >>>> >>>> -phil. >>>> >>>> On 7/12/16, 5:05 AM, Prasanta Sadhukhan wrote: >>>>> Hi All, >>>>> >>>>> Please review a fix for an issue where it is seen that if user >>>>> sets invalid imageablearea via Paper.setImageableArea and >>>>> then calls PrinterJob.validatePage() in linux, then it does not >>>>> get a valid pageformat >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6574279 >>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6574279/webrev.00/ >>>>> >>>>> Fix is to check for margin as noted via CUPS ppdPageSize() and >>>>> then calculate to find the valid margin in validatePaper() >>>>> similar to what we do in native validatePaper() in windows. >>>>> >>>>> Regards >>>>> Prasanta >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prahalad.kumar.narayanan at oracle.com Thu Aug 11 10:22:07 2016 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Thu, 11 Aug 2016 03:22:07 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] Review Request: JDK-8158524: Test file added for VolatileImage -vs- BufferedImage output comparison In-Reply-To: <57AC29D7.90605@oracle.com> References: <57AC29D7.90605@oracle.com> Message-ID: <60d1ffac-ebdc-4b0a-a7b2-c62a67bc90d7@default> Hello Everyone First, Thanks to Prasanta for his feedback. I 've incorporated the feedback in the code and changes are available for review. Review Link: http://cr.openjdk.java.net/~pnarayanan/8158524/webrev.01/ Quick summary on changes from previous revision: . Wild card imports have been replaced with specific imports . @override annotation has been added to the paint() method . RuntimeException is thrown instead of Error though both would report regression failure. . Image loading has been corrected with proper filePath. . With regard to image and licensing issue: . I checked the image properties. There is no 'author/copyright' information with this image. . The file matches when compared (binary) with the similar .gif image in test/java/awt/print/PrinterJob/ Kindly review the changes at your convenience and share your views. Thank you Have a good day Prahalad N. -----Original Message----- From: Prasanta Sadhukhan Sent: Thursday, August 11, 2016 1:02 PM To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net Cc: Philip Race; Sergey Bylokhov Subject: Re: [OpenJDK 2D-Dev] [9] Review Request: JDK-8158524: Test file added for VolatileImage -vs- BufferedImage output comparison You need to use @Override annotation for paint() method. Also, you can use specific imports rather than package imports. Also, I guess it's better to throw RuntimeException than Error for failure, not sure how jtreg will react to it. Lastly, I am not sure if you can use duke.gif image which maynot be licensed although we have similar duke.gif in java/awt/print/PrinterJob. Regards Prasanta On 8/11/2016 11:30 AM, Prahalad Kumar Narayanan wrote: > Hello Everyone > > Good day to you. > > I 'm planning to add a test file into jdk/test/ repository. > The webrev changes for the test file is presented herewith. > Link: > http://cr.openjdk.java.net/~pnarayanan/8158524/webrev.00/ > > Brief on the test & its objectives: > . As we know, VolatileImage utilizes accelerated rendering using GPU while BufferedImage utilizes software rendering > . The objective of this test-case is to check whether the rendered 2d primitives appear same on VolatileImage and BufferedImage > . In rare cases, the rendering on VolatileImage might differ by few pixels from BufferedImage due to D3D/OpenGL driver 's handling of primitives > . Java2D pipelines for D3D/OpenGL APIs use fudge factors to fine tune rendering calls so that output matches with output of BufferedImage. > . Thus the test case will help in checking for consistent rendering across pipelines and also in identifying scenarios where pipelines need to be fine-tuned. > > Kindly review the test file and share your views at your convenience > > Thank you > Have a good day > > Prahalad N. From prasanta.sadhukhan at oracle.com Thu Aug 11 13:57:12 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 11 Aug 2016 19:27:12 +0530 Subject: [OpenJDK 2D-Dev] [9] Review Request: JDK-8158524: Test file added for VolatileImage -vs- BufferedImage output comparison In-Reply-To: <60d1ffac-ebdc-4b0a-a7b2-c62a67bc90d7@default> References: <57AC29D7.90605@oracle.com> <60d1ffac-ebdc-4b0a-a7b2-c62a67bc90d7@default> Message-ID: <57AC8438.4070300@oracle.com> looks good to me. Regards Prasanta On 8/11/2016 3:52 PM, Prahalad Kumar Narayanan wrote: > Hello Everyone > > First, Thanks to Prasanta for his feedback. > I 've incorporated the feedback in the code and changes are available for review. > Review Link: http://cr.openjdk.java.net/~pnarayanan/8158524/webrev.01/ > > Quick summary on changes from previous revision: > . Wild card imports have been replaced with specific imports > . @override annotation has been added to the paint() method > . RuntimeException is thrown instead of Error though both would report regression failure. > . Image loading has been corrected with proper filePath. > . With regard to image and licensing issue: > . I checked the image properties. There is no 'author/copyright' information with this image. > . The file matches when compared (binary) with the similar .gif image in test/java/awt/print/PrinterJob/ > > Kindly review the changes at your convenience and share your views. > > Thank you > Have a good day > > Prahalad N. > > > -----Original Message----- > From: Prasanta Sadhukhan > Sent: Thursday, August 11, 2016 1:02 PM > To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net > Cc: Philip Race; Sergey Bylokhov > Subject: Re: [OpenJDK 2D-Dev] [9] Review Request: JDK-8158524: Test file added for VolatileImage -vs- BufferedImage output comparison > > You need to use @Override annotation for paint() method. Also, you can use specific imports rather than package imports. > Also, I guess it's better to throw RuntimeException than Error for failure, not sure how jtreg will react to it. > Lastly, I am not sure if you can use duke.gif image which maynot be licensed although we have similar duke.gif in java/awt/print/PrinterJob. > > Regards > Prasanta > On 8/11/2016 11:30 AM, Prahalad Kumar Narayanan wrote: >> Hello Everyone >> >> Good day to you. >> >> I 'm planning to add a test file into jdk/test/ repository. >> The webrev changes for the test file is presented herewith. >> Link: >> http://cr.openjdk.java.net/~pnarayanan/8158524/webrev.00/ >> >> Brief on the test & its objectives: >> . As we know, VolatileImage utilizes accelerated rendering using GPU while BufferedImage utilizes software rendering >> . The objective of this test-case is to check whether the rendered 2d primitives appear same on VolatileImage and BufferedImage >> . In rare cases, the rendering on VolatileImage might differ by few pixels from BufferedImage due to D3D/OpenGL driver 's handling of primitives >> . Java2D pipelines for D3D/OpenGL APIs use fudge factors to fine tune rendering calls so that output matches with output of BufferedImage. >> . Thus the test case will help in checking for consistent rendering across pipelines and also in identifying scenarios where pipelines need to be fine-tuned. >> >> Kindly review the test file and share your views at your convenience >> >> Thank you >> Have a good day >> >> Prahalad N. From brian.burkhalter at oracle.com Thu Aug 11 13:59:27 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 11 Aug 2016 06:59:27 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8145014: "IIOException: Couldn't seek!" when calling TIFFImageReader.getNumImages() In-Reply-To: <57AC0CE0.3010605@oracle.com> References: <5DAD551E-3290-465A-8D70-2E266A99656D@oracle.com> <57AC0CE0.3010605@oracle.com> Message-ID: Rethinking this slightly, I think it might be good to changes lines 218 and 236 of TIFFImageReader from imageIndex = index - 1; to imageIndex = index > 0 ? index - 1 : 0; If that looks reasonable I will update the webrev in place and push the fix. Thanks, Brian On Aug 10, 2016, at 10:28 PM, Philip Race wrote: > +1 > > -phil. > > On 8/10/16, 7:36 PM, Brian Burkhalter wrote: >> Please review at your convenience. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8145014 >> Patch: http://cr.openjdk.java.net/~bpb/8145014/webrev.00/ >> >> In the locateImage() method handle zero-entry IFDs and EOFExceptions, hopefully returning the correct viable number of leading images in the stream with any bogus ones at the end being ignored. >> >> Thanks, >> >> Brian From jayathirth.d.v at oracle.com Thu Aug 11 18:59:16 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 11 Aug 2016 11:59:16 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() method does not work when called inside imageStarted for PNG Message-ID: <06aa9e0a-bf19-4dd0-949a-c3c0cb00d4b1@default> Hi, Please review the following fix in JDK9 at your convenience: Bug : https://bugs.openjdk.java.net/browse/JDK-4924727 Webrev : http://cr.openjdk.java.net/~jdv/4924727/webrev.00/ Issue : When we issue ImageReader.abort() in IIOReadProgressListener.imageStarted(), reading is not aborted and it is continued. Root cause : After IIOReadProgressListener.imageStarted() call in PNGImageReader.java when we enter decodeImage() we call clearAbortRequest() which will clear the abort request from IIOReadProgressListener.imageStarted(). Solution : clearAbortRequest() documentation mentions that it should be called before reading of image starts, so it should be called before IIOReadProgressListener.imageStarted()(In PNGImageReader.java it is processImageStarted(0) in readImage()). So moved clearAbortRequest() call from decodeImage() to readImage(). Also we should call abortRequested() in PNGImageReader.java at places mapping to IIOReadProgressListener and not randomly at end of functions or at places related to IIOReadUpdateListener, updated the code for the same. Observation not related to this issue : We don't have call similar to IIOReadProgressListener.readAborted() in IIOReadUpdateListener, but user can call ImageReader.abort() from IIOReadUpdateListener methods. Is there a need to add similar method in IIOReadUpdateListener? Any inputs on this also would be helpful. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Thu Aug 11 19:10:01 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 11 Aug 2016 12:10:01 -0700 Subject: [OpenJDK 2D-Dev] [9] Review request for 8151303 [macosx] [hidpi] JButton's low-res. icon is visible when clicking on it In-Reply-To: <850cefda-57f4-8dfb-66ad-907d050b04fa@oracle.com> References: <56E01777.1030202@oracle.com> <56E01DE7.9040103@oracle.com> <56E2CB4F.6040301@oracle.com> <56E3277B.3000309@oracle.com> <56E815C3.40208@oracle.com> <56E816E9.1010308@oracle.com> <56E839DC.2040904@oracle.com> <56F01921.6060305@oracle.com> <56F03E0B.1080703@oracle.com> <5734B8AB.7070908@oracle.com> <0f87bf94-13c3-160b-d1f6-c95b959299bb@oracle.com> <6c50a4f1-b2e6-f447-18a9-57843a6a517e@oracle.com> <331c7407-0f8c-205c-f3a5-db3ac2f32398@oracle.com> <3dcd98ac-18cd-dfc4-b3f9-276b72aea9a2@oracle.com> <2bd157b4-3bfc-032b-498a-d5f00645cb8c@oracle.com> <850cefda-57f4-8dfb-66ad-907d050b04fa@oracle.com> Message-ID: <94c984b2-5c38-8708-5d3d-de5a05e797b1@oracle.com> Hi Alexandr, Should something be done to transfer the array of sizes to the new instance if the source is an MRCI? Perhaps a special case for MRCI as well that calls mrciInstance.map(mapper) instead of constructing a brand new object from scratch? ...jim On 08/11/2016 01:32 AM, Alexander Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8151303/webrev.03 > > MultiResolutionToolkitImage handing is added to the > MultiResolutionCachedImage.map() method. > > Thanks, > Alexandr. > > On 11/08/16 01:46, Jim Graham wrote: >> Ah, yes, only ToolkitImages can be "not yet loaded" in that manner. >> >> A quick look suggests that a MRCI should not be an instance of MRTI, >> but MRCI.map() does not force its argument to be an instance of MRCI, >> just MRI, so it would be possible for someone to pass an MRTI to >> MRCI.map() and then it would have this problem. >> >> Should we change the argument of MRCI.map() to MRCI? (And then you >> don't need to cast to Image and use getWidth/Height(Observer) to get >> its dimensions.) >> >> If that is not feasible, we should have it do something different for >> a non-MRCI... >> >> ...jim >> >> On 8/10/16 5:35 AM, Alexander Scherbatiy wrote: >>> On 09/08/16 03:49, Jim Graham wrote: >>>> Does MultiResolutionCachedImage.map() work if the Image hasn't been >>>> loaded yet (where getWidth/Height(Observer) can >>>> return -1)? Can it ever be called in a case like that? >>> >>> Could we rely on the fact that getWidth/Height(Observer) returns -1 >>> only for ToolkitImage? >>> >>> If so, the passed MultiResolutionToolkitImage is handled in >>> MultiResolutionToolkitImage.map() method. >>> If no, the fix should be updated to load the image size in some way. >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> ...jim >>>> >>>> On 08/08/2016 12:48 PM, Alexander Scherbatiy wrote: >>>>> >>>>> Just a friendly reminder. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 27/06/16 22:17, Alexander Scherbatiy wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Could you review the updated fix: >>>>>> http://cr.openjdk.java.net/~alexsch/8151303/webrev.02 >>>>>> >>>>>> The fix does not use a new public API to apply filters to >>>>>> multi-resolution images. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> >>>>>> On 14/05/16 02:54, Jim Graham wrote: >>>>>>> Another reason to avoid new API is that we don't have to involve the >>>>>>> CCC to get this "bug fix" in... >>>>>>> >>>>>>> ...jim >>>>>>> >>>>>>> On 5/13/16 3:50 PM, Jim Graham wrote: >>>>>>>> That looks very tight. The only issue I'd have is that it would be >>>>>>>> better if this could be done with non-public API for >>>>>>>> now - the map() methods could live on one of the sun.awt.image >>>>>>>> classes or even in a Swing implementation utility class >>>>>>>> and still work just fine. When we have more time to figure out how >>>>>>>> we're going to handle filtering of MRIs in general >>>>>>>> we can decide if this API should live on the base MRI interface. >>>>>>>> >>>>>>>> The only thing we'd lose is BaseMRI having an optimized >>>>>>>> implementation of the map() method, but I don't think it's >>>>>>>> implementation represents enough of an optimization to matter when >>>>>>>> we are creating and loading dozens of images... >>>>>>>> >>>>>>>> ...jim >>>>>>>> >>>>>>>> On 5/12/16 10:08 AM, Alexander Scherbatiy wrote: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Could you review the updated fix: >>>>>>>>> http://cr.openjdk.java.net/~alexsch/8151303/webrev.01 >>>>>>>>> >>>>>>>>> There was a suggestion to postpone the fix for the issue 8152309 >>>>>>>>> Seamless way of using image filters with >>>>>>>>> multi-resolution images >>>>>>>>> and continue with the current one: >>>>>>>>> http://mail.openjdk.java.net/pipermail/2d-dev/2016-April/006766.html >>>>>>>>> >>>>>>>>> >>>>>>>>> The new version of the fix introduces a mapper method which allows >>>>>>>>> to map all resolution variants of one >>>>>>>>> multi-resolution image to another: >>>>>>>>> ------------ >>>>>>>>> Image image = // original image >>>>>>>>> Image filteredImage = MultiResolutionImage.map(image, (img) -> >>>>>>>>> /* return filtered image */); >>>>>>>>> ------------ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> On 21/03/16 22:31, Jim Graham wrote: >>>>>>>>>> We could do that for our own filters, but any random custom >>>>>>>>>> filter >>>>>>>>>> could run into the same issue, so it might not make >>>>>>>>>> sense to upgrade the existing filter mechanism to always attempt >>>>>>>>>> to do MR filtering. We could either create a >>>>>>>>>> parallel set of MR-aware filter mechanisms (such as the >>>>>>>>>> previously >>>>>>>>>> suggested new method on Toolkit, or a new MR-aware >>>>>>>>>> version of FilteredImageSource for instance) and leave the >>>>>>>>>> existing mechanism as clearly documented as MR-unaware. >>>>>>>>>> Another idea is to tag a filter with an interface that indicates >>>>>>>>>> that it is MR aware? In any case, some thought needs >>>>>>>>>> to be given to feeding an MR image to a filter that (potentially >>>>>>>>>> or demonstrably) cannot deal with MR images. >>>>>>>>>> >>>>>>>>>> Alternately, we could then recommend that the old image filtering >>>>>>>>>> code isn't combined with multi-resolution images. >>>>>>>>>> It seems to me that the programmer is mostly in control over this >>>>>>>>>> happening since they've either manually created the >>>>>>>>>> MR image using the custiom MR image mechanism or they've supplied >>>>>>>>>> media with multiple resolution files (i.e. "@2x"). >>>>>>>>>> Is that really the case? >>>>>>>>>> >>>>>>>>>> Whether it is a new filtering mechanism that must be adopted or >>>>>>>>>> simply declaring the old filtering mechanism as >>>>>>>>>> "obsolete with respect to MR images"... >>>>>>>>>> >>>>>>>>>> That recommendation then "restricts forward" in that, for >>>>>>>>>> example, >>>>>>>>>> since Swing relies on the old mechanism, Swing then >>>>>>>>>> becomes "not recommended for use with MR images", or "not MR >>>>>>>>>> aware". That's probably not a restriction we want to >>>>>>>>>> promote so it should be viewed as a temporary restriction reality >>>>>>>>>> and a bug that we'll fix soon, whether by using some >>>>>>>>>> other mechanism to achieve the desired affects, or creating a new >>>>>>>>>> MR-aware filtering mechanism and using it in Swing. >>>>>>>>>> >>>>>>>>>> Similarly, other 3rd party libraries that accept images and do >>>>>>>>>> anything more than display them will have to be >>>>>>>>>> upgraded as well before they become "MR aware" or "MR accepting" >>>>>>>>>> or whatever term applies here... >>>>>>>>>> >>>>>>>>>> ...jim >>>>>>>>>> >>>>>>>>>> On 3/21/16 8:54 AM, Alexander Scherbatiy wrote: >>>>>>>>>>> >>>>>>>>>>> The one more thing is that image filters should also be updated >>>>>>>>>>> to use >>>>>>>>>>> them with multi-resolution images. >>>>>>>>>>> For example, consider the case: >>>>>>>>>>> ---------- >>>>>>>>>>> Image mrImage = getMultiResolutionImage(); >>>>>>>>>>> ImageProducer mriProducer = new >>>>>>>>>>> FilteredImageSource(mrImage.getSource(), new CropImageFilter(0, >>>>>>>>>>> 0, w, h)); >>>>>>>>>>> Toolkit.getDefaultToolkit().createImage(mriProducer); >>>>>>>>>>> ---------- >>>>>>>>>>> >>>>>>>>>>> The crop image filter applied to each resolution variant just >>>>>>>>>>> cuts >>>>>>>>>>> images with the same size. >>>>>>>>>>> It seems that there should be added API which allows to set a >>>>>>>>>>> scale for >>>>>>>>>>> a provided image filter to be properly used with the given >>>>>>>>>>> resolution >>>>>>>>>>> variant. >>>>>>>>>>> >>>>>>>>>>> I have created a separated issue for multi-resolution images >>>>>>>>>>> filtering >>>>>>>>>>> support: >>>>>>>>>>> JDK-8152309 Seamless way of using image filters with >>>>>>>>>>> multi-resolution >>>>>>>>>>> images >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152309 >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>> On 15/03/16 20:35, Alexander Scherbatiy wrote: >>>>>>>>>>>> On 15/03/16 18:06, Sergey Bylokhov wrote: >>>>>>>>>>>>> On 15.03.16 17:01, Alexander Scherbatiy wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> One update will be that FilteredImageSource should >>>>>>>>>>>>>> implement >>>>>>>>>>>>>> MultiResolutionImageProducer even it is used for non >>>>>>>>>>>>>> multi-resolution >>>>>>>>>>>>>> images. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The MRI can be created using two general ways: using fixed >>>>>>>>>>>>>> number of >>>>>>>>>>>>>> resolution variants or generating a resolution variant with >>>>>>>>>>>>>> necessary >>>>>>>>>>>>>> quality on demand. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The current implementation is rely on that MRToolkitImage >>>>>>>>>>>>>> contains a >>>>>>>>>>>>>> fixed number of resolution variants. In this case >>>>>>>>>>>>>> MediaTracker >>>>>>>>>>>>>> can >>>>>>>>>>>>>> iterate over resolution variants and load them all. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Using MultiResolutionImageProducer leads that >>>>>>>>>>>>>> MRToolkitImage >>>>>>>>>>>>>> will not >>>>>>>>>>>>>> know about number of resolution variants in case when they >>>>>>>>>>>>>> are >>>>>>>>>>>>>> generated >>>>>>>>>>>>>> on the fly and there will be no way to load all of them by >>>>>>>>>>>>>> MediaTracker. >>>>>>>>>>>>> >>>>>>>>>>>>> Just an idea to thinking about, can we save this filter to >>>>>>>>>>>>> the MRI >>>>>>>>>>>>> itself and apply it after some resolution variant will be >>>>>>>>>>>>> created on >>>>>>>>>>>>> the fly? >>>>>>>>>>>> >>>>>>>>>>>> Do you mean that it helps to leave the code in the AquaUtils >>>>>>>>>>>> class >>>>>>>>>>>> unchanged: >>>>>>>>>>>> --------------- >>>>>>>>>>>> 124 static Image generateLightenedImage(final Image image, >>>>>>>>>>>> final >>>>>>>>>>>> int percent) { >>>>>>>>>>>> 125 final GrayFilter filter = new GrayFilter(true, >>>>>>>>>>>> percent); >>>>>>>>>>>> 126 final ImageProducer prod = new >>>>>>>>>>>> FilteredImageSource(image.getSource(), filter); >>>>>>>>>>>> 127 return >>>>>>>>>>>> Toolkit.getDefaultToolkit().createImage(prod); >>>>>>>>>>>> 128 } >>>>>>>>>>>> --------------- >>>>>>>>>>>> >>>>>>>>>>>> or it is just an a better way for a filtered multi-resolution >>>>>>>>>>>> image >>>>>>>>>>>> generation? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> As I see, the way to solve it is only using >>>>>>>>>>>>>> MRI.getResolutionVariants() >>>>>>>>>>>>>> method for the MultiResolutionImageProducer creation. So the >>>>>>>>>>>>>> result of >>>>>>>>>>>>>> the call >>>>>>>>>>>>>> toolkit.createImage(new >>>>>>>>>>>>>> FilteredImageSource(mrImage.getSource(), >>>>>>>>>>>>>> filter)); >>>>>>>>>>>>>> will be a MRToolkitImage which is based on fixed number of >>>>>>>>>>>>>> filtered >>>>>>>>>>>>>> resolution variants from the original MRI. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> ...jim >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 3/11/16 5:42 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>>> On 09/03/16 16:58, Sergey Bylokhov wrote: >>>>>>>>>>>>>>>>> Probably we should enhance >>>>>>>>>>>>>>>>> ImageProducer/Tk.createImage/ImageFilter to >>>>>>>>>>>>>>>>> support this functionality? It seems that the number of >>>>>>>>>>>>>>>>> usage of >>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>> check "image instanceof MultiResolutionImage" will grow >>>>>>>>>>>>>>>>> over time. >>>>>>>>>>>>>>>> ImageProducer produces pixels for an image and is not >>>>>>>>>>>>>>>> able to >>>>>>>>>>>>>>>> take >>>>>>>>>>>>>>>> an information about the image resolution variants. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> May be we can add Toolkit.createImage(Image image, >>>>>>>>>>>>>>>> ImageFilter >>>>>>>>>>>>>>>> imageFilter) method which takes MultiResolutionImage into >>>>>>>>>>>>>>>> account to >>>>>>>>>>>>>>>> cover the common case where filtered image is created. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>> I think that at least our own API should support >>>>>>>>>>>>>>>>> MultiResolutionImage >>>>>>>>>>>>>>>>> w/o such checks, otherwise the user will need to do the >>>>>>>>>>>>>>>>> same. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> cc 2d-dev >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 09.03.16 15:30, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Could you review the fix: >>>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8151303 >>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8151303/webrev.00 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The AquaUtils does not take into account >>>>>>>>>>>>>>>>>> MultiResolutionImage >>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>> selected/disabled/lightened images generation. >>>>>>>>>>>>>>>>>> The fix also leaves the MultiResolutionCachedImage >>>>>>>>>>>>>>>>>> check because >>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> base system icon size can be differ from the requested >>>>>>>>>>>>>>>>>> painted >>>>>>>>>>>>>>>>>> size. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>> >>>>> >>> > From philip.race at oracle.com Thu Aug 11 21:29:54 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 11 Aug 2016 14:29:54 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-5049012: PrintToFile option is not disabled for flavors that do not support destination In-Reply-To: <577EE2B2.8020605@oracle.com> References: <57724BB4.40602@oracle.com> <5774137E.6090304@oracle.com> <5774CE17.2090209@oracle.com> <57752ABC.4020406@oracle.com> <57763688.4070806@oracle.com> <577EE2B2.8020605@oracle.com> Message-ID: <57ACEE52.1090906@oracle.com> It appears to me that this fix has caused a regression. When I bring up this dialog (on Linux) Print To File is always greyed out. I think somewhere along the line you became we concerned about whether specific value should grey it out or not that it got lost that is no longer possible to set this as a user even for SERVICE_FORMATTED. This is what I was thinking of when I wrote : >But I think there is still a problem. Now dstSupported is set only if >the *specific* destination is supported. Pls verify and file a new bug. -phil. On 07/07/2016 04:16 PM, Philip Race wrote: > Ok .. +1 > > -phil. > > On 7/1/16, 2:23 AM, Prasanta Sadhukhan wrote: >> Hi Phil, >> >> On 6/30/2016 7:50 PM, Philip Race wrote: >>> Eh ? Before your change the code was calling >>> isAttributeCategorySupported(), notisAttributeValueSupported() >>> >>> So there was not previously a possibility of that NPE, and >>> my point was now you have changed that call you need that !=null check >>> even more .. >> Yes, I got that, right immediately after sending the below mail and >> sent another email clarifying my misunderstanding. >>> >>> But I think there is still a problem. Now dstSupported is set only if >>> the *specific* destination is supported. >>> >>> A malformed file: URL would not be valid but should not >>> disable (grey out) the print to file checkbox which >>> is what it looks like here .. can you verify this ? >>> >> Yes, we will grey out the checkbox for malformed url (like >> files::/tmp/output.ps) as I found out. Please find modified webrev >> that takes care of this problem too: >> http://cr.openjdk.java.net/~psadhukhan/5049012/webrev.02/ >> >> Regards >> Prasanta >>> >>> -phil >>> >>> >>> >>> >>> On 6/30/16, 12:45 AM, Prasanta Sadhukhan wrote: >>>> Hi Phil, >>>> >>>> NPE will be thrown >>>> ---------- >>>> public boolean isAttributeValueSupported(Attribute attr, >>>> DocFlavor flavor, >>>> AttributeSet >>>> attributes) { >>>> if (attr == null) { >>>> throw new NullPointerException("null attribute"); >>>> } >>>> --------- >>>> before updateInfo() will be called so I guess null check is >>>> redundant there. Anyways, I have added the check back just to be safe >>>> http://cr.openjdk.java.net/~psadhukhan/5049012/webrev.01/ >>>> >>>> Regards >>>> Prasanta >>>> On 6/29/2016 11:59 PM, Philip Race wrote: >>>>> --- >>>>> https://docs.oracle.com/javase/8/docs/api/javax/print/PrintService.html#isAttributeValueSupported-javax.print.attribute.Attribute-javax.print.DocFlavor-javax.print.attribute.AttributeSet- >>>>> >>>>> >>>>> Throws: >>>>> NullPointerException - (unchecked exception) if attrval is null. >>>>> >>>>> -- >>>>> >>>>> So why did you remove the check for null ? >>>>> >>>>> >>>>> -phil. >>>>> >>>>> On 6/28/16, 3:04 AM, Prasanta Sadhukhan wrote: >>>>>> Hi All, >>>>>> >>>>>> Please review a fix for an issue where it is seen that >>>>>> "Print-To-File" option is enabled even for flavors that do not >>>>>> support Destination attribute >>>>>> even though isAttributeValueSupported for that flavor returns false. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-5049012 >>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/5049012/webrev.00/ >>>>>> >>>>>> The reason for this behaviour is in Print Dialog code, the >>>>>> validation is done against isAttributeCategorySupported() which >>>>>> still returns true because Pageable and Printable supports it >>>>>> and therefore the "Print-to-File" option gets enabled. >>>>>> >>>>>> But print dialog is shown specific to a doc flavor and a print >>>>>> service (selected one) and hence must validate the attribute >>>>>> against the chosen doc flavor. >>>>>> So, the proposed fix checks the attributevalue is supported or >>>>>> not for that flavor to determine if we need to enable >>>>>> "Print-to-File" option in print dialog. >>>>>> >>>>>> Regards >>>>>> Prasanta >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Aug 11 21:32:18 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 11 Aug 2016 14:32:18 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8145014: "IIOException: Couldn't seek!" when calling TIFFImageReader.getNumImages() In-Reply-To: References: <5DAD551E-3290-465A-8D70-2E266A99656D@oracle.com> <57AC0CE0.3010605@oracle.com> Message-ID: <57ACEEE2.20604@oracle.com> That is fine ... -phil. On 08/11/2016 06:59 AM, Brian Burkhalter wrote: > Rethinking this slightly, I think it might be good to changes lines 218 and 236 of TIFFImageReader from > > imageIndex = index - 1; > > to > > imageIndex = index > 0 ? index - 1 : 0; > > If that looks reasonable I will update the webrev in place and push the fix. > > Thanks, > > Brian > > On Aug 10, 2016, at 10:28 PM, Philip Race wrote: > >> +1 >> >> -phil. >> >> On 8/10/16, 7:36 PM, Brian Burkhalter wrote: >>> Please review at your convenience. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8145014 >>> Patch: http://cr.openjdk.java.net/~bpb/8145014/webrev.00/ >>> >>> In the locateImage() method handle zero-entry IFDs and EOFExceptions, hopefully returning the correct viable number of leading images in the stream with any bogus ones at the end being ignored. >>> >>> Thanks, >>> >>> Brian From philip.race at oracle.com Thu Aug 11 22:27:36 2016 From: philip.race at oracle.com (Philip Race) Date: Thu, 11 Aug 2016 15:27:36 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8145901: Printed content is overlapping. Message-ID: <57ACFBD8.9040105@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8145901 Webrev: http://cr.openjdk.java.net/~prr/8145901/ As per the evaluation in the bug this is an issue with the device scale being applied to the kerning adjustments made by the layout engine. The fix builds cleanly in JPRT and has been tested with the the JCK test in the bug report. I also did "on-screen" testing of various scripts and did not see any problems. -phil. From brian.burkhalter at oracle.com Fri Aug 12 01:26:05 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 11 Aug 2016 18:26:05 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8152966: ClassCastException when adding IFD to the TIFFDirectory before the image write Message-ID: Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8152966 Patch: http://cr.openjdk.java.net/~bpb/8152966/webrev.00/ Move the private method getDirectoryAsIFD(TIFFDirectory) from the API class TIFFDirectory to a public method in the internal class TIFFIFD and replace all casts such as TIFFDirectory dir; TIFFIFD ifd = (TIFFIFD)dir; with TIFFIFD ifd = TIFFIFD. getDirectoryAsIFD(dir); Thanks, Brian From prasanta.sadhukhan at oracle.com Fri Aug 12 05:22:17 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 12 Aug 2016 10:52:17 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8163922: Print-to-file is disabled for SERVICE_FORMATTED docflavor in linux Message-ID: <57AD5D09.2090606@oracle.com> Hi All, Please review a fix for an issue where it is seen that Print-to-File option is disabled even for SERVICE_FORMATTED DocFlavor after JDK-5049012 fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8163922 webrev: http://cr.openjdk.java.net/~psadhukhan/8163922/webrev.00/ We need to enabled dstSupported even if the destination is not specified for SERVICE_FORMATTED DocFlavor. Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Fri Aug 12 12:48:54 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 12 Aug 2016 15:48:54 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8139176: [macosx] java.awt.TextLayout does not handle correctly the bolded logical fonts In-Reply-To: <57AB998B.5060104@oracle.com> References: <57AB998B.5060104@oracle.com> Message-ID: <6e82f1d0-5bf6-14b0-9f2a-f714dc646322@oracle.com> Hi, Phil. A few comments about the test: - jtreg can stop the test at the end of the main, before invokeLater will start/complete.(on my system it always pass because of that) - The frame should be disposed at the end of the test. - Probably the correct location of the test is java/awt/font/TextLayout/? On 11.08.16 0:15, Philip Race wrote: > Equals was returning true because the full name is the same for > all members of the family. That in itself seems wrong .. no two > fonts should have the same name, but that will be addressed in > a follow-on fix. I assume the added code will be removed after follow-on fix? -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri Aug 12 13:06:33 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 12 Aug 2016 16:06:33 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: JDK-8158524: Test file added for VolatileImage -vs- BufferedImage output comparison In-Reply-To: <60d1ffac-ebdc-4b0a-a7b2-c62a67bc90d7@default> References: <57AC29D7.90605@oracle.com> <60d1ffac-ebdc-4b0a-a7b2-c62a67bc90d7@default> Message-ID: <7ad2d0be-1c49-f9b9-4b50-d3bab2b78139@oracle.com> Looks fine. Please add @key heedful jtreg tag before the push. On 11.08.16 13:22, Prahalad Kumar Narayanan wrote: > Hello Everyone > > First, Thanks to Prasanta for his feedback. > I 've incorporated the feedback in the code and changes are available for review. > Review Link: http://cr.openjdk.java.net/~pnarayanan/8158524/webrev.01/ > > Quick summary on changes from previous revision: > . Wild card imports have been replaced with specific imports > . @override annotation has been added to the paint() method > . RuntimeException is thrown instead of Error though both would report regression failure. > . Image loading has been corrected with proper filePath. > . With regard to image and licensing issue: > . I checked the image properties. There is no 'author/copyright' information with this image. > . The file matches when compared (binary) with the similar .gif image in test/java/awt/print/PrinterJob/ > > Kindly review the changes at your convenience and share your views. > > Thank you > Have a good day > > Prahalad N. > > > -----Original Message----- > From: Prasanta Sadhukhan > Sent: Thursday, August 11, 2016 1:02 PM > To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net > Cc: Philip Race; Sergey Bylokhov > Subject: Re: [OpenJDK 2D-Dev] [9] Review Request: JDK-8158524: Test file added for VolatileImage -vs- BufferedImage output comparison > > You need to use @Override annotation for paint() method. Also, you can use specific imports rather than package imports. > Also, I guess it's better to throw RuntimeException than Error for failure, not sure how jtreg will react to it. > Lastly, I am not sure if you can use duke.gif image which maynot be licensed although we have similar duke.gif in java/awt/print/PrinterJob. > > Regards > Prasanta > On 8/11/2016 11:30 AM, Prahalad Kumar Narayanan wrote: >> Hello Everyone >> >> Good day to you. >> >> I 'm planning to add a test file into jdk/test/ repository. >> The webrev changes for the test file is presented herewith. >> Link: >> http://cr.openjdk.java.net/~pnarayanan/8158524/webrev.00/ >> >> Brief on the test & its objectives: >> . As we know, VolatileImage utilizes accelerated rendering using GPU while BufferedImage utilizes software rendering >> . The objective of this test-case is to check whether the rendered 2d primitives appear same on VolatileImage and BufferedImage >> . In rare cases, the rendering on VolatileImage might differ by few pixels from BufferedImage due to D3D/OpenGL driver 's handling of primitives >> . Java2D pipelines for D3D/OpenGL APIs use fudge factors to fine tune rendering calls so that output matches with output of BufferedImage. >> . Thus the test case will help in checking for consistent rendering across pipelines and also in identifying scenarios where pipelines need to be fine-tuned. >> >> Kindly review the test file and share your views at your convenience >> >> Thank you >> Have a good day >> >> Prahalad N. > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri Aug 12 13:07:25 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 12 Aug 2016 16:07:25 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8139176: [macosx] java.awt.TextLayout does not handle correctly the bolded logical fonts In-Reply-To: <6e82f1d0-5bf6-14b0-9f2a-f714dc646322@oracle.com> References: <57AB998B.5060104@oracle.com> <6e82f1d0-5bf6-14b0-9f2a-f714dc646322@oracle.com> Message-ID: <5fc5e814-53ff-e064-c8ef-56067e6efbe5@oracle.com> On 12.08.16 15:48, Sergey Bylokhov wrote: > Hi, Phil. > A few comments about the test: > - jtreg can stop the test at the end of the main, before invokeLater > will start/complete.(on my system it always pass because of that) > - The frame should be disposed at the end of the test. > - Probably the correct location of the test is java/awt/font/TextLayout/? - I guess the test should have @key heedful jtreg tag. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri Aug 12 13:09:16 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 12 Aug 2016 16:09:16 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: JDK-8158524: Test file added for VolatileImage -vs- BufferedImage output comparison In-Reply-To: <7ad2d0be-1c49-f9b9-4b50-d3bab2b78139@oracle.com> References: <57AC29D7.90605@oracle.com> <60d1ffac-ebdc-4b0a-a7b2-c62a67bc90d7@default> <7ad2d0be-1c49-f9b9-4b50-d3bab2b78139@oracle.com> Message-ID: <508122c4-403d-f059-52f1-147e8c02f55f@oracle.com> On 12.08.16 16:06, Sergey Bylokhov wrote: > Looks fine. > Please add @key heedful jtreg tag before the push. Ouch I just realize that the test use the Swing components on non-EDT. > > On 11.08.16 13:22, Prahalad Kumar Narayanan wrote: >> Hello Everyone >> >> First, Thanks to Prasanta for his feedback. >> I 've incorporated the feedback in the code and changes are available >> for review. >> Review Link: >> http://cr.openjdk.java.net/~pnarayanan/8158524/webrev.01/ >> >> Quick summary on changes from previous revision: >> . Wild card imports have been replaced with specific imports >> . @override annotation has been added to the paint() method >> . RuntimeException is thrown instead of Error though both would >> report regression failure. >> . Image loading has been corrected with proper filePath. >> . With regard to image and licensing issue: >> . I checked the image properties. There is no >> 'author/copyright' information with this image. >> . The file matches when compared (binary) with the >> similar .gif image in test/java/awt/print/PrinterJob/ >> >> Kindly review the changes at your convenience and share your views. >> >> Thank you >> Have a good day >> >> Prahalad N. >> >> >> -----Original Message----- >> From: Prasanta Sadhukhan >> Sent: Thursday, August 11, 2016 1:02 PM >> To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net >> Cc: Philip Race; Sergey Bylokhov >> Subject: Re: [OpenJDK 2D-Dev] [9] Review Request: JDK-8158524: Test >> file added for VolatileImage -vs- BufferedImage output comparison >> >> You need to use @Override annotation for paint() method. Also, you can >> use specific imports rather than package imports. >> Also, I guess it's better to throw RuntimeException than Error for >> failure, not sure how jtreg will react to it. >> Lastly, I am not sure if you can use duke.gif image which maynot be >> licensed although we have similar duke.gif in java/awt/print/PrinterJob. >> >> Regards >> Prasanta >> On 8/11/2016 11:30 AM, Prahalad Kumar Narayanan wrote: >>> Hello Everyone >>> >>> Good day to you. >>> >>> I 'm planning to add a test file into jdk/test/ repository. >>> The webrev changes for the test file is presented herewith. >>> Link: >>> http://cr.openjdk.java.net/~pnarayanan/8158524/webrev.00/ >>> >>> Brief on the test & its objectives: >>> . As we know, VolatileImage utilizes accelerated rendering >>> using GPU while BufferedImage utilizes software rendering >>> . The objective of this test-case is to check whether the >>> rendered 2d primitives appear same on VolatileImage and BufferedImage >>> . In rare cases, the rendering on VolatileImage might differ >>> by few pixels from BufferedImage due to D3D/OpenGL driver 's handling >>> of primitives >>> . Java2D pipelines for D3D/OpenGL APIs use fudge >>> factors to fine tune rendering calls so that output matches with >>> output of BufferedImage. >>> . Thus the test case will help in checking for >>> consistent rendering across pipelines and also in identifying >>> scenarios where pipelines need to be fine-tuned. >>> >>> Kindly review the test file and share your views at your convenience >>> >>> Thank you >>> Have a good day >>> >>> Prahalad N. >> > > -- Best regards, Sergey. From philip.race at oracle.com Fri Aug 12 17:11:46 2016 From: philip.race at oracle.com (Philip Race) Date: Fri, 12 Aug 2016 10:11:46 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8139176: [macosx] java.awt.TextLayout does not handle correctly the bolded logical fonts In-Reply-To: <6e82f1d0-5bf6-14b0-9f2a-f714dc646322@oracle.com> References: <57AB998B.5060104@oracle.com> <6e82f1d0-5bf6-14b0-9f2a-f714dc646322@oracle.com> Message-ID: <57AE0352.3040509@oracle.com> On 8/12/16, 5:48 AM, Sergey Bylokhov wrote: > Hi, Phil. > A few comments about the test: > - jtreg can stop the test at the end of the main, before invokeLater > will start/complete.(on my system it always pass because of that) hmm. The only reason this test shows a window is to be helpful to humans. I think I'll make jtreg just draw to a BI and the UI only be there for the "interactive" mode which is meant to be used outside jtreg. That will dispense with (get rid of) the need for @headful too. > - The frame should be disposed at the end of the test. OK .. perhaps also non-essential if I make the above change > - Probably the correct location of the test is > java/awt/font/TextLayout/? OK. I will tweak the test and resubmit shortly. > > On 11.08.16 0:15, Philip Race wrote: >> Equals was returning true because the full name is the same for >> all members of the family. That in itself seems wrong .. no two >> fonts should have the same name, but that will be addressed in >> a follow-on fix. > > I assume the added code will be removed after follow-on fix? It does not have to be .. it is harmless and perhaps useful. I was thinking of leaving it. -phil. > From philip.race at oracle.com Fri Aug 12 17:15:41 2016 From: philip.race at oracle.com (Philip Race) Date: Fri, 12 Aug 2016 10:15:41 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8139176: [macosx] java.awt.TextLayout does not handle correctly the bolded logical fonts In-Reply-To: <57AE0352.3040509@oracle.com> References: <57AB998B.5060104@oracle.com> <6e82f1d0-5bf6-14b0-9f2a-f714dc646322@oracle.com> <57AE0352.3040509@oracle.com> Message-ID: <57AE043D.9040906@oracle.com> Updated test : http://cr.openjdk.java.net/~prr/8139176.1/ -phil. On 8/12/16, 10:11 AM, Philip Race wrote: > > > On 8/12/16, 5:48 AM, Sergey Bylokhov wrote: >> Hi, Phil. >> A few comments about the test: >> - jtreg can stop the test at the end of the main, before invokeLater >> will start/complete.(on my system it always pass because of that) > > hmm. The only reason this test shows a window is to be helpful to humans. > I think I'll make jtreg just draw to a BI and the UI only be there for > the "interactive" mode > which is meant to be used outside jtreg. > That will dispense with (get rid of) the need for @headful too. > >> - The frame should be disposed at the end of the test. > OK .. perhaps also non-essential if I make the above change >> - Probably the correct location of the test is >> java/awt/font/TextLayout/? > > OK. > > I will tweak the test and resubmit shortly. >> >> On 11.08.16 0:15, Philip Race wrote: >>> Equals was returning true because the full name is the same for >>> all members of the family. That in itself seems wrong .. no two >>> fonts should have the same name, but that will be addressed in >>> a follow-on fix. >> >> I assume the added code will be removed after follow-on fix? > > It does not have to be .. it is harmless and perhaps useful. I was > thinking of leaving it. > > -phil. >> From Sergey.Bylokhov at oracle.com Fri Aug 12 17:20:48 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 12 Aug 2016 20:20:48 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8139176: [macosx] java.awt.TextLayout does not handle correctly the bolded logical fonts In-Reply-To: <57AE0352.3040509@oracle.com> References: <57AB998B.5060104@oracle.com> <6e82f1d0-5bf6-14b0-9f2a-f714dc646322@oracle.com> <57AE0352.3040509@oracle.com> Message-ID: <664b55b7-be5a-fc52-7f2c-310c2f6039dc@oracle.com> On 12.08.16 20:11, Philip Race wrote: > >> I assume the added code will be removed after follow-on fix? > > It does not have to be .. it is harmless and perhaps useful. I was > thinking of leaving it. Then probably it can be added to the PhysicalFont itself? -- Best regards, Sergey. From philip.race at oracle.com Fri Aug 12 17:23:06 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 12 Aug 2016 10:23:06 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8139176: [macosx] java.awt.TextLayout does not handle correctly the bolded logical fonts In-Reply-To: <664b55b7-be5a-fc52-7f2c-310c2f6039dc@oracle.com> References: <57AB998B.5060104@oracle.com> <6e82f1d0-5bf6-14b0-9f2a-f714dc646322@oracle.com> <57AE0352.3040509@oracle.com> <664b55b7-be5a-fc52-7f2c-310c2f6039dc@oracle.com> Message-ID: <57AE05FA.8080509@oracle.com> On 08/12/2016 10:20 AM, Sergey Bylokhov wrote: > On 12.08.16 20:11, Philip Race wrote: >> >>> I assume the added code will be removed after follow-on fix? >> >> It does not have to be .. it is harmless and perhaps useful. I was >> thinking of leaving it. > > Then probably it can be added to the PhysicalFont itself? I did not want to touch shared code at all and the other cases may treat the style a little differently. So harmless on CFont .. -phil. > > From brian.burkhalter at oracle.com Fri Aug 12 18:23:29 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 12 Aug 2016 11:23:29 -0700 Subject: [OpenJDK 2D-Dev] [9] RFC JDK-8154058: [TIFF] ignoreMetadata parameter of TIFFImageReader's setInput() method affects TIFFImageReadParam in non-obvious way Message-ID: <7E7ACA58-AA5C-4352-979C-638993C8B7DF@oracle.com> Please comment at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8154058 Solution: Resolve as ?Not an Issue? According to [1], The ignoreMetadata parameter, if set to true, allows the reader to disregard any metadata encountered during the read. Subsequent calls to the getStreamMetadata and getImageMetadata methods may return null, and an IIOImage returned from readAll may return null from their getMetadata method. Setting this parameter may allow the reader to work more efficiently. The reader may choose to disregard this setting and return metadata normally. According to [2], setting ignoreMetadata has the effect of asking the reader to ignore any TIFF Fields which are not contained in any of the TIFFTagSets known to the reader. This seems to be within the scope of the specification in [1]. As a result of the foregoing I suggest that the issue be resolved as ?Will not Fix.? Thanks, Brian [1] http://download.java.net/java/jdk9/docs/api/javax/imageio/ImageReader.html#setInput-java.lang.Object-boolean-boolean- [2] http://hg.openjdk.java.net/jdk9/client/jdk/file/d5dc0c4fb473/src/java.desktop/share/classes/javax/imageio/metadata/doc-files/tiff_metadata.html, lines 219-234 -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Aug 12 18:27:34 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 12 Aug 2016 11:27:34 -0700 Subject: [OpenJDK 2D-Dev] [9] RFC JDK-8154058: [TIFF] ignoreMetadata parameter of TIFFImageReader's setInput() method affects TIFFImageReadParam in non-obvious way In-Reply-To: <7E7ACA58-AA5C-4352-979C-638993C8B7DF@oracle.com> References: <7E7ACA58-AA5C-4352-979C-638993C8B7DF@oracle.com> Message-ID: <6C4DB937-B2A7-4934-B190-480BA8CC1769@oracle.com> Correction (bee below). On Aug 12, 2016, at 11:23 AM, Brian Burkhalter wrote: > Please comment at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8154058 > Solution: Resolve as ?Not an Issue? > > According to [1], > > The ignoreMetadata parameter, if set to true, allows the reader to disregard any metadata encountered during the read. Subsequent calls to the getStreamMetadata and getImageMetadata methods may return null, and an IIOImage returned from readAll may return null from their getMetadata method. Setting this parameter may allow the reader to work more efficiently. The reader may choose to disregard this setting and return metadata normally. > > According to [2], setting ignoreMetadata has the effect of asking the reader to ignore any TIFF Fields which are not contained in any of the TIFFTagSets known to the reader. This seems to be within the scope of the specification in [1]. > > As a result of the foregoing I suggest that the issue be resolved as ?Will not Fix.? ?Will not Fix? in the previous sentence should have been ?Not an Issue." > Thanks, > > Brian > > [1] http://download.java.net/java/jdk9/docs/api/javax/imageio/ImageReader.html#setInput-java.lang.Object-boolean-boolean- > [2] http://hg.openjdk.java.net/jdk9/client/jdk/file/d5dc0c4fb473/src/java.desktop/share/classes/javax/imageio/metadata/doc-files/tiff_metadata.html, lines 219-234 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Fri Aug 12 19:28:11 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 12 Aug 2016 22:28:11 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8139176: [macosx] java.awt.TextLayout does not handle correctly the bolded logical fonts In-Reply-To: <57AE043D.9040906@oracle.com> References: <57AB998B.5060104@oracle.com> <6e82f1d0-5bf6-14b0-9f2a-f714dc646322@oracle.com> <57AE0352.3040509@oracle.com> <57AE043D.9040906@oracle.com> Message-ID: <98f20b9e-50df-1407-ba22-0c83d2b3c4a8@oracle.com> Looks fine. On 12.08.16 20:15, Philip Race wrote: > Updated test : http://cr.openjdk.java.net/~prr/8139176.1/ > > -phil. > > On 8/12/16, 10:11 AM, Philip Race wrote: >> >> >> On 8/12/16, 5:48 AM, Sergey Bylokhov wrote: >>> Hi, Phil. >>> A few comments about the test: >>> - jtreg can stop the test at the end of the main, before invokeLater >>> will start/complete.(on my system it always pass because of that) >> >> hmm. The only reason this test shows a window is to be helpful to humans. >> I think I'll make jtreg just draw to a BI and the UI only be there for >> the "interactive" mode >> which is meant to be used outside jtreg. >> That will dispense with (get rid of) the need for @headful too. >> >>> - The frame should be disposed at the end of the test. >> OK .. perhaps also non-essential if I make the above change >>> - Probably the correct location of the test is >>> java/awt/font/TextLayout/? >> >> OK. >> >> I will tweak the test and resubmit shortly. >>> >>> On 11.08.16 0:15, Philip Race wrote: >>>> Equals was returning true because the full name is the same for >>>> all members of the family. That in itself seems wrong .. no two >>>> fonts should have the same name, but that will be addressed in >>>> a follow-on fix. >>> >>> I assume the added code will be removed after follow-on fix? >> >> It does not have to be .. it is harmless and perhaps useful. I was >> thinking of leaving it. >> >> -phil. >>> -- Best regards, Sergey. From philip.race at oracle.com Fri Aug 12 21:14:58 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 12 Aug 2016 14:14:58 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8152966: ClassCastException when adding IFD to the TIFFDirectory before the image write In-Reply-To: References: Message-ID: <57AE3C52.3030306@oracle.com> +1 -phil. On 08/11/2016 06:26 PM, Brian Burkhalter wrote: > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8152966 > Patch: http://cr.openjdk.java.net/~bpb/8152966/webrev.00/ > > Move the private method getDirectoryAsIFD(TIFFDirectory) from the API class TIFFDirectory to a public method in the internal class TIFFIFD and replace all casts such as > > TIFFDirectory dir; > TIFFIFD ifd = (TIFFIFD)dir; > > with > > TIFFIFD ifd = TIFFIFD. getDirectoryAsIFD(dir); > > Thanks, > > Brian From alexandr.scherbatiy at oracle.com Mon Aug 15 15:47:01 2016 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 15 Aug 2016 19:47:01 +0400 Subject: [OpenJDK 2D-Dev] [9] Review request for 8151303 [macosx] [hidpi] JButton's low-res. icon is visible when clicking on it In-Reply-To: <94c984b2-5c38-8708-5d3d-de5a05e797b1@oracle.com> References: <56E01777.1030202@oracle.com> <56E01DE7.9040103@oracle.com> <56E2CB4F.6040301@oracle.com> <56E3277B.3000309@oracle.com> <56E815C3.40208@oracle.com> <56E816E9.1010308@oracle.com> <56E839DC.2040904@oracle.com> <56F01921.6060305@oracle.com> <56F03E0B.1080703@oracle.com> <5734B8AB.7070908@oracle.com> <0f87bf94-13c3-160b-d1f6-c95b959299bb@oracle.com> <6c50a4f1-b2e6-f447-18a9-57843a6a517e@oracle.com> <331c7407-0f8c-205c-f3a5-db3ac2f32398@oracle.com> <3dcd98ac-18cd-dfc4-b3f9-276b72aea9a2@oracle.com> <2bd157b4-3bfc-032b-498a-d5f00645cb8c@oracle.com> <850cefda-57f4-8dfb-66ad-907d050b04fa@oracle.com> <94c984b2-5c38-8708-5d3d-de5a05e797b1@oracle.com> Message-ID: Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8151303/webrev.04 The MRCI.sizes arrays is reused for for MultiResolutionCachedImage. Thanks, Alexandr. On 11/08/16 23:10, Jim Graham wrote: > Hi Alexandr, > > Should something be done to transfer the array of sizes to the new > instance if the source is an MRCI? Perhaps a special case for MRCI as > well that calls mrciInstance.map(mapper) instead of constructing a > brand new object from scratch? > > ...jim > > On 08/11/2016 01:32 AM, Alexander Scherbatiy wrote: >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8151303/webrev.03 >> >> MultiResolutionToolkitImage handing is added to the >> MultiResolutionCachedImage.map() method. >> >> Thanks, >> Alexandr. >> >> On 11/08/16 01:46, Jim Graham wrote: >>> Ah, yes, only ToolkitImages can be "not yet loaded" in that manner. >>> >>> A quick look suggests that a MRCI should not be an instance of MRTI, >>> but MRCI.map() does not force its argument to be an instance of MRCI, >>> just MRI, so it would be possible for someone to pass an MRTI to >>> MRCI.map() and then it would have this problem. >>> >>> Should we change the argument of MRCI.map() to MRCI? (And then you >>> don't need to cast to Image and use getWidth/Height(Observer) to get >>> its dimensions.) >>> >>> If that is not feasible, we should have it do something different for >>> a non-MRCI... >>> >>> ...jim >>> >>> On 8/10/16 5:35 AM, Alexander Scherbatiy wrote: >>>> On 09/08/16 03:49, Jim Graham wrote: >>>>> Does MultiResolutionCachedImage.map() work if the Image hasn't been >>>>> loaded yet (where getWidth/Height(Observer) can >>>>> return -1)? Can it ever be called in a case like that? >>>> >>>> Could we rely on the fact that getWidth/Height(Observer) returns -1 >>>> only for ToolkitImage? >>>> >>>> If so, the passed MultiResolutionToolkitImage is handled in >>>> MultiResolutionToolkitImage.map() method. >>>> If no, the fix should be updated to load the image size in some way. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>> >>>>> ...jim >>>>> >>>>> On 08/08/2016 12:48 PM, Alexander Scherbatiy wrote: >>>>>> >>>>>> Just a friendly reminder. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> On 27/06/16 22:17, Alexander Scherbatiy wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Could you review the updated fix: >>>>>>> http://cr.openjdk.java.net/~alexsch/8151303/webrev.02 >>>>>>> >>>>>>> The fix does not use a new public API to apply filters to >>>>>>> multi-resolution images. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> >>>>>>> On 14/05/16 02:54, Jim Graham wrote: >>>>>>>> Another reason to avoid new API is that we don't have to >>>>>>>> involve the >>>>>>>> CCC to get this "bug fix" in... >>>>>>>> >>>>>>>> ...jim >>>>>>>> >>>>>>>> On 5/13/16 3:50 PM, Jim Graham wrote: >>>>>>>>> That looks very tight. The only issue I'd have is that it >>>>>>>>> would be >>>>>>>>> better if this could be done with non-public API for >>>>>>>>> now - the map() methods could live on one of the sun.awt.image >>>>>>>>> classes or even in a Swing implementation utility class >>>>>>>>> and still work just fine. When we have more time to figure >>>>>>>>> out how >>>>>>>>> we're going to handle filtering of MRIs in general >>>>>>>>> we can decide if this API should live on the base MRI interface. >>>>>>>>> >>>>>>>>> The only thing we'd lose is BaseMRI having an optimized >>>>>>>>> implementation of the map() method, but I don't think it's >>>>>>>>> implementation represents enough of an optimization to matter >>>>>>>>> when >>>>>>>>> we are creating and loading dozens of images... >>>>>>>>> >>>>>>>>> ...jim >>>>>>>>> >>>>>>>>> On 5/12/16 10:08 AM, Alexander Scherbatiy wrote: >>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Could you review the updated fix: >>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8151303/webrev.01 >>>>>>>>>> >>>>>>>>>> There was a suggestion to postpone the fix for the issue 8152309 >>>>>>>>>> Seamless way of using image filters with >>>>>>>>>> multi-resolution images >>>>>>>>>> and continue with the current one: >>>>>>>>>> http://mail.openjdk.java.net/pipermail/2d-dev/2016-April/006766.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The new version of the fix introduces a mapper method which >>>>>>>>>> allows >>>>>>>>>> to map all resolution variants of one >>>>>>>>>> multi-resolution image to another: >>>>>>>>>> ------------ >>>>>>>>>> Image image = // original image >>>>>>>>>> Image filteredImage = MultiResolutionImage.map(image, >>>>>>>>>> (img) -> >>>>>>>>>> /* return filtered image */); >>>>>>>>>> ------------ >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>> On 21/03/16 22:31, Jim Graham wrote: >>>>>>>>>>> We could do that for our own filters, but any random custom >>>>>>>>>>> filter >>>>>>>>>>> could run into the same issue, so it might not make >>>>>>>>>>> sense to upgrade the existing filter mechanism to always >>>>>>>>>>> attempt >>>>>>>>>>> to do MR filtering. We could either create a >>>>>>>>>>> parallel set of MR-aware filter mechanisms (such as the >>>>>>>>>>> previously >>>>>>>>>>> suggested new method on Toolkit, or a new MR-aware >>>>>>>>>>> version of FilteredImageSource for instance) and leave the >>>>>>>>>>> existing mechanism as clearly documented as MR-unaware. >>>>>>>>>>> Another idea is to tag a filter with an interface that >>>>>>>>>>> indicates >>>>>>>>>>> that it is MR aware? In any case, some thought needs >>>>>>>>>>> to be given to feeding an MR image to a filter that >>>>>>>>>>> (potentially >>>>>>>>>>> or demonstrably) cannot deal with MR images. >>>>>>>>>>> >>>>>>>>>>> Alternately, we could then recommend that the old image >>>>>>>>>>> filtering >>>>>>>>>>> code isn't combined with multi-resolution images. >>>>>>>>>>> It seems to me that the programmer is mostly in control over >>>>>>>>>>> this >>>>>>>>>>> happening since they've either manually created the >>>>>>>>>>> MR image using the custiom MR image mechanism or they've >>>>>>>>>>> supplied >>>>>>>>>>> media with multiple resolution files (i.e. "@2x"). >>>>>>>>>>> Is that really the case? >>>>>>>>>>> >>>>>>>>>>> Whether it is a new filtering mechanism that must be adopted or >>>>>>>>>>> simply declaring the old filtering mechanism as >>>>>>>>>>> "obsolete with respect to MR images"... >>>>>>>>>>> >>>>>>>>>>> That recommendation then "restricts forward" in that, for >>>>>>>>>>> example, >>>>>>>>>>> since Swing relies on the old mechanism, Swing then >>>>>>>>>>> becomes "not recommended for use with MR images", or "not MR >>>>>>>>>>> aware". That's probably not a restriction we want to >>>>>>>>>>> promote so it should be viewed as a temporary restriction >>>>>>>>>>> reality >>>>>>>>>>> and a bug that we'll fix soon, whether by using some >>>>>>>>>>> other mechanism to achieve the desired affects, or creating >>>>>>>>>>> a new >>>>>>>>>>> MR-aware filtering mechanism and using it in Swing. >>>>>>>>>>> >>>>>>>>>>> Similarly, other 3rd party libraries that accept images and do >>>>>>>>>>> anything more than display them will have to be >>>>>>>>>>> upgraded as well before they become "MR aware" or "MR >>>>>>>>>>> accepting" >>>>>>>>>>> or whatever term applies here... >>>>>>>>>>> >>>>>>>>>>> ...jim >>>>>>>>>>> >>>>>>>>>>> On 3/21/16 8:54 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>> >>>>>>>>>>>> The one more thing is that image filters should also be >>>>>>>>>>>> updated >>>>>>>>>>>> to use >>>>>>>>>>>> them with multi-resolution images. >>>>>>>>>>>> For example, consider the case: >>>>>>>>>>>> ---------- >>>>>>>>>>>> Image mrImage = getMultiResolutionImage(); >>>>>>>>>>>> ImageProducer mriProducer = new >>>>>>>>>>>> FilteredImageSource(mrImage.getSource(), new >>>>>>>>>>>> CropImageFilter(0, >>>>>>>>>>>> 0, w, h)); >>>>>>>>>>>> Toolkit.getDefaultToolkit().createImage(mriProducer); >>>>>>>>>>>> ---------- >>>>>>>>>>>> >>>>>>>>>>>> The crop image filter applied to each resolution variant just >>>>>>>>>>>> cuts >>>>>>>>>>>> images with the same size. >>>>>>>>>>>> It seems that there should be added API which allows to set a >>>>>>>>>>>> scale for >>>>>>>>>>>> a provided image filter to be properly used with the given >>>>>>>>>>>> resolution >>>>>>>>>>>> variant. >>>>>>>>>>>> >>>>>>>>>>>> I have created a separated issue for multi-resolution images >>>>>>>>>>>> filtering >>>>>>>>>>>> support: >>>>>>>>>>>> JDK-8152309 Seamless way of using image filters with >>>>>>>>>>>> multi-resolution >>>>>>>>>>>> images >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152309 >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>> On 15/03/16 20:35, Alexander Scherbatiy wrote: >>>>>>>>>>>>> On 15/03/16 18:06, Sergey Bylokhov wrote: >>>>>>>>>>>>>> On 15.03.16 17:01, Alexander Scherbatiy wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> One update will be that FilteredImageSource should >>>>>>>>>>>>>>> implement >>>>>>>>>>>>>>> MultiResolutionImageProducer even it is used for non >>>>>>>>>>>>>>> multi-resolution >>>>>>>>>>>>>>> images. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The MRI can be created using two general ways: using >>>>>>>>>>>>>>> fixed >>>>>>>>>>>>>>> number of >>>>>>>>>>>>>>> resolution variants or generating a resolution variant with >>>>>>>>>>>>>>> necessary >>>>>>>>>>>>>>> quality on demand. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The current implementation is rely on that MRToolkitImage >>>>>>>>>>>>>>> contains a >>>>>>>>>>>>>>> fixed number of resolution variants. In this case >>>>>>>>>>>>>>> MediaTracker >>>>>>>>>>>>>>> can >>>>>>>>>>>>>>> iterate over resolution variants and load them all. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Using MultiResolutionImageProducer leads that >>>>>>>>>>>>>>> MRToolkitImage >>>>>>>>>>>>>>> will not >>>>>>>>>>>>>>> know about number of resolution variants in case when they >>>>>>>>>>>>>>> are >>>>>>>>>>>>>>> generated >>>>>>>>>>>>>>> on the fly and there will be no way to load all of them by >>>>>>>>>>>>>>> MediaTracker. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Just an idea to thinking about, can we save this filter to >>>>>>>>>>>>>> the MRI >>>>>>>>>>>>>> itself and apply it after some resolution variant will be >>>>>>>>>>>>>> created on >>>>>>>>>>>>>> the fly? >>>>>>>>>>>>> >>>>>>>>>>>>> Do you mean that it helps to leave the code in the AquaUtils >>>>>>>>>>>>> class >>>>>>>>>>>>> unchanged: >>>>>>>>>>>>> --------------- >>>>>>>>>>>>> 124 static Image generateLightenedImage(final Image >>>>>>>>>>>>> image, >>>>>>>>>>>>> final >>>>>>>>>>>>> int percent) { >>>>>>>>>>>>> 125 final GrayFilter filter = new GrayFilter(true, >>>>>>>>>>>>> percent); >>>>>>>>>>>>> 126 final ImageProducer prod = new >>>>>>>>>>>>> FilteredImageSource(image.getSource(), filter); >>>>>>>>>>>>> 127 return >>>>>>>>>>>>> Toolkit.getDefaultToolkit().createImage(prod); >>>>>>>>>>>>> 128 } >>>>>>>>>>>>> --------------- >>>>>>>>>>>>> >>>>>>>>>>>>> or it is just an a better way for a filtered >>>>>>>>>>>>> multi-resolution >>>>>>>>>>>>> image >>>>>>>>>>>>> generation? >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> As I see, the way to solve it is only using >>>>>>>>>>>>>>> MRI.getResolutionVariants() >>>>>>>>>>>>>>> method for the MultiResolutionImageProducer creation. So >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> result of >>>>>>>>>>>>>>> the call >>>>>>>>>>>>>>> toolkit.createImage(new >>>>>>>>>>>>>>> FilteredImageSource(mrImage.getSource(), >>>>>>>>>>>>>>> filter)); >>>>>>>>>>>>>>> will be a MRToolkitImage which is based on fixed >>>>>>>>>>>>>>> number of >>>>>>>>>>>>>>> filtered >>>>>>>>>>>>>>> resolution variants from the original MRI. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ...jim >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 3/11/16 5:42 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>>>> On 09/03/16 16:58, Sergey Bylokhov wrote: >>>>>>>>>>>>>>>>>> Probably we should enhance >>>>>>>>>>>>>>>>>> ImageProducer/Tk.createImage/ImageFilter to >>>>>>>>>>>>>>>>>> support this functionality? It seems that the number of >>>>>>>>>>>>>>>>>> usage of >>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>> check "image instanceof MultiResolutionImage" will grow >>>>>>>>>>>>>>>>>> over time. >>>>>>>>>>>>>>>>> ImageProducer produces pixels for an image and is not >>>>>>>>>>>>>>>>> able to >>>>>>>>>>>>>>>>> take >>>>>>>>>>>>>>>>> an information about the image resolution variants. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> May be we can add Toolkit.createImage(Image image, >>>>>>>>>>>>>>>>> ImageFilter >>>>>>>>>>>>>>>>> imageFilter) method which takes MultiResolutionImage into >>>>>>>>>>>>>>>>> account to >>>>>>>>>>>>>>>>> cover the common case where filtered image is created. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>> I think that at least our own API should support >>>>>>>>>>>>>>>>>> MultiResolutionImage >>>>>>>>>>>>>>>>>> w/o such checks, otherwise the user will need to do the >>>>>>>>>>>>>>>>>> same. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> cc 2d-dev >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 09.03.16 15:30, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Could you review the fix: >>>>>>>>>>>>>>>>>>> bug: >>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151303 >>>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8151303/webrev.00 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The AquaUtils does not take into account >>>>>>>>>>>>>>>>>>> MultiResolutionImage >>>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>> selected/disabled/lightened images generation. >>>>>>>>>>>>>>>>>>> The fix also leaves the MultiResolutionCachedImage >>>>>>>>>>>>>>>>>>> check because >>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>> base system icon size can be differ from the requested >>>>>>>>>>>>>>>>>>> painted >>>>>>>>>>>>>>>>>>> size. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>>> >>>> >> From james.graham at oracle.com Mon Aug 15 18:19:23 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 15 Aug 2016 11:19:23 -0700 Subject: [OpenJDK 2D-Dev] [9] Review request for 8151303 [macosx] [hidpi] JButton's low-res. icon is visible when clicking on it In-Reply-To: References: <56E01777.1030202@oracle.com> <56E01DE7.9040103@oracle.com> <56E2CB4F.6040301@oracle.com> <56E3277B.3000309@oracle.com> <56E815C3.40208@oracle.com> <56E816E9.1010308@oracle.com> <56E839DC.2040904@oracle.com> <56F01921.6060305@oracle.com> <56F03E0B.1080703@oracle.com> <5734B8AB.7070908@oracle.com> <0f87bf94-13c3-160b-d1f6-c95b959299bb@oracle.com> <6c50a4f1-b2e6-f447-18a9-57843a6a517e@oracle.com> <331c7407-0f8c-205c-f3a5-db3ac2f32398@oracle.com> <3dcd98ac-18cd-dfc4-b3f9-276b72aea9a2@oracle.com> <2bd157b4-3bfc-032b-498a-d5f00645cb8c@oracle.com> <850cefda-57f4-8dfb-66ad-907d050b04fa@oracle.com> <94c984b2-5c38-8708-5d3d-de5a05e797b1@oracle.com> Message-ID: <97ffae8e-24b6-563a-32b3-66f773a23726@oracle.com> Looks good. +1 ...jim On 08/15/2016 08:47 AM, Alexander Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8151303/webrev.04 > > The MRCI.sizes arrays is reused for for MultiResolutionCachedImage. > > Thanks, > Alexandr. > > On 11/08/16 23:10, Jim Graham wrote: >> Hi Alexandr, >> >> Should something be done to transfer the array of sizes to the new >> instance if the source is an MRCI? Perhaps a special case for MRCI as >> well that calls mrciInstance.map(mapper) instead of constructing a >> brand new object from scratch? >> >> ...jim >> >> On 08/11/2016 01:32 AM, Alexander Scherbatiy wrote: >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8151303/webrev.03 >>> >>> MultiResolutionToolkitImage handing is added to the >>> MultiResolutionCachedImage.map() method. >>> >>> Thanks, >>> Alexandr. >>> >>> On 11/08/16 01:46, Jim Graham wrote: >>>> Ah, yes, only ToolkitImages can be "not yet loaded" in that manner. >>>> >>>> A quick look suggests that a MRCI should not be an instance of MRTI, >>>> but MRCI.map() does not force its argument to be an instance of MRCI, >>>> just MRI, so it would be possible for someone to pass an MRTI to >>>> MRCI.map() and then it would have this problem. >>>> >>>> Should we change the argument of MRCI.map() to MRCI? (And then you >>>> don't need to cast to Image and use getWidth/Height(Observer) to get >>>> its dimensions.) >>>> >>>> If that is not feasible, we should have it do something different for >>>> a non-MRCI... >>>> >>>> ...jim >>>> >>>> On 8/10/16 5:35 AM, Alexander Scherbatiy wrote: >>>>> On 09/08/16 03:49, Jim Graham wrote: >>>>>> Does MultiResolutionCachedImage.map() work if the Image hasn't been >>>>>> loaded yet (where getWidth/Height(Observer) can >>>>>> return -1)? Can it ever be called in a case like that? >>>>> >>>>> Could we rely on the fact that getWidth/Height(Observer) returns -1 >>>>> only for ToolkitImage? >>>>> >>>>> If so, the passed MultiResolutionToolkitImage is handled in >>>>> MultiResolutionToolkitImage.map() method. >>>>> If no, the fix should be updated to load the image size in some way. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>>> >>>>>> ...jim >>>>>> >>>>>> On 08/08/2016 12:48 PM, Alexander Scherbatiy wrote: >>>>>>> >>>>>>> Just a friendly reminder. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> On 27/06/16 22:17, Alexander Scherbatiy wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> Could you review the updated fix: >>>>>>>> http://cr.openjdk.java.net/~alexsch/8151303/webrev.02 >>>>>>>> >>>>>>>> The fix does not use a new public API to apply filters to >>>>>>>> multi-resolution images. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>> >>>>>>>> On 14/05/16 02:54, Jim Graham wrote: >>>>>>>>> Another reason to avoid new API is that we don't have to >>>>>>>>> involve the >>>>>>>>> CCC to get this "bug fix" in... >>>>>>>>> >>>>>>>>> ...jim >>>>>>>>> >>>>>>>>> On 5/13/16 3:50 PM, Jim Graham wrote: >>>>>>>>>> That looks very tight. The only issue I'd have is that it >>>>>>>>>> would be >>>>>>>>>> better if this could be done with non-public API for >>>>>>>>>> now - the map() methods could live on one of the sun.awt.image >>>>>>>>>> classes or even in a Swing implementation utility class >>>>>>>>>> and still work just fine. When we have more time to figure >>>>>>>>>> out how >>>>>>>>>> we're going to handle filtering of MRIs in general >>>>>>>>>> we can decide if this API should live on the base MRI interface. >>>>>>>>>> >>>>>>>>>> The only thing we'd lose is BaseMRI having an optimized >>>>>>>>>> implementation of the map() method, but I don't think it's >>>>>>>>>> implementation represents enough of an optimization to matter >>>>>>>>>> when >>>>>>>>>> we are creating and loading dozens of images... >>>>>>>>>> >>>>>>>>>> ...jim >>>>>>>>>> >>>>>>>>>> On 5/12/16 10:08 AM, Alexander Scherbatiy wrote: >>>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> Could you review the updated fix: >>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8151303/webrev.01 >>>>>>>>>>> >>>>>>>>>>> There was a suggestion to postpone the fix for the issue 8152309 >>>>>>>>>>> Seamless way of using image filters with >>>>>>>>>>> multi-resolution images >>>>>>>>>>> and continue with the current one: >>>>>>>>>>> http://mail.openjdk.java.net/pipermail/2d-dev/2016-April/006766.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The new version of the fix introduces a mapper method which >>>>>>>>>>> allows >>>>>>>>>>> to map all resolution variants of one >>>>>>>>>>> multi-resolution image to another: >>>>>>>>>>> ------------ >>>>>>>>>>> Image image = // original image >>>>>>>>>>> Image filteredImage = MultiResolutionImage.map(image, >>>>>>>>>>> (img) -> >>>>>>>>>>> /* return filtered image */); >>>>>>>>>>> ------------ >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>> On 21/03/16 22:31, Jim Graham wrote: >>>>>>>>>>>> We could do that for our own filters, but any random custom >>>>>>>>>>>> filter >>>>>>>>>>>> could run into the same issue, so it might not make >>>>>>>>>>>> sense to upgrade the existing filter mechanism to always >>>>>>>>>>>> attempt >>>>>>>>>>>> to do MR filtering. We could either create a >>>>>>>>>>>> parallel set of MR-aware filter mechanisms (such as the >>>>>>>>>>>> previously >>>>>>>>>>>> suggested new method on Toolkit, or a new MR-aware >>>>>>>>>>>> version of FilteredImageSource for instance) and leave the >>>>>>>>>>>> existing mechanism as clearly documented as MR-unaware. >>>>>>>>>>>> Another idea is to tag a filter with an interface that >>>>>>>>>>>> indicates >>>>>>>>>>>> that it is MR aware? In any case, some thought needs >>>>>>>>>>>> to be given to feeding an MR image to a filter that >>>>>>>>>>>> (potentially >>>>>>>>>>>> or demonstrably) cannot deal with MR images. >>>>>>>>>>>> >>>>>>>>>>>> Alternately, we could then recommend that the old image >>>>>>>>>>>> filtering >>>>>>>>>>>> code isn't combined with multi-resolution images. >>>>>>>>>>>> It seems to me that the programmer is mostly in control over >>>>>>>>>>>> this >>>>>>>>>>>> happening since they've either manually created the >>>>>>>>>>>> MR image using the custiom MR image mechanism or they've >>>>>>>>>>>> supplied >>>>>>>>>>>> media with multiple resolution files (i.e. "@2x"). >>>>>>>>>>>> Is that really the case? >>>>>>>>>>>> >>>>>>>>>>>> Whether it is a new filtering mechanism that must be adopted or >>>>>>>>>>>> simply declaring the old filtering mechanism as >>>>>>>>>>>> "obsolete with respect to MR images"... >>>>>>>>>>>> >>>>>>>>>>>> That recommendation then "restricts forward" in that, for >>>>>>>>>>>> example, >>>>>>>>>>>> since Swing relies on the old mechanism, Swing then >>>>>>>>>>>> becomes "not recommended for use with MR images", or "not MR >>>>>>>>>>>> aware". That's probably not a restriction we want to >>>>>>>>>>>> promote so it should be viewed as a temporary restriction >>>>>>>>>>>> reality >>>>>>>>>>>> and a bug that we'll fix soon, whether by using some >>>>>>>>>>>> other mechanism to achieve the desired affects, or creating >>>>>>>>>>>> a new >>>>>>>>>>>> MR-aware filtering mechanism and using it in Swing. >>>>>>>>>>>> >>>>>>>>>>>> Similarly, other 3rd party libraries that accept images and do >>>>>>>>>>>> anything more than display them will have to be >>>>>>>>>>>> upgraded as well before they become "MR aware" or "MR >>>>>>>>>>>> accepting" >>>>>>>>>>>> or whatever term applies here... >>>>>>>>>>>> >>>>>>>>>>>> ...jim >>>>>>>>>>>> >>>>>>>>>>>> On 3/21/16 8:54 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> The one more thing is that image filters should also be >>>>>>>>>>>>> updated >>>>>>>>>>>>> to use >>>>>>>>>>>>> them with multi-resolution images. >>>>>>>>>>>>> For example, consider the case: >>>>>>>>>>>>> ---------- >>>>>>>>>>>>> Image mrImage = getMultiResolutionImage(); >>>>>>>>>>>>> ImageProducer mriProducer = new >>>>>>>>>>>>> FilteredImageSource(mrImage.getSource(), new >>>>>>>>>>>>> CropImageFilter(0, >>>>>>>>>>>>> 0, w, h)); >>>>>>>>>>>>> Toolkit.getDefaultToolkit().createImage(mriProducer); >>>>>>>>>>>>> ---------- >>>>>>>>>>>>> >>>>>>>>>>>>> The crop image filter applied to each resolution variant just >>>>>>>>>>>>> cuts >>>>>>>>>>>>> images with the same size. >>>>>>>>>>>>> It seems that there should be added API which allows to set a >>>>>>>>>>>>> scale for >>>>>>>>>>>>> a provided image filter to be properly used with the given >>>>>>>>>>>>> resolution >>>>>>>>>>>>> variant. >>>>>>>>>>>>> >>>>>>>>>>>>> I have created a separated issue for multi-resolution images >>>>>>>>>>>>> filtering >>>>>>>>>>>>> support: >>>>>>>>>>>>> JDK-8152309 Seamless way of using image filters with >>>>>>>>>>>>> multi-resolution >>>>>>>>>>>>> images >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152309 >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>> >>>>>>>>>>>>> On 15/03/16 20:35, Alexander Scherbatiy wrote: >>>>>>>>>>>>>> On 15/03/16 18:06, Sergey Bylokhov wrote: >>>>>>>>>>>>>>> On 15.03.16 17:01, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> One update will be that FilteredImageSource should >>>>>>>>>>>>>>>> implement >>>>>>>>>>>>>>>> MultiResolutionImageProducer even it is used for non >>>>>>>>>>>>>>>> multi-resolution >>>>>>>>>>>>>>>> images. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The MRI can be created using two general ways: using >>>>>>>>>>>>>>>> fixed >>>>>>>>>>>>>>>> number of >>>>>>>>>>>>>>>> resolution variants or generating a resolution variant with >>>>>>>>>>>>>>>> necessary >>>>>>>>>>>>>>>> quality on demand. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The current implementation is rely on that MRToolkitImage >>>>>>>>>>>>>>>> contains a >>>>>>>>>>>>>>>> fixed number of resolution variants. In this case >>>>>>>>>>>>>>>> MediaTracker >>>>>>>>>>>>>>>> can >>>>>>>>>>>>>>>> iterate over resolution variants and load them all. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Using MultiResolutionImageProducer leads that >>>>>>>>>>>>>>>> MRToolkitImage >>>>>>>>>>>>>>>> will not >>>>>>>>>>>>>>>> know about number of resolution variants in case when they >>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>> generated >>>>>>>>>>>>>>>> on the fly and there will be no way to load all of them by >>>>>>>>>>>>>>>> MediaTracker. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Just an idea to thinking about, can we save this filter to >>>>>>>>>>>>>>> the MRI >>>>>>>>>>>>>>> itself and apply it after some resolution variant will be >>>>>>>>>>>>>>> created on >>>>>>>>>>>>>>> the fly? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Do you mean that it helps to leave the code in the AquaUtils >>>>>>>>>>>>>> class >>>>>>>>>>>>>> unchanged: >>>>>>>>>>>>>> --------------- >>>>>>>>>>>>>> 124 static Image generateLightenedImage(final Image >>>>>>>>>>>>>> image, >>>>>>>>>>>>>> final >>>>>>>>>>>>>> int percent) { >>>>>>>>>>>>>> 125 final GrayFilter filter = new GrayFilter(true, >>>>>>>>>>>>>> percent); >>>>>>>>>>>>>> 126 final ImageProducer prod = new >>>>>>>>>>>>>> FilteredImageSource(image.getSource(), filter); >>>>>>>>>>>>>> 127 return >>>>>>>>>>>>>> Toolkit.getDefaultToolkit().createImage(prod); >>>>>>>>>>>>>> 128 } >>>>>>>>>>>>>> --------------- >>>>>>>>>>>>>> >>>>>>>>>>>>>> or it is just an a better way for a filtered >>>>>>>>>>>>>> multi-resolution >>>>>>>>>>>>>> image >>>>>>>>>>>>>> generation? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> As I see, the way to solve it is only using >>>>>>>>>>>>>>>> MRI.getResolutionVariants() >>>>>>>>>>>>>>>> method for the MultiResolutionImageProducer creation. So >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> result of >>>>>>>>>>>>>>>> the call >>>>>>>>>>>>>>>> toolkit.createImage(new >>>>>>>>>>>>>>>> FilteredImageSource(mrImage.getSource(), >>>>>>>>>>>>>>>> filter)); >>>>>>>>>>>>>>>> will be a MRToolkitImage which is based on fixed >>>>>>>>>>>>>>>> number of >>>>>>>>>>>>>>>> filtered >>>>>>>>>>>>>>>> resolution variants from the original MRI. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ...jim >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 3/11/16 5:42 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>>>>> On 09/03/16 16:58, Sergey Bylokhov wrote: >>>>>>>>>>>>>>>>>>> Probably we should enhance >>>>>>>>>>>>>>>>>>> ImageProducer/Tk.createImage/ImageFilter to >>>>>>>>>>>>>>>>>>> support this functionality? It seems that the number of >>>>>>>>>>>>>>>>>>> usage of >>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>> check "image instanceof MultiResolutionImage" will grow >>>>>>>>>>>>>>>>>>> over time. >>>>>>>>>>>>>>>>>> ImageProducer produces pixels for an image and is not >>>>>>>>>>>>>>>>>> able to >>>>>>>>>>>>>>>>>> take >>>>>>>>>>>>>>>>>> an information about the image resolution variants. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> May be we can add Toolkit.createImage(Image image, >>>>>>>>>>>>>>>>>> ImageFilter >>>>>>>>>>>>>>>>>> imageFilter) method which takes MultiResolutionImage into >>>>>>>>>>>>>>>>>> account to >>>>>>>>>>>>>>>>>> cover the common case where filtered image is created. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>> I think that at least our own API should support >>>>>>>>>>>>>>>>>>> MultiResolutionImage >>>>>>>>>>>>>>>>>>> w/o such checks, otherwise the user will need to do the >>>>>>>>>>>>>>>>>>> same. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> cc 2d-dev >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 09.03.16 15:30, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Could you review the fix: >>>>>>>>>>>>>>>>>>>> bug: >>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151303 >>>>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8151303/webrev.00 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> The AquaUtils does not take into account >>>>>>>>>>>>>>>>>>>> MultiResolutionImage >>>>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>> selected/disabled/lightened images generation. >>>>>>>>>>>>>>>>>>>> The fix also leaves the MultiResolutionCachedImage >>>>>>>>>>>>>>>>>>>> check because >>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>> base system icon size can be differ from the requested >>>>>>>>>>>>>>>>>>>> painted >>>>>>>>>>>>>>>>>>>> size. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> > From Sergey.Bylokhov at oracle.com Mon Aug 15 18:30:22 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 15 Aug 2016 21:30:22 +0300 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() method does not work when called inside imageStarted for PNG In-Reply-To: <06aa9e0a-bf19-4dd0-949a-c3c0cb00d4b1@default> References: <06aa9e0a-bf19-4dd0-949a-c3c0cb00d4b1@default> Message-ID: Is it possible to unify the test for all our plugins? I assume they should work in the same way. I am not sure but probably the image can be generated at runtime? On 11.08.16 21:59, Jayathirth D V wrote: > Hi, > > > > Please review the following fix in JDK9 at your convenience: > > > > Bug : https://bugs.openjdk.java.net/browse/JDK-4924727 > > > > Webrev : http://cr.openjdk.java.net/~jdv/4924727/webrev.00/ > > > > Issue : When we issue ImageReader.abort() in > IIOReadProgressListener.imageStarted(), reading is not aborted and it is > continued. > > > > Root cause : After IIOReadProgressListener.imageStarted() call in > PNGImageReader.java when we enter decodeImage() we call > clearAbortRequest() which will clear the abort request from > IIOReadProgressListener.imageStarted(). > > > > Solution : clearAbortRequest() documentation mentions that it should be > called before reading of image starts, so it should be called before > IIOReadProgressListener.imageStarted()(In PNGImageReader.java it is > processImageStarted(0) in readImage()). So moved clearAbortRequest() > call from decodeImage() to readImage(). Also we should call > abortRequested() in PNGImageReader.java at places mapping to > IIOReadProgressListener and not randomly at end of functions or at > places related to IIOReadUpdateListener, updated the code for the same. > > > > > > Observation not related to this issue : We don?t have call similar to > IIOReadProgressListener.readAborted() in IIOReadUpdateListener, but user > can call ImageReader.abort() from IIOReadUpdateListener methods. Is > there a need to add similar method in IIOReadUpdateListener? Any inputs > on this also would be helpful. > > > > Thanks, > > Jay > -- Best regards, Sergey. From prahalad.kumar.narayanan at oracle.com Tue Aug 16 08:11:13 2016 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Tue, 16 Aug 2016 01:11:13 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] Review Request: JDK-8158524: Test file added for VolatileImage -vs- BufferedImage output comparison In-Reply-To: <508122c4-403d-f059-52f1-147e8c02f55f@oracle.com> References: <57AC29D7.90605@oracle.com> <60d1ffac-ebdc-4b0a-a7b2-c62a67bc90d7@default> <7ad2d0be-1c49-f9b9-4b50-d3bab2b78139@oracle.com> <508122c4-403d-f059-52f1-147e8c02f55f@oracle.com> Message-ID: <886e9001-9394-44eb-b8fa-aea4c4c923cc@default> Hello Everyone This is a follow-up to my webrev. Thanks to Sergey for his feedback. I 've incorporated the feedback and changes are now available for review Link: http:// http://cr.openjdk.java.net/~pnarayanan/8158524/webrev.02/ Summary on changes from previous revision: . '@key headful' has been added to the jtreg comments . Swing UI components are invoked on EDT Kindly review the changes and provide your feedback at your convenience Thank you Have a good day Prahalad N. -----Original Message----- From: Sergey Bylokhov Sent: Friday, August 12, 2016 6:39 PM To: Prahalad Kumar Narayanan; Prasanta Sadhukhan; 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9] Review Request: JDK-8158524: Test file added for VolatileImage -vs- BufferedImage output comparison On 12.08.16 16:06, Sergey Bylokhov wrote: > Looks fine. > Please add @key heedful jtreg tag before the push. Ouch I just realize that the test use the Swing components on non-EDT. > > On 11.08.16 13:22, Prahalad Kumar Narayanan wrote: >> Hello Everyone >> >> First, Thanks to Prasanta for his feedback. >> I 've incorporated the feedback in the code and changes are available >> for review. >> Review Link: >> http://cr.openjdk.java.net/~pnarayanan/8158524/webrev.01/ >> >> Quick summary on changes from previous revision: >> . Wild card imports have been replaced with specific imports >> . @override annotation has been added to the paint() method >> . RuntimeException is thrown instead of Error though both would >> report regression failure. >> . Image loading has been corrected with proper filePath. >> . With regard to image and licensing issue: >> . I checked the image properties. There is no >> 'author/copyright' information with this image. >> . The file matches when compared (binary) with the >> similar .gif image in test/java/awt/print/PrinterJob/ >> >> Kindly review the changes at your convenience and share your views. >> >> Thank you >> Have a good day >> >> Prahalad N. >> >> >> -----Original Message----- >> From: Prasanta Sadhukhan >> Sent: Thursday, August 11, 2016 1:02 PM >> To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net >> Cc: Philip Race; Sergey Bylokhov >> Subject: Re: [OpenJDK 2D-Dev] [9] Review Request: JDK-8158524: Test >> file added for VolatileImage -vs- BufferedImage output comparison >> >> You need to use @Override annotation for paint() method. Also, you >> can use specific imports rather than package imports. >> Also, I guess it's better to throw RuntimeException than Error for >> failure, not sure how jtreg will react to it. >> Lastly, I am not sure if you can use duke.gif image which maynot be >> licensed although we have similar duke.gif in java/awt/print/PrinterJob. >> >> Regards >> Prasanta >> On 8/11/2016 11:30 AM, Prahalad Kumar Narayanan wrote: >>> Hello Everyone >>> >>> Good day to you. >>> >>> I 'm planning to add a test file into jdk/test/ repository. >>> The webrev changes for the test file is presented herewith. >>> Link: >>> http://cr.openjdk.java.net/~pnarayanan/8158524/webrev.00/ >>> >>> Brief on the test & its objectives: >>> . As we know, VolatileImage utilizes accelerated rendering >>> using GPU while BufferedImage utilizes software rendering >>> . The objective of this test-case is to check whether the >>> rendered 2d primitives appear same on VolatileImage and BufferedImage >>> . In rare cases, the rendering on VolatileImage might >>> differ by few pixels from BufferedImage due to D3D/OpenGL driver 's >>> handling of primitives >>> . Java2D pipelines for D3D/OpenGL APIs use fudge >>> factors to fine tune rendering calls so that output matches with >>> output of BufferedImage. >>> . Thus the test case will help in checking for >>> consistent rendering across pipelines and also in identifying >>> scenarios where pipelines need to be fine-tuned. >>> >>> Kindly review the test file and share your views at your convenience >>> >>> Thank you >>> Have a good day >>> >>> Prahalad N. >> > > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Aug 16 11:35:56 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 16 Aug 2016 14:35:56 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: JDK-8158524: Test file added for VolatileImage -vs- BufferedImage output comparison In-Reply-To: <886e9001-9394-44eb-b8fa-aea4c4c923cc@default> References: <57AC29D7.90605@oracle.com> <60d1ffac-ebdc-4b0a-a7b2-c62a67bc90d7@default> <7ad2d0be-1c49-f9b9-4b50-d3bab2b78139@oracle.com> <508122c4-403d-f059-52f1-147e8c02f55f@oracle.com> <886e9001-9394-44eb-b8fa-aea4c4c923cc@default> Message-ID: <2e0009da-b9d1-e3bb-c0c2-769059ce1c04@oracle.com> Looks fine. On 16.08.16 11:11, Prahalad Kumar Narayanan wrote: > Hello Everyone > > This is a follow-up to my webrev. > > Thanks to Sergey for his feedback. > I 've incorporated the feedback and changes are now available for review > Link: http:// http://cr.openjdk.java.net/~pnarayanan/8158524/webrev.02/ > > Summary on changes from previous revision: > . '@key headful' has been added to the jtreg comments > . Swing UI components are invoked on EDT > > Kindly review the changes and provide your feedback at your convenience > > Thank you > Have a good day > > Prahalad N. > > > -----Original Message----- > From: Sergey Bylokhov > Sent: Friday, August 12, 2016 6:39 PM > To: Prahalad Kumar Narayanan; Prasanta Sadhukhan; 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] [9] Review Request: JDK-8158524: Test file added for VolatileImage -vs- BufferedImage output comparison > > On 12.08.16 16:06, Sergey Bylokhov wrote: >> Looks fine. >> Please add @key heedful jtreg tag before the push. > > Ouch I just realize that the test use the Swing components on non-EDT. > >> >> On 11.08.16 13:22, Prahalad Kumar Narayanan wrote: >>> Hello Everyone >>> >>> First, Thanks to Prasanta for his feedback. >>> I 've incorporated the feedback in the code and changes are available >>> for review. >>> Review Link: >>> http://cr.openjdk.java.net/~pnarayanan/8158524/webrev.01/ >>> >>> Quick summary on changes from previous revision: >>> . Wild card imports have been replaced with specific imports >>> . @override annotation has been added to the paint() method >>> . RuntimeException is thrown instead of Error though both would >>> report regression failure. >>> . Image loading has been corrected with proper filePath. >>> . With regard to image and licensing issue: >>> . I checked the image properties. There is no >>> 'author/copyright' information with this image. >>> . The file matches when compared (binary) with the >>> similar .gif image in test/java/awt/print/PrinterJob/ >>> >>> Kindly review the changes at your convenience and share your views. >>> >>> Thank you >>> Have a good day >>> >>> Prahalad N. >>> >>> >>> -----Original Message----- >>> From: Prasanta Sadhukhan >>> Sent: Thursday, August 11, 2016 1:02 PM >>> To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net >>> Cc: Philip Race; Sergey Bylokhov >>> Subject: Re: [OpenJDK 2D-Dev] [9] Review Request: JDK-8158524: Test >>> file added for VolatileImage -vs- BufferedImage output comparison >>> >>> You need to use @Override annotation for paint() method. Also, you >>> can use specific imports rather than package imports. >>> Also, I guess it's better to throw RuntimeException than Error for >>> failure, not sure how jtreg will react to it. >>> Lastly, I am not sure if you can use duke.gif image which maynot be >>> licensed although we have similar duke.gif in java/awt/print/PrinterJob. >>> >>> Regards >>> Prasanta >>> On 8/11/2016 11:30 AM, Prahalad Kumar Narayanan wrote: >>>> Hello Everyone >>>> >>>> Good day to you. >>>> >>>> I 'm planning to add a test file into jdk/test/ repository. >>>> The webrev changes for the test file is presented herewith. >>>> Link: >>>> http://cr.openjdk.java.net/~pnarayanan/8158524/webrev.00/ >>>> >>>> Brief on the test & its objectives: >>>> . As we know, VolatileImage utilizes accelerated rendering >>>> using GPU while BufferedImage utilizes software rendering >>>> . The objective of this test-case is to check whether the >>>> rendered 2d primitives appear same on VolatileImage and BufferedImage >>>> . In rare cases, the rendering on VolatileImage might >>>> differ by few pixels from BufferedImage due to D3D/OpenGL driver 's >>>> handling of primitives >>>> . Java2D pipelines for D3D/OpenGL APIs use fudge >>>> factors to fine tune rendering calls so that output matches with >>>> output of BufferedImage. >>>> . Thus the test case will help in checking for >>>> consistent rendering across pipelines and also in identifying >>>> scenarios where pipelines need to be fine-tuned. >>>> >>>> Kindly review the test file and share your views at your convenience >>>> >>>> Thank you >>>> Have a good day >>>> >>>> Prahalad N. >>> >> >> > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Tue Aug 16 11:47:37 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 16 Aug 2016 17:17:37 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6574279: validatePage from PrinterJob returns argument under linux In-Reply-To: <57AC3983.7020504@oracle.com> References: <5784DD01.4040309@oracle.com> <57A25BE6.3080305@oracle.com> <57A331E4.8000907@oracle.com> <57A46852.4050801@oracle.com> <57AB9E3C.80302@oracle.com> <57AC3983.7020504@oracle.com> Message-ID: <57B2FD59.2060106@oracle.com> Hi All, On 8/11/2016 2:08 PM, Prasanta Sadhukhan wrote: > Hi Phil, > > On 8/11/2016 3:05 AM, Phil Race wrote: >> There does not seem to be a link to the new webrev in here. >> >> Is it this : http://cr.openjdk.java.net/~psadhukhan/6574279/webrev.01/ ? >> >> > to default Paper (Letter in US, A4 otherwise) imageable area >> >> I don't think that will ever be A4. Where is that coming from ? >> >> And you still have not fixed the problem with how you retrieve the MPA :- >> 512 MediaPrintableArea mpa = (MediaPrintableArea) >> 513 >> getPrintService().getDefaultAttributeValue(MediaPrintableArea.class); >> >> >> It is not supposed to be the MPA of the *default* paper. You want the >> MPA of *this* paper. >> Only if origPaper is not a supported paper do you go look for the >> default paper. >> > As you suggested, I have modified to check if mpa of origPaper is > amongst supported mpa(s) of the printer, if not, then go for mpa of > default paper. > However, it seems among 61 mpas returned by CUPSPrinter , > origPaper of 0,0,8.26",11.69" is within supported mpa of a paper size > 0,0,11.69",16.52" so it means 0,0,8",11" comes out to be supported mpa. > > Can you please comment on this modified webrev on what more we can do? > http://cr.openjdk.java.net/~psadhukhan/6574279/webrev.02/ > > I guess we need to find out the physical limitation of printer via > CUPS same what we do in windows via GetDeviceCaps(printDC, > PHYSICALOFFSETX); and use that in calculation for valid margin > but I could not find equivalent cups function. Can you suggest anyways? > I tried calling ppdFindOption(ppd, "HWMargins") in CUPS but it returns null although my printer ppd file has this line *%=== Custom Paper Support ================= *LeadingEdge Short: "" *LeadingEdge Long: "" *DefaultLeadingEdge: Short *MaxMediaWidth: "865" *MaxMediaHeight: "1701" **HWMargins: 12 12 12 12 *Anyways, I have updated the webrev to take care of the review comments and also get HWMargin (if the above ppdFindOption return null then fall back to custom margin as reported via ppd_file_t structure https://www.cups.org/doc/api-ppd.html#ppd_file_s) http://cr.openjdk.java.net/~psadhukhan/6574279/webrev.03/ Please review. Tested in ubuntu and solaris11. Regards Prasanta > Regards > Prasanta >> -phil. >> >> On 08/05/2016 03:20 AM, Prasanta Sadhukhan wrote: >>> >>> >>> On 8/4/2016 5:45 PM, Prasanta Sadhukhan wrote: >>>> I will override in PSPrinterJob but >>>> 1662 MediaPrintableArea mpa = >>>> 1663 (MediaPrintableArea)getPrintService(). >>>> 1664 getDefaultAttributeValue(MediaPrintableArea.class); >>>> >>>> is returning imageable area of default media of chosen printer from >>>> CUPS [ all supported media printable area is obtained from >>>> CUPSPrinter#getPageSizes(printer) & then initMedia() populates >>>> cupsMediaPrintables which is returned in getMediaPrintableArea()] >>>> as IPPPrintService#getDefaultAttributeValue() does >>>> ---------- >>>> if (category == MediaPrintableArea.class) { >>>> MediaPrintableArea[] mpas; >>>> if ((cps != null) && >>>> ((mpas = *cps.getMediaPrintableArea()*) != null)) { >>>> if (defaultMediaIndex == -1) { >>>> // initializes value of defaultMediaIndex >>>> getDefaultAttributeValue(Media.class); >>>> } >>>> return mpas[*defaultMediaIndex*]; >>>> } >>>> -------------- >>>> by which mpas[defaultMediaIndex] returns default media printable area. >>>> In else block, we instantiate mpa of Letter for US locale and A4 >>>> for other locales so I was not checking for null as in both if and >>>> else block , I was getting MediaPrintableArea instance. >>>> >>>> Regarding considering equal margins, I am not sure if there was any >>>> way I could get right and left margin separately. >>>> Please let me know if there is any way you know of. >>> I have modified to do the change in PSPrinterJob. Regarding the >>> equal margin, we do the same in >>> http://hg.openjdk.java.net/jdk9/client/jdk/file/abb2a39948fe/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java#l688 >>> http://cr.openjdk.java.net/~psadhukhan/6574279/webrev.01/ >> >> That does not seem to be the same case as this. >> >> -phil. >> >>> >>> Regards >>> Prasanta >>>> >>>> Regards >>>> Prasanta >>>> On 8/4/2016 2:32 AM, Philip Race wrote: >>>>> High-level question. Why is this not an over-ride in PSPrinterJob ? >>>>> >>>>> >>>>> I'm afraid I did not get much past the first line of the change : >>>>> 1662 MediaPrintableArea mpa = >>>>> 1663 (MediaPrintableArea)getPrintService(). >>>>> 1664 getDefaultAttributeValue(MediaPrintableArea.class); >>>>> >>>>> Read the docs for MediaPrintableArea :- >>>>> --- >>>>> To query for the printable area, a client must supply a suitable >>>>> context. >>>>> Without specifying at the very least the size of the media being used >>>>> no meaningful value for printable area can be obtained. >>>>> --- >>>>> >>>>> .. not to mention you assume a non-null return. >>>>> >>>>> and then you use new Paper() .. which is a constructor which >>>>> knows nothing about the printer. It is *speced* to return >>>>> US letter with one inch margins. >>>>> >>>>> Another reason why this seems like it should be a sub-class >>>>> over-ride. >>>>> >>>>> >>>>> Also this looks wrong --- >>>>> 1672 if ((imgX*2) + imgWid > wid) { >>>>> 1673 imgWid = wid - imgX*2; >>>>> 1674 } >>>>> >>>>> You can't assume equal margins. >>>>> >>>>> -phil. >>>>> >>>>> On 7/12/16, 5:05 AM, Prasanta Sadhukhan wrote: >>>>>> Hi All, >>>>>> >>>>>> Please review a fix for an issue where it is seen that if user >>>>>> sets invalid imageablearea via Paper.setImageableArea and >>>>>> then calls PrinterJob.validatePage() in linux, then it does not >>>>>> get a valid pageformat >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6574279 >>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6574279/webrev.00/ >>>>>> >>>>>> Fix is to check for margin as noted via CUPS ppdPageSize() and >>>>>> then calculate to find the valid margin in validatePaper() >>>>>> similar to what we do in native validatePaper() in windows. >>>>>> >>>>>> Regards >>>>>> Prasanta >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Tue Aug 16 16:02:35 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 16 Aug 2016 09:02:35 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8149562: TIFFField#createFromMetadataNode javadoc should provide information about sibling/child nodes that should be part of parameter node References: <304A3A05-9085-4C78-AF24-5AE7622399FB@oracle.com> Message-ID: <752CE81D-8DAC-4E0E-8090-D615C7218D8D@oracle.com> Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8149562 Patch: [1] Add one sentence to the TIFFField.createFromMetadataNode method specification stating that the supplied Node parameter must adhere to the TIFFField element structure defined by the TIFF native image metadata DTD. Thanks, Brian [1] diff --- a/src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFField.java +++ b/src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFField.java /** * Creates a {@code TIFFField} from a TIFF native image * metadata node. If the value of the {@code ?number"} attribute * of the node is not found in {@code tagSet} then a new * {@code TIFFTag} with name {@code TIFFTag.UNKNOWN_TAG_NAME} - * will be created and assigned to the field. + * will be created and assigned to the field. If the {@code Node} + * parameter content does not adhere to the {@code TIFFField} element + * structure defined by the + * + * TIFF native image metadata format specification + * an {@code Exception} will be thrown. * * @param tagSet The {@code TIFFTagSet} to which the * {@code TIFFTag} of the field belongs. * @param node A native TIFF image metadata {@code TIFFField} node. * @throws NullPointerException if {@code node} is * {@code null}. * @throws IllegalArgumentException if the name of the node is not * {@code "TIFFField"}. * @throws NullPointerException if the node does not contain any data. * @throws IllegalArgumentException if the combination of node attributes * and data is not legal per the {@link #TIFFField(TIFFTag,int,int,Object)} * constructor specification. * @return A new {@code TIFFField}. */ public static TIFFField createFromMetadataNode(TIFFTagSet tagSet, Node node) { -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Tue Aug 16 16:21:50 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 16 Aug 2016 19:21:50 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8164104 Cleanup of javaclient related mapfiles Message-ID: Hello. Please review cleanup of mapfiles, initially the problem was found here: http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011734.html - tabs were replaced by spaces - doubled empty lines removed jprt is ok. Bug: https://bugs.openjdk.java.net/browse/JDK-8164104 Patch can be found at: http://cr.openjdk.java.net/~serb/8164104/webrev.00/jdk.patch -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Aug 16 16:22:01 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 16 Aug 2016 19:22:01 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8164104 Cleanup of javaclient related mapfiles Message-ID: <9a63d42e-935e-44c9-56be-282a837ca85c@oracle.com> Hello. Please review cleanup of mapfiles, initially the problem was found here: http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011734.html - tabs were replaced by spaces - doubled empty lines removed jprt is ok. Bug: https://bugs.openjdk.java.net/browse/JDK-8164104 Patch can be found at: http://cr.openjdk.java.net/~serb/8164104/webrev.00/jdk.patch -- Best regards, Sergey. From philip.race at oracle.com Tue Aug 16 16:33:33 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 16 Aug 2016 09:33:33 -0700 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8164104 Cleanup of javaclient related mapfiles In-Reply-To: <9a63d42e-935e-44c9-56be-282a837ca85c@oracle.com> References: <9a63d42e-935e-44c9-56be-282a837ca85c@oracle.com> Message-ID: <57B3405D.2060504@oracle.com> I think "JPRT is OK" is good but may be not enough here? I am not sure if the build will complain about missing entries for JNI methods since there is no direct linking against these. Can you do a quick sanity run through of Java2Demo on Linux .. and ideally Solaris x64 too. -phil. On 08/16/2016 09:22 AM, Sergey Bylokhov wrote: > Hello. > > Please review cleanup of mapfiles, initially the problem was found here: > http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011734.html > > - tabs were replaced by spaces > - doubled empty lines removed > > jprt is ok. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8164104 > Patch can be found at: > http://cr.openjdk.java.net/~serb/8164104/webrev.00/jdk.patch > From Sergey.Bylokhov at oracle.com Wed Aug 17 13:33:32 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 17 Aug 2016 16:33:32 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8164104 Cleanup of javaclient related mapfiles In-Reply-To: <57B3405D.2060504@oracle.com> References: <9a63d42e-935e-44c9-56be-282a837ca85c@oracle.com> <57B3405D.2060504@oracle.com> Message-ID: <9db92a0e-69f4-a299-714e-02cb7fffd165@oracle.com> Tested on solarisX64/solarisSparc/linuxX64 no issues were found(SwingSet2/Java2Demo). But I wonder why the text on solarissparc filled by yellow shadow(Is it a known issue)? On 16.08.16 19:33, Phil Race wrote: > I think "JPRT is OK" is good but may be not enough here? > I am not sure if the build will complain about missing entries > for JNI methods since there is no direct linking against these. > Can you do a quick sanity run through of Java2Demo on Linux .. > and ideally Solaris x64 too. > > -phil. > > On 08/16/2016 09:22 AM, Sergey Bylokhov wrote: >> Hello. >> >> Please review cleanup of mapfiles, initially the problem was found here: >> http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011734.html >> >> - tabs were replaced by spaces >> - doubled empty lines removed >> >> jprt is ok. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8164104 >> Patch can be found at: >> http://cr.openjdk.java.net/~serb/8164104/webrev.00/jdk.patch >> > -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Wed Aug 17 15:03:11 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 17 Aug 2016 20:33:11 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR 8164205 [PIT][TEST_BUG] test javax/print/attribute/ServiceDlgPageRangeTest.java doesn't compile Message-ID: <57B47CAF.4020503@oracle.com> Hi All, Please review a modification to the testcase (wrong version was putbacked by mistake) hg diff test/javax/print/attribute/ServiceDlgPageRangeTest.java diff -r 0d3894b7fc66 test/javax/print/attribute/ServiceDlgPageRangeTest.java --- a/test/javax/print/attribute/ServiceDlgPageRangeTest.java Tue Aug 09 13:22:58 2016 +0530 +++ b/test/javax/print/attribute/ServiceDlgPageRangeTest.java Wed Aug 17 20:30:51 2016 +0530 @@ -29,6 +29,8 @@ */ import java.awt.BorderLayout; import java.awt.FlowLayout; +import java.awt.event.WindowAdapter; +import java.awt.event.WindowEvent; import javax.print.DocFlavor; import javax.print.PrintService; import javax.print.PrintServiceLookup; Regards Prasanta From philip.race at oracle.com Wed Aug 17 15:04:17 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 17 Aug 2016 08:04:17 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8163922: Print-to-file is disabled for SERVICE_FORMATTED docflavor in linux In-Reply-To: <57AD5D09.2090606@oracle.com> References: <57AD5D09.2090606@oracle.com> Message-ID: <57B47CF1.9030809@oracle.com> +1 with the caveat that I am assuming you tested this did not regress anything else .. -phil. On 8/11/16, 10:22 PM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix for an issue where it is seen that Print-to-File > option is disabled even for SERVICE_FORMATTED DocFlavor after > JDK-5049012 fix. > Bug: https://bugs.openjdk.java.net/browse/JDK-8163922 > webrev: http://cr.openjdk.java.net/~psadhukhan/8163922/webrev.00/ > > We need to enabled dstSupported even if the destination is not > specified for SERVICE_FORMATTED DocFlavor. > > Regards > Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Aug 17 15:39:03 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 17 Aug 2016 08:39:03 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6357887: selected printertray is ignored under linux In-Reply-To: <57AAECFD.2030802@oracle.com> References: <57AAECFD.2030802@oracle.com> Message-ID: <57B48517.3030200@oracle.com> This all looks fine although this can be a simple call to attributes.get(CustomMediaTray.class) can't it ? 502 for (int i=0; i< attrs.length; i++) { 503 Attribute attr = attrs[i]; 504 try { 505 if (attr instanceof CustomMediaTray) { 506 CustomMediaTray customTray = (CustomMediaTray)attr; 507 mOptions = " InputSlot="+ customTray.getChoiceName(); 508 } 509 } catch (ClassCastException e) { -phil. On 8/10/16, 1:59 AM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix for an issue where it is seen that the selected > printer tray is ignored in linux and default standard tray is used for > printing. > > Bug: https://bugs.openjdk.java.net/browse/JDK-6357887 > webrev: http://cr.openjdk.java.net/~psadhukhan/6357887/webrev.00/ > > Issue was lpr command needs "-o InputSlot=" to select the > printertray which was not being passed to lpr command. > Proposed fix added InputSlot option to lpr command to select the > printertray. > > Tested in ubuntu and solaris11. > > Regards > Prasanta From prasanta.sadhukhan at oracle.com Wed Aug 17 16:06:20 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 17 Aug 2016 21:36:20 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR 8164205 [PIT][TEST_BUG] test javax/print/attribute/ServiceDlgPageRangeTest.java doesn't compile In-Reply-To: <57B47CAF.4020503@oracle.com> References: <57B47CAF.4020503@oracle.com> Message-ID: <57B48B7C.5070700@oracle.com> will add this bugid to the test as well which is missing in the below diff. Regards Prasanta On 8/17/2016 8:33 PM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a modification to the testcase (wrong version was > putbacked by mistake) > > hg diff test/javax/print/attribute/ServiceDlgPageRangeTest.java > diff -r 0d3894b7fc66 > test/javax/print/attribute/ServiceDlgPageRangeTest.java > --- a/test/javax/print/attribute/ServiceDlgPageRangeTest.java Tue Aug > 09 13:22:58 2016 +0530 > +++ b/test/javax/print/attribute/ServiceDlgPageRangeTest.java Wed Aug > 17 20:30:51 2016 +0530 > @@ -29,6 +29,8 @@ > */ > import java.awt.BorderLayout; > import java.awt.FlowLayout; > +import java.awt.event.WindowAdapter; > +import java.awt.event.WindowEvent; > import javax.print.DocFlavor; > import javax.print.PrintService; > import javax.print.PrintServiceLookup; > > Regards > Prasanta From philip.race at oracle.com Wed Aug 17 17:24:20 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 17 Aug 2016 10:24:20 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR 8164205 [PIT][TEST_BUG] test javax/print/attribute/ServiceDlgPageRangeTest.java doesn't compile In-Reply-To: <57B48B7C.5070700@oracle.com> References: <57B47CAF.4020503@oracle.com> <57B48B7C.5070700@oracle.com> Message-ID: <57B49DC4.5060803@oracle.com> +1 -phil. ]On 08/17/2016 09:06 AM, Prasanta Sadhukhan wrote: > will add this bugid to the test as well which is missing in the below > diff. > > Regards > Prasanta > On 8/17/2016 8:33 PM, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a modification to the testcase (wrong version was >> putbacked by mistake) >> >> hg diff test/javax/print/attribute/ServiceDlgPageRangeTest.java >> diff -r 0d3894b7fc66 >> test/javax/print/attribute/ServiceDlgPageRangeTest.java >> --- a/test/javax/print/attribute/ServiceDlgPageRangeTest.java Tue Aug >> 09 13:22:58 2016 +0530 >> +++ b/test/javax/print/attribute/ServiceDlgPageRangeTest.java Wed Aug >> 17 20:30:51 2016 +0530 >> @@ -29,6 +29,8 @@ >> */ >> import java.awt.BorderLayout; >> import java.awt.FlowLayout; >> +import java.awt.event.WindowAdapter; >> +import java.awt.event.WindowEvent; >> import javax.print.DocFlavor; >> import javax.print.PrintService; >> import javax.print.PrintServiceLookup; >> >> Regards >> Prasanta > From philip.race at oracle.com Wed Aug 17 17:39:18 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 17 Aug 2016 10:39:18 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8149562: TIFFField#createFromMetadataNode javadoc should provide information about sibling/child nodes that should be part of parameter node In-Reply-To: <752CE81D-8DAC-4E0E-8090-D615C7218D8D@oracle.com> References: <304A3A05-9085-4C78-AF24-5AE7622399FB@oracle.com> <752CE81D-8DAC-4E0E-8090-D615C7218D8D@oracle.com> Message-ID: <57B4A146.20603@oracle.com> +1 -phil. On 08/16/2016 09:02 AM, Brian Burkhalter wrote: > Please review at your convenience. > > Issue:https://bugs.openjdk.java.net/browse/JDK-8149562 > Patch:[1] > > Add one sentence to the TIFFField.createFromMetadataNode method > specification stating that the supplied Node parameter must adhere to > the TIFFField element structure defined by the TIFF native image > metadata DTD. > > Thanks, > > Brian > > [1] diff > > --- > a/src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFField.java > +++ > b/src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFField.java > > /** > * Creates a {@code TIFFField} from a TIFF native image > * metadata node. If the value of the {@code ?number"} attribute > * of the node is not found in {@code tagSet} then a new > * {@code TIFFTag} with name {@code TIFFTag.UNKNOWN_TAG_NAME} > - * will be created and assigned to the field. > + * will be created and assigned to the field. If the {@code Node} > + * parameter content does not adhere to the {@code TIFFField} element > + * structure defined by the > + * href="../../metadata/doc-files/tiff_metadata.html#ImageMetadata"> > + * TIFF native image metadata format specification > + * an {@code Exception} will be thrown. > * > * @param tagSet The {@code TIFFTagSet} to which the > * {@code TIFFTag} of the field belongs. > * @param node A native TIFF image metadata {@code TIFFField} node. > * @throws NullPointerException if {@code node} is > * {@code null}. > * @throws IllegalArgumentException if the name of the node is not > * {@code "TIFFField"}. > * @throws NullPointerException if the node does not contain any > data. > * @throws IllegalArgumentException if the combination of node > attributes > * and data is not legal per the {@link > #TIFFField(TIFFTag,int,int,Object)} > * constructor specification. > * @return A new {@code TIFFField}. > */ > public static TIFFField createFromMetadataNode(TIFFTagSet tagSet, > Node node) { > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Aug 17 18:09:00 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 17 Aug 2016 11:09:00 -0700 Subject: [OpenJDK 2D-Dev] [9] RFC JDK-8154058: [TIFF] ignoreMetadata parameter of TIFFImageReader's setInput() method affects TIFFImageReadParam in non-obvious way In-Reply-To: <7E7ACA58-AA5C-4352-979C-638993C8B7DF@oracle.com> References: <7E7ACA58-AA5C-4352-979C-638993C8B7DF@oracle.com> Message-ID: <57B4A83C.709@oracle.com> Hi, That all seems fine (for the case of ignoreMetaData == true). But there may be still a bug - of some kind - uncovered by this test. The submitter has this case : ignore = false: EXIF: true Fax : true GPS : true which means that all metadata is being read .. as is the default per the docs on the TIFF package description. But I am wondering what the effect setting of param.removeAllowedTagSet(FaxTIFFTagSet.getInstance()); should have been in this case. A strict reading of the spec. makes it sound like it only has any effect when you specify ignoreMetadata == true but I don't see the point of the API in that case, since you are already ignoring metadata, unless it is just a matter of being more clear to the reader that the latitude it has to read metadata anyway regardless should be tempered by this additional call. But is there not also value in being able to remove the tag from the allowed set in the ignoreMetadata == false case ? That seemed to be the gist of the text here :- >In cases where the IFD includes fields which contain > large amounts of data this could be very inefficient. > Which fields are loaded may be controlled by setting >which TIFF tags the reader is allowed to recognize and whether it is ignoring metadata. eg .. "I want all metadata except Fax" .. -phil. On 08/12/2016 11:23 AM, Brian Burkhalter wrote: > Please comment at your convenience. > > Issue:https://bugs.openjdk.java.net/browse/JDK-8154058 > Solution:Resolve as ?Not an Issue? > > According to [1], > > /The |ignoreMetadata| parameter, if set to |true|, allows the reader > to disregard any metadata encountered during the read. Subsequent > calls to the |getStreamMetadata| and |getImageMetadata| methods may > return |null|, and an |IIOImage| returned from |readAll| may return > |null| from their |getMetadata| method. Setting this parameter may > allow the reader to work more efficiently. The reader may choose to > disregard this setting and return metadata normally. / > > According to [2], setting ignoreMetadata has the effect of asking the > reader to ignore any TIFF Fields which are not contained in any of the > TIFFTagSets known to the reader. This seems to be within the scope of > the specification in [1]. > > As a result of the foregoing I suggest that the issue be resolved as > ?Will not Fix.? > > Thanks, > > Brian > > [1] > http://download.java.net/java/jdk9/docs/api/javax/imageio/ImageReader.html#setInput-java.lang.Object-boolean-boolean- > [2] > http://hg.openjdk.java.net/jdk9/client/jdk/file/d5dc0c4fb473/src/java.desktop/share/classes/javax/imageio/metadata/doc-files/tiff_metadata.html, > lines 219-234 -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Aug 17 19:07:02 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 17 Aug 2016 12:07:02 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6574279: validatePage from PrinterJob returns argument under linux In-Reply-To: <57B2FD59.2060106@oracle.com> References: <5784DD01.4040309@oracle.com> <57A25BE6.3080305@oracle.com> <57A331E4.8000907@oracle.com> <57A46852.4050801@oracle.com> <57AB9E3C.80302@oracle.com> <57AC3983.7020504@oracle.com> <57B2FD59.2060106@oracle.com> Message-ID: <57B4B5D6.4030809@oracle.com> The cups docs say you can get physical margins as described here : http://opensource.apple.com//source/cups/cups-62/doc/spm.shtml?txt#CUPS_API ------------------------ PPD files specify all of the available pages sizes and the physical margins associated with them. ... ppd_sizet_ size = ppdPageSize(ppd, "/size/"); ... The| ||ppd_size_t| structure contains the width, length, and margin information: typedef struct /**** Page Sizes ****/ { int marked; /* Page size selected? */ char name[41]; /* Media size option */ float width, /* Width of media in points */ length, /* Length of media in points */ left, /* Left printable margin in points */ bottom, /* Bottom printable margin in points */ right, /* Right printable margin in points */ top; /* Top printable margin in points */ } ppd_size_t; -------------------- Moreover we are *already* calling that code : See Java_sun_print_CUPSPrinter_getPageSizes Does that not work ? Perhaps the gap is that CUPSPrinter.java does not tie the MPA to the Media it has created. Not sure of the best way to do this. Maybe the windows code solves this differently but a simple HashMap may work here. You'll have to investigate. A few specific comments on the code :- 484 if (option != NULL && option->num_choices > 0) { we are expecting an array of 4 elements here so may be >=4 is what we should require ? 500 JNU_ThrowOutOfMemoryError(env, "Could not create printer name"); comment seems to be a copy from an earlier line .. this is about allocating an array 516 @Override 517 protected void validatePaper(Paper origPaper, Paper newPaper) { 518 if (!(getPrintService() instanceof IPPPrintService)) { 519 super.validatePaper(origPaper, newPaper); 520 return; Hmm. IPPPrintService is Unix only whereas PSPrinterJob is shared code .. so I will bet you didn't try yet to compile this on Windows. -phil. On 8/16/16, 4:47 AM, Prasanta Sadhukhan wrote: > Hi All, > > On 8/11/2016 2:08 PM, Prasanta Sadhukhan wrote: >> Hi Phil, >> >> On 8/11/2016 3:05 AM, Phil Race wrote: >>> There does not seem to be a link to the new webrev in here. >>> >>> Is it this : http://cr.openjdk.java.net/~psadhukhan/6574279/webrev.01/ ? >>> >>> > to default Paper (Letter in US, A4 otherwise) imageable area >>> >>> I don't think that will ever be A4. Where is that coming from ? >>> >>> And you still have not fixed the problem with how you retrieve the >>> MPA :- >>> 512 MediaPrintableArea mpa = (MediaPrintableArea) >>> 513 >>> getPrintService().getDefaultAttributeValue(MediaPrintableArea.class); >>> >>> >>> It is not supposed to be the MPA of the *default* paper. You want >>> the MPA of *this* paper. >>> Only if origPaper is not a supported paper do you go look for the >>> default paper. >>> >> As you suggested, I have modified to check if mpa of origPaper is >> amongst supported mpa(s) of the printer, if not, then go for mpa of >> default paper. >> However, it seems among 61 mpas returned by CUPSPrinter , >> origPaper of 0,0,8.26",11.69" is within supported mpa of a paper size >> 0,0,11.69",16.52" so it means 0,0,8",11" comes out to be supported mpa. >> >> Can you please comment on this modified webrev on what more we can do? >> http://cr.openjdk.java.net/~psadhukhan/6574279/webrev.02/ >> >> I guess we need to find out the physical limitation of printer via >> CUPS same what we do in windows via GetDeviceCaps(printDC, >> PHYSICALOFFSETX); and use that in calculation for valid margin >> but I could not find equivalent cups function. Can you suggest anyways? >> > I tried calling ppdFindOption(ppd, "HWMargins") in CUPS but it returns > null although my printer ppd file has this line > > *%=== Custom Paper Support ================= > *LeadingEdge Short: "" > *LeadingEdge Long: "" > *DefaultLeadingEdge: Short > > *MaxMediaWidth: "865" > *MaxMediaHeight: "1701" > **HWMargins: 12 12 12 12 > > *Anyways, I have updated the webrev to take care of the review > comments and also get HWMargin (if the above ppdFindOption return null > then fall back to custom margin as reported via ppd_file_t structure > https://www.cups.org/doc/api-ppd.html#ppd_file_s) > > http://cr.openjdk.java.net/~psadhukhan/6574279/webrev.03/ > > Please review. Tested in ubuntu and solaris11. > > Regards > Prasanta >> Regards >> Prasanta >>> -phil. >>> >>> On 08/05/2016 03:20 AM, Prasanta Sadhukhan wrote: >>>> >>>> >>>> On 8/4/2016 5:45 PM, Prasanta Sadhukhan wrote: >>>>> I will override in PSPrinterJob but >>>>> 1662 MediaPrintableArea mpa = >>>>> 1663 (MediaPrintableArea)getPrintService(). >>>>> 1664 getDefaultAttributeValue(MediaPrintableArea.class); >>>>> >>>>> is returning imageable area of default media of chosen printer >>>>> from CUPS [ all supported media printable area is obtained from >>>>> CUPSPrinter#getPageSizes(printer) & then initMedia() populates >>>>> cupsMediaPrintables which is returned in getMediaPrintableArea()] >>>>> as IPPPrintService#getDefaultAttributeValue() does >>>>> ---------- >>>>> if (category == MediaPrintableArea.class) { >>>>> MediaPrintableArea[] mpas; >>>>> if ((cps != null) && >>>>> ((mpas = *cps.getMediaPrintableArea()*) != null)) { >>>>> if (defaultMediaIndex == -1) { >>>>> // initializes value of defaultMediaIndex >>>>> getDefaultAttributeValue(Media.class); >>>>> } >>>>> return mpas[*defaultMediaIndex*]; >>>>> } >>>>> -------------- >>>>> by which mpas[defaultMediaIndex] returns default media printable >>>>> area. >>>>> In else block, we instantiate mpa of Letter for US locale and A4 >>>>> for other locales so I was not checking for null as in both if and >>>>> else block , I was getting MediaPrintableArea instance. >>>>> >>>>> Regarding considering equal margins, I am not sure if there was >>>>> any way I could get right and left margin separately. >>>>> Please let me know if there is any way you know of. >>>> I have modified to do the change in PSPrinterJob. Regarding the >>>> equal margin, we do the same in >>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/abb2a39948fe/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java#l688 >>>> http://cr.openjdk.java.net/~psadhukhan/6574279/webrev.01/ >>> >>> That does not seem to be the same case as this. >>> >>> -phil. >>> >>>> >>>> Regards >>>> Prasanta >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 8/4/2016 2:32 AM, Philip Race wrote: >>>>>> High-level question. Why is this not an over-ride in PSPrinterJob ? >>>>>> >>>>>> >>>>>> I'm afraid I did not get much past the first line of the change : >>>>>> 1662 MediaPrintableArea mpa = >>>>>> 1663 (MediaPrintableArea)getPrintService(). >>>>>> 1664 getDefaultAttributeValue(MediaPrintableArea.class); >>>>>> >>>>>> Read the docs for MediaPrintableArea :- >>>>>> --- >>>>>> To query for the printable area, a client must supply a suitable >>>>>> context. >>>>>> Without specifying at the very least the size of the media being >>>>>> used >>>>>> no meaningful value for printable area can be obtained. >>>>>> --- >>>>>> >>>>>> .. not to mention you assume a non-null return. >>>>>> >>>>>> and then you use new Paper() .. which is a constructor which >>>>>> knows nothing about the printer. It is *speced* to return >>>>>> US letter with one inch margins. >>>>>> >>>>>> Another reason why this seems like it should be a sub-class >>>>>> over-ride. >>>>>> >>>>>> >>>>>> Also this looks wrong --- >>>>>> 1672 if ((imgX*2) + imgWid > wid) { >>>>>> 1673 imgWid = wid - imgX*2; >>>>>> 1674 } >>>>>> >>>>>> You can't assume equal margins. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 7/12/16, 5:05 AM, Prasanta Sadhukhan wrote: >>>>>>> Hi All, >>>>>>> >>>>>>> Please review a fix for an issue where it is seen that if user >>>>>>> sets invalid imageablearea via Paper.setImageableArea and >>>>>>> then calls PrinterJob.validatePage() in linux, then it does not >>>>>>> get a valid pageformat >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6574279 >>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6574279/webrev.00/ >>>>>>> >>>>>>> Fix is to check for margin as noted via CUPS ppdPageSize() and >>>>>>> then calculate to find the valid margin in validatePaper() >>>>>>> similar to what we do in native validatePaper() in windows. >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Aug 17 20:11:59 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 17 Aug 2016 13:11:59 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() method does not work when called inside imageStarted for PNG In-Reply-To: References: <06aa9e0a-bf19-4dd0-949a-c3c0cb00d4b1@default> Message-ID: <57B4C50F.6050809@oracle.com> I think we can - get all plugins,and for each - write a file in that format - read it back and apply the test It is also worth verifying that the writer abort checks are in sync with the reader aborts, ie happen at such equivalent points as might exist. -phil. On 08/15/2016 11:30 AM, Sergey Bylokhov wrote: > Is it possible to unify the test for all our plugins? I assume they > should work in the same way. I am not sure but probably the image can > be generated at runtime? > > On 11.08.16 21:59, Jayathirth D V wrote: >> Hi, >> >> >> >> Please review the following fix in JDK9 at your convenience: >> >> >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-4924727 >> >> >> >> Webrev : http://cr.openjdk.java.net/~jdv/4924727/webrev.00/ >> >> >> >> Issue : When we issue ImageReader.abort() in >> IIOReadProgressListener.imageStarted(), reading is not aborted and it is >> continued. >> >> >> >> Root cause : After IIOReadProgressListener.imageStarted() call in >> PNGImageReader.java when we enter decodeImage() we call >> clearAbortRequest() which will clear the abort request from >> IIOReadProgressListener.imageStarted(). >> >> >> >> Solution : clearAbortRequest() documentation mentions that it should be >> called before reading of image starts, so it should be called before >> IIOReadProgressListener.imageStarted()(In PNGImageReader.java it is >> processImageStarted(0) in readImage()). So moved clearAbortRequest() >> call from decodeImage() to readImage(). Also we should call >> abortRequested() in PNGImageReader.java at places mapping to >> IIOReadProgressListener and not randomly at end of functions or at >> places related to IIOReadUpdateListener, updated the code for the same. >> >> >> >> >> >> Observation not related to this issue : We don?t have call similar to >> IIOReadProgressListener.readAborted() in IIOReadUpdateListener, but user >> can call ImageReader.abort() from IIOReadUpdateListener methods. Is >> there a need to add similar method in IIOReadUpdateListener? Any inputs >> on this also would be helpful. >> >> >> >> Thanks, >> >> Jay >> > > From prasanta.sadhukhan at oracle.com Thu Aug 18 06:36:09 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 18 Aug 2016 12:06:09 +0530 Subject: [OpenJDK 2D-Dev] [9] Review Request: JDK-8158524: Test file added for VolatileImage -vs- BufferedImage output comparison In-Reply-To: <886e9001-9394-44eb-b8fa-aea4c4c923cc@default> References: <57AC29D7.90605@oracle.com> <60d1ffac-ebdc-4b0a-a7b2-c62a67bc90d7@default> <7ad2d0be-1c49-f9b9-4b50-d3bab2b78139@oracle.com> <508122c4-403d-f059-52f1-147e8c02f55f@oracle.com> <886e9001-9394-44eb-b8fa-aea4c4c923cc@default> Message-ID: <57B55759.4080600@oracle.com> +1 although I am not sure if JFrame is required. Probably it can be done with Frame too. Regards Prasanta On 8/16/2016 1:41 PM, Prahalad Kumar Narayanan wrote: > Hello Everyone > > This is a follow-up to my webrev. > > Thanks to Sergey for his feedback. > I 've incorporated the feedback and changes are now available for review > Link: http:// http://cr.openjdk.java.net/~pnarayanan/8158524/webrev.02/ > > Summary on changes from previous revision: > . '@key headful' has been added to the jtreg comments > . Swing UI components are invoked on EDT > > Kindly review the changes and provide your feedback at your convenience > > Thank you > Have a good day > > Prahalad N. > > > -----Original Message----- > From: Sergey Bylokhov > Sent: Friday, August 12, 2016 6:39 PM > To: Prahalad Kumar Narayanan; Prasanta Sadhukhan; 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] [9] Review Request: JDK-8158524: Test file added for VolatileImage -vs- BufferedImage output comparison > > On 12.08.16 16:06, Sergey Bylokhov wrote: >> Looks fine. >> Please add @key heedful jtreg tag before the push. > Ouch I just realize that the test use the Swing components on non-EDT. > >> On 11.08.16 13:22, Prahalad Kumar Narayanan wrote: >>> Hello Everyone >>> >>> First, Thanks to Prasanta for his feedback. >>> I 've incorporated the feedback in the code and changes are available >>> for review. >>> Review Link: >>> http://cr.openjdk.java.net/~pnarayanan/8158524/webrev.01/ >>> >>> Quick summary on changes from previous revision: >>> . Wild card imports have been replaced with specific imports >>> . @override annotation has been added to the paint() method >>> . RuntimeException is thrown instead of Error though both would >>> report regression failure. >>> . Image loading has been corrected with proper filePath. >>> . With regard to image and licensing issue: >>> . I checked the image properties. There is no >>> 'author/copyright' information with this image. >>> . The file matches when compared (binary) with the >>> similar .gif image in test/java/awt/print/PrinterJob/ >>> >>> Kindly review the changes at your convenience and share your views. >>> >>> Thank you >>> Have a good day >>> >>> Prahalad N. >>> >>> >>> -----Original Message----- >>> From: Prasanta Sadhukhan >>> Sent: Thursday, August 11, 2016 1:02 PM >>> To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net >>> Cc: Philip Race; Sergey Bylokhov >>> Subject: Re: [OpenJDK 2D-Dev] [9] Review Request: JDK-8158524: Test >>> file added for VolatileImage -vs- BufferedImage output comparison >>> >>> You need to use @Override annotation for paint() method. Also, you >>> can use specific imports rather than package imports. >>> Also, I guess it's better to throw RuntimeException than Error for >>> failure, not sure how jtreg will react to it. >>> Lastly, I am not sure if you can use duke.gif image which maynot be >>> licensed although we have similar duke.gif in java/awt/print/PrinterJob. >>> >>> Regards >>> Prasanta >>> On 8/11/2016 11:30 AM, Prahalad Kumar Narayanan wrote: >>>> Hello Everyone >>>> >>>> Good day to you. >>>> >>>> I 'm planning to add a test file into jdk/test/ repository. >>>> The webrev changes for the test file is presented herewith. >>>> Link: >>>> http://cr.openjdk.java.net/~pnarayanan/8158524/webrev.00/ >>>> >>>> Brief on the test & its objectives: >>>> . As we know, VolatileImage utilizes accelerated rendering >>>> using GPU while BufferedImage utilizes software rendering >>>> . The objective of this test-case is to check whether the >>>> rendered 2d primitives appear same on VolatileImage and BufferedImage >>>> . In rare cases, the rendering on VolatileImage might >>>> differ by few pixels from BufferedImage due to D3D/OpenGL driver 's >>>> handling of primitives >>>> . Java2D pipelines for D3D/OpenGL APIs use fudge >>>> factors to fine tune rendering calls so that output matches with >>>> output of BufferedImage. >>>> . Thus the test case will help in checking for >>>> consistent rendering across pipelines and also in identifying >>>> scenarios where pipelines need to be fine-tuned. >>>> >>>> Kindly review the test file and share your views at your convenience >>>> >>>> Thank you >>>> Have a good day >>>> >>>> Prahalad N. >> > > -- > Best regards, Sergey. From prasanta.sadhukhan at oracle.com Thu Aug 18 06:41:17 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 18 Aug 2016 12:11:17 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6357887: selected printertray is ignored under linux In-Reply-To: <57B48517.3030200@oracle.com> References: <57AAECFD.2030802@oracle.com> <57B48517.3030200@oracle.com> Message-ID: <57B5588D.1050909@oracle.com> MediaTray values are bundled with "Media" attribute so calling attributes.get(CustomMediatray.class) returns null. Modified webrev to get Media attribute and then see if the attribute is an instance of CustomMediatray. http://cr.openjdk.java.net/~psadhukhan/6357887/webrev.01/ Regards Prasanta On 8/17/2016 9:09 PM, Philip Race wrote: > This all looks fine although this can be a simple call to > attributes.get(CustomMediaTray.class) can't it ? > > 502 for (int i=0; i< attrs.length; i++) { > 503 Attribute attr = attrs[i]; > 504 try { > 505 if (attr instanceof CustomMediaTray) { > 506 CustomMediaTray customTray = > (CustomMediaTray)attr; > 507 mOptions = " InputSlot="+ > customTray.getChoiceName(); > 508 } > 509 } catch (ClassCastException e) { > > -phil. > > On 8/10/16, 1:59 AM, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a fix for an issue where it is seen that the selected >> printer tray is ignored in linux and default standard tray is used >> for printing. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-6357887 >> webrev: http://cr.openjdk.java.net/~psadhukhan/6357887/webrev.00/ >> >> Issue was lpr command needs "-o InputSlot=" to select the >> printertray which was not being passed to lpr command. >> Proposed fix added InputSlot option to lpr command to select the >> printertray. >> >> Tested in ubuntu and solaris11. >> >> Regards >> Prasanta From prasanta.sadhukhan at oracle.com Thu Aug 18 06:42:37 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 18 Aug 2016 12:12:37 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6357887: selected printertray is ignored under linux In-Reply-To: <57B5588D.1050909@oracle.com> References: <57AAECFD.2030802@oracle.com> <57B48517.3030200@oracle.com> <57B5588D.1050909@oracle.com> Message-ID: <57B558DD.4090204@oracle.com> On 8/18/2016 12:11 PM, Prasanta Sadhukhan wrote: > MediaTray values are bundled with "Media" attribute so calling > attributes.get(CustomMediatray.class) returns null. > Modified webrev to get Media attribute and then see if the attribute > is an instance of CustomMediatray. > > http://cr.openjdk.java.net/~psadhukhan/6357887/webrev.01/ > Also,removed some unused imports. > Regards > Prasanta > On 8/17/2016 9:09 PM, Philip Race wrote: >> This all looks fine although this can be a simple call to >> attributes.get(CustomMediaTray.class) can't it ? >> >> 502 for (int i=0; i< attrs.length; i++) { >> 503 Attribute attr = attrs[i]; >> 504 try { >> 505 if (attr instanceof CustomMediaTray) { >> 506 CustomMediaTray customTray = >> (CustomMediaTray)attr; >> 507 mOptions = " InputSlot="+ >> customTray.getChoiceName(); >> 508 } >> 509 } catch (ClassCastException e) { >> >> -phil. >> >> On 8/10/16, 1:59 AM, Prasanta Sadhukhan wrote: >>> Hi All, >>> >>> Please review a fix for an issue where it is seen that the selected >>> printer tray is ignored in linux and default standard tray is used >>> for printing. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-6357887 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/6357887/webrev.00/ >>> >>> Issue was lpr command needs "-o InputSlot=" to select the >>> printertray which was not being passed to lpr command. >>> Proposed fix added InputSlot option to lpr command to select the >>> printertray. >>> >>> Tested in ubuntu and solaris11. >>> >>> Regards >>> Prasanta > From prem.balakrishnan at oracle.com Thu Aug 18 09:42:18 2016 From: prem.balakrishnan at oracle.com (Prem Balakrishnan) Date: Thu, 18 Aug 2016 02:42:18 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails In-Reply-To: References: <1d62d8f6-c7e6-e5c6-38e2-1764fea8011b@oracle.com> <94e9c6a3-2e9f-4405-a5c5-1e4dadeba7d9@default> <3e53ac2e-ba9b-b4e9-3ebd-bccb35bc6650@oracle.com> Message-ID: <75f3e1d7-dfc0-4d0c-84d9-192b306d0728@default> Added "2d-dev" team for review Regards, Prem From: Alexandr Scherbatiy Sent: Thursday, August 18, 2016 2:57 PM To: Prem Balakrishnan; Rajeev Chamyal; awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails Could you also send the review to the 2d-dev alias? Thanks, Alexandr. On 8/18/2016 9:59 AM, Prem Balakrishnan wrote: Hi Alexandr, AccelSurface is implemented by *ONLY* D3DSurfaceData and OGLSurfaceData classes, Both of these classes extend SurfaceData as well. Hence, casting of 'as' variable which is of type AccelSurface object to SurfaceData is always VALID. Regards, Prem From: Alexandr Scherbatiy Sent: Wednesday, August 17, 2016 4:42 PM To: Prem Balakrishnan; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails On 8/17/2016 11:30 AM, Prem Balakrishnan wrote: Hi Alexandr, Thankyou for the review. YES scaled SurfaceData returns proper scale values from getDefaultScaleX()/getDefaultScaleY(), which I have used in the current patch. Please review the updated patch HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.02/"http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.02/ Is it always true that the 'as' variable which has type AccelSurface in the fix is always instance of SurfaceData? Thanks, Alexandr. Regards, Prem From: Alexandr Scherbatiy Sent: Tuesday, August 16, 2016 10:06 PM To: Prem Balakrishnan; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails On 8/16/2016 7:35 AM, Prem Balakrishnan wrote: Reminder From: Prem Balakrishnan Sent: Friday, August 12, 2016 6:36 PM To: Alexander Scherbatiy; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: RE: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails Hi Alexandr and Sergey, Please review the updated patch. HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.01/"http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.01/ >>"It is a little bit strange bug, because VolatileImage should handle this scale internally, and create double sized surface when necessary".-Sergey Yes as you mentioned Volatile Image is getting scaled internally. Thanks for the feedback. Cause: In VIOptWindowPainter::updateWindowAccel(psdops, w, h) call, width and height were passed without scaling, which was creating a bitmap of specified width and height, hence the output was clipped. I just have two general questions. - The scaled SurfaceData should return proper scales from getDefaultScaleX()/getDefaultScaleY() methods. Do these methods return right values after setting the scaled image sizes in the fix? - Region.clipScale() which is used in many places rounds values. The usual rule is to use Math.floor() for image coordinates rounding and Math.ceil() for sizes. Should the same rule be applicable here? Thanks, Alexandr. Regards, Prem From: Alexandr Scherbatiy Sent: Thursday, August 04, 2016 6:23 PM To: Prem Balakrishnan; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails On 8/3/2016 10:04 AM, Prem Balakrishnan wrote: Hi, Please review fix for JDK9, Bug: https://bugs.openjdk.java.net/browse/JDK-8144735 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.00/"http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.00/ Issue: javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails Cause: While creating Transparent VolatileImage, width and height was NOT hidpi scaled. Fix: VolatileImage width and height are scaled. I believe this is an issue in AWT and needs to be discussed on awt-dev alias. Should the backbuffer width and height be also scaled for the BIWindowPainter? Thanks, Alexandr. Thanks, Prem -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Thu Aug 18 11:07:46 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 18 Aug 2016 04:07:46 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8163922: Print-to-file is disabled for SERVICE_FORMATTED docflavor in linux In-Reply-To: <57AD5D09.2090606@oracle.com> References: <57AD5D09.2090606@oracle.com> Message-ID: Hi Prasanta, ? Can you please verify whether we have any test case already present which actually checks this basic behavior of visible Print-to-File option enabled in SERVICE_FORMATTED DocFlavor. ? If not, we need to add test case which checks this behavior specifically, so that it can be part of regression test for the code change made in ServiceDialog.java. ? Thanks, Jay ? From: Prasanta Sadhukhan Sent: Friday, August 12, 2016 10:52 AM To: Philip Race; 2d-dev Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8163922: Print-to-file is disabled for SERVICE_FORMATTED docflavor in linux ? Hi All, Please review a fix for an issue where it is seen that Print-to-File option is disabled even for SERVICE_FORMATTED DocFlavor after HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-5049012"JDK-5049012 fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8163922 webrev: http://cr.openjdk.java.net/~psadhukhan/8163922/webrev.00/ We need to enabled dstSupported even if the destination is not specified for SERVICE_FORMATTED DocFlavor. Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Thu Aug 18 11:59:33 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 18 Aug 2016 17:29:33 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8163922: Print-to-file is disabled for SERVICE_FORMATTED docflavor in linux In-Reply-To: References: <57AD5D09.2090606@oracle.com> Message-ID: <57B5A325.6010408@oracle.com> Ok. I have extended the testcase to check both the non SERVICE_FORMATTED and SERVICE_FORMATTED cases by showing 2 print dialogs. Please have a look. http://cr.openjdk.java.net/~psadhukhan/8163922/webrev.01/ Regards Prasanta On 8/18/2016 4:37 PM, Jayathirth D V wrote: > > Hi Prasanta, > > Can you please verify whether we have any test case already present > which actually checks this basic behavior of visible Print-to-File > option enabled in SERVICE_FORMATTED DocFlavor. > > If not, we need to add test case which checks this behavior > specifically, so that it can be part of regression test for the code > change made in ServiceDialog.java. > > Thanks, > > Jay > > *From:*Prasanta Sadhukhan > *Sent:* Friday, August 12, 2016 10:52 AM > *To:* Philip Race; 2d-dev > *Subject:* [OpenJDK 2D-Dev] [9] RFR JDK-8163922: Print-to-file is > disabled for SERVICE_FORMATTED docflavor in linux > > Hi All, > > Please review a fix for an issue where it is seen that Print-to-File > option is disabled even for SERVICE_FORMATTED DocFlavor after > JDK-5049012 fix. > Bug: https://bugs.openjdk.java.net/browse/JDK-8163922 > webrev: http://cr.openjdk.java.net/~psadhukhan/8163922/webrev.00/ > > > We need to enabled dstSupported even if the destination is not > specified for SERVICE_FORMATTED DocFlavor. > > Regards > Prasanta > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Thu Aug 18 16:04:53 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 18 Aug 2016 09:04:53 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8163258 : Getting NullPointerException from ImageIO.getReaderWriterInfo due to failure to check for null Message-ID: <49ab65c7-1dde-42ea-9066-facd386f685e@default> Hi, Please review the following fix in JDK9 at your convenience: Bug : https://bugs.openjdk.java.net/browse/JDK-8163258 Webrev : http://cr.openjdk.java.net/~jdv/8163258/webrev.00/ Issue : When we call ImageIO.getReaderMIMETypes() or ImageIO. getFileSuffixes() with MIMEType or FileSuffix as null in subclass ImageReaderSpi it throws NullPointerException. Root cause : We allow MIMEType and FileSuffix to be null in ImageReaderWriterSpi. But when we call getReaderMIMETypes() or getFileSuffixes() we try populate HashSet using Collections.addALL() which throws NPE. Solution : Before we populate HashSet using Collections.addALL() verify whether the input is null. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Thu Aug 18 16:12:47 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 18 Aug 2016 09:12:47 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8163922: Print-to-file is disabled for SERVICE_FORMATTED docflavor in linux In-Reply-To: <57B5A325.6010408@oracle.com> References: <57AD5D09.2090606@oracle.com> <57B5A325.6010408@oracle.com> Message-ID: Hi Prasanta, ? Changes are working fine. ? Thanks, Jay ? From: Prasanta Sadhukhan Sent: Thursday, August 18, 2016 5:30 PM To: Jayathirth D V; Philip Race; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-8163922: Print-to-file is disabled for SERVICE_FORMATTED docflavor in linux ? Ok. I have extended the testcase to check both the non SERVICE_FORMATTED and SERVICE_FORMATTED cases by showing 2 print dialogs. Please have a look. http://cr.openjdk.java.net/~psadhukhan/8163922/webrev.01/ Regards Prasanta On 8/18/2016 4:37 PM, Jayathirth D V wrote: Hi Prasanta, ? Can you please verify whether we have any test case already present which actually checks this basic behavior of visible Print-to-File option enabled in SERVICE_FORMATTED DocFlavor. ? If not, we need to add test case which checks this behavior specifically, so that it can be part of regression test for the code change made in ServiceDialog.java. ? Thanks, Jay ? From: Prasanta Sadhukhan Sent: Friday, August 12, 2016 10:52 AM To: Philip Race; 2d-dev Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8163922: Print-to-file is disabled for SERVICE_FORMATTED docflavor in linux ? Hi All, Please review a fix for an issue where it is seen that Print-to-File option is disabled even for SERVICE_FORMATTED DocFlavor after HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-5049012"JDK-5049012 fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8163922 webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/8163922/webrev.00/"http://cr.openjdk.java.net/~psadhukhan/8163922/webrev.00/ We need to enabled dstSupported even if the destination is not specified for SERVICE_FORMATTED DocFlavor. Regards Prasanta ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Aug 18 21:52:32 2016 From: philip.race at oracle.com (Philip Race) Date: Thu, 18 Aug 2016 14:52:32 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8163258 : Getting NullPointerException from ImageIO.getReaderWriterInfo due to failure to check for null In-Reply-To: <49ab65c7-1dde-42ea-9066-facd386f685e@default> References: <49ab65c7-1dde-42ea-9066-facd386f685e@default> Message-ID: <57B62E20.7050603@oracle.com> +1 -phil On 8/18/16, 9:04 AM, Jayathirth D V wrote: > > Hi, > > Please review the following fix in JDK9 at your convenience: > > Bug : https://bugs.openjdk.java.net/browse/JDK-8163258 > > Webrev : http://cr.openjdk.java.net/~jdv/8163258/webrev.00/ > > > Issue : When we call ImageIO.getReaderMIMETypes() or ImageIO. > getFileSuffixes() with MIMEType or FileSuffix as null in subclass > ImageReaderSpi it throws NullPointerException. > > Root cause : We allow MIMEType and FileSuffix to be null in > ImageReaderWriterSpi. But when we call getReaderMIMETypes() or > getFileSuffixes() we try populate HashSet using Collections.addALL() > which throws NPE. > > Solution : Before we populate HashSet using Collections.addALL() > verify whether the input is null. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Aug 18 21:53:43 2016 From: philip.race at oracle.com (Philip Race) Date: Thu, 18 Aug 2016 14:53:43 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8163922: Print-to-file is disabled for SERVICE_FORMATTED docflavor in linux In-Reply-To: References: <57AD5D09.2090606@oracle.com> <57B5A325.6010408@oracle.com> Message-ID: <57B62E67.3040801@oracle.com> +1 -phil On 8/18/16, 9:12 AM, Jayathirth D V wrote: > > Hi Prasanta, > > Changes are working fine. > > Thanks, > > Jay > > *From:*Prasanta Sadhukhan > *Sent:* Thursday, August 18, 2016 5:30 PM > *To:* Jayathirth D V; Philip Race; 2d-dev > *Subject:* Re: [OpenJDK 2D-Dev] [9] RFR JDK-8163922: Print-to-file is > disabled for SERVICE_FORMATTED docflavor in linux > > Ok. I have extended the testcase to check both the non > SERVICE_FORMATTED and SERVICE_FORMATTED cases by showing 2 print dialogs. > Please have a look. > http://cr.openjdk.java.net/~psadhukhan/8163922/webrev.01/ > > > Regards > Prasanta > > On 8/18/2016 4:37 PM, Jayathirth D V wrote: > > Hi Prasanta, > > Can you please verify whether we have any test case already > present which actually checks this basic behavior of visible > Print-to-File option enabled in SERVICE_FORMATTED DocFlavor. > > If not, we need to add test case which checks this behavior > specifically, so that it can be part of regression test for the > code change made in ServiceDialog.java. > > Thanks, > > Jay > > *From:*Prasanta Sadhukhan > *Sent:* Friday, August 12, 2016 10:52 AM > *To:* Philip Race; 2d-dev > *Subject:* [OpenJDK 2D-Dev] [9] RFR JDK-8163922: Print-to-file is > disabled for SERVICE_FORMATTED docflavor in linux > > Hi All, > > Please review a fix for an issue where it is seen that > Print-to-File option is disabled even for SERVICE_FORMATTED > DocFlavor after JDK-5049012 > fix. > Bug: https://bugs.openjdk.java.net/browse/JDK-8163922 > webrev: http://cr.openjdk.java.net/~psadhukhan/8163922/webrev.00/ > > > We need to enabled dstSupported even if the destination is not > specified for SERVICE_FORMATTED DocFlavor. > > Regards > Prasanta > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Aug 18 22:06:24 2016 From: philip.race at oracle.com (Philip Race) Date: Thu, 18 Aug 2016 15:06:24 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6357887: selected printertray is ignored under linux In-Reply-To: <57B5588D.1050909@oracle.com> References: <57AAECFD.2030802@oracle.com> <57B48517.3030200@oracle.com> <57B5588D.1050909@oracle.com> Message-ID: <57B63160.80908@oracle.com> Oh .. right under the covers the map is just a HashMap and the key to the map is the class so just decides if these are equal class objects. Hmm .. I don't know anymore if that was the original intent but we probably should not mess with it right now just for the optimisation. But now I am wondering why it has to be CustomMediaTray and not just MediaTray ... although I suspect that in the case of CUPS we are not ever mapping the media to standard ones, so they are always custom. That might be arise as a problem in the case of your other open review regarding validating the margins. I'll comment on that in that review but still surely any MediaTray is what you would want here but it is probably moot if you don't ever get a standard one. Please check into this and confirm what I suspect .. or not ... -phil. On 8/17/16, 11:41 PM, Prasanta Sadhukhan wrote: > MediaTray values are bundled with "Media" attribute so calling > attributes.get(CustomMediatray.class) returns null. > Modified webrev to get Media attribute and then see if the attribute > is an instance of CustomMediatray. > > http://cr.openjdk.java.net/~psadhukhan/6357887/webrev.01/ > > Regards > Prasanta > On 8/17/2016 9:09 PM, Philip Race wrote: >> This all looks fine although this can be a simple call to >> attributes.get(CustomMediaTray.class) can't it ? >> >> 502 for (int i=0; i< attrs.length; i++) { >> 503 Attribute attr = attrs[i]; >> 504 try { >> 505 if (attr instanceof CustomMediaTray) { >> 506 CustomMediaTray customTray = >> (CustomMediaTray)attr; >> 507 mOptions = " InputSlot="+ >> customTray.getChoiceName(); >> 508 } >> 509 } catch (ClassCastException e) { >> >> -phil. >> >> On 8/10/16, 1:59 AM, Prasanta Sadhukhan wrote: >>> Hi All, >>> >>> Please review a fix for an issue where it is seen that the selected >>> printer tray is ignored in linux and default standard tray is used >>> for printing. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-6357887 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/6357887/webrev.00/ >>> >>> Issue was lpr command needs "-o InputSlot=" to select the >>> printertray which was not being passed to lpr command. >>> Proposed fix added InputSlot option to lpr command to select the >>> printertray. >>> >>> Tested in ubuntu and solaris11. >>> >>> Regards >>> Prasanta > From philip.race at oracle.com Thu Aug 18 22:10:16 2016 From: philip.race at oracle.com (Philip Race) Date: Thu, 18 Aug 2016 15:10:16 -0700 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8164104 Cleanup of javaclient related mapfiles In-Reply-To: <9db92a0e-69f4-a299-714e-02cb7fffd165@oracle.com> References: <9a63d42e-935e-44c9-56be-282a837ca85c@oracle.com> <57B3405D.2060504@oracle.com> <9db92a0e-69f4-a299-714e-02cb7fffd165@oracle.com> Message-ID: <57B63248.3080904@oracle.com> On 8/17/16, 6:33 AM, Sergey Bylokhov wrote: > Tested on solarisX64/solarisSparc/linuxX64 no issues were > found(SwingSet2/Java2Demo). Sounds good. +1 > But I wonder why the text on solarissparc filled by yellow shadow(Is > it a known issue)? Yes there is an open bug. I believe it is a SPARC (or more probably big endian) issue in the Xrender server-side support for sub-pixel text. I believe I've observed this with Xvnc where both X libs, Xserver and Vnc are all running on the SPARC server and the latter two in one combined process. So a bug "not in our code" but I've never been able to put all the pieces together - or rather find the time to do that - to find where in the stack the problem lies. -phil. > > On 16.08.16 19:33, Phil Race wrote: >> I think "JPRT is OK" is good but may be not enough here? >> I am not sure if the build will complain about missing entries >> for JNI methods since there is no direct linking against these. >> Can you do a quick sanity run through of Java2Demo on Linux .. >> and ideally Solaris x64 too. >> >> -phil. >> >> On 08/16/2016 09:22 AM, Sergey Bylokhov wrote: >>> Hello. >>> >>> Please review cleanup of mapfiles, initially the problem was found >>> here: >>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011734.html >>> >>> - tabs were replaced by spaces >>> - doubled empty lines removed >>> >>> jprt is ok. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164104 >>> Patch can be found at: >>> http://cr.openjdk.java.net/~serb/8164104/webrev.00/jdk.patch >>> >> > > From philip.race at oracle.com Thu Aug 18 22:26:59 2016 From: philip.race at oracle.com (Philip Race) Date: Thu, 18 Aug 2016 15:26:59 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6574279: validatePage from PrinterJob returns argument under linux In-Reply-To: <57B4B5D6.4030809@oracle.com> References: <5784DD01.4040309@oracle.com> <57A25BE6.3080305@oracle.com> <57A331E4.8000907@oracle.com> <57A46852.4050801@oracle.com> <57AB9E3C.80302@oracle.com> <57AC3983.7020504@oracle.com> <57B2FD59.2060106@oracle.com> <57B4B5D6.4030809@oracle.com> Message-ID: <57B63633.8070004@oracle.com> PS as I just mentioned in another review thread, I have a suspicion that the Media and MPA for CUPS are never matched to "standard" (pre-defined in API) ones. I don't know how much this matters - A4 when sent to printing should (he says) get matched on size to the right media but you should check that, but this also may mean that if you try to get the MPA for the "standard" MediaSizeName.ISO_A4 none will be found .. all this sets back this fix until you work through that but I don't think the fix can be completely right until we have an understanding and resolution on that. -phil. On 8/17/16, 12:07 PM, Phil Race wrote: > The cups docs say you can get physical margins as described here : > > http://opensource.apple.com//source/cups/cups-62/doc/spm.shtml?txt#CUPS_API > ------------------------ > PPD files specify all of the available pages sizes and the physical > margins associated with them. > ... > > ppd_sizet_ size = ppdPageSize(ppd, "/size/"); > ... > > The| ||ppd_size_t| structure contains the width, length, and margin information: > > > typedef struct /**** Page Sizes ****/ > { > int marked; /* Page size selected? */ > char name[41]; /* Media size option */ > float width, /* Width of media in points */ > length, /* Length of media in points */ > left, /* Left printable margin in points */ > bottom, /* Bottom printable margin in points */ > right, /* Right printable margin in points */ > top; /* Top printable margin in points */ > } ppd_size_t; > > > -------------------- > > > Moreover we are *already* calling that code : > See Java_sun_print_CUPSPrinter_getPageSizes > > Does that not work ? > Perhaps the gap is that CUPSPrinter.java does not tie the MPA to the Media > it has created. Not sure of the best way to do this. Maybe the windows > code > solves this differently but a simple HashMap may work here. You'll have to > investigate. > > A few specific comments on the code :- > > > 484 if (option != NULL && option->num_choices > 0) { we are expecting > an array of 4 elements here so may be >=4 is what we should require ? > 500 JNU_ThrowOutOfMemoryError(env, "Could not create printer name"); > comment seems to be a copy from an earlier line .. this is about > allocating an array > > 516 @Override > 517 protected void validatePaper(Paper origPaper, Paper newPaper) { > 518 if (!(getPrintService() instanceof IPPPrintService)) { > 519 super.validatePaper(origPaper, newPaper); > 520 return; > > Hmm. IPPPrintService is Unix only whereas PSPrinterJob is shared code .. > so I will bet you didn't try yet to compile this on Windows. > > > -phil. > > On 8/16/16, 4:47 AM, Prasanta Sadhukhan wrote: >> Hi All, >> >> On 8/11/2016 2:08 PM, Prasanta Sadhukhan wrote: >>> Hi Phil, >>> >>> On 8/11/2016 3:05 AM, Phil Race wrote: >>>> There does not seem to be a link to the new webrev in here. >>>> >>>> Is it this : >>>> http://cr.openjdk.java.net/~psadhukhan/6574279/webrev.01/ ? >>>> >>>> > to default Paper (Letter in US, A4 otherwise) imageable area >>>> >>>> I don't think that will ever be A4. Where is that coming from ? >>>> >>>> And you still have not fixed the problem with how you retrieve the >>>> MPA :- >>>> 512 MediaPrintableArea mpa = (MediaPrintableArea) >>>> 513 >>>> getPrintService().getDefaultAttributeValue(MediaPrintableArea.class); >>>> >>>> >>>> It is not supposed to be the MPA of the *default* paper. You want >>>> the MPA of *this* paper. >>>> Only if origPaper is not a supported paper do you go look for the >>>> default paper. >>>> >>> As you suggested, I have modified to check if mpa of origPaper is >>> amongst supported mpa(s) of the printer, if not, then go for mpa of >>> default paper. >>> However, it seems among 61 mpas returned by CUPSPrinter , >>> origPaper of 0,0,8.26",11.69" is within supported mpa of a paper >>> size 0,0,11.69",16.52" so it means 0,0,8",11" comes out to be >>> supported mpa. >>> >>> Can you please comment on this modified webrev on what more we can do? >>> http://cr.openjdk.java.net/~psadhukhan/6574279/webrev.02/ >>> >>> I guess we need to find out the physical limitation of printer via >>> CUPS same what we do in windows via GetDeviceCaps(printDC, >>> PHYSICALOFFSETX); and use that in calculation for valid margin >>> but I could not find equivalent cups function. Can you suggest anyways? >>> >> I tried calling ppdFindOption(ppd, "HWMargins") in CUPS but it >> returns null although my printer ppd file has this line >> >> *%=== Custom Paper Support ================= >> *LeadingEdge Short: "" >> *LeadingEdge Long: "" >> *DefaultLeadingEdge: Short >> >> *MaxMediaWidth: "865" >> *MaxMediaHeight: "1701" >> **HWMargins: 12 12 12 12 >> >> *Anyways, I have updated the webrev to take care of the review >> comments and also get HWMargin (if the above ppdFindOption return >> null then fall back to custom margin as reported via ppd_file_t >> structure >> https://www.cups.org/doc/api-ppd.html#ppd_file_s) >> >> http://cr.openjdk.java.net/~psadhukhan/6574279/webrev.03/ >> >> Please review. Tested in ubuntu and solaris11. >> >> Regards >> Prasanta >>> Regards >>> Prasanta >>>> -phil. >>>> >>>> On 08/05/2016 03:20 AM, Prasanta Sadhukhan wrote: >>>>> >>>>> >>>>> On 8/4/2016 5:45 PM, Prasanta Sadhukhan wrote: >>>>>> I will override in PSPrinterJob but >>>>>> 1662 MediaPrintableArea mpa = >>>>>> 1663 (MediaPrintableArea)getPrintService(). >>>>>> 1664 >>>>>> getDefaultAttributeValue(MediaPrintableArea.class); >>>>>> >>>>>> is returning imageable area of default media of chosen printer >>>>>> from CUPS [ all supported media printable area is obtained from >>>>>> CUPSPrinter#getPageSizes(printer) & then initMedia() populates >>>>>> cupsMediaPrintables which is returned in getMediaPrintableArea()] >>>>>> as IPPPrintService#getDefaultAttributeValue() does >>>>>> ---------- >>>>>> if (category == MediaPrintableArea.class) { >>>>>> MediaPrintableArea[] mpas; >>>>>> if ((cps != null) && >>>>>> ((mpas = *cps.getMediaPrintableArea()*) != null)) { >>>>>> if (defaultMediaIndex == -1) { >>>>>> // initializes value of defaultMediaIndex >>>>>> getDefaultAttributeValue(Media.class); >>>>>> } >>>>>> return mpas[*defaultMediaIndex*]; >>>>>> } >>>>>> -------------- >>>>>> by which mpas[defaultMediaIndex] returns default media printable >>>>>> area. >>>>>> In else block, we instantiate mpa of Letter for US locale and A4 >>>>>> for other locales so I was not checking for null as in both if >>>>>> and else block , I was getting MediaPrintableArea instance. >>>>>> >>>>>> Regarding considering equal margins, I am not sure if there was >>>>>> any way I could get right and left margin separately. >>>>>> Please let me know if there is any way you know of. >>>>> I have modified to do the change in PSPrinterJob. Regarding the >>>>> equal margin, we do the same in >>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/abb2a39948fe/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java#l688 >>>>> http://cr.openjdk.java.net/~psadhukhan/6574279/webrev.01/ >>>> >>>> That does not seem to be the same case as this. >>>> >>>> -phil. >>>> >>>>> >>>>> Regards >>>>> Prasanta >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> On 8/4/2016 2:32 AM, Philip Race wrote: >>>>>>> High-level question. Why is this not an over-ride in PSPrinterJob ? >>>>>>> >>>>>>> >>>>>>> I'm afraid I did not get much past the first line of the change : >>>>>>> 1662 MediaPrintableArea mpa = >>>>>>> 1663 (MediaPrintableArea)getPrintService(). >>>>>>> 1664 >>>>>>> getDefaultAttributeValue(MediaPrintableArea.class); >>>>>>> >>>>>>> Read the docs for MediaPrintableArea :- >>>>>>> --- >>>>>>> To query for the printable area, a client must supply a suitable >>>>>>> context. >>>>>>> Without specifying at the very least the size of the media being >>>>>>> used >>>>>>> no meaningful value for printable area can be obtained. >>>>>>> --- >>>>>>> >>>>>>> .. not to mention you assume a non-null return. >>>>>>> >>>>>>> and then you use new Paper() .. which is a constructor which >>>>>>> knows nothing about the printer. It is *speced* to return >>>>>>> US letter with one inch margins. >>>>>>> >>>>>>> Another reason why this seems like it should be a sub-class >>>>>>> over-ride. >>>>>>> >>>>>>> >>>>>>> Also this looks wrong --- >>>>>>> 1672 if ((imgX*2) + imgWid > wid) { >>>>>>> 1673 imgWid = wid - imgX*2; >>>>>>> 1674 } >>>>>>> >>>>>>> You can't assume equal margins. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 7/12/16, 5:05 AM, Prasanta Sadhukhan wrote: >>>>>>>> Hi All, >>>>>>>> >>>>>>>> Please review a fix for an issue where it is seen that if user >>>>>>>> sets invalid imageablearea via Paper.setImageableArea and >>>>>>>> then calls PrinterJob.validatePage() in linux, then it does not >>>>>>>> get a valid pageformat >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6574279 >>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6574279/webrev.00/ >>>>>>>> >>>>>>>> Fix is to check for margin as noted via CUPS ppdPageSize() and >>>>>>>> then calculate to find the valid margin in validatePaper() >>>>>>>> similar to what we do in native validatePaper() in windows. >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>> >>>>> >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Fri Aug 19 05:35:16 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 19 Aug 2016 11:05:16 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8163258 : Getting NullPointerException from ImageIO.getReaderWriterInfo due to failure to check for null In-Reply-To: <49ab65c7-1dde-42ea-9066-facd386f685e@default> References: <49ab65c7-1dde-42ea-9066-facd386f685e@default> Message-ID: <57B69A94.9050903@oracle.com> Looks good to me. Regards Prasanta On 8/18/2016 9:34 PM, Jayathirth D V wrote: > > Hi, > > Please review the following fix in JDK9 at your convenience: > > Bug : https://bugs.openjdk.java.net/browse/JDK-8163258 > > Webrev : http://cr.openjdk.java.net/~jdv/8163258/webrev.00/ > > > Issue : When we call ImageIO.getReaderMIMETypes() or ImageIO. > getFileSuffixes() with MIMEType or FileSuffix as null in subclass > ImageReaderSpi it throws NullPointerException. > > Root cause : We allow MIMEType and FileSuffix to be null in > ImageReaderWriterSpi. But when we call getReaderMIMETypes() or > getFileSuffixes() we try populate HashSet using Collections.addALL() > which throws NPE. > > Solution : Before we populate HashSet using Collections.addALL() > verify whether the input is null. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Fri Aug 19 06:20:38 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 19 Aug 2016 11:50:38 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6357887: selected printertray is ignored under linux In-Reply-To: <57B63160.80908@oracle.com> References: <57AAECFD.2030802@oracle.com> <57B48517.3030200@oracle.com> <57B5588D.1050909@oracle.com> <57B63160.80908@oracle.com> Message-ID: <57B6A536.8050106@oracle.com> On 8/19/2016 3:36 AM, Philip Race wrote: > Oh .. right under the covers the map is just a HashMap > and the key to the map is the class so just decides if these are > equal class objects. Hmm .. I don't know anymore if that was the > original intent > but we probably should not mess with it right now just for the > optimisation. > But now I am wondering why it has to be CustomMediaTray and not just > MediaTray ... although I suspect that in the case of CUPS we are not > ever mapping the media to standard ones, so they are always custom. Yes, in CUPS http://hg.openjdk.java.net/jdk9/client/jdk/file/9f38d4f86e3d/src/java.desktop/unix/classes/sun/print/CUPSPrinter.java#l254 we instantiate CustomMediaTray (and do not map to standard) so I need to check for CustomMediatray to get the tray instance. Regards Prasanta > That might be arise as a problem in the case of your other open review > regarding > validating the margins. I'll comment on that in that review but still > surely > any MediaTray is what you would want here but it is probably moot if > you don't ever get a standard one. Please check into this and confirm > what I suspect .. or not ... > > -phil. > > On 8/17/16, 11:41 PM, Prasanta Sadhukhan wrote: >> MediaTray values are bundled with "Media" attribute so calling >> attributes.get(CustomMediatray.class) returns null. >> Modified webrev to get Media attribute and then see if the attribute >> is an instance of CustomMediatray. >> >> http://cr.openjdk.java.net/~psadhukhan/6357887/webrev.01/ >> >> Regards >> Prasanta >> On 8/17/2016 9:09 PM, Philip Race wrote: >>> This all looks fine although this can be a simple call to >>> attributes.get(CustomMediaTray.class) can't it ? >>> >>> 502 for (int i=0; i< attrs.length; i++) { >>> 503 Attribute attr = attrs[i]; >>> 504 try { >>> 505 if (attr instanceof CustomMediaTray) { >>> 506 CustomMediaTray customTray = >>> (CustomMediaTray)attr; >>> 507 mOptions = " InputSlot="+ >>> customTray.getChoiceName(); >>> 508 } >>> 509 } catch (ClassCastException e) { >>> >>> -phil. >>> >>> On 8/10/16, 1:59 AM, Prasanta Sadhukhan wrote: >>>> Hi All, >>>> >>>> Please review a fix for an issue where it is seen that the selected >>>> printer tray is ignored in linux and default standard tray is used >>>> for printing. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6357887 >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6357887/webrev.00/ >>>> >>>> Issue was lpr command needs "-o InputSlot=" to select the >>>> printertray which was not being passed to lpr command. >>>> Proposed fix added InputSlot option to lpr command to select the >>>> printertray. >>>> >>>> Tested in ubuntu and solaris11. >>>> >>>> Regards >>>> Prasanta >> From prem.balakrishnan at oracle.com Fri Aug 19 12:16:05 2016 From: prem.balakrishnan at oracle.com (Prem Balakrishnan) Date: Fri, 19 Aug 2016 05:16:05 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails In-Reply-To: <75f3e1d7-dfc0-4d0c-84d9-192b306d0728@default> References: <1d62d8f6-c7e6-e5c6-38e2-1764fea8011b@oracle.com> <94e9c6a3-2e9f-4405-a5c5-1e4dadeba7d9@default> <3e53ac2e-ba9b-b4e9-3ebd-bccb35bc6650@oracle.com> <75f3e1d7-dfc0-4d0c-84d9-192b306d0728@default> Message-ID: <5fb211e7-da91-4a5a-92f0-14c7d3d6a472@default> Reminder From: Prem Balakrishnan Sent: Thursday, August 18, 2016 3:12 PM To: Alexander Scherbatiy; Rajeev Chamyal; awt-dev at openjdk.java.net; 2d-dev at openjdk.java.net; Philip Race; Prasanta Sadhukhan Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails Added "2d-dev" team for review Regards, Prem From: Alexandr Scherbatiy Sent: Thursday, August 18, 2016 2:57 PM To: Prem Balakrishnan; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails Could you also send the review to the 2d-dev alias? Thanks, Alexandr. On 8/18/2016 9:59 AM, Prem Balakrishnan wrote: Hi Alexandr, AccelSurface is implemented by *ONLY* D3DSurfaceData and OGLSurfaceData classes, Both of these classes extend SurfaceData as well. Hence, casting of 'as' variable which is of type AccelSurface object to SurfaceData is always VALID. Regards, Prem From: Alexandr Scherbatiy Sent: Wednesday, August 17, 2016 4:42 PM To: Prem Balakrishnan; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails On 8/17/2016 11:30 AM, Prem Balakrishnan wrote: Hi Alexandr, Thankyou for the review. YES scaled SurfaceData returns proper scale values from getDefaultScaleX()/getDefaultScaleY(), which I have used in the current patch. Please review the updated patch HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.02/"http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.02/ Is it always true that the 'as' variable which has type AccelSurface in the fix is always instance of SurfaceData? Thanks, Alexandr. Regards, Prem From: Alexandr Scherbatiy Sent: Tuesday, August 16, 2016 10:06 PM To: Prem Balakrishnan; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails On 8/16/2016 7:35 AM, Prem Balakrishnan wrote: Reminder From: Prem Balakrishnan Sent: Friday, August 12, 2016 6:36 PM To: Alexander Scherbatiy; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: RE: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails Hi Alexandr and Sergey, Please review the updated patch. HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.01/"http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.01/ >>"It is a little bit strange bug, because VolatileImage should handle this scale internally, and create double sized surface when necessary".-Sergey Yes as you mentioned Volatile Image is getting scaled internally. Thanks for the feedback. Cause: In VIOptWindowPainter::updateWindowAccel(psdops, w, h) call, width and height were passed without scaling, which was creating a bitmap of specified width and height, hence the output was clipped. I just have two general questions. - The scaled SurfaceData should return proper scales from getDefaultScaleX()/getDefaultScaleY() methods. Do these methods return right values after setting the scaled image sizes in the fix? - Region.clipScale() which is used in many places rounds values. The usual rule is to use Math.floor() for image coordinates rounding and Math.ceil() for sizes. Should the same rule be applicable here? Thanks, Alexandr. Regards, Prem From: Alexandr Scherbatiy Sent: Thursday, August 04, 2016 6:23 PM To: Prem Balakrishnan; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails On 8/3/2016 10:04 AM, Prem Balakrishnan wrote: Hi, Please review fix for JDK9, Bug: https://bugs.openjdk.java.net/browse/JDK-8144735 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.00/"http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.00/ Issue: javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails Cause: While creating Transparent VolatileImage, width and height was NOT hidpi scaled. Fix: VolatileImage width and height are scaled. I believe this is an issue in AWT and needs to be discussed on awt-dev alias. Should the backbuffer width and height be also scaled for the BIWindowPainter? Thanks, Alexandr. Thanks, Prem -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Sun Aug 21 18:30:40 2016 From: philip.race at oracle.com (Philip Race) Date: Sun, 21 Aug 2016 11:30:40 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8145901: Printed content is overlapping. In-Reply-To: <57ACFBD8.9040105@oracle.com> References: <57ACFBD8.9040105@oracle.com> Message-ID: <57B9F350.6020902@oracle.com> Anyone ? -phil. On 8/11/16, 3:27 PM, Philip Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8145901 > Webrev: http://cr.openjdk.java.net/~prr/8145901/ > > As per the evaluation in the bug this is an issue with the > device scale being applied to the kerning adjustments made > by the layout engine. > > The fix builds cleanly in JPRT and has been tested with the > the JCK test in the bug report. > I also did "on-screen" testing of various scripts and did not > see any problems. > > -phil. > > From philip.race at oracle.com Sun Aug 21 18:31:44 2016 From: philip.race at oracle.com (Philip Race) Date: Sun, 21 Aug 2016 11:31:44 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8139176: [macosx] java.awt.TextLayout does not handle correctly the bolded logical fonts In-Reply-To: <98f20b9e-50df-1407-ba22-0c83d2b3c4a8@oracle.com> References: <57AB998B.5060104@oracle.com> <6e82f1d0-5bf6-14b0-9f2a-f714dc646322@oracle.com> <57AE0352.3040509@oracle.com> <57AE043D.9040906@oracle.com> <98f20b9e-50df-1407-ba22-0c83d2b3c4a8@oracle.com> Message-ID: <57B9F390.8050309@oracle.com> Thanks Sergey .. I am still waiting for a 2nd +1 from someone else. -phil. On 8/12/16, 12:28 PM, Sergey Bylokhov wrote: > Looks fine. > > On 12.08.16 20:15, Philip Race wrote: >> Updated test : http://cr.openjdk.java.net/~prr/8139176.1/ >> >> -phil. >> >> On 8/12/16, 10:11 AM, Philip Race wrote: >>> >>> >>> On 8/12/16, 5:48 AM, Sergey Bylokhov wrote: >>>> Hi, Phil. >>>> A few comments about the test: >>>> - jtreg can stop the test at the end of the main, before invokeLater >>>> will start/complete.(on my system it always pass because of that) >>> >>> hmm. The only reason this test shows a window is to be helpful to >>> humans. >>> I think I'll make jtreg just draw to a BI and the UI only be there for >>> the "interactive" mode >>> which is meant to be used outside jtreg. >>> That will dispense with (get rid of) the need for @headful too. >>> >>>> - The frame should be disposed at the end of the test. >>> OK .. perhaps also non-essential if I make the above change >>>> - Probably the correct location of the test is >>>> java/awt/font/TextLayout/? >>> >>> OK. >>> >>> I will tweak the test and resubmit shortly. >>>> >>>> On 11.08.16 0:15, Philip Race wrote: >>>>> Equals was returning true because the full name is the same for >>>>> all members of the family. That in itself seems wrong .. no two >>>>> fonts should have the same name, but that will be addressed in >>>>> a follow-on fix. >>>> >>>> I assume the added code will be removed after follow-on fix? >>> >>> It does not have to be .. it is harmless and perhaps useful. I was >>> thinking of leaving it. >>> >>> -phil. >>>> > > From prasanta.sadhukhan at oracle.com Mon Aug 22 07:02:06 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 22 Aug 2016 12:32:06 +0530 Subject: [OpenJDK 2D-Dev] Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails In-Reply-To: <75f3e1d7-dfc0-4d0c-84d9-192b306d0728@default> References: <1d62d8f6-c7e6-e5c6-38e2-1764fea8011b@oracle.com> <94e9c6a3-2e9f-4405-a5c5-1e4dadeba7d9@default> <3e53ac2e-ba9b-b4e9-3ebd-bccb35bc6650@oracle.com> <75f3e1d7-dfc0-4d0c-84d9-192b306d0728@default> Message-ID: <57BAA36E.2010704@oracle.com> I wonder how it compiles? I tried a small program ------------------ public class Test { AccelSurface b = new AccelSurface(); SurfaceData c = (SurfaceData)b; } class SurfaceData extends Surface {} class Surface {} class AccelSurface extends Surface {} --------- and it fails to compile Test.java:3: error: incompatible types: AccelSurface cannot be converted to SurfaceData SurfaceData c = (SurfaceData)b; ANyways, did you check with opengl pipeline? It seems getDefaultScaleX/Y is not present in OGLSurfaceData which will result in falling back to SurfaceData in which case the scale will be 1. Regards Prasanta On 8/18/2016 3:12 PM, Prem Balakrishnan wrote: > > Added ?2d-dev? team for review > > Regards, > > Prem > > *From:*Alexandr Scherbatiy > *Sent:* Thursday, August 18, 2016 2:57 PM > *To:* Prem Balakrishnan; Rajeev Chamyal; awt-dev at openjdk.java.net; > Sergey Bylokhov > *Subject:* Re: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > Could you also send the review to the 2d-dev alias? > > Thanks, > Alexandr. > > On 8/18/2016 9:59 AM, Prem Balakrishnan wrote: > > Hi Alexandr, > > AccelSurface is implemented by *ONLY* D3DSurfaceData and > OGLSurfaceData classes, > > Both of these classes extend SurfaceData as well. > > Hence, casting of 'as' variable which is of type AccelSurface > object to SurfaceData is always VALID. > > Regards, > Prem > > *From:*Alexandr Scherbatiy > *Sent:* Wednesday, August 17, 2016 4:42 PM > *To:* Prem Balakrishnan; Rajeev Chamyal; awt-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > On 8/17/2016 11:30 AM, Prem Balakrishnan wrote: > > > Hi Alexandr, > > Thankyou for the review. > > YES scaled SurfaceData returns proper scale values from > getDefaultScaleX()/getDefaultScaleY(), which I have used in the > current patch. > > Please review the updated patch > > http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.02/ > > > Is it always true that the 'as' variable which has type > AccelSurface in the fix is always instance of SurfaceData? > > Thanks, > Alexandr. > > > Regards, > Prem > > *From:*Alexandr Scherbatiy > *Sent:* Tuesday, August 16, 2016 10:06 PM > *To:* Prem Balakrishnan; Rajeev Chamyal; awt-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > On 8/16/2016 7:35 AM, Prem Balakrishnan wrote: > > > > Reminder > > *From:*Prem Balakrishnan > *Sent:* Friday, August 12, 2016 6:36 PM > *To:* Alexander Scherbatiy; Rajeev Chamyal; > awt-dev at openjdk.java.net ; Sergey > Bylokhov > *Subject:* RE: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > Hi Alexandr and Sergey, > > Please review the updated patch. > > http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.01/ > > > >>?It is a little bit strange bug, because VolatileImage should > handle this scale internally, and create double sized surface when > necessary?.-Sergey > > Yes as you mentioned Volatile Image is getting scaled internally. > Thanks for the feedback. > > *Cause:*In VIOptWindowPainter::updateWindowAccel(psdops, w, h) > call, width and height were passed without scaling, > > which was creating a bitmap of specified width and height, hence > the output was clipped. > > > I just have two general questions. > - The scaled SurfaceData should return proper scales from > getDefaultScaleX()/getDefaultScaleY() methods. Do these methods > return right values after setting the scaled image sizes in the fix? > - Region.clipScale() which is used in many places rounds values. > The usual rule is to use Math.floor() for image coordinates > rounding and Math.ceil() for sizes. > Should the same rule be applicable here? > > Thanks, > Alexandr. > > > > > > Regards, > > Prem > > *From:*Alexandr Scherbatiy > *Sent:* Thursday, August 04, 2016 6:23 PM > *To:* Prem Balakrishnan; Rajeev Chamyal; awt-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > On 8/3/2016 10:04 AM, Prem Balakrishnan wrote: > > Hi, > > Please review fix for JDK9, > > *Bug:*https://bugs.openjdk.java.net/browse/JDK-8144735 > > *Webrev:*http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.00/ > > > *Issue:* > > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > *Cause:* > > While creating Transparent VolatileImage, width and height was NOT > hidpi scaled. > > *Fix: *VolatileImage width and height are scaled. > > > I believe this is an issue in AWT and needs to be discussed on > awt-dev alias. > > Should the backbuffer width and height be also scaled for the > BIWindowPainter? > > Thanks, > Alexandr. > > Thanks, > > Prem > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Mon Aug 22 07:31:43 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 22 Aug 2016 13:01:43 +0530 Subject: [OpenJDK 2D-Dev] RFR: 8145901: Printed content is overlapping. In-Reply-To: <57ACFBD8.9040105@oracle.com> References: <57ACFBD8.9040105@oracle.com> Message-ID: <57BAAA5F.8050307@oracle.com> Printed content is not overlapping after the fix. Looks good to me. +1. Dont we need to do the same, applying device scale in 345 hb_font_set_scale(font, 346 FloatToF26Dot6(jdkFontInfo->ptSize), 347 FloatToF26Dot6(jdkFontInfo->ptSize)); Regards Prasanta On 8/12/2016 3:57 AM, Philip Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8145901 > Webrev: http://cr.openjdk.java.net/~prr/8145901/ > > As per the evaluation in the bug this is an issue with the > device scale being applied to the kerning adjustments made > by the layout engine. > > The fix builds cleanly in JPRT and has been tested with the > the JCK test in the bug report. > I also did "on-screen" testing of various scripts and did not > see any problems. > > -phil. > > From Sergey.Bylokhov at oracle.com Mon Aug 22 10:40:21 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 22 Aug 2016 13:40:21 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8145901: Printed content is overlapping. In-Reply-To: <57ACFBD8.9040105@oracle.com> References: <57ACFBD8.9040105@oracle.com> Message-ID: <609a2c9a-c4bb-0c7a-e58b-8e50b1abf883@oracle.com> Is it possible to add a small description for "float devScale;" I am always in doubts, what devScale means, is it a full transform(dev+user) or it is some "default-device-transform"? On 12.08.16 1:27, Philip Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8145901 > Webrev: http://cr.openjdk.java.net/~prr/8145901/ > > As per the evaluation in the bug this is an issue with the > device scale being applied to the kerning adjustments made > by the layout engine. > > The fix builds cleanly in JPRT and has been tested with the > the JCK test in the bug report. > I also did "on-screen" testing of various scripts and did not > see any problems. > > -phil. > > -- Best regards, Sergey. From philip.race at oracle.com Mon Aug 22 17:10:25 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 22 Aug 2016 10:10:25 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8145901: Printed content is overlapping. In-Reply-To: <57BAAA5F.8050307@oracle.com> References: <57ACFBD8.9040105@oracle.com> <57BAAA5F.8050307@oracle.com> Message-ID: <57BB3201.1040601@oracle.com> On 08/22/2016 12:31 AM, Prasanta Sadhukhan wrote: > Printed content is not overlapping after the fix. Looks good to me. +1. > Dont we need to do the same, applying device scale in > > 345 hb_font_set_scale(font, > 346 FloatToF26Dot6(jdkFontInfo->ptSize), > 347 FloatToF26Dot6(jdkFontInfo->ptSize)); No we don't. It is not applied there which is why there is this line in HBShaper 220 if (!aat && (getenv("HB_NODEVTX") != NULL)) { HB will only use coretext for AAT fonts. -phil. > > > Regards > Prasanta > On 8/12/2016 3:57 AM, Philip Race wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8145901 >> Webrev: http://cr.openjdk.java.net/~prr/8145901/ >> >> As per the evaluation in the bug this is an issue with the >> device scale being applied to the kerning adjustments made >> by the layout engine. >> >> The fix builds cleanly in JPRT and has been tested with the >> the JCK test in the bug report. >> I also did "on-screen" testing of various scripts and did not >> see any problems. >> >> -phil. >> >> > From philip.race at oracle.com Mon Aug 22 17:25:02 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 22 Aug 2016 10:25:02 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8145901: Printed content is overlapping. In-Reply-To: <609a2c9a-c4bb-0c7a-e58b-8e50b1abf883@oracle.com> References: <57ACFBD8.9040105@oracle.com> <609a2c9a-c4bb-0c7a-e58b-8e50b1abf883@oracle.com> Message-ID: <57BB356E.2020907@oracle.com> The font code actually has user+font+dev .. it is all 3 in this case. I will include a comment 46 float devScale; // Est. of much applying the full glyph tx scales x distance. -phil. On 08/22/2016 03:40 AM, Sergey Bylokhov wrote: > Is it possible to add a small description for "float devScale;" I am > always in doubts, what devScale means, is it a full > transform(dev+user) or it is some "default-device-transform"? > > On 12.08.16 1:27, Philip Race wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8145901 >> Webrev: http://cr.openjdk.java.net/~prr/8145901/ >> >> As per the evaluation in the bug this is an issue with the >> device scale being applied to the kerning adjustments made >> by the layout engine. >> >> The fix builds cleanly in JPRT and has been tested with the >> the JCK test in the bug report. >> I also did "on-screen" testing of various scripts and did not >> see any problems. >> >> -phil. >> >> > > From rachna.goel at oracle.com Tue Aug 23 02:40:31 2016 From: rachna.goel at oracle.com (Rachna Goel) Date: Tue, 23 Aug 2016 08:10:31 +0530 Subject: [OpenJDK 2D-Dev] RFR: JDK-8163362-Reconsider reflection usage in java.awt.font.JavaAWTFontAccessImpl class Message-ID: <2ae64671-064b-ee3a-1b45-43c9f5776a18@oracle.com> Hi, Please review fix for JDK-8163362. https://bugs.openjdk.java.net/browse/JDK-8163362 Webrev:http://cr.openjdk.java.net/~rgoel/JDK-8163362/webrev.01/ This is a cleanup fix in which Reflection usage in JavaAWTFontAccessImpl class was removed. Thanks, Rachna -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Tue Aug 23 04:28:55 2016 From: philip.race at oracle.com (Philip Race) Date: Mon, 22 Aug 2016 21:28:55 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8163362-Reconsider reflection usage in java.awt.font.JavaAWTFontAccessImpl class In-Reply-To: <2ae64671-064b-ee3a-1b45-43c9f5776a18@oracle.com> References: <2ae64671-064b-ee3a-1b45-43c9f5776a18@oracle.com> Message-ID: <57BBD107.4010502@oracle.com> This looks fine. I am just puzzled why reflection was used to begin with. What am I missing ? Was this future proofing against new constants being added ? -phil. On 8/22/16, 7:40 PM, Rachna Goel wrote: > Hi, > > Please review fix for JDK-8163362. > > https://bugs.openjdk.java.net/browse/JDK-8163362 > > Webrev:http://cr.openjdk.java.net/~rgoel/JDK-8163362/webrev.01/ > > This is a cleanup fix in which Reflection usage in JavaAWTFontAccessImpl > class was removed. > > Thanks, > > Rachna -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue Aug 23 09:28:38 2016 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 23 Aug 2016 13:28:38 +0400 Subject: [OpenJDK 2D-Dev] 8138771: java.awt.image.AbstractMultiResolutionImage needs customized spec for methods of Image which it implements In-Reply-To: <9F556132-58E4-4303-81CC-C031C5023A21@oracle.com> References: <27615500-F15F-4D58-B715-C8D96D6FD5FE@oracle.com> <9F556132-58E4-4303-81CC-C031C5023A21@oracle.com> Message-ID: On 22/08/16 11:06, Avik Niyogi wrote: > + awt-dev > > >> On 22-Aug-2016, at 12:28 pm, Avik Niyogi > > wrote: >> >> Hi All, >> >> Kindly review the proposed specifications for JDK9. >> >> *Bug: https://bugs.openjdk.java.net/browse/JDK-8138771* >> >> *Webrev: http://cr.openjdk.java.net/~aniyogi/8138771/webrev.00/ >> * >> >> *Issue: *The customised specifications necessitated for getGraphics >> method did not exist. >> So test cases created according to derived specifications would lead >> to test cases failures. >> >> *Cause: * No congruous specifications could elicit failure in >> circumstances not encompassed >> in test cases generated without the knowledge of the same. >> >> *Fix:* Appropriate comprehensive specifications required were added. - I am not a native speaker. May be something like this would be better: ------ /** * This method is not supported by {@code AbstractMultiResolutionImage} * and always throws {@code UnsupportedOperationException} * * @return {@code UnsupportedOperationException} is thrown * @throws UnsupportedOperationException this method is not supported ------ - others overridden method should have a documentation that they delegate call to the base image (see #getBaseImage) Thanks, Alexandr. >> >> With Regards, >> Avik Niyogi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Tue Aug 23 12:05:25 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 23 Aug 2016 17:35:25 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR 4885375: Page Ranges 'To Page' field must be populated based on Pageable Message-ID: <57BC3C05.3000400@oracle.com> Hi All, Please review a fix whereby it is seen that Page Ranges fields in the "cross-platform" dialog does not get populated based on what pageable's getNumberOfPages() returns. "To" field is always 1. However, for native dialog it shows the "To" field correctly based on what getNumberOfPages() returns. Bug: https://bugs.openjdk.java.net/browse/JDK-4885375 webrev: http://cr.openjdk.java.net/~psadhukhan/4885375/webrev.00/ This is because in cross platform ServiceDialog, for the ToPage to get populated, PageRanges should be present in the attribute set. In this case, there is no PageRanges so it defaults to "from 1 to 1" pages. Proposed fix is to set a PageRange attribute to be from 1 to getNumberOfPages. The 2nd issue of disabling PageRange fields if getNumberOfPages() returns 0 is not handled as there is no provision of passing PageRanges 0 to ServiceDialog (it resuls in IAE). Regards Prasanta From vadim.pakhnushev at oracle.com Tue Aug 23 13:01:34 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Tue, 23 Aug 2016 16:01:34 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8139176: [macosx] java.awt.TextLayout does not handle correctly the bolded logical fonts In-Reply-To: <57B9F390.8050309@oracle.com> References: <57AB998B.5060104@oracle.com> <6e82f1d0-5bf6-14b0-9f2a-f714dc646322@oracle.com> <57AE0352.3040509@oracle.com> <57AE043D.9040906@oracle.com> <98f20b9e-50df-1407-ba22-0c83d2b3c4a8@oracle.com> <57B9F390.8050309@oracle.com> Message-ID: <30247858-0c71-006d-67ed-cde9d85305bc@oracle.com> +1 Vadim On 21.08.2016 21:31, Philip Race wrote: > Thanks Sergey .. I am still waiting for a 2nd +1 from someone else. > > -phil. > > On 8/12/16, 12:28 PM, Sergey Bylokhov wrote: >> Looks fine. >> >> On 12.08.16 20:15, Philip Race wrote: >>> Updated test : http://cr.openjdk.java.net/~prr/8139176.1/ >>> >>> -phil. >>> >>> On 8/12/16, 10:11 AM, Philip Race wrote: >>>> >>>> >>>> On 8/12/16, 5:48 AM, Sergey Bylokhov wrote: >>>>> Hi, Phil. >>>>> A few comments about the test: >>>>> - jtreg can stop the test at the end of the main, before invokeLater >>>>> will start/complete.(on my system it always pass because of that) >>>> >>>> hmm. The only reason this test shows a window is to be helpful to >>>> humans. >>>> I think I'll make jtreg just draw to a BI and the UI only be there for >>>> the "interactive" mode >>>> which is meant to be used outside jtreg. >>>> That will dispense with (get rid of) the need for @headful too. >>>> >>>>> - The frame should be disposed at the end of the test. >>>> OK .. perhaps also non-essential if I make the above change >>>>> - Probably the correct location of the test is >>>>> java/awt/font/TextLayout/? >>>> >>>> OK. >>>> >>>> I will tweak the test and resubmit shortly. >>>>> >>>>> On 11.08.16 0:15, Philip Race wrote: >>>>>> Equals was returning true because the full name is the same for >>>>>> all members of the family. That in itself seems wrong .. no two >>>>>> fonts should have the same name, but that will be addressed in >>>>>> a follow-on fix. >>>>> >>>>> I assume the added code will be removed after follow-on fix? >>>> >>>> It does not have to be .. it is harmless and perhaps useful. I was >>>> thinking of leaving it. >>>> >>>> -phil. >>>>> >> >> From yasuenag at gmail.com Tue Aug 23 13:10:54 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 23 Aug 2016 22:10:54 +0900 Subject: [OpenJDK 2D-Dev] [REGRESSION?] Build warnings at jdhuff.c with GCC 6 Message-ID: <46f8bb76-5fe9-d0aa-cfd7-b228e5478640@gmail.com> Hi all, I've fixed several warnings when we build OpenJDK with GCC 6 in JDK-8160294. However, I encountered shift-negative-value warnings at jdhuff.c on my Fedora 24 (GCC 6.1.1): -------------- /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:13: warning: left shift of negative value [-Wshift-negative-value] { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1, ^~ /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:28: warning: left shift of negative value [-Wshift-negative-value] { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1, ^~ /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:43: warning: left shift of negative value [-Wshift-negative-value] { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1, : -------------- I think these warnings are available from JDK-8074827. This issue enables warnings to fix in the source code. However, in review of JDK-8160294, I heared that warnings in IJG JPEG library should just be suppressed: http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004497.html So I think they should be suppressed and we should fix as below: -------------- diff -r b548b8217d8c make/lib/Awt2dLibraries.gmk --- a/make/lib/Awt2dLibraries.gmk Mon Aug 22 19:28:36 2016 -0700 +++ b/make/lib/Awt2dLibraries.gmk Tue Aug 23 22:08:44 2016 +0900 @@ -490,7 +490,7 @@ CFLAGS := $(CFLAGS_JDKLIB) $(BUILD_LIBJAVAJPEG_HEADERS) \ $(LIBJAVA_HEADER_FLAGS) \ -I$(SUPPORT_OUTPUTDIR)/headers/java.desktop, \ - DISABLED_WARNINGS_gcc := clobbered, \ + DISABLED_WARNINGS_gcc := clobbered shift-negative-value, \ MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libjpeg/mapfile-vers, \ LDFLAGS := $(LDFLAGS_JDKLIB) \ $(call SET_SHARED_LIBRARY_ORIGIN), \ -------------- If it is correct, I file it to JBS and upload webrev. Do you think about it? Thanks, Yasumasa From philip.race at oracle.com Tue Aug 23 15:11:42 2016 From: philip.race at oracle.com (Philip Race) Date: Tue, 23 Aug 2016 08:11:42 -0700 Subject: [OpenJDK 2D-Dev] [REGRESSION?] Build warnings at jdhuff.c with GCC 6 In-Reply-To: <46f8bb76-5fe9-d0aa-cfd7-b228e5478640@gmail.com> References: <46f8bb76-5fe9-d0aa-cfd7-b228e5478640@gmail.com> Message-ID: <57BC67AE.9080607@oracle.com> Erik .. please chime in if you disagree with the following The goal here is to have no warnings with the *official* compilers. If you are using something else and get warnings then either fix the *source* or else you need to use --disable-warning-as-errors. Otherwise we'll be suppressing the warnings for a whole range of compilers and no one will know what the set is and these bugs will become 'unfixable' and a continual chore of churn. It will be something we should address as we move *official* compilers. In fact the warning you want to suppress is one I just got rid of (the suppression) http://hg.openjdk.java.net/jdk9/client/jdk/rev/d4f7412a51d2 I don't think we want to add it back unless the *official* compilers object .. I am sure that official list is documented somewhere. -phil. On 8/23/16, 6:10 AM, Yasumasa Suenaga wrote: > Hi all, > > I've fixed several warnings when we build OpenJDK with GCC 6 in > JDK-8160294. > However, I encountered shift-negative-value warnings at jdhuff.c on my > Fedora 24 (GCC 6.1.1): > -------------- > /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:13: > warning: left shift of negative value [-Wshift-negative-value] > { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1, > ^~ > /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:28: > warning: left shift of negative value [-Wshift-negative-value] > { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1, > ^~ > /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:43: > warning: left shift of negative value [-Wshift-negative-value] > { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1, > : > -------------- > > I think these warnings are available from JDK-8074827. > This issue enables warnings to fix in the source code. > However, in review of JDK-8160294, I heared that warnings in IJG JPEG > library should just be suppressed: > > http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004497.html > > > So I think they should be suppressed and we should fix as below: > -------------- > diff -r b548b8217d8c make/lib/Awt2dLibraries.gmk > --- a/make/lib/Awt2dLibraries.gmk Mon Aug 22 19:28:36 2016 -0700 > +++ b/make/lib/Awt2dLibraries.gmk Tue Aug 23 22:08:44 2016 +0900 > @@ -490,7 +490,7 @@ > CFLAGS := $(CFLAGS_JDKLIB) $(BUILD_LIBJAVAJPEG_HEADERS) \ > $(LIBJAVA_HEADER_FLAGS) \ > -I$(SUPPORT_OUTPUTDIR)/headers/java.desktop, \ > - DISABLED_WARNINGS_gcc := clobbered, \ > + DISABLED_WARNINGS_gcc := clobbered shift-negative-value, \ > MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libjpeg/mapfile-vers, \ > LDFLAGS := $(LDFLAGS_JDKLIB) \ > $(call SET_SHARED_LIBRARY_ORIGIN), \ > -------------- > > If it is correct, I file it to JBS and upload webrev. > Do you think about it? > > > Thanks, > > Yasumasa > > From erik.joelsson at oracle.com Tue Aug 23 15:47:48 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 23 Aug 2016 17:47:48 +0200 Subject: [OpenJDK 2D-Dev] [REGRESSION?] Build warnings at jdhuff.c with GCC 6 In-Reply-To: <57BC67AE.9080607@oracle.com> References: <46f8bb76-5fe9-d0aa-cfd7-b228e5478640@gmail.com> <57BC67AE.9080607@oracle.com> Message-ID: Hello, I do agree that maintaining the list of disabled warnings will be impossible unless we have a structured way of tracking for which compiler versions we disable what. Ideally we should be able to easily add conditions for when certain warnings should be disabled. We are unfortunately lacking that today and at least I don't have the bandwidth to fix that anytime soon. The official compilers are only really official for Oracle. The OpenJDK can (and should) be buildable with a much wider range of compiler versions. Luckily we have the workaround of setting --disable-warnings-as-errors when this situation occurs. For reference, the compilers Oracle uses are listed in README-builds.md in the top level directory in the forest. So for now at least, I think Phil is right. /Erik On 2016-08-23 17:11, Philip Race wrote: > Erik .. please chime in if you disagree with the following > The goal here is to have no warnings with the *official* compilers. > If you are using something else and get warnings then either fix > the *source* or else you need to use --disable-warning-as-errors. > > Otherwise we'll be suppressing the warnings for a whole range > of compilers and no one will know what the set is and these > bugs will become 'unfixable' and a continual chore of churn. > It will be something we should address as we move *official* compilers. > > In fact the warning you want to suppress is one I just got rid of (the > suppression) > http://hg.openjdk.java.net/jdk9/client/jdk/rev/d4f7412a51d2 > I don't think we want to add it back unless the *official* compilers object > .. I am sure that official list is documented somewhere. > > -phil. > > > On 8/23/16, 6:10 AM, Yasumasa Suenaga wrote: >> Hi all, >> >> I've fixed several warnings when we build OpenJDK with GCC 6 in >> JDK-8160294. >> However, I encountered shift-negative-value warnings at jdhuff.c on my >> Fedora 24 (GCC 6.1.1): >> -------------- >> /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:13: >> warning: left shift of negative value [-Wshift-negative-value] >> { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1, >> ^~ >> /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:28: >> warning: left shift of negative value [-Wshift-negative-value] >> { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1, >> ^~ >> /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:43: >> warning: left shift of negative value [-Wshift-negative-value] >> { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1, >> : >> -------------- >> >> I think these warnings are available from JDK-8074827. >> This issue enables warnings to fix in the source code. >> However, in review of JDK-8160294, I heared that warnings in IJG JPEG >> library should just be suppressed: >> >> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004497.html >> >> >> So I think they should be suppressed and we should fix as below: >> -------------- >> diff -r b548b8217d8c make/lib/Awt2dLibraries.gmk >> --- a/make/lib/Awt2dLibraries.gmk Mon Aug 22 19:28:36 2016 -0700 >> +++ b/make/lib/Awt2dLibraries.gmk Tue Aug 23 22:08:44 2016 +0900 >> @@ -490,7 +490,7 @@ >> CFLAGS := $(CFLAGS_JDKLIB) $(BUILD_LIBJAVAJPEG_HEADERS) \ >> $(LIBJAVA_HEADER_FLAGS) \ >> -I$(SUPPORT_OUTPUTDIR)/headers/java.desktop, \ >> - DISABLED_WARNINGS_gcc := clobbered, \ >> + DISABLED_WARNINGS_gcc := clobbered shift-negative-value, \ >> MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libjpeg/mapfile-vers, \ >> LDFLAGS := $(LDFLAGS_JDKLIB) \ >> $(call SET_SHARED_LIBRARY_ORIGIN), \ >> -------------- >> >> If it is correct, I file it to JBS and upload webrev. >> Do you think about it? >> >> >> Thanks, >> >> Yasumasa >> >> From philip.race at oracle.com Tue Aug 23 16:12:39 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 23 Aug 2016 09:12:39 -0700 Subject: [OpenJDK 2D-Dev] [REGRESSION?] Build warnings at jdhuff.c with GCC 6 In-Reply-To: References: <46f8bb76-5fe9-d0aa-cfd7-b228e5478640@gmail.com> <57BC67AE.9080607@oracle.com> Message-ID: <57BC75F7.1020403@oracle.com> On 08/23/2016 08:47 AM, Erik Joelsson wrote: > Hello, > > I do agree that maintaining the list of disabled warnings will be > impossible unless we have a structured way of tracking for which > compiler versions we disable what. Ideally we should be able to easily > add conditions for when certain warnings should be disabled. We are > unfortunately lacking that today and at least I don't have the > bandwidth to fix that anytime soon. > > The official compilers are only really official for Oracle. The > OpenJDK can (and should) be buildable with a much wider range of > compiler versions. I agree there. This is fortunately not an "unbuildable" situation. The only other option I can think of which may or may not be palatable is to explicitly check the compiler version and add that disabled warning only for that exact compiler version. There'd still be some maintenance as that compiler version became either official .. or obsolete .. Is there precedent (or any kind of support) for that ? -phil. > Luckily we have the workaround of setting --disable-warnings-as-errors > when this situation occurs. > > For reference, the compilers Oracle uses are listed in > README-builds.md in the top level directory in the forest. > > So for now at least, I think Phil is right. > > /Erik > > On 2016-08-23 17:11, Philip Race wrote: >> Erik .. please chime in if you disagree with the following >> The goal here is to have no warnings with the *official* compilers. >> If you are using something else and get warnings then either fix >> the *source* or else you need to use --disable-warning-as-errors. >> >> Otherwise we'll be suppressing the warnings for a whole range >> of compilers and no one will know what the set is and these >> bugs will become 'unfixable' and a continual chore of churn. >> It will be something we should address as we move *official* compilers. >> >> In fact the warning you want to suppress is one I just got rid of (the >> suppression) >> http://hg.openjdk.java.net/jdk9/client/jdk/rev/d4f7412a51d2 >> I don't think we want to add it back unless the *official* compilers >> object >> .. I am sure that official list is documented somewhere. >> >> -phil. >> >> >> On 8/23/16, 6:10 AM, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> I've fixed several warnings when we build OpenJDK with GCC 6 in >>> JDK-8160294. >>> However, I encountered shift-negative-value warnings at jdhuff.c on my >>> Fedora 24 (GCC 6.1.1): >>> -------------- >>> /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:13: >>> >>> warning: left shift of negative value [-Wshift-negative-value] >>> { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1, >>> ^~ >>> /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:28: >>> >>> warning: left shift of negative value [-Wshift-negative-value] >>> { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1, >>> ^~ >>> /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:43: >>> >>> warning: left shift of negative value [-Wshift-negative-value] >>> { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1, >>> : >>> -------------- >>> >>> I think these warnings are available from JDK-8074827. >>> This issue enables warnings to fix in the source code. >>> However, in review of JDK-8160294, I heared that warnings in IJG JPEG >>> library should just be suppressed: >>> >>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004497.html >>> >>> >>> So I think they should be suppressed and we should fix as below: >>> -------------- >>> diff -r b548b8217d8c make/lib/Awt2dLibraries.gmk >>> --- a/make/lib/Awt2dLibraries.gmk Mon Aug 22 19:28:36 2016 -0700 >>> +++ b/make/lib/Awt2dLibraries.gmk Tue Aug 23 22:08:44 2016 +0900 >>> @@ -490,7 +490,7 @@ >>> CFLAGS := $(CFLAGS_JDKLIB) $(BUILD_LIBJAVAJPEG_HEADERS) \ >>> $(LIBJAVA_HEADER_FLAGS) \ >>> -I$(SUPPORT_OUTPUTDIR)/headers/java.desktop, \ >>> - DISABLED_WARNINGS_gcc := clobbered, \ >>> + DISABLED_WARNINGS_gcc := clobbered shift-negative-value, \ >>> MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libjpeg/mapfile-vers, \ >>> LDFLAGS := $(LDFLAGS_JDKLIB) \ >>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>> -------------- >>> >>> If it is correct, I file it to JBS and upload webrev. >>> Do you think about it? >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> > From brian.burkhalter at oracle.com Tue Aug 23 18:17:26 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 23 Aug 2016 11:17:26 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8149562: TIFFField#createFromMetadataNode javadoc should provide information about sibling/child nodes that should be part of parameter node In-Reply-To: <57B4A146.20603@oracle.com> References: <304A3A05-9085-4C78-AF24-5AE7622399FB@oracle.com> <752CE81D-8DAC-4E0E-8090-D615C7218D8D@oracle.com> <57B4A146.20603@oracle.com> Message-ID: <17458A98-7260-4140-8137-2FAAE5175DAB@oracle.com> Here is a revision based on the CCC request discussion: http://cr.openjdk.java.net/~bpb/8149562/webrev.01/ It was necessary slightly to modify one test as well. Thanks, Brian On Aug 17, 2016, at 10:39 AM, Phil Race wrote: > +1 > > -phil. > > On 08/16/2016 09:02 AM, Brian Burkhalter wrote: >> Please review at your convenience. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8149562 >> Patch: [1] >> >> Add one sentence to the TIFFField.createFromMetadataNode method specification stating that the supplied Node parameter must adhere to the TIFFField element structure defined by the TIFF native image metadata DTD. >> >> Thanks, >> >> Brian >> >> [1] diff >> >> --- a/src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFField.java >> +++ b/src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFField.java >> >> /** >> * Creates a {@code TIFFField} from a TIFF native image >> * metadata node. If the value of the {@code ?number"} attribute >> * of the node is not found in {@code tagSet} then a new >> * {@code TIFFTag} with name {@code TIFFTag.UNKNOWN_TAG_NAME} >> - * will be created and assigned to the field. >> + * will be created and assigned to the field. If the {@code Node} >> + * parameter content does not adhere to the {@code TIFFField} element >> + * structure defined by the >> + * >> + * TIFF native image metadata format specification >> + * an {@code Exception} will be thrown. >> * >> * @param tagSet The {@code TIFFTagSet} to which the >> * {@code TIFFTag} of the field belongs. >> * @param node A native TIFF image metadata {@code TIFFField} node. >> * @throws NullPointerException if {@code node} is >> * {@code null}. >> * @throws IllegalArgumentException if the name of the node is not >> * {@code "TIFFField"}. >> * @throws NullPointerException if the node does not contain any data. >> * @throws IllegalArgumentException if the combination of node attributes >> * and data is not legal per the {@link #TIFFField(TIFFTag,int,int,Object)} >> * constructor specification. >> * @return A new {@code TIFFField}. >> */ >> public static TIFFField createFromMetadataNode(TIFFTagSet tagSet, >> Node node) { >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Tue Aug 23 18:34:23 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 23 Aug 2016 11:34:23 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8149562: TIFFField#createFromMetadataNode javadoc should provide information about sibling/child nodes that should be part of parameter node In-Reply-To: <17458A98-7260-4140-8137-2FAAE5175DAB@oracle.com> References: <304A3A05-9085-4C78-AF24-5AE7622399FB@oracle.com> <752CE81D-8DAC-4E0E-8090-D615C7218D8D@oracle.com> <57B4A146.20603@oracle.com> <17458A98-7260-4140-8137-2FAAE5175DAB@oracle.com> Message-ID: Whilst there is no harm in the cause of the IAE being NPE, unless it is precisely called out in the spec - which it is not - all it says is "Note that a cause might be set on such an exception." which is non-specific, I don't think the test should check for it. -phil. On 8/23/2016 11:17 AM, Brian Burkhalter wrote: > Here is a revision based on the CCC request discussion: > > http://cr.openjdk.java.net/~bpb/8149562/webrev.01/ > > > It was necessary slightly to modify one test as well. > > Thanks, > > Brian > > On Aug 17, 2016, at 10:39 AM, Phil Race > wrote: > >> +1 >> >> -phil. >> >> On 08/16/2016 09:02 AM, Brian Burkhalter wrote: >>> Please review at your convenience. >>> >>> Issue:https://bugs.openjdk.java.net/browse/JDK-8149562 >>> Patch:[1] >>> >>> Add one sentence to the TIFFField.createFromMetadataNode method >>> specification stating that the supplied Node parameter must adhere >>> to the TIFFField element structure defined by the TIFF native image >>> metadata DTD. >>> >>> Thanks, >>> >>> Brian >>> >>> [1] diff >>> >>> --- >>> a/src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFField.java >>> +++ >>> b/src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFField.java >>> >>> /** >>> * Creates a {@code TIFFField} from a TIFF native image >>> * metadata node. If the value of the {@code ?number"} attribute >>> * of the node is not found in {@code tagSet} then a new >>> * {@code TIFFTag} with name {@code TIFFTag.UNKNOWN_TAG_NAME} >>> - * will be created and assigned to the field. >>> + * will be created and assigned to the field. If the {@code Node} >>> + * parameter content does not adhere to the {@code TIFFField} >>> element >>> + * structure defined by the >>> + * >> href="../../metadata/doc-files/tiff_metadata.html#ImageMetadata"> >>> + * TIFF native image metadata format specification >>> + * an {@code Exception} will be thrown. >>> * >>> * @param tagSet The {@code TIFFTagSet} to which the >>> * {@code TIFFTag} of the field belongs. >>> * @param node A native TIFF image metadata {@code TIFFField} node. >>> * @throws NullPointerException if {@code node} is >>> * {@code null}. >>> * @throws IllegalArgumentException if the name of the node is not >>> * {@code "TIFFField"}. >>> * @throws NullPointerException if the node does not contain any >>> data. >>> * @throws IllegalArgumentException if the combination of node >>> attributes >>> * and data is not legal per the {@link >>> #TIFFField(TIFFTag,int,int,Object)} >>> * constructor specification. >>> * @return A new {@code TIFFField}. >>> */ >>> public static TIFFField createFromMetadataNode(TIFFTagSet tagSet, >>> Node node) { >>> >> > From brian.burkhalter at oracle.com Tue Aug 23 18:38:48 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 23 Aug 2016 11:38:48 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8149562: TIFFField#createFromMetadataNode javadoc should provide information about sibling/child nodes that should be part of parameter node In-Reply-To: References: <304A3A05-9085-4C78-AF24-5AE7622399FB@oracle.com> <752CE81D-8DAC-4E0E-8090-D615C7218D8D@oracle.com> <57B4A146.20603@oracle.com> <17458A98-7260-4140-8137-2FAAE5175DAB@oracle.com> Message-ID: <048528A7-B8CE-43DF-BAEC-2CC5183BCFCB@oracle.com> OK I have updated the test accordingly: http://cr.openjdk.java.net/~bpb/8149562/webrev.02/ 458 try { 459 TIFFField.createFromMetadataNode(ts, null); 460 } catch (IllegalArgumentException e) { 461 ok = true; 462 } Thanks, Brian On Aug 23, 2016, at 11:34 AM, Phil Race wrote: > Whilst there is no harm in the cause of the IAE being NPE, unless it > is precisely called out in the spec - which it is not - all it says is > "Note that a cause might be set on such an exception." > which is non-specific, I don't think the test should check for it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Tue Aug 23 18:41:39 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 23 Aug 2016 21:41:39 +0300 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8149562: TIFFField#createFromMetadataNode javadoc should provide information about sibling/child nodes that should be part of parameter node In-Reply-To: <048528A7-B8CE-43DF-BAEC-2CC5183BCFCB@oracle.com> References: <304A3A05-9085-4C78-AF24-5AE7622399FB@oracle.com> <752CE81D-8DAC-4E0E-8090-D615C7218D8D@oracle.com> <57B4A146.20603@oracle.com> <17458A98-7260-4140-8137-2FAAE5175DAB@oracle.com> <048528A7-B8CE-43DF-BAEC-2CC5183BCFCB@oracle.com> Message-ID: <6e6fb32d-e8b4-e807-3149-be82ec64418c@oracle.com> Is it possible, just for the record, to provide a comment why NPE was changed to IAE. actually this code looks a little bit strange: 493 } catch (NullPointerException npe) { 494 throw new IllegalArgumentException(npe); 495 } On 23.08.16 21:38, Brian Burkhalter wrote: > OK I have updated the test accordingly: > > http://cr.openjdk.java.net/~bpb/8149562/webrev.02/ > > 458 try { > 459 TIFFField.createFromMetadataNode(ts, null); > 460 } catch (IllegalArgumentException e) { > 461 ok = true; > 462 } > > Thanks, > > Brian > > On Aug 23, 2016, at 11:34 AM, Phil Race > wrote: > >> Whilst there is no harm in the cause of the IAE being NPE, unless it >> is precisely called out in the spec - which it is not - all it says is >> "Note that a cause might be set on such an exception." >> which is non-specific, I don't think the test should check for it. > -- Best regards, Sergey. From brian.burkhalter at oracle.com Tue Aug 23 18:42:56 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 23 Aug 2016 11:42:56 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8149562: TIFFField#createFromMetadataNode javadoc should provide information about sibling/child nodes that should be part of parameter node In-Reply-To: <6e6fb32d-e8b4-e807-3149-be82ec64418c@oracle.com> References: <304A3A05-9085-4C78-AF24-5AE7622399FB@oracle.com> <752CE81D-8DAC-4E0E-8090-D615C7218D8D@oracle.com> <57B4A146.20603@oracle.com> <17458A98-7260-4140-8137-2FAAE5175DAB@oracle.com> <048528A7-B8CE-43DF-BAEC-2CC5183BCFCB@oracle.com> <6e6fb32d-e8b4-e807-3149-be82ec64418c@oracle.com> Message-ID: <34C737C8-8186-41EC-9717-84FA82EA6ED9@oracle.com> I could do that but the most recent revision does not look like that. Thanks, Brian On Aug 23, 2016, at 11:41 AM, Sergey Bylokhov wrote: > Is it possible, just for the record, to provide a comment why NPE was changed to IAE. actually this code looks a little bit strange: > 493 } catch (NullPointerException npe) { > 494 throw new IllegalArgumentException(npe); > 495 } -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Tue Aug 23 18:45:07 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 23 Aug 2016 21:45:07 +0300 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8149562: TIFFField#createFromMetadataNode javadoc should provide information about sibling/child nodes that should be part of parameter node In-Reply-To: <6e6fb32d-e8b4-e807-3149-be82ec64418c@oracle.com> References: <304A3A05-9085-4C78-AF24-5AE7622399FB@oracle.com> <752CE81D-8DAC-4E0E-8090-D615C7218D8D@oracle.com> <57B4A146.20603@oracle.com> <17458A98-7260-4140-8137-2FAAE5175DAB@oracle.com> <048528A7-B8CE-43DF-BAEC-2CC5183BCFCB@oracle.com> <6e6fb32d-e8b4-e807-3149-be82ec64418c@oracle.com> Message-ID: On 23.08.16 21:41, Sergey Bylokhov wrote: > Is it possible, just for the record, to provide a comment why NPE was > changed to IAE. I meant the first check node==null. actually this code looks a little bit strange: > 493 } catch (NullPointerException npe) { > 494 throw new IllegalArgumentException(npe); > 495 } > > On 23.08.16 21:38, Brian Burkhalter wrote: >> OK I have updated the test accordingly: >> >> http://cr.openjdk.java.net/~bpb/8149562/webrev.02/ >> >> 458 try { >> 459 TIFFField.createFromMetadataNode(ts, null); >> 460 } catch (IllegalArgumentException e) { >> 461 ok = true; >> 462 } >> >> Thanks, >> >> Brian >> >> On Aug 23, 2016, at 11:34 AM, Phil Race > > wrote: >> >>> Whilst there is no harm in the cause of the IAE being NPE, unless it >>> is precisely called out in the spec - which it is not - all it says is >>> "Note that a cause might be set on such an exception." >>> which is non-specific, I don't think the test should check for it. >> > > -- Best regards, Sergey. From james.graham at oracle.com Tue Aug 23 21:32:13 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 23 Aug 2016 14:32:13 -0700 Subject: [OpenJDK 2D-Dev] 8138771: java.awt.image.AbstractMultiResolutionImage needs customized spec for methods of Image which it implements In-Reply-To: References: <27615500-F15F-4D58-B715-C8D96D6FD5FE@oracle.com> <9F556132-58E4-4303-81CC-C031C5023A21@oracle.com> Message-ID: I wonder why the @throws is not inherited...? Another way to fix this would be to implement it in the base Image class with the throw and all classes that can return a graphics override it. Then you wouldn't even need documentation in the AMRI class just to say "never mind we don't provide this method". The spec mentions that the method only works for off-screen images. While an AMRI may contain some off-screen images, it is not itself an off-screen so it should mention that. If we choose to list it in the methods in AMRI then I would just copy the entire comment from the super class Image and edit it based on the assumption that it is not supported for off-screen images, something like: /** * This inherited method can only be called for off-screen images, and throws * an exception in classes like this that do not support it. * @return there is no return value for a non-off-screen image. * @exception UnsupportedOperationException since this class does not represent * an off-screen image. */ ...jim On 8/23/16 2:28 AM, Alexander Scherbatiy wrote: > On 22/08/16 11:06, Avik Niyogi wrote: >> + awt-dev >> >> >>> On 22-Aug-2016, at 12:28 pm, Avik Niyogi > wrote: >>> >>> Hi All, >>> >>> Kindly review the proposed specifications for JDK9. >>> >>> *Bug: https://bugs.openjdk.java.net/browse/JDK-8138771* >>> >>> *Webrev: http://cr.openjdk.java.net/~aniyogi/8138771/webrev.00/ >>> * >>> >>> *Issue: *The customised specifications necessitated for getGraphics method did not exist. >>> So test cases created according to derived specifications would lead to test cases failures. >>> >>> *Cause: * No congruous specifications could elicit failure in circumstances not encompassed >>> in test cases generated without the knowledge of the same. >>> >>> *Fix:* Appropriate comprehensive specifications required were added. > - I am not a native speaker. May be something like this would be better: > ------ > /** > * This method is not supported by {@code AbstractMultiResolutionImage} > * and always throws {@code UnsupportedOperationException} > * > * @return {@code UnsupportedOperationException} is thrown > * @throws UnsupportedOperationException this method is not supported > ------ > > - others overridden method should have a documentation that they delegate call to the base image (see #getBaseImage) > > Thanks, > Alexandr. > >>> >>> With Regards, >>> Avik Niyogi >> > From yuka.kamiya at oracle.com Tue Aug 23 22:08:22 2016 From: yuka.kamiya at oracle.com (Yuka Kamiya) Date: Wed, 24 Aug 2016 07:08:22 +0900 Subject: [OpenJDK 2D-Dev] RFR: JDK-8164628: update copyright header in java.awt.font.JavaAWTFontAccessImpl class Message-ID: <0a7c6b7b-de56-c5c1-f1ba-ca5af6cd320e@oracle.com> Hi, https://bugs.openjdk.java.net/browse/JDK-8164628 Please review the following fix in JDK9. A comma was missing in the fix for https://bugs.openjdk.java.net/browse/JDK-8163362. --- a/src/java.desktop/share/classes/java/awt/font/JavaAWTFontAccessImpl.java +++ b/src/java.desktop/share/classes/java/awt/font/JavaAWTFontAccessImpl.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2014, 2016 Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2014, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * Thanks, -- Yuka From iris.clark at oracle.com Tue Aug 23 22:29:06 2016 From: iris.clark at oracle.com (Iris Clark) Date: Tue, 23 Aug 2016 15:29:06 -0700 (PDT) Subject: [OpenJDK 2D-Dev] RFR: JDK-8164628: update copyright header in java.awt.font.JavaAWTFontAccessImpl class In-Reply-To: <0a7c6b7b-de56-c5c1-f1ba-ca5af6cd320e@oracle.com> References: <0a7c6b7b-de56-c5c1-f1ba-ca5af6cd320e@oracle.com> Message-ID: <6eb393df-fd44-48c2-bbcd-851c3008df9f@default> Hi, Yuka. This looks fine to me. Thanks, iris (not a Reviewer) -----Original Message----- From: Yuka Kamiya Sent: Tuesday, August 23, 2016 3:08 PM To: 2d-dev at openjdk.java.net Subject: [OpenJDK 2D-Dev] RFR: JDK-8164628: update copyright header in java.awt.font.JavaAWTFontAccessImpl class Hi, https://bugs.openjdk.java.net/browse/JDK-8164628 Please review the following fix in JDK9. A comma was missing in the fix for https://bugs.openjdk.java.net/browse/JDK-8163362. --- a/src/java.desktop/share/classes/java/awt/font/JavaAWTFontAccessImpl.java +++ b/src/java.desktop/share/classes/java/awt/font/JavaAWTFontAccessImpl.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2014, 2016 Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2014, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * Thanks, -- Yuka From philip.race at oracle.com Tue Aug 23 22:59:17 2016 From: philip.race at oracle.com (Philip Race) Date: Tue, 23 Aug 2016 15:59:17 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8164628: update copyright header in java.awt.font.JavaAWTFontAccessImpl class In-Reply-To: <0a7c6b7b-de56-c5c1-f1ba-ca5af6cd320e@oracle.com> References: <0a7c6b7b-de56-c5c1-f1ba-ca5af6cd320e@oracle.com> Message-ID: <57BCD545.7000100@oracle.com> Approved -phil. On 8/23/16, 3:08 PM, Yuka Kamiya wrote: > Hi, > > https://bugs.openjdk.java.net/browse/JDK-8164628 > > Please review the following fix in JDK9. A comma was missing in the > fix for https://bugs.openjdk.java.net/browse/JDK-8163362. > > --- > a/src/java.desktop/share/classes/java/awt/font/JavaAWTFontAccessImpl.java > +++ > b/src/java.desktop/share/classes/java/awt/font/JavaAWTFontAccessImpl.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2014, 2016 Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2014, 2016, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > > Thanks, > -- > Yuka From brian.burkhalter at oracle.com Tue Aug 23 23:18:27 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 23 Aug 2016 16:18:27 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8149562: TIFFField#createFromMetadataNode javadoc should provide information about sibling/child nodes that should be part of parameter node In-Reply-To: References: <304A3A05-9085-4C78-AF24-5AE7622399FB@oracle.com> <752CE81D-8DAC-4E0E-8090-D615C7218D8D@oracle.com> <57B4A146.20603@oracle.com> <17458A98-7260-4140-8137-2FAAE5175DAB@oracle.com> <048528A7-B8CE-43DF-BAEC-2CC5183BCFCB@oracle.com> <6e6fb32d-e8b4-e807-3149-be82ec64418c@oracle.com> Message-ID: <78466516-09F5-4BFD-9CCD-83B129105D34@oracle.com> Hi Sergey, I have added some comments in both the source and the test: http://cr.openjdk.java.net/~bpb/8149562/webrev.03/ Please indicate whether you think this is sufficient. The CCC request has been approved therefore pushing this code is pending only review approval. Thanks, Brian On Aug 23, 2016, at 11:45 AM, Sergey Bylokhov wrote: > On 23.08.16 21:41, Sergey Bylokhov wrote: >> Is it possible, just for the record, to provide a comment why NPE was >> changed to IAE. > I meant the first check node==null. > > actually this code looks a little bit strange: >> 493 } catch (NullPointerException npe) { >> 494 throw new IllegalArgumentException(npe); >> 495 } -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Aug 24 00:12:22 2016 From: philip.race at oracle.com (Philip Race) Date: Tue, 23 Aug 2016 17:12:22 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8149562: TIFFField#createFromMetadataNode javadoc should provide information about sibling/child nodes that should be part of parameter node In-Reply-To: <78466516-09F5-4BFD-9CCD-83B129105D34@oracle.com> References: <304A3A05-9085-4C78-AF24-5AE7622399FB@oracle.com> <752CE81D-8DAC-4E0E-8090-D615C7218D8D@oracle.com> <57B4A146.20603@oracle.com> <17458A98-7260-4140-8137-2FAAE5175DAB@oracle.com> <048528A7-B8CE-43DF-BAEC-2CC5183BCFCB@oracle.com> <6e6fb32d-e8b4-e807-3149-be82ec64418c@oracle.com> <78466516-09F5-4BFD-9CCD-83B129105D34@oracle.com> Message-ID: <57BCE666.1010102@oracle.com> Still fine with me. -phil. On 8/23/16, 4:18 PM, Brian Burkhalter wrote: > Hi Sergey, > > I have added some comments in both the source and the test: > > http://cr.openjdk.java.net/~bpb/8149562/webrev.03/ > > > Please indicate whether you think this is sufficient. The CCC request > has been approved therefore pushing this code is pending only review > approval. > > Thanks, > > Brian > > On Aug 23, 2016, at 11:45 AM, Sergey Bylokhov > > wrote: > >> On 23.08.16 21:41, Sergey Bylokhov wrote: >>> Is it possible, just for the record, to provide a comment why NPE was >>> changed to IAE. >> I meant the first check node==null. >> >> actually this code looks a little bit strange: >>> 493 } catch (NullPointerException npe) { >>> 494 throw new IllegalArgumentException(npe); >>> 495 } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Aug 24 00:47:52 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 23 Aug 2016 17:47:52 -0700 Subject: [OpenJDK 2D-Dev] [9] RFC JDK-8154058: [TIFF] ignoreMetadata parameter of TIFFImageReader's setInput() method affects TIFFImageReadParam in non-obvious way In-Reply-To: <57B4A83C.709@oracle.com> References: <7E7ACA58-AA5C-4352-979C-638993C8B7DF@oracle.com> <57B4A83C.709@oracle.com> Message-ID: <786D92A0-CBFA-4A6D-B255-B620D3B36046@oracle.com> Not entirely sure whether this addresses your concerns but I have an updated version of the test which seems to validate my intent with this: http://cr.openjdk.java.net/~bpb/8154058/webrev.00/ Part of the output of this test is: STDOUT: ignore = true: ImageWidth: 50 EXIF (false): false Fax (false): false GPS (true): true ignore = false: ImageWidth: 50 EXIF (true): true Fax (true): true GPS (true): true In summary the behavior is that it reads everything, even tags it does not know about, it ignore == false, but it ignores everything it does not know about if ignore == true. Part of the motivation for reading everything when ignore == false is that there may be other tags out there which are proprietary and which the user wants to obtain but of which we are unaware. One bug which is uncovered however is that the BaselineTIFFTagSet should not be allowed to be removed as in that case reading will fail entirely. I will need to file another issue to track that. Thanks, Brian On Aug 17, 2016, at 11:09 AM, Phil Race wrote: > Hi, > > That all seems fine (for the case of ignoreMetaData == true). > > But there may be still a bug - of some kind - uncovered by this test. > The submitter has this case : > > ignore = false: > EXIF: true > Fax : true > GPS : true > > which means that all metadata is being read .. as is the default per the docs > on the TIFF package description. But I am wondering what the effect setting of > > param.removeAllowedTagSet(FaxTIFFTagSet.getInstance()); > > should have been in this case. > A strict reading of the spec. makes it sound like it only has any effect > when you specify ignoreMetadata == true but I don't see the point > of the API in that case, since you are already ignoring metadata, unless > it is just a matter of being more clear to the reader that the latitude > it has to read metadata anyway regardless should be tempered by > this additional call. > > But is there not also value in being able to remove the tag from > the allowed set in the ignoreMetadata == false case ? > > That seemed to be the gist of the text here :- > >In cases where the IFD includes fields which contain > > large amounts of data this could be very inefficient. > > Which fields are loaded may be controlled by setting > >which TIFF tags the reader is allowed to recognize and whether it is ignoring metadata. > > eg .. "I want all metadata except Fax" .. > > -phil. > > On 08/12/2016 11:23 AM, Brian Burkhalter wrote: >> Please comment at your convenience. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8154058 >> Solution: >> Resolve as ?Not an Issue? >> >> According to [1], >> >> The ignoreMetadata parameter, if set to true, allows the reader to disregard any metadata encountered during the read. Subsequent calls to the getStreamMetadata and getImageMetadata methods may return null, and an IIOImage returned from readAll may return null from their getMetadata method. Setting this parameter may allow the reader to work more efficiently. The reader may choose to disregard this setting and return metadata normally. >> >> According to [2], setting ignoreMetadata has the effect of asking the reader to ignore any TIFF Fields which are not contained in any of the TIFFTagSets known to the reader. This seems to be within the scope of the specification in [1]. >> >> As a result of the foregoing I suggest that the issue be resolved as ?Will not Fix.? >> >> Thanks, >> >> Brian >> >> [1] http://download.java.net/java/jdk9/docs/api/javax/imageio/ImageReader.html#setInput-java.lang.Object-boolean-boolean- >> [2] http://hg.openjdk.java.net/jdk9/client/jdk/file/d5dc0c4fb473/src/java.desktop/share/classes/javax/imageio/metadata/doc-files/tiff_metadata.html, lines 219-234 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Aug 24 00:49:11 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 23 Aug 2016 17:49:11 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8149562: TIFFField#createFromMetadataNode javadoc should provide information about sibling/child nodes that should be part of parameter node In-Reply-To: <57BCE666.1010102@oracle.com> References: <304A3A05-9085-4C78-AF24-5AE7622399FB@oracle.com> <752CE81D-8DAC-4E0E-8090-D615C7218D8D@oracle.com> <57B4A146.20603@oracle.com> <17458A98-7260-4140-8137-2FAAE5175DAB@oracle.com> <048528A7-B8CE-43DF-BAEC-2CC5183BCFCB@oracle.com> <6e6fb32d-e8b4-e807-3149-be82ec64418c@oracle.com> <78466516-09F5-4BFD-9CCD-83B129105D34@oracle.com> <57BCE666.1010102@oracle.com> Message-ID: OK unless there are objections from Sergey tomorrow I will plan to push it as-is. Thanks, Brian On Aug 23, 2016, at 5:12 PM, Philip Race wrote: > Still fine with me. > > -phil. > > On 8/23/16, 4:18 PM, Brian Burkhalter wrote: >> >> Hi Sergey, >> >> I have added some comments in both the source and the test: >> >> http://cr.openjdk.java.net/~bpb/8149562/webrev.03/ >> >> Please indicate whether you think this is sufficient. The CCC request has been approved therefore pushing this code is pending only review approval. >> >> Thanks, >> >> Brian >> >> On Aug 23, 2016, at 11:45 AM, Sergey Bylokhov wrote: >> >>> On 23.08.16 21:41, Sergey Bylokhov wrote: >>>> Is it possible, just for the record, to provide a comment why NPE was >>>> changed to IAE. >>> I meant the first check node==null. >>> >>> actually this code looks a little bit strange: >>>> 493 } catch (NullPointerException npe) { >>>> 494 throw new IllegalArgumentException(npe); >>>> 495 } >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Wed Aug 24 09:48:39 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 24 Aug 2016 11:48:39 +0200 Subject: [OpenJDK 2D-Dev] [REGRESSION?] Build warnings at jdhuff.c with GCC 6 In-Reply-To: <57BC75F7.1020403@oracle.com> References: <46f8bb76-5fe9-d0aa-cfd7-b228e5478640@gmail.com> <57BC67AE.9080607@oracle.com> <57BC75F7.1020403@oracle.com> Message-ID: <0e864777-8f99-70c5-6014-07f963f17015@oracle.com> Hello, On 2016-08-23 18:12, Phil Race wrote: > On 08/23/2016 08:47 AM, Erik Joelsson wrote: >> Hello, >> >> I do agree that maintaining the list of disabled warnings will be >> impossible unless we have a structured way of tracking for which >> compiler versions we disable what. Ideally we should be able to easily >> add conditions for when certain warnings should be disabled. We are >> unfortunately lacking that today and at least I don't have the >> bandwidth to fix that anytime soon. >> >> The official compilers are only really official for Oracle. The >> OpenJDK can (and should) be buildable with a much wider range of >> compiler versions. > I agree there. This is fortunately not an "unbuildable" situation. > The only other option I can think of which may or may not be palatable > is to explicitly > check the compiler version and add that disabled warning only for that > exact compiler version. > There'd still be some maintenance as that compiler version became either > official .. or obsolete .. > > Is there precedent (or any kind of support) for that ? What I had in mind was a structured way of adding conditionals for some kind of ranges of compiler versions, or at least something like 6.*, or "greater than 4.9.3". It's pretty simple today to check for exact compiler versions but then we end up with a lot of changes when minor versions are bumped. I don't think that would be worth it. In this particular case is shift-negative-value a new warning in GCC 6? If that's the case it doesn't actually hurt adding it since GCC is nice enough to not complain about unknown warning tags. If we do, just make sure to specify in a comment that it's specific to GCC version 6+. /Erik > -phil. > >> Luckily we have the workaround of setting --disable-warnings-as-errors >> when this situation occurs. >> >> For reference, the compilers Oracle uses are listed in >> README-builds.md in the top level directory in the forest. >> >> So for now at least, I think Phil is right. >> >> /Erik >> >> On 2016-08-23 17:11, Philip Race wrote: >>> Erik .. please chime in if you disagree with the following >>> The goal here is to have no warnings with the *official* compilers. >>> If you are using something else and get warnings then either fix >>> the *source* or else you need to use --disable-warning-as-errors. >>> >>> Otherwise we'll be suppressing the warnings for a whole range >>> of compilers and no one will know what the set is and these >>> bugs will become 'unfixable' and a continual chore of churn. >>> It will be something we should address as we move *official* compilers. >>> >>> In fact the warning you want to suppress is one I just got rid of (the >>> suppression) >>> http://hg.openjdk.java.net/jdk9/client/jdk/rev/d4f7412a51d2 >>> I don't think we want to add it back unless the *official* compilers >>> object >>> .. I am sure that official list is documented somewhere. >>> >>> -phil. >>> >>> >>> On 8/23/16, 6:10 AM, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> I've fixed several warnings when we build OpenJDK with GCC 6 in >>>> JDK-8160294. >>>> However, I encountered shift-negative-value warnings at jdhuff.c on my >>>> Fedora 24 (GCC 6.1.1): >>>> -------------- >>>> /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:13: >>>> >>>> warning: left shift of negative value [-Wshift-negative-value] >>>> { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1, >>>> ^~ >>>> /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:28: >>>> >>>> warning: left shift of negative value [-Wshift-negative-value] >>>> { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1, >>>> ^~ >>>> /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:43: >>>> >>>> warning: left shift of negative value [-Wshift-negative-value] >>>> { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1, >>>> : >>>> -------------- >>>> >>>> I think these warnings are available from JDK-8074827. >>>> This issue enables warnings to fix in the source code. >>>> However, in review of JDK-8160294, I heared that warnings in IJG JPEG >>>> library should just be suppressed: >>>> >>>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004497.html >>>> >>>> >>>> So I think they should be suppressed and we should fix as below: >>>> -------------- >>>> diff -r b548b8217d8c make/lib/Awt2dLibraries.gmk >>>> --- a/make/lib/Awt2dLibraries.gmk Mon Aug 22 19:28:36 2016 -0700 >>>> +++ b/make/lib/Awt2dLibraries.gmk Tue Aug 23 22:08:44 2016 +0900 >>>> @@ -490,7 +490,7 @@ >>>> CFLAGS := $(CFLAGS_JDKLIB) $(BUILD_LIBJAVAJPEG_HEADERS) \ >>>> $(LIBJAVA_HEADER_FLAGS) \ >>>> -I$(SUPPORT_OUTPUTDIR)/headers/java.desktop, \ >>>> - DISABLED_WARNINGS_gcc := clobbered, \ >>>> + DISABLED_WARNINGS_gcc := clobbered shift-negative-value, \ >>>> MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libjpeg/mapfile-vers, \ >>>> LDFLAGS := $(LDFLAGS_JDKLIB) \ >>>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>> -------------- >>>> >>>> If it is correct, I file it to JBS and upload webrev. >>>> Do you think about it? >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> From prasanta.sadhukhan at oracle.com Wed Aug 24 10:39:57 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 24 Aug 2016 16:09:57 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8154218: Non-usage of owner Frame when Frame object is passed to getPrintJob() Message-ID: <57BD797D.4060801@oracle.com> Hi All, Please review a fix for an issue where it is seen that the Frame object passed to Toolkit.getPrintJob() is not used when cross platform print dialog is created, so the print dialog does not have an owner Frame and therefore if the parent frame is disposed, the print dialog is not affected. Bug: https://bugs.openjdk.java.net/browse/JDK-8154218 webrev: http://cr.openjdk.java.net/~psadhukhan/8154218/webrev.00/ Proposed fix is to get the DialogOwner attribute which has been set in PrintJob2D.printDialog() and use the returned frame object as owner. As of now, null is explicitly passed as owner argument. Regards Prasanta From ajit.ghaisas at oracle.com Wed Aug 24 11:41:28 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Wed, 24 Aug 2016 04:41:28 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9]Fix for JDK-8158356 : SIGSEGV when attempting to rotate BufferedImage using AffineTransform by NaN degrees In-Reply-To: <57ABA20A.2060403@oracle.com> References: <57AB9B17.3030709@oracle.com> <3bbfa84f-36ae-69aa-cd07-912d1d1fa181@oracle.com> <57ABA20A.2060403@oracle.com> Message-ID: <962fe847-d042-4254-96a6-c5a53ce00b22@default> Hi, The root cause of the crash is - NaN is converted to an integer and used as array index in mlib_ImageScanPoly.c. The native method previously did not check the validity of the input double argument. Now, I have added a check for finite double values. If NaN or INF arguments are present in affine transform, the changes done in native code result in ImagingOpException ("Unable to transform src image") in AffineTransformOp.filter() methods. The constructors in AffineTransformOp.java are left unchanged. Please note that, this fix fixes the crash. The behavioral change in AffineTransformOp for such inputs will be fixed under JDK-8164729. Please review the updated webrev. http://cr.openjdk.java.net/~aghaisas/8158356/webrev.01/ Regards, Ajit -----Original Message----- From: Philip Race Sent: Thursday, August 11, 2016 3:22 AM To: Jim Graham Cc: Ajit Ghaisas; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [9]Fix for JDK-8158356 : SIGSEGV when attempting to rotate BufferedImage using AffineTransform by NaN degrees Agreed, I had previously asked for that too (off-line). ie. root cause why a NaN would cause a crash .. -phil. On 8/10/16, 2:47 PM, Jim Graham wrote: > This does address the specific test case directly, but I'd be happier > if we dug down and figured out where it went wrong in trying to > transform the image and put in a fix that addressed the root problem > whether it comes from the inputs being NaN or from some other similar > condition that could also trigger the same poorly written transform > code... > > ...jim > > On 8/10/16 2:22 PM, Phil Race wrote: >> 1) The spec for the constructors needs to be updated to include this >> reason for throwing ImagingOpException. A CCC request will be needed. >> >> 2) The C usage of "isnan()" may be problematic in some compilation >> environments. >> For example I believe this will not compile with VS2010, and many >> folks still use that. >> Instead you could use matrix[j] != matrix[j] as the two values should >> not compare equal if it is NaN. >> >> -phil. >> >> On 08/10/2016 04:15 AM, Ajit Ghaisas wrote: >>> Hi, >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8158356 >>> >>> Issue : AffineTransform using NaN value as input parameter >>> results in SIGSEGV. >>> >>> Fix : Transformation matrix is checked for NaN values in >>> AffineTransformOp.validateTransform(). >>> Also, at native level a separate check is made to >>> return error in case of NaN values. >>> >>> Webrev : >>> http://cr.openjdk.java.net/~aghaisas/8158356/webrev.00/ >>> >>> Request you to review. >>> >>> Regards, >>> Ajit >>> >> From yasuenag at gmail.com Wed Aug 24 12:31:01 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 24 Aug 2016 21:31:01 +0900 Subject: [OpenJDK 2D-Dev] [REGRESSION?] Build warnings at jdhuff.c with GCC 6 In-Reply-To: <0e864777-8f99-70c5-6014-07f963f17015@oracle.com> References: <46f8bb76-5fe9-d0aa-cfd7-b228e5478640@gmail.com> <57BC67AE.9080607@oracle.com> <57BC75F7.1020403@oracle.com> <0e864777-8f99-70c5-6014-07f963f17015@oracle.com> Message-ID: Hi Erik, Phil, Thank you for replying. I understand background of JDK-8074827. > In this particular case is shift-negative-value a new warning in GCC 6? Yes, this feature is implemented GCC 6: https://gnu.wildebeest.org/blog/mjw/2016/02/15/looking-forward-to-gcc6-many-new-warnings/ BTW, why is libjavajpeg only enabled these warnings? For example, liblcms is disabled format-nonliteral, type-limits, and misleading-indentation. I agree compiler warnings is very useful to fix. However, I think a part of source of libjavajpeg is third-party (developed by Independent JPEG Group). According to [1], warnings in this library should be suppressed. If all binaries which are included in JDK/JRE should be enabled all compiler warnings, I think LCMS and any other libraries should be fixed. Which policy is correct? Thanks, Yasumasa [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004495.html On 2016/08/24 18:48, Erik Joelsson wrote: > Hello, > > > On 2016-08-23 18:12, Phil Race wrote: >> On 08/23/2016 08:47 AM, Erik Joelsson wrote: >>> Hello, >>> >>> I do agree that maintaining the list of disabled warnings will be >>> impossible unless we have a structured way of tracking for which >>> compiler versions we disable what. Ideally we should be able to easily >>> add conditions for when certain warnings should be disabled. We are >>> unfortunately lacking that today and at least I don't have the >>> bandwidth to fix that anytime soon. >>> >>> The official compilers are only really official for Oracle. The >>> OpenJDK can (and should) be buildable with a much wider range of >>> compiler versions. >> I agree there. This is fortunately not an "unbuildable" situation. >> The only other option I can think of which may or may not be palatable >> is to explicitly >> check the compiler version and add that disabled warning only for that >> exact compiler version. >> There'd still be some maintenance as that compiler version became either >> official .. or obsolete .. >> >> Is there precedent (or any kind of support) for that ? > What I had in mind was a structured way of adding conditionals for some kind of ranges of compiler versions, or at least something like 6.*, or "greater than 4.9.3". It's pretty simple today to check for exact compiler versions but then we end up with a lot of changes when minor versions are bumped. I don't think that would be worth it. > > In this particular case is shift-negative-value a new warning in GCC 6? If that's the case it doesn't actually hurt adding it since GCC is nice enough to not complain about unknown warning tags. If we do, just make sure to specify in a comment that it's specific to GCC version 6+. > > /Erik >> -phil. >> >>> Luckily we have the workaround of setting --disable-warnings-as-errors >>> when this situation occurs. >>> >>> For reference, the compilers Oracle uses are listed in >>> README-builds.md in the top level directory in the forest. >>> >>> So for now at least, I think Phil is right. >>> >>> /Erik >>> >>> On 2016-08-23 17:11, Philip Race wrote: >>>> Erik .. please chime in if you disagree with the following >>>> The goal here is to have no warnings with the *official* compilers. >>>> If you are using something else and get warnings then either fix >>>> the *source* or else you need to use --disable-warning-as-errors. >>>> >>>> Otherwise we'll be suppressing the warnings for a whole range >>>> of compilers and no one will know what the set is and these >>>> bugs will become 'unfixable' and a continual chore of churn. >>>> It will be something we should address as we move *official* compilers. >>>> >>>> In fact the warning you want to suppress is one I just got rid of (the >>>> suppression) >>>> http://hg.openjdk.java.net/jdk9/client/jdk/rev/d4f7412a51d2 >>>> I don't think we want to add it back unless the *official* compilers >>>> object >>>> .. I am sure that official list is documented somewhere. >>>> >>>> -phil. >>>> >>>> >>>> On 8/23/16, 6:10 AM, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> I've fixed several warnings when we build OpenJDK with GCC 6 in >>>>> JDK-8160294. >>>>> However, I encountered shift-negative-value warnings at jdhuff.c on my >>>>> Fedora 24 (GCC 6.1.1): >>>>> -------------- >>>>> /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:13: >>>>> >>>>> warning: left shift of negative value [-Wshift-negative-value] >>>>> { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1, >>>>> ^~ >>>>> /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:28: >>>>> >>>>> warning: left shift of negative value [-Wshift-negative-value] >>>>> { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1, >>>>> ^~ >>>>> /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:43: >>>>> >>>>> warning: left shift of negative value [-Wshift-negative-value] >>>>> { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1, >>>>> : >>>>> -------------- >>>>> >>>>> I think these warnings are available from JDK-8074827. >>>>> This issue enables warnings to fix in the source code. >>>>> However, in review of JDK-8160294, I heared that warnings in IJG JPEG >>>>> library should just be suppressed: >>>>> >>>>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004497.html >>>>> >>>>> >>>>> So I think they should be suppressed and we should fix as below: >>>>> -------------- >>>>> diff -r b548b8217d8c make/lib/Awt2dLibraries.gmk >>>>> --- a/make/lib/Awt2dLibraries.gmk Mon Aug 22 19:28:36 2016 -0700 >>>>> +++ b/make/lib/Awt2dLibraries.gmk Tue Aug 23 22:08:44 2016 +0900 >>>>> @@ -490,7 +490,7 @@ >>>>> CFLAGS := $(CFLAGS_JDKLIB) $(BUILD_LIBJAVAJPEG_HEADERS) \ >>>>> $(LIBJAVA_HEADER_FLAGS) \ >>>>> -I$(SUPPORT_OUTPUTDIR)/headers/java.desktop, \ >>>>> - DISABLED_WARNINGS_gcc := clobbered, \ >>>>> + DISABLED_WARNINGS_gcc := clobbered shift-negative-value, \ >>>>> MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libjpeg/mapfile-vers, \ >>>>> LDFLAGS := $(LDFLAGS_JDKLIB) \ >>>>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>>> -------------- >>>>> >>>>> If it is correct, I file it to JBS and upload webrev. >>>>> Do you think about it? >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> > From Sergey.Bylokhov at oracle.com Wed Aug 24 15:09:19 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 24 Aug 2016 18:09:19 +0300 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8149562: TIFFField#createFromMetadataNode javadoc should provide information about sibling/child nodes that should be part of parameter node In-Reply-To: References: <304A3A05-9085-4C78-AF24-5AE7622399FB@oracle.com> <752CE81D-8DAC-4E0E-8090-D615C7218D8D@oracle.com> <57B4A146.20603@oracle.com> <17458A98-7260-4140-8137-2FAAE5175DAB@oracle.com> <048528A7-B8CE-43DF-BAEC-2CC5183BCFCB@oracle.com> <6e6fb32d-e8b4-e807-3149-be82ec64418c@oracle.com> <78466516-09F5-4BFD-9CCD-83B129105D34@oracle.com> <57BCE666.1010102@oracle.com> Message-ID: <7ee4be70-3108-79b4-71b6-86cc1a3c98ea@oracle.com> +1 On 24.08.16 3:49, Brian Burkhalter wrote: > OK unless there are objections from Sergey tomorrow I will plan to push > it as-is. > > Thanks, > > Brian > > On Aug 23, 2016, at 5:12 PM, Philip Race > wrote: > >> Still fine with me. >> >> -phil. >> >> On 8/23/16, 4:18 PM, Brian Burkhalter wrote: >>> Hi Sergey, >>> >>> I have added some comments in both the source and the test: >>> >>> http://cr.openjdk.java.net/~bpb/8149562/webrev.03/ >>> >>> >>> Please indicate whether you think this is sufficient. The CCC request >>> has been approved therefore pushing this code is pending only review >>> approval. >>> >>> Thanks, >>> >>> Brian >>> >>> On Aug 23, 2016, at 11:45 AM, Sergey Bylokhov >>> > wrote: >>> >>>> On 23.08.16 21:41, Sergey Bylokhov wrote: >>>>> Is it possible, just for the record, to provide a comment why NPE was >>>>> changed to IAE. >>>> I meant the first check node==null. >>>> >>>> actually this code looks a little bit strange: >>>>> 493 } catch (NullPointerException npe) { >>>>> 494 throw new IllegalArgumentException(npe); >>>>> 495 } >>> > -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Wed Aug 24 16:36:14 2016 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 24 Aug 2016 20:36:14 +0400 Subject: [OpenJDK 2D-Dev] [9] Review request for 8163854 Add ToolkitImage.getImage() method which loads an image with schema variant Message-ID: <081568bb-c765-0575-f8e7-dc5497b5e7e4@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8163854 webrev: http://cr.openjdk.java.net/~alexsch/8163854/webrev.00 The public API which allows to load an image with resolution variants based on the provided media resolution naming scheme is added: - Toolkit.MediaResolutionNamingScheme class - Toolkit.getImageUsingNamingSchemes(String fileName, MediaResolutionNamingScheme... namingSchemes) A simple example for images which use naming scheme @150pct for scale 1.5 and @2x for scale 2 is: image_name.ext image_name at 150pct.ext image_name at 2x.ext Toolkit toolkit = Toolkit.getDefaultToolkit(); Image image = toolkit.getImageUsingNamingSchemes(fileName, new Toolkit.MediaResolutionNamingScheme(?@150pct?, 1.5f), new Toolkit.MediaResolutionNamingScheme(?@2x", 2f) ); Thanks, Alexandr. From philip.race at oracle.com Wed Aug 24 16:47:23 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 24 Aug 2016 09:47:23 -0700 Subject: [OpenJDK 2D-Dev] [9]Fix for JDK-8158356 : SIGSEGV when attempting to rotate BufferedImage using AffineTransform by NaN degrees In-Reply-To: <962fe847-d042-4254-96a6-c5a53ce00b22@default> References: <57AB9B17.3030709@oracle.com> <3bbfa84f-36ae-69aa-cd07-912d1d1fa181@oracle.com> <57ABA20A.2060403@oracle.com> <962fe847-d042-4254-96a6-c5a53ce00b22@default> Message-ID: <57BDCF9B.6000000@oracle.com> +1 -phil. On 8/24/16, 4:41 AM, Ajit Ghaisas wrote: > Hi, > > The root cause of the crash is - NaN is converted to an integer and used as array index in mlib_ImageScanPoly.c. > The native method previously did not check the validity of the input double argument. Now, I have added a check for finite double values. > > If NaN or INF arguments are present in affine transform, the changes done in native code result in ImagingOpException ("Unable to transform src image") in AffineTransformOp.filter() methods. > The constructors in AffineTransformOp.java are left unchanged. > Please note that, this fix fixes the crash. The behavioral change in AffineTransformOp for such inputs will be fixed under JDK-8164729. > > Please review the updated webrev. > http://cr.openjdk.java.net/~aghaisas/8158356/webrev.01/ > > Regards, > Ajit > > -----Original Message----- > From: Philip Race > Sent: Thursday, August 11, 2016 3:22 AM > To: Jim Graham > Cc: Ajit Ghaisas; 2d-dev > Subject: Re: [OpenJDK 2D-Dev] [9]Fix for JDK-8158356 : SIGSEGV when attempting to rotate BufferedImage using AffineTransform by NaN degrees > > Agreed, I had previously asked for that too (off-line). > ie. root cause why a NaN would cause a crash .. > > -phil. > > On 8/10/16, 2:47 PM, Jim Graham wrote: >> This does address the specific test case directly, but I'd be happier >> if we dug down and figured out where it went wrong in trying to >> transform the image and put in a fix that addressed the root problem >> whether it comes from the inputs being NaN or from some other similar >> condition that could also trigger the same poorly written transform >> code... >> >> ...jim >> >> On 8/10/16 2:22 PM, Phil Race wrote: >>> 1) The spec for the constructors needs to be updated to include this >>> reason for throwing ImagingOpException. A CCC request will be needed. >>> >>> 2) The C usage of "isnan()" may be problematic in some compilation >>> environments. >>> For example I believe this will not compile with VS2010, and many >>> folks still use that. >>> Instead you could use matrix[j] != matrix[j] as the two values should >>> not compare equal if it is NaN. >>> >>> -phil. >>> >>> On 08/10/2016 04:15 AM, Ajit Ghaisas wrote: >>>> Hi, >>>> >>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8158356 >>>> >>>> Issue : AffineTransform using NaN value as input parameter >>>> results in SIGSEGV. >>>> >>>> Fix : Transformation matrix is checked for NaN values in >>>> AffineTransformOp.validateTransform(). >>>> Also, at native level a separate check is made to >>>> return error in case of NaN values. >>>> >>>> Webrev : >>>> http://cr.openjdk.java.net/~aghaisas/8158356/webrev.00/ >>>> >>>> Request you to review. >>>> >>>> Regards, >>>> Ajit >>>> From philip.race at oracle.com Wed Aug 24 16:50:46 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 24 Aug 2016 09:50:46 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8154218: Non-usage of owner Frame when Frame object is passed to getPrintJob() In-Reply-To: <57BD797D.4060801@oracle.com> References: <57BD797D.4060801@oracle.com> Message-ID: <57BDD066.1020803@oracle.com> +1 Some day we should still consider an API that lets the application pass in an owner. -phil. On 8/24/16, 3:39 AM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix for an issue where it is seen that the Frame > object passed to Toolkit.getPrintJob() is not used when cross platform > print dialog is created, > so the print dialog does not have an owner Frame and therefore if the > parent frame is disposed, the print dialog is not affected. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154218 > webrev: http://cr.openjdk.java.net/~psadhukhan/8154218/webrev.00/ > > Proposed fix is to get the DialogOwner attribute which has been set > in PrintJob2D.printDialog() and use the returned frame object as owner. > As of now, null is explicitly passed as owner argument. > > Regards > Prasanta From philip.race at oracle.com Wed Aug 24 16:56:02 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 24 Aug 2016 09:56:02 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR 4885375: Page Ranges 'To Page' field must be populated based on Pageable In-Reply-To: <57BC3C05.3000400@oracle.com> References: <57BC3C05.3000400@oracle.com> Message-ID: <57BDD1A2.9040904@oracle.com> Why does the test look like this ? 157 @Override 158 public int getNumberOfPages() { 159 return 0; 160 } -phil. On 8/23/16, 5:05 AM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix whereby it is seen that Page Ranges fields in the > "cross-platform" dialog does not get populated based on what > pageable's getNumberOfPages() returns. "To" field is always 1. > However, for native dialog it shows the "To" field correctly based on > what getNumberOfPages() returns. > > Bug: https://bugs.openjdk.java.net/browse/JDK-4885375 > webrev: http://cr.openjdk.java.net/~psadhukhan/4885375/webrev.00/ > > This is because in cross platform ServiceDialog, for the ToPage to get > populated, PageRanges should be present in the attribute set. In this > case, there is no PageRanges so it defaults to "from 1 to 1" pages. > Proposed fix is to set a PageRange attribute to be from 1 to > getNumberOfPages. > > The 2nd issue of disabling PageRange fields if getNumberOfPages() > returns 0 is not handled as there is no provision of passing > PageRanges 0 to ServiceDialog (it resuls in IAE). > > Regards > Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Wed Aug 24 16:57:33 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 24 Aug 2016 22:27:33 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR 4885375: Page Ranges 'To Page' field must be populated based on Pageable In-Reply-To: <57BDD1A2.9040904@oracle.com> References: <57BC3C05.3000400@oracle.com> <57BDD1A2.9040904@oracle.com> Message-ID: <57BDD1FD.4010806@oracle.com> Oh, it should be return 5. I was testing the 2nd issue and forgot to change it back. Regards Prasanta On 8/24/2016 10:26 PM, Philip Race wrote: > Why does the test look like this ? > 157 @Override > 158 public int getNumberOfPages() { > 159 return 0; > 160 } > > -phil. > > On 8/23/16, 5:05 AM, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a fix whereby it is seen that Page Ranges fields in the >> "cross-platform" dialog does not get populated based on what >> pageable's getNumberOfPages() returns. "To" field is always 1. >> However, for native dialog it shows the "To" field correctly based on >> what getNumberOfPages() returns. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-4885375 >> webrev: http://cr.openjdk.java.net/~psadhukhan/4885375/webrev.00/ >> >> This is because in cross platform ServiceDialog, for the ToPage to >> get populated, PageRanges should be present in the attribute set. In >> this case, there is no PageRanges so it defaults to "from 1 to 1" pages. >> Proposed fix is to set a PageRange attribute to be from 1 to >> getNumberOfPages. >> >> The 2nd issue of disabling PageRange fields if getNumberOfPages() >> returns 0 is not handled as there is no provision of passing >> PageRanges 0 to ServiceDialog (it resuls in IAE). >> >> Regards >> Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Wed Aug 24 17:08:52 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 24 Aug 2016 22:38:52 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR 4885375: Page Ranges 'To Page' field must be populated based on Pageable In-Reply-To: <57BDD1FD.4010806@oracle.com> References: <57BC3C05.3000400@oracle.com> <57BDD1A2.9040904@oracle.com> <57BDD1FD.4010806@oracle.com> Message-ID: <57BDD4A4.5070005@oracle.com> Modified testcase http://cr.openjdk.java.net/~psadhukhan/4885375/webrev.01/ On 8/24/2016 10:27 PM, Prasanta Sadhukhan wrote: > Oh, it should be return 5. I was testing the 2nd issue and forgot to > change it back. > > Regards > Prasanta > On 8/24/2016 10:26 PM, Philip Race wrote: >> Why does the test look like this ? >> 157 @Override >> 158 public int getNumberOfPages() { >> 159 return 0; >> 160 } >> >> -phil. >> >> On 8/23/16, 5:05 AM, Prasanta Sadhukhan wrote: >>> Hi All, >>> >>> Please review a fix whereby it is seen that Page Ranges fields in >>> the "cross-platform" dialog does not get populated based on what >>> pageable's getNumberOfPages() returns. "To" field is always 1. >>> However, for native dialog it shows the "To" field correctly based >>> on what getNumberOfPages() returns. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-4885375 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/4885375/webrev.00/ >>> >>> This is because in cross platform ServiceDialog, for the ToPage to >>> get populated, PageRanges should be present in the attribute set. In >>> this case, there is no PageRanges so it defaults to "from 1 to 1" >>> pages. >>> Proposed fix is to set a PageRange attribute to be from 1 to >>> getNumberOfPages. >>> >>> The 2nd issue of disabling PageRange fields if getNumberOfPages() >>> returns 0 is not handled as there is no provision of passing >>> PageRanges 0 to ServiceDialog (it resuls in IAE). >>> >>> Regards >>> Prasanta > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Aug 24 17:41:47 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 24 Aug 2016 10:41:47 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR 4885375: Page Ranges 'To Page' field must be populated based on Pageable In-Reply-To: <57BDD4A4.5070005@oracle.com> References: <57BC3C05.3000400@oracle.com> <57BDD1A2.9040904@oracle.com> <57BDD1FD.4010806@oracle.com> <57BDD4A4.5070005@oracle.com> Message-ID: <57BDDC5B.1090404@oracle.com> OK that is what I (sort of) suspected. +1 -phil. On 8/24/16, 10:08 AM, Prasanta Sadhukhan wrote: > Modified testcase > http://cr.openjdk.java.net/~psadhukhan/4885375/webrev.01/ > > On 8/24/2016 10:27 PM, Prasanta Sadhukhan wrote: >> Oh, it should be return 5. I was testing the 2nd issue and forgot to >> change it back. >> >> Regards >> Prasanta >> On 8/24/2016 10:26 PM, Philip Race wrote: >>> Why does the test look like this ? >>> 157 @Override >>> 158 public int getNumberOfPages() { >>> 159 return 0; >>> 160 } >>> >>> -phil. >>> >>> On 8/23/16, 5:05 AM, Prasanta Sadhukhan wrote: >>>> Hi All, >>>> >>>> Please review a fix whereby it is seen that Page Ranges fields in >>>> the "cross-platform" dialog does not get populated based on what >>>> pageable's getNumberOfPages() returns. "To" field is always 1. >>>> However, for native dialog it shows the "To" field correctly based >>>> on what getNumberOfPages() returns. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-4885375 >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/4885375/webrev.00/ >>>> >>>> This is because in cross platform ServiceDialog, for the ToPage to >>>> get populated, PageRanges should be present in the attribute set. >>>> In this case, there is no PageRanges so it defaults to "from 1 to >>>> 1" pages. >>>> Proposed fix is to set a PageRange attribute to be from 1 to >>>> getNumberOfPages. >>>> >>>> The 2nd issue of disabling PageRange fields if getNumberOfPages() >>>> returns 0 is not handled as there is no provision of passing >>>> PageRanges 0 to ServiceDialog (it resuls in IAE). >>>> >>>> Regards >>>> Prasanta >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Aug 24 18:35:35 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 24 Aug 2016 11:35:35 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6357887: selected printertray is ignored under linux In-Reply-To: <57B6A536.8050106@oracle.com> References: <57AAECFD.2030802@oracle.com> <57B48517.3030200@oracle.com> <57B5588D.1050909@oracle.com> <57B63160.80908@oracle.com> <57B6A536.8050106@oracle.com> Message-ID: <7d08d76c-a335-8d63-dd80-beb567920578@oracle.com> In fact what you should be doing here is Attribute attr = attrs.get(Media.class); if (attr instanceof CustomMediaTray) .... The program below should show that the lookup works so long as the key is the class understood by the API - not a sub-type. -phil. import javax.print.*; import javax.print.attribute.*; import javax.print.attribute.standard.*; public class CMT { public static void main(String args[]) throws Exception { PrintService svc = PrintServiceLookup.lookupPrintServices(null,null)[0]; Media[] allMedia = (Media[])svc.getSupportedAttributeValues(Media.class, null, null); PrintRequestAttributeSet aset = new HashPrintRequestAttributeSet(); for (int m=0;m>> attributes.get(CustomMediatray.class) returns null. >>> Modified webrev to get Media attribute and then see if the attribute >>> is an instance of CustomMediatray. >>> >>> http://cr.openjdk.java.net/~psadhukhan/6357887/webrev.01/ >>> >>> Regards >>> Prasanta >>> On 8/17/2016 9:09 PM, Philip Race wrote: >>>> This all looks fine although this can be a simple call to >>>> attributes.get(CustomMediaTray.class) can't it ? >>>> >>>> 502 for (int i=0; i< attrs.length; i++) { >>>> 503 Attribute attr = attrs[i]; >>>> 504 try { >>>> 505 if (attr instanceof CustomMediaTray) { >>>> 506 CustomMediaTray customTray = >>>> (CustomMediaTray)attr; >>>> 507 mOptions = " InputSlot="+ >>>> customTray.getChoiceName(); >>>> 508 } >>>> 509 } catch (ClassCastException e) { >>>> >>>> -phil. >>>> >>>> On 8/10/16, 1:59 AM, Prasanta Sadhukhan wrote: >>>>> Hi All, >>>>> >>>>> Please review a fix for an issue where it is seen that the >>>>> selected printer tray is ignored in linux and default standard >>>>> tray is used for printing. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6357887 >>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6357887/webrev.00/ >>>>> >>>>> Issue was lpr command needs "-o InputSlot=" to select >>>>> the printertray which was not being passed to lpr command. >>>>> Proposed fix added InputSlot option to lpr command to select the >>>>> printertray. >>>>> >>>>> Tested in ubuntu and solaris11. >>>>> >>>>> Regards >>>>> Prasanta >>> > From philip.race at oracle.com Wed Aug 24 19:49:41 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 24 Aug 2016 12:49:41 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8164752: Extraneous debugging printf in hb-jdk-font.cc Message-ID: <57BDFA55.6030402@oracle.com> Need a quick review to get rid of a debugging message that was inadvertenly included in a fix. Fix below .. https://bugs.openjdk.java.net/browse/JDK-8164752 --- a/src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc +++ b/src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc @@ -52,7 +52,6 @@ *glyph = (hb_codepoint_t) env->CallIntMethod(font2D, sunFontIDs.f2dCharToGlyphMID, u); -printf("unicode=%x glyph=%x\n", unicode, *glyph); return (*glyph != 0); } -phil. From brian.burkhalter at oracle.com Wed Aug 24 19:52:25 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 24 Aug 2016 12:52:25 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8164752: Extraneous debugging printf in hb-jdk-font.cc In-Reply-To: <57BDFA55.6030402@oracle.com> References: <57BDFA55.6030402@oracle.com> Message-ID: <4A39674E-3159-46D3-B595-96F10E4EF871@oracle.com> Approved. Brian On Aug 24, 2016, at 12:49 PM, Phil Race wrote: > Need a quick review to get rid of a debugging message that was > inadvertenly included in a fix. Fix below .. > > https://bugs.openjdk.java.net/browse/JDK-8164752 > > > --- a/src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc > +++ b/src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc > @@ -52,7 +52,6 @@ > > *glyph = (hb_codepoint_t) > env->CallIntMethod(font2D, sunFontIDs.f2dCharToGlyphMID, u); > -printf("unicode=%x glyph=%x\n", unicode, *glyph); > return (*glyph != 0); > } > > -phil. From avik.niyogi at oracle.com Wed Aug 24 06:43:23 2016 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Wed, 24 Aug 2016 12:13:23 +0530 Subject: [OpenJDK 2D-Dev] 8138771: java.awt.image.AbstractMultiResolutionImage needs customized spec for methods of Image which it implements In-Reply-To: References: <27615500-F15F-4D58-B715-C8D96D6FD5FE@oracle.com> <9F556132-58E4-4303-81CC-C031C5023A21@oracle.com> Message-ID: <797449A8-4A5B-41A3-8798-FC3B0E2C0C5C@oracle.com> Hi Jim, Just a few queries I have regarding the inputs provided. I have added them inline in red. Thank you for further inputs in advance. > On 24-Aug-2016, at 3:02 am, Jim Graham wrote: > > I wonder why the @throws is not inherited...? > > Another way to fix this would be to implement it in the base Image class with the throw and all classes that can return a graphics override it. Then you wouldn't even need documentation in the AMRI class just to say "never mind we don't provide this method?. AN: According to the bug description as written by the JCK team, they are expecting a custom synopsis for all the overridden methods in the AMRI class. Is this absolutely necessary for the JCK implementation. Is the real reason that a custom documentation required or is the documentation derived not available while creating JCK tests and/or they are not apt descriptions for the JCK tests? Either ways, which way of documentation of the AMRI class seem most appropriate and which requirement mention should be given the right precedence? For example: For the getWidth(ImageObserver observer) method, the description which would have come in a new webrev would have been the following. /** * Returns the width of the base image. If the width is not yet known, * this method returns -1 and the specified * ImageObserver object is notified later. * @param observer an object waiting for the image to be loaded. * @return the width of this image, or -1 * if the width is not yet known. */ Does this look apposite for the AMRI class or does this seem ?too custom? for the worse? > The spec mentions that the method only works for off-screen images. While an AMRI may contain some off-screen images, it is not itself an off-screen so it should mention that. If we choose to list it in the methods in AMRI then I would just copy the entire comment from the super class Image and edit it based on the assumption that it is not supported for off-screen images, something like: > > /** > * This inherited method can only be called for off-screen images, and throws > * an exception in classes like this that do not support it. > * @return there is no return value for a non-off-screen image. > * @exception UnsupportedOperationException since this class does not represent AN: Is there any particular reason we need to use @exception and not @throws? Sorry if it seems like a novice question, but when is either one used and why is @throws not the right tag to use here? > * an off-screen image. > */ > > ...jim > > On 8/23/16 2:28 AM, Alexander Scherbatiy wrote: >> On 22/08/16 11:06, Avik Niyogi wrote: >>> + awt-dev >>> >>> >>>> On 22-Aug-2016, at 12:28 pm, Avik Niyogi > wrote: >>>> >>>> Hi All, >>>> >>>> Kindly review the proposed specifications for JDK9. >>>> >>>> *Bug: https://bugs.openjdk.java.net/browse/JDK-8138771* >>>> >>>> *Webrev: http://cr.openjdk.java.net/~aniyogi/8138771/webrev.00/ >>>> * >>>> >>>> *Issue: *The customised specifications necessitated for getGraphics method did not exist. >>>> So test cases created according to derived specifications would lead to test cases failures. >>>> >>>> *Cause: * No congruous specifications could elicit failure in circumstances not encompassed >>>> in test cases generated without the knowledge of the same. >>>> >>>> *Fix:* Appropriate comprehensive specifications required were added. >> - I am not a native speaker. May be something like this would be better: >> ------ >> /** >> * This method is not supported by {@code AbstractMultiResolutionImage} >> * and always throws {@code UnsupportedOperationException} >> * >> * @return {@code UnsupportedOperationException} is thrown >> * @throws UnsupportedOperationException this method is not supported >> ------ >> >> - others overridden method should have a documentation that they delegate call to the base image (see #getBaseImage) >> >> Thanks, >> Alexandr. >> >>>> >>>> With Regards, >>>> Avik Niyogi >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Wed Aug 24 22:46:03 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 24 Aug 2016 15:46:03 -0700 Subject: [OpenJDK 2D-Dev] 8138771: java.awt.image.AbstractMultiResolutionImage needs customized spec for methods of Image which it implements In-Reply-To: <797449A8-4A5B-41A3-8798-FC3B0E2C0C5C@oracle.com> References: <27615500-F15F-4D58-B715-C8D96D6FD5FE@oracle.com> <9F556132-58E4-4303-81CC-C031C5023A21@oracle.com> <797449A8-4A5B-41A3-8798-FC3B0E2C0C5C@oracle.com> Message-ID: Hi Avik, On 8/23/16 11:43 PM, Avik Niyogi wrote: > Hi Jim, > > Just a few queries I have regarding the inputs provided. I have added them inline in red. Thank you for further inputs > in advance. >> On 24-Aug-2016, at 3:02 am, Jim Graham > wrote: >> >> I wonder why the @throws is not inherited...? >> >> Another way to fix this would be to implement it in the base Image class with the throw and all classes that can >> return a graphics override it. Then you wouldn't even need documentation in the AMRI class just to say "never mind we >> don't provide this method?. > AN: According to the bug description as written by the JCK team, they are expecting a custom synopsis for all > the overridden methods in the AMRI class. Is this absolutely necessary for the JCK implementation. Is the real reason > that a custom documentation required or is the documentation derived not available while creating JCK tests and/or they > are not apt descriptions for the JCK tests? Either ways, which way of documentation of the AMRI class seem most > appropriate and which requirement mention should be given the right precedence? I don't have answers to your questions, I just know that the documentation that was inherited (which seems to have missed inheriting the thrown exceptions) contains no mention of the exception that will be thrown here. I also know that this method is not relevant to this type of image and the fact that we have to override it just to have it choose the escape clause inherent in the spec is silly. We beg the question by having to implement it and then explain that we are implementing it only to assert that it can't be implemented. That's a silly situation that should be instead handled by having the exception be the default implementation on the super class and have only those methods that can implement the behavior override it. If we have a concrete implementation in the base Image class then this method doesn't even appear in the documentation of the AMRI class in the first place (it appears in the list of inherited methods which has the full description). On the other hand, one could argue that the super class method is sort of vague in describing which types of image support the method and which do not. In that case, then I think it makes sense for AMRI to override it just to state its policy on whether one can get a graphics from it. If that is the route we go for this method then I think it makes sense to mention "why" we are throwing the exception rather than simply state that we are throwing it. > For example: > For the getWidth(ImageObserver observer) method, the description which would have come in a new webrev would have been > the following. > > /** > * Returns the width of the base image. If the width is not yet known, > * this method returns -1 and the specified > * ImageObserver object is notified later. > * @param observer an object waiting for the image to be loaded. > * @return the width of this image, or -1 > * if the width is not yet known. > */ > > Does this look apposite for the AMRI class or does this seem ?too custom? for the worse? Note that the AMRI class does provide a width and height so it does need to override these methods. Also, the return values from these methods are special in the case of an AMRI and so the exact behavior needs to be described in these methods (in particular, that the w/h of the base image is used). >> The spec mentions that the method only works for off-screen images. While an AMRI may contain some off-screen images, >> it is not itself an off-screen so it should mention that. If we choose to list it in the methods in AMRI then I would >> just copy the entire comment from the super class Image and edit it based on the assumption that it is not supported >> for off-screen images, something like: >> >> /** >> * This inherited method can only be called for off-screen images, and throws >> * an exception in classes like this that do not support it. >> * @return there is no return value for a non-off-screen image. >> * @exception UnsupportedOperationException since this class does not represent > AN: Is there any particular reason we need to use @exception and not @throws? > Sorry if it seems like a novice question, but when is either one used and why is @throws not the right tag to use here? I just copied and pasted from the source code for the Image.getGraphics() method and it used @exception. They are described as synonyms by the documentation on writing javadocs and I'm not sure whether we prefer one or the other. Phil might know the answer to that... ...jim >> * an off-screen image. >> */ >> >> ...jim From james.graham at oracle.com Wed Aug 24 22:47:39 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 24 Aug 2016 15:47:39 -0700 Subject: [OpenJDK 2D-Dev] [9]Fix for JDK-8158356 : SIGSEGV when attempting to rotate BufferedImage using AffineTransform by NaN degrees In-Reply-To: <962fe847-d042-4254-96a6-c5a53ce00b22@default> References: <57AB9B17.3030709@oracle.com> <3bbfa84f-36ae-69aa-cd07-912d1d1fa181@oracle.com> <57ABA20A.2060403@oracle.com> <962fe847-d042-4254-96a6-c5a53ce00b22@default> Message-ID: <823ab626-2db7-23e3-4f0f-b00aca1b2463@oracle.com> +1 ...jim On 8/24/16 4:41 AM, Ajit Ghaisas wrote: > Hi, > > The root cause of the crash is - NaN is converted to an integer and used as array index in mlib_ImageScanPoly.c. > The native method previously did not check the validity of the input double argument. Now, I have added a check for finite double values. > > If NaN or INF arguments are present in affine transform, the changes done in native code result in ImagingOpException ("Unable to transform src image") in AffineTransformOp.filter() methods. > The constructors in AffineTransformOp.java are left unchanged. > Please note that, this fix fixes the crash. The behavioral change in AffineTransformOp for such inputs will be fixed under JDK-8164729. > > Please review the updated webrev. > http://cr.openjdk.java.net/~aghaisas/8158356/webrev.01/ > > Regards, > Ajit > > -----Original Message----- > From: Philip Race > Sent: Thursday, August 11, 2016 3:22 AM > To: Jim Graham > Cc: Ajit Ghaisas; 2d-dev > Subject: Re: [OpenJDK 2D-Dev] [9]Fix for JDK-8158356 : SIGSEGV when attempting to rotate BufferedImage using AffineTransform by NaN degrees > > Agreed, I had previously asked for that too (off-line). > ie. root cause why a NaN would cause a crash .. > > -phil. > > On 8/10/16, 2:47 PM, Jim Graham wrote: >> This does address the specific test case directly, but I'd be happier >> if we dug down and figured out where it went wrong in trying to >> transform the image and put in a fix that addressed the root problem >> whether it comes from the inputs being NaN or from some other similar >> condition that could also trigger the same poorly written transform >> code... >> >> ...jim >> >> On 8/10/16 2:22 PM, Phil Race wrote: >>> 1) The spec for the constructors needs to be updated to include this >>> reason for throwing ImagingOpException. A CCC request will be needed. >>> >>> 2) The C usage of "isnan()" may be problematic in some compilation >>> environments. >>> For example I believe this will not compile with VS2010, and many >>> folks still use that. >>> Instead you could use matrix[j] != matrix[j] as the two values should >>> not compare equal if it is NaN. >>> >>> -phil. >>> >>> On 08/10/2016 04:15 AM, Ajit Ghaisas wrote: >>>> Hi, >>>> >>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8158356 >>>> >>>> Issue : AffineTransform using NaN value as input parameter >>>> results in SIGSEGV. >>>> >>>> Fix : Transformation matrix is checked for NaN values in >>>> AffineTransformOp.validateTransform(). >>>> Also, at native level a separate check is made to >>>> return error in case of NaN values. >>>> >>>> Webrev : >>>> http://cr.openjdk.java.net/~aghaisas/8158356/webrev.00/ >>>> >>>> Request you to review. >>>> >>>> Regards, >>>> Ajit >>>> >>> From philip.race at oracle.com Thu Aug 25 00:24:52 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 24 Aug 2016 17:24:52 -0700 Subject: [OpenJDK 2D-Dev] [9] Review request for 8163854 Add ToolkitImage.getImage() method which loads an image with schema variant In-Reply-To: <081568bb-c765-0575-f8e7-dc5497b5e7e4@oracle.com> References: <081568bb-c765-0575-f8e7-dc5497b5e7e4@oracle.com> Message-ID: <57BE3AD4.4050802@oracle.com> Alexander, Were the existing Toolkit.getImage(String/URL) APIs not enhanced to do this for you automatically ? I suppose I thought they were but they can't be since you are using getImage(String) here. IMO that would be more important than this. And in any case I don't see why this is solved only for local files. I am *not* asking for that right now. I am asking if the existing Toolkit APIs can load a multi-res image and if not, why not and can we fix that instead .. -phil. On 8/24/16, 9:36 AM, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8163854 > webrev: http://cr.openjdk.java.net/~alexsch/8163854/webrev.00 > > The public API which allows to load an image with resolution > variants based on the provided media resolution naming scheme is added: > - Toolkit.MediaResolutionNamingScheme class > - Toolkit.getImageUsingNamingSchemes(String fileName, > MediaResolutionNamingScheme... namingSchemes) > > A simple example for images which use naming scheme @150pct for > scale 1.5 and @2x for scale 2 is: > image_name.ext > image_name at 150pct.ext > image_name at 2x.ext > > Toolkit toolkit = Toolkit.getDefaultToolkit(); > Image image = toolkit.getImageUsingNamingSchemes(fileName, > new Toolkit.MediaResolutionNamingScheme(?@150pct?, 1.5f), > new Toolkit.MediaResolutionNamingScheme(?@2x", 2f) > ); > > Thanks, > Alexandr. > From philip.race at oracle.com Thu Aug 25 01:39:59 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 24 Aug 2016 18:39:59 -0700 Subject: [OpenJDK 2D-Dev] [9] Review request for 8163854 Add ToolkitImage.getImage() method which loads an image with schema variant In-Reply-To: <57BE3AD4.4050802@oracle.com> References: <081568bb-c765-0575-f8e7-dc5497b5e7e4@oracle.com> <57BE3AD4.4050802@oracle.com> Message-ID: <57BE4C6F.6030007@oracle.com> FWIW I think the most important image loading use case is that some generic resource loading code - perhaps JDK code - will get a URL for where the resources are and go hunting. It is never going to call this API .. so it had better be an optimisation and not a necessity -phil. On 8/24/16, 5:24 PM, Philip Race wrote: > Alexander, > > Were the existing Toolkit.getImage(String/URL) APIs not enhanced to > do this for you automatically ? I suppose I thought they were but > they can't be since you are using getImage(String) here. > > IMO that would be more important than this. > > And in any case I don't see why this is solved only for local files. > > I am *not* asking for that right now. I am asking if the existing > Toolkit APIs > can load a multi-res image and if not, why not and can we fix that > instead .. > > -phil. > > On 8/24/16, 9:36 AM, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8163854 >> webrev: http://cr.openjdk.java.net/~alexsch/8163854/webrev.00 >> >> The public API which allows to load an image with resolution >> variants based on the provided media resolution naming scheme is added: >> - Toolkit.MediaResolutionNamingScheme class >> - Toolkit.getImageUsingNamingSchemes(String fileName, >> MediaResolutionNamingScheme... namingSchemes) >> >> A simple example for images which use naming scheme @150pct for >> scale 1.5 and @2x for scale 2 is: >> image_name.ext >> image_name at 150pct.ext >> image_name at 2x.ext >> >> Toolkit toolkit = Toolkit.getDefaultToolkit(); >> Image image = toolkit.getImageUsingNamingSchemes(fileName, >> new Toolkit.MediaResolutionNamingScheme(?@150pct?, 1.5f), >> new Toolkit.MediaResolutionNamingScheme(?@2x", 2f) >> ); >> >> Thanks, >> Alexandr. >> From prasanta.sadhukhan at oracle.com Thu Aug 25 06:27:25 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 25 Aug 2016 11:57:25 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6357887: selected printertray is ignored under linux In-Reply-To: <7d08d76c-a335-8d63-dd80-beb567920578@oracle.com> References: <57AAECFD.2030802@oracle.com> <57B48517.3030200@oracle.com> <57B5588D.1050909@oracle.com> <57B63160.80908@oracle.com> <57B6A536.8050106@oracle.com> <7d08d76c-a335-8d63-dd80-beb567920578@oracle.com> Message-ID: <57BE8FCD.9010800@oracle.com> Thanks Phil for the comments. Modified webrev: http://cr.openjdk.java.net/~psadhukhan/6357887/webrev.02/ Regards Prasanta On 8/25/2016 12:05 AM, Phil Race wrote: > In fact what you should be doing here is > Attribute attr = attrs.get(Media.class); > if (attr instanceof CustomMediaTray) .... > > The program below should show that the lookup works so long as the key > is the class understood by the API - not a sub-type. > > -phil. > import javax.print.*; > import javax.print.attribute.*; > import javax.print.attribute.standard.*; > > public class CMT { > > public static void main(String args[]) throws Exception { > > PrintService svc = > PrintServiceLookup.lookupPrintServices(null,null)[0]; > Media[] allMedia = > (Media[])svc.getSupportedAttributeValues(Media.class, null, > null); > PrintRequestAttributeSet aset = new HashPrintRequestAttributeSet(); > for (int m=0;m Media in = allMedia[m]; > aset.add(in); > Media out1 = (Media)aset.get(Media.class); > System.out.println("Class="+in.getClass()+" in="+in+ " > out="+out1); > Media out2 = (Media)aset.get(in.getClass()); > System.out.println("Class="+in.getClass()+" in="+in+ " > out="+out2); > } > } > > > > On 8/18/2016 11:20 PM, Prasanta Sadhukhan wrote: >> >> >> On 8/19/2016 3:36 AM, Philip Race wrote: >>> Oh .. right under the covers the map is just a HashMap >>> and the key to the map is the class so just decides if these are >>> equal class objects. Hmm .. I don't know anymore if that was the >>> original intent >>> but we probably should not mess with it right now just for the >>> optimisation. >>> But now I am wondering why it has to be CustomMediaTray and not just >>> MediaTray ... although I suspect that in the case of CUPS we are not >>> ever mapping the media to standard ones, so they are always custom. >> Yes, in CUPS >> http://hg.openjdk.java.net/jdk9/client/jdk/file/9f38d4f86e3d/src/java.desktop/unix/classes/sun/print/CUPSPrinter.java#l254 >> we instantiate CustomMediaTray (and do not map to standard) so I need >> to check for CustomMediatray to get the tray instance. >> >> Regards >> Prasanta >>> That might be arise as a problem in the case of your other open >>> review regarding >>> validating the margins. I'll comment on that in that review but >>> still surely >>> any MediaTray is what you would want here but it is probably moot if >>> you don't ever get a standard one. Please check into this and confirm >>> what I suspect .. or not ... >>> >>> -phil. >>> >>> On 8/17/16, 11:41 PM, Prasanta Sadhukhan wrote: >>>> MediaTray values are bundled with "Media" attribute so calling >>>> attributes.get(CustomMediatray.class) returns null. >>>> Modified webrev to get Media attribute and then see if the >>>> attribute is an instance of CustomMediatray. >>>> >>>> http://cr.openjdk.java.net/~psadhukhan/6357887/webrev.01/ >>>> >>>> Regards >>>> Prasanta >>>> On 8/17/2016 9:09 PM, Philip Race wrote: >>>>> This all looks fine although this can be a simple call to >>>>> attributes.get(CustomMediaTray.class) can't it ? >>>>> >>>>> 502 for (int i=0; i< attrs.length; i++) { >>>>> 503 Attribute attr = attrs[i]; >>>>> 504 try { >>>>> 505 if (attr instanceof CustomMediaTray) { >>>>> 506 CustomMediaTray customTray = >>>>> (CustomMediaTray)attr; >>>>> 507 mOptions = " InputSlot="+ >>>>> customTray.getChoiceName(); >>>>> 508 } >>>>> 509 } catch (ClassCastException e) { >>>>> >>>>> -phil. >>>>> >>>>> On 8/10/16, 1:59 AM, Prasanta Sadhukhan wrote: >>>>>> Hi All, >>>>>> >>>>>> Please review a fix for an issue where it is seen that the >>>>>> selected printer tray is ignored in linux and default standard >>>>>> tray is used for printing. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6357887 >>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6357887/webrev.00/ >>>>>> >>>>>> Issue was lpr command needs "-o InputSlot=" to select >>>>>> the printertray which was not being passed to lpr command. >>>>>> Proposed fix added InputSlot option to lpr command to select the >>>>>> printertray. >>>>>> >>>>>> Tested in ubuntu and solaris11. >>>>>> >>>>>> Regards >>>>>> Prasanta >>>> >> > From jayathirth.d.v at oracle.com Thu Aug 25 10:18:05 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 25 Aug 2016 03:18:05 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8154218: Non-usage of owner Frame when Frame object is passed to getPrintJob() In-Reply-To: <57BDD066.1020803@oracle.com> References: <57BD797D.4060801@oracle.com> <57BDD066.1020803@oracle.com> Message-ID: <8d20b03c-73fb-4faf-a05b-c6075223c7ff@default> Hi Prasanta, Changes are working fine. Before pushing please make sure that in test case we have maximum 80 characters per line. Thanks, Jay -----Original Message----- From: Philip Race Sent: Wednesday, August 24, 2016 10:21 PM To: Prasanta Sadhukhan Cc: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-8154218: Non-usage of owner Frame when Frame object is passed to getPrintJob() +1 Some day we should still consider an API that lets the application pass in an owner. -phil. On 8/24/16, 3:39 AM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix for an issue where it is seen that the Frame > object passed to Toolkit.getPrintJob() is not used when cross platform > print dialog is created, so the print dialog does not have an owner > Frame and therefore if the parent frame is disposed, the print dialog > is not affected. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154218 > webrev: http://cr.openjdk.java.net/~psadhukhan/8154218/webrev.00/ > > Proposed fix is to get the DialogOwner attribute which has been set > in PrintJob2D.printDialog() and use the returned frame object as owner. > As of now, null is explicitly passed as owner argument. > > Regards > Prasanta From prasanta.sadhukhan at oracle.com Thu Aug 25 10:40:46 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 25 Aug 2016 16:10:46 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-7064425: PageFormat Dialog has no owner window to reactivate Message-ID: <57BECB2E.4030102@oracle.com> Hi All, Please review a fix for jdk9 for an issue where it is seen that PageDialog and PrintDialog is not associated with the owner Frame that spawns the dialog. Bug: https://bugs.openjdk.java.net/browse/JDK-7064425 webrev: http://cr.openjdk.java.net/~psadhukhan/7064425/webrev.00/ The issue was there we explicitly pass null as owner to ServiceDialog in pageDialog(attributes). Proposed fix is to get the owner window, if pageDialog is called before calling printDialog, the window will be a Frame else the owner window will be ServiceDialog and pass this owner window to ServiceDialog instead of null. For PrintDialog, the proposed fix is to set an attribute with DialogOwner so that ServiceUI dialog can parse that attribute and can use the owner window as parent of the dialaog, Regards Prasanta From philip.race at oracle.com Thu Aug 25 13:25:38 2016 From: philip.race at oracle.com (Philip Race) Date: Thu, 25 Aug 2016 06:25:38 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6357887: selected printertray is ignored under linux In-Reply-To: <57BE8FCD.9010800@oracle.com> References: <57AAECFD.2030802@oracle.com> <57B48517.3030200@oracle.com> <57B5588D.1050909@oracle.com> <57B63160.80908@oracle.com> <57B6A536.8050106@oracle.com> <7d08d76c-a335-8d63-dd80-beb567920578@oracle.com> <57BE8FCD.9010800@oracle.com> Message-ID: <57BEF1D2.20004@oracle.com> +1 -phil On 8/24/16, 11:27 PM, Prasanta Sadhukhan wrote: > Thanks Phil for the comments. > Modified webrev: > http://cr.openjdk.java.net/~psadhukhan/6357887/webrev.02/ > > Regards > Prasanta > On 8/25/2016 12:05 AM, Phil Race wrote: >> In fact what you should be doing here is >> Attribute attr = attrs.get(Media.class); >> if (attr instanceof CustomMediaTray) .... >> >> The program below should show that the lookup works so long as the key >> is the class understood by the API - not a sub-type. >> >> -phil. >> import javax.print.*; >> import javax.print.attribute.*; >> import javax.print.attribute.standard.*; >> >> public class CMT { >> >> public static void main(String args[]) throws Exception { >> >> PrintService svc = >> PrintServiceLookup.lookupPrintServices(null,null)[0]; >> Media[] allMedia = >> (Media[])svc.getSupportedAttributeValues(Media.class, null, >> null); >> PrintRequestAttributeSet aset = new >> HashPrintRequestAttributeSet(); >> for (int m=0;m> Media in = allMedia[m]; >> aset.add(in); >> Media out1 = (Media)aset.get(Media.class); >> System.out.println("Class="+in.getClass()+" in="+in+ " >> out="+out1); >> Media out2 = (Media)aset.get(in.getClass()); >> System.out.println("Class="+in.getClass()+" in="+in+ " >> out="+out2); >> } >> } >> >> >> >> On 8/18/2016 11:20 PM, Prasanta Sadhukhan wrote: >>> >>> >>> On 8/19/2016 3:36 AM, Philip Race wrote: >>>> Oh .. right under the covers the map is just a HashMap >>>> and the key to the map is the class so just decides if these are >>>> equal class objects. Hmm .. I don't know anymore if that was the >>>> original intent >>>> but we probably should not mess with it right now just for the >>>> optimisation. >>>> But now I am wondering why it has to be CustomMediaTray and not just >>>> MediaTray ... although I suspect that in the case of CUPS we are not >>>> ever mapping the media to standard ones, so they are always custom. >>> Yes, in CUPS >>> http://hg.openjdk.java.net/jdk9/client/jdk/file/9f38d4f86e3d/src/java.desktop/unix/classes/sun/print/CUPSPrinter.java#l254 >>> we instantiate CustomMediaTray (and do not map to standard) so I >>> need to check for CustomMediatray to get the tray instance. >>> >>> Regards >>> Prasanta >>>> That might be arise as a problem in the case of your other open >>>> review regarding >>>> validating the margins. I'll comment on that in that review but >>>> still surely >>>> any MediaTray is what you would want here but it is probably moot if >>>> you don't ever get a standard one. Please check into this and confirm >>>> what I suspect .. or not ... >>>> >>>> -phil. >>>> >>>> On 8/17/16, 11:41 PM, Prasanta Sadhukhan wrote: >>>>> MediaTray values are bundled with "Media" attribute so calling >>>>> attributes.get(CustomMediatray.class) returns null. >>>>> Modified webrev to get Media attribute and then see if the >>>>> attribute is an instance of CustomMediatray. >>>>> >>>>> http://cr.openjdk.java.net/~psadhukhan/6357887/webrev.01/ >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 8/17/2016 9:09 PM, Philip Race wrote: >>>>>> This all looks fine although this can be a simple call to >>>>>> attributes.get(CustomMediaTray.class) can't it ? >>>>>> >>>>>> 502 for (int i=0; i< attrs.length; i++) { >>>>>> 503 Attribute attr = attrs[i]; >>>>>> 504 try { >>>>>> 505 if (attr instanceof CustomMediaTray) { >>>>>> 506 CustomMediaTray customTray = >>>>>> (CustomMediaTray)attr; >>>>>> 507 mOptions = " InputSlot="+ >>>>>> customTray.getChoiceName(); >>>>>> 508 } >>>>>> 509 } catch (ClassCastException e) { >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 8/10/16, 1:59 AM, Prasanta Sadhukhan wrote: >>>>>>> Hi All, >>>>>>> >>>>>>> Please review a fix for an issue where it is seen that the >>>>>>> selected printer tray is ignored in linux and default standard >>>>>>> tray is used for printing. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6357887 >>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6357887/webrev.00/ >>>>>>> >>>>>>> Issue was lpr command needs "-o InputSlot=" to select >>>>>>> the printertray which was not being passed to lpr command. >>>>>>> Proposed fix added InputSlot option to lpr command to select the >>>>>>> printertray. >>>>>>> >>>>>>> Tested in ubuntu and solaris11. >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>> >>> >> > From goetz.lindenmaier at sap.com Thu Aug 25 13:42:37 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 25 Aug 2016 13:42:37 +0000 Subject: [OpenJDK 2D-Dev] RFR(XS): 8161923: Fix free in awt_PrintControl. Message-ID: Hi, Could I please get a review for this tiny fix? http://cr.openjdk.java.net/~goetz/wr16/8161923-jdkMem/webrev.03/ Best regards, Goetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vadim.pakhnushev at oracle.com Thu Aug 25 13:53:34 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Thu, 25 Aug 2016 16:53:34 +0300 Subject: [OpenJDK 2D-Dev] RFR(XS): 8161923: Fix free in awt_PrintControl. In-Reply-To: References: Message-ID: <7f511416-76a1-cc09-0c7b-a1d64945a6e9@oracle.com> Looks good. Vadim On 25.08.2016 16:42, Lindenmaier, Goetz wrote: > > Hi, > > Could I please get a review for this tiny fix? > > http://cr.openjdk.java.net/~goetz/wr16/8161923-jdkMem/webrev.03/ > > > Best regards, > > Goetz. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vadim.pakhnushev at oracle.com Thu Aug 25 13:59:31 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Thu, 25 Aug 2016 16:59:31 +0300 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6357887: selected printertray is ignored under linux In-Reply-To: <57BEF1D2.20004@oracle.com> References: <57AAECFD.2030802@oracle.com> <57B48517.3030200@oracle.com> <57B5588D.1050909@oracle.com> <57B63160.80908@oracle.com> <57B6A536.8050106@oracle.com> <7d08d76c-a335-8d63-dd80-beb567920578@oracle.com> <57BE8FCD.9010800@oracle.com> <57BEF1D2.20004@oracle.com> Message-ID: <9c402c80-c5eb-898f-e2ca-54cb804f6513@oracle.com> In the PSPrinterJob.java customTray.getChoiceName() is not checked for null but in the UnixPrintJob it is checked. Could this be a problem? The getMediaTray method in the test could be simplified to for (Media m : media) { if (m instanceof MediaTray) { if (m.toString().trim()...) { return (MediaTray)m; } } } return null; Vadim On 25.08.2016 16:25, Philip Race wrote: > +1 > > -phil > > On 8/24/16, 11:27 PM, Prasanta Sadhukhan wrote: >> Thanks Phil for the comments. >> Modified webrev: >> http://cr.openjdk.java.net/~psadhukhan/6357887/webrev.02/ >> >> Regards >> Prasanta >> On 8/25/2016 12:05 AM, Phil Race wrote: >>> In fact what you should be doing here is >>> Attribute attr = attrs.get(Media.class); >>> if (attr instanceof CustomMediaTray) .... >>> >>> The program below should show that the lookup works so long as the key >>> is the class understood by the API - not a sub-type. >>> >>> -phil. >>> import javax.print.*; >>> import javax.print.attribute.*; >>> import javax.print.attribute.standard.*; >>> >>> public class CMT { >>> >>> public static void main(String args[]) throws Exception { >>> >>> PrintService svc = >>> PrintServiceLookup.lookupPrintServices(null,null)[0]; >>> Media[] allMedia = >>> (Media[])svc.getSupportedAttributeValues(Media.class, null, >>> null); >>> PrintRequestAttributeSet aset = new >>> HashPrintRequestAttributeSet(); >>> for (int m=0;m>> Media in = allMedia[m]; >>> aset.add(in); >>> Media out1 = (Media)aset.get(Media.class); >>> System.out.println("Class="+in.getClass()+" in="+in+ " >>> out="+out1); >>> Media out2 = (Media)aset.get(in.getClass()); >>> System.out.println("Class="+in.getClass()+" in="+in+ " >>> out="+out2); >>> } >>> } >>> >>> >>> >>> On 8/18/2016 11:20 PM, Prasanta Sadhukhan wrote: >>>> >>>> >>>> On 8/19/2016 3:36 AM, Philip Race wrote: >>>>> Oh .. right under the covers the map is just a HashMap >>>>> and the key to the map is the class so just decides if these are >>>>> equal class objects. Hmm .. I don't know anymore if that was the >>>>> original intent >>>>> but we probably should not mess with it right now just for the >>>>> optimisation. >>>>> But now I am wondering why it has to be CustomMediaTray and not just >>>>> MediaTray ... although I suspect that in the case of CUPS we are not >>>>> ever mapping the media to standard ones, so they are always custom. >>>> Yes, in CUPS >>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/9f38d4f86e3d/src/java.desktop/unix/classes/sun/print/CUPSPrinter.java#l254 >>>> we instantiate CustomMediaTray (and do not map to standard) so I >>>> need to check for CustomMediatray to get the tray instance. >>>> >>>> Regards >>>> Prasanta >>>>> That might be arise as a problem in the case of your other open >>>>> review regarding >>>>> validating the margins. I'll comment on that in that review but >>>>> still surely >>>>> any MediaTray is what you would want here but it is probably moot if >>>>> you don't ever get a standard one. Please check into this and confirm >>>>> what I suspect .. or not ... >>>>> >>>>> -phil. >>>>> >>>>> On 8/17/16, 11:41 PM, Prasanta Sadhukhan wrote: >>>>>> MediaTray values are bundled with "Media" attribute so calling >>>>>> attributes.get(CustomMediatray.class) returns null. >>>>>> Modified webrev to get Media attribute and then see if the >>>>>> attribute is an instance of CustomMediatray. >>>>>> >>>>>> http://cr.openjdk.java.net/~psadhukhan/6357887/webrev.01/ >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> On 8/17/2016 9:09 PM, Philip Race wrote: >>>>>>> This all looks fine although this can be a simple call to >>>>>>> attributes.get(CustomMediaTray.class) can't it ? >>>>>>> >>>>>>> 502 for (int i=0; i< attrs.length; i++) { >>>>>>> 503 Attribute attr = attrs[i]; >>>>>>> 504 try { >>>>>>> 505 if (attr instanceof CustomMediaTray) { >>>>>>> 506 CustomMediaTray customTray = >>>>>>> (CustomMediaTray)attr; >>>>>>> 507 mOptions = " InputSlot="+ >>>>>>> customTray.getChoiceName(); >>>>>>> 508 } >>>>>>> 509 } catch (ClassCastException e) { >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 8/10/16, 1:59 AM, Prasanta Sadhukhan wrote: >>>>>>>> Hi All, >>>>>>>> >>>>>>>> Please review a fix for an issue where it is seen that the >>>>>>>> selected printer tray is ignored in linux and default standard >>>>>>>> tray is used for printing. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6357887 >>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6357887/webrev.00/ >>>>>>>> >>>>>>>> Issue was lpr command needs "-o InputSlot=" to select >>>>>>>> the printertray which was not being passed to lpr command. >>>>>>>> Proposed fix added InputSlot option to lpr command to select >>>>>>>> the printertray. >>>>>>>> >>>>>>>> Tested in ubuntu and solaris11. >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>> >>>> >>> >> From prasanta.sadhukhan at oracle.com Thu Aug 25 15:42:46 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 25 Aug 2016 21:12:46 +0530 Subject: [OpenJDK 2D-Dev] RFR(XS): 8161923: Fix free in awt_PrintControl. In-Reply-To: References: Message-ID: <57BF11F6.7020206@oracle.com> +1 Regards Prasanta On 8/25/2016 7:12 PM, Lindenmaier, Goetz wrote: > > Hi, > > Could I please get a review for this tiny fix? > > http://cr.openjdk.java.net/~goetz/wr16/8161923-jdkMem/webrev.03/ > > > Best regards, > > Goetz. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Aug 25 15:46:39 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 25 Aug 2016 08:46:39 -0700 Subject: [OpenJDK 2D-Dev] RFR(XS): 8161923: Fix free in awt_PrintControl. In-Reply-To: <7f511416-76a1-cc09-0c7b-a1d64945a6e9@oracle.com> References: <7f511416-76a1-cc09-0c7b-a1d64945a6e9@oracle.com> Message-ID: <57BF12DF.7080905@oracle.com> +1 -phil. On 08/25/2016 06:53 AM, Vadim Pakhnushev wrote: > Looks good. > > Vadim > > On 25.08.2016 16:42, Lindenmaier, Goetz wrote: >> >> Hi, >> >> Could I please get a review for this tiny fix? >> >> http://cr.openjdk.java.net/~goetz/wr16/8161923-jdkMem/webrev.03/ >> >> >> Best regards, >> >> Goetz. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Thu Aug 25 16:14:18 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 25 Aug 2016 21:44:18 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6357887: selected printertray is ignored under linux In-Reply-To: <9c402c80-c5eb-898f-e2ca-54cb804f6513@oracle.com> References: <57AAECFD.2030802@oracle.com> <57B48517.3030200@oracle.com> <57B5588D.1050909@oracle.com> <57B63160.80908@oracle.com> <57B6A536.8050106@oracle.com> <7d08d76c-a335-8d63-dd80-beb567920578@oracle.com> <57BE8FCD.9010800@oracle.com> <57BEF1D2.20004@oracle.com> <9c402c80-c5eb-898f-e2ca-54cb804f6513@oracle.com> Message-ID: <57BF195A.4030500@oracle.com> On 8/25/2016 7:29 PM, Vadim Pakhnushev wrote: > In the PSPrinterJob.java customTray.getChoiceName() is not checked for > null but in the UnixPrintJob it is checked. > Could this be a problem? > Checked for null just to be safe and simplified test method Modified webrev http://cr.openjdk.java.net/~psadhukhan/6357887/webrev.03/ Regards Prasanta > The getMediaTray method in the test could be simplified to > for (Media m : media) { > if (m instanceof MediaTray) { > if (m.toString().trim()...) { > return (MediaTray)m; > } > } > } > return null; > > Vadim > > On 25.08.2016 16:25, Philip Race wrote: >> +1 >> >> -phil >> >> On 8/24/16, 11:27 PM, Prasanta Sadhukhan wrote: >>> Thanks Phil for the comments. >>> Modified webrev: >>> http://cr.openjdk.java.net/~psadhukhan/6357887/webrev.02/ >>> >>> Regards >>> Prasanta >>> On 8/25/2016 12:05 AM, Phil Race wrote: >>>> In fact what you should be doing here is >>>> Attribute attr = attrs.get(Media.class); >>>> if (attr instanceof CustomMediaTray) .... >>>> >>>> The program below should show that the lookup works so long as the key >>>> is the class understood by the API - not a sub-type. >>>> >>>> -phil. >>>> import javax.print.*; >>>> import javax.print.attribute.*; >>>> import javax.print.attribute.standard.*; >>>> >>>> public class CMT { >>>> >>>> public static void main(String args[]) throws Exception { >>>> >>>> PrintService svc = >>>> PrintServiceLookup.lookupPrintServices(null,null)[0]; >>>> Media[] allMedia = >>>> (Media[])svc.getSupportedAttributeValues(Media.class, null, null); >>>> PrintRequestAttributeSet aset = new >>>> HashPrintRequestAttributeSet(); >>>> for (int m=0;m>>> Media in = allMedia[m]; >>>> aset.add(in); >>>> Media out1 = (Media)aset.get(Media.class); >>>> System.out.println("Class="+in.getClass()+" in="+in+ " >>>> out="+out1); >>>> Media out2 = (Media)aset.get(in.getClass()); >>>> System.out.println("Class="+in.getClass()+" in="+in+ " >>>> out="+out2); >>>> } >>>> } >>>> >>>> >>>> >>>> On 8/18/2016 11:20 PM, Prasanta Sadhukhan wrote: >>>>> >>>>> >>>>> On 8/19/2016 3:36 AM, Philip Race wrote: >>>>>> Oh .. right under the covers the map is just a HashMap >>>>>> and the key to the map is the class so just decides if these are >>>>>> equal class objects. Hmm .. I don't know anymore if that was the >>>>>> original intent >>>>>> but we probably should not mess with it right now just for the >>>>>> optimisation. >>>>>> But now I am wondering why it has to be CustomMediaTray and not just >>>>>> MediaTray ... although I suspect that in the case of CUPS we are not >>>>>> ever mapping the media to standard ones, so they are always custom. >>>>> Yes, in CUPS >>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/9f38d4f86e3d/src/java.desktop/unix/classes/sun/print/CUPSPrinter.java#l254 >>>>> we instantiate CustomMediaTray (and do not map to standard) so I >>>>> need to check for CustomMediatray to get the tray instance. >>>>> >>>>> Regards >>>>> Prasanta >>>>>> That might be arise as a problem in the case of your other open >>>>>> review regarding >>>>>> validating the margins. I'll comment on that in that review but >>>>>> still surely >>>>>> any MediaTray is what you would want here but it is probably moot if >>>>>> you don't ever get a standard one. Please check into this and >>>>>> confirm >>>>>> what I suspect .. or not ... >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 8/17/16, 11:41 PM, Prasanta Sadhukhan wrote: >>>>>>> MediaTray values are bundled with "Media" attribute so calling >>>>>>> attributes.get(CustomMediatray.class) returns null. >>>>>>> Modified webrev to get Media attribute and then see if the >>>>>>> attribute is an instance of CustomMediatray. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~psadhukhan/6357887/webrev.01/ >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>> On 8/17/2016 9:09 PM, Philip Race wrote: >>>>>>>> This all looks fine although this can be a simple call to >>>>>>>> attributes.get(CustomMediaTray.class) can't it ? >>>>>>>> >>>>>>>> 502 for (int i=0; i< attrs.length; i++) { >>>>>>>> 503 Attribute attr = attrs[i]; >>>>>>>> 504 try { >>>>>>>> 505 if (attr instanceof CustomMediaTray) { >>>>>>>> 506 CustomMediaTray customTray = >>>>>>>> (CustomMediaTray)attr; >>>>>>>> 507 mOptions = " InputSlot="+ >>>>>>>> customTray.getChoiceName(); >>>>>>>> 508 } >>>>>>>> 509 } catch (ClassCastException e) { >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> On 8/10/16, 1:59 AM, Prasanta Sadhukhan wrote: >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> Please review a fix for an issue where it is seen that the >>>>>>>>> selected printer tray is ignored in linux and default standard >>>>>>>>> tray is used for printing. >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6357887 >>>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6357887/webrev.00/ >>>>>>>>> >>>>>>>>> Issue was lpr command needs "-o InputSlot=" to >>>>>>>>> select the printertray which was not being passed to lpr command. >>>>>>>>> Proposed fix added InputSlot option to lpr command to select >>>>>>>>> the printertray. >>>>>>>>> >>>>>>>>> Tested in ubuntu and solaris11. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Prasanta >>>>>>> >>>>> >>>> >>> > From vadim.pakhnushev at oracle.com Thu Aug 25 17:14:52 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Thu, 25 Aug 2016 20:14:52 +0300 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6357887: selected printertray is ignored under linux In-Reply-To: <57BF195A.4030500@oracle.com> References: <57AAECFD.2030802@oracle.com> <57B48517.3030200@oracle.com> <57B5588D.1050909@oracle.com> <57B63160.80908@oracle.com> <57B6A536.8050106@oracle.com> <7d08d76c-a335-8d63-dd80-beb567920578@oracle.com> <57BE8FCD.9010800@oracle.com> <57BEF1D2.20004@oracle.com> <9c402c80-c5eb-898f-e2ca-54cb804f6513@oracle.com> <57BF195A.4030500@oracle.com> Message-ID: <8669d23b-94f4-ecc2-f672-2fb84d4609f6@oracle.com> You see, you now have 102 MediaTray mt = null; 114 return( mt); This can be just return null; No need for new webrev for that, +1. Vadim On 25.08.2016 19:14, Prasanta Sadhukhan wrote: > > > On 8/25/2016 7:29 PM, Vadim Pakhnushev wrote: >> In the PSPrinterJob.java customTray.getChoiceName() is not checked >> for null but in the UnixPrintJob it is checked. >> Could this be a problem? >> > Checked for null just to be safe and simplified test method > Modified webrev > http://cr.openjdk.java.net/~psadhukhan/6357887/webrev.03/ > > Regards > Prasanta >> The getMediaTray method in the test could be simplified to >> for (Media m : media) { >> if (m instanceof MediaTray) { >> if (m.toString().trim()...) { >> return (MediaTray)m; >> } >> } >> } >> return null; >> >> Vadim >> >> On 25.08.2016 16:25, Philip Race wrote: >>> +1 >>> >>> -phil >>> >>> On 8/24/16, 11:27 PM, Prasanta Sadhukhan wrote: >>>> Thanks Phil for the comments. >>>> Modified webrev: >>>> http://cr.openjdk.java.net/~psadhukhan/6357887/webrev.02/ >>>> >>>> Regards >>>> Prasanta >>>> On 8/25/2016 12:05 AM, Phil Race wrote: >>>>> In fact what you should be doing here is >>>>> Attribute attr = attrs.get(Media.class); >>>>> if (attr instanceof CustomMediaTray) .... >>>>> >>>>> The program below should show that the lookup works so long as the >>>>> key >>>>> is the class understood by the API - not a sub-type. >>>>> >>>>> -phil. >>>>> import javax.print.*; >>>>> import javax.print.attribute.*; >>>>> import javax.print.attribute.standard.*; >>>>> >>>>> public class CMT { >>>>> >>>>> public static void main(String args[]) throws Exception { >>>>> >>>>> PrintService svc = >>>>> PrintServiceLookup.lookupPrintServices(null,null)[0]; >>>>> Media[] allMedia = >>>>> (Media[])svc.getSupportedAttributeValues(Media.class, null, null); >>>>> PrintRequestAttributeSet aset = new >>>>> HashPrintRequestAttributeSet(); >>>>> for (int m=0;m>>>> Media in = allMedia[m]; >>>>> aset.add(in); >>>>> Media out1 = (Media)aset.get(Media.class); >>>>> System.out.println("Class="+in.getClass()+" in="+in+ " >>>>> out="+out1); >>>>> Media out2 = (Media)aset.get(in.getClass()); >>>>> System.out.println("Class="+in.getClass()+" in="+in+ " >>>>> out="+out2); >>>>> } >>>>> } >>>>> >>>>> >>>>> >>>>> On 8/18/2016 11:20 PM, Prasanta Sadhukhan wrote: >>>>>> >>>>>> >>>>>> On 8/19/2016 3:36 AM, Philip Race wrote: >>>>>>> Oh .. right under the covers the map is just a HashMap >>>>>>> and the key to the map is the class so just decides if these are >>>>>>> equal class objects. Hmm .. I don't know anymore if that was the >>>>>>> original intent >>>>>>> but we probably should not mess with it right now just for the >>>>>>> optimisation. >>>>>>> But now I am wondering why it has to be CustomMediaTray and not >>>>>>> just >>>>>>> MediaTray ... although I suspect that in the case of CUPS we are >>>>>>> not >>>>>>> ever mapping the media to standard ones, so they are always custom. >>>>>> Yes, in CUPS >>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/9f38d4f86e3d/src/java.desktop/unix/classes/sun/print/CUPSPrinter.java#l254 >>>>>> we instantiate CustomMediaTray (and do not map to standard) so I >>>>>> need to check for CustomMediatray to get the tray instance. >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>>> That might be arise as a problem in the case of your other open >>>>>>> review regarding >>>>>>> validating the margins. I'll comment on that in that review but >>>>>>> still surely >>>>>>> any MediaTray is what you would want here but it is probably >>>>>>> moot if >>>>>>> you don't ever get a standard one. Please check into this and >>>>>>> confirm >>>>>>> what I suspect .. or not ... >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 8/17/16, 11:41 PM, Prasanta Sadhukhan wrote: >>>>>>>> MediaTray values are bundled with "Media" attribute so calling >>>>>>>> attributes.get(CustomMediatray.class) returns null. >>>>>>>> Modified webrev to get Media attribute and then see if the >>>>>>>> attribute is an instance of CustomMediatray. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~psadhukhan/6357887/webrev.01/ >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>>> On 8/17/2016 9:09 PM, Philip Race wrote: >>>>>>>>> This all looks fine although this can be a simple call to >>>>>>>>> attributes.get(CustomMediaTray.class) can't it ? >>>>>>>>> >>>>>>>>> 502 for (int i=0; i< attrs.length; i++) { >>>>>>>>> 503 Attribute attr = attrs[i]; >>>>>>>>> 504 try { >>>>>>>>> 505 if (attr instanceof CustomMediaTray) { >>>>>>>>> 506 CustomMediaTray customTray = >>>>>>>>> (CustomMediaTray)attr; >>>>>>>>> 507 mOptions = " InputSlot="+ >>>>>>>>> customTray.getChoiceName(); >>>>>>>>> 508 } >>>>>>>>> 509 } catch (ClassCastException e) { >>>>>>>>> >>>>>>>>> -phil. >>>>>>>>> >>>>>>>>> On 8/10/16, 1:59 AM, Prasanta Sadhukhan wrote: >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> Please review a fix for an issue where it is seen that the >>>>>>>>>> selected printer tray is ignored in linux and default >>>>>>>>>> standard tray is used for printing. >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6357887 >>>>>>>>>> webrev: >>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/6357887/webrev.00/ >>>>>>>>>> >>>>>>>>>> Issue was lpr command needs "-o InputSlot=" to >>>>>>>>>> select the printertray which was not being passed to lpr >>>>>>>>>> command. >>>>>>>>>> Proposed fix added InputSlot option to lpr command to select >>>>>>>>>> the printertray. >>>>>>>>>> >>>>>>>>>> Tested in ubuntu and solaris11. >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Prasanta >>>>>>>> >>>>>> >>>>> >>>> >> > From philip.race at oracle.com Thu Aug 25 21:10:39 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 25 Aug 2016 14:10:39 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8144015: [PIT] failures of text layout font tests Message-ID: <57BF5ECF.2010800@oracle.com> Webrev: http://cr.openjdk.java.net/~prr/8144015/ This RFR encompasses changes that are sufficiently related to keep them all together and they deserve testing as a whole. Multiple test failures are resolved. A list is below. Notable highlights ExtendedTextSourceLabel.createCharinfo() can now handle cases where the glyph count is less than the char count. This was not just a problem in 9 (harfbuzz) but has been observed on 8 too (8041480 in the list below). The fundamental change is to abandon the idea of updating in place which added complexity and was never going to work if you had too few glyphs .. HBShaper.c - Fixed that kerning was always enabled - Simplified - and corrected - the code that stored the resulting data - Stopped using throwing an exception as a way to expand storage - Cleaned up JNI usage Tests have been added/updated/open sourced as necessary. JPRT passed these changes. Bugs fixed by this change : https://bugs.openjdk.java.net/browse/JDK-8144015 8144015: [PIT] failures of text layout font tests ** https://bugs.openjdk.java.net/browse/JDK-8144023 8144023: [PIT] failure of text measurements in javax/swing/text/html/parser/Parser/6836089/bug6836089.java ** https://bugs.openjdk.java.net/browse/JDK-8145542 8145542: The case failed automatically and thrown java.lang.ArrayIndexOutOfBoundsException exception ** https://bugs.openjdk.java.net/browse/JDK-8151725 8151725: [macosx] ArrayIndexOOB exception when displaying Devanagari text in JEditorPane ** https://bugs.openjdk.java.net/browse/JDK-8144240 8144240: [macosx][PIT] AIOOB in closed/javax/swing/text/GlyphPainter2/6427244/bug6427244.java https://bugs.openjdk.java.net/browse/JDK-8152680 8152680: Regression in GlyphVector.getGlyphCharIndex behaviour ** https://bugs.openjdk.java.net/browse/JDK-8158924 8158924: Incorrect i18n text document layout ** https://bugs.openjdk.java.net/browse/JDK-8041480 8041480: ArrayIndexOutOfBoundsException when JTable contains certain string -phil. From kim.barrett at oracle.com Thu Aug 25 21:28:33 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 25 Aug 2016 17:28:33 -0400 Subject: [OpenJDK 2D-Dev] [REGRESSION?] Build warnings at jdhuff.c with GCC 6 In-Reply-To: <0e864777-8f99-70c5-6014-07f963f17015@oracle.com> References: <46f8bb76-5fe9-d0aa-cfd7-b228e5478640@gmail.com> <57BC67AE.9080607@oracle.com> <57BC75F7.1020403@oracle.com> <0e864777-8f99-70c5-6014-07f963f17015@oracle.com> Message-ID: <091838F6-BDD3-4A39-A8AA-6C527264940F@oracle.com> > On Aug 24, 2016, at 5:48 AM, Erik Joelsson wrote: > > Hello, > > > On 2016-08-23 18:12, Phil Race wrote: >> On 08/23/2016 08:47 AM, Erik Joelsson wrote: >>> Hello, >>> >>> I do agree that maintaining the list of disabled warnings will be >>> impossible unless we have a structured way of tracking for which >>> compiler versions we disable what. Ideally we should be able to easily >>> add conditions for when certain warnings should be disabled. We are >>> unfortunately lacking that today and at least I don't have the >>> bandwidth to fix that anytime soon. >>> >>> The official compilers are only really official for Oracle. The >>> OpenJDK can (and should) be buildable with a much wider range of >>> compiler versions. >> I agree there. This is fortunately not an "unbuildable" situation. >> The only other option I can think of which may or may not be palatable >> is to explicitly >> check the compiler version and add that disabled warning only for that >> exact compiler version. >> There'd still be some maintenance as that compiler version became either >> official .. or obsolete .. >> >> Is there precedent (or any kind of support) for that ? > What I had in mind was a structured way of adding conditionals for some kind of ranges of compiler versions, or at least something like 6.*, or "greater than 4.9.3". It's pretty simple today to check for exact compiler versions but then we end up with a lot of changes when minor versions are bumped. I don't think that would be worth it. > > In this particular case is shift-negative-value a new warning in GCC 6? If that's the case it doesn't actually hurt adding it since GCC is nice enough to not complain about unknown warning tags. Not reviewing, but this caught my eye. The feature of not complaining about unknown -Wno-xxx warning options is only since gcc4.4. Some folks (like SAP) are still using versions that are older than that. > If we do, just make sure to specify in a comment that it's specific to GCC version 6+. From philip.race at oracle.com Thu Aug 25 23:16:22 2016 From: philip.race at oracle.com (Philip Race) Date: Thu, 25 Aug 2016 16:16:22 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8164818: Reg. test java/awt/font/TextLayout/VisibleAdvance.java fails Message-ID: <57BF7C46.90703@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-8164818 webrev: http://cr.openjdk.java.net/~prr/8164818/ 26.6 fixed point was being used in harfbuzz interface code and 16.16 elsewhere so we had a precision mismatch. More details in the bug report. -phil. From philip.race at oracle.com Thu Aug 25 23:22:20 2016 From: philip.race at oracle.com (Philip Race) Date: Thu, 25 Aug 2016 16:22:20 -0700 Subject: [OpenJDK 2D-Dev] [REGRESSION?] Build warnings at jdhuff.c with GCC 6 In-Reply-To: References: <46f8bb76-5fe9-d0aa-cfd7-b228e5478640@gmail.com> <57BC67AE.9080607@oracle.com> <57BC75F7.1020403@oracle.com> <0e864777-8f99-70c5-6014-07f963f17015@oracle.com> Message-ID: <57BF7DAC.7070406@oracle.com> On 8/24/16, 5:31 AM, Yasumasa Suenaga wrote: > Hi Erik, Phil, > > Thank you for replying. > I understand background of JDK-8074827. > >> In this particular case is shift-negative-value a new warning in GCC 6? > > Yes, this feature is implemented GCC 6: > https://gnu.wildebeest.org/blog/mjw/2016/02/15/looking-forward-to-gcc6-many-new-warnings/ I see. I tracked down the commit so yes, this seems to be the case. > > BTW, why is libjavajpeg only enabled these warnings? > For example, liblcms is disabled format-nonliteral, type-limits, and > misleading-indentation. We only disable the warnings that are observed .. not all warnings else we might as well turn off warnings completely. > > I agree compiler warnings is very useful to fix. However, I think a > part of source of libjavajpeg is third-party (developed by Independent > JPEG Group). > According to [1], warnings in this library should be suppressed. Yes. FWIW this is the most stable 3rd party library we have - by a long way - so it *could* be argued that tweaking it isn't likely to get lost any time soon but I'd still prefer to keep the source as it came. > > If all binaries which are included in JDK/JRE should be enabled all > compiler warnings, I think LCMS and any other libraries should be fixed. Well you would *have* to get upstream to resolve it. But it is whack-a-mole. As you have discovered new compilers generate new warnings .. and it is not monotonic either. -phil. > > Which policy is correct? > > > Thanks, > > Yasumasa > > > [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004495.html > > > On 2016/08/24 18:48, Erik Joelsson wrote: >> Hello, >> >> >> On 2016-08-23 18:12, Phil Race wrote: >>> On 08/23/2016 08:47 AM, Erik Joelsson wrote: >>>> Hello, >>>> >>>> I do agree that maintaining the list of disabled warnings will be >>>> impossible unless we have a structured way of tracking for which >>>> compiler versions we disable what. Ideally we should be able to easily >>>> add conditions for when certain warnings should be disabled. We are >>>> unfortunately lacking that today and at least I don't have the >>>> bandwidth to fix that anytime soon. >>>> >>>> The official compilers are only really official for Oracle. The >>>> OpenJDK can (and should) be buildable with a much wider range of >>>> compiler versions. >>> I agree there. This is fortunately not an "unbuildable" situation. >>> The only other option I can think of which may or may not be palatable >>> is to explicitly >>> check the compiler version and add that disabled warning only for that >>> exact compiler version. >>> There'd still be some maintenance as that compiler version became >>> either >>> official .. or obsolete .. >>> >>> Is there precedent (or any kind of support) for that ? >> What I had in mind was a structured way of adding conditionals for >> some kind of ranges of compiler versions, or at least something like >> 6.*, or "greater than 4.9.3". It's pretty simple today to check for >> exact compiler versions but then we end up with a lot of changes when >> minor versions are bumped. I don't think that would be worth it. >> >> In this particular case is shift-negative-value a new warning in GCC >> 6? If that's the case it doesn't actually hurt adding it since GCC is >> nice enough to not complain about unknown warning tags. If we do, >> just make sure to specify in a comment that it's specific to GCC >> version 6+. >> >> /Erik >>> -phil. >>> >>>> Luckily we have the workaround of setting --disable-warnings-as-errors >>>> when this situation occurs. >>>> >>>> For reference, the compilers Oracle uses are listed in >>>> README-builds.md in the top level directory in the forest. >>>> >>>> So for now at least, I think Phil is right. >>>> >>>> /Erik >>>> >>>> On 2016-08-23 17:11, Philip Race wrote: >>>>> Erik .. please chime in if you disagree with the following >>>>> The goal here is to have no warnings with the *official* compilers. >>>>> If you are using something else and get warnings then either fix >>>>> the *source* or else you need to use --disable-warning-as-errors. >>>>> >>>>> Otherwise we'll be suppressing the warnings for a whole range >>>>> of compilers and no one will know what the set is and these >>>>> bugs will become 'unfixable' and a continual chore of churn. >>>>> It will be something we should address as we move *official* >>>>> compilers. >>>>> >>>>> In fact the warning you want to suppress is one I just got rid of >>>>> (the >>>>> suppression) >>>>> http://hg.openjdk.java.net/jdk9/client/jdk/rev/d4f7412a51d2 >>>>> I don't think we want to add it back unless the *official* compilers >>>>> object >>>>> .. I am sure that official list is documented somewhere. >>>>> >>>>> -phil. >>>>> >>>>> >>>>> On 8/23/16, 6:10 AM, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> I've fixed several warnings when we build OpenJDK with GCC 6 in >>>>>> JDK-8160294. >>>>>> However, I encountered shift-negative-value warnings at jdhuff.c >>>>>> on my >>>>>> Fedora 24 (GCC 6.1.1): >>>>>> -------------- >>>>>> /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:13: >>>>>> >>>>>> >>>>>> warning: left shift of negative value [-Wshift-negative-value] >>>>>> { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1, >>>>>> ^~ >>>>>> /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:28: >>>>>> >>>>>> >>>>>> warning: left shift of negative value [-Wshift-negative-value] >>>>>> { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1, >>>>>> ^~ >>>>>> /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:43: >>>>>> >>>>>> >>>>>> warning: left shift of negative value [-Wshift-negative-value] >>>>>> { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1, >>>>>> : >>>>>> -------------- >>>>>> >>>>>> I think these warnings are available from JDK-8074827. >>>>>> This issue enables warnings to fix in the source code. >>>>>> However, in review of JDK-8160294, I heared that warnings in IJG >>>>>> JPEG >>>>>> library should just be suppressed: >>>>>> >>>>>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004497.html >>>>>> >>>>>> >>>>>> >>>>>> So I think they should be suppressed and we should fix as below: >>>>>> -------------- >>>>>> diff -r b548b8217d8c make/lib/Awt2dLibraries.gmk >>>>>> --- a/make/lib/Awt2dLibraries.gmk Mon Aug 22 19:28:36 2016 -0700 >>>>>> +++ b/make/lib/Awt2dLibraries.gmk Tue Aug 23 22:08:44 2016 +0900 >>>>>> @@ -490,7 +490,7 @@ >>>>>> CFLAGS := $(CFLAGS_JDKLIB) $(BUILD_LIBJAVAJPEG_HEADERS) \ >>>>>> $(LIBJAVA_HEADER_FLAGS) \ >>>>>> -I$(SUPPORT_OUTPUTDIR)/headers/java.desktop, \ >>>>>> - DISABLED_WARNINGS_gcc := clobbered, \ >>>>>> + DISABLED_WARNINGS_gcc := clobbered shift-negative-value, \ >>>>>> MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libjpeg/mapfile-vers, \ >>>>>> LDFLAGS := $(LDFLAGS_JDKLIB) \ >>>>>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>>>> -------------- >>>>>> >>>>>> If it is correct, I file it to JBS and upload webrev. >>>>>> Do you think about it? >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >> From philip.race at oracle.com Thu Aug 25 23:27:17 2016 From: philip.race at oracle.com (Philip Race) Date: Thu, 25 Aug 2016 16:27:17 -0700 Subject: [OpenJDK 2D-Dev] [REGRESSION?] Build warnings at jdhuff.c with GCC 6 In-Reply-To: <0e864777-8f99-70c5-6014-07f963f17015@oracle.com> References: <46f8bb76-5fe9-d0aa-cfd7-b228e5478640@gmail.com> <57BC67AE.9080607@oracle.com> <57BC75F7.1020403@oracle.com> <0e864777-8f99-70c5-6014-07f963f17015@oracle.com> Message-ID: <57BF7ED5.4050107@oracle.com> On 8/24/16, 2:48 AM, Erik Joelsson wrote: > Hello, > > > On 2016-08-23 18:12, Phil Race wrote: >> On 08/23/2016 08:47 AM, Erik Joelsson wrote: >>> Hello, >>> >>> I do agree that maintaining the list of disabled warnings will be >>> impossible unless we have a structured way of tracking for which >>> compiler versions we disable what. Ideally we should be able to easily >>> add conditions for when certain warnings should be disabled. We are >>> unfortunately lacking that today and at least I don't have the >>> bandwidth to fix that anytime soon. >>> >>> The official compilers are only really official for Oracle. The >>> OpenJDK can (and should) be buildable with a much wider range of >>> compiler versions. >> I agree there. This is fortunately not an "unbuildable" situation. >> The only other option I can think of which may or may not be palatable >> is to explicitly >> check the compiler version and add that disabled warning only for that >> exact compiler version. >> There'd still be some maintenance as that compiler version became either >> official .. or obsolete .. >> >> Is there precedent (or any kind of support) for that ? > What I had in mind was a structured way of adding conditionals for > some kind of ranges of compiler versions, or at least something like > 6.*, or "greater than 4.9.3". It's pretty simple today to check for > exact compiler versions but then we end up with a lot of changes when > minor versions are bumped. I don't think that would be worth it. > > In this particular case is shift-negative-value a new warning in GCC > 6? If that's the case it doesn't actually hurt adding it since GCC is > nice enough to not complain about unknown warning tags. If we do, just > make sure to specify in a comment that it's specific to GCC version 6+. OK lets allow this with a comment and hope it does not set a trend. I'd be largely unwilling to do it if it were not for the fact that someday I presume we'll be using gcc6 ... If there is a chance that - someday - you will get around to that "structured way", maybe a comment could be added that follow a standard format we devise so if this is requested for some other compiler you are able to grep and find all the ones to fix. Although this one makefile is probably the place to look so may be it is not really needed. The comment also ought to be phrased in a way that it is apparent the disabled warning should be left alone. -phil. > > /Erik >> -phil. >> >>> Luckily we have the workaround of setting --disable-warnings-as-errors >>> when this situation occurs. >>> >>> For reference, the compilers Oracle uses are listed in >>> README-builds.md in the top level directory in the forest. >>> >>> So for now at least, I think Phil is right. >>> >>> /Erik >>> >>> On 2016-08-23 17:11, Philip Race wrote: >>>> Erik .. please chime in if you disagree with the following >>>> The goal here is to have no warnings with the *official* compilers. >>>> If you are using something else and get warnings then either fix >>>> the *source* or else you need to use --disable-warning-as-errors. >>>> >>>> Otherwise we'll be suppressing the warnings for a whole range >>>> of compilers and no one will know what the set is and these >>>> bugs will become 'unfixable' and a continual chore of churn. >>>> It will be something we should address as we move *official* >>>> compilers. >>>> >>>> In fact the warning you want to suppress is one I just got rid of (the >>>> suppression) >>>> http://hg.openjdk.java.net/jdk9/client/jdk/rev/d4f7412a51d2 >>>> I don't think we want to add it back unless the *official* compilers >>>> object >>>> .. I am sure that official list is documented somewhere. >>>> >>>> -phil. >>>> >>>> >>>> On 8/23/16, 6:10 AM, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> I've fixed several warnings when we build OpenJDK with GCC 6 in >>>>> JDK-8160294. >>>>> However, I encountered shift-negative-value warnings at jdhuff.c >>>>> on my >>>>> Fedora 24 (GCC 6.1.1): >>>>> -------------- >>>>> /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:13: >>>>> >>>>> >>>>> warning: left shift of negative value [-Wshift-negative-value] >>>>> { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1, >>>>> ^~ >>>>> /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:28: >>>>> >>>>> >>>>> warning: left shift of negative value [-Wshift-negative-value] >>>>> { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1, >>>>> ^~ >>>>> /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:43: >>>>> >>>>> >>>>> warning: left shift of negative value [-Wshift-negative-value] >>>>> { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1, >>>>> : >>>>> -------------- >>>>> >>>>> I think these warnings are available from JDK-8074827. >>>>> This issue enables warnings to fix in the source code. >>>>> However, in review of JDK-8160294, I heared that warnings in IJG JPEG >>>>> library should just be suppressed: >>>>> >>>>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004497.html >>>>> >>>>> >>>>> So I think they should be suppressed and we should fix as below: >>>>> -------------- >>>>> diff -r b548b8217d8c make/lib/Awt2dLibraries.gmk >>>>> --- a/make/lib/Awt2dLibraries.gmk Mon Aug 22 19:28:36 2016 -0700 >>>>> +++ b/make/lib/Awt2dLibraries.gmk Tue Aug 23 22:08:44 2016 +0900 >>>>> @@ -490,7 +490,7 @@ >>>>> CFLAGS := $(CFLAGS_JDKLIB) $(BUILD_LIBJAVAJPEG_HEADERS) \ >>>>> $(LIBJAVA_HEADER_FLAGS) \ >>>>> -I$(SUPPORT_OUTPUTDIR)/headers/java.desktop, \ >>>>> - DISABLED_WARNINGS_gcc := clobbered, \ >>>>> + DISABLED_WARNINGS_gcc := clobbered shift-negative-value, \ >>>>> MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libjpeg/mapfile-vers, \ >>>>> LDFLAGS := $(LDFLAGS_JDKLIB) \ >>>>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>>> -------------- >>>>> >>>>> If it is correct, I file it to JBS and upload webrev. >>>>> Do you think about it? >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> > From goetz.lindenmaier at sap.com Fri Aug 26 06:24:08 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 26 Aug 2016 06:24:08 +0000 Subject: [OpenJDK 2D-Dev] RFR(XS): 8161923: Fix free in awt_PrintControl. In-Reply-To: <7f511416-76a1-cc09-0c7b-a1d64945a6e9@oracle.com> References: <7f511416-76a1-cc09-0c7b-a1d64945a6e9@oracle.com> Message-ID: <4d991accea93404cae1fb4e6a5f3fb24@DEWDFE13DE50.global.corp.sap> Thanks Vadim! Best regards, Goetz. > -----Original Message----- > From: Vadim Pakhnushev [mailto:vadim.pakhnushev at oracle.com] > Sent: Donnerstag, 25. August 2016 15:54 > To: Lindenmaier, Goetz ; 2d-dev <2d- > dev at openjdk.java.net> > Subject: Re: [OpenJDK 2D-Dev] RFR(XS): 8161923: Fix free in > awt_PrintControl. > > Looks good. > > Vadim > > On 25.08.2016 16:42, Lindenmaier, Goetz wrote: > > > Hi, > > > > Could I please get a review for this tiny fix? > > http://cr.openjdk.java.net/~goetz/wr16/8161923- > jdkMem/webrev.03/ jdkMem/webrev.03/> > > > > Best regards, > > Goetz. > From prem.balakrishnan at oracle.com Fri Aug 26 06:26:09 2016 From: prem.balakrishnan at oracle.com (Prem Balakrishnan) Date: Thu, 25 Aug 2016 23:26:09 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails In-Reply-To: <57BAA36E.2010704@oracle.com> References: <1d62d8f6-c7e6-e5c6-38e2-1764fea8011b@oracle.com> <94e9c6a3-2e9f-4405-a5c5-1e4dadeba7d9@default> <3e53ac2e-ba9b-b4e9-3ebd-bccb35bc6650@oracle.com> <75f3e1d7-dfc0-4d0c-84d9-192b306d0728@default> <57BAA36E.2010704@oracle.com> Message-ID: <197cdc08-165e-412d-9254-69c069e4fe47@default> Hi Prasanta, Thankyou for the review. The code compiles , Actual scenario is as below: public class Temp { AccelSurface as = new AccelSurface() {}; SurfaceData sd = (SurfaceData)as; } class SurfaceData {} interface Surface {} interface AccelSurface extends Surface{} class D3DSurfaceData extends SurfaceData implements AccelSurface{} class OGLSurfaceData extends SurfaceData implements AccelSurface{} ------------------- In suggested fix, the SurfaceData is always of type D3DSurfaceData. And hence getDefaultScaleX/Y holds good. OpenGL rendering is handled in a different flow. HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.02/"http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.02/ Suggested fix also resolves the following failures on hidpi windows 8 javax/swing/JWindow/ShapedAndTranslucentWindows/PerPixelTranslucent.java javax/swing/JWindow/ShapedAndTranslucentWindows/PerPixelTranslucentGradient.java javax/swing/JWindow/ShapedAndTranslucentWindows/SetShapeAndClickSwing.java javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedPerPixelTranslucentGradient.java javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedTranslucentPerPixelTranslucentGradient.java javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java ---------------------- OpenGL Rendering issue will be addressed in HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8164811"JDK-8164811 Regards, Prem From: Prasanta Sadhukhan Sent: Monday, August 22, 2016 12:32 PM To: Prem Balakrishnan; Rajeev Chamyal; awt-dev at openjdk.java.net; 2d-dev at openjdk.java.net Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails I wonder how it compiles? I tried a small program ------------------ public class Test { AccelSurface b = new AccelSurface(); SurfaceData c = (SurfaceData)b; } class SurfaceData extends Surface {} class Surface {} class AccelSurface extends Surface {} --------- and it fails to compile Test.java:3: error: incompatible types: AccelSurface cannot be converted to SurfaceData SurfaceData c = (SurfaceData)b; ANyways, did you check with opengl pipeline? It seems getDefaultScaleX/Y is not present in OGLSurfaceData which will result in falling back to SurfaceData in which case the scale will be 1. Regards Prasanta On 8/18/2016 3:12 PM, Prem Balakrishnan wrote: Added "2d-dev" team for review Regards, Prem From: Alexandr Scherbatiy Sent: Thursday, August 18, 2016 2:57 PM To: Prem Balakrishnan; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails Could you also send the review to the 2d-dev alias? Thanks, Alexandr. On 8/18/2016 9:59 AM, Prem Balakrishnan wrote: Hi Alexandr, AccelSurface is implemented by *ONLY* D3DSurfaceData and OGLSurfaceData classes, Both of these classes extend SurfaceData as well. Hence, casting of 'as' variable which is of type AccelSurface object to SurfaceData is always VALID. Regards, Prem From: Alexandr Scherbatiy Sent: Wednesday, August 17, 2016 4:42 PM To: Prem Balakrishnan; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails On 8/17/2016 11:30 AM, Prem Balakrishnan wrote: Hi Alexandr, Thankyou for the review. YES scaled SurfaceData returns proper scale values from getDefaultScaleX()/getDefaultScaleY(), which I have used in the current patch. Please review the updated patch HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.02/"http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.02/ Is it always true that the 'as' variable which has type AccelSurface in the fix is always instance of SurfaceData? Thanks, Alexandr. Regards, Prem From: Alexandr Scherbatiy Sent: Tuesday, August 16, 2016 10:06 PM To: Prem Balakrishnan; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails On 8/16/2016 7:35 AM, Prem Balakrishnan wrote: Reminder From: Prem Balakrishnan Sent: Friday, August 12, 2016 6:36 PM To: Alexander Scherbatiy; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: RE: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails Hi Alexandr and Sergey, Please review the updated patch. HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.01/"http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.01/ >>"It is a little bit strange bug, because VolatileImage should handle this scale internally, and create double sized surface when necessary".-Sergey Yes as you mentioned Volatile Image is getting scaled internally. Thanks for the feedback. Cause: In VIOptWindowPainter::updateWindowAccel(psdops, w, h) call, width and height were passed without scaling, which was creating a bitmap of specified width and height, hence the output was clipped. I just have two general questions. - The scaled SurfaceData should return proper scales from getDefaultScaleX()/getDefaultScaleY() methods. Do these methods return right values after setting the scaled image sizes in the fix? - Region.clipScale() which is used in many places rounds values. The usual rule is to use Math.floor() for image coordinates rounding and Math.ceil() for sizes. Should the same rule be applicable here? Thanks, Alexandr. Regards, Prem From: Alexandr Scherbatiy Sent: Thursday, August 04, 2016 6:23 PM To: Prem Balakrishnan; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails On 8/3/2016 10:04 AM, Prem Balakrishnan wrote: Hi, Please review fix for JDK9, Bug: https://bugs.openjdk.java.net/browse/JDK-8144735 Webrev: http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.00/ Issue: javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails Cause: While creating Transparent VolatileImage, width and height was NOT hidpi scaled. Fix: VolatileImage width and height are scaled. I believe this is an issue in AWT and needs to be discussed on awt-dev alias. Should the backbuffer width and height be also scaled for the BIWindowPainter? Thanks, Alexandr. Thanks, Prem -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Fri Aug 26 06:37:48 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 26 Aug 2016 12:07:48 +0530 Subject: [OpenJDK 2D-Dev] Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails In-Reply-To: <197cdc08-165e-412d-9254-69c069e4fe47@default> References: <1d62d8f6-c7e6-e5c6-38e2-1764fea8011b@oracle.com> <94e9c6a3-2e9f-4405-a5c5-1e4dadeba7d9@default> <3e53ac2e-ba9b-b4e9-3ebd-bccb35bc6650@oracle.com> <75f3e1d7-dfc0-4d0c-84d9-192b306d0728@default> <57BAA36E.2010704@oracle.com> <197cdc08-165e-412d-9254-69c069e4fe47@default> Message-ID: <57BFE3BC.5050500@oracle.com> Ok. so long you are addressing the opengl issue albeit via different bugid, it's ok with me. +1. Regards Prasanta On 8/26/2016 11:56 AM, Prem Balakrishnan wrote: > > Hi Prasanta, > > Thankyou for the review. > > The code compiles , Actual scenario is as below: > > public class Temp { > > AccelSurface as = new AccelSurface() {}; > > SurfaceData sd = (SurfaceData)as; > > } > > class SurfaceData {} > > interface Surface {} > > interface AccelSurface extends Surface{} > > class D3DSurfaceData extends SurfaceData implements AccelSurface{} > > class OGLSurfaceData extends SurfaceData implements AccelSurface{} > > ------------------- > > In suggested fix, the SurfaceData is always of type D3DSurfaceData. > > And hence getDefaultScaleX/Y holds good. OpenGL rendering is handled > in a different flow. > > http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.02/ > > > Suggested fix also resolves the following failures on hidpi windows 8 > > javax/swing/JWindow/ShapedAndTranslucentWindows/PerPixelTranslucent.java > javax/swing/JWindow/ShapedAndTranslucentWindows/PerPixelTranslucentGradient.java > > javax/swing/JWindow/ShapedAndTranslucentWindows/SetShapeAndClickSwing.java > > javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedPerPixelTranslucentGradient.java > > javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedTranslucentPerPixelTranslucentGradient.java > > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > > ---------------------- > OpenGL Rendering issue will be addressed in JDK-8164811 > > > > > Regards, > > Prem > > *From:*Prasanta Sadhukhan > *Sent:* Monday, August 22, 2016 12:32 PM > *To:* Prem Balakrishnan; Rajeev Chamyal; awt-dev at openjdk.java.net; > 2d-dev at openjdk.java.net > *Subject:* Re: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > I wonder how it compiles? > I tried a small program > ------------------ > public class Test { > AccelSurface b = new AccelSurface(); > SurfaceData c = (SurfaceData)b; > } > > class SurfaceData extends Surface {} > class Surface {} > class AccelSurface extends Surface {} > --------- > and it fails to compile > Test.java:3: error: incompatible types: AccelSurface cannot be > converted to SurfaceData > SurfaceData c = (SurfaceData)b; > > ANyways, did you check with opengl pipeline? It seems > getDefaultScaleX/Y is not present in OGLSurfaceData which will result > in falling back to SurfaceData in which case the scale will be 1. > > Regards > Prasanta > > On 8/18/2016 3:12 PM, Prem Balakrishnan wrote: > > Added ?2d-dev? team for review > > Regards, > > Prem > > *From:*Alexandr Scherbatiy > *Sent:* Thursday, August 18, 2016 2:57 PM > *To:* Prem Balakrishnan; Rajeev Chamyal; awt-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > Could you also send the review to the 2d-dev alias? > > Thanks, > Alexandr. > > On 8/18/2016 9:59 AM, Prem Balakrishnan wrote: > > Hi Alexandr, > > AccelSurface is implemented by *ONLY* D3DSurfaceData and > OGLSurfaceData classes, > > Both of these classes extend SurfaceData as well. > > Hence, casting of 'as' variable which is of type AccelSurface > object to SurfaceData is always VALID. > > Regards, > Prem > > *From:*Alexandr Scherbatiy > *Sent:* Wednesday, August 17, 2016 4:42 PM > *To:* Prem Balakrishnan; Rajeev Chamyal; > awt-dev at openjdk.java.net ; > Sergey Bylokhov > *Subject:* Re: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > On 8/17/2016 11:30 AM, Prem Balakrishnan wrote: > > > > Hi Alexandr, > > Thankyou for the review. > > YES scaled SurfaceData returns proper scale values from > getDefaultScaleX()/getDefaultScaleY(), which I have used in > the current patch. > > Please review the updated patch > > http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.02/ > > > Is it always true that the 'as' variable which has type > AccelSurface in the fix is always instance of SurfaceData? > > Thanks, > Alexandr. > > > > Regards, > Prem > > *From:*Alexandr Scherbatiy > *Sent:* Tuesday, August 16, 2016 10:06 PM > *To:* Prem Balakrishnan; Rajeev Chamyal; > awt-dev at openjdk.java.net ; > Sergey Bylokhov > *Subject:* Re: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > On 8/16/2016 7:35 AM, Prem Balakrishnan wrote: > > > > > Reminder > > *From:*Prem Balakrishnan > *Sent:* Friday, August 12, 2016 6:36 PM > *To:* Alexander Scherbatiy; Rajeev Chamyal; > awt-dev at openjdk.java.net ; > Sergey Bylokhov > *Subject:* RE: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > Hi Alexandr and Sergey, > > Please review the updated patch. > > http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.01/ > > > >>?It is a little bit strange bug, because VolatileImage > should handle this scale internally, and create double sized > surface when necessary?.-Sergey > > Yes as you mentioned Volatile Image is getting scaled > internally. Thanks for the feedback. > > *Cause:*In VIOptWindowPainter::updateWindowAccel(psdops, w, h) > call, width and height were passed without scaling, > > which was creating a bitmap of specified width and height, > hence the output was clipped. > > > I just have two general questions. > - The scaled SurfaceData should return proper scales from > getDefaultScaleX()/getDefaultScaleY() methods. Do these > methods return right values after setting the scaled image > sizes in the fix? > - Region.clipScale() which is used in many places rounds > values. The usual rule is to use Math.floor() for image > coordinates rounding and Math.ceil() for sizes. > Should the same rule be applicable here? > > Thanks, > Alexandr. > > > > > > > Regards, > > Prem > > *From:*Alexandr Scherbatiy > *Sent:* Thursday, August 04, 2016 6:23 PM > *To:* Prem Balakrishnan; Rajeev Chamyal; > awt-dev at openjdk.java.net ; > Sergey Bylokhov > *Subject:* Re: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > On 8/3/2016 10:04 AM, Prem Balakrishnan wrote: > > Hi, > > Please review fix for JDK9, > > *Bug:*https://bugs.openjdk.java.net/browse/JDK-8144735 > > *Webrev:*http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.00/ > > > *Issue:* > > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > *Cause:* > > While creating Transparent VolatileImage, width and height was > NOT hidpi scaled. > > *Fix: *VolatileImage width and height are scaled. > > > I believe this is an issue in AWT and needs to be discussed > on awt-dev alias. > > Should the backbuffer width and height be also scaled for > the BIWindowPainter? > > Thanks, > Alexandr. > > Thanks, > > Prem > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Fri Aug 26 07:23:43 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 26 Aug 2016 09:23:43 +0200 Subject: [OpenJDK 2D-Dev] [REGRESSION?] Build warnings at jdhuff.c with GCC 6 In-Reply-To: <091838F6-BDD3-4A39-A8AA-6C527264940F@oracle.com> References: <46f8bb76-5fe9-d0aa-cfd7-b228e5478640@gmail.com> <57BC67AE.9080607@oracle.com> <57BC75F7.1020403@oracle.com> <0e864777-8f99-70c5-6014-07f963f17015@oracle.com> <091838F6-BDD3-4A39-A8AA-6C527264940F@oracle.com> Message-ID: <3fa82b5f-975b-4dca-e1d3-5b8b31e6d011@oracle.com> On 2016-08-25 23:28, Kim Barrett wrote: >> On Aug 24, 2016, at 5:48 AM, Erik Joelsson wrote: >> >> Hello, >> >> >> On 2016-08-23 18:12, Phil Race wrote: >>> On 08/23/2016 08:47 AM, Erik Joelsson wrote: >>>> Hello, >>>> >>>> I do agree that maintaining the list of disabled warnings will be >>>> impossible unless we have a structured way of tracking for which >>>> compiler versions we disable what. Ideally we should be able to easily >>>> add conditions for when certain warnings should be disabled. We are >>>> unfortunately lacking that today and at least I don't have the >>>> bandwidth to fix that anytime soon. >>>> >>>> The official compilers are only really official for Oracle. The >>>> OpenJDK can (and should) be buildable with a much wider range of >>>> compiler versions. >>> I agree there. This is fortunately not an "unbuildable" situation. >>> The only other option I can think of which may or may not be palatable >>> is to explicitly >>> check the compiler version and add that disabled warning only for that >>> exact compiler version. >>> There'd still be some maintenance as that compiler version became either >>> official .. or obsolete .. >>> >>> Is there precedent (or any kind of support) for that ? >> What I had in mind was a structured way of adding conditionals for some kind of ranges of compiler versions, or at least something like 6.*, or "greater than 4.9.3". It's pretty simple today to check for exact compiler versions but then we end up with a lot of changes when minor versions are bumped. I don't think that would be worth it. >> >> In this particular case is shift-negative-value a new warning in GCC 6? If that's the case it doesn't actually hurt adding it since GCC is nice enough to not complain about unknown warning tags. > Not reviewing, but this caught my eye. > > The feature of not complaining about unknown -Wno-xxx warning options is only since gcc4.4. > Some folks (like SAP) are still using versions that are older than that. That is true, so configure checks if gcc complains about unknown warnings. If not, we automatically do not add the -Wno-* arguments. /Erik >> If we do, just make sure to specify in a comment that it's specific to GCC version 6+. From prasanta.sadhukhan at oracle.com Fri Aug 26 08:05:13 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 26 Aug 2016 13:35:13 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-7064425: PageFormat Dialog has no owner window to reactivate In-Reply-To: <57BECB2E.4030102@oracle.com> References: <57BECB2E.4030102@oracle.com> Message-ID: <57BFF839.3010009@oracle.com> Hi All, I have modified the webrev to take care of JDK-6948907 : sun.print.DialogOwner does not support Dialogs as DialogOwner also. http://cr.openjdk.java.net/~psadhukhan/7064425/webrev.01/ Tested on windows and ubuntu. Regards Prasanta On 8/25/2016 4:10 PM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix for jdk9 for an issue where it is seen that > PageDialog and PrintDialog is not associated with the owner Frame that > spawns the dialog. > > Bug: https://bugs.openjdk.java.net/browse/JDK-7064425 > webrev: http://cr.openjdk.java.net/~psadhukhan/7064425/webrev.00/ > > The issue was there we explicitly pass null as owner to ServiceDialog > in pageDialog(attributes). > Proposed fix is to get the owner window, > if pageDialog is called before calling printDialog, the window will be > a Frame else the owner window will be ServiceDialog > and pass this owner window to ServiceDialog instead of null. > > For PrintDialog, the proposed fix is to set an attribute with > DialogOwner so that ServiceUI dialog can parse that attribute and can > use the owner window as parent of the dialaog, > > Regards > Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Mon Aug 29 08:11:26 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 29 Aug 2016 13:41:26 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR 4987884: PrinterJob carries over some values between calls to print. In-Reply-To: <577B43FA.5080009@oracle.com> References: <577B43FA.5080009@oracle.com> Message-ID: <57C3EE2E.3060400@oracle.com> Hi All, If we call ----------------- / pageFormat = job.pageDialog(pageFormat);// // pageFormat.setPaper(paper);// // job.setPrintable(p, pageFormat);// //// // try {// // job.printDialog();// // job.print();// // } catch (PrinterException e) {}// /------------------- then these attributes are added Media, OrientationRequested, MediaPrintableArea, Chromaticity, PrinterResolution, Copies, SheetCollate, Sides even if we do not change any fields and PageRanges attribute is added if we change page selection from "All" to "Pages". In light of that, I do not think we can remove PageRanges attribute from no-args print() method as that will remove user selection. Or for that matter, any attributes as those can be set via pageDialog or printDialog. I guess we need to mark this as "Wont fix" . spec also is not clear if we are not supposed to honour any attributes already set, if we call no-args print() method. Any comments? Regards Prasanta On 7/5/2016 10:52 AM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix whereby it is seen that the PageRanges attribute > passed to 1st print() call is inadvertently been carried forward to > 2nd print > if some program tries calling in this sequence > ---------- > /PrinterJob pj = PrinterJob.getPrinterJob();// > //pj.setPageable(..)// > //pj.print(..)// > //pj.setPageable(..)// > //pj.print(..) > ------------ > / > Bug: https://bugs.openjdk.java.net/browse/JDK-4987884/ > /webrev: http://cr.openjdk.java.net/~psadhukhan/4987884/webrev.00// > > /This is because no-args print() uses an internal attribute set which > is presumed to carry over information not supplied > by the client directly but created during a call to no-args > printDialog() or during call to setPrintable() called via setAttributes(). > but it apparently seems, we should not be remembering PageRange > attribute between calls to print() as it will result in wrong page > numbers being printed. > > Proposed fix to remove the PageRanges attribute from no-args print() > between print() calls. > > Regards > Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Mon Aug 29 08:42:42 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 29 Aug 2016 01:42:42 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() method does not work when called inside imageStarted for PNG In-Reply-To: <57B4C50F.6050809@oracle.com> References: <06aa9e0a-bf19-4dd0-949a-c3c0cb00d4b1@default> <57B4C50F.6050809@oracle.com> Message-ID: <5a23861e-448c-4d23-8704-0bbc7c2148d2@default> Hi Phil & Sergey, Thanks for your inputs. I have verified reader.abort() request for IIOReadProgressListener for all available plugins. Apart from PNG although all readers were able to abort read when we call reader.abort() from IIOReadProgressListener callbacks, they were not calling processReadAborted() right after IIOReadProgressListener callbacks. So I have made changes for the same. And in some readers before every read call they were not calling clearAbortRequest(), which is important because if we use same reader for another read() call it will be invalid unless we clear previous abort request. In case of JPEG since we are using native IJG library we need to update abortFlag present in imageioJPEG.c before every call as we are doing for other readers using clearAbortRequest(). Since this has native and make changes I have verified changes through JPRT also which is successfully building on all platforms (http://scaaa637.us.oracle.com//archive/2016/08/2016-08-29-065104.jay.client_commit//JobStatus.txt ) Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/4924727/webrev.01/ I noticed that in case on WBMP I was not getting ImageReader object to call setInput() in test case to verify the behavior of reader.abort(). So I have created separate bug for the same (https://bugs.openjdk.java.net/browse/JDK-8164930 ). And in case of WBMP we already have clearAbortRequest() call and also we are returning from IIOReadProgressListener callbacks properly, only thing here is we are not returning right after callbacks as we have updated other plugins. I want to verify writer plugins in separate bug as we already have lot of changes in this bug. So I have created https://bugs.openjdk.java.net/browse/JDK-8164931 and will be working on this bug. Thanks, Jay -----Original Message----- From: Phil Race Sent: Thursday, August 18, 2016 1:42 AM To: Sergey Bylokhov Cc: Jayathirth D V; Prasanta Sadhukhan; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() method does not work when called inside imageStarted for PNG I think we can - get all plugins,and for each - write a file in that format - read it back and apply the test It is also worth verifying that the writer abort checks are in sync with the reader aborts, ie happen at such equivalent points as might exist. -phil. On 08/15/2016 11:30 AM, Sergey Bylokhov wrote: > Is it possible to unify the test for all our plugins? I assume they > should work in the same way. I am not sure but probably the image can > be generated at runtime? > > On 11.08.16 21:59, Jayathirth D V wrote: >> Hi, >> >> >> >> Please review the following fix in JDK9 at your convenience: >> >> >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-4924727 >> >> >> >> Webrev : http://cr.openjdk.java.net/~jdv/4924727/webrev.00/ >> >> >> >> Issue : When we issue ImageReader.abort() in >> IIOReadProgressListener.imageStarted(), reading is not aborted and it >> is continued. >> >> >> >> Root cause : After IIOReadProgressListener.imageStarted() call in >> PNGImageReader.java when we enter decodeImage() we call >> clearAbortRequest() which will clear the abort request from >> IIOReadProgressListener.imageStarted(). >> >> >> >> Solution : clearAbortRequest() documentation mentions that it should >> be called before reading of image starts, so it should be called >> before IIOReadProgressListener.imageStarted()(In PNGImageReader.java >> it is >> processImageStarted(0) in readImage()). So moved clearAbortRequest() >> call from decodeImage() to readImage(). Also we should call >> abortRequested() in PNGImageReader.java at places mapping to >> IIOReadProgressListener and not randomly at end of functions or at >> places related to IIOReadUpdateListener, updated the code for the same. >> >> >> >> >> >> Observation not related to this issue : We don't have call similar to >> IIOReadProgressListener.readAborted() in IIOReadUpdateListener, but >> user can call ImageReader.abort() from IIOReadUpdateListener methods. >> Is there a need to add similar method in IIOReadUpdateListener? Any >> inputs on this also would be helpful. >> >> >> >> Thanks, >> >> Jay >> > > From brian.burkhalter at oracle.com Mon Aug 29 14:39:10 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 29 Aug 2016 07:39:10 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8160327: Support for thumbnails present in APP1 marker for JPEG Message-ID: <82E1034D-B00E-4B64-BC95-F9DAAE44516C@oracle.com> Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8160327 Patch: http://cr.openjdk.java.net/~bpb/8160327/webrev.00/ Add thumbnail and standard metadata Document/ImageCreationTime from the APP1 Exif marker segment if present The code has been tested using JPEG-Exif images with compressed thumbnails from Canon, Nikon, and Olympus cameras, and using a JPEG-Exif image with an uncompressed thumbnail from a Sony camera. Thanks, Brian From brian.burkhalter at oracle.com Mon Aug 29 14:39:10 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 29 Aug 2016 07:39:10 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8160327: Support for thumbnails present in APP1 marker for JPEG Message-ID: <82E1034D-B00E-4B64-BC95-F9DAAE44516C@oracle.com> Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8160327 Patch: http://cr.openjdk.java.net/~bpb/8160327/webrev.00/ Add thumbnail and standard metadata Document/ImageCreationTime from the APP1 Exif marker segment if present The code has been tested using JPEG-Exif images with compressed thumbnails from Canon, Nikon, and Olympus cameras, and using a JPEG-Exif image with an uncompressed thumbnail from a Sony camera. Thanks, Brian From Sergey.Bylokhov at oracle.com Mon Aug 29 14:41:58 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 29 Aug 2016 17:41:58 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8164818: Reg. test java/awt/font/TextLayout/VisibleAdvance.java fails In-Reply-To: <57BF7C46.90703@oracle.com> References: <57BF7C46.90703@oracle.com> Message-ID: Looks fine. On 26.08.16 2:16, Philip Race wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8164818 > webrev: http://cr.openjdk.java.net/~prr/8164818/ > > 26.6 fixed point was being used in harfbuzz interface code > and 16.16 elsewhere so we had a precision mismatch. > More details in the bug report. > > -phil. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Aug 29 14:55:03 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 29 Aug 2016 17:55:03 +0300 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() method does not work when called inside imageStarted for PNG In-Reply-To: <5a23861e-448c-4d23-8704-0bbc7c2148d2@default> References: <06aa9e0a-bf19-4dd0-949a-c3c0cb00d4b1@default> <57B4C50F.6050809@oracle.com> <5a23861e-448c-4d23-8704-0bbc7c2148d2@default> Message-ID: <4fa0630e-9a97-805d-a603-0d4e51c64e74@oracle.com> Hi, Jay. Please delete the temporary file via Files.delete(), which will throw an exception if the file is locked by some reader. On 29.08.16 11:42, Jayathirth D V wrote: > Hi Phil & Sergey, > > Thanks for your inputs. > > I have verified reader.abort() request for IIOReadProgressListener for all available plugins. > > Apart from PNG although all readers were able to abort read when we call reader.abort() from IIOReadProgressListener callbacks, they were not calling processReadAborted() right after IIOReadProgressListener callbacks. So I have made changes for the same. > > And in some readers before every read call they were not calling clearAbortRequest(), which is important because if we use same reader for another read() call it will be invalid unless we clear previous abort request. > > In case of JPEG since we are using native IJG library we need to update abortFlag present in imageioJPEG.c before every call as we are doing for other readers using clearAbortRequest(). > > Since this has native and make changes I have verified changes through JPRT also which is successfully building on all platforms (http://scaaa637.us.oracle.com//archive/2016/08/2016-08-29-065104.jay.client_commit//JobStatus.txt ) > > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/4924727/webrev.01/ > > I noticed that in case on WBMP I was not getting ImageReader object to call setInput() in test case to verify the behavior of reader.abort(). So I have created separate bug for the same (https://bugs.openjdk.java.net/browse/JDK-8164930 ). And in case of WBMP we already have clearAbortRequest() call and also we are returning from IIOReadProgressListener callbacks properly, only thing here is we are not returning right after callbacks as we have updated other plugins. > > I want to verify writer plugins in separate bug as we already have lot of changes in this bug. So I have created https://bugs.openjdk.java.net/browse/JDK-8164931 and will be working on this bug. > > Thanks, > Jay > > -----Original Message----- > From: Phil Race > Sent: Thursday, August 18, 2016 1:42 AM > To: Sergey Bylokhov > Cc: Jayathirth D V; Prasanta Sadhukhan; 2d-dev > Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() method does not work when called inside imageStarted for PNG > > I think we can > - get all plugins,and for each > - write a file in that format > - read it back and apply the test > > It is also worth verifying that the writer abort checks are in sync with the reader aborts, ie happen at such equivalent points as might exist. > > -phil. > > On 08/15/2016 11:30 AM, Sergey Bylokhov wrote: >> Is it possible to unify the test for all our plugins? I assume they >> should work in the same way. I am not sure but probably the image can >> be generated at runtime? >> >> On 11.08.16 21:59, Jayathirth D V wrote: >>> Hi, >>> >>> >>> >>> Please review the following fix in JDK9 at your convenience: >>> >>> >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-4924727 >>> >>> >>> >>> Webrev : http://cr.openjdk.java.net/~jdv/4924727/webrev.00/ >>> >>> >>> >>> Issue : When we issue ImageReader.abort() in >>> IIOReadProgressListener.imageStarted(), reading is not aborted and it >>> is continued. >>> >>> >>> >>> Root cause : After IIOReadProgressListener.imageStarted() call in >>> PNGImageReader.java when we enter decodeImage() we call >>> clearAbortRequest() which will clear the abort request from >>> IIOReadProgressListener.imageStarted(). >>> >>> >>> >>> Solution : clearAbortRequest() documentation mentions that it should >>> be called before reading of image starts, so it should be called >>> before IIOReadProgressListener.imageStarted()(In PNGImageReader.java >>> it is >>> processImageStarted(0) in readImage()). So moved clearAbortRequest() >>> call from decodeImage() to readImage(). Also we should call >>> abortRequested() in PNGImageReader.java at places mapping to >>> IIOReadProgressListener and not randomly at end of functions or at >>> places related to IIOReadUpdateListener, updated the code for the same. >>> >>> >>> >>> >>> >>> Observation not related to this issue : We don't have call similar to >>> IIOReadProgressListener.readAborted() in IIOReadUpdateListener, but >>> user can call ImageReader.abort() from IIOReadUpdateListener methods. >>> Is there a need to add similar method in IIOReadUpdateListener? Any >>> inputs on this also would be helpful. >>> >>> >>> >>> Thanks, >>> >>> Jay >>> >> >> > -- Best regards, Sergey. From jayathirth.d.v at oracle.com Mon Aug 29 15:07:45 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 29 Aug 2016 08:07:45 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() method does not work when called inside imageStarted for PNG In-Reply-To: <4fa0630e-9a97-805d-a603-0d4e51c64e74@oracle.com> References: <06aa9e0a-bf19-4dd0-949a-c3c0cb00d4b1@default> <57B4C50F.6050809@oracle.com> <5a23861e-448c-4d23-8704-0bbc7c2148d2@default> <4fa0630e-9a97-805d-a603-0d4e51c64e74@oracle.com> Message-ID: <46d689e7-6246-451d-ba98-7bbfd93ef163@default> Hi Sergey, I am not getting the usage of Files.delete() from its specification. Can you please elaborate what special case it will handle in my test case? I am creating temporary file separately for all the readers and deleting them. Also I am closing the ImageInputStream associated after read operation. Thanks, Jay -----Original Message----- From: Sergey Bylokhov Sent: Monday, August 29, 2016 8:25 PM To: Jayathirth D V; Philip Race Cc: Prasanta Sadhukhan; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() method does not work when called inside imageStarted for PNG Hi, Jay. Please delete the temporary file via Files.delete(), which will throw an exception if the file is locked by some reader. On 29.08.16 11:42, Jayathirth D V wrote: > Hi Phil & Sergey, > > Thanks for your inputs. > > I have verified reader.abort() request for IIOReadProgressListener for all available plugins. > > Apart from PNG although all readers were able to abort read when we call reader.abort() from IIOReadProgressListener callbacks, they were not calling processReadAborted() right after IIOReadProgressListener callbacks. So I have made changes for the same. > > And in some readers before every read call they were not calling clearAbortRequest(), which is important because if we use same reader for another read() call it will be invalid unless we clear previous abort request. > > In case of JPEG since we are using native IJG library we need to update abortFlag present in imageioJPEG.c before every call as we are doing for other readers using clearAbortRequest(). > > Since this has native and make changes I have verified changes through > JPRT also which is successfully building on all platforms > (http://scaaa637.us.oracle.com//archive/2016/08/2016-08-29-065104.jay. > client_commit//JobStatus.txt ) > > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/4924727/webrev.01/ > > I noticed that in case on WBMP I was not getting ImageReader object to call setInput() in test case to verify the behavior of reader.abort(). So I have created separate bug for the same (https://bugs.openjdk.java.net/browse/JDK-8164930 ). And in case of WBMP we already have clearAbortRequest() call and also we are returning from IIOReadProgressListener callbacks properly, only thing here is we are not returning right after callbacks as we have updated other plugins. > > I want to verify writer plugins in separate bug as we already have lot of changes in this bug. So I have created https://bugs.openjdk.java.net/browse/JDK-8164931 and will be working on this bug. > > Thanks, > Jay > > -----Original Message----- > From: Phil Race > Sent: Thursday, August 18, 2016 1:42 AM > To: Sergey Bylokhov > Cc: Jayathirth D V; Prasanta Sadhukhan; 2d-dev > Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() > method does not work when called inside imageStarted for PNG > > I think we can > - get all plugins,and for each > - write a file in that format > - read it back and apply the test > > It is also worth verifying that the writer abort checks are in sync with the reader aborts, ie happen at such equivalent points as might exist. > > -phil. > > On 08/15/2016 11:30 AM, Sergey Bylokhov wrote: >> Is it possible to unify the test for all our plugins? I assume they >> should work in the same way. I am not sure but probably the image can >> be generated at runtime? >> >> On 11.08.16 21:59, Jayathirth D V wrote: >>> Hi, >>> >>> >>> >>> Please review the following fix in JDK9 at your convenience: >>> >>> >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-4924727 >>> >>> >>> >>> Webrev : http://cr.openjdk.java.net/~jdv/4924727/webrev.00/ >>> >>> >>> >>> Issue : When we issue ImageReader.abort() in >>> IIOReadProgressListener.imageStarted(), reading is not aborted and >>> it is continued. >>> >>> >>> >>> Root cause : After IIOReadProgressListener.imageStarted() call in >>> PNGImageReader.java when we enter decodeImage() we call >>> clearAbortRequest() which will clear the abort request from >>> IIOReadProgressListener.imageStarted(). >>> >>> >>> >>> Solution : clearAbortRequest() documentation mentions that it should >>> be called before reading of image starts, so it should be called >>> before IIOReadProgressListener.imageStarted()(In PNGImageReader.java >>> it is >>> processImageStarted(0) in readImage()). So moved clearAbortRequest() >>> call from decodeImage() to readImage(). Also we should call >>> abortRequested() in PNGImageReader.java at places mapping to >>> IIOReadProgressListener and not randomly at end of functions or at >>> places related to IIOReadUpdateListener, updated the code for the same. >>> >>> >>> >>> >>> >>> Observation not related to this issue : We don't have call similar >>> to >>> IIOReadProgressListener.readAborted() in IIOReadUpdateListener, but >>> user can call ImageReader.abort() from IIOReadUpdateListener methods. >>> Is there a need to add similar method in IIOReadUpdateListener? Any >>> inputs on this also would be helpful. >>> >>> >>> >>> Thanks, >>> >>> Jay >>> >> >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Aug 29 15:22:11 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 29 Aug 2016 18:22:11 +0300 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() method does not work when called inside imageStarted for PNG In-Reply-To: <46d689e7-6246-451d-ba98-7bbfd93ef163@default> References: <06aa9e0a-bf19-4dd0-949a-c3c0cb00d4b1@default> <57B4C50F.6050809@oracle.com> <5a23861e-448c-4d23-8704-0bbc7c2148d2@default> <4fa0630e-9a97-805d-a603-0d4e51c64e74@oracle.com> <46d689e7-6246-451d-ba98-7bbfd93ef163@default> Message-ID: On 29.08.16 18:07, Jayathirth D V wrote: > Hi Sergey, > > I am not getting the usage of Files.delete() from its specification. Can you please elaborate what special case it will handle in my test case? > I am creating temporary file separately for all the readers and deleting them. Files.delete() will throw an exception if the file cannot be deleted, and File.delete() will return false in such case. Also I am closing the ImageInputStream associated after read operation. But plugin itself can leak some streams and lock a temporary file, so Files.delete() will catch this. > -----Original Message----- > From: Sergey Bylokhov > Sent: Monday, August 29, 2016 8:25 PM > To: Jayathirth D V; Philip Race > Cc: Prasanta Sadhukhan; 2d-dev > Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() method does not work when called inside imageStarted for PNG > > Hi, Jay. > Please delete the temporary file via Files.delete(), which will throw an exception if the file is locked by some reader. > > On 29.08.16 11:42, Jayathirth D V wrote: >> Hi Phil & Sergey, >> >> Thanks for your inputs. >> >> I have verified reader.abort() request for IIOReadProgressListener for all available plugins. >> >> Apart from PNG although all readers were able to abort read when we call reader.abort() from IIOReadProgressListener callbacks, they were not calling processReadAborted() right after IIOReadProgressListener callbacks. So I have made changes for the same. >> >> And in some readers before every read call they were not calling clearAbortRequest(), which is important because if we use same reader for another read() call it will be invalid unless we clear previous abort request. >> >> In case of JPEG since we are using native IJG library we need to update abortFlag present in imageioJPEG.c before every call as we are doing for other readers using clearAbortRequest(). >> >> Since this has native and make changes I have verified changes through >> JPRT also which is successfully building on all platforms >> (http://scaaa637.us.oracle.com//archive/2016/08/2016-08-29-065104.jay. >> client_commit//JobStatus.txt ) >> >> Please find updated webrev for review: >> http://cr.openjdk.java.net/~jdv/4924727/webrev.01/ >> >> I noticed that in case on WBMP I was not getting ImageReader object to call setInput() in test case to verify the behavior of reader.abort(). So I have created separate bug for the same (https://bugs.openjdk.java.net/browse/JDK-8164930 ). And in case of WBMP we already have clearAbortRequest() call and also we are returning from IIOReadProgressListener callbacks properly, only thing here is we are not returning right after callbacks as we have updated other plugins. >> >> I want to verify writer plugins in separate bug as we already have lot of changes in this bug. So I have created https://bugs.openjdk.java.net/browse/JDK-8164931 and will be working on this bug. >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Phil Race >> Sent: Thursday, August 18, 2016 1:42 AM >> To: Sergey Bylokhov >> Cc: Jayathirth D V; Prasanta Sadhukhan; 2d-dev >> Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() >> method does not work when called inside imageStarted for PNG >> >> I think we can >> - get all plugins,and for each >> - write a file in that format >> - read it back and apply the test >> >> It is also worth verifying that the writer abort checks are in sync with the reader aborts, ie happen at such equivalent points as might exist. >> >> -phil. >> >> On 08/15/2016 11:30 AM, Sergey Bylokhov wrote: >>> Is it possible to unify the test for all our plugins? I assume they >>> should work in the same way. I am not sure but probably the image can >>> be generated at runtime? >>> >>> On 11.08.16 21:59, Jayathirth D V wrote: >>>> Hi, >>>> >>>> >>>> >>>> Please review the following fix in JDK9 at your convenience: >>>> >>>> >>>> >>>> Bug : https://bugs.openjdk.java.net/browse/JDK-4924727 >>>> >>>> >>>> >>>> Webrev : http://cr.openjdk.java.net/~jdv/4924727/webrev.00/ >>>> >>>> >>>> >>>> Issue : When we issue ImageReader.abort() in >>>> IIOReadProgressListener.imageStarted(), reading is not aborted and >>>> it is continued. >>>> >>>> >>>> >>>> Root cause : After IIOReadProgressListener.imageStarted() call in >>>> PNGImageReader.java when we enter decodeImage() we call >>>> clearAbortRequest() which will clear the abort request from >>>> IIOReadProgressListener.imageStarted(). >>>> >>>> >>>> >>>> Solution : clearAbortRequest() documentation mentions that it should >>>> be called before reading of image starts, so it should be called >>>> before IIOReadProgressListener.imageStarted()(In PNGImageReader.java >>>> it is >>>> processImageStarted(0) in readImage()). So moved clearAbortRequest() >>>> call from decodeImage() to readImage(). Also we should call >>>> abortRequested() in PNGImageReader.java at places mapping to >>>> IIOReadProgressListener and not randomly at end of functions or at >>>> places related to IIOReadUpdateListener, updated the code for the same. >>>> >>>> >>>> >>>> >>>> >>>> Observation not related to this issue : We don't have call similar >>>> to >>>> IIOReadProgressListener.readAborted() in IIOReadUpdateListener, but >>>> user can call ImageReader.abort() from IIOReadUpdateListener methods. >>>> Is there a need to add similar method in IIOReadUpdateListener? Any >>>> inputs on this also would be helpful. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Jay >>>> >>> >>> >> > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From prem.balakrishnan at oracle.com Tue Aug 30 06:17:29 2016 From: prem.balakrishnan at oracle.com (Prem Balakrishnan) Date: Mon, 29 Aug 2016 23:17:29 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails In-Reply-To: <57BFE3BC.5050500@oracle.com> References: <1d62d8f6-c7e6-e5c6-38e2-1764fea8011b@oracle.com> <94e9c6a3-2e9f-4405-a5c5-1e4dadeba7d9@default> <3e53ac2e-ba9b-b4e9-3ebd-bccb35bc6650@oracle.com> <75f3e1d7-dfc0-4d0c-84d9-192b306d0728@default> <57BAA36E.2010704@oracle.com> <197cdc08-165e-412d-9254-69c069e4fe47@default> <57BFE3BC.5050500@oracle.com> Message-ID: Reminder From: Prasanta Sadhukhan Sent: Friday, August 26, 2016 12:08 PM To: Prem Balakrishnan; 2d-dev at openjdk.java.net Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails Ok. so long you are addressing the opengl issue albeit via different bugid, it's ok with me. +1. Regards Prasanta On 8/26/2016 11:56 AM, Prem Balakrishnan wrote: Hi Prasanta, Thankyou for the review. The code compiles , Actual scenario is as below: public class Temp { AccelSurface as = new AccelSurface() {}; SurfaceData sd = (SurfaceData)as; } class SurfaceData {} interface Surface {} interface AccelSurface extends Surface{} class D3DSurfaceData extends SurfaceData implements AccelSurface{} class OGLSurfaceData extends SurfaceData implements AccelSurface{} ------------------- In suggested fix, the SurfaceData is always of type D3DSurfaceData. And hence getDefaultScaleX/Y holds good. OpenGL rendering is handled in a different flow. HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.02/"http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.02/ Suggested fix also resolves the following failures on hidpi windows 8 javax/swing/JWindow/ShapedAndTranslucentWindows/PerPixelTranslucent.java javax/swing/JWindow/ShapedAndTranslucentWindows/PerPixelTranslucentGradient.java javax/swing/JWindow/ShapedAndTranslucentWindows/SetShapeAndClickSwing.java javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedPerPixelTranslucentGradient.java javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedTranslucentPerPixelTranslucentGradient.java javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java ---------------------- OpenGL Rendering issue will be addressed in HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8164811"JDK-8164811 Regards, Prem From: Prasanta Sadhukhan Sent: Monday, August 22, 2016 12:32 PM To: Prem Balakrishnan; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails I wonder how it compiles? I tried a small program ------------------ public class Test { AccelSurface b = new AccelSurface(); SurfaceData c = (SurfaceData)b; } class SurfaceData extends Surface {} class Surface {} class AccelSurface extends Surface {} --------- and it fails to compile Test.java:3: error: incompatible types: AccelSurface cannot be converted to SurfaceData SurfaceData c = (SurfaceData)b; ANyways, did you check with opengl pipeline? It seems getDefaultScaleX/Y is not present in OGLSurfaceData which will result in falling back to SurfaceData in which case the scale will be 1. Regards Prasanta On 8/18/2016 3:12 PM, Prem Balakrishnan wrote: Added "2d-dev" team for review Regards, Prem From: Alexandr Scherbatiy Sent: Thursday, August 18, 2016 2:57 PM To: Prem Balakrishnan; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails Could you also send the review to the 2d-dev alias? Thanks, Alexandr. On 8/18/2016 9:59 AM, Prem Balakrishnan wrote: Hi Alexandr, AccelSurface is implemented by *ONLY* D3DSurfaceData and OGLSurfaceData classes, Both of these classes extend SurfaceData as well. Hence, casting of 'as' variable which is of type AccelSurface object to SurfaceData is always VALID. Regards, Prem From: Alexandr Scherbatiy Sent: Wednesday, August 17, 2016 4:42 PM To: Prem Balakrishnan; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails On 8/17/2016 11:30 AM, Prem Balakrishnan wrote: Hi Alexandr, Thankyou for the review. YES scaled SurfaceData returns proper scale values from getDefaultScaleX()/getDefaultScaleY(), which I have used in the current patch. Please review the updated patch HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.02/"http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.02/ Is it always true that the 'as' variable which has type AccelSurface in the fix is always instance of SurfaceData? Thanks, Alexandr. Regards, Prem From: Alexandr Scherbatiy Sent: Tuesday, August 16, 2016 10:06 PM To: Prem Balakrishnan; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails On 8/16/2016 7:35 AM, Prem Balakrishnan wrote: Reminder From: Prem Balakrishnan Sent: Friday, August 12, 2016 6:36 PM To: Alexander Scherbatiy; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: RE: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails Hi Alexandr and Sergey, Please review the updated patch. HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.01/"http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.01/ >>"It is a little bit strange bug, because VolatileImage should handle this scale internally, and create double sized surface when necessary".-Sergey Yes as you mentioned Volatile Image is getting scaled internally. Thanks for the feedback. Cause: In VIOptWindowPainter::updateWindowAccel(psdops, w, h) call, width and height were passed without scaling, which was creating a bitmap of specified width and height, hence the output was clipped. I just have two general questions. - The scaled SurfaceData should return proper scales from getDefaultScaleX()/getDefaultScaleY() methods. Do these methods return right values after setting the scaled image sizes in the fix? - Region.clipScale() which is used in many places rounds values. The usual rule is to use Math.floor() for image coordinates rounding and Math.ceil() for sizes. Should the same rule be applicable here? Thanks, Alexandr. Regards, Prem From: Alexandr Scherbatiy Sent: Thursday, August 04, 2016 6:23 PM To: Prem Balakrishnan; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails On 8/3/2016 10:04 AM, Prem Balakrishnan wrote: Hi, Please review fix for JDK9, Bug: https://bugs.openjdk.java.net/browse/JDK-8144735 Webrev: http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.00/ Issue: javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails Cause: While creating Transparent VolatileImage, width and height was NOT hidpi scaled. Fix: VolatileImage width and height are scaled. I believe this is an issue in AWT and needs to be discussed on awt-dev alias. Should the backbuffer width and height be also scaled for the BIWindowPainter? Thanks, Alexandr. Thanks, Prem -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Wed Aug 31 06:55:08 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 31 Aug 2016 12:25:08 +0530 Subject: [OpenJDK 2D-Dev] RFR: 8164818: Reg. test java/awt/font/TextLayout/VisibleAdvance.java fails In-Reply-To: <57BF7C46.90703@oracle.com> References: <57BF7C46.90703@oracle.com> Message-ID: <57C67F4C.9010801@oracle.com> Looks good to me. Regards Prasanta On 8/26/2016 4:46 AM, Philip Race wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8164818 > webrev: http://cr.openjdk.java.net/~prr/8164818/ > > 26.6 fixed point was being used in harfbuzz interface code > and 16.16 elsewhere so we had a precision mismatch. > More details in the bug report. > > -phil. From jayathirth.d.v at oracle.com Wed Aug 31 10:07:59 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 31 Aug 2016 03:07:59 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() method does not work when called inside imageStarted for PNG In-Reply-To: References: <06aa9e0a-bf19-4dd0-949a-c3c0cb00d4b1@default> <57B4C50F.6050809@oracle.com> <5a23861e-448c-4d23-8704-0bbc7c2148d2@default> <4fa0630e-9a97-805d-a603-0d4e51c64e74@oracle.com> <46d689e7-6246-451d-ba98-7bbfd93ef163@default> Message-ID: Hi Sergey, Thanks for the clarification. I have updated the test case to use Files.delete(). Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/4924727/webrev.02/ Regards, Jay -----Original Message----- From: Sergey Bylokhov Sent: Monday, August 29, 2016 8:52 PM To: Jayathirth D V Cc: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() method does not work when called inside imageStarted for PNG On 29.08.16 18:07, Jayathirth D V wrote: > Hi Sergey, > > I am not getting the usage of Files.delete() from its specification. Can you please elaborate what special case it will handle in my test case? > I am creating temporary file separately for all the readers and deleting them. Files.delete() will throw an exception if the file cannot be deleted, and File.delete() will return false in such case. Also I am closing the ImageInputStream associated after read operation. But plugin itself can leak some streams and lock a temporary file, so Files.delete() will catch this. > -----Original Message----- > From: Sergey Bylokhov > Sent: Monday, August 29, 2016 8:25 PM > To: Jayathirth D V; Philip Race > Cc: Prasanta Sadhukhan; 2d-dev > Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() method does not work when called inside imageStarted for PNG > > Hi, Jay. > Please delete the temporary file via Files.delete(), which will throw an exception if the file is locked by some reader. > > On 29.08.16 11:42, Jayathirth D V wrote: >> Hi Phil & Sergey, >> >> Thanks for your inputs. >> >> I have verified reader.abort() request for IIOReadProgressListener for all available plugins. >> >> Apart from PNG although all readers were able to abort read when we call reader.abort() from IIOReadProgressListener callbacks, they were not calling processReadAborted() right after IIOReadProgressListener callbacks. So I have made changes for the same. >> >> And in some readers before every read call they were not calling clearAbortRequest(), which is important because if we use same reader for another read() call it will be invalid unless we clear previous abort request. >> >> In case of JPEG since we are using native IJG library we need to update abortFlag present in imageioJPEG.c before every call as we are doing for other readers using clearAbortRequest(). >> >> Since this has native and make changes I have verified changes through >> JPRT also which is successfully building on all platforms >> (http://scaaa637.us.oracle.com//archive/2016/08/2016-08-29-065104.jay. >> client_commit//JobStatus.txt ) >> >> Please find updated webrev for review: >> http://cr.openjdk.java.net/~jdv/4924727/webrev.01/ >> >> I noticed that in case on WBMP I was not getting ImageReader object to call setInput() in test case to verify the behavior of reader.abort(). So I have created separate bug for the same (https://bugs.openjdk.java.net/browse/JDK-8164930 ). And in case of WBMP we already have clearAbortRequest() call and also we are returning from IIOReadProgressListener callbacks properly, only thing here is we are not returning right after callbacks as we have updated other plugins. >> >> I want to verify writer plugins in separate bug as we already have lot of changes in this bug. So I have created https://bugs.openjdk.java.net/browse/JDK-8164931 and will be working on this bug. >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Phil Race >> Sent: Thursday, August 18, 2016 1:42 AM >> To: Sergey Bylokhov >> Cc: Jayathirth D V; Prasanta Sadhukhan; 2d-dev >> Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() >> method does not work when called inside imageStarted for PNG >> >> I think we can >> - get all plugins,and for each >> - write a file in that format >> - read it back and apply the test >> >> It is also worth verifying that the writer abort checks are in sync with the reader aborts, ie happen at such equivalent points as might exist. >> >> -phil. >> >> On 08/15/2016 11:30 AM, Sergey Bylokhov wrote: >>> Is it possible to unify the test for all our plugins? I assume they >>> should work in the same way. I am not sure but probably the image can >>> be generated at runtime? >>> >>> On 11.08.16 21:59, Jayathirth D V wrote: >>>> Hi, >>>> >>>> >>>> >>>> Please review the following fix in JDK9 at your convenience: >>>> >>>> >>>> >>>> Bug : https://bugs.openjdk.java.net/browse/JDK-4924727 >>>> >>>> >>>> >>>> Webrev : http://cr.openjdk.java.net/~jdv/4924727/webrev.00/ >>>> >>>> >>>> >>>> Issue : When we issue ImageReader.abort() in >>>> IIOReadProgressListener.imageStarted(), reading is not aborted and >>>> it is continued. >>>> >>>> >>>> >>>> Root cause : After IIOReadProgressListener.imageStarted() call in >>>> PNGImageReader.java when we enter decodeImage() we call >>>> clearAbortRequest() which will clear the abort request from >>>> IIOReadProgressListener.imageStarted(). >>>> >>>> >>>> >>>> Solution : clearAbortRequest() documentation mentions that it should >>>> be called before reading of image starts, so it should be called >>>> before IIOReadProgressListener.imageStarted()(In PNGImageReader.java >>>> it is >>>> processImageStarted(0) in readImage()). So moved clearAbortRequest() >>>> call from decodeImage() to readImage(). Also we should call >>>> abortRequested() in PNGImageReader.java at places mapping to >>>> IIOReadProgressListener and not randomly at end of functions or at >>>> places related to IIOReadUpdateListener, updated the code for the same. >>>> >>>> >>>> >>>> >>>> >>>> Observation not related to this issue : We don't have call similar >>>> to >>>> IIOReadProgressListener.readAborted() in IIOReadUpdateListener, but >>>> user can call ImageReader.abort() from IIOReadUpdateListener methods. >>>> Is there a need to add similar method in IIOReadUpdateListener? Any >>>> inputs on this also would be helpful. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Jay >>>> >>> >>> >> > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Wed Aug 31 10:16:55 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 31 Aug 2016 15:46:55 +0530 Subject: [OpenJDK 2D-Dev] RFR: 8144015: [PIT] failures of text layout font tests In-Reply-To: <57BF5ECF.2010800@oracle.com> References: <57BF5ECF.2010800@oracle.com> Message-ID: <57C6AE97.6080003@oracle.com> Looks ok to me. Regards Prasanta On 8/26/2016 2:40 AM, Phil Race wrote: > > Webrev: http://cr.openjdk.java.net/~prr/8144015/ > > This RFR encompasses changes that are sufficiently related > to keep them all together and they deserve testing as a whole. > Multiple test failures are resolved. A list is below. > > Notable highlights > ExtendedTextSourceLabel.createCharinfo() can now handle > cases where the glyph count is less than the char count. > This was not just a problem in 9 (harfbuzz) but has been > observed on 8 too (8041480 in the list below). > The fundamental change is to abandon the idea of > updating in place which added complexity and was > never going to work if you had too few glyphs .. > > HBShaper.c > - Fixed that kerning was always enabled > - Simplified - and corrected - the code that stored the resulting data > - Stopped using throwing an exception as a way to expand storage > - Cleaned up JNI usage > > Tests have been added/updated/open sourced as necessary. > > JPRT passed these changes. > > > Bugs fixed by this change : > https://bugs.openjdk.java.net/browse/JDK-8144015 > 8144015: [PIT] failures of text layout font tests > > ** https://bugs.openjdk.java.net/browse/JDK-8144023 > 8144023: [PIT] failure of text measurements in > javax/swing/text/html/parser/Parser/6836089/bug6836089.java > > ** https://bugs.openjdk.java.net/browse/JDK-8145542 > 8145542: The case failed automatically and thrown > java.lang.ArrayIndexOutOfBoundsException exception > > ** https://bugs.openjdk.java.net/browse/JDK-8151725 > 8151725: [macosx] ArrayIndexOOB exception when displaying Devanagari > text in JEditorPane > > ** https://bugs.openjdk.java.net/browse/JDK-8144240 > 8144240: [macosx][PIT] AIOOB in > closed/javax/swing/text/GlyphPainter2/6427244/bug6427244.java > > https://bugs.openjdk.java.net/browse/JDK-8152680 > 8152680: Regression in GlyphVector.getGlyphCharIndex behaviour > > ** https://bugs.openjdk.java.net/browse/JDK-8158924 > 8158924: Incorrect i18n text document layout > > ** https://bugs.openjdk.java.net/browse/JDK-8041480 > 8041480: ArrayIndexOutOfBoundsException when JTable contains certain > string > > -phil. From Sergey.Bylokhov at oracle.com Wed Aug 31 10:51:40 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 31 Aug 2016 13:51:40 +0300 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() method does not work when called inside imageStarted for PNG In-Reply-To: References: <06aa9e0a-bf19-4dd0-949a-c3c0cb00d4b1@default> <57B4C50F.6050809@oracle.com> <5a23861e-448c-4d23-8704-0bbc7c2148d2@default> <4fa0630e-9a97-805d-a603-0d4e51c64e74@oracle.com> <46d689e7-6246-451d-ba98-7bbfd93ef163@default> Message-ID: <7a36a7ae-549d-333d-a395-afd7f2472a36@oracle.com> I have only one question: should we call the new clearNativeReadAbortFlag(and probably the others processXXX()) under the ThreadLock? On 31.08.16 13:07, Jayathirth D V wrote: > Hi Sergey, > > Thanks for the clarification. > I have updated the test case to use Files.delete(). > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/4924727/webrev.02/ > > Regards, > Jay > > -----Original Message----- > From: Sergey Bylokhov > Sent: Monday, August 29, 2016 8:52 PM > To: Jayathirth D V > Cc: 2d-dev > Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() method does not work when called inside imageStarted for PNG > > On 29.08.16 18:07, Jayathirth D V wrote: >> Hi Sergey, >> >> I am not getting the usage of Files.delete() from its specification. Can you please elaborate what special case it will handle in my test case? >> I am creating temporary file separately for all the readers and deleting them. > > Files.delete() will throw an exception if the file cannot be deleted, and File.delete() will return false in such case. > > Also I am closing the ImageInputStream associated after read operation. > > But plugin itself can leak some streams and lock a temporary file, so > Files.delete() will catch this. > > >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Monday, August 29, 2016 8:25 PM >> To: Jayathirth D V; Philip Race >> Cc: Prasanta Sadhukhan; 2d-dev >> Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() method does not work when called inside imageStarted for PNG >> >> Hi, Jay. >> Please delete the temporary file via Files.delete(), which will throw an exception if the file is locked by some reader. >> >> On 29.08.16 11:42, Jayathirth D V wrote: >>> Hi Phil & Sergey, >>> >>> Thanks for your inputs. >>> >>> I have verified reader.abort() request for IIOReadProgressListener for all available plugins. >>> >>> Apart from PNG although all readers were able to abort read when we call reader.abort() from IIOReadProgressListener callbacks, they were not calling processReadAborted() right after IIOReadProgressListener callbacks. So I have made changes for the same. >>> >>> And in some readers before every read call they were not calling clearAbortRequest(), which is important because if we use same reader for another read() call it will be invalid unless we clear previous abort request. >>> >>> In case of JPEG since we are using native IJG library we need to update abortFlag present in imageioJPEG.c before every call as we are doing for other readers using clearAbortRequest(). >>> >>> Since this has native and make changes I have verified changes through >>> JPRT also which is successfully building on all platforms >>> (http://scaaa637.us.oracle.com//archive/2016/08/2016-08-29-065104.jay. >>> client_commit//JobStatus.txt ) >>> >>> Please find updated webrev for review: >>> http://cr.openjdk.java.net/~jdv/4924727/webrev.01/ >>> >>> I noticed that in case on WBMP I was not getting ImageReader object to call setInput() in test case to verify the behavior of reader.abort(). So I have created separate bug for the same (https://bugs.openjdk.java.net/browse/JDK-8164930 ). And in case of WBMP we already have clearAbortRequest() call and also we are returning from IIOReadProgressListener callbacks properly, only thing here is we are not returning right after callbacks as we have updated other plugins. >>> >>> I want to verify writer plugins in separate bug as we already have lot of changes in this bug. So I have created https://bugs.openjdk.java.net/browse/JDK-8164931 and will be working on this bug. >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Phil Race >>> Sent: Thursday, August 18, 2016 1:42 AM >>> To: Sergey Bylokhov >>> Cc: Jayathirth D V; Prasanta Sadhukhan; 2d-dev >>> Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() >>> method does not work when called inside imageStarted for PNG >>> >>> I think we can >>> - get all plugins,and for each >>> - write a file in that format >>> - read it back and apply the test >>> >>> It is also worth verifying that the writer abort checks are in sync with the reader aborts, ie happen at such equivalent points as might exist. >>> >>> -phil. >>> >>> On 08/15/2016 11:30 AM, Sergey Bylokhov wrote: >>>> Is it possible to unify the test for all our plugins? I assume they >>>> should work in the same way. I am not sure but probably the image can >>>> be generated at runtime? >>>> >>>> On 11.08.16 21:59, Jayathirth D V wrote: >>>>> Hi, >>>>> >>>>> >>>>> >>>>> Please review the following fix in JDK9 at your convenience: >>>>> >>>>> >>>>> >>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-4924727 >>>>> >>>>> >>>>> >>>>> Webrev : http://cr.openjdk.java.net/~jdv/4924727/webrev.00/ >>>>> >>>>> >>>>> >>>>> Issue : When we issue ImageReader.abort() in >>>>> IIOReadProgressListener.imageStarted(), reading is not aborted and >>>>> it is continued. >>>>> >>>>> >>>>> >>>>> Root cause : After IIOReadProgressListener.imageStarted() call in >>>>> PNGImageReader.java when we enter decodeImage() we call >>>>> clearAbortRequest() which will clear the abort request from >>>>> IIOReadProgressListener.imageStarted(). >>>>> >>>>> >>>>> >>>>> Solution : clearAbortRequest() documentation mentions that it should >>>>> be called before reading of image starts, so it should be called >>>>> before IIOReadProgressListener.imageStarted()(In PNGImageReader.java >>>>> it is >>>>> processImageStarted(0) in readImage()). So moved clearAbortRequest() >>>>> call from decodeImage() to readImage(). Also we should call >>>>> abortRequested() in PNGImageReader.java at places mapping to >>>>> IIOReadProgressListener and not randomly at end of functions or at >>>>> places related to IIOReadUpdateListener, updated the code for the same. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Observation not related to this issue : We don't have call similar >>>>> to >>>>> IIOReadProgressListener.readAborted() in IIOReadUpdateListener, but >>>>> user can call ImageReader.abort() from IIOReadUpdateListener methods. >>>>> Is there a need to add similar method in IIOReadUpdateListener? Any >>>>> inputs on this also would be helpful. >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Jay >>>>> >>>> >>>> >>> >> >> >> -- >> Best regards, Sergey. >> > > -- Best regards, Sergey. From jayathirth.d.v at oracle.com Wed Aug 31 11:48:19 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 31 Aug 2016 04:48:19 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() method does not work when called inside imageStarted for PNG In-Reply-To: <7a36a7ae-549d-333d-a395-afd7f2472a36@oracle.com> References: <06aa9e0a-bf19-4dd0-949a-c3c0cb00d4b1@default> <57B4C50F.6050809@oracle.com> <5a23861e-448c-4d23-8704-0bbc7c2148d2@default> <4fa0630e-9a97-805d-a603-0d4e51c64e74@oracle.com> <46d689e7-6246-451d-ba98-7bbfd93ef163@default> <7a36a7ae-549d-333d-a395-afd7f2472a36@oracle.com> Message-ID: <6b764a34-e9fb-473a-ace7-f0d4bacb9928@default> Hi Sergey, In case of JPEG whole read process is under a ThreadLock. public BufferedImage read(int imageIndex, ImageReadParam param) throws IOException { setThreadLock(); try { cbLock.check(); try { readInternal(imageIndex, param, false); By others processXXX() do you mean processXXX() in other plugins or processXXX() in case of JPEG? Please clarify. Thanks, Jay -----Original Message----- From: Sergey Bylokhov Sent: Wednesday, August 31, 2016 4:22 PM To: Jayathirth D V; Philip Race Cc: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() method does not work when called inside imageStarted for PNG I have only one question: should we call the new clearNativeReadAbortFlag(and probably the others processXXX()) under the ThreadLock? On 31.08.16 13:07, Jayathirth D V wrote: > Hi Sergey, > > Thanks for the clarification. > I have updated the test case to use Files.delete(). > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/4924727/webrev.02/ > > Regards, > Jay > > -----Original Message----- > From: Sergey Bylokhov > Sent: Monday, August 29, 2016 8:52 PM > To: Jayathirth D V > Cc: 2d-dev > Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() > method does not work when called inside imageStarted for PNG > > On 29.08.16 18:07, Jayathirth D V wrote: >> Hi Sergey, >> >> I am not getting the usage of Files.delete() from its specification. Can you please elaborate what special case it will handle in my test case? >> I am creating temporary file separately for all the readers and deleting them. > > Files.delete() will throw an exception if the file cannot be deleted, and File.delete() will return false in such case. > > Also I am closing the ImageInputStream associated after read operation. > > But plugin itself can leak some streams and lock a temporary file, so > Files.delete() will catch this. > > >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Monday, August 29, 2016 8:25 PM >> To: Jayathirth D V; Philip Race >> Cc: Prasanta Sadhukhan; 2d-dev >> Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() >> method does not work when called inside imageStarted for PNG >> >> Hi, Jay. >> Please delete the temporary file via Files.delete(), which will throw an exception if the file is locked by some reader. >> >> On 29.08.16 11:42, Jayathirth D V wrote: >>> Hi Phil & Sergey, >>> >>> Thanks for your inputs. >>> >>> I have verified reader.abort() request for IIOReadProgressListener for all available plugins. >>> >>> Apart from PNG although all readers were able to abort read when we call reader.abort() from IIOReadProgressListener callbacks, they were not calling processReadAborted() right after IIOReadProgressListener callbacks. So I have made changes for the same. >>> >>> And in some readers before every read call they were not calling clearAbortRequest(), which is important because if we use same reader for another read() call it will be invalid unless we clear previous abort request. >>> >>> In case of JPEG since we are using native IJG library we need to update abortFlag present in imageioJPEG.c before every call as we are doing for other readers using clearAbortRequest(). >>> >>> Since this has native and make changes I have verified changes >>> through JPRT also which is successfully building on all platforms >>> (http://scaaa637.us.oracle.com//archive/2016/08/2016-08-29-065104.jay. >>> client_commit//JobStatus.txt ) >>> >>> Please find updated webrev for review: >>> http://cr.openjdk.java.net/~jdv/4924727/webrev.01/ >>> >>> I noticed that in case on WBMP I was not getting ImageReader object to call setInput() in test case to verify the behavior of reader.abort(). So I have created separate bug for the same (https://bugs.openjdk.java.net/browse/JDK-8164930 ). And in case of WBMP we already have clearAbortRequest() call and also we are returning from IIOReadProgressListener callbacks properly, only thing here is we are not returning right after callbacks as we have updated other plugins. >>> >>> I want to verify writer plugins in separate bug as we already have lot of changes in this bug. So I have created https://bugs.openjdk.java.net/browse/JDK-8164931 and will be working on this bug. >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Phil Race >>> Sent: Thursday, August 18, 2016 1:42 AM >>> To: Sergey Bylokhov >>> Cc: Jayathirth D V; Prasanta Sadhukhan; 2d-dev >>> Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() >>> method does not work when called inside imageStarted for PNG >>> >>> I think we can >>> - get all plugins,and for each >>> - write a file in that format >>> - read it back and apply the test >>> >>> It is also worth verifying that the writer abort checks are in sync with the reader aborts, ie happen at such equivalent points as might exist. >>> >>> -phil. >>> >>> On 08/15/2016 11:30 AM, Sergey Bylokhov wrote: >>>> Is it possible to unify the test for all our plugins? I assume they >>>> should work in the same way. I am not sure but probably the image >>>> can be generated at runtime? >>>> >>>> On 11.08.16 21:59, Jayathirth D V wrote: >>>>> Hi, >>>>> >>>>> >>>>> >>>>> Please review the following fix in JDK9 at your convenience: >>>>> >>>>> >>>>> >>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-4924727 >>>>> >>>>> >>>>> >>>>> Webrev : http://cr.openjdk.java.net/~jdv/4924727/webrev.00/ >>>>> >>>>> >>>>> >>>>> Issue : When we issue ImageReader.abort() in >>>>> IIOReadProgressListener.imageStarted(), reading is not aborted and >>>>> it is continued. >>>>> >>>>> >>>>> >>>>> Root cause : After IIOReadProgressListener.imageStarted() call in >>>>> PNGImageReader.java when we enter decodeImage() we call >>>>> clearAbortRequest() which will clear the abort request from >>>>> IIOReadProgressListener.imageStarted(). >>>>> >>>>> >>>>> >>>>> Solution : clearAbortRequest() documentation mentions that it >>>>> should be called before reading of image starts, so it should be >>>>> called before IIOReadProgressListener.imageStarted()(In >>>>> PNGImageReader.java it is >>>>> processImageStarted(0) in readImage()). So moved >>>>> clearAbortRequest() call from decodeImage() to readImage(). Also >>>>> we should call >>>>> abortRequested() in PNGImageReader.java at places mapping to >>>>> IIOReadProgressListener and not randomly at end of functions or at >>>>> places related to IIOReadUpdateListener, updated the code for the same. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Observation not related to this issue : We don't have call similar >>>>> to >>>>> IIOReadProgressListener.readAborted() in IIOReadUpdateListener, >>>>> but user can call ImageReader.abort() from IIOReadUpdateListener methods. >>>>> Is there a need to add similar method in IIOReadUpdateListener? >>>>> Any inputs on this also would be helpful. >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Jay >>>>> >>>> >>>> >>> >> >> >> -- >> Best regards, Sergey. >> > > -- Best regards, Sergey. From vadim.pakhnushev at oracle.com Wed Aug 31 11:29:59 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Wed, 31 Aug 2016 14:29:59 +0300 Subject: [OpenJDK 2D-Dev] Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails In-Reply-To: References: <1d62d8f6-c7e6-e5c6-38e2-1764fea8011b@oracle.com> <94e9c6a3-2e9f-4405-a5c5-1e4dadeba7d9@default> <3e53ac2e-ba9b-b4e9-3ebd-bccb35bc6650@oracle.com> <75f3e1d7-dfc0-4d0c-84d9-192b306d0728@default> <57BAA36E.2010704@oracle.com> <197cdc08-165e-412d-9254-69c069e4fe47@default> <57BFE3BC.5050500@oracle.com> Message-ID: <7da9c7b5-8798-d5bf-d085-ab6affcdfc8f@oracle.com> Prem, I believe it's possible to use AccelSurface.getBounds() method and skip casting to SurfaceData completely. The calculations are basically the same. According to the comments in the TranslucentWindowPainter.createInstance you will get BIWindowPainter even for OpenGL pipeline unless you force optimized path via sun.java2d.twp.forceopt so you will need to check these paths in the fix for OpenGL. Thanks, Vadim On 30.08.2016 9:17, Prem Balakrishnan wrote: > > Reminder > > *From:*Prasanta Sadhukhan > *Sent:* Friday, August 26, 2016 12:08 PM > *To:* Prem Balakrishnan; 2d-dev at openjdk.java.net > *Subject:* Re: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > Ok. so long you are addressing the opengl issue albeit via different > bugid, it's ok with me. +1. > > Regards > Prasanta > > On 8/26/2016 11:56 AM, Prem Balakrishnan wrote: > > Hi Prasanta, > > Thankyou for the review. > > The code compiles , Actual scenario is as below: > > public class Temp { > > AccelSurface as = new AccelSurface() {}; > > SurfaceData sd = (SurfaceData)as; > > } > > class SurfaceData {} > > interface Surface {} > > interface AccelSurface extends Surface{} > > class D3DSurfaceData extends SurfaceData implements AccelSurface{} > > class OGLSurfaceData extends SurfaceData implements AccelSurface{} > > ------------------- > > In suggested fix, the SurfaceData is always of type D3DSurfaceData. > > And hence getDefaultScaleX/Y holds good. OpenGL rendering is > handled in a different flow. > > http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.02/ > > > Suggested fix also resolves the following failures on hidpi windows 8 > > javax/swing/JWindow/ShapedAndTranslucentWindows/PerPixelTranslucent.java > > javax/swing/JWindow/ShapedAndTranslucentWindows/PerPixelTranslucentGradient.java > > javax/swing/JWindow/ShapedAndTranslucentWindows/SetShapeAndClickSwing.java > > javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedPerPixelTranslucentGradient.java > > javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedTranslucentPerPixelTranslucentGradient.java > > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > > ---------------------- > OpenGL Rendering issue will be addressed in JDK-8164811 > > > > > Regards, > > Prem > > *From:*Prasanta Sadhukhan > *Sent:* Monday, August 22, 2016 12:32 PM > *To:* Prem Balakrishnan; Rajeev Chamyal; awt-dev at openjdk.java.net > ; 2d-dev at openjdk.java.net > > *Subject:* Re: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > I wonder how it compiles? > I tried a small program > ------------------ > public class Test { > AccelSurface b = new AccelSurface(); > SurfaceData c = (SurfaceData)b; > } > > class SurfaceData extends Surface {} > class Surface {} > class AccelSurface extends Surface {} > --------- > and it fails to compile > Test.java:3: error: incompatible types: AccelSurface cannot be > converted to SurfaceData > SurfaceData c = (SurfaceData)b; > > ANyways, did you check with opengl pipeline? It seems > getDefaultScaleX/Y is not present in OGLSurfaceData which will > result in falling back to SurfaceData in which case the scale will > be 1. > > Regards > Prasanta > > On 8/18/2016 3:12 PM, Prem Balakrishnan wrote: > > Added ?2d-dev? team for review > > Regards, > > Prem > > *From:*Alexandr Scherbatiy > *Sent:* Thursday, August 18, 2016 2:57 PM > *To:* Prem Balakrishnan; Rajeev Chamyal; > awt-dev at openjdk.java.net ; > Sergey Bylokhov > *Subject:* Re: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > Could you also send the review to the 2d-dev alias? > > Thanks, > Alexandr. > > On 8/18/2016 9:59 AM, Prem Balakrishnan wrote: > > Hi Alexandr, > > AccelSurface is implemented by *ONLY* D3DSurfaceData and > OGLSurfaceData classes, > > Both of these classes extend SurfaceData as well. > > Hence, casting of 'as' variable which is of type > AccelSurface object to SurfaceData is always VALID. > > Regards, > Prem > > *From:*Alexandr Scherbatiy > *Sent:* Wednesday, August 17, 2016 4:42 PM > *To:* Prem Balakrishnan; Rajeev Chamyal; > awt-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > On 8/17/2016 11:30 AM, Prem Balakrishnan wrote: > > > > > Hi Alexandr, > > Thankyou for the review. > > YES scaled SurfaceData returns proper scale values from > getDefaultScaleX()/getDefaultScaleY(), which I have used > in the current patch. > > Please review the updated patch > > http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.02/ > > > Is it always true that the 'as' variable which has type > AccelSurface in the fix is always instance of SurfaceData? > > Thanks, > Alexandr. > > > > > Regards, > Prem > > *From:*Alexandr Scherbatiy > *Sent:* Tuesday, August 16, 2016 10:06 PM > *To:* Prem Balakrishnan; Rajeev Chamyal; > awt-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > On 8/16/2016 7:35 AM, Prem Balakrishnan wrote: > > > > > > Reminder > > *From:*Prem Balakrishnan > *Sent:* Friday, August 12, 2016 6:36 PM > *To:* Alexander Scherbatiy; Rajeev Chamyal; > awt-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* RE: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > Hi Alexandr and Sergey, > > Please review the updated patch. > > http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.01/ > > > >>?It is a little bit strange bug, because VolatileImage > should handle this scale internally, and create double > sized surface when necessary?.-Sergey > > Yes as you mentioned Volatile Image is getting scaled > internally. Thanks for the feedback. > > *Cause:*In VIOptWindowPainter::updateWindowAccel(psdops, w, > h) call, width and height were passed without scaling, > > which was creating a bitmap of specified width and height, > hence the output was clipped. > > > I just have two general questions. > - The scaled SurfaceData should return proper scales > from getDefaultScaleX()/getDefaultScaleY() methods. Do > these methods return right values after setting the scaled > image sizes in the fix? > - Region.clipScale() which is used in many places rounds > values. The usual rule is to use Math.floor() for image > coordinates rounding and Math.ceil() for sizes. > Should the same rule be applicable here? > > Thanks, > Alexandr. > > > > > > > > Regards, > > Prem > > *From:*Alexandr Scherbatiy > *Sent:* Thursday, August 04, 2016 6:23 PM > *To:* Prem Balakrishnan; Rajeev Chamyal; > awt-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > On 8/3/2016 10:04 AM, Prem Balakrishnan wrote: > > Hi, > > Please review fix for JDK9, > > *Bug:*https://bugs.openjdk.java.net/browse/JDK-8144735 > > *Webrev:*http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.00/ > > > *Issue:* > > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > *Cause:* > > While creating Transparent VolatileImage, width and height > was NOT hidpi scaled. > > *Fix: *VolatileImage width and height are scaled. > > > I believe this is an issue in AWT and needs to be > discussed on awt-dev alias. > > Should the backbuffer width and height be also scaled > for the BIWindowPainter? > > Thanks, > Alexandr. > > Thanks, > > Prem > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Wed Aug 31 12:37:32 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 31 Aug 2016 15:37:32 +0300 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() method does not work when called inside imageStarted for PNG In-Reply-To: <6b764a34-e9fb-473a-ace7-f0d4bacb9928@default> References: <06aa9e0a-bf19-4dd0-949a-c3c0cb00d4b1@default> <57B4C50F.6050809@oracle.com> <5a23861e-448c-4d23-8704-0bbc7c2148d2@default> <4fa0630e-9a97-805d-a603-0d4e51c64e74@oracle.com> <46d689e7-6246-451d-ba98-7bbfd93ef163@default> <7a36a7ae-549d-333d-a395-afd7f2472a36@oracle.com> <6b764a34-e9fb-473a-ace7-f0d4bacb9928@default> Message-ID: <0e66fe0e-70de-594c-e36f-02328e94711d@oracle.com> On 31.08.16 14:48, Jayathirth D V wrote: > Hi Sergey, > > In case of JPEG whole read process is under a ThreadLock. > public BufferedImage read(int imageIndex, ImageReadParam param) > throws IOException { > setThreadLock(); > try { > cbLock.check(); > try { > readInternal(imageIndex, param, false); Then the fix looks fine. > > By others processXXX() do you mean processXXX() in other plugins or processXXX() in case of JPEG? > Please clarify. I meant only the code related to jpeg. > > Thanks, > Jay > > -----Original Message----- > From: Sergey Bylokhov > Sent: Wednesday, August 31, 2016 4:22 PM > To: Jayathirth D V; Philip Race > Cc: 2d-dev > Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() method does not work when called inside imageStarted for PNG > > I have only one question: should we call the new clearNativeReadAbortFlag(and probably the others processXXX()) under the ThreadLock? > > On 31.08.16 13:07, Jayathirth D V wrote: >> Hi Sergey, >> >> Thanks for the clarification. >> I have updated the test case to use Files.delete(). >> Please find updated webrev for review: >> http://cr.openjdk.java.net/~jdv/4924727/webrev.02/ >> >> Regards, >> Jay >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Monday, August 29, 2016 8:52 PM >> To: Jayathirth D V >> Cc: 2d-dev >> Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() >> method does not work when called inside imageStarted for PNG >> >> On 29.08.16 18:07, Jayathirth D V wrote: >>> Hi Sergey, >>> >>> I am not getting the usage of Files.delete() from its specification. Can you please elaborate what special case it will handle in my test case? >>> I am creating temporary file separately for all the readers and deleting them. >> >> Files.delete() will throw an exception if the file cannot be deleted, and File.delete() will return false in such case. >> >> Also I am closing the ImageInputStream associated after read operation. >> >> But plugin itself can leak some streams and lock a temporary file, so >> Files.delete() will catch this. >> >> >>> -----Original Message----- >>> From: Sergey Bylokhov >>> Sent: Monday, August 29, 2016 8:25 PM >>> To: Jayathirth D V; Philip Race >>> Cc: Prasanta Sadhukhan; 2d-dev >>> Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() >>> method does not work when called inside imageStarted for PNG >>> >>> Hi, Jay. >>> Please delete the temporary file via Files.delete(), which will throw an exception if the file is locked by some reader. >>> >>> On 29.08.16 11:42, Jayathirth D V wrote: >>>> Hi Phil & Sergey, >>>> >>>> Thanks for your inputs. >>>> >>>> I have verified reader.abort() request for IIOReadProgressListener for all available plugins. >>>> >>>> Apart from PNG although all readers were able to abort read when we call reader.abort() from IIOReadProgressListener callbacks, they were not calling processReadAborted() right after IIOReadProgressListener callbacks. So I have made changes for the same. >>>> >>>> And in some readers before every read call they were not calling clearAbortRequest(), which is important because if we use same reader for another read() call it will be invalid unless we clear previous abort request. >>>> >>>> In case of JPEG since we are using native IJG library we need to update abortFlag present in imageioJPEG.c before every call as we are doing for other readers using clearAbortRequest(). >>>> >>>> Since this has native and make changes I have verified changes >>>> through JPRT also which is successfully building on all platforms >>>> (http://scaaa637.us.oracle.com//archive/2016/08/2016-08-29-065104.jay. >>>> client_commit//JobStatus.txt ) >>>> >>>> Please find updated webrev for review: >>>> http://cr.openjdk.java.net/~jdv/4924727/webrev.01/ >>>> >>>> I noticed that in case on WBMP I was not getting ImageReader object to call setInput() in test case to verify the behavior of reader.abort(). So I have created separate bug for the same (https://bugs.openjdk.java.net/browse/JDK-8164930 ). And in case of WBMP we already have clearAbortRequest() call and also we are returning from IIOReadProgressListener callbacks properly, only thing here is we are not returning right after callbacks as we have updated other plugins. >>>> >>>> I want to verify writer plugins in separate bug as we already have lot of changes in this bug. So I have created https://bugs.openjdk.java.net/browse/JDK-8164931 and will be working on this bug. >>>> >>>> Thanks, >>>> Jay >>>> >>>> -----Original Message----- >>>> From: Phil Race >>>> Sent: Thursday, August 18, 2016 1:42 AM >>>> To: Sergey Bylokhov >>>> Cc: Jayathirth D V; Prasanta Sadhukhan; 2d-dev >>>> Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() >>>> method does not work when called inside imageStarted for PNG >>>> >>>> I think we can >>>> - get all plugins,and for each >>>> - write a file in that format >>>> - read it back and apply the test >>>> >>>> It is also worth verifying that the writer abort checks are in sync with the reader aborts, ie happen at such equivalent points as might exist. >>>> >>>> -phil. >>>> >>>> On 08/15/2016 11:30 AM, Sergey Bylokhov wrote: >>>>> Is it possible to unify the test for all our plugins? I assume they >>>>> should work in the same way. I am not sure but probably the image >>>>> can be generated at runtime? >>>>> >>>>> On 11.08.16 21:59, Jayathirth D V wrote: >>>>>> Hi, >>>>>> >>>>>> >>>>>> >>>>>> Please review the following fix in JDK9 at your convenience: >>>>>> >>>>>> >>>>>> >>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-4924727 >>>>>> >>>>>> >>>>>> >>>>>> Webrev : http://cr.openjdk.java.net/~jdv/4924727/webrev.00/ >>>>>> >>>>>> >>>>>> >>>>>> Issue : When we issue ImageReader.abort() in >>>>>> IIOReadProgressListener.imageStarted(), reading is not aborted and >>>>>> it is continued. >>>>>> >>>>>> >>>>>> >>>>>> Root cause : After IIOReadProgressListener.imageStarted() call in >>>>>> PNGImageReader.java when we enter decodeImage() we call >>>>>> clearAbortRequest() which will clear the abort request from >>>>>> IIOReadProgressListener.imageStarted(). >>>>>> >>>>>> >>>>>> >>>>>> Solution : clearAbortRequest() documentation mentions that it >>>>>> should be called before reading of image starts, so it should be >>>>>> called before IIOReadProgressListener.imageStarted()(In >>>>>> PNGImageReader.java it is >>>>>> processImageStarted(0) in readImage()). So moved >>>>>> clearAbortRequest() call from decodeImage() to readImage(). Also >>>>>> we should call >>>>>> abortRequested() in PNGImageReader.java at places mapping to >>>>>> IIOReadProgressListener and not randomly at end of functions or at >>>>>> places related to IIOReadUpdateListener, updated the code for the same. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Observation not related to this issue : We don't have call similar >>>>>> to >>>>>> IIOReadProgressListener.readAborted() in IIOReadUpdateListener, >>>>>> but user can call ImageReader.abort() from IIOReadUpdateListener methods. >>>>>> Is there a need to add similar method in IIOReadUpdateListener? >>>>>> Any inputs on this also would be helpful. >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jay >>>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> Best regards, Sergey. >>> >> >> > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From jayathirth.d.v at oracle.com Wed Aug 31 13:03:40 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 31 Aug 2016 06:03:40 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() method does not work when called inside imageStarted for PNG In-Reply-To: <0e66fe0e-70de-594c-e36f-02328e94711d@oracle.com> References: <06aa9e0a-bf19-4dd0-949a-c3c0cb00d4b1@default> <57B4C50F.6050809@oracle.com> <5a23861e-448c-4d23-8704-0bbc7c2148d2@default> <4fa0630e-9a97-805d-a603-0d4e51c64e74@oracle.com> <46d689e7-6246-451d-ba98-7bbfd93ef163@default> <7a36a7ae-549d-333d-a395-afd7f2472a36@oracle.com> <6b764a34-e9fb-473a-ace7-f0d4bacb9928@default> <0e66fe0e-70de-594c-e36f-02328e94711d@oracle.com> Message-ID: Thanks for the review Sergey. -----Original Message----- From: Sergey Bylokhov Sent: Wednesday, August 31, 2016 6:08 PM To: Jayathirth D V Cc: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() method does not work when called inside imageStarted for PNG On 31.08.16 14:48, Jayathirth D V wrote: > Hi Sergey, > > In case of JPEG whole read process is under a ThreadLock. > public BufferedImage read(int imageIndex, ImageReadParam param) > throws IOException { > setThreadLock(); > try { > cbLock.check(); > try { > readInternal(imageIndex, param, false); Then the fix looks fine. > > By others processXXX() do you mean processXXX() in other plugins or processXXX() in case of JPEG? > Please clarify. I meant only the code related to jpeg. > > Thanks, > Jay > > -----Original Message----- > From: Sergey Bylokhov > Sent: Wednesday, August 31, 2016 4:22 PM > To: Jayathirth D V; Philip Race > Cc: 2d-dev > Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() > method does not work when called inside imageStarted for PNG > > I have only one question: should we call the new clearNativeReadAbortFlag(and probably the others processXXX()) under the ThreadLock? > > On 31.08.16 13:07, Jayathirth D V wrote: >> Hi Sergey, >> >> Thanks for the clarification. >> I have updated the test case to use Files.delete(). >> Please find updated webrev for review: >> http://cr.openjdk.java.net/~jdv/4924727/webrev.02/ >> >> Regards, >> Jay >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Monday, August 29, 2016 8:52 PM >> To: Jayathirth D V >> Cc: 2d-dev >> Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() >> method does not work when called inside imageStarted for PNG >> >> On 29.08.16 18:07, Jayathirth D V wrote: >>> Hi Sergey, >>> >>> I am not getting the usage of Files.delete() from its specification. Can you please elaborate what special case it will handle in my test case? >>> I am creating temporary file separately for all the readers and deleting them. >> >> Files.delete() will throw an exception if the file cannot be deleted, and File.delete() will return false in such case. >> >> Also I am closing the ImageInputStream associated after read operation. >> >> But plugin itself can leak some streams and lock a temporary file, so >> Files.delete() will catch this. >> >> >>> -----Original Message----- >>> From: Sergey Bylokhov >>> Sent: Monday, August 29, 2016 8:25 PM >>> To: Jayathirth D V; Philip Race >>> Cc: Prasanta Sadhukhan; 2d-dev >>> Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() >>> method does not work when called inside imageStarted for PNG >>> >>> Hi, Jay. >>> Please delete the temporary file via Files.delete(), which will throw an exception if the file is locked by some reader. >>> >>> On 29.08.16 11:42, Jayathirth D V wrote: >>>> Hi Phil & Sergey, >>>> >>>> Thanks for your inputs. >>>> >>>> I have verified reader.abort() request for IIOReadProgressListener for all available plugins. >>>> >>>> Apart from PNG although all readers were able to abort read when we call reader.abort() from IIOReadProgressListener callbacks, they were not calling processReadAborted() right after IIOReadProgressListener callbacks. So I have made changes for the same. >>>> >>>> And in some readers before every read call they were not calling clearAbortRequest(), which is important because if we use same reader for another read() call it will be invalid unless we clear previous abort request. >>>> >>>> In case of JPEG since we are using native IJG library we need to update abortFlag present in imageioJPEG.c before every call as we are doing for other readers using clearAbortRequest(). >>>> >>>> Since this has native and make changes I have verified changes >>>> through JPRT also which is successfully building on all platforms >>>> (http://scaaa637.us.oracle.com//archive/2016/08/2016-08-29-065104.jay. >>>> client_commit//JobStatus.txt ) >>>> >>>> Please find updated webrev for review: >>>> http://cr.openjdk.java.net/~jdv/4924727/webrev.01/ >>>> >>>> I noticed that in case on WBMP I was not getting ImageReader object to call setInput() in test case to verify the behavior of reader.abort(). So I have created separate bug for the same (https://bugs.openjdk.java.net/browse/JDK-8164930 ). And in case of WBMP we already have clearAbortRequest() call and also we are returning from IIOReadProgressListener callbacks properly, only thing here is we are not returning right after callbacks as we have updated other plugins. >>>> >>>> I want to verify writer plugins in separate bug as we already have lot of changes in this bug. So I have created https://bugs.openjdk.java.net/browse/JDK-8164931 and will be working on this bug. >>>> >>>> Thanks, >>>> Jay >>>> >>>> -----Original Message----- >>>> From: Phil Race >>>> Sent: Thursday, August 18, 2016 1:42 AM >>>> To: Sergey Bylokhov >>>> Cc: Jayathirth D V; Prasanta Sadhukhan; 2d-dev >>>> Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() >>>> method does not work when called inside imageStarted for PNG >>>> >>>> I think we can >>>> - get all plugins,and for each >>>> - write a file in that format >>>> - read it back and apply the test >>>> >>>> It is also worth verifying that the writer abort checks are in sync with the reader aborts, ie happen at such equivalent points as might exist. >>>> >>>> -phil. >>>> >>>> On 08/15/2016 11:30 AM, Sergey Bylokhov wrote: >>>>> Is it possible to unify the test for all our plugins? I assume >>>>> they should work in the same way. I am not sure but probably the >>>>> image can be generated at runtime? >>>>> >>>>> On 11.08.16 21:59, Jayathirth D V wrote: >>>>>> Hi, >>>>>> >>>>>> >>>>>> >>>>>> Please review the following fix in JDK9 at your convenience: >>>>>> >>>>>> >>>>>> >>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-4924727 >>>>>> >>>>>> >>>>>> >>>>>> Webrev : http://cr.openjdk.java.net/~jdv/4924727/webrev.00/ >>>>>> >>>>>> >>>>>> >>>>>> Issue : When we issue ImageReader.abort() in >>>>>> IIOReadProgressListener.imageStarted(), reading is not aborted >>>>>> and it is continued. >>>>>> >>>>>> >>>>>> >>>>>> Root cause : After IIOReadProgressListener.imageStarted() call in >>>>>> PNGImageReader.java when we enter decodeImage() we call >>>>>> clearAbortRequest() which will clear the abort request from >>>>>> IIOReadProgressListener.imageStarted(). >>>>>> >>>>>> >>>>>> >>>>>> Solution : clearAbortRequest() documentation mentions that it >>>>>> should be called before reading of image starts, so it should be >>>>>> called before IIOReadProgressListener.imageStarted()(In >>>>>> PNGImageReader.java it is >>>>>> processImageStarted(0) in readImage()). So moved >>>>>> clearAbortRequest() call from decodeImage() to readImage(). Also >>>>>> we should call >>>>>> abortRequested() in PNGImageReader.java at places mapping to >>>>>> IIOReadProgressListener and not randomly at end of functions or >>>>>> at places related to IIOReadUpdateListener, updated the code for the same. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Observation not related to this issue : We don't have call >>>>>> similar to >>>>>> IIOReadProgressListener.readAborted() in IIOReadUpdateListener, >>>>>> but user can call ImageReader.abort() from IIOReadUpdateListener methods. >>>>>> Is there a need to add similar method in IIOReadUpdateListener? >>>>>> Any inputs on this also would be helpful. >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jay >>>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> Best regards, Sergey. >>> >> >> > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From prem.balakrishnan at oracle.com Wed Aug 31 13:05:09 2016 From: prem.balakrishnan at oracle.com (Prem Balakrishnan) Date: Wed, 31 Aug 2016 06:05:09 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails In-Reply-To: <7da9c7b5-8798-d5bf-d085-ab6affcdfc8f@oracle.com> References: <1d62d8f6-c7e6-e5c6-38e2-1764fea8011b@oracle.com> <94e9c6a3-2e9f-4405-a5c5-1e4dadeba7d9@default> <3e53ac2e-ba9b-b4e9-3ebd-bccb35bc6650@oracle.com> <75f3e1d7-dfc0-4d0c-84d9-192b306d0728@default> <57BAA36E.2010704@oracle.com> <197cdc08-165e-412d-9254-69c069e4fe47@default> <57BFE3BC.5050500@oracle.com> <7da9c7b5-8798-d5bf-d085-ab6affcdfc8f@oracle.com> Message-ID: <279ab3e1-5fac-40f3-a382-7c3c5156b8f9@default> Hi Vadim, Thankyou for the Review. I have updated the patch as per review comments, http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.03/ >According to the comments in the TranslucentWindowPainter.createInstance you will get BIWindowPainter even for OpenGL pipeline unless you force optimized path via >sun.java2d.twp.forceopt so you will need to check these paths in the fix for OpenGL. Yes, BIWindowPainter get called in OpenGl pipleline , I am working on OpenGL rendering issue(8164811). Regards, Prem From: Vadim Pakhnushev Sent: Wednesday, August 31, 2016 5:00 PM To: Prem Balakrishnan; Sergey Bylokhov; 2d-dev at openjdk.java.net Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails Prem, I believe it's possible to use AccelSurface.getBounds() method and skip casting to SurfaceData completely. The calculations are basically the same. According to the comments in the TranslucentWindowPainter.createInstance you will get BIWindowPainter even for OpenGL pipeline unless you force optimized path via sun.java2d.twp.forceopt so you will need to check these paths in the fix for OpenGL. Thanks, Vadim On 30.08.2016 9:17, Prem Balakrishnan wrote: Reminder From: Prasanta Sadhukhan Sent: Friday, August 26, 2016 12:08 PM To: Prem Balakrishnan; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails Ok. so long you are addressing the opengl issue albeit via different bugid, it's ok with me. +1. Regards Prasanta On 8/26/2016 11:56 AM, Prem Balakrishnan wrote: Hi Prasanta, Thankyou for the review. The code compiles , Actual scenario is as below: public class Temp { AccelSurface as = new AccelSurface() {}; SurfaceData sd = (SurfaceData)as; } class SurfaceData {} interface Surface {} interface AccelSurface extends Surface{} class D3DSurfaceData extends SurfaceData implements AccelSurface{} class OGLSurfaceData extends SurfaceData implements AccelSurface{} ------------------- In suggested fix, the SurfaceData is always of type D3DSurfaceData. And hence getDefaultScaleX/Y holds good. OpenGL rendering is handled in a different flow. HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.02/"http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.02/ Suggested fix also resolves the following failures on hidpi windows 8 javax/swing/JWindow/ShapedAndTranslucentWindows/PerPixelTranslucent.java javax/swing/JWindow/ShapedAndTranslucentWindows/PerPixelTranslucentGradient.java javax/swing/JWindow/ShapedAndTranslucentWindows/SetShapeAndClickSwing.java javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedPerPixelTranslucentGradient.java javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedTranslucentPerPixelTranslucentGradient.java javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java ---------------------- OpenGL Rendering issue will be addressed in HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8164811"JDK-8164811 Regards, Prem From: Prasanta Sadhukhan Sent: Monday, August 22, 2016 12:32 PM To: Prem Balakrishnan; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails I wonder how it compiles? I tried a small program ------------------ public class Test { AccelSurface b = new AccelSurface(); SurfaceData c = (SurfaceData)b; } class SurfaceData extends Surface {} class Surface {} class AccelSurface extends Surface {} --------- and it fails to compile Test.java:3: error: incompatible types: AccelSurface cannot be converted to SurfaceData SurfaceData c = (SurfaceData)b; ANyways, did you check with opengl pipeline? It seems getDefaultScaleX/Y is not present in OGLSurfaceData which will result in falling back to SurfaceData in which case the scale will be 1. Regards Prasanta On 8/18/2016 3:12 PM, Prem Balakrishnan wrote: Added "2d-dev" team for review Regards, Prem From: Alexandr Scherbatiy Sent: Thursday, August 18, 2016 2:57 PM To: Prem Balakrishnan; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails Could you also send the review to the 2d-dev alias? Thanks, Alexandr. On 8/18/2016 9:59 AM, Prem Balakrishnan wrote: Hi Alexandr, AccelSurface is implemented by *ONLY* D3DSurfaceData and OGLSurfaceData classes, Both of these classes extend SurfaceData as well. Hence, casting of 'as' variable which is of type AccelSurface object to SurfaceData is always VALID. Regards, Prem From: Alexandr Scherbatiy Sent: Wednesday, August 17, 2016 4:42 PM To: Prem Balakrishnan; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails On 8/17/2016 11:30 AM, Prem Balakrishnan wrote: Hi Alexandr, Thankyou for the review. YES scaled SurfaceData returns proper scale values from getDefaultScaleX()/getDefaultScaleY(), which I have used in the current patch. Please review the updated patch HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.02/"http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.02/ Is it always true that the 'as' variable which has type AccelSurface in the fix is always instance of SurfaceData? Thanks, Alexandr. Regards, Prem From: Alexandr Scherbatiy Sent: Tuesday, August 16, 2016 10:06 PM To: Prem Balakrishnan; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails On 8/16/2016 7:35 AM, Prem Balakrishnan wrote: Reminder From: Prem Balakrishnan Sent: Friday, August 12, 2016 6:36 PM To: Alexander Scherbatiy; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: RE: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails Hi Alexandr and Sergey, Please review the updated patch. HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.01/"http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.01/ >>"It is a little bit strange bug, because VolatileImage should handle this scale internally, and create double sized surface when necessary".-Sergey Yes as you mentioned Volatile Image is getting scaled internally. Thanks for the feedback. Cause: In VIOptWindowPainter::updateWindowAccel(psdops, w, h) call, width and height were passed without scaling, which was creating a bitmap of specified width and height, hence the output was clipped. I just have two general questions. - The scaled SurfaceData should return proper scales from getDefaultScaleX()/getDefaultScaleY() methods. Do these methods return right values after setting the scaled image sizes in the fix? - Region.clipScale() which is used in many places rounds values. The usual rule is to use Math.floor() for image coordinates rounding and Math.ceil() for sizes. Should the same rule be applicable here? Thanks, Alexandr. Regards, Prem From: Alexandr Scherbatiy Sent: Thursday, August 04, 2016 6:23 PM To: Prem Balakrishnan; Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails On 8/3/2016 10:04 AM, Prem Balakrishnan wrote: Hi, Please review fix for JDK9, Bug: https://bugs.openjdk.java.net/browse/JDK-8144735 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.00/"http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.00/ Issue: javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails Cause: While creating Transparent VolatileImage, width and height was NOT hidpi scaled. Fix: VolatileImage width and height are scaled. I believe this is an issue in AWT and needs to be discussed on awt-dev alias. Should the backbuffer width and height be also scaled for the BIWindowPainter? Thanks, Alexandr. Thanks, Prem -------------- next part -------------- An HTML attachment was scrubbed... URL: From vadim.pakhnushev at oracle.com Wed Aug 31 13:05:31 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Wed, 31 Aug 2016 16:05:31 +0300 Subject: [OpenJDK 2D-Dev] Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails In-Reply-To: <279ab3e1-5fac-40f3-a382-7c3c5156b8f9@default> References: <1d62d8f6-c7e6-e5c6-38e2-1764fea8011b@oracle.com> <94e9c6a3-2e9f-4405-a5c5-1e4dadeba7d9@default> <3e53ac2e-ba9b-b4e9-3ebd-bccb35bc6650@oracle.com> <75f3e1d7-dfc0-4d0c-84d9-192b306d0728@default> <57BAA36E.2010704@oracle.com> <197cdc08-165e-412d-9254-69c069e4fe47@default> <57BFE3BC.5050500@oracle.com> <7da9c7b5-8798-d5bf-d085-ab6affcdfc8f@oracle.com> <279ab3e1-5fac-40f3-a382-7c3c5156b8f9@default> Message-ID: <3664876f-21e4-09ca-53dd-a11b98345587@oracle.com> +1 Vadim On 31.08.2016 16:05, Prem Balakrishnan wrote: > > Hi Vadim, > > Thankyou for the Review. > > I have updated the patch as per review comments, > > http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.03/ > > > >According to the comments in the > TranslucentWindowPainter.createInstance you will get BIWindowPainter > even for OpenGL pipeline unless you force optimized path via > >sun.java2d.twp.forceopt so you will need to check these paths in the > fix for OpenGL. > > Yes, BIWindowPainter get called in OpenGl pipleline , I am working on > OpenGL rendering issue(8164811). > > Regards, > > Prem > > *From:*Vadim Pakhnushev > *Sent:* Wednesday, August 31, 2016 5:00 PM > *To:* Prem Balakrishnan; Sergey Bylokhov; 2d-dev at openjdk.java.net > *Subject:* Re: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > Prem, > > I believe it's possible to use AccelSurface.getBounds() method and > skip casting to SurfaceData completely. > The calculations are basically the same. > > According to the comments in the > TranslucentWindowPainter.createInstance you will get BIWindowPainter > even for OpenGL pipeline unless you force optimized path via > sun.java2d.twp.forceopt so you will need to check these paths in the > fix for OpenGL. > > Thanks, > Vadim > > On 30.08.2016 9:17, Prem Balakrishnan wrote: > > Reminder > > *From:*Prasanta Sadhukhan > *Sent:* Friday, August 26, 2016 12:08 PM > *To:* Prem Balakrishnan; 2d-dev at openjdk.java.net > > *Subject:* Re: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > Ok. so long you are addressing the opengl issue albeit via > different bugid, it's ok with me. +1. > > Regards > Prasanta > > On 8/26/2016 11:56 AM, Prem Balakrishnan wrote: > > Hi Prasanta, > > Thankyou for the review. > > The code compiles , Actual scenario is as below: > > public class Temp { > > AccelSurface as = new AccelSurface() {}; > > SurfaceData sd = (SurfaceData)as; > > } > > class SurfaceData {} > > interface Surface {} > > interface AccelSurface extends Surface{} > > class D3DSurfaceData extends SurfaceData implements AccelSurface{} > > class OGLSurfaceData extends SurfaceData implements AccelSurface{} > > ------------------- > > In suggested fix, the SurfaceData is always of type > D3DSurfaceData. > > And hence getDefaultScaleX/Y holds good. OpenGL rendering is > handled in a different flow. > > http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.02/ > > > Suggested fix also resolves the following failures on hidpi > windows 8 > > javax/swing/JWindow/ShapedAndTranslucentWindows/PerPixelTranslucent.java > > javax/swing/JWindow/ShapedAndTranslucentWindows/PerPixelTranslucentGradient.java > > javax/swing/JWindow/ShapedAndTranslucentWindows/SetShapeAndClickSwing.java > > javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedPerPixelTranslucentGradient.java > > javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedTranslucentPerPixelTranslucentGradient.java > > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > > ---------------------- > OpenGL Rendering issue will be addressed in JDK-8164811 > > > > > Regards, > > Prem > > *From:*Prasanta Sadhukhan > *Sent:* Monday, August 22, 2016 12:32 PM > *To:* Prem Balakrishnan; Rajeev Chamyal; > awt-dev at openjdk.java.net ; > 2d-dev at openjdk.java.net > *Subject:* Re: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > I wonder how it compiles? > I tried a small program > ------------------ > public class Test { > AccelSurface b = new AccelSurface(); > SurfaceData c = (SurfaceData)b; > } > > class SurfaceData extends Surface {} > class Surface {} > class AccelSurface extends Surface {} > --------- > and it fails to compile > Test.java:3: error: incompatible types: AccelSurface cannot be > converted to SurfaceData > SurfaceData c = (SurfaceData)b; > > ANyways, did you check with opengl pipeline? It seems > getDefaultScaleX/Y is not present in OGLSurfaceData which will > result in falling back to SurfaceData in which case the scale > will be 1. > > Regards > Prasanta > > On 8/18/2016 3:12 PM, Prem Balakrishnan wrote: > > Added ?2d-dev? team for review > > Regards, > > Prem > > *From:*Alexandr Scherbatiy > *Sent:* Thursday, August 18, 2016 2:57 PM > *To:* Prem Balakrishnan; Rajeev Chamyal; > awt-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > Could you also send the review to the 2d-dev alias? > > Thanks, > Alexandr. > > On 8/18/2016 9:59 AM, Prem Balakrishnan wrote: > > Hi Alexandr, > > AccelSurface is implemented by *ONLY* D3DSurfaceData > and OGLSurfaceData classes, > > Both of these classes extend SurfaceData as well. > > Hence, casting of 'as' variable which is of type > AccelSurface object to SurfaceData is always VALID. > > Regards, > Prem > > *From:*Alexandr Scherbatiy > *Sent:* Wednesday, August 17, 2016 4:42 PM > *To:* Prem Balakrishnan; Rajeev Chamyal; > awt-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > On 8/17/2016 11:30 AM, Prem Balakrishnan wrote: > > > > > > Hi Alexandr, > > Thankyou for the review. > > YES scaled SurfaceData returns proper scale values > from getDefaultScaleX()/getDefaultScaleY(), which I > have used in the current patch. > > Please review the updated patch > > http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.02/ > > > Is it always true that the 'as' variable which has > type AccelSurface in the fix is always instance of > SurfaceData? > > Thanks, > Alexandr. > > > > > > Regards, > Prem > > *From:*Alexandr Scherbatiy > *Sent:* Tuesday, August 16, 2016 10:06 PM > *To:* Prem Balakrishnan; Rajeev Chamyal; > awt-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > On 8/16/2016 7:35 AM, Prem Balakrishnan wrote: > > > > > > > Reminder > > *From:*Prem Balakrishnan > *Sent:* Friday, August 12, 2016 6:36 PM > *To:* Alexander Scherbatiy; Rajeev Chamyal; > awt-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* RE: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > Hi Alexandr and Sergey, > > Please review the updated patch. > > http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.01/ > > > >>?It is a little bit strange bug, because > VolatileImage should handle this scale internally, and > create double sized surface when necessary?.-Sergey > > Yes as you mentioned Volatile Image is getting scaled > internally. Thanks for the feedback. > > *Cause:*In > VIOptWindowPainter::updateWindowAccel(psdops, w, h) > call, width and height were passed without scaling, > > which was creating a bitmap of specified width and > height, hence the output was clipped. > > > I just have two general questions. > - The scaled SurfaceData should return proper scales > from getDefaultScaleX()/getDefaultScaleY() methods. Do > these methods return right values after setting the > scaled image sizes in the fix? > - Region.clipScale() which is used in many places > rounds values. The usual rule is to use Math.floor() > for image coordinates rounding and Math.ceil() for sizes. > Should the same rule be applicable here? > > Thanks, > Alexandr. > > > > > > > > > Regards, > > Prem > > *From:*Alexandr Scherbatiy > *Sent:* Thursday, August 04, 2016 6:23 PM > *To:* Prem Balakrishnan; Rajeev Chamyal; > awt-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: Review Request: JDK-8144735 [hidpi] > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > On 8/3/2016 10:04 AM, Prem Balakrishnan wrote: > > Hi, > > Please review fix for JDK9, > > *Bug:*https://bugs.openjdk.java.net/browse/JDK-8144735 > > *Webrev:*http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.00/ > > > > *Issue:* > > javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java > fails > > *Cause:* > > While creating Transparent VolatileImage, width and > height was NOT hidpi scaled. > > *Fix: *VolatileImage width and height are scaled. > > > I believe this is an issue in AWT and needs to be > discussed on awt-dev alias. > > Should the backbuffer width and height be also > scaled for the BIWindowPainter? > > Thanks, > Alexandr. > > Thanks, > > Prem > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Wed Aug 31 16:58:21 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 31 Aug 2016 22:28:21 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR 8165146 [PIT][TEST_BUG] Doubtful usability of java/awt/print/PrinterJob/TestMediaTraySelection.java Message-ID: <57C70CAD.5040902@oracle.com> Hi All, It seems there is a question mark on the usability of the testcase if the user does not have a printer that does not have multiple trays. The testcase might be useful for dev environment so removing @test tag to prevent it running from jtreg harness. Please review. hg diff test/java/awt/print/PrinterJob/TestMediaTraySelection.java diff -r 145d979bb1fb test/java/awt/print/PrinterJob/TestMediaTraySelection.java --- a/test/java/awt/print/PrinterJob/TestMediaTraySelection.java Tue Aug 30 11:07:58 2016 +0530 +++ b/test/java/awt/print/PrinterJob/TestMediaTraySelection.java Wed Aug 31 22:25:53 2016 +0530 @@ -21,8 +21,7 @@ * questions. */ /* - * @test - * @bug 6357887 + * @bug 6357887 8165146 * @summary Verifies if selected printertray is used Regards Prasanta From philip.race at oracle.com Wed Aug 31 18:37:40 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 31 Aug 2016 11:37:40 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-7064425: PageFormat Dialog has no owner window to reactivate In-Reply-To: <57BFF839.3010009@oracle.com> References: <57BECB2E.4030102@oracle.com> <57BFF839.3010009@oracle.com> Message-ID: <57C723F4.6010804@oracle.com> 911 public boolean printDialog(final PrintRequestAttributeSet attributes) ... 956 attributes.add(new DialogOwner((Frame)w)); So this now adds the DialogOwner to the attribute set passed by the application. This needs to be guaranteed to be removed again before the method returns otherwise apart from leaving that visible to the application, there is some risk that the frame will not be GC'd when it should have been. - Frame ownerFrame = (dlgOwner != null) ? dlgOwner.getOwner() : null; + Window ownerFrame = (dlgOwner != null) ? dlgOwner.getOwner() : null so maybe change the var name to just "owner" ? WPrintDialog dialog; 484 if (ownerFrame instanceof Frame) { 485 dialog = new WPrintDialog((Frame)ownerFrame, this); 486 } else { 487 dialog = new WPrintDialog((Dialog)ownerFrame, this); 488 } could (should?) be WPrintDialog dialog = new WPrintDialog(((owner instanceof Frame) ? (Frame)owner : (Dialog)owner), this) and so on for the other cases too .. it will save a lot of repetition for newPrintToFileErrorDialog(..) -phil. On 08/26/2016 01:05 AM, Prasanta Sadhukhan wrote: > Hi All, > > I have modified the webrev to take care of JDK-6948907 > : > sun.print.DialogOwner does not support Dialogs as DialogOwner > also. > http://cr.openjdk.java.net/~psadhukhan/7064425/webrev.01/ > > Tested on windows and ubuntu. > > Regards > Prasanta > On 8/25/2016 4:10 PM, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a fix for jdk9 for an issue where it is seen that >> PageDialog and PrintDialog is not associated with the owner Frame >> that spawns the dialog. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-7064425 >> webrev: http://cr.openjdk.java.net/~psadhukhan/7064425/webrev.00/ >> >> The issue was there we explicitly pass null as owner to ServiceDialog >> in pageDialog(attributes). >> Proposed fix is to get the owner window, >> if pageDialog is called before calling printDialog, the window will >> be a Frame else the owner window will be ServiceDialog >> and pass this owner window to ServiceDialog instead of null. >> >> For PrintDialog, the proposed fix is to set an attribute with >> DialogOwner so that ServiceUI dialog can parse that attribute and can >> use the owner window as parent of the dialaog, >> >> Regards >> Prasanta > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Aug 31 18:50:05 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 31 Aug 2016 11:50:05 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR 8165146 [PIT][TEST_BUG] Doubtful usability of java/awt/print/PrinterJob/TestMediaTraySelection.java In-Reply-To: <57C70CAD.5040902@oracle.com> References: <57C70CAD.5040902@oracle.com> Message-ID: <01bd7694-ec05-6fac-b5b4-1a029d43d012@oracle.com> +1 -phil. On 8/31/2016 9:58 AM, Prasanta Sadhukhan wrote: > Hi All, > > It seems there is a question mark on the usability of the testcase if > the user does not have a printer that does not have multiple trays. > The testcase might be useful for dev environment so removing @test tag > to prevent it running from jtreg harness. > Please review. > > hg diff test/java/awt/print/PrinterJob/TestMediaTraySelection.java > diff -r 145d979bb1fb > test/java/awt/print/PrinterJob/TestMediaTraySelection.java > --- a/test/java/awt/print/PrinterJob/TestMediaTraySelection.java Tue > Aug 30 11:07:58 2016 +0530 > +++ b/test/java/awt/print/PrinterJob/TestMediaTraySelection.java Wed > Aug 31 22:25:53 2016 +0530 > @@ -21,8 +21,7 @@ > * questions. > */ > /* > - * @test > - * @bug 6357887 > + * @bug 6357887 8165146 > * @summary Verifies if selected printertray is used > > Regards > Prasanta From philip.race at oracle.com Wed Aug 31 23:03:37 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 31 Aug 2016 16:03:37 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8160327: Support for thumbnails present in APP1 marker for JPEG In-Reply-To: <82E1034D-B00E-4B64-BC95-F9DAAE44516C@oracle.com> References: <82E1034D-B00E-4B64-BC95-F9DAAE44516C@oracle.com> Message-ID: <57C76249.3000704@oracle.com> imageCreationTime = LocalDateTime.parse(dateTime, formatter); Seems like it may throw DateTimeParseException - a subtype of RuntimeException https://docs.oracle.com/javase/8/docs/api/java/time/LocalDateTime.html#parse-java.lang.CharSequence-java.time.format.DateTimeFormatter- I think in the case of such malformed data we want to silently swallow it rather than propagate to the caller. 164 // XXX Might want to set JPEGImageReader$ThumbnailReadListener 165 // to track thumbnail reading progress. XXX ? int getThumbnailWidth(int index) { 187 if (getNumThumbnails() != 1 || index != 0) { 188 throw new IndexOutOfBoundsException(); 189 } 190 return thumbnailWidth; 191 } Would it not be more informative to include "index" in the exception ? Other than that looks fine. -phil. On 8/29/16, 7:39 AM, Brian Burkhalter wrote: > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8160327 > Patch: http://cr.openjdk.java.net/~bpb/8160327/webrev.00/ > > Add thumbnail and standard metadata Document/ImageCreationTime from the APP1 Exif marker segment if present > > The code has been tested using JPEG-Exif images with compressed thumbnails from Canon, Nikon, and Olympus cameras, and using a JPEG-Exif image with an uncompressed thumbnail from a Sony camera. > > Thanks, > > Brian From philip.race at oracle.com Wed Aug 31 23:17:40 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 31 Aug 2016 16:17:40 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() method does not work when called inside imageStarted for PNG In-Reply-To: <0e66fe0e-70de-594c-e36f-02328e94711d@oracle.com> References: <06aa9e0a-bf19-4dd0-949a-c3c0cb00d4b1@default> <57B4C50F.6050809@oracle.com> <5a23861e-448c-4d23-8704-0bbc7c2148d2@default> <4fa0630e-9a97-805d-a603-0d4e51c64e74@oracle.com> <46d689e7-6246-451d-ba98-7bbfd93ef163@default> <7a36a7ae-549d-333d-a395-afd7f2472a36@oracle.com> <6b764a34-e9fb-473a-ace7-f0d4bacb9928@default> <0e66fe0e-70de-594c-e36f-02328e94711d@oracle.com> Message-ID: <57C76594.2000504@oracle.com> I don't understand why the change from while() { .. } to do { .. } while(..) was needed in GIFImageReader but then I don't see any harm in it either. Can you explain that one ? Also I'd like Brian to sign off on the TIFF change. Other than that all seems fine. -phil. On 8/31/16, 5:37 AM, Sergey Bylokhov wrote: > On 31.08.16 14:48, Jayathirth D V wrote: >> Hi Sergey, >> >> In case of JPEG whole read process is under a ThreadLock. >> public BufferedImage read(int imageIndex, ImageReadParam param) >> throws IOException { >> setThreadLock(); >> try { >> cbLock.check(); >> try { >> readInternal(imageIndex, param, false); > > Then the fix looks fine. > >> >> By others processXXX() do you mean processXXX() in other plugins or >> processXXX() in case of JPEG? >> Please clarify. > > I meant only the code related to jpeg. > >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Wednesday, August 31, 2016 4:22 PM >> To: Jayathirth D V; Philip Race >> Cc: 2d-dev >> Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() >> method does not work when called inside imageStarted for PNG >> >> I have only one question: should we call the new >> clearNativeReadAbortFlag(and probably the others processXXX()) under >> the ThreadLock? >> >> On 31.08.16 13:07, Jayathirth D V wrote: >>> Hi Sergey, >>> >>> Thanks for the clarification. >>> I have updated the test case to use Files.delete(). >>> Please find updated webrev for review: >>> http://cr.openjdk.java.net/~jdv/4924727/webrev.02/ >>> >>> Regards, >>> Jay >>> >>> -----Original Message----- >>> From: Sergey Bylokhov >>> Sent: Monday, August 29, 2016 8:52 PM >>> To: Jayathirth D V >>> Cc: 2d-dev >>> Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() >>> method does not work when called inside imageStarted for PNG >>> >>> On 29.08.16 18:07, Jayathirth D V wrote: >>>> Hi Sergey, >>>> >>>> I am not getting the usage of Files.delete() from its >>>> specification. Can you please elaborate what special case it will >>>> handle in my test case? >>>> I am creating temporary file separately for all the readers and >>>> deleting them. >>> >>> Files.delete() will throw an exception if the file cannot be >>> deleted, and File.delete() will return false in such case. >>> >>> Also I am closing the ImageInputStream associated after read operation. >>> >>> But plugin itself can leak some streams and lock a temporary file, so >>> Files.delete() will catch this. >>> >>> >>>> -----Original Message----- >>>> From: Sergey Bylokhov >>>> Sent: Monday, August 29, 2016 8:25 PM >>>> To: Jayathirth D V; Philip Race >>>> Cc: Prasanta Sadhukhan; 2d-dev >>>> Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() >>>> method does not work when called inside imageStarted for PNG >>>> >>>> Hi, Jay. >>>> Please delete the temporary file via Files.delete(), which will >>>> throw an exception if the file is locked by some reader. >>>> >>>> On 29.08.16 11:42, Jayathirth D V wrote: >>>>> Hi Phil & Sergey, >>>>> >>>>> Thanks for your inputs. >>>>> >>>>> I have verified reader.abort() request for IIOReadProgressListener >>>>> for all available plugins. >>>>> >>>>> Apart from PNG although all readers were able to abort read when >>>>> we call reader.abort() from IIOReadProgressListener callbacks, >>>>> they were not calling processReadAborted() right after >>>>> IIOReadProgressListener callbacks. So I have made changes for the >>>>> same. >>>>> >>>>> And in some readers before every read call they were not calling >>>>> clearAbortRequest(), which is important because if we use same >>>>> reader for another read() call it will be invalid unless we clear >>>>> previous abort request. >>>>> >>>>> In case of JPEG since we are using native IJG library we need to >>>>> update abortFlag present in imageioJPEG.c before every call as we >>>>> are doing for other readers using clearAbortRequest(). >>>>> >>>>> Since this has native and make changes I have verified changes >>>>> through JPRT also which is successfully building on all platforms >>>>> (http://scaaa637.us.oracle.com//archive/2016/08/2016-08-29-065104.jay. >>>>> >>>>> client_commit//JobStatus.txt ) >>>>> >>>>> Please find updated webrev for review: >>>>> http://cr.openjdk.java.net/~jdv/4924727/webrev.01/ >>>>> >>>>> I noticed that in case on WBMP I was not getting ImageReader >>>>> object to call setInput() in test case to verify the behavior of >>>>> reader.abort(). So I have created separate bug for the same >>>>> (https://bugs.openjdk.java.net/browse/JDK-8164930 ). And in case >>>>> of WBMP we already have clearAbortRequest() call and also we are >>>>> returning from IIOReadProgressListener callbacks properly, only >>>>> thing here is we are not returning right after callbacks as we >>>>> have updated other plugins. >>>>> >>>>> I want to verify writer plugins in separate bug as we already have >>>>> lot of changes in this bug. So I have created >>>>> https://bugs.openjdk.java.net/browse/JDK-8164931 and will be >>>>> working on this bug. >>>>> >>>>> Thanks, >>>>> Jay >>>>> >>>>> -----Original Message----- >>>>> From: Phil Race >>>>> Sent: Thursday, August 18, 2016 1:42 AM >>>>> To: Sergey Bylokhov >>>>> Cc: Jayathirth D V; Prasanta Sadhukhan; 2d-dev >>>>> Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() >>>>> method does not work when called inside imageStarted for PNG >>>>> >>>>> I think we can >>>>> - get all plugins,and for each >>>>> - write a file in that format >>>>> - read it back and apply the test >>>>> >>>>> It is also worth verifying that the writer abort checks are in >>>>> sync with the reader aborts, ie happen at such equivalent points >>>>> as might exist. >>>>> >>>>> -phil. >>>>> >>>>> On 08/15/2016 11:30 AM, Sergey Bylokhov wrote: >>>>>> Is it possible to unify the test for all our plugins? I assume they >>>>>> should work in the same way. I am not sure but probably the image >>>>>> can be generated at runtime? >>>>>> >>>>>> On 11.08.16 21:59, Jayathirth D V wrote: >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>> >>>>>>> Please review the following fix in JDK9 at your convenience: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-4924727 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Webrev : http://cr.openjdk.java.net/~jdv/4924727/webrev.00/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> Issue : When we issue ImageReader.abort() in >>>>>>> IIOReadProgressListener.imageStarted(), reading is not aborted and >>>>>>> it is continued. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Root cause : After IIOReadProgressListener.imageStarted() call in >>>>>>> PNGImageReader.java when we enter decodeImage() we call >>>>>>> clearAbortRequest() which will clear the abort request from >>>>>>> IIOReadProgressListener.imageStarted(). >>>>>>> >>>>>>> >>>>>>> >>>>>>> Solution : clearAbortRequest() documentation mentions that it >>>>>>> should be called before reading of image starts, so it should be >>>>>>> called before IIOReadProgressListener.imageStarted()(In >>>>>>> PNGImageReader.java it is >>>>>>> processImageStarted(0) in readImage()). So moved >>>>>>> clearAbortRequest() call from decodeImage() to readImage(). Also >>>>>>> we should call >>>>>>> abortRequested() in PNGImageReader.java at places mapping to >>>>>>> IIOReadProgressListener and not randomly at end of functions or at >>>>>>> places related to IIOReadUpdateListener, updated the code for >>>>>>> the same. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Observation not related to this issue : We don't have call similar >>>>>>> to >>>>>>> IIOReadProgressListener.readAborted() in IIOReadUpdateListener, >>>>>>> but user can call ImageReader.abort() from IIOReadUpdateListener >>>>>>> methods. >>>>>>> Is there a need to add similar method in IIOReadUpdateListener? >>>>>>> Any inputs on this also would be helpful. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Jay >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Best regards, Sergey. >>>> >>> >>> >> >> >> -- >> Best regards, Sergey. >> > > From steven.loomis at oracle.com Wed Aug 31 23:46:46 2016 From: steven.loomis at oracle.com (Steven Loomis) Date: Wed, 31 Aug 2016 16:46:46 -0700 (PDT) Subject: [OpenJDK 2D-Dev] RFR: 8144015: [PIT] failures of text layout font tests Message-ID: Looks good to me! ----- Original Message ----- From: prasanta.sadhukhan at oracle.com To: philip.race at oracle.com, 2d-dev at openjdk.java.net Sent: Wednesday, August 31, 2016 3:17:27 AM GMT -08:00 US/Canada Pacific Subject: Re: [OpenJDK 2D-Dev] RFR: 8144015: [PIT] failures of text layout font tests Looks ok to me. Regards Prasanta On 8/26/2016 2:40 AM, Phil Race wrote: > > Webrev: http://cr.openjdk.java.net/~prr/8144015/ > > This RFR encompasses changes that are sufficiently related > to keep them all together and they deserve testing as a whole. > Multiple test failures are resolved. A list is below. > > Notable highlights > ExtendedTextSourceLabel.createCharinfo() can now handle > cases where the glyph count is less than the char count. > This was not just a problem in 9 (harfbuzz) but has been > observed on 8 too (8041480 in the list below). > The fundamental change is to abandon the idea of > updating in place which added complexity and was > never going to work if you had too few glyphs .. > > HBShaper.c > - Fixed that kerning was always enabled > - Simplified - and corrected - the code that stored the resulting data > - Stopped using throwing an exception as a way to expand storage > - Cleaned up JNI usage > > Tests have been added/updated/open sourced as necessary. > > JPRT passed these changes. > > > Bugs fixed by this change : > https://bugs.openjdk.java.net/browse/JDK-8144015 > 8144015: [PIT] failures of text layout font tests > > ** https://bugs.openjdk.java.net/browse/JDK-8144023 > 8144023: [PIT] failure of text measurements in > javax/swing/text/html/parser/Parser/6836089/bug6836089.java > > ** https://bugs.openjdk.java.net/browse/JDK-8145542 > 8145542: The case failed automatically and thrown > java.lang.ArrayIndexOutOfBoundsException exception > > ** https://bugs.openjdk.java.net/browse/JDK-8151725 > 8151725: [macosx] ArrayIndexOOB exception when displaying Devanagari > text in JEditorPane > > ** https://bugs.openjdk.java.net/browse/JDK-8144240 > 8144240: [macosx][PIT] AIOOB in > closed/javax/swing/text/GlyphPainter2/6427244/bug6427244.java > > https://bugs.openjdk.java.net/browse/JDK-8152680 > 8152680: Regression in GlyphVector.getGlyphCharIndex behaviour > > ** https://bugs.openjdk.java.net/browse/JDK-8158924 > 8158924: Incorrect i18n text document layout > > ** https://bugs.openjdk.java.net/browse/JDK-8041480 > 8041480: ArrayIndexOutOfBoundsException when JTable contains certain > string > > -phil. From steven.loomis at oracle.com Wed Aug 31 23:47:25 2016 From: steven.loomis at oracle.com (Steven Loomis) Date: Wed, 31 Aug 2016 16:47:25 -0700 (PDT) Subject: [OpenJDK 2D-Dev] RFR: 8164818: Reg. test java/awt/font/TextLayout/VisibleAdvance.java fails Message-ID: <0c42f288-4858-4828-a402-3720a223d231@default> This one also looks good to me. ----- Original Message ----- From: prasanta.sadhukhan at oracle.com To: philip.race at oracle.com, 2d-dev at openjdk.java.net Sent: Tuesday, August 30, 2016 11:55:43 PM GMT -08:00 US/Canada Pacific Subject: Re: [OpenJDK 2D-Dev] RFR: 8164818: Reg. test java/awt/font/TextLayout/VisibleAdvance.java fails Looks good to me. Regards Prasanta On 8/26/2016 4:46 AM, Philip Race wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8164818 > webrev: http://cr.openjdk.java.net/~prr/8164818/ > > 26.6 fixed point was being used in harfbuzz interface code > and 16.16 elsewhere so we had a precision mismatch. > More details in the bug report. > > -phil.