From james.graham at oracle.com Fri Apr 1 02:24:26 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 31 Mar 2016 19:24:26 -0700 Subject: [OpenJDK 2D-Dev] [9] Review request for 8073320 Windows HiDPI Graphics support In-Reply-To: <56012064.2020800@oracle.com> References: <56012064.2020800@oracle.com> Message-ID: <56FDDBDA.5070907@oracle.com> Hi Alexandr, Is there a bug filed to upgrade JLightweightFrame to allow non-integer (and X/Y) scales? We'd need this capability to implement "Swing embedded in FX" correctly on Win8.1+... ...jim On 9/22/2015 2:33 AM, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8073320 > webrev: http://cr.openjdk.java.net/~alexsch/8073320/webrev.00 > > This is an initial part of the HiDPI Graphics support on Windows for > the JEP 263: HiDPI Graphics on Windows and Linux > http://openjdk.java.net/jeps/263 > > - scale factors are added to surface dates > - window size, events coordinates and font are scaled on native side > - backup buffered image is scaled in SunVolatileImage > - AwtRobot MouseMove() and GetRGBPixels() methods are updated > - GetDpiForMonitor function is used to query the specified monitor > for the horizontal and vertical DPI values. > If it is not available ID2D1Factory::GetDesktopDpi method is used > instead. > - "sun.java2d.uiScale.enabled", "sun.java2d.win.uiScale", > "sun.java2d.win.uiScaleX", and "sun.java2d.win.uiScaleY" options are > added for the testing purposes. > > Thanks, > Alexandr. > From prasanta.sadhukhan at oracle.com Fri Apr 1 07:02:53 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Fri, 1 Apr 2016 12:32:53 +0530 Subject: [OpenJDK 2D-Dev] [9]: RFR JDK-6357905, , java.awt.JobAttributes.getFromPage() and getToPage() always returns "1". In-Reply-To: <56FD46F4.8040704@oracle.com> References: <56F8ED8F.6030007@oracle.com> <56F9D724.3060104@oracle.com> <56FCB41E.4000505@oracle.com> <56FD45E5.4020208@oracle.com> <56FD46F4.8040704@oracle.com> Message-ID: <56FE1D1D.7000603@oracle.com> Please find the modified webrev with check for existing values to select which order to do the update. http://cr.openjdk.java.net/~psadhukhan/6357905/webrev.02/ I have checked with 1) initially user sets from=3, to=4 and then user change from=1,to=2 2) initially user sets from=3, to=4 and then user change from=2,to=3 2) no initial setting from user, so from=1,to=1 and user change from=2,to=3 3)no initial setting from user, so from=1,to=1 and user change from=1,to=2 Regards Prasanta On 3/31/2016 9:19 PM, Philip Race wrote: > Actually never mind about the > or >= difference > that code is fine since it is the condition under which the exception > is thrown not the condition that the setting is accepted ! > > But you do still need to check the existing values to see which order > to do the update. > > -phil > > On 3/31/16, 8:44 AM, Philip Race wrote: >> >> >> On 3/30/16, 10:22 PM, prasanta sadhukhan wrote: >>> Hi Phil, >>> >>> I found out we do not need to change minPage. >> That makes more sense now. >> >>> Changing toPage before frompage should be enough. >>> Please find the modified webrev: >>> http://cr.openjdk.java.net/~psadhukhan/6357905/webrev.01/ >> >> Don't you need to check ? setToPage also checks that to > from >> >> Supposing we start with from=3,to=4 >> and you want to change it so that from=1,to=2 >> when you try to change the to page (in the first step) to 3,2 >> you will also get an IAE. >> >> So you need to examine the existing values to decide which order to >> do the update. >> >> A bad API design IMO, it should have been setPageRange(int from, int to) >> but it is too late for that. >> >> BTW I notice it really is a requirement that from < to and to > from >> >> eg : I see >> (toPage != 0 && fromPage > toPage) || >> >> I would have expected >= .. >> >> .. in fact the docs for setFromPage say : >> * @param fromPage an integer greater than zero and less than or >> equal to >> * toPage >> >> So the implementation looks wrong to me for that and setToPage. >> >> -phil. >>> >>> Regards >>> Prasanta >>> On 3/29/2016 6:45 AM, Philip Race wrote: >>>> Please add an evaluation to the bug report. >>>> >>>> As to the fix I am under the impression that min&max page are >>>> meant to constrain what the user can enter in the dialog so >>>> if min page & max page are set to "1" then the problem >>>> may be with those settings ? >>>> >>>> i.e the application can set those values and expect the user >>>> can't change them so updating our code to circumvent that >>>> seems wrong. >>>> >>>> -phil. >>>> >>>> On 3/28/16, 1:38 AM, prasanta sadhukhan wrote: >>>>> Hi All, >>>>> >>>>> Please review a print job attribute fix for jdk9. >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6357905 >>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6357905/webrev.00/ >>>>> >>>>> The issue was in the Print-dialog, when some pages are specified >>>>> using "Pages" within "Page range", >>>>> java.awt.JobAttributes.getFromPage() and getToPage() always >>>>> returns "1" >>>>> and not the values as updated by the user. >>>>> The fix was to get the pageranges attribute as set by the user and >>>>> obtain the from and to Page range and update the JobAttribute's >>>>> from and to Page. >>>>> >>>>> Regards >>>>> Prasanta >>> From alexander.v.stepanov at oracle.com Fri Apr 1 10:02:43 2016 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Fri, 1 Apr 2016 13:02:43 +0300 Subject: [OpenJDK 2D-Dev] RFR 8149028: [TEST] add test for TIFFDirectory In-Reply-To: <56FD5A17.6010101@oracle.com> References: <56F55D56.4090408@oracle.com> <56FAB9B3.6050209@oracle.com> <56FD47B9.6010008@oracle.com> <56FD5A17.6010101@oracle.com> Message-ID: <56FE4743.9040708@oracle.com> Thanks! On 3/31/2016 8:10 PM, Semyon Sadetsky wrote: > Looks good. > > --Semyon > > On 3/31/2016 6:52 PM, Alexander Stepanov wrote: >> Please see >> http://cr.openjdk.java.net/~avstepan/8149028/webrev.02/ >> (one more test covering TIFFImageReadParam was added). >> >> Thanks, >> Alexander >> >> On 3/29/2016 8:21 PM, Alexander Stepanov wrote: >>> Please see the updated webrev: >>> http://cr.openjdk.java.net/~avstepan/8149028/webrev.01/ >>> (one more test was added). >>> >>> Thanks, >>> Alexander >>> >>> On 3/25/2016 6:46 PM, Alexander Stepanov wrote: >>>> Hello, >>>> >>>> Could you please review the following fix >>>> http://cr.openjdk.java.net/~avstepan/8149028/webrev.00/ >>>> for >>>> https://bugs.openjdk.java.net/browse/JDK-8149028 >>>> >>>> Just a single test added. >>>> >>>> Thanks, >>>> Alexander >>>> >>> >> > From yuri.nesterenko at oracle.com Fri Apr 1 10:29:36 2016 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Fri, 1 Apr 2016 13:29:36 +0300 Subject: [OpenJDK 2D-Dev] RFR 8149028: [TEST] add test for TIFFDirectory In-Reply-To: <56FD47B9.6010008@oracle.com> References: <56F55D56.4090408@oracle.com> <56FAB9B3.6050209@oracle.com> <56FD47B9.6010008@oracle.com> Message-ID: <56FE4D90.6020107@oracle.com> +1 -yan On 03/31/2016 06:52 PM, Alexander Stepanov wrote: > Please see > http://cr.openjdk.java.net/~avstepan/8149028/webrev.02/ > (one more test covering TIFFImageReadParam was added). > > Thanks, > Alexander > > On 3/29/2016 8:21 PM, Alexander Stepanov wrote: >> Please see the updated webrev: >> http://cr.openjdk.java.net/~avstepan/8149028/webrev.01/ >> (one more test was added). >> >> Thanks, >> Alexander >> >> On 3/25/2016 6:46 PM, Alexander Stepanov wrote: >>> Hello, >>> >>> Could you please review the following fix >>> http://cr.openjdk.java.net/~avstepan/8149028/webrev.00/ >>> for >>> https://bugs.openjdk.java.net/browse/JDK-8149028 >>> >>> Just a single test added. >>> >>> Thanks, >>> Alexander >>> >> > From prasanta.sadhukhan at oracle.com Fri Apr 1 10:57:25 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Fri, 1 Apr 2016 16:27:25 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8074826, , Resolve disabled warnings for liblcms Message-ID: <56FE5415.4040706@oracle.com> Hi All, Please review a fix to remove the disabled warnings from lcms library Bug: https://bugs.openjdk.java.net/browse/JDK-8074826 webrev: http://cr.openjdk.java.net/~psadhukhan/8074826/webrev.00/ One issue was snprintf/sprintf was using arguments it8 ->DoubleFormatter instead of string format literal like %f or %d which was causing the warning. I have used DEFAULT_DBL_FORMAT which was anyway copied to it8 ->DoubleFormatter. Another issue was cmsUNUSED_PARAMETER macro was used to suppress unused parameter warning but this macro was called after the return statement, thereby E_STATEMENT_NOT_REACHED warning was getting issued. Now, I am Calling this before the return statements. I have run JPRT build on these targets *** Build targets: solaris_sparcv9_5.11-product solaris_sparcv9_5.11-fastdebug solaris_x64_5.11-product solaris_x64_5.11-fastdebug linux_i586_3.8-product with attributes distribution=OEL linux_i586_3.8-fastdebug with attributes distribution=OEL linux_x64_3.8-product with attributes distribution=OEL linux_x64_3.8-fastdebug with attributes distribution=OEL macosx_x64_10.9-product macosx_x64_10.9-fastdebug windows_i586_6.3-product windows_i586_6.3-fastdebug windows_x64_6.3-product windows_x64_6.3-fastdebug Build Stats: 14 pass, 0 fail, 0 killed, 0 working, 0 initializing, 0 not started Regards Prasanta From erik.joelsson at oracle.com Fri Apr 1 13:22:36 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 1 Apr 2016 15:22:36 +0200 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8074826, , Resolve disabled warnings for liblcms In-Reply-To: <56FE5415.4040706@oracle.com> References: <56FE5415.4040706@oracle.com> Message-ID: <56FE761C.1060805@oracle.com> Thanks for fixing this! The build change looks fine. Someone else should look at the code changes. /Erik On 2016-04-01 12:57, prasanta sadhukhan wrote: > Hi All, > > Please review a fix to remove the disabled warnings from lcms library > Bug: https://bugs.openjdk.java.net/browse/JDK-8074826 > webrev: http://cr.openjdk.java.net/~psadhukhan/8074826/webrev.00/ > > One issue was snprintf/sprintf was using arguments > > it8 ->DoubleFormatter > > instead of string format literal like %f or %d > which was causing the warning. I have used > > DEFAULT_DBL_FORMAT which was anyway copied to it8 ->DoubleFormatter. > > Another issue was > > cmsUNUSED_PARAMETER macro was used to suppress unused parameter > warning but this macro was called after the return statement, thereby > E_STATEMENT_NOT_REACHED warning was getting issued. Now, I am Calling > this before the return statements. I have run JPRT build on these > targets *** Build targets: solaris_sparcv9_5.11-product > solaris_sparcv9_5.11-fastdebug solaris_x64_5.11-product > solaris_x64_5.11-fastdebug linux_i586_3.8-product with attributes > distribution=OEL linux_i586_3.8-fastdebug with attributes > distribution=OEL linux_x64_3.8-product with attributes > distribution=OEL linux_x64_3.8-fastdebug with attributes > distribution=OEL macosx_x64_10.9-product macosx_x64_10.9-fastdebug > windows_i586_6.3-product windows_i586_6.3-fastdebug > windows_x64_6.3-product windows_x64_6.3-fastdebug Build Stats: > 14 pass, 0 fail, 0 killed, 0 working, 0 initializing, 0 not started > > Regards > Prasanta > From philip.race at oracle.com Fri Apr 1 16:29:40 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 01 Apr 2016 09:29:40 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8153272: Fix @run tag in CreateFontArrayTest.java Message-ID: <56FEA1F4.2090808@oracle.com> A simple one .. any one reviewer will do. Fix is inline below. Bug :https://bugs.openjdk.java.net/browse/JDK-8153272 -phil. --- a/test/java/awt/FontClass/CreateFont/CreateFontArrayTest.java +++ b/test/java/awt/FontClass/CreateFont/CreateFontArrayTest.java @@ -23,9 +23,9 @@ /* * @test - * @bug 8055463 + * @bug 8055463 8153272 * @summary Test createFont APIs - * @run CreateFontArrayTest + * @run main CreateFontArrayTest */ From philip.race at oracle.com Fri Apr 1 16:31:41 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 01 Apr 2016 09:31:41 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8074826, , Resolve disabled warnings for liblcms In-Reply-To: <56FE5415.4040706@oracle.com> References: <56FE5415.4040706@oracle.com> Message-ID: <56FEA26D.8010209@oracle.com> Sorry, no we don't want this patch. We are not fixing warnings in upstream libraries. -phil. On 04/01/2016 03:57 AM, prasanta sadhukhan wrote: > Hi All, > > Please review a fix to remove the disabled warnings from lcms library > Bug: https://bugs.openjdk.java.net/browse/JDK-8074826 > webrev: http://cr.openjdk.java.net/~psadhukhan/8074826/webrev.00/ > > One issue was snprintf/sprintf was using arguments > > it8 ->DoubleFormatter > > instead of string format literal like %f or %d > which was causing the warning. I have used > > DEFAULT_DBL_FORMAT which was anyway copied to it8 ->DoubleFormatter. > > Another issue was > > cmsUNUSED_PARAMETER macro was used to suppress unused parameter > warning but this macro was called after the return statement, thereby > E_STATEMENT_NOT_REACHED warning was getting issued. Now, I am Calling > this before the return statements. I have run JPRT build on these > targets *** Build targets: solaris_sparcv9_5.11-product > solaris_sparcv9_5.11-fastdebug solaris_x64_5.11-product > solaris_x64_5.11-fastdebug linux_i586_3.8-product with attributes > distribution=OEL linux_i586_3.8-fastdebug with attributes > distribution=OEL linux_x64_3.8-product with attributes > distribution=OEL linux_x64_3.8-fastdebug with attributes > distribution=OEL macosx_x64_10.9-product macosx_x64_10.9-fastdebug > windows_i586_6.3-product windows_i586_6.3-fastdebug > windows_x64_6.3-product windows_x64_6.3-fastdebug Build Stats: > 14 pass, 0 fail, 0 killed, 0 working, 0 initializing, 0 not started > > Regards > Prasanta > From philip.race at oracle.com Fri Apr 1 17:16:38 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 01 Apr 2016 10:16:38 -0700 Subject: [OpenJDK 2D-Dev] [9]: RFR JDK-6357905, , java.awt.JobAttributes.getFromPage() and getToPage() always returns "1". In-Reply-To: <56FE1D1D.7000603@oracle.com> References: <56F8ED8F.6030007@oracle.com> <56F9D724.3060104@oracle.com> <56FCB41E.4000505@oracle.com> <56FD45E5.4020208@oracle.com> <56FD46F4.8040704@oracle.com> <56FE1D1D.7000603@oracle.com> Message-ID: <56FEACF6.90905@oracle.com> Looks good ! -phil. On 04/01/2016 12:02 AM, prasanta sadhukhan wrote: > Please find the modified webrev with check for existing values to > select which order to do the update. > http://cr.openjdk.java.net/~psadhukhan/6357905/webrev.02/ > > I have checked with > 1) initially user sets from=3, to=4 and then user change from=1,to=2 > 2) initially user sets from=3, to=4 and then user change from=2,to=3 > 2) no initial setting from user, so from=1,to=1 and user change > from=2,to=3 > 3)no initial setting from user, so from=1,to=1 and user change > from=1,to=2 > > Regards > Prasanta > On 3/31/2016 9:19 PM, Philip Race wrote: >> Actually never mind about the > or >= difference >> that code is fine since it is the condition under which the exception >> is thrown not the condition that the setting is accepted ! >> >> But you do still need to check the existing values to see which order >> to do the update. >> >> -phil >> >> On 3/31/16, 8:44 AM, Philip Race wrote: >>> >>> >>> On 3/30/16, 10:22 PM, prasanta sadhukhan wrote: >>>> Hi Phil, >>>> >>>> I found out we do not need to change minPage. >>> That makes more sense now. >>> >>>> Changing toPage before frompage should be enough. >>>> Please find the modified webrev: >>>> http://cr.openjdk.java.net/~psadhukhan/6357905/webrev.01/ >>> >>> Don't you need to check ? setToPage also checks that to > from >>> >>> Supposing we start with from=3,to=4 >>> and you want to change it so that from=1,to=2 >>> when you try to change the to page (in the first step) to 3,2 >>> you will also get an IAE. >>> >>> So you need to examine the existing values to decide which order to >>> do the update. >>> >>> A bad API design IMO, it should have been setPageRange(int from, int >>> to) >>> but it is too late for that. >>> >>> BTW I notice it really is a requirement that from < to and to > from >>> >>> eg : I see >>> (toPage != 0 && fromPage > toPage) || >>> >>> I would have expected >= .. >>> >>> .. in fact the docs for setFromPage say : >>> * @param fromPage an integer greater than zero and less than >>> or equal to >>> * toPage >>> >>> So the implementation looks wrong to me for that and setToPage. >>> >>> -phil. >>>> >>>> Regards >>>> Prasanta >>>> On 3/29/2016 6:45 AM, Philip Race wrote: >>>>> Please add an evaluation to the bug report. >>>>> >>>>> As to the fix I am under the impression that min&max page are >>>>> meant to constrain what the user can enter in the dialog so >>>>> if min page & max page are set to "1" then the problem >>>>> may be with those settings ? >>>>> >>>>> i.e the application can set those values and expect the user >>>>> can't change them so updating our code to circumvent that >>>>> seems wrong. >>>>> >>>>> -phil. >>>>> >>>>> On 3/28/16, 1:38 AM, prasanta sadhukhan wrote: >>>>>> Hi All, >>>>>> >>>>>> Please review a print job attribute fix for jdk9. >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6357905 >>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6357905/webrev.00/ >>>>>> >>>>>> The issue was in the Print-dialog, when some pages are specified >>>>>> using "Pages" within "Page range", >>>>>> java.awt.JobAttributes.getFromPage() and getToPage() always >>>>>> returns "1" >>>>>> and not the values as updated by the user. >>>>>> The fix was to get the pageranges attribute as set by the user >>>>>> and obtain the from and to Page range and update the >>>>>> JobAttribute's from and to Page. >>>>>> >>>>>> Regards >>>>>> Prasanta >>>> > From alexander.v.stepanov at oracle.com Fri Apr 1 17:31:22 2016 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Fri, 1 Apr 2016 20:31:22 +0300 Subject: [OpenJDK 2D-Dev] RFR 8152183: [TEST] add test for TIFFField In-Reply-To: <56F90248.7000609@oracle.com> References: <56F2A387.8070506@oracle.com> <56F90248.7000609@oracle.com> Message-ID: <56FEB06A.7040806@oracle.com> Please see the updated webrev: http://cr.openjdk.java.net/~avstepan/8152183/webrev.01/ One more test (for multi-page tiffs) was added; for now to be ignored because of JDK-8148454 Thanks, Alexander On 3/28/2016 1:07 PM, Alexander Stepanov wrote: > Sorry, just a reminder. > > Thanks, > Alexander > > On 3/23/2016 5:09 PM, Alexander Stepanov wrote: >> Hello, >> >> Could you please review the following fix >> http://cr.openjdk.java.net/~avstepan/8152183/webrev.00/ >> for >> https://bugs.openjdk.java.net/browse/JDK-8152183 >> >> Just a single test added. >> >> Thanks, >> Alexander > From philip.race at oracle.com Fri Apr 1 22:19:00 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 01 Apr 2016 15:19:00 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8147544: Remove sun.misc.ManagedLocalsThread from java.desktop Message-ID: <56FEF3D4.9060704@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8147544 Fix: http://cr.openjdk.java.net/~prr/8147544/ ManagedLocalThreads is now superseded by a standard constructor on java.lang.Thread :- http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f90cd2c011bc The various places in JDK that use the internal API need to migrate to this. This fix addresses all (I hope) such usages in java.desktop. I had to invent names for threads in numerous places since the required constructor insists on one. Most uses install a Runnable but in about 4 cases we need to extend Thread. In those cases I added a comment, and in some cases a private no-args constructor() to try to guard against anyone coming along later and accidentally adding & calling a wrong super-class constructor. JPRT has been used to verify the build on all platforms and I am in the process of running some sanity checks on the major platforms to make sure nothing unexpected happens but in general real testing of all of these changes is going to only happen with a nearly full test run, so the earlier the better to get the changes in. -phil. From chris.hegarty at oracle.com Sun Apr 3 15:24:21 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sun, 3 Apr 2016 16:24:21 +0100 Subject: [OpenJDK 2D-Dev] RFR: 8147544: Remove sun.misc.ManagedLocalsThread from java.desktop In-Reply-To: <56FEF3D4.9060704@oracle.com> References: <56FEF3D4.9060704@oracle.com> Message-ID: <67BE8102-8D6D-4E12-A947-5F60DCF1BABB@oracle.com> On 1 Apr 2016, at 23:19, Phil Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8147544 > Fix: http://cr.openjdk.java.net/~prr/8147544/ Your changes look ok to me. Thanks for doing this Phil. -Chris. > ManagedLocalThreads is now superseded by a standard > constructor on java.lang.Thread :- > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f90cd2c011bc > > The various places in JDK that use the internal API need to migrate to this. > > This fix addresses all (I hope) such usages in java.desktop. > > I had to invent names for threads in numerous places since > the required constructor insists on one. > > Most uses install a Runnable but in about 4 cases we need to extend Thread. > In those cases I added a comment, and in some cases a private no-args > constructor() to try to guard against anyone coming along later and accidentally > adding & calling a wrong super-class constructor. > > JPRT has been used to verify the build on all platforms and I am > in the process of running some sanity checks on the major > platforms to make sure nothing unexpected happens but > in general real testing of all of these changes is going to only happen > with a nearly full test run, so the earlier the better to get the changes in. > > -phil. > > From Sergey.Bylokhov at oracle.com Sun Apr 3 16:49:00 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sun, 3 Apr 2016 19:49:00 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8147544: Remove sun.misc.ManagedLocalsThread from java.desktop In-Reply-To: <67BE8102-8D6D-4E12-A947-5F60DCF1BABB@oracle.com> References: <56FEF3D4.9060704@oracle.com> <67BE8102-8D6D-4E12-A947-5F60DCF1BABB@oracle.com> Message-ID: <5701497C.40301@oracle.com> The fix looks fine, but we will need to use correct Thread constructor, it will not easy tracked unlike the usage of separate class. On 03.04.16 18:24, Chris Hegarty wrote: > > On 1 Apr 2016, at 23:19, Phil Race wrote: > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8147544 >> Fix: http://cr.openjdk.java.net/~prr/8147544/ > > Your changes look ok to me. Thanks for doing this Phil. > > -Chris. > >> ManagedLocalThreads is now superseded by a standard >> constructor on java.lang.Thread :- >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f90cd2c011bc >> >> The various places in JDK that use the internal API need to migrate to this. >> >> This fix addresses all (I hope) such usages in java.desktop. >> >> I had to invent names for threads in numerous places since >> the required constructor insists on one. >> >> Most uses install a Runnable but in about 4 cases we need to extend Thread. >> In those cases I added a comment, and in some cases a private no-args >> constructor() to try to guard against anyone coming along later and accidentally >> adding & calling a wrong super-class constructor. >> >> JPRT has been used to verify the build on all platforms and I am >> in the process of running some sanity checks on the major >> platforms to make sure nothing unexpected happens but >> in general real testing of all of these changes is going to only happen >> with a nearly full test run, so the earlier the better to get the changes in. >> >> -phil. >> >> > -- Best regards, Sergey. From philip.race at oracle.com Sun Apr 3 17:50:07 2016 From: philip.race at oracle.com (Philip Race) Date: Sun, 03 Apr 2016 10:50:07 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8147544: Remove sun.misc.ManagedLocalsThread from java.desktop In-Reply-To: <5701497C.40301@oracle.com> References: <56FEF3D4.9060704@oracle.com> <67BE8102-8D6D-4E12-A947-5F60DCF1BABB@oracle.com> <5701497C.40301@oracle.com> Message-ID: <570157CF.2060008@oracle.com> Yes, it will be much harder to audit that the correct constructor has been used, so it needs to be a reviewer checklist item. -phil. On 4/3/16, 9:49 AM, Sergey Bylokhov wrote: > The fix looks fine, but we will need to use correct Thread > constructor, it will not easy tracked unlike the usage of separate class. > > On 03.04.16 18:24, Chris Hegarty wrote: >> >> On 1 Apr 2016, at 23:19, Phil Race wrote: >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147544 >>> Fix: http://cr.openjdk.java.net/~prr/8147544/ >> >> Your changes look ok to me. Thanks for doing this Phil. >> >> -Chris. >> >>> ManagedLocalThreads is now superseded by a standard >>> constructor on java.lang.Thread :- >>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f90cd2c011bc >>> >>> The various places in JDK that use the internal API need to migrate >>> to this. >>> >>> This fix addresses all (I hope) such usages in java.desktop. >>> >>> I had to invent names for threads in numerous places since >>> the required constructor insists on one. >>> >>> Most uses install a Runnable but in about 4 cases we need to extend >>> Thread. >>> In those cases I added a comment, and in some cases a private no-args >>> constructor() to try to guard against anyone coming along later and >>> accidentally >>> adding & calling a wrong super-class constructor. >>> >>> JPRT has been used to verify the build on all platforms and I am >>> in the process of running some sanity checks on the major >>> platforms to make sure nothing unexpected happens but >>> in general real testing of all of these changes is going to only happen >>> with a nearly full test run, so the earlier the better to get the >>> changes in. >>> >>> -phil. >>> >>> >> > > From jayathirth.d.v at oracle.com Mon Apr 4 10:59:35 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 4 Apr 2016 03:59:35 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9]: RFR JDK-6357905, , java.awt.JobAttributes.getFromPage() and getToPage() always returns "1". In-Reply-To: <56FEACF6.90905@oracle.com> References: <56F8ED8F.6030007@oracle.com> <56F9D724.3060104@oracle.com> <56FCB41E.4000505@oracle.com> <56FD45E5.4020208@oracle.com> <56FD46F4.8040704@oracle.com> <56FE1D1D.7000603@oracle.com> <56FEACF6.90905@oracle.com> Message-ID: Hi Prasanta, Changes are fine and test case looks good. Please make proper indentation for jtreg comments before checkin. Thanks, Jay -----Original Message----- From: Phil Race Sent: Friday, April 01, 2016 10:47 PM To: prasanta sadhukhan Cc: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [9]: RFR JDK-6357905, , java.awt.JobAttributes.getFromPage() and getToPage() always returns "1". Looks good ! -phil. On 04/01/2016 12:02 AM, prasanta sadhukhan wrote: > Please find the modified webrev with check for existing values to > select which order to do the update. > http://cr.openjdk.java.net/~psadhukhan/6357905/webrev.02/ > > I have checked with > 1) initially user sets from=3, to=4 and then user change from=1,to=2 > 2) initially user sets from=3, to=4 and then user change from=2,to=3 > 2) no initial setting from user, so from=1,to=1 and user change > from=2,to=3 > 3)no initial setting from user, so from=1,to=1 and user change > from=1,to=2 > > Regards > Prasanta > On 3/31/2016 9:19 PM, Philip Race wrote: >> Actually never mind about the > or >= difference that code is fine >> since it is the condition under which the exception is thrown not the >> condition that the setting is accepted ! >> >> But you do still need to check the existing values to see which order >> to do the update. >> >> -phil >> >> On 3/31/16, 8:44 AM, Philip Race wrote: >>> >>> >>> On 3/30/16, 10:22 PM, prasanta sadhukhan wrote: >>>> Hi Phil, >>>> >>>> I found out we do not need to change minPage. >>> That makes more sense now. >>> >>>> Changing toPage before frompage should be enough. >>>> Please find the modified webrev: >>>> http://cr.openjdk.java.net/~psadhukhan/6357905/webrev.01/ >>> >>> Don't you need to check ? setToPage also checks that to > from >>> >>> Supposing we start with from=3,to=4 >>> and you want to change it so that from=1,to=2 when you try to change >>> the to page (in the first step) to 3,2 you will also get an IAE. >>> >>> So you need to examine the existing values to decide which order to >>> do the update. >>> >>> A bad API design IMO, it should have been setPageRange(int from, int >>> to) >>> but it is too late for that. >>> >>> BTW I notice it really is a requirement that from < to and to > from >>> >>> eg : I see >>> (toPage != 0 && fromPage > toPage) || >>> >>> I would have expected >= .. >>> >>> .. in fact the docs for setFromPage say : >>> * @param fromPage an integer greater than zero and less than >>> or equal to >>> * toPage >>> >>> So the implementation looks wrong to me for that and setToPage. >>> >>> -phil. >>>> >>>> Regards >>>> Prasanta >>>> On 3/29/2016 6:45 AM, Philip Race wrote: >>>>> Please add an evaluation to the bug report. >>>>> >>>>> As to the fix I am under the impression that min&max page are >>>>> meant to constrain what the user can enter in the dialog so if min >>>>> page & max page are set to "1" then the problem may be with those >>>>> settings ? >>>>> >>>>> i.e the application can set those values and expect the user can't >>>>> change them so updating our code to circumvent that seems wrong. >>>>> >>>>> -phil. >>>>> >>>>> On 3/28/16, 1:38 AM, prasanta sadhukhan wrote: >>>>>> Hi All, >>>>>> >>>>>> Please review a print job attribute fix for jdk9. >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6357905 >>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6357905/webrev.00/ >>>>>> >>>>>> The issue was in the Print-dialog, when some pages are specified >>>>>> using "Pages" within "Page range", >>>>>> java.awt.JobAttributes.getFromPage() and getToPage() always >>>>>> returns "1" >>>>>> and not the values as updated by the user. >>>>>> The fix was to get the pageranges attribute as set by the user >>>>>> and obtain the from and to Page range and update the >>>>>> JobAttribute's from and to Page. >>>>>> >>>>>> Regards >>>>>> Prasanta >>>> > From prasanta.sadhukhan at oracle.com Mon Apr 4 11:21:23 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Mon, 4 Apr 2016 16:51:23 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6921664, , The amount of copies and the printer job name is not passed to the implementing Message-ID: <57024E33.3000801@oracle.com> Hi All, Please review a fix for jdk9 Bug: https://bugs.openjdk.java.net/browse/JDK-6921664 webrev: http://cr.openjdk.java.net/~psadhukhan/6921664/webrev.00/ The issue was for a third party non-builtin print service, if the application sets the copies, jobname attribute these attributes are not passed to the third party print() implementation. This is because when we find there is a non-builtin print service, we call spoolService() in RasterPrinterJob which , even though it creates an attribute set via attributes = new HashPrintRequestAttributeSet(); but it does not populate the attributes with the attributes set by the application, so when we call job.print(doc, attributes); we were passing attributes without any attribute set. I added the minimal copies and jobName attributes to the attribute list before calling the 3rdparty print implementation. Regards Prasanta From alexey.ivanov at oracle.com Mon Apr 4 12:52:28 2016 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Mon, 4 Apr 2016 15:52:28 +0300 Subject: [OpenJDK 2D-Dev] [8u-dev] Request for review and approval for bug 8147807: crash in libkcms.so on linux-sparc In-Reply-To: <56EAF62D.60102@oracle.com> References: <56BC9860.7050006@oracle.com> <56BD9576.4090904@oracle.com> <56BDA2AF.9000209@oracle.com> <56C1941F.3040900@oracle.com> <56EAF62D.60102@oracle.com> Message-ID: <5702638C.9050304@oracle.com> Thanks to everyone for reviewing. I've pushed the fix today. Regards, Alexey On 17.03.2016 21:23, Phil Race wrote: > +1 > > -phil. > > On 02/15/2016 01:02 AM, Erik Joelsson wrote: >> Looks good. >> /Erik >> >> On 2016-02-12 10:15, Se?n Coffey wrote: >>> Approved for jdk8u-dev once you have a peer code review. >>> >>> Regards, >>> Sean. >>> >>> On 12/02/2016 08:19, Alexey Ivanov wrote: >>>> I forgot to add jdk8u-dev list... >>>> >>>> On 11.02.2016 17:19, Alexey Ivanov wrote: >>>>> Hello, >>>>> >>>>> Could you please review the fix for JDK-8147807 and approve push >>>>> to 8u-dev? >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8147807 >>>>> Webrev: http://cr.openjdk.java.net/~aivanov/8147807/jdk8/webrev.00/ >>>>> >>>>> The issue is not relevant to jdk 9. >>>>> >>>>> The fix just removes kcms service leaving lcms as the only option >>>>> which is the default in jdk8. >>>>> >>>>> >>>>> Thanks in advance, >>>>> Alexey >>>> >>> >> > From jayathirth.d.v at oracle.com Mon Apr 4 15:35:15 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 4 Apr 2016 08:35:15 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8153363: Redundant check for number of components in PackedColorModel.equals() method Message-ID: <4bf9e2d9-e542-48d9-ac40-625a4200ca80@default> Hi, Please review the following fix in JDK9: Bug : https://bugs.openjdk.java.net/browse/JDK-8153363 Webrev : http://cr.openjdk.java.net/~jdv/8153363/webrev.00/ Issue : We have redundant check for equality of number of components in PackedColorModel. Solution : Number of components equality is verified in Parent class(ColorModel) and we call super.equals(), no need for checking the equality again. JCK test "api/java_awt/Image/PackedColorModel/equalsTests.java" verifies equals() method so added noreg-jck label in bug. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Apr 4 17:37:44 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 04 Apr 2016 10:37:44 -0700 Subject: [OpenJDK 2D-Dev] Result: New 2D Group Member: Alexander Scherbatiy Message-ID: <5702A668.8090001@oracle.com> The vote for Alexander Scherbatiy [1] is now closed. Yes: 4 Veto: 0 Abstain: 0 According to the OpenJDK Bylaws definition of Lazy Consensus [2], this is sufficient to approve the nomination. -phil. [1] http://mail.openjdk.java.net/pipermail/2d-dev/2016-March/006513.html [2] http://openjdk.java.net/bylaws#lazy-consensus From philip.race at oracle.com Mon Apr 4 21:28:43 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 04 Apr 2016 14:28:43 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8153363: Redundant check for number of components in PackedColorModel.equals() method In-Reply-To: <4bf9e2d9-e542-48d9-ac40-625a4200ca80@default> References: <4bf9e2d9-e542-48d9-ac40-625a4200ca80@default> Message-ID: <5702DC8B.8020104@oracle.com> This looks fine although I am unable to work out how a JCK test detected the duplication -phil. On 04/04/2016 08:35 AM, Jayathirth D V wrote: > > Hi, > > _Please review the following fix in JDK9:_ > > __ > > Bug : https://bugs.openjdk.java.net/browse/JDK-8153363 > > Webrev : http://cr.openjdk.java.net/~jdv/8153363/webrev.00/ > > > Issue : We have redundant check for equality of number of components > in PackedColorModel. > > Solution : Number of components equality is verified in Parent > class(ColorModel) and we call super.equals(), no need for checking the > equality again. > > JCK test "api/java_awt/Image/PackedColorModel/equalsTests.java" > verifies equals() method so added noreg-jck label in bug. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Mon Apr 4 21:43:42 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 4 Apr 2016 14:43:42 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8153363: Redundant check for number of components in PackedColorModel.equals() method In-Reply-To: <4bf9e2d9-e542-48d9-ac40-625a4200ca80@default> References: <4bf9e2d9-e542-48d9-ac40-625a4200ca80@default> Message-ID: <5702E00E.3080509@oracle.com> Looks good... ...jim On 4/4/16 8:35 AM, Jayathirth D V wrote: > Hi, > > _Please review the following fix in JDK9:_ > > __ > > Bug : https://bugs.openjdk.java.net/browse/JDK-8153363 > > Webrev : http://cr.openjdk.java.net/~jdv/8153363/webrev.00/ > > Issue : We have redundant check for equality of number of components in > PackedColorModel. > > Solution : Number of components equality is verified in Parent > class(ColorModel) and we call super.equals(), no need for checking the > equality again. > > JCK test "api/java_awt/Image/PackedColorModel/equalsTests.java" verifies > equals() method so added noreg-jck label in bug. > > Thanks, > > Jay > From philip.race at oracle.com Mon Apr 4 22:33:09 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 04 Apr 2016 15:33:09 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8134986: Incorrect use of ConcurrentHashMap.contains in SunFontManager.java Message-ID: <5702EBA5.1020304@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8134986 When converted from a HashSet to a HashMap contains() should have changed to containsKey(). It does not lead to duplicate fonts because it is caught later on but it might lead to wasted work One line fix in line below diff --git a/src/java.desktop/share/classes/sun/font/SunFontManager.java b/src/java.desktop/share/classes/sun/font/SunFontManager.java --- a/src/java.desktop/share/classes/sun/font/SunFontManager.java +++ b/src/java.desktop/share/classes/sun/font/SunFontManager.java @@ -1843,7 +1843,7 @@ private PhysicalFont registerFontFile(String file) { if (new File(file).isAbsolute() && - !registeredFonts.contains(file)) { + !registeredFonts.containsKey(file)) { int fontFormat = FONTFORMAT_NONE; int fontRank = Font2D.UNKNOWN_RANK; if (ttFilter.accept(null, file)) { -phil. From jayathirth.d.v at oracle.com Tue Apr 5 05:23:41 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 4 Apr 2016 22:23:41 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8153363: Redundant check for number of components in PackedColorModel.equals() method In-Reply-To: <5702DC8B.8020104@oracle.com> References: <4bf9e2d9-e542-48d9-ac40-625a4200ca80@default> <5702DC8B.8020104@oracle.com> Message-ID: Hi Phil, I was analyzing HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-7107905"JDK-7107905 as part of it I was looking for any other subclass of ColorModel which doesn't have override equals() method. While doing this I found out that in PackedColorModel we are doing redundant check for number of components. So I raised HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8153363"JDK-8153363 to resolve this minor issue. I mentioned JCK test in mail so that I can add noreg-jck label in bug. Thanks, Jay From: Phil Race Sent: Tuesday, April 05, 2016 2:59 AM To: Jayathirth D V Cc: Prasanta Sadhukhan; 2d-dev Subject: Re: Review Request for JDK-8153363: Redundant check for number of components in PackedColorModel.equals() method This looks fine although I am unable to work out how a JCK test detected the duplication -phil. On 04/04/2016 08:35 AM, Jayathirth D V wrote: Hi, Please review the following fix in JDK9: Bug : https://bugs.openjdk.java.net/browse/JDK-8153363 Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8153363/webrev.00/"http://cr.openjdk.java.net/~jdv/8153363/webrev.00/ Issue : We have redundant check for equality of number of components in PackedColorModel. Solution : Number of components equality is verified in Parent class(ColorModel) and we call super.equals(), no need for checking the equality again. JCK test "api/java_awt/Image/PackedColorModel/equalsTests.java" verifies equals() method so added noreg-jck label in bug. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Tue Apr 5 11:08:39 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Tue, 5 Apr 2016 16:38:39 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6801613, , Cross-platform pageDialog and printDialog top margin entry broken Message-ID: <57039CB7.7090300@oracle.com> Hi All, Please review a fix for jdk9 Bug: https://bugs.openjdk.java.net/browse/JDK-6801613 webrev: http://cr.openjdk.java.net/~psadhukhan/6801613/webrev.00/ The issue was the PrinterJob cross-platform "Page setup dialog" top margin entry is broken. If you enter a value in the top margin field and hit "OK", the value is not updated in the PageFormat instance return value, nor is it updated in the attribute set used to call the pageDialog method. Tabbing out of the top margin field before hitting OK does not fix the problem. Likewise, clicking on a different margin entry field before hitting OK also does not fix the problem. The reason was we created topMargin JFormattedTextField once and added focusListener and ActionListener to this textfield but we overwrote the topMargin textField again by creating another instance and in that instance, we failed to add actionListener or focusListener, so when we tabbed out of topmargin field, focusLost() method was not called which would have called updateMargin() method to update the margins. Fix was to remove this erroneous instance creation and overwriting of topMargin textfield. Regards Prasanta From alexandr.scherbatiy at oracle.com Tue Apr 5 14:30:01 2016 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 5 Apr 2016 18:30:01 +0400 Subject: [OpenJDK 2D-Dev] [9] Review request for 8152309 Seamless way of using image filters with multi-resolution images Message-ID: <5703CBE9.8030800@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8152309 webrev: http://cr.openjdk.java.net/~alexsch/8152309/webrev.00 The purpose of the fix is to allow to apply an image filter for a multi-resolution image to get new multi-resolution image so the code below works without changes: ---------- Image mrImage = getMultiResolutionImage(); ImageProducer mriProducer = new FilteredImageSource(mrImage.getSource(), new CropImageFilter(x, y, w, h)); Image filteredMRImage = Toolkit.getDefaultToolkit().createImage(mriProducer); ---------- The Image producer needs to be updated to contain a set of resolution-variant image producers. It can be done introducing a new MultiResolution[Image]Producer interface. However, the FilteredImageSource which takes an original image producer as a constructor argument needs to be declared as MultiResolution[Image]Producer even for ordinary image producers. I chose to add the getRVProducers() method directly to the ImageProducer interface. The option to add a method which request a resolution variant producer for the given image size (getRVProducer(width, height) ) seems is not possible because the result multi-resolution image can be loaded by a MediaTracker which can load only finite number of resolution variants. Applying an image filter to resolution-variant producers requires to scale filters which use fixed image size (like CropImageFilter and ReplicateScaleFilter). There should be a way to get a scaled filter using the original one. The resolution variant image producer need to provide necessary scale factors for the used filter. To do that getScaledFilterInstance(scaleX, scaleY) method is added to the ImageFilter and public ResolutionVariantItem class which can hold image or image producer with associated scale factors is introduced. There is an interesting problem in SunGraphics2D where a multi-resolution image size is requested. To do that it is necessary to have an image observer which needs to redirect calls to the base image observer. The resolution variant observer needs to know scale factors to recalculate given [x, y, width, height] values. The scale factors are provided by toolkit multi-resolution image but for non toolkit multi-resolution images they need to be calculated dividing a rv-image size to base image size. It looks like a closed loop when to know scale factors it needs to get a rv-image size but for this it is necessary to use an image observer which requires scale factors. The current fix just divides rv-image size to base image size for non toolkit multi-resolution images to get scale factors . Thanks, Alexandr. From Sergey.Bylokhov at oracle.com Tue Apr 5 14:34:42 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 5 Apr 2016 17:34:42 +0300 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream In-Reply-To: <111c7914-e6c1-4805-9c3c-d8f092f3faa3@default> References: <99cb1549-30b5-44af-b399-ebed22255cf8@default> <56E997F1.2070605@oracle.com> <56E9C39D.6090701@oracle.com> <56E9D1D5.8090500@oracle.com> <56EAB79C.1080503@oracle.com> <88e50a67-fdd2-4b97-aa19-3ac5d419e2cf@default> <56EAFD38.80604@oracle.com> <56F0A94C.8080703@oracle.com> <56F17140.2070208@oracle.com> <481ff313-103f-4a71-bec9-44a3fa0a70ef@default> <56F3294E.1040306@oracle.com> <387cc752-40cd-4d3a-9350-e53193d80dfd@default> <56F9AC5E.8010107@oracle.com> <56FA77D8.3030108@oracle.com> <111c7914-e6c1-4805-9c3c-d8f092f3faa3@default> Message-ID: <5703CD02.6010204@oracle.com> On 30.03.16 9:48, Jayathirth D V wrote: > Thanks for pointing it out. It looks like redundant try-catch block. There is small code clean up is possible after your latest change: 1587 ImageOutputStream stream = null; 1588 stream = createImageOutputStream(output); I guess such code is redundant too. > I have removed these blocks in write() methods so that we are handling "cant create cache file" exception in common way in all read() and write() methods. > Also I have updated test case description to hold true for only those read() and write() methods where we are using createImageXXXStream() for readability. > > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/8044289/webrev.06/ > > After CCC is done we will push above change to repo. > > Thanks, > Jay > > -----Original Message----- > From: Sergey Bylokhov > Sent: Tuesday, March 29, 2016 6:11 PM > To: Philip Race; Jayathirth D V > Cc: 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream > > I am not sure what is the reason of this code? > 1546 try { > 1547 output.delete(); > 1548 stream = createImageOutputStream(output); > 1549 } catch (IOException e) { > 1550 throw e; > 1551 } > > On 29.03.16 1:12, Philip Race wrote: >> This all looks fine to me. Although no new Exception types are thrown >> I think we need a CCC anyway, so please prepare and get that approved >> before pushing. >> >> -phil. >> >> On 3/28/16, 3:30 AM, Jayathirth D V wrote: >>> >>> Hi Phil, >>> >>> After discussion with Sergey we have come to conclusion that Sergey >>> is okay with throwing exception or returning null/false. >>> >>> So I have modified the webrev to throw exception. >>> >>> Also in write() I have modified the catch block to just throw the >>> caught exception without adding message since it will create >>> confusion between the case where we are not able to create cache and >>> when >>> createImageOutputStream() returns null. >>> >>> Regarding catch block of createImageOutputStream() only when we >>> usecache is true we use FileCacheImageOutputStream() and it throws >>> IOException so I think there is no need to add extra check before >>> throwing IOException. >>> >>> Please find updated webrev for review : >>> >>> http://cr.openjdk.java.net/~jdv/8044289/webrev.04/ >>> >>> >>> Thanks, >>> >>> Jay >>> >>> *From:*Jayathirth D V >>> *Sent:* Thursday, March 24, 2016 3:52 PM >>> *To:* Philip Race >>> *Cc:* Sergey Bylokhov; 2d-dev at openjdk.java.net >>> *Subject:* RE: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >>> ImageIO.read() and write() NPE is not handled properly for stream >>> >>> Hi Phil, >>> >>> We can change the code to something like : >>> >>> 1522 * @return false if no appropriate writer is >>> found or >>> 1523 * when needed stream is null. >>> >>> 1545 try { >>> 1546 output.delete(); >>> 1547 stream = createImageOutputStream(output); >>> 1548 } catch (IOException e) { >>> 1549 *throw e;* >>> 1550 } >>> >>> In this case we will be throwing IOException when we are not able to >>> create cache file and stream is null. >>> >>> And return null/false when createImageXXXStream returns null. Also we >>> can add check before throwing IIOException from createImageXXXStream >>> for usecache. >>> >>> 350 >>> 351 boolean usecache = getUseCache() && hasCachePermission(); >>> 352 >>> 353 while (iter.hasNext()) { >>> 354 ImageInputStreamSpi spi = iter.next(); >>> 355 if (spi.getInputClass().isInstance(input)) { >>> 356 try { >>> 357 return spi.createInputStreamInstance(input, >>> 358 usecache, >>> 359 >>> getCacheDirectory()); >>> 360 } catch (IOException e) { >>> 361 *if (usecache)* >>> 362 throw new IIOException("Can't create cache >>> file!", e); >>> 363 } >>> 364 } >>> 365 } >>> >>> This will be one of the approach. >>> >>> Or we can throw IOException in all the cases with additional check in >>> createImageXXXStream for usecache. This will be like throwing >>> IOException when createImageXXXStream returns null/false or it throws >>> IIOException when it cant create cache file. This will be another >>> approach. Please let us know your inputs. >>> >>> Thanks, >>> >>> Jay >>> >>> *From:*Philip Race >>> *Sent:* Thursday, March 24, 2016 5:10 AM >>> *To:* Jayathirth D V >>> *Cc:* Sergey Bylokhov; 2d-dev at openjdk.java.net >>> >>> *Subject:* Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >>> ImageIO.read() and write() NPE is not handled properly for stream >>> >>> I don't think this is ready and we need to discuss whether to rework it. >>> >>> In general I think I prefer IIO rather than null when we have a stream problem. >>> >>> >>> For one thing you have this change :- >>> >>> 1522 * @return false if no appropriate writer is >>> found or >>> 1523 * not able to create required ImageOutputStream. >>> yet the implementation says :- >>> 1545 try { >>> 1546 output.delete(); >>> 1547 stream = createImageOutputStream(output); >>> 1548 } catch (IOException e) { >>> 1549 throw new IIOException("Can't create output stream!", e); >>> 1550 } >>> So whilst "null" would mean we cannot find an IOS SPI it isn't the >>> only reason we fail to create the IOS A null return seems to get >>> passed through to doWrite() which probably throws IIOE And I think >>> that the implementation is actually right here where it throws an >>> exception. >>> The ability to create an image input or output stream could be >>> because of some kind of problem opening the file, or with the IIS or >>> IOS implementations - like they were de-registered. I think in many >>> if not all of these cases IOE - or IIOE is what we want. >>> Also since we call createImageInputStream() - which is public - we >>> need to look at that, and what it does, which is also something to consider. >>> If it returns null, that seems to mean that no suitable SPI is >>> registered which can only happen if they are de-registered. For the >>> methods where we use createImageInputStream() I think it is fair to >>> turn that into IIOE BTW I note that the code there says :- >>> 350 >>> 351 boolean usecache = getUseCache() && hasCachePermission(); >>> 352 >>> 353 while (iter.hasNext()) { >>> 354 ImageInputStreamSpi spi = iter.next(); >>> 355 if (spi.getInputClass().isInstance(input)) { >>> 356 try { >>> 357 return spi.createInputStreamInstance(input, >>> 358 usecache, >>> 359 getCacheDirectory()); >>> 360 } catch (IOException e) { >>> 361 throw new IIOException("Can't create cache file!", e); >>> 362 } >>> 363 } >>> 364 } >>> So far I can see that means it will claim any Exception that is >>> generated is because it could not create the cache file without any proof of that and even if "useCache" is false. >>> It seems to imply to me that the author was not considering things >>> like someone passing a closed InputStream .. probably we ought to be >>> more vague in this case or look more deeply at what we can tell from whether it is IIOE or IOE. >>> -phil. >>> >>> On 3/22/16, 10:49 AM, Jayathirth D V wrote: >>> >>> Thanks for the review Sergey. >>> >>> Can I get +1 for this please? >>> >>> -Jay >>> >>> -----Original Message----- >>> >>> From: Sergey Bylokhov >>> >>> Sent: Tuesday, March 22, 2016 9:52 PM >>> >>> To: Jayathirth D V; Philip Race >>> >>> Cc:2d-dev at openjdk.java.net >>> >>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >>> ImageIO.read() and write() NPE is not handled properly for stream >>> >>> This fix looks fine to me. >>> >>> At least it made all code work in a similar way. But probably someone will have other opinion? >>> >>> On 22.03.16 12:34, Jayathirth D V wrote: >>> >>> Hi Sergey, >>> >>> I have unified changes related to ImageIO.read() and ImageIO.write(). >>> >>> In case of read() we will be returning null when createImageInputStream() returns null. >>> >>> In case of write() we will be returning false when createImageOutputStream() returns null. >>> >>> Please find updated webrev for review: >>> >>> http://cr.openjdk.java.net/~jdv/8044289/webrev.03/ >>> >>> >>> Thanks, >>> >>> Jay >>> >>> -----Original Message----- >>> >>> From: Sergey Bylokhov >>> >>> Sent: Tuesday, March 22, 2016 7:39 AM >>> >>> To: Jayathirth D V; Philip Race >>> >>> Cc:2d-dev at openjdk.java.net >>> >>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 >>> : In >>> >>> ImageIO.read() and write() NPE is not handled properly for >>> stream >>> >>> Hi, Jay. >>> >>> Since we decided to update the specification we get an additional flexibility in the fix, because we can update the "@exception IOException" part of javadoc and describe that it can be thrown if ImageXXXStream cannot be created. >>> >>> I don't see a big differences of both approaches in case of write() methods, but in case of read(which has the similar issue but was skipped in the fix) there is a difference. >>> >>> Note that the read(File) unlike other methods throws the >>> unspecified >>> >>> IIOException exception if ImageXXXStream cannot be created. >>> We can >>> >>> think about unification of read/write methods in ImageIO. Hmm >>> but even >>> >>> then >>> >>> read() in some cases will return null and in some cases throw an exception.... >>> >>> and createImageInputStream/createImageOutputStream() will look alien as they always return null not an exception. >>> >>> Another possible unification is to update javadoc for all >>> methods, >>> >>> that they will return null if related providers are not >>> found(in this >>> >>> case "throw new IIOException("Can't create an ImageInputStream!"))" >>> >>> should be removed from read(File); >>> >>> On 21.03.16 10:26, Jayathirth D V wrote: >>> >>> Hi Sergey, >>> >>> For the second approach I have created webrev for review. >>> >>> Please review updated webrev : >>> >>> http://cr.openjdk.java.net/~jdv/8044289/webrev.02/ >>> >>> >>> Thanks, >>> >>> Jay >>> >>> -----Original Message----- >>> >>> From: Jayathirth D V >>> >>> Sent: Friday, March 18, 2016 2:23 PM >>> >>> To: Sergey Bylokhov >>> >>> Cc:2d-dev at openjdk.java.net >>> ; Philip Race >>> >>> Subject: RE: [OpenJDK 2D-Dev] Review Request for >>> JDK-8044289 : In >>> >>> ImageIO.read() and write() NPE is not handled properly >>> for stream >>> >>> Hi Sergey, >>> >>> Thanks for your inputs. >>> >>> Indeed all the null values returned by createImageInputStream() and createImageInputStream() are valid only. >>> >>> I went through the code more and found that there is no need for fix in ImageIO.read() methods as null stream is handled in read(ImageInputStream stream) which is called by all the remaining read() API's through IAE. So i can remove the changes made in ImageIO.read() functions. Also istream is closed in finally block of read(url). >>> >>> For ImageIO.write(File) & ImageIO.write(OutputStream) NPE we have two approaches for fix: >>> >>> 1) Keep the present changes of throwing IOException when stream is null and change the throw clause of write() spec mentioning: >>> >>> "IOException - if an error occurs during writing or not able to create required ImageOutputStream" >>> >>> 2) Remove the present changes and handle null in doWrite() method by returning false when stream is null & add code in finally block to close the stream only when stream is not null. Along with this we can also change Returns clause of spec to mention that write() might return false when we are not able to create ImageOutputStream. >>> >>> >>> >>> private static boolean doWrite(RenderedImage >>> im, ImageWriter writer, >>> >>> >>> ImageOutputStream output) throws IOException { >>> >>> if (writer == null) { >>> >>> return false; >>> >>> } >>> >>> + if (output == null) { >>> >>> + return false; >>> >>> + } >>> >>> >>> >>> try { >>> >>> return doWrite(im, >>> writer, stream); >>> >>> } finally { >>> >>> + if (stream != null) >>> >>> stream.close(); >>> >>> } >>> >>> >>> >>> Returns : >>> >>> false if no appropriate writer is found or not able to create required ImageOutputStream. >>> >>> Please let me know your inputs. >>> >>> Thanks, >>> >>> Jay >>> >>> -----Original Message----- >>> >>> From: Sergey Bylokhov >>> >>> Sent: Friday, March 18, 2016 12:24 AM >>> >>> To: Jayathirth D V >>> >>> Cc:2d-dev at openjdk.java.net >>> ; Philip Race >>> >>> Subject: Re: [OpenJDK 2D-Dev] Review Request for >>> JDK-8044289 : In >>> >>> ImageIO.read() and write() NPE is not handled properly >>> for stream >>> >>> On 17.03.16 21:14, Jayathirth D V wrote: >>> >>> There are many places in createImageInputStream() and createImageOutputStream() where it will return null for stream. >>> >>> But when why you change the write/read methods? They should take null into account and work according to specification. If some bogus null returns from createImageInputStream/createImageOutputStream then it should be fixed in these methods. >>> >>> So for NPE described in bug to occur there can be multiple paths: >>> >>> 1) One of the path described in bug is when theRegistry.getServiceProviders() throws IAE and we return null. >>> >>> This is the case when we have no installed spi and should return null/false. >>> >>> 2) When we pass non-existent file path to ImageIO (as described inhttp://stackoverflow.com/questions/11153200/with-imageio-write-api-call-i-get-nullpointerexception ). Here we catch FileNotFoundException but still we return stream as null at the end which will cause NPE further. >>> >>> This is same thing described in the bug(about stream.close()). The write method call createImageOutputStream() and got FileNotFoundException. >>> >>> This exception should be propagated to the user, but it is replaced in the finally block, because we try to close the stream=null. So the fix for this particular case is to check the stream to null in finally, No? >>> >>> 3) When we don't support the provider and theRegistry.getServiceProviders() return iterator with size zero. >>> >>> This means that our providers do not support this case, and we should return null/false. >>> >>> For us to follow first scenario we need access to categoryMap of IIORegistry and delete the ImageInputStreamSpi/ ImageOutputStreamSpi but I was not able to find a way to tamper it from test case. If we follow second case FileNotFoundException will be thrown by default eventhough we handle NPE. >>> >>> But you change the code and we now contradicts the specification, in your case the test should expect false/null from write()/read(). >>> >>> In the test case we are trying to following third scenario to get stream as null to verify the code changes. >>> >>> To catch the bogus null we should try to use another approach, or change the spec. But it seems all null values above are correct, we should be ready for them. >>> >>> As part of collective fix we are throwing IOException which will indicate that we are not able to create required stream. >>> >>> Thanks, >>> >>> Jay >>> >>> -----Original Message----- >>> >>> From: Sergey Bylokhov >>> >>> Sent: Thursday, March 17, 2016 7:27 PM >>> >>> To: Phil Race >>> >>> Cc: Jayathirth D V;2d-dev at openjdk.java.net >>> >>> >>> Subject: Re: [OpenJDK 2D-Dev] Review Request for >>> JDK-8044289 : In >>> >>> ImageIO.read() and write() NPE is not handled >>> properly for stream >>> >>> On 17.03.16 0:36, Phil Race wrote: >>> >>> I don't think that is the actual reason here >>> >>> But the test doing exactly this thing -> deregister >>> all spi => in >>> >>> this case according to specification all related >>> >>> methods(read/write/creatImageInputStream/creatImageOutputStream) should return null or false. >>> >>> - it seems likely that there >>> >>> was some kind of internal error or bad SPI causing this. >>> >>> So throwing an exception seems more appropriate. >>> >>> the problem was in some of our methods which do not expect null in some places(like stream.close() from the bug description). >>> >>> And also the bug was originally solely about write(..). >>> >>> -phil. >>> >>> On 03/16/2016 01:35 PM, Sergey Bylokhov wrote: >>> >>> As far as I understand the >>> createImageInputStream() returns null >>> >>> is this stream is unsupported by current >>> plugins via spi. Probably >>> >>> the >>> >>> read() method should return null too? >>> >>> /** >>> >>> * Returns a {@code BufferedImage} as >>> the result of decoding >>> >>> * a supplied {@code InputStream} >>> with an {@code ImageReader} >>> >>> * chosen automatically from among those currently registered. >>> >>> * The {@code InputStream} is wrapped >>> in an >>> >>> * {@code ImageInputStream}. If no >>> registered >>> >>> * {@code ImageReader} claims to be >>> able to read the >>> >>> * resulting stream, {@code null} is returned. >>> >>> * >>> >>> ....... >>> >>> * @return a {@code BufferedImage} >>> containing the decoded >>> >>> * contents of the input, or {@code null}. >>> >>> */ >>> >>> public static BufferedImage >>> read(InputStream input) throws >>> >>> IOException >>> >>> On 16.03.16 20:29, Philip Race wrote: >>> >>> The test writes out into "test.src". >>> >>> I believe that you should treat that as a "read-only" location. >>> >>> Write to a tempfile (File.createTempFile()) or TESTCLASSES. >>> >>> -phil. >>> >>> On 3/15/16, 10:50 PM, Jayathirth D V wrote: >>> >>> Hi Phil,All >>> >>> _Please review the following fix in >>> JDK9:_ >>> >>> __ >>> >>> Bug >>> :https://bugs.openjdk.java.net/browse/JDK-8044289 >>> >>> Webrev :http://cr.openjdk.java.net/~jdv/8044289/webrev.00/ >>> >>> >>> >>> >>> >>> >>> >>> Issue : When createImageInputStream() >>> or createImageOutputStream >>> >>> returns null in ImageIO.read() or >>> ImageIO.write() we are seeing >>> >>> NPE as it stream is used further without null check. >>> >>> Root cause : "stream" is used without >>> checking whether it is >>> >>> null or not. >>> >>> Solution : Handle null pointer of stream and throw IIOException. >>> >>> Test case contains all possible >>> scenarios where >>> >>> createImageInputStream() or createImageOutputStream can return null. >>> >>> Thanks, >>> >>> Jay >>> >>> -- >>> >>> Best regards, Sergey. >>> >>> -- >>> >>> Best regards, Sergey. >>> >>> -- >>> >>> Best regards, Sergey. >>> >>> -- >>> >>> Best regards, Sergey. >>> > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From jayathirth.d.v at oracle.com Tue Apr 5 15:02:05 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 5 Apr 2016 08:02:05 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream In-Reply-To: <5703CD02.6010204@oracle.com> References: <99cb1549-30b5-44af-b399-ebed22255cf8@default> <56E997F1.2070605@oracle.com> <56E9C39D.6090701@oracle.com> <56E9D1D5.8090500@oracle.com> <56EAB79C.1080503@oracle.com> <88e50a67-fdd2-4b97-aa19-3ac5d419e2cf@default> <56EAFD38.80604@oracle.com> <56F0A94C.8080703@oracle.com> <56F17140.2070208@oracle.com> <481ff313-103f-4a71-bec9-44a3fa0a70ef@default> <56F3294E.1040306@oracle.com> <387cc752-40cd-4d3a-9350-e53193d80dfd@default> <56F9AC5E.8010107@oracle.com> <56FA77D8.3030108@oracle.com> <111c7914-e6c1-4805-9c3c-d8f092f3faa3@default> <5703CD02.6010204@oracle.com> Message-ID: Hi Sergey, It will be pushed after removing the redundant code. Please find the webrev: http://cr.openjdk.java.net/~jdv/8044289/webrev.07/ Thanks, Jay -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, April 05, 2016 8:05 PM To: Jayathirth D V Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream On 30.03.16 9:48, Jayathirth D V wrote: > Thanks for pointing it out. It looks like redundant try-catch block. There is small code clean up is possible after your latest change: 1587 ImageOutputStream stream = null; 1588 stream = createImageOutputStream(output); I guess such code is redundant too. > I have removed these blocks in write() methods so that we are handling "cant create cache file" exception in common way in all read() and write() methods. > Also I have updated test case description to hold true for only those read() and write() methods where we are using createImageXXXStream() for readability. > > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/8044289/webrev.06/ > > After CCC is done we will push above change to repo. > > Thanks, > Jay > > -----Original Message----- > From: Sergey Bylokhov > Sent: Tuesday, March 29, 2016 6:11 PM > To: Philip Race; Jayathirth D V > Cc: 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In > ImageIO.read() and write() NPE is not handled properly for stream > > I am not sure what is the reason of this code? > 1546 try { > 1547 output.delete(); > 1548 stream = createImageOutputStream(output); > 1549 } catch (IOException e) { > 1550 throw e; > 1551 } > > On 29.03.16 1:12, Philip Race wrote: >> This all looks fine to me. Although no new Exception types are thrown >> I think we need a CCC anyway, so please prepare and get that approved >> before pushing. >> >> -phil. >> >> On 3/28/16, 3:30 AM, Jayathirth D V wrote: >>> >>> Hi Phil, >>> >>> After discussion with Sergey we have come to conclusion that Sergey >>> is okay with throwing exception or returning null/false. >>> >>> So I have modified the webrev to throw exception. >>> >>> Also in write() I have modified the catch block to just throw the >>> caught exception without adding message since it will create >>> confusion between the case where we are not able to create cache and >>> when >>> createImageOutputStream() returns null. >>> >>> Regarding catch block of createImageOutputStream() only when we >>> usecache is true we use FileCacheImageOutputStream() and it throws >>> IOException so I think there is no need to add extra check before >>> throwing IOException. >>> >>> Please find updated webrev for review : >>> >>> http://cr.openjdk.java.net/~jdv/8044289/webrev.04/ >>> >>> >>> Thanks, >>> >>> Jay >>> >>> *From:*Jayathirth D V >>> *Sent:* Thursday, March 24, 2016 3:52 PM >>> *To:* Philip Race >>> *Cc:* Sergey Bylokhov; 2d-dev at openjdk.java.net >>> *Subject:* RE: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >>> ImageIO.read() and write() NPE is not handled properly for stream >>> >>> Hi Phil, >>> >>> We can change the code to something like : >>> >>> 1522 * @return false if no appropriate writer is >>> found or >>> 1523 * when needed stream is null. >>> >>> 1545 try { >>> 1546 output.delete(); >>> 1547 stream = createImageOutputStream(output); >>> 1548 } catch (IOException e) { >>> 1549 *throw e;* >>> 1550 } >>> >>> In this case we will be throwing IOException when we are not able to >>> create cache file and stream is null. >>> >>> And return null/false when createImageXXXStream returns null. Also >>> we can add check before throwing IIOException from >>> createImageXXXStream for usecache. >>> >>> 350 >>> 351 boolean usecache = getUseCache() && hasCachePermission(); >>> 352 >>> 353 while (iter.hasNext()) { >>> 354 ImageInputStreamSpi spi = iter.next(); >>> 355 if (spi.getInputClass().isInstance(input)) { >>> 356 try { >>> 357 return spi.createInputStreamInstance(input, >>> 358 usecache, >>> 359 >>> getCacheDirectory()); >>> 360 } catch (IOException e) { >>> 361 *if (usecache)* >>> 362 throw new IIOException("Can't create cache >>> file!", e); >>> 363 } >>> 364 } >>> 365 } >>> >>> This will be one of the approach. >>> >>> Or we can throw IOException in all the cases with additional check >>> in createImageXXXStream for usecache. This will be like throwing >>> IOException when createImageXXXStream returns null/false or it >>> throws IIOException when it cant create cache file. This will be >>> another approach. Please let us know your inputs. >>> >>> Thanks, >>> >>> Jay >>> >>> *From:*Philip Race >>> *Sent:* Thursday, March 24, 2016 5:10 AM >>> *To:* Jayathirth D V >>> *Cc:* Sergey Bylokhov; 2d-dev at openjdk.java.net >>> >>> *Subject:* Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >>> ImageIO.read() and write() NPE is not handled properly for stream >>> >>> I don't think this is ready and we need to discuss whether to rework it. >>> >>> In general I think I prefer IIO rather than null when we have a stream problem. >>> >>> >>> For one thing you have this change :- >>> >>> 1522 * @return false if no appropriate writer is >>> found or >>> 1523 * not able to create required ImageOutputStream. >>> yet the implementation says :- >>> 1545 try { >>> 1546 output.delete(); >>> 1547 stream = createImageOutputStream(output); >>> 1548 } catch (IOException e) { >>> 1549 throw new IIOException("Can't create output stream!", e); >>> 1550 } >>> So whilst "null" would mean we cannot find an IOS SPI it isn't the >>> only reason we fail to create the IOS A null return seems to get >>> passed through to doWrite() which probably throws IIOE And I think >>> that the implementation is actually right here where it throws an >>> exception. >>> The ability to create an image input or output stream could be >>> because of some kind of problem opening the file, or with the IIS or >>> IOS implementations - like they were de-registered. I think in many >>> if not all of these cases IOE - or IIOE is what we want. >>> Also since we call createImageInputStream() - which is public - we >>> need to look at that, and what it does, which is also something to consider. >>> If it returns null, that seems to mean that no suitable SPI is >>> registered which can only happen if they are de-registered. For the >>> methods where we use createImageInputStream() I think it is fair to >>> turn that into IIOE BTW I note that the code there says :- >>> 350 >>> 351 boolean usecache = getUseCache() && hasCachePermission(); >>> 352 >>> 353 while (iter.hasNext()) { >>> 354 ImageInputStreamSpi spi = iter.next(); >>> 355 if (spi.getInputClass().isInstance(input)) { >>> 356 try { >>> 357 return spi.createInputStreamInstance(input, >>> 358 usecache, >>> 359 getCacheDirectory()); >>> 360 } catch (IOException e) { >>> 361 throw new IIOException("Can't create cache file!", e); >>> 362 } >>> 363 } >>> 364 } >>> So far I can see that means it will claim any Exception that is >>> generated is because it could not create the cache file without any proof of that and even if "useCache" is false. >>> It seems to imply to me that the author was not considering things >>> like someone passing a closed InputStream .. probably we ought to be >>> more vague in this case or look more deeply at what we can tell from whether it is IIOE or IOE. >>> -phil. >>> >>> On 3/22/16, 10:49 AM, Jayathirth D V wrote: >>> >>> Thanks for the review Sergey. >>> >>> Can I get +1 for this please? >>> >>> -Jay >>> >>> -----Original Message----- >>> >>> From: Sergey Bylokhov >>> >>> Sent: Tuesday, March 22, 2016 9:52 PM >>> >>> To: Jayathirth D V; Philip Race >>> >>> Cc:2d-dev at openjdk.java.net >>> >>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : >>> In >>> ImageIO.read() and write() NPE is not handled properly for stream >>> >>> This fix looks fine to me. >>> >>> At least it made all code work in a similar way. But probably someone will have other opinion? >>> >>> On 22.03.16 12:34, Jayathirth D V wrote: >>> >>> Hi Sergey, >>> >>> I have unified changes related to ImageIO.read() and ImageIO.write(). >>> >>> In case of read() we will be returning null when createImageInputStream() returns null. >>> >>> In case of write() we will be returning false when createImageOutputStream() returns null. >>> >>> Please find updated webrev for review: >>> >>> http://cr.openjdk.java.net/~jdv/8044289/webrev.03/ >>> >>> >>> Thanks, >>> >>> Jay >>> >>> -----Original Message----- >>> >>> From: Sergey Bylokhov >>> >>> Sent: Tuesday, March 22, 2016 7:39 AM >>> >>> To: Jayathirth D V; Philip Race >>> >>> Cc:2d-dev at openjdk.java.net >>> >>> Subject: Re: [OpenJDK 2D-Dev] Review Request for >>> JDK-8044289 >>> : In >>> >>> ImageIO.read() and write() NPE is not handled properly for >>> stream >>> >>> Hi, Jay. >>> >>> Since we decided to update the specification we get an additional flexibility in the fix, because we can update the "@exception IOException" part of javadoc and describe that it can be thrown if ImageXXXStream cannot be created. >>> >>> I don't see a big differences of both approaches in case of write() methods, but in case of read(which has the similar issue but was skipped in the fix) there is a difference. >>> >>> Note that the read(File) unlike other methods throws the >>> unspecified >>> >>> IIOException exception if ImageXXXStream cannot be created. >>> We can >>> >>> think about unification of read/write methods in ImageIO. >>> Hmm but even >>> >>> then >>> >>> read() in some cases will return null and in some cases throw an exception.... >>> >>> and createImageInputStream/createImageOutputStream() will look alien as they always return null not an exception. >>> >>> Another possible unification is to update javadoc for all >>> methods, >>> >>> that they will return null if related providers are not >>> found(in this >>> >>> case "throw new IIOException("Can't create an ImageInputStream!"))" >>> >>> should be removed from read(File); >>> >>> On 21.03.16 10:26, Jayathirth D V wrote: >>> >>> Hi Sergey, >>> >>> For the second approach I have created webrev for review. >>> >>> Please review updated webrev : >>> >>> http://cr.openjdk.java.net/~jdv/8044289/webrev.02/ >>> >>> >>> Thanks, >>> >>> Jay >>> >>> -----Original Message----- >>> >>> From: Jayathirth D V >>> >>> Sent: Friday, March 18, 2016 2:23 PM >>> >>> To: Sergey Bylokhov >>> >>> Cc:2d-dev at openjdk.java.net >>> ; Philip Race >>> >>> Subject: RE: [OpenJDK 2D-Dev] Review Request for >>> JDK-8044289 : In >>> >>> ImageIO.read() and write() NPE is not handled properly >>> for stream >>> >>> Hi Sergey, >>> >>> Thanks for your inputs. >>> >>> Indeed all the null values returned by createImageInputStream() and createImageInputStream() are valid only. >>> >>> I went through the code more and found that there is no need for fix in ImageIO.read() methods as null stream is handled in read(ImageInputStream stream) which is called by all the remaining read() API's through IAE. So i can remove the changes made in ImageIO.read() functions. Also istream is closed in finally block of read(url). >>> >>> For ImageIO.write(File) & ImageIO.write(OutputStream) NPE we have two approaches for fix: >>> >>> 1) Keep the present changes of throwing IOException when stream is null and change the throw clause of write() spec mentioning: >>> >>> "IOException - if an error occurs during writing or not able to create required ImageOutputStream" >>> >>> 2) Remove the present changes and handle null in doWrite() method by returning false when stream is null & add code in finally block to close the stream only when stream is not null. Along with this we can also change Returns clause of spec to mention that write() might return false when we are not able to create ImageOutputStream. >>> >>> >>> >>> private static boolean doWrite(RenderedImage >>> im, ImageWriter writer, >>> >>> >>> ImageOutputStream output) throws IOException { >>> >>> if (writer == null) { >>> >>> return false; >>> >>> } >>> >>> + if (output == null) { >>> >>> + return false; >>> >>> + } >>> >>> >>> >>> try { >>> >>> return doWrite(im, >>> writer, stream); >>> >>> } finally { >>> >>> + if (stream != null) >>> >>> stream.close(); >>> >>> } >>> >>> >>> >>> Returns : >>> >>> false if no appropriate writer is found or not able to create required ImageOutputStream. >>> >>> Please let me know your inputs. >>> >>> Thanks, >>> >>> Jay >>> >>> -----Original Message----- >>> >>> From: Sergey Bylokhov >>> >>> Sent: Friday, March 18, 2016 12:24 AM >>> >>> To: Jayathirth D V >>> >>> Cc:2d-dev at openjdk.java.net >>> ; Philip Race >>> >>> Subject: Re: [OpenJDK 2D-Dev] Review Request for >>> JDK-8044289 : In >>> >>> ImageIO.read() and write() NPE is not handled properly >>> for stream >>> >>> On 17.03.16 21:14, Jayathirth D V wrote: >>> >>> There are many places in createImageInputStream() and createImageOutputStream() where it will return null for stream. >>> >>> But when why you change the write/read methods? They should take null into account and work according to specification. If some bogus null returns from createImageInputStream/createImageOutputStream then it should be fixed in these methods. >>> >>> So for NPE described in bug to occur there can be multiple paths: >>> >>> 1) One of the path described in bug is when theRegistry.getServiceProviders() throws IAE and we return null. >>> >>> This is the case when we have no installed spi and should return null/false. >>> >>> 2) When we pass non-existent file path to ImageIO (as described inhttp://stackoverflow.com/questions/11153200/with-imageio-write-api-call-i-get-nullpointerexception ). Here we catch FileNotFoundException but still we return stream as null at the end which will cause NPE further. >>> >>> This is same thing described in the bug(about stream.close()). The write method call createImageOutputStream() and got FileNotFoundException. >>> >>> This exception should be propagated to the user, but it is replaced in the finally block, because we try to close the stream=null. So the fix for this particular case is to check the stream to null in finally, No? >>> >>> 3) When we don't support the provider and theRegistry.getServiceProviders() return iterator with size zero. >>> >>> This means that our providers do not support this case, and we should return null/false. >>> >>> For us to follow first scenario we need access to categoryMap of IIORegistry and delete the ImageInputStreamSpi/ ImageOutputStreamSpi but I was not able to find a way to tamper it from test case. If we follow second case FileNotFoundException will be thrown by default eventhough we handle NPE. >>> >>> But you change the code and we now contradicts the specification, in your case the test should expect false/null from write()/read(). >>> >>> In the test case we are trying to following third scenario to get stream as null to verify the code changes. >>> >>> To catch the bogus null we should try to use another approach, or change the spec. But it seems all null values above are correct, we should be ready for them. >>> >>> As part of collective fix we are throwing IOException which will indicate that we are not able to create required stream. >>> >>> Thanks, >>> >>> Jay >>> >>> -----Original Message----- >>> >>> From: Sergey Bylokhov >>> >>> Sent: Thursday, March 17, 2016 7:27 PM >>> >>> To: Phil Race >>> >>> Cc: Jayathirth D V;2d-dev at openjdk.java.net >>> >>> >>> Subject: Re: [OpenJDK 2D-Dev] Review Request for >>> JDK-8044289 : In >>> >>> ImageIO.read() and write() NPE is not handled >>> properly for stream >>> >>> On 17.03.16 0:36, Phil Race wrote: >>> >>> I don't think that is the actual reason here >>> >>> But the test doing exactly this thing -> deregister >>> all spi => in >>> >>> this case according to specification all related >>> >>> methods(read/write/creatImageInputStream/creatImageOutputStream) should return null or false. >>> >>> - it seems likely that there >>> >>> was some kind of internal error or bad SPI causing this. >>> >>> So throwing an exception seems more appropriate. >>> >>> the problem was in some of our methods which do not expect null in some places(like stream.close() from the bug description). >>> >>> And also the bug was originally solely about write(..). >>> >>> -phil. >>> >>> On 03/16/2016 01:35 PM, Sergey Bylokhov wrote: >>> >>> As far as I understand the >>> createImageInputStream() returns null >>> >>> is this stream is unsupported by current >>> plugins via spi. Probably >>> >>> the >>> >>> read() method should return null too? >>> >>> /** >>> >>> * Returns a {@code BufferedImage} >>> as the result of decoding >>> >>> * a supplied {@code InputStream} >>> with an {@code ImageReader} >>> >>> * chosen automatically from among those currently registered. >>> >>> * The {@code InputStream} is >>> wrapped in an >>> >>> * {@code ImageInputStream}. If no >>> registered >>> >>> * {@code ImageReader} claims to be >>> able to read the >>> >>> * resulting stream, {@code null} is returned. >>> >>> * >>> >>> ....... >>> >>> * @return a {@code BufferedImage} >>> containing the decoded >>> >>> * contents of the input, or {@code null}. >>> >>> */ >>> >>> public static BufferedImage >>> read(InputStream input) throws >>> >>> IOException >>> >>> On 16.03.16 20:29, Philip Race wrote: >>> >>> The test writes out into "test.src". >>> >>> I believe that you should treat that as a "read-only" location. >>> >>> Write to a tempfile (File.createTempFile()) or TESTCLASSES. >>> >>> -phil. >>> >>> On 3/15/16, 10:50 PM, Jayathirth D V wrote: >>> >>> Hi Phil,All >>> >>> _Please review the following fix in >>> JDK9:_ >>> >>> __ >>> >>> Bug >>> :https://bugs.openjdk.java.net/browse/JDK-8044289 >>> >>> Webrev >>> :http://cr.openjdk.java.net/~jdv/8044289/webrev.00/ >>> >>> >>> >>> >>> >>> >>> >>> >>> Issue : When >>> createImageInputStream() or createImageOutputStream >>> >>> returns null in ImageIO.read() or >>> ImageIO.write() we are seeing >>> >>> NPE as it stream is used further without null check. >>> >>> Root cause : "stream" is used >>> without checking whether it is >>> >>> null or not. >>> >>> Solution : Handle null pointer of stream and throw IIOException. >>> >>> Test case contains all possible >>> scenarios where >>> >>> createImageInputStream() or createImageOutputStream can return null. >>> >>> Thanks, >>> >>> Jay >>> >>> -- >>> >>> Best regards, Sergey. >>> >>> -- >>> >>> Best regards, Sergey. >>> >>> -- >>> >>> Best regards, Sergey. >>> >>> -- >>> >>> Best regards, Sergey. >>> > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Tue Apr 5 15:05:04 2016 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 5 Apr 2016 19:05:04 +0400 Subject: [OpenJDK 2D-Dev] [9] Review request for 8073320 Windows HiDPI Graphics support In-Reply-To: <56FDDBDA.5070907@oracle.com> References: <56012064.2020800@oracle.com> <56FDDBDA.5070907@oracle.com> Message-ID: <5703D420.3090700@oracle.com> On 01/04/16 06:24, Jim Graham wrote: > Hi Alexandr, > > Is there a bug filed to upgrade JLightweightFrame to allow non-integer > (and X/Y) scales? We'd need this capability to implement "Swing > embedded in FX" correctly on Win8.1+... I have created JDK-8153522 Update JLightweightFrame to allow non-integer (and X/Y) scales https://bugs.openjdk.java.net/browse/JDK-8153522 Thanks, Alexandr. > > ...jim > > On 9/22/2015 2:33 AM, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8073320 >> webrev: http://cr.openjdk.java.net/~alexsch/8073320/webrev.00 >> >> This is an initial part of the HiDPI Graphics support on Windows for >> the JEP 263: HiDPI Graphics on Windows and Linux >> http://openjdk.java.net/jeps/263 >> >> - scale factors are added to surface dates >> - window size, events coordinates and font are scaled on native side >> - backup buffered image is scaled in SunVolatileImage >> - AwtRobot MouseMove() and GetRGBPixels() methods are updated >> - GetDpiForMonitor function is used to query the specified monitor >> for the horizontal and vertical DPI values. >> If it is not available ID2D1Factory::GetDesktopDpi method is used >> instead. >> - "sun.java2d.uiScale.enabled", "sun.java2d.win.uiScale", >> "sun.java2d.win.uiScaleX", and "sun.java2d.win.uiScaleY" options are >> added for the testing purposes. >> >> Thanks, >> Alexandr. >> From Sergey.Bylokhov at oracle.com Tue Apr 5 15:16:34 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 5 Apr 2016 18:16:34 +0300 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream In-Reply-To: References: <99cb1549-30b5-44af-b399-ebed22255cf8@default> <56E997F1.2070605@oracle.com> <56E9C39D.6090701@oracle.com> <56E9D1D5.8090500@oracle.com> <56EAB79C.1080503@oracle.com> <88e50a67-fdd2-4b97-aa19-3ac5d419e2cf@default> <56EAFD38.80604@oracle.com> <56F0A94C.8080703@oracle.com> <56F17140.2070208@oracle.com> <481ff313-103f-4a71-bec9-44a3fa0a70ef@default> <56F3294E.1040306@oracle.com> <387cc752-40cd-4d3a-9350-e53193d80dfd@default> <56F9AC5E.8010107@oracle.com> <56FA77D8.3030108@oracle.com> <111c7914-e6c1-4805-9c3c-d8f092f3faa3@default> <5703CD02.6010204@oracle.com> Message-ID: <5703D6D2.6@oracle.com> Looks fine, thanks. On 05.04.16 18:02, Jayathirth D V wrote: > Hi Sergey, > > It will be pushed after removing the redundant code. > Please find the webrev: > http://cr.openjdk.java.net/~jdv/8044289/webrev.07/ > > Thanks, > Jay > > -----Original Message----- > From: Sergey Bylokhov > Sent: Tuesday, April 05, 2016 8:05 PM > To: Jayathirth D V > Cc: 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream > > On 30.03.16 9:48, Jayathirth D V wrote: >> Thanks for pointing it out. It looks like redundant try-catch block. > > There is small code clean up is possible after your latest change: > 1587 ImageOutputStream stream = null; > 1588 stream = createImageOutputStream(output); > > I guess such code is redundant too. > >> I have removed these blocks in write() methods so that we are handling "cant create cache file" exception in common way in all read() and write() methods. >> Also I have updated test case description to hold true for only those read() and write() methods where we are using createImageXXXStream() for readability. >> >> Please find updated webrev for review: >> http://cr.openjdk.java.net/~jdv/8044289/webrev.06/ >> >> After CCC is done we will push above change to repo. >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Tuesday, March 29, 2016 6:11 PM >> To: Philip Race; Jayathirth D V >> Cc: 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >> ImageIO.read() and write() NPE is not handled properly for stream >> >> I am not sure what is the reason of this code? >> 1546 try { >> 1547 output.delete(); >> 1548 stream = createImageOutputStream(output); >> 1549 } catch (IOException e) { >> 1550 throw e; >> 1551 } >> >> On 29.03.16 1:12, Philip Race wrote: >>> This all looks fine to me. Although no new Exception types are thrown >>> I think we need a CCC anyway, so please prepare and get that approved >>> before pushing. >>> >>> -phil. >>> >>> On 3/28/16, 3:30 AM, Jayathirth D V wrote: >>>> >>>> Hi Phil, >>>> >>>> After discussion with Sergey we have come to conclusion that Sergey >>>> is okay with throwing exception or returning null/false. >>>> >>>> So I have modified the webrev to throw exception. >>>> >>>> Also in write() I have modified the catch block to just throw the >>>> caught exception without adding message since it will create >>>> confusion between the case where we are not able to create cache and >>>> when >>>> createImageOutputStream() returns null. >>>> >>>> Regarding catch block of createImageOutputStream() only when we >>>> usecache is true we use FileCacheImageOutputStream() and it throws >>>> IOException so I think there is no need to add extra check before >>>> throwing IOException. >>>> >>>> Please find updated webrev for review : >>>> >>>> http://cr.openjdk.java.net/~jdv/8044289/webrev.04/ >>>> >>>> >>>> Thanks, >>>> >>>> Jay >>>> >>>> *From:*Jayathirth D V >>>> *Sent:* Thursday, March 24, 2016 3:52 PM >>>> *To:* Philip Race >>>> *Cc:* Sergey Bylokhov; 2d-dev at openjdk.java.net >>>> *Subject:* RE: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >>>> ImageIO.read() and write() NPE is not handled properly for stream >>>> >>>> Hi Phil, >>>> >>>> We can change the code to something like : >>>> >>>> 1522 * @return false if no appropriate writer is >>>> found or >>>> 1523 * when needed stream is null. >>>> >>>> 1545 try { >>>> 1546 output.delete(); >>>> 1547 stream = createImageOutputStream(output); >>>> 1548 } catch (IOException e) { >>>> 1549 *throw e;* >>>> 1550 } >>>> >>>> In this case we will be throwing IOException when we are not able to >>>> create cache file and stream is null. >>>> >>>> And return null/false when createImageXXXStream returns null. Also >>>> we can add check before throwing IIOException from >>>> createImageXXXStream for usecache. >>>> >>>> 350 >>>> 351 boolean usecache = getUseCache() && hasCachePermission(); >>>> 352 >>>> 353 while (iter.hasNext()) { >>>> 354 ImageInputStreamSpi spi = iter.next(); >>>> 355 if (spi.getInputClass().isInstance(input)) { >>>> 356 try { >>>> 357 return spi.createInputStreamInstance(input, >>>> 358 usecache, >>>> 359 >>>> getCacheDirectory()); >>>> 360 } catch (IOException e) { >>>> 361 *if (usecache)* >>>> 362 throw new IIOException("Can't create cache >>>> file!", e); >>>> 363 } >>>> 364 } >>>> 365 } >>>> >>>> This will be one of the approach. >>>> >>>> Or we can throw IOException in all the cases with additional check >>>> in createImageXXXStream for usecache. This will be like throwing >>>> IOException when createImageXXXStream returns null/false or it >>>> throws IIOException when it cant create cache file. This will be >>>> another approach. Please let us know your inputs. >>>> >>>> Thanks, >>>> >>>> Jay >>>> >>>> *From:*Philip Race >>>> *Sent:* Thursday, March 24, 2016 5:10 AM >>>> *To:* Jayathirth D V >>>> *Cc:* Sergey Bylokhov; 2d-dev at openjdk.java.net >>>> >>>> *Subject:* Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >>>> ImageIO.read() and write() NPE is not handled properly for stream >>>> >>>> I don't think this is ready and we need to discuss whether to rework it. >>>> >>>> In general I think I prefer IIO rather than null when we have a stream problem. >>>> >>>> >>>> For one thing you have this change :- >>>> >>>> 1522 * @return false if no appropriate writer is >>>> found or >>>> 1523 * not able to create required ImageOutputStream. >>>> yet the implementation says :- >>>> 1545 try { >>>> 1546 output.delete(); >>>> 1547 stream = createImageOutputStream(output); >>>> 1548 } catch (IOException e) { >>>> 1549 throw new IIOException("Can't create output stream!", e); >>>> 1550 } >>>> So whilst "null" would mean we cannot find an IOS SPI it isn't the >>>> only reason we fail to create the IOS A null return seems to get >>>> passed through to doWrite() which probably throws IIOE And I think >>>> that the implementation is actually right here where it throws an >>>> exception. >>>> The ability to create an image input or output stream could be >>>> because of some kind of problem opening the file, or with the IIS or >>>> IOS implementations - like they were de-registered. I think in many >>>> if not all of these cases IOE - or IIOE is what we want. >>>> Also since we call createImageInputStream() - which is public - we >>>> need to look at that, and what it does, which is also something to consider. >>>> If it returns null, that seems to mean that no suitable SPI is >>>> registered which can only happen if they are de-registered. For the >>>> methods where we use createImageInputStream() I think it is fair to >>>> turn that into IIOE BTW I note that the code there says :- >>>> 350 >>>> 351 boolean usecache = getUseCache() && hasCachePermission(); >>>> 352 >>>> 353 while (iter.hasNext()) { >>>> 354 ImageInputStreamSpi spi = iter.next(); >>>> 355 if (spi.getInputClass().isInstance(input)) { >>>> 356 try { >>>> 357 return spi.createInputStreamInstance(input, >>>> 358 usecache, >>>> 359 getCacheDirectory()); >>>> 360 } catch (IOException e) { >>>> 361 throw new IIOException("Can't create cache file!", e); >>>> 362 } >>>> 363 } >>>> 364 } >>>> So far I can see that means it will claim any Exception that is >>>> generated is because it could not create the cache file without any proof of that and even if "useCache" is false. >>>> It seems to imply to me that the author was not considering things >>>> like someone passing a closed InputStream .. probably we ought to be >>>> more vague in this case or look more deeply at what we can tell from whether it is IIOE or IOE. >>>> -phil. >>>> >>>> On 3/22/16, 10:49 AM, Jayathirth D V wrote: >>>> >>>> Thanks for the review Sergey. >>>> >>>> Can I get +1 for this please? >>>> >>>> -Jay >>>> >>>> -----Original Message----- >>>> >>>> From: Sergey Bylokhov >>>> >>>> Sent: Tuesday, March 22, 2016 9:52 PM >>>> >>>> To: Jayathirth D V; Philip Race >>>> >>>> Cc:2d-dev at openjdk.java.net >>>> >>>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : >>>> In >>>> ImageIO.read() and write() NPE is not handled properly for stream >>>> >>>> This fix looks fine to me. >>>> >>>> At least it made all code work in a similar way. But probably someone will have other opinion? >>>> >>>> On 22.03.16 12:34, Jayathirth D V wrote: >>>> >>>> Hi Sergey, >>>> >>>> I have unified changes related to ImageIO.read() and ImageIO.write(). >>>> >>>> In case of read() we will be returning null when createImageInputStream() returns null. >>>> >>>> In case of write() we will be returning false when createImageOutputStream() returns null. >>>> >>>> Please find updated webrev for review: >>>> >>>> http://cr.openjdk.java.net/~jdv/8044289/webrev.03/ >>>> >>>> >>>> Thanks, >>>> >>>> Jay >>>> >>>> -----Original Message----- >>>> >>>> From: Sergey Bylokhov >>>> >>>> Sent: Tuesday, March 22, 2016 7:39 AM >>>> >>>> To: Jayathirth D V; Philip Race >>>> >>>> Cc:2d-dev at openjdk.java.net >>>> >>>> Subject: Re: [OpenJDK 2D-Dev] Review Request for >>>> JDK-8044289 >>>> : In >>>> >>>> ImageIO.read() and write() NPE is not handled properly for >>>> stream >>>> >>>> Hi, Jay. >>>> >>>> Since we decided to update the specification we get an additional flexibility in the fix, because we can update the "@exception IOException" part of javadoc and describe that it can be thrown if ImageXXXStream cannot be created. >>>> >>>> I don't see a big differences of both approaches in case of write() methods, but in case of read(which has the similar issue but was skipped in the fix) there is a difference. >>>> >>>> Note that the read(File) unlike other methods throws the >>>> unspecified >>>> >>>> IIOException exception if ImageXXXStream cannot be created. >>>> We can >>>> >>>> think about unification of read/write methods in ImageIO. >>>> Hmm but even >>>> >>>> then >>>> >>>> read() in some cases will return null and in some cases throw an exception.... >>>> >>>> and createImageInputStream/createImageOutputStream() will look alien as they always return null not an exception. >>>> >>>> Another possible unification is to update javadoc for all >>>> methods, >>>> >>>> that they will return null if related providers are not >>>> found(in this >>>> >>>> case "throw new IIOException("Can't create an ImageInputStream!"))" >>>> >>>> should be removed from read(File); >>>> >>>> On 21.03.16 10:26, Jayathirth D V wrote: >>>> >>>> Hi Sergey, >>>> >>>> For the second approach I have created webrev for review. >>>> >>>> Please review updated webrev : >>>> >>>> http://cr.openjdk.java.net/~jdv/8044289/webrev.02/ >>>> >>>> >>>> Thanks, >>>> >>>> Jay >>>> >>>> -----Original Message----- >>>> >>>> From: Jayathirth D V >>>> >>>> Sent: Friday, March 18, 2016 2:23 PM >>>> >>>> To: Sergey Bylokhov >>>> >>>> Cc:2d-dev at openjdk.java.net >>>> ; Philip Race >>>> >>>> Subject: RE: [OpenJDK 2D-Dev] Review Request for >>>> JDK-8044289 : In >>>> >>>> ImageIO.read() and write() NPE is not handled properly >>>> for stream >>>> >>>> Hi Sergey, >>>> >>>> Thanks for your inputs. >>>> >>>> Indeed all the null values returned by createImageInputStream() and createImageInputStream() are valid only. >>>> >>>> I went through the code more and found that there is no need for fix in ImageIO.read() methods as null stream is handled in read(ImageInputStream stream) which is called by all the remaining read() API's through IAE. So i can remove the changes made in ImageIO.read() functions. Also istream is closed in finally block of read(url). >>>> >>>> For ImageIO.write(File) & ImageIO.write(OutputStream) NPE we have two approaches for fix: >>>> >>>> 1) Keep the present changes of throwing IOException when stream is null and change the throw clause of write() spec mentioning: >>>> >>>> "IOException - if an error occurs during writing or not able to create required ImageOutputStream" >>>> >>>> 2) Remove the present changes and handle null in doWrite() method by returning false when stream is null & add code in finally block to close the stream only when stream is not null. Along with this we can also change Returns clause of spec to mention that write() might return false when we are not able to create ImageOutputStream. >>>> >>>> >>>> >>>> private static boolean doWrite(RenderedImage >>>> im, ImageWriter writer, >>>> >>>> >>>> ImageOutputStream output) throws IOException { >>>> >>>> if (writer == null) { >>>> >>>> return false; >>>> >>>> } >>>> >>>> + if (output == null) { >>>> >>>> + return false; >>>> >>>> + } >>>> >>>> >>>> >>>> try { >>>> >>>> return doWrite(im, >>>> writer, stream); >>>> >>>> } finally { >>>> >>>> + if (stream != null) >>>> >>>> stream.close(); >>>> >>>> } >>>> >>>> >>>> >>>> Returns : >>>> >>>> false if no appropriate writer is found or not able to create required ImageOutputStream. >>>> >>>> Please let me know your inputs. >>>> >>>> Thanks, >>>> >>>> Jay >>>> >>>> -----Original Message----- >>>> >>>> From: Sergey Bylokhov >>>> >>>> Sent: Friday, March 18, 2016 12:24 AM >>>> >>>> To: Jayathirth D V >>>> >>>> Cc:2d-dev at openjdk.java.net >>>> ; Philip Race >>>> >>>> Subject: Re: [OpenJDK 2D-Dev] Review Request for >>>> JDK-8044289 : In >>>> >>>> ImageIO.read() and write() NPE is not handled properly >>>> for stream >>>> >>>> On 17.03.16 21:14, Jayathirth D V wrote: >>>> >>>> There are many places in createImageInputStream() and createImageOutputStream() where it will return null for stream. >>>> >>>> But when why you change the write/read methods? They should take null into account and work according to specification. If some bogus null returns from createImageInputStream/createImageOutputStream then it should be fixed in these methods. >>>> >>>> So for NPE described in bug to occur there can be multiple paths: >>>> >>>> 1) One of the path described in bug is when theRegistry.getServiceProviders() throws IAE and we return null. >>>> >>>> This is the case when we have no installed spi and should return null/false. >>>> >>>> 2) When we pass non-existent file path to ImageIO (as described inhttp://stackoverflow.com/questions/11153200/with-imageio-write-api-call-i-get-nullpointerexception ). Here we catch FileNotFoundException but still we return stream as null at the end which will cause NPE further. >>>> >>>> This is same thing described in the bug(about stream.close()). The write method call createImageOutputStream() and got FileNotFoundException. >>>> >>>> This exception should be propagated to the user, but it is replaced in the finally block, because we try to close the stream=null. So the fix for this particular case is to check the stream to null in finally, No? >>>> >>>> 3) When we don't support the provider and theRegistry.getServiceProviders() return iterator with size zero. >>>> >>>> This means that our providers do not support this case, and we should return null/false. >>>> >>>> For us to follow first scenario we need access to categoryMap of IIORegistry and delete the ImageInputStreamSpi/ ImageOutputStreamSpi but I was not able to find a way to tamper it from test case. If we follow second case FileNotFoundException will be thrown by default eventhough we handle NPE. >>>> >>>> But you change the code and we now contradicts the specification, in your case the test should expect false/null from write()/read(). >>>> >>>> In the test case we are trying to following third scenario to get stream as null to verify the code changes. >>>> >>>> To catch the bogus null we should try to use another approach, or change the spec. But it seems all null values above are correct, we should be ready for them. >>>> >>>> As part of collective fix we are throwing IOException which will indicate that we are not able to create required stream. >>>> >>>> Thanks, >>>> >>>> Jay >>>> >>>> -----Original Message----- >>>> >>>> From: Sergey Bylokhov >>>> >>>> Sent: Thursday, March 17, 2016 7:27 PM >>>> >>>> To: Phil Race >>>> >>>> Cc: Jayathirth D V;2d-dev at openjdk.java.net >>>> >>>> >>>> Subject: Re: [OpenJDK 2D-Dev] Review Request for >>>> JDK-8044289 : In >>>> >>>> ImageIO.read() and write() NPE is not handled >>>> properly for stream >>>> >>>> On 17.03.16 0:36, Phil Race wrote: >>>> >>>> I don't think that is the actual reason here >>>> >>>> But the test doing exactly this thing -> deregister >>>> all spi => in >>>> >>>> this case according to specification all related >>>> >>>> methods(read/write/creatImageInputStream/creatImageOutputStream) should return null or false. >>>> >>>> - it seems likely that there >>>> >>>> was some kind of internal error or bad SPI causing this. >>>> >>>> So throwing an exception seems more appropriate. >>>> >>>> the problem was in some of our methods which do not expect null in some places(like stream.close() from the bug description). >>>> >>>> And also the bug was originally solely about write(..). >>>> >>>> -phil. >>>> >>>> On 03/16/2016 01:35 PM, Sergey Bylokhov wrote: >>>> >>>> As far as I understand the >>>> createImageInputStream() returns null >>>> >>>> is this stream is unsupported by current >>>> plugins via spi. Probably >>>> >>>> the >>>> >>>> read() method should return null too? >>>> >>>> /** >>>> >>>> * Returns a {@code BufferedImage} >>>> as the result of decoding >>>> >>>> * a supplied {@code InputStream} >>>> with an {@code ImageReader} >>>> >>>> * chosen automatically from among those currently registered. >>>> >>>> * The {@code InputStream} is >>>> wrapped in an >>>> >>>> * {@code ImageInputStream}. If no >>>> registered >>>> >>>> * {@code ImageReader} claims to be >>>> able to read the >>>> >>>> * resulting stream, {@code null} is returned. >>>> >>>> * >>>> >>>> ....... >>>> >>>> * @return a {@code BufferedImage} >>>> containing the decoded >>>> >>>> * contents of the input, or {@code null}. >>>> >>>> */ >>>> >>>> public static BufferedImage >>>> read(InputStream input) throws >>>> >>>> IOException >>>> >>>> On 16.03.16 20:29, Philip Race wrote: >>>> >>>> The test writes out into "test.src". >>>> >>>> I believe that you should treat that as a "read-only" location. >>>> >>>> Write to a tempfile (File.createTempFile()) or TESTCLASSES. >>>> >>>> -phil. >>>> >>>> On 3/15/16, 10:50 PM, Jayathirth D V wrote: >>>> >>>> Hi Phil,All >>>> >>>> _Please review the following fix in >>>> JDK9:_ >>>> >>>> __ >>>> >>>> Bug >>>> :https://bugs.openjdk.java.net/browse/JDK-8044289 >>>> >>>> Webrev >>>> :http://cr.openjdk.java.net/~jdv/8044289/webrev.00/ >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Issue : When >>>> createImageInputStream() or createImageOutputStream >>>> >>>> returns null in ImageIO.read() or >>>> ImageIO.write() we are seeing >>>> >>>> NPE as it stream is used further without null check. >>>> >>>> Root cause : "stream" is used >>>> without checking whether it is >>>> >>>> null or not. >>>> >>>> Solution : Handle null pointer of stream and throw IIOException. >>>> >>>> Test case contains all possible >>>> scenarios where >>>> >>>> createImageInputStream() or createImageOutputStream can return null. >>>> >>>> Thanks, >>>> >>>> Jay >>>> >>>> -- >>>> >>>> Best regards, Sergey. >>>> >>>> -- >>>> >>>> Best regards, Sergey. >>>> >>>> -- >>>> >>>> Best regards, Sergey. >>>> >>>> -- >>>> >>>> Best regards, Sergey. >>>> >> >> >> -- >> Best regards, Sergey. >> > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From philip.race at oracle.com Tue Apr 5 18:45:19 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 05 Apr 2016 11:45:19 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8146324: Add sun.font.FontUtilities.isComplexCharCode or related method to public API In-Reply-To: <56F583EA.8080402@oracle.com> References: <56F45933.2030705@oracle.com> <56F45E34.4030806@oracle.com> <56F4689E.5090802@oracle.com> <56F47166.3000303@oracle.com> <56F57BDB.1020905@oracle.com> <56F583EA.8080402@oracle.com> Message-ID: <570407BF.9090102@oracle.com> I have an approved CCC sitting waiting for a 2nd reviewer on the code change -phil. On 03/25/2016 11:31 AM, Sergey Bylokhov wrote: > Looks fine. > > On 25.03.16 20:56, Phil Race wrote: >> After a hallway conversation I have decided to change it to NPE. >> Not that I think it matters greatly either way since I don't think >> developers will be passing null to this method anyway :-) >> >> The test is changed to match .. >> >> http://cr.openjdk.java.net/~prr/8146324.1 >> >> -phil. >> >> On 03/24/2016 03:59 PM, Sergey Bylokhov wrote: >>> On 25.03.16 1:22, Phil Race wrote: >>>> That is true .. although I think I have previously been convinced >>>> that IAE >>>> is generally the better choice for such a case, I found only >>>> deriveFont >>>> that throws IAE for null in this file. >>> >>> deriveFont were changed(NPE to IAE) in 2001, but other methods and the >>> new code still use NPE. I think that in the most cases the null is not >>> taken into account and the specification is updated later(like the new >>> createFonts()). >>> >>>> So the question is whether to be consistent or to start picking the >>>> better option. >>>> So if there were no existing IAEs or NPEs in this file, which would >>>> you >>>> choose now ? >>> >>> Personally I always use NPE for null(via Objects.requireNonNull(...)). >>> and IAE for other incorrect arguments/types. or if the file(or the >>> same method) uses IAE already for null. As an example I use >>> System.getProperty(String). >>> >>> But in Font.java we specify NPE for a few methods already, some other >>> methods throw NPE but w/o specification(except deriveFont...) >>> >>>> >>>> -phil. >>>> >>>> On 03/24/2016 02:37 PM, Sergey Bylokhov wrote: >>>>> Hi, Phil. >>>>> Should this new method throw IAE? It seems that NPE can be thrown >>>>> instead, At least other methods in Font.java including the newly >>>>> added >>>>> createFonts() throw NPE. >>>>> >>>>> On 25.03.16 0:16, Phil Race wrote: >>>>>> bug : https://bugs.openjdk.java.net/browse/JDK-8146324 >>>>>> fix : http://cr.openjdk.java.net/~prr/8146324/ >>>>>> >>>>>> Developers have used an internal API to detect when TextLayout or >>>>>> GlyphVector.layoutGlyphVectorwill be needed since that is a slower >>>>>> path. >>>>>> >>>>>> This provides a public equivalent capability. >>>>>> >>>>>> I have included a test which checks the assertions of the API. >>>>>> >>>>>> A CCC will be filed. >>>>>> >>>>>> -phil. >>>>> >>>>> >>>> >>> >>> >> > > From semyon.sadetsky at oracle.com Tue Apr 5 18:52:20 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 5 Apr 2016 21:52:20 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8146324: Add sun.font.FontUtilities.isComplexCharCode or related method to public API In-Reply-To: <570407BF.9090102@oracle.com> References: <56F45933.2030705@oracle.com> <56F45E34.4030806@oracle.com> <56F4689E.5090802@oracle.com> <56F47166.3000303@oracle.com> <56F57BDB.1020905@oracle.com> <56F583EA.8080402@oracle.com> <570407BF.9090102@oracle.com> Message-ID: <57040964.1010204@oracle.com> approved. --Semyon On 4/5/2016 9:45 PM, Phil Race wrote: > I have an approved CCC sitting waiting for a 2nd reviewer on the code > change > > -phil. > > On 03/25/2016 11:31 AM, Sergey Bylokhov wrote: >> Looks fine. >> >> On 25.03.16 20:56, Phil Race wrote: >>> After a hallway conversation I have decided to change it to NPE. >>> Not that I think it matters greatly either way since I don't think >>> developers will be passing null to this method anyway :-) >>> >>> The test is changed to match .. >>> >>> http://cr.openjdk.java.net/~prr/8146324.1 >>> >>> -phil. >>> >>> On 03/24/2016 03:59 PM, Sergey Bylokhov wrote: >>>> On 25.03.16 1:22, Phil Race wrote: >>>>> That is true .. although I think I have previously been convinced >>>>> that IAE >>>>> is generally the better choice for such a case, I found only >>>>> deriveFont >>>>> that throws IAE for null in this file. >>>> >>>> deriveFont were changed(NPE to IAE) in 2001, but other methods and the >>>> new code still use NPE. I think that in the most cases the null is not >>>> taken into account and the specification is updated later(like the new >>>> createFonts()). >>>> >>>>> So the question is whether to be consistent or to start picking the >>>>> better option. >>>>> So if there were no existing IAEs or NPEs in this file, which >>>>> would you >>>>> choose now ? >>>> >>>> Personally I always use NPE for null(via Objects.requireNonNull(...)). >>>> and IAE for other incorrect arguments/types. or if the file(or the >>>> same method) uses IAE already for null. As an example I use >>>> System.getProperty(String). >>>> >>>> But in Font.java we specify NPE for a few methods already, some other >>>> methods throw NPE but w/o specification(except deriveFont...) >>>> >>>>> >>>>> -phil. >>>>> >>>>> On 03/24/2016 02:37 PM, Sergey Bylokhov wrote: >>>>>> Hi, Phil. >>>>>> Should this new method throw IAE? It seems that NPE can be thrown >>>>>> instead, At least other methods in Font.java including the newly >>>>>> added >>>>>> createFonts() throw NPE. >>>>>> >>>>>> On 25.03.16 0:16, Phil Race wrote: >>>>>>> bug : https://bugs.openjdk.java.net/browse/JDK-8146324 >>>>>>> fix : http://cr.openjdk.java.net/~prr/8146324/ >>>>>>> >>>>>>> Developers have used an internal API to detect when TextLayout or >>>>>>> GlyphVector.layoutGlyphVectorwill be needed since that is a slower >>>>>>> path. >>>>>>> >>>>>>> This provides a public equivalent capability. >>>>>>> >>>>>>> I have included a test which checks the assertions of the API. >>>>>>> >>>>>>> A CCC will be filed. >>>>>>> >>>>>>> -phil. >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > From jennifer.godinez at oracle.com Tue Apr 5 19:59:09 2016 From: jennifer.godinez at oracle.com (Jennifer Godinez) Date: Tue, 5 Apr 2016 12:59:09 -0700 Subject: [OpenJDK 2D-Dev] CFV: New 2D Group Member: Alexander Scherbatiy In-Reply-To: <56EB3465.7070709@oracle.com> References: <56EB3465.7070709@oracle.com> Message-ID: <5704190D.6040502@oracle.com> Vote: Yes - Jennifer On 3/17/2016 3:49 PM, Philip Race wrote: > I hereby nominate Alexander Scherbatiy to membership in the 2D group. > > Alexander Scherbatiy is a current member of the Swing group > and has contributed almost 200 changesets to OpenJDK :- > http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000&rev=author%28%22alexsch%22%29 > > Increasingly, and particularly over the last 18 months he has made many > of these significant contributions in the 2D area notably hi-dpi > graphics support and so I hereby nominate Alexander to membership of > the 2D group > > Votes are due by 1st April 2016 > > //Only current Members of the 2D Group [1] are eligible to vote on > this nomination. > For Lazy Consensus voting instructions, see [2]. > > [1] http://openjdk.java.net/census#2d > > [2] http://openjdk.java.net/groups/#member-vote > > > -phil -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Tue Apr 5 22:56:10 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 05 Apr 2016 15:56:10 -0700 Subject: [OpenJDK 2D-Dev] RFR 8152183: [TEST] add test for TIFFField In-Reply-To: <56FEB06A.7040806@oracle.com> References: <56F2A387.8070506@oracle.com> <56F90248.7000609@oracle.com> <56FEB06A.7040806@oracle.com> Message-ID: <5704428A.6090600@oracle.com> 45 private final static String FILENAME = "test.tiff"; 136 OutputStream s = new BufferedOutputStream(new FileOutputStream(FILENAME)); I did not think you could assume $CWD is writeable in jtreg tests. If I can be assured this is actually OK then I have no other issues. -phil. On 04/01/2016 10:31 AM, Alexander Stepanov wrote: > Please see the updated webrev: > http://cr.openjdk.java.net/~avstepan/8152183/webrev.01/ > > One more test (for multi-page tiffs) was added; for now to be ignored > because of JDK-8148454 > > Thanks, > Alexander > > On 3/28/2016 1:07 PM, Alexander Stepanov wrote: >> Sorry, just a reminder. >> >> Thanks, >> Alexander >> >> On 3/23/2016 5:09 PM, Alexander Stepanov wrote: >>> Hello, >>> >>> Could you please review the following fix >>> http://cr.openjdk.java.net/~avstepan/8152183/webrev.00/ >>> for >>> https://bugs.openjdk.java.net/browse/JDK-8152183 >>> >>> Just a single test added. >>> >>> Thanks, >>> Alexander >> > From alexander.v.stepanov at oracle.com Wed Apr 6 09:21:00 2016 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Wed, 6 Apr 2016 12:21:00 +0300 Subject: [OpenJDK 2D-Dev] RFR 8152183: [TEST] add test for TIFFField In-Reply-To: <5704428A.6090600@oracle.com> References: <56F2A387.8070506@oracle.com> <56F90248.7000609@oracle.com> <56FEB06A.7040806@oracle.com> <5704428A.6090600@oracle.com> Message-ID: <5704D4FC.5080202@oracle.com> Hello Phil, > I did not think you could assume $CWD is writeable in jtreg tests. according to the jtreg docs, "when jtreg is executed, it cd's into a scratch". Could the scratch dir be non-writable? At a 1st glance it seems to be unlikely, but maybe I'm wrong. Thanks, Alexander On 4/6/2016 1:56 AM, Phil Race wrote: > 45 private final static String FILENAME = "test.tiff"; > > 136 OutputStream s = new BufferedOutputStream(new > FileOutputStream(FILENAME)); > > > I did not think you could assume $CWD is writeable in jtreg tests. > If I can be assured this is actually OK then I have no other issues. > > -phil. > > On 04/01/2016 10:31 AM, Alexander Stepanov wrote: >> Please see the updated webrev: >> http://cr.openjdk.java.net/~avstepan/8152183/webrev.01/ >> >> One more test (for multi-page tiffs) was added; for now to be ignored >> because of JDK-8148454 >> >> Thanks, >> Alexander >> >> On 3/28/2016 1:07 PM, Alexander Stepanov wrote: >>> Sorry, just a reminder. >>> >>> Thanks, >>> Alexander >>> >>> On 3/23/2016 5:09 PM, Alexander Stepanov wrote: >>>> Hello, >>>> >>>> Could you please review the following fix >>>> http://cr.openjdk.java.net/~avstepan/8152183/webrev.00/ >>>> for >>>> https://bugs.openjdk.java.net/browse/JDK-8152183 >>>> >>>> Just a single test added. >>>> >>>> Thanks, >>>> Alexander >>> >> > From prasanta.sadhukhan at oracle.com Wed Apr 6 10:09:51 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Wed, 6 Apr 2016 15:39:51 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6529030, , Java Printing: Print range > Selection gets enabled Message-ID: <5704E06F.2010502@oracle.com> Hi All, Please review a fix for jdk9. Bug: https://bugs.openjdk.java.net/browse/JDK-6529030 webrev: http://cr.openjdk.java.net/~psadhukhan/6529030/webrev.00/ The issue was when using java.awt.print.PrinterJob instance more then once, Selection radio button in Print dialog gets enabled from 2nd instance even though we are printing "All" pages however Selection radio button is disabled in the first instance. This is seen in windows. This is because initially when windows initialized the print dialog, it calls InitPrintDialog() which calls getSelectAttrib() to find out which selection attribute user has selected. getSelectAttrib() returns PD_NOSELECTION as SunPageSelection.class was not added to attribute. So, in InitPrintDialog() we set PRINTDLG flags to PD_NOSELECTION. So, we see "Selection " radio button is disabled in 1st instance of print dialog. Now, when user presses "OK", windows native code calls setNativeAttributes() and adds SunPageSelection.class to the attribute with SunPageSelection.ALL or SunPageSelection.RANGE. When 2nd print dialog is shown, InitPrintDialog() will again call getSelectAttrib() which will now return SunPageSelection.ALL/SunPageSelection.RANGE which will be set to PRINTDLG flag but we are not disabling Selection radio button, so in 2nd instance, Selection radio button gets enabled. Fix was to check if PD_SELECTION attribute is selected by user, if not , sets PRINTDLG flag with PD_NOSELECTION. I have checked 8151590 and 8061267 works correctly with this patch. Regards Prasanta From alexander.v.stepanov at oracle.com Wed Apr 6 10:14:15 2016 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Wed, 6 Apr 2016 13:14:15 +0300 Subject: [OpenJDK 2D-Dev] RFR 8152183: [TEST] add test for TIFFField In-Reply-To: <5704D4FC.5080202@oracle.com> References: <56F2A387.8070506@oracle.com> <56F90248.7000609@oracle.com> <56FEB06A.7040806@oracle.com> <5704428A.6090600@oracle.com> <5704D4FC.5080202@oracle.com> Message-ID: <5704E177.3070205@oracle.com> P.S.: and even if scratch is accidentally non-writable (which is definitely an exceptional situation), then the 'writeImage()' method will throw a proper Exception, so it seems there is no need in additional checks here. Thanks, Alexander On 4/6/2016 12:21 PM, Alexander Stepanov wrote: > Hello Phil, > > > I did not think you could assume $CWD is writeable in jtreg tests. > > according to the jtreg docs, "when jtreg is executed, it cd's into a > scratch". Could the scratch dir be non-writable? At a 1st glance it > seems to be unlikely, but maybe I'm wrong. > > Thanks, > Alexander > > On 4/6/2016 1:56 AM, Phil Race wrote: >> 45 private final static String FILENAME = "test.tiff"; >> >> 136 OutputStream s = new BufferedOutputStream(new >> FileOutputStream(FILENAME)); >> >> >> I did not think you could assume $CWD is writeable in jtreg tests. >> If I can be assured this is actually OK then I have no other issues. >> >> -phil. >> >> On 04/01/2016 10:31 AM, Alexander Stepanov wrote: >>> Please see the updated webrev: >>> http://cr.openjdk.java.net/~avstepan/8152183/webrev.01/ >>> >>> One more test (for multi-page tiffs) was added; for now to be >>> ignored because of JDK-8148454 >>> >>> Thanks, >>> Alexander >>> >>> On 3/28/2016 1:07 PM, Alexander Stepanov wrote: >>>> Sorry, just a reminder. >>>> >>>> Thanks, >>>> Alexander >>>> >>>> On 3/23/2016 5:09 PM, Alexander Stepanov wrote: >>>>> Hello, >>>>> >>>>> Could you please review the following fix >>>>> http://cr.openjdk.java.net/~avstepan/8152183/webrev.00/ >>>>> for >>>>> https://bugs.openjdk.java.net/browse/JDK-8152183 >>>>> >>>>> Just a single test added. >>>>> >>>>> Thanks, >>>>> Alexander >>>> >>> >> > From prasanta.sadhukhan at oracle.com Wed Apr 6 11:36:42 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Wed, 6 Apr 2016 17:06:42 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: PrinterJob.getUserName() throws a security exception when user.name permission is not given Message-ID: <5704F4CA.3020108@oracle.com> Hi All, Please review a document fix for jdk9 Bug: https://bugs.openjdk.java.net/browse/JDK-6197099 webrev: http://cr.openjdk.java.net/~psadhukhan/6197099/webrev.00/ PrinterJob.getUserName() is supposed to return the current user name of the system. This method does not document any exception. But when SecurityManager is installed, this method throws a security exception when PropertyPermission - user.name is not given in the policy file. But this is not documented anywhere and hence the user will not know until he gets the exception. Documented the long-standing existing exception. will raise a ccc after the technical review. Regards Prasanta From jayathirth.d.v at oracle.com Wed Apr 6 11:47:25 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 6 Apr 2016 04:47:25 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: equals() method in IndexColorModel doesnt exist and it relies on ColorModel.equals() which is not strict Message-ID: Hi, Please review the following fix in JDK9: Bug : https://bugs.openjdk.java.net/browse/JDK-7107905 Webrev : http://cr.openjdk.java.net/~jdv/7107905/webrev.00/ Issue : When we compare two IndexColorModel objects with different ColorMap(or any other property specific to IndexColorModel) using equals() method it returns true. Root cause : There is no override equals() method specific to IndexColorModel and it uses super class equals() which is ColorModel and it doesn't verify equality for IndexColorModel specific properties. Solution : Add override equals() method for IndexColorModel which verifies its unique properties for equality. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Wed Apr 6 12:39:50 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 6 Apr 2016 15:39:50 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8134986: Incorrect use of ConcurrentHashMap.contains in SunFontManager.java In-Reply-To: <5702EBA5.1020304@oracle.com> References: <5702EBA5.1020304@oracle.com> Message-ID: <57050396.5070202@oracle.com> Looks fine. On 05.04.16 1:33, Phil Race wrote: > https://bugs.openjdk.java.net/browse/JDK-8134986 > > When converted from a HashSet to a HashMap contains() should have > changed to containsKey(). It does not lead to duplicate fonts because > it is caught later on but it might lead to wasted work > > One line fix in line below > > diff --git a/src/java.desktop/share/classes/sun/font/SunFontManager.java > b/src/java.desktop/share/classes/sun/font/SunFontManager.java > --- a/src/java.desktop/share/classes/sun/font/SunFontManager.java > +++ b/src/java.desktop/share/classes/sun/font/SunFontManager.java > @@ -1843,7 +1843,7 @@ > > private PhysicalFont registerFontFile(String file) { > if (new File(file).isAbsolute() && > - !registeredFonts.contains(file)) { > + !registeredFonts.containsKey(file)) { > int fontFormat = FONTFORMAT_NONE; > int fontRank = Font2D.UNKNOWN_RANK; > if (ttFilter.accept(null, file)) { > > > -phil. > -- Best regards, Sergey. From james.graham at oracle.com Wed Apr 6 21:17:36 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 6 Apr 2016 14:17:36 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: equals() method in IndexColorModel doesnt exist and it relies on ColorModel.equals() which is not strict In-Reply-To: References: Message-ID: <57057CF0.50604@oracle.com> Are there any bugs in the database about the fact that many of these ColorModel subclasses implement equals without hashcode? They really should both be implemented, but since ColorModel implements the method based on its tests, they are technically covered by the equals/hashCode contract - it's just not a very optimal implementation of the contract. For now, it would be good to implement hashCode() on ICM now that you are creating an equals() method for it. Also, ColorModel.hashCode() is a poor implementation. It doesn't use the paradigms recommended by Effective Java and looks like it produces poor hashes as a result (just in the first two elements of the hashCode I see a collision due to poor choice of numbers). With respect to this particular equals() override I think it looks fine, though the use of the isValid() method reduces its performance for a couple of reasons: - it retests the index for the range [0,map size] which we already know is valid - if the validBits is null, there is no need to even do the test. This might be faster for the very common case: if (validBits == null) { if (cm.validBits != null) return false; // loop just comparing rgb[] values } else { if (cm.validBits == null) return false; // loop, testing rgb[] values and // corresponding validBits indices directly } Note that in the constructor we set validBits to null if it is "true" for all valid indices so if one of the cmaps has it null and the other does not, then that is a very good indicator that their valid indices don't match. On a more minor note, I don't like the indentation of the if statement, I'd move the "{" brace to a line of its own indented the same as its closing "}" to make the body of the if stand out. It isn't strictly the Java coding guidelines, but it does match a bunch of the other 2D code - sort of a local exception to the coding style. I'd also add a few test cases that test that 2 separately and identically constructed ICM instances are equals() == true, tested with one of each of the constructors... ...jim On 4/6/2016 4:47 AM, Jayathirth D V wrote: > Hi, > > _Please review the following fix in JDK9:_ > > Bug : https://bugs.openjdk.java.net/browse/JDK-7107905 > > Webrev : http://cr.openjdk.java.net/~jdv/7107905/webrev.00/ > > Issue : When we compare two IndexColorModel objects with different > ColorMap(or any other property specific to IndexColorModel) using > equals() method it returns true. > > Root cause : There is no override equals() method specific to > IndexColorModel and it uses super class equals() which is ColorModel and > it doesn?t verify equality for IndexColorModel specific properties. > > Solution : Add override equals() method for IndexColorModel which > verifies its unique properties for equality. > > Thanks, > > Jay > From dmitry.batrak at jetbrains.com Thu Apr 7 12:26:28 2016 From: dmitry.batrak at jetbrains.com (Dmitry Batrak) Date: Thu, 7 Apr 2016 15:26:28 +0300 Subject: [OpenJDK 2D-Dev] [PATCH] JDK-8146035: Windows - With LCD antialiasing, some glyphs are not rendered correctly Message-ID: Hello, I'd like to propose a fix for JDK-8146035. I am not a committer, so I hope someone can sponsor this fix. I work at Jetbrains, which has signed a company-level contributor agreement, so, from a legal perspective, I believe, there are no obstacles. My investigation shows that the issue is caused by incorrect determination of bitmap size, prepared for glyph rendering, so only part of glyph becomes visible due to cropping. This seems to happen because compatible bitmap is not selected into memory device context (DC) before calling GetTextMetrics. Documentation for CreateCompatibleDC call ( https://msdn.microsoft.com/en-us/library/windows/desktop/dd183489%28v=vs.85%29.aspx) says compatible bitmap needs to be selected into DC before any drawing operation. Even though GetTextMetrics is not a drawing operation, it turns out to be affected by selected bitmap's type too (by default a monochrome bitmap is selected in a memory DC). This behaviour was also mentioned in the following MSDN blog post comment: https://blogs.msdn.microsoft.com/oldnewthing/20060614-00/?p=30873#comment-392143 The proposed fix is to select a temporary 1x1 compatible bitmap into memory DC before GetTextMetrics call. Here's webrev link - http://adm-12504.intellij.net/ I didn't create a test case, as it would require a specific font file (I couldn't reproduce the issue for fonts bundled with Windows). Best regards, Dmitry Batrak -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick at reini.net Thu Apr 7 12:32:54 2016 From: patrick at reini.net (patrick at reini.net) Date: Thu, 07 Apr 2016 14:32:54 +0200 Subject: [OpenJDK 2D-Dev] JDK-8153732 Change Windows refresh logic to also catch remote printer changes Message-ID: <8db78b505f148620ccc91a60e5bd20f3@reini.net> Hi all, I have various customers that do use remote print servers from the application servers and therefore do not see remote printers added without restarting the JVM of the application server using the current implementation. Because I do not want to tweak with reflection on the Windows PrintServiceLookup implementation in the long run, I would like to help implementing a alternate solution that also handles remote printers as well. I would like to discuss a possible solution for this problem using a the RegistryKeyChangeEvent on printer registry keys instead of the FindFirstPrinterChangeNotification call as described in the following blog: https://blogs.msdn.microsoft.com/hmahrt/2012/04/09/how-to-listen-for-printer-connections/ Cheers Patrick From jayathirth.d.v at oracle.com Thu Apr 7 13:46:37 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 7 Apr 2016 06:46:37 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: equals() method in IndexColorModel doesnt exist and it relies on ColorModel.equals() which is not strict In-Reply-To: <57057CF0.50604@oracle.com> References: <57057CF0.50604@oracle.com> Message-ID: Hi Jim, Thanks for your valuable inputs. Please find the updates inline. I have created new webrev http://cr.openjdk.java.net/~jdv/7107905/webrev.01/ for review. Are there any bugs in the database about the fact that many of these ColorModel subclasses implement equals without hashcode? They really should both be implemented, but since ColorModel implements the method based on its tests, they are technically covered by the equals/hashCode contract - it's just not a very optimal implementation of the contract. - Yes https://bugs.openjdk.java.net/browse/JDK-6588409 has mentioned the same thing. Can I create a subtask to address java.awt.image changes? For now, it would be good to implement hashCode() on ICM now that you are creating an equals() method for it. - I am not completely sure of what is the optimal way of adding hashCode() API so I took help from internet and IDE to make the changes. I am including super.hashCode() as it adds uniqueness to ICM. Also, ColorModel.hashCode() is a poor implementation. It doesn't use the paradigms recommended by Effective Java and looks like it produces poor hashes as a result (just in the first two elements of the hashCode I see a collision due to poor choice of numbers). - I think since we are not using Prime numbers and it might result in improper hash code. I have made similar changes to hashCode() of ColorModel. With respect to this particular equals() override I think it looks fine, though the use of the isValid() method reduces its performance for a couple of reasons: - it retests the index for the range [0,map size] which we already know is valid - if the validBits is null, there is no need to even do the test. This might be faster for the very common case: if (validBits == null) { if (cm.validBits != null) return false; // loop just comparing rgb[] values } else { if (cm.validBits == null) return false; // loop, testing rgb[] values and // corresponding validBits indices directly } Note that in the constructor we set validBits to null if it is "true" for all valid indices so if one of the cmaps has it null and the other does not, then that is a very good indicator that their valid indices don't match. - I have updated the suggested changes. On a more minor note, I don't like the indentation of the if statement, I'd move the "{" brace to a line of its own indented the same as its closing "}" to make the body of the if stand out. It isn't strictly the Java coding guidelines, but it does match a bunch of the other 2D code - sort of a local exception to the coding style. - In the same file itself we are following Java coding guidelines of having braces after if like "if () {". I am not completely sure of including "{" in new line. I'd also add a few test cases that test that 2 separately and identically constructed ICM instances are equals() == true, tested with one of each of the constructors... - I have made changes to test case for verifying all constructors with same ICM. Also added verification for hashCode value. ...jim On 4/6/2016 4:47 AM, Jayathirth D V wrote: > Hi, > > _Please review the following fix in JDK9:_ > > Bug : https://bugs.openjdk.java.net/browse/JDK-7107905 > > Webrev : http://cr.openjdk.java.net/~jdv/7107905/webrev.00/ > > Issue : When we compare two IndexColorModel objects with different > ColorMap(or any other property specific to IndexColorModel) using > equals() method it returns true. > > Root cause : There is no override equals() method specific to > IndexColorModel and it uses super class equals() which is ColorModel > and it doesn't verify equality for IndexColorModel specific properties. > > Solution : Add override equals() method for IndexColorModel which > verifies its unique properties for equality. > > Thanks, > > Jay > From james.graham at oracle.com Thu Apr 7 18:58:06 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 7 Apr 2016 11:58:06 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: equals() method in IndexColorModel doesnt exist and it relies on ColorModel.equals() which is not strict In-Reply-To: References: <57057CF0.50604@oracle.com> Message-ID: <5706ADBE.10803@oracle.com> Hi Jayathirth, This looks good. One thing to note for efficiency, "instanceof" also checks for null. It only returns true for non-null objects, so you don't need to explicitly test for null at the top of ICM.equals(). (Though, you should include a test(s) in the unit test that verifies that no ICM returns true for equals(null) to be sure.) You can see that CM.equals() is implemented this way. Also, for performance, ICM should include a quick "if (this == cm) return true;" check, like CM.equals(). I'd recommend: - first instanceof - then == test - then super.equals() - finally, test equality of data fields More comments inline: On 4/7/16 6:46 AM, Jayathirth D V wrote: > - Yes https://bugs.openjdk.java.net/browse/JDK-6588409 has mentioned the same thing. Can I create a subtask to address java.awt.image changes? That would be good. > For now, it would be good to implement hashCode() on ICM now that you are creating an equals() method for it. > > - I am not completely sure of what is the optimal way of adding hashCode() API so I took help from internet and IDE to make the changes. I am including super.hashCode() as it adds uniqueness to ICM. You did a great job. To save time in the future, you should all have copies of the latest version of "Effective Java" by Josh Bloch. It has a whole chapter on equals/hashCode. It's a very handy reference for all sorts of good programming practice for the Java language. > Also, ColorModel.hashCode() is a poor implementation. It doesn't use the paradigms recommended by Effective Java and looks like it produces poor hashes as a result (just in the first two elements of the hashCode I see a collision due to poor choice of numbers). > - I think since we are not using Prime numbers and it might result in improper hash code. I have made similar changes to hashCode() of ColorModel. Looks great. > - In the same file itself we are following Java coding guidelines of having braces after if like "if () {". I am not completely sure of including "{" in new line. You are correct, that matching local code is a good consideration when considering code style. In this case, though, the indentation on these if statements is an example of what we're trying to avoid so it would be better to fix these particular statements (don't bother fixing the other lines in the file at this point, that can wait until we have to update other parts of the file, but don't propagate a bad style in new code). In particular: Never do this: if (some complex test || some additional tests || some additional tests || some additional tests || some continuation of the test) { the body of the code; more body of the code; } Quick question - where does the body of the if statement start? Does your eye see it in a fraction of a second or do you have to search for it? That is the worst option for indenting an if statement with continuation lines. Never do that in new code. Do either of the following two versions: Java Code Style guidelines recommends indenting 8 spaces for conditional continuations: if (some complex test || some additional tests || some additional tests || some additional tests || some continuation of the test) { the body of the code; more body of the code; } Jim's personal extension to the JCS recommends (and the 2D team historically tended to agree): if (some complex test || some additional tests || some additional tests || some additional tests || some continuation of the test) { the body of the code; more body of the code; } Both of those immediately draw the eye to the separating point between the conditional and the body of the code. > I'd also add a few test cases that test that 2 separately and identically constructed ICM instances are equals() == true, tested with one of each of the constructors... > > - I have made changes to test case for verifying all constructors with same ICM. Also added verification for hashCode value. Unfortunately, some of your tests for hashCode make an invalid assumption. It is technically correct for the hash codes of 2 different objects to be the same regardless of whether they are equals() or not. In fact, a perfectly valid implementation of hashCode() could return a constant number and it would be correct from the perspective of the equals/hashCode contract. (Such code, however, would not be optimal, but it would be valid/correct-to-spec.) The only condition that is required is that the hash codes match if the objects are equals(), but they are allowed to match if the objects are !equals(). In other words: boolean equals1 = (o1.equals(o2)); boolean equals2 = (o2.equals(o1)); boolean equalsH = (o1.hashCode() == o2.hashCode()); if (equals1 != equals2) that is an error - we should test this if (equals1 && !equalsH) that is an error - we should test this // No other conditions are an error, no other testing should be done In particular, the cases where you test the hash codes for being the same on objects that are not intended to be equals() should be deleted. It would be good to also add tests to make sure that they are symmetrically equals (or symmetrically not equals) as well (i.e. o1.equals(o2) matches o2.equals(o1) in all cases whether they match or not). Since it is less than optimal for hash codes to match if the objects are not equal, it might potentially be something to check on, but it should not generate a unit test failure and so should not appear in the unit test for this bug. Such a "code collision test" would be part of a performance test run periodically for QA, but we have never bothered with hashCode optimization unless a customer submits a complaint about the performance of some object in a hash map due to hash collisions (and I doubt that ColorModel objects are being used in such a manner), so I wouldn't recommend it here. ...jim From Sergey.Bylokhov at oracle.com Thu Apr 7 19:11:41 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 7 Apr 2016 22:11:41 +0300 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: equals() method in IndexColorModel doesnt exist and it relies on ColorModel.equals() which is not strict In-Reply-To: <5706ADBE.10803@oracle.com> References: <57057CF0.50604@oracle.com> <5706ADBE.10803@oracle.com> Message-ID: <5706B0ED.80806@oracle.com> Small note that we should not forget to create a ccc. On 07.04.16 21:58, Jim Graham wrote: > Hi Jayathirth, > > This looks good. > > One thing to note for efficiency, "instanceof" also checks for null. It > only returns true for non-null objects, so you don't need to explicitly > test for null at the top of ICM.equals(). (Though, you should include a > test(s) in the unit test that verifies that no ICM returns true for > equals(null) to be sure.) You can see that CM.equals() is implemented > this way. > > Also, for performance, ICM should include a quick "if (this == cm) > return true;" check, like CM.equals(). I'd recommend: > > - first instanceof > - then == test > - then super.equals() > - finally, test equality of data fields > > More comments inline: > > On 4/7/16 6:46 AM, Jayathirth D V wrote: >> - Yes https://bugs.openjdk.java.net/browse/JDK-6588409 has >> mentioned the same thing. Can I create a subtask to address >> java.awt.image changes? > > That would be good. > >> For now, it would be good to implement hashCode() on ICM now that you >> are creating an equals() method for it. >> >> - I am not completely sure of what is the optimal way of adding >> hashCode() API so I took help from internet and IDE to make the >> changes. I am including super.hashCode() as it adds uniqueness to ICM. > > You did a great job. To save time in the future, you should all have > copies of the latest version of "Effective Java" by Josh Bloch. It has > a whole chapter on equals/hashCode. It's a very handy reference for all > sorts of good programming practice for the Java language. > >> Also, ColorModel.hashCode() is a poor implementation. It doesn't use >> the paradigms recommended by Effective Java and looks like it produces >> poor hashes as a result (just in the first two elements of the >> hashCode I see a collision due to poor choice of numbers). >> - I think since we are not using Prime numbers and it might result >> in improper hash code. I have made similar changes to hashCode() of >> ColorModel. > > Looks great. > >> - In the same file itself we are following Java coding guidelines >> of having braces after if like "if () {". I am not completely sure of >> including "{" in new line. > > You are correct, that matching local code is a good consideration when > considering code style. In this case, though, the indentation on these > if statements is an example of what we're trying to avoid so it would be > better to fix these particular statements (don't bother fixing the other > lines in the file at this point, that can wait until we have to update > other parts of the file, but don't propagate a bad style in new code). > In particular: > > Never do this: > > if (some complex test || > some additional tests || > some additional tests || > some additional tests || > some continuation of the test) { > the body of the code; > more body of the code; > } > Quick question - where does the body of the if statement start? Does > your eye see it in a fraction of a second or do you have to search for it? > > That is the worst option for indenting an if statement with continuation > lines. Never do that in new code. Do either of the following two > versions: > > Java Code Style guidelines recommends indenting 8 spaces for conditional > continuations: > if (some complex test || > some additional tests || > some additional tests || > some additional tests || > some continuation of the test) { > the body of the code; > more body of the code; > } > > Jim's personal extension to the JCS recommends (and the 2D team > historically tended to agree): > if (some complex test || > some additional tests || > some additional tests || > some additional tests || > some continuation of the test) > { > the body of the code; > more body of the code; > } > > Both of those immediately draw the eye to the separating point between > the conditional and the body of the code. > >> I'd also add a few test cases that test that 2 separately and >> identically constructed ICM instances are equals() == true, tested >> with one of each of the constructors... >> >> - I have made changes to test case for verifying all constructors >> with same ICM. Also added verification for hashCode value. > > Unfortunately, some of your tests for hashCode make an invalid > assumption. It is technically correct for the hash codes of 2 different > objects to be the same regardless of whether they are equals() or not. > In fact, a perfectly valid implementation of hashCode() could return a > constant number and it would be correct from the perspective of the > equals/hashCode contract. (Such code, however, would not be optimal, > but it would be valid/correct-to-spec.) The only condition that is > required is that the hash codes match if the objects are equals(), but > they are allowed to match if the objects are !equals(). In other words: > > boolean equals1 = (o1.equals(o2)); > boolean equals2 = (o2.equals(o1)); > boolean equalsH = (o1.hashCode() == o2.hashCode()); > > if (equals1 != equals2) that is an error - we should test this > if (equals1 && !equalsH) that is an error - we should test this > // No other conditions are an error, no other testing should be done > > In particular, the cases where you test the hash codes for being the > same on objects that are not intended to be equals() should be deleted. > It would be good to also add tests to make sure that they are > symmetrically equals (or symmetrically not equals) as well (i.e. > o1.equals(o2) matches o2.equals(o1) in all cases whether they match or > not). > > Since it is less than optimal for hash codes to match if the objects are > not equal, it might potentially be something to check on, but it should > not generate a unit test failure and so should not appear in the unit > test for this bug. Such a "code collision test" would be part of a > performance test run periodically for QA, but we have never bothered > with hashCode optimization unless a customer submits a complaint about > the performance of some object in a hash map due to hash collisions (and > I doubt that ColorModel objects are being used in such a manner), so I > wouldn't recommend it here. > > ...jim -- Best regards, Sergey. From yuri.nesterenko at oracle.com Fri Apr 8 09:08:43 2016 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Fri, 8 Apr 2016 12:08:43 +0300 Subject: [OpenJDK 2D-Dev] RFR 8152183: [TEST] add test for TIFFField In-Reply-To: <56FEB06A.7040806@oracle.com> References: <56F2A387.8070506@oracle.com> <56F90248.7000609@oracle.com> <56FEB06A.7040806@oracle.com> Message-ID: <5707751B.2030708@oracle.com> +1 -yan On 04/01/2016 08:31 PM, Alexander Stepanov wrote: > Please see the updated webrev: > http://cr.openjdk.java.net/~avstepan/8152183/webrev.01/ > > One more test (for multi-page tiffs) was added; for now to be ignored > because of JDK-8148454 > > Thanks, > Alexander > > On 3/28/2016 1:07 PM, Alexander Stepanov wrote: >> Sorry, just a reminder. >> >> Thanks, >> Alexander >> >> On 3/23/2016 5:09 PM, Alexander Stepanov wrote: >>> Hello, >>> >>> Could you please review the following fix >>> http://cr.openjdk.java.net/~avstepan/8152183/webrev.00/ >>> for >>> https://bugs.openjdk.java.net/browse/JDK-8152183 >>> >>> Just a single test added. >>> >>> Thanks, >>> Alexander >> > From alexander.v.stepanov at oracle.com Fri Apr 8 09:25:04 2016 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Fri, 8 Apr 2016 12:25:04 +0300 Subject: [OpenJDK 2D-Dev] RFR 8152183: [TEST] add test for TIFFField In-Reply-To: <5707751B.2030708@oracle.com> References: <56F2A387.8070506@oracle.com> <56F90248.7000609@oracle.com> <56FEB06A.7040806@oracle.com> <5707751B.2030708@oracle.com> Message-ID: <570778F0.6050804@oracle.com> Thanks! On 4/8/2016 12:08 PM, Yuri Nesterenko wrote: > +1 > > -yan > > On 04/01/2016 08:31 PM, Alexander Stepanov wrote: >> Please see the updated webrev: >> http://cr.openjdk.java.net/~avstepan/8152183/webrev.01/ >> >> One more test (for multi-page tiffs) was added; for now to be ignored >> because of JDK-8148454 >> >> Thanks, >> Alexander >> >> On 3/28/2016 1:07 PM, Alexander Stepanov wrote: >>> Sorry, just a reminder. >>> >>> Thanks, >>> Alexander >>> >>> On 3/23/2016 5:09 PM, Alexander Stepanov wrote: >>>> Hello, >>>> >>>> Could you please review the following fix >>>> http://cr.openjdk.java.net/~avstepan/8152183/webrev.00/ >>>> for >>>> https://bugs.openjdk.java.net/browse/JDK-8152183 >>>> >>>> Just a single test added. >>>> >>>> Thanks, >>>> Alexander >>> >> > From jayathirth.d.v at oracle.com Mon Apr 11 07:46:32 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 11 Apr 2016 00:46:32 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: equals() method in IndexColorModel doesnt exist and it relies on ColorModel.equals() which is not strict In-Reply-To: <5706ADBE.10803@oracle.com> References: <57057CF0.50604@oracle.com> <5706ADBE.10803@oracle.com> Message-ID: Hi Jim, Thanks for the review. I have made all recommended changes and created new subtask for JDK-6588409(https://bugs.openjdk.java.net/browse/JDK-8153943 ). Please review updated webrev: http://cr.openjdk.java.net/~jdv/7107905/webrev.02/ Thanks, Jay -----Original Message----- From: Jim Graham Sent: Friday, April 08, 2016 12:28 AM To: Jayathirth D V; Philip Race; Prasanta Sadhukhan Cc: 2d-dev at openjdk.java.net Subject: Re: Review Request for JDK-7107905: equals() method in IndexColorModel doesnt exist and it relies on ColorModel.equals() which is not strict Hi Jayathirth, This looks good. One thing to note for efficiency, "instanceof" also checks for null. It only returns true for non-null objects, so you don't need to explicitly test for null at the top of ICM.equals(). (Though, you should include a test(s) in the unit test that verifies that no ICM returns true for equals(null) to be sure.) You can see that CM.equals() is implemented this way. Also, for performance, ICM should include a quick "if (this == cm) return true;" check, like CM.equals(). I'd recommend: - first instanceof - then == test - then super.equals() - finally, test equality of data fields More comments inline: On 4/7/16 6:46 AM, Jayathirth D V wrote: > - Yes https://bugs.openjdk.java.net/browse/JDK-6588409 has mentioned the same thing. Can I create a subtask to address java.awt.image changes? That would be good. > For now, it would be good to implement hashCode() on ICM now that you are creating an equals() method for it. > > - I am not completely sure of what is the optimal way of adding hashCode() API so I took help from internet and IDE to make the changes. I am including super.hashCode() as it adds uniqueness to ICM. You did a great job. To save time in the future, you should all have copies of the latest version of "Effective Java" by Josh Bloch. It has a whole chapter on equals/hashCode. It's a very handy reference for all sorts of good programming practice for the Java language. > Also, ColorModel.hashCode() is a poor implementation. It doesn't use the paradigms recommended by Effective Java and looks like it produces poor hashes as a result (just in the first two elements of the hashCode I see a collision due to poor choice of numbers). > - I think since we are not using Prime numbers and it might result in improper hash code. I have made similar changes to hashCode() of ColorModel. Looks great. > - In the same file itself we are following Java coding guidelines of having braces after if like "if () {". I am not completely sure of including "{" in new line. You are correct, that matching local code is a good consideration when considering code style. In this case, though, the indentation on these if statements is an example of what we're trying to avoid so it would be better to fix these particular statements (don't bother fixing the other lines in the file at this point, that can wait until we have to update other parts of the file, but don't propagate a bad style in new code). In particular: Never do this: if (some complex test || some additional tests || some additional tests || some additional tests || some continuation of the test) { the body of the code; more body of the code; } Quick question - where does the body of the if statement start? Does your eye see it in a fraction of a second or do you have to search for it? That is the worst option for indenting an if statement with continuation lines. Never do that in new code. Do either of the following two versions: Java Code Style guidelines recommends indenting 8 spaces for conditional continuations: if (some complex test || some additional tests || some additional tests || some additional tests || some continuation of the test) { the body of the code; more body of the code; } Jim's personal extension to the JCS recommends (and the 2D team historically tended to agree): if (some complex test || some additional tests || some additional tests || some additional tests || some continuation of the test) { the body of the code; more body of the code; } Both of those immediately draw the eye to the separating point between the conditional and the body of the code. > I'd also add a few test cases that test that 2 separately and identically constructed ICM instances are equals() == true, tested with one of each of the constructors... > > - I have made changes to test case for verifying all constructors with same ICM. Also added verification for hashCode value. Unfortunately, some of your tests for hashCode make an invalid assumption. It is technically correct for the hash codes of 2 different objects to be the same regardless of whether they are equals() or not. In fact, a perfectly valid implementation of hashCode() could return a constant number and it would be correct from the perspective of the equals/hashCode contract. (Such code, however, would not be optimal, but it would be valid/correct-to-spec.) The only condition that is required is that the hash codes match if the objects are equals(), but they are allowed to match if the objects are !equals(). In other words: boolean equals1 = (o1.equals(o2)); boolean equals2 = (o2.equals(o1)); boolean equalsH = (o1.hashCode() == o2.hashCode()); if (equals1 != equals2) that is an error - we should test this if (equals1 && !equalsH) that is an error - we should test this // No other conditions are an error, no other testing should be done In particular, the cases where you test the hash codes for being the same on objects that are not intended to be equals() should be deleted. It would be good to also add tests to make sure that they are symmetrically equals (or symmetrically not equals) as well (i.e. o1.equals(o2) matches o2.equals(o1) in all cases whether they match or not). Since it is less than optimal for hash codes to match if the objects are not equal, it might potentially be something to check on, but it should not generate a unit test failure and so should not appear in the unit test for this bug. Such a "code collision test" would be part of a performance test run periodically for QA, but we have never bothered with hashCode optimization unless a customer submits a complaint about the performance of some object in a hash map due to hash collisions (and I doubt that ColorModel objects are being used in such a manner), so I wouldn't recommend it here. ...jim From jayathirth.d.v at oracle.com Mon Apr 11 08:28:03 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 11 Apr 2016 01:28:03 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: equals() method in IndexColorModel doesnt exist and it relies on ColorModel.equals() which is not strict In-Reply-To: <5706B0ED.80806@oracle.com> References: <57057CF0.50604@oracle.com> <5706ADBE.10803@oracle.com> <5706B0ED.80806@oracle.com> Message-ID: <49e8f020-9d95-4925-ac01-aa6a7e349a82@default> Sure Sergey after technical review is done I will raise CCC for the same. Thanks, Jay -----Original Message----- From: Sergey Bylokhov Sent: Friday, April 08, 2016 12:42 AM To: Jim Graham; Jayathirth D V; Philip Race; Prasanta Sadhukhan Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: equals() method in IndexColorModel doesnt exist and it relies on ColorModel.equals() which is not strict Small note that we should not forget to create a ccc. On 07.04.16 21:58, Jim Graham wrote: > Hi Jayathirth, > > This looks good. > > One thing to note for efficiency, "instanceof" also checks for null. > It only returns true for non-null objects, so you don't need to > explicitly test for null at the top of ICM.equals(). (Though, you > should include a > test(s) in the unit test that verifies that no ICM returns true for > equals(null) to be sure.) You can see that CM.equals() is implemented > this way. > > Also, for performance, ICM should include a quick "if (this == cm) > return true;" check, like CM.equals(). I'd recommend: > > - first instanceof > - then == test > - then super.equals() > - finally, test equality of data fields > > More comments inline: > > On 4/7/16 6:46 AM, Jayathirth D V wrote: >> - Yes https://bugs.openjdk.java.net/browse/JDK-6588409 has >> mentioned the same thing. Can I create a subtask to address >> java.awt.image changes? > > That would be good. > >> For now, it would be good to implement hashCode() on ICM now that you >> are creating an equals() method for it. >> >> - I am not completely sure of what is the optimal way of adding >> hashCode() API so I took help from internet and IDE to make the >> changes. I am including super.hashCode() as it adds uniqueness to ICM. > > You did a great job. To save time in the future, you should all have > copies of the latest version of "Effective Java" by Josh Bloch. It > has a whole chapter on equals/hashCode. It's a very handy reference > for all sorts of good programming practice for the Java language. > >> Also, ColorModel.hashCode() is a poor implementation. It doesn't use >> the paradigms recommended by Effective Java and looks like it >> produces poor hashes as a result (just in the first two elements of >> the hashCode I see a collision due to poor choice of numbers). >> - I think since we are not using Prime numbers and it might >> result in improper hash code. I have made similar changes to >> hashCode() of ColorModel. > > Looks great. > >> - In the same file itself we are following Java coding guidelines >> of having braces after if like "if () {". I am not completely sure of >> including "{" in new line. > > You are correct, that matching local code is a good consideration when > considering code style. In this case, though, the indentation on > these if statements is an example of what we're trying to avoid so it > would be better to fix these particular statements (don't bother > fixing the other lines in the file at this point, that can wait until > we have to update other parts of the file, but don't propagate a bad style in new code). > In particular: > > Never do this: > > if (some complex test || > some additional tests || > some additional tests || > some additional tests || > some continuation of the test) { > the body of the code; > more body of the code; > } > Quick question - where does the body of the if statement start? Does > your eye see it in a fraction of a second or do you have to search for it? > > That is the worst option for indenting an if statement with > continuation lines. Never do that in new code. Do either of the > following two > versions: > > Java Code Style guidelines recommends indenting 8 spaces for > conditional > continuations: > if (some complex test || > some additional tests || > some additional tests || > some additional tests || > some continuation of the test) { > the body of the code; > more body of the code; > } > > Jim's personal extension to the JCS recommends (and the 2D team > historically tended to agree): > if (some complex test || > some additional tests || > some additional tests || > some additional tests || > some continuation of the test) > { > the body of the code; > more body of the code; > } > > Both of those immediately draw the eye to the separating point between > the conditional and the body of the code. > >> I'd also add a few test cases that test that 2 separately and >> identically constructed ICM instances are equals() == true, tested >> with one of each of the constructors... >> >> - I have made changes to test case for verifying all constructors >> with same ICM. Also added verification for hashCode value. > > Unfortunately, some of your tests for hashCode make an invalid > assumption. It is technically correct for the hash codes of 2 > different objects to be the same regardless of whether they are equals() or not. > In fact, a perfectly valid implementation of hashCode() could return a > constant number and it would be correct from the perspective of the > equals/hashCode contract. (Such code, however, would not be optimal, > but it would be valid/correct-to-spec.) The only condition that is > required is that the hash codes match if the objects are equals(), but > they are allowed to match if the objects are !equals(). In other words: > > boolean equals1 = (o1.equals(o2)); > boolean equals2 = (o2.equals(o1)); > boolean equalsH = (o1.hashCode() == o2.hashCode()); > > if (equals1 != equals2) that is an error - we should test this if > (equals1 && !equalsH) that is an error - we should test this // No > other conditions are an error, no other testing should be done > > In particular, the cases where you test the hash codes for being the > same on objects that are not intended to be equals() should be deleted. > It would be good to also add tests to make sure that they are > symmetrically equals (or symmetrically not equals) as well (i.e. > o1.equals(o2) matches o2.equals(o1) in all cases whether they match or > not). > > Since it is less than optimal for hash codes to match if the objects > are not equal, it might potentially be something to check on, but it > should not generate a unit test failure and so should not appear in > the unit test for this bug. Such a "code collision test" would be > part of a performance test run periodically for QA, but we have never > bothered with hashCode optimization unless a customer submits a > complaint about the performance of some object in a hash map due to > hash collisions (and I doubt that ColorModel objects are being used in > such a manner), so I wouldn't recommend it here. > > ...jim -- Best regards, Sergey. From alexey.ivanov at oracle.com Mon Apr 11 13:53:02 2016 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Mon, 11 Apr 2016 16:53:02 +0300 Subject: [OpenJDK 2D-Dev] [PATCH] JDK-8146035: Windows - With LCD antialiasing, some glyphs are not rendered correctly In-Reply-To: References: Message-ID: <570BAC3E.2070008@oracle.com> Hello Dmitry, Thank you very much for your patch. The fix looks good to me. I will sponsor integrating the fix into the code base as soon as code review is complete. Thanks, Alexey On 07.04.2016 15:26, Dmitry Batrak wrote: > Hello, > > I'd like to propose a fix for JDK-8146035. I am not a committer, > so I hope someone can sponsor this fix. > I work at Jetbrains, which has signed a company-level contributor > agreement, > so, from a legal perspective, I believe, there are no obstacles. > > My investigation shows that the issue is caused by incorrect > determination > of bitmap size, prepared for glyph rendering, so only part of glyph > becomes visible due to cropping. This seems to happen because > compatible bitmap is not selected into memory device context (DC) > before calling GetTextMetrics. Documentation for CreateCompatibleDC call > (https://msdn.microsoft.com/en-us/library/windows/desktop/dd183489%28v=vs.85%29.aspx) > > says compatible bitmap needs to be selected into DC before any drawing > operation. > Even though GetTextMetrics is not a drawing operation, it turns out > to be affected by selected bitmap's type too (by default a monochrome > bitmap > is selected in a memory DC). This behaviour was also mentioned in the > following > MSDN blog post comment: > https://blogs.msdn.microsoft.com/oldnewthing/20060614-00/?p=30873#comment-392143 > > The proposed fix is to select a temporary 1x1 compatible bitmap > into memory DC before GetTextMetrics call. > Here's webrev link - http://adm-12504.intellij.net/ > I didn't create a test case, as it would require a specific font file > (I couldn't reproduce the issue for fonts bundled with Windows). > > Best regards, > Dmitry Batrak From james.graham at oracle.com Mon Apr 11 18:51:11 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 11 Apr 2016 11:51:11 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: equals() method in IndexColorModel doesnt exist and it relies on ColorModel.equals() which is not strict In-Reply-To: References: <57057CF0.50604@oracle.com> <5706ADBE.10803@oracle.com> Message-ID: <570BF21F.9010603@oracle.com> Hi Jay, There was one thing I pointed out in the first review that got lost in the shuffle. When the validBits are not null you use isValid(i) to test the values, but that method does 3 things: - tests the index for validity, but we already know it is valid - tests validBits for null, but we already know it is not - calls validBits.testBit() - this is the only part we need For performance, I'd switch to just testing for the bits directly, as in: validBits.testBit(i) == cm.validBits.testBit(i) ...jim On 4/11/2016 12:46 AM, Jayathirth D V wrote: > Hi Jim, > > Thanks for the review. > I have made all recommended changes and created new subtask for JDK-6588409(https://bugs.openjdk.java.net/browse/JDK-8153943 ). > > Please review updated webrev: > http://cr.openjdk.java.net/~jdv/7107905/webrev.02/ > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Friday, April 08, 2016 12:28 AM > To: Jayathirth D V; Philip Race; Prasanta Sadhukhan > Cc: 2d-dev at openjdk.java.net > Subject: Re: Review Request for JDK-7107905: equals() method in IndexColorModel doesnt exist and it relies on ColorModel.equals() which is not strict > > Hi Jayathirth, > > This looks good. > > One thing to note for efficiency, "instanceof" also checks for null. It only returns true for non-null objects, so you don't need to explicitly test for null at the top of ICM.equals(). (Though, you should include a > test(s) in the unit test that verifies that no ICM returns true for > equals(null) to be sure.) You can see that CM.equals() is implemented this way. > > Also, for performance, ICM should include a quick "if (this == cm) return true;" check, like CM.equals(). I'd recommend: > > - first instanceof > - then == test > - then super.equals() > - finally, test equality of data fields > > More comments inline: > > On 4/7/16 6:46 AM, Jayathirth D V wrote: >> - Yes https://bugs.openjdk.java.net/browse/JDK-6588409 has mentioned the same thing. Can I create a subtask to address java.awt.image changes? > > That would be good. > >> For now, it would be good to implement hashCode() on ICM now that you are creating an equals() method for it. >> >> - I am not completely sure of what is the optimal way of adding hashCode() API so I took help from internet and IDE to make the changes. I am including super.hashCode() as it adds uniqueness to ICM. > > You did a great job. To save time in the future, you should all have copies of the latest version of "Effective Java" by Josh Bloch. It has a whole chapter on equals/hashCode. It's a very handy reference for all sorts of good programming practice for the Java language. > >> Also, ColorModel.hashCode() is a poor implementation. It doesn't use the paradigms recommended by Effective Java and looks like it produces poor hashes as a result (just in the first two elements of the hashCode I see a collision due to poor choice of numbers). >> - I think since we are not using Prime numbers and it might result in improper hash code. I have made similar changes to hashCode() of ColorModel. > > Looks great. > >> - In the same file itself we are following Java coding guidelines of having braces after if like "if () {". I am not completely sure of including "{" in new line. > > You are correct, that matching local code is a good consideration when considering code style. In this case, though, the indentation on these if statements is an example of what we're trying to avoid so it would be better to fix these particular statements (don't bother fixing the other lines in the file at this point, that can wait until we have to update other parts of the file, but don't propagate a bad style in new code). > In particular: > > Never do this: > > if (some complex test || > some additional tests || > some additional tests || > some additional tests || > some continuation of the test) { > the body of the code; > more body of the code; > } > Quick question - where does the body of the if statement start? Does your eye see it in a fraction of a second or do you have to search for it? > > That is the worst option for indenting an if statement with continuation lines. Never do that in new code. Do either of the following two versions: > > Java Code Style guidelines recommends indenting 8 spaces for conditional > continuations: > if (some complex test || > some additional tests || > some additional tests || > some additional tests || > some continuation of the test) { > the body of the code; > more body of the code; > } > > Jim's personal extension to the JCS recommends (and the 2D team historically tended to agree): > if (some complex test || > some additional tests || > some additional tests || > some additional tests || > some continuation of the test) > { > the body of the code; > more body of the code; > } > > Both of those immediately draw the eye to the separating point between the conditional and the body of the code. > >> I'd also add a few test cases that test that 2 separately and identically constructed ICM instances are equals() == true, tested with one of each of the constructors... >> >> - I have made changes to test case for verifying all constructors with same ICM. Also added verification for hashCode value. > > Unfortunately, some of your tests for hashCode make an invalid assumption. It is technically correct for the hash codes of 2 different objects to be the same regardless of whether they are equals() or not. > In fact, a perfectly valid implementation of hashCode() could return a constant number and it would be correct from the perspective of the equals/hashCode contract. (Such code, however, would not be optimal, but it would be valid/correct-to-spec.) The only condition that is required is that the hash codes match if the objects are equals(), but they are allowed to match if the objects are !equals(). In other words: > > boolean equals1 = (o1.equals(o2)); > boolean equals2 = (o2.equals(o1)); > boolean equalsH = (o1.hashCode() == o2.hashCode()); > > if (equals1 != equals2) that is an error - we should test this if (equals1 && !equalsH) that is an error - we should test this // No other conditions are an error, no other testing should be done > > In particular, the cases where you test the hash codes for being the same on objects that are not intended to be equals() should be deleted. > It would be good to also add tests to make sure that they are symmetrically equals (or symmetrically not equals) as well (i.e. > o1.equals(o2) matches o2.equals(o1) in all cases whether they match or not). > > Since it is less than optimal for hash codes to match if the objects are not equal, it might potentially be something to check on, but it should not generate a unit test failure and so should not appear in the unit test for this bug. Such a "code collision test" would be part of a performance test run periodically for QA, but we have never bothered with hashCode optimization unless a customer submits a complaint about the performance of some object in a hash map due to hash collisions (and I doubt that ColorModel objects are being used in such a manner), so I wouldn't recommend it here. > > ...jim > From prasanta.sadhukhan at oracle.com Tue Apr 12 11:16:37 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Tue, 12 Apr 2016 16:46:37 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8154057, , [macosx] getPrintJob doesn't throw NPE if Frame is null AND type is COMMON Message-ID: <570CD915.8060803@oracle.com> Hi All, Please review a fix for jdk9. Bug: https://bugs.openjdk.java.net/browse/JDK-8154057 webrev: http://cr.openjdk.java.net/~psadhukhan/8154057/webrev.00/ As per spec, Toolkit.getPrintJob() should throw NPE if null frame object is passed to it. But on macos, it seems getPrintJob() does not check for null frame and show the print dialog. Fix is to check for null frame which is same as what we do in windows (WToolkit) and linux (XToolkit). Regards Prasanta From jayathirth.d.v at oracle.com Tue Apr 12 11:36:25 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 12 Apr 2016 04:36:25 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: equals() method in IndexColorModel doesnt exist and it relies on ColorModel.equals() which is not strict In-Reply-To: <570BF21F.9010603@oracle.com> References: <57057CF0.50604@oracle.com> <5706ADBE.10803@oracle.com> <570BF21F.9010603@oracle.com> Message-ID: <34a9ed1b-bf8a-43fb-9032-65c9c47a9c11@default> Hi Jim, I have updated the webrev to include changes to check testBit() instead of using isValid(). Please find the updated webrev for review: http://cr.openjdk.java.net/~jdv/7107905/webrev.03/ Thanks, Jay -----Original Message----- From: Jim Graham Sent: Tuesday, April 12, 2016 12:21 AM To: Jayathirth D V; Philip Race; Prasanta Sadhukhan Cc: 2d-dev at openjdk.java.net Subject: Re: Review Request for JDK-7107905: equals() method in IndexColorModel doesnt exist and it relies on ColorModel.equals() which is not strict Hi Jay, There was one thing I pointed out in the first review that got lost in the shuffle. When the validBits are not null you use isValid(i) to test the values, but that method does 3 things: - tests the index for validity, but we already know it is valid - tests validBits for null, but we already know it is not - calls validBits.testBit() - this is the only part we need For performance, I'd switch to just testing for the bits directly, as in: validBits.testBit(i) == cm.validBits.testBit(i) ...jim On 4/11/2016 12:46 AM, Jayathirth D V wrote: > Hi Jim, > > Thanks for the review. > I have made all recommended changes and created new subtask for JDK-6588409(https://bugs.openjdk.java.net/browse/JDK-8153943 ). > > Please review updated webrev: > http://cr.openjdk.java.net/~jdv/7107905/webrev.02/ > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Friday, April 08, 2016 12:28 AM > To: Jayathirth D V; Philip Race; Prasanta Sadhukhan > Cc: 2d-dev at openjdk.java.net > Subject: Re: Review Request for JDK-7107905: equals() method in > IndexColorModel doesnt exist and it relies on ColorModel.equals() > which is not strict > > Hi Jayathirth, > > This looks good. > > One thing to note for efficiency, "instanceof" also checks for null. > It only returns true for non-null objects, so you don't need to > explicitly test for null at the top of ICM.equals(). (Though, you > should include a > test(s) in the unit test that verifies that no ICM returns true for > equals(null) to be sure.) You can see that CM.equals() is implemented this way. > > Also, for performance, ICM should include a quick "if (this == cm) return true;" check, like CM.equals(). I'd recommend: > > - first instanceof > - then == test > - then super.equals() > - finally, test equality of data fields > > More comments inline: > > On 4/7/16 6:46 AM, Jayathirth D V wrote: >> - Yes https://bugs.openjdk.java.net/browse/JDK-6588409 has mentioned the same thing. Can I create a subtask to address java.awt.image changes? > > That would be good. > >> For now, it would be good to implement hashCode() on ICM now that you are creating an equals() method for it. >> >> - I am not completely sure of what is the optimal way of adding hashCode() API so I took help from internet and IDE to make the changes. I am including super.hashCode() as it adds uniqueness to ICM. > > You did a great job. To save time in the future, you should all have copies of the latest version of "Effective Java" by Josh Bloch. It has a whole chapter on equals/hashCode. It's a very handy reference for all sorts of good programming practice for the Java language. > >> Also, ColorModel.hashCode() is a poor implementation. It doesn't use the paradigms recommended by Effective Java and looks like it produces poor hashes as a result (just in the first two elements of the hashCode I see a collision due to poor choice of numbers). >> - I think since we are not using Prime numbers and it might result in improper hash code. I have made similar changes to hashCode() of ColorModel. > > Looks great. > >> - In the same file itself we are following Java coding guidelines of having braces after if like "if () {". I am not completely sure of including "{" in new line. > > You are correct, that matching local code is a good consideration when considering code style. In this case, though, the indentation on these if statements is an example of what we're trying to avoid so it would be better to fix these particular statements (don't bother fixing the other lines in the file at this point, that can wait until we have to update other parts of the file, but don't propagate a bad style in new code). > In particular: > > Never do this: > > if (some complex test || > some additional tests || > some additional tests || > some additional tests || > some continuation of the test) { > the body of the code; > more body of the code; > } > Quick question - where does the body of the if statement start? Does your eye see it in a fraction of a second or do you have to search for it? > > That is the worst option for indenting an if statement with continuation lines. Never do that in new code. Do either of the following two versions: > > Java Code Style guidelines recommends indenting 8 spaces for > conditional > continuations: > if (some complex test || > some additional tests || > some additional tests || > some additional tests || > some continuation of the test) { > the body of the code; > more body of the code; > } > > Jim's personal extension to the JCS recommends (and the 2D team historically tended to agree): > if (some complex test || > some additional tests || > some additional tests || > some additional tests || > some continuation of the test) > { > the body of the code; > more body of the code; > } > > Both of those immediately draw the eye to the separating point between the conditional and the body of the code. > >> I'd also add a few test cases that test that 2 separately and identically constructed ICM instances are equals() == true, tested with one of each of the constructors... >> >> - I have made changes to test case for verifying all constructors with same ICM. Also added verification for hashCode value. > > Unfortunately, some of your tests for hashCode make an invalid assumption. It is technically correct for the hash codes of 2 different objects to be the same regardless of whether they are equals() or not. > In fact, a perfectly valid implementation of hashCode() could return a constant number and it would be correct from the perspective of the equals/hashCode contract. (Such code, however, would not be optimal, but it would be valid/correct-to-spec.) The only condition that is required is that the hash codes match if the objects are equals(), but they are allowed to match if the objects are !equals(). In other words: > > boolean equals1 = (o1.equals(o2)); > boolean equals2 = (o2.equals(o1)); > boolean equalsH = (o1.hashCode() == o2.hashCode()); > > if (equals1 != equals2) that is an error - we should test this if > (equals1 && !equalsH) that is an error - we should test this // No > other conditions are an error, no other testing should be done > > In particular, the cases where you test the hash codes for being the same on objects that are not intended to be equals() should be deleted. > It would be good to also add tests to make sure that they are symmetrically equals (or symmetrically not equals) as well (i.e. > o1.equals(o2) matches o2.equals(o1) in all cases whether they match or not). > > Since it is less than optimal for hash codes to match if the objects are not equal, it might potentially be something to check on, but it should not generate a unit test failure and so should not appear in the unit test for this bug. Such a "code collision test" would be part of a performance test run periodically for QA, but we have never bothered with hashCode optimization unless a customer submits a complaint about the performance of some object in a hash map due to hash collisions (and I doubt that ColorModel objects are being used in such a manner), so I wouldn't recommend it here. > > ...jim > From Sergey.Bylokhov at oracle.com Tue Apr 12 13:34:22 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 12 Apr 2016 16:34:22 +0300 Subject: [OpenJDK 2D-Dev] [PATCH] JDK-8146035: Windows - With LCD antialiasing, some glyphs are not rendered correctly In-Reply-To: <570BAC3E.2070008@oracle.com> References: <570BAC3E.2070008@oracle.com> Message-ID: <570CF95E.6090603@oracle.com> Looks fine. On 11.04.16 16:53, Alexey Ivanov wrote: > Hello Dmitry, > > Thank you very much for your patch. > > The fix looks good to me. > > I will sponsor integrating the fix into the code base as soon as code > review is complete. > > Thanks, > Alexey > > On 07.04.2016 15:26, Dmitry Batrak wrote: >> Hello, >> >> I'd like to propose a fix for JDK-8146035. I am not a committer, >> so I hope someone can sponsor this fix. >> I work at Jetbrains, which has signed a company-level contributor >> agreement, >> so, from a legal perspective, I believe, there are no obstacles. >> >> My investigation shows that the issue is caused by incorrect >> determination >> of bitmap size, prepared for glyph rendering, so only part of glyph >> becomes visible due to cropping. This seems to happen because >> compatible bitmap is not selected into memory device context (DC) >> before calling GetTextMetrics. Documentation for CreateCompatibleDC call >> (https://msdn.microsoft.com/en-us/library/windows/desktop/dd183489%28v=vs.85%29.aspx) >> >> says compatible bitmap needs to be selected into DC before any drawing >> operation. >> Even though GetTextMetrics is not a drawing operation, it turns out >> to be affected by selected bitmap's type too (by default a monochrome >> bitmap >> is selected in a memory DC). This behaviour was also mentioned in the >> following >> MSDN blog post comment: >> https://blogs.msdn.microsoft.com/oldnewthing/20060614-00/?p=30873#comment-392143 >> >> >> The proposed fix is to select a temporary 1x1 compatible bitmap >> into memory DC before GetTextMetrics call. >> Here's webrev link - http://adm-12504.intellij.net/ >> I didn't create a test case, as it would require a specific font file >> (I couldn't reproduce the issue for fonts bundled with Windows). >> >> Best regards, >> Dmitry Batrak > -- Best regards, Sergey. From philip.race at oracle.com Tue Apr 12 17:02:31 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 12 Apr 2016 10:02:31 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8154057, , [macosx] getPrintJob doesn't throw NPE if Frame is null AND type is COMMON In-Reply-To: <570CD915.8060803@oracle.com> References: <570CD915.8060803@oracle.com> Message-ID: <570D2A27.9060809@oracle.com> please resubmit this review request with the bug id in the subject line. -phil. On 04/12/2016 04:16 AM, prasanta sadhukhan wrote: > Hi All, > > Please review a fix for jdk9. > Bug: https://bugs.openjdk.java.net/browse/JDK-8154057 > webrev: http://cr.openjdk.java.net/~psadhukhan/8154057/webrev.00/ > > As per spec, Toolkit.getPrintJob() should throw NPE if null frame > object is passed to it. > But on macos, it seems getPrintJob() does not check for null frame and > show the print dialog. > > Fix is to check for null frame which is same as what we do in windows > (WToolkit) and linux (XToolkit). > > Regards > Prasanta From philip.race at oracle.com Tue Apr 12 17:03:34 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 12 Apr 2016 10:03:34 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8154057, , [macosx] getPrintJob doesn't throw NPE if Frame is null AND type is COMMON In-Reply-To: <570D2A27.9060809@oracle.com> References: <570CD915.8060803@oracle.com> <570D2A27.9060809@oracle.com> Message-ID: <570D2A66.2070201@oracle.com> Sorry not this one I meant a different review :http://mail.openjdk.java.net/pipermail/2d-dev/2016-April/006670.html -phil On 04/12/2016 10:02 AM, Phil Race wrote: > please resubmit this review request with the bug id in the subject line. > > -phil. > > On 04/12/2016 04:16 AM, prasanta sadhukhan wrote: >> Hi All, >> >> Please review a fix for jdk9. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154057 >> webrev: http://cr.openjdk.java.net/~psadhukhan/8154057/webrev.00/ >> >> As per spec, Toolkit.getPrintJob() should throw NPE if null frame >> object is passed to it. >> But on macos, it seems getPrintJob() does not check for null frame >> and show the print dialog. >> >> Fix is to check for null frame which is same as what we do in windows >> (WToolkit) and linux (XToolkit). >> >> Regards >> Prasanta > From philip.race at oracle.com Tue Apr 12 17:13:41 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 12 Apr 2016 10:13:41 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8154057, , [macosx] getPrintJob doesn't throw NPE if Frame is null AND type is COMMON In-Reply-To: <570CD915.8060803@oracle.com> References: <570CD915.8060803@oracle.com> Message-ID: <570D2CC5.5030303@oracle.com> hmm .. if it does not throw NPE when the dialog type is common that could mean that the code is not referencing the frame as a modal parent /owner in that case which could be another bug. Did you check into how this is used relative to other platforms ? -phil. On 04/12/2016 04:16 AM, prasanta sadhukhan wrote: > Hi All, > > Please review a fix for jdk9. > Bug: https://bugs.openjdk.java.net/browse/JDK-8154057 > webrev: http://cr.openjdk.java.net/~psadhukhan/8154057/webrev.00/ > > As per spec, Toolkit.getPrintJob() should throw NPE if null frame > object is passed to it. > But on macos, it seems getPrintJob() does not check for null frame and > show the print dialog. > > Fix is to check for null frame which is same as what we do in windows > (WToolkit) and linux (XToolkit). > > Regards > Prasanta From philip.race at oracle.com Tue Apr 12 17:22:41 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 12 Apr 2016 10:22:41 -0700 Subject: [OpenJDK 2D-Dev] [PATCH] JDK-8146035: Windows - With LCD antialiasing, some glyphs are not rendered correctly In-Reply-To: References: Message-ID: <570D2EE1.1040809@oracle.com> Alexey didn't say this but he already proposed exactly this fix himself in a private email exchange, +1, although I am not sure we can legally pull down the patch from that (any) website. Please resubmit it as a diff in the email. Or Alexey could just push it as his own :-) -phil. On 04/07/2016 05:26 AM, Dmitry Batrak wrote: > Hello, > > I'd like to propose a fix for JDK-8146035. I am not a committer, > so I hope someone can sponsor this fix. > I work at Jetbrains, which has signed a company-level contributor > agreement, > so, from a legal perspective, I believe, there are no obstacles. > > My investigation shows that the issue is caused by incorrect > determination > of bitmap size, prepared for glyph rendering, so only part of glyph > becomes visible due to cropping. This seems to happen because > compatible bitmap is not selected into memory device context (DC) > before calling GetTextMetrics. Documentation for CreateCompatibleDC call > (https://msdn.microsoft.com/en-us/library/windows/desktop/dd183489%28v=vs.85%29.aspx) > > says compatible bitmap needs to be selected into DC before any drawing > operation. > Even though GetTextMetrics is not a drawing operation, it turns out > to be affected by selected bitmap's type too (by default a monochrome > bitmap > is selected in a memory DC). This behaviour was also mentioned in the > following > MSDN blog post comment: > https://blogs.msdn.microsoft.com/oldnewthing/20060614-00/?p=30873#comment-392143 > > The proposed fix is to select a temporary 1x1 compatible bitmap > into memory DC before GetTextMetrics call. > Here's webrev link - http://adm-12504.intellij.net/ > I didn't create a test case, as it would require a specific font file > (I couldn't reproduce the issue for fonts bundled with Windows). > > Best regards, > Dmitry Batrak From dmitry.batrak at jetbrains.com Tue Apr 12 17:43:52 2016 From: dmitry.batrak at jetbrains.com (Dmitry Batrak) Date: Tue, 12 Apr 2016 20:43:52 +0300 Subject: [OpenJDK 2D-Dev] [PATCH] JDK-8146035: Windows - With LCD antialiasing, some glyphs are not rendered correctly Message-ID: Repeating the patch inline: === patch start === --- old/src/java.desktop/windows/native/libfontmanager/lcdglyph.c 2016-04-07 13:10:01.507608685 +0300 +++ new/src/java.desktop/windows/native/libfontmanager/lcdglyph.c 2016-04-07 13:10:01.391608686 +0300 @@ -157,6 +157,9 @@ if (hBitmap != 0) { \ DeleteObject(hBitmap); \ } \ + if (tmpBitmap != 0) { \ + DeleteObject(tmpBitmap); \ + } \ if (dibImage != NULL) { \ free(dibImage); \ } \ @@ -196,6 +199,7 @@ int bmWidth, bmHeight; int x, y; HBITMAP hBitmap = NULL, hOrigBM; + HBITMAP tmpBitmap = NULL; int gamma, orient; HWND hWnd = NULL; @@ -250,6 +254,12 @@ } oldFont = SelectObject(hMemoryDC, hFont); + tmpBitmap = CreateCompatibleBitmap(hDesktopDC, 1, 1); + if (tmpBitmap == NULL) { + FREE_AND_RETURN; + } + hOrigBM = (HBITMAP)SelectObject(hMemoryDC, tmpBitmap); + memset(&textMetric, 0, sizeof(TEXTMETRIC)); err = GetTextMetrics(hMemoryDC, &textMetric); if (err == 0) { @@ -334,7 +344,7 @@ if (hBitmap == NULL) { FREE_AND_RETURN; } - hOrigBM = (HBITMAP)SelectObject(hMemoryDC, hBitmap); + SelectObject(hMemoryDC, hBitmap); /* Fill in black */ rect.left = 0; @@ -478,6 +488,7 @@ ReleaseDC(hWnd, hDesktopDC); DeleteObject(hMemoryDC); DeleteObject(hBitmap); + DeleteObject(tmpBitmap); return ptr_to_jlong(glyphInfo); } === patch end === Thanks, Dmitry On Tue, Apr 12, 2016 at 8:22 PM, Phil Race wrote: > Alexey didn't say this but he already proposed exactly this fix himself > in a private email exchange, > > +1, although I am not sure we can legally pull down the patch from that > (any) website. > Please resubmit it as a diff in the email. > > Or Alexey could just push it as his own :-) > > -phil. > > On 04/07/2016 05:26 AM, Dmitry Batrak wrote: > >> Hello, >> >> I'd like to propose a fix for JDK-8146035. I am not a committer, >> so I hope someone can sponsor this fix. >> I work at Jetbrains, which has signed a company-level contributor >> agreement, >> so, from a legal perspective, I believe, there are no obstacles. >> >> My investigation shows that the issue is caused by incorrect determination >> of bitmap size, prepared for glyph rendering, so only part of glyph >> becomes visible due to cropping. This seems to happen because >> compatible bitmap is not selected into memory device context (DC) >> before calling GetTextMetrics. Documentation for CreateCompatibleDC call >> ( >> https://msdn.microsoft.com/en-us/library/windows/desktop/dd183489%28v=vs.85%29.aspx) >> >> says compatible bitmap needs to be selected into DC before any drawing >> operation. >> Even though GetTextMetrics is not a drawing operation, it turns out >> to be affected by selected bitmap's type too (by default a monochrome >> bitmap >> is selected in a memory DC). This behaviour was also mentioned in the >> following >> MSDN blog post comment: >> >> https://blogs.msdn.microsoft.com/oldnewthing/20060614-00/?p=30873#comment-392143 >> >> The proposed fix is to select a temporary 1x1 compatible bitmap >> into memory DC before GetTextMetrics call. >> Here's webrev link - http://adm-12504.intellij.net/ >> I didn't create a test case, as it would require a specific font file >> (I couldn't reproduce the issue for fonts bundled with Windows). >> >> Best regards, >> Dmitry Batrak >> > > -- Dmitry Batrak Senior Software Developer JetBrains http://www.jetbrains.com The Drive to Develop -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Tue Apr 12 19:45:07 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 12 Apr 2016 12:45:07 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: equals() method in IndexColorModel doesnt exist and it relies on ColorModel.equals() which is not strict In-Reply-To: <34a9ed1b-bf8a-43fb-9032-65c9c47a9c11@default> References: <57057CF0.50604@oracle.com> <5706ADBE.10803@oracle.com> <570BF21F.9010603@oracle.com> <34a9ed1b-bf8a-43fb-9032-65c9c47a9c11@default> Message-ID: <570D5043.8000405@oracle.com> Hi Jay, Looks great! Good to go... ...jim On 4/12/2016 4:36 AM, Jayathirth D V wrote: > Hi Jim, > > I have updated the webrev to include changes to check testBit() instead of using isValid(). > Please find the updated webrev for review: > http://cr.openjdk.java.net/~jdv/7107905/webrev.03/ > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Tuesday, April 12, 2016 12:21 AM > To: Jayathirth D V; Philip Race; Prasanta Sadhukhan > Cc: 2d-dev at openjdk.java.net > Subject: Re: Review Request for JDK-7107905: equals() method in IndexColorModel doesnt exist and it relies on ColorModel.equals() which is not strict > > Hi Jay, > > There was one thing I pointed out in the first review that got lost in the shuffle. When the validBits are not null you use isValid(i) to test the values, but that method does 3 things: > > - tests the index for validity, but we already know it is valid > - tests validBits for null, but we already know it is not > - calls validBits.testBit() - this is the only part we need > > For performance, I'd switch to just testing for the bits directly, as in: > > validBits.testBit(i) == cm.validBits.testBit(i) > > ...jim > > On 4/11/2016 12:46 AM, Jayathirth D V wrote: >> Hi Jim, >> >> Thanks for the review. >> I have made all recommended changes and created new subtask for JDK-6588409(https://bugs.openjdk.java.net/browse/JDK-8153943 ). >> >> Please review updated webrev: >> http://cr.openjdk.java.net/~jdv/7107905/webrev.02/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Friday, April 08, 2016 12:28 AM >> To: Jayathirth D V; Philip Race; Prasanta Sadhukhan >> Cc: 2d-dev at openjdk.java.net >> Subject: Re: Review Request for JDK-7107905: equals() method in >> IndexColorModel doesnt exist and it relies on ColorModel.equals() >> which is not strict >> >> Hi Jayathirth, >> >> This looks good. >> >> One thing to note for efficiency, "instanceof" also checks for null. >> It only returns true for non-null objects, so you don't need to >> explicitly test for null at the top of ICM.equals(). (Though, you >> should include a >> test(s) in the unit test that verifies that no ICM returns true for >> equals(null) to be sure.) You can see that CM.equals() is implemented this way. >> >> Also, for performance, ICM should include a quick "if (this == cm) return true;" check, like CM.equals(). I'd recommend: >> >> - first instanceof >> - then == test >> - then super.equals() >> - finally, test equality of data fields >> >> More comments inline: >> >> On 4/7/16 6:46 AM, Jayathirth D V wrote: >>> - Yes https://bugs.openjdk.java.net/browse/JDK-6588409 has mentioned the same thing. Can I create a subtask to address java.awt.image changes? >> >> That would be good. >> >>> For now, it would be good to implement hashCode() on ICM now that you are creating an equals() method for it. >>> >>> - I am not completely sure of what is the optimal way of adding hashCode() API so I took help from internet and IDE to make the changes. I am including super.hashCode() as it adds uniqueness to ICM. >> >> You did a great job. To save time in the future, you should all have copies of the latest version of "Effective Java" by Josh Bloch. It has a whole chapter on equals/hashCode. It's a very handy reference for all sorts of good programming practice for the Java language. >> >>> Also, ColorModel.hashCode() is a poor implementation. It doesn't use the paradigms recommended by Effective Java and looks like it produces poor hashes as a result (just in the first two elements of the hashCode I see a collision due to poor choice of numbers). >>> - I think since we are not using Prime numbers and it might result in improper hash code. I have made similar changes to hashCode() of ColorModel. >> >> Looks great. >> >>> - In the same file itself we are following Java coding guidelines of having braces after if like "if () {". I am not completely sure of including "{" in new line. >> >> You are correct, that matching local code is a good consideration when considering code style. In this case, though, the indentation on these if statements is an example of what we're trying to avoid so it would be better to fix these particular statements (don't bother fixing the other lines in the file at this point, that can wait until we have to update other parts of the file, but don't propagate a bad style in new code). >> In particular: >> >> Never do this: >> >> if (some complex test || >> some additional tests || >> some additional tests || >> some additional tests || >> some continuation of the test) { >> the body of the code; >> more body of the code; >> } >> Quick question - where does the body of the if statement start? Does your eye see it in a fraction of a second or do you have to search for it? >> >> That is the worst option for indenting an if statement with continuation lines. Never do that in new code. Do either of the following two versions: >> >> Java Code Style guidelines recommends indenting 8 spaces for >> conditional >> continuations: >> if (some complex test || >> some additional tests || >> some additional tests || >> some additional tests || >> some continuation of the test) { >> the body of the code; >> more body of the code; >> } >> >> Jim's personal extension to the JCS recommends (and the 2D team historically tended to agree): >> if (some complex test || >> some additional tests || >> some additional tests || >> some additional tests || >> some continuation of the test) >> { >> the body of the code; >> more body of the code; >> } >> >> Both of those immediately draw the eye to the separating point between the conditional and the body of the code. >> >>> I'd also add a few test cases that test that 2 separately and identically constructed ICM instances are equals() == true, tested with one of each of the constructors... >>> >>> - I have made changes to test case for verifying all constructors with same ICM. Also added verification for hashCode value. >> >> Unfortunately, some of your tests for hashCode make an invalid assumption. It is technically correct for the hash codes of 2 different objects to be the same regardless of whether they are equals() or not. >> In fact, a perfectly valid implementation of hashCode() could return a constant number and it would be correct from the perspective of the equals/hashCode contract. (Such code, however, would not be optimal, but it would be valid/correct-to-spec.) The only condition that is required is that the hash codes match if the objects are equals(), but they are allowed to match if the objects are !equals(). In other words: >> >> boolean equals1 = (o1.equals(o2)); >> boolean equals2 = (o2.equals(o1)); >> boolean equalsH = (o1.hashCode() == o2.hashCode()); >> >> if (equals1 != equals2) that is an error - we should test this if >> (equals1 && !equalsH) that is an error - we should test this // No >> other conditions are an error, no other testing should be done >> >> In particular, the cases where you test the hash codes for being the same on objects that are not intended to be equals() should be deleted. >> It would be good to also add tests to make sure that they are symmetrically equals (or symmetrically not equals) as well (i.e. >> o1.equals(o2) matches o2.equals(o1) in all cases whether they match or not). >> >> Since it is less than optimal for hash codes to match if the objects are not equal, it might potentially be something to check on, but it should not generate a unit test failure and so should not appear in the unit test for this bug. Such a "code collision test" would be part of a performance test run periodically for QA, but we have never bothered with hashCode optimization unless a customer submits a complaint about the performance of some object in a hash map due to hash collisions (and I doubt that ColorModel objects are being used in such a manner), so I wouldn't recommend it here. >> >> ...jim >> From philip.race at oracle.com Tue Apr 12 19:59:03 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 12 Apr 2016 12:59:03 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: equals() method in IndexColorModel doesnt exist and it relies on ColorModel.equals() which is not strict In-Reply-To: <570D5043.8000405@oracle.com> References: <57057CF0.50604@oracle.com> <5706ADBE.10803@oracle.com> <570BF21F.9010603@oracle.com> <34a9ed1b-bf8a-43fb-9032-65c9c47a9c11@default> <570D5043.8000405@oracle.com> Message-ID: <570D5387.2070303@oracle.com> I am catching up on email here, and "+1" but a couple of comments - ColorModel.hashCode() doesn't say a lot about how it is calculated so it seems safe to change it. Sometimes it makes performance sense to cache the calculated value but in this case there is probably no big win from doing so since it is not likely a commonly used case. Also equals looks unavoidably expensive. - I suppose that we can't learn anything useful from "cm.validbits.equals(this.validbits)" since only the bits up to "map_size" should be tested ? - As Sergey noted, do file a CCC - this has been general practice when over-riding equals or hashCode. I am not sure if you will get asked there to say anything about what is meant by "equals()" or or how "hashCode()" is calculated. You should get that CCC approved before committing. -phil. On 04/12/2016 12:45 PM, Jim Graham wrote: > Hi Jay, > > Looks great! Good to go... > > ...jim > > On 4/12/2016 4:36 AM, Jayathirth D V wrote: >> Hi Jim, >> >> I have updated the webrev to include changes to check testBit() >> instead of using isValid(). >> Please find the updated webrev for review: >> http://cr.openjdk.java.net/~jdv/7107905/webrev.03/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Tuesday, April 12, 2016 12:21 AM >> To: Jayathirth D V; Philip Race; Prasanta Sadhukhan >> Cc: 2d-dev at openjdk.java.net >> Subject: Re: Review Request for JDK-7107905: equals() method in >> IndexColorModel doesnt exist and it relies on ColorModel.equals() >> which is not strict >> >> Hi Jay, >> >> There was one thing I pointed out in the first review that got lost >> in the shuffle. When the validBits are not null you use isValid(i) >> to test the values, but that method does 3 things: >> >> - tests the index for validity, but we already know it is valid >> - tests validBits for null, but we already know it is not >> - calls validBits.testBit() - this is the only part we need >> >> For performance, I'd switch to just testing for the bits directly, as >> in: >> >> validBits.testBit(i) == cm.validBits.testBit(i) >> >> ...jim >> >> On 4/11/2016 12:46 AM, Jayathirth D V wrote: >>> Hi Jim, >>> >>> Thanks for the review. >>> I have made all recommended changes and created new subtask for >>> JDK-6588409(https://bugs.openjdk.java.net/browse/JDK-8153943 ). >>> >>> Please review updated webrev: >>> http://cr.openjdk.java.net/~jdv/7107905/webrev.02/ >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Jim Graham >>> Sent: Friday, April 08, 2016 12:28 AM >>> To: Jayathirth D V; Philip Race; Prasanta Sadhukhan >>> Cc: 2d-dev at openjdk.java.net >>> Subject: Re: Review Request for JDK-7107905: equals() method in >>> IndexColorModel doesnt exist and it relies on ColorModel.equals() >>> which is not strict >>> >>> Hi Jayathirth, >>> >>> This looks good. >>> >>> One thing to note for efficiency, "instanceof" also checks for null. >>> It only returns true for non-null objects, so you don't need to >>> explicitly test for null at the top of ICM.equals(). (Though, you >>> should include a >>> test(s) in the unit test that verifies that no ICM returns true for >>> equals(null) to be sure.) You can see that CM.equals() is >>> implemented this way. >>> >>> Also, for performance, ICM should include a quick "if (this == cm) >>> return true;" check, like CM.equals(). I'd recommend: >>> >>> - first instanceof >>> - then == test >>> - then super.equals() >>> - finally, test equality of data fields >>> >>> More comments inline: >>> >>> On 4/7/16 6:46 AM, Jayathirth D V wrote: >>>> - Yes https://bugs.openjdk.java.net/browse/JDK-6588409 has >>>> mentioned the same thing. Can I create a subtask to address >>>> java.awt.image changes? >>> >>> That would be good. >>> >>>> For now, it would be good to implement hashCode() on ICM now that >>>> you are creating an equals() method for it. >>>> >>>> - I am not completely sure of what is the optimal way of adding >>>> hashCode() API so I took help from internet and IDE to make the >>>> changes. I am including super.hashCode() as it adds uniqueness to ICM. >>> >>> You did a great job. To save time in the future, you should all >>> have copies of the latest version of "Effective Java" by Josh >>> Bloch. It has a whole chapter on equals/hashCode. It's a very >>> handy reference for all sorts of good programming practice for the >>> Java language. >>> >>>> Also, ColorModel.hashCode() is a poor implementation. It doesn't >>>> use the paradigms recommended by Effective Java and looks like it >>>> produces poor hashes as a result (just in the first two elements of >>>> the hashCode I see a collision due to poor choice of numbers). >>>> - I think since we are not using Prime numbers and it might >>>> result in improper hash code. I have made similar changes to >>>> hashCode() of ColorModel. >>> >>> Looks great. >>> >>>> - In the same file itself we are following Java coding >>>> guidelines of having braces after if like "if () {". I am not >>>> completely sure of including "{" in new line. >>> >>> You are correct, that matching local code is a good consideration >>> when considering code style. In this case, though, the indentation >>> on these if statements is an example of what we're trying to avoid >>> so it would be better to fix these particular statements (don't >>> bother fixing the other lines in the file at this point, that can >>> wait until we have to update other parts of the file, but don't >>> propagate a bad style in new code). >>> In particular: >>> >>> Never do this: >>> >>> if (some complex test || >>> some additional tests || >>> some additional tests || >>> some additional tests || >>> some continuation of the test) { >>> the body of the code; >>> more body of the code; >>> } >>> Quick question - where does the body of the if statement start? >>> Does your eye see it in a fraction of a second or do you have to >>> search for it? >>> >>> That is the worst option for indenting an if statement with >>> continuation lines. Never do that in new code. Do either of the >>> following two versions: >>> >>> Java Code Style guidelines recommends indenting 8 spaces for >>> conditional >>> continuations: >>> if (some complex test || >>> some additional tests || >>> some additional tests || >>> some additional tests || >>> some continuation of the test) { >>> the body of the code; >>> more body of the code; >>> } >>> >>> Jim's personal extension to the JCS recommends (and the 2D team >>> historically tended to agree): >>> if (some complex test || >>> some additional tests || >>> some additional tests || >>> some additional tests || >>> some continuation of the test) >>> { >>> the body of the code; >>> more body of the code; >>> } >>> >>> Both of those immediately draw the eye to the separating point >>> between the conditional and the body of the code. >>> >>>> I'd also add a few test cases that test that 2 separately and >>>> identically constructed ICM instances are equals() == true, tested >>>> with one of each of the constructors... >>>> >>>> - I have made changes to test case for verifying all >>>> constructors with same ICM. Also added verification for hashCode >>>> value. >>> >>> Unfortunately, some of your tests for hashCode make an invalid >>> assumption. It is technically correct for the hash codes of 2 >>> different objects to be the same regardless of whether they are >>> equals() or not. >>> In fact, a perfectly valid implementation of hashCode() could return >>> a constant number and it would be correct from the perspective of >>> the equals/hashCode contract. (Such code, however, would not be >>> optimal, but it would be valid/correct-to-spec.) The only condition >>> that is required is that the hash codes match if the objects are >>> equals(), but they are allowed to match if the objects are >>> !equals(). In other words: >>> >>> boolean equals1 = (o1.equals(o2)); >>> boolean equals2 = (o2.equals(o1)); >>> boolean equalsH = (o1.hashCode() == o2.hashCode()); >>> >>> if (equals1 != equals2) that is an error - we should test this if >>> (equals1 && !equalsH) that is an error - we should test this // No >>> other conditions are an error, no other testing should be done >>> >>> In particular, the cases where you test the hash codes for being the >>> same on objects that are not intended to be equals() should be deleted. >>> It would be good to also add tests to make sure that they are >>> symmetrically equals (or symmetrically not equals) as well (i.e. >>> o1.equals(o2) matches o2.equals(o1) in all cases whether they match >>> or not). >>> >>> Since it is less than optimal for hash codes to match if the objects >>> are not equal, it might potentially be something to check on, but it >>> should not generate a unit test failure and so should not appear in >>> the unit test for this bug. Such a "code collision test" would be >>> part of a performance test run periodically for QA, but we have >>> never bothered with hashCode optimization unless a customer submits >>> a complaint about the performance of some object in a hash map due >>> to hash collisions (and I doubt that ColorModel objects are being >>> used in such a manner), so I wouldn't recommend it here. >>> >>> ...jim >>> From james.graham at oracle.com Tue Apr 12 20:19:05 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 12 Apr 2016 13:19:05 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: equals() method in IndexColorModel doesnt exist and it relies on ColorModel.equals() which is not strict In-Reply-To: <570D5387.2070303@oracle.com> References: <57057CF0.50604@oracle.com> <5706ADBE.10803@oracle.com> <570BF21F.9010603@oracle.com> <34a9ed1b-bf8a-43fb-9032-65c9c47a9c11@default> <570D5043.8000405@oracle.com> <570D5387.2070303@oracle.com> Message-ID: <570D5839.3000402@oracle.com> On 4/12/2016 12:59 PM, Phil Race wrote: > I am catching up on email here, and "+1" but a couple of comments > > - I suppose that we can't learn anything useful from > "cm.validbits.equals(this.validbits)" > since only the bits up to "map_size" should be tested ? Perhaps if the constructors truncated it at the required size we could use equals(). I'm not sure that is worthwhile, given how rarely it is used. I think it is used by default on some platforms (Windows? X11?) if they have an 8-bit screen with a sparse colormap, but that should be pretty rare these days since nearly everything we use should be 24-bits these days. I have a better idea, though. But, since the field is assigned the original supplied value from the constructor, then the likelihood that a non-null value will be == identical to another colormap is likely larger than normal, perhaps we can make it faster by checking for == and then slipping into the faster test that simply compares the rgb[] values? Something like: if (validBits == cm.validBits) { compare rgb[] entries } else if (validBits == null || cm.validBits == null) { return false; } else { bigger loop that compares rgb[] and validBits() values } Note that if the two fields are == and non-null, then the entries in the rgb[] array for indices that are non-valid should have zeros in them because of the way that the colormap data is copied internally, so the rgb[] comparisons should be valid without checking the associated bits. Potentially we could also use: boolean fulltest; if (validBits == cm.validBits) { fulltest = false; } else if (validBits == null || cm.validBits == null) { return false; } else if (validBits.equals(cm.validBits)) { fulltest = false; } else { fulltest = true; } if (fulltest) { compare both rgb[] and validBits() values } else { compare rgb[] entries alone } In this case we are using validBits.equals() to reduce the amount of testing in the loop, but are not basing a conclusion on whether the result of the comparison will be true or false. equals() implies we don't need to compare its values bit by bit, but !equals() doesn't mean that the ICMs aren't equals()... ...jim From philip.race at oracle.com Tue Apr 12 20:18:42 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 12 Apr 2016 13:18:42 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: equals() method in IndexColorModel doesnt exist and it relies on ColorModel.equals() which is not strict In-Reply-To: <570D5839.3000402@oracle.com> References: <57057CF0.50604@oracle.com> <5706ADBE.10803@oracle.com> <570BF21F.9010603@oracle.com> <34a9ed1b-bf8a-43fb-9032-65c9c47a9c11@default> <570D5043.8000405@oracle.com> <570D5387.2070303@oracle.com> <570D5839.3000402@oracle.com> Message-ID: <570D5822.40705@oracle.com> Seems like this would work/help. -phil. On 04/12/2016 01:19 PM, Jim Graham wrote: > > > On 4/12/2016 12:59 PM, Phil Race wrote: >> I am catching up on email here, and "+1" but a couple of comments >> >> - I suppose that we can't learn anything useful from >> "cm.validbits.equals(this.validbits)" >> since only the bits up to "map_size" should be tested ? > > Perhaps if the constructors truncated it at the required size we could > use equals(). I'm not sure that is worthwhile, given how rarely it is > used. I think it is used by default on some platforms (Windows? > X11?) if they have an 8-bit screen with a sparse colormap, but that > should be pretty rare these days since nearly everything we use should > be 24-bits these days. > > I have a better idea, though. > > But, since the field is assigned the original supplied value from the > constructor, then the likelihood that a non-null value will be == > identical to another colormap is likely larger than normal, perhaps we > can make it faster by checking for == and then slipping into the > faster test that simply compares the rgb[] values? Something like: > > if (validBits == cm.validBits) { > compare rgb[] entries > } else if (validBits == null || cm.validBits == null) { > return false; > } else { > bigger loop that compares rgb[] and validBits() values > } > > Note that if the two fields are == and non-null, then the entries in > the rgb[] array for indices that are non-valid should have zeros in > them because of the way that the colormap data is copied internally, > so the rgb[] comparisons should be valid without checking the > associated bits. > > Potentially we could also use: > > boolean fulltest; > if (validBits == cm.validBits) { > fulltest = false; > } else if (validBits == null || cm.validBits == null) { > return false; > } else if (validBits.equals(cm.validBits)) { > fulltest = false; > } else { > fulltest = true; > } > > if (fulltest) { > compare both rgb[] and validBits() values > } else { > compare rgb[] entries alone > } > > In this case we are using validBits.equals() to reduce the amount of > testing in the loop, but are not basing a conclusion on whether the > result of the comparison will be true or false. equals() implies we > don't need to compare its values bit by bit, but !equals() doesn't > mean that the ICMs aren't equals()... > > ...jim From Sergey.Bylokhov at oracle.com Tue Apr 12 22:37:05 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 13 Apr 2016 01:37:05 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 7102282 TEST_BUG: sun/java2d/OpenGL/GradientPaints.java should be modified Message-ID: <570D7891.5010408@oracle.com> Hello, Please review the fix for jdk9. This test uncover a few issues: Test bug: - Fail on HiDPI system, because the test tries to check the rendering to the BufferedImage and VolaileImage using some threshold. Fixed by the "-Dsun.java2d.uiScale=1" option. jdk bug: - timeout error (in the bug the value 800 is suggested). It seems a duplicate of JDK-8041129 [1]. Anyway 800 is to big, and should be considered as a jdk bug(if will be reproduced on the latest jdk9). - Incorrect rendering on some systems and video cards (especially on linux), is covered by JDK-7124403 [2] Since OGL performance should be fixed already, I updated the test only for the retina case. After the fix I think the test is ok, and other possible failures should be considered as a jdk bugs. I also create a new bug JDK-8154103 [3] to check the performance of XRender pipeline, it is slower than x11 and ogl. [1] https://bugs.openjdk.java.net/browse/JDK-8041129 [2] https://bugs.openjdk.java.net/browse/JDK-7124403 [2] https://bugs.openjdk.java.net/browse/JDK-8154103 Bug: https://bugs.openjdk.java.net/browse/JDK-7102282 Webrev can be found at: http://cr.openjdk.java.net/~serb/7102282/webrev.00 -- Best regards, Sergey. From philip.race at oracle.com Tue Apr 12 23:22:58 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 12 Apr 2016 16:22:58 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6529030, , Java Printing: Print range > Selection gets enabled In-Reply-To: <5704E06F.2010502@oracle.com> References: <5704E06F.2010502@oracle.com> Message-ID: <570D8352.5060405@oracle.com> Hi, My reading here : https://msdn.microsoft.com/en-us/library/windows/desktop/ms646843%28v=vs.85%29.aspx of the meaning of PD_NOSELECTION is that it disables the SELECTION radio button such that the user *cannot* select it. Is that true ? If so this seems like it cannot be the right fix for this issue and I am not sure why getSelectAttrib() would want to return that. Perhaps we never in practice return PD_NOSELECTION ? I am also unsure what it means to set flags to PD_NOSELECTION | PD_SELECTION as the windows docs don't tell me enough. Maybe what we want is just that we do not cause PD_SELECTION to be set rather than setting PD_NOSELECTION. But to decide what to do I need to know the real effect of PD_NOSELECTION. BTW about the test: you should make sure that the instructions are valid on OS X and Linux .. -phil. On 04/06/2016 03:09 AM, prasanta sadhukhan wrote: > Hi All, > > Please review a fix for jdk9. > Bug: https://bugs.openjdk.java.net/browse/JDK-6529030 > webrev: http://cr.openjdk.java.net/~psadhukhan/6529030/webrev.00/ > > The issue was when using java.awt.print.PrinterJob instance more then > once, Selection radio button in Print dialog gets enabled from 2nd > instance even though we are printing "All" pages > however Selection radio button is disabled in the first instance. > This is seen in windows. > > This is because initially when windows initialized the print dialog, > it calls InitPrintDialog() which calls getSelectAttrib() to find out > which selection attribute user has selected. > getSelectAttrib() returns PD_NOSELECTION as SunPageSelection.class was > not added to attribute. > So, in InitPrintDialog() we set PRINTDLG flags to PD_NOSELECTION. So, > we see "Selection " radio button is disabled in 1st instance of print > dialog. > Now, when user presses "OK", windows native code calls > setNativeAttributes() and adds SunPageSelection.class to the attribute > with SunPageSelection.ALL or SunPageSelection.RANGE. > > When 2nd print dialog is shown, InitPrintDialog() will again call > getSelectAttrib() which will now return > SunPageSelection.ALL/SunPageSelection.RANGE which will be set to > PRINTDLG flag but > we are not disabling Selection radio button, so in 2nd instance, > Selection radio button gets enabled. > > Fix was to check if PD_SELECTION attribute is selected by user, if not > , sets PRINTDLG flag with PD_NOSELECTION. > > I have checked 8151590 and 8061267 works correctly with this patch. > > Regards > Prasanta From prasanta.sadhukhan at oracle.com Wed Apr 13 05:23:11 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Wed, 13 Apr 2016 10:53:11 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6197099 : PrinterJob.getUserName() throws a security exception when user.name permission is not given In-Reply-To: <5704F4CA.3020108@oracle.com> References: <5704F4CA.3020108@oracle.com> Message-ID: <570DD7BF.90506@oracle.com> Resending with bugid in the subject line. On 4/6/2016 5:06 PM, prasanta sadhukhan wrote: > Hi All, > > Please review a document fix for jdk9 > Bug: https://bugs.openjdk.java.net/browse/JDK-6197099 > webrev: http://cr.openjdk.java.net/~psadhukhan/6197099/webrev.00/ > > PrinterJob.getUserName() is supposed to return the current user name > of the system. This method does not document any exception. > But when SecurityManager is installed, this method throws a security > exception when PropertyPermission - user.name is not given in the > policy file. > But this is not documented anywhere and hence the user will not know > until he gets the exception. > > Documented the long-standing existing exception. > > will raise a ccc after the technical review. > > Regards > Prasanta From prasanta.sadhukhan at oracle.com Wed Apr 13 08:13:08 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Wed, 13 Apr 2016 13:43:08 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8154057, , [macosx] getPrintJob doesn't throw NPE if Frame is null AND type is COMMON In-Reply-To: <570D2CC5.5030303@oracle.com> References: <570CD915.8060803@oracle.com> <570D2CC5.5030303@oracle.com> Message-ID: <570DFF94.7020101@oracle.com> Hi Phil, Yes, it seems code does not use this frame as parent/owner. Actually, xxxToolkit will call initPrintJob2D() after checking for frame==null, followed by PrintJob2D.printDialog() which will just store the frame in the attribute if (frame != null) { attributes.add(new DialogOwner(frame)); } and then call ServiceUI.printDialog() which just pass null as owner to ServiceDialog() for now. // For now we set owner to null. In the future, it may be passed // as an argument. Window owner = null; dialog = new ServiceDialog(gc, x, y, services, defaultIndex, flavor, attributes, (Dialog)owner); and so this behaviour is common to all platforms. I guess we should populate WIndow owner with this frame object. But since this NPE problem is specific to mac,can we fix this bug first as the other platforms has same null check code in Toolkit.getPrintJob() and create another bug for this frame usage. Please let me know your thoughts. BTW, It was not seen (ie NPE is thrown) for native dialog in mac as in initPrintJob2D() we have this check if (frame == null && (jobAttributes == null || jobAttributes.getDialog() == DialogType.NATIVE)) { throw new NullPointerException("Frame must not be null"); } Regards Prasanta On 4/12/2016 10:43 PM, Phil Race wrote: > hmm .. if it does not throw NPE when the dialog type is common that > could mean > that the code is not referencing the frame as a modal parent /owner in > that case which could > be another bug. > Did you check into how this is used relative to other platforms ? > > -phil. > > > On 04/12/2016 04:16 AM, prasanta sadhukhan wrote: >> Hi All, >> >> Please review a fix for jdk9. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154057 >> webrev: http://cr.openjdk.java.net/~psadhukhan/8154057/webrev.00/ >> >> As per spec, Toolkit.getPrintJob() should throw NPE if null frame >> object is passed to it. >> But on macos, it seems getPrintJob() does not check for null frame >> and show the print dialog. >> >> Fix is to check for null frame which is same as what we do in windows >> (WToolkit) and linux (XToolkit). >> >> Regards >> Prasanta > From jayathirth.d.v at oracle.com Wed Apr 13 08:33:09 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 13 Apr 2016 01:33:09 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: equals() method in IndexColorModel doesnt exist and it relies on ColorModel.equals() which is not strict In-Reply-To: <570D5822.40705@oracle.com> References: <57057CF0.50604@oracle.com> <5706ADBE.10803@oracle.com> <570BF21F.9010603@oracle.com> <34a9ed1b-bf8a-43fb-9032-65c9c47a9c11@default> <570D5043.8000405@oracle.com> <570D5387.2070303@oracle.com> <570D5839.3000402@oracle.com> <570D5822.40705@oracle.com> Message-ID: Hi, Thanks Phil & Jim for your suggestion. I have made changes mentioned by Jim for whether we have validate individual bits of validBits or not in different conditions. Please find updated webrev for review : http://cr.openjdk.java.net/~jdv/7107905/webrev.04/ Thanks, Jay -----Original Message----- From: Phil Race Sent: Wednesday, April 13, 2016 1:49 AM To: Jim Graham Cc: Jayathirth D V; Prasanta Sadhukhan; 2d-dev at openjdk.java.net Subject: Re: Review Request for JDK-7107905: equals() method in IndexColorModel doesnt exist and it relies on ColorModel.equals() which is not strict Seems like this would work/help. -phil. On 04/12/2016 01:19 PM, Jim Graham wrote: > > > On 4/12/2016 12:59 PM, Phil Race wrote: >> I am catching up on email here, and "+1" but a couple of comments >> >> - I suppose that we can't learn anything useful from >> "cm.validbits.equals(this.validbits)" >> since only the bits up to "map_size" should be tested ? > > Perhaps if the constructors truncated it at the required size we could > use equals(). I'm not sure that is worthwhile, given how rarely it is > used. I think it is used by default on some platforms (Windows? > X11?) if they have an 8-bit screen with a sparse colormap, but that > should be pretty rare these days since nearly everything we use should > be 24-bits these days. > > I have a better idea, though. > > But, since the field is assigned the original supplied value from the > constructor, then the likelihood that a non-null value will be == > identical to another colormap is likely larger than normal, perhaps we > can make it faster by checking for == and then slipping into the > faster test that simply compares the rgb[] values? Something like: > > if (validBits == cm.validBits) { > compare rgb[] entries > } else if (validBits == null || cm.validBits == null) { > return false; > } else { > bigger loop that compares rgb[] and validBits() values } > > Note that if the two fields are == and non-null, then the entries in > the rgb[] array for indices that are non-valid should have zeros in > them because of the way that the colormap data is copied internally, > so the rgb[] comparisons should be valid without checking the > associated bits. > > Potentially we could also use: > > boolean fulltest; > if (validBits == cm.validBits) { > fulltest = false; > } else if (validBits == null || cm.validBits == null) { > return false; > } else if (validBits.equals(cm.validBits)) { > fulltest = false; > } else { > fulltest = true; > } > > if (fulltest) { > compare both rgb[] and validBits() values } else { > compare rgb[] entries alone > } > > In this case we are using validBits.equals() to reduce the amount of > testing in the loop, but are not basing a conclusion on whether the > result of the comparison will be true or false. equals() implies we > don't need to compare its values bit by bit, but !equals() doesn't > mean that the ICMs aren't equals()... > > ...jim From prasanta.sadhukhan at oracle.com Wed Apr 13 11:17:53 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Wed, 13 Apr 2016 16:47:53 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6529030, , Java Printing: Print range > Selection gets enabled In-Reply-To: <570D8352.5060405@oracle.com> References: <5704E06F.2010502@oracle.com> <570D8352.5060405@oracle.com> Message-ID: <570E2AE1.4020604@oracle.com> Hi Phil, On 4/13/2016 4:52 AM, Phil Race wrote: > Hi, > > My reading here : > https://msdn.microsoft.com/en-us/library/windows/desktop/ms646843%28v=vs.85%29.aspx > > > of the meaning of PD_NOSELECTION is that it disables the SELECTION > radio button such > that the user *cannot* select it. > > Is that true ? Yes, PD_NOSELECTION will disable SELECTION radio button. > If so this seems like it cannot be the right fix for this issue > and I am not sure why getSelectAttrib() would want to return that. protected final int getSelectAttrib() { if (attributes != null) { SunPageSelection pages = (SunPageSelection)attributes.get(SunPageSelection.class); if (pages == SunPageSelection.RANGE) { return PD_PAGENUMS; } else if (pages == SunPageSelection.SELECTION) { return PD_SELECTION; } else if (pages == SunPageSelection.ALL) { return PD_ALLPAGES; } } return PD_NOSELECTION; } so if SunPageSelection is not added to attribute which was the case in 1st instance so PD_NOSELECTION is returned and we have in awt_PrintControl.cpp#InitPrintDialog() if (selectType != 0) { selectType will be 4 for PD_NOSELECTION so pd.Flags will be set and Selection radio button is disabled in 1st instance pd.Flags |= selectType; } > Perhaps we never in practice return PD_NOSELECTION ? > > I am also unsure what it means to set flags to PD_NOSELECTION | > PD_SELECTION > as the windows docs don't tell me enough. It will still disable SELECTION radio button. > > Maybe what we want is just that we do not cause PD_SELECTION to be set > rather than setting PD_NOSELECTION. > I have modified the webrev to not set PD_NOSELECTION if getSelectAttrib() returns NOSELECTION so it will mean Selection radiobutton will be enabled now but will not be selected UNLESS user selects job.setDefaultSelection(JobAttributes.DefaultSelectionType.SELECTION) explicitly in the application. http://cr.openjdk.java.net/~psadhukhan/6529030/webrev.01/ Also, I added @requires (os.family == windows) tag to make sure the test is run on windows only as in linux, osx we do not get the "selection" option [only All and Page range] for this test. Regards Prasanta > But to decide what to do I need to know the real effect of > PD_NOSELECTION. > > BTW about the test: you should make sure that the instructions are > valid on OS X and Linux .. > > -phil. > > On 04/06/2016 03:09 AM, prasanta sadhukhan wrote: >> Hi All, >> >> Please review a fix for jdk9. >> Bug: https://bugs.openjdk.java.net/browse/JDK-6529030 >> webrev: http://cr.openjdk.java.net/~psadhukhan/6529030/webrev.00/ >> >> The issue was when using java.awt.print.PrinterJob instance more then >> once, Selection radio button in Print dialog gets enabled from 2nd >> instance even though we are printing "All" pages >> however Selection radio button is disabled in the first instance. >> This is seen in windows. >> >> This is because initially when windows initialized the print dialog, >> it calls InitPrintDialog() which calls getSelectAttrib() to find out >> which selection attribute user has selected. >> getSelectAttrib() returns PD_NOSELECTION as SunPageSelection.class >> was not added to attribute. >> So, in InitPrintDialog() we set PRINTDLG flags to PD_NOSELECTION. So, >> we see "Selection " radio button is disabled in 1st instance of print >> dialog. >> Now, when user presses "OK", windows native code calls >> setNativeAttributes() and adds SunPageSelection.class to the >> attribute with SunPageSelection.ALL or SunPageSelection.RANGE. >> >> When 2nd print dialog is shown, InitPrintDialog() will again call >> getSelectAttrib() which will now return >> SunPageSelection.ALL/SunPageSelection.RANGE which will be set to >> PRINTDLG flag but >> we are not disabling Selection radio button, so in 2nd instance, >> Selection radio button gets enabled. >> >> Fix was to check if PD_SELECTION attribute is selected by user, if >> not , sets PRINTDLG flag with PD_NOSELECTION. >> >> I have checked 8151590 and 8061267 works correctly with this patch. >> >> Regards >> Prasanta > From yuri.nesterenko at oracle.com Wed Apr 13 11:50:28 2016 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Wed, 13 Apr 2016 14:50:28 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 7102282 TEST_BUG: sun/java2d/OpenGL/GradientPaints.java should be modified In-Reply-To: <570D7891.5010408@oracle.com> References: <570D7891.5010408@oracle.com> Message-ID: <570E3284.2080709@oracle.com> +1 -yan On 04/13/2016 01:37 AM, Sergey Bylokhov wrote: > Hello, > Please review the fix for jdk9. > > This test uncover a few issues: > Test bug: > - Fail on HiDPI system, because the test tries to check the rendering > to the BufferedImage and VolaileImage using some threshold. Fixed by the > "-Dsun.java2d.uiScale=1" option. > > jdk bug: > - timeout error (in the bug the value 800 is suggested). It seems a > duplicate of JDK-8041129 [1]. Anyway 800 is to big, and should be > considered as a jdk bug(if will be reproduced on the latest jdk9). > - Incorrect rendering on some systems and video cards (especially on > linux), is covered by JDK-7124403 [2] > > Since OGL performance should be fixed already, I updated the test only > for the retina case. After the fix I think the test is ok, and other > possible failures should be considered as a jdk bugs. > > I also create a new bug JDK-8154103 [3] to check the performance of > XRender pipeline, it is slower than x11 and ogl. > > [1] https://bugs.openjdk.java.net/browse/JDK-8041129 > [2] https://bugs.openjdk.java.net/browse/JDK-7124403 > [2] https://bugs.openjdk.java.net/browse/JDK-8154103 > > Bug: https://bugs.openjdk.java.net/browse/JDK-7102282 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7102282/webrev.00 > From prasanta.sadhukhan at oracle.com Wed Apr 13 11:53:51 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Wed, 13 Apr 2016 17:23:51 +0530 Subject: [OpenJDK 2D-Dev] [9] Review Request: 7102282 TEST_BUG: sun/java2d/OpenGL/GradientPaints.java should be modified In-Reply-To: <570E3284.2080709@oracle.com> References: <570D7891.5010408@oracle.com> <570E3284.2080709@oracle.com> Message-ID: <570E334F.7030000@oracle.com> Hi Sergey, I guess you forgot to add 7102282 to the bugid. Regards Prasanta > > On 04/13/2016 01:37 AM, Sergey Bylokhov wrote: >> Hello,bu >> Please review the fix for jdk9. >> >> This test uncover a few issues: >> Test bug: >> - Fail on HiDPI system, because the test tries to check the rendering >> to the BufferedImage and VolaileImage using some threshold. Fixed by the >> "-Dsun.java2d.uiScale=1" option. >> >> jdk bug: >> - timeout error (in the bug the value 800 is suggested). It seems a >> duplicate of JDK-8041129 [1]. Anyway 800 is to big, and should be >> considered as a jdk bug(if will be reproduced on the latest jdk9). >> - Incorrect rendering on some systems and video cards (especially on >> linux), is covered by JDK-7124403 [2] >> >> Since OGL performance should be fixed already, I updated the test only >> for the retina case. After the fix I think the test is ok, and other >> possible failures should be considered as a jdk bugs. >> >> I also create a new bug JDK-8154103 [3] to check the performance of >> XRender pipeline, it is slower than x11 and ogl. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8041129 >> [2] https://bugs.openjdk.java.net/browse/JDK-7124403 >> [2] https://bugs.openjdk.java.net/browse/JDK-8154103 >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-7102282 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/7102282/webrev.00 >> > From philip.race at oracle.com Wed Apr 13 14:35:28 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 13 Apr 2016 07:35:28 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6197099 : PrinterJob.getUserName() throws a security exception when user.name permission is not given In-Reply-To: <570DD7BF.90506@oracle.com> References: <5704F4CA.3020108@oracle.com> <570DD7BF.90506@oracle.com> Message-ID: <570E5930.1060809@oracle.com> This needs a test. You can provide one by following other similar examples. Also it needs a CCC to document the exception. Finally, I am a bit surprised at the exact exception. Where precisely does this originate (stack trace, please) ? Probably we should throw SecurityException instead, even if it is not the exact behaviour today. Just make sure that our own code is ready for such a change. -phil. On 4/12/16, 10:23 PM, prasanta sadhukhan wrote: > Resending with bugid in the subject line. > > On 4/6/2016 5:06 PM, prasanta sadhukhan wrote: >> Hi All, >> >> Please review a document fix for jdk9 >> Bug: https://bugs.openjdk.java.net/browse/JDK-6197099 >> webrev: http://cr.openjdk.java.net/~psadhukhan/6197099/webrev.00/ >> >> PrinterJob.getUserName() is supposed to return the current user name >> of the system. This method does not document any exception. >> But when SecurityManager is installed, this method throws a security >> exception when PropertyPermission - user.name is not given in the >> policy file. >> But this is not documented anywhere and hence the user will not know >> until he gets the exception. >> >> Documented the long-standing existing exception. >> >> will raise a ccc after the technical review. >> >> Regards >> Prasanta > From philip.race at oracle.com Wed Apr 13 15:35:14 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 13 Apr 2016 08:35:14 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6921664, , The amount of copies and the printer job name is not passed to the implementing In-Reply-To: <57024E33.3000801@oracle.com> References: <57024E33.3000801@oracle.com> Message-ID: <570E6732.8060807@oracle.com> I have updated the synopsis, please use this in the commit :- "The number of copies and the job name are not passed to a 3rd party PrintService" Fix looks fine. -phil On 4/4/16, 4:21 AM, prasanta sadhukhan wrote: > Hi All, > > Please review a fix for jdk9 > Bug: https://bugs.openjdk.java.net/browse/JDK-6921664 > webrev: http://cr.openjdk.java.net/~psadhukhan/6921664/webrev.00/ > > The issue was > for a third party non-builtin print service, if the application sets > the copies, jobname attribute these attributes are not passed to the > third party print() implementation. > This is because when we find there is a non-builtin print service, we > call spoolService() in RasterPrinterJob > which , even though it creates an attribute set via attributes = new > HashPrintRequestAttributeSet(); > but it does not populate the attributes with the attributes set by the > application, so when we call job.print(doc, attributes); we were > passing attributes without any attribute set. > > I added the minimal copies and jobName attributes to the attribute > list before calling the 3rdparty print implementation. > > Regards > Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Apr 13 15:41:59 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 13 Apr 2016 08:41:59 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6801613, , Cross-platform pageDialog and printDialog top margin entry broken In-Reply-To: <57039CB7.7090300@oracle.com> References: <57039CB7.7090300@oracle.com> Message-ID: <570E68C7.6040605@oracle.com> +1 although I think robot may be able to automate this. -phil. On 4/5/16, 4:08 AM, prasanta sadhukhan wrote: > Hi All, > > Please review a fix for jdk9 > Bug: https://bugs.openjdk.java.net/browse/JDK-6801613 > webrev: http://cr.openjdk.java.net/~psadhukhan/6801613/webrev.00/ > > The issue was the PrinterJob cross-platform "Page setup dialog" top > margin entry is broken. > If you enter a value in the top margin field and hit "OK", the value > is not updated in the PageFormat instance return value, > nor is it updated in the attribute set used to call the pageDialog > method. > Tabbing out of the top margin field before hitting OK does not fix the > problem. > Likewise, clicking on a different margin entry field before hitting OK > also does not fix the problem. > > The reason was we created topMargin JFormattedTextField once and added > focusListener and ActionListener to this textfield but > we overwrote the topMargin textField again by creating another > instance and in that instance, we failed to add actionListener or > focusListener, > so when we tabbed out of topmargin field, focusLost() method was not > called which would have called updateMargin() method to update the > margins. > > Fix was to remove this erroneous instance creation and overwriting of > topMargin textfield. > > Regards > Prasanta From philip.race at oracle.com Wed Apr 13 15:59:52 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 13 Apr 2016 08:59:52 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8154057, , [macosx] getPrintJob doesn't throw NPE if Frame is null AND type is COMMON In-Reply-To: <570DFF94.7020101@oracle.com> References: <570CD915.8060803@oracle.com> <570D2CC5.5030303@oracle.com> <570DFF94.7020101@oracle.com> Message-ID: <570E6CF8.9050307@oracle.com> Ok, so +1 to this fix but file a new bug to track the non-usage of the owner frame. -phil. On 4/13/16, 1:13 AM, prasanta sadhukhan wrote: > Hi Phil, > > Yes, it seems code does not use this frame as parent/owner. > Actually, xxxToolkit will call initPrintJob2D() after checking for > frame==null, followed by PrintJob2D.printDialog() which will just > store the frame in the attribute > if (frame != null) { > attributes.add(new DialogOwner(frame)); > } > and then call ServiceUI.printDialog() > which just pass null as owner to ServiceDialog() for now. > > // For now we set owner to null. In the future, it may be passed > // as an argument. > Window owner = null; > > dialog = new ServiceDialog(gc, > x, > y, > services, defaultIndex, > flavor, attributes, > (Dialog)owner); > and so this behaviour is common to all platforms. > > I guess we should populate WIndow owner with this frame object. > > But since this NPE problem is specific to mac,can we fix this bug first > as the other platforms has same null check code in > Toolkit.getPrintJob() and create another bug for this frame usage. > Please let me know your thoughts. > > BTW, > It was not seen (ie NPE is thrown) for native dialog in mac as in > initPrintJob2D() we have this check > if (frame == null && > (jobAttributes == null || > jobAttributes.getDialog() == DialogType.NATIVE)) { > throw new NullPointerException("Frame must not be null"); > } > > Regards > Prasanta > On 4/12/2016 10:43 PM, Phil Race wrote: >> hmm .. if it does not throw NPE when the dialog type is common that >> could mean >> that the code is not referencing the frame as a modal parent /owner >> in that case which could >> be another bug. >> Did you check into how this is used relative to other platforms ? >> >> -phil. >> >> >> On 04/12/2016 04:16 AM, prasanta sadhukhan wrote: >>> Hi All, >>> >>> Please review a fix for jdk9. >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154057 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8154057/webrev.00/ >>> >>> As per spec, Toolkit.getPrintJob() should throw NPE if null frame >>> object is passed to it. >>> But on macos, it seems getPrintJob() does not check for null frame >>> and show the print dialog. >>> >>> Fix is to check for null frame which is same as what we do in >>> windows (WToolkit) and linux (XToolkit). >>> >>> Regards >>> Prasanta >> > From philip.race at oracle.com Wed Apr 13 17:10:05 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 13 Apr 2016 10:10:05 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6529030, , Java Printing: Print range > Selection gets enabled In-Reply-To: <570E2AE1.4020604@oracle.com> References: <5704E06F.2010502@oracle.com> <570D8352.5060405@oracle.com> <570E2AE1.4020604@oracle.com> Message-ID: <570E7D6D.9040306@oracle.com> This seems reasonable to me - we don't want "disable" the selection radio button and prevent the user from selecting it since our API does support it as an option. The way I first read the bug report was that it implied that the first invocation when the selection button was disabled was "right" and the 2nd invocation was "wrong" whereas it seems the other way around. If the updated code (and my understanding) is correct then should we not in fact be updating getSelectAttrib() so that it never returns PD_NOSELECTION, rather than "fixing it up" in this code ? Of course you then need to look to see how we interpret & use a return value of PD_NOSELECTIONfrom getSelectAttrib() on OS X and Linux. I would really like to get Jennifer's input on this. -phil. On 4/13/16, 4:17 AM, prasanta sadhukhan wrote: > Hi Phil, > > On 4/13/2016 4:52 AM, Phil Race wrote: >> Hi, >> >> My reading here : >> https://msdn.microsoft.com/en-us/library/windows/desktop/ms646843%28v=vs.85%29.aspx >> >> >> of the meaning of PD_NOSELECTION is that it disables the SELECTION >> radio button such >> that the user *cannot* select it. >> >> Is that true ? > Yes, PD_NOSELECTION will disable SELECTION radio button. >> If so this seems like it cannot be the right fix for this issue >> and I am not sure why getSelectAttrib() would want to return that. > protected final int getSelectAttrib() { > if (attributes != null) { > SunPageSelection pages = > (SunPageSelection)attributes.get(SunPageSelection.class); > if (pages == SunPageSelection.RANGE) { > return PD_PAGENUMS; > } else if (pages == SunPageSelection.SELECTION) { > return PD_SELECTION; > } else if (pages == SunPageSelection.ALL) { > return PD_ALLPAGES; > } > } > return PD_NOSELECTION; > } > so if SunPageSelection is not added to attribute which was the case in > 1st instance so PD_NOSELECTION is returned > and we have in awt_PrintControl.cpp#InitPrintDialog() > if (selectType != 0) { selectType will be 4 for PD_NOSELECTION so > pd.Flags will be set and Selection radio button is disabled in 1st > instance > pd.Flags |= selectType; > } >> Perhaps we never in practice return PD_NOSELECTION ? >> >> I am also unsure what it means to set flags to PD_NOSELECTION | >> PD_SELECTION >> as the windows docs don't tell me enough. > It will still disable SELECTION radio button. >> >> Maybe what we want is just that we do not cause PD_SELECTION to be set >> rather than setting PD_NOSELECTION. >> > I have modified the webrev to not set PD_NOSELECTION if > getSelectAttrib() returns NOSELECTION so it will mean Selection > radiobutton will be enabled now but will not be selected UNLESS user > selects > job.setDefaultSelection(JobAttributes.DefaultSelectionType.SELECTION) > explicitly in the application. > > http://cr.openjdk.java.net/~psadhukhan/6529030/webrev.01/ > Also, I added @requires (os.family == windows) tag to make sure the > test is run on windows only as in linux, osx we do not get the > "selection" option [only All and Page range] for this test. > > Regards > Prasanta >> But to decide what to do I need to know the real effect of >> PD_NOSELECTION. >> >> BTW about the test: you should make sure that the instructions are >> valid on OS X and Linux .. >> >> -phil. >> >> On 04/06/2016 03:09 AM, prasanta sadhukhan wrote: >>> Hi All, >>> >>> Please review a fix for jdk9. >>> Bug: https://bugs.openjdk.java.net/browse/JDK-6529030 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/6529030/webrev.00/ >>> >>> The issue was when using java.awt.print.PrinterJob instance more >>> then once, Selection radio button in Print dialog gets enabled from >>> 2nd instance even though we are printing "All" pages >>> however Selection radio button is disabled in the first instance. >>> This is seen in windows. >>> >>> This is because initially when windows initialized the print dialog, >>> it calls InitPrintDialog() which calls getSelectAttrib() to find out >>> which selection attribute user has selected. >>> getSelectAttrib() returns PD_NOSELECTION as SunPageSelection.class >>> was not added to attribute. >>> So, in InitPrintDialog() we set PRINTDLG flags to PD_NOSELECTION. >>> So, we see "Selection " radio button is disabled in 1st instance of >>> print dialog. >>> Now, when user presses "OK", windows native code calls >>> setNativeAttributes() and adds SunPageSelection.class to the >>> attribute with SunPageSelection.ALL or SunPageSelection.RANGE. >>> >>> When 2nd print dialog is shown, InitPrintDialog() will again call >>> getSelectAttrib() which will now return >>> SunPageSelection.ALL/SunPageSelection.RANGE which will be set to >>> PRINTDLG flag but >>> we are not disabling Selection radio button, so in 2nd instance, >>> Selection radio button gets enabled. >>> >>> Fix was to check if PD_SELECTION attribute is selected by user, if >>> not , sets PRINTDLG flag with PD_NOSELECTION. >>> >>> I have checked 8151590 and 8061267 works correctly with this patch. >>> >>> Regards >>> Prasanta >> > From philip.race at oracle.com Wed Apr 13 20:50:31 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 13 Apr 2016 13:50:31 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: equals() method in IndexColorModel doesnt exist and it relies on ColorModel.equals() which is not strict In-Reply-To: <570D5839.3000402@oracle.com> References: <57057CF0.50604@oracle.com> <5706ADBE.10803@oracle.com> <570BF21F.9010603@oracle.com> <34a9ed1b-bf8a-43fb-9032-65c9c47a9c11@default> <570D5043.8000405@oracle.com> <570D5387.2070303@oracle.com> <570D5839.3000402@oracle.com> Message-ID: <570EB117.4030006@oracle.com> +1 -phil. On 04/12/2016 01:19 PM, Jim Graham wrote: > > > On 4/12/2016 12:59 PM, Phil Race wrote: >> I am catching up on email here, and "+1" but a couple of comments >> >> - I suppose that we can't learn anything useful from >> "cm.validbits.equals(this.validbits)" >> since only the bits up to "map_size" should be tested ? > > Perhaps if the constructors truncated it at the required size we could > use equals(). I'm not sure that is worthwhile, given how rarely it is > used. I think it is used by default on some platforms (Windows? > X11?) if they have an 8-bit screen with a sparse colormap, but that > should be pretty rare these days since nearly everything we use should > be 24-bits these days. > > I have a better idea, though. > > But, since the field is assigned the original supplied value from the > constructor, then the likelihood that a non-null value will be == > identical to another colormap is likely larger than normal, perhaps we > can make it faster by checking for == and then slipping into the > faster test that simply compares the rgb[] values? Something like: > > if (validBits == cm.validBits) { > compare rgb[] entries > } else if (validBits == null || cm.validBits == null) { > return false; > } else { > bigger loop that compares rgb[] and validBits() values > } > > Note that if the two fields are == and non-null, then the entries in > the rgb[] array for indices that are non-valid should have zeros in > them because of the way that the colormap data is copied internally, > so the rgb[] comparisons should be valid without checking the > associated bits. > > Potentially we could also use: > > boolean fulltest; > if (validBits == cm.validBits) { > fulltest = false; > } else if (validBits == null || cm.validBits == null) { > return false; > } else if (validBits.equals(cm.validBits)) { > fulltest = false; > } else { > fulltest = true; > } > > if (fulltest) { > compare both rgb[] and validBits() values > } else { > compare rgb[] entries alone > } > > In this case we are using validBits.equals() to reduce the amount of > testing in the loop, but are not basing a conclusion on whether the > result of the comparison will be true or false. equals() implies we > don't need to compare its values bit by bit, but !equals() doesn't > mean that the ICMs aren't equals()... > > ...jim From james.graham at oracle.com Wed Apr 13 21:26:49 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 13 Apr 2016 14:26:49 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: equals() method in IndexColorModel doesnt exist and it relies on ColorModel.equals() which is not strict In-Reply-To: References: <57057CF0.50604@oracle.com> <5706ADBE.10803@oracle.com> <570BF21F.9010603@oracle.com> <34a9ed1b-bf8a-43fb-9032-65c9c47a9c11@default> <570D5043.8000405@oracle.com> <570D5387.2070303@oracle.com> <570D5839.3000402@oracle.com> <570D5822.40705@oracle.com> Message-ID: <570EB999.7090408@oracle.com> Looks good. The only thing left is the CCC... ...jim On 4/13/16 1:33 AM, Jayathirth D V wrote: > Hi, > > Thanks Phil & Jim for your suggestion. > I have made changes mentioned by Jim for whether we have validate individual bits of validBits or not in different conditions. > Please find updated webrev for review : > http://cr.openjdk.java.net/~jdv/7107905/webrev.04/ > > Thanks, > Jay > > -----Original Message----- > From: Phil Race > Sent: Wednesday, April 13, 2016 1:49 AM > To: Jim Graham > Cc: Jayathirth D V; Prasanta Sadhukhan; 2d-dev at openjdk.java.net > Subject: Re: Review Request for JDK-7107905: equals() method in IndexColorModel doesnt exist and it relies on ColorModel.equals() which is not strict > > Seems like this would work/help. > > -phil. > > On 04/12/2016 01:19 PM, Jim Graham wrote: >> >> >> On 4/12/2016 12:59 PM, Phil Race wrote: >>> I am catching up on email here, and "+1" but a couple of comments >>> >>> - I suppose that we can't learn anything useful from >>> "cm.validbits.equals(this.validbits)" >>> since only the bits up to "map_size" should be tested ? >> >> Perhaps if the constructors truncated it at the required size we could >> use equals(). I'm not sure that is worthwhile, given how rarely it is >> used. I think it is used by default on some platforms (Windows? >> X11?) if they have an 8-bit screen with a sparse colormap, but that >> should be pretty rare these days since nearly everything we use should >> be 24-bits these days. >> >> I have a better idea, though. >> >> But, since the field is assigned the original supplied value from the >> constructor, then the likelihood that a non-null value will be == >> identical to another colormap is likely larger than normal, perhaps we >> can make it faster by checking for == and then slipping into the >> faster test that simply compares the rgb[] values? Something like: >> >> if (validBits == cm.validBits) { >> compare rgb[] entries >> } else if (validBits == null || cm.validBits == null) { >> return false; >> } else { >> bigger loop that compares rgb[] and validBits() values } >> >> Note that if the two fields are == and non-null, then the entries in >> the rgb[] array for indices that are non-valid should have zeros in >> them because of the way that the colormap data is copied internally, >> so the rgb[] comparisons should be valid without checking the >> associated bits. >> >> Potentially we could also use: >> >> boolean fulltest; >> if (validBits == cm.validBits) { >> fulltest = false; >> } else if (validBits == null || cm.validBits == null) { >> return false; >> } else if (validBits.equals(cm.validBits)) { >> fulltest = false; >> } else { >> fulltest = true; >> } >> >> if (fulltest) { >> compare both rgb[] and validBits() values } else { >> compare rgb[] entries alone >> } >> >> In this case we are using validBits.equals() to reduce the amount of >> testing in the loop, but are not basing a conclusion on whether the >> result of the comparison will be true or false. equals() implies we >> don't need to compare its values bit by bit, but !equals() doesn't >> mean that the ICMs aren't equals()... >> >> ...jim > From prasanta.sadhukhan at oracle.com Thu Apr 14 05:30:14 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Thu, 14 Apr 2016 11:00:14 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8154057, , [macosx] getPrintJob doesn't throw NPE if Frame is null AND type is COMMON In-Reply-To: <570E6CF8.9050307@oracle.com> References: <570CD915.8060803@oracle.com> <570D2CC5.5030303@oracle.com> <570DFF94.7020101@oracle.com> <570E6CF8.9050307@oracle.com> Message-ID: <570F2AE6.3020605@oracle.com> Thanks for the review. I have filed a new issue for this non-usage of frame https://bugs.openjdk.java.net/browse/JDK-8154218 Regards Prasanta On 4/13/2016 9:29 PM, Philip Race wrote: > Ok, so +1 to this fix but file a new bug to track the non-usage of the > owner frame. > > -phil. > > On 4/13/16, 1:13 AM, prasanta sadhukhan wrote: >> Hi Phil, >> >> Yes, it seems code does not use this frame as parent/owner. >> Actually, xxxToolkit will call initPrintJob2D() after checking for >> frame==null, followed by PrintJob2D.printDialog() which will just >> store the frame in the attribute >> if (frame != null) { >> attributes.add(new DialogOwner(frame)); >> } >> and then call ServiceUI.printDialog() >> which just pass null as owner to ServiceDialog() for now. >> >> // For now we set owner to null. In the future, it may be passed >> // as an argument. >> Window owner = null; >> >> dialog = new ServiceDialog(gc, >> x, >> y, >> services, defaultIndex, >> flavor, attributes, >> (Dialog)owner); >> and so this behaviour is common to all platforms. >> >> I guess we should populate WIndow owner with this frame object. >> >> But since this NPE problem is specific to mac,can we fix this bug first >> as the other platforms has same null check code in >> Toolkit.getPrintJob() and create another bug for this frame usage. >> Please let me know your thoughts. >> >> BTW, >> It was not seen (ie NPE is thrown) for native dialog in mac as in >> initPrintJob2D() we have this check >> if (frame == null && >> (jobAttributes == null || >> jobAttributes.getDialog() == DialogType.NATIVE)) { >> throw new NullPointerException("Frame must not be null"); >> } >> >> Regards >> Prasanta >> On 4/12/2016 10:43 PM, Phil Race wrote: >>> hmm .. if it does not throw NPE when the dialog type is common that >>> could mean >>> that the code is not referencing the frame as a modal parent /owner >>> in that case which could >>> be another bug. >>> Did you check into how this is used relative to other platforms ? >>> >>> -phil. >>> >>> >>> On 04/12/2016 04:16 AM, prasanta sadhukhan wrote: >>>> Hi All, >>>> >>>> Please review a fix for jdk9. >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154057 >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8154057/webrev.00/ >>>> >>>> As per spec, Toolkit.getPrintJob() should throw NPE if null frame >>>> object is passed to it. >>>> But on macos, it seems getPrintJob() does not check for null frame >>>> and show the print dialog. >>>> >>>> Fix is to check for null frame which is same as what we do in >>>> windows (WToolkit) and linux (XToolkit). >>>> >>>> Regards >>>> Prasanta >>> >> From alexey.ivanov at oracle.com Thu Apr 14 09:00:51 2016 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Thu, 14 Apr 2016 12:00:51 +0300 Subject: [OpenJDK 2D-Dev] [PATCH] JDK-8146035: Windows - With LCD antialiasing, some glyphs are not rendered correctly In-Reply-To: <570D2EE1.1040809@oracle.com> References: <570D2EE1.1040809@oracle.com> Message-ID: <570F5C43.6060601@oracle.com> Hi Phil, Thank you very much for your reviewing the code and approving the fix. I have uploaded the webrev to OpenJDK: http://cr.openjdk.java.net/~aivanov/dmitry.batrak/8146035/jdk9/webrev.00/ The patch is the same. On 12.04.2016 20:22, Phil Race wrote: > Alexey didn't say this but he already proposed exactly this fix himself > in a private email exchange, I didn't say that because it was Dmitry who was the original author of the fix. :) Alex and I asked Dmitry to submit his fix to the public alias to give him proper credit as the author of the fix. Regards, Alexey > > +1, although I am not sure we can legally pull down the patch from > that (any) website. > Please resubmit it as a diff in the email. > > Or Alexey could just push it as his own :-) > > -phil. > > On 04/07/2016 05:26 AM, Dmitry Batrak wrote: >> Hello, >> >> I'd like to propose a fix for JDK-8146035. I am not a committer, >> so I hope someone can sponsor this fix. >> I work at Jetbrains, which has signed a company-level contributor >> agreement, >> so, from a legal perspective, I believe, there are no obstacles. >> >> My investigation shows that the issue is caused by incorrect >> determination >> of bitmap size, prepared for glyph rendering, so only part of glyph >> becomes visible due to cropping. This seems to happen because >> compatible bitmap is not selected into memory device context (DC) >> before calling GetTextMetrics. Documentation for CreateCompatibleDC call >> (https://msdn.microsoft.com/en-us/library/windows/desktop/dd183489%28v=vs.85%29.aspx) >> >> says compatible bitmap needs to be selected into DC before any >> drawing operation. >> Even though GetTextMetrics is not a drawing operation, it turns out >> to be affected by selected bitmap's type too (by default a monochrome >> bitmap >> is selected in a memory DC). This behaviour was also mentioned in the >> following >> MSDN blog post comment: >> https://blogs.msdn.microsoft.com/oldnewthing/20060614-00/?p=30873#comment-392143 >> >> >> The proposed fix is to select a temporary 1x1 compatible bitmap >> into memory DC before GetTextMetrics call. >> Here's webrev link - http://adm-12504.intellij.net/ >> I didn't create a test case, as it would require a specific font file >> (I couldn't reproduce the issue for fonts bundled with Windows). >> >> Best regards, >> Dmitry Batrak > From Sergey.Bylokhov at oracle.com Thu Apr 14 13:12:54 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 14 Apr 2016 16:12:54 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 7102282 TEST_BUG: sun/java2d/OpenGL/GradientPaints.java should be modified In-Reply-To: <570E334F.7030000@oracle.com> References: <570D7891.5010408@oracle.com> <570E3284.2080709@oracle.com> <570E334F.7030000@oracle.com> Message-ID: <570F9756.3030900@oracle.com> On 13.04.16 14:53, prasanta sadhukhan wrote: > I guess you forgot to add 7102282 to the bugid. Thanks for review! The fix is updated: http://cr.openjdk.java.net/~serb/7102282/webrev.01 > > Regards > Prasanta >> >> On 04/13/2016 01:37 AM, Sergey Bylokhov wrote: >>> Hello,bu >>> Please review the fix for jdk9. >>> >>> This test uncover a few issues: >>> Test bug: >>> - Fail on HiDPI system, because the test tries to check the rendering >>> to the BufferedImage and VolaileImage using some threshold. Fixed by the >>> "-Dsun.java2d.uiScale=1" option. >>> >>> jdk bug: >>> - timeout error (in the bug the value 800 is suggested). It seems a >>> duplicate of JDK-8041129 [1]. Anyway 800 is to big, and should be >>> considered as a jdk bug(if will be reproduced on the latest jdk9). >>> - Incorrect rendering on some systems and video cards (especially on >>> linux), is covered by JDK-7124403 [2] >>> >>> Since OGL performance should be fixed already, I updated the test only >>> for the retina case. After the fix I think the test is ok, and other >>> possible failures should be considered as a jdk bugs. >>> >>> I also create a new bug JDK-8154103 [3] to check the performance of >>> XRender pipeline, it is slower than x11 and ogl. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8041129 >>> [2] https://bugs.openjdk.java.net/browse/JDK-7124403 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8154103 >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-7102282 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/7102282/webrev.00 >>> >> > -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Thu Apr 14 14:01:47 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Thu, 14 Apr 2016 19:31:47 +0530 Subject: [OpenJDK 2D-Dev] [9] Review Request: 7102282 TEST_BUG: sun/java2d/OpenGL/GradientPaints.java should be modified In-Reply-To: <570F9756.3030900@oracle.com> References: <570D7891.5010408@oracle.com> <570E3284.2080709@oracle.com> <570E334F.7030000@oracle.com> <570F9756.3030900@oracle.com> Message-ID: <570FA2CB.5000606@oracle.com> Looks good to me. Regards Prasanta On 4/14/2016 6:42 PM, Sergey Bylokhov wrote: > On 13.04.16 14:53, prasanta sadhukhan wrote: >> I guess you forgot to add 7102282 to the bugid. > > Thanks for review! The fix is updated: > http://cr.openjdk.java.net/~serb/7102282/webrev.01 > >> >> Regards >> Prasanta >>> >>> On 04/13/2016 01:37 AM, Sergey Bylokhov wrote: >>>> Hello,bu >>>> Please review the fix for jdk9. >>>> >>>> This test uncover a few issues: >>>> Test bug: >>>> - Fail on HiDPI system, because the test tries to check the >>>> rendering >>>> to the BufferedImage and VolaileImage using some threshold. Fixed >>>> by the >>>> "-Dsun.java2d.uiScale=1" option. >>>> >>>> jdk bug: >>>> - timeout error (in the bug the value 800 is suggested). It seems a >>>> duplicate of JDK-8041129 [1]. Anyway 800 is to big, and should be >>>> considered as a jdk bug(if will be reproduced on the latest jdk9). >>>> - Incorrect rendering on some systems and video cards (especially on >>>> linux), is covered by JDK-7124403 [2] >>>> >>>> Since OGL performance should be fixed already, I updated the test only >>>> for the retina case. After the fix I think the test is ok, and other >>>> possible failures should be considered as a jdk bugs. >>>> >>>> I also create a new bug JDK-8154103 [3] to check the performance of >>>> XRender pipeline, it is slower than x11 and ogl. >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8041129 >>>> [2] https://bugs.openjdk.java.net/browse/JDK-7124403 >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8154103 >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7102282 >>>> Webrev can be found at: >>>> http://cr.openjdk.java.net/~serb/7102282/webrev.00 >>>> >>> >> > > From prasanta.sadhukhan at oracle.com Thu Apr 14 14:03:53 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Thu, 14 Apr 2016 19:33:53 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6921664, , The amount of copies and the printer job name is not passed to the implementing In-Reply-To: <570E6732.8060807@oracle.com> References: <57024E33.3000801@oracle.com> <570E6732.8060807@oracle.com> Message-ID: <570FA349.2090101@oracle.com> Hi Jay, Could you please give your +1 on this? Regards Prasanta On 4/13/2016 9:05 PM, Philip Race wrote: > I have updated the synopsis, please use this in the commit :- > "The number of copies and the job name are not passed to a 3rd party > PrintService" > > Fix looks fine. > > -phil > > > On 4/4/16, 4:21 AM, prasanta sadhukhan wrote: >> Hi All, >> >> Please review a fix for jdk9 >> Bug: https://bugs.openjdk.java.net/browse/JDK-6921664 >> webrev: http://cr.openjdk.java.net/~psadhukhan/6921664/webrev.00/ >> >> The issue was >> for a third party non-builtin print service, if the application sets >> the copies, jobname attribute these attributes are not passed to the >> third party print() implementation. >> This is because when we find there is a non-builtin print service, we >> call spoolService() in RasterPrinterJob >> which , even though it creates an attribute set via attributes = new >> HashPrintRequestAttributeSet(); >> but it does not populate the attributes with the attributes set by >> the application, so when we call job.print(doc, attributes); we were >> passing attributes without any attribute set. >> >> I added the minimal copies and jobName attributes to the attribute >> list before calling the 3rdparty print implementation. >> >> Regards >> Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Thu Apr 14 14:04:18 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Thu, 14 Apr 2016 19:34:18 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6801613, , Cross-platform pageDialog and printDialog top margin entry broken In-Reply-To: <570E68C7.6040605@oracle.com> References: <57039CB7.7090300@oracle.com> <570E68C7.6040605@oracle.com> Message-ID: <570FA362.50609@oracle.com> Hi Jay, Could you please give your +1 on this? Regards Prasanta On 4/13/2016 9:11 PM, Philip Race wrote: > +1 although I think robot may be able to automate this. > > -phil. > > On 4/5/16, 4:08 AM, prasanta sadhukhan wrote: >> Hi All, >> >> Please review a fix for jdk9 >> Bug: https://bugs.openjdk.java.net/browse/JDK-6801613 >> webrev: http://cr.openjdk.java.net/~psadhukhan/6801613/webrev.00/ >> >> The issue was the PrinterJob cross-platform "Page setup dialog" top >> margin entry is broken. >> If you enter a value in the top margin field and hit "OK", the value >> is not updated in the PageFormat instance return value, >> nor is it updated in the attribute set used to call the pageDialog >> method. >> Tabbing out of the top margin field before hitting OK does not fix >> the problem. >> Likewise, clicking on a different margin entry field before hitting >> OK also does not fix the problem. >> >> The reason was we created topMargin JFormattedTextField once and >> added focusListener and ActionListener to this textfield but >> we overwrote the topMargin textField again by creating another >> instance and in that instance, we failed to add actionListener or >> focusListener, >> so when we tabbed out of topmargin field, focusLost() method was not >> called which would have called updateMargin() method to update the >> margins. >> >> Fix was to remove this erroneous instance creation and overwriting of >> topMargin textfield. >> >> Regards >> Prasanta From jennifer.godinez at oracle.com Thu Apr 14 19:30:53 2016 From: jennifer.godinez at oracle.com (Jennifer Godinez) Date: Thu, 14 Apr 2016 12:30:53 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8134986: Incorrect use of ConcurrentHashMap.contains in SunFontManager.java In-Reply-To: <5702EBA5.1020304@oracle.com> References: <5702EBA5.1020304@oracle.com> Message-ID: <570FEFED.3040900@oracle.com> Looks good. Jennifer On 04/04/2016 03:33 PM, Phil Race wrote: > https://bugs.openjdk.java.net/browse/JDK-8134986 > > When converted from a HashSet to a HashMap contains() should have > changed to containsKey(). It does not lead to duplicate fonts because > it is caught later on but it might lead to wasted work > > One line fix in line below > > diff --git > a/src/java.desktop/share/classes/sun/font/SunFontManager.java > b/src/java.desktop/share/classes/sun/font/SunFontManager.java > --- a/src/java.desktop/share/classes/sun/font/SunFontManager.java > +++ b/src/java.desktop/share/classes/sun/font/SunFontManager.java > @@ -1843,7 +1843,7 @@ > > private PhysicalFont registerFontFile(String file) { > if (new File(file).isAbsolute() && > - !registeredFonts.contains(file)) { > + !registeredFonts.containsKey(file)) { > int fontFormat = FONTFORMAT_NONE; > int fontRank = Font2D.UNKNOWN_RANK; > if (ttFilter.accept(null, file)) { > > > -phil. > From jayathirth.d.v at oracle.com Fri Apr 15 04:39:51 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 14 Apr 2016 21:39:51 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6921664, , The amount of copies and the printer job name is not passed to the implementing In-Reply-To: <570FA349.2090101@oracle.com> References: <57024E33.3000801@oracle.com> <570E6732.8060807@oracle.com> <570FA349.2090101@oracle.com> Message-ID: <22fa6ba2-b133-4120-a5fa-9aedb54543da@default> Hi Prasanta, ? Change is working fine, +1. Additional comments : Please add your analysis in JBS and also remove/update the present Javadoc comment in test case and add Override annotation for subclasses present in test case. ? Thanks, Jay ? From: prasanta sadhukhan Sent: Thursday, April 14, 2016 7:34 PM To: Philip Race Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9] RFR: JDK-6921664, , The amount of copies and the printer job name is not passed to the implementing ? Hi Jay, Could you please give your +1 on this? Regards Prasanta On 4/13/2016 9:05 PM, Philip Race wrote: I have updated the synopsis, please use this in the commit :- "The number of copies and the job name are not passed to a 3rd party PrintService" Fix looks fine. -phil On 4/4/16, 4:21 AM, prasanta sadhukhan wrote: Hi All, Please review a fix for jdk9 Bug: https://bugs.openjdk.java.net/browse/JDK-6921664 webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/6921664/webrev.00/"http://cr.openjdk.java.net/~psadhukhan/6921664/webrev.00/ The issue was for a third party non-builtin print service, if the application sets the copies, jobname attribute these attributes are not passed to the third party print() implementation. This is because when we find there is a non-builtin print service, we call spoolService() in RasterPrinterJob which , even though it creates an attribute set via attributes = new HashPrintRequestAttributeSet(); but it does not populate the attributes with the attributes set by the application, so when we call job.print(doc, attributes); we were passing attributes without any attribute set. I added the minimal copies and jobName attributes to the attribute list before calling the 3rdparty print implementation. Regards Prasanta ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Fri Apr 15 05:16:53 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 14 Apr 2016 22:16:53 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6801613, , Cross-platform pageDialog and printDialog top margin entry broken In-Reply-To: <570FA362.50609@oracle.com> References: <57039CB7.7090300@oracle.com> <570E68C7.6040605@oracle.com> <570FA362.50609@oracle.com> Message-ID: <42d836f2-d8c9-4ffb-8ff2-882f836aafd6@default> Hi Prasanta, Changes are working fine. Jtreg comment in test case is not properly indented and add '*' for each multiline as per coding guidelines before pushing the change. Also summary of test case should mention about what is test doing, instead of the problem statement. Thanks, Jay -----Original Message----- From: prasanta sadhukhan Sent: Thursday, April 14, 2016 7:34 PM To: Philip Race Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-6801613, , Cross-platform pageDialog and printDialog top margin entry broken Hi Jay, Could you please give your +1 on this? Regards Prasanta On 4/13/2016 9:11 PM, Philip Race wrote: > +1 although I think robot may be able to automate this. > > -phil. > > On 4/5/16, 4:08 AM, prasanta sadhukhan wrote: >> Hi All, >> >> Please review a fix for jdk9 >> Bug: https://bugs.openjdk.java.net/browse/JDK-6801613 >> webrev: http://cr.openjdk.java.net/~psadhukhan/6801613/webrev.00/ >> >> The issue was the PrinterJob cross-platform "Page setup dialog" top >> margin entry is broken. >> If you enter a value in the top margin field and hit "OK", the value >> is not updated in the PageFormat instance return value, nor is it >> updated in the attribute set used to call the pageDialog method. >> Tabbing out of the top margin field before hitting OK does not fix >> the problem. >> Likewise, clicking on a different margin entry field before hitting >> OK also does not fix the problem. >> >> The reason was we created topMargin JFormattedTextField once and >> added focusListener and ActionListener to this textfield but we >> overwrote the topMargin textField again by creating another instance >> and in that instance, we failed to add actionListener or >> focusListener, so when we tabbed out of topmargin field, focusLost() >> method was not called which would have called updateMargin() method >> to update the margins. >> >> Fix was to remove this erroneous instance creation and overwriting of >> topMargin textfield. >> >> Regards >> Prasanta From jayathirth.d.v at oracle.com Fri Apr 15 05:24:32 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 14 Apr 2016 22:24:32 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8154057, , [macosx] getPrintJob doesn't throw NPE if Frame is null AND type is COMMON In-Reply-To: <570F2AE6.3020605@oracle.com> References: <570CD915.8060803@oracle.com> <570D2CC5.5030303@oracle.com> <570DFF94.7020101@oracle.com> <570E6CF8.9050307@oracle.com> <570F2AE6.3020605@oracle.com> Message-ID: <80761ff2-04fc-4c24-a9c6-79763f553d3a@default> Hi Prasanta, Changes are fine. Please add your analysis in JBS. Some lines in test case has more than 80 characters, please update them before pushing. I have updated the OS and CPU as generic for new bug https://bugs.openjdk.java.net/browse/JDK-8154218 since we know it is common problem among all platforms. Thanks, Jay -----Original Message----- From: prasanta sadhukhan Sent: Thursday, April 14, 2016 11:00 AM To: Philip Race Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9] RFR: JDK-8154057, , [macosx] getPrintJob doesn't throw NPE if Frame is null AND type is COMMON Thanks for the review. I have filed a new issue for this non-usage of frame https://bugs.openjdk.java.net/browse/JDK-8154218 Regards Prasanta On 4/13/2016 9:29 PM, Philip Race wrote: > Ok, so +1 to this fix but file a new bug to track the non-usage of the > owner frame. > > -phil. > > On 4/13/16, 1:13 AM, prasanta sadhukhan wrote: >> Hi Phil, >> >> Yes, it seems code does not use this frame as parent/owner. >> Actually, xxxToolkit will call initPrintJob2D() after checking for >> frame==null, followed by PrintJob2D.printDialog() which will just >> store the frame in the attribute if (frame != null) { >> attributes.add(new DialogOwner(frame)); >> } >> and then call ServiceUI.printDialog() which just pass null as owner >> to ServiceDialog() for now. >> >> // For now we set owner to null. In the future, it may be passed >> // as an argument. >> Window owner = null; >> >> dialog = new ServiceDialog(gc, >> x, >> y, >> services, defaultIndex, >> flavor, attributes, >> (Dialog)owner); and so this >> behaviour is common to all platforms. >> >> I guess we should populate WIndow owner with this frame object. >> >> But since this NPE problem is specific to mac,can we fix this bug >> first as the other platforms has same null check code in >> Toolkit.getPrintJob() and create another bug for this frame usage. >> Please let me know your thoughts. >> >> BTW, >> It was not seen (ie NPE is thrown) for native dialog in mac as in >> initPrintJob2D() we have this check >> if (frame == null && >> (jobAttributes == null || >> jobAttributes.getDialog() == DialogType.NATIVE)) { >> throw new NullPointerException("Frame must not be null"); >> } >> >> Regards >> Prasanta >> On 4/12/2016 10:43 PM, Phil Race wrote: >>> hmm .. if it does not throw NPE when the dialog type is common that >>> could mean that the code is not referencing the frame as a modal >>> parent /owner in that case which could be another bug. >>> Did you check into how this is used relative to other platforms ? >>> >>> -phil. >>> >>> >>> On 04/12/2016 04:16 AM, prasanta sadhukhan wrote: >>>> Hi All, >>>> >>>> Please review a fix for jdk9. >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154057 >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8154057/webrev.00/ >>>> >>>> As per spec, Toolkit.getPrintJob() should throw NPE if null frame >>>> object is passed to it. >>>> But on macos, it seems getPrintJob() does not check for null frame >>>> and show the print dialog. >>>> >>>> Fix is to check for null frame which is same as what we do in >>>> windows (WToolkit) and linux (XToolkit). >>>> >>>> Regards >>>> Prasanta >>> >> From prasanta.sadhukhan at oracle.com Fri Apr 15 05:47:50 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Fri, 15 Apr 2016 11:17:50 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6921664, , The amount of copies and the printer job name is not passed to the implementing In-Reply-To: <22fa6ba2-b133-4120-a5fa-9aedb54543da@default> References: <57024E33.3000801@oracle.com> <570E6732.8060807@oracle.com> <570FA349.2090101@oracle.com> <22fa6ba2-b133-4120-a5fa-9aedb54543da@default> Message-ID: <57108086.6050607@oracle.com> Thanks Jay. Please find the new webrev adding @Override annotation and I also changed the copyright to 2016. http://cr.openjdk.java.net/~psadhukhan/6921664/webrev.01/ Regards Prasanta On 4/15/2016 10:09 AM, Jayathirth D V wrote: > > Hi Prasanta, > > Change is working fine, +1. > > Additional comments : Please add your analysis in JBS and also > remove/update the present Javadoc comment in test case and add > Override annotation for subclasses present in test case. > > . > > Thanks, > > Jay > > *From:*prasanta sadhukhan > *Sent:* Thursday, April 14, 2016 7:34 PM > *To:* Philip Race > *Cc:* 2d-dev at openjdk.java.net > *Subject:* Re: [OpenJDK 2D-Dev] [9] RFR: JDK-6921664, , The amount of > copies and the printer job name is not passed to the implementing > > Hi Jay, > > Could you please give your +1 on this? > > Regards > Prasanta > > On 4/13/2016 9:05 PM, Philip Race wrote: > > I have updated the synopsis, please use this in the commit :- > "The number of copies and the job name are not passed to a 3rd > party PrintService" > > Fix looks fine. > > -phil > > > On 4/4/16, 4:21 AM, prasanta sadhukhan wrote: > > Hi All, > > Please review a fix for jdk9 > Bug: https://bugs.openjdk.java.net/browse/JDK-6921664 > webrev: > http://cr.openjdk.java.net/~psadhukhan/6921664/webrev.00/ > > > The issue was > for a third party non-builtin print service, if the > application sets the copies, jobname attribute these > attributes are not passed to the third party print() > implementation. > This is because when we find there is a non-builtin print > service, we call spoolService() in RasterPrinterJob > which , even though it creates an attribute set via attributes > = new HashPrintRequestAttributeSet(); > but it does not populate the attributes with the attributes > set by the application, so when we call job.print(doc, > attributes); we were passing attributes without any attribute > set. > > I added the minimal copies and jobName attributes to the > attribute list before calling the 3rdparty print implementation. > > Regards > Prasanta > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Fri Apr 15 05:54:11 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 14 Apr 2016 22:54:11 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6921664, , The amount of copies and the printer job name is not passed to the implementing In-Reply-To: <57108086.6050607@oracle.com> References: <57024E33.3000801@oracle.com> <570E6732.8060807@oracle.com> <570FA349.2090101@oracle.com> <22fa6ba2-b133-4120-a5fa-9aedb54543da@default> <57108086.6050607@oracle.com> Message-ID: Looks fine. ? From: prasanta sadhukhan Sent: Friday, April 15, 2016 11:18 AM To: Jayathirth D V; Philip Race Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9] RFR: JDK-6921664, , The amount of copies and the printer job name is not passed to the implementing ? Thanks Jay. Please find the new webrev adding @Override annotation and I also changed the copyright to 2016. http://cr.openjdk.java.net/~psadhukhan/6921664/webrev.01/ Regards Prasanta On 4/15/2016 10:09 AM, Jayathirth D V wrote: Hi Prasanta, ? Change is working fine, +1. Additional comments : Please add your analysis in JBS and also remove/update the present Javadoc comment in test case and add Override annotation for subclasses present in test case. ?. Thanks, Jay ? From: prasanta sadhukhan Sent: Thursday, April 14, 2016 7:34 PM To: Philip Race Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9] RFR: JDK-6921664, , The amount of copies and the printer job name is not passed to the implementing ? Hi Jay, Could you please give your +1 on this? Regards Prasanta On 4/13/2016 9:05 PM, Philip Race wrote: I have updated the synopsis, please use this in the commit :- "The number of copies and the job name are not passed to a 3rd party PrintService" Fix looks fine. -phil On 4/4/16, 4:21 AM, prasanta sadhukhan wrote: Hi All, Please review a fix for jdk9 Bug: https://bugs.openjdk.java.net/browse/JDK-6921664 webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/6921664/webrev.00/"http://cr.openjdk.java.net/~psadhukhan/6921664/webrev.00/ The issue was for a third party non-builtin print service, if the application sets the copies, jobname attribute these attributes are not passed to the third party print() implementation. This is because when we find there is a non-builtin print service, we call spoolService() in RasterPrinterJob which , even though it creates an attribute set via attributes = new HashPrintRequestAttributeSet(); but it does not populate the attributes with the attributes set by the application, so when we call job.print(doc, attributes); we were passing attributes without any attribute set. I added the minimal copies and jobName attributes to the attribute list before calling the 3rdparty print implementation. Regards Prasanta ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Fri Apr 15 06:06:20 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Fri, 15 Apr 2016 11:36:20 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6801613, , Cross-platform pageDialog and printDialog top margin entry broken In-Reply-To: <42d836f2-d8c9-4ffb-8ff2-882f836aafd6@default> References: <57039CB7.7090300@oracle.com> <570E68C7.6040605@oracle.com> <570FA362.50609@oracle.com> <42d836f2-d8c9-4ffb-8ff2-882f836aafd6@default> Message-ID: <571084DC.7090705@oracle.com> Thanks Jay. Please find the modified webrev with proper indentation of testcase. http://cr.openjdk.java.net/~psadhukhan/6801613/webrev.01/ Regards Prasanta On 4/15/2016 10:46 AM, Jayathirth D V wrote: > Hi Prasanta, > > Changes are working fine. > Jtreg comment in test case is not properly indented and add '*' for each multiline as per coding guidelines before pushing the change. > Also summary of test case should mention about what is test doing, instead of the problem statement. > > Thanks, > Jay > > -----Original Message----- > From: prasanta sadhukhan > Sent: Thursday, April 14, 2016 7:34 PM > To: Philip Race > Cc: 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-6801613, , Cross-platform pageDialog and printDialog top margin entry broken > > Hi Jay, > > Could you please give your +1 on this? > > Regards > Prasanta > > On 4/13/2016 9:11 PM, Philip Race wrote: >> +1 although I think robot may be able to automate this. >> >> -phil. >> >> On 4/5/16, 4:08 AM, prasanta sadhukhan wrote: >>> Hi All, >>> >>> Please review a fix for jdk9 >>> Bug: https://bugs.openjdk.java.net/browse/JDK-6801613 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/6801613/webrev.00/ >>> >>> The issue was the PrinterJob cross-platform "Page setup dialog" top >>> margin entry is broken. >>> If you enter a value in the top margin field and hit "OK", the value >>> is not updated in the PageFormat instance return value, nor is it >>> updated in the attribute set used to call the pageDialog method. >>> Tabbing out of the top margin field before hitting OK does not fix >>> the problem. >>> Likewise, clicking on a different margin entry field before hitting >>> OK also does not fix the problem. >>> >>> The reason was we created topMargin JFormattedTextField once and >>> added focusListener and ActionListener to this textfield but we >>> overwrote the topMargin textField again by creating another instance >>> and in that instance, we failed to add actionListener or >>> focusListener, so when we tabbed out of topmargin field, focusLost() >>> method was not called which would have called updateMargin() method >>> to update the margins. >>> >>> Fix was to remove this erroneous instance creation and overwriting of >>> topMargin textfield. >>> >>> Regards >>> Prasanta From jayathirth.d.v at oracle.com Fri Apr 15 06:12:28 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 14 Apr 2016 23:12:28 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6801613, , Cross-platform pageDialog and printDialog top margin entry broken In-Reply-To: <571084DC.7090705@oracle.com> References: <57039CB7.7090300@oracle.com> <570E68C7.6040605@oracle.com> <570FA362.50609@oracle.com> <42d836f2-d8c9-4ffb-8ff2-882f836aafd6@default> <571084DC.7090705@oracle.com> Message-ID: <6c280da6-5f2b-41c0-84fd-3196652495b8@default> Hi Prasanta, +1.Last line of jtreg comment is still not proper. No need for one more webrev. Please change it before pushing. Thanks, Jay -----Original Message----- From: prasanta sadhukhan Sent: Friday, April 15, 2016 11:36 AM To: Jayathirth D V Cc: 2d-dev at openjdk.java.net; Philip Race Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-6801613, , Cross-platform pageDialog and printDialog top margin entry broken Thanks Jay. Please find the modified webrev with proper indentation of testcase. http://cr.openjdk.java.net/~psadhukhan/6801613/webrev.01/ Regards Prasanta On 4/15/2016 10:46 AM, Jayathirth D V wrote: > Hi Prasanta, > > Changes are working fine. > Jtreg comment in test case is not properly indented and add '*' for each multiline as per coding guidelines before pushing the change. > Also summary of test case should mention about what is test doing, instead of the problem statement. > > Thanks, > Jay > > -----Original Message----- > From: prasanta sadhukhan > Sent: Thursday, April 14, 2016 7:34 PM > To: Philip Race > Cc: 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-6801613, , Cross-platform > pageDialog and printDialog top margin entry broken > > Hi Jay, > > Could you please give your +1 on this? > > Regards > Prasanta > > On 4/13/2016 9:11 PM, Philip Race wrote: >> +1 although I think robot may be able to automate this. >> >> -phil. >> >> On 4/5/16, 4:08 AM, prasanta sadhukhan wrote: >>> Hi All, >>> >>> Please review a fix for jdk9 >>> Bug: https://bugs.openjdk.java.net/browse/JDK-6801613 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/6801613/webrev.00/ >>> >>> The issue was the PrinterJob cross-platform "Page setup dialog" top >>> margin entry is broken. >>> If you enter a value in the top margin field and hit "OK", the >>> value is not updated in the PageFormat instance return value, nor is >>> it updated in the attribute set used to call the pageDialog method. >>> Tabbing out of the top margin field before hitting OK does not fix >>> the problem. >>> Likewise, clicking on a different margin entry field before hitting >>> OK also does not fix the problem. >>> >>> The reason was we created topMargin JFormattedTextField once and >>> added focusListener and ActionListener to this textfield but we >>> overwrote the topMargin textField again by creating another instance >>> and in that instance, we failed to add actionListener or >>> focusListener, so when we tabbed out of topmargin field, focusLost() >>> method was not called which would have called updateMargin() method >>> to update the margins. >>> >>> Fix was to remove this erroneous instance creation and overwriting >>> of topMargin textfield. >>> >>> Regards >>> Prasanta From prasanta.sadhukhan at oracle.com Fri Apr 15 07:05:01 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Fri, 15 Apr 2016 12:35:01 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6197099 : PrinterJob.getUserName() throws a security exception when user.name permission is not given In-Reply-To: <570E5930.1060809@oracle.com> References: <5704F4CA.3020108@oracle.com> <570DD7BF.90506@oracle.com> <570E5930.1060809@oracle.com> Message-ID: <5710929D.3050808@oracle.com> Hi Phil, Please find the modified webrev with the testcase: http://cr.openjdk.java.net/~psadhukhan/6197099/webrev.01/ Regards Prasanta On 4/13/2016 8:05 PM, Philip Race wrote: > This needs a test. You can provide one by following other similar > examples. > Also it needs a CCC to document the exception. > Finally, I am a bit surprised at the exact exception. > Where precisely does this originate (stack trace, please) ? > Probably we should throw SecurityException instead, even > if it is not the exact behaviour today. > Just make sure that our own code is ready for such a change. > > -phil. > > On 4/12/16, 10:23 PM, prasanta sadhukhan wrote: >> Resending with bugid in the subject line. >> >> On 4/6/2016 5:06 PM, prasanta sadhukhan wrote: >>> Hi All, >>> >>> Please review a document fix for jdk9 >>> Bug: https://bugs.openjdk.java.net/browse/JDK-6197099 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/6197099/webrev.00/ >>> >>> PrinterJob.getUserName() is supposed to return the current user name >>> of the system. This method does not document any exception. >>> But when SecurityManager is installed, this method throws a security >>> exception when PropertyPermission - user.name is not given in the >>> policy file. >>> But this is not documented anywhere and hence the user will not know >>> until he gets the exception. >>> >>> Documented the long-standing existing exception. >>> >>> will raise a ccc after the technical review. >>> >>> Regards >>> Prasanta >> From prahalad.kumar.narayanan at oracle.com Fri Apr 15 07:25:09 2016 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Fri, 15 Apr 2016 00:25:09 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: Antialiased text on translucent backgrounds gets bright artifacts In-Reply-To: <5702DE6F.5000903@oracle.com> References: <63d69ba8-d5cf-4697-bb5c-f51aaaa8c427@default> <56EB4DBB.9080802@oracle.com> <56F3505B.2070101@oracle.com> <215e497a-db82-4f6f-99e9-bd44f25d5999@default> <56FAF088.70300@oracle.com> <6b400fd0-a335-46a5-9fed-abb06c3fd6a0@default> <56FC33F6.1060108@oracle.com> <5702DE6F.5000903@oracle.com> Message-ID: <4213d5c2-3711-4631-87a3-ba40c1e5ceeb@default> Hello Jim & Everyone on Java2D Community Good day to you. This is a review request and a follow-up to the bug-fix for the issue Bug : JDK-8015070 Link : https://bugs.openjdk.java.net/browse/JDK-8015070 Webrev Link : http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.04/ Quick Inferences on Changes in Current -Webrev.04 1 ) Subtle changes to the blend loop- . The subtle changes taken up, have helped to improve the performance. . With the current logic in webrev.04, Java2DBench reports better performance than Un-Optimized solution that was present in webrev.00 . J2DBench was run for Font Styles { Plain, Bold, Italic, Bold n Italic } and Font Sizes { 12, 20, 36, 72 } . My sincere thanks to Jim for all his detailed feedback through the multiple reviews that has evolved the solution today. (Details on changes) 1.a. Loading of Color components . When modelled as per SRCOVER_MASK_FILL code, the logic required few additional calculations to load color components. . The extra calculations indeed impacted performance figures. . This could be offset in two possible ways a. Inspect parent macro- NAME_SOLID_DRAWGLYPHLISTAA and advance by pixel address and not by pixel index. The parent macro invokes GlyphListAABlendFourByteArgb through this macro- GlyphListAABlend ## STRATEGY(DST, pixels, x, pPix, fgpixel, solidpix, src); Changing parent macro will cause spurious changes across GlyphListAABlend ## other pixel formats. There is additional risk of breaking the stable and well optimized LoopMacros.h. b. Load color components based on pre-Multiplication status This has been taken up and change is limited to the function being modified. Thankfully J2DBench has still reported improvement in performance. 1.b. New Macro to avoid if (DST ## IsPremultiplied) { . A new macro- DeclareAndInit ## DST ## SrcOverMaskBlendFactor has been introduced to choose between dstF, or dstA . The implementation is available in the header files of pixel formats ( Eg: IntArgb.h IntArgbPre.h ) . There are 29 different pixel formats known to Java2D, and . Hence, the new macro's implementation is added only to those pixel formats that require the current glyph blending logic. 2 ) Testing across different formats . The Regression test code has been modified to test anti-aliased text rendering on 7 different pixel formats- . IntArgb, IntArgb_Pre, FourByteAbgr, FourByteAbgr_Pre, IntRGB, IntBGR, 3ByteBGR. . As expected, the test fails without the fix on JDK 8 and JDK 7 versions & passes with JDK 9-internal containing the fix. 3 ) Explanation on Code Changes : . With multiple reviews and changes, today the code fixes the bug and is well optimized as well. . For ease of reviewer and effort in review, I 've explained the logic with /* comment statements */ herewith. . Note: These comments don't figure in the webrev. As one cannot guarantee how /* comments */ within macros would be perceived by compiler across different platforms. #define GlyphListAABlend4ByteArgb(DST, GLYPH_PIXELS, PIXEL_INDEX, DST_PTR, \ FG_PIXEL, PREFIX, SRC_PREFIX) \ do { \ DeclareAlphaVarFor4ByteArgb(resA) \ DeclareCompVarsFor4ByteArgb(res) \ jint mixValSrc = GLYPH_PIXELS[PIXEL_INDEX]; \ if (mixValSrc) { \ /* Evaluating srcColor components */ \ if (mixValSrc != 0xff) { \ /* No-op. Retained to match reference as SRCOVER_MASK_FILL */ \ PromoteByteAlphaFor4ByteArgb(mixValSrc); \ /* Glyph mask determines visibility of the srcColor */ \ resA = MultiplyAlphaFor4ByteArgb(mixValSrc, SRC_PREFIX ## A); \ MultiplyAndStore4ByteArgbComps(res, resA, SRC_PREFIX); \ } else { \ /* If mixValSrc and srcA are maximum, then result color is */ \ /* opaque. Hence the fast path to store foreground pixel */ \ /* color and return. */ \ if (SRC_PREFIX ## A == MaxValFor4ByteArgb) { \ Store ## DST ## PixelData(DST_PTR, PIXEL_INDEX, \ FG_PIXEL, PREFIX); \ break; \ } \ /* This is understood easier with floating point logic. */ \ /* 1.0f is max value used in floating point calculation */ \ /* (1.0f * srcA) gives srcA. Hence we directly consider */ \ /* srcA without Multiply with glyph mask. */ \ resA = SRC_PREFIX ## A; \ MultiplyAndStore4ByteArgbComps(res, \ SRC_PREFIX ## A, \ SRC_PREFIX); \ } \ /* Evaluating dstColor components */ \ /* This is required only when resA(i.e., srcA) is not maximum */ \ if (resA != MaxValFor4ByteArgb) { \ DeclareAndInvertAlphaVarFor4ByteArgb(dstF, resA) \ DeclareAndClearAlphaVarFor4ByteArgb(dstA) \ DeclareCompVarsFor4ByteArgb(dst) \ DeclareCompVarsFor4ByteArgb(tmp) \ /* Based on the pixelFormat we could reduce calculations */ \ /* done to load the color and alpha components */ \ if (!(DST ## IsPremultiplied)) { \ Load ## DST ## To4ByteArgb(DST_PTR, pix, PIXEL_INDEX, \ dstA, dstR, dstG, dstB); \ Store4ByteArgbCompsUsingOp(tmp, =, dst); \ } else { \ Declare ## DST ## AlphaLoadData(DstPix) \ jint pixelOffset = PIXEL_INDEX * (DST ## PixelStride); \ DST ## DataType *pixelAddress = PtrAddBytes(DST_PTR, \ pixelOffset); \ /* The macro's implementation loads color components */ \ /* without divide by alpha adjustment as required for */ \ /* subsequent calculations. Note: This is used only */ \ /* with preMultiplied alpha based pixel formats */ \ LoadAlphaFrom ## DST ## For4ByteArgb(pixelAddress, \ DstPix, \ dst); \ Postload4ByteArgbFrom ## DST(pixelAddress, \ DstPix, \ tmp); \ } \ /* Avoid blending operatons if dst is fully transparent */ \ if (dstA) { \ /* dstA would be 0 if either of the following is true. */ \ /* 1. srcA is max. Parent if condition validates this. */ \ /* 2. dstA is zero. The current if condition validates */ \ /* Henceforth, the following Multiply need not be moved*/ \ /* ahead of the if condition. This also helps to better*/ \ /* performance */ \ dstA = MultiplyAlphaFor4ByteArgb(dstF, dstA); \ resA += dstA; \ /* Declares blendF variable and assigns appropriate */ \ /* alpha value. The definitions are contained in the*/ \ /* header files of respective pixel formats */ \ DeclareAndInit ## DST ## SrcOverDstBlendFactor(dstF, \ dstA, \ blendF); \ /* This is understood easier with floating point logic.*/ \ /* 1.0f is max value used in floating point calculation*/ \ /* (1.0f * tmp) gives tmp. Hence we avoid 3 Multiply */ \ /* operations and add the loaded color to result */ \ if (blendF != MaxValFor4ByteArgb) { \ MultiplyAndStore4ByteArgbComps(tmp, \ blendF, \ tmp); \ } \ Store4ByteArgbCompsUsingOp(res, +=, tmp); \ } \ } \ /* In the above calculations, color values are multiplied with */ \ /* with alpha. This is perfectly fine for pre-Multiplied alpha */ \ /* based pixel formats. For non pre-multiplied alpha based */ \ /* pixel formats, the alpha is removed from color components */ \ /* and then stored to the resulting color. */ \ if (!(DST ## IsOpaque) && \ !(DST ## IsPremultiplied) && resA && \ resA < MaxValFor4ByteArgb) \ { \ DivideAndStore4ByteArgbComps(res, res, resA); \ } \ Store ## DST ## From4ByteArgbComps(DST_PTR, pix, \ PIXEL_INDEX, res); \ } \ } while (0); My apologies if the above code did not appear on the final webrev email. ( In few instances, the newlines don't appear in plain-text format ) Kindly review the changes present in webrev and provide your views. If the changes are good, we could take up for the code check-in. Thank you for your time in review Have a good day Prahalad N. -----Original Message----- From: Jim Graham Sent: Tuesday, April 05, 2016 3:07 AM To: Prahalad Kumar Narayanan; Sergey Bylokhov; Philip Race Cc: Praveen Srivastava Subject: Re: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: Antialiased text on translucent backgrounds gets bright artifacts Hi Prahalad, Can I see the webrev diffs for the "today's experiment" code with the new macro? Also, Did you test this with opaque destinations? The most common use of text is on an opaque destination, so that would matter more. I would suggest: INT_RGB, THREE_BYTE_BGR, INT_ARGB, INT_ARGB_PRE in that order of precedence of importance. Also, test with translucent colors, though those are less important than opaque colors. I'm still looking at why the non-pre would be slower than the pre. About the only difference is the one line "if (!PRE) { DSTF = DSTA; }". One suggestion might be to move the test for transparent destination up a couple of lines, and to get rid of the extra "DSTF = dstA" assignement with the following structure: dstA = Mult...(); if (dstA) { resA += dstA; Declare... Postload... if (DST ## IsPremultiplied) { MultiplyAndStore(..., DSTF, ...); } else { MultiplyAndStore(..., dstA, ...); } Store... } Basically, dstA == 0 is the actual test for "do we need to even try to blend the destination in here". If it is zero then there is no need to add dstA to resA and there is no need to adjust the factor we blend by (MultiplyAndStore). It can be triggered by either a transparent destination pixel or an opaque source pixel, but either way, dstA is the right test, not DSTF. The second part, eliminating the DSTF=dstA assignment, gets rid of a line that might trip up the optimizer by simply having the macro expand differently for the two types. To be even more streamlined, we could create a new set of macros: // In the header files for PRE types: #define SRCOVER_DST_BLEND_FACTOR_(dF, dA) (dF) // In the header files for non-PRE types: #define SRCOVER_DST_BLEND_FACTOR_(dF, dA) (dA) Then we wouldn't need the test above for "if (DST ## Pre)", we would just expand the macro with: MultiplyAndStore(..., SRCOVER_DST_BLEND_FACTOR ## DST(DSTF, dstA), ...) which would hopefully confuse the optimizer even less. If you want to really eliminate the pixel address computations, you could rewrite the calling loop so that it steps along a pixel pointer rather than using indexing. Have the calling function/macro set up a pRas pointer to the pixel and step that along the row by TYPE##PixelStride as it iterates across the glyph, then hand that into the Glyph blend macro as DST_PTR (and eliminate PIXEL_INDEX as it would be "0" in this case)... ...jim On 4/4/16 4:37 AM, Prahalad Kumar Narayanan wrote: > Dear Jim > > Good day to you. > > ( Just in-case, you had missed my long Friday 's email ) > > Quick Recap of Proceedings > > 1.On Friday, I had profiled two solutions that fix the bug- > JDK-8015070, using Java2D Bench > > 2.Profiling was done for 16 test cases with different combinations of > > a.Font Style: Plain, Bold, Italic, Bold-Italic > > b.Font Size: 12, 20, 36, 72 > > 3.Result from Friday 's profiling experiments: > > a.Regular Solution (Un-optimized) : This was observed to be faster for > IntArgb pixel format > > b.Optimized Solution (based on SrcOver_MaskFill with fast path) : This > was observed to be faster for IntArgb_Pre pixel format > > Update from Today's Experiments > > 1.First, I understood that new calculations introduced (pixelAddress > computation) impacted performance of optimized solution in IntArgb format. > > 2.Henceforth, I made the following changes, while loading destination color: > > a.Check if the pixel format is PreMultiplied > > b.If the format is preMultiplied, then > take up new calculations and > use LoadAlphaFrom ## DST ## For4ByteArgb macro that does *Not* cause > divide by alpha adjustment > > c.If the format is regular Argb, then > take up loading of colors > using standard Load ## DST ## To4ByteArgb > > 3.Once the release build was available, Java2D Bench was re-run (using > pre-saved options file) > > Result from Bench metrics: > > a.In most of the test cases, the optimized solution has higher metric : > Avg characters/ second for both IntArgb and IntArgb_Pre formats > > b.In 6 / total-16 test cases, optimized solution was marginally lower > than the metrics of Regular un-optimized algorithm (only for > IntArgb_Pre) > > c.However, J2DAnalyzer reported that even these 6-test cases were > within 10% deviation. Hence the algorithms were categorized to be > 'same' in performance. > > Suggestion Required > > 1.The attached zip file, contains Algorithms.cpp - Which lists down > different algorithms profiled so far. > > 2.I 've introduced comments within the macro to explain the change. > > a.Note: These comments will be removed from the final source code to > be checked in. > > 3.Kindly review the latest algorithm (for any issues/ bugs) and > provide your suggestions. > > a.latest algorithm can be easily traced by searching for > "LoadOptimized Algorithm v3" within the file. > > Thank you for your time in review & detailed feedback that you get > every time. > > Every such review improves the quality of code & the solution > > Prahalad N. > > *From:* Prahalad Kumar Narayanan > *Sent:* Friday, April 01, 2016 5:07 PM > *To:* Jim Graham; Sergey Bylokhov; Philip Race > *Cc:* Praveen Srivastava > *Subject:* RE: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: > Antialiased text on translucent backgrounds gets bright artifacts > > Dear Jim > > Good day to you. > > Thanks for your suggestions in the reviews that has evolved the fix to > the bug. > > As guided by you, I measured the performance of Text Rendering with > Text Antialiasing Hint on using Java2D Bench Tool. > > Solutions Profiled: > > We have two solutions - Un optimized solution and Optimized > solution modelled as per SRCOVER_MASKFILL > > ( Both the solutions were profiled on windows x86_64 with JDK > 9-internal Release build ) > > Test Cases Profiled: > > With Font set to : Lucida sans, different combinations of > > Font Styles : Plain, Bold, Italic, Bold Italic && > > Font Sizes : 12, 20, 36, 72 points were tested. > > Attached herewith: JDK8015070-Profiling Data.zip > > The archive contains: > > 1. Algorithms.cpp : Just to have a quick glance of all the > algorithms that we have tried so far. > > 2. *.txt Files : For each test, Java2D bench > reports the average metrics/second. > > The text file > contains collection of all such average metric for nearly 16 different > test cases. > > 3. res Output : .res output from each of the test runs. > > Observation from J2DBench Reports > > 1. I could not get time to run the Analyzer tool across each > of these *.res files. I shall do them on Monday. > > 2. From the summary text ( average chars per. Second ) that > J2DBench reported, > > Un-optimized solution seems to be better for > IntArgb pixel format and > > Optimized solution is better for IntArgb_Pre > pixel format by significant margin. > > 3. I tried to improve the optimized algorithm (based on > SRCOVER_MASKFILL ) further by adding a if (dstA) { ... > > Though there is a marginal improvement, the > optimized solution could not exceed numbers of regular algorithm (for > IntArgb pixel format) > > This could be due to the extra calculations that > we do in-order to load color components separately. > > However, for IntArgb_Pre pixel format, the > optimized solution is way-ahead and gives better performance. > > 4. In the summary reports, you will find > CompatibleBufferedImage( Translucent ) as well. > > In a separate experiment, I found that the pixel > format for compatible buffered image got mapped IntArgb_Pre. > > Thus, the performance numbers match with that of > IntArgb_Pre pixel format > > At the present moment, I 'm confused on the solution would be better > to fix the Bug. > > Kindly share your views and thoughts > > Thank you > > Have a good day > > Prahalad N. > > -----Original Message----- > From: Jim Graham > Sent: Thursday, March 31, 2016 1:46 AM > To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net > ; Sergey Bylokhov > Subject: Re: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: > Antialiased text on translucent backgrounds gets bright artifacts > > Hi Prahalad, > > Benchmarks must run for a significant period of time to be valid. > > Measuring with nanoTime() is fine, but the run times should exceed at > least a couple of seconds, not a few nanoseconds. You might want to > use Java2DBench instead (in src/demo/share/java2d in the java.desktop > repo), which calibrates test times, does multiple runs, and includes > an analyzer to compare results from multiple test runs... > > ...jim > > On 3/30/2016 4:27 AM, Prahalad Kumar Narayanan wrote: > >> Hello Jim and Everyone on Java2D Group > >> > >> Good day to you. > >> > >> A quick follow-up to Review Request on bug: > >> Bug : JDK-8015070 > >> Bug Link :https://bugs.openjdk.java.net/browse/JDK-8015070 > >> > >> Thank you Jim for the detailed feedback. > >> > >> It takes a lot of time not only in performing the review, but also in getting the feedback with clear words. > >> In each review, the solution definitely gets better & better. I 'm > >> happy about it...! :) > >> > >> Quick Inferences from previous feedback: > >> > >> Incorporating the fast path into current logic: > >> 1. I agree with you on this point and I noticed this when we modelled the solution as per the mask fill. > >> 2. I ignored it initially for two reasons, > >> a. The statement - if (resA != MaxValFor4ByteArgb)... follows srcColor pre-multiplication step and this will ensure to skip most of the blending calculations pertaining to destination. > >> b. Any addition / tweaks to current logic, might deviate from the SRCOVER_MASKFILL reference model. > >> Many a time, managing code with similar logic across implementation helps a lot. > >> 3. As you said, including the fast path will avoid few multiplications and if checks too. > >> The changes are available in the current webrev. > >> Link: > >>http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.03/ > >> > >> Profiling method, and Metrics: > >> 1. The profiling method that was done yesterday was mere >> execution of the regression test (available in the webrev) and time >> measured with System.currentTimeMillis API > >> Since only one iteration was run, the time soared into milli seconds. This could be due to internal glyph caching mechanism. > >> 2. Today, I evolved the regression test, into a benchmark that does the following: > >> a. Select Font style : {Plain, Bold, Italic, Bold >> Italic} > >> b. Select Font size : {20, 40, 60, 80} > >> c. Trigger drawstring once before benchmark is run. This is to ensure, the font subsystem is done with glyph caching internally. > >> d. Use famous string that has all characters-" The quick brown fox jumps over the lazy dog. 0123456789. " > >> e. For every style-size combination - run the test >> for 20 iterations and take the average. (Note: Font is fixed to >> 'verdana' ) > >> f. Modify the precision from System.currentTimeMillis to System.nanoTime() and reduce elapsedTime to micro seconds. > >> > >> 3. With the above setup in code, my observation on windows is as follows: > >> a. In many cases, The optimized logic is either equal-to (or) better in performance than the un-optimized logic. > >> The difference is very minimal - few tens to few hundreds of micro-seconds. > >> b. The optimized algorithm improves performance for Pre-multiplied alpha based destination buffer. > >> c. There are occasional huge deviations where optimized logic seems to take longer time. > >> These could be due to external factors >> like- stalls for memory, bus io etc., > >> Since, the deviation is in micro seconds, I believe, it may not be a concern. > >> d. The complete list of time measurement taken up >> on windows x86_64 release build is as-follows- > >> I 'm not sure, how the data appears in the final webrev-email. > >> Kindly excuse, if the data is un-readable. > >> > >> Platform : Windows x86_64 Release Build Algorithm : Unoptimized. > >> webrev.00 > >> ````````````````````````````````````````````````````````````````````` >> ` > >> ```` Executing Bench For Image Type: IntArgb > >> -Font Style: Plain /Font Size: 20 /Time consumed (us): 84.742 > >> -Font Style: Plain /Font Size: 40 /Time consumed (us): 318.395 > >> -Font Style: Plain /Font Size: 60 /Time consumed (us): 657.474 > >> -Font Style: Plain /Font Size: 80 /Time consumed (us): 813.079 > >> -Font Style: Bold /Font Size: 20 /Time consumed (us): 386.380 > >> -Font Style: Bold /Font Size: 40 /Time consumed (us): 339.301 > >> -Font Style: Bold /Font Size: 60 /Time consumed (us): 492.631 > >> -Font Style: Bold /Font Size: 80 /Time consumed (us): 625.812 > >> -Font Style: Italic /Font Size: 20 /Time consumed (us): 235.059 > >> -Font Style: Italic /Font Size: 40 /Time consumed (us): 320.180 > >> -Font Style: Italic /Font Size: 60 /Time consumed (us): 474.558 > >> -Font Style: Italic /Font Size: 80 /Time consumed (us): 1188.169 > >> -Font Style: Bold-Italic /Font Size: 20 /Time consumed (us): >> 426.988 > >> -Font Style: Bold-Italic /Font Size: 40 /Time consumed (us): >> 374.064 > >> -Font Style: Bold-Italic /Font Size: 60 /Time consumed (us): >> 732.375 > >> -Font Style: Bold-Italic /Font Size: 80 /Time consumed (us): 864.68 > >> > >> Executing Bench For Image Type: IntArgb_Pre > >> -Font Style: Plain /Font Size: 20 /Time consumed (us): 129.768 > >> -Font Style: Plain /Font Size: 40 /Time consumed (us): 206.299 > >> -Font Style: Plain /Font Size: 60 /Time consumed (us): 249.941 > >> -Font Style: Plain /Font Size: 80 /Time consumed (us): 362.372 > >> -Font Style: Bold /Font Size: 20 /Time consumed (us): 145.096 > >> -Font Style: Bold /Font Size: 40 /Time consumed (us): 151.589 > >> -Font Style: Bold /Font Size: 60 /Time consumed (us): 240.972 > >> -Font Style: Bold /Font Size: 80 /Time consumed (us): 331.894 > >> -Font Style: Italic /Font Size: 20 /Time consumed (us): 95.028 > >> -Font Style: Italic /Font Size: 40 /Time consumed (us): 245.300 > >> -Font Style: Italic /Font Size: 60 /Time consumed (us): 270.379 > >> -Font Style: Italic /Font Size: 80 /Time consumed (us): 398.139 > >> -Font Style: Bold-Italic /Font Size: 20 /Time consumed (us): 93.243 > >> -Font Style: Bold-Italic /Font Size: 40 /Time consumed (us): >> 475.406 > >> -Font Style: Bold-Italic /Font Size: 60 /Time consumed (us): >> 280.085 > >> -Font Style: Bold-Italic /Font Size: 80 /Time consumed (us): >> 357.486 > >> > >> Platform : Windows x86_64 Release Build Algorithm : Optimized. > >> webrev.03 > >> ````````````````````````````````````````````````````````````````````` >> ` > >> ```` Executing Bench For Image Type: IntArgb > >> -Font Style: Plain /Font Size: 20 /Time consumed (us): 120.954 > >> -Font Style: Plain /Font Size: 40 /Time consumed (us): 364.871 > >> -Font Style: Plain /Font Size: 60 /Time consumed (us): 561.799 > >> -Font Style: Plain /Font Size: 80 /Time consumed (us): 653.390 > >> -Font Style: Bold /Font Size: 20 /Time consumed (us): 261.566 > >> -Font Style: Bold /Font Size: 40 /Time consumed (us): 311.054 > >> -Font Style: Bold /Font Size: 60 /Time consumed (us): 490.735 > >> -Font Style: Bold /Font Size: 80 /Time consumed (us): 656.559 > >> -Font Style: Italic /Font Size: 20 /Time consumed (us): 314.289 > >> -Font Style: Italic /Font Size: 40 /Time consumed (us): 378.750 > >> -Font Style: Italic /Font Size: 60 /Time consumed (us): 491.181 > >> -Font Style: Italic /Font Size: 80 /Time consumed (us): 770.172 > >> -Font Style: Bold-Italic /Font Size: 20 /Time consumed (us): >> 375.336 > >> -Font Style: Bold-Italic /Font Size: 40 /Time consumed (us): >> 571.371 > >> -Font Style: Bold-Italic /Font Size: 60 /Time consumed (us): >> 548.300 > >> -Font Style: Bold-Italic /Font Size: 80 /Time consumed (us): >> 714.526 > >> > >> Executing Bench For Image Type: IntArgb_Pre > >> -Font Style: Plain /Font Size: 20 /Time consumed (us): 45.026 > >> -Font Style: Plain /Font Size: 40 /Time consumed (us): 219.016 > >> -Font Style: Plain /Font Size: 60 /Time consumed (us): 279.617 > >> -Font Style: Plain /Font Size: 80 /Time consumed (us): 282.829 > >> -Font Style: Bold /Font Size: 20 /Time consumed (us): 51.809 > >> -Font Style: Bold /Font Size: 40 /Time consumed (us): 117.563 > >> -Font Style: Bold /Font Size: 60 /Time consumed (us): 508.049 > >> -Font Style: Bold /Font Size: 80 /Time consumed (us): 402.802 > >> -Font Style: Italic /Font Size: 20 /Time consumed (us): 79.320 > >> -Font Style: Italic /Font Size: 40 /Time consumed (us): 227.473 > >> -Font Style: Italic /Font Size: 60 /Time consumed (us): 330.488 > >> -Font Style: Italic /Font Size: 80 /Time consumed (us): 353.782 > >> -Font Style: Bold-Italic /Font Size: 20 /Time consumed (us): 54.687 > >> -Font Style: Bold-Italic /Font Size: 40 /Time consumed (us): >> 235.505 > >> -Font Style: Bold-Italic /Font Size: 60 /Time consumed (us): >> 227.205 > >> -Font Style: Bold-Italic /Font Size: 80 /Time consumed (us): >> 324.308 > >> > >> Updated webrev with changes for the fast-path : > >>http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.03/ > >> Kindly review and provide your suggestions. > >> > >> Thank you once again for detailed review and feedback Have a good day > >> > >> Prahalad N. > >> > >> > >> > >> -----Original Message----- > >> From: Jim Graham > >> Sent: Wednesday, March 30, 2016 2:46 AM > >> To: Prahalad Kumar Narayanan;2d-dev at openjdk.java.net >> ; Sergey Bylokhov > >> Subject: Re: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: > >> Antialiased text on translucent backgrounds gets bright artifacts > >> > >> Hi Prahalad, > >> > >> This latest version looks like it should produce correct answers. > >> > >> I'd like to see benchmark results on more platforms, particularly Windows since the different compilers may optimize these things differently. > >> > >> Also, you didn't mention what data set you used for benchmarking. >> I'd > >> like to see benchmark results for small, medium and large font sizes, > >> and possibly bold and italic fonts as well. The reason is that the > >> relative ratios of "empty glyph pixels" to "partial glyph pixels" to > >> "fully covered glyph pixels" changes depending on the font type and > >> size so if you made one of those faster and another slower then the > >> results may be seen as a gain in one type of test if you only test >> one > >> font type and size and it happens to match the part of the code that > >> is more streamlined. Also, for small font sizes the per-glyph > >> overhead might hide per-pixel issues. Please share which fonts and > >> sizes you used for testing and consider using some different sizes, > >> including something very large like 36 or 48 points (something with > >> large areas of opaque > >> pixels) as well as more normal sizes that appear in GUIs. Also, bold fonts can have a higher percentage of opaque pixels. > >> > >> In particular... > >> > >> This latest version is missing the "fast path" from the existing code for the case of srcA == 255 and glyphA == 255 where it just stores the FG_PIXEL values directly. For large fonts/glyphs that case may be as important as detecting empty glyph pixels. > >> > >> On the other hand, an additional "if" may cause the compiler to generate less efficient code as per Sergey's concern. Since this "if" eliminates some multiplies and possibly some divides, I'd hope it would be a win-win. > >> > >> You could add the fast path back inside the case where mixValSrc is 255 and just test srcA for 255 and do the Store ## DST ## PixelData() macro that used to be at the end of the block in the existing code, and then use "break;" to escape out of the do/while surrounding the whole macro so it moves on to the next pixel. > >> > >> (Arguably, we might want to consider teaching our SRCOVER_MASKFILL to > >> do the same thing. I think that was one of the added values of >> having > >> a separate GLYPH loop, but really both should be optimizing that > >> case...) > >> > >> I can see now that the macro switch to use the same macro set as SRCOVER_MASKFILL required you to compute the pixel address, as you noted in your summary. It makes the new macro more cumbersome and makes it look like it's doing a bit more work per-pixel, but in reality I think the overall operations end up being the same as long as the compiler optimizes the deliberate multiplications the same way it did for implicit multiplications in the "pRas[foo]" and "pRas[foo*4]" code that was being generated previously. Benchmarks will tell us if we're good there... > >> > >> ...jim > >> > >> > >> On 3/28/16 5:33 AM, Prahalad Kumar Narayanan wrote: > >>> Hello Everyone on Java2D Group > >>> > >>> Good day to you. > >>> > >>> This is a follow-up to Review Request on bug: > >>> Bug : JDK-8015070 > >>> Bug Link :https://bugs.openjdk.java.net/browse/JDK-8015070 > >>> > >>> First, Thanks to Jim and Sergey for their feedback on the changes so far. > >>> > >>> Inferences from Jim 's Feedback on Loading destination colors: > >>> 1. The API or Macro that I had earlier used to Load DST colors, indeed, adjusted destination color components with divide-by-alpha if destination was already pre-multiplied. > >>> My apologies.. I should have spotted this error at the first iteration itself. > >>> 2. Due to the divide-by-alpha adjustment, the remaining logic >>> would become incorrect. ( Especially, the multiplication with dstF >>> based on pre-mulitplication status ) > >>> 3. Correct API is being used now, and the dstColor components are loaded directly without any divide-by-alpha adjustment. > >>> > >>> Inferences from Sergey's Feedback on Performance. > >>> 1. To set the context for everyone, the logic present in the current webrev.02 is modelled as per SRCOVER_MASKFILL. > >>> There are multiple if (...) conditions that remove un-necessary blending calculations. Ideally this should improve performance. > >>> However, since some data are not readily available (as present in SRCOVER_MASKFILL), few additional calculations have been added. > >>> They are: pre-multiplying srcColor with alpha and assigning to res. > >>> Finding the correct address of Pixel using DST_PTR and PixelStride. > >>> Henceforth, as Sergey suggests, Observation on performance will be beneficial. > >>> 2. The performance of the new logic was measured with >>> linux-x86_64-normal-server-release config and compared with the >>> logic used in un-optimized code in webrev.00 > >>> 3. Result: The newer logic provides a fractional gain (about 15 - 20 ms) over the older logic. > >>> > >>> Other Subtle Changes: > >>> 1. The test file has been renamed from >>> AADrawStringArtifact.java to more meaningful - >>> AntialiasedTextArtifact.java > >>> 2. The test file tests for both TYPE_INT_ARGB and TYPE_INT_ARGB_PRE BufferedImage formats. > >>> The code has been well commented to explain the logic used in every function. > >>> > >>> Kindly take your time to review the changes in the webrev link mentioned below and provide your suggestions. > >>> Webrev Link: > >>>http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.02/ > >>> > >>> > >>> Thank you for your time in review > >>> Have a good day > >>> > >>> Prahalad N. > >>> > >>> > >>> -----Original Message----- > >>> From: Jim Graham > >>> Sent: Thursday, March 24, 2016 7:57 AM > >>> To: Prahalad Kumar Narayanan;2d-dev at openjdk.java.net >>> > >>> Subject: Re: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: > >>> Antialiased text on translucent backgrounds gets bright artifacts > >>> > >>> Hi Prahalad, > >>> > >>> (On a side note - ouch! I came up with these macros in the first > >>> place, but 20 years later I'm now realizing just how hard they are >>> to > >>> navigate and review. My apologies...) > >>> > >>> The macro you are still using to load the destination data is one that loads it to non-premultiplied components, which means it will divide out the alpha if the destination is PRE. The rest of the logic assumes that the components were loaded without any adjustment of their premultiplication so not only is that division an unnecessary operation, it makes the following math wrong. > >>> > >>> The SRCOVER_MASKFILL macro seems to use "Postload ## STRATEGY ## From ## TYPE" which seems to load them into separate components without any adjustment of their pre-multiplication status. This is paired with "LoadAlphaFrom ## TYPE ## For ## STRATEGY" to load just the destination alpha for computing dstF... > >>> > >>> ...jim > >>> > >>> On 3/22/16 4:35 AM, Prahalad Kumar Narayanan wrote: > >>>> Hello Everyone on Java2D Group > >>>> > >>>> Good day to you. > >>>> > >>>> This is a Follow-up to Review Request on the bug: > >>>> Bug : JDK-8015070 Anti-aliased Text on Translucent background gets bright artifacts > >>>> Bug Link :https://bugs.openjdk.java.net/browse/JDK-8015070 > >>>> > >>>> First, Sincere thanks to Jim for his valuable feedback. > >>>> 1. As Jim correctly mentioned, SRCOVER_MASKFILL has a similar logic to blend two Translucent colors based on an Alpha mask. > >>>> 2. The calculations are exactly the same as the changes in previous webrev. > >>>> However the logic of SRCOVER_MASKFILL is 'Optimized' to reduce the number of computations. > >>>> 3. This optimization is definitely required because, the logic is executed for every single pixel in a glyph. > >>>> Example: If a string is made up of 5 English >>>> characters with each character having 32 x 32 pixels, > >>>> The anti-aliasing logic will be executed for 5 x 32 x 32 iterations. > >>>> Reducing computation per pixel will imply a huge benefit for complete drawString operation. > >>>> > >>>> Observation from SRCOVER_MASKFILL > >>>> 1. The mask fill reduces computations by through multiple if(...) conditions. > >>>> Each if condition affirms whether the next set of computations are required. > >>>> 2. Optimization 1: If mask value is 0- skip entire logic. > >>>> 3. Optimization 2: If mask value is maximum, say 255, take >>>> srcA directly without multiplying with maskAlpha ( Reason: 1 * >>>> srcAlpha = srcAlpha ) > >>>> 4. Optimization 3: Compute pre-multiplied resColor in two steps. First with srcColor and then with dstColor. > >>>> If the resAlpha from 1st step (i.e., srcColor) is fully opaque, avoid blending dstColor altogether. > >>>> > >>>> Changes in Current Webrev.01 > >>>> 1. The fix for the current bug is modelled based on SRCOVER_MASKFILL. > >>>> 2. The changes have been verified to work on windows, linux and mac operating systems. > >>>> 3. The automated Test file- AADrawStringArtifact.java runs >>>> as expected > >>>> Identifies artifact & throws exception when run on JDK 7 and 8. > >>>> With JDK9, the test file returns without error. > >>>> 3. JPRT build has been run to ensure, changes build on all supported platforms. > >>>> JPRT job link : > >>>>http://scaaa637.us.oracle.com//archive/2016/03/2016-03-22-070604.pra > > >>>> h > >>>> n > >>>> ara-linux.client > >>>> > >>>> Kindly review the changes in the below mentioned link and provide >>>> your views > >>>> Webrev Link : > >>>>http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.01/ > >>>> > >>>> > >>>> Thank you for your time in review > >>>> Have a good day > >>>> > >>>> Prahalad N. > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: Jim Graham > >>>> Sent: Friday, March 18, 2016 6:07 AM > >>>> To: Prahalad Kumar Narayanan;2d-dev at openjdk.java.net >>>> > >>>> Subject: Re: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: > >>>> Antialiased text on translucent backgrounds gets bright artifacts > >>>> > >>>> Hi Prahalad, > >>>> > >>>> This basically boils down to "alpha blending math needs to be performed in premultiplied form" and the existing code was not doing that. > >>>> > >>>> Your changes do add a pre-multiplication step to the math in two > >>>> places > >>>> - when you mix the src alpha and the glyph alpha at the top of the macro, and again when you do the Multiply(dst, dstA, dst) step in the middle. In that sense, the new math is correct. > >>>> > >>>> However, it is not the optimal way to implement this. In > >>>> particular, the macro used here to load the data from the > >>>> destination is the one that loads it into 4 ARGB non-premultiplied > >>>> values. If the destination is non-PRE, then your added multiply > >>>> step is exactly what is needed, but it could be combined with the > >>>> multiply that will happen later in the blending equation, so it is > >>>> an added step rather than a fixed fraction in the existing MultMultAdd parameters. > >>>> Additionally, if the destination is already PRE, then the macro > >>>> being used to load the dst pixel data there will have done a divide > >>>> step to divide out the alpha from the destination, only to have you > >>>> reverse that math with your new > >>>> Multiply() step. That's a lot of math to end up with a NOP. > >>>> > >>>> The MUL8 you added for the srcA and glyph value is needed, that change is good. Since it is common for glyph pixels to have zero alpha, you might want to test the glyph alpha for 0 and skip the pixel before you do the multiply, though. This would add one more if, but it would be a common case. > >>>> > >>>> The trickier part is to load the destination components without un-premultiplying them. Unfortunately there is no "Load...ToArgbPre" > >>>> macro to parallel the Load macro used in the function. Perhaps there should be, but you'd still end up with an extra multiply step as I mentioned above because you can fold the premultiplication of the dst data into the MultMultAdd by carefully choosing the parameters you use in the math there. > >>>> > >>>> The good news is that the way that the SRCOVER_MASKFILL uses the various type-specific macros works around this a bit and minimizes the number of multiplies that happen. You could check out DEFINE_SRCOVER_MASKFILL and see how it works in the case where pMask is not null (pMask is an alpha mask with values very similar to the glyphAA data). Modeling this code on that code would correct the math and minimize it as well... > >>>> > >>>> ...jim > >>>> > >>>> On 3/17/16 3:00 AM, Prahalad Kumar Narayanan wrote: > >>>>> Hello Everyone on Java2D Group > >>>>> > >>>>> Good day to you. > >>>>> > >>>>> Herewith, I 'm sharing the webrev for two identical Java2D Bugs. > >>>>> > >>>>> Bug ID : JDK-8015070 > >>>>> > >>>>> Title : Antialiased text on translucent backgrounds gets > >>>>> bright artifacts > >>>>> > >>>>> Link :https://bugs.openjdk.java.net/browse/JDK-8015070 > >>>>> > >>>>> Bug ID : JDK-8013564 ( currently closed as duplicate ) > >>>>> > >>>>> Title : Font rendering anti-aliasing in translucent > >>>>> BufferedImages broken > >>>>> > >>>>> Link :https://bugs.openjdk.java.net/browse/JDK-8013564 > >>>>> > >>>>> Webrev Link : > >>>>>http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.00/ > >>>>> > >>>>> Quick Summary on Bugs : > >>>>> > >>>>> ```````````````````````````````````````````````` > >>>>> > >>>>> 1. Artifacts appear on Edges of text characters when anti-aliased > >>>>> text is drawn on Translucent background > >>>>> > >>>>> 2. The issue is reproducible on all platforms - windows, linux and mac os. > >>>>> > >>>>> 3. Besides, the issue is reproduced with the commonly used pixel > >>>>> format- 4ByteArgb. > >>>>> > >>>>> Root Cause & Solution : > >>>>> > >>>>> ```````````````````````````````````````````````` > >>>>> > >>>>> 1. The Macro: GlyphListAABlend4ByteArgb in File: LoopMacros.h >>>>> uses > >>>>> the standard blending algorithm > >>>>> > >>>>> dstColor = [ srcColor * glyphAlpha + dstColor * (1 - > >>>>> glyphAlpha) ] / dstAlpha > >>>>> > >>>>> 2. The above equation works only when the srcColor and dstColor are Opaque. > >>>>> > >>>>> 3. When srcColor and dstColor are Translucent, their > >>>>> alphaComponent will influence the visibility of the color, and > >>>>> visibility of the color below. > >>>>> > >>>>> 4. The new set of calculations for blending Translucent source >>>>> and > >>>>> destination colors is given as > >>>>> > >>>>> resAlpha = 1 - ((1 - srcAlpha) * (1 - dstAlpha)) > >>>>> > >>>>> resColor = [ srcColor * srcAlpha + dstColor * dstAlpha > >>>>> * > >>>>> (1 > >>>>> - > >>>>> srcAlpha) ] / resAlpha > >>>>> > >>>>> 5. Reference text for the equation: > >>>>>https://en.wikipedia.org/wiki/Alpha_compositing > >>>>> > >>>>> 6. With the above modification to the blending logic, the > >>>>> artifacts do not appear and issues are fixed. > >>>>> > >>>>> Jtreg & Jprt Results : > >>>>> > >>>>> ```````````````````````````````````````````````` > >>>>> > >>>>> 1. A simple test-file: AADrawStringArtifact.java has been created > >>>>> to be a part of jtreg test cases. > >>>>> > >>>>> The test file is well commented to explain - nature >>>>> of > >>>>> artifact and how the test tries to identify them. > >>>>> > >>>>> As required, the test case fails with Jdk 7, Jdk 8 >>>>> and > >>>>> succeeds with Jdk 9-internal (built with changes for the bug fix) > >>>>> > >>>>> 2. The changes to blending logic lies within > >>>>> java.desktop/src/share/native/... > >>>>> > >>>>> Henceforth, JPRT was used to ensure successful build > >>>>> across all supported platforms > >>>>> > >>>>> Jprt Job Link : > >>>>>http://scaaa637.us.oracle.com//archive/2016/03/2016-03-17-072001.pr > > >>>>> a > >>>>> h > >>>>> n > >>>>> ara-linux.client > >>>>> > >>>>> The build succeeds on all platforms. > >>>>> > >>>>> Kindly review the webrev link and provide your views and suggestions. > >>>>> > >>>>> Webrev Link : > >>>>>http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.00/ > >>>>> > >>>>> If the changes look good, we could take up the changes for source checkin. > >>>>> > >>>>> Thank you for your time in review > >>>>> > >>>>> Have a good day > >>>>> > >>>>> Prahalad N. > >>>>> > From prasanta.sadhukhan at oracle.com Fri Apr 15 10:34:24 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Fri, 15 Apr 2016 16:04:24 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6529030, , Java Printing: Print range > Selection gets enabled In-Reply-To: <570E7D6D.9040306@oracle.com> References: <5704E06F.2010502@oracle.com> <570D8352.5060405@oracle.com> <570E2AE1.4020604@oracle.com> <570E7D6D.9040306@oracle.com> Message-ID: <5710C3B0.1020304@oracle.com> Hi Phil, On 4/13/2016 10:40 PM, Philip Race wrote: > This seems reasonable to me - we don't want "disable" the selection > radio button > and prevent the user from selecting it since our API does support it > as an option. > The way I first read the bug report was that it implied that the first > invocation > when the selection button was disabled was "right" and the 2nd invocation > was "wrong" whereas it seems the other way around. > > If the updated code (and my understanding) is correct then should we > not in fact be updating getSelectAttrib() so that it never returns > PD_NOSELECTION, > rather than "fixing it up" in this code ? > > Of course you then need to look to see how we interpret & use a > return value of PD_NOSELECTIONfrom getSelectAttrib() on OS X and Linux. > getSelectAttrib() is not called in linux. But it's called in osx and we determine to/from pages to determine which radio button (All/Pages) to select http://hg.openjdk.java.net/jdk9/client/jdk/file/735a130dc8db/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m#l388 Regards Prasanta > I would really like to get Jennifer's input on this. > > -phil. > > On 4/13/16, 4:17 AM, prasanta sadhukhan wrote: >> Hi Phil, >> >> On 4/13/2016 4:52 AM, Phil Race wrote: >>> Hi, >>> >>> My reading here : >>> https://msdn.microsoft.com/en-us/library/windows/desktop/ms646843%28v=vs.85%29.aspx >>> >>> >>> of the meaning of PD_NOSELECTION is that it disables the SELECTION >>> radio button such >>> that the user *cannot* select it. >>> >>> Is that true ? >> Yes, PD_NOSELECTION will disable SELECTION radio button. >>> If so this seems like it cannot be the right fix for this issue >>> and I am not sure why getSelectAttrib() would want to return that. >> protected final int getSelectAttrib() { >> if (attributes != null) { >> SunPageSelection pages = >> (SunPageSelection)attributes.get(SunPageSelection.class); >> if (pages == SunPageSelection.RANGE) { >> return PD_PAGENUMS; >> } else if (pages == SunPageSelection.SELECTION) { >> return PD_SELECTION; >> } else if (pages == SunPageSelection.ALL) { >> return PD_ALLPAGES; >> } >> } >> return PD_NOSELECTION; >> } >> so if SunPageSelection is not added to attribute which was the case >> in 1st instance so PD_NOSELECTION is returned >> and we have in awt_PrintControl.cpp#InitPrintDialog() >> if (selectType != 0) { selectType will be 4 for PD_NOSELECTION so >> pd.Flags will be set and Selection radio button is disabled in 1st >> instance >> pd.Flags |= selectType; >> } >>> Perhaps we never in practice return PD_NOSELECTION ? >>> >>> I am also unsure what it means to set flags to PD_NOSELECTION | >>> PD_SELECTION >>> as the windows docs don't tell me enough. >> It will still disable SELECTION radio button. >>> >>> Maybe what we want is just that we do not cause PD_SELECTION to be set >>> rather than setting PD_NOSELECTION. >>> >> I have modified the webrev to not set PD_NOSELECTION if >> getSelectAttrib() returns NOSELECTION so it will mean Selection >> radiobutton will be enabled now but will not be selected UNLESS user >> selects >> job.setDefaultSelection(JobAttributes.DefaultSelectionType.SELECTION) >> explicitly in the application. >> >> http://cr.openjdk.java.net/~psadhukhan/6529030/webrev.01/ >> Also, I added @requires (os.family == windows) tag to make sure the >> test is run on windows only as in linux, osx we do not get the >> "selection" option [only All and Page range] for this test. >> >> Regards >> Prasanta >>> But to decide what to do I need to know the real effect of >>> PD_NOSELECTION. >>> >>> BTW about the test: you should make sure that the instructions are >>> valid on OS X and Linux .. >>> >>> -phil. >>> >>> On 04/06/2016 03:09 AM, prasanta sadhukhan wrote: >>>> Hi All, >>>> >>>> Please review a fix for jdk9. >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6529030 >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6529030/webrev.00/ >>>> >>>> The issue was when using java.awt.print.PrinterJob instance more >>>> then once, Selection radio button in Print dialog gets enabled from >>>> 2nd instance even though we are printing "All" pages >>>> however Selection radio button is disabled in the first instance. >>>> This is seen in windows. >>>> >>>> This is because initially when windows initialized the print >>>> dialog, it calls InitPrintDialog() which calls getSelectAttrib() to >>>> find out which selection attribute user has selected. >>>> getSelectAttrib() returns PD_NOSELECTION as SunPageSelection.class >>>> was not added to attribute. >>>> So, in InitPrintDialog() we set PRINTDLG flags to PD_NOSELECTION. >>>> So, we see "Selection " radio button is disabled in 1st instance of >>>> print dialog. >>>> Now, when user presses "OK", windows native code calls >>>> setNativeAttributes() and adds SunPageSelection.class to the >>>> attribute with SunPageSelection.ALL or SunPageSelection.RANGE. >>>> >>>> When 2nd print dialog is shown, InitPrintDialog() will again call >>>> getSelectAttrib() which will now return >>>> SunPageSelection.ALL/SunPageSelection.RANGE which will be set to >>>> PRINTDLG flag but >>>> we are not disabling Selection radio button, so in 2nd instance, >>>> Selection radio button gets enabled. >>>> >>>> Fix was to check if PD_SELECTION attribute is selected by user, if >>>> not , sets PRINTDLG flag with PD_NOSELECTION. >>>> >>>> I have checked 8151590 and 8061267 works correctly with this patch. >>>> >>>> Regards >>>> Prasanta >>> >> From jayathirth.d.v at oracle.com Tue Apr 19 07:12:56 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 19 Apr 2016 00:12:56 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6197099 : PrinterJob.getUserName() throws a security exception when user.name permission is not given In-Reply-To: <5710929D.3050808@oracle.com> References: <5704F4CA.3020108@oracle.com> <570DD7BF.90506@oracle.com> <570E5930.1060809@oracle.com> <5710929D.3050808@oracle.com> Message-ID: Hi Prasanta, In test case there is an indentation problem for multiline comments in jtreg. Also what I have observed is that in case of jtreg summary if we include "." after running jtreg in the report it will not show complete summary it will show only until the "." In your case it will show only " Verifies PrinterJob ". Please update the summary. Other changes are fine. Thanks, Jay -----Original Message----- From: prasanta sadhukhan Sent: Friday, April 15, 2016 12:35 PM To: Philip Race Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9] RFR: JDK-6197099 : PrinterJob.getUserName() throws a security exception when user.name permission is not given Hi Phil, Please find the modified webrev with the testcase: http://cr.openjdk.java.net/~psadhukhan/6197099/webrev.01/ Regards Prasanta On 4/13/2016 8:05 PM, Philip Race wrote: > This needs a test. You can provide one by following other similar > examples. > Also it needs a CCC to document the exception. > Finally, I am a bit surprised at the exact exception. > Where precisely does this originate (stack trace, please) ? > Probably we should throw SecurityException instead, even if it is not > the exact behaviour today. > Just make sure that our own code is ready for such a change. > > -phil. > > On 4/12/16, 10:23 PM, prasanta sadhukhan wrote: >> Resending with bugid in the subject line. >> >> On 4/6/2016 5:06 PM, prasanta sadhukhan wrote: >>> Hi All, >>> >>> Please review a document fix for jdk9 >>> Bug: https://bugs.openjdk.java.net/browse/JDK-6197099 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/6197099/webrev.00/ >>> >>> PrinterJob.getUserName() is supposed to return the current user name >>> of the system. This method does not document any exception. >>> But when SecurityManager is installed, this method throws a security >>> exception when PropertyPermission - user.name is not given in the >>> policy file. >>> But this is not documented anywhere and hence the user will not know >>> until he gets the exception. >>> >>> Documented the long-standing existing exception. >>> >>> will raise a ccc after the technical review. >>> >>> Regards >>> Prasanta >> From prasanta.sadhukhan at oracle.com Tue Apr 19 07:26:37 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Tue, 19 Apr 2016 12:56:37 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6197099 : PrinterJob.getUserName() throws a security exception when user.name permission is not given In-Reply-To: References: <5704F4CA.3020108@oracle.com> <570DD7BF.90506@oracle.com> <570E5930.1060809@oracle.com> <5710929D.3050808@oracle.com> Message-ID: <5715DDAD.4040700@oracle.com> On 4/19/2016 12:42 PM, Jayathirth D V wrote: > Hi Prasanta, > > In test case there is an indentation problem for multiline comments in jtreg. > Also what I have observed is that in case of jtreg summary if we include "." after running jtreg in the report it will not show complete summary it will show only until the "." > In your case it will show only " Verifies PrinterJob ". Please update the summary. Other changes are fine. Thanks Jay. Although I did not see this problem but maybe different version of jtreg has this issue.Anyways, I have modified the webrev: http://cr.openjdk.java.net/~psadhukhan/6197099/webrev.02/ Regards Prasanta > Thanks, > Jay > > -----Original Message----- > From: prasanta sadhukhan > Sent: Friday, April 15, 2016 12:35 PM > To: Philip Race > Cc: 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] [9] RFR: JDK-6197099 : PrinterJob.getUserName() throws a security exception when user.name permission is not given > > Hi Phil, > > Please find the modified webrev with the testcase: > http://cr.openjdk.java.net/~psadhukhan/6197099/webrev.01/ > > Regards > Prasanta > On 4/13/2016 8:05 PM, Philip Race wrote: >> This needs a test. You can provide one by following other similar >> examples. >> Also it needs a CCC to document the exception. >> Finally, I am a bit surprised at the exact exception. >> Where precisely does this originate (stack trace, please) ? >> Probably we should throw SecurityException instead, even if it is not >> the exact behaviour today. >> Just make sure that our own code is ready for such a change. >> >> -phil. >> >> On 4/12/16, 10:23 PM, prasanta sadhukhan wrote: >>> Resending with bugid in the subject line. >>> >>> On 4/6/2016 5:06 PM, prasanta sadhukhan wrote: >>>> Hi All, >>>> >>>> Please review a document fix for jdk9 >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6197099 >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6197099/webrev.00/ >>>> >>>> PrinterJob.getUserName() is supposed to return the current user name >>>> of the system. This method does not document any exception. >>>> But when SecurityManager is installed, this method throws a security >>>> exception when PropertyPermission - user.name is not given in the >>>> policy file. >>>> But this is not documented anywhere and hence the user will not know >>>> until he gets the exception. >>>> >>>> Documented the long-standing existing exception. >>>> >>>> will raise a ccc after the technical review. >>>> >>>> Regards >>>> Prasanta From jayathirth.d.v at oracle.com Tue Apr 19 07:29:30 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 19 Apr 2016 00:29:30 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6197099 : PrinterJob.getUserName() throws a security exception when user.name permission is not given In-Reply-To: <5715DDAD.4040700@oracle.com> References: <5704F4CA.3020108@oracle.com> <570DD7BF.90506@oracle.com> <570E5930.1060809@oracle.com> <5710929D.3050808@oracle.com> <5715DDAD.4040700@oracle.com> Message-ID: <4ac205bd-be21-4089-bd16-b201d3598daf@default> Looks good. -----Original Message----- From: prasanta sadhukhan Sent: Tuesday, April 19, 2016 12:57 PM To: Jayathirth D V; Philip Race Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9] RFR: JDK-6197099 : PrinterJob.getUserName() throws a security exception when user.name permission is not given On 4/19/2016 12:42 PM, Jayathirth D V wrote: > Hi Prasanta, > > In test case there is an indentation problem for multiline comments in jtreg. > Also what I have observed is that in case of jtreg summary if we include "." after running jtreg in the report it will not show complete summary it will show only until the "." > In your case it will show only " Verifies PrinterJob ". Please update the summary. Other changes are fine. Thanks Jay. Although I did not see this problem but maybe different version of jtreg has this issue.Anyways, I have modified the webrev: http://cr.openjdk.java.net/~psadhukhan/6197099/webrev.02/ Regards Prasanta > Thanks, > Jay > > -----Original Message----- > From: prasanta sadhukhan > Sent: Friday, April 15, 2016 12:35 PM > To: Philip Race > Cc: 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] [9] RFR: JDK-6197099 : > PrinterJob.getUserName() throws a security exception when user.name > permission is not given > > Hi Phil, > > Please find the modified webrev with the testcase: > http://cr.openjdk.java.net/~psadhukhan/6197099/webrev.01/ > > Regards > Prasanta > On 4/13/2016 8:05 PM, Philip Race wrote: >> This needs a test. You can provide one by following other similar >> examples. >> Also it needs a CCC to document the exception. >> Finally, I am a bit surprised at the exact exception. >> Where precisely does this originate (stack trace, please) ? >> Probably we should throw SecurityException instead, even if it is not >> the exact behaviour today. >> Just make sure that our own code is ready for such a change. >> >> -phil. >> >> On 4/12/16, 10:23 PM, prasanta sadhukhan wrote: >>> Resending with bugid in the subject line. >>> >>> On 4/6/2016 5:06 PM, prasanta sadhukhan wrote: >>>> Hi All, >>>> >>>> Please review a document fix for jdk9 >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6197099 >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6197099/webrev.00/ >>>> >>>> PrinterJob.getUserName() is supposed to return the current user >>>> name of the system. This method does not document any exception. >>>> But when SecurityManager is installed, this method throws a >>>> security exception when PropertyPermission - user.name is not given >>>> in the policy file. >>>> But this is not documented anywhere and hence the user will not >>>> know until he gets the exception. >>>> >>>> Documented the long-standing existing exception. >>>> >>>> will raise a ccc after the technical review. >>>> >>>> Regards >>>> Prasanta From prasanta.sadhukhan at oracle.com Tue Apr 19 07:31:19 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Tue, 19 Apr 2016 13:01:19 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6197099 : PrinterJob.getUserName() throws a security exception when user.name permission is not given In-Reply-To: <4ac205bd-be21-4089-bd16-b201d3598daf@default> References: <5704F4CA.3020108@oracle.com> <570DD7BF.90506@oracle.com> <570E5930.1060809@oracle.com> <5710929D.3050808@oracle.com> <5715DDAD.4040700@oracle.com> <4ac205bd-be21-4089-bd16-b201d3598daf@default> Message-ID: <5715DEC7.5040706@oracle.com> Hi Phil, ccc request is approved. Can you please give +1 so that I can push this change? Regards Prasanta On 4/19/2016 12:59 PM, Jayathirth D V wrote: > Looks good. > > -----Original Message----- > From: prasanta sadhukhan > Sent: Tuesday, April 19, 2016 12:57 PM > To: Jayathirth D V; Philip Race > Cc: 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] [9] RFR: JDK-6197099 : PrinterJob.getUserName() throws a security exception when user.name permission is not given > > > > On 4/19/2016 12:42 PM, Jayathirth D V wrote: >> Hi Prasanta, >> >> In test case there is an indentation problem for multiline comments in jtreg. >> Also what I have observed is that in case of jtreg summary if we include "." after running jtreg in the report it will not show complete summary it will show only until the "." >> In your case it will show only " Verifies PrinterJob ". Please update the summary. Other changes are fine. > Thanks Jay. Although I did not see this problem but maybe different version of jtreg has this issue.Anyways, I have modified the webrev: > http://cr.openjdk.java.net/~psadhukhan/6197099/webrev.02/ > > Regards > Prasanta >> Thanks, >> Jay >> >> -----Original Message----- >> From: prasanta sadhukhan >> Sent: Friday, April 15, 2016 12:35 PM >> To: Philip Race >> Cc: 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] [9] RFR: JDK-6197099 : >> PrinterJob.getUserName() throws a security exception when user.name >> permission is not given >> >> Hi Phil, >> >> Please find the modified webrev with the testcase: >> http://cr.openjdk.java.net/~psadhukhan/6197099/webrev.01/ >> >> Regards >> Prasanta >> On 4/13/2016 8:05 PM, Philip Race wrote: >>> This needs a test. You can provide one by following other similar >>> examples. >>> Also it needs a CCC to document the exception. >>> Finally, I am a bit surprised at the exact exception. >>> Where precisely does this originate (stack trace, please) ? >>> Probably we should throw SecurityException instead, even if it is not >>> the exact behaviour today. >>> Just make sure that our own code is ready for such a change. >>> >>> -phil. >>> >>> On 4/12/16, 10:23 PM, prasanta sadhukhan wrote: >>>> Resending with bugid in the subject line. >>>> >>>> On 4/6/2016 5:06 PM, prasanta sadhukhan wrote: >>>>> Hi All, >>>>> >>>>> Please review a document fix for jdk9 >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6197099 >>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6197099/webrev.00/ >>>>> >>>>> PrinterJob.getUserName() is supposed to return the current user >>>>> name of the system. This method does not document any exception. >>>>> But when SecurityManager is installed, this method throws a >>>>> security exception when PropertyPermission - user.name is not given >>>>> in the policy file. >>>>> But this is not documented anywhere and hence the user will not >>>>> know until he gets the exception. >>>>> >>>>> Documented the long-standing existing exception. >>>>> >>>>> will raise a ccc after the technical review. >>>>> >>>>> Regards >>>>> Prasanta From philip.race at oracle.com Tue Apr 19 17:06:32 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 19 Apr 2016 10:06:32 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6197099 : PrinterJob.getUserName() throws a security exception when user.name permission is not given In-Reply-To: <5715DEC7.5040706@oracle.com> References: <5704F4CA.3020108@oracle.com> <570DD7BF.90506@oracle.com> <570E5930.1060809@oracle.com> <5710929D.3050808@oracle.com> <5715DDAD.4040700@oracle.com> <4ac205bd-be21-4089-bd16-b201d3598daf@default> <5715DEC7.5040706@oracle.com> Message-ID: <57166598.60909@oracle.com> +1 -phil On 04/19/2016 12:31 AM, prasanta sadhukhan wrote: > Hi Phil, > > ccc request is approved. Can you please give +1 so that I can push > this change? > > Regards > Prasanta > On 4/19/2016 12:59 PM, Jayathirth D V wrote: >> Looks good. >> >> -----Original Message----- >> From: prasanta sadhukhan >> Sent: Tuesday, April 19, 2016 12:57 PM >> To: Jayathirth D V; Philip Race >> Cc: 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] [9] RFR: JDK-6197099 : >> PrinterJob.getUserName() throws a security exception when user.name >> permission is not given >> >> >> >> On 4/19/2016 12:42 PM, Jayathirth D V wrote: >>> Hi Prasanta, >>> >>> In test case there is an indentation problem for multiline comments >>> in jtreg. >>> Also what I have observed is that in case of jtreg summary if we >>> include "." after running jtreg in the report it will not show >>> complete summary it will show only until the "." >>> In your case it will show only " Verifies PrinterJob ". Please >>> update the summary. Other changes are fine. >> Thanks Jay. Although I did not see this problem but maybe different >> version of jtreg has this issue.Anyways, I have modified the webrev: >> http://cr.openjdk.java.net/~psadhukhan/6197099/webrev.02/ >> >> Regards >> Prasanta >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: prasanta sadhukhan >>> Sent: Friday, April 15, 2016 12:35 PM >>> To: Philip Race >>> Cc: 2d-dev at openjdk.java.net >>> Subject: Re: [OpenJDK 2D-Dev] [9] RFR: JDK-6197099 : >>> PrinterJob.getUserName() throws a security exception when user.name >>> permission is not given >>> >>> Hi Phil, >>> >>> Please find the modified webrev with the testcase: >>> http://cr.openjdk.java.net/~psadhukhan/6197099/webrev.01/ >>> >>> Regards >>> Prasanta >>> On 4/13/2016 8:05 PM, Philip Race wrote: >>>> This needs a test. You can provide one by following other similar >>>> examples. >>>> Also it needs a CCC to document the exception. >>>> Finally, I am a bit surprised at the exact exception. >>>> Where precisely does this originate (stack trace, please) ? >>>> Probably we should throw SecurityException instead, even if it is not >>>> the exact behaviour today. >>>> Just make sure that our own code is ready for such a change. >>>> >>>> -phil. >>>> >>>> On 4/12/16, 10:23 PM, prasanta sadhukhan wrote: >>>>> Resending with bugid in the subject line. >>>>> >>>>> On 4/6/2016 5:06 PM, prasanta sadhukhan wrote: >>>>>> Hi All, >>>>>> >>>>>> Please review a document fix for jdk9 >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6197099 >>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6197099/webrev.00/ >>>>>> >>>>>> PrinterJob.getUserName() is supposed to return the current user >>>>>> name of the system. This method does not document any exception. >>>>>> But when SecurityManager is installed, this method throws a >>>>>> security exception when PropertyPermission - user.name is not given >>>>>> in the policy file. >>>>>> But this is not documented anywhere and hence the user will not >>>>>> know until he gets the exception. >>>>>> >>>>>> Documented the long-standing existing exception. >>>>>> >>>>>> will raise a ccc after the technical review. >>>>>> >>>>>> Regards >>>>>> Prasanta > From philip.race at oracle.com Tue Apr 19 20:08:04 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 19 Apr 2016 13:08:04 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] Review request for 8152309 Seamless way of using image filters with multi-resolution images In-Reply-To: <5703CBE9.8030800@oracle.com> References: <5703CBE9.8030800@oracle.com> Message-ID: <57169024.9080001@oracle.com> I've gone up and down the API (and most of the implementation) ResolutionVariantItem is really only used in the public API in one place :- ImageProducer defines :- + default List> getResolutionVariantItems() { + return Arrays.asList(new ResolutionVariantItem<>(this, 1, 1)); The sort-of second place is that FilteredImageSource over-rides this. The rest is the internal uses of the class (and its definition of course) So do we need such a generic sounding API class for this one case, (or are there other API-level uses?) and is there a different approach which avoid the new class entirely ? Assuming ResolutionVariantItem is the right name - and design - it seems like it could use a bit more class javadoc, even if it is basically a bag to hold a few things. There are few formatting/typo things I noticed but no point in talking about those until the rest is near conclusion. -phil. On 04/05/2016 07:30 AM, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8152309 > webrev: http://cr.openjdk.java.net/~alexsch/8152309/webrev.00 > > > The purpose of the fix is to allow to apply an image filter for a > multi-resolution image to get new multi-resolution image so the code > below works without changes: > ---------- > Image mrImage = getMultiResolutionImage(); > ImageProducer mriProducer = new > FilteredImageSource(mrImage.getSource(), new CropImageFilter(x, y, w, > h)); > Image filteredMRImage = > Toolkit.getDefaultToolkit().createImage(mriProducer); > ---------- > > > The Image producer needs to be updated to contain a set of > resolution-variant image producers. It can be done introducing a new > MultiResolution[Image]Producer interface. However, the > FilteredImageSource which takes an original image producer as a > constructor argument needs to be declared as > MultiResolution[Image]Producer even for ordinary image producers. > I chose to add the getRVProducers() method directly to the > ImageProducer interface. > > The option to add a method which request a resolution variant producer > for the given image size (getRVProducer(width, height) ) seems is not > possible because the result multi-resolution image can be loaded by a > MediaTracker which can load only finite number of resolution variants. > > Applying an image filter to resolution-variant producers requires to > scale filters which use fixed image size (like CropImageFilter and > ReplicateScaleFilter). > There should be a way to get a scaled filter using the original one. > The resolution variant image producer need to provide necessary scale > factors for the used filter. > To do that getScaledFilterInstance(scaleX, scaleY) method is added to > the ImageFilter and public ResolutionVariantItem class which can hold > image or image producer with associated scale factors is introduced. > > There is an interesting problem in SunGraphics2D where a > multi-resolution image size is requested. To do that it is necessary > to have an image observer which needs to redirect calls to the base > image observer. The resolution variant observer needs to know scale > factors to recalculate given [x, y, width, height] values. The scale > factors are provided by toolkit multi-resolution image but for non > toolkit multi-resolution images they need to be calculated dividing a > rv-image size to base image size. It looks like a closed loop when to > know scale factors it needs to get a rv-image size but for this it is > necessary to use an image observer which requires scale factors. > The current fix just divides rv-image size to base image size for non > toolkit multi-resolution images to get scale factors . > > Thanks, > Alexandr. > From jennifer.godinez at oracle.com Tue Apr 19 22:22:28 2016 From: jennifer.godinez at oracle.com (Jennifer Godinez) Date: Tue, 19 Apr 2016 15:22:28 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6529030, , Java Printing: Print range > Selection gets enabled In-Reply-To: <5710C3B0.1020304@oracle.com> References: <5704E06F.2010502@oracle.com> <570D8352.5060405@oracle.com> <570E2AE1.4020604@oracle.com> <570E7D6D.9040306@oracle.com> <5710C3B0.1020304@oracle.com> Message-ID: <5716AFA4.6040309@oracle.com> Hi Prasanta, It looks to me that we missed to check (flags & PD_NOSELECTION) in setNativeAttributes that's why we are setting SunPageSelection attribute when we shouldn't. I think that is where we should put the fix. Jennifer On 04/15/2016 03:34 AM, prasanta sadhukhan wrote: > Hi Phil, > > On 4/13/2016 10:40 PM, Philip Race wrote: >> This seems reasonable to me - we don't want "disable" the selection >> radio button >> and prevent the user from selecting it since our API does support it >> as an option. >> The way I first read the bug report was that it implied that the >> first invocation >> when the selection button was disabled was "right" and the 2nd >> invocation >> was "wrong" whereas it seems the other way around. >> >> If the updated code (and my understanding) is correct then should we >> not in fact be updating getSelectAttrib() so that it never returns >> PD_NOSELECTION, >> rather than "fixing it up" in this code ? >> >> Of course you then need to look to see how we interpret & use a >> return value of PD_NOSELECTIONfrom getSelectAttrib() on OS X and Linux. >> > getSelectAttrib() is not called in linux. > But it's called in osx and we determine to/from pages to determine > which radio button (All/Pages) to select > http://hg.openjdk.java.net/jdk9/client/jdk/file/735a130dc8db/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m#l388 > > > Regards > Prasanta >> I would really like to get Jennifer's input on this. >> >> -phil. >> >> On 4/13/16, 4:17 AM, prasanta sadhukhan wrote: >>> Hi Phil, >>> >>> On 4/13/2016 4:52 AM, Phil Race wrote: >>>> Hi, >>>> >>>> My reading here : >>>> https://msdn.microsoft.com/en-us/library/windows/desktop/ms646843%28v=vs.85%29.aspx >>>> >>>> >>>> of the meaning of PD_NOSELECTION is that it disables the SELECTION >>>> radio button such >>>> that the user *cannot* select it. >>>> >>>> Is that true ? >>> Yes, PD_NOSELECTION will disable SELECTION radio button. >>>> If so this seems like it cannot be the right fix for this issue >>>> and I am not sure why getSelectAttrib() would want to return that. >>> protected final int getSelectAttrib() { >>> if (attributes != null) { >>> SunPageSelection pages = >>> (SunPageSelection)attributes.get(SunPageSelection.class); >>> if (pages == SunPageSelection.RANGE) { >>> return PD_PAGENUMS; >>> } else if (pages == SunPageSelection.SELECTION) { >>> return PD_SELECTION; >>> } else if (pages == SunPageSelection.ALL) { >>> return PD_ALLPAGES; >>> } >>> } >>> return PD_NOSELECTION; >>> } >>> so if SunPageSelection is not added to attribute which was the case >>> in 1st instance so PD_NOSELECTION is returned >>> and we have in awt_PrintControl.cpp#InitPrintDialog() >>> if (selectType != 0) { selectType will be 4 for PD_NOSELECTION so >>> pd.Flags will be set and Selection radio button is disabled in 1st >>> instance >>> pd.Flags |= selectType; >>> } >>>> Perhaps we never in practice return PD_NOSELECTION ? >>>> >>>> I am also unsure what it means to set flags to PD_NOSELECTION | >>>> PD_SELECTION >>>> as the windows docs don't tell me enough. >>> It will still disable SELECTION radio button. >>>> >>>> Maybe what we want is just that we do not cause PD_SELECTION to be set >>>> rather than setting PD_NOSELECTION. >>>> >>> I have modified the webrev to not set PD_NOSELECTION if >>> getSelectAttrib() returns NOSELECTION so it will mean Selection >>> radiobutton will be enabled now but will not be selected UNLESS user >>> selects >>> job.setDefaultSelection(JobAttributes.DefaultSelectionType.SELECTION) explicitly >>> in the application. >>> >>> http://cr.openjdk.java.net/~psadhukhan/6529030/webrev.01/ >>> Also, I added @requires (os.family == windows) tag to make sure the >>> test is run on windows only as in linux, osx we do not get the >>> "selection" option [only All and Page range] for this test. >>> >>> Regards >>> Prasanta >>>> But to decide what to do I need to know the real effect of >>>> PD_NOSELECTION. >>>> >>>> BTW about the test: you should make sure that the instructions are >>>> valid on OS X and Linux .. >>>> >>>> -phil. >>>> >>>> On 04/06/2016 03:09 AM, prasanta sadhukhan wrote: >>>>> Hi All, >>>>> >>>>> Please review a fix for jdk9. >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6529030 >>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6529030/webrev.00/ >>>>> >>>>> The issue was when using java.awt.print.PrinterJob instance more >>>>> then once, Selection radio button in Print dialog gets enabled >>>>> from 2nd instance even though we are printing "All" pages >>>>> however Selection radio button is disabled in the first instance. >>>>> This is seen in windows. >>>>> >>>>> This is because initially when windows initialized the print >>>>> dialog, it calls InitPrintDialog() which calls getSelectAttrib() >>>>> to find out which selection attribute user has selected. >>>>> getSelectAttrib() returns PD_NOSELECTION as SunPageSelection.class >>>>> was not added to attribute. >>>>> So, in InitPrintDialog() we set PRINTDLG flags to PD_NOSELECTION. >>>>> So, we see "Selection " radio button is disabled in 1st instance >>>>> of print dialog. >>>>> Now, when user presses "OK", windows native code calls >>>>> setNativeAttributes() and adds SunPageSelection.class to the >>>>> attribute with SunPageSelection.ALL or SunPageSelection.RANGE. >>>>> >>>>> When 2nd print dialog is shown, InitPrintDialog() will again call >>>>> getSelectAttrib() which will now return >>>>> SunPageSelection.ALL/SunPageSelection.RANGE which will be set to >>>>> PRINTDLG flag but >>>>> we are not disabling Selection radio button, so in 2nd instance, >>>>> Selection radio button gets enabled. >>>>> >>>>> Fix was to check if PD_SELECTION attribute is selected by user, if >>>>> not , sets PRINTDLG flag with PD_NOSELECTION. >>>>> >>>>> I have checked 8151590 and 8061267 works correctly with this patch. >>>>> >>>>> Regards >>>>> Prasanta >>>> >>> > From prasanta.sadhukhan at oracle.com Wed Apr 20 09:09:23 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Wed, 20 Apr 2016 14:39:23 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6529030, , Java Printing: Print range > Selection gets enabled In-Reply-To: <5716AFA4.6040309@oracle.com> References: <5704E06F.2010502@oracle.com> <570D8352.5060405@oracle.com> <570E2AE1.4020604@oracle.com> <570E7D6D.9040306@oracle.com> <5710C3B0.1020304@oracle.com> <5716AFA4.6040309@oracle.com> Message-ID: <57174743.4030205@oracle.com> Hi Jennifer, If I do not set SunPageSelection attribute in setNativeAttributes() like this + if ((flags & PD_NOSELECTION) != PD_NOSELECTION) { if ((flags & PD_PAGENUMS) != 0) { attributes.add(SunPageSelection.RANGE); } else if ((flags & PD_SELECTION) != 0) { attributes.add(SunPageSelection.SELECTION); } else { attributes.add(SunPageSelection.ALL); } + } without doing my fix in awt_PrintControl.cpp#InitPrintDialog() it will disable the selection radio button for both invocation as getSelectAttrib() returns PD_NOSELECTION. I think my fix in InitPrintDialog() http://cr.openjdk.java.net/~psadhukhan/6529030/webrev.01/ is required for this fix. Regards Prasanta On 4/20/2016 3:52 AM, Jennifer Godinez wrote: > Hi Prasanta, > > It looks to me that we missed to check (flags & PD_NOSELECTION) in > setNativeAttributes that's why we are setting SunPageSelection > attribute when we shouldn't. I think that is where we should put the > fix. > > Jennifer > > On 04/15/2016 03:34 AM, prasanta sadhukhan wrote: >> Hi Phil, >> >> On 4/13/2016 10:40 PM, Philip Race wrote: >>> This seems reasonable to me - we don't want "disable" the selection >>> radio button >>> and prevent the user from selecting it since our API does support it >>> as an option. >>> The way I first read the bug report was that it implied that the >>> first invocation >>> when the selection button was disabled was "right" and the 2nd >>> invocation >>> was "wrong" whereas it seems the other way around. >>> >>> If the updated code (and my understanding) is correct then should we >>> not in fact be updating getSelectAttrib() so that it never returns >>> PD_NOSELECTION, >>> rather than "fixing it up" in this code ? >>> >>> Of course you then need to look to see how we interpret & use a >>> return value of PD_NOSELECTIONfrom getSelectAttrib() on OS X and Linux. >>> >> getSelectAttrib() is not called in linux. >> But it's called in osx and we determine to/from pages to determine >> which radio button (All/Pages) to select >> http://hg.openjdk.java.net/jdk9/client/jdk/file/735a130dc8db/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m#l388 >> >> >> Regards >> Prasanta >>> I would really like to get Jennifer's input on this. >>> >>> -phil. >>> >>> On 4/13/16, 4:17 AM, prasanta sadhukhan wrote: >>>> Hi Phil, >>>> >>>> On 4/13/2016 4:52 AM, Phil Race wrote: >>>>> Hi, >>>>> >>>>> My reading here : >>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/ms646843%28v=vs.85%29.aspx >>>>> >>>>> >>>>> of the meaning of PD_NOSELECTION is that it disables the SELECTION >>>>> radio button such >>>>> that the user *cannot* select it. >>>>> >>>>> Is that true ? >>>> Yes, PD_NOSELECTION will disable SELECTION radio button. >>>>> If so this seems like it cannot be the right fix for this issue >>>>> and I am not sure why getSelectAttrib() would want to return that. >>>> protected final int getSelectAttrib() { >>>> if (attributes != null) { >>>> SunPageSelection pages = >>>> (SunPageSelection)attributes.get(SunPageSelection.class); >>>> if (pages == SunPageSelection.RANGE) { >>>> return PD_PAGENUMS; >>>> } else if (pages == SunPageSelection.SELECTION) { >>>> return PD_SELECTION; >>>> } else if (pages == SunPageSelection.ALL) { >>>> return PD_ALLPAGES; >>>> } >>>> } >>>> return PD_NOSELECTION; >>>> } >>>> so if SunPageSelection is not added to attribute which was the case >>>> in 1st instance so PD_NOSELECTION is returned >>>> and we have in awt_PrintControl.cpp#InitPrintDialog() >>>> if (selectType != 0) { selectType will be 4 for PD_NOSELECTION so >>>> pd.Flags will be set and Selection radio button is disabled in 1st >>>> instance >>>> pd.Flags |= selectType; >>>> } >>>>> Perhaps we never in practice return PD_NOSELECTION ? >>>>> >>>>> I am also unsure what it means to set flags to PD_NOSELECTION | >>>>> PD_SELECTION >>>>> as the windows docs don't tell me enough. >>>> It will still disable SELECTION radio button. >>>>> >>>>> Maybe what we want is just that we do not cause PD_SELECTION to be >>>>> set >>>>> rather than setting PD_NOSELECTION. >>>>> >>>> I have modified the webrev to not set PD_NOSELECTION if >>>> getSelectAttrib() returns NOSELECTION so it will mean Selection >>>> radiobutton will be enabled now but will not be selected UNLESS >>>> user selects >>>> job.setDefaultSelection(JobAttributes.DefaultSelectionType.SELECTION) >>>> explicitly in the application. >>>> >>>> http://cr.openjdk.java.net/~psadhukhan/6529030/webrev.01/ >>>> Also, I added @requires (os.family == windows) tag to make sure the >>>> test is run on windows only as in linux, osx we do not get the >>>> "selection" option [only All and Page range] for this test. >>>> >>>> Regards >>>> Prasanta >>>>> But to decide what to do I need to know the real effect of >>>>> PD_NOSELECTION. >>>>> >>>>> BTW about the test: you should make sure that the instructions are >>>>> valid on OS X and Linux .. >>>>> >>>>> -phil. >>>>> >>>>> On 04/06/2016 03:09 AM, prasanta sadhukhan wrote: >>>>>> Hi All, >>>>>> >>>>>> Please review a fix for jdk9. >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6529030 >>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6529030/webrev.00/ >>>>>> >>>>>> The issue was when using java.awt.print.PrinterJob instance more >>>>>> then once, Selection radio button in Print dialog gets enabled >>>>>> from 2nd instance even though we are printing "All" pages >>>>>> however Selection radio button is disabled in the first instance. >>>>>> This is seen in windows. >>>>>> >>>>>> This is because initially when windows initialized the print >>>>>> dialog, it calls InitPrintDialog() which calls getSelectAttrib() >>>>>> to find out which selection attribute user has selected. >>>>>> getSelectAttrib() returns PD_NOSELECTION as >>>>>> SunPageSelection.class was not added to attribute. >>>>>> So, in InitPrintDialog() we set PRINTDLG flags to PD_NOSELECTION. >>>>>> So, we see "Selection " radio button is disabled in 1st instance >>>>>> of print dialog. >>>>>> Now, when user presses "OK", windows native code calls >>>>>> setNativeAttributes() and adds SunPageSelection.class to the >>>>>> attribute with SunPageSelection.ALL or SunPageSelection.RANGE. >>>>>> >>>>>> When 2nd print dialog is shown, InitPrintDialog() will again call >>>>>> getSelectAttrib() which will now return >>>>>> SunPageSelection.ALL/SunPageSelection.RANGE which will be set to >>>>>> PRINTDLG flag but >>>>>> we are not disabling Selection radio button, so in 2nd instance, >>>>>> Selection radio button gets enabled. >>>>>> >>>>>> Fix was to check if PD_SELECTION attribute is selected by user, >>>>>> if not , sets PRINTDLG flag with PD_NOSELECTION. >>>>>> >>>>>> I have checked 8151590 and 8061267 works correctly with this patch. >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>> >>>> >> > From jayathirth.d.v at oracle.com Wed Apr 20 09:46:54 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 20 Apr 2016 02:46:54 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED In-Reply-To: <56C789E4.6000409@oracle.com> References: <2c9221dc-ed76-481a-8bee-a694d313448e@default> <56BD0CAB.6080704@oracle.com> <90de7741-c175-4803-9c3e-30b1039b2774@default> <56C227D1.1030600@oracle.com> <46329edf-4cbe-48d4-a519-c908b09844a6@default> <56C789E4.6000409@oracle.com> Message-ID: <7f5f1cd3-4022-4739-b412-9d3f3c74181f@default> Hi Jim, As discussed we will not add dithering error values to primary colors with color map which represents Primary colors approximately(+/-5 delta). I have made changes based on this suggestion and added new function to calculate whether color map represents primary colors approximately or not. If it represents only then we will avoid adding dithering error values in case ByteIndexed destination. I have observed that in case of white color we are picking (252,252,252) or (246,246,246) and not (255,255,255) from colormap. What I have observed that out of 256 places we are storing RGB colors at start and then gray values. So we are picking final gray value and not in between white value. That's why I am not verifying white color validity in test case. Please find updated webrev for review : http://cr.openjdk.java.net/~jdv/7116979/webrev.01/ Thanks, Jay -----Original Message----- From: Jim Graham Sent: Saturday, February 20, 2016 3:02 AM To: Jayathirth D V Cc: 2d-dev at openjdk.java.net; Philip Race; Prasanta Sadhukhan Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED Hi Jayathirth, Thank you for attaching the detailed logs, but I don't have a program that can deal with the 7z files. Can you summarize what was learned from them? Also, the colormap you created, while subset, was a perfectly scaled cube. I was referring more to a random colormap where you might have 2 colors close to a primary, but neither is on a line from the primary to the 0.5 gray value so each has a different hue. That's something that can only be evaluated visually. One example of randomized colormaps is when we display via X11 onto an 8-bit display. That probably never happens any more, but we may not be able to allocate colors in the colormap in such a case and if another program has already allocated most of the dynamic colormap then we would not be able to add our own colors. This could be dealt with by simply marking our standard colormap as having primaries, or by scanning any given colormap and marking it if it has primaries, and then only perform this code on colormaps with the primaries. Solving it for our own colormap (or solving it for any colormap that has all primaries) would likely solve it for 99% of the vanishingly small number of developers who might run into this. But, in the end, what would we accomplish by adding this one very targeted fix? I'm also curious where the push for this is coming from. While we aren't perfect here, so much of the world today is focused on lossless image formats that I don't imagine there is much need for really good 8-bit indexed image support any more...? If anything, spatial dithering is considered a very low quality algorithm and error propagation dithering would handle all of the colormaps much better. We used to do error propagation dithering back in the JDK 1.1 days, but we dropped it when we introduced 2D because we added a bunch of ways to render small pieces of an image and only the current spatial dithering algorithm can be started in the middle of an operation. That doesn't mean that you can't still do error propagation since many operations already operate on the full image any way and you can still handle subset image operations by either converting the full image first and then copying or by tracing the errors from the edge of the image to the point of the subimage operation. We never bothered to upgrade our algorithms it just never seemed to be work that made sense to prioritize given that screens were overwhelmingly moving to full-color at the time of "Java 2" (and now to HDR in 2016+). 8-bit indexed isn't used much any more. If we want to make 8-bit destination images work better we'd be better off adopting error propagation dithering again rather than trying to tune this algorithm for black. It looks like the bug was closed briefly in 2014 and then reopened soon thereafter with no justification. It is true that we still have this anomaly, but it isn't clear why this is high enough priority to work on in 2016 when other bit depths would work better for destination imagery and other dithering algorithms would work better for most customers and even this targeted fix isn't perfect... ...jim On 2/16/2016 8:32 AM, Jayathirth D V wrote: > Hi Jim, > > Thanks for letting me know about the importance of custom color maps. I was not able to understand what you mentioned previously since I am new to this terminology. > > Regarding performance I checked with image having complete 255,255,128 pixels and ran it for 100 times. I am running on Windows 7 Professional SP1 with Intel i5-5300U CPU. Overall I don't see much difference in time taken for drawImage() API before and after change. Details for INT_RGB image as input: > > Before change : > Minimum time 536827ns > Maximum time 1560947ns > Average time 871167ns > > After change : > Minimum time 536380ns > Maximum time 1468130ns > Average time 830778ns > > There is +/- 10% delta both for before and after change time but there is no major gap. Even for image with other input type it holds the same. > > > Regarding custom color maps, previously I ran on default color map generated in TYPE_BYTE_INDEXED constructor. Now I tested with modified color map so that it doesn't contain any of the primary color values. Instead of using 0-255 values with value 51 increments in R,G,B components I used color map with 20-245 values with value 45 as increment. For this color map before and after change all the pixels are referring to same index in color map irrespective of removal of error delta addition in case of primary colors. > > I have attached log for Red and Green primary colors before and after change(Was not able to attach for more since it exceeded 120KB mailing list limit). Please search for "Final index value =" in the logs. Please let me know your inputs. > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Tuesday, February 16, 2016 1:03 AM > To: Jayathirth D V > Cc: 2d-dev at openjdk.java.net; Philip Race; Prasanta Sadhukhan > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : > Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED > > Hi Jayathirth, > > The issue with testing performance with white images is that the tests allow the code to eliminate 3 indexed fetches which take time. Primary colors end up being the one obscure case where the new code might be faster. But, non-primary colors would be slower by a fair amount, so performance testing with converting a randomized or non-primary-color image are the more telling case. An image filled with 255,255,128 would be the worst case because it would involve all of the tests and still have to do all of the lookups. > > My question about how this works with custom colormaps was not really addressed by your response. A simple test to make sure the colormap has accurate (or very close) conversions for the primary colors may be enough to validate the colormap for the indicated tests. If the colormap contains no pure conversions for some of the primary colors then they may need to be dithered anyway... > > ...jim > > On 2/15/16 3:39 AM, Jayathirth D V wrote: >> Hi Jim, >> >> I performed performance analysis with white image so that all >> conditions are checked in the new branch added. There is no major >> difference in time taken before and after change. For each input I >> have tested time taken for drawImage() API to convert from every >> format to Byte indexed type. For every unique conversion test is run >> for 100 times. Please find the details: >> >> Input >> >> type >> >> >> >> Min >> >> before change >> >> (ns) >> >> >> >> Min >> >> after change >> >> (ns) >> >> >> >> Max >> >> before change >> >> (ns) >> >> >> >> Max >> >> after change >> >> (ns) >> >> >> >> Average >> >> before change >> >> (ns) >> >> >> >> Average >> >> after >> >> change >> >> (ns) >> >> INT_RGB >> >> >> >> 523437 >> >> >> >> 481491 >> >> >> >> 1230724 >> >> >> >> 1270440 >> >> >> >> 789452 >> >> >> >> 666144 >> >> INT_ARGB >> >> >> >> 500232 >> >> >> >> 493986 >> >> >> >> 12406307 >> >> >> >> 1308816 >> >> >> >> 793384 >> >> >> >> 654015 >> >> INT_ARGB_PRE >> >> >> >> 500233 >> >> >> >> 492201 >> >> >> >> 1037057 >> >> >> >> 981277 >> >> >> >> 710250 >> >> >> >> 699214 >> >> INT_BGR >> >> >> >> 537716 >> >> >> >> 562706 >> >> >> >> 1446703 >> >> >> >> 2046001 >> >> >> >> 862377 >> >> >> >> 863256 >> >> 3BYTE_BGR >> >> >> >> 483275 >> >> >> >> 481045 >> >> >> >> 1181638 >> >> >> >> 1384676 >> >> >> >> 651427 >> >> >> >> 580961 >> >> 4BYTE_ABGR >> >> >> >> 544410 >> >> >> >> 499786 >> >> >> >> 1292305 >> >> >> >> 968783 >> >> >> >> 690106 >> >> >> >> 683881 >> >> 4BYTE_ABGR_PRE >> >> >> >> 504249 >> >> >> >> 505588 >> >> >> >> 1680086 >> >> >> >> 1216445 >> >> >> >> 756101 >> >> >> >> 687750 >> >> USHORT_565_RGB >> >> >> >> 507818 >> >> >> >> 505588 >> >> >> >> 978153 >> >> >> >> 1346746 >> >> >> >> 652908 >> >> >> >> 655782 >> >> USHORT_555_RGB >> >> >> >> 510496 >> >> >> >> 509604 >> >> >> >> 952272 >> >> >> >> 1162004 >> >> >> >> 650418 >> >> >> >> 670811 >> >> BYTE_GRAY >> >> >> >> 481491 >> >> >> >> 478367 >> >> >> >> 1140585 >> >> >> >> 1799231 >> >> >> >> 691160 >> >> >> >> 583250 >> >> USHORT_GRAY >> >> >> >> 506927 >> >> >> >> 507373 >> >> >> >> 1375751 >> >> >> >> 1255267 >> >> >> >> 728202 >> >> >> >> 646902 >> >> BYTE_BINARY >> >> >> >> 541733 >> >> >> >> 496217 >> >> >> >> 1083466 >> >> >> >> 959411 >> >> >> >> 730527 >> >> >> >> 728461 >> >> The changes are tested with plain images having primary colors like >> RED, GREEN, BLUE, BLACK and WHITE. >> >> Thanks, >> >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Friday, February 12, 2016 4:05 AM >> To: Jayathirth D V; 2d-dev at openjdk.java.net; Philip Race; Prasanta >> Sadhukhan >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : >> Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED >> >> Hi Jayathirth, >> >> Did you do any performance analysis of this change? You are adding 6 >> tests and multiple branches to per-pixel code. >> >> The effectiveness of this technique depends on the colormap that we >> have set up. For the BufferedImage.TYPE_INDEXED constructor we >> produce a fairly nice colormap, but if someone creates a custom >> colormap then the colors could be anything. We create a decent >> inversion for just about any colormap, but that doesn't mean that >> using only "the best match for solid red" will produce a better >> result for a dithered approximation for red. It is true that if >> there is a really good match for red then we should just use that, >> but if there are no direct matches for red then we may choose to >> paint a red region with solid orange even though there is another >> color in the colormap that when mixed with orange approximates a red >> tone better. For example, if a colormap contains no pure red, but >> >> contains: >> >> 240, 20, 0 >> >> 240, 0, 20 >> >> (I'm not sure if 20 is within our current error deltas that we use >> for dithering, but this is an example not a test case.) >> >> Then using one of these alone might skew the color towards orange or >> purple. Using both together in a dither pattern might keep the >> overall hue impression as red, but with a small amount of noise in its saturation. >> >> What types of colormaps was this tested with? >> >> ...jim >> >> On 2/11/16 6:37 AM, Jayathirth D V wrote: >> >>> Hi, >> >>> >> >>> _Please review the following fix in JDK9:_ >> >>> >> >>> __ >> >>> >> >>> Bug :https://bugs.openjdk.java.net/browse/JDK-7116979 >> >>> >> >>> Webrev :http://cr.openjdk.java.net/~jdv/7116979/webrev.00/ >> >>> >> >>> Issue : When Image containing black pixels are converted from any >> >>> format to Byte Indexed format some of the pixels are not black. They >> >>> are following pattern similar to dithering. >> >>> >> >>> Root cause : When we convert any format type to ByteIndexed we are >> >>> adding Error delta values to R,G,B components using dithering indices. >> >>> This is causing some pixels values to not point to proper index in >> >>> color table. >> >>> >> >>> Solution : There is no need to add error delta for primary colors >> >>> containing basic values in R,G,B components. Exclude such pixels >>> from >> >>> delta addition. >> >>> >> >>> Thanks, >> >>> >> >>> Jay >> >>> >> From jayathirth.d.v at oracle.com Wed Apr 20 12:45:27 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 20 Apr 2016 05:45:27 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8153943 : In java.awt.image package some of the classes are missing hashCode() or equals() method Message-ID: Hi, Please review the following fix in JDK9: Bug : https://bugs.openjdk.java.net/browse/JDK-8153943 This is subtask of https://bugs.openjdk.java.net/browse/JDK-6588409 Webrev : http://cr.openjdk.java.net/~jdv/8153943/webrev.00/ Issue : Some of the java.awt.image classes are missing either equals() or hashCode() method. Solution : Add missing equals() or hashCode() methods. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.batrak at jetbrains.com Wed Apr 20 13:14:11 2016 From: dmitry.batrak at jetbrains.com (Dmitry Batrak) Date: Wed, 20 Apr 2016 16:14:11 +0300 Subject: [OpenJDK 2D-Dev] [PATCH] JDK-8152680: Regression in GlyphVector.getGlyphCharIndex behaviour Message-ID: Hello, I'd like to propose a patch for JDK-8152680 - an issue I've raised via bugreport.java.com earlier, hope someone can sponsor it. I have a Contributor status via agreement signed by Jetbrains. The issue is related to the extraction of glyph-to-character mapping from results of text layout, performed by Harfbuzz, when layout is requested for a specified substring of text string. For LTR case, existing code assumes that cluster values (which are later interpreted as character indices) are assigned by Harfbuzz starting from the beginning of substring, but actually it's done starting from the beginning of whole string (as mentioned by existing comment in HBShaper.c). For reference, this logic can be found at hb-buffer.cc:1470 (function hb_buffer_add_utf). The proposed fix is to take into account this numbering scheme by shifting cluster value correspondingly. GlyphCharIndicesTest test case is included to cover this fix. RTL case is not affected by the problem mentioned above, but there's another issue with it - cluster value generated by Harfbuzz is ignored completely, instead character index is taken to be equal to glyph index (in visual order). This will not work, e.g. in case when there are more glyphs than characters - some glyphs will reference non-existing characters. The proposed fix is just to use the same shifted cluster value, as for LTR case - I believe it works just as well in RTL case. GlyphCharIndicesRtlTest test case is included to cover RTL case, but I'm not sure it should be definitely committed, as it depends on a specific Windows font, which doesn't seem to be available by default in Windows 10 (even though it must be present in Windows Vista, 7 and 8). I couldn't find a better font on Windows, demonstrating the issue. Webrev for the fix is available at http://cr.openjdk.java.net/~avu/DmitryBatrak/JDK-8152680 (kindly posted by my colleague, having access to cr.openjdk.java.net). Best regards, Dmitry Batrak -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Apr 20 17:17:39 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 20 Apr 2016 10:17:39 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8153943 : In java.awt.image package some of the classes are missing hashCode() or equals() method In-Reply-To: References: Message-ID: <5717B9B3.3090807@oracle.com> Hi, You removed the following test in CCM.java : 2941 if (obj.getClass() != getClass()) { 2942 return false; 2943 } What this means is that before your change an instance of a subclass of CCM would never be equals() to any direct instantiatation of CCM but after your change it can be. I suspect the condition was there on purpose. -phil. On 04/20/2016 05:45 AM, Jayathirth D V wrote: > > Hi, > > _Please review the following fix in JDK9:_ > > Bug : https://bugs.openjdk.java.net/browse/JDK-8153943 > > This is subtask of https://bugs.openjdk.java.net/browse/JDK-6588409 > > Webrev : http://cr.openjdk.java.net/~jdv/8153943/webrev.00/ > > > Issue : Some of the java.awt.image classes are missing either equals() > or hashCode() method. > > Solution : Add missing equals() or hashCode() methods. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Wed Apr 20 19:27:37 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 20 Apr 2016 22:27:37 +0300 Subject: [OpenJDK 2D-Dev] Fix for JDK-8074829 : Resolve disabled warnings for libawt_headless In-Reply-To: References: Message-ID: <5717D829.8070704@oracle.com> 2d-dev added. I am not sure but why "declaration in the code" is a bad thing and we should fix it? - DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE I cannot find the documentation in solaris studio for this warning. On 20.04.16 11:57, Ajit Ghaisas wrote: > Hi, > > Bug : https://bugs.openjdk.java.net/browse/JDK-8074829 > This bug is to remove warning suppressions from makefile and fix the warnings for libawt_headless library. > > I have removed following warning suppressions & fixed the warnings for libawt_headless library. > DISABLED_WARNINGS_gcc := maybe-uninitialized int-to-pointer-cast > DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE > > Warning suppression that cannot be removed : > DISABLED_WARNINGS_solstudio := E_EMPTY_TRANSLATION_UNIT > This is due to the fact that - jdk/src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops.c file becomes empty file in case of HEADLESS mode compilation. > Request you to review following webrev : > http://cr.openjdk.java.net/~aghaisas/8074829/webrev.00/ > > Regards, > Ajit > -- Best regards, Sergey. From philip.race at oracle.com Wed Apr 20 20:19:20 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 20 Apr 2016 13:19:20 -0700 Subject: [OpenJDK 2D-Dev] Fix for JDK-8074829 : Resolve disabled warnings for libawt_headless In-Reply-To: <5717D829.8070704@oracle.com> References: <5717D829.8070704@oracle.com> Message-ID: <5717E448.7000003@oracle.com> On 04/20/2016 12:27 PM, Sergey Bylokhov wrote: > 2d-dev added. In fact all these are 2D. No AWT warnings here. > > I am not sure but why "declaration in the code" is a bad thing and we > should fix it? > - DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE > > I cannot find the documentation in solaris studio for this warning. I don't mind fixing it if it is still an issue but does the current compiler actually complain about it ? The SS11 -> SS12 upgrade might have got a more modern C compiler .. > > On 20.04.16 11:57, Ajit Ghaisas wrote: >> Hi, >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8074829 >> This bug is to remove warning suppressions from makefile and fix >> the warnings for libawt_headless library. >> >> I have removed following warning suppressions & fixed the >> warnings for libawt_headless library. >> DISABLED_WARNINGS_gcc := maybe-uninitialized int-to-pointer-cast What made that one go away ?? >> DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE >> >> Warning suppression that cannot be removed : >> DISABLED_WARNINGS_solstudio := E_EMPTY_TRANSLATION_UNIT >> This is due to the fact that - >> jdk/src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops.c >> file becomes empty file in case of HEADLESS mode compilation. Sigh .. there ought to be "informational" warnings as well as "risky practice" warnings and this should be in the former category. You could move something like the jni.h and jlong.h imports outside to see if that shuts it up. Not saying that is what we want to do but it would be interesting to check. -phil. > >> Request you to review following webrev : >> http://cr.openjdk.java.net/~aghaisas/8074829/webrev.00/ >> >> Regards, >> Ajit >> > > From alexandr.scherbatiy at oracle.com Wed Apr 20 20:46:43 2016 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 21 Apr 2016 00:46:43 +0400 Subject: [OpenJDK 2D-Dev] [9] Review request for 8152309 Seamless way of using image filters with multi-resolution images In-Reply-To: <57169024.9080001@oracle.com> References: <5703CBE9.8030800@oracle.com> <57169024.9080001@oracle.com> Message-ID: <5717EAB3.6010506@oracle.com> On 20/04/16 00:08, Phil Race wrote: > I've gone up and down the API (and most of the implementation) > > ResolutionVariantItem is really only used in the public API in one > place :- > > ImageProducer defines :- > > + default List> > getResolutionVariantItems() { > + return Arrays.asList(new ResolutionVariantItem<>(this, 1, 1)); > > > The sort-of second place is that FilteredImageSource over-rides this. > The rest is the internal uses of the class (and its definition of course) > > So do we need such a generic sounding API class for this one case, (or > are there other API-level uses?) and is there a different approach > which avoid the new class entirely ? The ResolutionVariantItem class in this case is used to provide scale factors for the ImageFilter and MediaTracker. If we want to avoid this class it is necessary to understand from which place these scale factors can be obtained. The MultiResolutionImage has just getResolutionVariant(width, height) method which allows to provide an image either from a set of resolution variants or just generating an image with requested size. It seems that generation an image for requested size is not an option for multi-resolution Toolkit image just because it can be loaded by MediaTracker. MediaTracker.addImage(Image, id, width, height) method needs to load all resolution variants from the provided multi-resolution image. First it means that there should be finite number of them. The second is that for passed width and height argument it needs to calculate size for the resolution variants which are not loaded yet. This is the first place where the scale factors need to be provided with resolution variant: MediaTracker.addImage(mriImage, id, w, h) -> MediaTracker.addImage(resolutionVariant, id, w * rvScaleX, h * rvScaleY) The second place where the resolution variant scales are used is SunGraphics2D.drawImage() method when it draws a multi-resoltion image with an applied filter. Image mrImage = // create a multi-resolution image ImageProducer filteredImageSource = new FilteredImageSource(mrImage.getSource(), filter); Image filteredImage = toolkit.createImage(filteredImageSource); SunGraphics2D.drawImage() calls getResolutionVariant(mrImage, ...) method to get a resolution variant with the requested destination width and height to draw it. The resolution variant in this case is just a ToolkitImage which source is FilteredImageSource an filter is a scaled filter: toolkit.createImage(new FilteredImageSource(resulutionVariant.getSource(), filter.getScaledFilterInstance(scaleX, scaleY))) And the question is where the the scale factors can be obtained for this case? If there are others way to provide scale factors for the described cases it will allow to not use new classes like ResolutionVariantItem. Thanks, Alexandr. > > Assuming ResolutionVariantItem is the right name - and design - it > seems like it could use a bit more class javadoc, even if it is basically > a bag to hold a few things. > > There are few formatting/typo things I noticed but no point in talking > about > those until the rest is near conclusion. > > -phil. > > On 04/05/2016 07:30 AM, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8152309 >> webrev: http://cr.openjdk.java.net/~alexsch/8152309/webrev.00 >> >> >> The purpose of the fix is to allow to apply an image filter for a >> multi-resolution image to get new multi-resolution image so the code >> below works without changes: >> ---------- >> Image mrImage = getMultiResolutionImage(); >> ImageProducer mriProducer = new >> FilteredImageSource(mrImage.getSource(), new CropImageFilter(x, y, w, >> h)); >> Image filteredMRImage = >> Toolkit.getDefaultToolkit().createImage(mriProducer); >> ---------- >> >> >> The Image producer needs to be updated to contain a set of >> resolution-variant image producers. It can be done introducing a new >> MultiResolution[Image]Producer interface. However, the >> FilteredImageSource which takes an original image producer as a >> constructor argument needs to be declared as >> MultiResolution[Image]Producer even for ordinary image producers. >> I chose to add the getRVProducers() method directly to the >> ImageProducer interface. >> >> The option to add a method which request a resolution variant >> producer for the given image size (getRVProducer(width, height) ) >> seems is not possible because the result multi-resolution image can >> be loaded by a MediaTracker which can load only finite number of >> resolution variants. >> >> Applying an image filter to resolution-variant producers requires to >> scale filters which use fixed image size (like CropImageFilter and >> ReplicateScaleFilter). >> There should be a way to get a scaled filter using the original one. >> The resolution variant image producer need to provide necessary scale >> factors for the used filter. >> To do that getScaledFilterInstance(scaleX, scaleY) method is added to >> the ImageFilter and public ResolutionVariantItem class which can hold >> image or image producer with associated scale factors is introduced. >> >> There is an interesting problem in SunGraphics2D where a >> multi-resolution image size is requested. To do that it is necessary >> to have an image observer which needs to redirect calls to the base >> image observer. The resolution variant observer needs to know scale >> factors to recalculate given [x, y, width, height] values. The scale >> factors are provided by toolkit multi-resolution image but for non >> toolkit multi-resolution images they need to be calculated dividing a >> rv-image size to base image size. It looks like a closed loop when to >> know scale factors it needs to get a rv-image size but for this it is >> necessary to use an image observer which requires scale factors. >> The current fix just divides rv-image size to base image size for non >> toolkit multi-resolution images to get scale factors . >> >> Thanks, >> Alexandr. >> > From prasanta.sadhukhan at oracle.com Thu Apr 21 10:05:21 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Thu, 21 Apr 2016 15:35:21 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6529030, , Java Printing: Print range > Selection gets enabled In-Reply-To: <57174743.4030205@oracle.com> References: <5704E06F.2010502@oracle.com> <570D8352.5060405@oracle.com> <570E2AE1.4020604@oracle.com> <570E7D6D.9040306@oracle.com> <5710C3B0.1020304@oracle.com> <5716AFA4.6040309@oracle.com> <57174743.4030205@oracle.com> Message-ID: <5718A5E1.9000306@oracle.com> Hi Phil, As we discussed that java.awt.PrintJob should have selection radio button enabled as JobAttributes supports selection but java.awt.print.PrinterJob should NOT have selection radio button enabled as at API level, we do not support selection. So, as per suggestion by Jennifer I have modified the setNativeAttributes to check for PD_NOSELECTION and found we conform to the above theory. We have selection button enabled for jdk1.1 printjob but disabled for jdk1.2 PrinterJob. Also, since it is a windows specific code fix, it will not effect any other platform. Please review modified webrev: http://cr.openjdk.java.net/~psadhukhan/6529030/webrev.02/ Regards Prasanta On 4/20/2016 2:39 PM, prasanta sadhukhan wrote: > Hi Jennifer, > > If I do not set SunPageSelection attribute in setNativeAttributes() > like this > > + if ((flags & PD_NOSELECTION) != PD_NOSELECTION) { > if ((flags & PD_PAGENUMS) != 0) { > attributes.add(SunPageSelection.RANGE); > } else if ((flags & PD_SELECTION) != 0) { > attributes.add(SunPageSelection.SELECTION); > } else { > attributes.add(SunPageSelection.ALL); > } > + } > without doing my fix in awt_PrintControl.cpp#InitPrintDialog() it will > disable the selection radio button for both invocation as > getSelectAttrib() returns PD_NOSELECTION. > I think my fix in InitPrintDialog() > http://cr.openjdk.java.net/~psadhukhan/6529030/webrev.01/ > is required for this fix. > > Regards > Prasanta > On 4/20/2016 3:52 AM, Jennifer Godinez wrote: >> Hi Prasanta, >> >> It looks to me that we missed to check (flags & PD_NOSELECTION) in >> setNativeAttributes that's why we are setting SunPageSelection >> attribute when we shouldn't. I think that is where we should put the >> fix. >> >> Jennifer >> >> On 04/15/2016 03:34 AM, prasanta sadhukhan wrote: >>> Hi Phil, >>> >>> On 4/13/2016 10:40 PM, Philip Race wrote: >>>> This seems reasonable to me - we don't want "disable" the selection >>>> radio button >>>> and prevent the user from selecting it since our API does support >>>> it as an option. >>>> The way I first read the bug report was that it implied that the >>>> first invocation >>>> when the selection button was disabled was "right" and the 2nd >>>> invocation >>>> was "wrong" whereas it seems the other way around. >>>> >>>> If the updated code (and my understanding) is correct then should we >>>> not in fact be updating getSelectAttrib() so that it never returns >>>> PD_NOSELECTION, >>>> rather than "fixing it up" in this code ? >>>> >>>> Of course you then need to look to see how we interpret & use a >>>> return value of PD_NOSELECTIONfrom getSelectAttrib() on OS X and >>>> Linux. >>>> >>> getSelectAttrib() is not called in linux. >>> But it's called in osx and we determine to/from pages to determine >>> which radio button (All/Pages) to select >>> http://hg.openjdk.java.net/jdk9/client/jdk/file/735a130dc8db/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m#l388 >>> >>> >>> Regards >>> Prasanta >>>> I would really like to get Jennifer's input on this. >>>> >>>> -phil. >>>> >>>> On 4/13/16, 4:17 AM, prasanta sadhukhan wrote: >>>>> Hi Phil, >>>>> >>>>> On 4/13/2016 4:52 AM, Phil Race wrote: >>>>>> Hi, >>>>>> >>>>>> My reading here : >>>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/ms646843%28v=vs.85%29.aspx >>>>>> >>>>>> >>>>>> of the meaning of PD_NOSELECTION is that it disables the >>>>>> SELECTION radio button such >>>>>> that the user *cannot* select it. >>>>>> >>>>>> Is that true ? >>>>> Yes, PD_NOSELECTION will disable SELECTION radio button. >>>>>> If so this seems like it cannot be the right fix for this issue >>>>>> and I am not sure why getSelectAttrib() would want to return that. >>>>> protected final int getSelectAttrib() { >>>>> if (attributes != null) { >>>>> SunPageSelection pages = >>>>> (SunPageSelection)attributes.get(SunPageSelection.class); >>>>> if (pages == SunPageSelection.RANGE) { >>>>> return PD_PAGENUMS; >>>>> } else if (pages == SunPageSelection.SELECTION) { >>>>> return PD_SELECTION; >>>>> } else if (pages == SunPageSelection.ALL) { >>>>> return PD_ALLPAGES; >>>>> } >>>>> } >>>>> return PD_NOSELECTION; >>>>> } >>>>> so if SunPageSelection is not added to attribute which was the >>>>> case in 1st instance so PD_NOSELECTION is returned >>>>> and we have in awt_PrintControl.cpp#InitPrintDialog() >>>>> if (selectType != 0) { selectType will be 4 for PD_NOSELECTION so >>>>> pd.Flags will be set and Selection radio button is disabled in 1st >>>>> instance >>>>> pd.Flags |= selectType; >>>>> } >>>>>> Perhaps we never in practice return PD_NOSELECTION ? >>>>>> >>>>>> I am also unsure what it means to set flags to PD_NOSELECTION | >>>>>> PD_SELECTION >>>>>> as the windows docs don't tell me enough. >>>>> It will still disable SELECTION radio button. >>>>>> >>>>>> Maybe what we want is just that we do not cause PD_SELECTION to >>>>>> be set >>>>>> rather than setting PD_NOSELECTION. >>>>>> >>>>> I have modified the webrev to not set PD_NOSELECTION if >>>>> getSelectAttrib() returns NOSELECTION so it will mean Selection >>>>> radiobutton will be enabled now but will not be selected UNLESS >>>>> user selects >>>>> job.setDefaultSelection(JobAttributes.DefaultSelectionType.SELECTION) >>>>> explicitly in the application. >>>>> >>>>> http://cr.openjdk.java.net/~psadhukhan/6529030/webrev.01/ >>>>> Also, I added @requires (os.family == windows) tag to make sure >>>>> the test is run on windows only as in linux, osx we do not get the >>>>> "selection" option [only All and Page range] for this test. >>>>> >>>>> Regards >>>>> Prasanta >>>>>> But to decide what to do I need to know the real effect of >>>>>> PD_NOSELECTION. >>>>>> >>>>>> BTW about the test: you should make sure that the instructions are >>>>>> valid on OS X and Linux .. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 04/06/2016 03:09 AM, prasanta sadhukhan wrote: >>>>>>> Hi All, >>>>>>> >>>>>>> Please review a fix for jdk9. >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6529030 >>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6529030/webrev.00/ >>>>>>> >>>>>>> The issue was when using java.awt.print.PrinterJob instance more >>>>>>> then once, Selection radio button in Print dialog gets enabled >>>>>>> from 2nd instance even though we are printing "All" pages >>>>>>> however Selection radio button is disabled in the first instance. >>>>>>> This is seen in windows. >>>>>>> >>>>>>> This is because initially when windows initialized the print >>>>>>> dialog, it calls InitPrintDialog() which calls getSelectAttrib() >>>>>>> to find out which selection attribute user has selected. >>>>>>> getSelectAttrib() returns PD_NOSELECTION as >>>>>>> SunPageSelection.class was not added to attribute. >>>>>>> So, in InitPrintDialog() we set PRINTDLG flags to >>>>>>> PD_NOSELECTION. So, we see "Selection " radio button is disabled >>>>>>> in 1st instance of print dialog. >>>>>>> Now, when user presses "OK", windows native code calls >>>>>>> setNativeAttributes() and adds SunPageSelection.class to the >>>>>>> attribute with SunPageSelection.ALL or SunPageSelection.RANGE. >>>>>>> >>>>>>> When 2nd print dialog is shown, InitPrintDialog() will again >>>>>>> call getSelectAttrib() which will now return >>>>>>> SunPageSelection.ALL/SunPageSelection.RANGE which will be set to >>>>>>> PRINTDLG flag but >>>>>>> we are not disabling Selection radio button, so in 2nd instance, >>>>>>> Selection radio button gets enabled. >>>>>>> >>>>>>> Fix was to check if PD_SELECTION attribute is selected by user, >>>>>>> if not , sets PRINTDLG flag with PD_NOSELECTION. >>>>>>> >>>>>>> I have checked 8151590 and 8061267 works correctly with this patch. >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>> >>>>> >>> >> > From jayathirth.d.v at oracle.com Thu Apr 21 11:39:34 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 21 Apr 2016 04:39:34 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8153943 : In java.awt.image package some of the classes are missing hashCode() or equals() method In-Reply-To: <5717B9B3.3090807@oracle.com> References: <5717B9B3.3090807@oracle.com> Message-ID: Hi Phil, Thanks for the review. I have updated the recommended changes also I made similar change in PixelInterleavedSampleModel.java because it is also a non-final & non-abstract class. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/8153943/webrev.01/ Thanks, Jay From: Phil Race Sent: Wednesday, April 20, 2016 10:48 PM To: Jayathirth D V Cc: Jim Graham; Prasanta Sadhukhan; 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8153943 : In java.awt.image package some of the classes are missing hashCode() or equals() method Hi, You removed the following test in CCM.java : 2941 if (obj.getClass() != getClass()) { 2942 return false; 2943 } What this means is that before your change an instance of a subclass of CCM would never be equals() to any direct instantiatation of CCM but after your change it can be. I suspect the condition was there on purpose. -phil. On 04/20/2016 05:45 AM, Jayathirth D V wrote: Hi, Please review the following fix in JDK9: Bug : https://bugs.openjdk.java.net/browse/JDK-8153943 This is subtask of https://bugs.openjdk.java.net/browse/JDK-6588409 Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8153943/webrev.00/"http://cr.openjdk.java.net/~jdv/8153943/webrev.00/ Issue : Some of the java.awt.image classes are missing either equals() or hashCode() method. Solution : Add missing equals() or hashCode() methods. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajit.ghaisas at oracle.com Thu Apr 21 13:33:06 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Thu, 21 Apr 2016 06:33:06 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Fix for JDK-8074829 : Resolve disabled warnings for libawt_headless In-Reply-To: <5717E448.7000003@oracle.com> References: <5717D829.8070704@oracle.com> <5717E448.7000003@oracle.com> Message-ID: <48002ede-2af9-4bf2-bb32-f38114ea438b@default> >>On 04/20/2016 12:27 PM, Sergey Bylokhov wrote: >> 2d-dev added. >In fact all these are 2D. No AWT warnings here. >> >> I am not sure but why "declaration in the code" is a bad thing and we >> should fix it? >> - DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE >> >> I cannot find the documentation in solaris studio for this warning. >I don't mind fixing it if it is still an issue but does the current compiler actually complain about it ? >The SS11 -> SS12 upgrade might have got a more modern C compiler .. [Ajit ] Yes. The Solaris compiler still complains about this declaration in code. Hence, I have fixed the reported warnings after removing the suppression from makefile. >> >> On 20.04.16 11:57, Ajit Ghaisas wrote: >>> Hi, >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8074829 >>> This bug is to remove warning suppressions from makefile and fix >>> the warnings for libawt_headless library. >>> >>> I have removed following warning suppressions & fixed the >>> warnings for libawt_headless library. >>> DISABLED_WARNINGS_gcc := maybe-uninitialized int-to-pointer-cast >What made that one go away ?? [Ajit] : I fixed warnings reported for 'maybe-uninitialized' and 'E_DECLARATION_IN_CODE' warning types in two .c files in webrev. There was no warning after removal of 'int-to-pointer-cast' suppression from makefile. No code change was made for this type of warning. >>> DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE >>> >>> Warning suppression that cannot be removed : >>> DISABLED_WARNINGS_solstudio := E_EMPTY_TRANSLATION_UNIT >>> This is due to the fact that - >>> jdk/src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops.c >>> file becomes empty file in case of HEADLESS mode compilation. >Sigh .. there ought to be "informational" warnings as well as "risky practice" warnings and this should be in the former category. >You could move something like the jni.h and jlong.h imports outside to see if that shuts it up. >Not saying that is what we want to do but it would be interesting to check. [Ajit] : Nope. Moving jni.h or jlong.h inclusions outside #ifndef HEADLESS did not help. We still get E_EMPTY_TRANSLATION_UNIT warning. To get rid of this warning, there are suggestions to make a typedef - and not use it anywhere - but, I would rather keep the suppression in makefile than defining a typedef without actual usage. Another solution is to exclude this file from HEADLESS compilation. I am not sure how to achieve it. Any suggestion? >-phil. >> >>> Request you to review following webrev : >>> http://cr.openjdk.java.net/~aghaisas/8074829/webrev.00/ >>> >>> Regards, >>> Ajit From alexey.ivanov at oracle.com Thu Apr 21 14:37:18 2016 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Thu, 21 Apr 2016 17:37:18 +0300 Subject: [OpenJDK 2D-Dev] [9] request for review: 8078382: Wrong glyph is displayed for a derived font In-Reply-To: <55AFC5DA.1030408@oracle.com> References: <55A64031.3060205@oracle.com> <55A68982.9090906@oracle.com> <55A7ACBD.9040403@oracle.com> <55A7FA20.7000105@oracle.com> <55AFC5DA.1030408@oracle.com> Message-ID: <5718E59E.6060804@oracle.com> Hi Phil, I ran a number of tests with different fonts: Windows GDI consistently selects Bold rather than Italic to produce the missing Bold Italic. So I suggest using Andrew's first patch: http://cr.openjdk.java.net/~bae/8078382/9/webrev.00/ The patch changes the order of font selection: bold will be used, if possible, as the base for bold-italic instead of italic which is the current default. It also fixes the issue where italic is returned instead of bold. Thank you in advance, Alexey On 22.07.2015 19:33, Alexey Ivanov wrote: > Hi Phil, > > On 16.07.2015 21:38, Phil Race wrote: >> On 07/16/2015 06:08 AM, Andrew Brygin wrote: >>> Hi Phil, >>> >>> another option to avoid the problem is to be a bit more specific >>> regarding the >>> required font when we obtaining lcd glyph from GDI. >>> If we specify a particular name of the font which we used to >>> construct the >>> glyph vector, then we will get glyphs exactly for desired characters: >>> >>> http://cr.openjdk.java.net/~bae/8078382/9/webrev.01/ >>> >>> This change affects only the case of lcd glyphs on windows, >>> it reduces the scope of required testing. >> >> This is heading in the direction I was thinking of but since GDI is >> excepting a face name >> (what we call a family name), I am not sure if this will always work >> as is. >> There are possible issues with using a localized name and the length >> of the full name exceeding what Windows allows here. >> And there may be unintended consequences that are not immediately >> obvious. >> I would like to try limit this to the case where we can positively >> identify that the >> font is not the one we expected. And do it cheaply too. >> I do not have a quick answer here but roughly the algorithm might be >> - specify family, check (somehow) if GDI selects the same base font >> - if not, try the facename approach (if the name fits). Did we >> succeed and get the same base font ? >> - if not, bail on GDI for this case and do the rasterisation ourselves. >> >> "cheaply" might depend on caching a success value on the first >> attempt, so >> that we only do it once, ever, for a font. Then the problem becomes >> how to >> do the verification. One approach might be to call GetFontData() which >> will give us some chunk of the font file and we can see if the name >> (or something >> else we can quickly and reliably parse) is exactly that we expect .. > > It looks there's no easy way to detect whether GDI selected the same > base font or not. GetTextFace function doesn't help it: it always > returns the face name passed in LOGFONT except in the cases where > there's no such font. > > I haven't found any other API which could tell us what font GDI > selected. So the only alternative is to use GetFontData and parse the > font file itself. Yet I can't find any example how to use this > function. I'll keep searching in that direction. > > > Regards, > Alexey > >> >> Leaving aside the 'wrong glyph' case, I have to suppose it is >> possible that >> there are other un-noticed cases where we use a different base font than >> that selected by GDI. The algorithms are not defined anywhere I can >> locate. >> >>> >>> However, there seems to be a copy&paste error in FontFamily.java: >>> on lines 340 - 341 we check that bold font fits our needs but use >>> italic >>> anyway. Was it done by purpose, or this is really an error? >> >> That is a copy/paste mistake. It should be fixed. >> >> -phil. >> >>> >>> Thanks, >>> Andrew >>> >>> On 7/15/2015 7:25 PM, Phil Race wrote: >>>> This probably needs more examination and perhaps a more complex fix. >>>> The observation that GDI bases bold-italic on the bold version not the >>>> italic version is an implementation choice just as we had done the >>>> opposite. It is possible some other time it does the opposite or some >>>> other platform does the opposite. I have supposed it is harder to >>>> synthesise italic than to do 'over-strike'. And this GDI usage >>>> applies only to LCD glyphs. >>>> >>>> Maybe what we need to do is see if we can detect the cases when >>>> GDI and JDK disagree on the actual font and remap the glyph id. >>>> >>>> -phil. >>>> >>>> On 7/15/15 4:12 AM, Andrew Brygin wrote: >>>>> Hello, >>>>> >>>>> could you please review a fix for 8078382? >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8078382 >>>>> webrev: http://cr.openjdk.java.net/~bae/8078382/9/webrev.00/ >>>>> >>>>> The problem is caused by following peculiarity of the Code New >>>>> Roman font: this font provides plain, italic and bold variants. >>>>> In bold and italic variants of the font, different glyphs >>>>> correspond to the apostrophe character (0039): >>>>> bold: 0039 -> 0x250 (592) >>>>> italic: 0039 -> 0x256 (598) >>>>> >>>>> So, we translate character to glyphs using italic variant >>>>> of the font, and then request glyph images from GDI. >>>>> However, GDI uses the bold variant of the font in order >>>>> to compose glyph images for artificial bold-italic variant, >>>>> and we have got a glyph image for ? instead of apostrophe. >>>>> >>>>> Suggested fix is to select bold variant (if possible) as a >>>>> base for artificial bold-italic. >>>>> >>>>> There is no regression test because it requires a specific font >>>>> to be installed on a test system. The font can be found here: >>>>> http://www.dafont.com/code-new-roman.font >>>>> >>>>> Please take a look. >>>>> >>>>> Thanks, >>>>> Andrew >>>> >>> >> > From philip.race at oracle.com Thu Apr 21 20:13:21 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 21 Apr 2016 13:13:21 -0700 Subject: [OpenJDK 2D-Dev] Fix for JDK-8074829 : Resolve disabled warnings for libawt_headless In-Reply-To: <48002ede-2af9-4bf2-bb32-f38114ea438b@default> References: <5717D829.8070704@oracle.com> <5717E448.7000003@oracle.com> <48002ede-2af9-4bf2-bb32-f38114ea438b@default> Message-ID: <57193461.1090904@oracle.com> > Another solution is to exclude this file from HEADLESS compilation. > I am not sure how to achieve it. Any suggestion? I suppose that is possible and I expect we can do that See in the make file, where I think you just need to add entries to LIBAWT_HEADLESS_EXCLUDES := medialib although I have not tried it. Hmm .. I wonder why medialib needs to be explicitly excluded from headless ? .. but that is for another day. I have another question: why do you mention only OGLBlitLoops.c ? I've flicked through a number of the C files in the same location and all look to have the same issue. -phil. On 04/21/2016 06:33 AM, Ajit Ghaisas wrote: >>> On 04/20/2016 12:27 PM, Sergey Bylokhov wrote: >>> 2d-dev added. >> In fact all these are 2D. No AWT warnings here. >>> I am not sure but why "declaration in the code" is a bad thing and we >>> should fix it? >>> - DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE >>> >>> I cannot find the documentation in solaris studio for this warning. >> I don't mind fixing it if it is still an issue but does the current compiler actually complain about it ? >> The SS11 -> SS12 upgrade might have got a more modern C compiler .. > [Ajit ] Yes. The Solaris compiler still complains about this declaration in code. Hence, I have fixed the reported warnings after removing the suppression from makefile. > >>> On 20.04.16 11:57, Ajit Ghaisas wrote: >>>> Hi, >>>> >>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8074829 >>>> This bug is to remove warning suppressions from makefile and fix >>>> the warnings for libawt_headless library. >>>> >>>> I have removed following warning suppressions & fixed the >>>> warnings for libawt_headless library. >>>> DISABLED_WARNINGS_gcc := maybe-uninitialized int-to-pointer-cast >> What made that one go away ?? > [Ajit] : I fixed warnings reported for 'maybe-uninitialized' and 'E_DECLARATION_IN_CODE' warning types in two .c files in webrev. > There was no warning after removal of 'int-to-pointer-cast' suppression from makefile. No code change was made for this type of warning. > > >>>> DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE >>>> >>>> Warning suppression that cannot be removed : >>>> DISABLED_WARNINGS_solstudio := E_EMPTY_TRANSLATION_UNIT >>>> This is due to the fact that - >>>> jdk/src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops.c >>>> file becomes empty file in case of HEADLESS mode compilation. >> Sigh .. there ought to be "informational" warnings as well as "risky practice" warnings and this should be in the former category. >> You could move something like the jni.h and jlong.h imports outside to see if that shuts it up. >> Not saying that is what we want to do but it would be interesting to check. > [Ajit] : Nope. Moving jni.h or jlong.h inclusions outside #ifndef HEADLESS did not help. We still get E_EMPTY_TRANSLATION_UNIT warning. > To get rid of this warning, there are suggestions to make a typedef - and not use it anywhere - but, I would rather keep the suppression in makefile than defining a typedef without actual usage. > Another solution is to exclude this file from HEADLESS compilation. I am not sure how to achieve it. Any suggestion? > > >> -phil. >>>> Request you to review following webrev : >>>> http://cr.openjdk.java.net/~aghaisas/8074829/webrev.00/ >>>> >>>> Regards, >>>> Ajit From philip.race at oracle.com Fri Apr 22 18:06:40 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 22 Apr 2016 11:06:40 -0700 Subject: [OpenJDK 2D-Dev] RFR 8154213: clean up uses of boxed primitive constructors in the java.desktop module Message-ID: <571A6830.5090108@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8154213 Webrev: http://cr.openjdk.java.net/~prr/8154213/ https://bugs.openjdk.java.net/browse/JDK-8145468 has caused the following constructors usages to be deprecated : new Long(long) and new Integer(String) new Integer(int) and new Integer(String) new Float(int) and new Float(String) new Double(int) and new Double(String) new Character(char) The deprecations warnings were suppressed for the java.desktop module. This fix changes all uses in the java.desktop module to use Foo.valueOf(..) or in a few cases where we directly assign to a variable use auto-boxing. Additionally doc comments that use constructors were updated. Finally the deprecation suppression was removed. JPRT has been used to verify the build and I have run through the various affected Swing L&Fs using SwingSet as a sanity check. I do not have any information on the performance difference (benefits or otherwise) of this change but I did not see any usage in java.desktop that appears to be remotely performance critical. -phil. From james.graham at oracle.com Sat Apr 23 01:56:23 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 22 Apr 2016 18:56:23 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED In-Reply-To: <7f5f1cd3-4022-4739-b412-9d3f3c74181f@default> References: <2c9221dc-ed76-481a-8bee-a694d313448e@default> <56BD0CAB.6080704@oracle.com> <90de7741-c175-4803-9c3e-30b1039b2774@default> <56C227D1.1030600@oracle.com> <46329edf-4cbe-48d4-a519-c908b09844a6@default> <56C789E4.6000409@oracle.com> <7f5f1cd3-4022-4739-b412-9d3f3c74181f@default> Message-ID: <4a833ce4-04b4-0250-e78f-ef60fbd52806@oracle.com> Hi Jay, It looks like it will work, but there are some inconsistencies in the code that we should address and a couple of optimizations. First, there is a mixture of using "int" and "jboolean" for the type of the new boolean parameter. It would be great if we could just declare it as jboolean in the structures, but it looks like those are limited to basic C types. It seems a little clunky to mix types like this, but I'd be interested in hearing what Phil says. I think it would be fine to just use int throughout. I'd suggest a name change: representsPrimary => representsPrimaries (since there are multiple primary colors) The place to load the variable for testing in the ByteIndexed macros would be in the "InitByteIndexedStoreVarsY" macro where it sets up the "PREFIX ## InvLut" variable. It should also use a PREFIX. Look through those macros for wherever the InvLut value is declared and initialized, and follow a similar pattern for "PREFIX ## ". You could use "representsPrimaries" for the name here too, but it could also be shortened to just "repPrims" or "optPrims" since the macros are all centralized here. Once you do the preceding step, you can delete a lot of lines that pre-load the "representsPrimaries" in the calling macros, which should also eliminate a lot of files from the webrev. In the code in ByteIndexed.h:StoreByteIndexedFrom3ByteRgb() that tests the variable, I'd just test "representsPrimary" with no "==" rather than comparing it to 1 since it is a boolean, not (really) an integer. With respect to the new function that tests the primary matches (in ByteIndexed.c), some of the code is unnecessarily complicated: - When you find a color match failure (lines 301, et al), you could just return false directly. As it stands, you set a variable and break, but the break only breaks out of 1 of 3 nested if statements, so it doesn't save any calculations. Just return false directly as a single failure means the answer is "no". - your r, g, and b values are extracted from the color in the wrong order near line 285. r involves a shift of 16, and b involves no shift. I suppose this is paired with computing the dr and db values with the wrong indices or this technique wouldn't work, but it is clunky to name the variables inconsistently with the data they actually hold. - you use parentheses on the left-hand side of an assignment when you extract the r, g, and b values (also near line 285). You don't need parentheses on that side of an assignment operator. There are several things that are more complicated than they need to be with your testing lines. They use a lot more computations than you need. For instance: - You test the i,j,k using a modulus operation (lines 298, 312, 326), but really you just need to know if it is 0 or not-0, so just test it for ==0 or !=0. - rather than using multiplication and modulus to assign the dr,dg,db values near line 291, why not just use "dr = (i == 0) ? 0 : 255;"? - the tests for range use a separate subtraction and a compare, when they could be inlined. First, I'd get rid of the "represents_primary" variable entirely and then rewrite the whole tail end of the loop body from 291 to the end of the loop as: if (i == 0) { if (r > delta) return false; } else { if (r < 255-delta) return false; } // 2 more similar tests for j/g and k/b Then "return true" at the end of the function if it reaches there. Keep in mind that the mapping of ijk to rgb might be affected if you fix the shifts used to extract the rgb components from color... ...jim On 4/20/2016 2:46 AM, Jayathirth D V wrote: > Hi Jim, > > As discussed we will not add dithering error values to primary colors with color map which represents Primary colors approximately(+/-5 delta). > I have made changes based on this suggestion and added new function to calculate whether color map represents primary colors approximately or not. > If it represents only then we will avoid adding dithering error values in case ByteIndexed destination. > > I have observed that in case of white color we are picking (252,252,252) or (246,246,246) and not (255,255,255) from colormap. What I have observed that out of 256 places we are storing RGB colors at start and then gray values. So we are picking final gray value and not in between white value. That's why I am not verifying white color validity in test case. > > Please find updated webrev for review : > http://cr.openjdk.java.net/~jdv/7116979/webrev.01/ > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Saturday, February 20, 2016 3:02 AM > To: Jayathirth D V > Cc: 2d-dev at openjdk.java.net; Philip Race; Prasanta Sadhukhan > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED > > Hi Jayathirth, > > Thank you for attaching the detailed logs, but I don't have a program that can deal with the 7z files. Can you summarize what was learned from them? > > Also, the colormap you created, while subset, was a perfectly scaled cube. I was referring more to a random colormap where you might have 2 colors close to a primary, but neither is on a line from the primary to the 0.5 gray value so each has a different hue. That's something that can only be evaluated visually. One example of randomized colormaps is when we display via X11 onto an 8-bit display. That probably never happens any more, but we may not be able to allocate colors in the colormap in such a case and if another program has already allocated most of the dynamic colormap then we would not be able to add our own colors. > > This could be dealt with by simply marking our standard colormap as having primaries, or by scanning any given colormap and marking it if it has primaries, and then only perform this code on colormaps with the primaries. Solving it for our own colormap (or solving it for any colormap that has all primaries) would likely solve it for 99% of the vanishingly small number of developers who might run into this. > > But, in the end, what would we accomplish by adding this one very targeted fix? > > I'm also curious where the push for this is coming from. While we aren't perfect here, so much of the world today is focused on lossless image formats that I don't imagine there is much need for really good 8-bit indexed image support any more...? > > If anything, spatial dithering is considered a very low quality algorithm and error propagation dithering would handle all of the colormaps much better. We used to do error propagation dithering back in the JDK 1.1 days, but we dropped it when we introduced 2D because we added a bunch of ways to render small pieces of an image and only the current spatial dithering algorithm can be started in the middle of an operation. That doesn't mean that you can't still do error propagation since many operations already operate on the full image any way and you can still handle subset image operations by either converting the full image first and then copying or by tracing the errors from the edge of the image to the point of the subimage operation. We never bothered to upgrade our algorithms it just never seemed to be work that made sense to prioritize given that screens were overwhelmingly moving to full-color at the time of "Java 2" (and now to HDR in 2016+). 8-bit indexed isn't used much any more. > > If we want to make 8-bit destination images work better we'd be better off adopting error propagation dithering again rather than trying to tune this algorithm for black. > > It looks like the bug was closed briefly in 2014 and then reopened soon thereafter with no justification. It is true that we still have this anomaly, but it isn't clear why this is high enough priority to work on in 2016 when other bit depths would work better for destination imagery and other dithering algorithms would work better for most customers and even this targeted fix isn't perfect... > > ...jim > > On 2/16/2016 8:32 AM, Jayathirth D V wrote: >> Hi Jim, >> >> Thanks for letting me know about the importance of custom color maps. I was not able to understand what you mentioned previously since I am new to this terminology. >> >> Regarding performance I checked with image having complete 255,255,128 pixels and ran it for 100 times. I am running on Windows 7 Professional SP1 with Intel i5-5300U CPU. Overall I don't see much difference in time taken for drawImage() API before and after change. Details for INT_RGB image as input: >> >> Before change : >> Minimum time 536827ns >> Maximum time 1560947ns >> Average time 871167ns >> >> After change : >> Minimum time 536380ns >> Maximum time 1468130ns >> Average time 830778ns >> >> There is +/- 10% delta both for before and after change time but there is no major gap. Even for image with other input type it holds the same. >> >> >> Regarding custom color maps, previously I ran on default color map generated in TYPE_BYTE_INDEXED constructor. Now I tested with modified color map so that it doesn't contain any of the primary color values. Instead of using 0-255 values with value 51 increments in R,G,B components I used color map with 20-245 values with value 45 as increment. For this color map before and after change all the pixels are referring to same index in color map irrespective of removal of error delta addition in case of primary colors. >> >> I have attached log for Red and Green primary colors before and after change(Was not able to attach for more since it exceeded 120KB mailing list limit). Please search for "Final index value =" in the logs. Please let me know your inputs. >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Tuesday, February 16, 2016 1:03 AM >> To: Jayathirth D V >> Cc: 2d-dev at openjdk.java.net; Philip Race; Prasanta Sadhukhan >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : >> Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED >> >> Hi Jayathirth, >> >> The issue with testing performance with white images is that the tests allow the code to eliminate 3 indexed fetches which take time. Primary colors end up being the one obscure case where the new code might be faster. But, non-primary colors would be slower by a fair amount, so performance testing with converting a randomized or non-primary-color image are the more telling case. An image filled with 255,255,128 would be the worst case because it would involve all of the tests and still have to do all of the lookups. >> >> My question about how this works with custom colormaps was not really addressed by your response. A simple test to make sure the colormap has accurate (or very close) conversions for the primary colors may be enough to validate the colormap for the indicated tests. If the colormap contains no pure conversions for some of the primary colors then they may need to be dithered anyway... >> >> ...jim >> >> On 2/15/16 3:39 AM, Jayathirth D V wrote: >>> Hi Jim, >>> >>> I performed performance analysis with white image so that all >>> conditions are checked in the new branch added. There is no major >>> difference in time taken before and after change. For each input I >>> have tested time taken for drawImage() API to convert from every >>> format to Byte indexed type. For every unique conversion test is run >>> for 100 times. Please find the details: >>> >>> Input >>> >>> type >>> >>> >>> >>> Min >>> >>> before change >>> >>> (ns) >>> >>> >>> >>> Min >>> >>> after change >>> >>> (ns) >>> >>> >>> >>> Max >>> >>> before change >>> >>> (ns) >>> >>> >>> >>> Max >>> >>> after change >>> >>> (ns) >>> >>> >>> >>> Average >>> >>> before change >>> >>> (ns) >>> >>> >>> >>> Average >>> >>> after >>> >>> change >>> >>> (ns) >>> >>> INT_RGB >>> >>> >>> >>> 523437 >>> >>> >>> >>> 481491 >>> >>> >>> >>> 1230724 >>> >>> >>> >>> 1270440 >>> >>> >>> >>> 789452 >>> >>> >>> >>> 666144 >>> >>> INT_ARGB >>> >>> >>> >>> 500232 >>> >>> >>> >>> 493986 >>> >>> >>> >>> 12406307 >>> >>> >>> >>> 1308816 >>> >>> >>> >>> 793384 >>> >>> >>> >>> 654015 >>> >>> INT_ARGB_PRE >>> >>> >>> >>> 500233 >>> >>> >>> >>> 492201 >>> >>> >>> >>> 1037057 >>> >>> >>> >>> 981277 >>> >>> >>> >>> 710250 >>> >>> >>> >>> 699214 >>> >>> INT_BGR >>> >>> >>> >>> 537716 >>> >>> >>> >>> 562706 >>> >>> >>> >>> 1446703 >>> >>> >>> >>> 2046001 >>> >>> >>> >>> 862377 >>> >>> >>> >>> 863256 >>> >>> 3BYTE_BGR >>> >>> >>> >>> 483275 >>> >>> >>> >>> 481045 >>> >>> >>> >>> 1181638 >>> >>> >>> >>> 1384676 >>> >>> >>> >>> 651427 >>> >>> >>> >>> 580961 >>> >>> 4BYTE_ABGR >>> >>> >>> >>> 544410 >>> >>> >>> >>> 499786 >>> >>> >>> >>> 1292305 >>> >>> >>> >>> 968783 >>> >>> >>> >>> 690106 >>> >>> >>> >>> 683881 >>> >>> 4BYTE_ABGR_PRE >>> >>> >>> >>> 504249 >>> >>> >>> >>> 505588 >>> >>> >>> >>> 1680086 >>> >>> >>> >>> 1216445 >>> >>> >>> >>> 756101 >>> >>> >>> >>> 687750 >>> >>> USHORT_565_RGB >>> >>> >>> >>> 507818 >>> >>> >>> >>> 505588 >>> >>> >>> >>> 978153 >>> >>> >>> >>> 1346746 >>> >>> >>> >>> 652908 >>> >>> >>> >>> 655782 >>> >>> USHORT_555_RGB >>> >>> >>> >>> 510496 >>> >>> >>> >>> 509604 >>> >>> >>> >>> 952272 >>> >>> >>> >>> 1162004 >>> >>> >>> >>> 650418 >>> >>> >>> >>> 670811 >>> >>> BYTE_GRAY >>> >>> >>> >>> 481491 >>> >>> >>> >>> 478367 >>> >>> >>> >>> 1140585 >>> >>> >>> >>> 1799231 >>> >>> >>> >>> 691160 >>> >>> >>> >>> 583250 >>> >>> USHORT_GRAY >>> >>> >>> >>> 506927 >>> >>> >>> >>> 507373 >>> >>> >>> >>> 1375751 >>> >>> >>> >>> 1255267 >>> >>> >>> >>> 728202 >>> >>> >>> >>> 646902 >>> >>> BYTE_BINARY >>> >>> >>> >>> 541733 >>> >>> >>> >>> 496217 >>> >>> >>> >>> 1083466 >>> >>> >>> >>> 959411 >>> >>> >>> >>> 730527 >>> >>> >>> >>> 728461 >>> >>> The changes are tested with plain images having primary colors like >>> RED, GREEN, BLUE, BLACK and WHITE. >>> >>> Thanks, >>> >>> Jay >>> >>> -----Original Message----- >>> From: Jim Graham >>> Sent: Friday, February 12, 2016 4:05 AM >>> To: Jayathirth D V; 2d-dev at openjdk.java.net; Philip Race; Prasanta >>> Sadhukhan >>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : >>> Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED >>> >>> Hi Jayathirth, >>> >>> Did you do any performance analysis of this change? You are adding 6 >>> tests and multiple branches to per-pixel code. >>> >>> The effectiveness of this technique depends on the colormap that we >>> have set up. For the BufferedImage.TYPE_INDEXED constructor we >>> produce a fairly nice colormap, but if someone creates a custom >>> colormap then the colors could be anything. We create a decent >>> inversion for just about any colormap, but that doesn't mean that >>> using only "the best match for solid red" will produce a better >>> result for a dithered approximation for red. It is true that if >>> there is a really good match for red then we should just use that, >>> but if there are no direct matches for red then we may choose to >>> paint a red region with solid orange even though there is another >>> color in the colormap that when mixed with orange approximates a red >>> tone better. For example, if a colormap contains no pure red, but >>> >>> contains: >>> >>> 240, 20, 0 >>> >>> 240, 0, 20 >>> >>> (I'm not sure if 20 is within our current error deltas that we use >>> for dithering, but this is an example not a test case.) >>> >>> Then using one of these alone might skew the color towards orange or >>> purple. Using both together in a dither pattern might keep the >>> overall hue impression as red, but with a small amount of noise in its saturation. >>> >>> What types of colormaps was this tested with? >>> >>> ...jim >>> >>> On 2/11/16 6:37 AM, Jayathirth D V wrote: >>> >>>> Hi, >>> >>>> >>> >>>> _Please review the following fix in JDK9:_ >>> >>>> >>> >>>> __ >>> >>>> >>> >>>> Bug :https://bugs.openjdk.java.net/browse/JDK-7116979 >>> >>>> >>> >>>> Webrev :http://cr.openjdk.java.net/~jdv/7116979/webrev.00/ >>> >>>> >>> >>>> Issue : When Image containing black pixels are converted from any >>> >>>> format to Byte Indexed format some of the pixels are not black. They >>> >>>> are following pattern similar to dithering. >>> >>>> >>> >>>> Root cause : When we convert any format type to ByteIndexed we are >>> >>>> adding Error delta values to R,G,B components using dithering indices. >>> >>>> This is causing some pixels values to not point to proper index in >>> >>>> color table. >>> >>>> >>> >>>> Solution : There is no need to add error delta for primary colors >>> >>>> containing basic values in R,G,B components. Exclude such pixels >>>> from >>> >>>> delta addition. >>> >>>> >>> >>>> Thanks, >>> >>>> >>> >>>> Jay >>> >>>> >>> From james.graham at oracle.com Sat Apr 23 01:59:32 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 22 Apr 2016 18:59:32 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8153943 : In java.awt.image package some of the classes are missing hashCode() or equals() method In-Reply-To: <5717B9B3.3090807@oracle.com> References: <5717B9B3.3090807@oracle.com> Message-ID: <412b6974-cf58-79ea-5544-f2f5e8b9b5dd@oracle.com> This is actually a pretty nasty issue that Joe Darcy also brought up in the CCC review. In order to have symmetric testing of .equals(), we pretty much have to enforce this test at all levels, including in the original ColorModels.equals() method. If we don't enforce this in CM.equals(), then we could run ccm.equals(othercm) and it would return false because the class is wrong, but turning it around and testing othercm.equals(ccm) would succeed because it doesn't enforce the class equality. So, I'd recommend that CM.equals() tests getClass() == getClass() at the base level and then all others will use super.equals() and get the same protection. It means you can't have a subclass of CCM be "equals" to a different subclass of CCM, but that's an unfortunate issue with equals needing to honor symmetry... :( ...jim On 4/20/2016 10:17 AM, Phil Race wrote: > Hi, You removed the following test in CCM.java : 2941 if (obj.getClass() > != getClass()) { > 2942 return false; > > 2943 } > > What this means is that before your change an instance of a subclass of CCM > would never be equals() to any direct instantiatation of CCM but after > your change it can be. I suspect the condition was there on purpose. > > -phil. > > On 04/20/2016 05:45 AM, Jayathirth D V wrote: >> >> Hi, >> >> >> >> _Please review the following fix in JDK9:_ >> >> >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8153943 >> >> >> >> This is subtask of https://bugs.openjdk.java.net/browse/JDK-6588409 >> >> >> >> Webrev : http://cr.openjdk.java.net/~jdv/8153943/webrev.00/ >> >> >> >> >> Issue : Some of the java.awt.image classes are missing either equals() >> or hashCode() method. >> >> >> >> Solution : Add missing equals() or hashCode() methods. >> >> >> >> Thanks, >> >> Jay >> >> >> > From prasanta.sadhukhan at oracle.com Mon Apr 25 05:11:52 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Mon, 25 Apr 2016 10:41:52 +0530 Subject: [OpenJDK 2D-Dev] RFR 8154213: clean up uses of boxed primitive constructors in the java.desktop module In-Reply-To: <571A6830.5090108@oracle.com> References: <571A6830.5090108@oracle.com> Message-ID: <571DA718.4060808@oracle.com> Hi Phil, My 2 cents: JLayeredPane.java has typo Integer.valueOf.valueOf. In some cases, you have used Float.valueOf(xx) like in ServiceDialog.java, PNGImageDecoder.java but in some cases you jave used lmObj = lmVal; without using Float.valueOf(). Shouldn't we be consistent to use auto-boxing? Regards Prasanta On 4/22/2016 11:36 PM, Phil Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8154213 > Webrev: http://cr.openjdk.java.net/~prr/8154213/ > > https://bugs.openjdk.java.net/browse/JDK-8145468 has caused > the following constructors usages to be deprecated : > new Long(long) and new Integer(String) > new Integer(int) and new Integer(String) > new Float(int) and new Float(String) > new Double(int) and new Double(String) > new Character(char) > > The deprecations warnings were suppressed for the java.desktop module. > > This fix changes all uses in the java.desktop module to use > Foo.valueOf(..) > or in a few cases where we directly assign to a variable use auto-boxing. > > Additionally doc comments that use constructors were updated. > > Finally the deprecation suppression was removed. > > JPRT has been used to verify the build and I have run through the > various affected Swing L&Fs using SwingSet as a sanity check. > > I do not have any information on the performance difference (benefits > or otherwise) > of this change but I did not see any usage in java.desktop that > appears to be > remotely performance critical. > > -phil. > From jayathirth.d.v at oracle.com Mon Apr 25 08:26:45 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 25 Apr 2016 01:26:45 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: equals() method in IndexColorModel doesnt exist and it relies on ColorModel.equals() which is not strict In-Reply-To: <570EB999.7090408@oracle.com> References: <57057CF0.50604@oracle.com> <5706ADBE.10803@oracle.com> <570BF21F.9010603@oracle.com> <34a9ed1b-bf8a-43fb-9032-65c9c47a9c11@default> <570D5043.8000405@oracle.com> <570D5387.2070303@oracle.com> <570D5839.3000402@oracle.com> <570D5822.40705@oracle.com> <570EB999.7090408@oracle.com> Message-ID: <94c3a958-d927-4b42-89f0-d0c44d4d19ab@default> Hi, Based on Joe's and Jim's suggestion I have made changes to include check for getClass() in baseclass and use super.equals() from subclasses to verify class equality. Please find updated webrev for review : http://cr.openjdk.java.net/~jdv/7107905/webrev.05/ For JDK-8153943 I will make relevant changes in its subclasses and sent review in its thread. Thanks, Jay -----Original Message----- From: Jim Graham Sent: Thursday, April 14, 2016 2:57 AM To: Jayathirth D V; Philip Race Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: equals() method in IndexColorModel doesnt exist and it relies on ColorModel.equals() which is not strict Looks good. The only thing left is the CCC... ...jim On 4/13/16 1:33 AM, Jayathirth D V wrote: > Hi, > > Thanks Phil & Jim for your suggestion. > I have made changes mentioned by Jim for whether we have validate individual bits of validBits or not in different conditions. > Please find updated webrev for review : > http://cr.openjdk.java.net/~jdv/7107905/webrev.04/ > > Thanks, > Jay > > -----Original Message----- > From: Phil Race > Sent: Wednesday, April 13, 2016 1:49 AM > To: Jim Graham > Cc: Jayathirth D V; Prasanta Sadhukhan; 2d-dev at openjdk.java.net > Subject: Re: Review Request for JDK-7107905: equals() method in > IndexColorModel doesnt exist and it relies on ColorModel.equals() > which is not strict > > Seems like this would work/help. > > -phil. > > On 04/12/2016 01:19 PM, Jim Graham wrote: >> >> >> On 4/12/2016 12:59 PM, Phil Race wrote: >>> I am catching up on email here, and "+1" but a couple of comments >>> >>> - I suppose that we can't learn anything useful from >>> "cm.validbits.equals(this.validbits)" >>> since only the bits up to "map_size" should be tested ? >> >> Perhaps if the constructors truncated it at the required size we >> could use equals(). I'm not sure that is worthwhile, given how >> rarely it is used. I think it is used by default on some platforms (Windows? >> X11?) if they have an 8-bit screen with a sparse colormap, but that >> should be pretty rare these days since nearly everything we use >> should be 24-bits these days. >> >> I have a better idea, though. >> >> But, since the field is assigned the original supplied value from the >> constructor, then the likelihood that a non-null value will be == >> identical to another colormap is likely larger than normal, perhaps >> we can make it faster by checking for == and then slipping into the >> faster test that simply compares the rgb[] values? Something like: >> >> if (validBits == cm.validBits) { >> compare rgb[] entries >> } else if (validBits == null || cm.validBits == null) { >> return false; >> } else { >> bigger loop that compares rgb[] and validBits() values } >> >> Note that if the two fields are == and non-null, then the entries in >> the rgb[] array for indices that are non-valid should have zeros in >> them because of the way that the colormap data is copied internally, >> so the rgb[] comparisons should be valid without checking the >> associated bits. >> >> Potentially we could also use: >> >> boolean fulltest; >> if (validBits == cm.validBits) { >> fulltest = false; >> } else if (validBits == null || cm.validBits == null) { >> return false; >> } else if (validBits.equals(cm.validBits)) { >> fulltest = false; >> } else { >> fulltest = true; >> } >> >> if (fulltest) { >> compare both rgb[] and validBits() values } else { >> compare rgb[] entries alone >> } >> >> In this case we are using validBits.equals() to reduce the amount of >> testing in the loop, but are not basing a conclusion on whether the >> result of the comparison will be true or false. equals() implies we >> don't need to compare its values bit by bit, but !equals() doesn't >> mean that the ICMs aren't equals()... >> >> ...jim > From jayathirth.d.v at oracle.com Mon Apr 25 09:31:22 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 25 Apr 2016 02:31:22 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8153943 : In java.awt.image package some of the classes are missing hashCode() or equals() method In-Reply-To: <412b6974-cf58-79ea-5544-f2f5e8b9b5dd@oracle.com> References: <5717B9B3.3090807@oracle.com> <412b6974-cf58-79ea-5544-f2f5e8b9b5dd@oracle.com> Message-ID: <102c8c05-d432-4a7f-b664-72e733493f55@default> Hi Jim, I have made changes to include check for class equality in base class and use super.equals() from subclasses. Please find updated webrev for review : http://cr.openjdk.java.net/~jdv/8153943/webrev.02/ Change related to ColorModel is present in JDK-7107905 review. Thanks, Jay -----Original Message----- From: Jim Graham Sent: Saturday, April 23, 2016 7:30 AM To: Phil Race; Jayathirth D V Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8153943 : In java.awt.image package some of the classes are missing hashCode() or equals() method This is actually a pretty nasty issue that Joe Darcy also brought up in the CCC review. In order to have symmetric testing of .equals(), we pretty much have to enforce this test at all levels, including in the original ColorModels.equals() method. If we don't enforce this in CM.equals(), then we could run ccm.equals(othercm) and it would return false because the class is wrong, but turning it around and testing othercm.equals(ccm) would succeed because it doesn't enforce the class equality. So, I'd recommend that CM.equals() tests getClass() == getClass() at the base level and then all others will use super.equals() and get the same protection. It means you can't have a subclass of CCM be "equals" to a different subclass of CCM, but that's an unfortunate issue with equals needing to honor symmetry... :( ...jim On 4/20/2016 10:17 AM, Phil Race wrote: > Hi, You removed the following test in CCM.java : 2941 if > (obj.getClass() != getClass()) { > 2942 return false; > > 2943 } > > What this means is that before your change an instance of a subclass > of CCM would never be equals() to any direct instantiatation of CCM > but after your change it can be. I suspect the condition was there on purpose. > > -phil. > > On 04/20/2016 05:45 AM, Jayathirth D V wrote: >> >> Hi, >> >> >> >> _Please review the following fix in JDK9:_ >> >> >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8153943 >> >> >> >> This is subtask of https://bugs.openjdk.java.net/browse/JDK-6588409 >> >> >> >> Webrev : http://cr.openjdk.java.net/~jdv/8153943/webrev.00/ >> >> >> >> >> Issue : Some of the java.awt.image classes are missing either >> equals() or hashCode() method. >> >> >> >> Solution : Add missing equals() or hashCode() methods. >> >> >> >> Thanks, >> >> Jay >> >> >> > From Sergey.Bylokhov at oracle.com Mon Apr 25 15:34:29 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 25 Apr 2016 18:34:29 +0300 Subject: [OpenJDK 2D-Dev] RFR 8154213: clean up uses of boxed primitive constructors in the java.desktop module In-Reply-To: <571DA718.4060808@oracle.com> References: <571A6830.5090108@oracle.com> <571DA718.4060808@oracle.com> Message-ID: <571E3905.4000709@oracle.com> Some tweaks are possible also: - In some cases like in PrintServiceLookupProvider.java it is possible to use Integer.parseInt() instead of "Integer.valueOf()" + "intValue()". - It is also possible to use classes like Integer = GetIntegerAction() instead of "String = GetPropertyAction()". On 25.04.16 8:11, prasanta sadhukhan wrote: > Hi Phil, > > My 2 cents: > JLayeredPane.java has typo Integer.valueOf.valueOf. > In some cases, you have used > > Float.valueOf(xx) like in ServiceDialog.java, PNGImageDecoder.java > > but in some cases you jave used > > lmObj = lmVal; without using Float.valueOf(). Shouldn't we be consistent > to use auto-boxing? Regards Prasanta > > On 4/22/2016 11:36 PM, Phil Race wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154213 >> Webrev: http://cr.openjdk.java.net/~prr/8154213/ >> >> https://bugs.openjdk.java.net/browse/JDK-8145468 has caused >> the following constructors usages to be deprecated : >> new Long(long) and new Integer(String) >> new Integer(int) and new Integer(String) >> new Float(int) and new Float(String) >> new Double(int) and new Double(String) >> new Character(char) >> >> The deprecations warnings were suppressed for the java.desktop module. >> >> This fix changes all uses in the java.desktop module to use >> Foo.valueOf(..) >> or in a few cases where we directly assign to a variable use auto-boxing. >> >> Additionally doc comments that use constructors were updated. >> >> Finally the deprecation suppression was removed. >> >> JPRT has been used to verify the build and I have run through the >> various affected Swing L&Fs using SwingSet as a sanity check. >> >> I do not have any information on the performance difference (benefits >> or otherwise) >> of this change but I did not see any usage in java.desktop that >> appears to be >> remotely performance critical. >> >> -phil. >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Apr 25 15:48:54 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 25 Apr 2016 18:48:54 +0300 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8153943 : In java.awt.image package some of the classes are missing hashCode() or equals() method In-Reply-To: <412b6974-cf58-79ea-5544-f2f5e8b9b5dd@oracle.com> References: <5717B9B3.3090807@oracle.com> <412b6974-cf58-79ea-5544-f2f5e8b9b5dd@oracle.com> Message-ID: <571E3C66.6080807@oracle.com> On 23.04.16 4:59, Jim Graham wrote: > So, I'd recommend that CM.equals() tests getClass() == getClass() at the > base level and then all others will use super.equals() and get the same > protection. It means you can't have a subclass of CCM be "equals" to a > different subclass of CCM, but that's an unfortunate issue with equals > needing to honor symmetry... :( Small note. In this case the custom classes which do not provide the new state, cannot compares to parent class because of "class==class" check. I guess this is behavior change, but I am not sure should we document that or not. > > ...jim > > On 4/20/2016 10:17 AM, Phil Race wrote: >> Hi, You removed the following test in CCM.java : 2941 if (obj.getClass() >> != getClass()) { >> 2942 return false; >> >> 2943 } >> >> What this means is that before your change an instance of a subclass >> of CCM >> would never be equals() to any direct instantiatation of CCM but after >> your change it can be. I suspect the condition was there on purpose. >> >> -phil. >> >> On 04/20/2016 05:45 AM, Jayathirth D V wrote: >>> >>> Hi, >>> >>> >>> >>> _Please review the following fix in JDK9:_ >>> >>> >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8153943 >>> >>> >>> >>> This is subtask of https://bugs.openjdk.java.net/browse/JDK-6588409 >>> >>> >>> >>> Webrev : http://cr.openjdk.java.net/~jdv/8153943/webrev.00/ >>> >>> >>> >>> >>> Issue : Some of the java.awt.image classes are missing either equals() >>> or hashCode() method. >>> >>> >>> >>> Solution : Add missing equals() or hashCode() methods. >>> >>> >>> >>> Thanks, >>> >>> Jay >>> >>> >>> >> -- Best regards, Sergey. From philip.race at oracle.com Mon Apr 25 16:06:53 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 25 Apr 2016 09:06:53 -0700 Subject: [OpenJDK 2D-Dev] RFR 8154213: clean up uses of boxed primitive constructors in the java.desktop module In-Reply-To: <571DA718.4060808@oracle.com> References: <571A6830.5090108@oracle.com> <571DA718.4060808@oracle.com> Message-ID: <571E409D.2050507@oracle.com> On 04/24/2016 10:11 PM, prasanta sadhukhan wrote: > Hi Phil, > > My 2 cents: > JLayeredPane.java has typo Integer.valueOf.valueOf. That is a doc typo of course. I can fix that. > In some cases, you have used > > Float.valueOf(xx) like in ServiceDialog.java, PNGImageDecoder.java > > but in some cases you jave used > > lmObj = lmVal; without using Float.valueOf(). Shouldn't we be > consistent to use auto-boxing? I actually discussed this in my initial email "in a few cases where we directly assign to a variable use auto-boxing." So it was deliberate. -phil. > Regards Prasanta > > On 4/22/2016 11:36 PM, Phil Race wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154213 >> Webrev: http://cr.openjdk.java.net/~prr/8154213/ >> >> https://bugs.openjdk.java.net/browse/JDK-8145468 has caused >> the following constructors usages to be deprecated : >> new Long(long) and new Integer(String) >> new Integer(int) and new Integer(String) >> new Float(int) and new Float(String) >> new Double(int) and new Double(String) >> new Character(char) >> >> The deprecations warnings were suppressed for the java.desktop module. >> >> This fix changes all uses in the java.desktop module to use >> Foo.valueOf(..) >> or in a few cases where we directly assign to a variable use >> auto-boxing. >> >> Additionally doc comments that use constructors were updated. >> >> Finally the deprecation suppression was removed. >> >> JPRT has been used to verify the build and I have run through the >> various affected Swing L&Fs using SwingSet as a sanity check. >> >> I do not have any information on the performance difference (benefits >> or otherwise) >> of this change but I did not see any usage in java.desktop that >> appears to be >> remotely performance critical. >> >> -phil. >> > From philip.race at oracle.com Mon Apr 25 16:19:26 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 25 Apr 2016 09:19:26 -0700 Subject: [OpenJDK 2D-Dev] RFR 8154213: clean up uses of boxed primitive constructors in the java.desktop module In-Reply-To: <571E3905.4000709@oracle.com> References: <571A6830.5090108@oracle.com> <571DA718.4060808@oracle.com> <571E3905.4000709@oracle.com> Message-ID: <571E438E.3060001@oracle.com> On 04/25/2016 08:34 AM, Sergey Bylokhov wrote: > Some tweaks are possible also: > - In some cases like in PrintServiceLookupProvider.java it is > possible to use Integer.parseInt() instead of "Integer.valueOf()" + > "intValue()". That [one] seems easy enough but I don't see any more in the webrev. http://cr.openjdk.java.net/~prr/8154213.1 - also fixes the typo in JLayeredPane.java > - It is also possible to use classes like Integer = > GetIntegerAction() instead of "String = GetPropertyAction()". > I don't see this used anywhere in the patch and so it seems like that should be dealt with as a separate issue. -phil. > On 25.04.16 8:11, prasanta sadhukhan wrote: >> Hi Phil, >> >> My 2 cents: >> JLayeredPane.java has typo Integer.valueOf.valueOf. >> In some cases, you have used >> >> Float.valueOf(xx) like in ServiceDialog.java, PNGImageDecoder.java >> >> but in some cases you jave used >> >> lmObj = lmVal; without using Float.valueOf(). Shouldn't we be consistent >> to use auto-boxing? Regards Prasanta >> >> On 4/22/2016 11:36 PM, Phil Race wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154213 >>> Webrev: http://cr.openjdk.java.net/~prr/8154213/ >>> >>> https://bugs.openjdk.java.net/browse/JDK-8145468 has caused >>> the following constructors usages to be deprecated : >>> new Long(long) and new Integer(String) >>> new Integer(int) and new Integer(String) >>> new Float(int) and new Float(String) >>> new Double(int) and new Double(String) >>> new Character(char) >>> >>> The deprecations warnings were suppressed for the java.desktop module. >>> >>> This fix changes all uses in the java.desktop module to use >>> Foo.valueOf(..) >>> or in a few cases where we directly assign to a variable use >>> auto-boxing. >>> >>> Additionally doc comments that use constructors were updated. >>> >>> Finally the deprecation suppression was removed. >>> >>> JPRT has been used to verify the build and I have run through the >>> various affected Swing L&Fs using SwingSet as a sanity check. >>> >>> I do not have any information on the performance difference (benefits >>> or otherwise) >>> of this change but I did not see any usage in java.desktop that >>> appears to be >>> remotely performance critical. >>> >>> -phil. >>> >> > > From Sergey.Bylokhov at oracle.com Mon Apr 25 17:11:57 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 25 Apr 2016 20:11:57 +0300 Subject: [OpenJDK 2D-Dev] RFR 8154213: clean up uses of boxed primitive constructors in the java.desktop module In-Reply-To: <571E438E.3060001@oracle.com> References: <571A6830.5090108@oracle.com> <571DA718.4060808@oracle.com> <571E3905.4000709@oracle.com> <571E438E.3060001@oracle.com> Message-ID: <571E4FDD.2090107@oracle.com> On 25.04.16 19:19, Phil Race wrote: > On 04/25/2016 08:34 AM, Sergey Bylokhov wrote: >> Some tweaks are possible also: >> - In some cases like in PrintServiceLookupProvider.java it is >> possible to use Integer.parseInt() instead of "Integer.valueOf()" + >> "intValue()". > > That [one] seems easy enough but I don't see any more in the webrev. The similar code can be found in the documentation of NumberFormatter.java: " * Number, the corresponding instance of the value class 72 * will be created using the constructor appropriate for the primitive 73 * type the value class represents. For example: 74 * setValueClass(Integer.class) will cause the resulting 75 * value to be created via 76 * Integer.valueOf(((Number)formatter.parseObject(string)).intValue())." Note about the sentence about the constructor: "will be created using the constructor appropriate for the primitive type". Actually our implementation of NumberFormatter contradicts this spec so I think it is not a problem for this fix, but it will be good to file separately? > > http://cr.openjdk.java.net/~prr/8154213.1 > > - also fixes the typo in JLayeredPane.java > > >> - It is also possible to use classes like Integer = >> GetIntegerAction() instead of "String = GetPropertyAction()". >> > I don't see this used anywhere in the patch and so it seems like that > should > be dealt with as a separate issue. > > -phil. > >> On 25.04.16 8:11, prasanta sadhukhan wrote: >>> Hi Phil, >>> >>> My 2 cents: >>> JLayeredPane.java has typo Integer.valueOf.valueOf. >>> In some cases, you have used >>> >>> Float.valueOf(xx) like in ServiceDialog.java, PNGImageDecoder.java >>> >>> but in some cases you jave used >>> >>> lmObj = lmVal; without using Float.valueOf(). Shouldn't we be consistent >>> to use auto-boxing? Regards Prasanta >>> >>> On 4/22/2016 11:36 PM, Phil Race wrote: >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154213 >>>> Webrev: http://cr.openjdk.java.net/~prr/8154213/ >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8145468 has caused >>>> the following constructors usages to be deprecated : >>>> new Long(long) and new Integer(String) >>>> new Integer(int) and new Integer(String) >>>> new Float(int) and new Float(String) >>>> new Double(int) and new Double(String) >>>> new Character(char) >>>> >>>> The deprecations warnings were suppressed for the java.desktop module. >>>> >>>> This fix changes all uses in the java.desktop module to use >>>> Foo.valueOf(..) >>>> or in a few cases where we directly assign to a variable use >>>> auto-boxing. >>>> >>>> Additionally doc comments that use constructors were updated. >>>> >>>> Finally the deprecation suppression was removed. >>>> >>>> JPRT has been used to verify the build and I have run through the >>>> various affected Swing L&Fs using SwingSet as a sanity check. >>>> >>>> I do not have any information on the performance difference (benefits >>>> or otherwise) >>>> of this change but I did not see any usage in java.desktop that >>>> appears to be >>>> remotely performance critical. >>>> >>>> -phil. >>>> >>> >> >> > -- Best regards, Sergey. From vadim.pakhnushev at oracle.com Mon Apr 25 17:13:10 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Mon, 25 Apr 2016 20:13:10 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8047931: Remove unused medialib code Message-ID: <571E5026.7040207@oracle.com> Hi all, Please review this cleanup fix: https://bugs.openjdk.java.net/browse/JDK-8047931 While investigating unused files in the sparc build, it was found that there are a lot of unused code in the medialib. So without further ado, here's the whopping 35000 lines removal webrev: http://cr.openjdk.java.net/~vadim/8047931/webrev.00/ At least on Windows, it reduced the size of the mlib_image.dll by almost 180KB from 663KB to 486KB and shortened the build by 3 minutes on my i5. It was tested with the JPRT build on all platforms. Some notes in order of the files in the webrev: Awt2dLibraries.gmk Deleted removed files from the sparc exclude list. mlib_ImageAffine.c Main entry point mlib_ImageAffine always pass NULL as a colormap to the mlib_ImageAffine_alltypes. This is basically a starting point for the majority of removal which leads to removal of colormap parameters of several other functions and elimination of several if (colormap != NULL) blocks. Which in turn leads to removal of function pointer arrays such as mlib_AffineFunArr_bl_i and mlib_AffineFunArr_bc_i. mlib_ImageAffine.h Removed colormap parameters and related declarations. mlib_ImageAffineEdge.c Removed parts of the code in the mlib_ImageAffineEdge* functions related to the colormaps. mlib_ImageConv* mlib_v_ImageConv* Removed 2x2 through 7x7 convolution functions as we only use NxM ones. mlib_image_proto.h Basically removed all functions with a colormap parameter. mlib_v_ImageAffine* Removed sparc implementations of unused mlib_ImageAffine* functions. Thanks, Vadim From philip.race at oracle.com Mon Apr 25 21:03:42 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 25 Apr 2016 14:03:42 -0700 Subject: [OpenJDK 2D-Dev] RFR 8154213: clean up uses of boxed primitive constructors in the java.desktop module In-Reply-To: <571E4FDD.2090107@oracle.com> References: <571A6830.5090108@oracle.com> <571DA718.4060808@oracle.com> <571E3905.4000709@oracle.com> <571E438E.3060001@oracle.com> <571E4FDD.2090107@oracle.com> Message-ID: <571E862E.9010800@oracle.com> On 04/25/2016 10:11 AM, Sergey Bylokhov wrote: > On 25.04.16 19:19, Phil Race wrote: >> On 04/25/2016 08:34 AM, Sergey Bylokhov wrote: >>> Some tweaks are possible also: >>> - In some cases like in PrintServiceLookupProvider.java it is >>> possible to use Integer.parseInt() instead of "Integer.valueOf()" + >>> "intValue()". >> >> That [one] seems easy enough but I don't see any more in the webrev. > > The similar code can be found in the documentation of > NumberFormatter.java: > > " * Number, the corresponding instance of the value class > 72 * will be created using the constructor appropriate for the > primitive > 73 * type the value class represents. For example: > 74 * setValueClass(Integer.class) will cause the > resulting > 75 * value to be created via > 76 * > Integer.valueOf(((Number)formatter.parseObject(string)).intValue())." > > Note about the sentence about the constructor: "will be created using > the constructor appropriate for the primitive type". Actually our > implementation of NumberFormatter contradicts this spec so I think it > is not a problem for this fix, but it will be good to file separately? Yes, and I did see that one but it was in a comment and a bit messy so I decided to do the minimal change. We can take that up separately. -phil. > >> >> http://cr.openjdk.java.net/~prr/8154213.1 >> >> - also fixes the typo in JLayeredPane.java >> >> >>> - It is also possible to use classes like Integer = >>> GetIntegerAction() instead of "String = GetPropertyAction()". >>> >> I don't see this used anywhere in the patch and so it seems like that >> should >> be dealt with as a separate issue. >> >> -phil. >> >>> On 25.04.16 8:11, prasanta sadhukhan wrote: >>>> Hi Phil, >>>> >>>> My 2 cents: >>>> JLayeredPane.java has typo Integer.valueOf.valueOf. >>>> In some cases, you have used >>>> >>>> Float.valueOf(xx) like in ServiceDialog.java, PNGImageDecoder.java >>>> >>>> but in some cases you jave used >>>> >>>> lmObj = lmVal; without using Float.valueOf(). Shouldn't we be >>>> consistent >>>> to use auto-boxing? Regards Prasanta >>>> >>>> On 4/22/2016 11:36 PM, Phil Race wrote: >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154213 >>>>> Webrev: http://cr.openjdk.java.net/~prr/8154213/ >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8145468 has caused >>>>> the following constructors usages to be deprecated : >>>>> new Long(long) and new Integer(String) >>>>> new Integer(int) and new Integer(String) >>>>> new Float(int) and new Float(String) >>>>> new Double(int) and new Double(String) >>>>> new Character(char) >>>>> >>>>> The deprecations warnings were suppressed for the java.desktop >>>>> module. >>>>> >>>>> This fix changes all uses in the java.desktop module to use >>>>> Foo.valueOf(..) >>>>> or in a few cases where we directly assign to a variable use >>>>> auto-boxing. >>>>> >>>>> Additionally doc comments that use constructors were updated. >>>>> >>>>> Finally the deprecation suppression was removed. >>>>> >>>>> JPRT has been used to verify the build and I have run through the >>>>> various affected Swing L&Fs using SwingSet as a sanity check. >>>>> >>>>> I do not have any information on the performance difference (benefits >>>>> or otherwise) >>>>> of this change but I did not see any usage in java.desktop that >>>>> appears to be >>>>> remotely performance critical. >>>>> >>>>> -phil. >>>>> >>>> >>> >>> >> > > From alexey.ivanov at oracle.com Tue Apr 26 16:30:12 2016 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Tue, 26 Apr 2016 19:30:12 +0300 Subject: [OpenJDK 2D-Dev] [PATCH] JDK-8146035: Windows - With LCD antialiasing, some glyphs are not rendered correctly In-Reply-To: References: Message-ID: <571F9794.1030407@oracle.com> The patch is also available at http://cr.openjdk.java.net/~aivanov/dmitry.batrak/8146035/jdk9/webrev.00/ The fix has been integrated into 9/client https://bugs.openjdk.java.net/browse/JDK-8146035 and to 8u-dev https://bugs.openjdk.java.net/browse/JDK-8154232 Regards, Alexey On 12.04.2016 20:43, Dmitry Batrak wrote: > Repeating the patch inline: > > === patch start === > --- old/src/java.desktop/windows/native/libfontmanager/lcdglyph.c > 2016-04-07 13:10:01.507608685 +0300 > +++ new/src/java.desktop/windows/native/libfontmanager/lcdglyph.c > 2016-04-07 13:10:01.391608686 +0300 > @@ -157,6 +157,9 @@ > if (hBitmap != 0) { \ > DeleteObject(hBitmap); \ > } \ > + if (tmpBitmap != 0) { \ > + DeleteObject(tmpBitmap); \ > + } \ > if (dibImage != NULL) { \ > free(dibImage); \ > } \ > @@ -196,6 +199,7 @@ > int bmWidth, bmHeight; > int x, y; > HBITMAP hBitmap = NULL, hOrigBM; > + HBITMAP tmpBitmap = NULL; > int gamma, orient; > > HWND hWnd = NULL; > @@ -250,6 +254,12 @@ > } > oldFont = SelectObject(hMemoryDC, hFont); > > + tmpBitmap = CreateCompatibleBitmap(hDesktopDC, 1, 1); > + if (tmpBitmap == NULL) { > + FREE_AND_RETURN; > + } > + hOrigBM = (HBITMAP)SelectObject(hMemoryDC, tmpBitmap); > + > memset(&textMetric, 0, sizeof(TEXTMETRIC)); > err = GetTextMetrics(hMemoryDC, &textMetric); > if (err == 0) { > @@ -334,7 +344,7 @@ > if (hBitmap == NULL) { > FREE_AND_RETURN; > } > - hOrigBM = (HBITMAP)SelectObject(hMemoryDC, hBitmap); > + SelectObject(hMemoryDC, hBitmap); > > /* Fill in black */ > rect.left = 0; > @@ -478,6 +488,7 @@ > ReleaseDC(hWnd, hDesktopDC); > DeleteObject(hMemoryDC); > DeleteObject(hBitmap); > + DeleteObject(tmpBitmap); > > return ptr_to_jlong(glyphInfo); > } > === patch end === > > Thanks, > Dmitry > > On Tue, Apr 12, 2016 at 8:22 PM, Phil Race > wrote: > > Alexey didn't say this but he already proposed exactly this fix > himself > in a private email exchange, > > +1, although I am not sure we can legally pull down the patch from > that (any) website. > Please resubmit it as a diff in the email. > > Or Alexey could just push it as his own :-) > > -phil. > > On 04/07/2016 05:26 AM, Dmitry Batrak wrote: > > Hello, > > I'd like to propose a fix for JDK-8146035. I am not a committer, > so I hope someone can sponsor this fix. > I work at Jetbrains, which has signed a company-level > contributor agreement, > so, from a legal perspective, I believe, there are no obstacles. > > My investigation shows that the issue is caused by incorrect > determination > of bitmap size, prepared for glyph rendering, so only part of > glyph > becomes visible due to cropping. This seems to happen because > compatible bitmap is not selected into memory device context (DC) > before calling GetTextMetrics. Documentation for > CreateCompatibleDC call > (https://msdn.microsoft.com/en-us/library/windows/desktop/dd183489%28v=vs.85%29.aspx) > > says compatible bitmap needs to be selected into DC before any > drawing operation. > Even though GetTextMetrics is not a drawing operation, it > turns out > to be affected by selected bitmap's type too (by default a > monochrome bitmap > is selected in a memory DC). This behaviour was also mentioned > in the following > MSDN blog post comment: > https://blogs.msdn.microsoft.com/oldnewthing/20060614-00/?p=30873#comment-392143 > > The proposed fix is to select a temporary 1x1 compatible bitmap > into memory DC before GetTextMetrics call. > Here's webrev link - http://adm-12504.intellij.net/ > I didn't create a test case, as it would require a specific > font file > (I couldn't reproduce the issue for fonts bundled with Windows). > > Best regards, > Dmitry Batrak > > > > > > -- > Dmitry Batrak > Senior Software Developer > JetBrains > http://www.jetbrains.com > The Drive to Develop -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Tue Apr 26 16:45:38 2016 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 26 Apr 2016 09:45:38 -0700 Subject: [OpenJDK 2D-Dev] Fwd: Re: JDK 9 pre-review of JDK-6850612: Deprecate Class.newInstance since it violates the checked exception language contract In-Reply-To: <5718FEF7.1020807@oracle.com> References: <5718FEF7.1020807@oracle.com> Message-ID: <57f52e95-9485-1114-5314-cbdf1680709b@oracle.com> Phil and other client reviewers, Please review this change from core libs which impacts client libs implementations. In brief, deprecating a method in core reflection requires uses of that method to have a @SuppressWarnings("deprecation") annotation. The typical way to minimize the scope of the deprecation is to declare a temporary variable which can host the @SuppressWarnings annotation. The alternative would have been to suppress the warning on the entire method, which would allow addition use of deprecated methods to sneak in. http://cr.openjdk.java.net/~darcy/6850612.0/ Thanks, -Joe -------- Forwarded Message -------- Subject: Re: JDK 9 pre-review of JDK-6850612: Deprecate Class.newInstance since it violates the checked exception language contract Date: Thu, 21 Apr 2016 09:25:27 -0700 From: joe darcy Organization: Oracle Corporation To: core-libs-dev Hello, After a generally positive reception, please review the webrev to implement the deprecation of Class.newInstance and the suppression of the resulting warnings: http://cr.openjdk.java.net/~darcy/6850612.0/ There are also some changes in the langtools repo; I'll send a separate review request for those changes to compiler-dev. I'll also forward this review request to other areas with affected code. Thanks, -Joe On 4/17/2016 10:31 AM, joe darcy wrote: > Hello, > > With talk of deprecation in the air [1], I thought it would be a fine > time to examine one of the bugs on my list > > JDK-6850612: Deprecate Class.newInstance since it violates the > checked exception language contract > > As the title of the bug implies, The Class.newInstance method > knowingly violates the checking exception contract. This has long been > documented in its specification: > >> Note that this method propagates any exception thrown by the nullary >> constructor, including a checked exception. Use of this method >> effectively bypasses the compile-time exception checking that would >> otherwise be performed by the compiler. The Constructor.newInstance >> method avoids this problem by wrapping any exception thrown by the >> constructor in a (checked) InvocationTargetException. > > Roughly, the fix would be to turn the text of this note into the > @deprecated text and to add a @Deprecated(since="9") annotation to the > method. There are a few dozen uses of the method in the JDK that would > have to be @SuppressWarning-ed or otherwise updated. > > Thoughts on the appropriateness of deprecating this method at this time? > > Comments on the bug have suggested that besides deprecating the > method, a new method on Class could be introduced, > newInstanceWithProperExceptionBehavior, that had the same signature > but wrapped exceptions thrown by the constructor call in the same way > Constructor.newInstance does. > > Thanks, > > -Joe > > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040192.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Tue Apr 26 18:26:25 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 26 Apr 2016 11:26:25 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED In-Reply-To: <4a833ce4-04b4-0250-e78f-ef60fbd52806@oracle.com> References: <2c9221dc-ed76-481a-8bee-a694d313448e@default> <56BD0CAB.6080704@oracle.com> <90de7741-c175-4803-9c3e-30b1039b2774@default> <56C227D1.1030600@oracle.com> <46329edf-4cbe-48d4-a519-c908b09844a6@default> <56C789E4.6000409@oracle.com> <7f5f1cd3-4022-4739-b412-9d3f3c74181f@default> <4a833ce4-04b4-0250-e78f-ef60fbd52806@oracle.com> Message-ID: <571FB2D1.30205@oracle.com> On 04/22/2016 06:56 PM, Jim Graham wrote: > Hi Jay, > > It looks like it will work, but there are some inconsistencies in the > code that we should address and a couple of optimizations. > > First, there is a mixture of using "int" and "jboolean" for the type > of the new boolean parameter. It would be great if we could just > declare it as jboolean in the structures, but it looks like those are > limited to basic C types. It seems a little clunky to mix types like > this, but I'd be interested in hearing what Phil says. I think it > would be fine to just use int throughout. From the ones I've seen may be much better to just use int throughout. Eg 264 static jboolean calculatePrimaryColorsAprroximation(int* cmap, unsigned char* cube, int cube_size) { aside from having a typo in the name also makes a fair amount of internal uses of jboolean and JNI_TRUE/JNI_FALSE. It then does this 385 cData->representsPrimary = calculatePrimaryColorsAprroximation(pRgb, cData->img_clr_tbl, 32); ie stores it in an int .. I see no reason for this as there is no JNI code involved. Moreover this usage of the variables declared as boolean then has code like 174 (representsPrimary == 1))) { \ -phil. > > I'd suggest a name change: > representsPrimary => representsPrimaries > (since there are multiple primary colors) > > The place to load the variable for testing in the ByteIndexed macros > would be in the "InitByteIndexedStoreVarsY" macro where it sets up the > "PREFIX ## InvLut" variable. It should also use a PREFIX. Look > through those macros for wherever the InvLut value is declared and > initialized, and follow a similar pattern for "PREFIX ## ". > You could use "representsPrimaries" for the name here too, but it > could also be shortened to just "repPrims" or "optPrims" since the > macros are all centralized here. > > Once you do the preceding step, you can delete a lot of lines that > pre-load the "representsPrimaries" in the calling macros, which should > also eliminate a lot of files from the webrev. > > In the code in ByteIndexed.h:StoreByteIndexedFrom3ByteRgb() that tests > the variable, I'd just test "representsPrimary" with no "==" rather > than comparing it to 1 since it is a boolean, not (really) an integer. > > With respect to the new function that tests the primary matches (in > ByteIndexed.c), some of the code is unnecessarily complicated: > > - When you find a color match failure (lines 301, et al), you could > just return false directly. As it stands, you set a variable and > break, but the break only breaks out of 1 of 3 nested if statements, > so it doesn't save any calculations. Just return false directly as a > single failure means the answer is "no". > > - your r, g, and b values are extracted from the color in the wrong > order near line 285. r involves a shift of 16, and b involves no > shift. I suppose this is paired with computing the dr and db values > with the wrong indices or this technique wouldn't work, but it is > clunky to name the variables inconsistently with the data they > actually hold. > > - you use parentheses on the left-hand side of an assignment when you > extract the r, g, and b values (also near line 285). You don't need > parentheses on that side of an assignment operator. > > There are several things that are more complicated than they need to > be with your testing lines. They use a lot more computations than you > need. For instance: > > - You test the i,j,k using a modulus operation (lines 298, 312, 326), > but really you just need to know if it is 0 or not-0, so just test it > for ==0 or !=0. > - rather than using multiplication and modulus to assign the dr,dg,db > values near line 291, why not just use "dr = (i == 0) ? 0 : 255;"? > - the tests for range use a separate subtraction and a compare, when > they could be inlined. > > First, I'd get rid of the "represents_primary" variable entirely and > then rewrite the whole tail end of the loop body from 291 to the end > of the loop as: > > if (i == 0) { > if (r > delta) return false; > } else { > if (r < 255-delta) return false; > } > // 2 more similar tests for j/g and k/b > > Then "return true" at the end of the function if it reaches there. > Keep in mind that the mapping of ijk to rgb might be affected if you > fix the shifts used to extract the rgb components from color... > > ...jim > > On 4/20/2016 2:46 AM, Jayathirth D V wrote: >> Hi Jim, >> >> As discussed we will not add dithering error values to primary colors >> with color map which represents Primary colors approximately(+/-5 >> delta). >> I have made changes based on this suggestion and added new function >> to calculate whether color map represents primary colors >> approximately or not. >> If it represents only then we will avoid adding dithering error >> values in case ByteIndexed destination. >> >> I have observed that in case of white color we are picking >> (252,252,252) or (246,246,246) and not (255,255,255) from colormap. >> What I have observed that out of 256 places we are storing RGB colors >> at start and then gray values. So we are picking final gray value and >> not in between white value. That's why I am not verifying white color >> validity in test case. >> >> Please find updated webrev for review : >> http://cr.openjdk.java.net/~jdv/7116979/webrev.01/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Saturday, February 20, 2016 3:02 AM >> To: Jayathirth D V >> Cc: 2d-dev at openjdk.java.net; Philip Race; Prasanta Sadhukhan >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : >> Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED >> >> Hi Jayathirth, >> >> Thank you for attaching the detailed logs, but I don't have a program >> that can deal with the 7z files. Can you summarize what was learned >> from them? >> >> Also, the colormap you created, while subset, was a perfectly scaled >> cube. I was referring more to a random colormap where you might have >> 2 colors close to a primary, but neither is on a line from the >> primary to the 0.5 gray value so each has a different hue. That's >> something that can only be evaluated visually. One example of >> randomized colormaps is when we display via X11 onto an 8-bit >> display. That probably never happens any more, but we may not be >> able to allocate colors in the colormap in such a case and if another >> program has already allocated most of the dynamic colormap then we >> would not be able to add our own colors. >> >> This could be dealt with by simply marking our standard colormap as >> having primaries, or by scanning any given colormap and marking it if >> it has primaries, and then only perform this code on colormaps with >> the primaries. Solving it for our own colormap (or solving it for >> any colormap that has all primaries) would likely solve it for 99% of >> the vanishingly small number of developers who might run into this. >> >> But, in the end, what would we accomplish by adding this one very >> targeted fix? >> >> I'm also curious where the push for this is coming from. While we >> aren't perfect here, so much of the world today is focused on >> lossless image formats that I don't imagine there is much need for >> really good 8-bit indexed image support any more...? >> >> If anything, spatial dithering is considered a very low quality >> algorithm and error propagation dithering would handle all of the >> colormaps much better. We used to do error propagation dithering >> back in the JDK 1.1 days, but we dropped it when we introduced 2D >> because we added a bunch of ways to render small pieces of an image >> and only the current spatial dithering algorithm can be started in >> the middle of an operation. That doesn't mean that you can't still >> do error propagation since many operations already operate on the >> full image any way and you can still handle subset image operations >> by either converting the full image first and then copying or by >> tracing the errors from the edge of the image to the point of the >> subimage operation. We never bothered to upgrade our algorithms it >> just never seemed to be work that made sense to prioritize given that >> screens were overwhelmingly moving to full-color at the time of "Java >> 2" (and now to HDR in 2016+). 8-bit indexed isn't used much any more. >> >> If we want to make 8-bit destination images work better we'd be >> better off adopting error propagation dithering again rather than >> trying to tune this algorithm for black. >> >> It looks like the bug was closed briefly in 2014 and then reopened >> soon thereafter with no justification. It is true that we still have >> this anomaly, but it isn't clear why this is high enough priority to >> work on in 2016 when other bit depths would work better for >> destination imagery and other dithering algorithms would work better >> for most customers and even this targeted fix isn't perfect... >> >> ...jim >> >> On 2/16/2016 8:32 AM, Jayathirth D V wrote: >>> Hi Jim, >>> >>> Thanks for letting me know about the importance of custom color >>> maps. I was not able to understand what you mentioned previously >>> since I am new to this terminology. >>> >>> Regarding performance I checked with image having complete >>> 255,255,128 pixels and ran it for 100 times. I am running on Windows >>> 7 Professional SP1 with Intel i5-5300U CPU. Overall I don't see >>> much difference in time taken for drawImage() API before and after >>> change. Details for INT_RGB image as input: >>> >>> Before change : >>> Minimum time 536827ns >>> Maximum time 1560947ns >>> Average time 871167ns >>> >>> After change : >>> Minimum time 536380ns >>> Maximum time 1468130ns >>> Average time 830778ns >>> >>> There is +/- 10% delta both for before and after change time but >>> there is no major gap. Even for image with other input type it holds >>> the same. >>> >>> >>> Regarding custom color maps, previously I ran on default color map >>> generated in TYPE_BYTE_INDEXED constructor. Now I tested with >>> modified color map so that it doesn't contain any of the primary >>> color values. Instead of using 0-255 values with value 51 increments >>> in R,G,B components I used color map with 20-245 values with value >>> 45 as increment. For this color map before and after change all the >>> pixels are referring to same index in color map irrespective of >>> removal of error delta addition in case of primary colors. >>> >>> I have attached log for Red and Green primary colors before and >>> after change(Was not able to attach for more since it exceeded 120KB >>> mailing list limit). Please search for "Final index value =" in the >>> logs. Please let me know your inputs. >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Jim Graham >>> Sent: Tuesday, February 16, 2016 1:03 AM >>> To: Jayathirth D V >>> Cc: 2d-dev at openjdk.java.net; Philip Race; Prasanta Sadhukhan >>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : >>> Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED >>> >>> Hi Jayathirth, >>> >>> The issue with testing performance with white images is that the >>> tests allow the code to eliminate 3 indexed fetches which take >>> time. Primary colors end up being the one obscure case where the >>> new code might be faster. But, non-primary colors would be slower >>> by a fair amount, so performance testing with converting a >>> randomized or non-primary-color image are the more telling case. An >>> image filled with 255,255,128 would be the worst case because it >>> would involve all of the tests and still have to do all of the lookups. >>> >>> My question about how this works with custom colormaps was not >>> really addressed by your response. A simple test to make sure the >>> colormap has accurate (or very close) conversions for the primary >>> colors may be enough to validate the colormap for the indicated >>> tests. If the colormap contains no pure conversions for some of the >>> primary colors then they may need to be dithered anyway... >>> >>> ...jim >>> >>> On 2/15/16 3:39 AM, Jayathirth D V wrote: >>>> Hi Jim, >>>> >>>> I performed performance analysis with white image so that all >>>> conditions are checked in the new branch added. There is no major >>>> difference in time taken before and after change. For each input I >>>> have tested time taken for drawImage() API to convert from every >>>> format to Byte indexed type. For every unique conversion test is run >>>> for 100 times. Please find the details: >>>> >>>> Input >>>> >>>> type >>>> >>>> >>>> >>>> Min >>>> >>>> before change >>>> >>>> (ns) >>>> >>>> >>>> >>>> Min >>>> >>>> after change >>>> >>>> (ns) >>>> >>>> >>>> >>>> Max >>>> >>>> before change >>>> >>>> (ns) >>>> >>>> >>>> >>>> Max >>>> >>>> after change >>>> >>>> (ns) >>>> >>>> >>>> >>>> Average >>>> >>>> before change >>>> >>>> (ns) >>>> >>>> >>>> >>>> Average >>>> >>>> after >>>> >>>> change >>>> >>>> (ns) >>>> >>>> INT_RGB >>>> >>>> >>>> >>>> 523437 >>>> >>>> >>>> >>>> 481491 >>>> >>>> >>>> >>>> 1230724 >>>> >>>> >>>> >>>> 1270440 >>>> >>>> >>>> >>>> 789452 >>>> >>>> >>>> >>>> 666144 >>>> >>>> INT_ARGB >>>> >>>> >>>> >>>> 500232 >>>> >>>> >>>> >>>> 493986 >>>> >>>> >>>> >>>> 12406307 >>>> >>>> >>>> >>>> 1308816 >>>> >>>> >>>> >>>> 793384 >>>> >>>> >>>> >>>> 654015 >>>> >>>> INT_ARGB_PRE >>>> >>>> >>>> >>>> 500233 >>>> >>>> >>>> >>>> 492201 >>>> >>>> >>>> >>>> 1037057 >>>> >>>> >>>> >>>> 981277 >>>> >>>> >>>> >>>> 710250 >>>> >>>> >>>> >>>> 699214 >>>> >>>> INT_BGR >>>> >>>> >>>> >>>> 537716 >>>> >>>> >>>> >>>> 562706 >>>> >>>> >>>> >>>> 1446703 >>>> >>>> >>>> >>>> 2046001 >>>> >>>> >>>> >>>> 862377 >>>> >>>> >>>> >>>> 863256 >>>> >>>> 3BYTE_BGR >>>> >>>> >>>> >>>> 483275 >>>> >>>> >>>> >>>> 481045 >>>> >>>> >>>> >>>> 1181638 >>>> >>>> >>>> >>>> 1384676 >>>> >>>> >>>> >>>> 651427 >>>> >>>> >>>> >>>> 580961 >>>> >>>> 4BYTE_ABGR >>>> >>>> >>>> >>>> 544410 >>>> >>>> >>>> >>>> 499786 >>>> >>>> >>>> >>>> 1292305 >>>> >>>> >>>> >>>> 968783 >>>> >>>> >>>> >>>> 690106 >>>> >>>> >>>> >>>> 683881 >>>> >>>> 4BYTE_ABGR_PRE >>>> >>>> >>>> >>>> 504249 >>>> >>>> >>>> >>>> 505588 >>>> >>>> >>>> >>>> 1680086 >>>> >>>> >>>> >>>> 1216445 >>>> >>>> >>>> >>>> 756101 >>>> >>>> >>>> >>>> 687750 >>>> >>>> USHORT_565_RGB >>>> >>>> >>>> >>>> 507818 >>>> >>>> >>>> >>>> 505588 >>>> >>>> >>>> >>>> 978153 >>>> >>>> >>>> >>>> 1346746 >>>> >>>> >>>> >>>> 652908 >>>> >>>> >>>> >>>> 655782 >>>> >>>> USHORT_555_RGB >>>> >>>> >>>> >>>> 510496 >>>> >>>> >>>> >>>> 509604 >>>> >>>> >>>> >>>> 952272 >>>> >>>> >>>> >>>> 1162004 >>>> >>>> >>>> >>>> 650418 >>>> >>>> >>>> >>>> 670811 >>>> >>>> BYTE_GRAY >>>> >>>> >>>> >>>> 481491 >>>> >>>> >>>> >>>> 478367 >>>> >>>> >>>> >>>> 1140585 >>>> >>>> >>>> >>>> 1799231 >>>> >>>> >>>> >>>> 691160 >>>> >>>> >>>> >>>> 583250 >>>> >>>> USHORT_GRAY >>>> >>>> >>>> >>>> 506927 >>>> >>>> >>>> >>>> 507373 >>>> >>>> >>>> >>>> 1375751 >>>> >>>> >>>> >>>> 1255267 >>>> >>>> >>>> >>>> 728202 >>>> >>>> >>>> >>>> 646902 >>>> >>>> BYTE_BINARY >>>> >>>> >>>> >>>> 541733 >>>> >>>> >>>> >>>> 496217 >>>> >>>> >>>> >>>> 1083466 >>>> >>>> >>>> >>>> 959411 >>>> >>>> >>>> >>>> 730527 >>>> >>>> >>>> >>>> 728461 >>>> >>>> The changes are tested with plain images having primary colors like >>>> RED, GREEN, BLUE, BLACK and WHITE. >>>> >>>> Thanks, >>>> >>>> Jay >>>> >>>> -----Original Message----- >>>> From: Jim Graham >>>> Sent: Friday, February 12, 2016 4:05 AM >>>> To: Jayathirth D V; 2d-dev at openjdk.java.net; Philip Race; Prasanta >>>> Sadhukhan >>>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : >>>> Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED >>>> >>>> Hi Jayathirth, >>>> >>>> Did you do any performance analysis of this change? You are adding 6 >>>> tests and multiple branches to per-pixel code. >>>> >>>> The effectiveness of this technique depends on the colormap that we >>>> have set up. For the BufferedImage.TYPE_INDEXED constructor we >>>> produce a fairly nice colormap, but if someone creates a custom >>>> colormap then the colors could be anything. We create a decent >>>> inversion for just about any colormap, but that doesn't mean that >>>> using only "the best match for solid red" will produce a better >>>> result for a dithered approximation for red. It is true that if >>>> there is a really good match for red then we should just use that, >>>> but if there are no direct matches for red then we may choose to >>>> paint a red region with solid orange even though there is another >>>> color in the colormap that when mixed with orange approximates a red >>>> tone better. For example, if a colormap contains no pure red, but >>>> >>>> contains: >>>> >>>> 240, 20, 0 >>>> >>>> 240, 0, 20 >>>> >>>> (I'm not sure if 20 is within our current error deltas that we use >>>> for dithering, but this is an example not a test case.) >>>> >>>> Then using one of these alone might skew the color towards orange or >>>> purple. Using both together in a dither pattern might keep the >>>> overall hue impression as red, but with a small amount of noise in >>>> its saturation. >>>> >>>> What types of colormaps was this tested with? >>>> >>>> ...jim >>>> >>>> On 2/11/16 6:37 AM, Jayathirth D V wrote: >>>> >>>>> Hi, >>>> >>>>> >>>> >>>>> _Please review the following fix in JDK9:_ >>>> >>>>> >>>> >>>>> __ >>>> >>>>> >>>> >>>>> Bug :https://bugs.openjdk.java.net/browse/JDK-7116979 >>>> >>>>> >>>> >>>>> Webrev :http://cr.openjdk.java.net/~jdv/7116979/webrev.00/ >>>> >>>>> >>>> >>>>> Issue : When Image containing black pixels are converted from any >>>> >>>>> format to Byte Indexed format some of the pixels are not black. They >>>> >>>>> are following pattern similar to dithering. >>>> >>>>> >>>> >>>>> Root cause : When we convert any format type to ByteIndexed we are >>>> >>>>> adding Error delta values to R,G,B components using dithering >>>>> indices. >>>> >>>>> This is causing some pixels values to not point to proper index in >>>> >>>>> color table. >>>> >>>>> >>>> >>>>> Solution : There is no need to add error delta for primary colors >>>> >>>>> containing basic values in R,G,B components. Exclude such pixels >>>>> from >>>> >>>>> delta addition. >>>> >>>>> >>>> >>>>> Thanks, >>>> >>>>> >>>> >>>>> Jay >>>> >>>>> >>>> From james.graham at oracle.com Tue Apr 26 20:41:39 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 26 Apr 2016 13:41:39 -0700 Subject: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: Antialiased text on translucent backgrounds gets bright artifacts In-Reply-To: <4213d5c2-3711-4631-87a3-ba40c1e5ceeb@default> References: <63d69ba8-d5cf-4697-bb5c-f51aaaa8c427@default> <56EB4DBB.9080802@oracle.com> <56F3505B.2070101@oracle.com> <215e497a-db82-4f6f-99e9-bd44f25d5999@default> <56FAF088.70300@oracle.com> <6b400fd0-a335-46a5-9fed-abb06c3fd6a0@default> <56FC33F6.1060108@oracle.com> <5702DE6F.5000903@oracle.com> <4213d5c2-3711-4631-87a3-ba40c1e5ceeb@default> Message-ID: <2b1d0a70-0ab3-ca34-92f0-447a435f72a3@oracle.com> Hi Prahalad, One potential portability issue - you have a "DeclareAndInit" macro for the new "choose which blend factor" macro in the middle of a block. Some C compilers allow declaring a new variable in the middle of a block, but not all. Since it would be hard to move the declaration to the top of the block, since it depends on a value computed in the first couple of lines, it might be better to change it from a "DeclareAndInit" style macro into a regular declaration, and a macro to get the value, so "jint blendF;" at the top of the block and "blendF = SrcOverDstBlendFactorFor ## DST(...);" in the middle of the block. (Or name it "SrcOver ## DST ## BlendFactor(...)?" I just noticed something about this .04 version of the function. At the top you have a test for mixValSrc != 255 and then both clauses of the if statement end with essentially the same code, multiplying the source by the value in resA. (The version in the else clause uses SRC_PREFIX ## A, but it could just as easily also use resA since they are the same value at that point.) This means you could potentially move both "MultiplyAndStore" macros until after the if and use resA as the multiplier. Now, if you look, the immediate next statement tests if resA is maxVal. If it is maxVal, then you don't need to do that multiply at all, so the macro could be moved even further to be inside the "if (resA != maxVal)" block. At that point, you could then reinstate the "else" on that if block and move the Store##DST##PixelData into that else, to save you another test of resA. This would essentially look like this: if (mixValSrc != 255) { PromoteByteAlpha...; resA = MultiplyAlpha...; } else { resA = SRC_PREFIX ## A; } if (resA != MaxVal) { Declare,declare,declare,declare...; Multiply...Comps(res, resA, SRC_PREFIX); } else { Store ## DST ## PixelData...; } It shortens the code a little, but I'm not sure if it would really help performance other than not having to do the test for maxVal twice. Still, tests are fairly expensive in code like this so it could be worth a shot at testing, and it would simplify the code a bit in either case... ...jim On 4/15/16 12:25 AM, Prahalad Kumar Narayanan wrote: > Hello Jim & Everyone on Java2D Community > > Good day to you. > > This is a review request and a follow-up to the bug-fix for the issue > Bug : JDK-8015070 > Link : https://bugs.openjdk.java.net/browse/JDK-8015070 > > Webrev Link : http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.04/ > > Quick Inferences on Changes in Current -Webrev.04 > > 1 ) Subtle changes to the blend loop- > . The subtle changes taken up, have helped to improve the performance. > . With the current logic in webrev.04, Java2DBench reports better performance than Un-Optimized solution that was present in webrev.00 > . J2DBench was run for Font Styles { Plain, Bold, Italic, Bold n Italic } and Font Sizes { 12, 20, 36, 72 } > . My sincere thanks to Jim for all his detailed feedback through the multiple reviews that has evolved the solution today. > > (Details on changes) > 1.a. Loading of Color components > . When modelled as per SRCOVER_MASK_FILL code, the logic required few additional calculations to load color components. > . The extra calculations indeed impacted performance figures. > . This could be offset in two possible ways > a. Inspect parent macro- NAME_SOLID_DRAWGLYPHLISTAA and advance by pixel address and not by pixel index. > The parent macro invokes GlyphListAABlendFourByteArgb through this macro- GlyphListAABlend ## STRATEGY(DST, pixels, x, pPix, fgpixel, solidpix, src); > Changing parent macro will cause spurious changes across GlyphListAABlend ## other pixel formats. > There is additional risk of breaking the stable and well optimized LoopMacros.h. > b. Load color components based on pre-Multiplication status > This has been taken up and change is limited to the function being modified. > Thankfully J2DBench has still reported improvement in performance. > > 1.b. New Macro to avoid if (DST ## IsPremultiplied) { > . A new macro- DeclareAndInit ## DST ## SrcOverMaskBlendFactor has been introduced to choose between dstF, or dstA > . The implementation is available in the header files of pixel formats ( Eg: IntArgb.h IntArgbPre.h ) > . There are 29 different pixel formats known to Java2D, and > . Hence, the new macro's implementation is added only to those pixel formats that require the current glyph blending logic. > > 2 ) Testing across different formats > . The Regression test code has been modified to test anti-aliased text rendering on 7 different pixel formats- > . IntArgb, IntArgb_Pre, FourByteAbgr, FourByteAbgr_Pre, IntRGB, IntBGR, 3ByteBGR. > . As expected, the test fails without the fix on JDK 8 and JDK 7 versions & passes with JDK 9-internal containing the fix. > > 3 ) Explanation on Code Changes : > . With multiple reviews and changes, today the code fixes the bug and is well optimized as well. > . For ease of reviewer and effort in review, I 've explained the logic with /* comment statements */ herewith. > . Note: These comments don't figure in the webrev. > As one cannot guarantee how /* comments */ within macros would be perceived by compiler across different platforms. > > #define GlyphListAABlend4ByteArgb(DST, GLYPH_PIXELS, PIXEL_INDEX, DST_PTR, \ > FG_PIXEL, PREFIX, SRC_PREFIX) \ > do { \ > DeclareAlphaVarFor4ByteArgb(resA) \ > DeclareCompVarsFor4ByteArgb(res) \ > jint mixValSrc = GLYPH_PIXELS[PIXEL_INDEX]; \ > if (mixValSrc) { \ > /* Evaluating srcColor components */ \ > if (mixValSrc != 0xff) { \ > /* No-op. Retained to match reference as SRCOVER_MASK_FILL */ \ > PromoteByteAlphaFor4ByteArgb(mixValSrc); \ > /* Glyph mask determines visibility of the srcColor */ \ > resA = MultiplyAlphaFor4ByteArgb(mixValSrc, SRC_PREFIX ## A); \ > MultiplyAndStore4ByteArgbComps(res, resA, SRC_PREFIX); \ > } else { \ > /* If mixValSrc and srcA are maximum, then result color is */ \ > /* opaque. Hence the fast path to store foreground pixel */ \ > /* color and return. */ \ > if (SRC_PREFIX ## A == MaxValFor4ByteArgb) { \ > Store ## DST ## PixelData(DST_PTR, PIXEL_INDEX, \ > FG_PIXEL, PREFIX); \ > break; \ > } \ > /* This is understood easier with floating point logic. */ \ > /* 1.0f is max value used in floating point calculation */ \ > /* (1.0f * srcA) gives srcA. Hence we directly consider */ \ > /* srcA without Multiply with glyph mask. */ \ > resA = SRC_PREFIX ## A; \ > MultiplyAndStore4ByteArgbComps(res, \ > SRC_PREFIX ## A, \ > SRC_PREFIX); \ > } \ > /* Evaluating dstColor components */ \ > /* This is required only when resA(i.e., srcA) is not maximum */ \ > if (resA != MaxValFor4ByteArgb) { \ > DeclareAndInvertAlphaVarFor4ByteArgb(dstF, resA) \ > DeclareAndClearAlphaVarFor4ByteArgb(dstA) \ > DeclareCompVarsFor4ByteArgb(dst) \ > DeclareCompVarsFor4ByteArgb(tmp) \ > /* Based on the pixelFormat we could reduce calculations */ \ > /* done to load the color and alpha components */ \ > if (!(DST ## IsPremultiplied)) { \ > Load ## DST ## To4ByteArgb(DST_PTR, pix, PIXEL_INDEX, \ > dstA, dstR, dstG, dstB); \ > Store4ByteArgbCompsUsingOp(tmp, =, dst); \ > } else { \ > Declare ## DST ## AlphaLoadData(DstPix) \ > jint pixelOffset = PIXEL_INDEX * (DST ## PixelStride); \ > DST ## DataType *pixelAddress = PtrAddBytes(DST_PTR, \ > pixelOffset); \ > /* The macro's implementation loads color components */ \ > /* without divide by alpha adjustment as required for */ \ > /* subsequent calculations. Note: This is used only */ \ > /* with preMultiplied alpha based pixel formats */ \ > LoadAlphaFrom ## DST ## For4ByteArgb(pixelAddress, \ > DstPix, \ > dst); \ > Postload4ByteArgbFrom ## DST(pixelAddress, \ > DstPix, \ > tmp); \ > } \ > /* Avoid blending operatons if dst is fully transparent */ \ > if (dstA) { \ > /* dstA would be 0 if either of the following is true. */ \ > /* 1. srcA is max. Parent if condition validates this. */ \ > /* 2. dstA is zero. The current if condition validates */ \ > /* Henceforth, the following Multiply need not be moved*/ \ > /* ahead of the if condition. This also helps to better*/ \ > /* performance */ \ > dstA = MultiplyAlphaFor4ByteArgb(dstF, dstA); \ > resA += dstA; \ > /* Declares blendF variable and assigns appropriate */ \ > /* alpha value. The definitions are contained in the*/ \ > /* header files of respective pixel formats */ \ > DeclareAndInit ## DST ## SrcOverDstBlendFactor(dstF, \ > dstA, \ > blendF); \ > /* This is understood easier with floating point logic.*/ \ > /* 1.0f is max value used in floating point calculation*/ \ > /* (1.0f * tmp) gives tmp. Hence we avoid 3 Multiply */ \ > /* operations and add the loaded color to result */ \ > if (blendF != MaxValFor4ByteArgb) { \ > MultiplyAndStore4ByteArgbComps(tmp, \ > blendF, \ > tmp); \ > } \ > Store4ByteArgbCompsUsingOp(res, +=, tmp); \ > } \ > } \ > /* In the above calculations, color values are multiplied with */ \ > /* with alpha. This is perfectly fine for pre-Multiplied alpha */ \ > /* based pixel formats. For non pre-multiplied alpha based */ \ > /* pixel formats, the alpha is removed from color components */ \ > /* and then stored to the resulting color. */ \ > if (!(DST ## IsOpaque) && \ > !(DST ## IsPremultiplied) && resA && \ > resA < MaxValFor4ByteArgb) \ > { \ > DivideAndStore4ByteArgbComps(res, res, resA); \ > } \ > Store ## DST ## From4ByteArgbComps(DST_PTR, pix, \ > PIXEL_INDEX, res); \ > } \ > } while (0); > > My apologies if the above code did not appear on the final webrev email. > ( In few instances, the newlines don't appear in plain-text format ) > > Kindly review the changes present in webrev and provide your views. > If the changes are good, we could take up for the code check-in. > > Thank you for your time in review > Have a good day > > Prahalad N. > > > > -----Original Message----- > From: Jim Graham > Sent: Tuesday, April 05, 2016 3:07 AM > To: Prahalad Kumar Narayanan; Sergey Bylokhov; Philip Race > Cc: Praveen Srivastava > Subject: Re: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: Antialiased text on translucent backgrounds gets bright artifacts > > Hi Prahalad, > > Can I see the webrev diffs for the "today's experiment" code with the new macro? > > Also, Did you test this with opaque destinations? The most common use of text is on an opaque destination, so that would matter more. I would > suggest: INT_RGB, THREE_BYTE_BGR, INT_ARGB, INT_ARGB_PRE in that order of precedence of importance. Also, test with translucent colors, though those are less important than opaque colors. > > I'm still looking at why the non-pre would be slower than the pre. > About the only difference is the one line "if (!PRE) { DSTF = DSTA; }". > One suggestion might be to move the test for transparent destination up a couple of lines, and to get rid of the extra "DSTF = dstA" > assignement with the following structure: > > dstA = Mult...(); > if (dstA) { > resA += dstA; > Declare... > Postload... > if (DST ## IsPremultiplied) { > MultiplyAndStore(..., DSTF, ...); > } else { > MultiplyAndStore(..., dstA, ...); > } > Store... > } > > Basically, dstA == 0 is the actual test for "do we need to even try to blend the destination in here". If it is zero then there is no need to add dstA to resA and there is no need to adjust the factor we blend by (MultiplyAndStore). It can be triggered by either a transparent destination pixel or an opaque source pixel, but either way, dstA is the right test, not DSTF. The second part, eliminating the DSTF=dstA assignment, gets rid of a line that might trip up the optimizer by simply having the macro expand differently for the two types. To be even more streamlined, we could create a new set of macros: > > // In the header files for PRE types: > #define SRCOVER_DST_BLEND_FACTOR_(dF, dA) (dF) > // In the header files for non-PRE types: > #define SRCOVER_DST_BLEND_FACTOR_(dF, dA) (dA) > > Then we wouldn't need the test above for "if (DST ## Pre)", we would just expand the macro with: > MultiplyAndStore(..., SRCOVER_DST_BLEND_FACTOR ## DST(DSTF, dstA), ...) which would hopefully confuse the optimizer even less. > > If you want to really eliminate the pixel address computations, you could rewrite the calling loop so that it steps along a pixel pointer rather than using indexing. Have the calling function/macro set up a pRas pointer to the pixel and step that along the row by TYPE##PixelStride as it iterates across the glyph, then hand that into the Glyph blend macro as DST_PTR (and eliminate PIXEL_INDEX as it would be "0" in this case)... > > ...jim > > On 4/4/16 4:37 AM, Prahalad Kumar Narayanan wrote: >> Dear Jim >> >> Good day to you. >> >> ( Just in-case, you had missed my long Friday 's email ) >> >> Quick Recap of Proceedings >> >> 1.On Friday, I had profiled two solutions that fix the bug- >> JDK-8015070, using Java2D Bench >> >> 2.Profiling was done for 16 test cases with different combinations of >> >> a.Font Style: Plain, Bold, Italic, Bold-Italic >> >> b.Font Size: 12, 20, 36, 72 >> >> 3.Result from Friday 's profiling experiments: >> >> a.Regular Solution (Un-optimized) : This was observed to be faster for >> IntArgb pixel format >> >> b.Optimized Solution (based on SrcOver_MaskFill with fast path) : This >> was observed to be faster for IntArgb_Pre pixel format >> >> Update from Today's Experiments >> >> 1.First, I understood that new calculations introduced (pixelAddress >> computation) impacted performance of optimized solution in IntArgb format. >> >> 2.Henceforth, I made the following changes, while loading destination color: >> >> a.Check if the pixel format is PreMultiplied >> >> b.If the format is preMultiplied, then > take up new calculations and >> use LoadAlphaFrom ## DST ## For4ByteArgb macro that does *Not* cause >> divide by alpha adjustment >> >> c.If the format is regular Argb, then > take up loading of colors >> using standard Load ## DST ## To4ByteArgb >> >> 3.Once the release build was available, Java2D Bench was re-run (using >> pre-saved options file) >> >> Result from Bench metrics: >> >> a.In most of the test cases, the optimized solution has higher metric : >> Avg characters/ second for both IntArgb and IntArgb_Pre formats >> >> b.In 6 / total-16 test cases, optimized solution was marginally lower >> than the metrics of Regular un-optimized algorithm (only for >> IntArgb_Pre) >> >> c.However, J2DAnalyzer reported that even these 6-test cases were >> within 10% deviation. Hence the algorithms were categorized to be >> 'same' in performance. >> >> Suggestion Required >> >> 1.The attached zip file, contains Algorithms.cpp - Which lists down >> different algorithms profiled so far. >> >> 2.I 've introduced comments within the macro to explain the change. >> >> a.Note: These comments will be removed from the final source code to >> be checked in. >> >> 3.Kindly review the latest algorithm (for any issues/ bugs) and >> provide your suggestions. >> >> a.latest algorithm can be easily traced by searching for >> "LoadOptimized Algorithm v3" within the file. >> >> Thank you for your time in review & detailed feedback that you get >> every time. >> >> Every such review improves the quality of code & the solution >> >> Prahalad N. >> >> *From:* Prahalad Kumar Narayanan >> *Sent:* Friday, April 01, 2016 5:07 PM >> *To:* Jim Graham; Sergey Bylokhov; Philip Race >> *Cc:* Praveen Srivastava >> *Subject:* RE: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: >> Antialiased text on translucent backgrounds gets bright artifacts >> >> Dear Jim >> >> Good day to you. >> >> Thanks for your suggestions in the reviews that has evolved the fix to >> the bug. >> >> As guided by you, I measured the performance of Text Rendering with >> Text Antialiasing Hint on using Java2D Bench Tool. >> >> Solutions Profiled: >> >> We have two solutions - Un optimized solution and Optimized >> solution modelled as per SRCOVER_MASKFILL >> >> ( Both the solutions were profiled on windows x86_64 with JDK >> 9-internal Release build ) >> >> Test Cases Profiled: >> >> With Font set to : Lucida sans, different combinations of >> >> Font Styles : Plain, Bold, Italic, Bold Italic && >> >> Font Sizes : 12, 20, 36, 72 points were tested. >> >> Attached herewith: JDK8015070-Profiling Data.zip >> >> The archive contains: >> >> 1. Algorithms.cpp : Just to have a quick glance of all the >> algorithms that we have tried so far. >> >> 2. *.txt Files : For each test, Java2D bench >> reports the average metrics/second. >> >> The text file >> contains collection of all such average metric for nearly 16 different >> test cases. >> >> 3. res Output : .res output from each of the test runs. >> >> Observation from J2DBench Reports >> >> 1. I could not get time to run the Analyzer tool across each >> of these *.res files. I shall do them on Monday. >> >> 2. From the summary text ( average chars per. Second ) that >> J2DBench reported, >> >> Un-optimized solution seems to be better for >> IntArgb pixel format and >> >> Optimized solution is better for IntArgb_Pre >> pixel format by significant margin. >> >> 3. I tried to improve the optimized algorithm (based on >> SRCOVER_MASKFILL ) further by adding a if (dstA) { ... >> >> Though there is a marginal improvement, the >> optimized solution could not exceed numbers of regular algorithm (for >> IntArgb pixel format) >> >> This could be due to the extra calculations that >> we do in-order to load color components separately. >> >> However, for IntArgb_Pre pixel format, the >> optimized solution is way-ahead and gives better performance. >> >> 4. In the summary reports, you will find >> CompatibleBufferedImage( Translucent ) as well. >> >> In a separate experiment, I found that the pixel >> format for compatible buffered image got mapped IntArgb_Pre. >> >> Thus, the performance numbers match with that of >> IntArgb_Pre pixel format >> >> At the present moment, I 'm confused on the solution would be better >> to fix the Bug. >> >> Kindly share your views and thoughts >> >> Thank you >> >> Have a good day >> >> Prahalad N. >> >> -----Original Message----- >> From: Jim Graham >> Sent: Thursday, March 31, 2016 1:46 AM >> To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net >> ; Sergey Bylokhov >> Subject: Re: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: >> Antialiased text on translucent backgrounds gets bright artifacts >> >> Hi Prahalad, >> >> Benchmarks must run for a significant period of time to be valid. >> >> Measuring with nanoTime() is fine, but the run times should exceed at >> least a couple of seconds, not a few nanoseconds. You might want to >> use Java2DBench instead (in src/demo/share/java2d in the java.desktop >> repo), which calibrates test times, does multiple runs, and includes >> an analyzer to compare results from multiple test runs... >> >> ...jim >> >> On 3/30/2016 4:27 AM, Prahalad Kumar Narayanan wrote: >> >>> Hello Jim and Everyone on Java2D Group >> >>> >> >>> Good day to you. >> >>> >> >>> A quick follow-up to Review Request on bug: >> >>> Bug : JDK-8015070 >> >>> Bug Link :https://bugs.openjdk.java.net/browse/JDK-8015070 >> >>> >> >>> Thank you Jim for the detailed feedback. >> >>> >> >>> It takes a lot of time not only in performing the review, but also in getting the feedback with clear words. >> >>> In each review, the solution definitely gets better & better. I 'm >> >>> happy about it...! :) >> >>> >> >>> Quick Inferences from previous feedback: >> >>> >> >>> Incorporating the fast path into current logic: >> >>> 1. I agree with you on this point and I noticed this when we modelled the solution as per the mask fill. >> >>> 2. I ignored it initially for two reasons, >> >>> a. The statement - if (resA != MaxValFor4ByteArgb)... follows srcColor pre-multiplication step and this will ensure to skip most of the blending calculations pertaining to destination. >> >>> b. Any addition / tweaks to current logic, might deviate from the SRCOVER_MASKFILL reference model. >> >>> Many a time, managing code with similar logic across implementation helps a lot. >> >>> 3. As you said, including the fast path will avoid few multiplications and if checks too. >> >>> The changes are available in the current webrev. >> >>> Link: >> >>> http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.03/ >> >>> >> >>> Profiling method, and Metrics: >> >>> 1. The profiling method that was done yesterday was mere >>> execution of the regression test (available in the webrev) and time >>> measured with System.currentTimeMillis API >> >>> Since only one iteration was run, the time soared into milli seconds. This could be due to internal glyph caching mechanism. >> >>> 2. Today, I evolved the regression test, into a benchmark that does the following: >> >>> a. Select Font style : {Plain, Bold, Italic, Bold >>> Italic} >> >>> b. Select Font size : {20, 40, 60, 80} >> >>> c. Trigger drawstring once before benchmark is run. This is to ensure, the font subsystem is done with glyph caching internally. >> >>> d. Use famous string that has all characters-" The quick brown fox jumps over the lazy dog. 0123456789. " >> >>> e. For every style-size combination - run the test >>> for 20 iterations and take the average. (Note: Font is fixed to >>> 'verdana' ) >> >>> f. Modify the precision from System.currentTimeMillis to System.nanoTime() and reduce elapsedTime to micro seconds. >> >>> >> >>> 3. With the above setup in code, my observation on windows is as follows: >> >>> a. In many cases, The optimized logic is either equal-to (or) better in performance than the un-optimized logic. >> >>> The difference is very minimal - few tens to few hundreds of micro-seconds. >> >>> b. The optimized algorithm improves performance for Pre-multiplied alpha based destination buffer. >> >>> c. There are occasional huge deviations where optimized logic seems to take longer time. >> >>> These could be due to external factors >>> like- stalls for memory, bus io etc., >> >>> Since, the deviation is in micro seconds, I believe, it may not be a concern. >> >>> d. The complete list of time measurement taken up >>> on windows x86_64 release build is as-follows- >> >>> I 'm not sure, how the data appears in the final webrev-email. >> >>> Kindly excuse, if the data is un-readable. >> >>> >> >>> Platform : Windows x86_64 Release Build Algorithm : Unoptimized. >> >>> webrev.00 >> >>> ````````````````````````````````````````````````````````````````````` >>> ` >> >>> ```` Executing Bench For Image Type: IntArgb >> >>> -Font Style: Plain /Font Size: 20 /Time consumed (us): 84.742 >> >>> -Font Style: Plain /Font Size: 40 /Time consumed (us): 318.395 >> >>> -Font Style: Plain /Font Size: 60 /Time consumed (us): 657.474 >> >>> -Font Style: Plain /Font Size: 80 /Time consumed (us): 813.079 >> >>> -Font Style: Bold /Font Size: 20 /Time consumed (us): 386.380 >> >>> -Font Style: Bold /Font Size: 40 /Time consumed (us): 339.301 >> >>> -Font Style: Bold /Font Size: 60 /Time consumed (us): 492.631 >> >>> -Font Style: Bold /Font Size: 80 /Time consumed (us): 625.812 >> >>> -Font Style: Italic /Font Size: 20 /Time consumed (us): 235.059 >> >>> -Font Style: Italic /Font Size: 40 /Time consumed (us): 320.180 >> >>> -Font Style: Italic /Font Size: 60 /Time consumed (us): 474.558 >> >>> -Font Style: Italic /Font Size: 80 /Time consumed (us): 1188.169 >> >>> -Font Style: Bold-Italic /Font Size: 20 /Time consumed (us): >>> 426.988 >> >>> -Font Style: Bold-Italic /Font Size: 40 /Time consumed (us): >>> 374.064 >> >>> -Font Style: Bold-Italic /Font Size: 60 /Time consumed (us): >>> 732.375 >> >>> -Font Style: Bold-Italic /Font Size: 80 /Time consumed (us): 864.68 >> >>> >> >>> Executing Bench For Image Type: IntArgb_Pre >> >>> -Font Style: Plain /Font Size: 20 /Time consumed (us): 129.768 >> >>> -Font Style: Plain /Font Size: 40 /Time consumed (us): 206.299 >> >>> -Font Style: Plain /Font Size: 60 /Time consumed (us): 249.941 >> >>> -Font Style: Plain /Font Size: 80 /Time consumed (us): 362.372 >> >>> -Font Style: Bold /Font Size: 20 /Time consumed (us): 145.096 >> >>> -Font Style: Bold /Font Size: 40 /Time consumed (us): 151.589 >> >>> -Font Style: Bold /Font Size: 60 /Time consumed (us): 240.972 >> >>> -Font Style: Bold /Font Size: 80 /Time consumed (us): 331.894 >> >>> -Font Style: Italic /Font Size: 20 /Time consumed (us): 95.028 >> >>> -Font Style: Italic /Font Size: 40 /Time consumed (us): 245.300 >> >>> -Font Style: Italic /Font Size: 60 /Time consumed (us): 270.379 >> >>> -Font Style: Italic /Font Size: 80 /Time consumed (us): 398.139 >> >>> -Font Style: Bold-Italic /Font Size: 20 /Time consumed (us): 93.243 >> >>> -Font Style: Bold-Italic /Font Size: 40 /Time consumed (us): >>> 475.406 >> >>> -Font Style: Bold-Italic /Font Size: 60 /Time consumed (us): >>> 280.085 >> >>> -Font Style: Bold-Italic /Font Size: 80 /Time consumed (us): >>> 357.486 >> >>> >> >>> Platform : Windows x86_64 Release Build Algorithm : Optimized. >> >>> webrev.03 >> >>> ````````````````````````````````````````````````````````````````````` >>> ` >> >>> ```` Executing Bench For Image Type: IntArgb >> >>> -Font Style: Plain /Font Size: 20 /Time consumed (us): 120.954 >> >>> -Font Style: Plain /Font Size: 40 /Time consumed (us): 364.871 >> >>> -Font Style: Plain /Font Size: 60 /Time consumed (us): 561.799 >> >>> -Font Style: Plain /Font Size: 80 /Time consumed (us): 653.390 >> >>> -Font Style: Bold /Font Size: 20 /Time consumed (us): 261.566 >> >>> -Font Style: Bold /Font Size: 40 /Time consumed (us): 311.054 >> >>> -Font Style: Bold /Font Size: 60 /Time consumed (us): 490.735 >> >>> -Font Style: Bold /Font Size: 80 /Time consumed (us): 656.559 >> >>> -Font Style: Italic /Font Size: 20 /Time consumed (us): 314.289 >> >>> -Font Style: Italic /Font Size: 40 /Time consumed (us): 378.750 >> >>> -Font Style: Italic /Font Size: 60 /Time consumed (us): 491.181 >> >>> -Font Style: Italic /Font Size: 80 /Time consumed (us): 770.172 >> >>> -Font Style: Bold-Italic /Font Size: 20 /Time consumed (us): >>> 375.336 >> >>> -Font Style: Bold-Italic /Font Size: 40 /Time consumed (us): >>> 571.371 >> >>> -Font Style: Bold-Italic /Font Size: 60 /Time consumed (us): >>> 548.300 >> >>> -Font Style: Bold-Italic /Font Size: 80 /Time consumed (us): >>> 714.526 >> >>> >> >>> Executing Bench For Image Type: IntArgb_Pre >> >>> -Font Style: Plain /Font Size: 20 /Time consumed (us): 45.026 >> >>> -Font Style: Plain /Font Size: 40 /Time consumed (us): 219.016 >> >>> -Font Style: Plain /Font Size: 60 /Time consumed (us): 279.617 >> >>> -Font Style: Plain /Font Size: 80 /Time consumed (us): 282.829 >> >>> -Font Style: Bold /Font Size: 20 /Time consumed (us): 51.809 >> >>> -Font Style: Bold /Font Size: 40 /Time consumed (us): 117.563 >> >>> -Font Style: Bold /Font Size: 60 /Time consumed (us): 508.049 >> >>> -Font Style: Bold /Font Size: 80 /Time consumed (us): 402.802 >> >>> -Font Style: Italic /Font Size: 20 /Time consumed (us): 79.320 >> >>> -Font Style: Italic /Font Size: 40 /Time consumed (us): 227.473 >> >>> -Font Style: Italic /Font Size: 60 /Time consumed (us): 330.488 >> >>> -Font Style: Italic /Font Size: 80 /Time consumed (us): 353.782 >> >>> -Font Style: Bold-Italic /Font Size: 20 /Time consumed (us): 54.687 >> >>> -Font Style: Bold-Italic /Font Size: 40 /Time consumed (us): >>> 235.505 >> >>> -Font Style: Bold-Italic /Font Size: 60 /Time consumed (us): >>> 227.205 >> >>> -Font Style: Bold-Italic /Font Size: 80 /Time consumed (us): >>> 324.308 >> >>> >> >>> Updated webrev with changes for the fast-path : >> >>> http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.03/ >> >>> Kindly review and provide your suggestions. >> >>> >> >>> Thank you once again for detailed review and feedback Have a good day >> >>> >> >>> Prahalad N. >> >>> >> >>> >> >>> >> >>> -----Original Message----- >> >>> From: Jim Graham >> >>> Sent: Wednesday, March 30, 2016 2:46 AM >> >>> To: Prahalad Kumar Narayanan;2d-dev at openjdk.java.net >>> ; Sergey Bylokhov >> >>> Subject: Re: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: >> >>> Antialiased text on translucent backgrounds gets bright artifacts >> >>> >> >>> Hi Prahalad, >> >>> >> >>> This latest version looks like it should produce correct answers. >> >>> >> >>> I'd like to see benchmark results on more platforms, particularly Windows since the different compilers may optimize these things differently. >> >>> >> >>> Also, you didn't mention what data set you used for benchmarking. >>> I'd >> >>> like to see benchmark results for small, medium and large font sizes, >> >>> and possibly bold and italic fonts as well. The reason is that the >> >>> relative ratios of "empty glyph pixels" to "partial glyph pixels" to >> >>> "fully covered glyph pixels" changes depending on the font type and >> >>> size so if you made one of those faster and another slower then the >> >>> results may be seen as a gain in one type of test if you only test >>> one >> >>> font type and size and it happens to match the part of the code that >> >>> is more streamlined. Also, for small font sizes the per-glyph >> >>> overhead might hide per-pixel issues. Please share which fonts and >> >>> sizes you used for testing and consider using some different sizes, >> >>> including something very large like 36 or 48 points (something with >> >>> large areas of opaque >> >>> pixels) as well as more normal sizes that appear in GUIs. Also, bold fonts can have a higher percentage of opaque pixels. >> >>> >> >>> In particular... >> >>> >> >>> This latest version is missing the "fast path" from the existing code for the case of srcA == 255 and glyphA == 255 where it just stores the FG_PIXEL values directly. For large fonts/glyphs that case may be as important as detecting empty glyph pixels. >> >>> >> >>> On the other hand, an additional "if" may cause the compiler to generate less efficient code as per Sergey's concern. Since this "if" eliminates some multiplies and possibly some divides, I'd hope it would be a win-win. >> >>> >> >>> You could add the fast path back inside the case where mixValSrc is 255 and just test srcA for 255 and do the Store ## DST ## PixelData() macro that used to be at the end of the block in the existing code, and then use "break;" to escape out of the do/while surrounding the whole macro so it moves on to the next pixel. >> >>> >> >>> (Arguably, we might want to consider teaching our SRCOVER_MASKFILL to >> >>> do the same thing. I think that was one of the added values of >>> having >> >>> a separate GLYPH loop, but really both should be optimizing that >> >>> case...) >> >>> >> >>> I can see now that the macro switch to use the same macro set as SRCOVER_MASKFILL required you to compute the pixel address, as you noted in your summary. It makes the new macro more cumbersome and makes it look like it's doing a bit more work per-pixel, but in reality I think the overall operations end up being the same as long as the compiler optimizes the deliberate multiplications the same way it did for implicit multiplications in the "pRas[foo]" and "pRas[foo*4]" code that was being generated previously. Benchmarks will tell us if we're good there... >> >>> >> >>> ...jim >> >>> >> >>> >> >>> On 3/28/16 5:33 AM, Prahalad Kumar Narayanan wrote: >> >>>> Hello Everyone on Java2D Group >> >>>> >> >>>> Good day to you. >> >>>> >> >>>> This is a follow-up to Review Request on bug: >> >>>> Bug : JDK-8015070 >> >>>> Bug Link :https://bugs.openjdk.java.net/browse/JDK-8015070 >> >>>> >> >>>> First, Thanks to Jim and Sergey for their feedback on the changes so far. >> >>>> >> >>>> Inferences from Jim 's Feedback on Loading destination colors: >> >>>> 1. The API or Macro that I had earlier used to Load DST colors, indeed, adjusted destination color components with divide-by-alpha if destination was already pre-multiplied. >> >>>> My apologies.. I should have spotted this error at the first iteration itself. >> >>>> 2. Due to the divide-by-alpha adjustment, the remaining logic >>>> would become incorrect. ( Especially, the multiplication with dstF >>>> based on pre-mulitplication status ) >> >>>> 3. Correct API is being used now, and the dstColor components are loaded directly without any divide-by-alpha adjustment. >> >>>> >> >>>> Inferences from Sergey's Feedback on Performance. >> >>>> 1. To set the context for everyone, the logic present in the current webrev.02 is modelled as per SRCOVER_MASKFILL. >> >>>> There are multiple if (...) conditions that remove un-necessary blending calculations. Ideally this should improve performance. >> >>>> However, since some data are not readily available (as present in SRCOVER_MASKFILL), few additional calculations have been added. >> >>>> They are: pre-multiplying srcColor with alpha and assigning to res. >> >>>> Finding the correct address of Pixel using DST_PTR and PixelStride. >> >>>> Henceforth, as Sergey suggests, Observation on performance will be beneficial. >> >>>> 2. The performance of the new logic was measured with >>>> linux-x86_64-normal-server-release config and compared with the >>>> logic used in un-optimized code in webrev.00 >> >>>> 3. Result: The newer logic provides a fractional gain (about 15 - 20 ms) over the older logic. >> >>>> >> >>>> Other Subtle Changes: >> >>>> 1. The test file has been renamed from >>>> AADrawStringArtifact.java to more meaningful - >>>> AntialiasedTextArtifact.java >> >>>> 2. The test file tests for both TYPE_INT_ARGB and TYPE_INT_ARGB_PRE BufferedImage formats. >> >>>> The code has been well commented to explain the logic used in every function. >> >>>> >> >>>> Kindly take your time to review the changes in the webrev link mentioned below and provide your suggestions. >> >>>> Webrev Link: >> >>>> http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.02/ >> >>>> >> >>>> >> >>>> Thank you for your time in review >> >>>> Have a good day >> >>>> >> >>>> Prahalad N. >> >>>> >> >>>> >> >>>> -----Original Message----- >> >>>> From: Jim Graham >> >>>> Sent: Thursday, March 24, 2016 7:57 AM >> >>>> To: Prahalad Kumar Narayanan;2d-dev at openjdk.java.net >>>> >> >>>> Subject: Re: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: >> >>>> Antialiased text on translucent backgrounds gets bright artifacts >> >>>> >> >>>> Hi Prahalad, >> >>>> >> >>>> (On a side note - ouch! I came up with these macros in the first >> >>>> place, but 20 years later I'm now realizing just how hard they are >>>> to >> >>>> navigate and review. My apologies...) >> >>>> >> >>>> The macro you are still using to load the destination data is one that loads it to non-premultiplied components, which means it will divide out the alpha if the destination is PRE. The rest of the logic assumes that the components were loaded without any adjustment of their premultiplication so not only is that division an unnecessary operation, it makes the following math wrong. >> >>>> >> >>>> The SRCOVER_MASKFILL macro seems to use "Postload ## STRATEGY ## From ## TYPE" which seems to load them into separate components without any adjustment of their pre-multiplication status. This is paired with "LoadAlphaFrom ## TYPE ## For ## STRATEGY" to load just the destination alpha for computing dstF... >> >>>> >> >>>> ...jim >> >>>> >> >>>> On 3/22/16 4:35 AM, Prahalad Kumar Narayanan wrote: >> >>>>> Hello Everyone on Java2D Group >> >>>>> >> >>>>> Good day to you. >> >>>>> >> >>>>> This is a Follow-up to Review Request on the bug: >> >>>>> Bug : JDK-8015070 Anti-aliased Text on Translucent background gets bright artifacts >> >>>>> Bug Link :https://bugs.openjdk.java.net/browse/JDK-8015070 >> >>>>> >> >>>>> First, Sincere thanks to Jim for his valuable feedback. >> >>>>> 1. As Jim correctly mentioned, SRCOVER_MASKFILL has a similar logic to blend two Translucent colors based on an Alpha mask. >> >>>>> 2. The calculations are exactly the same as the changes in previous webrev. >> >>>>> However the logic of SRCOVER_MASKFILL is 'Optimized' to reduce the number of computations. >> >>>>> 3. This optimization is definitely required because, the logic is executed for every single pixel in a glyph. >> >>>>> Example: If a string is made up of 5 English >>>>> characters with each character having 32 x 32 pixels, >> >>>>> The anti-aliasing logic will be executed for 5 x 32 x 32 iterations. >> >>>>> Reducing computation per pixel will imply a huge benefit for complete drawString operation. >> >>>>> >> >>>>> Observation from SRCOVER_MASKFILL >> >>>>> 1. The mask fill reduces computations by through multiple if(...) conditions. >> >>>>> Each if condition affirms whether the next set of computations are required. >> >>>>> 2. Optimization 1: If mask value is 0- skip entire logic. >> >>>>> 3. Optimization 2: If mask value is maximum, say 255, take >>>>> srcA directly without multiplying with maskAlpha ( Reason: 1 * >>>>> srcAlpha = srcAlpha ) >> >>>>> 4. Optimization 3: Compute pre-multiplied resColor in two steps. First with srcColor and then with dstColor. >> >>>>> If the resAlpha from 1st step (i.e., srcColor) is fully opaque, avoid blending dstColor altogether. >> >>>>> >> >>>>> Changes in Current Webrev.01 >> >>>>> 1. The fix for the current bug is modelled based on SRCOVER_MASKFILL. >> >>>>> 2. The changes have been verified to work on windows, linux and mac operating systems. >> >>>>> 3. The automated Test file- AADrawStringArtifact.java runs >>>>> as expected >> >>>>> Identifies artifact & throws exception when run on JDK 7 and 8. >> >>>>> With JDK9, the test file returns without error. >> >>>>> 3. JPRT build has been run to ensure, changes build on all supported platforms. >> >>>>> JPRT job link : >> >>>>> http://scaaa637.us.oracle.com//archive/2016/03/2016-03-22-070604.pra >> >> >>>>> h >> >>>>> n >> >>>>> ara-linux.client >> >>>>> >> >>>>> Kindly review the changes in the below mentioned link and provide >>>>> your views >> >>>>> Webrev Link : >> >>>>> http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.01/ >> >>>>> >> >>>>> >> >>>>> Thank you for your time in review >> >>>>> Have a good day >> >>>>> >> >>>>> Prahalad N. >> >>>>> >> >>>>> >> >>>>> -----Original Message----- >> >>>>> From: Jim Graham >> >>>>> Sent: Friday, March 18, 2016 6:07 AM >> >>>>> To: Prahalad Kumar Narayanan;2d-dev at openjdk.java.net >>>>> >> >>>>> Subject: Re: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: >> >>>>> Antialiased text on translucent backgrounds gets bright artifacts >> >>>>> >> >>>>> Hi Prahalad, >> >>>>> >> >>>>> This basically boils down to "alpha blending math needs to be performed in premultiplied form" and the existing code was not doing that. >> >>>>> >> >>>>> Your changes do add a pre-multiplication step to the math in two >> >>>>> places >> >>>>> - when you mix the src alpha and the glyph alpha at the top of the macro, and again when you do the Multiply(dst, dstA, dst) step in the middle. In that sense, the new math is correct. >> >>>>> >> >>>>> However, it is not the optimal way to implement this. In >> >>>>> particular, the macro used here to load the data from the >> >>>>> destination is the one that loads it into 4 ARGB non-premultiplied >> >>>>> values. If the destination is non-PRE, then your added multiply >> >>>>> step is exactly what is needed, but it could be combined with the >> >>>>> multiply that will happen later in the blending equation, so it is >> >>>>> an added step rather than a fixed fraction in the existing MultMultAdd parameters. >> >>>>> Additionally, if the destination is already PRE, then the macro >> >>>>> being used to load the dst pixel data there will have done a divide >> >>>>> step to divide out the alpha from the destination, only to have you >> >>>>> reverse that math with your new >> >>>>> Multiply() step. That's a lot of math to end up with a NOP. >> >>>>> >> >>>>> The MUL8 you added for the srcA and glyph value is needed, that change is good. Since it is common for glyph pixels to have zero alpha, you might want to test the glyph alpha for 0 and skip the pixel before you do the multiply, though. This would add one more if, but it would be a common case. >> >>>>> >> >>>>> The trickier part is to load the destination components without un-premultiplying them. Unfortunately there is no "Load...ToArgbPre" >> >>>>> macro to parallel the Load macro used in the function. Perhaps there should be, but you'd still end up with an extra multiply step as I mentioned above because you can fold the premultiplication of the dst data into the MultMultAdd by carefully choosing the parameters you use in the math there. >> >>>>> >> >>>>> The good news is that the way that the SRCOVER_MASKFILL uses the various type-specific macros works around this a bit and minimizes the number of multiplies that happen. You could check out DEFINE_SRCOVER_MASKFILL and see how it works in the case where pMask is not null (pMask is an alpha mask with values very similar to the glyphAA data). Modeling this code on that code would correct the math and minimize it as well... >> >>>>> >> >>>>> ...jim >> >>>>> >> >>>>> On 3/17/16 3:00 AM, Prahalad Kumar Narayanan wrote: >> >>>>>> Hello Everyone on Java2D Group >> >>>>>> >> >>>>>> Good day to you. >> >>>>>> >> >>>>>> Herewith, I 'm sharing the webrev for two identical Java2D Bugs. >> >>>>>> >> >>>>>> Bug ID : JDK-8015070 >> >>>>>> >> >>>>>> Title : Antialiased text on translucent backgrounds gets >> >>>>>> bright artifacts >> >>>>>> >> >>>>>> Link :https://bugs.openjdk.java.net/browse/JDK-8015070 >> >>>>>> >> >>>>>> Bug ID : JDK-8013564 ( currently closed as duplicate ) >> >>>>>> >> >>>>>> Title : Font rendering anti-aliasing in translucent >> >>>>>> BufferedImages broken >> >>>>>> >> >>>>>> Link :https://bugs.openjdk.java.net/browse/JDK-8013564 >> >>>>>> >> >>>>>> Webrev Link : >> >>>>>> http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.00/ >> >>>>>> >> >>>>>> Quick Summary on Bugs : >> >>>>>> >> >>>>>> ```````````````````````````````````````````````` >> >>>>>> >> >>>>>> 1. Artifacts appear on Edges of text characters when anti-aliased >> >>>>>> text is drawn on Translucent background >> >>>>>> >> >>>>>> 2. The issue is reproducible on all platforms - windows, linux and mac os. >> >>>>>> >> >>>>>> 3. Besides, the issue is reproduced with the commonly used pixel >> >>>>>> format- 4ByteArgb. >> >>>>>> >> >>>>>> Root Cause & Solution : >> >>>>>> >> >>>>>> ```````````````````````````````````````````````` >> >>>>>> >> >>>>>> 1. The Macro: GlyphListAABlend4ByteArgb in File: LoopMacros.h >>>>>> uses >> >>>>>> the standard blending algorithm >> >>>>>> >> >>>>>> dstColor = [ srcColor * glyphAlpha + dstColor * (1 - >> >>>>>> glyphAlpha) ] / dstAlpha >> >>>>>> >> >>>>>> 2. The above equation works only when the srcColor and dstColor are Opaque. >> >>>>>> >> >>>>>> 3. When srcColor and dstColor are Translucent, their >> >>>>>> alphaComponent will influence the visibility of the color, and >> >>>>>> visibility of the color below. >> >>>>>> >> >>>>>> 4. The new set of calculations for blending Translucent source >>>>>> and >> >>>>>> destination colors is given as >> >>>>>> >> >>>>>> resAlpha = 1 - ((1 - srcAlpha) * (1 - dstAlpha)) >> >>>>>> >> >>>>>> resColor = [ srcColor * srcAlpha + dstColor * dstAlpha >> >>>>>> * >> >>>>>> (1 >> >>>>>> - >> >>>>>> srcAlpha) ] / resAlpha >> >>>>>> >> >>>>>> 5. Reference text for the equation: >> >>>>>> https://en.wikipedia.org/wiki/Alpha_compositing >> >>>>>> >> >>>>>> 6. With the above modification to the blending logic, the >> >>>>>> artifacts do not appear and issues are fixed. >> >>>>>> >> >>>>>> Jtreg & Jprt Results : >> >>>>>> >> >>>>>> ```````````````````````````````````````````````` >> >>>>>> >> >>>>>> 1. A simple test-file: AADrawStringArtifact.java has been created >> >>>>>> to be a part of jtreg test cases. >> >>>>>> >> >>>>>> The test file is well commented to explain - nature >>>>>> of >> >>>>>> artifact and how the test tries to identify them. >> >>>>>> >> >>>>>> As required, the test case fails with Jdk 7, Jdk 8 >>>>>> and >> >>>>>> succeeds with Jdk 9-internal (built with changes for the bug fix) >> >>>>>> >> >>>>>> 2. The changes to blending logic lies within >> >>>>>> java.desktop/src/share/native/... >> >>>>>> >> >>>>>> Henceforth, JPRT was used to ensure successful build >> >>>>>> across all supported platforms >> >>>>>> >> >>>>>> Jprt Job Link : >> >>>>>> http://scaaa637.us.oracle.com//archive/2016/03/2016-03-17-072001.pr >> >> >>>>>> a >> >>>>>> h >> >>>>>> n >> >>>>>> ara-linux.client >> >>>>>> >> >>>>>> The build succeeds on all platforms. >> >>>>>> >> >>>>>> Kindly review the webrev link and provide your views and suggestions. >> >>>>>> >> >>>>>> Webrev Link : >> >>>>>> http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.00/ >> >>>>>> >> >>>>>> If the changes look good, we could take up the changes for source checkin. >> >>>>>> >> >>>>>> Thank you for your time in review >> >>>>>> >> >>>>>> Have a good day >> >>>>>> >> >>>>>> Prahalad N. >> >>>>>> >> From james.graham at oracle.com Tue Apr 26 22:08:01 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 26 Apr 2016 15:08:01 -0700 Subject: [OpenJDK 2D-Dev] [9] Review request for 8152309 Seamless way of using image filters with multi-resolution images In-Reply-To: <5703CBE9.8030800@oracle.com> References: <5703CBE9.8030800@oracle.com> Message-ID: This all snowballed pretty far and wide. The original fix to Swing icons was trivial in comparison. In retrospect it might be better to simply offer the helper method from the original bug fix as a Toolkit solution and force applications to adopt it when dealing with MR sources: http://cr.openjdk.java.net/~alexsch/8151303/webrev.00/ We can revisit this solution in the future if we get a lot of push from the community, but it seems like a lot of complications to add to the code for this small set of use cases... ...jim On 4/5/16 7:30 AM, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8152309 > webrev: http://cr.openjdk.java.net/~alexsch/8152309/webrev.00 > > > The purpose of the fix is to allow to apply an image filter for a > multi-resolution image to get new multi-resolution image so the code > below works without changes: > ---------- > Image mrImage = getMultiResolutionImage(); > ImageProducer mriProducer = new > FilteredImageSource(mrImage.getSource(), new CropImageFilter(x, y, w, h)); > Image filteredMRImage = > Toolkit.getDefaultToolkit().createImage(mriProducer); > ---------- > > > The Image producer needs to be updated to contain a set of > resolution-variant image producers. It can be done introducing a new > MultiResolution[Image]Producer interface. However, the > FilteredImageSource which takes an original image producer as a > constructor argument needs to be declared as > MultiResolution[Image]Producer even for ordinary image producers. > I chose to add the getRVProducers() method directly to the ImageProducer > interface. > > The option to add a method which request a resolution variant producer > for the given image size (getRVProducer(width, height) ) seems is not > possible because the result multi-resolution image can be loaded by a > MediaTracker which can load only finite number of resolution variants. > > Applying an image filter to resolution-variant producers requires to > scale filters which use fixed image size (like CropImageFilter and > ReplicateScaleFilter). > There should be a way to get a scaled filter using the original one. The > resolution variant image producer need to provide necessary scale > factors for the used filter. > To do that getScaledFilterInstance(scaleX, scaleY) method is added to > the ImageFilter and public ResolutionVariantItem class which can hold > image or image producer with associated scale factors is introduced. > > There is an interesting problem in SunGraphics2D where a > multi-resolution image size is requested. To do that it is necessary to > have an image observer which needs to redirect calls to the base image > observer. The resolution variant observer needs to know scale factors to > recalculate given [x, y, width, height] values. The scale factors are > provided by toolkit multi-resolution image but for non toolkit > multi-resolution images they need to be calculated dividing a rv-image > size to base image size. It looks like a closed loop when to know scale > factors it needs to get a rv-image size but for this it is necessary to > use an image observer which requires scale factors. > The current fix just divides rv-image size to base image size for non > toolkit multi-resolution images to get scale factors . > > Thanks, > Alexandr. > From james.graham at oracle.com Tue Apr 26 22:53:57 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 26 Apr 2016 15:53:57 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: equals() method in IndexColorModel doesnt exist and it relies on ColorModel.equals() which is not strict In-Reply-To: <94c3a958-d927-4b42-89f0-d0c44d4d19ab@default> References: <57057CF0.50604@oracle.com> <5706ADBE.10803@oracle.com> <570BF21F.9010603@oracle.com> <34a9ed1b-bf8a-43fb-9032-65c9c47a9c11@default> <570D5043.8000405@oracle.com> <570D5387.2070303@oracle.com> <570D5839.3000402@oracle.com> <570D5822.40705@oracle.com> <570EB999.7090408@oracle.com> <94c3a958-d927-4b42-89f0-d0c44d4d19ab@default> Message-ID: This version of the ICM.equals() method starts with casting the unkown obj to ICM, which may throw a cast exception. That cast needs to be moved down after the call to super.equals() ("this == cm" can just be "this == obj"). In the ICM hashcode function, is there a reason that the hash variable isn't just initialized to super.hashCode() rather than starting with 7 and doing a multiply-add to incorporate the super hashcode? ...jim On 4/25/16 1:26 AM, Jayathirth D V wrote: > Hi, > > Based on Joe's and Jim's suggestion I have made changes to include check for getClass() in baseclass and use super.equals() from subclasses to verify class equality. > Please find updated webrev for review : > http://cr.openjdk.java.net/~jdv/7107905/webrev.05/ > > For JDK-8153943 I will make relevant changes in its subclasses and sent review in its thread. > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Thursday, April 14, 2016 2:57 AM > To: Jayathirth D V; Philip Race > Cc: 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: equals() method in IndexColorModel doesnt exist and it relies on ColorModel.equals() which is not strict > > Looks good. The only thing left is the CCC... > > ...jim > > On 4/13/16 1:33 AM, Jayathirth D V wrote: >> Hi, >> >> Thanks Phil & Jim for your suggestion. >> I have made changes mentioned by Jim for whether we have validate individual bits of validBits or not in different conditions. >> Please find updated webrev for review : >> http://cr.openjdk.java.net/~jdv/7107905/webrev.04/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Phil Race >> Sent: Wednesday, April 13, 2016 1:49 AM >> To: Jim Graham >> Cc: Jayathirth D V; Prasanta Sadhukhan; 2d-dev at openjdk.java.net >> Subject: Re: Review Request for JDK-7107905: equals() method in >> IndexColorModel doesnt exist and it relies on ColorModel.equals() >> which is not strict >> >> Seems like this would work/help. >> >> -phil. >> >> On 04/12/2016 01:19 PM, Jim Graham wrote: >>> >>> >>> On 4/12/2016 12:59 PM, Phil Race wrote: >>>> I am catching up on email here, and "+1" but a couple of comments >>>> >>>> - I suppose that we can't learn anything useful from >>>> "cm.validbits.equals(this.validbits)" >>>> since only the bits up to "map_size" should be tested ? >>> >>> Perhaps if the constructors truncated it at the required size we >>> could use equals(). I'm not sure that is worthwhile, given how >>> rarely it is used. I think it is used by default on some platforms (Windows? >>> X11?) if they have an 8-bit screen with a sparse colormap, but that >>> should be pretty rare these days since nearly everything we use >>> should be 24-bits these days. >>> >>> I have a better idea, though. >>> >>> But, since the field is assigned the original supplied value from the >>> constructor, then the likelihood that a non-null value will be == >>> identical to another colormap is likely larger than normal, perhaps >>> we can make it faster by checking for == and then slipping into the >>> faster test that simply compares the rgb[] values? Something like: >>> >>> if (validBits == cm.validBits) { >>> compare rgb[] entries >>> } else if (validBits == null || cm.validBits == null) { >>> return false; >>> } else { >>> bigger loop that compares rgb[] and validBits() values } >>> >>> Note that if the two fields are == and non-null, then the entries in >>> the rgb[] array for indices that are non-valid should have zeros in >>> them because of the way that the colormap data is copied internally, >>> so the rgb[] comparisons should be valid without checking the >>> associated bits. >>> >>> Potentially we could also use: >>> >>> boolean fulltest; >>> if (validBits == cm.validBits) { >>> fulltest = false; >>> } else if (validBits == null || cm.validBits == null) { >>> return false; >>> } else if (validBits.equals(cm.validBits)) { >>> fulltest = false; >>> } else { >>> fulltest = true; >>> } >>> >>> if (fulltest) { >>> compare both rgb[] and validBits() values } else { >>> compare rgb[] entries alone >>> } >>> >>> In this case we are using validBits.equals() to reduce the amount of >>> testing in the loop, but are not basing a conclusion on whether the >>> result of the comparison will be true or false. equals() implies we >>> don't need to compare its values bit by bit, but !equals() doesn't >>> mean that the ICMs aren't equals()... >>> >>> ...jim >> From james.graham at oracle.com Tue Apr 26 23:04:26 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 26 Apr 2016 16:04:26 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8153943 : In java.awt.image package some of the classes are missing hashCode() or equals() method In-Reply-To: <571E3C66.6080807@oracle.com> References: <5717B9B3.3090807@oracle.com> <412b6974-cf58-79ea-5544-f2f5e8b9b5dd@oracle.com> <571E3C66.6080807@oracle.com> Message-ID: On 4/25/16 8:48 AM, Sergey Bylokhov wrote: > On 23.04.16 4:59, Jim Graham wrote: >> So, I'd recommend that CM.equals() tests getClass() == getClass() at the >> base level and then all others will use super.equals() and get the same >> protection. It means you can't have a subclass of CCM be "equals" to a >> different subclass of CCM, but that's an unfortunate issue with equals >> needing to honor symmetry... :( > > Small note. In this case the custom classes which do not provide the new > state, cannot compares to parent class because of "class==class" check. > I guess this is behavior change, but I am not sure should we document > that or not. I don't believe that we have any more than single-level inheritance with CM objects, but just in case there are custom subclasses of these objects we should probably mention it. It probably couldn't hurt to document it in the doc comments for the equals() classes and mention it in the CCC requests. I'd suggest something like: * Because there are multiple subclasses of ColorModel that might * be compared against each other with this method, and in order * to protect the symmetry property of * {@code (a.equals(b) == b.equals(a))}, * the target object must be the exact same class as this * object to evaluate as {equals}. ...jim From james.graham at oracle.com Tue Apr 26 23:10:09 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 26 Apr 2016 16:10:09 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8153943 : In java.awt.image package some of the classes are missing hashCode() or equals() method In-Reply-To: <102c8c05-d432-4a7f-b664-72e733493f55@default> References: <5717B9B3.3090807@oracle.com> <412b6974-cf58-79ea-5544-f2f5e8b9b5dd@oracle.com> <102c8c05-d432-4a7f-b664-72e733493f55@default> Message-ID: <16a0421e-33fd-1d1d-0b17-374efef5b71a@oracle.com> The ComponentColorModel implementation is a meaningless wrapper around super.equals/hashCode(). Why does it not test CCM-specific fields? The ComponentSampleModel.hashCode() method should be upgraded based on the recommendations in Effective Java like the other methods here. PixelInterleavedSampleModel and BandedSampleModel also have a meaningless override of super.equals/hashCode(). And all of these classes suffer from casting to the specific type before verifying its class as I mentioned in the ICM.equals() review... ...jim On 4/25/16 2:31 AM, Jayathirth D V wrote: > Hi Jim, > > I have made changes to include check for class equality in base class and use super.equals() from subclasses. > Please find updated webrev for review : > http://cr.openjdk.java.net/~jdv/8153943/webrev.02/ > > Change related to ColorModel is present in JDK-7107905 review. > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Saturday, April 23, 2016 7:30 AM > To: Phil Race; Jayathirth D V > Cc: 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8153943 : In java.awt.image package some of the classes are missing hashCode() or equals() method > > This is actually a pretty nasty issue that Joe Darcy also brought up in the CCC review. > > In order to have symmetric testing of .equals(), we pretty much have to enforce this test at all levels, including in the original > ColorModels.equals() method. If we don't enforce this in CM.equals(), then we could run ccm.equals(othercm) and it would return false because the class is wrong, but turning it around and testing > othercm.equals(ccm) would succeed because it doesn't enforce the class equality. > > So, I'd recommend that CM.equals() tests getClass() == getClass() at the base level and then all others will use super.equals() and get the same protection. It means you can't have a subclass of CCM be "equals" to a different subclass of CCM, but that's an unfortunate issue with equals needing to honor symmetry... :( > > ...jim > > On 4/20/2016 10:17 AM, Phil Race wrote: >> Hi, You removed the following test in CCM.java : 2941 if >> (obj.getClass() != getClass()) { >> 2942 return false; >> >> 2943 } >> >> What this means is that before your change an instance of a subclass >> of CCM would never be equals() to any direct instantiatation of CCM >> but after your change it can be. I suspect the condition was there on purpose. >> >> -phil. >> >> On 04/20/2016 05:45 AM, Jayathirth D V wrote: >>> >>> Hi, >>> >>> >>> >>> _Please review the following fix in JDK9:_ >>> >>> >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8153943 >>> >>> >>> >>> This is subtask of https://bugs.openjdk.java.net/browse/JDK-6588409 >>> >>> >>> >>> Webrev : http://cr.openjdk.java.net/~jdv/8153943/webrev.00/ >>> >>> >>> >>> >>> Issue : Some of the java.awt.image classes are missing either >>> equals() or hashCode() method. >>> >>> >>> >>> Solution : Add missing equals() or hashCode() methods. >>> >>> >>> >>> Thanks, >>> >>> Jay >>> >>> >>> >> From prahalad.kumar.narayanan at oracle.com Wed Apr 27 13:37:43 2016 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Wed, 27 Apr 2016 06:37:43 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: Antialiased text on translucent backgrounds gets bright artifacts In-Reply-To: <2b1d0a70-0ab3-ca34-92f0-447a435f72a3@oracle.com> References: <63d69ba8-d5cf-4697-bb5c-f51aaaa8c427@default> <56EB4DBB.9080802@oracle.com> <56F3505B.2070101@oracle.com> <215e497a-db82-4f6f-99e9-bd44f25d5999@default> <56FAF088.70300@oracle.com> <6b400fd0-a335-46a5-9fed-abb06c3fd6a0@default> <56FC33F6.1060108@oracle.com> <5702DE6F.5000903@oracle.com> <4213d5c2-3711-4631-87a3-ba40c1e5ceeb@default> <2b1d0a70-0ab3-ca34-92f0-447a435f72a3@oracle.com> Message-ID: <5bba3046-40d3-471b-8457-93cb637aaf1c@default> Dear Jim and Everyone on Java2D Community Good day to you. First, Thanks to Jim for his feedback. I 've incorporated his feedback in latest version of code and webrev link is shared below Webrev Link: http://cr.openjdk.java.net/~aghaisas/prahalad/8015070/webrev.05/ Quick Description on Changes : 1. Removing redundant code MultiplyAndStore4ByteArgbComps(res, resA, SRC_PREFIX) The redundant code within if and else blocks of if ( mixValSrc != 0xff ) has been moved into block that does color blending. As Jim rightly said, the change would execute Multiply operation only if blending is required On the other hand, If resA reaches maximum value, the fast path is executed. 2. Fast path execution The fast path that directly sets foreground color has been moved into else block after checking if ( resA != MaxValFor4ByteArgb ) Conceptually, resA would be maximum only when glyphAlpha (mixValSrc) and srcAlpha are maximum. 3. Isolated Declare and Store macros. A single macro DeclareAndInit... has been split into two macros Declare ## DST ## SrcOverDstBlendFactor and Store ## DST ## SrcOverDstBlendFactor. This would indeed address some compilers that do not allow declaration in the middle of the block. 4. Other Relevant Information: The changes have been verified to build on all platforms through JPRT auto build system. Java2D benchmarks were run with the changes and no degradation on performance was seen compared to webrev.04 Regression was run and no new regression failures have been introduced with the change. 5. To reduce reviewer 's effort in review, code has been expanded with comments herewith. #define GlyphListAABlend4ByteArgb(DST, GLYPH_PIXELS, PIXEL_INDEX, DST_PTR, \ FG_PIXEL, PREFIX, SRC_PREFIX) \ do { \ DeclareAlphaVarFor4ByteArgb(resA) \ DeclareCompVarsFor4ByteArgb(res) \ jint mixValSrc = GLYPH_PIXELS[PIXEL_INDEX]; \ if (mixValSrc) { \ /* Evaluating srcAlpha component */ \ if (mixValSrc != 0xff) { \ /* No-op. Retained to match reference as SRCOVER_MASK_FILL */ \ PromoteByteAlphaFor4ByteArgb(mixValSrc); \ /* Glyph mask determines visibility of the srcColor */ \ resA = MultiplyAlphaFor4ByteArgb(mixValSrc, SRC_PREFIX ## A); \ } else { \ /* This is understood easier with floating point logic. */ \ /* 1.0f is max value used in floating point calculation */ \ /* (1.0f * srcA) gives srcA. Hence we directly consider */ \ /* srcA without Multiply with glyph mask. */ \ resA = SRC_PREFIX ## A; \ } \ /* Blending srcColor and dstColor */ \ /* This is required only when resA(i.e., srcA) is not maximum */ \ if (resA != MaxValFor4ByteArgb) { \ DeclareAndInvertAlphaVarFor4ByteArgb(dstF, resA) \ DeclareAndClearAlphaVarFor4ByteArgb(dstA) \ DeclareCompVarsFor4ByteArgb(dst) \ DeclareCompVarsFor4ByteArgb(tmp) \ /* Redundant statement moved from previous if -else block */ \ MultiplyAndStore4ByteArgbComps(res, resA, SRC_PREFIX); \ /* Based on the pixelFormat we could reduce calculations */ \ /* done to load the color and alpha components */ \ if (!(DST ## IsPremultiplied)) { \ Load ## DST ## To4ByteArgb(DST_PTR, pix, PIXEL_INDEX, \ dstA, dstR, dstG, dstB); \ Store4ByteArgbCompsUsingOp(tmp, =, dst); \ } else { \ Declare ## DST ## AlphaLoadData(DstPix) \ jint pixelOffset = PIXEL_INDEX * (DST ## PixelStride); \ DST ## DataType *pixelAddress = PtrAddBytes(DST_PTR, \ pixelOffset); \ /* The macro's implementation loads color components */ \ /* without divide by alpha adjustment as required for */ \ /* subsequent calculations. Note: This is used only */ \ /* with preMultiplied alpha based pixel formats */ \ LoadAlphaFrom ## DST ## For4ByteArgb(pixelAddress, \ DstPix, \ dst); \ Postload4ByteArgbFrom ## DST(pixelAddress, \ DstPix, \ tmp); \ } \ /* Avoid blending operatons if dst is fully transparent */ \ if (dstA) { \ Declare ## DST ## SrcOverDstBlendFactor(blendF) \ /* dstA would be 0 if either of the following is true. */ \ /* 1. srcA is max. Parent if condition validates this. */ \ /* 2. dstA is zero. The current if condition validates */ \ /* Henceforth, the following Multiply need not be moved */ \ /* ahead of the if condition. This also helps to better */ \ /* performance */ \ dstA = MultiplyAlphaFor4ByteArgb(dstF, dstA); \ resA += dstA; \ /* Declares blendF variable and assigns appropriate */ \ /* alpha value. The definitions are contained in the*/ \ /* header files of respective pixel formats */ \ blendF = Store ## DST ## SrcOverDstBlendFactor(dstF, \ dstA); \ /* This is understood easier with floating point logic.*/ \ /* 1.0f is max value used in floating point calculation*/ \ /* (1.0f * tmp) gives tmp. Hence we avoid Multiply */ \ /* operation and directly add loaded color to result*/ \ if (blendF != MaxValFor4ByteArgb) { \ MultiplyAndStore4ByteArgbComps(tmp, \ blendF, \ tmp); \ } \ Store4ByteArgbCompsUsingOp(res, +=, tmp); \ } \ } else { \ /* resA is maximum only when srcA and glyphAlpha are max */ \ /* Hence the fast path to store foreground pixel color and */ \ /* break to the next pixel. */ \ Store ## DST ## PixelData(DST_PTR, PIXEL_INDEX, \ FG_PIXEL, PREFIX); \ break; \ } \ /* In the above calculations, color values are multiplied with */ \ /* with alpha. This is perfectly fine for pre-Multiplied alpha */ \ /* based pixel formats. For non pre-multiplied alpha based */ \ /* pixel formats, the alpha is removed from color components */ \ /* and then stored to the resulting color */ \ if (!(DST ## IsOpaque) && \ !(DST ## IsPremultiplied) && resA && \ resA < MaxValFor4ByteArgb) \ { \ DivideAndStore4ByteArgbComps(res, res, resA); \ } \ Store ## DST ## From4ByteArgbComps(DST_PTR, pix, \ PIXEL_INDEX, res); \ } \ } while (0); Kindly review the changes present in the webrev and provide your views. Thank you once again for your effort in review Have a great day Prahalad N. -----Original Message----- From: Jim Graham Sent: Wednesday, April 27, 2016 2:12 AM To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: Antialiased text on translucent backgrounds gets bright artifacts Hi Prahalad, One potential portability issue - you have a "DeclareAndInit" macro for the new "choose which blend factor" macro in the middle of a block. Some C compilers allow declaring a new variable in the middle of a block, but not all. Since it would be hard to move the declaration to the top of the block, since it depends on a value computed in the first couple of lines, it might be better to change it from a "DeclareAndInit" style macro into a regular declaration, and a macro to get the value, so "jint blendF;" at the top of the block and "blendF = SrcOverDstBlendFactorFor ## DST(...);" in the middle of the block. (Or name it "SrcOver ## DST ## BlendFactor(...)?" I just noticed something about this .04 version of the function. At the top you have a test for mixValSrc != 255 and then both clauses of the if statement end with essentially the same code, multiplying the source by the value in resA. (The version in the else clause uses SRC_PREFIX ## A, but it could just as easily also use resA since they are the same value at that point.) This means you could potentially move both "MultiplyAndStore" macros until after the if and use resA as the multiplier. Now, if you look, the immediate next statement tests if resA is maxVal. If it is maxVal, then you don't need to do that multiply at all, so the macro could be moved even further to be inside the "if (resA != maxVal)" block. At that point, you could then reinstate the "else" on that if block and move the Store##DST##PixelData into that else, to save you another test of resA. This would essentially look like this: if (mixValSrc != 255) { PromoteByteAlpha...; resA = MultiplyAlpha...; } else { resA = SRC_PREFIX ## A; } if (resA != MaxVal) { Declare,declare,declare,declare...; Multiply...Comps(res, resA, SRC_PREFIX); } else { Store ## DST ## PixelData...; } It shortens the code a little, but I'm not sure if it would really help performance other than not having to do the test for maxVal twice. Still, tests are fairly expensive in code like this so it could be worth a shot at testing, and it would simplify the code a bit in either case... ...jim On 4/15/16 12:25 AM, Prahalad Kumar Narayanan wrote: > Hello Jim & Everyone on Java2D Community > > Good day to you. > > This is a review request and a follow-up to the bug-fix for the issue > Bug : JDK-8015070 > Link : https://bugs.openjdk.java.net/browse/JDK-8015070 > > Webrev Link : > http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.04/ > > Quick Inferences on Changes in Current -Webrev.04 > > 1 ) Subtle changes to the blend loop- > . The subtle changes taken up, have helped to improve the performance. > . With the current logic in webrev.04, Java2DBench reports better performance than Un-Optimized solution that was present in webrev.00 > . J2DBench was run for Font Styles { Plain, Bold, Italic, Bold n Italic } and Font Sizes { 12, 20, 36, 72 } > . My sincere thanks to Jim for all his detailed feedback through the multiple reviews that has evolved the solution today. > > (Details on changes) > 1.a. Loading of Color components > . When modelled as per SRCOVER_MASK_FILL code, the logic required few additional calculations to load color components. > . The extra calculations indeed impacted performance figures. > . This could be offset in two possible ways > a. Inspect parent macro- NAME_SOLID_DRAWGLYPHLISTAA and advance by pixel address and not by pixel index. > The parent macro invokes GlyphListAABlendFourByteArgb through this macro- GlyphListAABlend ## STRATEGY(DST, pixels, x, pPix, fgpixel, solidpix, src); > Changing parent macro will cause spurious changes across GlyphListAABlend ## other pixel formats. > There is additional risk of breaking the stable and well optimized LoopMacros.h. > b. Load color components based on pre-Multiplication status > This has been taken up and change is limited to the function being modified. > Thankfully J2DBench has still reported improvement in performance. > > 1.b. New Macro to avoid if (DST ## IsPremultiplied) { > . A new macro- DeclareAndInit ## DST ## SrcOverMaskBlendFactor has been introduced to choose between dstF, or dstA > . The implementation is available in the header files of pixel formats ( Eg: IntArgb.h IntArgbPre.h ) > . There are 29 different pixel formats known to Java2D, and > . Hence, the new macro's implementation is added only to those pixel formats that require the current glyph blending logic. > > 2 ) Testing across different formats > . The Regression test code has been modified to test anti-aliased text rendering on 7 different pixel formats- > . IntArgb, IntArgb_Pre, FourByteAbgr, FourByteAbgr_Pre, IntRGB, IntBGR, 3ByteBGR. > . As expected, the test fails without the fix on JDK 8 and JDK 7 versions & passes with JDK 9-internal containing the fix. > > 3 ) Explanation on Code Changes : > . With multiple reviews and changes, today the code fixes the bug and is well optimized as well. > . For ease of reviewer and effort in review, I 've explained the logic with /* comment statements */ herewith. > . Note: These comments don't figure in the webrev. > As one cannot guarantee how /* comments */ within macros would be perceived by compiler across different platforms. > > #define GlyphListAABlend4ByteArgb(DST, GLYPH_PIXELS, PIXEL_INDEX, DST_PTR, \ > FG_PIXEL, PREFIX, SRC_PREFIX) \ > do { \ > DeclareAlphaVarFor4ByteArgb(resA) \ > DeclareCompVarsFor4ByteArgb(res) \ > jint mixValSrc = GLYPH_PIXELS[PIXEL_INDEX]; \ > if (mixValSrc) { \ > /* Evaluating srcColor components */ \ > if (mixValSrc != 0xff) { \ > /* No-op. Retained to match reference as SRCOVER_MASK_FILL */ \ > PromoteByteAlphaFor4ByteArgb(mixValSrc); \ > /* Glyph mask determines visibility of the srcColor */ \ > resA = MultiplyAlphaFor4ByteArgb(mixValSrc, SRC_PREFIX ## A); \ > MultiplyAndStore4ByteArgbComps(res, resA, SRC_PREFIX); \ > } else { \ > /* If mixValSrc and srcA are maximum, then result color is */ \ > /* opaque. Hence the fast path to store foreground pixel */ \ > /* color and return. */ \ > if (SRC_PREFIX ## A == MaxValFor4ByteArgb) { \ > Store ## DST ## PixelData(DST_PTR, PIXEL_INDEX, \ > FG_PIXEL, PREFIX); \ > break; \ > } \ > /* This is understood easier with floating point logic. */ \ > /* 1.0f is max value used in floating point calculation */ \ > /* (1.0f * srcA) gives srcA. Hence we directly consider */ \ > /* srcA without Multiply with glyph mask. */ \ > resA = SRC_PREFIX ## A; \ > MultiplyAndStore4ByteArgbComps(res, \ > SRC_PREFIX ## A, \ > SRC_PREFIX); \ > } \ > /* Evaluating dstColor components */ \ > /* This is required only when resA(i.e., srcA) is not maximum */ \ > if (resA != MaxValFor4ByteArgb) { \ > DeclareAndInvertAlphaVarFor4ByteArgb(dstF, resA) \ > DeclareAndClearAlphaVarFor4ByteArgb(dstA) \ > DeclareCompVarsFor4ByteArgb(dst) \ > DeclareCompVarsFor4ByteArgb(tmp) \ > /* Based on the pixelFormat we could reduce calculations */ \ > /* done to load the color and alpha components */ \ > if (!(DST ## IsPremultiplied)) { \ > Load ## DST ## To4ByteArgb(DST_PTR, pix, PIXEL_INDEX, \ > dstA, dstR, dstG, dstB); \ > Store4ByteArgbCompsUsingOp(tmp, =, dst); \ > } else { \ > Declare ## DST ## AlphaLoadData(DstPix) \ > jint pixelOffset = PIXEL_INDEX * (DST ## PixelStride); \ > DST ## DataType *pixelAddress = PtrAddBytes(DST_PTR, \ > pixelOffset); \ > /* The macro's implementation loads color components */ \ > /* without divide by alpha adjustment as required for */ \ > /* subsequent calculations. Note: This is used only */ \ > /* with preMultiplied alpha based pixel formats */ \ > LoadAlphaFrom ## DST ## For4ByteArgb(pixelAddress, \ > DstPix, \ > dst); \ > Postload4ByteArgbFrom ## DST(pixelAddress, \ > DstPix, \ > tmp); \ > } \ > /* Avoid blending operatons if dst is fully transparent */ \ > if (dstA) { \ > /* dstA would be 0 if either of the following is true. */ \ > /* 1. srcA is max. Parent if condition validates this. */ \ > /* 2. dstA is zero. The current if condition validates */ \ > /* Henceforth, the following Multiply need not be moved*/ \ > /* ahead of the if condition. This also helps to better*/ \ > /* performance */ \ > dstA = MultiplyAlphaFor4ByteArgb(dstF, dstA); \ > resA += dstA; \ > /* Declares blendF variable and assigns appropriate */ \ > /* alpha value. The definitions are contained in the*/ \ > /* header files of respective pixel formats */ \ > DeclareAndInit ## DST ## SrcOverDstBlendFactor(dstF, \ > dstA, \ > blendF); \ > /* This is understood easier with floating point logic.*/ \ > /* 1.0f is max value used in floating point calculation*/ \ > /* (1.0f * tmp) gives tmp. Hence we avoid 3 Multiply */ \ > /* operations and add the loaded color to result */ \ > if (blendF != MaxValFor4ByteArgb) { \ > MultiplyAndStore4ByteArgbComps(tmp, \ > blendF, \ > tmp); \ > } \ > Store4ByteArgbCompsUsingOp(res, +=, tmp); \ > } \ > } \ > /* In the above calculations, color values are multiplied with */ \ > /* with alpha. This is perfectly fine for pre-Multiplied alpha */ \ > /* based pixel formats. For non pre-multiplied alpha based */ \ > /* pixel formats, the alpha is removed from color components */ \ > /* and then stored to the resulting color. */ \ > if (!(DST ## IsOpaque) && \ > !(DST ## IsPremultiplied) && resA && \ > resA < MaxValFor4ByteArgb) \ > { \ > DivideAndStore4ByteArgbComps(res, res, resA); \ > } \ > Store ## DST ## From4ByteArgbComps(DST_PTR, pix, \ > PIXEL_INDEX, res); \ > } \ > } while (0); > > My apologies if the above code did not appear on the final webrev email. > ( In few instances, the newlines don't appear in plain-text format ) > > Kindly review the changes present in webrev and provide your views. > If the changes are good, we could take up for the code check-in. > > Thank you for your time in review > Have a good day > > Prahalad N. > > > > -----Original Message----- > From: Jim Graham > Sent: Tuesday, April 05, 2016 3:07 AM > To: Prahalad Kumar Narayanan; Sergey Bylokhov; Philip Race > Cc: Praveen Srivastava > Subject: Re: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: > Antialiased text on translucent backgrounds gets bright artifacts > > Hi Prahalad, > > Can I see the webrev diffs for the "today's experiment" code with the new macro? > > Also, Did you test this with opaque destinations? The most common use > of text is on an opaque destination, so that would matter more. I > would > suggest: INT_RGB, THREE_BYTE_BGR, INT_ARGB, INT_ARGB_PRE in that order of precedence of importance. Also, test with translucent colors, though those are less important than opaque colors. > > I'm still looking at why the non-pre would be slower than the pre. > About the only difference is the one line "if (!PRE) { DSTF = DSTA; }". > One suggestion might be to move the test for transparent destination up a couple of lines, and to get rid of the extra "DSTF = dstA" > assignement with the following structure: > > dstA = Mult...(); > if (dstA) { > resA += dstA; > Declare... > Postload... > if (DST ## IsPremultiplied) { > MultiplyAndStore(..., DSTF, ...); > } else { > MultiplyAndStore(..., dstA, ...); > } > Store... > } > > Basically, dstA == 0 is the actual test for "do we need to even try to blend the destination in here". If it is zero then there is no need to add dstA to resA and there is no need to adjust the factor we blend by (MultiplyAndStore). It can be triggered by either a transparent destination pixel or an opaque source pixel, but either way, dstA is the right test, not DSTF. The second part, eliminating the DSTF=dstA assignment, gets rid of a line that might trip up the optimizer by simply having the macro expand differently for the two types. To be even more streamlined, we could create a new set of macros: > > // In the header files for PRE types: > #define SRCOVER_DST_BLEND_FACTOR_(dF, dA) (dF) > // In the header files for non-PRE types: > #define SRCOVER_DST_BLEND_FACTOR_(dF, dA) (dA) > > Then we wouldn't need the test above for "if (DST ## Pre)", we would just expand the macro with: > MultiplyAndStore(..., SRCOVER_DST_BLEND_FACTOR ## DST(DSTF, dstA), ...) which would hopefully confuse the optimizer even less. > > If you want to really eliminate the pixel address computations, you could rewrite the calling loop so that it steps along a pixel pointer rather than using indexing. Have the calling function/macro set up a pRas pointer to the pixel and step that along the row by TYPE##PixelStride as it iterates across the glyph, then hand that into the Glyph blend macro as DST_PTR (and eliminate PIXEL_INDEX as it would be "0" in this case)... > > ...jim > > On 4/4/16 4:37 AM, Prahalad Kumar Narayanan wrote: >> Dear Jim >> >> Good day to you. >> >> ( Just in-case, you had missed my long Friday 's email ) >> >> Quick Recap of Proceedings >> >> 1.On Friday, I had profiled two solutions that fix the bug- >> JDK-8015070, using Java2D Bench >> >> 2.Profiling was done for 16 test cases with different combinations of >> >> a.Font Style: Plain, Bold, Italic, Bold-Italic >> >> b.Font Size: 12, 20, 36, 72 >> >> 3.Result from Friday 's profiling experiments: >> >> a.Regular Solution (Un-optimized) : This was observed to be faster >> for IntArgb pixel format >> >> b.Optimized Solution (based on SrcOver_MaskFill with fast path) : >> This was observed to be faster for IntArgb_Pre pixel format >> >> Update from Today's Experiments >> >> 1.First, I understood that new calculations introduced (pixelAddress >> computation) impacted performance of optimized solution in IntArgb format. >> >> 2.Henceforth, I made the following changes, while loading destination color: >> >> a.Check if the pixel format is PreMultiplied >> >> b.If the format is preMultiplied, then > take up new calculations and >> use LoadAlphaFrom ## DST ## For4ByteArgb macro that does *Not* cause >> divide by alpha adjustment >> >> c.If the format is regular Argb, then > take up loading of colors >> using standard Load ## DST ## To4ByteArgb >> >> 3.Once the release build was available, Java2D Bench was re-run >> (using pre-saved options file) >> >> Result from Bench metrics: >> >> a.In most of the test cases, the optimized solution has higher metric : >> Avg characters/ second for both IntArgb and IntArgb_Pre formats >> >> b.In 6 / total-16 test cases, optimized solution was marginally lower >> than the metrics of Regular un-optimized algorithm (only for >> IntArgb_Pre) >> >> c.However, J2DAnalyzer reported that even these 6-test cases were >> within 10% deviation. Hence the algorithms were categorized to be >> 'same' in performance. >> >> Suggestion Required >> >> 1.The attached zip file, contains Algorithms.cpp - Which lists down >> different algorithms profiled so far. >> >> 2.I 've introduced comments within the macro to explain the change. >> >> a.Note: These comments will be removed from the final source code to >> be checked in. >> >> 3.Kindly review the latest algorithm (for any issues/ bugs) and >> provide your suggestions. >> >> a.latest algorithm can be easily traced by searching for >> "LoadOptimized Algorithm v3" within the file. >> >> Thank you for your time in review & detailed feedback that you get >> every time. >> >> Every such review improves the quality of code & the solution >> >> Prahalad N. >> >> *From:* Prahalad Kumar Narayanan >> *Sent:* Friday, April 01, 2016 5:07 PM >> *To:* Jim Graham; Sergey Bylokhov; Philip Race >> *Cc:* Praveen Srivastava >> *Subject:* RE: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: >> Antialiased text on translucent backgrounds gets bright artifacts >> >> Dear Jim >> >> Good day to you. >> >> Thanks for your suggestions in the reviews that has evolved the fix >> to the bug. >> >> As guided by you, I measured the performance of Text Rendering with >> Text Antialiasing Hint on using Java2D Bench Tool. >> >> Solutions Profiled: >> >> We have two solutions - Un optimized solution and Optimized >> solution modelled as per SRCOVER_MASKFILL >> >> ( Both the solutions were profiled on windows x86_64 with >> JDK 9-internal Release build ) >> >> Test Cases Profiled: >> >> With Font set to : Lucida sans, different combinations of >> >> Font Styles : Plain, Bold, Italic, Bold Italic && >> >> Font Sizes : 12, 20, 36, 72 points were tested. >> >> Attached herewith: JDK8015070-Profiling Data.zip >> >> The archive contains: >> >> 1. Algorithms.cpp : Just to have a quick glance of all the >> algorithms that we have tried so far. >> >> 2. *.txt Files : For each test, Java2D bench >> reports the average metrics/second. >> >> The text file >> contains collection of all such average metric for nearly 16 >> different test cases. >> >> 3. res Output : .res output from each of the test runs. >> >> Observation from J2DBench Reports >> >> 1. I could not get time to run the Analyzer tool across >> each of these *.res files. I shall do them on Monday. >> >> 2. From the summary text ( average chars per. Second ) that >> J2DBench reported, >> >> Un-optimized solution seems to be better for >> IntArgb pixel format and >> >> Optimized solution is better for IntArgb_Pre >> pixel format by significant margin. >> >> 3. I tried to improve the optimized algorithm (based on >> SRCOVER_MASKFILL ) further by adding a if (dstA) { ... >> >> Though there is a marginal improvement, the >> optimized solution could not exceed numbers of regular algorithm (for >> IntArgb pixel format) >> >> This could be due to the extra calculations that >> we do in-order to load color components separately. >> >> However, for IntArgb_Pre pixel format, the >> optimized solution is way-ahead and gives better performance. >> >> 4. In the summary reports, you will find >> CompatibleBufferedImage( Translucent ) as well. >> >> In a separate experiment, I found that the pixel >> format for compatible buffered image got mapped IntArgb_Pre. >> >> Thus, the performance numbers match with that of >> IntArgb_Pre pixel format >> >> At the present moment, I 'm confused on the solution would be better >> to fix the Bug. >> >> Kindly share your views and thoughts >> >> Thank you >> >> Have a good day >> >> Prahalad N. >> >> -----Original Message----- >> From: Jim Graham >> Sent: Thursday, March 31, 2016 1:46 AM >> To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net >> ; Sergey Bylokhov >> Subject: Re: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: >> Antialiased text on translucent backgrounds gets bright artifacts >> >> Hi Prahalad, >> >> Benchmarks must run for a significant period of time to be valid. >> >> Measuring with nanoTime() is fine, but the run times should exceed at >> least a couple of seconds, not a few nanoseconds. You might want to >> use Java2DBench instead (in src/demo/share/java2d in the java.desktop >> repo), which calibrates test times, does multiple runs, and includes >> an analyzer to compare results from multiple test runs... >> >> ...jim >> >> On 3/30/2016 4:27 AM, Prahalad Kumar Narayanan wrote: >> >>> Hello Jim and Everyone on Java2D Group >> >>> >> >>> Good day to you. >> >>> >> >>> A quick follow-up to Review Request on bug: >> >>> Bug : JDK-8015070 >> >>> Bug Link :https://bugs.openjdk.java.net/browse/JDK-8015070 >> >>> >> >>> Thank you Jim for the detailed feedback. >> >>> >> >>> It takes a lot of time not only in performing the review, but also in getting the feedback with clear words. >> >>> In each review, the solution definitely gets better & better. I 'm >> >>> happy about it...! :) >> >>> >> >>> Quick Inferences from previous feedback: >> >>> >> >>> Incorporating the fast path into current logic: >> >>> 1. I agree with you on this point and I noticed this when we modelled the solution as per the mask fill. >> >>> 2. I ignored it initially for two reasons, >> >>> a. The statement - if (resA != MaxValFor4ByteArgb)... follows srcColor pre-multiplication step and this will ensure to skip most of the blending calculations pertaining to destination. >> >>> b. Any addition / tweaks to current logic, might deviate from the SRCOVER_MASKFILL reference model. >> >>> Many a time, managing code with similar logic across implementation helps a lot. >> >>> 3. As you said, including the fast path will avoid few multiplications and if checks too. >> >>> The changes are available in the current webrev. >> >>> Link: >> >>> http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.03/ >> >>> >> >>> Profiling method, and Metrics: >> >>> 1. The profiling method that was done yesterday was mere >>> execution of the regression test (available in the webrev) and time >>> measured with System.currentTimeMillis API >> >>> Since only one iteration was run, the time soared into milli seconds. This could be due to internal glyph caching mechanism. >> >>> 2. Today, I evolved the regression test, into a benchmark that does the following: >> >>> a. Select Font style : {Plain, Bold, Italic, Bold >>> Italic} >> >>> b. Select Font size : {20, 40, 60, 80} >> >>> c. Trigger drawstring once before benchmark is run. This is to ensure, the font subsystem is done with glyph caching internally. >> >>> d. Use famous string that has all characters-" The quick brown fox jumps over the lazy dog. 0123456789. " >> >>> e. For every style-size combination - run the test >>> for 20 iterations and take the average. (Note: Font is fixed to >>> 'verdana' ) >> >>> f. Modify the precision from System.currentTimeMillis to System.nanoTime() and reduce elapsedTime to micro seconds. >> >>> >> >>> 3. With the above setup in code, my observation on windows is as follows: >> >>> a. In many cases, The optimized logic is either equal-to (or) better in performance than the un-optimized logic. >> >>> The difference is very minimal - few tens to few hundreds of micro-seconds. >> >>> b. The optimized algorithm improves performance for Pre-multiplied alpha based destination buffer. >> >>> c. There are occasional huge deviations where optimized logic seems to take longer time. >> >>> These could be due to external factors >>> like- stalls for memory, bus io etc., >> >>> Since, the deviation is in micro seconds, I believe, it may not be a concern. >> >>> d. The complete list of time measurement taken up >>> on windows x86_64 release build is as-follows- >> >>> I 'm not sure, how the data appears in the final webrev-email. >> >>> Kindly excuse, if the data is un-readable. >> >>> >> >>> Platform : Windows x86_64 Release Build Algorithm : Unoptimized. >> >>> webrev.00 >> >>> ```````````````````````````````````````````````````````````````````` >>> ` >>> ` >> >>> ```` Executing Bench For Image Type: IntArgb >> >>> -Font Style: Plain /Font Size: 20 /Time consumed (us): 84.742 >> >>> -Font Style: Plain /Font Size: 40 /Time consumed (us): 318.395 >> >>> -Font Style: Plain /Font Size: 60 /Time consumed (us): 657.474 >> >>> -Font Style: Plain /Font Size: 80 /Time consumed (us): 813.079 >> >>> -Font Style: Bold /Font Size: 20 /Time consumed (us): 386.380 >> >>> -Font Style: Bold /Font Size: 40 /Time consumed (us): 339.301 >> >>> -Font Style: Bold /Font Size: 60 /Time consumed (us): 492.631 >> >>> -Font Style: Bold /Font Size: 80 /Time consumed (us): 625.812 >> >>> -Font Style: Italic /Font Size: 20 /Time consumed (us): 235.059 >> >>> -Font Style: Italic /Font Size: 40 /Time consumed (us): 320.180 >> >>> -Font Style: Italic /Font Size: 60 /Time consumed (us): 474.558 >> >>> -Font Style: Italic /Font Size: 80 /Time consumed (us): 1188.169 >> >>> -Font Style: Bold-Italic /Font Size: 20 /Time consumed (us): >>> 426.988 >> >>> -Font Style: Bold-Italic /Font Size: 40 /Time consumed (us): >>> 374.064 >> >>> -Font Style: Bold-Italic /Font Size: 60 /Time consumed (us): >>> 732.375 >> >>> -Font Style: Bold-Italic /Font Size: 80 /Time consumed (us): >>> 864.68 >> >>> >> >>> Executing Bench For Image Type: IntArgb_Pre >> >>> -Font Style: Plain /Font Size: 20 /Time consumed (us): 129.768 >> >>> -Font Style: Plain /Font Size: 40 /Time consumed (us): 206.299 >> >>> -Font Style: Plain /Font Size: 60 /Time consumed (us): 249.941 >> >>> -Font Style: Plain /Font Size: 80 /Time consumed (us): 362.372 >> >>> -Font Style: Bold /Font Size: 20 /Time consumed (us): 145.096 >> >>> -Font Style: Bold /Font Size: 40 /Time consumed (us): 151.589 >> >>> -Font Style: Bold /Font Size: 60 /Time consumed (us): 240.972 >> >>> -Font Style: Bold /Font Size: 80 /Time consumed (us): 331.894 >> >>> -Font Style: Italic /Font Size: 20 /Time consumed (us): 95.028 >> >>> -Font Style: Italic /Font Size: 40 /Time consumed (us): 245.300 >> >>> -Font Style: Italic /Font Size: 60 /Time consumed (us): 270.379 >> >>> -Font Style: Italic /Font Size: 80 /Time consumed (us): 398.139 >> >>> -Font Style: Bold-Italic /Font Size: 20 /Time consumed (us): >>> 93.243 >> >>> -Font Style: Bold-Italic /Font Size: 40 /Time consumed (us): >>> 475.406 >> >>> -Font Style: Bold-Italic /Font Size: 60 /Time consumed (us): >>> 280.085 >> >>> -Font Style: Bold-Italic /Font Size: 80 /Time consumed (us): >>> 357.486 >> >>> >> >>> Platform : Windows x86_64 Release Build Algorithm : Optimized. >> >>> webrev.03 >> >>> ```````````````````````````````````````````````````````````````````` >>> ` >>> ` >> >>> ```` Executing Bench For Image Type: IntArgb >> >>> -Font Style: Plain /Font Size: 20 /Time consumed (us): 120.954 >> >>> -Font Style: Plain /Font Size: 40 /Time consumed (us): 364.871 >> >>> -Font Style: Plain /Font Size: 60 /Time consumed (us): 561.799 >> >>> -Font Style: Plain /Font Size: 80 /Time consumed (us): 653.390 >> >>> -Font Style: Bold /Font Size: 20 /Time consumed (us): 261.566 >> >>> -Font Style: Bold /Font Size: 40 /Time consumed (us): 311.054 >> >>> -Font Style: Bold /Font Size: 60 /Time consumed (us): 490.735 >> >>> -Font Style: Bold /Font Size: 80 /Time consumed (us): 656.559 >> >>> -Font Style: Italic /Font Size: 20 /Time consumed (us): 314.289 >> >>> -Font Style: Italic /Font Size: 40 /Time consumed (us): 378.750 >> >>> -Font Style: Italic /Font Size: 60 /Time consumed (us): 491.181 >> >>> -Font Style: Italic /Font Size: 80 /Time consumed (us): 770.172 >> >>> -Font Style: Bold-Italic /Font Size: 20 /Time consumed (us): >>> 375.336 >> >>> -Font Style: Bold-Italic /Font Size: 40 /Time consumed (us): >>> 571.371 >> >>> -Font Style: Bold-Italic /Font Size: 60 /Time consumed (us): >>> 548.300 >> >>> -Font Style: Bold-Italic /Font Size: 80 /Time consumed (us): >>> 714.526 >> >>> >> >>> Executing Bench For Image Type: IntArgb_Pre >> >>> -Font Style: Plain /Font Size: 20 /Time consumed (us): 45.026 >> >>> -Font Style: Plain /Font Size: 40 /Time consumed (us): 219.016 >> >>> -Font Style: Plain /Font Size: 60 /Time consumed (us): 279.617 >> >>> -Font Style: Plain /Font Size: 80 /Time consumed (us): 282.829 >> >>> -Font Style: Bold /Font Size: 20 /Time consumed (us): 51.809 >> >>> -Font Style: Bold /Font Size: 40 /Time consumed (us): 117.563 >> >>> -Font Style: Bold /Font Size: 60 /Time consumed (us): 508.049 >> >>> -Font Style: Bold /Font Size: 80 /Time consumed (us): 402.802 >> >>> -Font Style: Italic /Font Size: 20 /Time consumed (us): 79.320 >> >>> -Font Style: Italic /Font Size: 40 /Time consumed (us): 227.473 >> >>> -Font Style: Italic /Font Size: 60 /Time consumed (us): 330.488 >> >>> -Font Style: Italic /Font Size: 80 /Time consumed (us): 353.782 >> >>> -Font Style: Bold-Italic /Font Size: 20 /Time consumed (us): >>> 54.687 >> >>> -Font Style: Bold-Italic /Font Size: 40 /Time consumed (us): >>> 235.505 >> >>> -Font Style: Bold-Italic /Font Size: 60 /Time consumed (us): >>> 227.205 >> >>> -Font Style: Bold-Italic /Font Size: 80 /Time consumed (us): >>> 324.308 >> >>> >> >>> Updated webrev with changes for the fast-path : >> >>> http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.03/ >> >>> Kindly review and provide your suggestions. >> >>> >> >>> Thank you once again for detailed review and feedback Have a good >>> day >> >>> >> >>> Prahalad N. >> >>> >> >>> >> >>> >> >>> -----Original Message----- >> >>> From: Jim Graham >> >>> Sent: Wednesday, March 30, 2016 2:46 AM >> >>> To: Prahalad Kumar Narayanan;2d-dev at openjdk.java.net >>> ; Sergey Bylokhov >> >>> Subject: Re: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: >> >>> Antialiased text on translucent backgrounds gets bright artifacts >> >>> >> >>> Hi Prahalad, >> >>> >> >>> This latest version looks like it should produce correct answers. >> >>> >> >>> I'd like to see benchmark results on more platforms, particularly Windows since the different compilers may optimize these things differently. >> >>> >> >>> Also, you didn't mention what data set you used for benchmarking. >>> I'd >> >>> like to see benchmark results for small, medium and large font >>> sizes, >> >>> and possibly bold and italic fonts as well. The reason is that the >> >>> relative ratios of "empty glyph pixels" to "partial glyph pixels" to >> >>> "fully covered glyph pixels" changes depending on the font type and >> >>> size so if you made one of those faster and another slower then the >> >>> results may be seen as a gain in one type of test if you only test >>> one >> >>> font type and size and it happens to match the part of the code that >> >>> is more streamlined. Also, for small font sizes the per-glyph >> >>> overhead might hide per-pixel issues. Please share which fonts and >> >>> sizes you used for testing and consider using some different sizes, >> >>> including something very large like 36 or 48 points (something with >> >>> large areas of opaque >> >>> pixels) as well as more normal sizes that appear in GUIs. Also, bold fonts can have a higher percentage of opaque pixels. >> >>> >> >>> In particular... >> >>> >> >>> This latest version is missing the "fast path" from the existing code for the case of srcA == 255 and glyphA == 255 where it just stores the FG_PIXEL values directly. For large fonts/glyphs that case may be as important as detecting empty glyph pixels. >> >>> >> >>> On the other hand, an additional "if" may cause the compiler to generate less efficient code as per Sergey's concern. Since this "if" eliminates some multiplies and possibly some divides, I'd hope it would be a win-win. >> >>> >> >>> You could add the fast path back inside the case where mixValSrc is 255 and just test srcA for 255 and do the Store ## DST ## PixelData() macro that used to be at the end of the block in the existing code, and then use "break;" to escape out of the do/while surrounding the whole macro so it moves on to the next pixel. >> >>> >> >>> (Arguably, we might want to consider teaching our SRCOVER_MASKFILL >>> to >> >>> do the same thing. I think that was one of the added values of >>> having >> >>> a separate GLYPH loop, but really both should be optimizing that >> >>> case...) >> >>> >> >>> I can see now that the macro switch to use the same macro set as SRCOVER_MASKFILL required you to compute the pixel address, as you noted in your summary. It makes the new macro more cumbersome and makes it look like it's doing a bit more work per-pixel, but in reality I think the overall operations end up being the same as long as the compiler optimizes the deliberate multiplications the same way it did for implicit multiplications in the "pRas[foo]" and "pRas[foo*4]" code that was being generated previously. Benchmarks will tell us if we're good there... >> >>> >> >>> ...jim >> >>> >> >>> >> >>> On 3/28/16 5:33 AM, Prahalad Kumar Narayanan wrote: >> >>>> Hello Everyone on Java2D Group >> >>>> >> >>>> Good day to you. >> >>>> >> >>>> This is a follow-up to Review Request on bug: >> >>>> Bug : JDK-8015070 >> >>>> Bug Link :https://bugs.openjdk.java.net/browse/JDK-8015070 >> >>>> >> >>>> First, Thanks to Jim and Sergey for their feedback on the changes so far. >> >>>> >> >>>> Inferences from Jim 's Feedback on Loading destination colors: >> >>>> 1. The API or Macro that I had earlier used to Load DST colors, indeed, adjusted destination color components with divide-by-alpha if destination was already pre-multiplied. >> >>>> My apologies.. I should have spotted this error at the first iteration itself. >> >>>> 2. Due to the divide-by-alpha adjustment, the remaining >>>> logic would become incorrect. ( Especially, the multiplication with >>>> dstF based on pre-mulitplication status ) >> >>>> 3. Correct API is being used now, and the dstColor components are loaded directly without any divide-by-alpha adjustment. >> >>>> >> >>>> Inferences from Sergey's Feedback on Performance. >> >>>> 1. To set the context for everyone, the logic present in the current webrev.02 is modelled as per SRCOVER_MASKFILL. >> >>>> There are multiple if (...) conditions that remove un-necessary blending calculations. Ideally this should improve performance. >> >>>> However, since some data are not readily available (as present in SRCOVER_MASKFILL), few additional calculations have been added. >> >>>> They are: pre-multiplying srcColor with alpha and assigning to res. >> >>>> Finding the correct address of Pixel using DST_PTR and PixelStride. >> >>>> Henceforth, as Sergey suggests, Observation on performance will be beneficial. >> >>>> 2. The performance of the new logic was measured with >>>> linux-x86_64-normal-server-release config and compared with the >>>> logic used in un-optimized code in webrev.00 >> >>>> 3. Result: The newer logic provides a fractional gain (about 15 - 20 ms) over the older logic. >> >>>> >> >>>> Other Subtle Changes: >> >>>> 1. The test file has been renamed from >>>> AADrawStringArtifact.java to more meaningful - >>>> AntialiasedTextArtifact.java >> >>>> 2. The test file tests for both TYPE_INT_ARGB and TYPE_INT_ARGB_PRE BufferedImage formats. >> >>>> The code has been well commented to explain the logic used in every function. >> >>>> >> >>>> Kindly take your time to review the changes in the webrev link mentioned below and provide your suggestions. >> >>>> Webrev Link: >> >>>> http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.02/ >> >>>> >> >>>> >> >>>> Thank you for your time in review >> >>>> Have a good day >> >>>> >> >>>> Prahalad N. >> >>>> >> >>>> >> >>>> -----Original Message----- >> >>>> From: Jim Graham >> >>>> Sent: Thursday, March 24, 2016 7:57 AM >> >>>> To: Prahalad Kumar Narayanan;2d-dev at openjdk.java.net >>>> >> >>>> Subject: Re: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: >> >>>> Antialiased text on translucent backgrounds gets bright artifacts >> >>>> >> >>>> Hi Prahalad, >> >>>> >> >>>> (On a side note - ouch! I came up with these macros in the first >> >>>> place, but 20 years later I'm now realizing just how hard they are >>>> to >> >>>> navigate and review. My apologies...) >> >>>> >> >>>> The macro you are still using to load the destination data is one that loads it to non-premultiplied components, which means it will divide out the alpha if the destination is PRE. The rest of the logic assumes that the components were loaded without any adjustment of their premultiplication so not only is that division an unnecessary operation, it makes the following math wrong. >> >>>> >> >>>> The SRCOVER_MASKFILL macro seems to use "Postload ## STRATEGY ## From ## TYPE" which seems to load them into separate components without any adjustment of their pre-multiplication status. This is paired with "LoadAlphaFrom ## TYPE ## For ## STRATEGY" to load just the destination alpha for computing dstF... >> >>>> >> >>>> ...jim >> >>>> >> >>>> On 3/22/16 4:35 AM, Prahalad Kumar Narayanan wrote: >> >>>>> Hello Everyone on Java2D Group >> >>>>> >> >>>>> Good day to you. >> >>>>> >> >>>>> This is a Follow-up to Review Request on the bug: >> >>>>> Bug : JDK-8015070 Anti-aliased Text on Translucent background gets bright artifacts >> >>>>> Bug Link :https://bugs.openjdk.java.net/browse/JDK-8015070 >> >>>>> >> >>>>> First, Sincere thanks to Jim for his valuable feedback. >> >>>>> 1. As Jim correctly mentioned, SRCOVER_MASKFILL has a similar logic to blend two Translucent colors based on an Alpha mask. >> >>>>> 2. The calculations are exactly the same as the changes in previous webrev. >> >>>>> However the logic of SRCOVER_MASKFILL is 'Optimized' to reduce the number of computations. >> >>>>> 3. This optimization is definitely required because, the logic is executed for every single pixel in a glyph. >> >>>>> Example: If a string is made up of 5 English >>>>> characters with each character having 32 x 32 pixels, >> >>>>> The anti-aliasing logic will be executed for 5 x 32 x 32 iterations. >> >>>>> Reducing computation per pixel will imply a huge benefit for complete drawString operation. >> >>>>> >> >>>>> Observation from SRCOVER_MASKFILL >> >>>>> 1. The mask fill reduces computations by through multiple if(...) conditions. >> >>>>> Each if condition affirms whether the next set of computations are required. >> >>>>> 2. Optimization 1: If mask value is 0- skip entire logic. >> >>>>> 3. Optimization 2: If mask value is maximum, say 255, take >>>>> srcA directly without multiplying with maskAlpha ( Reason: 1 * >>>>> srcAlpha = srcAlpha ) >> >>>>> 4. Optimization 3: Compute pre-multiplied resColor in two steps. First with srcColor and then with dstColor. >> >>>>> If the resAlpha from 1st step (i.e., srcColor) is fully opaque, avoid blending dstColor altogether. >> >>>>> >> >>>>> Changes in Current Webrev.01 >> >>>>> 1. The fix for the current bug is modelled based on SRCOVER_MASKFILL. >> >>>>> 2. The changes have been verified to work on windows, linux and mac operating systems. >> >>>>> 3. The automated Test file- AADrawStringArtifact.java runs >>>>> as expected >> >>>>> Identifies artifact & throws exception when run on JDK 7 and 8. >> >>>>> With JDK9, the test file returns without error. >> >>>>> 3. JPRT build has been run to ensure, changes build on all supported platforms. >> >>>>> JPRT job link : >> >>>>> http://scaaa637.us.oracle.com//archive/2016/03/2016-03-22-070604.p >>>>> ra >> >> >>>>> h >> >>>>> n >> >>>>> ara-linux.client >> >>>>> >> >>>>> Kindly review the changes in the below mentioned link and provide >>>>> your views >> >>>>> Webrev Link : >> >>>>> http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.01/ >> >>>>> >> >>>>> >> >>>>> Thank you for your time in review >> >>>>> Have a good day >> >>>>> >> >>>>> Prahalad N. >> >>>>> >> >>>>> >> >>>>> -----Original Message----- >> >>>>> From: Jim Graham >> >>>>> Sent: Friday, March 18, 2016 6:07 AM >> >>>>> To: Prahalad Kumar Narayanan;2d-dev at openjdk.java.net >>>>> >> >>>>> Subject: Re: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: >> >>>>> Antialiased text on translucent backgrounds gets bright artifacts >> >>>>> >> >>>>> Hi Prahalad, >> >>>>> >> >>>>> This basically boils down to "alpha blending math needs to be performed in premultiplied form" and the existing code was not doing that. >> >>>>> >> >>>>> Your changes do add a pre-multiplication step to the math in two >> >>>>> places >> >>>>> - when you mix the src alpha and the glyph alpha at the top of the macro, and again when you do the Multiply(dst, dstA, dst) step in the middle. In that sense, the new math is correct. >> >>>>> >> >>>>> However, it is not the optimal way to implement this. In >> >>>>> particular, the macro used here to load the data from the >> >>>>> destination is the one that loads it into 4 ARGB non-premultiplied >> >>>>> values. If the destination is non-PRE, then your added multiply >> >>>>> step is exactly what is needed, but it could be combined with the >> >>>>> multiply that will happen later in the blending equation, so it is >> >>>>> an added step rather than a fixed fraction in the existing MultMultAdd parameters. >> >>>>> Additionally, if the destination is already PRE, then the macro >> >>>>> being used to load the dst pixel data there will have done a >>>>> divide >> >>>>> step to divide out the alpha from the destination, only to have >>>>> you >> >>>>> reverse that math with your new >> >>>>> Multiply() step. That's a lot of math to end up with a NOP. >> >>>>> >> >>>>> The MUL8 you added for the srcA and glyph value is needed, that change is good. Since it is common for glyph pixels to have zero alpha, you might want to test the glyph alpha for 0 and skip the pixel before you do the multiply, though. This would add one more if, but it would be a common case. >> >>>>> >> >>>>> The trickier part is to load the destination components without un-premultiplying them. Unfortunately there is no "Load...ToArgbPre" >> >>>>> macro to parallel the Load macro used in the function. Perhaps there should be, but you'd still end up with an extra multiply step as I mentioned above because you can fold the premultiplication of the dst data into the MultMultAdd by carefully choosing the parameters you use in the math there. >> >>>>> >> >>>>> The good news is that the way that the SRCOVER_MASKFILL uses the various type-specific macros works around this a bit and minimizes the number of multiplies that happen. You could check out DEFINE_SRCOVER_MASKFILL and see how it works in the case where pMask is not null (pMask is an alpha mask with values very similar to the glyphAA data). Modeling this code on that code would correct the math and minimize it as well... >> >>>>> >> >>>>> ...jim >> >>>>> >> >>>>> On 3/17/16 3:00 AM, Prahalad Kumar Narayanan wrote: >> >>>>>> Hello Everyone on Java2D Group >> >>>>>> >> >>>>>> Good day to you. >> >>>>>> >> >>>>>> Herewith, I 'm sharing the webrev for two identical Java2D Bugs. >> >>>>>> >> >>>>>> Bug ID : JDK-8015070 >> >>>>>> >> >>>>>> Title : Antialiased text on translucent backgrounds gets >> >>>>>> bright artifacts >> >>>>>> >> >>>>>> Link :https://bugs.openjdk.java.net/browse/JDK-8015070 >> >>>>>> >> >>>>>> Bug ID : JDK-8013564 ( currently closed as duplicate ) >> >>>>>> >> >>>>>> Title : Font rendering anti-aliasing in translucent >> >>>>>> BufferedImages broken >> >>>>>> >> >>>>>> Link :https://bugs.openjdk.java.net/browse/JDK-8013564 >> >>>>>> >> >>>>>> Webrev Link : >> >>>>>> http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.00/ >> >>>>>> >> >>>>>> Quick Summary on Bugs : >> >>>>>> >> >>>>>> ```````````````````````````````````````````````` >> >>>>>> >> >>>>>> 1. Artifacts appear on Edges of text characters when >>>>>> anti-aliased >> >>>>>> text is drawn on Translucent background >> >>>>>> >> >>>>>> 2. The issue is reproducible on all platforms - windows, linux and mac os. >> >>>>>> >> >>>>>> 3. Besides, the issue is reproduced with the commonly used pixel >> >>>>>> format- 4ByteArgb. >> >>>>>> >> >>>>>> Root Cause & Solution : >> >>>>>> >> >>>>>> ```````````````````````````````````````````````` >> >>>>>> >> >>>>>> 1. The Macro: GlyphListAABlend4ByteArgb in File: LoopMacros.h >>>>>> uses >> >>>>>> the standard blending algorithm >> >>>>>> >> >>>>>> dstColor = [ srcColor * glyphAlpha + dstColor * (1 - >> >>>>>> glyphAlpha) ] / dstAlpha >> >>>>>> >> >>>>>> 2. The above equation works only when the srcColor and dstColor are Opaque. >> >>>>>> >> >>>>>> 3. When srcColor and dstColor are Translucent, their >> >>>>>> alphaComponent will influence the visibility of the color, and >> >>>>>> visibility of the color below. >> >>>>>> >> >>>>>> 4. The new set of calculations for blending Translucent source >>>>>> and >> >>>>>> destination colors is given as >> >>>>>> >> >>>>>> resAlpha = 1 - ((1 - srcAlpha) * (1 - dstAlpha)) >> >>>>>> >> >>>>>> resColor = [ srcColor * srcAlpha + dstColor * >>>>>> dstAlpha >> >>>>>> * >> >>>>>> (1 >> >>>>>> - >> >>>>>> srcAlpha) ] / resAlpha >> >>>>>> >> >>>>>> 5. Reference text for the equation: >> >>>>>> https://en.wikipedia.org/wiki/Alpha_compositing >> >>>>>> >> >>>>>> 6. With the above modification to the blending logic, the >> >>>>>> artifacts do not appear and issues are fixed. >> >>>>>> >> >>>>>> Jtreg & Jprt Results : >> >>>>>> >> >>>>>> ```````````````````````````````````````````````` >> >>>>>> >> >>>>>> 1. A simple test-file: AADrawStringArtifact.java has been >>>>>> created >> >>>>>> to be a part of jtreg test cases. >> >>>>>> >> >>>>>> The test file is well commented to explain - nature >>>>>> of >> >>>>>> artifact and how the test tries to identify them. >> >>>>>> >> >>>>>> As required, the test case fails with Jdk 7, Jdk 8 >>>>>> and >> >>>>>> succeeds with Jdk 9-internal (built with changes for the bug fix) >> >>>>>> >> >>>>>> 2. The changes to blending logic lies within >> >>>>>> java.desktop/src/share/native/... >> >>>>>> >> >>>>>> Henceforth, JPRT was used to ensure successful build >> >>>>>> across all supported platforms >> >>>>>> >> >>>>>> Jprt Job Link : >> >>>>>> http://scaaa637.us.oracle.com//archive/2016/03/2016-03-17-072001. >>>>>> pr >> >> >>>>>> a >> >>>>>> h >> >>>>>> n >> >>>>>> ara-linux.client >> >>>>>> >> >>>>>> The build succeeds on all platforms. >> >>>>>> >> >>>>>> Kindly review the webrev link and provide your views and suggestions. >> >>>>>> >> >>>>>> Webrev Link : >> >>>>>> http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.00/ >> >>>>>> >> >>>>>> If the changes look good, we could take up the changes for source checkin. >> >>>>>> >> >>>>>> Thank you for your time in review >> >>>>>> >> >>>>>> Have a good day >> >>>>>> >> >>>>>> Prahalad N. >> >>>>>> >> From volker.simonis at gmail.com Wed Apr 27 14:35:04 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 27 Apr 2016 16:35:04 +0200 Subject: [OpenJDK 2D-Dev] RFR(S): 8155236: AIX: fix detection of Xrender extension Message-ID: Hi, can somebody please review this AIX-only fix which I've found in one of my old patch queues :) http://cr.openjdk.java.net/~simonis/webrevs/2016/8155236/ https://bugs.openjdk.java.net/browse/JDK-8155236 On AIX we have to use a special syntax for the dlopen() string argument because the shared libraries are packed in multi-architecture archives. We first try to load the system default libXrender which is contained in the 'X11.base.lib' fileset starting with AIX 6.1. If the latter wasn't successful, we also try to load the version under /opt/freeware. This may be downloaded from the "AIX Toolbox for Linux Applications" even for AIX 5.3. Thank you and best regards, Volker From philip.race at oracle.com Wed Apr 27 16:35:15 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 27 Apr 2016 09:35:15 -0700 Subject: [OpenJDK 2D-Dev] RFR(S): 8155236: AIX: fix detection of Xrender extension In-Reply-To: References: Message-ID: <5720EA43.7040007@oracle.com> Whilst the syntax is all new to me, since it is contained entirely in #if defined(_AIX) I am OK with this fix. phil. On 4/27/16, 7:35 AM, Volker Simonis wrote: > Hi, > > can somebody please review this AIX-only fix which I've found in one > of my old patch queues :) > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8155236/ > https://bugs.openjdk.java.net/browse/JDK-8155236 > > On AIX we have to use a special syntax for the dlopen() string > argument because the shared libraries are packed in multi-architecture > archives. We first try to load the system default libXrender which is > contained in the 'X11.base.lib' fileset starting with AIX 6.1. > > If the latter wasn't successful, we also try to load the version under > /opt/freeware. This may be downloaded from the "AIX Toolbox for Linux > Applications" even for AIX 5.3. > > Thank you and best regards, > Volker From volker.simonis at gmail.com Wed Apr 27 16:49:43 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 27 Apr 2016 18:49:43 +0200 Subject: [OpenJDK 2D-Dev] RFR(S): 8155236: AIX: fix detection of Xrender extension In-Reply-To: <5720EA43.7040007@oracle.com> References: <5720EA43.7040007@oracle.com> Message-ID: I've checked that it really works :) Thanks, Volker On Wed, Apr 27, 2016 at 6:35 PM, Philip Race wrote: > Whilst the syntax is all new to me, since it is contained > entirely in #if defined(_AIX) I am OK with this fix. > > phil. > > > On 4/27/16, 7:35 AM, Volker Simonis wrote: >> >> Hi, >> >> can somebody please review this AIX-only fix which I've found in one >> of my old patch queues :) >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8155236/ >> https://bugs.openjdk.java.net/browse/JDK-8155236 >> >> On AIX we have to use a special syntax for the dlopen() string >> argument because the shared libraries are packed in multi-architecture >> archives. We first try to load the system default libXrender which is >> contained in the 'X11.base.lib' fileset starting with AIX 6.1. >> >> If the latter wasn't successful, we also try to load the version under >> /opt/freeware. This may be downloaded from the "AIX Toolbox for Linux >> Applications" even for AIX 5.3. >> >> Thank you and best regards, >> Volker From philip.race at oracle.com Wed Apr 27 16:55:29 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 27 Apr 2016 09:55:29 -0700 Subject: [OpenJDK 2D-Dev] Fwd: Re: JDK 9 pre-review of JDK-6850612: Deprecate Class.newInstance since it violates the checked exception language contract In-Reply-To: <57f52e95-9485-1114-5314-cbdf1680709b@oracle.com> References: <5718FEF7.1020807@oracle.com> <57f52e95-9485-1114-5314-cbdf1680709b@oracle.com> Message-ID: <5720EF01.3070902@oracle.com> Rather than adding all these annotations I would prefer that you do what Stuart did with the boxed primitive constructor deprecation where he disabled the deprecation checking on the desktop module until we can clean it up. That one was done within about a week and should be in dev in a few days .. -phil On 4/26/16, 9:45 AM, joe darcy wrote: > > Phil and other client reviewers, > > Please review this change from core libs which impacts client libs > implementations. In brief, deprecating a method in core reflection > requires uses of that method to have a > @SuppressWarnings("deprecation") annotation. The typical way to > minimize the scope of the deprecation is to declare a temporary > variable which can host the @SuppressWarnings annotation. The > alternative would have been to suppress the warning on the entire > method, which would allow addition use of deprecated methods to sneak in. > > http://cr.openjdk.java.net/~darcy/6850612.0/ > > Thanks, > > -Joe > > > -------- Forwarded Message -------- > Subject: Re: JDK 9 pre-review of JDK-6850612: Deprecate > Class.newInstance since it violates the checked exception language > contract > Date: Thu, 21 Apr 2016 09:25:27 -0700 > From: joe darcy > Organization: Oracle Corporation > To: core-libs-dev > > > > Hello, > > After a generally positive reception, please review the webrev to > implement the deprecation of Class.newInstance and the suppression of > the resulting warnings: > > http://cr.openjdk.java.net/~darcy/6850612.0/ > > There are also some changes in the langtools repo; I'll send a separate > review request for those changes to compiler-dev. > > I'll also forward this review request to other areas with affected code. > > Thanks, > > -Joe > > On 4/17/2016 10:31 AM, joe darcy wrote: > > Hello, > > > > With talk of deprecation in the air [1], I thought it would be a fine > > time to examine one of the bugs on my list > > > > JDK-6850612: Deprecate Class.newInstance since it violates the > > checked exception language contract > > > > As the title of the bug implies, The Class.newInstance method > > knowingly violates the checking exception contract. This has long been > > documented in its specification: > > > >> Note that this method propagates any exception thrown by the nullary > >> constructor, including a checked exception. Use of this method > >> effectively bypasses the compile-time exception checking that would > >> otherwise be performed by the compiler. The Constructor.newInstance > >> method avoids this problem by wrapping any exception thrown by the > >> constructor in a (checked) InvocationTargetException. > > > > Roughly, the fix would be to turn the text of this note into the > > @deprecated text and to add a @Deprecated(since="9") annotation to the > > method. There are a few dozen uses of the method in the JDK that would > > have to be @SuppressWarning-ed or otherwise updated. > > > > Thoughts on the appropriateness of deprecating this method at this time? > > > > Comments on the bug have suggested that besides deprecating the > > method, a new method on Class could be introduced, > > newInstanceWithProperExceptionBehavior, that had the same signature > > but wrapped exceptions thrown by the constructor call in the same way > > Constructor.newInstance does. > > > > Thanks, > > > > -Joe > > > > [1] > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040192.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Wed Apr 27 20:35:10 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 27 Apr 2016 13:35:10 -0700 Subject: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: Antialiased text on translucent backgrounds gets bright artifacts In-Reply-To: <5bba3046-40d3-471b-8457-93cb637aaf1c@default> References: <63d69ba8-d5cf-4697-bb5c-f51aaaa8c427@default> <56EB4DBB.9080802@oracle.com> <56F3505B.2070101@oracle.com> <215e497a-db82-4f6f-99e9-bd44f25d5999@default> <56FAF088.70300@oracle.com> <6b400fd0-a335-46a5-9fed-abb06c3fd6a0@default> <56FC33F6.1060108@oracle.com> <5702DE6F.5000903@oracle.com> <4213d5c2-3711-4631-87a3-ba40c1e5ceeb@default> <2b1d0a70-0ab3-ca34-92f0-447a435f72a3@oracle.com> <5bba3046-40d3-471b-8457-93cb637aaf1c@default> Message-ID: <510cd0d5-5062-9365-5246-a9290116471b@oracle.com> Thanks Prahalad, First, the macro design issues for all of these LoopMacros.h et al files are pretty complex, so I apologize if this is a big learning step here and if the feedback can look like nit-picking at times. But the system is complicated enough that we should take care to make sure the new work remains consistent to what is already there and to keep this complicated system maintainable in the long run. The only issue I have with the new macros is that Store*() naming convention is typically used when the macro itself does the assignment. In the case of the new Store*BlendFactor() macros, they simply return the value and the caller does the assignment, so the name is off. This could be fixed either by moving "blendF" to an argument to the macro, or renaming it to one of the suggestions I gave earlier that don't imply assignment inside the macro. Another thing to consider is that the type of the blend factor is actually determined by the alpha blend token "STRATEGY", not by the image type. Many of the alpha blend types are dependent on the image types being used, but it is not solely determined by the image type, sometimes it depends on the pair of src/dst image types. In any case, the STRATEGY used for alpha blending is not directly tied to an image type. Other alpha loop macros take a STRATEGY as an argument and invoke the proper alpha blending value declaration and manipulation macros with "For ## Strategy" macro name expansions. But we are hard-coding "For4ByteArgb" in this particular macro, which means we are hard-coding the particular type of alpha math. Since that determination is done by hard-coding in this macro and not by delegating to the image type, then it is inappropriate to ask the image-type-based macro to decide how to declare the blend factor. If anything, we should use "DeclareAlphaVarFor4ByteArgb()" to declare the variable, not an image-based macro. Note that the Declare() macros for the alpha math strategies take an argument called "VAR" so then you can assume that they've named the variable the same token that you supplied. My recommendation would be to delete the new Declare macros and replace their use in LoopMacros.h with a usage of the existing DeclareAlphaVarFor4ByteArgb() macro, and then I would move the resulting variable into the argument list for the Store ## BlendFactor macro and move the assignment part of the statement inside of the macro... ...jim On 4/27/16 6:37 AM, Prahalad Kumar Narayanan wrote: > Dear Jim and Everyone on Java2D Community > > Good day to you. > > First, Thanks to Jim for his feedback. > I 've incorporated his feedback in latest version of code and webrev link is shared below > Webrev Link: http://cr.openjdk.java.net/~aghaisas/prahalad/8015070/webrev.05/ > > Quick Description on Changes : > 1. Removing redundant code MultiplyAndStore4ByteArgbComps(res, resA, SRC_PREFIX) > The redundant code within if and else blocks of if ( mixValSrc != 0xff ) has been moved into block that does color blending. > As Jim rightly said, the change would execute Multiply operation only if blending is required > On the other hand, If resA reaches maximum value, the fast path is executed. > > 2. Fast path execution > The fast path that directly sets foreground color has been moved into else block after checking if ( resA != MaxValFor4ByteArgb ) > Conceptually, resA would be maximum only when glyphAlpha (mixValSrc) and srcAlpha are maximum. > > 3. Isolated Declare and Store macros. > A single macro DeclareAndInit... has been split into two macros Declare ## DST ## SrcOverDstBlendFactor and Store ## DST ## SrcOverDstBlendFactor. > This would indeed address some compilers that do not allow declaration in the middle of the block. > > 4. Other Relevant Information: > The changes have been verified to build on all platforms through JPRT auto build system. > Java2D benchmarks were run with the changes and no degradation on performance was seen compared to webrev.04 > Regression was run and no new regression failures have been introduced with the change. > > 5. To reduce reviewer 's effort in review, code has been expanded with comments herewith. > > #define GlyphListAABlend4ByteArgb(DST, GLYPH_PIXELS, PIXEL_INDEX, DST_PTR, \ > FG_PIXEL, PREFIX, SRC_PREFIX) \ > do { \ > DeclareAlphaVarFor4ByteArgb(resA) \ > DeclareCompVarsFor4ByteArgb(res) \ > jint mixValSrc = GLYPH_PIXELS[PIXEL_INDEX]; \ > if (mixValSrc) { \ > /* Evaluating srcAlpha component */ \ > if (mixValSrc != 0xff) { \ > /* No-op. Retained to match reference as SRCOVER_MASK_FILL */ \ > PromoteByteAlphaFor4ByteArgb(mixValSrc); \ > /* Glyph mask determines visibility of the srcColor */ \ > resA = MultiplyAlphaFor4ByteArgb(mixValSrc, SRC_PREFIX ## A); \ > } else { \ > /* This is understood easier with floating point logic. */ \ > /* 1.0f is max value used in floating point calculation */ \ > /* (1.0f * srcA) gives srcA. Hence we directly consider */ \ > /* srcA without Multiply with glyph mask. */ \ > resA = SRC_PREFIX ## A; \ > } \ > /* Blending srcColor and dstColor */ \ > /* This is required only when resA(i.e., srcA) is not maximum */ \ > if (resA != MaxValFor4ByteArgb) { \ > DeclareAndInvertAlphaVarFor4ByteArgb(dstF, resA) \ > DeclareAndClearAlphaVarFor4ByteArgb(dstA) \ > DeclareCompVarsFor4ByteArgb(dst) \ > DeclareCompVarsFor4ByteArgb(tmp) \ > /* Redundant statement moved from previous if -else block */ \ > MultiplyAndStore4ByteArgbComps(res, resA, SRC_PREFIX); \ > /* Based on the pixelFormat we could reduce calculations */ \ > /* done to load the color and alpha components */ \ > if (!(DST ## IsPremultiplied)) { \ > Load ## DST ## To4ByteArgb(DST_PTR, pix, PIXEL_INDEX, \ > dstA, dstR, dstG, dstB); \ > Store4ByteArgbCompsUsingOp(tmp, =, dst); \ > } else { \ > Declare ## DST ## AlphaLoadData(DstPix) \ > jint pixelOffset = PIXEL_INDEX * (DST ## PixelStride); \ > DST ## DataType *pixelAddress = PtrAddBytes(DST_PTR, \ > pixelOffset); \ > /* The macro's implementation loads color components */ \ > /* without divide by alpha adjustment as required for */ \ > /* subsequent calculations. Note: This is used only */ \ > /* with preMultiplied alpha based pixel formats */ \ > LoadAlphaFrom ## DST ## For4ByteArgb(pixelAddress, \ > DstPix, \ > dst); \ > Postload4ByteArgbFrom ## DST(pixelAddress, \ > DstPix, \ > tmp); \ > } \ > /* Avoid blending operatons if dst is fully transparent */ \ > if (dstA) { \ > Declare ## DST ## SrcOverDstBlendFactor(blendF) \ > /* dstA would be 0 if either of the following is true. */ \ > /* 1. srcA is max. Parent if condition validates this. */ \ > /* 2. dstA is zero. The current if condition validates */ \ > /* Henceforth, the following Multiply need not be moved */ \ > /* ahead of the if condition. This also helps to better */ \ > /* performance */ \ > dstA = MultiplyAlphaFor4ByteArgb(dstF, dstA); \ > resA += dstA; \ > /* Declares blendF variable and assigns appropriate */ \ > /* alpha value. The definitions are contained in the*/ \ > /* header files of respective pixel formats */ \ > blendF = Store ## DST ## SrcOverDstBlendFactor(dstF, \ > dstA); \ > /* This is understood easier with floating point logic.*/ \ > /* 1.0f is max value used in floating point calculation*/ \ > /* (1.0f * tmp) gives tmp. Hence we avoid Multiply */ \ > /* operation and directly add loaded color to result*/ \ > if (blendF != MaxValFor4ByteArgb) { \ > MultiplyAndStore4ByteArgbComps(tmp, \ > blendF, \ > tmp); \ > } \ > Store4ByteArgbCompsUsingOp(res, +=, tmp); \ > } \ > } else { \ > /* resA is maximum only when srcA and glyphAlpha are max */ \ > /* Hence the fast path to store foreground pixel color and */ \ > /* break to the next pixel. */ \ > Store ## DST ## PixelData(DST_PTR, PIXEL_INDEX, \ > FG_PIXEL, PREFIX); \ > break; \ > } \ > /* In the above calculations, color values are multiplied with */ \ > /* with alpha. This is perfectly fine for pre-Multiplied alpha */ \ > /* based pixel formats. For non pre-multiplied alpha based */ \ > /* pixel formats, the alpha is removed from color components */ \ > /* and then stored to the resulting color */ \ > if (!(DST ## IsOpaque) && \ > !(DST ## IsPremultiplied) && resA && \ > resA < MaxValFor4ByteArgb) \ > { \ > DivideAndStore4ByteArgbComps(res, res, resA); \ > } \ > Store ## DST ## From4ByteArgbComps(DST_PTR, pix, \ > PIXEL_INDEX, res); \ > } \ > } while (0); > > Kindly review the changes present in the webrev and provide your views. > > Thank you once again for your effort in review > Have a great day > > Prahalad N. > > > -----Original Message----- > From: Jim Graham > Sent: Wednesday, April 27, 2016 2:12 AM > To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: Antialiased text on translucent backgrounds gets bright artifacts > > Hi Prahalad, > > One potential portability issue - you have a "DeclareAndInit" macro for the new "choose which blend factor" macro in the middle of a block. > Some C compilers allow declaring a new variable in the middle of a block, but not all. Since it would be hard to move the declaration to the top of the block, since it depends on a value computed in the first couple of lines, it might be better to change it from a "DeclareAndInit" > style macro into a regular declaration, and a macro to get the value, so "jint blendF;" at the top of the block and "blendF = SrcOverDstBlendFactorFor ## DST(...);" in the middle of the block. (Or name it "SrcOver ## DST ## BlendFactor(...)?" > > I just noticed something about this .04 version of the function. At the top you have a test for mixValSrc != 255 and then both clauses of the if statement end with essentially the same code, multiplying the source by the value in resA. (The version in the else clause uses SRC_PREFIX ## A, but it could just as easily also use resA since they are the same value at that point.) > > This means you could potentially move both "MultiplyAndStore" macros until after the if and use resA as the multiplier. Now, if you look, the immediate next statement tests if resA is maxVal. If it is maxVal, then you don't need to do that multiply at all, so the macro could be moved even further to be inside the "if (resA != maxVal)" block. > > At that point, you could then reinstate the "else" on that if block and move the Store##DST##PixelData into that else, to save you another test of resA. This would essentially look like this: > > if (mixValSrc != 255) { > PromoteByteAlpha...; > resA = MultiplyAlpha...; > } else { > resA = SRC_PREFIX ## A; > } > if (resA != MaxVal) { > Declare,declare,declare,declare...; > Multiply...Comps(res, resA, SRC_PREFIX); } else { > Store ## DST ## PixelData...; > } > > It shortens the code a little, but I'm not sure if it would really help performance other than not having to do the test for maxVal twice. > Still, tests are fairly expensive in code like this so it could be worth a shot at testing, and it would simplify the code a bit in either case... > > ...jim > > On 4/15/16 12:25 AM, Prahalad Kumar Narayanan wrote: >> Hello Jim & Everyone on Java2D Community >> >> Good day to you. >> >> This is a review request and a follow-up to the bug-fix for the issue >> Bug : JDK-8015070 >> Link : https://bugs.openjdk.java.net/browse/JDK-8015070 >> >> Webrev Link : >> http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.04/ >> >> Quick Inferences on Changes in Current -Webrev.04 >> >> 1 ) Subtle changes to the blend loop- >> . The subtle changes taken up, have helped to improve the performance. >> . With the current logic in webrev.04, Java2DBench reports better performance than Un-Optimized solution that was present in webrev.00 >> . J2DBench was run for Font Styles { Plain, Bold, Italic, Bold n Italic } and Font Sizes { 12, 20, 36, 72 } >> . My sincere thanks to Jim for all his detailed feedback through the multiple reviews that has evolved the solution today. >> >> (Details on changes) >> 1.a. Loading of Color components >> . When modelled as per SRCOVER_MASK_FILL code, the logic required few additional calculations to load color components. >> . The extra calculations indeed impacted performance figures. >> . This could be offset in two possible ways >> a. Inspect parent macro- NAME_SOLID_DRAWGLYPHLISTAA and advance by pixel address and not by pixel index. >> The parent macro invokes GlyphListAABlendFourByteArgb through this macro- GlyphListAABlend ## STRATEGY(DST, pixels, x, pPix, fgpixel, solidpix, src); >> Changing parent macro will cause spurious changes across GlyphListAABlend ## other pixel formats. >> There is additional risk of breaking the stable and well optimized LoopMacros.h. >> b. Load color components based on pre-Multiplication status >> This has been taken up and change is limited to the function being modified. >> Thankfully J2DBench has still reported improvement in performance. >> >> 1.b. New Macro to avoid if (DST ## IsPremultiplied) { >> . A new macro- DeclareAndInit ## DST ## SrcOverMaskBlendFactor has been introduced to choose between dstF, or dstA >> . The implementation is available in the header files of pixel formats ( Eg: IntArgb.h IntArgbPre.h ) >> . There are 29 different pixel formats known to Java2D, and >> . Hence, the new macro's implementation is added only to those pixel formats that require the current glyph blending logic. >> >> 2 ) Testing across different formats >> . The Regression test code has been modified to test anti-aliased text rendering on 7 different pixel formats- >> . IntArgb, IntArgb_Pre, FourByteAbgr, FourByteAbgr_Pre, IntRGB, IntBGR, 3ByteBGR. >> . As expected, the test fails without the fix on JDK 8 and JDK 7 versions & passes with JDK 9-internal containing the fix. >> >> 3 ) Explanation on Code Changes : >> . With multiple reviews and changes, today the code fixes the bug and is well optimized as well. >> . For ease of reviewer and effort in review, I 've explained the logic with /* comment statements */ herewith. >> . Note: These comments don't figure in the webrev. >> As one cannot guarantee how /* comments */ within macros would be perceived by compiler across different platforms. >> >> #define GlyphListAABlend4ByteArgb(DST, GLYPH_PIXELS, PIXEL_INDEX, DST_PTR, \ >> FG_PIXEL, PREFIX, SRC_PREFIX) \ >> do { \ >> DeclareAlphaVarFor4ByteArgb(resA) \ >> DeclareCompVarsFor4ByteArgb(res) \ >> jint mixValSrc = GLYPH_PIXELS[PIXEL_INDEX]; \ >> if (mixValSrc) { \ >> /* Evaluating srcColor components */ \ >> if (mixValSrc != 0xff) { \ >> /* No-op. Retained to match reference as SRCOVER_MASK_FILL */ \ >> PromoteByteAlphaFor4ByteArgb(mixValSrc); \ >> /* Glyph mask determines visibility of the srcColor */ \ >> resA = MultiplyAlphaFor4ByteArgb(mixValSrc, SRC_PREFIX ## A); \ >> MultiplyAndStore4ByteArgbComps(res, resA, SRC_PREFIX); \ >> } else { \ >> /* If mixValSrc and srcA are maximum, then result color is */ \ >> /* opaque. Hence the fast path to store foreground pixel */ \ >> /* color and return. */ \ >> if (SRC_PREFIX ## A == MaxValFor4ByteArgb) { \ >> Store ## DST ## PixelData(DST_PTR, PIXEL_INDEX, \ >> FG_PIXEL, PREFIX); \ >> break; \ >> } \ >> /* This is understood easier with floating point logic. */ \ >> /* 1.0f is max value used in floating point calculation */ \ >> /* (1.0f * srcA) gives srcA. Hence we directly consider */ \ >> /* srcA without Multiply with glyph mask. */ \ >> resA = SRC_PREFIX ## A; \ >> MultiplyAndStore4ByteArgbComps(res, \ >> SRC_PREFIX ## A, \ >> SRC_PREFIX); \ >> } \ >> /* Evaluating dstColor components */ \ >> /* This is required only when resA(i.e., srcA) is not maximum */ \ >> if (resA != MaxValFor4ByteArgb) { \ >> DeclareAndInvertAlphaVarFor4ByteArgb(dstF, resA) \ >> DeclareAndClearAlphaVarFor4ByteArgb(dstA) \ >> DeclareCompVarsFor4ByteArgb(dst) \ >> DeclareCompVarsFor4ByteArgb(tmp) \ >> /* Based on the pixelFormat we could reduce calculations */ \ >> /* done to load the color and alpha components */ \ >> if (!(DST ## IsPremultiplied)) { \ >> Load ## DST ## To4ByteArgb(DST_PTR, pix, PIXEL_INDEX, \ >> dstA, dstR, dstG, dstB); \ >> Store4ByteArgbCompsUsingOp(tmp, =, dst); \ >> } else { \ >> Declare ## DST ## AlphaLoadData(DstPix) \ >> jint pixelOffset = PIXEL_INDEX * (DST ## PixelStride); \ >> DST ## DataType *pixelAddress = PtrAddBytes(DST_PTR, \ >> pixelOffset); \ >> /* The macro's implementation loads color components */ \ >> /* without divide by alpha adjustment as required for */ \ >> /* subsequent calculations. Note: This is used only */ \ >> /* with preMultiplied alpha based pixel formats */ \ >> LoadAlphaFrom ## DST ## For4ByteArgb(pixelAddress, \ >> DstPix, \ >> dst); \ >> Postload4ByteArgbFrom ## DST(pixelAddress, \ >> DstPix, \ >> tmp); \ >> } \ >> /* Avoid blending operatons if dst is fully transparent */ \ >> if (dstA) { \ >> /* dstA would be 0 if either of the following is true. */ \ >> /* 1. srcA is max. Parent if condition validates this. */ \ >> /* 2. dstA is zero. The current if condition validates */ \ >> /* Henceforth, the following Multiply need not be moved*/ \ >> /* ahead of the if condition. This also helps to better*/ \ >> /* performance */ \ >> dstA = MultiplyAlphaFor4ByteArgb(dstF, dstA); \ >> resA += dstA; \ >> /* Declares blendF variable and assigns appropriate */ \ >> /* alpha value. The definitions are contained in the*/ \ >> /* header files of respective pixel formats */ \ >> DeclareAndInit ## DST ## SrcOverDstBlendFactor(dstF, \ >> dstA, \ >> blendF); \ >> /* This is understood easier with floating point logic.*/ \ >> /* 1.0f is max value used in floating point calculation*/ \ >> /* (1.0f * tmp) gives tmp. Hence we avoid 3 Multiply */ \ >> /* operations and add the loaded color to result */ \ >> if (blendF != MaxValFor4ByteArgb) { \ >> MultiplyAndStore4ByteArgbComps(tmp, \ >> blendF, \ >> tmp); \ >> } \ >> Store4ByteArgbCompsUsingOp(res, +=, tmp); \ >> } \ >> } \ >> /* In the above calculations, color values are multiplied with */ \ >> /* with alpha. This is perfectly fine for pre-Multiplied alpha */ \ >> /* based pixel formats. For non pre-multiplied alpha based */ \ >> /* pixel formats, the alpha is removed from color components */ \ >> /* and then stored to the resulting color. */ \ >> if (!(DST ## IsOpaque) && \ >> !(DST ## IsPremultiplied) && resA && \ >> resA < MaxValFor4ByteArgb) \ >> { \ >> DivideAndStore4ByteArgbComps(res, res, resA); \ >> } \ >> Store ## DST ## From4ByteArgbComps(DST_PTR, pix, \ >> PIXEL_INDEX, res); \ >> } \ >> } while (0); >> >> My apologies if the above code did not appear on the final webrev email. >> ( In few instances, the newlines don't appear in plain-text format ) >> >> Kindly review the changes present in webrev and provide your views. >> If the changes are good, we could take up for the code check-in. >> >> Thank you for your time in review >> Have a good day >> >> Prahalad N. >> >> >> >> -----Original Message----- >> From: Jim Graham >> Sent: Tuesday, April 05, 2016 3:07 AM >> To: Prahalad Kumar Narayanan; Sergey Bylokhov; Philip Race >> Cc: Praveen Srivastava >> Subject: Re: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: >> Antialiased text on translucent backgrounds gets bright artifacts >> >> Hi Prahalad, >> >> Can I see the webrev diffs for the "today's experiment" code with the new macro? >> >> Also, Did you test this with opaque destinations? The most common use >> of text is on an opaque destination, so that would matter more. I >> would >> suggest: INT_RGB, THREE_BYTE_BGR, INT_ARGB, INT_ARGB_PRE in that order of precedence of importance. Also, test with translucent colors, though those are less important than opaque colors. >> >> I'm still looking at why the non-pre would be slower than the pre. >> About the only difference is the one line "if (!PRE) { DSTF = DSTA; }". >> One suggestion might be to move the test for transparent destination up a couple of lines, and to get rid of the extra "DSTF = dstA" >> assignement with the following structure: >> >> dstA = Mult...(); >> if (dstA) { >> resA += dstA; >> Declare... >> Postload... >> if (DST ## IsPremultiplied) { >> MultiplyAndStore(..., DSTF, ...); >> } else { >> MultiplyAndStore(..., dstA, ...); >> } >> Store... >> } >> >> Basically, dstA == 0 is the actual test for "do we need to even try to blend the destination in here". If it is zero then there is no need to add dstA to resA and there is no need to adjust the factor we blend by (MultiplyAndStore). It can be triggered by either a transparent destination pixel or an opaque source pixel, but either way, dstA is the right test, not DSTF. The second part, eliminating the DSTF=dstA assignment, gets rid of a line that might trip up the optimizer by simply having the macro expand differently for the two types. To be even more streamlined, we could create a new set of macros: >> >> // In the header files for PRE types: >> #define SRCOVER_DST_BLEND_FACTOR_(dF, dA) (dF) >> // In the header files for non-PRE types: >> #define SRCOVER_DST_BLEND_FACTOR_(dF, dA) (dA) >> >> Then we wouldn't need the test above for "if (DST ## Pre)", we would just expand the macro with: >> MultiplyAndStore(..., SRCOVER_DST_BLEND_FACTOR ## DST(DSTF, dstA), ...) which would hopefully confuse the optimizer even less. >> >> If you want to really eliminate the pixel address computations, you could rewrite the calling loop so that it steps along a pixel pointer rather than using indexing. Have the calling function/macro set up a pRas pointer to the pixel and step that along the row by TYPE##PixelStride as it iterates across the glyph, then hand that into the Glyph blend macro as DST_PTR (and eliminate PIXEL_INDEX as it would be "0" in this case)... >> >> ...jim >> >> On 4/4/16 4:37 AM, Prahalad Kumar Narayanan wrote: >>> Dear Jim >>> >>> Good day to you. >>> >>> ( Just in-case, you had missed my long Friday 's email ) >>> >>> Quick Recap of Proceedings >>> >>> 1.On Friday, I had profiled two solutions that fix the bug- >>> JDK-8015070, using Java2D Bench >>> >>> 2.Profiling was done for 16 test cases with different combinations of >>> >>> a.Font Style: Plain, Bold, Italic, Bold-Italic >>> >>> b.Font Size: 12, 20, 36, 72 >>> >>> 3.Result from Friday 's profiling experiments: >>> >>> a.Regular Solution (Un-optimized) : This was observed to be faster >>> for IntArgb pixel format >>> >>> b.Optimized Solution (based on SrcOver_MaskFill with fast path) : >>> This was observed to be faster for IntArgb_Pre pixel format >>> >>> Update from Today's Experiments >>> >>> 1.First, I understood that new calculations introduced (pixelAddress >>> computation) impacted performance of optimized solution in IntArgb format. >>> >>> 2.Henceforth, I made the following changes, while loading destination color: >>> >>> a.Check if the pixel format is PreMultiplied >>> >>> b.If the format is preMultiplied, then > take up new calculations and >>> use LoadAlphaFrom ## DST ## For4ByteArgb macro that does *Not* cause >>> divide by alpha adjustment >>> >>> c.If the format is regular Argb, then > take up loading of colors >>> using standard Load ## DST ## To4ByteArgb >>> >>> 3.Once the release build was available, Java2D Bench was re-run >>> (using pre-saved options file) >>> >>> Result from Bench metrics: >>> >>> a.In most of the test cases, the optimized solution has higher metric : >>> Avg characters/ second for both IntArgb and IntArgb_Pre formats >>> >>> b.In 6 / total-16 test cases, optimized solution was marginally lower >>> than the metrics of Regular un-optimized algorithm (only for >>> IntArgb_Pre) >>> >>> c.However, J2DAnalyzer reported that even these 6-test cases were >>> within 10% deviation. Hence the algorithms were categorized to be >>> 'same' in performance. >>> >>> Suggestion Required >>> >>> 1.The attached zip file, contains Algorithms.cpp - Which lists down >>> different algorithms profiled so far. >>> >>> 2.I 've introduced comments within the macro to explain the change. >>> >>> a.Note: These comments will be removed from the final source code to >>> be checked in. >>> >>> 3.Kindly review the latest algorithm (for any issues/ bugs) and >>> provide your suggestions. >>> >>> a.latest algorithm can be easily traced by searching for >>> "LoadOptimized Algorithm v3" within the file. >>> >>> Thank you for your time in review & detailed feedback that you get >>> every time. >>> >>> Every such review improves the quality of code & the solution >>> >>> Prahalad N. >>> >>> *From:* Prahalad Kumar Narayanan >>> *Sent:* Friday, April 01, 2016 5:07 PM >>> *To:* Jim Graham; Sergey Bylokhov; Philip Race >>> *Cc:* Praveen Srivastava >>> *Subject:* RE: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: >>> Antialiased text on translucent backgrounds gets bright artifacts >>> >>> Dear Jim >>> >>> Good day to you. >>> >>> Thanks for your suggestions in the reviews that has evolved the fix >>> to the bug. >>> >>> As guided by you, I measured the performance of Text Rendering with >>> Text Antialiasing Hint on using Java2D Bench Tool. >>> >>> Solutions Profiled: >>> >>> We have two solutions - Un optimized solution and Optimized >>> solution modelled as per SRCOVER_MASKFILL >>> >>> ( Both the solutions were profiled on windows x86_64 with >>> JDK 9-internal Release build ) >>> >>> Test Cases Profiled: >>> >>> With Font set to : Lucida sans, different combinations of >>> >>> Font Styles : Plain, Bold, Italic, Bold Italic && >>> >>> Font Sizes : 12, 20, 36, 72 points were tested. >>> >>> Attached herewith: JDK8015070-Profiling Data.zip >>> >>> The archive contains: >>> >>> 1. Algorithms.cpp : Just to have a quick glance of all the >>> algorithms that we have tried so far. >>> >>> 2. *.txt Files : For each test, Java2D bench >>> reports the average metrics/second. >>> >>> The text file >>> contains collection of all such average metric for nearly 16 >>> different test cases. >>> >>> 3. res Output : .res output from each of the test runs. >>> >>> Observation from J2DBench Reports >>> >>> 1. I could not get time to run the Analyzer tool across >>> each of these *.res files. I shall do them on Monday. >>> >>> 2. From the summary text ( average chars per. Second ) that >>> J2DBench reported, >>> >>> Un-optimized solution seems to be better for >>> IntArgb pixel format and >>> >>> Optimized solution is better for IntArgb_Pre >>> pixel format by significant margin. >>> >>> 3. I tried to improve the optimized algorithm (based on >>> SRCOVER_MASKFILL ) further by adding a if (dstA) { ... >>> >>> Though there is a marginal improvement, the >>> optimized solution could not exceed numbers of regular algorithm (for >>> IntArgb pixel format) >>> >>> This could be due to the extra calculations that >>> we do in-order to load color components separately. >>> >>> However, for IntArgb_Pre pixel format, the >>> optimized solution is way-ahead and gives better performance. >>> >>> 4. In the summary reports, you will find >>> CompatibleBufferedImage( Translucent ) as well. >>> >>> In a separate experiment, I found that the pixel >>> format for compatible buffered image got mapped IntArgb_Pre. >>> >>> Thus, the performance numbers match with that of >>> IntArgb_Pre pixel format >>> >>> At the present moment, I 'm confused on the solution would be better >>> to fix the Bug. >>> >>> Kindly share your views and thoughts >>> >>> Thank you >>> >>> Have a good day >>> >>> Prahalad N. >>> >>> -----Original Message----- >>> From: Jim Graham >>> Sent: Thursday, March 31, 2016 1:46 AM >>> To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net >>> ; Sergey Bylokhov >>> Subject: Re: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: >>> Antialiased text on translucent backgrounds gets bright artifacts >>> >>> Hi Prahalad, >>> >>> Benchmarks must run for a significant period of time to be valid. >>> >>> Measuring with nanoTime() is fine, but the run times should exceed at >>> least a couple of seconds, not a few nanoseconds. You might want to >>> use Java2DBench instead (in src/demo/share/java2d in the java.desktop >>> repo), which calibrates test times, does multiple runs, and includes >>> an analyzer to compare results from multiple test runs... >>> >>> ...jim >>> >>> On 3/30/2016 4:27 AM, Prahalad Kumar Narayanan wrote: >>> >>>> Hello Jim and Everyone on Java2D Group >>> >>>> >>> >>>> Good day to you. >>> >>>> >>> >>>> A quick follow-up to Review Request on bug: >>> >>>> Bug : JDK-8015070 >>> >>>> Bug Link :https://bugs.openjdk.java.net/browse/JDK-8015070 >>> >>>> >>> >>>> Thank you Jim for the detailed feedback. >>> >>>> >>> >>>> It takes a lot of time not only in performing the review, but also in getting the feedback with clear words. >>> >>>> In each review, the solution definitely gets better & better. I 'm >>> >>>> happy about it...! :) >>> >>>> >>> >>>> Quick Inferences from previous feedback: >>> >>>> >>> >>>> Incorporating the fast path into current logic: >>> >>>> 1. I agree with you on this point and I noticed this when we modelled the solution as per the mask fill. >>> >>>> 2. I ignored it initially for two reasons, >>> >>>> a. The statement - if (resA != MaxValFor4ByteArgb)... follows srcColor pre-multiplication step and this will ensure to skip most of the blending calculations pertaining to destination. >>> >>>> b. Any addition / tweaks to current logic, might deviate from the SRCOVER_MASKFILL reference model. >>> >>>> Many a time, managing code with similar logic across implementation helps a lot. >>> >>>> 3. As you said, including the fast path will avoid few multiplications and if checks too. >>> >>>> The changes are available in the current webrev. >>> >>>> Link: >>> >>>> http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.03/ >>> >>>> >>> >>>> Profiling method, and Metrics: >>> >>>> 1. The profiling method that was done yesterday was mere >>>> execution of the regression test (available in the webrev) and time >>>> measured with System.currentTimeMillis API >>> >>>> Since only one iteration was run, the time soared into milli seconds. This could be due to internal glyph caching mechanism. >>> >>>> 2. Today, I evolved the regression test, into a benchmark that does the following: >>> >>>> a. Select Font style : {Plain, Bold, Italic, Bold >>>> Italic} >>> >>>> b. Select Font size : {20, 40, 60, 80} >>> >>>> c. Trigger drawstring once before benchmark is run. This is to ensure, the font subsystem is done with glyph caching internally. >>> >>>> d. Use famous string that has all characters-" The quick brown fox jumps over the lazy dog. 0123456789. " >>> >>>> e. For every style-size combination - run the test >>>> for 20 iterations and take the average. (Note: Font is fixed to >>>> 'verdana' ) >>> >>>> f. Modify the precision from System.currentTimeMillis to System.nanoTime() and reduce elapsedTime to micro seconds. >>> >>>> >>> >>>> 3. With the above setup in code, my observation on windows is as follows: >>> >>>> a. In many cases, The optimized logic is either equal-to (or) better in performance than the un-optimized logic. >>> >>>> The difference is very minimal - few tens to few hundreds of micro-seconds. >>> >>>> b. The optimized algorithm improves performance for Pre-multiplied alpha based destination buffer. >>> >>>> c. There are occasional huge deviations where optimized logic seems to take longer time. >>> >>>> These could be due to external factors >>>> like- stalls for memory, bus io etc., >>> >>>> Since, the deviation is in micro seconds, I believe, it may not be a concern. >>> >>>> d. The complete list of time measurement taken up >>>> on windows x86_64 release build is as-follows- >>> >>>> I 'm not sure, how the data appears in the final webrev-email. >>> >>>> Kindly excuse, if the data is un-readable. >>> >>>> >>> >>>> Platform : Windows x86_64 Release Build Algorithm : Unoptimized. >>> >>>> webrev.00 >>> >>>> ```````````````````````````````````````````````````````````````````` >>>> ` >>>> ` >>> >>>> ```` Executing Bench For Image Type: IntArgb >>> >>>> -Font Style: Plain /Font Size: 20 /Time consumed (us): 84.742 >>> >>>> -Font Style: Plain /Font Size: 40 /Time consumed (us): 318.395 >>> >>>> -Font Style: Plain /Font Size: 60 /Time consumed (us): 657.474 >>> >>>> -Font Style: Plain /Font Size: 80 /Time consumed (us): 813.079 >>> >>>> -Font Style: Bold /Font Size: 20 /Time consumed (us): 386.380 >>> >>>> -Font Style: Bold /Font Size: 40 /Time consumed (us): 339.301 >>> >>>> -Font Style: Bold /Font Size: 60 /Time consumed (us): 492.631 >>> >>>> -Font Style: Bold /Font Size: 80 /Time consumed (us): 625.812 >>> >>>> -Font Style: Italic /Font Size: 20 /Time consumed (us): 235.059 >>> >>>> -Font Style: Italic /Font Size: 40 /Time consumed (us): 320.180 >>> >>>> -Font Style: Italic /Font Size: 60 /Time consumed (us): 474.558 >>> >>>> -Font Style: Italic /Font Size: 80 /Time consumed (us): 1188.169 >>> >>>> -Font Style: Bold-Italic /Font Size: 20 /Time consumed (us): >>>> 426.988 >>> >>>> -Font Style: Bold-Italic /Font Size: 40 /Time consumed (us): >>>> 374.064 >>> >>>> -Font Style: Bold-Italic /Font Size: 60 /Time consumed (us): >>>> 732.375 >>> >>>> -Font Style: Bold-Italic /Font Size: 80 /Time consumed (us): >>>> 864.68 >>> >>>> >>> >>>> Executing Bench For Image Type: IntArgb_Pre >>> >>>> -Font Style: Plain /Font Size: 20 /Time consumed (us): 129.768 >>> >>>> -Font Style: Plain /Font Size: 40 /Time consumed (us): 206.299 >>> >>>> -Font Style: Plain /Font Size: 60 /Time consumed (us): 249.941 >>> >>>> -Font Style: Plain /Font Size: 80 /Time consumed (us): 362.372 >>> >>>> -Font Style: Bold /Font Size: 20 /Time consumed (us): 145.096 >>> >>>> -Font Style: Bold /Font Size: 40 /Time consumed (us): 151.589 >>> >>>> -Font Style: Bold /Font Size: 60 /Time consumed (us): 240.972 >>> >>>> -Font Style: Bold /Font Size: 80 /Time consumed (us): 331.894 >>> >>>> -Font Style: Italic /Font Size: 20 /Time consumed (us): 95.028 >>> >>>> -Font Style: Italic /Font Size: 40 /Time consumed (us): 245.300 >>> >>>> -Font Style: Italic /Font Size: 60 /Time consumed (us): 270.379 >>> >>>> -Font Style: Italic /Font Size: 80 /Time consumed (us): 398.139 >>> >>>> -Font Style: Bold-Italic /Font Size: 20 /Time consumed (us): >>>> 93.243 >>> >>>> -Font Style: Bold-Italic /Font Size: 40 /Time consumed (us): >>>> 475.406 >>> >>>> -Font Style: Bold-Italic /Font Size: 60 /Time consumed (us): >>>> 280.085 >>> >>>> -Font Style: Bold-Italic /Font Size: 80 /Time consumed (us): >>>> 357.486 >>> >>>> >>> >>>> Platform : Windows x86_64 Release Build Algorithm : Optimized. >>> >>>> webrev.03 >>> >>>> ```````````````````````````````````````````````````````````````````` >>>> ` >>>> ` >>> >>>> ```` Executing Bench For Image Type: IntArgb >>> >>>> -Font Style: Plain /Font Size: 20 /Time consumed (us): 120.954 >>> >>>> -Font Style: Plain /Font Size: 40 /Time consumed (us): 364.871 >>> >>>> -Font Style: Plain /Font Size: 60 /Time consumed (us): 561.799 >>> >>>> -Font Style: Plain /Font Size: 80 /Time consumed (us): 653.390 >>> >>>> -Font Style: Bold /Font Size: 20 /Time consumed (us): 261.566 >>> >>>> -Font Style: Bold /Font Size: 40 /Time consumed (us): 311.054 >>> >>>> -Font Style: Bold /Font Size: 60 /Time consumed (us): 490.735 >>> >>>> -Font Style: Bold /Font Size: 80 /Time consumed (us): 656.559 >>> >>>> -Font Style: Italic /Font Size: 20 /Time consumed (us): 314.289 >>> >>>> -Font Style: Italic /Font Size: 40 /Time consumed (us): 378.750 >>> >>>> -Font Style: Italic /Font Size: 60 /Time consumed (us): 491.181 >>> >>>> -Font Style: Italic /Font Size: 80 /Time consumed (us): 770.172 >>> >>>> -Font Style: Bold-Italic /Font Size: 20 /Time consumed (us): >>>> 375.336 >>> >>>> -Font Style: Bold-Italic /Font Size: 40 /Time consumed (us): >>>> 571.371 >>> >>>> -Font Style: Bold-Italic /Font Size: 60 /Time consumed (us): >>>> 548.300 >>> >>>> -Font Style: Bold-Italic /Font Size: 80 /Time consumed (us): >>>> 714.526 >>> >>>> >>> >>>> Executing Bench For Image Type: IntArgb_Pre >>> >>>> -Font Style: Plain /Font Size: 20 /Time consumed (us): 45.026 >>> >>>> -Font Style: Plain /Font Size: 40 /Time consumed (us): 219.016 >>> >>>> -Font Style: Plain /Font Size: 60 /Time consumed (us): 279.617 >>> >>>> -Font Style: Plain /Font Size: 80 /Time consumed (us): 282.829 >>> >>>> -Font Style: Bold /Font Size: 20 /Time consumed (us): 51.809 >>> >>>> -Font Style: Bold /Font Size: 40 /Time consumed (us): 117.563 >>> >>>> -Font Style: Bold /Font Size: 60 /Time consumed (us): 508.049 >>> >>>> -Font Style: Bold /Font Size: 80 /Time consumed (us): 402.802 >>> >>>> -Font Style: Italic /Font Size: 20 /Time consumed (us): 79.320 >>> >>>> -Font Style: Italic /Font Size: 40 /Time consumed (us): 227.473 >>> >>>> -Font Style: Italic /Font Size: 60 /Time consumed (us): 330.488 >>> >>>> -Font Style: Italic /Font Size: 80 /Time consumed (us): 353.782 >>> >>>> -Font Style: Bold-Italic /Font Size: 20 /Time consumed (us): >>>> 54.687 >>> >>>> -Font Style: Bold-Italic /Font Size: 40 /Time consumed (us): >>>> 235.505 >>> >>>> -Font Style: Bold-Italic /Font Size: 60 /Time consumed (us): >>>> 227.205 >>> >>>> -Font Style: Bold-Italic /Font Size: 80 /Time consumed (us): >>>> 324.308 >>> >>>> >>> >>>> Updated webrev with changes for the fast-path : >>> >>>> http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.03/ >>> >>>> Kindly review and provide your suggestions. >>> >>>> >>> >>>> Thank you once again for detailed review and feedback Have a good >>>> day >>> >>>> >>> >>>> Prahalad N. >>> >>>> >>> >>>> >>> >>>> >>> >>>> -----Original Message----- >>> >>>> From: Jim Graham >>> >>>> Sent: Wednesday, March 30, 2016 2:46 AM >>> >>>> To: Prahalad Kumar Narayanan;2d-dev at openjdk.java.net >>>> ; Sergey Bylokhov >>> >>>> Subject: Re: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: >>> >>>> Antialiased text on translucent backgrounds gets bright artifacts >>> >>>> >>> >>>> Hi Prahalad, >>> >>>> >>> >>>> This latest version looks like it should produce correct answers. >>> >>>> >>> >>>> I'd like to see benchmark results on more platforms, particularly Windows since the different compilers may optimize these things differently. >>> >>>> >>> >>>> Also, you didn't mention what data set you used for benchmarking. >>>> I'd >>> >>>> like to see benchmark results for small, medium and large font >>>> sizes, >>> >>>> and possibly bold and italic fonts as well. The reason is that the >>> >>>> relative ratios of "empty glyph pixels" to "partial glyph pixels" to >>> >>>> "fully covered glyph pixels" changes depending on the font type and >>> >>>> size so if you made one of those faster and another slower then the >>> >>>> results may be seen as a gain in one type of test if you only test >>>> one >>> >>>> font type and size and it happens to match the part of the code that >>> >>>> is more streamlined. Also, for small font sizes the per-glyph >>> >>>> overhead might hide per-pixel issues. Please share which fonts and >>> >>>> sizes you used for testing and consider using some different sizes, >>> >>>> including something very large like 36 or 48 points (something with >>> >>>> large areas of opaque >>> >>>> pixels) as well as more normal sizes that appear in GUIs. Also, bold fonts can have a higher percentage of opaque pixels. >>> >>>> >>> >>>> In particular... >>> >>>> >>> >>>> This latest version is missing the "fast path" from the existing code for the case of srcA == 255 and glyphA == 255 where it just stores the FG_PIXEL values directly. For large fonts/glyphs that case may be as important as detecting empty glyph pixels. >>> >>>> >>> >>>> On the other hand, an additional "if" may cause the compiler to generate less efficient code as per Sergey's concern. Since this "if" eliminates some multiplies and possibly some divides, I'd hope it would be a win-win. >>> >>>> >>> >>>> You could add the fast path back inside the case where mixValSrc is 255 and just test srcA for 255 and do the Store ## DST ## PixelData() macro that used to be at the end of the block in the existing code, and then use "break;" to escape out of the do/while surrounding the whole macro so it moves on to the next pixel. >>> >>>> >>> >>>> (Arguably, we might want to consider teaching our SRCOVER_MASKFILL >>>> to >>> >>>> do the same thing. I think that was one of the added values of >>>> having >>> >>>> a separate GLYPH loop, but really both should be optimizing that >>> >>>> case...) >>> >>>> >>> >>>> I can see now that the macro switch to use the same macro set as SRCOVER_MASKFILL required you to compute the pixel address, as you noted in your summary. It makes the new macro more cumbersome and makes it look like it's doing a bit more work per-pixel, but in reality I think the overall operations end up being the same as long as the compiler optimizes the deliberate multiplications the same way it did for implicit multiplications in the "pRas[foo]" and "pRas[foo*4]" code that was being generated previously. Benchmarks will tell us if we're good there... >>> >>>> >>> >>>> ...jim >>> >>>> >>> >>>> >>> >>>> On 3/28/16 5:33 AM, Prahalad Kumar Narayanan wrote: >>> >>>>> Hello Everyone on Java2D Group >>> >>>>> >>> >>>>> Good day to you. >>> >>>>> >>> >>>>> This is a follow-up to Review Request on bug: >>> >>>>> Bug : JDK-8015070 >>> >>>>> Bug Link :https://bugs.openjdk.java.net/browse/JDK-8015070 >>> >>>>> >>> >>>>> First, Thanks to Jim and Sergey for their feedback on the changes so far. >>> >>>>> >>> >>>>> Inferences from Jim 's Feedback on Loading destination colors: >>> >>>>> 1. The API or Macro that I had earlier used to Load DST colors, indeed, adjusted destination color components with divide-by-alpha if destination was already pre-multiplied. >>> >>>>> My apologies.. I should have spotted this error at the first iteration itself. >>> >>>>> 2. Due to the divide-by-alpha adjustment, the remaining >>>>> logic would become incorrect. ( Especially, the multiplication with >>>>> dstF based on pre-mulitplication status ) >>> >>>>> 3. Correct API is being used now, and the dstColor components are loaded directly without any divide-by-alpha adjustment. >>> >>>>> >>> >>>>> Inferences from Sergey's Feedback on Performance. >>> >>>>> 1. To set the context for everyone, the logic present in the current webrev.02 is modelled as per SRCOVER_MASKFILL. >>> >>>>> There are multiple if (...) conditions that remove un-necessary blending calculations. Ideally this should improve performance. >>> >>>>> However, since some data are not readily available (as present in SRCOVER_MASKFILL), few additional calculations have been added. >>> >>>>> They are: pre-multiplying srcColor with alpha and assigning to res. >>> >>>>> Finding the correct address of Pixel using DST_PTR and PixelStride. >>> >>>>> Henceforth, as Sergey suggests, Observation on performance will be beneficial. >>> >>>>> 2. The performance of the new logic was measured with >>>>> linux-x86_64-normal-server-release config and compared with the >>>>> logic used in un-optimized code in webrev.00 >>> >>>>> 3. Result: The newer logic provides a fractional gain (about 15 - 20 ms) over the older logic. >>> >>>>> >>> >>>>> Other Subtle Changes: >>> >>>>> 1. The test file has been renamed from >>>>> AADrawStringArtifact.java to more meaningful - >>>>> AntialiasedTextArtifact.java >>> >>>>> 2. The test file tests for both TYPE_INT_ARGB and TYPE_INT_ARGB_PRE BufferedImage formats. >>> >>>>> The code has been well commented to explain the logic used in every function. >>> >>>>> >>> >>>>> Kindly take your time to review the changes in the webrev link mentioned below and provide your suggestions. >>> >>>>> Webrev Link: >>> >>>>> http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.02/ >>> >>>>> >>> >>>>> >>> >>>>> Thank you for your time in review >>> >>>>> Have a good day >>> >>>>> >>> >>>>> Prahalad N. >>> >>>>> >>> >>>>> >>> >>>>> -----Original Message----- >>> >>>>> From: Jim Graham >>> >>>>> Sent: Thursday, March 24, 2016 7:57 AM >>> >>>>> To: Prahalad Kumar Narayanan;2d-dev at openjdk.java.net >>>>> >>> >>>>> Subject: Re: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: >>> >>>>> Antialiased text on translucent backgrounds gets bright artifacts >>> >>>>> >>> >>>>> Hi Prahalad, >>> >>>>> >>> >>>>> (On a side note - ouch! I came up with these macros in the first >>> >>>>> place, but 20 years later I'm now realizing just how hard they are >>>>> to >>> >>>>> navigate and review. My apologies...) >>> >>>>> >>> >>>>> The macro you are still using to load the destination data is one that loads it to non-premultiplied components, which means it will divide out the alpha if the destination is PRE. The rest of the logic assumes that the components were loaded without any adjustment of their premultiplication so not only is that division an unnecessary operation, it makes the following math wrong. >>> >>>>> >>> >>>>> The SRCOVER_MASKFILL macro seems to use "Postload ## STRATEGY ## From ## TYPE" which seems to load them into separate components without any adjustment of their pre-multiplication status. This is paired with "LoadAlphaFrom ## TYPE ## For ## STRATEGY" to load just the destination alpha for computing dstF... >>> >>>>> >>> >>>>> ...jim >>> >>>>> >>> >>>>> On 3/22/16 4:35 AM, Prahalad Kumar Narayanan wrote: >>> >>>>>> Hello Everyone on Java2D Group >>> >>>>>> >>> >>>>>> Good day to you. >>> >>>>>> >>> >>>>>> This is a Follow-up to Review Request on the bug: >>> >>>>>> Bug : JDK-8015070 Anti-aliased Text on Translucent background gets bright artifacts >>> >>>>>> Bug Link :https://bugs.openjdk.java.net/browse/JDK-8015070 >>> >>>>>> >>> >>>>>> First, Sincere thanks to Jim for his valuable feedback. >>> >>>>>> 1. As Jim correctly mentioned, SRCOVER_MASKFILL has a similar logic to blend two Translucent colors based on an Alpha mask. >>> >>>>>> 2. The calculations are exactly the same as the changes in previous webrev. >>> >>>>>> However the logic of SRCOVER_MASKFILL is 'Optimized' to reduce the number of computations. >>> >>>>>> 3. This optimization is definitely required because, the logic is executed for every single pixel in a glyph. >>> >>>>>> Example: If a string is made up of 5 English >>>>>> characters with each character having 32 x 32 pixels, >>> >>>>>> The anti-aliasing logic will be executed for 5 x 32 x 32 iterations. >>> >>>>>> Reducing computation per pixel will imply a huge benefit for complete drawString operation. >>> >>>>>> >>> >>>>>> Observation from SRCOVER_MASKFILL >>> >>>>>> 1. The mask fill reduces computations by through multiple if(...) conditions. >>> >>>>>> Each if condition affirms whether the next set of computations are required. >>> >>>>>> 2. Optimization 1: If mask value is 0- skip entire logic. >>> >>>>>> 3. Optimization 2: If mask value is maximum, say 255, take >>>>>> srcA directly without multiplying with maskAlpha ( Reason: 1 * >>>>>> srcAlpha = srcAlpha ) >>> >>>>>> 4. Optimization 3: Compute pre-multiplied resColor in two steps. First with srcColor and then with dstColor. >>> >>>>>> If the resAlpha from 1st step (i.e., srcColor) is fully opaque, avoid blending dstColor altogether. >>> >>>>>> >>> >>>>>> Changes in Current Webrev.01 >>> >>>>>> 1. The fix for the current bug is modelled based on SRCOVER_MASKFILL. >>> >>>>>> 2. The changes have been verified to work on windows, linux and mac operating systems. >>> >>>>>> 3. The automated Test file- AADrawStringArtifact.java runs >>>>>> as expected >>> >>>>>> Identifies artifact & throws exception when run on JDK 7 and 8. >>> >>>>>> With JDK9, the test file returns without error. >>> >>>>>> 3. JPRT build has been run to ensure, changes build on all supported platforms. >>> >>>>>> JPRT job link : >>> >>>>>> http://scaaa637.us.oracle.com//archive/2016/03/2016-03-22-070604.p >>>>>> ra >>> >>> >>>>>> h >>> >>>>>> n >>> >>>>>> ara-linux.client >>> >>>>>> >>> >>>>>> Kindly review the changes in the below mentioned link and provide >>>>>> your views >>> >>>>>> Webrev Link : >>> >>>>>> http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.01/ >>> >>>>>> >>> >>>>>> >>> >>>>>> Thank you for your time in review >>> >>>>>> Have a good day >>> >>>>>> >>> >>>>>> Prahalad N. >>> >>>>>> >>> >>>>>> >>> >>>>>> -----Original Message----- >>> >>>>>> From: Jim Graham >>> >>>>>> Sent: Friday, March 18, 2016 6:07 AM >>> >>>>>> To: Prahalad Kumar Narayanan;2d-dev at openjdk.java.net >>>>>> >>> >>>>>> Subject: Re: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: >>> >>>>>> Antialiased text on translucent backgrounds gets bright artifacts >>> >>>>>> >>> >>>>>> Hi Prahalad, >>> >>>>>> >>> >>>>>> This basically boils down to "alpha blending math needs to be performed in premultiplied form" and the existing code was not doing that. >>> >>>>>> >>> >>>>>> Your changes do add a pre-multiplication step to the math in two >>> >>>>>> places >>> >>>>>> - when you mix the src alpha and the glyph alpha at the top of the macro, and again when you do the Multiply(dst, dstA, dst) step in the middle. In that sense, the new math is correct. >>> >>>>>> >>> >>>>>> However, it is not the optimal way to implement this. In >>> >>>>>> particular, the macro used here to load the data from the >>> >>>>>> destination is the one that loads it into 4 ARGB non-premultiplied >>> >>>>>> values. If the destination is non-PRE, then your added multiply >>> >>>>>> step is exactly what is needed, but it could be combined with the >>> >>>>>> multiply that will happen later in the blending equation, so it is >>> >>>>>> an added step rather than a fixed fraction in the existing MultMultAdd parameters. >>> >>>>>> Additionally, if the destination is already PRE, then the macro >>> >>>>>> being used to load the dst pixel data there will have done a >>>>>> divide >>> >>>>>> step to divide out the alpha from the destination, only to have >>>>>> you >>> >>>>>> reverse that math with your new >>> >>>>>> Multiply() step. That's a lot of math to end up with a NOP. >>> >>>>>> >>> >>>>>> The MUL8 you added for the srcA and glyph value is needed, that change is good. Since it is common for glyph pixels to have zero alpha, you might want to test the glyph alpha for 0 and skip the pixel before you do the multiply, though. This would add one more if, but it would be a common case. >>> >>>>>> >>> >>>>>> The trickier part is to load the destination components without un-premultiplying them. Unfortunately there is no "Load...ToArgbPre" >>> >>>>>> macro to parallel the Load macro used in the function. Perhaps there should be, but you'd still end up with an extra multiply step as I mentioned above because you can fold the premultiplication of the dst data into the MultMultAdd by carefully choosing the parameters you use in the math there. >>> >>>>>> >>> >>>>>> The good news is that the way that the SRCOVER_MASKFILL uses the various type-specific macros works around this a bit and minimizes the number of multiplies that happen. You could check out DEFINE_SRCOVER_MASKFILL and see how it works in the case where pMask is not null (pMask is an alpha mask with values very similar to the glyphAA data). Modeling this code on that code would correct the math and minimize it as well... >>> >>>>>> >>> >>>>>> ...jim >>> >>>>>> >>> >>>>>> On 3/17/16 3:00 AM, Prahalad Kumar Narayanan wrote: >>> >>>>>>> Hello Everyone on Java2D Group >>> >>>>>>> >>> >>>>>>> Good day to you. >>> >>>>>>> >>> >>>>>>> Herewith, I 'm sharing the webrev for two identical Java2D Bugs. >>> >>>>>>> >>> >>>>>>> Bug ID : JDK-8015070 >>> >>>>>>> >>> >>>>>>> Title : Antialiased text on translucent backgrounds gets >>> >>>>>>> bright artifacts >>> >>>>>>> >>> >>>>>>> Link :https://bugs.openjdk.java.net/browse/JDK-8015070 >>> >>>>>>> >>> >>>>>>> Bug ID : JDK-8013564 ( currently closed as duplicate ) >>> >>>>>>> >>> >>>>>>> Title : Font rendering anti-aliasing in translucent >>> >>>>>>> BufferedImages broken >>> >>>>>>> >>> >>>>>>> Link :https://bugs.openjdk.java.net/browse/JDK-8013564 >>> >>>>>>> >>> >>>>>>> Webrev Link : >>> >>>>>>> http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.00/ >>> >>>>>>> >>> >>>>>>> Quick Summary on Bugs : >>> >>>>>>> >>> >>>>>>> ```````````````````````````````````````````````` >>> >>>>>>> >>> >>>>>>> 1. Artifacts appear on Edges of text characters when >>>>>>> anti-aliased >>> >>>>>>> text is drawn on Translucent background >>> >>>>>>> >>> >>>>>>> 2. The issue is reproducible on all platforms - windows, linux and mac os. >>> >>>>>>> >>> >>>>>>> 3. Besides, the issue is reproduced with the commonly used pixel >>> >>>>>>> format- 4ByteArgb. >>> >>>>>>> >>> >>>>>>> Root Cause & Solution : >>> >>>>>>> >>> >>>>>>> ```````````````````````````````````````````````` >>> >>>>>>> >>> >>>>>>> 1. The Macro: GlyphListAABlend4ByteArgb in File: LoopMacros.h >>>>>>> uses >>> >>>>>>> the standard blending algorithm >>> >>>>>>> >>> >>>>>>> dstColor = [ srcColor * glyphAlpha + dstColor * (1 - >>> >>>>>>> glyphAlpha) ] / dstAlpha >>> >>>>>>> >>> >>>>>>> 2. The above equation works only when the srcColor and dstColor are Opaque. >>> >>>>>>> >>> >>>>>>> 3. When srcColor and dstColor are Translucent, their >>> >>>>>>> alphaComponent will influence the visibility of the color, and >>> >>>>>>> visibility of the color below. >>> >>>>>>> >>> >>>>>>> 4. The new set of calculations for blending Translucent source >>>>>>> and >>> >>>>>>> destination colors is given as >>> >>>>>>> >>> >>>>>>> resAlpha = 1 - ((1 - srcAlpha) * (1 - dstAlpha)) >>> >>>>>>> >>> >>>>>>> resColor = [ srcColor * srcAlpha + dstColor * >>>>>>> dstAlpha >>> >>>>>>> * >>> >>>>>>> (1 >>> >>>>>>> - >>> >>>>>>> srcAlpha) ] / resAlpha >>> >>>>>>> >>> >>>>>>> 5. Reference text for the equation: >>> >>>>>>> https://en.wikipedia.org/wiki/Alpha_compositing >>> >>>>>>> >>> >>>>>>> 6. With the above modification to the blending logic, the >>> >>>>>>> artifacts do not appear and issues are fixed. >>> >>>>>>> >>> >>>>>>> Jtreg & Jprt Results : >>> >>>>>>> >>> >>>>>>> ```````````````````````````````````````````````` >>> >>>>>>> >>> >>>>>>> 1. A simple test-file: AADrawStringArtifact.java has been >>>>>>> created >>> >>>>>>> to be a part of jtreg test cases. >>> >>>>>>> >>> >>>>>>> The test file is well commented to explain - nature >>>>>>> of >>> >>>>>>> artifact and how the test tries to identify them. >>> >>>>>>> >>> >>>>>>> As required, the test case fails with Jdk 7, Jdk 8 >>>>>>> and >>> >>>>>>> succeeds with Jdk 9-internal (built with changes for the bug fix) >>> >>>>>>> >>> >>>>>>> 2. The changes to blending logic lies within >>> >>>>>>> java.desktop/src/share/native/... >>> >>>>>>> >>> >>>>>>> Henceforth, JPRT was used to ensure successful build >>> >>>>>>> across all supported platforms >>> >>>>>>> >>> >>>>>>> Jprt Job Link : >>> >>>>>>> http://scaaa637.us.oracle.com//archive/2016/03/2016-03-17-072001. >>>>>>> pr >>> >>> >>>>>>> a >>> >>>>>>> h >>> >>>>>>> n >>> >>>>>>> ara-linux.client >>> >>>>>>> >>> >>>>>>> The build succeeds on all platforms. >>> >>>>>>> >>> >>>>>>> Kindly review the webrev link and provide your views and suggestions. >>> >>>>>>> >>> >>>>>>> Webrev Link : >>> >>>>>>> http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.00/ >>> >>>>>>> >>> >>>>>>> If the changes look good, we could take up the changes for source checkin. >>> >>>>>>> >>> >>>>>>> Thank you for your time in review >>> >>>>>>> >>> >>>>>>> Have a good day >>> >>>>>>> >>> >>>>>>> Prahalad N. >>> >>>>>>> >>> From ajit.ghaisas at oracle.com Thu Apr 28 12:44:06 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Thu, 28 Apr 2016 05:44:06 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Fix for JDK-8074829 : Resolve disabled warnings for libawt_headless In-Reply-To: <57193461.1090904@oracle.com> References: <5717D829.8070704@oracle.com> <5717E448.7000003@oracle.com> <48002ede-2af9-4bf2-bb32-f38114ea438b@default> <57193461.1090904@oracle.com> Message-ID: Hi, I tried excluding files under directory : jdk/src/java.desktop/share/native/common/java2d/opengl from libawt_headless. It resulted in compilation errors - as the headers in this directory (and under sub-directory J2D_GL) are used in other places. To Phil's question on - why I mentioned only OGLBlitLoops.c file? - this is the file where warning is reported and build stopped. Hence, I propose not to remove the suppression of warning E_EMPTY_TRANSLATION_UNIT in make file for Solaris. There is no change in original webrev : http://cr.openjdk.java.net/~aghaisas/8074829/webrev.00/ Based on Erik's suggestion, I have built it for arm and arm64 with no errors. Regards, Ajit -----Original Message----- From: Phil Race Sent: Friday, April 22, 2016 1:43 AM To: Ajit Ghaisas Cc: Sergey Bylokhov; 2d-dev; build-dev at openjdk.java.net Subject: Re: Fix for JDK-8074829 : Resolve disabled warnings for libawt_headless > Another solution is to exclude this file from HEADLESS compilation. > I am not sure how to achieve it. Any suggestion? I suppose that is possible and I expect we can do that See in the make file, where I think you just need to add entries to LIBAWT_HEADLESS_EXCLUDES := medialib although I have not tried it. Hmm .. I wonder why medialib needs to be explicitly excluded from headless ? .. but that is for another day. I have another question: why do you mention only OGLBlitLoops.c ? I've flicked through a number of the C files in the same location and all look to have the same issue. -phil. On 04/21/2016 06:33 AM, Ajit Ghaisas wrote: >>> On 04/20/2016 12:27 PM, Sergey Bylokhov wrote: >>> 2d-dev added. >> In fact all these are 2D. No AWT warnings here. >>> I am not sure but why "declaration in the code" is a bad thing and >>> we should fix it? >>> - DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE >>> >>> I cannot find the documentation in solaris studio for this warning. >> I don't mind fixing it if it is still an issue but does the current compiler actually complain about it ? >> The SS11 -> SS12 upgrade might have got a more modern C compiler .. > [Ajit ] Yes. The Solaris compiler still complains about this declaration in code. Hence, I have fixed the reported warnings after removing the suppression from makefile. > >>> On 20.04.16 11:57, Ajit Ghaisas wrote: >>>> Hi, >>>> >>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8074829 >>>> This bug is to remove warning suppressions from makefile and >>>> fix the warnings for libawt_headless library. >>>> >>>> I have removed following warning suppressions & fixed the >>>> warnings for libawt_headless library. >>>> DISABLED_WARNINGS_gcc := maybe-uninitialized >>>> int-to-pointer-cast >> What made that one go away ?? > [Ajit] : I fixed warnings reported for 'maybe-uninitialized' and 'E_DECLARATION_IN_CODE' warning types in two .c files in webrev. > There was no warning after removal of 'int-to-pointer-cast' suppression from makefile. No code change was made for this type of warning. > > >>>> DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE >>>> >>>> Warning suppression that cannot be removed : >>>> DISABLED_WARNINGS_solstudio := E_EMPTY_TRANSLATION_UNIT >>>> This is due to the fact that - >>>> jdk/src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops >>>> .c file becomes empty file in case of HEADLESS mode compilation. >> Sigh .. there ought to be "informational" warnings as well as "risky practice" warnings and this should be in the former category. >> You could move something like the jni.h and jlong.h imports outside to see if that shuts it up. >> Not saying that is what we want to do but it would be interesting to check. > [Ajit] : Nope. Moving jni.h or jlong.h inclusions outside #ifndef HEADLESS did not help. We still get E_EMPTY_TRANSLATION_UNIT warning. > To get rid of this warning, there are suggestions to make a typedef - and not use it anywhere - but, I would rather keep the suppression in makefile than defining a typedef without actual usage. > Another solution is to exclude this file from HEADLESS compilation. I am not sure how to achieve it. Any suggestion? > > >> -phil. >>>> Request you to review following webrev : >>>> http://cr.openjdk.java.net/~aghaisas/8074829/webrev.00/ >>>> >>>> Regards, >>>> Ajit From erik.joelsson at oracle.com Thu Apr 28 12:55:27 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 28 Apr 2016 14:55:27 +0200 Subject: [OpenJDK 2D-Dev] Fix for JDK-8074829 : Resolve disabled warnings for libawt_headless In-Reply-To: References: <5717D829.8070704@oracle.com> <5717E448.7000003@oracle.com> <48002ede-2af9-4bf2-bb32-f38114ea438b@default> <57193461.1090904@oracle.com> Message-ID: <5722083F.1080802@oracle.com> Then I'm happy, thanks! /Erik On 2016-04-28 14:44, Ajit Ghaisas wrote: > Hi, > > I tried excluding files under directory : jdk/src/java.desktop/share/native/common/java2d/opengl from libawt_headless. > It resulted in compilation errors - as the headers in this directory (and under sub-directory J2D_GL) are used in other places. > > To Phil's question on - why I mentioned only OGLBlitLoops.c file? - this is the file where warning is reported and build stopped. > > Hence, I propose not to remove the suppression of warning E_EMPTY_TRANSLATION_UNIT in make file for Solaris. > There is no change in original webrev : http://cr.openjdk.java.net/~aghaisas/8074829/webrev.00/ > > Based on Erik's suggestion, I have built it for arm and arm64 with no errors. > > Regards, > Ajit > > -----Original Message----- > From: Phil Race > Sent: Friday, April 22, 2016 1:43 AM > To: Ajit Ghaisas > Cc: Sergey Bylokhov; 2d-dev; build-dev at openjdk.java.net > Subject: Re: Fix for JDK-8074829 : Resolve disabled warnings for libawt_headless > > > Another solution is to exclude this file from HEADLESS compilation. > > I am not sure how to achieve it. Any suggestion? > > I suppose that is possible and I expect we can do that See in the make file, where I think you just need to add entries to > LIBAWT_HEADLESS_EXCLUDES := medialib > > although I have not tried it. > Hmm .. I wonder why medialib needs to be explicitly excluded from headless ? .. but that is for another day. > > I have another question: why do you mention only OGLBlitLoops.c ? > I've flicked through a number of the C files in the same location and all look to have the same issue. > > -phil. > > On 04/21/2016 06:33 AM, Ajit Ghaisas wrote: >>>> On 04/20/2016 12:27 PM, Sergey Bylokhov wrote: >>>> 2d-dev added. >>> In fact all these are 2D. No AWT warnings here. >>>> I am not sure but why "declaration in the code" is a bad thing and >>>> we should fix it? >>>> - DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE >>>> >>>> I cannot find the documentation in solaris studio for this warning. >>> I don't mind fixing it if it is still an issue but does the current compiler actually complain about it ? >>> The SS11 -> SS12 upgrade might have got a more modern C compiler .. >> [Ajit ] Yes. The Solaris compiler still complains about this declaration in code. Hence, I have fixed the reported warnings after removing the suppression from makefile. >> >>>> On 20.04.16 11:57, Ajit Ghaisas wrote: >>>>> Hi, >>>>> >>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8074829 >>>>> This bug is to remove warning suppressions from makefile and >>>>> fix the warnings for libawt_headless library. >>>>> >>>>> I have removed following warning suppressions & fixed the >>>>> warnings for libawt_headless library. >>>>> DISABLED_WARNINGS_gcc := maybe-uninitialized >>>>> int-to-pointer-cast >>> What made that one go away ?? >> [Ajit] : I fixed warnings reported for 'maybe-uninitialized' and 'E_DECLARATION_IN_CODE' warning types in two .c files in webrev. >> There was no warning after removal of 'int-to-pointer-cast' suppression from makefile. No code change was made for this type of warning. >> >> >>>>> DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE >>>>> >>>>> Warning suppression that cannot be removed : >>>>> DISABLED_WARNINGS_solstudio := E_EMPTY_TRANSLATION_UNIT >>>>> This is due to the fact that - >>>>> jdk/src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops >>>>> .c file becomes empty file in case of HEADLESS mode compilation. >>> Sigh .. there ought to be "informational" warnings as well as "risky practice" warnings and this should be in the former category. >>> You could move something like the jni.h and jlong.h imports outside to see if that shuts it up. >>> Not saying that is what we want to do but it would be interesting to check. >> [Ajit] : Nope. Moving jni.h or jlong.h inclusions outside #ifndef HEADLESS did not help. We still get E_EMPTY_TRANSLATION_UNIT warning. >> To get rid of this warning, there are suggestions to make a typedef - and not use it anywhere - but, I would rather keep the suppression in makefile than defining a typedef without actual usage. >> Another solution is to exclude this file from HEADLESS compilation. I am not sure how to achieve it. Any suggestion? >> >> >>> -phil. >>>>> Request you to review following webrev : >>>>> http://cr.openjdk.java.net/~aghaisas/8074829/webrev.00/ >>>>> >>>>> Regards, >>>>> Ajit From philip.race at oracle.com Thu Apr 28 20:52:35 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 28 Apr 2016 13:52:35 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8039444: Swing applications not being displayed properly Message-ID: <57227813.8090008@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8039444 Webrev: http://cr.openjdk.java.net/~prr/8039444/ This makes 9 consistent in black-listing all intel chipsets as we did in 8u40 : http://mail.openjdk.java.net/pipermail/2d-dev/2014-November/004939.html Ideally we would not have to do that but we have not made any solid progress in being to 'white list' any. One thing I intend to do is make sure there is a way to force it on regardless. That will be a follow-up. -phil. From vadim.pakhnushev at oracle.com Thu Apr 28 21:13:23 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 29 Apr 2016 00:13:23 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8039444: Swing applications not being displayed properly In-Reply-To: <57227813.8090008@oracle.com> References: <57227813.8090008@oracle.com> Message-ID: <57227CF3.4080307@oracle.com> +1 Vadim On 28.04.2016 23:52, Phil Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8039444 > Webrev: http://cr.openjdk.java.net/~prr/8039444/ > > This makes 9 consistent in black-listing all intel chipsets as we did > in 8u40 : > > http://mail.openjdk.java.net/pipermail/2d-dev/2014-November/004939.html > > Ideally we would not have to do that but we have not made any solid > progress in being to 'white list' any. > > One thing I intend to do is make sure there is a way to force it on > regardless. > That will be a follow-up. > > -phil. > > From Sergey.Bylokhov at oracle.com Thu Apr 28 21:22:23 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 29 Apr 2016 00:22:23 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8039444: Swing applications not being displayed properly In-Reply-To: <57227CF3.4080307@oracle.com> References: <57227813.8090008@oracle.com> <57227CF3.4080307@oracle.com> Message-ID: <57227F0F.3030901@oracle.com> +1 On 29.04.16 0:13, Vadim Pakhnushev wrote: >> One thing I intend to do is make sure there is a way to force it on >> regardless. >> That will be a follow-up. I guess we also should unify -Dsun.java2d option? in some cases it will force the pipeline(like xrender) and in some not like d3d. -- Best regards, Sergey. From philip.race at oracle.com Thu Apr 28 23:00:35 2016 From: philip.race at oracle.com (Philip Race) Date: Thu, 28 Apr 2016 16:00:35 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8039444: Swing applications not being displayed properly In-Reply-To: <57227F0F.3030901@oracle.com> References: <57227813.8090008@oracle.com> <57227CF3.4080307@oracle.com> <57227F0F.3030901@oracle.com> Message-ID: <57229613.1010701@oracle.com> > I guess we also should unify -Dsun.java2d option? in some cases it will force the pipeline(like xrender) and in some not like d3d. Yes, I have 3 things in the pipeline (pardon the pun) - clean up of legacy unused flags on windows, This is done and I expect to submit a review tonight or maybe tomorrow. Then once that noise is removed : - a way to force d3d at your own risk - an examination of how all the pipeline options for each platform and default interact and provide comprehensible documentation. The last one is the one you are getting at I think -phil. On 4/28/16, 2:22 PM, Sergey Bylokhov wrote: > +1 > On 29.04.16 0:13, Vadim Pakhnushev wrote: >>> One thing I intend to do is make sure there is a way to force it on >>> regardless. >>> That will be a follow-up. > > I guess we also should unify -Dsun.java2d option? in some cases it > will force the pipeline(like xrender) and in some not like d3d. > From jayathirth.d.v at oracle.com Fri Apr 29 08:21:34 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Fri, 29 Apr 2016 01:21:34 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: equals() method in IndexColorModel doesnt exist and it relies on ColorModel.equals() which is not strict In-Reply-To: References: <57057CF0.50604@oracle.com> <5706ADBE.10803@oracle.com> <570BF21F.9010603@oracle.com> <34a9ed1b-bf8a-43fb-9032-65c9c47a9c11@default> <570D5043.8000405@oracle.com> <570D5387.2070303@oracle.com> <570D5839.3000402@oracle.com> <570D5822.40705@oracle.com> <570EB999.7090408@oracle.com> <94c3a958-d927-4b42-89f0-d0c44d4d19ab@default> Message-ID: <91a51d1c-a232-4669-93d9-4736c963b1ad@default> Hi Jim, Thanks for the review. I have updated the changes mentioned by you. ICM.hashCode() was generated using NetBeans and I added super.hashCode() to include things from ColorModel. Initializing "hash" to 7 is redundant so I removed it and initialized to super.hashCode(). Please find updated webrev for review : http://cr.openjdk.java.net/~jdv/7107905/webrev.06/ I will make changes in CCC after technical review is approved. Thanks, Jay -----Original Message----- From: Jim Graham Sent: Wednesday, April 27, 2016 4:24 AM To: Jayathirth D V; Philip Race Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: equals() method in IndexColorModel doesnt exist and it relies on ColorModel.equals() which is not strict This version of the ICM.equals() method starts with casting the unkown obj to ICM, which may throw a cast exception. That cast needs to be moved down after the call to super.equals() ("this == cm" can just be "this == obj"). In the ICM hashcode function, is there a reason that the hash variable isn't just initialized to super.hashCode() rather than starting with 7 and doing a multiply-add to incorporate the super hashcode? ...jim On 4/25/16 1:26 AM, Jayathirth D V wrote: > Hi, > > Based on Joe's and Jim's suggestion I have made changes to include check for getClass() in baseclass and use super.equals() from subclasses to verify class equality. > Please find updated webrev for review : > http://cr.openjdk.java.net/~jdv/7107905/webrev.05/ > > For JDK-8153943 I will make relevant changes in its subclasses and sent review in its thread. > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Thursday, April 14, 2016 2:57 AM > To: Jayathirth D V; Philip Race > Cc: 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: equals() > method in IndexColorModel doesnt exist and it relies on > ColorModel.equals() which is not strict > > Looks good. The only thing left is the CCC... > > ...jim > > On 4/13/16 1:33 AM, Jayathirth D V wrote: >> Hi, >> >> Thanks Phil & Jim for your suggestion. >> I have made changes mentioned by Jim for whether we have validate individual bits of validBits or not in different conditions. >> Please find updated webrev for review : >> http://cr.openjdk.java.net/~jdv/7107905/webrev.04/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Phil Race >> Sent: Wednesday, April 13, 2016 1:49 AM >> To: Jim Graham >> Cc: Jayathirth D V; Prasanta Sadhukhan; 2d-dev at openjdk.java.net >> Subject: Re: Review Request for JDK-7107905: equals() method in >> IndexColorModel doesnt exist and it relies on ColorModel.equals() >> which is not strict >> >> Seems like this would work/help. >> >> -phil. >> >> On 04/12/2016 01:19 PM, Jim Graham wrote: >>> >>> >>> On 4/12/2016 12:59 PM, Phil Race wrote: >>>> I am catching up on email here, and "+1" but a couple of comments >>>> >>>> - I suppose that we can't learn anything useful from >>>> "cm.validbits.equals(this.validbits)" >>>> since only the bits up to "map_size" should be tested ? >>> >>> Perhaps if the constructors truncated it at the required size we >>> could use equals(). I'm not sure that is worthwhile, given how >>> rarely it is used. I think it is used by default on some platforms (Windows? >>> X11?) if they have an 8-bit screen with a sparse colormap, but that >>> should be pretty rare these days since nearly everything we use >>> should be 24-bits these days. >>> >>> I have a better idea, though. >>> >>> But, since the field is assigned the original supplied value from >>> the constructor, then the likelihood that a non-null value will be >>> == identical to another colormap is likely larger than normal, >>> perhaps we can make it faster by checking for == and then slipping >>> into the faster test that simply compares the rgb[] values? Something like: >>> >>> if (validBits == cm.validBits) { >>> compare rgb[] entries >>> } else if (validBits == null || cm.validBits == null) { >>> return false; >>> } else { >>> bigger loop that compares rgb[] and validBits() values } >>> >>> Note that if the two fields are == and non-null, then the entries in >>> the rgb[] array for indices that are non-valid should have zeros in >>> them because of the way that the colormap data is copied internally, >>> so the rgb[] comparisons should be valid without checking the >>> associated bits. >>> >>> Potentially we could also use: >>> >>> boolean fulltest; >>> if (validBits == cm.validBits) { >>> fulltest = false; >>> } else if (validBits == null || cm.validBits == null) { >>> return false; >>> } else if (validBits.equals(cm.validBits)) { >>> fulltest = false; >>> } else { >>> fulltest = true; >>> } >>> >>> if (fulltest) { >>> compare both rgb[] and validBits() values } else { >>> compare rgb[] entries alone >>> } >>> >>> In this case we are using validBits.equals() to reduce the amount of >>> testing in the loop, but are not basing a conclusion on whether the >>> result of the comparison will be true or false. equals() implies we >>> don't need to compare its values bit by bit, but !equals() doesn't >>> mean that the ICMs aren't equals()... >>> >>> ...jim >> From james.graham at oracle.com Fri Apr 29 09:02:35 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 29 Apr 2016 02:02:35 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: equals() method in IndexColorModel doesnt exist and it relies on ColorModel.equals() which is not strict In-Reply-To: <91a51d1c-a232-4669-93d9-4736c963b1ad@default> References: <57057CF0.50604@oracle.com> <5706ADBE.10803@oracle.com> <570BF21F.9010603@oracle.com> <34a9ed1b-bf8a-43fb-9032-65c9c47a9c11@default> <570D5043.8000405@oracle.com> <570D5387.2070303@oracle.com> <570D5839.3000402@oracle.com> <570D5822.40705@oracle.com> <570EB999.7090408@oracle.com> <94c3a958-d927-4b42-89f0-d0c44d4d19ab@default> <91a51d1c-a232-4669-93d9-4736c963b1ad@default> Message-ID: <5723232B.2080505@oracle.com> That looks fine. I assumed that the test case hadn't changed since last time and didn't read through it. Let me know if I need to look at anything in that file... ...jim On 04/29/2016 01:21 AM, Jayathirth D V wrote: > Hi Jim, > > Thanks for the review. > I have updated the changes mentioned by you. ICM.hashCode() was generated using NetBeans and I added super.hashCode() to include things from ColorModel. Initializing "hash" to 7 is redundant so I removed it and initialized to super.hashCode(). > > Please find updated webrev for review : > http://cr.openjdk.java.net/~jdv/7107905/webrev.06/ > > I will make changes in CCC after technical review is approved. > > Thanks, > Jay > -----Original Message----- > From: Jim Graham > Sent: Wednesday, April 27, 2016 4:24 AM > To: Jayathirth D V; Philip Race > Cc: 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: equals() method in IndexColorModel doesnt exist and it relies on ColorModel.equals() which is not strict > > This version of the ICM.equals() method starts with casting the unkown obj to ICM, which may throw a cast exception. That cast needs to be moved down after the call to super.equals() ("this == cm" can just be "this == obj"). > > In the ICM hashcode function, is there a reason that the hash variable isn't just initialized to super.hashCode() rather than starting with 7 and doing a multiply-add to incorporate the super hashcode? > > ...jim > > On 4/25/16 1:26 AM, Jayathirth D V wrote: >> Hi, >> >> Based on Joe's and Jim's suggestion I have made changes to include check for getClass() in baseclass and use super.equals() from subclasses to verify class equality. >> Please find updated webrev for review : >> http://cr.openjdk.java.net/~jdv/7107905/webrev.05/ >> >> For JDK-8153943 I will make relevant changes in its subclasses and sent review in its thread. >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Thursday, April 14, 2016 2:57 AM >> To: Jayathirth D V; Philip Race >> Cc: 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: equals() >> method in IndexColorModel doesnt exist and it relies on >> ColorModel.equals() which is not strict >> >> Looks good. The only thing left is the CCC... >> >> ...jim >> >> On 4/13/16 1:33 AM, Jayathirth D V wrote: >>> Hi, >>> >>> Thanks Phil & Jim for your suggestion. >>> I have made changes mentioned by Jim for whether we have validate individual bits of validBits or not in different conditions. >>> Please find updated webrev for review : >>> http://cr.openjdk.java.net/~jdv/7107905/webrev.04/ >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Phil Race >>> Sent: Wednesday, April 13, 2016 1:49 AM >>> To: Jim Graham >>> Cc: Jayathirth D V; Prasanta Sadhukhan; 2d-dev at openjdk.java.net >>> Subject: Re: Review Request for JDK-7107905: equals() method in >>> IndexColorModel doesnt exist and it relies on ColorModel.equals() >>> which is not strict >>> >>> Seems like this would work/help. >>> >>> -phil. >>> >>> On 04/12/2016 01:19 PM, Jim Graham wrote: >>>> >>>> On 4/12/2016 12:59 PM, Phil Race wrote: >>>>> I am catching up on email here, and "+1" but a couple of comments >>>>> >>>>> - I suppose that we can't learn anything useful from >>>>> "cm.validbits.equals(this.validbits)" >>>>> since only the bits up to "map_size" should be tested ? >>>> Perhaps if the constructors truncated it at the required size we >>>> could use equals(). I'm not sure that is worthwhile, given how >>>> rarely it is used. I think it is used by default on some platforms (Windows? >>>> X11?) if they have an 8-bit screen with a sparse colormap, but that >>>> should be pretty rare these days since nearly everything we use >>>> should be 24-bits these days. >>>> >>>> I have a better idea, though. >>>> >>>> But, since the field is assigned the original supplied value from >>>> the constructor, then the likelihood that a non-null value will be >>>> == identical to another colormap is likely larger than normal, >>>> perhaps we can make it faster by checking for == and then slipping >>>> into the faster test that simply compares the rgb[] values? Something like: >>>> >>>> if (validBits == cm.validBits) { >>>> compare rgb[] entries >>>> } else if (validBits == null || cm.validBits == null) { >>>> return false; >>>> } else { >>>> bigger loop that compares rgb[] and validBits() values } >>>> >>>> Note that if the two fields are == and non-null, then the entries in >>>> the rgb[] array for indices that are non-valid should have zeros in >>>> them because of the way that the colormap data is copied internally, >>>> so the rgb[] comparisons should be valid without checking the >>>> associated bits. >>>> >>>> Potentially we could also use: >>>> >>>> boolean fulltest; >>>> if (validBits == cm.validBits) { >>>> fulltest = false; >>>> } else if (validBits == null || cm.validBits == null) { >>>> return false; >>>> } else if (validBits.equals(cm.validBits)) { >>>> fulltest = false; >>>> } else { >>>> fulltest = true; >>>> } >>>> >>>> if (fulltest) { >>>> compare both rgb[] and validBits() values } else { >>>> compare rgb[] entries alone >>>> } >>>> >>>> In this case we are using validBits.equals() to reduce the amount of >>>> testing in the loop, but are not basing a conclusion on whether the >>>> result of the comparison will be true or false. equals() implies we >>>> don't need to compare its values bit by bit, but !equals() doesn't >>>> mean that the ICMs aren't equals()... >>>> >>>> ...jim From jayathirth.d.v at oracle.com Fri Apr 29 09:35:01 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Fri, 29 Apr 2016 02:35:01 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: equals() method in IndexColorModel doesnt exist and it relies on ColorModel.equals() which is not strict In-Reply-To: <5723232B.2080505@oracle.com> References: <57057CF0.50604@oracle.com> <5706ADBE.10803@oracle.com> <570BF21F.9010603@oracle.com> <34a9ed1b-bf8a-43fb-9032-65c9c47a9c11@default> <570D5043.8000405@oracle.com> <570D5387.2070303@oracle.com> <570D5839.3000402@oracle.com> <570D5822.40705@oracle.com> <570EB999.7090408@oracle.com> <94c3a958-d927-4b42-89f0-d0c44d4d19ab@default> <91a51d1c-a232-4669-93d9-4736c963b1ad@default> <5723232B.2080505@oracle.com> Message-ID: <884fa334-1c1a-44da-afa3-4af4049c7ae9@default> Hi Jim, Thanks for the approval. I have not changed things in test case. Regards, Jay -----Original Message----- From: Jim Graham Sent: Friday, April 29, 2016 2:33 PM To: Jayathirth D V; Philip Race Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: equals() method in IndexColorModel doesnt exist and it relies on ColorModel.equals() which is not strict That looks fine. I assumed that the test case hadn't changed since last time and didn't read through it. Let me know if I need to look at anything in that file... ...jim On 04/29/2016 01:21 AM, Jayathirth D V wrote: > Hi Jim, > > Thanks for the review. > I have updated the changes mentioned by you. ICM.hashCode() was generated using NetBeans and I added super.hashCode() to include things from ColorModel. Initializing "hash" to 7 is redundant so I removed it and initialized to super.hashCode(). > > Please find updated webrev for review : > http://cr.openjdk.java.net/~jdv/7107905/webrev.06/ > > I will make changes in CCC after technical review is approved. > > Thanks, > Jay > -----Original Message----- > From: Jim Graham > Sent: Wednesday, April 27, 2016 4:24 AM > To: Jayathirth D V; Philip Race > Cc: 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: equals() > method in IndexColorModel doesnt exist and it relies on > ColorModel.equals() which is not strict > > This version of the ICM.equals() method starts with casting the unkown obj to ICM, which may throw a cast exception. That cast needs to be moved down after the call to super.equals() ("this == cm" can just be "this == obj"). > > In the ICM hashcode function, is there a reason that the hash variable isn't just initialized to super.hashCode() rather than starting with 7 and doing a multiply-add to incorporate the super hashcode? > > ...jim > > On 4/25/16 1:26 AM, Jayathirth D V wrote: >> Hi, >> >> Based on Joe's and Jim's suggestion I have made changes to include check for getClass() in baseclass and use super.equals() from subclasses to verify class equality. >> Please find updated webrev for review : >> http://cr.openjdk.java.net/~jdv/7107905/webrev.05/ >> >> For JDK-8153943 I will make relevant changes in its subclasses and sent review in its thread. >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Thursday, April 14, 2016 2:57 AM >> To: Jayathirth D V; Philip Race >> Cc: 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: >> equals() method in IndexColorModel doesnt exist and it relies on >> ColorModel.equals() which is not strict >> >> Looks good. The only thing left is the CCC... >> >> ...jim >> >> On 4/13/16 1:33 AM, Jayathirth D V wrote: >>> Hi, >>> >>> Thanks Phil & Jim for your suggestion. >>> I have made changes mentioned by Jim for whether we have validate individual bits of validBits or not in different conditions. >>> Please find updated webrev for review : >>> http://cr.openjdk.java.net/~jdv/7107905/webrev.04/ >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Phil Race >>> Sent: Wednesday, April 13, 2016 1:49 AM >>> To: Jim Graham >>> Cc: Jayathirth D V; Prasanta Sadhukhan; 2d-dev at openjdk.java.net >>> Subject: Re: Review Request for JDK-7107905: equals() method in >>> IndexColorModel doesnt exist and it relies on ColorModel.equals() >>> which is not strict >>> >>> Seems like this would work/help. >>> >>> -phil. >>> >>> On 04/12/2016 01:19 PM, Jim Graham wrote: >>>> >>>> On 4/12/2016 12:59 PM, Phil Race wrote: >>>>> I am catching up on email here, and "+1" but a couple of comments >>>>> >>>>> - I suppose that we can't learn anything useful from >>>>> "cm.validbits.equals(this.validbits)" >>>>> since only the bits up to "map_size" should be tested ? >>>> Perhaps if the constructors truncated it at the required size we >>>> could use equals(). I'm not sure that is worthwhile, given how >>>> rarely it is used. I think it is used by default on some platforms (Windows? >>>> X11?) if they have an 8-bit screen with a sparse colormap, but that >>>> should be pretty rare these days since nearly everything we use >>>> should be 24-bits these days. >>>> >>>> I have a better idea, though. >>>> >>>> But, since the field is assigned the original supplied value from >>>> the constructor, then the likelihood that a non-null value will be >>>> == identical to another colormap is likely larger than normal, >>>> perhaps we can make it faster by checking for == and then slipping >>>> into the faster test that simply compares the rgb[] values? Something like: >>>> >>>> if (validBits == cm.validBits) { >>>> compare rgb[] entries >>>> } else if (validBits == null || cm.validBits == null) { >>>> return false; >>>> } else { >>>> bigger loop that compares rgb[] and validBits() values } >>>> >>>> Note that if the two fields are == and non-null, then the entries >>>> in the rgb[] array for indices that are non-valid should have zeros >>>> in them because of the way that the colormap data is copied >>>> internally, so the rgb[] comparisons should be valid without >>>> checking the associated bits. >>>> >>>> Potentially we could also use: >>>> >>>> boolean fulltest; >>>> if (validBits == cm.validBits) { >>>> fulltest = false; >>>> } else if (validBits == null || cm.validBits == null) { >>>> return false; >>>> } else if (validBits.equals(cm.validBits)) { >>>> fulltest = false; >>>> } else { >>>> fulltest = true; >>>> } >>>> >>>> if (fulltest) { >>>> compare both rgb[] and validBits() values } else { >>>> compare rgb[] entries alone >>>> } >>>> >>>> In this case we are using validBits.equals() to reduce the amount >>>> of testing in the loop, but are not basing a conclusion on whether >>>> the result of the comparison will be true or false. equals() >>>> implies we don't need to compare its values bit by bit, but >>>> !equals() doesn't mean that the ICMs aren't equals()... >>>> >>>> ...jim From jayathirth.d.v at oracle.com Fri Apr 29 11:45:42 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Fri, 29 Apr 2016 04:45:42 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED In-Reply-To: <571FB2D1.30205@oracle.com> References: <2c9221dc-ed76-481a-8bee-a694d313448e@default> <56BD0CAB.6080704@oracle.com> <90de7741-c175-4803-9c3e-30b1039b2774@default> <56C227D1.1030600@oracle.com> <46329edf-4cbe-48d4-a519-c908b09844a6@default> <56C789E4.6000409@oracle.com> <7f5f1cd3-4022-4739-b412-9d3f3c74181f@default> <4a833ce4-04b4-0250-e78f-ef60fbd52806@oracle.com> <571FB2D1.30205@oracle.com> Message-ID: <3ab637db-7b8b-440a-8d65-222f3b5ca55e@default> Hi, Thanks Phil & Jim for your inputs. I have made all recommended changes. Please find updated webrev for review : http://cr.openjdk.java.net/~jdv/7116979/webrev.02/ Thanks, Jay -----Original Message----- From: Phil Race Sent: Tuesday, April 26, 2016 11:56 PM To: Jim Graham Cc: Jayathirth D V; 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED On 04/22/2016 06:56 PM, Jim Graham wrote: > Hi Jay, > > It looks like it will work, but there are some inconsistencies in the > code that we should address and a couple of optimizations. > > First, there is a mixture of using "int" and "jboolean" for the type > of the new boolean parameter. It would be great if we could just > declare it as jboolean in the structures, but it looks like those are > limited to basic C types. It seems a little clunky to mix types like > this, but I'd be interested in hearing what Phil says. I think it > would be fine to just use int throughout. From the ones I've seen may be much better to just use int throughout. Eg 264 static jboolean calculatePrimaryColorsAprroximation(int* cmap, unsigned char* cube, int cube_size) { aside from having a typo in the name also makes a fair amount of internal uses of jboolean and JNI_TRUE/JNI_FALSE. It then does this 385 cData->representsPrimary = calculatePrimaryColorsAprroximation(pRgb, cData->img_clr_tbl, 32); ie stores it in an int .. I see no reason for this as there is no JNI code involved. Moreover this usage of the variables declared as boolean then has code like 174 (representsPrimary == 1))) { \ -phil. > > I'd suggest a name change: > representsPrimary => representsPrimaries (since there are multiple > primary colors) > > The place to load the variable for testing in the ByteIndexed macros > would be in the "InitByteIndexedStoreVarsY" macro where it sets up the > "PREFIX ## InvLut" variable. It should also use a PREFIX. Look > through those macros for wherever the InvLut value is declared and > initialized, and follow a similar pattern for "PREFIX ## ". > You could use "representsPrimaries" for the name here too, but it > could also be shortened to just "repPrims" or "optPrims" since the > macros are all centralized here. > > Once you do the preceding step, you can delete a lot of lines that > pre-load the "representsPrimaries" in the calling macros, which should > also eliminate a lot of files from the webrev. > > In the code in ByteIndexed.h:StoreByteIndexedFrom3ByteRgb() that tests > the variable, I'd just test "representsPrimary" with no "==" rather > than comparing it to 1 since it is a boolean, not (really) an integer. > > With respect to the new function that tests the primary matches (in > ByteIndexed.c), some of the code is unnecessarily complicated: > > - When you find a color match failure (lines 301, et al), you could > just return false directly. As it stands, you set a variable and > break, but the break only breaks out of 1 of 3 nested if statements, > so it doesn't save any calculations. Just return false directly as a > single failure means the answer is "no". > > - your r, g, and b values are extracted from the color in the wrong > order near line 285. r involves a shift of 16, and b involves no > shift. I suppose this is paired with computing the dr and db values > with the wrong indices or this technique wouldn't work, but it is > clunky to name the variables inconsistently with the data they > actually hold. > > - you use parentheses on the left-hand side of an assignment when you > extract the r, g, and b values (also near line 285). You don't need > parentheses on that side of an assignment operator. > > There are several things that are more complicated than they need to > be with your testing lines. They use a lot more computations than you > need. For instance: > > - You test the i,j,k using a modulus operation (lines 298, 312, 326), > but really you just need to know if it is 0 or not-0, so just test it > for ==0 or !=0. > - rather than using multiplication and modulus to assign the dr,dg,db > values near line 291, why not just use "dr = (i == 0) ? 0 : 255;"? > - the tests for range use a separate subtraction and a compare, when > they could be inlined. > > First, I'd get rid of the "represents_primary" variable entirely and > then rewrite the whole tail end of the loop body from 291 to the end > of the loop as: > > if (i == 0) { > if (r > delta) return false; > } else { > if (r < 255-delta) return false; > } > // 2 more similar tests for j/g and k/b > > Then "return true" at the end of the function if it reaches there. > Keep in mind that the mapping of ijk to rgb might be affected if you > fix the shifts used to extract the rgb components from color... > > ...jim > > On 4/20/2016 2:46 AM, Jayathirth D V wrote: >> Hi Jim, >> >> As discussed we will not add dithering error values to primary colors >> with color map which represents Primary colors approximately(+/-5 >> delta). >> I have made changes based on this suggestion and added new function >> to calculate whether color map represents primary colors >> approximately or not. >> If it represents only then we will avoid adding dithering error >> values in case ByteIndexed destination. >> >> I have observed that in case of white color we are picking >> (252,252,252) or (246,246,246) and not (255,255,255) from colormap. >> What I have observed that out of 256 places we are storing RGB colors >> at start and then gray values. So we are picking final gray value and >> not in between white value. That's why I am not verifying white color >> validity in test case. >> >> Please find updated webrev for review : >> http://cr.openjdk.java.net/~jdv/7116979/webrev.01/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Saturday, February 20, 2016 3:02 AM >> To: Jayathirth D V >> Cc: 2d-dev at openjdk.java.net; Philip Race; Prasanta Sadhukhan >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : >> Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED >> >> Hi Jayathirth, >> >> Thank you for attaching the detailed logs, but I don't have a program >> that can deal with the 7z files. Can you summarize what was learned >> from them? >> >> Also, the colormap you created, while subset, was a perfectly scaled >> cube. I was referring more to a random colormap where you might have >> 2 colors close to a primary, but neither is on a line from the >> primary to the 0.5 gray value so each has a different hue. That's >> something that can only be evaluated visually. One example of >> randomized colormaps is when we display via X11 onto an 8-bit >> display. That probably never happens any more, but we may not be >> able to allocate colors in the colormap in such a case and if another >> program has already allocated most of the dynamic colormap then we >> would not be able to add our own colors. >> >> This could be dealt with by simply marking our standard colormap as >> having primaries, or by scanning any given colormap and marking it if >> it has primaries, and then only perform this code on colormaps with >> the primaries. Solving it for our own colormap (or solving it for >> any colormap that has all primaries) would likely solve it for 99% of >> the vanishingly small number of developers who might run into this. >> >> But, in the end, what would we accomplish by adding this one very >> targeted fix? >> >> I'm also curious where the push for this is coming from. While we >> aren't perfect here, so much of the world today is focused on >> lossless image formats that I don't imagine there is much need for >> really good 8-bit indexed image support any more...? >> >> If anything, spatial dithering is considered a very low quality >> algorithm and error propagation dithering would handle all of the >> colormaps much better. We used to do error propagation dithering >> back in the JDK 1.1 days, but we dropped it when we introduced 2D >> because we added a bunch of ways to render small pieces of an image >> and only the current spatial dithering algorithm can be started in >> the middle of an operation. That doesn't mean that you can't still >> do error propagation since many operations already operate on the >> full image any way and you can still handle subset image operations >> by either converting the full image first and then copying or by >> tracing the errors from the edge of the image to the point of the >> subimage operation. We never bothered to upgrade our algorithms it >> just never seemed to be work that made sense to prioritize given that >> screens were overwhelmingly moving to full-color at the time of "Java >> 2" (and now to HDR in 2016+). 8-bit indexed isn't used much any more. >> >> If we want to make 8-bit destination images work better we'd be >> better off adopting error propagation dithering again rather than >> trying to tune this algorithm for black. >> >> It looks like the bug was closed briefly in 2014 and then reopened >> soon thereafter with no justification. It is true that we still have >> this anomaly, but it isn't clear why this is high enough priority to >> work on in 2016 when other bit depths would work better for >> destination imagery and other dithering algorithms would work better >> for most customers and even this targeted fix isn't perfect... >> >> ...jim >> >> On 2/16/2016 8:32 AM, Jayathirth D V wrote: >>> Hi Jim, >>> >>> Thanks for letting me know about the importance of custom color >>> maps. I was not able to understand what you mentioned previously >>> since I am new to this terminology. >>> >>> Regarding performance I checked with image having complete >>> 255,255,128 pixels and ran it for 100 times. I am running on Windows >>> 7 Professional SP1 with Intel i5-5300U CPU. Overall I don't see >>> much difference in time taken for drawImage() API before and after >>> change. Details for INT_RGB image as input: >>> >>> Before change : >>> Minimum time 536827ns >>> Maximum time 1560947ns >>> Average time 871167ns >>> >>> After change : >>> Minimum time 536380ns >>> Maximum time 1468130ns >>> Average time 830778ns >>> >>> There is +/- 10% delta both for before and after change time but >>> there is no major gap. Even for image with other input type it holds >>> the same. >>> >>> >>> Regarding custom color maps, previously I ran on default color map >>> generated in TYPE_BYTE_INDEXED constructor. Now I tested with >>> modified color map so that it doesn't contain any of the primary >>> color values. Instead of using 0-255 values with value 51 increments >>> in R,G,B components I used color map with 20-245 values with value >>> 45 as increment. For this color map before and after change all the >>> pixels are referring to same index in color map irrespective of >>> removal of error delta addition in case of primary colors. >>> >>> I have attached log for Red and Green primary colors before and >>> after change(Was not able to attach for more since it exceeded 120KB >>> mailing list limit). Please search for "Final index value =" in the >>> logs. Please let me know your inputs. >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Jim Graham >>> Sent: Tuesday, February 16, 2016 1:03 AM >>> To: Jayathirth D V >>> Cc: 2d-dev at openjdk.java.net; Philip Race; Prasanta Sadhukhan >>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : >>> Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED >>> >>> Hi Jayathirth, >>> >>> The issue with testing performance with white images is that the >>> tests allow the code to eliminate 3 indexed fetches which take time. >>> Primary colors end up being the one obscure case where the new code >>> might be faster. But, non-primary colors would be slower by a fair >>> amount, so performance testing with converting a randomized or >>> non-primary-color image are the more telling case. An image filled >>> with 255,255,128 would be the worst case because it would involve >>> all of the tests and still have to do all of the lookups. >>> >>> My question about how this works with custom colormaps was not >>> really addressed by your response. A simple test to make sure the >>> colormap has accurate (or very close) conversions for the primary >>> colors may be enough to validate the colormap for the indicated >>> tests. If the colormap contains no pure conversions for some of the >>> primary colors then they may need to be dithered anyway... >>> >>> ...jim >>> >>> On 2/15/16 3:39 AM, Jayathirth D V wrote: >>>> Hi Jim, >>>> >>>> I performed performance analysis with white image so that all >>>> conditions are checked in the new branch added. There is no major >>>> difference in time taken before and after change. For each input I >>>> have tested time taken for drawImage() API to convert from every >>>> format to Byte indexed type. For every unique conversion test is >>>> run for 100 times. Please find the details: >>>> >>>> Input >>>> >>>> type >>>> >>>> >>>> >>>> Min >>>> >>>> before change >>>> >>>> (ns) >>>> >>>> >>>> >>>> Min >>>> >>>> after change >>>> >>>> (ns) >>>> >>>> >>>> >>>> Max >>>> >>>> before change >>>> >>>> (ns) >>>> >>>> >>>> >>>> Max >>>> >>>> after change >>>> >>>> (ns) >>>> >>>> >>>> >>>> Average >>>> >>>> before change >>>> >>>> (ns) >>>> >>>> >>>> >>>> Average >>>> >>>> after >>>> >>>> change >>>> >>>> (ns) >>>> >>>> INT_RGB >>>> >>>> >>>> >>>> 523437 >>>> >>>> >>>> >>>> 481491 >>>> >>>> >>>> >>>> 1230724 >>>> >>>> >>>> >>>> 1270440 >>>> >>>> >>>> >>>> 789452 >>>> >>>> >>>> >>>> 666144 >>>> >>>> INT_ARGB >>>> >>>> >>>> >>>> 500232 >>>> >>>> >>>> >>>> 493986 >>>> >>>> >>>> >>>> 12406307 >>>> >>>> >>>> >>>> 1308816 >>>> >>>> >>>> >>>> 793384 >>>> >>>> >>>> >>>> 654015 >>>> >>>> INT_ARGB_PRE >>>> >>>> >>>> >>>> 500233 >>>> >>>> >>>> >>>> 492201 >>>> >>>> >>>> >>>> 1037057 >>>> >>>> >>>> >>>> 981277 >>>> >>>> >>>> >>>> 710250 >>>> >>>> >>>> >>>> 699214 >>>> >>>> INT_BGR >>>> >>>> >>>> >>>> 537716 >>>> >>>> >>>> >>>> 562706 >>>> >>>> >>>> >>>> 1446703 >>>> >>>> >>>> >>>> 2046001 >>>> >>>> >>>> >>>> 862377 >>>> >>>> >>>> >>>> 863256 >>>> >>>> 3BYTE_BGR >>>> >>>> >>>> >>>> 483275 >>>> >>>> >>>> >>>> 481045 >>>> >>>> >>>> >>>> 1181638 >>>> >>>> >>>> >>>> 1384676 >>>> >>>> >>>> >>>> 651427 >>>> >>>> >>>> >>>> 580961 >>>> >>>> 4BYTE_ABGR >>>> >>>> >>>> >>>> 544410 >>>> >>>> >>>> >>>> 499786 >>>> >>>> >>>> >>>> 1292305 >>>> >>>> >>>> >>>> 968783 >>>> >>>> >>>> >>>> 690106 >>>> >>>> >>>> >>>> 683881 >>>> >>>> 4BYTE_ABGR_PRE >>>> >>>> >>>> >>>> 504249 >>>> >>>> >>>> >>>> 505588 >>>> >>>> >>>> >>>> 1680086 >>>> >>>> >>>> >>>> 1216445 >>>> >>>> >>>> >>>> 756101 >>>> >>>> >>>> >>>> 687750 >>>> >>>> USHORT_565_RGB >>>> >>>> >>>> >>>> 507818 >>>> >>>> >>>> >>>> 505588 >>>> >>>> >>>> >>>> 978153 >>>> >>>> >>>> >>>> 1346746 >>>> >>>> >>>> >>>> 652908 >>>> >>>> >>>> >>>> 655782 >>>> >>>> USHORT_555_RGB >>>> >>>> >>>> >>>> 510496 >>>> >>>> >>>> >>>> 509604 >>>> >>>> >>>> >>>> 952272 >>>> >>>> >>>> >>>> 1162004 >>>> >>>> >>>> >>>> 650418 >>>> >>>> >>>> >>>> 670811 >>>> >>>> BYTE_GRAY >>>> >>>> >>>> >>>> 481491 >>>> >>>> >>>> >>>> 478367 >>>> >>>> >>>> >>>> 1140585 >>>> >>>> >>>> >>>> 1799231 >>>> >>>> >>>> >>>> 691160 >>>> >>>> >>>> >>>> 583250 >>>> >>>> USHORT_GRAY >>>> >>>> >>>> >>>> 506927 >>>> >>>> >>>> >>>> 507373 >>>> >>>> >>>> >>>> 1375751 >>>> >>>> >>>> >>>> 1255267 >>>> >>>> >>>> >>>> 728202 >>>> >>>> >>>> >>>> 646902 >>>> >>>> BYTE_BINARY >>>> >>>> >>>> >>>> 541733 >>>> >>>> >>>> >>>> 496217 >>>> >>>> >>>> >>>> 1083466 >>>> >>>> >>>> >>>> 959411 >>>> >>>> >>>> >>>> 730527 >>>> >>>> >>>> >>>> 728461 >>>> >>>> The changes are tested with plain images having primary colors like >>>> RED, GREEN, BLUE, BLACK and WHITE. >>>> >>>> Thanks, >>>> >>>> Jay >>>> >>>> -----Original Message----- >>>> From: Jim Graham >>>> Sent: Friday, February 12, 2016 4:05 AM >>>> To: Jayathirth D V; 2d-dev at openjdk.java.net; Philip Race; Prasanta >>>> Sadhukhan >>>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : >>>> Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED >>>> >>>> Hi Jayathirth, >>>> >>>> Did you do any performance analysis of this change? You are adding >>>> 6 tests and multiple branches to per-pixel code. >>>> >>>> The effectiveness of this technique depends on the colormap that we >>>> have set up. For the BufferedImage.TYPE_INDEXED constructor we >>>> produce a fairly nice colormap, but if someone creates a custom >>>> colormap then the colors could be anything. We create a decent >>>> inversion for just about any colormap, but that doesn't mean that >>>> using only "the best match for solid red" will produce a better >>>> result for a dithered approximation for red. It is true that if >>>> there is a really good match for red then we should just use that, >>>> but if there are no direct matches for red then we may choose to >>>> paint a red region with solid orange even though there is another >>>> color in the colormap that when mixed with orange approximates a >>>> red tone better. For example, if a colormap contains no pure red, >>>> but >>>> >>>> contains: >>>> >>>> 240, 20, 0 >>>> >>>> 240, 0, 20 >>>> >>>> (I'm not sure if 20 is within our current error deltas that we use >>>> for dithering, but this is an example not a test case.) >>>> >>>> Then using one of these alone might skew the color towards orange >>>> or purple. Using both together in a dither pattern might keep the >>>> overall hue impression as red, but with a small amount of noise in >>>> its saturation. >>>> >>>> What types of colormaps was this tested with? >>>> >>>> ...jim >>>> >>>> On 2/11/16 6:37 AM, Jayathirth D V wrote: >>>> >>>>> Hi, >>>> >>>>> >>>> >>>>> _Please review the following fix in JDK9:_ >>>> >>>>> >>>> >>>>> __ >>>> >>>>> >>>> >>>>> Bug :https://bugs.openjdk.java.net/browse/JDK-7116979 >>>> >>>>> >>>> >>>>> Webrev :http://cr.openjdk.java.net/~jdv/7116979/webrev.00/ >>>> >>>>> >>>> >>>>> Issue : When Image containing black pixels are converted from any >>>> >>>>> format to Byte Indexed format some of the pixels are not black. >>>>> They >>>> >>>>> are following pattern similar to dithering. >>>> >>>>> >>>> >>>>> Root cause : When we convert any format type to ByteIndexed we are >>>> >>>>> adding Error delta values to R,G,B components using dithering >>>>> indices. >>>> >>>>> This is causing some pixels values to not point to proper index in >>>> >>>>> color table. >>>> >>>>> >>>> >>>>> Solution : There is no need to add error delta for primary colors >>>> >>>>> containing basic values in R,G,B components. Exclude such pixels >>>>> from >>>> >>>>> delta addition. >>>> >>>>> >>>> >>>>> Thanks, >>>> >>>>> >>>> >>>>> Jay >>>> >>>>> >>>> From brian.burkhalter at oracle.com Fri Apr 29 14:38:12 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 29 Apr 2016 07:38:12 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8149810: TIFFField#getAsLong throws ClassCastException when data is type TIFFTag.TIFF_DOUBLE or TIFFTag.FLOAT Message-ID: Please review at your convenience: Issue: https://bugs.openjdk.java.net/browse/JDK-8149810 Patch: http://cr.openjdk.java.net/~bpb/8149810/webrev.00/ Summary: 1) Fix the code which caused the exception. 2) Update the specification of getAsLong() to be similar to that of getAsInt(), i.e., complete and accurate. Thanks, Brian From anton.tarasov at jetbrains.com Fri Apr 29 15:01:02 2016 From: anton.tarasov at jetbrains.com (Anton Tarasov) Date: Fri, 29 Apr 2016 18:01:02 +0300 Subject: [OpenJDK 2D-Dev] [8u/9] Review request: JDK-8028486 [TEST_BUG] [macosx] java/awt/Window/WindowsLeak/WindowsLeak.java fails In-Reply-To: References: <19B7AD38-1D66-4657-8A03-EDE2089C7BEB@jetbrains.com> <0788a529-50d2-4468-a5c5-5cc459136f75@oracle.com> <102685E0-5948-47CC-9C9F-1A73800AB753@jetbrains.com> Message-ID: <520095F8-933F-47CC-92A1-D412B06FC625@jetbrains.com> [CC?ing to 2d-dev to discuss the issue] > On 29 Apr 2016, at 16:14, Sergey Bylokhov wrote: > > On 29.04.16 15:53, Anton Tarasov wrote: >> It seems so. But that might be not that critical, because it doesn?t hold (it won?t) any UI controls and all the UI tree. Anyway it leaks, yes. > > Looks like this is crossplatform bug and it also affects d3d/ogl. So probably we can fix it on the upper level? validatedSrc/Dst/Data is stored the surfaces which were validated and ready to paint. from the first point of view we can change them to soft reference, and take care about null values. Are the validatedSrc/Dst/Data objects referenced from somewhere else? They are private, so from native? If not, soft refs won?t help I?m afraid... This is not the case for CGLLayer, which is referenced from JNI. And so, wrapping it with a weak ref will work. Also, if the SurfaceData is uniquely tight to the layer, then it seems natural to dispose (not flush) it with the layer disposal. And that?s actually the case: LWWindowPeer.disposeImpl() invalidates it. But the problem is that invalidation doesn?t release the layer. So, again the question is: should the layer be nullified on invalidation or it should be made a weak ref? For me this seems quite logical to release resources on disposal/invalidation, what do you think? As to the fixing the issue globally, I don?t have enough understanding of the pipe design so that to do that properly. For instance, as I wrote before, I don?t know under which conditions the context should/may be disposed? May be someone else can advice on it. Thanks, Anton. > Note that such changes are 2d related code and should be reviewed on 2d-dev. > >> >>> Assigned the peer/surfaceData to null in CGLayer can causes an NPE in all its usage, because there is no any synchronization which will prevent the usage of CGLayer after disposing. >> >> That?s bad. Will wrapping the refs with AtomicReference help? >> >>> >>> Unrelated to the fix, but it seems we should call flush() on surface when the layer is disposed, at least I do not understand where we flush the native ogl data for the latest surface data. >> >> >> This will trigger CGLLayerSurfaceData.invalidate(), but the ?layer? will still not be nullified. What about nullifying it in invalidate()? Will we face the same synchronisation issue? >> >> Anton. >> >>> >>> On 29.04.16 15:00, Anton Tarasov wrote: >>>> Hi Sergey, Alexander, >>>> >>>> Please review the fix: >>>> >>>> bug: JDK-8028486 [TEST_BUG] [macosx] java/awt/Window/WindowsLeak/WindowsLeak.java fails >>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8028486/webrev.0 >>>> >>>> I?m copying my comment from CR: >>>> >>>> Please open the attached screenshot [*], made with YourKit, where a chain of links is shown from the GC roots. >>>> The frame is held by its peer which is held by CGLLayer which is held as validatedSrcData in the GL context. >>>> The point is that the GL context doesn't cleanup the last state until under some conditions, which are not applicable to this scenario. >>>> I'm not sure should the cleanup be triggered here or not, but the problem can be solved otherwise. >>>> >>>> The point is that in the chain the CGLLayer instance has been disposed, in response to the frame disposal. >>>> So, this is the only ref that holds it (the JNI ref is released by the native peer on disposal). >>>> Thus, as the layer is disposed it can at least zero all the java refs it holds (this change already fixes the problem). >>>> Then, the "layer" ref in CGLLayerSurfaceData should probably be made weak. >>>> >>>> [*] https://bugs.openjdk.java.net/secure/attachment/59121/8028486.png >>>> >>>> As to the ?weak ref? mentioned in the comment. I didn?t do that, but if you find it reasonable I can add that change (or file a separate CR). >>>> >>>> Also, the fix contains some additional cleanup (not related to this CR): two more JNI local refs leak, fixed. >>>> >>>> Thanks, >>>> Anton. >>>> >>> >>> >>> -- >>> Best regards, Sergey. >> > > > -- > Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri Apr 29 15:19:36 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 29 Apr 2016 18:19:36 +0300 Subject: [OpenJDK 2D-Dev] [8u/9] Review request: JDK-8028486 [TEST_BUG] [macosx] java/awt/Window/WindowsLeak/WindowsLeak.java fails In-Reply-To: <520095F8-933F-47CC-92A1-D412B06FC625@jetbrains.com> References: <19B7AD38-1D66-4657-8A03-EDE2089C7BEB@jetbrains.com> <0788a529-50d2-4468-a5c5-5cc459136f75@oracle.com> <102685E0-5948-47CC-9C9F-1A73800AB753@jetbrains.com> <520095F8-933F-47CC-92A1-D412B06FC625@jetbrains.com> Message-ID: <27d8cf9f-c740-3aa5-8310-dbd9938b5327@oracle.com> On 29.04.16 18:01, Anton Tarasov wrote: > [CC?ing to 2d-dev to discuss the issue] > >> On 29 Apr 2016, at 16:14, Sergey Bylokhov wrote: >> >> On 29.04.16 15:53, Anton Tarasov wrote: >>> It seems so. But that might be not that critical, because it doesn?t hold (it won?t) any UI controls and all the UI tree. Anyway it leaks, yes. >> >> Looks like this is crossplatform bug and it also affects d3d/ogl. So probably we can fix it on the upper level? validatedSrc/Dst/Data is stored the surfaces which were validated and ready to paint. from the first point of view we can change them to soft reference, and take care about null values. > > Are the validatedSrc/Dst/Data objects referenced from somewhere else? They are private, so from native? If not, soft refs won?t help I?m afraid... I guess it is used in BufferedContext only, to skip updates of the native ogl/d3d context if the target/source surfaces were not changed since the last update. > > This is not the case for CGLLayer, which is referenced from JNI. And so, wrapping it with a weak ref will work. Also, if the SurfaceData is uniquely tight to the layer, then it seems natural to dispose (not flush) it with the layer disposal. And that?s actually the case: LWWindowPeer.disposeImpl() invalidates it. > But the problem is that invalidation doesn?t release the layer. Yes, that's right the surface and layer are bound to each other(and the layer can have more than one surface). So I do not see a reason why we should break the link between them, which causes the surface to live more time than its layer. I guess the right things to do is to fix the "gc root", since we have no cycles here. > > So, again the question is: should the layer be nullified on invalidation or it should be made a weak ref? For me this seems quite logical to release resources on disposal/invalidation, what do you think? > > As to the fixing the issue globally, I don?t have enough understanding of the pipe design so that to do that properly. For instance, as I wrote before, I don?t know under which conditions the context should/may be disposed? > > May be someone else can advice on it. I can take a look, but are you sure that the test "WindowsLeak.java" reproduce exactly your problem? >> Note that such changes are 2d related code and should be reviewed on 2d-dev. >> >>> >>>> Assigned the peer/surfaceData to null in CGLayer can causes an NPE in all its usage, because there is no any synchronization which will prevent the usage of CGLayer after disposing. >>> >>> That?s bad. Will wrapping the refs with AtomicReference help? >>> >>>> >>>> Unrelated to the fix, but it seems we should call flush() on surface when the layer is disposed, at least I do not understand where we flush the native ogl data for the latest surface data. >>> >>> >>> This will trigger CGLLayerSurfaceData.invalidate(), but the ?layer? will still not be nullified. What about nullifying it in invalidate()? Will we face the same synchronisation issue? >>> >>> Anton. >>> >>>> >>>> On 29.04.16 15:00, Anton Tarasov wrote: >>>>> Hi Sergey, Alexander, >>>>> >>>>> Please review the fix: >>>>> >>>>> bug: JDK-8028486 [TEST_BUG] [macosx] java/awt/Window/WindowsLeak/WindowsLeak.java fails >>>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8028486/webrev.0 >>>>> >>>>> I?m copying my comment from CR: >>>>> >>>>> Please open the attached screenshot [*], made with YourKit, where a chain of links is shown from the GC roots. >>>>> The frame is held by its peer which is held by CGLLayer which is held as validatedSrcData in the GL context. >>>>> The point is that the GL context doesn't cleanup the last state until under some conditions, which are not applicable to this scenario. >>>>> I'm not sure should the cleanup be triggered here or not, but the problem can be solved otherwise. >>>>> >>>>> The point is that in the chain the CGLLayer instance has been disposed, in response to the frame disposal. >>>>> So, this is the only ref that holds it (the JNI ref is released by the native peer on disposal). >>>>> Thus, as the layer is disposed it can at least zero all the java refs it holds (this change already fixes the problem). >>>>> Then, the "layer" ref in CGLLayerSurfaceData should probably be made weak. >>>>> >>>>> [*] https://bugs.openjdk.java.net/secure/attachment/59121/8028486.png >>>>> >>>>> As to the ?weak ref? mentioned in the comment. I didn?t do that, but if you find it reasonable I can add that change (or file a separate CR). >>>>> >>>>> Also, the fix contains some additional cleanup (not related to this CR): two more JNI local refs leak, fixed. >>>>> >>>>> Thanks, >>>>> Anton. >>>>> >>>> >>>> >>>> -- >>>> Best regards, Sergey. >>> >> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. From anton.tarasov at jetbrains.com Fri Apr 29 16:24:19 2016 From: anton.tarasov at jetbrains.com (Anton Tarasov) Date: Fri, 29 Apr 2016 19:24:19 +0300 Subject: [OpenJDK 2D-Dev] [8u/9] Review request: JDK-8028486 [TEST_BUG] [macosx] java/awt/Window/WindowsLeak/WindowsLeak.java fails In-Reply-To: <27d8cf9f-c740-3aa5-8310-dbd9938b5327@oracle.com> References: <19B7AD38-1D66-4657-8A03-EDE2089C7BEB@jetbrains.com> <0788a529-50d2-4468-a5c5-5cc459136f75@oracle.com> <102685E0-5948-47CC-9C9F-1A73800AB753@jetbrains.com> <520095F8-933F-47CC-92A1-D412B06FC625@jetbrains.com> <27d8cf9f-c740-3aa5-8310-dbd9938b5327@oracle.com> Message-ID: <2494F3E6-9506-4F8D-B447-F33F9010440D@jetbrains.com> > On 29 Apr 2016, at 18:19, Sergey Bylokhov wrote: > > On 29.04.16 18:01, Anton Tarasov wrote: >> [CC?ing to 2d-dev to discuss the issue] >> >>> On 29 Apr 2016, at 16:14, Sergey Bylokhov wrote: >>> >>> On 29.04.16 15:53, Anton Tarasov wrote: >>>> It seems so. But that might be not that critical, because it doesn?t hold (it won?t) any UI controls and all the UI tree. Anyway it leaks, yes. >>> >>> Looks like this is crossplatform bug and it also affects d3d/ogl. So probably we can fix it on the upper level? validatedSrc/Dst/Data is stored the surfaces which were validated and ready to paint. from the first point of view we can change them to soft reference, and take care about null values. >> >> Are the validatedSrc/Dst/Data objects referenced from somewhere else? They are private, so from native? If not, soft refs won?t help I?m afraid... > > I guess it is used in BufferedContext only, to skip updates of the native ogl/d3d context if the target/source surfaces were not changed since the last update. Ok. > >> >> This is not the case for CGLLayer, which is referenced from JNI. And so, wrapping it with a weak ref will work. Also, if the SurfaceData is uniquely tight to the layer, then it seems natural to dispose (not flush) it with the layer disposal. And that?s actually the case: LWWindowPeer.disposeImpl() invalidates it. >> But the problem is that invalidation doesn?t release the layer. > > Yes, that's right the surface and layer are bound to each other(and the layer can have more than one surface). So I do not see a reason why we should break the link between them, which causes the surface to live more time than its layer. I guess the right things to do is to fix the "gc root", since we have no cycles here. Are you suggesting to kill GraphicsEnvironment? But what if frames are recreated? Then recreate it? > >> >> So, again the question is: should the layer be nullified on invalidation or it should be made a weak ref? For me this seems quite logical to release resources on disposal/invalidation, what do you think? >> >> As to the fixing the issue globally, I don?t have enough understanding of the pipe design so that to do that properly. For instance, as I wrote before, I don?t know under which conditions the context should/may be disposed? >> >> May be someone else can advice on it. > > I can take a look, but are you sure that the test "WindowsLeak.java" reproduce exactly your problem? My problem is that there?s a number of revealed JDK leaks on Mac. And this one looks like the last in the list ) So, if you please take a look I?d appreciate. Thanks, Anton. > >>> Note that such changes are 2d related code and should be reviewed on 2d-dev. >>> >>>> >>>>> Assigned the peer/surfaceData to null in CGLayer can causes an NPE in all its usage, because there is no any synchronization which will prevent the usage of CGLayer after disposing. >>>> >>>> That?s bad. Will wrapping the refs with AtomicReference help? >>>> >>>>> >>>>> Unrelated to the fix, but it seems we should call flush() on surface when the layer is disposed, at least I do not understand where we flush the native ogl data for the latest surface data. >>>> >>>> >>>> This will trigger CGLLayerSurfaceData.invalidate(), but the ?layer? will still not be nullified. What about nullifying it in invalidate()? Will we face the same synchronisation issue? >>>> >>>> Anton. >>>> >>>>> >>>>> On 29.04.16 15:00, Anton Tarasov wrote: >>>>>> Hi Sergey, Alexander, >>>>>> >>>>>> Please review the fix: >>>>>> >>>>>> bug: JDK-8028486 [TEST_BUG] [macosx] java/awt/Window/WindowsLeak/WindowsLeak.java fails >>>>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8028486/webrev.0 >>>>>> >>>>>> I?m copying my comment from CR: >>>>>> >>>>>> Please open the attached screenshot [*], made with YourKit, where a chain of links is shown from the GC roots. >>>>>> The frame is held by its peer which is held by CGLLayer which is held as validatedSrcData in the GL context. >>>>>> The point is that the GL context doesn't cleanup the last state until under some conditions, which are not applicable to this scenario. >>>>>> I'm not sure should the cleanup be triggered here or not, but the problem can be solved otherwise. >>>>>> >>>>>> The point is that in the chain the CGLLayer instance has been disposed, in response to the frame disposal. >>>>>> So, this is the only ref that holds it (the JNI ref is released by the native peer on disposal). >>>>>> Thus, as the layer is disposed it can at least zero all the java refs it holds (this change already fixes the problem). >>>>>> Then, the "layer" ref in CGLLayerSurfaceData should probably be made weak. >>>>>> >>>>>> [*] https://bugs.openjdk.java.net/secure/attachment/59121/8028486.png >>>>>> >>>>>> As to the ?weak ref? mentioned in the comment. I didn?t do that, but if you find it reasonable I can add that change (or file a separate CR). >>>>>> >>>>>> Also, the fix contains some additional cleanup (not related to this CR): two more JNI local refs leak, fixed. >>>>>> >>>>>> Thanks, >>>>>> Anton. >>>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >>>> >>> >>> >>> -- >>> Best regards, Sergey. >> > > > -- > Best regards, Sergey. From brian.burkhalter at oracle.com Fri Apr 29 16:45:31 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 29 Apr 2016 09:45:31 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8151323: GeoTIFFTagSet#"ModelTiePointTag" name case does not match GeoTIFF specification Message-ID: <0D7FD475-E247-42DF-99CA-715E7FEB3462@oracle.com> Please review at your convenience: Issue: https://bugs.openjdk.java.net/browse/JDK-8151323 Patch: http://cr.openjdk.java.net/~bpb/8151323/webrev.00/ Summary: s/ModelTiePointTag/ModelTiepointTag/ Thanks, Brian From alexander.potochkin at oracle.com Fri Apr 29 16:58:26 2016 From: alexander.potochkin at oracle.com (Alexander Potochkin) Date: Fri, 29 Apr 2016 19:58:26 +0300 Subject: [OpenJDK 2D-Dev] [PATCH] JDK-8146035: Windows - With LCD antialiasing, some glyphs are not rendered correctly In-Reply-To: <570F5C43.6060601@oracle.com> References: <570D2EE1.1040809@oracle.com> <570F5C43.6060601@oracle.com> Message-ID: <1b301994-1ab6-b582-41f1-2b4a84c7cf09@oracle.com> for the reference: the fix was committed to JDK8 and JDK9 Thank you Dmitry for your contribution! alexp On 4/14/2016 12:00, Alexey Ivanov wrote: > Hi Phil, > > Thank you very much for your reviewing the code and approving the fix. > > I have uploaded the webrev to OpenJDK: > http://cr.openjdk.java.net/~aivanov/dmitry.batrak/8146035/jdk9/webrev.00/ > > The patch is the same. > > On 12.04.2016 20:22, Phil Race wrote: >> Alexey didn't say this but he already proposed exactly this fix himself >> in a private email exchange, > > I didn't say that because it was Dmitry who was the original author of > the fix. :) > Alex and I asked Dmitry to submit his fix to the public alias to give > him proper credit as the author of the fix. > > > Regards, > Alexey > >> >> +1, although I am not sure we can legally pull down the patch from >> that (any) website. >> Please resubmit it as a diff in the email. >> >> Or Alexey could just push it as his own :-) >> >> -phil. >> >> On 04/07/2016 05:26 AM, Dmitry Batrak wrote: >>> Hello, >>> >>> I'd like to propose a fix for JDK-8146035. I am not a committer, >>> so I hope someone can sponsor this fix. >>> I work at Jetbrains, which has signed a company-level contributor >>> agreement, >>> so, from a legal perspective, I believe, there are no obstacles. >>> >>> My investigation shows that the issue is caused by incorrect >>> determination >>> of bitmap size, prepared for glyph rendering, so only part of glyph >>> becomes visible due to cropping. This seems to happen because >>> compatible bitmap is not selected into memory device context (DC) >>> before calling GetTextMetrics. Documentation for CreateCompatibleDC >>> call >>> (https://msdn.microsoft.com/en-us/library/windows/desktop/dd183489%28v=vs.85%29.aspx) >>> >>> says compatible bitmap needs to be selected into DC before any >>> drawing operation. >>> Even though GetTextMetrics is not a drawing operation, it turns out >>> to be affected by selected bitmap's type too (by default a >>> monochrome bitmap >>> is selected in a memory DC). This behaviour was also mentioned in >>> the following >>> MSDN blog post comment: >>> https://blogs.msdn.microsoft.com/oldnewthing/20060614-00/?p=30873#comment-392143 >>> >>> >>> The proposed fix is to select a temporary 1x1 compatible bitmap >>> into memory DC before GetTextMetrics call. >>> Here's webrev link - http://adm-12504.intellij.net/ >>> I didn't create a test case, as it would require a specific font file >>> (I couldn't reproduce the issue for fonts bundled with Windows). >>> >>> Best regards, >>> Dmitry Batrak >> > From brian.burkhalter at oracle.com Fri Apr 29 17:50:48 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 29 Apr 2016 10:50:48 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8149560: TIFFField#createFromMetadataNode throws a NullPointerException when the node is set with "tagNumber" attribute Message-ID: <9DA3AAA5-F4DF-4985-8E7B-0BE0D9AE6374@oracle.com> Please review at your convenience: Issue: https://bugs.openjdk.java.net/browse/JDK-8149560 Patch: http://cr.openjdk.java.net/~bpb/8149560/webrev.00/ Summary: 1) Change the specification of createFromMetadataNode() to change the tag number attribute name from ?tagNumber? to ?number? in accord with the javax_imageio_tiff_image_1.0 native image metadata format specification. 2) Add a couple of @throws clauses to clarify exceptions which might ensure from a bad node parameter?s being passed in to createFromMetadataNode(). Thanks, Brian From philip.race at oracle.com Fri Apr 29 17:52:41 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 29 Apr 2016 10:52:41 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8149560: TIFFField#createFromMetadataNode throws a NullPointerException when the node is set with "tagNumber" attribute In-Reply-To: <9DA3AAA5-F4DF-4985-8E7B-0BE0D9AE6374@oracle.com> References: <9DA3AAA5-F4DF-4985-8E7B-0BE0D9AE6374@oracle.com> Message-ID: <57239F69.40406@oracle.com> +1 -phil. On 04/29/2016 10:50 AM, Brian Burkhalter wrote: > Please review at your convenience: > > Issue: https://bugs.openjdk.java.net/browse/JDK-8149560 > Patch: http://cr.openjdk.java.net/~bpb/8149560/webrev.00/ > > Summary: > 1) Change the specification of createFromMetadataNode() to change the tag number attribute name from ?tagNumber? to ?number? in accord with the javax_imageio_tiff_image_1.0 native image metadata format specification. > 2) Add a couple of @throws clauses to clarify exceptions which might ensure from a bad node parameter?s being passed in to createFromMetadataNode(). > > Thanks, > > Brian From philip.race at oracle.com Fri Apr 29 17:53:34 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 29 Apr 2016 10:53:34 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8151323: GeoTIFFTagSet#"ModelTiePointTag" name case does not match GeoTIFF specification In-Reply-To: <0D7FD475-E247-42DF-99CA-715E7FEB3462@oracle.com> References: <0D7FD475-E247-42DF-99CA-715E7FEB3462@oracle.com> Message-ID: <57239F9E.7070201@oracle.com> +1 -phil On 04/29/2016 09:45 AM, Brian Burkhalter wrote: > Please review at your convenience: > > Issue: https://bugs.openjdk.java.net/browse/JDK-8151323 > Patch: http://cr.openjdk.java.net/~bpb/8151323/webrev.00/ > > Summary: > s/ModelTiePointTag/ModelTiepointTag/ > > Thanks, > > Brian From philip.race at oracle.com Fri Apr 29 17:54:17 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 29 Apr 2016 10:54:17 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8149810: TIFFField#getAsLong throws ClassCastException when data is type TIFFTag.TIFF_DOUBLE or TIFFTag.FLOAT In-Reply-To: References: Message-ID: <57239FC9.90509@oracle.com> +1 -phil. On 04/29/2016 07:38 AM, Brian Burkhalter wrote: > Please review at your convenience: > > Issue: https://bugs.openjdk.java.net/browse/JDK-8149810 > Patch: http://cr.openjdk.java.net/~bpb/8149810/webrev.00/ > > Summary: > 1) Fix the code which caused the exception. > 2) Update the specification of getAsLong() to be similar to that of getAsInt(), i.e., complete and accurate. > > Thanks, > > Brian From philip.race at oracle.com Fri Apr 29 19:35:42 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 29 Apr 2016 12:35:42 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8155682: Get rid of legacy Windows Flags for DX Message-ID: <5723B78E.5060708@oracle.com> Bug : https://bugs.openjdk.java.net/browse/JDK-8155682 Webrev: http://cr.openjdk.java.net/~prr/8155682/ None of these flags have been referenced since (I think) the current D3D pipeline was integrated in 6u10/jdk7. JPRT built successfully. I was a little conservative in that offscreenSharingEnabled is not used but the comments indicate it is for a feature that may still be of interest some day. -phil. From brian.burkhalter at oracle.com Fri Apr 29 19:53:04 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 29 Apr 2016 12:53:04 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8149816: TIFFField#getValueAsString result is unexpected for RATIONAL and SRATIONAL types (when modulo is 0) Message-ID: <2160C403-DB5F-4EFE-8382-72C3311001B6@oracle.com> Please review at your convenience: Issue: https://bugs.openjdk.java.net/browse/JDK-8149816 Patch: http://cr.openjdk.java.net/~bpb/8149816/webrev.00/ Summary: 1) Verified that the extant behavior is consistent with both the tiffdump and tiffinfo tools from the standard libtiff library. 2) Updated the specification of getValueAsString() to clarify the behavior when the type is [S]RATIONAL and the numerator is an integral multiple of the denominator. Thanks, Brian From james.graham at oracle.com Fri Apr 29 23:13:13 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 29 Apr 2016 16:13:13 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED In-Reply-To: <3ab637db-7b8b-440a-8d65-222f3b5ca55e@default> References: <2c9221dc-ed76-481a-8bee-a694d313448e@default> <56BD0CAB.6080704@oracle.com> <90de7741-c175-4803-9c3e-30b1039b2774@default> <56C227D1.1030600@oracle.com> <46329edf-4cbe-48d4-a519-c908b09844a6@default> <56C789E4.6000409@oracle.com> <7f5f1cd3-4022-4739-b412-9d3f3c74181f@default> <4a833ce4-04b4-0250-e78f-ef60fbd52806@oracle.com> <571FB2D1.30205@oracle.com> <3ab637db-7b8b-440a-8d65-222f3b5ca55e@default> Message-ID: The code changes look good. One question on the test case, though - why is Color.WHITE commented out in the test case? Was it failing? ...jim On 4/29/16 4:45 AM, Jayathirth D V wrote: > Hi, > > Thanks Phil & Jim for your inputs. > I have made all recommended changes. > Please find updated webrev for review : > http://cr.openjdk.java.net/~jdv/7116979/webrev.02/ > > Thanks, > Jay > > -----Original Message----- > From: Phil Race > Sent: Tuesday, April 26, 2016 11:56 PM > To: Jim Graham > Cc: Jayathirth D V; 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED > > On 04/22/2016 06:56 PM, Jim Graham wrote: >> Hi Jay, >> >> It looks like it will work, but there are some inconsistencies in the >> code that we should address and a couple of optimizations. >> >> First, there is a mixture of using "int" and "jboolean" for the type >> of the new boolean parameter. It would be great if we could just >> declare it as jboolean in the structures, but it looks like those are >> limited to basic C types. It seems a little clunky to mix types like >> this, but I'd be interested in hearing what Phil says. I think it >> would be fine to just use int throughout. > > From the ones I've seen may be much better to just use int throughout. Eg > > 264 static jboolean calculatePrimaryColorsAprroximation(int* cmap, unsigned char* cube, int cube_size) { > > aside from having a typo in the name also makes a fair amount of internal uses of jboolean and JNI_TRUE/JNI_FALSE. > > It then does this > > 385 cData->representsPrimary = calculatePrimaryColorsAprroximation(pRgb, cData->img_clr_tbl, 32); > > ie stores it in an int .. I see no reason for this as there is no JNI code involved. > > > Moreover this usage of the variables declared as boolean then has code like > > 174 (representsPrimary == 1))) { \ > > > -phil. > >> >> I'd suggest a name change: >> representsPrimary => representsPrimaries (since there are multiple >> primary colors) >> >> The place to load the variable for testing in the ByteIndexed macros >> would be in the "InitByteIndexedStoreVarsY" macro where it sets up the >> "PREFIX ## InvLut" variable. It should also use a PREFIX. Look >> through those macros for wherever the InvLut value is declared and >> initialized, and follow a similar pattern for "PREFIX ## ". >> You could use "representsPrimaries" for the name here too, but it >> could also be shortened to just "repPrims" or "optPrims" since the >> macros are all centralized here. >> >> Once you do the preceding step, you can delete a lot of lines that >> pre-load the "representsPrimaries" in the calling macros, which should >> also eliminate a lot of files from the webrev. >> >> In the code in ByteIndexed.h:StoreByteIndexedFrom3ByteRgb() that tests >> the variable, I'd just test "representsPrimary" with no "==" rather >> than comparing it to 1 since it is a boolean, not (really) an integer. >> >> With respect to the new function that tests the primary matches (in >> ByteIndexed.c), some of the code is unnecessarily complicated: >> >> - When you find a color match failure (lines 301, et al), you could >> just return false directly. As it stands, you set a variable and >> break, but the break only breaks out of 1 of 3 nested if statements, >> so it doesn't save any calculations. Just return false directly as a >> single failure means the answer is "no". >> >> - your r, g, and b values are extracted from the color in the wrong >> order near line 285. r involves a shift of 16, and b involves no >> shift. I suppose this is paired with computing the dr and db values >> with the wrong indices or this technique wouldn't work, but it is >> clunky to name the variables inconsistently with the data they >> actually hold. >> >> - you use parentheses on the left-hand side of an assignment when you >> extract the r, g, and b values (also near line 285). You don't need >> parentheses on that side of an assignment operator. >> >> There are several things that are more complicated than they need to >> be with your testing lines. They use a lot more computations than you >> need. For instance: >> >> - You test the i,j,k using a modulus operation (lines 298, 312, 326), >> but really you just need to know if it is 0 or not-0, so just test it >> for ==0 or !=0. >> - rather than using multiplication and modulus to assign the dr,dg,db >> values near line 291, why not just use "dr = (i == 0) ? 0 : 255;"? >> - the tests for range use a separate subtraction and a compare, when >> they could be inlined. >> >> First, I'd get rid of the "represents_primary" variable entirely and >> then rewrite the whole tail end of the loop body from 291 to the end >> of the loop as: >> >> if (i == 0) { >> if (r > delta) return false; >> } else { >> if (r < 255-delta) return false; >> } >> // 2 more similar tests for j/g and k/b >> >> Then "return true" at the end of the function if it reaches there. >> Keep in mind that the mapping of ijk to rgb might be affected if you >> fix the shifts used to extract the rgb components from color... >> >> ...jim >> >> On 4/20/2016 2:46 AM, Jayathirth D V wrote: >>> Hi Jim, >>> >>> As discussed we will not add dithering error values to primary colors >>> with color map which represents Primary colors approximately(+/-5 >>> delta). >>> I have made changes based on this suggestion and added new function >>> to calculate whether color map represents primary colors >>> approximately or not. >>> If it represents only then we will avoid adding dithering error >>> values in case ByteIndexed destination. >>> >>> I have observed that in case of white color we are picking >>> (252,252,252) or (246,246,246) and not (255,255,255) from colormap. >>> What I have observed that out of 256 places we are storing RGB colors >>> at start and then gray values. So we are picking final gray value and >>> not in between white value. That's why I am not verifying white color >>> validity in test case. >>> >>> Please find updated webrev for review : >>> http://cr.openjdk.java.net/~jdv/7116979/webrev.01/ >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Jim Graham >>> Sent: Saturday, February 20, 2016 3:02 AM >>> To: Jayathirth D V >>> Cc: 2d-dev at openjdk.java.net; Philip Race; Prasanta Sadhukhan >>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : >>> Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED >>> >>> Hi Jayathirth, >>> >>> Thank you for attaching the detailed logs, but I don't have a program >>> that can deal with the 7z files. Can you summarize what was learned >>> from them? >>> >>> Also, the colormap you created, while subset, was a perfectly scaled >>> cube. I was referring more to a random colormap where you might have >>> 2 colors close to a primary, but neither is on a line from the >>> primary to the 0.5 gray value so each has a different hue. That's >>> something that can only be evaluated visually. One example of >>> randomized colormaps is when we display via X11 onto an 8-bit >>> display. That probably never happens any more, but we may not be >>> able to allocate colors in the colormap in such a case and if another >>> program has already allocated most of the dynamic colormap then we >>> would not be able to add our own colors. >>> >>> This could be dealt with by simply marking our standard colormap as >>> having primaries, or by scanning any given colormap and marking it if >>> it has primaries, and then only perform this code on colormaps with >>> the primaries. Solving it for our own colormap (or solving it for >>> any colormap that has all primaries) would likely solve it for 99% of >>> the vanishingly small number of developers who might run into this. >>> >>> But, in the end, what would we accomplish by adding this one very >>> targeted fix? >>> >>> I'm also curious where the push for this is coming from. While we >>> aren't perfect here, so much of the world today is focused on >>> lossless image formats that I don't imagine there is much need for >>> really good 8-bit indexed image support any more...? >>> >>> If anything, spatial dithering is considered a very low quality >>> algorithm and error propagation dithering would handle all of the >>> colormaps much better. We used to do error propagation dithering >>> back in the JDK 1.1 days, but we dropped it when we introduced 2D >>> because we added a bunch of ways to render small pieces of an image >>> and only the current spatial dithering algorithm can be started in >>> the middle of an operation. That doesn't mean that you can't still >>> do error propagation since many operations already operate on the >>> full image any way and you can still handle subset image operations >>> by either converting the full image first and then copying or by >>> tracing the errors from the edge of the image to the point of the >>> subimage operation. We never bothered to upgrade our algorithms it >>> just never seemed to be work that made sense to prioritize given that >>> screens were overwhelmingly moving to full-color at the time of "Java >>> 2" (and now to HDR in 2016+). 8-bit indexed isn't used much any more. >>> >>> If we want to make 8-bit destination images work better we'd be >>> better off adopting error propagation dithering again rather than >>> trying to tune this algorithm for black. >>> >>> It looks like the bug was closed briefly in 2014 and then reopened >>> soon thereafter with no justification. It is true that we still have >>> this anomaly, but it isn't clear why this is high enough priority to >>> work on in 2016 when other bit depths would work better for >>> destination imagery and other dithering algorithms would work better >>> for most customers and even this targeted fix isn't perfect... >>> >>> ...jim >>> >>> On 2/16/2016 8:32 AM, Jayathirth D V wrote: >>>> Hi Jim, >>>> >>>> Thanks for letting me know about the importance of custom color >>>> maps. I was not able to understand what you mentioned previously >>>> since I am new to this terminology. >>>> >>>> Regarding performance I checked with image having complete >>>> 255,255,128 pixels and ran it for 100 times. I am running on Windows >>>> 7 Professional SP1 with Intel i5-5300U CPU. Overall I don't see >>>> much difference in time taken for drawImage() API before and after >>>> change. Details for INT_RGB image as input: >>>> >>>> Before change : >>>> Minimum time 536827ns >>>> Maximum time 1560947ns >>>> Average time 871167ns >>>> >>>> After change : >>>> Minimum time 536380ns >>>> Maximum time 1468130ns >>>> Average time 830778ns >>>> >>>> There is +/- 10% delta both for before and after change time but >>>> there is no major gap. Even for image with other input type it holds >>>> the same. >>>> >>>> >>>> Regarding custom color maps, previously I ran on default color map >>>> generated in TYPE_BYTE_INDEXED constructor. Now I tested with >>>> modified color map so that it doesn't contain any of the primary >>>> color values. Instead of using 0-255 values with value 51 increments >>>> in R,G,B components I used color map with 20-245 values with value >>>> 45 as increment. For this color map before and after change all the >>>> pixels are referring to same index in color map irrespective of >>>> removal of error delta addition in case of primary colors. >>>> >>>> I have attached log for Red and Green primary colors before and >>>> after change(Was not able to attach for more since it exceeded 120KB >>>> mailing list limit). Please search for "Final index value =" in the >>>> logs. Please let me know your inputs. >>>> >>>> Thanks, >>>> Jay >>>> >>>> -----Original Message----- >>>> From: Jim Graham >>>> Sent: Tuesday, February 16, 2016 1:03 AM >>>> To: Jayathirth D V >>>> Cc: 2d-dev at openjdk.java.net; Philip Race; Prasanta Sadhukhan >>>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : >>>> Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED >>>> >>>> Hi Jayathirth, >>>> >>>> The issue with testing performance with white images is that the >>>> tests allow the code to eliminate 3 indexed fetches which take time. >>>> Primary colors end up being the one obscure case where the new code >>>> might be faster. But, non-primary colors would be slower by a fair >>>> amount, so performance testing with converting a randomized or >>>> non-primary-color image are the more telling case. An image filled >>>> with 255,255,128 would be the worst case because it would involve >>>> all of the tests and still have to do all of the lookups. >>>> >>>> My question about how this works with custom colormaps was not >>>> really addressed by your response. A simple test to make sure the >>>> colormap has accurate (or very close) conversions for the primary >>>> colors may be enough to validate the colormap for the indicated >>>> tests. If the colormap contains no pure conversions for some of the >>>> primary colors then they may need to be dithered anyway... >>>> >>>> ...jim >>>> >>>> On 2/15/16 3:39 AM, Jayathirth D V wrote: >>>>> Hi Jim, >>>>> >>>>> I performed performance analysis with white image so that all >>>>> conditions are checked in the new branch added. There is no major >>>>> difference in time taken before and after change. For each input I >>>>> have tested time taken for drawImage() API to convert from every >>>>> format to Byte indexed type. For every unique conversion test is >>>>> run for 100 times. Please find the details: >>>>> >>>>> Input >>>>> >>>>> type >>>>> >>>>> >>>>> >>>>> Min >>>>> >>>>> before change >>>>> >>>>> (ns) >>>>> >>>>> >>>>> >>>>> Min >>>>> >>>>> after change >>>>> >>>>> (ns) >>>>> >>>>> >>>>> >>>>> Max >>>>> >>>>> before change >>>>> >>>>> (ns) >>>>> >>>>> >>>>> >>>>> Max >>>>> >>>>> after change >>>>> >>>>> (ns) >>>>> >>>>> >>>>> >>>>> Average >>>>> >>>>> before change >>>>> >>>>> (ns) >>>>> >>>>> >>>>> >>>>> Average >>>>> >>>>> after >>>>> >>>>> change >>>>> >>>>> (ns) >>>>> >>>>> INT_RGB >>>>> >>>>> >>>>> >>>>> 523437 >>>>> >>>>> >>>>> >>>>> 481491 >>>>> >>>>> >>>>> >>>>> 1230724 >>>>> >>>>> >>>>> >>>>> 1270440 >>>>> >>>>> >>>>> >>>>> 789452 >>>>> >>>>> >>>>> >>>>> 666144 >>>>> >>>>> INT_ARGB >>>>> >>>>> >>>>> >>>>> 500232 >>>>> >>>>> >>>>> >>>>> 493986 >>>>> >>>>> >>>>> >>>>> 12406307 >>>>> >>>>> >>>>> >>>>> 1308816 >>>>> >>>>> >>>>> >>>>> 793384 >>>>> >>>>> >>>>> >>>>> 654015 >>>>> >>>>> INT_ARGB_PRE >>>>> >>>>> >>>>> >>>>> 500233 >>>>> >>>>> >>>>> >>>>> 492201 >>>>> >>>>> >>>>> >>>>> 1037057 >>>>> >>>>> >>>>> >>>>> 981277 >>>>> >>>>> >>>>> >>>>> 710250 >>>>> >>>>> >>>>> >>>>> 699214 >>>>> >>>>> INT_BGR >>>>> >>>>> >>>>> >>>>> 537716 >>>>> >>>>> >>>>> >>>>> 562706 >>>>> >>>>> >>>>> >>>>> 1446703 >>>>> >>>>> >>>>> >>>>> 2046001 >>>>> >>>>> >>>>> >>>>> 862377 >>>>> >>>>> >>>>> >>>>> 863256 >>>>> >>>>> 3BYTE_BGR >>>>> >>>>> >>>>> >>>>> 483275 >>>>> >>>>> >>>>> >>>>> 481045 >>>>> >>>>> >>>>> >>>>> 1181638 >>>>> >>>>> >>>>> >>>>> 1384676 >>>>> >>>>> >>>>> >>>>> 651427 >>>>> >>>>> >>>>> >>>>> 580961 >>>>> >>>>> 4BYTE_ABGR >>>>> >>>>> >>>>> >>>>> 544410 >>>>> >>>>> >>>>> >>>>> 499786 >>>>> >>>>> >>>>> >>>>> 1292305 >>>>> >>>>> >>>>> >>>>> 968783 >>>>> >>>>> >>>>> >>>>> 690106 >>>>> >>>>> >>>>> >>>>> 683881 >>>>> >>>>> 4BYTE_ABGR_PRE >>>>> >>>>> >>>>> >>>>> 504249 >>>>> >>>>> >>>>> >>>>> 505588 >>>>> >>>>> >>>>> >>>>> 1680086 >>>>> >>>>> >>>>> >>>>> 1216445 >>>>> >>>>> >>>>> >>>>> 756101 >>>>> >>>>> >>>>> >>>>> 687750 >>>>> >>>>> USHORT_565_RGB >>>>> >>>>> >>>>> >>>>> 507818 >>>>> >>>>> >>>>> >>>>> 505588 >>>>> >>>>> >>>>> >>>>> 978153 >>>>> >>>>> >>>>> >>>>> 1346746 >>>>> >>>>> >>>>> >>>>> 652908 >>>>> >>>>> >>>>> >>>>> 655782 >>>>> >>>>> USHORT_555_RGB >>>>> >>>>> >>>>> >>>>> 510496 >>>>> >>>>> >>>>> >>>>> 509604 >>>>> >>>>> >>>>> >>>>> 952272 >>>>> >>>>> >>>>> >>>>> 1162004 >>>>> >>>>> >>>>> >>>>> 650418 >>>>> >>>>> >>>>> >>>>> 670811 >>>>> >>>>> BYTE_GRAY >>>>> >>>>> >>>>> >>>>> 481491 >>>>> >>>>> >>>>> >>>>> 478367 >>>>> >>>>> >>>>> >>>>> 1140585 >>>>> >>>>> >>>>> >>>>> 1799231 >>>>> >>>>> >>>>> >>>>> 691160 >>>>> >>>>> >>>>> >>>>> 583250 >>>>> >>>>> USHORT_GRAY >>>>> >>>>> >>>>> >>>>> 506927 >>>>> >>>>> >>>>> >>>>> 507373 >>>>> >>>>> >>>>> >>>>> 1375751 >>>>> >>>>> >>>>> >>>>> 1255267 >>>>> >>>>> >>>>> >>>>> 728202 >>>>> >>>>> >>>>> >>>>> 646902 >>>>> >>>>> BYTE_BINARY >>>>> >>>>> >>>>> >>>>> 541733 >>>>> >>>>> >>>>> >>>>> 496217 >>>>> >>>>> >>>>> >>>>> 1083466 >>>>> >>>>> >>>>> >>>>> 959411 >>>>> >>>>> >>>>> >>>>> 730527 >>>>> >>>>> >>>>> >>>>> 728461 >>>>> >>>>> The changes are tested with plain images having primary colors like >>>>> RED, GREEN, BLUE, BLACK and WHITE. >>>>> >>>>> Thanks, >>>>> >>>>> Jay >>>>> >>>>> -----Original Message----- >>>>> From: Jim Graham >>>>> Sent: Friday, February 12, 2016 4:05 AM >>>>> To: Jayathirth D V; 2d-dev at openjdk.java.net; Philip Race; Prasanta >>>>> Sadhukhan >>>>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : >>>>> Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED >>>>> >>>>> Hi Jayathirth, >>>>> >>>>> Did you do any performance analysis of this change? You are adding >>>>> 6 tests and multiple branches to per-pixel code. >>>>> >>>>> The effectiveness of this technique depends on the colormap that we >>>>> have set up. For the BufferedImage.TYPE_INDEXED constructor we >>>>> produce a fairly nice colormap, but if someone creates a custom >>>>> colormap then the colors could be anything. We create a decent >>>>> inversion for just about any colormap, but that doesn't mean that >>>>> using only "the best match for solid red" will produce a better >>>>> result for a dithered approximation for red. It is true that if >>>>> there is a really good match for red then we should just use that, >>>>> but if there are no direct matches for red then we may choose to >>>>> paint a red region with solid orange even though there is another >>>>> color in the colormap that when mixed with orange approximates a >>>>> red tone better. For example, if a colormap contains no pure red, >>>>> but >>>>> >>>>> contains: >>>>> >>>>> 240, 20, 0 >>>>> >>>>> 240, 0, 20 >>>>> >>>>> (I'm not sure if 20 is within our current error deltas that we use >>>>> for dithering, but this is an example not a test case.) >>>>> >>>>> Then using one of these alone might skew the color towards orange >>>>> or purple. Using both together in a dither pattern might keep the >>>>> overall hue impression as red, but with a small amount of noise in >>>>> its saturation. >>>>> >>>>> What types of colormaps was this tested with? >>>>> >>>>> ...jim >>>>> >>>>> On 2/11/16 6:37 AM, Jayathirth D V wrote: >>>>> >>>>>> Hi, >>>>> >>>>>> >>>>> >>>>>> _Please review the following fix in JDK9:_ >>>>> >>>>>> >>>>> >>>>>> __ >>>>> >>>>>> >>>>> >>>>>> Bug :https://bugs.openjdk.java.net/browse/JDK-7116979 >>>>> >>>>>> >>>>> >>>>>> Webrev :http://cr.openjdk.java.net/~jdv/7116979/webrev.00/ >>>>> >>>>>> >>>>> >>>>>> Issue : When Image containing black pixels are converted from any >>>>> >>>>>> format to Byte Indexed format some of the pixels are not black. >>>>>> They >>>>> >>>>>> are following pattern similar to dithering. >>>>> >>>>>> >>>>> >>>>>> Root cause : When we convert any format type to ByteIndexed we are >>>>> >>>>>> adding Error delta values to R,G,B components using dithering >>>>>> indices. >>>>> >>>>>> This is causing some pixels values to not point to proper index in >>>>> >>>>>> color table. >>>>> >>>>>> >>>>> >>>>>> Solution : There is no need to add error delta for primary colors >>>>> >>>>>> containing basic values in R,G,B components. Exclude such pixels >>>>>> from >>>>> >>>>>> delta addition. >>>>> >>>>>> >>>>> >>>>>> Thanks, >>>>> >>>>>> >>>>> >>>>>> Jay >>>>> >>>>>> >>>>> > From jayathirth.d.v at oracle.com Sat Apr 30 07:59:02 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Sat, 30 Apr 2016 00:59:02 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED In-Reply-To: References: <2c9221dc-ed76-481a-8bee-a694d313448e@default> <56BD0CAB.6080704@oracle.com> <90de7741-c175-4803-9c3e-30b1039b2774@default> <56C227D1.1030600@oracle.com> <46329edf-4cbe-48d4-a519-c908b09844a6@default> <56C789E4.6000409@oracle.com> <7f5f1cd3-4022-4739-b412-9d3f3c74181f@default> <4a833ce4-04b4-0250-e78f-ef60fbd52806@oracle.com> <571FB2D1.30205@oracle.com> <3ab637db-7b8b-440a-8d65-222f3b5ca55e@default> Message-ID: <2762734e-c6fd-4c36-b4ab-3c3b3e05c67a@default> Hi Jim, As I have mentioned in my previously, It looks like we take index from (31,31) in cube for white color which is gray value increment from color-map in 255 index. "I have observed that in case of white color we are picking (252,252,252) and not (255,255,255) from color-map. What I have observed that out of 256 places we are storing RGB colors at start and then gray values. So we are picking final gray value and not in between white value. That's why I am not verifying white color validity in test case." There is no variable to find out exactly until where we are storing RGB colors in color-map as it can vary if user provides custom color-map. This looks like completely different issue of not extracting proper value for white color. Thanks, Jay -----Original Message----- From: Jim Graham Sent: Saturday, April 30, 2016 4:43 AM To: Jayathirth D V; Philip Race Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED The code changes look good. One question on the test case, though - why is Color.WHITE commented out in the test case? Was it failing? ...jim On 4/29/16 4:45 AM, Jayathirth D V wrote: > Hi, > > Thanks Phil & Jim for your inputs. > I have made all recommended changes. > Please find updated webrev for review : > http://cr.openjdk.java.net/~jdv/7116979/webrev.02/ > > Thanks, > Jay > > -----Original Message----- > From: Phil Race > Sent: Tuesday, April 26, 2016 11:56 PM > To: Jim Graham > Cc: Jayathirth D V; 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : > Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED > > On 04/22/2016 06:56 PM, Jim Graham wrote: >> Hi Jay, >> >> It looks like it will work, but there are some inconsistencies in the >> code that we should address and a couple of optimizations. >> >> First, there is a mixture of using "int" and "jboolean" for the type >> of the new boolean parameter. It would be great if we could just >> declare it as jboolean in the structures, but it looks like those are >> limited to basic C types. It seems a little clunky to mix types like >> this, but I'd be interested in hearing what Phil says. I think it >> would be fine to just use int throughout. > > From the ones I've seen may be much better to just use int > throughout. Eg > > 264 static jboolean calculatePrimaryColorsAprroximation(int* cmap, > unsigned char* cube, int cube_size) { > > aside from having a typo in the name also makes a fair amount of internal uses of jboolean and JNI_TRUE/JNI_FALSE. > > It then does this > > 385 cData->representsPrimary = calculatePrimaryColorsAprroximation(pRgb, cData->img_clr_tbl, 32); > > ie stores it in an int .. I see no reason for this as there is no JNI code involved. > > > Moreover this usage of the variables declared as boolean then has code > like > > 174 (representsPrimary == 1))) { \ > > > -phil. > >> >> I'd suggest a name change: >> representsPrimary => representsPrimaries (since there are >> multiple primary colors) >> >> The place to load the variable for testing in the ByteIndexed macros >> would be in the "InitByteIndexedStoreVarsY" macro where it sets up >> the "PREFIX ## InvLut" variable. It should also use a PREFIX. Look >> through those macros for wherever the InvLut value is declared and >> initialized, and follow a similar pattern for "PREFIX ## ". >> You could use "representsPrimaries" for the name here too, but it >> could also be shortened to just "repPrims" or "optPrims" since the >> macros are all centralized here. >> >> Once you do the preceding step, you can delete a lot of lines that >> pre-load the "representsPrimaries" in the calling macros, which >> should also eliminate a lot of files from the webrev. >> >> In the code in ByteIndexed.h:StoreByteIndexedFrom3ByteRgb() that >> tests the variable, I'd just test "representsPrimary" with no "==" >> rather than comparing it to 1 since it is a boolean, not (really) an integer. >> >> With respect to the new function that tests the primary matches (in >> ByteIndexed.c), some of the code is unnecessarily complicated: >> >> - When you find a color match failure (lines 301, et al), you could >> just return false directly. As it stands, you set a variable and >> break, but the break only breaks out of 1 of 3 nested if statements, >> so it doesn't save any calculations. Just return false directly as a >> single failure means the answer is "no". >> >> - your r, g, and b values are extracted from the color in the wrong >> order near line 285. r involves a shift of 16, and b involves no >> shift. I suppose this is paired with computing the dr and db values >> with the wrong indices or this technique wouldn't work, but it is >> clunky to name the variables inconsistently with the data they >> actually hold. >> >> - you use parentheses on the left-hand side of an assignment when you >> extract the r, g, and b values (also near line 285). You don't need >> parentheses on that side of an assignment operator. >> >> There are several things that are more complicated than they need to >> be with your testing lines. They use a lot more computations than >> you need. For instance: >> >> - You test the i,j,k using a modulus operation (lines 298, 312, 326), >> but really you just need to know if it is 0 or not-0, so just test it >> for ==0 or !=0. >> - rather than using multiplication and modulus to assign the dr,dg,db >> values near line 291, why not just use "dr = (i == 0) ? 0 : 255;"? >> - the tests for range use a separate subtraction and a compare, when >> they could be inlined. >> >> First, I'd get rid of the "represents_primary" variable entirely and >> then rewrite the whole tail end of the loop body from 291 to the end >> of the loop as: >> >> if (i == 0) { >> if (r > delta) return false; >> } else { >> if (r < 255-delta) return false; >> } >> // 2 more similar tests for j/g and k/b >> >> Then "return true" at the end of the function if it reaches there. >> Keep in mind that the mapping of ijk to rgb might be affected if you >> fix the shifts used to extract the rgb components from color... >> >> ...jim >> >> On 4/20/2016 2:46 AM, Jayathirth D V wrote: >>> Hi Jim, >>> >>> As discussed we will not add dithering error values to primary >>> colors with color map which represents Primary colors >>> approximately(+/-5 delta). >>> I have made changes based on this suggestion and added new function >>> to calculate whether color map represents primary colors >>> approximately or not. >>> If it represents only then we will avoid adding dithering error >>> values in case ByteIndexed destination. >>> >>> I have observed that in case of white color we are picking >>> (252,252,252) or (246,246,246) and not (255,255,255) from colormap. >>> What I have observed that out of 256 places we are storing RGB >>> colors at start and then gray values. So we are picking final gray >>> value and not in between white value. That's why I am not verifying >>> white color validity in test case. >>> >>> Please find updated webrev for review : >>> http://cr.openjdk.java.net/~jdv/7116979/webrev.01/ >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Jim Graham >>> Sent: Saturday, February 20, 2016 3:02 AM >>> To: Jayathirth D V >>> Cc: 2d-dev at openjdk.java.net; Philip Race; Prasanta Sadhukhan >>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : >>> Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED >>> >>> Hi Jayathirth, >>> >>> Thank you for attaching the detailed logs, but I don't have a >>> program that can deal with the 7z files. Can you summarize what was >>> learned from them? >>> >>> Also, the colormap you created, while subset, was a perfectly scaled >>> cube. I was referring more to a random colormap where you might >>> have >>> 2 colors close to a primary, but neither is on a line from the >>> primary to the 0.5 gray value so each has a different hue. That's >>> something that can only be evaluated visually. One example of >>> randomized colormaps is when we display via X11 onto an 8-bit >>> display. That probably never happens any more, but we may not be >>> able to allocate colors in the colormap in such a case and if >>> another program has already allocated most of the dynamic colormap >>> then we would not be able to add our own colors. >>> >>> This could be dealt with by simply marking our standard colormap as >>> having primaries, or by scanning any given colormap and marking it >>> if it has primaries, and then only perform this code on colormaps >>> with the primaries. Solving it for our own colormap (or solving it >>> for any colormap that has all primaries) would likely solve it for >>> 99% of the vanishingly small number of developers who might run into this. >>> >>> But, in the end, what would we accomplish by adding this one very >>> targeted fix? >>> >>> I'm also curious where the push for this is coming from. While we >>> aren't perfect here, so much of the world today is focused on >>> lossless image formats that I don't imagine there is much need for >>> really good 8-bit indexed image support any more...? >>> >>> If anything, spatial dithering is considered a very low quality >>> algorithm and error propagation dithering would handle all of the >>> colormaps much better. We used to do error propagation dithering >>> back in the JDK 1.1 days, but we dropped it when we introduced 2D >>> because we added a bunch of ways to render small pieces of an image >>> and only the current spatial dithering algorithm can be started in >>> the middle of an operation. That doesn't mean that you can't still >>> do error propagation since many operations already operate on the >>> full image any way and you can still handle subset image operations >>> by either converting the full image first and then copying or by >>> tracing the errors from the edge of the image to the point of the >>> subimage operation. We never bothered to upgrade our algorithms it >>> just never seemed to be work that made sense to prioritize given >>> that screens were overwhelmingly moving to full-color at the time of >>> "Java 2" (and now to HDR in 2016+). 8-bit indexed isn't used much any more. >>> >>> If we want to make 8-bit destination images work better we'd be >>> better off adopting error propagation dithering again rather than >>> trying to tune this algorithm for black. >>> >>> It looks like the bug was closed briefly in 2014 and then reopened >>> soon thereafter with no justification. It is true that we still >>> have this anomaly, but it isn't clear why this is high enough >>> priority to work on in 2016 when other bit depths would work better >>> for destination imagery and other dithering algorithms would work >>> better for most customers and even this targeted fix isn't perfect... >>> >>> ...jim >>> >>> On 2/16/2016 8:32 AM, Jayathirth D V wrote: >>>> Hi Jim, >>>> >>>> Thanks for letting me know about the importance of custom color >>>> maps. I was not able to understand what you mentioned previously >>>> since I am new to this terminology. >>>> >>>> Regarding performance I checked with image having complete >>>> 255,255,128 pixels and ran it for 100 times. I am running on >>>> Windows >>>> 7 Professional SP1 with Intel i5-5300U CPU. Overall I don't see >>>> much difference in time taken for drawImage() API before and after >>>> change. Details for INT_RGB image as input: >>>> >>>> Before change : >>>> Minimum time 536827ns >>>> Maximum time 1560947ns >>>> Average time 871167ns >>>> >>>> After change : >>>> Minimum time 536380ns >>>> Maximum time 1468130ns >>>> Average time 830778ns >>>> >>>> There is +/- 10% delta both for before and after change time but >>>> there is no major gap. Even for image with other input type it >>>> holds the same. >>>> >>>> >>>> Regarding custom color maps, previously I ran on default color map >>>> generated in TYPE_BYTE_INDEXED constructor. Now I tested with >>>> modified color map so that it doesn't contain any of the primary >>>> color values. Instead of using 0-255 values with value 51 >>>> increments in R,G,B components I used color map with 20-245 values >>>> with value >>>> 45 as increment. For this color map before and after change all the >>>> pixels are referring to same index in color map irrespective of >>>> removal of error delta addition in case of primary colors. >>>> >>>> I have attached log for Red and Green primary colors before and >>>> after change(Was not able to attach for more since it exceeded >>>> 120KB mailing list limit). Please search for "Final index value =" >>>> in the logs. Please let me know your inputs. >>>> >>>> Thanks, >>>> Jay >>>> >>>> -----Original Message----- >>>> From: Jim Graham >>>> Sent: Tuesday, February 16, 2016 1:03 AM >>>> To: Jayathirth D V >>>> Cc: 2d-dev at openjdk.java.net; Philip Race; Prasanta Sadhukhan >>>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : >>>> Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED >>>> >>>> Hi Jayathirth, >>>> >>>> The issue with testing performance with white images is that the >>>> tests allow the code to eliminate 3 indexed fetches which take time. >>>> Primary colors end up being the one obscure case where the new code >>>> might be faster. But, non-primary colors would be slower by a fair >>>> amount, so performance testing with converting a randomized or >>>> non-primary-color image are the more telling case. An image filled >>>> with 255,255,128 would be the worst case because it would involve >>>> all of the tests and still have to do all of the lookups. >>>> >>>> My question about how this works with custom colormaps was not >>>> really addressed by your response. A simple test to make sure the >>>> colormap has accurate (or very close) conversions for the primary >>>> colors may be enough to validate the colormap for the indicated >>>> tests. If the colormap contains no pure conversions for some of >>>> the primary colors then they may need to be dithered anyway... >>>> >>>> ...jim >>>> >>>> On 2/15/16 3:39 AM, Jayathirth D V wrote: >>>>> Hi Jim, >>>>> >>>>> I performed performance analysis with white image so that all >>>>> conditions are checked in the new branch added. There is no major >>>>> difference in time taken before and after change. For each input I >>>>> have tested time taken for drawImage() API to convert from every >>>>> format to Byte indexed type. For every unique conversion test is >>>>> run for 100 times. Please find the details: >>>>> >>>>> Input >>>>> >>>>> type >>>>> >>>>> >>>>> >>>>> Min >>>>> >>>>> before change >>>>> >>>>> (ns) >>>>> >>>>> >>>>> >>>>> Min >>>>> >>>>> after change >>>>> >>>>> (ns) >>>>> >>>>> >>>>> >>>>> Max >>>>> >>>>> before change >>>>> >>>>> (ns) >>>>> >>>>> >>>>> >>>>> Max >>>>> >>>>> after change >>>>> >>>>> (ns) >>>>> >>>>> >>>>> >>>>> Average >>>>> >>>>> before change >>>>> >>>>> (ns) >>>>> >>>>> >>>>> >>>>> Average >>>>> >>>>> after >>>>> >>>>> change >>>>> >>>>> (ns) >>>>> >>>>> INT_RGB >>>>> >>>>> >>>>> >>>>> 523437 >>>>> >>>>> >>>>> >>>>> 481491 >>>>> >>>>> >>>>> >>>>> 1230724 >>>>> >>>>> >>>>> >>>>> 1270440 >>>>> >>>>> >>>>> >>>>> 789452 >>>>> >>>>> >>>>> >>>>> 666144 >>>>> >>>>> INT_ARGB >>>>> >>>>> >>>>> >>>>> 500232 >>>>> >>>>> >>>>> >>>>> 493986 >>>>> >>>>> >>>>> >>>>> 12406307 >>>>> >>>>> >>>>> >>>>> 1308816 >>>>> >>>>> >>>>> >>>>> 793384 >>>>> >>>>> >>>>> >>>>> 654015 >>>>> >>>>> INT_ARGB_PRE >>>>> >>>>> >>>>> >>>>> 500233 >>>>> >>>>> >>>>> >>>>> 492201 >>>>> >>>>> >>>>> >>>>> 1037057 >>>>> >>>>> >>>>> >>>>> 981277 >>>>> >>>>> >>>>> >>>>> 710250 >>>>> >>>>> >>>>> >>>>> 699214 >>>>> >>>>> INT_BGR >>>>> >>>>> >>>>> >>>>> 537716 >>>>> >>>>> >>>>> >>>>> 562706 >>>>> >>>>> >>>>> >>>>> 1446703 >>>>> >>>>> >>>>> >>>>> 2046001 >>>>> >>>>> >>>>> >>>>> 862377 >>>>> >>>>> >>>>> >>>>> 863256 >>>>> >>>>> 3BYTE_BGR >>>>> >>>>> >>>>> >>>>> 483275 >>>>> >>>>> >>>>> >>>>> 481045 >>>>> >>>>> >>>>> >>>>> 1181638 >>>>> >>>>> >>>>> >>>>> 1384676 >>>>> >>>>> >>>>> >>>>> 651427 >>>>> >>>>> >>>>> >>>>> 580961 >>>>> >>>>> 4BYTE_ABGR >>>>> >>>>> >>>>> >>>>> 544410 >>>>> >>>>> >>>>> >>>>> 499786 >>>>> >>>>> >>>>> >>>>> 1292305 >>>>> >>>>> >>>>> >>>>> 968783 >>>>> >>>>> >>>>> >>>>> 690106 >>>>> >>>>> >>>>> >>>>> 683881 >>>>> >>>>> 4BYTE_ABGR_PRE >>>>> >>>>> >>>>> >>>>> 504249 >>>>> >>>>> >>>>> >>>>> 505588 >>>>> >>>>> >>>>> >>>>> 1680086 >>>>> >>>>> >>>>> >>>>> 1216445 >>>>> >>>>> >>>>> >>>>> 756101 >>>>> >>>>> >>>>> >>>>> 687750 >>>>> >>>>> USHORT_565_RGB >>>>> >>>>> >>>>> >>>>> 507818 >>>>> >>>>> >>>>> >>>>> 505588 >>>>> >>>>> >>>>> >>>>> 978153 >>>>> >>>>> >>>>> >>>>> 1346746 >>>>> >>>>> >>>>> >>>>> 652908 >>>>> >>>>> >>>>> >>>>> 655782 >>>>> >>>>> USHORT_555_RGB >>>>> >>>>> >>>>> >>>>> 510496 >>>>> >>>>> >>>>> >>>>> 509604 >>>>> >>>>> >>>>> >>>>> 952272 >>>>> >>>>> >>>>> >>>>> 1162004 >>>>> >>>>> >>>>> >>>>> 650418 >>>>> >>>>> >>>>> >>>>> 670811 >>>>> >>>>> BYTE_GRAY >>>>> >>>>> >>>>> >>>>> 481491 >>>>> >>>>> >>>>> >>>>> 478367 >>>>> >>>>> >>>>> >>>>> 1140585 >>>>> >>>>> >>>>> >>>>> 1799231 >>>>> >>>>> >>>>> >>>>> 691160 >>>>> >>>>> >>>>> >>>>> 583250 >>>>> >>>>> USHORT_GRAY >>>>> >>>>> >>>>> >>>>> 506927 >>>>> >>>>> >>>>> >>>>> 507373 >>>>> >>>>> >>>>> >>>>> 1375751 >>>>> >>>>> >>>>> >>>>> 1255267 >>>>> >>>>> >>>>> >>>>> 728202 >>>>> >>>>> >>>>> >>>>> 646902 >>>>> >>>>> BYTE_BINARY >>>>> >>>>> >>>>> >>>>> 541733 >>>>> >>>>> >>>>> >>>>> 496217 >>>>> >>>>> >>>>> >>>>> 1083466 >>>>> >>>>> >>>>> >>>>> 959411 >>>>> >>>>> >>>>> >>>>> 730527 >>>>> >>>>> >>>>> >>>>> 728461 >>>>> >>>>> The changes are tested with plain images having primary colors >>>>> like RED, GREEN, BLUE, BLACK and WHITE. >>>>> >>>>> Thanks, >>>>> >>>>> Jay >>>>> >>>>> -----Original Message----- >>>>> From: Jim Graham >>>>> Sent: Friday, February 12, 2016 4:05 AM >>>>> To: Jayathirth D V; 2d-dev at openjdk.java.net; Philip Race; Prasanta >>>>> Sadhukhan >>>>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : >>>>> Unexpected pixel colour when converting images to >>>>> TYPE_BYTE_INDEXED >>>>> >>>>> Hi Jayathirth, >>>>> >>>>> Did you do any performance analysis of this change? You are >>>>> adding >>>>> 6 tests and multiple branches to per-pixel code. >>>>> >>>>> The effectiveness of this technique depends on the colormap that >>>>> we have set up. For the BufferedImage.TYPE_INDEXED constructor we >>>>> produce a fairly nice colormap, but if someone creates a custom >>>>> colormap then the colors could be anything. We create a decent >>>>> inversion for just about any colormap, but that doesn't mean that >>>>> using only "the best match for solid red" will produce a better >>>>> result for a dithered approximation for red. It is true that if >>>>> there is a really good match for red then we should just use that, >>>>> but if there are no direct matches for red then we may choose to >>>>> paint a red region with solid orange even though there is another >>>>> color in the colormap that when mixed with orange approximates a >>>>> red tone better. For example, if a colormap contains no pure red, >>>>> but >>>>> >>>>> contains: >>>>> >>>>> 240, 20, 0 >>>>> >>>>> 240, 0, 20 >>>>> >>>>> (I'm not sure if 20 is within our current error deltas that we use >>>>> for dithering, but this is an example not a test case.) >>>>> >>>>> Then using one of these alone might skew the color towards orange >>>>> or purple. Using both together in a dither pattern might keep the >>>>> overall hue impression as red, but with a small amount of noise in >>>>> its saturation. >>>>> >>>>> What types of colormaps was this tested with? >>>>> >>>>> ...jim >>>>> >>>>> On 2/11/16 6:37 AM, Jayathirth D V wrote: >>>>> >>>>>> Hi, >>>>> >>>>>> >>>>> >>>>>> _Please review the following fix in JDK9:_ >>>>> >>>>>> >>>>> >>>>>> __ >>>>> >>>>>> >>>>> >>>>>> Bug :https://bugs.openjdk.java.net/browse/JDK-7116979 >>>>> >>>>>> >>>>> >>>>>> Webrev :http://cr.openjdk.java.net/~jdv/7116979/webrev.00/ >>>>> >>>>>> >>>>> >>>>>> Issue : When Image containing black pixels are converted from any >>>>> >>>>>> format to Byte Indexed format some of the pixels are not black. >>>>>> They >>>>> >>>>>> are following pattern similar to dithering. >>>>> >>>>>> >>>>> >>>>>> Root cause : When we convert any format type to ByteIndexed we >>>>>> are >>>>> >>>>>> adding Error delta values to R,G,B components using dithering >>>>>> indices. >>>>> >>>>>> This is causing some pixels values to not point to proper index >>>>>> in >>>>> >>>>>> color table. >>>>> >>>>>> >>>>> >>>>>> Solution : There is no need to add error delta for primary colors >>>>> >>>>>> containing basic values in R,G,B components. Exclude such pixels >>>>>> from >>>>> >>>>>> delta addition. >>>>> >>>>>> >>>>> >>>>>> Thanks, >>>>> >>>>>> >>>>> >>>>>> Jay >>>>> >>>>>> >>>>> >