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: