From adinn at redhat.com Fri May 1 07:41:37 2015
From: adinn at redhat.com (Andrew Dinn)
Date: Fri, 01 May 2015 08:41:37 +0100
Subject: [OpenJDK 2D-Dev] RFR 8078654: CloseTTFontFileFunc callback
should be removed
In-Reply-To: <554296C9.50102@oracle.com>
References: <553E0A4B.4000901@redhat.com> <554159FA.30704@oracle.com>
<5541E8DD.2020008@redhat.com> <554296C9.50102@oracle.com>
Message-ID: <55432E31.1020906@redhat.com>
On 30/04/15 21:55, Phil Race wrote:
> I don't read it the way you do.
No, indeed I think the difference is that you read it correctly (modulo
the uncertainty that remains as to /why/ the Get and Release calls are
there). Thank you for clarifying.
regards,
Andrew Dinn
-----------
From prasanta.sadhukhan at oracle.com Mon May 4 08:17:38 2015
From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan)
Date: Mon, 04 May 2015 13:47:38 +0530
Subject: [OpenJDK 2D-Dev] RFR: (JDK-8015368) [TESTBUG]
javax/print/attribute/URLPDFPrinting.java fails on solaris with
java.net.ConnectException: Connection timed out
Message-ID: <55472B22.1020600@oracle.com>
Hi,
The test in question was trying to connect to an address that when run
inside Oracle needs an HTTP proxy and the test system is not configured
with proxies so it's getting timed out.
The fix is to generate a simple pdf and use it from local folder.
Also, moved the test out of closed repo to general open domain.
Bug: https://bugs.openjdk.java.net/browse/JDK-8015368
webrev: http://cr.openjdk.java.net/~psadhukhan/8015368/webrev.00/
Regards
Prasanta
From philip.race at oracle.com Mon May 4 16:23:09 2015
From: philip.race at oracle.com (Phil Race)
Date: Mon, 04 May 2015 09:23:09 -0700
Subject: [OpenJDK 2D-Dev] RFR: (JDK-8015368) [TESTBUG]
javax/print/attribute/URLPDFPrinting.java fails on solaris with
java.net.ConnectException: Connection timed out
In-Reply-To: <55472B22.1020600@oracle.com>
References: <55472B22.1020600@oracle.com>
Message-ID: <55479CED.9030004@oracle.com>
The test is missing the GPL. Make sure you copy one from a test so as
NOT to include the class path exception
-phil.
On 05/04/2015 01:17 AM, prasanta sadhukhan wrote:
> Hi,
>
> The test in question was trying to connect to an address that when run
> inside Oracle needs an HTTP proxy and the test system is not
> configured with proxies so it's getting timed out.
> The fix is to generate a simple pdf and use it from local folder.
> Also, moved the test out of closed repo to general open domain.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8015368
> webrev: http://cr.openjdk.java.net/~psadhukhan/8015368/webrev.00/
>
> Regards
> Prasanta
From philip.race at oracle.com Mon May 4 16:24:28 2015
From: philip.race at oracle.com (Phil Race)
Date: Mon, 04 May 2015 09:24:28 -0700
Subject: [OpenJDK 2D-Dev] Review Request: (JDK-8077584) Value of
java.awt.font.OpenType.TAG_OPBD is incorrect
In-Reply-To: <55421957.8000906@oracle.com>
References: <552E4D86.2010101@oracle.com> <5541C59D.2000909@oracle.com>
<554212BC.4020408@oracle.com> <55421957.8000906@oracle.com>
Message-ID: <55479D3C.1050508@oracle.com>
Please remove the "@author" tag. We do not use them in OpenJDK
-phil.
On 04/30/2015 05:00 AM, prasanta sadhukhan wrote:
> Hi Sergey,
>
> Done.
> http://cr.openjdk.java.net/~psadhukhan/8077584/webrev.01/
>
> Regards
> Prasanta
> On 4/30/2015 5:02 PM, Sergey Bylokhov wrote:
>> Hi, Prasanta.
>> Can you split the long lines in the test?
>>
>> On 30.04.15 9:03, prasanta sadhukhan wrote:
>>> Hi All,
>>>
>>> Any feedback? Can this be committed?
>>>
>>> Regards
>>> Prasanta
>>> On 4/15/2015 5:07 PM, prasanta sadhukhan wrote:
>>>> Hi,
>>>>
>>>> I would like a review for a jdk9 fix whereby TAG_OPBD tag is
>>>> updated to correct value.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8077584
>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8077584/webrev.00/
>>>>
>>>> Regards
>>>> Prasanta
>>>
>>
>>
>
From prasanta.sadhukhan at oracle.com Tue May 5 05:48:09 2015
From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan)
Date: Tue, 05 May 2015 11:18:09 +0530
Subject: [OpenJDK 2D-Dev] RFR: (JDK-8015368) [TESTBUG]
javax/print/attribute/URLPDFPrinting.java fails on solaris with
java.net.ConnectException: Connection timed out
In-Reply-To: <55479CED.9030004@oracle.com>
References: <55472B22.1020600@oracle.com> <55479CED.9030004@oracle.com>
Message-ID: <55485999.1010101@oracle.com>
Thanks Phil for pointing that. I have added the GPL.
Please find the modified webrev
http://cr.openjdk.java.net/~psadhukhan/8015368/webrev.00/
Regards
Prasanta
On 5/4/2015 9:53 PM, Phil Race wrote:
> The test is missing the GPL. Make sure you copy one from a test so as
> NOT to include the class path exception
>
> -phil.
>
> On 05/04/2015 01:17 AM, prasanta sadhukhan wrote:
>> Hi,
>>
>> The test in question was trying to connect to an address that when
>> run inside Oracle needs an HTTP proxy and the test system is not
>> configured with proxies so it's getting timed out.
>> The fix is to generate a simple pdf and use it from local folder.
>> Also, moved the test out of closed repo to general open domain.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8015368
>> webrev: http://cr.openjdk.java.net/~psadhukhan/8015368/webrev.00/
>>
>> Regards
>> Prasanta
>
From prasanta.sadhukhan at oracle.com Tue May 5 06:01:02 2015
From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan)
Date: Tue, 05 May 2015 11:31:02 +0530
Subject: [OpenJDK 2D-Dev] Review Request: (JDK-8077584) Value of
java.awt.font.OpenType.TAG_OPBD is incorrect
In-Reply-To: <55479D3C.1050508@oracle.com>
References: <552E4D86.2010101@oracle.com> <5541C59D.2000909@oracle.com>
<554212BC.4020408@oracle.com> <55421957.8000906@oracle.com>
<55479D3C.1050508@oracle.com>
Message-ID: <55485C9E.4000603@oracle.com>
Thanks for the info. It's Done.
http://cr.openjdk.java.net/~psadhukhan/8077584/webrev.02/
Regards
Prasanta
On 5/4/2015 9:54 PM, Phil Race wrote:
> Please remove the "@author" tag. We do not use them in OpenJDK
>
> -phil.
>
> On 04/30/2015 05:00 AM, prasanta sadhukhan wrote:
>> Hi Sergey,
>>
>> Done.
>> http://cr.openjdk.java.net/~psadhukhan/8077584/webrev.01/
>>
>> Regards
>> Prasanta
>> On 4/30/2015 5:02 PM, Sergey Bylokhov wrote:
>>> Hi, Prasanta.
>>> Can you split the long lines in the test?
>>>
>>> On 30.04.15 9:03, prasanta sadhukhan wrote:
>>>> Hi All,
>>>>
>>>> Any feedback? Can this be committed?
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 4/15/2015 5:07 PM, prasanta sadhukhan wrote:
>>>>> Hi,
>>>>>
>>>>> I would like a review for a jdk9 fix whereby TAG_OPBD tag is
>>>>> updated to correct value.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8077584
>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8077584/webrev.00/
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>
>>>
>>>
>>
>
From prasanta.sadhukhan at oracle.com Tue May 5 08:12:11 2015
From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan)
Date: Tue, 05 May 2015 13:42:11 +0530
Subject: [OpenJDK 2D-Dev] RFR: (JDK-7011935) Using AWT in fullscreen
exclusive mode results in a black screen
Message-ID: <55487B5B.5040305@oracle.com>
Hi,
Please review a fix for fullscreen mode not working in D3D pipeline. It
seems D3DPRESENT_PARAMETERS Windowed flag needs to be enabled for
fullscreen mode to be in effect.
https://bugs.openjdk.java.net/browse/JDK-7011935
http://cr.openjdk.java.net/~psadhukhan/7011935/webrev.00/
Regards
Prasanta
From Sergey.Bylokhov at oracle.com Wed May 6 19:46:14 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 06 May 2015 22:46:14 +0300
Subject: [OpenJDK 2D-Dev] RFR: (JDK-7011935) Using AWT in fullscreen
exclusive mode results in a black screen
In-Reply-To: <55487B5B.5040305@oracle.com>
References: <55487B5B.5040305@oracle.com>
Message-ID: <554A6F86.6090103@oracle.com>
Hi, Prasanta.
I am not an expert in this code, but a few notes.
- The main question is: is a problem in the "Windowed flag" or in the
method "D3DContext::ConfigureContext" which treats non-/windowed windows
in different way.
- Is the changes in the D3DGraphicsDevice.java were made
intentionally, if yes then removeFSWindowListener should be changed as well?
- is it possible to automate the test?
On 05.05.15 11:12, prasanta sadhukhan wrote:
> Hi,
>
> Please review a fix for fullscreen mode not working in D3D pipeline.
> It seems D3DPRESENT_PARAMETERS Windowed flag needs to be enabled for
> fullscreen mode to be in effect.
>
> https://bugs.openjdk.java.net/browse/JDK-7011935
> http://cr.openjdk.java.net/~psadhukhan/7011935/webrev.00/
>
> Regards
> Prasanta
--
Best regards, Sergey.
From vadim.pakhnushev at oracle.com Thu May 7 14:36:10 2015
From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev)
Date: Thu, 07 May 2015 17:36:10 +0300
Subject: [OpenJDK 2D-Dev] RFR: (JDK-7011935) Using AWT in fullscreen
exclusive mode results in a black screen
In-Reply-To: <55487B5B.5040305@oracle.com>
References: <55487B5B.5040305@oracle.com>
Message-ID: <554B785A.2000307@oracle.com>
Hi Prasanta,
I don't think that this is the right fix, it basically changes the D3D
fullscreen mode from exclusive to simulated (as per
GraphicsDevice.setFullScreenWindow terminology).
I think further investigation is needed as to why this happens.
BTW, while trying this, I've found that after the JDK9 compiler upgrade
D3D device can't be created.
I've traced it to the focus window client area size and filed
https://bugs.openjdk.java.net/browse/JDK-8079652
Thanks,
Vadim
On 05.05.2015 11:12, prasanta sadhukhan wrote:
> Hi,
>
> Please review a fix for fullscreen mode not working in D3D pipeline.
> It seems D3DPRESENT_PARAMETERS Windowed flag needs to be enabled for
> fullscreen mode to be in effect.
>
> https://bugs.openjdk.java.net/browse/JDK-7011935
> http://cr.openjdk.java.net/~psadhukhan/7011935/webrev.00/
>
> Regards
> Prasanta
From vadim.pakhnushev at oracle.com Fri May 8 11:07:20 2015
From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev)
Date: Fri, 08 May 2015 14:07:20 +0300
Subject: [OpenJDK 2D-Dev] RFR: JDK-8079652: Could not enable D3D pipeline
Message-ID: <554C98E8.8090006@oracle.com>
Hi,
Please review the fix for https://bugs.openjdk.java.net/browse/JDK-8079652
Focus window's client area should be bigger otherwise CreateDevice fails.
diff --git
a/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
b/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
---
a/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
+++
b/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
@@ -829,7 +829,7 @@
}
HWND hWnd = CreateWindow(L"D3DFocusWindow", L"D3DFocusWindow", 0,
- mi.rcMonitor.left, mi.rcMonitor.top, 1, 1,
+ mi.rcMonitor.left, mi.rcMonitor.top, 100, 100,
NULL, NULL, GetModuleHandle(NULL), NULL);
if (hWnd == 0) {
J2dRlsTraceLn(J2D_TRACE_ERROR,
From Sergey.Bylokhov at oracle.com Fri May 8 13:14:06 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 08 May 2015 16:14:06 +0300
Subject: [OpenJDK 2D-Dev] RFR: JDK-8079652: Could not enable D3D pipeline
In-Reply-To: <554C98E8.8090006@oracle.com>
References: <554C98E8.8090006@oracle.com>
Message-ID: <554CB69E.9070402@oracle.com>
Hi, Vadim.
Why we do not use the full screen size for this window?
On 08.05.15 14:07, Vadim Pakhnushev wrote:
> Hi,
> Please review the fix for
> https://bugs.openjdk.java.net/browse/JDK-8079652
> Focus window's client area should be bigger otherwise CreateDevice fails.
>
> diff --git
> a/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
> b/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>
> ---
> a/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
> +++
> b/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
> @@ -829,7 +829,7 @@
> }
>
> HWND hWnd = CreateWindow(L"D3DFocusWindow", L"D3DFocusWindow", 0,
> - mi.rcMonitor.left, mi.rcMonitor.top, 1, 1,
> + mi.rcMonitor.left, mi.rcMonitor.top, 100, 100,
> NULL, NULL, GetModuleHandle(NULL), NULL);
> if (hWnd == 0) {
> J2dRlsTraceLn(J2D_TRACE_ERROR,
>
--
Best regards, Sergey.
From vadim.pakhnushev at oracle.com Fri May 8 13:19:18 2015
From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev)
Date: Fri, 08 May 2015 16:19:18 +0300
Subject: [OpenJDK 2D-Dev] RFR: JDK-8079652: Could not enable D3D pipeline
In-Reply-To: <554CB69E.9070402@oracle.com>
References: <554C98E8.8090006@oracle.com> <554CB69E.9070402@oracle.com>
Message-ID: <554CB7D6.4090804@oracle.com>
It's invisible and used only for getting application focus notifications
internally by Direct3D.
On 08.05.2015 16:14, Sergey Bylokhov wrote:
> Hi, Vadim.
> Why we do not use the full screen size for this window?
>
> On 08.05.15 14:07, Vadim Pakhnushev wrote:
>> Hi,
>> Please review the fix for
>> https://bugs.openjdk.java.net/browse/JDK-8079652
>> Focus window's client area should be bigger otherwise CreateDevice
>> fails.
>>
>> diff --git
>> a/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>> b/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>>
>> ---
>> a/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>> +++
>> b/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>> @@ -829,7 +829,7 @@
>> }
>>
>> HWND hWnd = CreateWindow(L"D3DFocusWindow", L"D3DFocusWindow", 0,
>> - mi.rcMonitor.left, mi.rcMonitor.top, 1, 1,
>> + mi.rcMonitor.left, mi.rcMonitor.top, 100, 100,
>> NULL, NULL, GetModuleHandle(NULL), NULL);
>> if (hWnd == 0) {
>> J2dRlsTraceLn(J2D_TRACE_ERROR,
>>
>
>
From Sergey.Bylokhov at oracle.com Fri May 8 13:28:28 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 08 May 2015 16:28:28 +0300
Subject: [OpenJDK 2D-Dev] RFR: JDK-8079652: Could not enable D3D pipeline
In-Reply-To: <554CB7D6.4090804@oracle.com>
References: <554C98E8.8090006@oracle.com> <554CB69E.9070402@oracle.com>
<554CB7D6.4090804@oracle.com>
Message-ID: <554CB9FC.2020404@oracle.com>
Hi, Vadim.
Thanks for clarification, please add this information as a comment to
the code, before the push.
On 08.05.15 16:19, Vadim Pakhnushev wrote:
> It's invisible and used only for getting application focus
> notifications internally by Direct3D.
>
> On 08.05.2015 16:14, Sergey Bylokhov wrote:
>> Hi, Vadim.
>> Why we do not use the full screen size for this window?
>>
>> On 08.05.15 14:07, Vadim Pakhnushev wrote:
>>> Hi,
>>> Please review the fix for
>>> https://bugs.openjdk.java.net/browse/JDK-8079652
>>> Focus window's client area should be bigger otherwise CreateDevice
>>> fails.
>>>
>>> diff --git
>>> a/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>>> b/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>>>
>>> ---
>>> a/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>>> +++
>>> b/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>>> @@ -829,7 +829,7 @@
>>> }
>>>
>>> HWND hWnd = CreateWindow(L"D3DFocusWindow", L"D3DFocusWindow", 0,
>>> - mi.rcMonitor.left, mi.rcMonitor.top, 1, 1,
>>> + mi.rcMonitor.left, mi.rcMonitor.top, 100, 100,
>>> NULL, NULL, GetModuleHandle(NULL), NULL);
>>> if (hWnd == 0) {
>>> J2dRlsTraceLn(J2D_TRACE_ERROR,
>>>
>>
>>
>
--
Best regards, Sergey.
From philip.race at oracle.com Fri May 8 18:38:15 2015
From: philip.race at oracle.com (Phil Race)
Date: Fri, 08 May 2015 11:38:15 -0700
Subject: [OpenJDK 2D-Dev] RFR: JDK-8079652: Could not enable D3D pipeline
In-Reply-To: <554CB9FC.2020404@oracle.com>
References: <554C98E8.8090006@oracle.com>
<554CB69E.9070402@oracle.com> <554CB7D6.4090804@oracle.com>
<554CB9FC.2020404@oracle.com>
Message-ID: <554D0297.3060501@oracle.com>
I guess this is OK since 100x100 ought to be always big enough but not
too big ..
I suppose it may imply a different default window style is being added
by CreateWindow
than we got before.
-phil.
On 5/8/2015 6:28 AM, Sergey Bylokhov wrote:
> Hi, Vadim.
> Thanks for clarification, please add this information as a comment to
> the code, before the push.
>
> On 08.05.15 16:19, Vadim Pakhnushev wrote:
>> It's invisible and used only for getting application focus
>> notifications internally by Direct3D.
>>
>> On 08.05.2015 16:14, Sergey Bylokhov wrote:
>>> Hi, Vadim.
>>> Why we do not use the full screen size for this window?
>>>
>>> On 08.05.15 14:07, Vadim Pakhnushev wrote:
>>>> Hi,
>>>> Please review the fix for
>>>> https://bugs.openjdk.java.net/browse/JDK-8079652
>>>> Focus window's client area should be bigger otherwise CreateDevice
>>>> fails.
>>>>
>>>> diff --git
>>>> a/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>>>> b/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>>>>
>>>> ---
>>>> a/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>>>> +++
>>>> b/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>>>> @@ -829,7 +829,7 @@
>>>> }
>>>>
>>>> HWND hWnd = CreateWindow(L"D3DFocusWindow", L"D3DFocusWindow", 0,
>>>> - mi.rcMonitor.left, mi.rcMonitor.top, 1, 1,
>>>> + mi.rcMonitor.left, mi.rcMonitor.top, 100, 100,
>>>> NULL, NULL, GetModuleHandle(NULL), NULL);
>>>> if (hWnd == 0) {
>>>> J2dRlsTraceLn(J2D_TRACE_ERROR,
>>>>
>>>
>>>
>>
>
>
From Sergey.Bylokhov at oracle.com Fri May 8 19:25:19 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 08 May 2015 22:25:19 +0300
Subject: [OpenJDK 2D-Dev] [9] Review Request: 6587235 Incorrect javadoc: "no
parameter" in 2d source code
Message-ID: <554D0D9F.9010207@oracle.com>
Hello.
Please review the fix for a typos in jdk9. This CR was filed by me long
time ago and I doubt that someone will take a look at it.
I fixed all clients files in sun.** subpackages.
Bug: https://bugs.openjdk.java.net/browse/JDK-6587235
Webrev can be found at: http://cr.openjdk.java.net/~serb/6587235/webrev.00
--
Best regards, Sergey.
From philip.race at oracle.com Fri May 8 19:52:11 2015
From: philip.race at oracle.com (Phil Race)
Date: Fri, 08 May 2015 12:52:11 -0700
Subject: [OpenJDK 2D-Dev] [9] Review Request: 6587235 Incorrect javadoc:
"no parameter" in 2d source code
In-Reply-To: <554D0D9F.9010207@oracle.com>
References: <554D0D9F.9010207@oracle.com>
Message-ID: <554D13EB.1070504@oracle.com>
273 * RuntimePermission("accessClassInPackage."+pkg)
274 * permission.
275 *
276 * @param pkgname the package name.
perhaps line 273 should match ?
7 * @param srcArg The first source tile for the compositing operation.
88 * @param dstIn The second source tile for the compositing operation.
89 * @param dstOut The tile where the result of the operation is stored.
90 */
91 public void compose(Raster srcArg, Raster dstIn, WritableRaster dstOut) {
it might be better to rename the actual arguments to match the doc.
47 /**
48 * Construct a new dialog type selection enumeration value with the
49 * given integer value.
50 *
51 * @param frame Integer value.
52 */
53 public DialogOwner(Frame frame) {
Huh ? The entire doc seems to be nonsense .. changing the name of the param
just makes it worse. The text seems to have been copied from
javax.attribute.standard.DialogTypeSelection.java
-phil.
On 05/08/2015 12:25 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for a typos in jdk9. This CR was filed by me
> long time ago and I doubt that someone will take a look at it.
> I fixed all clients files in sun.** subpackages.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-6587235
> Webrev can be found at:
> http://cr.openjdk.java.net/~serb/6587235/webrev.00
>
From Sergey.Bylokhov at oracle.com Fri May 8 22:34:01 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sat, 09 May 2015 01:34:01 +0300
Subject: [OpenJDK 2D-Dev] [9] Review Request: 6587235 Incorrect javadoc:
"no parameter" in 2d source code
In-Reply-To: <554D13EB.1070504@oracle.com>
References: <554D0D9F.9010207@oracle.com> <554D13EB.1070504@oracle.com>
Message-ID: <554D39D9.4040301@oracle.com>
Hi, Phil.
Thanks for a review! The new version:
http://cr.openjdk.java.net/~serb/6587235/webrev.01
On 08.05.15 22:52, Phil Race wrote:
> 273 * RuntimePermission("accessClassInPackage."+pkg)
> 274 * permission.
> 275 *
> 276 * @param pkgname the package name.
>
>
> perhaps line 273 should match ?
>
> 7 * @param srcArg The first source tile for the compositing
> operation.
> 88 * @param dstIn The second source tile for the compositing
> operation.
> 89 * @param dstOut The tile where the result of the operation
> is stored.
> 90 */
> 91 public void compose(Raster srcArg, Raster dstIn,
> WritableRaster dstOut) {
>
> it might be better to rename the actual arguments to match the doc.
>
>
> 47 /**
> 48 * Construct a new dialog type selection enumeration value
> with the
> 49 * given integer value.
> 50 *
> 51 * @param frame Integer value.
> 52 */
> 53 public DialogOwner(Frame frame) {
>
> Huh ? The entire doc seems to be nonsense .. changing the name of the
> param
> just makes it worse. The text seems to have been copied from
> javax.attribute.standard.DialogTypeSelection.java
>
>
> -phil.
>
> On 05/08/2015 12:25 PM, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for a typos in jdk9. This CR was filed by me
>> long time ago and I doubt that someone will take a look at it.
>> I fixed all clients files in sun.** subpackages.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-6587235
>> Webrev can be found at:
>> http://cr.openjdk.java.net/~serb/6587235/webrev.00
>>
>
--
Best regards, Sergey.
From philip.race at oracle.com Sat May 9 01:24:29 2015
From: philip.race at oracle.com (Phil Race)
Date: Fri, 08 May 2015 18:24:29 -0700
Subject: [OpenJDK 2D-Dev] [9] Review Request: 6587235 Incorrect javadoc:
"no parameter" in 2d source code
In-Reply-To: <554D39D9.4040301@oracle.com>
References: <554D0D9F.9010207@oracle.com> <554D13EB.1070504@oracle.com>
<554D39D9.4040301@oracle.com>
Message-ID: <554D61CD.8000901@oracle.com>
I did not slog through all the webrev again but the changed parts look
good, so "+1".
-phil.
On 5/8/15 3:34 PM, Sergey Bylokhov wrote:
> Hi, Phil.
> Thanks for a review! The new version:
> http://cr.openjdk.java.net/~serb/6587235/webrev.01
>
> On 08.05.15 22:52, Phil Race wrote:
>> 273 * RuntimePermission("accessClassInPackage."+pkg)
>> 274 * permission.
>> 275 *
>> 276 * @param pkgname the package name.
>>
>>
>> perhaps line 273 should match ?
>>
>> 7 * @param srcArg The first source tile for the compositing
>> operation.
>> 88 * @param dstIn The second source tile for the compositing
>> operation.
>> 89 * @param dstOut The tile where the result of the operation
>> is stored.
>> 90 */
>> 91 public void compose(Raster srcArg, Raster dstIn,
>> WritableRaster dstOut) {
>>
>> it might be better to rename the actual arguments to match the doc.
>>
>>
>> 47 /**
>> 48 * Construct a new dialog type selection enumeration value
>> with the
>> 49 * given integer value.
>> 50 *
>> 51 * @param frame Integer value.
>> 52 */
>> 53 public DialogOwner(Frame frame) {
>>
>> Huh ? The entire doc seems to be nonsense .. changing the name of the
>> param
>> just makes it worse. The text seems to have been copied from
>> javax.attribute.standard.DialogTypeSelection.java
>>
>>
>> -phil.
>>
>> On 05/08/2015 12:25 PM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review the fix for a typos in jdk9. This CR was filed by me
>>> long time ago and I doubt that someone will take a look at it.
>>> I fixed all clients files in sun.** subpackages.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6587235
>>> Webrev can be found at:
>>> http://cr.openjdk.java.net/~serb/6587235/webrev.00
>>>
>>
>
>
From prasanta.sadhukhan at oracle.com Mon May 11 05:55:11 2015
From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan)
Date: Mon, 11 May 2015 11:25:11 +0530
Subject: [OpenJDK 2D-Dev] Review Request: (JDK-8077584) Value of
java.awt.font.OpenType.TAG_OPBD is incorrect
In-Reply-To: <55485C9E.4000603@oracle.com>
References: <552E4D86.2010101@oracle.com> <5541C59D.2000909@oracle.com>
<554212BC.4020408@oracle.com> <55421957.8000906@oracle.com>
<55479D3C.1050508@oracle.com> <55485C9E.4000603@oracle.com>
Message-ID: <5550443F.4080606@oracle.com>
Hi All,
Any more feedback? Can this be committed?
Regards
Prasanta
On 5/5/2015 11:31 AM, prasanta sadhukhan wrote:
> Thanks for the info. It's Done.
> http://cr.openjdk.java.net/~psadhukhan/8077584/webrev.02/
>
> Regards
> Prasanta
> On 5/4/2015 9:54 PM, Phil Race wrote:
>> Please remove the "@author" tag. We do not use them in OpenJDK
>>
>> -phil.
>>
>> On 04/30/2015 05:00 AM, prasanta sadhukhan wrote:
>>> Hi Sergey,
>>>
>>> Done.
>>> http://cr.openjdk.java.net/~psadhukhan/8077584/webrev.01/
>>>
>>> Regards
>>> Prasanta
>>> On 4/30/2015 5:02 PM, Sergey Bylokhov wrote:
>>>> Hi, Prasanta.
>>>> Can you split the long lines in the test?
>>>>
>>>> On 30.04.15 9:03, prasanta sadhukhan wrote:
>>>>> Hi All,
>>>>>
>>>>> Any feedback? Can this be committed?
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 4/15/2015 5:07 PM, prasanta sadhukhan wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I would like a review for a jdk9 fix whereby TAG_OPBD tag is
>>>>>> updated to correct value.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8077584
>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8077584/webrev.00/
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>
>>>>
>>>>
>>>
>>
>
From prasanta.sadhukhan at oracle.com Mon May 11 05:55:35 2015
From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan)
Date: Mon, 11 May 2015 11:25:35 +0530
Subject: [OpenJDK 2D-Dev] RFR: (JDK-8015368) [TESTBUG]
javax/print/attribute/URLPDFPrinting.java fails on solaris with
java.net.ConnectException: Connection timed out
In-Reply-To: <55485999.1010101@oracle.com>
References: <55472B22.1020600@oracle.com> <55479CED.9030004@oracle.com>
<55485999.1010101@oracle.com>
Message-ID: <55504457.4080401@oracle.com>
Hi All,
Any feedback? Can this be committed?
Regards
Prasanta
On 5/5/2015 11:18 AM, prasanta sadhukhan wrote:
> Thanks Phil for pointing that. I have added the GPL.
> Please find the modified webrev
> http://cr.openjdk.java.net/~psadhukhan/8015368/webrev.00/
>
> Regards
> Prasanta
>
> On 5/4/2015 9:53 PM, Phil Race wrote:
>> The test is missing the GPL. Make sure you copy one from a test so as
>> NOT to include the class path exception
>>
>> -phil.
>>
>> On 05/04/2015 01:17 AM, prasanta sadhukhan wrote:
>>> Hi,
>>>
>>> The test in question was trying to connect to an address that when
>>> run inside Oracle needs an HTTP proxy and the test system is not
>>> configured with proxies so it's getting timed out.
>>> The fix is to generate a simple pdf and use it from local folder.
>>> Also, moved the test out of closed repo to general open domain.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8015368
>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8015368/webrev.00/
>>>
>>> Regards
>>> Prasanta
>>
>
From philip.race at oracle.com Mon May 11 16:54:50 2015
From: philip.race at oracle.com (Phil Race)
Date: Mon, 11 May 2015 09:54:50 -0700
Subject: [OpenJDK 2D-Dev] Review Request: (JDK-8077584) Value of
java.awt.font.OpenType.TAG_OPBD is incorrect
In-Reply-To: <5550443F.4080606@oracle.com>
References: <552E4D86.2010101@oracle.com> <5541C59D.2000909@oracle.com>
<554212BC.4020408@oracle.com> <55421957.8000906@oracle.com>
<55479D3C.1050508@oracle.com> <55485C9E.4000603@oracle.com>
<5550443F.4080606@oracle.com>
Message-ID: <5550DEDA.9000702@oracle.com>
On 5/10/15 10:55 PM, prasanta sadhukhan wrote:
> Hi All,
>
> Any more feedback? Can this be committed?
Yes, it can be committed.
-phil.
>
> Regards
> Prasanta
>
> On 5/5/2015 11:31 AM, prasanta sadhukhan wrote:
>> Thanks for the info. It's Done.
>> http://cr.openjdk.java.net/~psadhukhan/8077584/webrev.02/
>>
>> Regards
>> Prasanta
>> On 5/4/2015 9:54 PM, Phil Race wrote:
>>> Please remove the "@author" tag. We do not use them in OpenJDK
>>>
>>> -phil.
>>>
>>> On 04/30/2015 05:00 AM, prasanta sadhukhan wrote:
>>>> Hi Sergey,
>>>>
>>>> Done.
>>>> http://cr.openjdk.java.net/~psadhukhan/8077584/webrev.01/
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 4/30/2015 5:02 PM, Sergey Bylokhov wrote:
>>>>> Hi, Prasanta.
>>>>> Can you split the long lines in the test?
>>>>>
>>>>> On 30.04.15 9:03, prasanta sadhukhan wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> Any feedback? Can this be committed?
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>> On 4/15/2015 5:07 PM, prasanta sadhukhan wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I would like a review for a jdk9 fix whereby TAG_OPBD tag is
>>>>>>> updated to correct value.
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8077584
>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8077584/webrev.00/
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
From vadim.pakhnushev at oracle.com Wed May 13 10:48:36 2015
From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev)
Date: Wed, 13 May 2015 13:48:36 +0300
Subject: [OpenJDK 2D-Dev] RFR: JDK-8079652: Could not enable D3D pipeline
In-Reply-To: <554D0297.3060501@oracle.com>
References: <554C98E8.8090006@oracle.com>
<554CB69E.9070402@oracle.com> <554CB7D6.4090804@oracle.com>
<554CB9FC.2020404@oracle.com> <554D0297.3060501@oracle.com>
Message-ID: <55532C04.8000406@oracle.com>
Actually I've found a better solution - specify WS_POPUP window style.
In this case the client area size will be exactly as specified instead
of adjusting for some default window style.
So please review the second iteration:
diff --git
a/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
b/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
---
a/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
+++
b/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
@@ -828,7 +828,7 @@
return 0;
}
- HWND hWnd = CreateWindow(L"D3DFocusWindow", L"D3DFocusWindow", 0,
+ HWND hWnd = CreateWindow(L"D3DFocusWindow", L"D3DFocusWindow",
WS_POPUP,
mi.rcMonitor.left, mi.rcMonitor.top, 1, 1,
NULL, NULL, GetModuleHandle(NULL), NULL);
if (hWnd == 0) {
Thanks,
Vadim
On 08.05.2015 21:38, Phil Race wrote:
> I guess this is OK since 100x100 ought to be always big enough but not
> too big ..
> I suppose it may imply a different default window style is being added
> by CreateWindow
> than we got before.
>
> -phil.
>
>
>
> On 5/8/2015 6:28 AM, Sergey Bylokhov wrote:
>> Hi, Vadim.
>> Thanks for clarification, please add this information as a comment to
>> the code, before the push.
>>
>> On 08.05.15 16:19, Vadim Pakhnushev wrote:
>>> It's invisible and used only for getting application focus
>>> notifications internally by Direct3D.
>>>
>>> On 08.05.2015 16:14, Sergey Bylokhov wrote:
>>>> Hi, Vadim.
>>>> Why we do not use the full screen size for this window?
>>>>
>>>> On 08.05.15 14:07, Vadim Pakhnushev wrote:
>>>>> Hi,
>>>>> Please review the fix for
>>>>> https://bugs.openjdk.java.net/browse/JDK-8079652
>>>>> Focus window's client area should be bigger otherwise CreateDevice
>>>>> fails.
>>>>>
>>>>> diff --git
>>>>> a/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>>>>> b/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>>>>>
>>>>> ---
>>>>> a/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>>>>> +++
>>>>> b/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>>>>> @@ -829,7 +829,7 @@
>>>>> }
>>>>>
>>>>> HWND hWnd = CreateWindow(L"D3DFocusWindow",
>>>>> L"D3DFocusWindow", 0,
>>>>> - mi.rcMonitor.left, mi.rcMonitor.top, 1, 1,
>>>>> + mi.rcMonitor.left, mi.rcMonitor.top, 100, 100,
>>>>> NULL, NULL, GetModuleHandle(NULL), NULL);
>>>>> if (hWnd == 0) {
>>>>> J2dRlsTraceLn(J2D_TRACE_ERROR,
>>>>>
>>>>
>>>>
>>>
>>
>>
>
From philip.race at oracle.com Wed May 13 20:45:51 2015
From: philip.race at oracle.com (Phil Race)
Date: Wed, 13 May 2015 13:45:51 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8080317: Disable warning treated as error for
signed/unsigned comparison in building splashscreen
Message-ID: <5553B7FF.8030103@oracle.com>
Warnings are now treated as errors by default.
I need a quick review on this from anyone who is available so I can fix
our build for integration...
-phil.
https://bugs.openjdk.java.net/browse/JDK-8080317
$ hg diff make/lib/Awt2dLibraries.gmk
diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk
--- a/make/lib/Awt2dLibraries.gmk
+++ b/make/lib/Awt2dLibraries.gmk
@@ -885,10 +885,10 @@
OPTIMIZATION := LOW, \
CFLAGS := $(LIBSPLASHSCREEN_CFLAGS) $(CFLAGS_JDKLIB) \
$(GIFLIB_CFLAGS) $(LIBJPEG_CFLAGS) $(PNG_CFLAGS), \
- DISABLED_WARNINGS_gcc := type-limits unused-result
maybe-uninitialized, \
+ DISABLED_WARNINGS_gcc := sign-compare type-limits unused-result
maybe-uninitialized, \
DISABLED_WARNINGS_clang := incompatible-pointer-types, \
DISABLED_WARNINGS_solstudio := E_NEWLINE_NOT_LAST
E_DECLARATION_IN_CODE, \
- DISABLED_WARNINGS_microsoft := 4244 4267, \
+ DISABLED_WARNINGS_microsoft := 4018 4244 4267, \
MAPFILE :=
$(JDK_TOPDIR)/make/mapfiles/libsplashscreen/mapfile-vers, \
LDFLAGS := $(LDFLAGS_JDKLIB) \
$(call SET_SHARED_LIBRARY_ORIGIN), \
From david.dehaven at oracle.com Wed May 13 20:51:35 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Wed, 13 May 2015 13:51:35 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8080317: Disable warning treated as error
for signed/unsigned comparison in building splashscreen
In-Reply-To: <5553B7FF.8030103@oracle.com>
References: <5553B7FF.8030103@oracle.com>
Message-ID: <377F5495-4341-4A32-80BE-BB2AB276F0CB@oracle.com>
Adding Magnus
-DrD-
> On May 13, 2015, at 1:45 PM, Phil Race wrote:
>
> Warnings are now treated as errors by default.
> I need a quick review on this from anyone who is available so I can fix our build for integration...
>
> -phil.
>
> https://bugs.openjdk.java.net/browse/JDK-8080317
>
> $ hg diff make/lib/Awt2dLibraries.gmk
> diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk
> --- a/make/lib/Awt2dLibraries.gmk
> +++ b/make/lib/Awt2dLibraries.gmk
> @@ -885,10 +885,10 @@
> OPTIMIZATION := LOW, \
> CFLAGS := $(LIBSPLASHSCREEN_CFLAGS) $(CFLAGS_JDKLIB) \
> $(GIFLIB_CFLAGS) $(LIBJPEG_CFLAGS) $(PNG_CFLAGS), \
> - DISABLED_WARNINGS_gcc := type-limits unused-result maybe-uninitialized, \
> + DISABLED_WARNINGS_gcc := sign-compare type-limits unused-result maybe-uninitialized, \
> DISABLED_WARNINGS_clang := incompatible-pointer-types, \
> DISABLED_WARNINGS_solstudio := E_NEWLINE_NOT_LAST E_DECLARATION_IN_CODE, \
> - DISABLED_WARNINGS_microsoft := 4244 4267, \
> + DISABLED_WARNINGS_microsoft := 4018 4244 4267, \
> MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libsplashscreen/mapfile-vers, \
> LDFLAGS := $(LDFLAGS_JDKLIB) \
> $(call SET_SHARED_LIBRARY_ORIGIN), \
>
From david.dehaven at oracle.com Wed May 13 20:57:23 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Wed, 13 May 2015 13:57:23 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8080317: Disable warning treated as error
for signed/unsigned comparison in building splashscreen
In-Reply-To: <5553B7FF.8030103@oracle.com>
References: <5553B7FF.8030103@oracle.com>
Message-ID: <4EC0FD54-F7CD-451D-B3BA-6C5357136B37@oracle.com>
The changes look ok to me.
-DrD-
> On May 13, 2015, at 1:45 PM, Phil Race wrote:
>
> Warnings are now treated as errors by default.
> I need a quick review on this from anyone who is available so I can fix our build for integration...
>
> -phil.
>
> https://bugs.openjdk.java.net/browse/JDK-8080317
>
> $ hg diff make/lib/Awt2dLibraries.gmk
> diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk
> --- a/make/lib/Awt2dLibraries.gmk
> +++ b/make/lib/Awt2dLibraries.gmk
> @@ -885,10 +885,10 @@
> OPTIMIZATION := LOW, \
> CFLAGS := $(LIBSPLASHSCREEN_CFLAGS) $(CFLAGS_JDKLIB) \
> $(GIFLIB_CFLAGS) $(LIBJPEG_CFLAGS) $(PNG_CFLAGS), \
> - DISABLED_WARNINGS_gcc := type-limits unused-result maybe-uninitialized, \
> + DISABLED_WARNINGS_gcc := sign-compare type-limits unused-result maybe-uninitialized, \
> DISABLED_WARNINGS_clang := incompatible-pointer-types, \
> DISABLED_WARNINGS_solstudio := E_NEWLINE_NOT_LAST E_DECLARATION_IN_CODE, \
> - DISABLED_WARNINGS_microsoft := 4244 4267, \
> + DISABLED_WARNINGS_microsoft := 4018 4244 4267, \
> MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libsplashscreen/mapfile-vers, \
> LDFLAGS := $(LDFLAGS_JDKLIB) \
> $(call SET_SHARED_LIBRARY_ORIGIN), \
>
From mark.reinhold at oracle.com Thu May 14 16:43:49 2015
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 14 May 2015 09:43:49 -0700 (PDT)
Subject: [OpenJDK 2D-Dev] JEP 251: Multi-Resolution Images
Message-ID: <20150514164349.6557762BD8@eggemoggin.niobe.net>
New JEP Candidate: http://openjdk.java.net/jeps/251
- Mark
From philip.race at oracle.com Fri May 15 20:00:00 2015
From: philip.race at oracle.com (Phil Race)
Date: Fri, 15 May 2015 13:00:00 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8u backport of 8076419: Path2D copy
constructors and clone method propagate size of arrays from source path
Message-ID: <55565040.3050201@oracle.com>
I have prepared a direct 8u-dev backport of the JDK 9
fix for https://bugs.openjdk.java.net/browse/JDK-8076419
http://cr.openjdk.java.net/~prr/8076419.8u/
Please review.
For reference the JDK 9 review was here
http://mail.openjdk.java.net/pipermail/2d-dev/2015-March/005246.html
and the JDK 9 changeset is here
http://hg.openjdk.java.net/jdk9/client/jdk/rev/9e9588daa10c
-phil.
From prasanta.sadhukhan at oracle.com Mon May 18 06:21:59 2015
From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan)
Date: Mon, 18 May 2015 11:51:59 +0530
Subject: [OpenJDK 2D-Dev] RFR: (JDK-8015368) [TESTBUG]
javax/print/attribute/URLPDFPrinting.java fails on solaris with
java.net.ConnectException: Connection timed out
In-Reply-To: <55504457.4080401@oracle.com>
References: <55472B22.1020600@oracle.com>
<55479CED.9030004@oracle.com> <55485999.1010101@oracle.com>
<55504457.4080401@oracle.com>
Message-ID: <55598507.1060104@oracle.com>
Gentle reminder. If there is no more issue, can this webrev be commited?
Regards
Prasanta
On 5/11/2015 11:25 AM, prasanta sadhukhan wrote:
> Hi All,
>
> Any feedback? Can this be committed?
>
> Regards
> Prasanta
>
> On 5/5/2015 11:18 AM, prasanta sadhukhan wrote:
>> Thanks Phil for pointing that. I have added the GPL.
>> Please find the modified webrev
>> http://cr.openjdk.java.net/~psadhukhan/8015368/webrev.00/
>>
>> Regards
>> Prasanta
>>
>> On 5/4/2015 9:53 PM, Phil Race wrote:
>>> The test is missing the GPL. Make sure you copy one from a test so
>>> as NOT to include the class path exception
>>>
>>> -phil.
>>>
>>> On 05/04/2015 01:17 AM, prasanta sadhukhan wrote:
>>>> Hi,
>>>>
>>>> The test in question was trying to connect to an address that when
>>>> run inside Oracle needs an HTTP proxy and the test system is not
>>>> configured with proxies so it's getting timed out.
>>>> The fix is to generate a simple pdf and use it from local folder.
>>>> Also, moved the test out of closed repo to general open domain.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8015368
>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8015368/webrev.00/
>>>>
>>>> Regards
>>>> Prasanta
>>>
>>
>
From philip.race at oracle.com Mon May 18 20:19:34 2015
From: philip.race at oracle.com (Phil Race)
Date: Mon, 18 May 2015 13:19:34 -0700
Subject: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD
Rendering hints seems not working without FRACTIONALMETRICS=ON
In-Reply-To: <55422C52.8010906@oracle.com>
References: <53BD5E45.4000805@oracle.com> <9A5D5D1C-F58F-4DFC-B327-9A9DB18B155E@gmail.com> <54297B00.5020604@oracle.com> <6B49FF00-8A8F-41DF-A574-B9537C1A2B94@gmail.com> <5437EE69.3090606@oracle.com> <54380F42.7060705@oracle.com> <54381FFC.5000507@oracle.com> <5438465D.5070503@oracle.com> <54384C03.5020006@oracle.com> <543ADF1B.9020802@oracle.com> <543BC85F.8050202@oracle.com> <543C62AC.2010907@oracle.com> <544A92CC.10406@oracle.com> <544AB09D.5060805@oracle.com>
<548B21D2.8080701@oracle.com> <5512CB71.30908@oracle.com>
<5512EF51.7070907@plausible.coop> <5514029A.1090101@oracle.com>
<55156E31.7080803@oracle.com> <553952F2.9040007@oracle.com>
<553A7046.3000008@oracle.com> <55422C52.8010906@oracle.com>
Message-ID: <555A4956.5060607@oracle.com>
Hi,
So 1.79 is essentially 1.8 which is what Mac historically used as gamma.
So I'd pick 180 instead of 179
Since that value minimises the discrepancy it's looking positive but
there's still a discrepancy.
Before we 'live with it', I'd be interested to know what happens if you
set your display's profile to a generic RGB one.
How do the glyph shapes (if you try your best to ignore the colour)
match what other apps produce ?
-phil.
On 04/30/2015 06:21 AM, Andrew Brygin wrote:
> Hello Phil,
>
> please take a look to updated version of the fix:
>
> http://cr.openjdk.java.net/~bae/8023794/9/webrev.09/
>
> The main difference is in glyph generation. I have implemented
> 'reverse gamma correction'
> approach instead of 'glyph blending'. By default we use gamma value
> which provides minimum
> of discrepancy with gyph images produced by Apple's jdk. However, it
> can be adjusted via
> environment variable J2D_LCD_REVERSE_GAMMA (CGGlyphImages.m, lines
> 198 - 220).
>
> Following chart illustrates dependency between the 'reverse gamma'
> and a difference
> in pixel values comparing to jdk6 from Apple:
> http://cr.openjdk.java.net/~bae/8023794/best_reverse_gamma.png
>
> Following set of images has been used for the comparison:
> http://cr.openjdk.java.net/~bae/8023794/images/
> An index of image corresponds to the value of reverse gamma used for
> image
> generation.
>
> Beside this, following minor changes were done:
> * RenderingHints.KEY_ANTIALIASING was removed form fontHints,
> because it has no direct relation to text rendering, and does not
> have
> any effect at the moment.
> * A comment regarding unevaluated rendering hints was added.
>
> Please take a look.
>
> Thanks,
> Andrew
>
> On 4/24/2015 7:33 PM, Andrew Brygin wrote:
>> Hello Phil,
>>
>> please see my comments inline.
>> On 4/23/2015 11:15 PM, Phil Race wrote:
>>>
>>> 373 fontHints.put(RenderingHints.KEY_ANTIALIASING,
>>> RenderingHints.VALUE_ANTIALIAS_ON);
>>>
>>> Why do we need this ? Historically in the (non-OSX) code this would
>>> slow things down by making
>>> text rendering go via ductus rendering.
>>> If this really is a 'fontsHint' map, it seems it should not be here.
>>
>> I agree that this particular hint has no direct relation to the font
>> hints,
>> and probably should not be here. I guess that KEY_ANTALIASING was put
>> here in order to force text antialiasing on when default text
>> antailiasing is evaluating:
>>
>> http://hg.openjdk.java.net/jdk9/client/jdk/file/0e483e64c1e4/src/java.desktop/share/classes/sun/java2d/SurfaceData.java#l741
>>
>>
>> I do not think that it has any effect now, because we set text
>> antialiasing hint explicitly.
>> I will check whether it can be safely removed.
>>
>>> 410 sg2d.surfaceData.getTransparency() == Transparency.OPAQUE &&
>>>
>>> I thought you were removing this condition ?
>> I have rolled this change back, because at the moment lcd shader
>> produces ugly results in the case of translucent destination.
>> There is a separate bug regarding the translucent destination support:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8078516
>>
>> I am going to relax this condition when(if) our lcd shader will be
>> ready.
>>
>> In fact, this problem is not limited by ogl, because d3d and software
>> loops
>> has the same limitation.
>>
>>
>>>
>>> CGGlyphImages.m
>>>
>>> 202 #if __LITTLE_ENDIAN__
>>> 203 *(dst + 2) = 0xFF - (p >> 24 & 0xFF);
>>> 204 *(dst + 1) = 0xFF - (p >> 16 & 0xFF);
>>> 205 *(dst) = 0xFF - (p >> 8 & 0xFF);
>>> 206 #else
>>> 207 *(dst) = 0xFF - (p >> 16 & 0xFF);
>>> 208 *(dst + 1) = 0xFF - (p >> 8 & 0xFF);
>>> 209 *(dst + 2) = 0xFF - (p & 0xFF);
>>> 210 #endif
>>> 211 }
>>>
>>> became
>>> 217 {
>>> 218 *(dst + 0) = 0xFF - (p >> 16 & 0xFF); // red
>>> 219 *(dst + 1) = 0xFF - (p >> 8 & 0xFF); // green
>>> 220 *(dst + 2) = 0xFF - (p & 0xFF); // blue
>>> 221 }
>>>
>>>
>>> I started by assuming you were removing the BIG_ENDIAN code that
>>> was probably legacy PPC code but instead I see that the
>>> LITTLE_ENDIAN case is removed,
>>> so I don't understand this.
>>>
>>> And further down the file now I see that in ConvertBWPixelToByteGray
>>> you did remove the big endian case.
>>>
>>
>> Note that we are
>> Please note that we force the lcd glyph generation by requesting
>> host (i.e. LITTLE_ENDIAN) byte order for the canvas bitmap:
>>
>> 407 uint32_t bmpInfo = kCGImageAlphaPremultipliedFirst;
>> 408 if (mode->glyphDescriptor == &rgb) {
>> 409 bmpInfo |= kCGBitmapByteOrder32Host;
>> 410 }
>>
>> So, before the fix (and for grayscale case now) the buffer has default
>> BIG_ENDIAN order. I.e. grayscale canvas stores data in following format:
>>
>> as bytes: A R G B
>> as int: 0xBBGGRRAA
>>
>> The same byte order was used for the rgb canvas before the fix.
>> But now the canvas is configured to store data in following format:
>>
>> as bytes: B G R A
>> as int: 0xAARRGGBB
>>
>> So, data extraction routines were updated accordingly.
>>
>>> 365 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_GASP:
>>> 366 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_DEFAULT:
>>> 367 default:
>>> 368 e = [NSException
>>> 369 exceptionWithName:@"IllegalArgumentException"
>>> 370 reason:@"Invalid hint value"
>>> 371 userInfo:nil];
>>>
>>>
>>> I think this means that by the time we get here we should not have
>>> DEFAULT or GASP
>>> but we should have the actual interpretation for this surface, font
>>> and point size.
>>> So this looks correct but maybe you can add a comment on this.
>>
>> will do.
>>
>>> The heuristic of blending black and white is interesting.
>>> How did you arrive at this ? It suggests that the glyph bitmap we
>>> are caching is
>>> not 'colour neutral' which is odd. Maybe we are missing code to apply
>>> the 'reverse gamma correction' ?
>>
>> I have played with the idea about 'reverse gamma correction', it
>> seemed very attractive to me.
>> Roughly speaking, gamma > 1 makes black-on-white glyphs a bit
>> narrower, and white-no-black
>> glyphs a bit wider (bolder?), and it is the same effect that we need.
>> Unfortunately, direct comparison of black-on-white and
>> white-on-black glyphs makes me think
>> that difference between these glyphs can not be explained only by
>> gamma correction.
>>
>> Please take a look at this screenshot:
>> http://cr.openjdk.java.net/~bae/8023794/bw-wb-comparision.png
>>
>>
>> row 1: text is rendered by jdk6 as-is.
>> row 2: simulates our pipeline where black-on-white glyphs are used
>> (max error on white-on-black)
>> row 3: simulates our pipeline where white-on-black glyphs are used
>> (max error on black-on-white)
>> row 4: blended glyphs are used.
>>
>> The basic idea of blending is to minimize max error (difference)
>> between produced glyph image
>> and original color-aware glyphs.
>>
>> If better results can be achieved with 'reverse gamma correction', we
>> can revise this code later.
>>
>>> And can (should) any of these changes also be applied to D3D ?
>>
>> 1. We can check how gamma correction is done in d3d. If a lookup is
>> also used there,
>> we can assess how rough the interpolation is.
>>
>> 2. translucent destination support (as a part of JDK-8078516)?
>>
>> Thanks,
>> Andrew
>>
>>>
>>> -phil.
>>>
>>> On 03/27/2015 07:50 AM, Andrew Brygin wrote:
>>>> There is a minor update in the fix: it does not worth to blend
>>>> black-on-white
>>>> and white-on-black glyphs for the case of AA glyphs, because it
>>>> makes no difference.
>>>> CGGlyphImages.m, lines 294 - 325, 755 - 763, and 787 - 794:
>>>>
>>>> http://cr.openjdk.java.net/~bae/8023794/9/webrev.08
>>>>
>>>> I have also modified the AntialiasDemo a bit in order to render the
>>>> sample text in different colors, and in order to render into a
>>>> volatile
>>>> image as well:
>>>> http://cr.openjdk.java.net/~bae/8023794/demo/AntialiasDemo.java
>>>>
>>>> It could be used to assess the change in glyph generation.
>>>>
>>>> Thanks,
>>>> Andrew
>>>>
>>>> On 3/26/2015 3:59 PM, Andrew Brygin wrote:
>>>>> Hi Chris,
>>>>>
>>>>> thank you for the comments and explanation. I have updated the
>>>>> OGLContext_IsLCDShaderSupportAvailable()
>>>>> and comments in OGLTextRenderer.c accordingly:
>>>>>
>>>>> http://cr.openjdk.java.net/~bae/8023794/9/webrev.07/
>>>>>
>>>>> Good to know that you keep an eye on the OGL pipeline :)
>>>>>
>>>>> Thanks,
>>>>> Andrew
>>>>>
>>>>> On 3/25/2015 8:24 PM, Chris Campbell wrote:
>>>>>> Hi Andrew,
>>>>>>
>>>>>> That's a good find re: pow(). In the comment at lines 277-283 I
>>>>>> mentioned that there was only a scalar variant of pow(). I
>>>>>> wonder if that was a limitation in some early version of GLSL I
>>>>>> was using or perhaps some driver bug/restriction. According to
>>>>>> all the docs I can find the vector variants have been there all
>>>>>> along:
>>>>>> https://www.opengl.org/sdk/docs/man4/index.php
>>>>>>
>>>>>> So now I'm wondering if the slowness was actually due to me
>>>>>> trying 3 scalar pow() calls versus one vector pow() call.
>>>>>>
>>>>>> Oh, aha! I think this explains part of it:
>>>>>>
>>>>>> 269 * This is the GLSL fragment shader source code for
>>>>>> rendering LCD-optimized
>>>>>> 270 * text. Do not be frightened; it is much easier to
>>>>>> understand than the
>>>>>> 271 * equivalent ASM-like fragment program!
>>>>>>
>>>>>> Looks like I wrote the original version of this shader using the
>>>>>> GL_ARB_fragment_program language, which indeed only had a scalar
>>>>>> POW instruction (see section 3.11.5.20):
>>>>>> https://www.opengl.org/registry/specs/ARB/fragment_program.txt
>>>>>>
>>>>>> And then I'm guessing that when I rewrote it in more modern GLSL,
>>>>>> I didn't notice that pow() supported vectors. Sigh. That 3D
>>>>>> texture LUT was a lot of work for a whole lot of nothing.
>>>>>>
>>>>>> In any case, you might want to rewrite the comment at lines
>>>>>> 277-283 to suit the new code. Same goes for the comment at line
>>>>>> 315:
>>>>>>
>>>>>> // gamma adjust the dest color using the invgamma LUT
>>>>>>
>>>>>> Also, I noticed that the restrictions in
>>>>>> OGLContext_IsLCDShaderSupportAvailable() could be loosened since
>>>>>> you only need 2 texture units now. Just in the extremely
>>>>>> unlikely case that anyone's running this stuff on ancient
>>>>>> hardware :)
>>>>>>
>>>>>> Thanks,
>>>>>> Chris
>>>>>>
>>>>>>
>>>>>> Andrew Brygin wrote:
>>>>>>> Hello Phil,
>>>>>>>
>>>>>>> could you please take a look to updated version of the fix?
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~bae/8023794/9/webrev.06/
>>>>>>>
>>>>>>> * OGLTextRenderer.c
>>>>>>> It was discovered, that in some cases lcd glyphs had visible 'dark
>>>>>>> border' around.
>>>>>>> This border appeared due to the gamma correction in lcd shader,
>>>>>>> which
>>>>>>> uses lookup
>>>>>>> on 3D texture instead of using 'pow' routine. The texture is
>>>>>>> populated
>>>>>>> with significant
>>>>>>> granularity (16 points per edge), what is a root cause of rough
>>>>>>> interpolation of color values.
>>>>>>> Suggested change is to eliminate the interpolation and use 'pow'
>>>>>>> routine
>>>>>>> directly.
>>>>>>> It gives more accurate color values, and does not introduce
>>>>>>> significant
>>>>>>> performance hit
>>>>>>> (see benchmark summary below).
>>>>>>> However, this part of the fix affects not only macosx, but any
>>>>>>> platform
>>>>>>> where OGL text
>>>>>>> shader can be used, so it probably worth to split into a
>>>>>>> separate fix.
>>>>>>>
>>>>>>> Summary:
>>>>>>> lcd-ogl-3Dlookup:
>>>>>>> Number of tests: 4
>>>>>>> Overall average: 42.68027553311743
>>>>>>> Best spread: 3.49% variance
>>>>>>> Worst spread: 29.59% variance
>>>>>>> (Basis for results comparison)
>>>>>>>
>>>>>>> lcd-ogl-pow:
>>>>>>> Number of tests: 4
>>>>>>> Overall average: 42.468941501367084
>>>>>>> Best spread: 2.51% variance
>>>>>>> Worst spread: 29.44% variance
>>>>>>> Comparison to basis:
>>>>>>> Best result: 103.28% of basis
>>>>>>> Worst result: 97.36% of basis
>>>>>>> Number of wins: 1
>>>>>>> Number of ties: 2
>>>>>>> Number of losses: 1
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Andrew
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>
From bourges.laurent at gmail.com Tue May 19 06:43:59 2015
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Tue, 19 May 2015 08:43:59 +0200
Subject: [OpenJDK 2D-Dev] RFR: 8u backport of 8076419: Path2D copy
constructors and clone method propagate size of arrays from source path
In-Reply-To: <55565040.3050201@oracle.com>
References: <55565040.3050201@oracle.com>
Message-ID:
Phil,
It seems OK for me but I am not an official reviewer, just the patch author.
Laurent
Le 15 mai 2015 22:02, "Phil Race" a ?crit :
>
> I have prepared a direct 8u-dev backport of the JDK 9
> fix for https://bugs.openjdk.java.net/browse/JDK-8076419
>
> http://cr.openjdk.java.net/~prr/8076419.8u/
>
> Please review.
>
> For reference the JDK 9 review was here
http://mail.openjdk.java.net/pipermail/2d-dev/2015-March/005246.html
> and the JDK 9 changeset is here
http://hg.openjdk.java.net/jdk9/client/jdk/rev/9e9588daa10c
>
> -phil.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From james.graham at oracle.com Tue May 19 22:05:06 2015
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 19 May 2015 15:05:06 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8u backport of 8076419: Path2D copy
constructors and clone method propagate size of arrays from source path
In-Reply-To: <55565040.3050201@oracle.com>
References: <55565040.3050201@oracle.com>
Message-ID: <555BB392.7070605@oracle.com>
+1!
...jim
On 5/15/2015 1:00 PM, Phil Race wrote:
> I have prepared a direct 8u-dev backport of the JDK 9
> fix for https://bugs.openjdk.java.net/browse/JDK-8076419
>
> http://cr.openjdk.java.net/~prr/8076419.8u/
>
> Please review.
>
> For reference the JDK 9 review was here
> http://mail.openjdk.java.net/pipermail/2d-dev/2015-March/005246.html
> and the JDK 9 changeset is here
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/9e9588daa10c
>
> -phil.
From philip.race at oracle.com Wed May 20 00:03:33 2015
From: philip.race at oracle.com (Phil Race)
Date: Tue, 19 May 2015 17:03:33 -0700
Subject: [OpenJDK 2D-Dev] RFR: (JDK-8015368) [TESTBUG]
javax/print/attribute/URLPDFPrinting.java fails on solaris with
java.net.ConnectException: Connection timed out
In-Reply-To: <55504457.4080401@oracle.com>
References: <55472B22.1020600@oracle.com> <55479CED.9030004@oracle.com>
<55485999.1010101@oracle.com> <55504457.4080401@oracle.com>
Message-ID: <555BCF55.5070802@oracle.com>
Looks fine now. Approved.
-phil.
On 5/10/15 10:55 PM, prasanta sadhukhan wrote:
> Hi All,
>
> Any feedback? Can this be committed?
>
> Regards
> Prasanta
>
> On 5/5/2015 11:18 AM, prasanta sadhukhan wrote:
>> Thanks Phil for pointing that. I have added the GPL.
>> Please find the modified webrev
>> http://cr.openjdk.java.net/~psadhukhan/8015368/webrev.00/
>>
>> Regards
>> Prasanta
>>
>> On 5/4/2015 9:53 PM, Phil Race wrote:
>>> The test is missing the GPL. Make sure you copy one from a test so
>>> as NOT to include the class path exception
>>>
>>> -phil.
>>>
>>> On 05/04/2015 01:17 AM, prasanta sadhukhan wrote:
>>>> Hi,
>>>>
>>>> The test in question was trying to connect to an address that when
>>>> run inside Oracle needs an HTTP proxy and the test system is not
>>>> configured with proxies so it's getting timed out.
>>>> The fix is to generate a simple pdf and use it from local folder.
>>>> Also, moved the test out of closed repo to general open domain.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8015368
>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8015368/webrev.00/
>>>>
>>>> Regards
>>>> Prasanta
>>>
>>
>
From philip.race at oracle.com Wed May 20 17:40:00 2015
From: philip.race at oracle.com (Phil Race)
Date: Wed, 20 May 2015 10:40:00 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8u backport of 8078464 : Path2D storage
growth algorithms should be less linear
Message-ID: <555CC6F0.8020001@oracle.com>
I have prepared a direct 8u-dev backport of the JDK 9
fix for https://bugs.openjdk.java.net/browse/JDK-8078464
http://cr.openjdk.java.net/~prr/8078464.8u/
Please review.
For reference the JDK 9 review was here :
http://mail.openjdk.java.net/pipermail/2d-dev/2015-April/005259.html
and the JDK 9 changeset is here
http://hg.openjdk.java.net/jdk9/client/jdk/rev/9b6ed21ae317
-phil.
From bourges.laurent at gmail.com Wed May 20 19:32:59 2015
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Wed, 20 May 2015 21:32:59 +0200
Subject: [OpenJDK 2D-Dev] RFR: 8u backport of 8078464 : Path2D storage
growth algorithms should be less linear
In-Reply-To: <555CC6F0.8020001@oracle.com>
References: <555CC6F0.8020001@oracle.com>
Message-ID:
Phil,
It is ok for me.
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From james.graham at oracle.com Wed May 20 22:19:15 2015
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 20 May 2015 15:19:15 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8u backport of 8078464 : Path2D storage
growth algorithms should be less linear
In-Reply-To: <555CC6F0.8020001@oracle.com>
References: <555CC6F0.8020001@oracle.com>
Message-ID: <555D0863.4080904@oracle.com>
+1...
...jim
On 5/20/2015 10:40 AM, Phil Race wrote:
> I have prepared a direct 8u-dev backport of the JDK 9
> fix for https://bugs.openjdk.java.net/browse/JDK-8078464
>
> http://cr.openjdk.java.net/~prr/8078464.8u/
>
> Please review.
>
> For reference the JDK 9 review was here :
> http://mail.openjdk.java.net/pipermail/2d-dev/2015-April/005259.html
> and the JDK 9 changeset is here
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/9b6ed21ae317
>
> -phil.
From Sergey.Bylokhov at oracle.com Thu May 21 13:22:08 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 21 May 2015 16:22:08 +0300
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8061831 [OGL]
"java.lang.InternalError: not implemented yet" during the blit of VI to VI
in xor mode
Message-ID: <555DDC00.7050608@oracle.com>
Hello.
Please review the fix for jdk9.
Our blits machinary in case of absent of direct/general blits will use
the AnyBlit, which uses surface.getRaster method. This method is not
implemented in OGL surfaces, so we must have some blit, which covers all
possible combinations of source/destination/composite.
In the fix for JDK-7124347[1] the new OGLAnyCompositeBlit was added, and
this new blit covers situation, when we cannot call getRaster on
destination and must read it to the temporary buffer. But it does not
take into account that the same problem exists for the source. If the
source surface is OpenGLSurface and xor composite is used we should copy
it to the temporary buffer also.
In this fix I added some parameters, which configure OGLAnyCompositeBlit
for the case when some kind of ogl source is passed.
[1] https://bugs.openjdk.java.net/browse/JDK-7124347
Bug: https://bugs.openjdk.java.net/browse/JDK-8061831
Webrev can be found at: http://cr.openjdk.java.net/~serb/8061831/webrev
--
Best regards, Sergey.
From andrew.brygin at oracle.com Thu May 21 14:23:09 2015
From: andrew.brygin at oracle.com (Andrew Brygin)
Date: Thu, 21 May 2015 17:23:09 +0300
Subject: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD
Rendering hints seems not working without FRACTIONALMETRICS=ON
In-Reply-To: <555A4956.5060607@oracle.com>
References: <53BD5E45.4000805@oracle.com> <9A5D5D1C-F58F-4DFC-B327-9A9DB18B155E@gmail.com> <54297B00.5020604@oracle.com> <6B49FF00-8A8F-41DF-A574-B9537C1A2B94@gmail.com> <5437EE69.3090606@oracle.com> <54380F42.7060705@oracle.com> <54381FFC.5000507@oracle.com> <5438465D.5070503@oracle.com> <54384C03.5020006@oracle.com> <543ADF1B.9020802@oracle.com> <543BC85F.8050202@oracle.com> <543C62AC.2010907@oracle.com> <544A92CC.10406@oracle.com> <544AB09D.5060805@oracle.com>
<548B21D2.8080701@oracle.com> <5512CB71.30908@oracle.com>
<5512EF51.7070907@plausible.coop> <5514029A.1090101@oracle.com>
<55156E31.7080803@oracle.com> <553952F2.9040007@oracle.com>
<553A7046.3000008@oracle.com> <55422C52.8010906@oracle.com>
<555A4956.5060607@oracle.com>
Message-ID: <555DEA4D.2010903@oracle.com>
Hello Phil,
I have changed the default reverse gamma to 180:
http://cr.openjdk.java.net/~bae/8023794/9/webrev.10/
I also did some experiments with the lcd contrast, and found that
value 160 decreases the discrepancy a bit: 21 instead of 29 with
the default lcd contrast value (140).
However, there still is the discrepancy, and at the moment I do not
see how we can avoid it completely with our rendering model.
It looks like that there is something more sophisticated than
just gamma correction, and we are unable to derive 'color independent'
glyphs from black-on-white glyphs provided by the native system.
I have also played with changing display profiles but it seems to
have no detectable effect.
Thanks,
Andrew
On 5/18/2015 11:19 PM, Phil Race wrote:
> Hi,
>
> So 1.79 is essentially 1.8 which is what Mac historically used as
> gamma. So I'd pick 180 instead of 179
> Since that value minimises the discrepancy it's looking positive but
> there's still a discrepancy.
> Before we 'live with it', I'd be interested to know what happens if
> you set your display's profile to a generic RGB one.
>
> How do the glyph shapes (if you try your best to ignore the colour)
> match what other apps produce ?
>
> -phil.
>
>
> On 04/30/2015 06:21 AM, Andrew Brygin wrote:
>> Hello Phil,
>>
>> please take a look to updated version of the fix:
>>
>> http://cr.openjdk.java.net/~bae/8023794/9/webrev.09/
>>
>> The main difference is in glyph generation. I have implemented
>> 'reverse gamma correction'
>> approach instead of 'glyph blending'. By default we use gamma value
>> which provides minimum
>> of discrepancy with gyph images produced by Apple's jdk. However, it
>> can be adjusted via
>> environment variable J2D_LCD_REVERSE_GAMMA (CGGlyphImages.m, lines
>> 198 - 220).
>>
>> Following chart illustrates dependency between the 'reverse gamma'
>> and a difference
>> in pixel values comparing to jdk6 from Apple:
>> http://cr.openjdk.java.net/~bae/8023794/best_reverse_gamma.png
>>
>> Following set of images has been used for the comparison:
>> http://cr.openjdk.java.net/~bae/8023794/images/
>> An index of image corresponds to the value of reverse gamma used for
>> image
>> generation.
>>
>> Beside this, following minor changes were done:
>> * RenderingHints.KEY_ANTIALIASING was removed form fontHints,
>> because it has no direct relation to text rendering, and does
>> not have
>> any effect at the moment.
>> * A comment regarding unevaluated rendering hints was added.
>>
>> Please take a look.
>>
>> Thanks,
>> Andrew
>>
>> On 4/24/2015 7:33 PM, Andrew Brygin wrote:
>>> Hello Phil,
>>>
>>> please see my comments inline.
>>> On 4/23/2015 11:15 PM, Phil Race wrote:
>>>>
>>>> 373 fontHints.put(RenderingHints.KEY_ANTIALIASING,
>>>> RenderingHints.VALUE_ANTIALIAS_ON);
>>>>
>>>> Why do we need this ? Historically in the (non-OSX) code this would
>>>> slow things down by making
>>>> text rendering go via ductus rendering.
>>>> If this really is a 'fontsHint' map, it seems it should not be here.
>>>
>>> I agree that this particular hint has no direct relation to the font
>>> hints,
>>> and probably should not be here. I guess that KEY_ANTALIASING was put
>>> here in order to force text antialiasing on when default text
>>> antailiasing is evaluating:
>>>
>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/0e483e64c1e4/src/java.desktop/share/classes/sun/java2d/SurfaceData.java#l741
>>>
>>>
>>> I do not think that it has any effect now, because we set text
>>> antialiasing hint explicitly.
>>> I will check whether it can be safely removed.
>>>
>>>> 410 sg2d.surfaceData.getTransparency() == Transparency.OPAQUE &&
>>>>
>>>> I thought you were removing this condition ?
>>> I have rolled this change back, because at the moment lcd shader
>>> produces ugly results in the case of translucent destination.
>>> There is a separate bug regarding the translucent destination support:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8078516
>>>
>>> I am going to relax this condition when(if) our lcd shader will be
>>> ready.
>>>
>>> In fact, this problem is not limited by ogl, because d3d and
>>> software loops
>>> has the same limitation.
>>>
>>>
>>>>
>>>> CGGlyphImages.m
>>>>
>>>> 202 #if __LITTLE_ENDIAN__
>>>> 203 *(dst + 2) = 0xFF - (p >> 24 & 0xFF);
>>>> 204 *(dst + 1) = 0xFF - (p >> 16 & 0xFF);
>>>> 205 *(dst) = 0xFF - (p >> 8 & 0xFF);
>>>> 206 #else
>>>> 207 *(dst) = 0xFF - (p >> 16 & 0xFF);
>>>> 208 *(dst + 1) = 0xFF - (p >> 8 & 0xFF);
>>>> 209 *(dst + 2) = 0xFF - (p & 0xFF);
>>>> 210 #endif
>>>> 211 }
>>>>
>>>> became
>>>> 217 {
>>>> 218 *(dst + 0) = 0xFF - (p >> 16 & 0xFF); // red
>>>> 219 *(dst + 1) = 0xFF - (p >> 8 & 0xFF); // green
>>>> 220 *(dst + 2) = 0xFF - (p & 0xFF); // blue
>>>> 221 }
>>>>
>>>>
>>>> I started by assuming you were removing the BIG_ENDIAN code that
>>>> was probably legacy PPC code but instead I see that the
>>>> LITTLE_ENDIAN case is removed,
>>>> so I don't understand this.
>>>>
>>>> And further down the file now I see that in
>>>> ConvertBWPixelToByteGray you did remove the big endian case.
>>>>
>>>
>>> Note that we are
>>> Please note that we force the lcd glyph generation by requesting
>>> host (i.e. LITTLE_ENDIAN) byte order for the canvas bitmap:
>>>
>>> 407 uint32_t bmpInfo = kCGImageAlphaPremultipliedFirst;
>>> 408 if (mode->glyphDescriptor == &rgb) {
>>> 409 bmpInfo |= kCGBitmapByteOrder32Host;
>>> 410 }
>>>
>>> So, before the fix (and for grayscale case now) the buffer has default
>>> BIG_ENDIAN order. I.e. grayscale canvas stores data in following
>>> format:
>>>
>>> as bytes: A R G B
>>> as int: 0xBBGGRRAA
>>>
>>> The same byte order was used for the rgb canvas before the fix.
>>> But now the canvas is configured to store data in following format:
>>>
>>> as bytes: B G R A
>>> as int: 0xAARRGGBB
>>>
>>> So, data extraction routines were updated accordingly.
>>>
>>>> 365 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_GASP:
>>>> 366 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_DEFAULT:
>>>> 367 default:
>>>> 368 e = [NSException
>>>> 369 exceptionWithName:@"IllegalArgumentException"
>>>> 370 reason:@"Invalid hint value"
>>>> 371 userInfo:nil];
>>>>
>>>>
>>>> I think this means that by the time we get here we should not have
>>>> DEFAULT or GASP
>>>> but we should have the actual interpretation for this surface, font
>>>> and point size.
>>>> So this looks correct but maybe you can add a comment on this.
>>>
>>> will do.
>>>
>>>> The heuristic of blending black and white is interesting.
>>>> How did you arrive at this ? It suggests that the glyph bitmap we
>>>> are caching is
>>>> not 'colour neutral' which is odd. Maybe we are missing code to apply
>>>> the 'reverse gamma correction' ?
>>>
>>> I have played with the idea about 'reverse gamma correction', it
>>> seemed very attractive to me.
>>> Roughly speaking, gamma > 1 makes black-on-white glyphs a bit
>>> narrower, and white-no-black
>>> glyphs a bit wider (bolder?), and it is the same effect that we need.
>>> Unfortunately, direct comparison of black-on-white and
>>> white-on-black glyphs makes me think
>>> that difference between these glyphs can not be explained only by
>>> gamma correction.
>>>
>>> Please take a look at this screenshot:
>>> http://cr.openjdk.java.net/~bae/8023794/bw-wb-comparision.png
>>>
>>>
>>> row 1: text is rendered by jdk6 as-is.
>>> row 2: simulates our pipeline where black-on-white glyphs are used
>>> (max error on white-on-black)
>>> row 3: simulates our pipeline where white-on-black glyphs are used
>>> (max error on black-on-white)
>>> row 4: blended glyphs are used.
>>>
>>> The basic idea of blending is to minimize max error (difference)
>>> between produced glyph image
>>> and original color-aware glyphs.
>>>
>>> If better results can be achieved with 'reverse gamma correction',
>>> we can revise this code later.
>>>
>>>> And can (should) any of these changes also be applied to D3D ?
>>>
>>> 1. We can check how gamma correction is done in d3d. If a lookup is
>>> also used there,
>>> we can assess how rough the interpolation is.
>>>
>>> 2. translucent destination support (as a part of JDK-8078516)?
>>>
>>> Thanks,
>>> Andrew
>>>
>>>>
>>>> -phil.
>>>>
>>>> On 03/27/2015 07:50 AM, Andrew Brygin wrote:
>>>>> There is a minor update in the fix: it does not worth to blend
>>>>> black-on-white
>>>>> and white-on-black glyphs for the case of AA glyphs, because it
>>>>> makes no difference.
>>>>> CGGlyphImages.m, lines 294 - 325, 755 - 763, and 787 - 794:
>>>>>
>>>>> http://cr.openjdk.java.net/~bae/8023794/9/webrev.08
>>>>>
>>>>> I have also modified the AntialiasDemo a bit in order to render the
>>>>> sample text in different colors, and in order to render into a
>>>>> volatile
>>>>> image as well:
>>>>> http://cr.openjdk.java.net/~bae/8023794/demo/AntialiasDemo.java
>>>>>
>>>>> It could be used to assess the change in glyph generation.
>>>>>
>>>>> Thanks,
>>>>> Andrew
>>>>>
>>>>> On 3/26/2015 3:59 PM, Andrew Brygin wrote:
>>>>>> Hi Chris,
>>>>>>
>>>>>> thank you for the comments and explanation. I have updated the
>>>>>> OGLContext_IsLCDShaderSupportAvailable()
>>>>>> and comments in OGLTextRenderer.c accordingly:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~bae/8023794/9/webrev.07/
>>>>>>
>>>>>> Good to know that you keep an eye on the OGL pipeline :)
>>>>>>
>>>>>> Thanks,
>>>>>> Andrew
>>>>>>
>>>>>> On 3/25/2015 8:24 PM, Chris Campbell wrote:
>>>>>>> Hi Andrew,
>>>>>>>
>>>>>>> That's a good find re: pow(). In the comment at lines 277-283 I
>>>>>>> mentioned that there was only a scalar variant of pow(). I
>>>>>>> wonder if that was a limitation in some early version of GLSL I
>>>>>>> was using or perhaps some driver bug/restriction. According to
>>>>>>> all the docs I can find the vector variants have been there all
>>>>>>> along:
>>>>>>> https://www.opengl.org/sdk/docs/man4/index.php
>>>>>>>
>>>>>>> So now I'm wondering if the slowness was actually due to me
>>>>>>> trying 3 scalar pow() calls versus one vector pow() call.
>>>>>>>
>>>>>>> Oh, aha! I think this explains part of it:
>>>>>>>
>>>>>>> 269 * This is the GLSL fragment shader source code for
>>>>>>> rendering LCD-optimized
>>>>>>> 270 * text. Do not be frightened; it is much easier to
>>>>>>> understand than the
>>>>>>> 271 * equivalent ASM-like fragment program!
>>>>>>>
>>>>>>> Looks like I wrote the original version of this shader using the
>>>>>>> GL_ARB_fragment_program language, which indeed only had a scalar
>>>>>>> POW instruction (see section 3.11.5.20):
>>>>>>> https://www.opengl.org/registry/specs/ARB/fragment_program.txt
>>>>>>>
>>>>>>> And then I'm guessing that when I rewrote it in more modern
>>>>>>> GLSL, I didn't notice that pow() supported vectors. Sigh. That
>>>>>>> 3D texture LUT was a lot of work for a whole lot of nothing.
>>>>>>>
>>>>>>> In any case, you might want to rewrite the comment at lines
>>>>>>> 277-283 to suit the new code. Same goes for the comment at line
>>>>>>> 315:
>>>>>>>
>>>>>>> // gamma adjust the dest color using the invgamma LUT
>>>>>>>
>>>>>>> Also, I noticed that the restrictions in
>>>>>>> OGLContext_IsLCDShaderSupportAvailable() could be loosened since
>>>>>>> you only need 2 texture units now. Just in the extremely
>>>>>>> unlikely case that anyone's running this stuff on ancient
>>>>>>> hardware :)
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Chris
>>>>>>>
>>>>>>>
>>>>>>> Andrew Brygin wrote:
>>>>>>>> Hello Phil,
>>>>>>>>
>>>>>>>> could you please take a look to updated version of the fix?
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~bae/8023794/9/webrev.06/
>>>>>>>>
>>>>>>>> * OGLTextRenderer.c
>>>>>>>> It was discovered, that in some cases lcd glyphs had visible 'dark
>>>>>>>> border' around.
>>>>>>>> This border appeared due to the gamma correction in lcd shader,
>>>>>>>> which
>>>>>>>> uses lookup
>>>>>>>> on 3D texture instead of using 'pow' routine. The texture is
>>>>>>>> populated
>>>>>>>> with significant
>>>>>>>> granularity (16 points per edge), what is a root cause of rough
>>>>>>>> interpolation of color values.
>>>>>>>> Suggested change is to eliminate the interpolation and use
>>>>>>>> 'pow' routine
>>>>>>>> directly.
>>>>>>>> It gives more accurate color values, and does not introduce
>>>>>>>> significant
>>>>>>>> performance hit
>>>>>>>> (see benchmark summary below).
>>>>>>>> However, this part of the fix affects not only macosx, but any
>>>>>>>> platform
>>>>>>>> where OGL text
>>>>>>>> shader can be used, so it probably worth to split into a
>>>>>>>> separate fix.
>>>>>>>>
>>>>>>>> Summary:
>>>>>>>> lcd-ogl-3Dlookup:
>>>>>>>> Number of tests: 4
>>>>>>>> Overall average: 42.68027553311743
>>>>>>>> Best spread: 3.49% variance
>>>>>>>> Worst spread: 29.59% variance
>>>>>>>> (Basis for results comparison)
>>>>>>>>
>>>>>>>> lcd-ogl-pow:
>>>>>>>> Number of tests: 4
>>>>>>>> Overall average: 42.468941501367084
>>>>>>>> Best spread: 2.51% variance
>>>>>>>> Worst spread: 29.44% variance
>>>>>>>> Comparison to basis:
>>>>>>>> Best result: 103.28% of basis
>>>>>>>> Worst result: 97.36% of basis
>>>>>>>> Number of wins: 1
>>>>>>>> Number of ties: 2
>>>>>>>> Number of losses: 1
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Andrew
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
From james.graham at oracle.com Thu May 21 19:59:07 2015
From: james.graham at oracle.com (Jim Graham)
Date: Thu, 21 May 2015 12:59:07 -0700
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8061831 [OGL]
"java.lang.InternalError: not implemented yet" during the blit of VI to VI
in xor mode
In-Reply-To: <555DDC00.7050608@oracle.com>
References: <555DDC00.7050608@oracle.com>
Message-ID: <555E390B.9020106@oracle.com>
Please use the same indentation as the surrounding constructions:
62 OGLSurfaceToSwBlit blitSurfaceToIntArgbPre =
NN new OGLSurfaceToSwBlit(SurfaceType.IntArgbPre,
NN OGLSurfaceData.PF_INT_ARGB_PRE);
I'm curious about bufferClip in the converter routine. Does that help?
Since we clip when we blit back to the destination in the last line,
we don't necessarily need to clip the intermediate operation. I suppose
it could save time, but if it is a rect clip then I would think the
entire op would already be trimmed to just the size of the clip. And if
it is a complex clip then there is a tradeoff between operating on the
excluded pixels and how long it takes to create the translated clip and
how much overhead there is in enumerating it inside the performop blit.
Best to leave it for now, but I thought I would float that issue...
Looks good, modulo the indenting issue...
...jim
On 5/21/15 6:22 AM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk9.
> Our blits machinary in case of absent of direct/general blits will use
> the AnyBlit, which uses surface.getRaster method. This method is not
> implemented in OGL surfaces, so we must have some blit, which covers all
> possible combinations of source/destination/composite.
>
> In the fix for JDK-7124347[1] the new OGLAnyCompositeBlit was added, and
> this new blit covers situation, when we cannot call getRaster on
> destination and must read it to the temporary buffer. But it does not
> take into account that the same problem exists for the source. If the
> source surface is OpenGLSurface and xor composite is used we should copy
> it to the temporary buffer also.
>
> In this fix I added some parameters, which configure OGLAnyCompositeBlit
> for the case when some kind of ogl source is passed.
>
>
> [1] https://bugs.openjdk.java.net/browse/JDK-7124347
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8061831
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8061831/webrev
>
From Sergey.Bylokhov at oracle.com Fri May 22 16:59:40 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 22 May 2015 19:59:40 +0300
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8061831 [OGL]
"java.lang.InternalError: not implemented yet" during the blit of VI to VI
in xor mode
In-Reply-To: <555E390B.9020106@oracle.com>
References: <555DDC00.7050608@oracle.com> <555E390B.9020106@oracle.com>
Message-ID: <555F607C.7060707@oracle.com>
On 21.05.15 22:59, Jim Graham wrote:
> I'm curious about bufferClip in the converter routine. Does that
> help? Since we clip when we blit back to the destination in the last
> line, we don't necessarily need to clip the intermediate operation. I
> suppose it could save time, but if it is a rect clip then I would
> think the entire op would already be trimmed to just the size of the
> clip. And if it is a complex clip then there is a tradeoff between
> operating on the excluded pixels and how long it takes to create the
> translated clip and how much overhead there is in enumerating it
> inside the performop blit. Best to leave it for now, but I thought I
> would float that issue...
This clip is useful, because in general we can use some custom/slow
compozite here, and it will be better to minimize it usage.
>
> Looks good, modulo the indenting issue...
>
> ...jim
>
> On 5/21/15 6:22 AM, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for jdk9.
>> Our blits machinary in case of absent of direct/general blits will use
>> the AnyBlit, which uses surface.getRaster method. This method is not
>> implemented in OGL surfaces, so we must have some blit, which covers all
>> possible combinations of source/destination/composite.
>>
>> In the fix for JDK-7124347[1] the new OGLAnyCompositeBlit was added, and
>> this new blit covers situation, when we cannot call getRaster on
>> destination and must read it to the temporary buffer. But it does not
>> take into account that the same problem exists for the source. If the
>> source surface is OpenGLSurface and xor composite is used we should copy
>> it to the temporary buffer also.
>>
>> In this fix I added some parameters, which configure OGLAnyCompositeBlit
>> for the case when some kind of ogl source is passed.
>>
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-7124347
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061831
>> Webrev can be found at: http://cr.openjdk.java.net/~serb/8061831/webrev
>>
--
Best regards, Sergey.
From Sergey.Bylokhov at oracle.com Fri May 22 17:04:11 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 22 May 2015 20:04:11 +0300
Subject: [OpenJDK 2D-Dev] [9] Review Request: JDK-8080953
[TEST_BUG]Test java/awt/FontClass/DebugFonts.java fails due to wrongly
typed bugid
In-Reply-To: <555F606B.3040606@oracle.com>
References: <555F606B.3040606@oracle.com>
Message-ID: <555F618B.7090507@oracle.com>
cc 2d
On 22.05.15 19:59, pooja chopra wrote:
> Hello,
> Please review a fix for issue:
> 8080953 [TEST_BUG]Test java/awt/FontClass/DebugFonts.java fails due to
> wrongly typed bugid
> Test bug fix.
> https://bugs.openjdk.java.net/browse/JDK-8080953
> The webrev is : http://cr.openjdk.java.net/~pchopra/8080953/webrev.00
>
> Thanks,
> Pooja
>
--
Best regards, Sergey.
From alexander.zvegintsev at oracle.com Fri May 22 18:56:42 2015
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Fri, 22 May 2015 21:56:42 +0300
Subject: [OpenJDK 2D-Dev] [9] Review Request: 6587235
Incorrect javadoc: "no parameter" in 2d source code
In-Reply-To: <554D39D9.4040301@oracle.com>
References: <554D0D9F.9010207@oracle.com> <554D13EB.1070504@oracle.com>
<554D39D9.4040301@oracle.com>
Message-ID: <555F7BEA.7050409@oracle.com>
the fix looks good to me too.
--
Thanks,
Alexander.
On 09.05.2015 1:34, Sergey Bylokhov wrote:
> Hi, Phil.
> Thanks for a review! The new version:
> http://cr.openjdk.java.net/~serb/6587235/webrev.01
>
> On 08.05.15 22:52, Phil Race wrote:
>> 273 * RuntimePermission("accessClassInPackage."+pkg)
>> 274 * permission.
>> 275 *
>> 276 * @param pkgname the package name.
>>
>>
>> perhaps line 273 should match ?
>>
>> 7 * @param srcArg The first source tile for the compositing
>> operation.
>> 88 * @param dstIn The second source tile for the compositing
>> operation.
>> 89 * @param dstOut The tile where the result of the operation
>> is stored.
>> 90 */
>> 91 public void compose(Raster srcArg, Raster dstIn,
>> WritableRaster dstOut) {
>>
>> it might be better to rename the actual arguments to match the doc.
>>
>>
>> 47 /**
>> 48 * Construct a new dialog type selection enumeration value
>> with the
>> 49 * given integer value.
>> 50 *
>> 51 * @param frame Integer value.
>> 52 */
>> 53 public DialogOwner(Frame frame) {
>>
>> Huh ? The entire doc seems to be nonsense .. changing the name of the
>> param
>> just makes it worse. The text seems to have been copied from
>> javax.attribute.standard.DialogTypeSelection.java
>>
>>
>> -phil.
>>
>> On 05/08/2015 12:25 PM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review the fix for a typos in jdk9. This CR was filed by me
>>> long time ago and I doubt that someone will take a look at it.
>>> I fixed all clients files in sun.** subpackages.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6587235
>>> Webrev can be found at:
>>> http://cr.openjdk.java.net/~serb/6587235/webrev.00
>>>
>>
>
>
From prasanta.sadhukhan at oracle.com Mon May 25 11:16:38 2015
From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan)
Date: Mon, 25 May 2015 16:46:38 +0530
Subject: [OpenJDK 2D-Dev] RFR [TestBug 8080086]: Test
javax/imageio/plugins/png/ItxtUtf8Test.java fails on Linux with G1 GC
Message-ID: <55630496.4030000@oracle.com>
Hi All,
The test throws OOME in 64bit linux but passes in 32bit linux. It seems
to require more memory for 64bit system so increasing the max heap size
from 2MB to 4MB to execute the test successfully on 64bit linux.
bug: https://bugs.openjdk.java.net/browse/JDK-8080086
webrev: http://cr.openjdk.java.net/~psadhukhan/8080086/webrev.00/
Regards
Prasanta
From Sergey.Bylokhov at oracle.com Mon May 25 12:35:57 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 25 May 2015 15:35:57 +0300
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8080847 Copying of overlapping
memory should be improved in java2d
Message-ID: <5563172D.4080605@oracle.com>
Hello.
Please review the fix forjdk9.
I found this issue during code review of another task, related to
performance.
The sample code below will call the IsomorphicCopy method which call
memcpy on the overlapping memory(this is the simplest example)
BufferedImage img = new BufferedImage(100, 100,
BufferedImage.TYPE_INT_ARGB_PRE);
Graphics2D g = img.createGraphics();
g.setComposite(AlphaComposite.Src);
g.drawImage(img, 0, 0, null);
g.dispose();
http://linux.die.net/man/3/memcpy
"The memcpy() function copies n bytes from memory area src to memory
area dest. The memory areas must not overlap. Use memmove(3) if the
memory areas do overlap"
I can confirm this bug using valgrind and a program above:
command:
valgrind --smc-check=all --tool=memcheck --leak-check=full -v
./9/client/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/java -Xint
Main
output:
==60975== Source and destination overlap in memcpy(0xe1b8b4d8,
0xe1b8b4d8, 400)
==60975== at 0x4C2F71C: memcpy@@GLIBC_2.14 (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==60975== by 0x1E0F504D: AnyIntIsomorphicCopy (in
/moe/workspaces/jdk/9/client-work/build/linux-x86_64-normal-server-fastdebug/images/jdk/lib/amd64/libawt.so)
==60975== by 0x1E0F5DE8: Java_sun_java2d_loops_Blit_Blit (in
/moe/workspaces/jdk/9/client-work/build/linux-x86_64-normal-server-fastdebug/images/jdk/lib/amd64/libawt.so)
Bug: https://bugs.openjdk.java.net/browse/JDK-8080847
Webrev can be found at: http://cr.openjdk.java.net/~serb/8080847/webrev.00
--
Best regards, Sergey.
From Sergey.Bylokhov at oracle.com Mon May 25 15:49:21 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 25 May 2015 18:49:21 +0300
Subject: [OpenJDK 2D-Dev] RFR [TestBug 8080086]: Test
javax/imageio/plugins/png/ItxtUtf8Test.java fails on Linux with G1 GC
In-Reply-To: <55630496.4030000@oracle.com>
References: <55630496.4030000@oracle.com>
Message-ID: <55634481.2050404@oracle.com>
Hi, Prasanta.
Can you confirm that an initial bugs( 6541476 6782079) still can be
reproduced using an updated test on x86 and x64?
On 25.05.15 14:16, prasanta sadhukhan wrote:
> Hi All,
>
> The test throws OOME in 64bit linux but passes in 32bit linux. It
> seems to require more memory for 64bit system so increasing the max
> heap size from 2MB to 4MB to execute the test successfully on 64bit
> linux.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8080086
> webrev: http://cr.openjdk.java.net/~psadhukhan/8080086/webrev.00/
>
> Regards
> Prasanta
--
Best regards, Sergey.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From james.graham at oracle.com Mon May 25 19:16:13 2015
From: james.graham at oracle.com (Jim Graham)
Date: Mon, 25 May 2015 12:16:13 -0700
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8080847 Copying of
overlapping memory should be improved in java2d
In-Reply-To: <5563172D.4080605@oracle.com>
References: <5563172D.4080605@oracle.com>
Message-ID: <556374FD.4020501@oracle.com>
I don't recall if we ever promised that this case would work without
aliasing issues. I know that we went out of our way in the copyArea
method to prevent the aliasing issue, doing the blits piecemeal so that
they don't interfere with each other. Further, while it may be easy
enough to just call memmove to have the libraray do this for us in the
IsoBlit case, other cases that don't fall into the IsoBlit macro will
not be similarly protected. In particular, if you specify an alpha
value, you will not get this protection (at least not without a huge
amount of work to overhaul the entire DrawImage pipeline).
I would say that this would be OK if we planned to make this promise
about drawImage across all image formats and composition modes, but that
would be a far more complicated fix. Until then, we should not open
this can of worms by modifying this one specific Blit case...
...jim
On 5/25/2015 5:35 AM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix forjdk9.
>
> I found this issue during code review of another task, related to
> performance.
>
> The sample code below will call the IsomorphicCopy method which call
> memcpy on the overlapping memory(this is the simplest example)
>
> BufferedImage img = new BufferedImage(100, 100,
> BufferedImage.TYPE_INT_ARGB_PRE);
> Graphics2D g = img.createGraphics();
> g.setComposite(AlphaComposite.Src);
> g.drawImage(img, 0, 0, null);
> g.dispose();
>
> http://linux.die.net/man/3/memcpy
> "The memcpy() function copies n bytes from memory area src to memory
> area dest. The memory areas must not overlap. Use memmove(3) if the
> memory areas do overlap"
>
>
> I can confirm this bug using valgrind and a program above:
> command:
> valgrind --smc-check=all --tool=memcheck --leak-check=full -v
> ./9/client/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/java -Xint
> Main
>
> output:
> ==60975== Source and destination overlap in memcpy(0xe1b8b4d8,
> 0xe1b8b4d8, 400)
> ==60975== at 0x4C2F71C: memcpy@@GLIBC_2.14 (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==60975== by 0x1E0F504D: AnyIntIsomorphicCopy (in
> /moe/workspaces/jdk/9/client-work/build/linux-x86_64-normal-server-fastdebug/images/jdk/lib/amd64/libawt.so)
>
> ==60975== by 0x1E0F5DE8: Java_sun_java2d_loops_Blit_Blit (in
> /moe/workspaces/jdk/9/client-work/build/linux-x86_64-normal-server-fastdebug/images/jdk/lib/amd64/libawt.so)
>
>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8080847
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8080847/webrev.00
>
From Sergey.Bylokhov at oracle.com Mon May 25 19:32:23 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 25 May 2015 22:32:23 +0300
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8080847 Copying of
overlapping memory should be improved in java2d
In-Reply-To: <556374FD.4020501@oracle.com>
References: <5563172D.4080605@oracle.com> <556374FD.4020501@oracle.com>
Message-ID: <556378C7.6090807@oracle.com>
Hi, Jim.
Actually there is a difference in support: it works but result is a
little bit wrong, and it does not work and crashes. This fix is not a
general solution for the incorrect result of the blit+aliasing, but for
the possible crash of memcpy especially after some improvements like in
glibc. I think this still an issue.
> I don't recall if we ever promised that this case would work without
> aliasing issues. I know that we went out of our way in the copyArea
> method to prevent the aliasing issue, doing the blits piecemeal so
> that they don't interfere with each other. Further, while it may be
> easy enough to just call memmove to have the libraray do this for us
> in the IsoBlit case, other cases that don't fall into the IsoBlit
> macro will not be similarly protected. In particular, if you specify
> an alpha value, you will not get this protection (at least not without
> a huge amount of work to overhaul the entire DrawImage pipeline).
>
> I would say that this would be OK if we planned to make this promise
> about drawImage across all image formats and composition modes, but
> that would be a far more complicated fix. Until then, we should not
> open this can of worms by modifying this one specific Blit case...
>
> ...jim
>
> On 5/25/2015 5:35 AM, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix forjdk9.
>>
>> I found this issue during code review of another task, related to
>> performance.
>>
>> The sample code below will call the IsomorphicCopy method which call
>> memcpy on the overlapping memory(this is the simplest example)
>>
>> BufferedImage img = new BufferedImage(100, 100,
>> BufferedImage.TYPE_INT_ARGB_PRE);
>> Graphics2D g = img.createGraphics();
>> g.setComposite(AlphaComposite.Src);
>> g.drawImage(img, 0, 0, null);
>> g.dispose();
>>
>> http://linux.die.net/man/3/memcpy
>> "The memcpy() function copies n bytes from memory area src to memory
>> area dest. The memory areas must not overlap. Use memmove(3) if the
>> memory areas do overlap"
>>
>>
>> I can confirm this bug using valgrind and a program above:
>> command:
>> valgrind --smc-check=all --tool=memcheck --leak-check=full -v
>> ./9/client/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/java
>> -Xint
>> Main
>>
>> output:
>> ==60975== Source and destination overlap in memcpy(0xe1b8b4d8,
>> 0xe1b8b4d8, 400)
>> ==60975== at 0x4C2F71C: memcpy@@GLIBC_2.14 (in
>> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
>> ==60975== by 0x1E0F504D: AnyIntIsomorphicCopy (in
>> /moe/workspaces/jdk/9/client-work/build/linux-x86_64-normal-server-fastdebug/images/jdk/lib/amd64/libawt.so)
>>
>>
>> ==60975== by 0x1E0F5DE8: Java_sun_java2d_loops_Blit_Blit (in
>> /moe/workspaces/jdk/9/client-work/build/linux-x86_64-normal-server-fastdebug/images/jdk/lib/amd64/libawt.so)
>>
>>
>>
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8080847
>> Webrev can be found at:
>> http://cr.openjdk.java.net/~serb/8080847/webrev.00
>>
--
Best regards, Sergey.
From prasanta.sadhukhan at oracle.com Tue May 26 06:12:46 2015
From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan)
Date: Tue, 26 May 2015 11:42:46 +0530
Subject: [OpenJDK 2D-Dev] RFR [TestBug 8080086]: Test
javax/imageio/plugins/png/ItxtUtf8Test.java fails on Linux with G1 GC
In-Reply-To: <55634481.2050404@oracle.com>
References: <55630496.4030000@oracle.com> <55634481.2050404@oracle.com>
Message-ID: <55640EDD.9080407@oracle.com>
Hi Sergey,
Yes, the original bugs can still be reproduced with jdk1.6 with updated
test.
Regards
Prasanta
On 5/25/2015 9:19 PM, Sergey Bylokhov wrote:
> Hi, Prasanta.
> Can you confirm that an initial bugs( 6541476 6782079) still can be
> reproduced using an updated test on x86 and x64?
>
> On 25.05.15 14:16, prasanta sadhukhan wrote:
>> Hi All,
>>
>> The test throws OOME in 64bit linux but passes in 32bit linux. It
>> seems to require more memory for 64bit system so increasing the max
>> heap size from 2MB to 4MB to execute the test successfully on 64bit
>> linux.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8080086
>> webrev: http://cr.openjdk.java.net/~psadhukhan/8080086/webrev.00/
>>
>> Regards
>> Prasanta
>
>
> --
> Best regards, Sergey.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From Sergey.Bylokhov at oracle.com Tue May 26 10:24:09 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 26 May 2015 13:24:09 +0300
Subject: [OpenJDK 2D-Dev] RFR [TestBug 8080086]: Test
javax/imageio/plugins/png/ItxtUtf8Test.java fails on Linux with G1 GC
In-Reply-To: <55640EDD.9080407@oracle.com>
References: <55630496.4030000@oracle.com> <55634481.2050404@oracle.com>
<55640EDD.9080407@oracle.com>
Message-ID: <556449C9.40602@oracle.com>
Thanks for clarification!
The fix looks fine.
On 26.05.15 9:12, prasanta sadhukhan wrote:
> Hi Sergey,
>
> Yes, the original bugs can still be reproduced with jdk1.6 with
> updated test.
>
> Regards
> Prasanta
> On 5/25/2015 9:19 PM, Sergey Bylokhov wrote:
>> Hi, Prasanta.
>> Can you confirm that an initial bugs( 6541476 6782079) still can be
>> reproduced using an updated test on x86 and x64?
>>
>> On 25.05.15 14:16, prasanta sadhukhan wrote:
>>> Hi All,
>>>
>>> The test throws OOME in 64bit linux but passes in 32bit linux. It
>>> seems to require more memory for 64bit system so increasing the max
>>> heap size from 2MB to 4MB to execute the test successfully on 64bit
>>> linux.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8080086
>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8080086/webrev.00/
>>>
>>> Regards
>>> Prasanta
>>
>>
>> --
>> Best regards, Sergey.
>
--
Best regards, Sergey.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From james.graham at oracle.com Tue May 26 10:43:19 2015
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 26 May 2015 03:43:19 -0700
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8080847 Copying of
overlapping memory should be improved in java2d
In-Reply-To: <556378C7.6090807@oracle.com>
References: <5563172D.4080605@oracle.com> <556374FD.4020501@oracle.com>
<556378C7.6090807@oracle.com>
Message-ID: <55644E47.4040008@oracle.com>
What crash in memcpy? The issue you pointed to is about dealing with
overlapping memory. memcpy does not crash on overlapping memory copies,
it just duplicates data oddly in a way that most uses probably don't want.
Also, the fix you gave only fixed the problem for the horizontal
direction, if the drawImage call were directed at 0,1 then we'd still
get all scan lines duplicated from the first...
...jim
On 5/25/2015 12:32 PM, Sergey Bylokhov wrote:
> Hi, Jim.
> Actually there is a difference in support: it works but result is a
> little bit wrong, and it does not work and crashes. This fix is not a
> general solution for the incorrect result of the blit+aliasing, but for
> the possible crash of memcpy especially after some improvements like in
> glibc. I think this still an issue.
>
>> I don't recall if we ever promised that this case would work without
>> aliasing issues. I know that we went out of our way in the copyArea
>> method to prevent the aliasing issue, doing the blits piecemeal so
>> that they don't interfere with each other. Further, while it may be
>> easy enough to just call memmove to have the libraray do this for us
>> in the IsoBlit case, other cases that don't fall into the IsoBlit
>> macro will not be similarly protected. In particular, if you specify
>> an alpha value, you will not get this protection (at least not without
>> a huge amount of work to overhaul the entire DrawImage pipeline).
>>
>> I would say that this would be OK if we planned to make this promise
>> about drawImage across all image formats and composition modes, but
>> that would be a far more complicated fix. Until then, we should not
>> open this can of worms by modifying this one specific Blit case...
>>
>> ...jim
>>
>> On 5/25/2015 5:35 AM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review the fix forjdk9.
>>>
>>> I found this issue during code review of another task, related to
>>> performance.
>>>
>>> The sample code below will call the IsomorphicCopy method which call
>>> memcpy on the overlapping memory(this is the simplest example)
>>>
>>> BufferedImage img = new BufferedImage(100, 100,
>>> BufferedImage.TYPE_INT_ARGB_PRE);
>>> Graphics2D g = img.createGraphics();
>>> g.setComposite(AlphaComposite.Src);
>>> g.drawImage(img, 0, 0, null);
>>> g.dispose();
>>>
>>> http://linux.die.net/man/3/memcpy
>>> "The memcpy() function copies n bytes from memory area src to memory
>>> area dest. The memory areas must not overlap. Use memmove(3) if the
>>> memory areas do overlap"
>>>
>>>
>>> I can confirm this bug using valgrind and a program above:
>>> command:
>>> valgrind --smc-check=all --tool=memcheck --leak-check=full -v
>>> ./9/client/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/java
>>> -Xint
>>> Main
>>>
>>> output:
>>> ==60975== Source and destination overlap in memcpy(0xe1b8b4d8,
>>> 0xe1b8b4d8, 400)
>>> ==60975== at 0x4C2F71C: memcpy@@GLIBC_2.14 (in
>>> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
>>> ==60975== by 0x1E0F504D: AnyIntIsomorphicCopy (in
>>> /moe/workspaces/jdk/9/client-work/build/linux-x86_64-normal-server-fastdebug/images/jdk/lib/amd64/libawt.so)
>>>
>>>
>>> ==60975== by 0x1E0F5DE8: Java_sun_java2d_loops_Blit_Blit (in
>>> /moe/workspaces/jdk/9/client-work/build/linux-x86_64-normal-server-fastdebug/images/jdk/lib/amd64/libawt.so)
>>>
>>>
>>>
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8080847
>>> Webrev can be found at:
>>> http://cr.openjdk.java.net/~serb/8080847/webrev.00
>>>
>
>
From Sergey.Bylokhov at oracle.com Tue May 26 11:34:30 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 26 May 2015 14:34:30 +0300
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8080847 Copying of
overlapping memory should be improved in java2d
In-Reply-To: <55644E47.4040008@oracle.com>
References: <5563172D.4080605@oracle.com> <556374FD.4020501@oracle.com>
<556378C7.6090807@oracle.com> <55644E47.4040008@oracle.com>
Message-ID: <55645A46.70506@oracle.com>
On 26.05.15 13:43, Jim Graham wrote:
> What crash in memcpy?
Simply because behavior of this function is undefined if the two arrays
"to" and "from" overlap. Plus this clears an output for the tools like
valgrind and some other issues can be found easily.
> The issue you pointed to is about dealing with overlapping memory.
> memcpy does not crash on overlapping memory copies, it just duplicates
> data oddly in a way that most uses probably don't want.
>
> Also, the fix you gave only fixed the problem for the horizontal
> direction, if the drawImage call were directed at 0,1 then we'd still
> get all scan lines duplicated from the first...
Right, I can take a look to this bug too.
>
> ...jim
>
> On 5/25/2015 12:32 PM, Sergey Bylokhov wrote:
>> Hi, Jim.
>> Actually there is a difference in support: it works but result is a
>> little bit wrong, and it does not work and crashes. This fix is not a
>> general solution for the incorrect result of the blit+aliasing, but for
>> the possible crash of memcpy especially after some improvements like in
>> glibc. I think this still an issue.
>>
>>> I don't recall if we ever promised that this case would work without
>>> aliasing issues. I know that we went out of our way in the copyArea
>>> method to prevent the aliasing issue, doing the blits piecemeal so
>>> that they don't interfere with each other. Further, while it may be
>>> easy enough to just call memmove to have the libraray do this for us
>>> in the IsoBlit case, other cases that don't fall into the IsoBlit
>>> macro will not be similarly protected. In particular, if you specify
>>> an alpha value, you will not get this protection (at least not without
>>> a huge amount of work to overhaul the entire DrawImage pipeline).
>>>
>>> I would say that this would be OK if we planned to make this promise
>>> about drawImage across all image formats and composition modes, but
>>> that would be a far more complicated fix. Until then, we should not
>>> open this can of worms by modifying this one specific Blit case...
>>>
>>> ...jim
>>>
>>> On 5/25/2015 5:35 AM, Sergey Bylokhov wrote:
>>>> Hello.
>>>> Please review the fix forjdk9.
>>>>
>>>> I found this issue during code review of another task, related to
>>>> performance.
>>>>
>>>> The sample code below will call the IsomorphicCopy method which call
>>>> memcpy on the overlapping memory(this is the simplest example)
>>>>
>>>> BufferedImage img = new BufferedImage(100, 100,
>>>> BufferedImage.TYPE_INT_ARGB_PRE);
>>>> Graphics2D g = img.createGraphics();
>>>> g.setComposite(AlphaComposite.Src);
>>>> g.drawImage(img, 0, 0, null);
>>>> g.dispose();
>>>>
>>>> http://linux.die.net/man/3/memcpy
>>>> "The memcpy() function copies n bytes from memory area src to memory
>>>> area dest. The memory areas must not overlap. Use memmove(3) if the
>>>> memory areas do overlap"
>>>>
>>>>
>>>> I can confirm this bug using valgrind and a program above:
>>>> command:
>>>> valgrind --smc-check=all --tool=memcheck --leak-check=full -v
>>>> ./9/client/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/java
>>>>
>>>> -Xint
>>>> Main
>>>>
>>>> output:
>>>> ==60975== Source and destination overlap in memcpy(0xe1b8b4d8,
>>>> 0xe1b8b4d8, 400)
>>>> ==60975== at 0x4C2F71C: memcpy@@GLIBC_2.14 (in
>>>> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
>>>> ==60975== by 0x1E0F504D: AnyIntIsomorphicCopy (in
>>>> /moe/workspaces/jdk/9/client-work/build/linux-x86_64-normal-server-fastdebug/images/jdk/lib/amd64/libawt.so)
>>>>
>>>>
>>>>
>>>> ==60975== by 0x1E0F5DE8: Java_sun_java2d_loops_Blit_Blit (in
>>>> /moe/workspaces/jdk/9/client-work/build/linux-x86_64-normal-server-fastdebug/images/jdk/lib/amd64/libawt.so)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8080847
>>>> Webrev can be found at:
>>>> http://cr.openjdk.java.net/~serb/8080847/webrev.00
>>>>
>>
>>
--
Best regards, Sergey.
From vadim.pakhnushev at oracle.com Tue May 26 13:09:36 2015
From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev)
Date: Tue, 26 May 2015 16:09:36 +0300
Subject: [OpenJDK 2D-Dev] RFR: JDK-8079652: Could not enable D3D pipeline
In-Reply-To: <55532C04.8000406@oracle.com>
References: <554C98E8.8090006@oracle.com> <554CB69E.9070402@oracle.com> <554CB7D6.4090804@oracle.com> <554CB9FC.2020404@oracle.com>
<554D0297.3060501@oracle.com> <55532C04.8000406@oracle.com>
Message-ID: <55647090.7050505@oracle.com>
Could somebody take a look?
On 13.05.2015 13:48, Vadim Pakhnushev wrote:
> Actually I've found a better solution - specify WS_POPUP window style.
> In this case the client area size will be exactly as specified instead
> of adjusting for some default window style.
> So please review the second iteration:
>
> diff --git
> a/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
> b/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>
> ---
> a/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
> +++
> b/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
> @@ -828,7 +828,7 @@
> return 0;
> }
>
> - HWND hWnd = CreateWindow(L"D3DFocusWindow", L"D3DFocusWindow", 0,
> + HWND hWnd = CreateWindow(L"D3DFocusWindow", L"D3DFocusWindow",
> WS_POPUP,
> mi.rcMonitor.left, mi.rcMonitor.top, 1, 1,
> NULL, NULL, GetModuleHandle(NULL), NULL);
> if (hWnd == 0) {
>
> Thanks,
> Vadim
>
> On 08.05.2015 21:38, Phil Race wrote:
>> I guess this is OK since 100x100 ought to be always big enough but
>> not too big ..
>> I suppose it may imply a different default window style is being
>> added by CreateWindow
>> than we got before.
>>
>> -phil.
>>
>>
>>
>> On 5/8/2015 6:28 AM, Sergey Bylokhov wrote:
>>> Hi, Vadim.
>>> Thanks for clarification, please add this information as a comment
>>> to the code, before the push.
>>>
>>> On 08.05.15 16:19, Vadim Pakhnushev wrote:
>>>> It's invisible and used only for getting application focus
>>>> notifications internally by Direct3D.
>>>>
>>>> On 08.05.2015 16:14, Sergey Bylokhov wrote:
>>>>> Hi, Vadim.
>>>>> Why we do not use the full screen size for this window?
>>>>>
>>>>> On 08.05.15 14:07, Vadim Pakhnushev wrote:
>>>>>> Hi,
>>>>>> Please review the fix for
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8079652
>>>>>> Focus window's client area should be bigger otherwise
>>>>>> CreateDevice fails.
>>>>>>
>>>>>> diff --git
>>>>>> a/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>>>>>> b/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>>>>>>
>>>>>> ---
>>>>>> a/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>>>>>> +++
>>>>>> b/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>>>>>> @@ -829,7 +829,7 @@
>>>>>> }
>>>>>>
>>>>>> HWND hWnd = CreateWindow(L"D3DFocusWindow",
>>>>>> L"D3DFocusWindow", 0,
>>>>>> - mi.rcMonitor.left, mi.rcMonitor.top, 1, 1,
>>>>>> + mi.rcMonitor.left, mi.rcMonitor.top, 100, 100,
>>>>>> NULL, NULL, GetModuleHandle(NULL), NULL);
>>>>>> if (hWnd == 0) {
>>>>>> J2dRlsTraceLn(J2D_TRACE_ERROR,
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
From Sergey.Bylokhov at oracle.com Tue May 26 13:11:33 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 26 May 2015 16:11:33 +0300
Subject: [OpenJDK 2D-Dev] RFR: JDK-8079652: Could not enable D3D pipeline
In-Reply-To: <55647090.7050505@oracle.com>
References: <554C98E8.8090006@oracle.com> <554CB69E.9070402@oracle.com> <554CB7D6.4090804@oracle.com> <554CB9FC.2020404@oracle.com>
<554D0297.3060501@oracle.com> <55532C04.8000406@oracle.com>
<55647090.7050505@oracle.com>
Message-ID: <55647105.7080904@oracle.com>
Hi, Vadim.
The fix looks fine to me.
On 26.05.15 16:09, Vadim Pakhnushev wrote:
> Could somebody take a look?
>
> On 13.05.2015 13:48, Vadim Pakhnushev wrote:
>> Actually I've found a better solution - specify WS_POPUP window style.
>> In this case the client area size will be exactly as specified
>> instead of adjusting for some default window style.
>> So please review the second iteration:
>>
>> diff --git
>> a/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>> b/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>>
>> ---
>> a/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>> +++
>> b/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>> @@ -828,7 +828,7 @@
>> return 0;
>> }
>>
>> - HWND hWnd = CreateWindow(L"D3DFocusWindow", L"D3DFocusWindow", 0,
>> + HWND hWnd = CreateWindow(L"D3DFocusWindow", L"D3DFocusWindow",
>> WS_POPUP,
>> mi.rcMonitor.left, mi.rcMonitor.top, 1, 1,
>> NULL, NULL, GetModuleHandle(NULL), NULL);
>> if (hWnd == 0) {
>>
>> Thanks,
>> Vadim
>>
>> On 08.05.2015 21:38, Phil Race wrote:
>>> I guess this is OK since 100x100 ought to be always big enough but
>>> not too big ..
>>> I suppose it may imply a different default window style is being
>>> added by CreateWindow
>>> than we got before.
>>>
>>> -phil.
>>>
>>>
>>>
>>> On 5/8/2015 6:28 AM, Sergey Bylokhov wrote:
>>>> Hi, Vadim.
>>>> Thanks for clarification, please add this information as a comment
>>>> to the code, before the push.
>>>>
>>>> On 08.05.15 16:19, Vadim Pakhnushev wrote:
>>>>> It's invisible and used only for getting application focus
>>>>> notifications internally by Direct3D.
>>>>>
>>>>> On 08.05.2015 16:14, Sergey Bylokhov wrote:
>>>>>> Hi, Vadim.
>>>>>> Why we do not use the full screen size for this window?
>>>>>>
>>>>>> On 08.05.15 14:07, Vadim Pakhnushev wrote:
>>>>>>> Hi,
>>>>>>> Please review the fix for
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8079652
>>>>>>> Focus window's client area should be bigger otherwise
>>>>>>> CreateDevice fails.
>>>>>>>
>>>>>>> diff --git
>>>>>>> a/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>>>>>>> b/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>>>>>>>
>>>>>>> ---
>>>>>>> a/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>>>>>>> +++
>>>>>>> b/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>>>>>>> @@ -829,7 +829,7 @@
>>>>>>> }
>>>>>>>
>>>>>>> HWND hWnd = CreateWindow(L"D3DFocusWindow",
>>>>>>> L"D3DFocusWindow", 0,
>>>>>>> - mi.rcMonitor.left, mi.rcMonitor.top, 1, 1,
>>>>>>> + mi.rcMonitor.left, mi.rcMonitor.top, 100, 100,
>>>>>>> NULL, NULL, GetModuleHandle(NULL), NULL);
>>>>>>> if (hWnd == 0) {
>>>>>>> J2dRlsTraceLn(J2D_TRACE_ERROR,
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
--
Best regards, Sergey.
From james.graham at oracle.com Tue May 26 18:27:14 2015
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 26 May 2015 11:27:14 -0700
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8080847 Copying of
overlapping memory should be improved in java2d
In-Reply-To: <55645A46.70506@oracle.com>
References: <5563172D.4080605@oracle.com>
<556374FD.4020501@oracle.com> <556378C7.6090807@oracle.com>
<55644E47.4040008@oracle.com> <55645A46.70506@oracle.com>
Message-ID: <5564BB02.40703@oracle.com>
Undefined doesn't mean "may crash" in this case, it means that the
contents of memory may not match what you would expect if the regions
overlap because it is just a dump copy loop that does not do any
aliasing checks.
Is there a way to silence the warning? In this particular case we are
totally OK with the undefined behavior, in fact, the accidental behavior
that they are calling "undefined" because it is confusing to most
developers who don't know enough to worry about aliased memory regions -
is actually the behavior we want because it will match the results of
all of the other blits.
If there is no way to silence the tool, then I'd recommend hard-coding
our own "dumb copy loop" instead so that the behavior continues to match
what memcpy should have been doing.
Do not just fix this in the vertical direction as well - if you continue
on a path that makes the aliasing not happen then I will insist that you
modify all drawimage paths to all deal gracefully with memory aliasing
and write an extensive test suite to make sure that we correctly manage
the aliasing in all cases, all composite modes, the bg versions as well
as the non-bg versions, scaled and transformed blits, etc. If you are
not prepared to do all of that, then we should drop this attempt to fix
a "bug" that is really code working as (un)expected and focus instead on
silencing the warning...
...jim
On 5/26/2015 4:34 AM, Sergey Bylokhov wrote:
> On 26.05.15 13:43, Jim Graham wrote:
>> What crash in memcpy?
> Simply because behavior of this function is undefined if the two arrays
> "to" and "from" overlap. Plus this clears an output for the tools like
> valgrind and some other issues can be found easily.
>
>> The issue you pointed to is about dealing with overlapping memory.
>> memcpy does not crash on overlapping memory copies, it just duplicates
>> data oddly in a way that most uses probably don't want.
>>
>> Also, the fix you gave only fixed the problem for the horizontal
>> direction, if the drawImage call were directed at 0,1 then we'd still
>> get all scan lines duplicated from the first...
> Right, I can take a look to this bug too.
>>
>> ...jim
>>
>> On 5/25/2015 12:32 PM, Sergey Bylokhov wrote:
>>> Hi, Jim.
>>> Actually there is a difference in support: it works but result is a
>>> little bit wrong, and it does not work and crashes. This fix is not a
>>> general solution for the incorrect result of the blit+aliasing, but for
>>> the possible crash of memcpy especially after some improvements like in
>>> glibc. I think this still an issue.
>>>
>>>> I don't recall if we ever promised that this case would work without
>>>> aliasing issues. I know that we went out of our way in the copyArea
>>>> method to prevent the aliasing issue, doing the blits piecemeal so
>>>> that they don't interfere with each other. Further, while it may be
>>>> easy enough to just call memmove to have the libraray do this for us
>>>> in the IsoBlit case, other cases that don't fall into the IsoBlit
>>>> macro will not be similarly protected. In particular, if you specify
>>>> an alpha value, you will not get this protection (at least not without
>>>> a huge amount of work to overhaul the entire DrawImage pipeline).
>>>>
>>>> I would say that this would be OK if we planned to make this promise
>>>> about drawImage across all image formats and composition modes, but
>>>> that would be a far more complicated fix. Until then, we should not
>>>> open this can of worms by modifying this one specific Blit case...
>>>>
>>>> ...jim
>>>>
>>>> On 5/25/2015 5:35 AM, Sergey Bylokhov wrote:
>>>>> Hello.
>>>>> Please review the fix forjdk9.
>>>>>
>>>>> I found this issue during code review of another task, related to
>>>>> performance.
>>>>>
>>>>> The sample code below will call the IsomorphicCopy method which call
>>>>> memcpy on the overlapping memory(this is the simplest example)
>>>>>
>>>>> BufferedImage img = new BufferedImage(100, 100,
>>>>> BufferedImage.TYPE_INT_ARGB_PRE);
>>>>> Graphics2D g = img.createGraphics();
>>>>> g.setComposite(AlphaComposite.Src);
>>>>> g.drawImage(img, 0, 0, null);
>>>>> g.dispose();
>>>>>
>>>>> http://linux.die.net/man/3/memcpy
>>>>> "The memcpy() function copies n bytes from memory area src to memory
>>>>> area dest. The memory areas must not overlap. Use memmove(3) if the
>>>>> memory areas do overlap"
>>>>>
>>>>>
>>>>> I can confirm this bug using valgrind and a program above:
>>>>> command:
>>>>> valgrind --smc-check=all --tool=memcheck --leak-check=full -v
>>>>> ./9/client/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/java
>>>>>
>>>>> -Xint
>>>>> Main
>>>>>
>>>>> output:
>>>>> ==60975== Source and destination overlap in memcpy(0xe1b8b4d8,
>>>>> 0xe1b8b4d8, 400)
>>>>> ==60975== at 0x4C2F71C: memcpy@@GLIBC_2.14 (in
>>>>> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
>>>>> ==60975== by 0x1E0F504D: AnyIntIsomorphicCopy (in
>>>>> /moe/workspaces/jdk/9/client-work/build/linux-x86_64-normal-server-fastdebug/images/jdk/lib/amd64/libawt.so)
>>>>>
>>>>>
>>>>>
>>>>> ==60975== by 0x1E0F5DE8: Java_sun_java2d_loops_Blit_Blit (in
>>>>> /moe/workspaces/jdk/9/client-work/build/linux-x86_64-normal-server-fastdebug/images/jdk/lib/amd64/libawt.so)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8080847
>>>>> Webrev can be found at:
>>>>> http://cr.openjdk.java.net/~serb/8080847/webrev.00
>>>>>
>>>
>>>
>
>
From philip.race at oracle.com Tue May 26 19:22:54 2015
From: philip.race at oracle.com (Phil Race)
Date: Tue, 26 May 2015 12:22:54 -0700
Subject: [OpenJDK 2D-Dev] RFR: JDK-8079652: Could not enable D3D pipeline
In-Reply-To: <55647105.7080904@oracle.com>
References: <554C98E8.8090006@oracle.com> <554CB69E.9070402@oracle.com> <554CB7D6.4090804@oracle.com> <554CB9FC.2020404@oracle.com>
<554D0297.3060501@oracle.com> <55532C04.8000406@oracle.com>
<55647090.7050505@oracle.com> <55647105.7080904@oracle.com>
Message-ID: <5564C80E.1060909@oracle.com>
I am OK with this too.
-phil.
On 05/26/2015 06:11 AM, Sergey Bylokhov wrote:
> Hi, Vadim.
> The fix looks fine to me.
>
> On 26.05.15 16:09, Vadim Pakhnushev wrote:
>> Could somebody take a look?
>>
>> On 13.05.2015 13:48, Vadim Pakhnushev wrote:
>>> Actually I've found a better solution - specify WS_POPUP window style.
>>> In this case the client area size will be exactly as specified
>>> instead of adjusting for some default window style.
>>> So please review the second iteration:
>>>
>>> diff --git
>>> a/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>>> b/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>>>
>>> ---
>>> a/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>>> +++
>>> b/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>>> @@ -828,7 +828,7 @@
>>> return 0;
>>> }
>>>
>>> - HWND hWnd = CreateWindow(L"D3DFocusWindow", L"D3DFocusWindow", 0,
>>> + HWND hWnd = CreateWindow(L"D3DFocusWindow", L"D3DFocusWindow",
>>> WS_POPUP,
>>> mi.rcMonitor.left, mi.rcMonitor.top, 1, 1,
>>> NULL, NULL, GetModuleHandle(NULL), NULL);
>>> if (hWnd == 0) {
>>>
>>> Thanks,
>>> Vadim
>>>
>>> On 08.05.2015 21:38, Phil Race wrote:
>>>> I guess this is OK since 100x100 ought to be always big enough but
>>>> not too big ..
>>>> I suppose it may imply a different default window style is being
>>>> added by CreateWindow
>>>> than we got before.
>>>>
>>>> -phil.
>>>>
>>>>
>>>>
>>>> On 5/8/2015 6:28 AM, Sergey Bylokhov wrote:
>>>>> Hi, Vadim.
>>>>> Thanks for clarification, please add this information as a comment
>>>>> to the code, before the push.
>>>>>
>>>>> On 08.05.15 16:19, Vadim Pakhnushev wrote:
>>>>>> It's invisible and used only for getting application focus
>>>>>> notifications internally by Direct3D.
>>>>>>
>>>>>> On 08.05.2015 16:14, Sergey Bylokhov wrote:
>>>>>>> Hi, Vadim.
>>>>>>> Why we do not use the full screen size for this window?
>>>>>>>
>>>>>>> On 08.05.15 14:07, Vadim Pakhnushev wrote:
>>>>>>>> Hi,
>>>>>>>> Please review the fix for
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8079652
>>>>>>>> Focus window's client area should be bigger otherwise
>>>>>>>> CreateDevice fails.
>>>>>>>>
>>>>>>>> diff --git
>>>>>>>> a/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>>>>>>>> b/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>>>>>>>>
>>>>>>>> ---
>>>>>>>> a/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>>>>>>>> +++
>>>>>>>> b/src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
>>>>>>>> @@ -829,7 +829,7 @@
>>>>>>>> }
>>>>>>>>
>>>>>>>> HWND hWnd = CreateWindow(L"D3DFocusWindow",
>>>>>>>> L"D3DFocusWindow", 0,
>>>>>>>> - mi.rcMonitor.left, mi.rcMonitor.top, 1, 1,
>>>>>>>> + mi.rcMonitor.left, mi.rcMonitor.top, 100, 100,
>>>>>>>> NULL, NULL, GetModuleHandle(NULL), NULL);
>>>>>>>> if (hWnd == 0) {
>>>>>>>> J2dRlsTraceLn(J2D_TRACE_ERROR,
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
>
From linuxhippy at gmail.com Tue May 26 19:58:50 2015
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Tue, 26 May 2015 21:58:50 +0200
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8080847 Copying of
overlapping memory should be improved in java2d
In-Reply-To: <5564BB02.40703@oracle.com>
References: <5563172D.4080605@oracle.com> <556374FD.4020501@oracle.com>
<556378C7.6090807@oracle.com> <55644E47.4040008@oracle.com>
<55645A46.70506@oracle.com> <5564BB02.40703@oracle.com>
Message-ID:
Hi Jim,
> If there is no way to silence the tool, then I'd recommend hard-coding our
> own "dumb copy loop" instead so that the behavior continues to match what
> memcpy should have been doing.
Isn't performance/throughput a concern for this case?
Mamcpy is usually highly tuned with hand-optimized SIMD assembly, most
likely reverting to a simply loop will not produce nearly as good
code.
Br, Clemens
From james.graham at oracle.com Tue May 26 22:49:09 2015
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 26 May 2015 15:49:09 -0700
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8080847 Copying of
overlapping memory should be improved in java2d
In-Reply-To:
References: <5563172D.4080605@oracle.com>
<556374FD.4020501@oracle.com> <556378C7.6090807@oracle.com>
<55644E47.4040008@oracle.com> <55645A46.70506@oracle.com>
<5564BB02.40703@oracle.com>
Message-ID: <5564F865.2010906@oracle.com>
Compilers have also gotten really really good at recognizing memory copy
loops and applying the same optimizations automatically depending on the
optimization level.
I'd really prefer to just leave this code alone and maybe find a way to
tag the line to silence the warnings from the tool. If we must replace
the code, we would need to do performance benchmarks in any case...
...jim
On 5/26/2015 12:58 PM, Clemens Eisserer wrote:
> Hi Jim,
>
>> If there is no way to silence the tool, then I'd recommend hard-coding our
>> own "dumb copy loop" instead so that the behavior continues to match what
>> memcpy should have been doing.
>
> Isn't performance/throughput a concern for this case?
> Mamcpy is usually highly tuned with hand-optimized SIMD assembly, most
> likely reverting to a simply loop will not produce nearly as good
> code.
>
> Br, Clemens
>
From torgeir.veimo at gmail.com Wed May 27 05:21:56 2015
From: torgeir.veimo at gmail.com (Torgeir Veimo)
Date: Wed, 27 May 2015 15:21:56 +1000
Subject: [OpenJDK 2D-Dev] Fwd: [9] Review request for 8023794: [macosx] LCD
Rendering hints seems not working without FRACTIONALMETRICS=ON
In-Reply-To:
References:
<53BD5E45.4000805@oracle.com>
<9A5D5D1C-F58F-4DFC-B327-9A9DB18B155E@gmail.com>
<54297B00.5020604@oracle.com>
<6B49FF00-8A8F-41DF-A574-B9537C1A2B94@gmail.com>
<5437EE69.3090606@oracle.com> <54380F42.7060705@oracle.com>
<54381FFC.5000507@oracle.com> <5438465D.5070503@oracle.com>
<54384C03.5020006@oracle.com> <543ADF1B.9020802@oracle.com>
<543BC85F.8050202@oracle.com> <543C62AC.2010907@oracle.com>
<544A92CC.10406@oracle.com> <544AB09D.5060805@oracle.com>
<548B21D2.8080701@oracle.com> <5512CB71.30908@oracle.com>
<5512EF51.7070907@plausible.coop> <5514029A.1090101@oracle.com>
<55156E31.7080803@oracle.com> <553952F2.9040007@oracle.com>
<553A7046.3000008@oracle.com> <55422C52.8010906@oracle.com>
<555A4956.5060607@oracle.com> <555DEA4D.2010903@oracle.com>
Message-ID:
This looks extremely promising;
https://bugzilla-attachments-216655.netbeans.org/bugzilla/attachment.cgi?id=153888
I'd say don't let perfect be the enemy of the good, please get this
out into a jdk9 release and let the community provide more feedback.
On 22 May 2015 at 00:23, Andrew Brygin wrote:
> Hello Phil,
>
> I have changed the default reverse gamma to 180:
>
> http://cr.openjdk.java.net/~bae/8023794/9/webrev.10/
>
> I also did some experiments with the lcd contrast, and found that
> value 160 decreases the discrepancy a bit: 21 instead of 29 with
> the default lcd contrast value (140).
> However, there still is the discrepancy, and at the moment I do not
> see how we can avoid it completely with our rendering model.
> It looks like that there is something more sophisticated than
> just gamma correction, and we are unable to derive 'color independent'
> glyphs from black-on-white glyphs provided by the native system.
>
> I have also played with changing display profiles but it seems to
> have no detectable effect.
>
> Thanks,
> Andrew
>
>
> On 5/18/2015 11:19 PM, Phil Race wrote:
>>
>> Hi,
>>
>> So 1.79 is essentially 1.8 which is what Mac historically used as gamma.
>> So I'd pick 180 instead of 179
>> Since that value minimises the discrepancy it's looking positive but
>> there's still a discrepancy.
>> Before we 'live with it', I'd be interested to know what happens if you
>> set your display's profile to a generic RGB one.
>>
>> How do the glyph shapes (if you try your best to ignore the colour) match
>> what other apps produce ?
>>
>> -phil.
>>
>>
>> On 04/30/2015 06:21 AM, Andrew Brygin wrote:
>>>
>>> Hello Phil,
>>>
>>> please take a look to updated version of the fix:
>>>
>>> http://cr.openjdk.java.net/~bae/8023794/9/webrev.09/
>>>
>>> The main difference is in glyph generation. I have implemented 'reverse
>>> gamma correction'
>>> approach instead of 'glyph blending'. By default we use gamma value
>>> which provides minimum
>>> of discrepancy with gyph images produced by Apple's jdk. However, it can
>>> be adjusted via
>>> environment variable J2D_LCD_REVERSE_GAMMA (CGGlyphImages.m, lines 198 -
>>> 220).
>>>
>>> Following chart illustrates dependency between the 'reverse gamma' and a
>>> difference
>>> in pixel values comparing to jdk6 from Apple:
>>> http://cr.openjdk.java.net/~bae/8023794/best_reverse_gamma.png
>>>
>>> Following set of images has been used for the comparison:
>>> http://cr.openjdk.java.net/~bae/8023794/images/
>>> An index of image corresponds to the value of reverse gamma used for
>>> image
>>> generation.
>>>
>>> Beside this, following minor changes were done:
>>> * RenderingHints.KEY_ANTIALIASING was removed form fontHints,
>>> because it has no direct relation to text rendering, and does not
>>> have
>>> any effect at the moment.
>>> * A comment regarding unevaluated rendering hints was added.
>>>
>>> Please take a look.
>>>
>>> Thanks,
>>> Andrew
>>>
>>> On 4/24/2015 7:33 PM, Andrew Brygin wrote:
>>>>
>>>> Hello Phil,
>>>>
>>>> please see my comments inline.
>>>> On 4/23/2015 11:15 PM, Phil Race wrote:
>>>>>
>>>>>
>>>>> 373 fontHints.put(RenderingHints.KEY_ANTIALIASING,
>>>>> RenderingHints.VALUE_ANTIALIAS_ON);
>>>>>
>>>>> Why do we need this ? Historically in the (non-OSX) code this would
>>>>> slow things down by making
>>>>> text rendering go via ductus rendering.
>>>>> If this really is a 'fontsHint' map, it seems it should not be here.
>>>>
>>>>
>>>> I agree that this particular hint has no direct relation to the font
>>>> hints,
>>>> and probably should not be here. I guess that KEY_ANTALIASING was put
>>>> here in order to force text antialiasing on when default text
>>>> antailiasing is evaluating:
>>>>
>>>>
>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/0e483e64c1e4/src/java.desktop/share/classes/sun/java2d/SurfaceData.java#l741
>>>>
>>>> I do not think that it has any effect now, because we set text
>>>> antialiasing hint explicitly.
>>>> I will check whether it can be safely removed.
>>>>
>>>>> 410 sg2d.surfaceData.getTransparency() == Transparency.OPAQUE &&
>>>>>
>>>>> I thought you were removing this condition ?
>>>>
>>>> I have rolled this change back, because at the moment lcd shader
>>>> produces ugly results in the case of translucent destination.
>>>> There is a separate bug regarding the translucent destination support:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8078516
>>>>
>>>> I am going to relax this condition when(if) our lcd shader will be
>>>> ready.
>>>>
>>>> In fact, this problem is not limited by ogl, because d3d and software
>>>> loops
>>>> has the same limitation.
>>>>
>>>>
>>>>>
>>>>> CGGlyphImages.m
>>>>>
>>>>> 202 #if __LITTLE_ENDIAN__
>>>>> 203 *(dst + 2) = 0xFF - (p >> 24 & 0xFF);
>>>>> 204 *(dst + 1) = 0xFF - (p >> 16 & 0xFF);
>>>>> 205 *(dst) = 0xFF - (p >> 8 & 0xFF);
>>>>> 206 #else
>>>>> 207 *(dst) = 0xFF - (p >> 16 & 0xFF);
>>>>> 208 *(dst + 1) = 0xFF - (p >> 8 & 0xFF);
>>>>> 209 *(dst + 2) = 0xFF - (p & 0xFF);
>>>>> 210 #endif
>>>>> 211 }
>>>>>
>>>>> became
>>>>> 217 {
>>>>> 218 *(dst + 0) = 0xFF - (p >> 16 & 0xFF); // red
>>>>> 219 *(dst + 1) = 0xFF - (p >> 8 & 0xFF); // green
>>>>> 220 *(dst + 2) = 0xFF - (p & 0xFF); // blue
>>>>> 221 }
>>>>>
>>>>>
>>>>> I started by assuming you were removing the BIG_ENDIAN code that
>>>>> was probably legacy PPC code but instead I see that the LITTLE_ENDIAN
>>>>> case is removed,
>>>>> so I don't understand this.
>>>>>
>>>>> And further down the file now I see that in ConvertBWPixelToByteGray
>>>>> you did remove the big endian case.
>>>>>
>>>>
>>>> Note that we are
>>>> Please note that we force the lcd glyph generation by requesting
>>>> host (i.e. LITTLE_ENDIAN) byte order for the canvas bitmap:
>>>>
>>>> 407 uint32_t bmpInfo = kCGImageAlphaPremultipliedFirst;
>>>> 408 if (mode->glyphDescriptor == &rgb) {
>>>> 409 bmpInfo |= kCGBitmapByteOrder32Host;
>>>> 410 }
>>>>
>>>> So, before the fix (and for grayscale case now) the buffer has default
>>>> BIG_ENDIAN order. I.e. grayscale canvas stores data in following format:
>>>>
>>>> as bytes: A R G B
>>>> as int: 0xBBGGRRAA
>>>>
>>>> The same byte order was used for the rgb canvas before the fix.
>>>> But now the canvas is configured to store data in following format:
>>>>
>>>> as bytes: B G R A
>>>> as int: 0xAARRGGBB
>>>>
>>>> So, data extraction routines were updated accordingly.
>>>>
>>>>> 365 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_GASP:
>>>>> 366 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_DEFAULT:
>>>>> 367 default:
>>>>> 368 e = [NSException
>>>>> 369 exceptionWithName:@"IllegalArgumentException"
>>>>> 370 reason:@"Invalid hint value"
>>>>> 371 userInfo:nil];
>>>>>
>>>>>
>>>>> I think this means that by the time we get here we should not have
>>>>> DEFAULT or GASP
>>>>> but we should have the actual interpretation for this surface, font and
>>>>> point size.
>>>>> So this looks correct but maybe you can add a comment on this.
>>>>
>>>>
>>>> will do.
>>>>
>>>>> The heuristic of blending black and white is interesting.
>>>>> How did you arrive at this ? It suggests that the glyph bitmap we are
>>>>> caching is
>>>>> not 'colour neutral' which is odd. Maybe we are missing code to apply
>>>>> the 'reverse gamma correction' ?
>>>>
>>>>
>>>> I have played with the idea about 'reverse gamma correction', it seemed
>>>> very attractive to me.
>>>> Roughly speaking, gamma > 1 makes black-on-white glyphs a bit narrower,
>>>> and white-no-black
>>>> glyphs a bit wider (bolder?), and it is the same effect that we need.
>>>> Unfortunately, direct comparison of black-on-white and white-on-black
>>>> glyphs makes me think
>>>> that difference between these glyphs can not be explained only by gamma
>>>> correction.
>>>>
>>>> Please take a look at this screenshot:
>>>> http://cr.openjdk.java.net/~bae/8023794/bw-wb-comparision.png
>>>>
>>>>
>>>> row 1: text is rendered by jdk6 as-is.
>>>> row 2: simulates our pipeline where black-on-white glyphs are used (max
>>>> error on white-on-black)
>>>> row 3: simulates our pipeline where white-on-black glyphs are used (max
>>>> error on black-on-white)
>>>> row 4: blended glyphs are used.
>>>>
>>>> The basic idea of blending is to minimize max error (difference) between
>>>> produced glyph image
>>>> and original color-aware glyphs.
>>>>
>>>> If better results can be achieved with 'reverse gamma correction', we
>>>> can revise this code later.
>>>>
>>>>> And can (should) any of these changes also be applied to D3D ?
>>>>
>>>>
>>>> 1. We can check how gamma correction is done in d3d. If a lookup is also
>>>> used there,
>>>> we can assess how rough the interpolation is.
>>>>
>>>> 2. translucent destination support (as a part of JDK-8078516)?
>>>>
>>>> Thanks,
>>>> Andrew
>>>>
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 03/27/2015 07:50 AM, Andrew Brygin wrote:
>>>>>>
>>>>>> There is a minor update in the fix: it does not worth to blend
>>>>>> black-on-white
>>>>>> and white-on-black glyphs for the case of AA glyphs, because it makes
>>>>>> no difference.
>>>>>> CGGlyphImages.m, lines 294 - 325, 755 - 763, and 787 - 794:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~bae/8023794/9/webrev.08
>>>>>>
>>>>>> I have also modified the AntialiasDemo a bit in order to render the
>>>>>> sample text in different colors, and in order to render into a
>>>>>> volatile
>>>>>> image as well:
>>>>>> http://cr.openjdk.java.net/~bae/8023794/demo/AntialiasDemo.java
>>>>>>
>>>>>> It could be used to assess the change in glyph generation.
>>>>>>
>>>>>> Thanks,
>>>>>> Andrew
>>>>>>
>>>>>> On 3/26/2015 3:59 PM, Andrew Brygin wrote:
>>>>>>>
>>>>>>> Hi Chris,
>>>>>>>
>>>>>>> thank you for the comments and explanation. I have updated the
>>>>>>> OGLContext_IsLCDShaderSupportAvailable()
>>>>>>> and comments in OGLTextRenderer.c accordingly:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~bae/8023794/9/webrev.07/
>>>>>>>
>>>>>>> Good to know that you keep an eye on the OGL pipeline :)
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Andrew
>>>>>>>
>>>>>>> On 3/25/2015 8:24 PM, Chris Campbell wrote:
>>>>>>>>
>>>>>>>> Hi Andrew,
>>>>>>>>
>>>>>>>> That's a good find re: pow(). In the comment at lines 277-283 I
>>>>>>>> mentioned that there was only a scalar variant of pow(). I wonder if that
>>>>>>>> was a limitation in some early version of GLSL I was using or perhaps some
>>>>>>>> driver bug/restriction. According to all the docs I can find the vector
>>>>>>>> variants have been there all along:
>>>>>>>> https://www.opengl.org/sdk/docs/man4/index.php
>>>>>>>>
>>>>>>>> So now I'm wondering if the slowness was actually due to me trying 3
>>>>>>>> scalar pow() calls versus one vector pow() call.
>>>>>>>>
>>>>>>>> Oh, aha! I think this explains part of it:
>>>>>>>>
>>>>>>>> 269 * This is the GLSL fragment shader source code for rendering
>>>>>>>> LCD-optimized
>>>>>>>> 270 * text. Do not be frightened; it is much easier to understand
>>>>>>>> than the
>>>>>>>> 271 * equivalent ASM-like fragment program!
>>>>>>>>
>>>>>>>> Looks like I wrote the original version of this shader using the
>>>>>>>> GL_ARB_fragment_program language, which indeed only had a scalar POW
>>>>>>>> instruction (see section 3.11.5.20):
>>>>>>>> https://www.opengl.org/registry/specs/ARB/fragment_program.txt
>>>>>>>>
>>>>>>>> And then I'm guessing that when I rewrote it in more modern GLSL, I
>>>>>>>> didn't notice that pow() supported vectors. Sigh. That 3D texture LUT was a
>>>>>>>> lot of work for a whole lot of nothing.
>>>>>>>>
>>>>>>>> In any case, you might want to rewrite the comment at lines 277-283
>>>>>>>> to suit the new code. Same goes for the comment at line 315:
>>>>>>>>
>>>>>>>> // gamma adjust the dest color using the invgamma LUT
>>>>>>>>
>>>>>>>> Also, I noticed that the restrictions in
>>>>>>>> OGLContext_IsLCDShaderSupportAvailable() could be loosened since you only
>>>>>>>> need 2 texture units now. Just in the extremely unlikely case that anyone's
>>>>>>>> running this stuff on ancient hardware :)
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Chris
>>>>>>>>
>>>>>>>>
>>>>>>>> Andrew Brygin wrote:
>>>>>>>>>
>>>>>>>>> Hello Phil,
>>>>>>>>>
>>>>>>>>> could you please take a look to updated version of the fix?
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~bae/8023794/9/webrev.06/
>>>>>>>>>
>>>>>>>>> * OGLTextRenderer.c
>>>>>>>>> It was discovered, that in some cases lcd glyphs had visible 'dark
>>>>>>>>> border' around.
>>>>>>>>> This border appeared due to the gamma correction in lcd shader,
>>>>>>>>> which
>>>>>>>>> uses lookup
>>>>>>>>> on 3D texture instead of using 'pow' routine. The texture is
>>>>>>>>> populated
>>>>>>>>> with significant
>>>>>>>>> granularity (16 points per edge), what is a root cause of rough
>>>>>>>>> interpolation of color values.
>>>>>>>>> Suggested change is to eliminate the interpolation and use 'pow'
>>>>>>>>> routine
>>>>>>>>> directly.
>>>>>>>>> It gives more accurate color values, and does not introduce
>>>>>>>>> significant
>>>>>>>>> performance hit
>>>>>>>>> (see benchmark summary below).
>>>>>>>>> However, this part of the fix affects not only macosx, but any
>>>>>>>>> platform
>>>>>>>>> where OGL text
>>>>>>>>> shader can be used, so it probably worth to split into a separate
>>>>>>>>> fix.
>>>>>>>>>
>>>>>>>>> Summary:
>>>>>>>>> lcd-ogl-3Dlookup:
>>>>>>>>> Number of tests: 4
>>>>>>>>> Overall average: 42.68027553311743
>>>>>>>>> Best spread: 3.49% variance
>>>>>>>>> Worst spread: 29.59% variance
>>>>>>>>> (Basis for results comparison)
>>>>>>>>>
>>>>>>>>> lcd-ogl-pow:
>>>>>>>>> Number of tests: 4
>>>>>>>>> Overall average: 42.468941501367084
>>>>>>>>> Best spread: 2.51% variance
>>>>>>>>> Worst spread: 29.44% variance
>>>>>>>>> Comparison to basis:
>>>>>>>>> Best result: 103.28% of basis
>>>>>>>>> Worst result: 97.36% of basis
>>>>>>>>> Number of wins: 1
>>>>>>>>> Number of ties: 2
>>>>>>>>> Number of losses: 1
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Andrew
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
--
-Tor
From Sergey.Bylokhov at oracle.com Wed May 27 10:36:08 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 27 May 2015 13:36:08 +0300
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8080847 Copying of
overlapping memory should be improved in java2d
In-Reply-To: <5564BB02.40703@oracle.com>
References: <5563172D.4080605@oracle.com>
<556374FD.4020501@oracle.com> <556378C7.6090807@oracle.com>
<55644E47.4040008@oracle.com> <55645A46.70506@oracle.com>
<5564BB02.40703@oracle.com>
Message-ID: <55659E18.8040903@oracle.com>
On 26.05.15 21:27, Jim Graham wrote:
> Undefined doesn't mean "may crash" in this case, it means that the
> contents of memory may not match what you would expect if the regions
> overlap because it is just a dump copy loop that does not do any
> aliasing checks.
Since it is undefined it can crash, but even if it is not, it can
produce the different results for the same application on different cpu.
Because it can copy data in any direction based on the current cpu. It
is not a simple copy loop. see discussion [1] for example.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=12518
https://sourceware.org/bugzilla/show_bug.cgi?id=12518#c3
I still insist that it is the simplest fix, which will relieve us of
randomness and will bring into accord with the native specification. It
is similar to this rule: Swing should be accessed on the EDT.
Application can work for decades and contradict this rule, but can be
broken in any updates of Swing.
>
> Is there a way to silence the warning? In this particular case we are
> totally OK with the undefined behavior, in fact, the accidental
> behavior that they are calling "undefined" because it is confusing to
> most developers who don't know enough to worry about aliased memory
> regions - is actually the behavior we want because it will match the
> results of all of the other blits.
>
> If there is no way to silence the tool, then I'd recommend hard-coding
> our own "dumb copy loop" instead so that the behavior continues to
> match what memcpy should have been doing.
>
> Do not just fix this in the vertical direction as well - if you
> continue on a path that makes the aliasing not happen then I will
> insist that you modify all drawimage paths to all deal gracefully with
> memory aliasing and write an extensive test suite to make sure that we
> correctly manage the aliasing in all cases, all composite modes, the
> bg versions as well as the non-bg versions, scaled and transformed
> blits, etc. If you are not prepared to do all of that, then we should
> drop this attempt to fix a "bug" that is really code working as
> (un)expected and focus instead on silencing the warning...
>
> ...jim
>
> On 5/26/2015 4:34 AM, Sergey Bylokhov wrote:
>> On 26.05.15 13:43, Jim Graham wrote:
>>> What crash in memcpy?
>> Simply because behavior of this function is undefined if the two arrays
>> "to" and "from" overlap. Plus this clears an output for the tools like
>> valgrind and some other issues can be found easily.
>>
>>> The issue you pointed to is about dealing with overlapping memory.
>>> memcpy does not crash on overlapping memory copies, it just duplicates
>>> data oddly in a way that most uses probably don't want.
>>>
>>> Also, the fix you gave only fixed the problem for the horizontal
>>> direction, if the drawImage call were directed at 0,1 then we'd still
>>> get all scan lines duplicated from the first...
>> Right, I can take a look to this bug too.
>>>
>>> ...jim
>>>
>>> On 5/25/2015 12:32 PM, Sergey Bylokhov wrote:
>>>> Hi, Jim.
>>>> Actually there is a difference in support: it works but result is a
>>>> little bit wrong, and it does not work and crashes. This fix is not a
>>>> general solution for the incorrect result of the blit+aliasing, but
>>>> for
>>>> the possible crash of memcpy especially after some improvements
>>>> like in
>>>> glibc. I think this still an issue.
>>>>
>>>>> I don't recall if we ever promised that this case would work without
>>>>> aliasing issues. I know that we went out of our way in the copyArea
>>>>> method to prevent the aliasing issue, doing the blits piecemeal so
>>>>> that they don't interfere with each other. Further, while it may be
>>>>> easy enough to just call memmove to have the libraray do this for us
>>>>> in the IsoBlit case, other cases that don't fall into the IsoBlit
>>>>> macro will not be similarly protected. In particular, if you specify
>>>>> an alpha value, you will not get this protection (at least not
>>>>> without
>>>>> a huge amount of work to overhaul the entire DrawImage pipeline).
>>>>>
>>>>> I would say that this would be OK if we planned to make this promise
>>>>> about drawImage across all image formats and composition modes, but
>>>>> that would be a far more complicated fix. Until then, we should not
>>>>> open this can of worms by modifying this one specific Blit case...
>>>>>
>>>>> ...jim
>>>>>
>>>>> On 5/25/2015 5:35 AM, Sergey Bylokhov wrote:
>>>>>> Hello.
>>>>>> Please review the fix forjdk9.
>>>>>>
>>>>>> I found this issue during code review of another task, related to
>>>>>> performance.
>>>>>>
>>>>>> The sample code below will call the IsomorphicCopy method which call
>>>>>> memcpy on the overlapping memory(this is the simplest example)
>>>>>>
>>>>>> BufferedImage img = new BufferedImage(100, 100,
>>>>>> BufferedImage.TYPE_INT_ARGB_PRE);
>>>>>> Graphics2D g = img.createGraphics();
>>>>>> g.setComposite(AlphaComposite.Src);
>>>>>> g.drawImage(img, 0, 0, null);
>>>>>> g.dispose();
>>>>>>
>>>>>> http://linux.die.net/man/3/memcpy
>>>>>> "The memcpy() function copies n bytes from memory area src to memory
>>>>>> area dest. The memory areas must not overlap. Use memmove(3) if the
>>>>>> memory areas do overlap"
>>>>>>
>>>>>>
>>>>>> I can confirm this bug using valgrind and a program above:
>>>>>> command:
>>>>>> valgrind --smc-check=all --tool=memcheck --leak-check=full -v
>>>>>> ./9/client/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/java
>>>>>>
>>>>>>
>>>>>> -Xint
>>>>>> Main
>>>>>>
>>>>>> output:
>>>>>> ==60975== Source and destination overlap in memcpy(0xe1b8b4d8,
>>>>>> 0xe1b8b4d8, 400)
>>>>>> ==60975== at 0x4C2F71C: memcpy@@GLIBC_2.14 (in
>>>>>> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
>>>>>> ==60975== by 0x1E0F504D: AnyIntIsomorphicCopy (in
>>>>>> /moe/workspaces/jdk/9/client-work/build/linux-x86_64-normal-server-fastdebug/images/jdk/lib/amd64/libawt.so)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ==60975== by 0x1E0F5DE8: Java_sun_java2d_loops_Blit_Blit (in
>>>>>> /moe/workspaces/jdk/9/client-work/build/linux-x86_64-normal-server-fastdebug/images/jdk/lib/amd64/libawt.so)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8080847
>>>>>> Webrev can be found at:
>>>>>> http://cr.openjdk.java.net/~serb/8080847/webrev.00
>>>>>>
>>>>
>>>>
>>
>>
--
Best regards, Sergey.
From aph at redhat.com Wed May 27 10:54:45 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 27 May 2015 11:54:45 +0100
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8080847 Copying of
overlapping memory should be improved in java2d
In-Reply-To: <55659E18.8040903@oracle.com>
References: <5563172D.4080605@oracle.com> <556374FD.4020501@oracle.com> <556378C7.6090807@oracle.com> <55644E47.4040008@oracle.com>
<55645A46.70506@oracle.com> <5564BB02.40703@oracle.com>
<55659E18.8040903@oracle.com>
Message-ID: <5565A275.2040909@redhat.com>
On 05/27/2015 11:36 AM, Sergey Bylokhov wrote:
> On 26.05.15 21:27, Jim Graham wrote:
>> Undefined doesn't mean "may crash" in this case, it means that the
>> contents of memory may not match what you would expect if the regions
>> overlap because it is just a dump copy loop that does not do any
>> aliasing checks.
> Since it is undefined it can crash, but even if it is not, it can
> produce the different results for the same application on different cpu.
Definitely. It certainly can crash. There is no way that we should
tolerate UB in any code which is part of Java. We can just use
memmove().
Andrew.
From andrew.brygin at oracle.com Wed May 27 13:17:24 2015
From: andrew.brygin at oracle.com (Andrew Brygin)
Date: Wed, 27 May 2015 16:17:24 +0300
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8061831 [OGL]
"java.lang.InternalError: not implemented yet" during the blit of VI to VI
in xor mode
In-Reply-To: <555F607C.7060707@oracle.com>
References: <555DDC00.7050608@oracle.com> <555E390B.9020106@oracle.com>
<555F607C.7060707@oracle.com>
Message-ID: <5565C3E4.3070000@oracle.com>
Hello Sergey,
the fix looks fine to me.
Thanks,
Andrew
On 5/22/2015 7:59 PM, Sergey Bylokhov wrote:
> On 21.05.15 22:59, Jim Graham wrote:
>> I'm curious about bufferClip in the converter routine. Does that
>> help? Since we clip when we blit back to the destination in the last
>> line, we don't necessarily need to clip the intermediate operation.
>> I suppose it could save time, but if it is a rect clip then I would
>> think the entire op would already be trimmed to just the size of the
>> clip. And if it is a complex clip then there is a tradeoff between
>> operating on the excluded pixels and how long it takes to create the
>> translated clip and how much overhead there is in enumerating it
>> inside the performop blit. Best to leave it for now, but I thought I
>> would float that issue...
> This clip is useful, because in general we can use some custom/slow
> compozite here, and it will be better to minimize it usage.
>>
>> Looks good, modulo the indenting issue...
>>
>> ...jim
>>
>> On 5/21/15 6:22 AM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review the fix for jdk9.
>>> Our blits machinary in case of absent of direct/general blits will use
>>> the AnyBlit, which uses surface.getRaster method. This method is not
>>> implemented in OGL surfaces, so we must have some blit, which covers
>>> all
>>> possible combinations of source/destination/composite.
>>>
>>> In the fix for JDK-7124347[1] the new OGLAnyCompositeBlit was added,
>>> and
>>> this new blit covers situation, when we cannot call getRaster on
>>> destination and must read it to the temporary buffer. But it does not
>>> take into account that the same problem exists for the source. If the
>>> source surface is OpenGLSurface and xor composite is used we should
>>> copy
>>> it to the temporary buffer also.
>>>
>>> In this fix I added some parameters, which configure
>>> OGLAnyCompositeBlit
>>> for the case when some kind of ogl source is passed.
>>>
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-7124347
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061831
>>> Webrev can be found at: http://cr.openjdk.java.net/~serb/8061831/webrev
>>>
>
>
From denis.fokin at gmail.com Wed May 27 14:16:09 2015
From: denis.fokin at gmail.com (Denis Fokin)
Date: Wed, 27 May 2015 18:16:09 +0400
Subject: [OpenJDK 2D-Dev] [9] Review Request: JDK-8041900 [macosx]
Java forces the use of discrete GPU
Message-ID:
Please review the fix for jdk9
The fix allows do not force discrete video card usage on MacBook Pro models
with two video cards. I have tested the fix on several MPBs.
Bug: https://bugs.openjdk.java.net/browse/JDK-8041900
Webrev: http://cr.openjdk.java.net/~denis/8041900/webrev.00
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From Sergey.Bylokhov at oracle.com Wed May 27 14:30:48 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 27 May 2015 17:30:48 +0300
Subject: [OpenJDK 2D-Dev] [9] Review Request: JDK-8041900
[macosx] Java forces the use of discrete GPU
In-Reply-To:
References:
Message-ID: <5565D518.1070001@oracle.com>
Hi, Denis.
Can you describe the steps on how to test it. On my mac it still change
the vc.
On 27.05.15 17:16, Denis Fokin wrote:
> Please review the fix for jdk9
>
> The fix allows do not force discrete video card usage on MacBook Pro
> models with two video cards. I have tested the fix on several MPBs.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8041900
> Webrev: http://cr.openjdk.java.net/~denis/8041900/webrev.00
>
--
Best regards, Sergey.
From torgeir.veimo at gmail.com Wed May 27 14:52:48 2015
From: torgeir.veimo at gmail.com (Torgeir Veimo)
Date: Thu, 28 May 2015 00:52:48 +1000
Subject: [OpenJDK 2D-Dev] Fwd: [9] Review Request: JDK-8041900
[macosx] Java forces the use of discrete GPU
In-Reply-To:
References:
<5565D518.1070001@oracle.com>
Message-ID:
Same here, 2014 15" macbook pro. Running netbeans with openjdk from hg
yesterday with this patch applied.
On 28/05/2015, Sergey Bylokhov wrote:
> Hi, Denis.
> Can you describe the steps on how to test it. On my mac it still change
> the vc.
>
> On 27.05.15 17:16, Denis Fokin wrote:
>> Please review the fix for jdk9
>>
>> The fix allows do not force discrete video card usage on MacBook Pro
>> models with two video cards. I have tested the fix on several MPBs.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8041900
>> Webrev: http://cr.openjdk.java.net/~denis/8041900/webrev.00
>>
>
>
> --
> Best regards, Sergey.
>
>
--
-Tor
From denis.fokin at gmail.com Wed May 27 15:08:06 2015
From: denis.fokin at gmail.com (Denis Fokin)
Date: Wed, 27 May 2015 18:08:06 +0300
Subject: [OpenJDK 2D-Dev] [9] Review Request: JDK-8041900
[macosx] Java forces the use of discrete GPU
In-Reply-To: <5565D518.1070001@oracle.com>
References:
<5565D518.1070001@oracle.com>
Message-ID: <0043AB18-6F14-42E0-9453-F0A74A11450D@gmail.com>
Hi, Sergey,
Basically, you should close all apps that can switch the vc including the utility for switching video cards. Make sure in About This Mac -> Displays that the integrated card is enabled. Start an application with the patched version of Java. Check About This Mac -> Displays. Integrated video card should be still active.
> 27 ??? 2015 ?., ? 17:30, Sergey Bylokhov ???????(?):
>
> Hi, Denis.
> Can you describe the steps on how to test it. On my mac it still change the vc.
>
>> On 27.05.15 17:16, Denis Fokin wrote:
>> Please review the fix for jdk9
>>
>> The fix allows do not force discrete video card usage on MacBook Pro models with two video cards. I have tested the fix on several MPBs.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8041900
>> Webrev: http://cr.openjdk.java.net/~denis/8041900/webrev.00
>
>
> --
> Best regards, Sergey.
>
From torgeir.veimo at gmail.com Wed May 27 15:19:31 2015
From: torgeir.veimo at gmail.com (Torgeir Veimo)
Date: Thu, 28 May 2015 01:19:31 +1000
Subject: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD
Rendering hints seems not working without FRACTIONALMETRICS=ON
In-Reply-To:
References:
<53BD5E45.4000805@oracle.com>
<9A5D5D1C-F58F-4DFC-B327-9A9DB18B155E@gmail.com>
<54297B00.5020604@oracle.com>
<6B49FF00-8A8F-41DF-A574-B9537C1A2B94@gmail.com>
<5437EE69.3090606@oracle.com> <54380F42.7060705@oracle.com>
<54381FFC.5000507@oracle.com> <5438465D.5070503@oracle.com>
<54384C03.5020006@oracle.com> <543ADF1B.9020802@oracle.com>
<543BC85F.8050202@oracle.com> <543C62AC.2010907@oracle.com>
<544A92CC.10406@oracle.com> <544AB09D.5060805@oracle.com>
<548B21D2.8080701@oracle.com> <5512CB71.30908@oracle.com>
<5512EF51.7070907@plausible.coop> <5514029A.1090101@oracle.com>
<55156E31.7080803@oracle.com> <553952F2.9040007@oracle.com>
<553A7046.3000008@oracle.com> <55422C52.8010906@oracle.com>
<555A4956.5060607@oracle.com> <555DEA4D.2010903@oracle.com>
Message-ID:
I am still unable to get subpixel antialiasing to work for netbeans
with this patch. Are there circumstances (eg. certain surface
configuration or double buffering), where subpixel antialising will be
disabled?
On 27 May 2015 at 15:21, Torgeir Veimo wrote:
> This looks extremely promising;
> https://bugzilla-attachments-216655.netbeans.org/bugzilla/attachment.cgi?id=153888
>
> I'd say don't let perfect be the enemy of the good, please get this
> out into a jdk9 release and let the community provide more feedback.
>
> On 22 May 2015 at 00:23, Andrew Brygin wrote:
>> Hello Phil,
>>
>> I have changed the default reverse gamma to 180:
>>
>> http://cr.openjdk.java.net/~bae/8023794/9/webrev.10/
>>
>> I also did some experiments with the lcd contrast, and found that
>> value 160 decreases the discrepancy a bit: 21 instead of 29 with
>> the default lcd contrast value (140).
>> However, there still is the discrepancy, and at the moment I do not
>> see how we can avoid it completely with our rendering model.
>> It looks like that there is something more sophisticated than
>> just gamma correction, and we are unable to derive 'color independent'
>> glyphs from black-on-white glyphs provided by the native system.
>>
>> I have also played with changing display profiles but it seems to
>> have no detectable effect.
>>
>> Thanks,
>> Andrew
>>
>>
>> On 5/18/2015 11:19 PM, Phil Race wrote:
>>>
>>> Hi,
>>>
>>> So 1.79 is essentially 1.8 which is what Mac historically used as gamma.
>>> So I'd pick 180 instead of 179
>>> Since that value minimises the discrepancy it's looking positive but
>>> there's still a discrepancy.
>>> Before we 'live with it', I'd be interested to know what happens if you
>>> set your display's profile to a generic RGB one.
>>>
>>> How do the glyph shapes (if you try your best to ignore the colour) match
>>> what other apps produce ?
>>>
>>> -phil.
>>>
>>>
>>> On 04/30/2015 06:21 AM, Andrew Brygin wrote:
>>>>
>>>> Hello Phil,
>>>>
>>>> please take a look to updated version of the fix:
>>>>
>>>> http://cr.openjdk.java.net/~bae/8023794/9/webrev.09/
>>>>
>>>> The main difference is in glyph generation. I have implemented 'reverse
>>>> gamma correction'
>>>> approach instead of 'glyph blending'. By default we use gamma value
>>>> which provides minimum
>>>> of discrepancy with gyph images produced by Apple's jdk. However, it can
>>>> be adjusted via
>>>> environment variable J2D_LCD_REVERSE_GAMMA (CGGlyphImages.m, lines 198 -
>>>> 220).
>>>>
>>>> Following chart illustrates dependency between the 'reverse gamma' and a
>>>> difference
>>>> in pixel values comparing to jdk6 from Apple:
>>>> http://cr.openjdk.java.net/~bae/8023794/best_reverse_gamma.png
>>>>
>>>> Following set of images has been used for the comparison:
>>>> http://cr.openjdk.java.net/~bae/8023794/images/
>>>> An index of image corresponds to the value of reverse gamma used for
>>>> image
>>>> generation.
>>>>
>>>> Beside this, following minor changes were done:
>>>> * RenderingHints.KEY_ANTIALIASING was removed form fontHints,
>>>> because it has no direct relation to text rendering, and does not
>>>> have
>>>> any effect at the moment.
>>>> * A comment regarding unevaluated rendering hints was added.
>>>>
>>>> Please take a look.
>>>>
>>>> Thanks,
>>>> Andrew
>>>>
>>>> On 4/24/2015 7:33 PM, Andrew Brygin wrote:
>>>>>
>>>>> Hello Phil,
>>>>>
>>>>> please see my comments inline.
>>>>> On 4/23/2015 11:15 PM, Phil Race wrote:
>>>>>>
>>>>>>
>>>>>> 373 fontHints.put(RenderingHints.KEY_ANTIALIASING,
>>>>>> RenderingHints.VALUE_ANTIALIAS_ON);
>>>>>>
>>>>>> Why do we need this ? Historically in the (non-OSX) code this would
>>>>>> slow things down by making
>>>>>> text rendering go via ductus rendering.
>>>>>> If this really is a 'fontsHint' map, it seems it should not be here.
>>>>>
>>>>>
>>>>> I agree that this particular hint has no direct relation to the font
>>>>> hints,
>>>>> and probably should not be here. I guess that KEY_ANTALIASING was put
>>>>> here in order to force text antialiasing on when default text
>>>>> antailiasing is evaluating:
>>>>>
>>>>>
>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/0e483e64c1e4/src/java.desktop/share/classes/sun/java2d/SurfaceData.java#l741
>>>>>
>>>>> I do not think that it has any effect now, because we set text
>>>>> antialiasing hint explicitly.
>>>>> I will check whether it can be safely removed.
>>>>>
>>>>>> 410 sg2d.surfaceData.getTransparency() == Transparency.OPAQUE &&
>>>>>>
>>>>>> I thought you were removing this condition ?
>>>>>
>>>>> I have rolled this change back, because at the moment lcd shader
>>>>> produces ugly results in the case of translucent destination.
>>>>> There is a separate bug regarding the translucent destination support:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8078516
>>>>>
>>>>> I am going to relax this condition when(if) our lcd shader will be
>>>>> ready.
>>>>>
>>>>> In fact, this problem is not limited by ogl, because d3d and software
>>>>> loops
>>>>> has the same limitation.
>>>>>
>>>>>
>>>>>>
>>>>>> CGGlyphImages.m
>>>>>>
>>>>>> 202 #if __LITTLE_ENDIAN__
>>>>>> 203 *(dst + 2) = 0xFF - (p >> 24 & 0xFF);
>>>>>> 204 *(dst + 1) = 0xFF - (p >> 16 & 0xFF);
>>>>>> 205 *(dst) = 0xFF - (p >> 8 & 0xFF);
>>>>>> 206 #else
>>>>>> 207 *(dst) = 0xFF - (p >> 16 & 0xFF);
>>>>>> 208 *(dst + 1) = 0xFF - (p >> 8 & 0xFF);
>>>>>> 209 *(dst + 2) = 0xFF - (p & 0xFF);
>>>>>> 210 #endif
>>>>>> 211 }
>>>>>>
>>>>>> became
>>>>>> 217 {
>>>>>> 218 *(dst + 0) = 0xFF - (p >> 16 & 0xFF); // red
>>>>>> 219 *(dst + 1) = 0xFF - (p >> 8 & 0xFF); // green
>>>>>> 220 *(dst + 2) = 0xFF - (p & 0xFF); // blue
>>>>>> 221 }
>>>>>>
>>>>>>
>>>>>> I started by assuming you were removing the BIG_ENDIAN code that
>>>>>> was probably legacy PPC code but instead I see that the LITTLE_ENDIAN
>>>>>> case is removed,
>>>>>> so I don't understand this.
>>>>>>
>>>>>> And further down the file now I see that in ConvertBWPixelToByteGray
>>>>>> you did remove the big endian case.
>>>>>>
>>>>>
>>>>> Note that we are
>>>>> Please note that we force the lcd glyph generation by requesting
>>>>> host (i.e. LITTLE_ENDIAN) byte order for the canvas bitmap:
>>>>>
>>>>> 407 uint32_t bmpInfo = kCGImageAlphaPremultipliedFirst;
>>>>> 408 if (mode->glyphDescriptor == &rgb) {
>>>>> 409 bmpInfo |= kCGBitmapByteOrder32Host;
>>>>> 410 }
>>>>>
>>>>> So, before the fix (and for grayscale case now) the buffer has default
>>>>> BIG_ENDIAN order. I.e. grayscale canvas stores data in following format:
>>>>>
>>>>> as bytes: A R G B
>>>>> as int: 0xBBGGRRAA
>>>>>
>>>>> The same byte order was used for the rgb canvas before the fix.
>>>>> But now the canvas is configured to store data in following format:
>>>>>
>>>>> as bytes: B G R A
>>>>> as int: 0xAARRGGBB
>>>>>
>>>>> So, data extraction routines were updated accordingly.
>>>>>
>>>>>> 365 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_GASP:
>>>>>> 366 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_DEFAULT:
>>>>>> 367 default:
>>>>>> 368 e = [NSException
>>>>>> 369 exceptionWithName:@"IllegalArgumentException"
>>>>>> 370 reason:@"Invalid hint value"
>>>>>> 371 userInfo:nil];
>>>>>>
>>>>>>
>>>>>> I think this means that by the time we get here we should not have
>>>>>> DEFAULT or GASP
>>>>>> but we should have the actual interpretation for this surface, font and
>>>>>> point size.
>>>>>> So this looks correct but maybe you can add a comment on this.
>>>>>
>>>>>
>>>>> will do.
>>>>>
>>>>>> The heuristic of blending black and white is interesting.
>>>>>> How did you arrive at this ? It suggests that the glyph bitmap we are
>>>>>> caching is
>>>>>> not 'colour neutral' which is odd. Maybe we are missing code to apply
>>>>>> the 'reverse gamma correction' ?
>>>>>
>>>>>
>>>>> I have played with the idea about 'reverse gamma correction', it seemed
>>>>> very attractive to me.
>>>>> Roughly speaking, gamma > 1 makes black-on-white glyphs a bit narrower,
>>>>> and white-no-black
>>>>> glyphs a bit wider (bolder?), and it is the same effect that we need.
>>>>> Unfortunately, direct comparison of black-on-white and white-on-black
>>>>> glyphs makes me think
>>>>> that difference between these glyphs can not be explained only by gamma
>>>>> correction.
>>>>>
>>>>> Please take a look at this screenshot:
>>>>> http://cr.openjdk.java.net/~bae/8023794/bw-wb-comparision.png
>>>>>
>>>>>
>>>>> row 1: text is rendered by jdk6 as-is.
>>>>> row 2: simulates our pipeline where black-on-white glyphs are used (max
>>>>> error on white-on-black)
>>>>> row 3: simulates our pipeline where white-on-black glyphs are used (max
>>>>> error on black-on-white)
>>>>> row 4: blended glyphs are used.
>>>>>
>>>>> The basic idea of blending is to minimize max error (difference) between
>>>>> produced glyph image
>>>>> and original color-aware glyphs.
>>>>>
>>>>> If better results can be achieved with 'reverse gamma correction', we
>>>>> can revise this code later.
>>>>>
>>>>>> And can (should) any of these changes also be applied to D3D ?
>>>>>
>>>>>
>>>>> 1. We can check how gamma correction is done in d3d. If a lookup is also
>>>>> used there,
>>>>> we can assess how rough the interpolation is.
>>>>>
>>>>> 2. translucent destination support (as a part of JDK-8078516)?
>>>>>
>>>>> Thanks,
>>>>> Andrew
>>>>>
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>> On 03/27/2015 07:50 AM, Andrew Brygin wrote:
>>>>>>>
>>>>>>> There is a minor update in the fix: it does not worth to blend
>>>>>>> black-on-white
>>>>>>> and white-on-black glyphs for the case of AA glyphs, because it makes
>>>>>>> no difference.
>>>>>>> CGGlyphImages.m, lines 294 - 325, 755 - 763, and 787 - 794:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~bae/8023794/9/webrev.08
>>>>>>>
>>>>>>> I have also modified the AntialiasDemo a bit in order to render the
>>>>>>> sample text in different colors, and in order to render into a
>>>>>>> volatile
>>>>>>> image as well:
>>>>>>> http://cr.openjdk.java.net/~bae/8023794/demo/AntialiasDemo.java
>>>>>>>
>>>>>>> It could be used to assess the change in glyph generation.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Andrew
>>>>>>>
>>>>>>> On 3/26/2015 3:59 PM, Andrew Brygin wrote:
>>>>>>>>
>>>>>>>> Hi Chris,
>>>>>>>>
>>>>>>>> thank you for the comments and explanation. I have updated the
>>>>>>>> OGLContext_IsLCDShaderSupportAvailable()
>>>>>>>> and comments in OGLTextRenderer.c accordingly:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~bae/8023794/9/webrev.07/
>>>>>>>>
>>>>>>>> Good to know that you keep an eye on the OGL pipeline :)
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Andrew
>>>>>>>>
>>>>>>>> On 3/25/2015 8:24 PM, Chris Campbell wrote:
>>>>>>>>>
>>>>>>>>> Hi Andrew,
>>>>>>>>>
>>>>>>>>> That's a good find re: pow(). In the comment at lines 277-283 I
>>>>>>>>> mentioned that there was only a scalar variant of pow(). I wonder if that
>>>>>>>>> was a limitation in some early version of GLSL I was using or perhaps some
>>>>>>>>> driver bug/restriction. According to all the docs I can find the vector
>>>>>>>>> variants have been there all along:
>>>>>>>>> https://www.opengl.org/sdk/docs/man4/index.php
>>>>>>>>>
>>>>>>>>> So now I'm wondering if the slowness was actually due to me trying 3
>>>>>>>>> scalar pow() calls versus one vector pow() call.
>>>>>>>>>
>>>>>>>>> Oh, aha! I think this explains part of it:
>>>>>>>>>
>>>>>>>>> 269 * This is the GLSL fragment shader source code for rendering
>>>>>>>>> LCD-optimized
>>>>>>>>> 270 * text. Do not be frightened; it is much easier to understand
>>>>>>>>> than the
>>>>>>>>> 271 * equivalent ASM-like fragment program!
>>>>>>>>>
>>>>>>>>> Looks like I wrote the original version of this shader using the
>>>>>>>>> GL_ARB_fragment_program language, which indeed only had a scalar POW
>>>>>>>>> instruction (see section 3.11.5.20):
>>>>>>>>> https://www.opengl.org/registry/specs/ARB/fragment_program.txt
>>>>>>>>>
>>>>>>>>> And then I'm guessing that when I rewrote it in more modern GLSL, I
>>>>>>>>> didn't notice that pow() supported vectors. Sigh. That 3D texture LUT was a
>>>>>>>>> lot of work for a whole lot of nothing.
>>>>>>>>>
>>>>>>>>> In any case, you might want to rewrite the comment at lines 277-283
>>>>>>>>> to suit the new code. Same goes for the comment at line 315:
>>>>>>>>>
>>>>>>>>> // gamma adjust the dest color using the invgamma LUT
>>>>>>>>>
>>>>>>>>> Also, I noticed that the restrictions in
>>>>>>>>> OGLContext_IsLCDShaderSupportAvailable() could be loosened since you only
>>>>>>>>> need 2 texture units now. Just in the extremely unlikely case that anyone's
>>>>>>>>> running this stuff on ancient hardware :)
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Chris
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Andrew Brygin wrote:
>>>>>>>>>>
>>>>>>>>>> Hello Phil,
>>>>>>>>>>
>>>>>>>>>> could you please take a look to updated version of the fix?
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~bae/8023794/9/webrev.06/
>>>>>>>>>>
>>>>>>>>>> * OGLTextRenderer.c
>>>>>>>>>> It was discovered, that in some cases lcd glyphs had visible 'dark
>>>>>>>>>> border' around.
>>>>>>>>>> This border appeared due to the gamma correction in lcd shader,
>>>>>>>>>> which
>>>>>>>>>> uses lookup
>>>>>>>>>> on 3D texture instead of using 'pow' routine. The texture is
>>>>>>>>>> populated
>>>>>>>>>> with significant
>>>>>>>>>> granularity (16 points per edge), what is a root cause of rough
>>>>>>>>>> interpolation of color values.
>>>>>>>>>> Suggested change is to eliminate the interpolation and use 'pow'
>>>>>>>>>> routine
>>>>>>>>>> directly.
>>>>>>>>>> It gives more accurate color values, and does not introduce
>>>>>>>>>> significant
>>>>>>>>>> performance hit
>>>>>>>>>> (see benchmark summary below).
>>>>>>>>>> However, this part of the fix affects not only macosx, but any
>>>>>>>>>> platform
>>>>>>>>>> where OGL text
>>>>>>>>>> shader can be used, so it probably worth to split into a separate
>>>>>>>>>> fix.
>>>>>>>>>>
>>>>>>>>>> Summary:
>>>>>>>>>> lcd-ogl-3Dlookup:
>>>>>>>>>> Number of tests: 4
>>>>>>>>>> Overall average: 42.68027553311743
>>>>>>>>>> Best spread: 3.49% variance
>>>>>>>>>> Worst spread: 29.59% variance
>>>>>>>>>> (Basis for results comparison)
>>>>>>>>>>
>>>>>>>>>> lcd-ogl-pow:
>>>>>>>>>> Number of tests: 4
>>>>>>>>>> Overall average: 42.468941501367084
>>>>>>>>>> Best spread: 2.51% variance
>>>>>>>>>> Worst spread: 29.44% variance
>>>>>>>>>> Comparison to basis:
>>>>>>>>>> Best result: 103.28% of basis
>>>>>>>>>> Worst result: 97.36% of basis
>>>>>>>>>> Number of wins: 1
>>>>>>>>>> Number of ties: 2
>>>>>>>>>> Number of losses: 1
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Andrew
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
>
> --
> -Tor
--
-Tor
From philip.race at oracle.com Wed May 27 16:31:24 2015
From: philip.race at oracle.com (Phil Race)
Date: Wed, 27 May 2015 09:31:24 -0700
Subject: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD
Rendering hints seems not working without FRACTIONALMETRICS=ON
In-Reply-To: <555DEA4D.2010903@oracle.com>
References: <53BD5E45.4000805@oracle.com> <9A5D5D1C-F58F-4DFC-B327-9A9DB18B155E@gmail.com> <54297B00.5020604@oracle.com> <6B49FF00-8A8F-41DF-A574-B9537C1A2B94@gmail.com> <5437EE69.3090606@oracle.com> <54380F42.7060705@oracle.com> <54381FFC.5000507@oracle.com> <5438465D.5070503@oracle.com> <54384C03.5020006@oracle.com> <543ADF1B.9020802@oracle.com> <543BC85F.8050202@oracle.com> <543C62AC.2010907@oracle.com> <544A92CC.10406@oracle.com> <544AB09D.5060805@oracle.com>
<548B21D2.8080701@oracle.com> <5512CB71.30908@oracle.com>
<5512EF51.7070907@plausible.coop> <5514029A.1090101@oracle.com>
<55156E31.7080803@oracle.com> <553952F2.9040007@oracle.com>
<553A7046.3000008@oracle.com> <55422C52.8010906@oracle.com>
<555A4956.5060607@oracle.com> <555DEA4D.2010903@oracle.com>
Message-ID: <5565F15C.1080705@oracle.com>
OK .. it's a step forward, so approved, although there is more to be done.
I do ask that you however restore this comment until you actually remove the constraint :
405 * - and the destination is opaque
-phil.
On 05/21/2015 07:23 AM, Andrew Brygin wrote:
> Hello Phil,
>
> I have changed the default reverse gamma to 180:
>
> http://cr.openjdk.java.net/~bae/8023794/9/webrev.10/
>
> I also did some experiments with the lcd contrast, and found that
> value 160 decreases the discrepancy a bit: 21 instead of 29 with
> the default lcd contrast value (140).
> However, there still is the discrepancy, and at the moment I do not
> see how we can avoid it completely with our rendering model.
> It looks like that there is something more sophisticated than
> just gamma correction, and we are unable to derive 'color independent'
> glyphs from black-on-white glyphs provided by the native system.
>
> I have also played with changing display profiles but it seems to
> have no detectable effect.
>
> Thanks,
> Andrew
>
> On 5/18/2015 11:19 PM, Phil Race wrote:
>> Hi,
>>
>> So 1.79 is essentially 1.8 which is what Mac historically used as
>> gamma. So I'd pick 180 instead of 179
>> Since that value minimises the discrepancy it's looking positive but
>> there's still a discrepancy.
>> Before we 'live with it', I'd be interested to know what happens if
>> you set your display's profile to a generic RGB one.
>>
>> How do the glyph shapes (if you try your best to ignore the colour)
>> match what other apps produce ?
>>
>> -phil.
>>
>>
>> On 04/30/2015 06:21 AM, Andrew Brygin wrote:
>>> Hello Phil,
>>>
>>> please take a look to updated version of the fix:
>>>
>>> http://cr.openjdk.java.net/~bae/8023794/9/webrev.09/
>>>
>>> The main difference is in glyph generation. I have implemented
>>> 'reverse gamma correction'
>>> approach instead of 'glyph blending'. By default we use gamma value
>>> which provides minimum
>>> of discrepancy with gyph images produced by Apple's jdk. However,
>>> it can be adjusted via
>>> environment variable J2D_LCD_REVERSE_GAMMA (CGGlyphImages.m, lines
>>> 198 - 220).
>>>
>>> Following chart illustrates dependency between the 'reverse gamma'
>>> and a difference
>>> in pixel values comparing to jdk6 from Apple:
>>> http://cr.openjdk.java.net/~bae/8023794/best_reverse_gamma.png
>>>
>>> Following set of images has been used for the comparison:
>>> http://cr.openjdk.java.net/~bae/8023794/images/
>>> An index of image corresponds to the value of reverse gamma used
>>> for image
>>> generation.
>>>
>>> Beside this, following minor changes were done:
>>> * RenderingHints.KEY_ANTIALIASING was removed form fontHints,
>>> because it has no direct relation to text rendering, and does
>>> not have
>>> any effect at the moment.
>>> * A comment regarding unevaluated rendering hints was added.
>>>
>>> Please take a look.
>>>
>>> Thanks,
>>> Andrew
>>>
>>> On 4/24/2015 7:33 PM, Andrew Brygin wrote:
>>>> Hello Phil,
>>>>
>>>> please see my comments inline.
>>>> On 4/23/2015 11:15 PM, Phil Race wrote:
>>>>>
>>>>> 373 fontHints.put(RenderingHints.KEY_ANTIALIASING,
>>>>> RenderingHints.VALUE_ANTIALIAS_ON);
>>>>>
>>>>> Why do we need this ? Historically in the (non-OSX) code this
>>>>> would slow things down by making
>>>>> text rendering go via ductus rendering.
>>>>> If this really is a 'fontsHint' map, it seems it should not be here.
>>>>
>>>> I agree that this particular hint has no direct relation to the
>>>> font hints,
>>>> and probably should not be here. I guess that KEY_ANTALIASING was put
>>>> here in order to force text antialiasing on when default text
>>>> antailiasing is evaluating:
>>>>
>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/0e483e64c1e4/src/java.desktop/share/classes/sun/java2d/SurfaceData.java#l741
>>>>
>>>>
>>>> I do not think that it has any effect now, because we set text
>>>> antialiasing hint explicitly.
>>>> I will check whether it can be safely removed.
>>>>
>>>>> 410 sg2d.surfaceData.getTransparency() == Transparency.OPAQUE &&
>>>>>
>>>>> I thought you were removing this condition ?
>>>> I have rolled this change back, because at the moment lcd shader
>>>> produces ugly results in the case of translucent destination.
>>>> There is a separate bug regarding the translucent destination support:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8078516
>>>>
>>>> I am going to relax this condition when(if) our lcd shader will be
>>>> ready.
>>>>
>>>> In fact, this problem is not limited by ogl, because d3d and
>>>> software loops
>>>> has the same limitation.
>>>>
>>>>
>>>>>
>>>>> CGGlyphImages.m
>>>>>
>>>>> 202 #if __LITTLE_ENDIAN__
>>>>> 203 *(dst + 2) = 0xFF - (p >> 24 & 0xFF);
>>>>> 204 *(dst + 1) = 0xFF - (p >> 16 & 0xFF);
>>>>> 205 *(dst) = 0xFF - (p >> 8 & 0xFF);
>>>>> 206 #else
>>>>> 207 *(dst) = 0xFF - (p >> 16 & 0xFF);
>>>>> 208 *(dst + 1) = 0xFF - (p >> 8 & 0xFF);
>>>>> 209 *(dst + 2) = 0xFF - (p & 0xFF);
>>>>> 210 #endif
>>>>> 211 }
>>>>>
>>>>> became
>>>>> 217 {
>>>>> 218 *(dst + 0) = 0xFF - (p >> 16 & 0xFF); // red
>>>>> 219 *(dst + 1) = 0xFF - (p >> 8 & 0xFF); // green
>>>>> 220 *(dst + 2) = 0xFF - (p & 0xFF); // blue
>>>>> 221 }
>>>>>
>>>>>
>>>>> I started by assuming you were removing the BIG_ENDIAN code that
>>>>> was probably legacy PPC code but instead I see that the
>>>>> LITTLE_ENDIAN case is removed,
>>>>> so I don't understand this.
>>>>>
>>>>> And further down the file now I see that in
>>>>> ConvertBWPixelToByteGray you did remove the big endian case.
>>>>>
>>>>
>>>> Note that we are
>>>> Please note that we force the lcd glyph generation by requesting
>>>> host (i.e. LITTLE_ENDIAN) byte order for the canvas bitmap:
>>>>
>>>> 407 uint32_t bmpInfo = kCGImageAlphaPremultipliedFirst;
>>>> 408 if (mode->glyphDescriptor == &rgb) {
>>>> 409 bmpInfo |= kCGBitmapByteOrder32Host;
>>>> 410 }
>>>>
>>>> So, before the fix (and for grayscale case now) the buffer has default
>>>> BIG_ENDIAN order. I.e. grayscale canvas stores data in following
>>>> format:
>>>>
>>>> as bytes: A R G B
>>>> as int: 0xBBGGRRAA
>>>>
>>>> The same byte order was used for the rgb canvas before the fix.
>>>> But now the canvas is configured to store data in following format:
>>>>
>>>> as bytes: B G R A
>>>> as int: 0xAARRGGBB
>>>>
>>>> So, data extraction routines were updated accordingly.
>>>>
>>>>> 365 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_GASP:
>>>>> 366 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_DEFAULT:
>>>>> 367 default:
>>>>> 368 e = [NSException
>>>>> 369 exceptionWithName:@"IllegalArgumentException"
>>>>> 370 reason:@"Invalid hint value"
>>>>> 371 userInfo:nil];
>>>>>
>>>>>
>>>>> I think this means that by the time we get here we should not have
>>>>> DEFAULT or GASP
>>>>> but we should have the actual interpretation for this surface,
>>>>> font and point size.
>>>>> So this looks correct but maybe you can add a comment on this.
>>>>
>>>> will do.
>>>>
>>>>> The heuristic of blending black and white is interesting.
>>>>> How did you arrive at this ? It suggests that the glyph bitmap we
>>>>> are caching is
>>>>> not 'colour neutral' which is odd. Maybe we are missing code to apply
>>>>> the 'reverse gamma correction' ?
>>>>
>>>> I have played with the idea about 'reverse gamma correction', it
>>>> seemed very attractive to me.
>>>> Roughly speaking, gamma > 1 makes black-on-white glyphs a bit
>>>> narrower, and white-no-black
>>>> glyphs a bit wider (bolder?), and it is the same effect that we need.
>>>> Unfortunately, direct comparison of black-on-white and
>>>> white-on-black glyphs makes me think
>>>> that difference between these glyphs can not be explained only by
>>>> gamma correction.
>>>>
>>>> Please take a look at this screenshot:
>>>> http://cr.openjdk.java.net/~bae/8023794/bw-wb-comparision.png
>>>>
>>>>
>>>> row 1: text is rendered by jdk6 as-is.
>>>> row 2: simulates our pipeline where black-on-white glyphs are used
>>>> (max error on white-on-black)
>>>> row 3: simulates our pipeline where white-on-black glyphs are used
>>>> (max error on black-on-white)
>>>> row 4: blended glyphs are used.
>>>>
>>>> The basic idea of blending is to minimize max error (difference)
>>>> between produced glyph image
>>>> and original color-aware glyphs.
>>>>
>>>> If better results can be achieved with 'reverse gamma correction',
>>>> we can revise this code later.
>>>>
>>>>> And can (should) any of these changes also be applied to D3D ?
>>>>
>>>> 1. We can check how gamma correction is done in d3d. If a lookup is
>>>> also used there,
>>>> we can assess how rough the interpolation is.
>>>>
>>>> 2. translucent destination support (as a part of JDK-8078516)?
>>>>
>>>> Thanks,
>>>> Andrew
>>>>
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 03/27/2015 07:50 AM, Andrew Brygin wrote:
>>>>>> There is a minor update in the fix: it does not worth to blend
>>>>>> black-on-white
>>>>>> and white-on-black glyphs for the case of AA glyphs, because it
>>>>>> makes no difference.
>>>>>> CGGlyphImages.m, lines 294 - 325, 755 - 763, and 787 - 794:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~bae/8023794/9/webrev.08
>>>>>>
>>>>>> I have also modified the AntialiasDemo a bit in order to render the
>>>>>> sample text in different colors, and in order to render into a
>>>>>> volatile
>>>>>> image as well:
>>>>>> http://cr.openjdk.java.net/~bae/8023794/demo/AntialiasDemo.java
>>>>>>
>>>>>> It could be used to assess the change in glyph generation.
>>>>>>
>>>>>> Thanks,
>>>>>> Andrew
>>>>>>
>>>>>> On 3/26/2015 3:59 PM, Andrew Brygin wrote:
>>>>>>> Hi Chris,
>>>>>>>
>>>>>>> thank you for the comments and explanation. I have updated the
>>>>>>> OGLContext_IsLCDShaderSupportAvailable()
>>>>>>> and comments in OGLTextRenderer.c accordingly:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~bae/8023794/9/webrev.07/
>>>>>>>
>>>>>>> Good to know that you keep an eye on the OGL pipeline :)
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Andrew
>>>>>>>
>>>>>>> On 3/25/2015 8:24 PM, Chris Campbell wrote:
>>>>>>>> Hi Andrew,
>>>>>>>>
>>>>>>>> That's a good find re: pow(). In the comment at lines 277-283
>>>>>>>> I mentioned that there was only a scalar variant of pow(). I
>>>>>>>> wonder if that was a limitation in some early version of GLSL I
>>>>>>>> was using or perhaps some driver bug/restriction. According to
>>>>>>>> all the docs I can find the vector variants have been there all
>>>>>>>> along:
>>>>>>>> https://www.opengl.org/sdk/docs/man4/index.php
>>>>>>>>
>>>>>>>> So now I'm wondering if the slowness was actually due to me
>>>>>>>> trying 3 scalar pow() calls versus one vector pow() call.
>>>>>>>>
>>>>>>>> Oh, aha! I think this explains part of it:
>>>>>>>>
>>>>>>>> 269 * This is the GLSL fragment shader source code for
>>>>>>>> rendering LCD-optimized
>>>>>>>> 270 * text. Do not be frightened; it is much easier to
>>>>>>>> understand than the
>>>>>>>> 271 * equivalent ASM-like fragment program!
>>>>>>>>
>>>>>>>> Looks like I wrote the original version of this shader using
>>>>>>>> the GL_ARB_fragment_program language, which indeed only had a
>>>>>>>> scalar POW instruction (see section 3.11.5.20):
>>>>>>>> https://www.opengl.org/registry/specs/ARB/fragment_program.txt
>>>>>>>>
>>>>>>>> And then I'm guessing that when I rewrote it in more modern
>>>>>>>> GLSL, I didn't notice that pow() supported vectors. Sigh. That
>>>>>>>> 3D texture LUT was a lot of work for a whole lot of nothing.
>>>>>>>>
>>>>>>>> In any case, you might want to rewrite the comment at lines
>>>>>>>> 277-283 to suit the new code. Same goes for the comment at
>>>>>>>> line 315:
>>>>>>>>
>>>>>>>> // gamma adjust the dest color using the invgamma LUT
>>>>>>>>
>>>>>>>> Also, I noticed that the restrictions in
>>>>>>>> OGLContext_IsLCDShaderSupportAvailable() could be loosened
>>>>>>>> since you only need 2 texture units now. Just in the extremely
>>>>>>>> unlikely case that anyone's running this stuff on ancient
>>>>>>>> hardware :)
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Chris
>>>>>>>>
>>>>>>>>
>>>>>>>> Andrew Brygin wrote:
>>>>>>>>> Hello Phil,
>>>>>>>>>
>>>>>>>>> could you please take a look to updated version of the fix?
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~bae/8023794/9/webrev.06/
>>>>>>>>>
>>>>>>>>> * OGLTextRenderer.c
>>>>>>>>> It was discovered, that in some cases lcd glyphs had visible
>>>>>>>>> 'dark
>>>>>>>>> border' around.
>>>>>>>>> This border appeared due to the gamma correction in lcd
>>>>>>>>> shader, which
>>>>>>>>> uses lookup
>>>>>>>>> on 3D texture instead of using 'pow' routine. The texture is
>>>>>>>>> populated
>>>>>>>>> with significant
>>>>>>>>> granularity (16 points per edge), what is a root cause of rough
>>>>>>>>> interpolation of color values.
>>>>>>>>> Suggested change is to eliminate the interpolation and use
>>>>>>>>> 'pow' routine
>>>>>>>>> directly.
>>>>>>>>> It gives more accurate color values, and does not introduce
>>>>>>>>> significant
>>>>>>>>> performance hit
>>>>>>>>> (see benchmark summary below).
>>>>>>>>> However, this part of the fix affects not only macosx, but any
>>>>>>>>> platform
>>>>>>>>> where OGL text
>>>>>>>>> shader can be used, so it probably worth to split into a
>>>>>>>>> separate fix.
>>>>>>>>>
>>>>>>>>> Summary:
>>>>>>>>> lcd-ogl-3Dlookup:
>>>>>>>>> Number of tests: 4
>>>>>>>>> Overall average: 42.68027553311743
>>>>>>>>> Best spread: 3.49% variance
>>>>>>>>> Worst spread: 29.59% variance
>>>>>>>>> (Basis for results comparison)
>>>>>>>>>
>>>>>>>>> lcd-ogl-pow:
>>>>>>>>> Number of tests: 4
>>>>>>>>> Overall average: 42.468941501367084
>>>>>>>>> Best spread: 2.51% variance
>>>>>>>>> Worst spread: 29.44% variance
>>>>>>>>> Comparison to basis:
>>>>>>>>> Best result: 103.28% of basis
>>>>>>>>> Worst result: 97.36% of basis
>>>>>>>>> Number of wins: 1
>>>>>>>>> Number of ties: 2
>>>>>>>>> Number of losses: 1
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Andrew
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
From volker.simonis at gmail.com Wed May 27 17:01:43 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 27 May 2015 19:01:43 +0200
Subject: [OpenJDK 2D-Dev] RFR: 8035302: Eliminate dependency on
sun.nio.cs from AWT and Motif code
In-Reply-To: <5526E05E.5010906@oracle.com>
References: <54E7ABB8.7010901@oracle.com> <54E7B587.70904@oracle.com>
<54E8499F.7060706@oracle.com> <55074BDE.1050602@oracle.com>
<550B14BF.3040209@oracle.com> <550B91D3.6000406@oracle.com>
<550C9375.8070404@oracle.com> <55133B36.5040109@oracle.com>
<5526D222.3080308@oracle.com> <5526E05E.5010906@oracle.com>
Message-ID:
Hi everybody,
sorry, but as usually, I'm a little late to the game:)
This change, along with change "8073152: Update
Standard/ExtendedCharsets to work with module system" causes build
failures on AIX.
It took me some time to dig trough the build system, but I think that
I at least have a weak understanding of what's going on now:
So this change removes the dependencies of the 'java.desktop' module
on the 'jdk.charsets' module or to be more precise, it removes
'java.desktop's dependency on sun.nio.cs.ext.
But unfortunately this only works on the current Oracle-supported
platforms. The following dependencies still exist:
sun.font.X11GB2312 -> sun.nio.cs.EUC_CN
sun.font.X11GBK -> sun.nio.cs.GBK
sun.font.X11KSC5601 -> sun.nio.cs.EUC_KR
Before this change, the classes X11GB2312, X11GBK and X11KSC5601 were
located in sun.awt.motif and they imported both "sun.nio.cs.*" and
"sun.nio.cs.ext.*". After this change, they only import
"sun.nio.cs.*", so if the required character sets aren?t located in
the standard charsets package but in the extended one, this won't work
any more.
On the Oracle platforms this still works because both Linux and
Solaris put the corresponding charsets (i.e. X11GB2312, X11GBK and
X11KSC5601) into the standard charsets package sun.nio.cs by using the
two configuration files jdk/make/data/charsetmapping/stdcs-linux and
jdk/make/data/charsetmapping/stdcs-solaris. On MacOS X the build still
works because the sun.font.* classes are excluded from the
'java.desktop' module altogether (see java.desktop_EXCLUDE_FILES in
make/CompileJavaModules.gmk).
On AIX the build fails because there the corresponding charsets (i.e.
X11GB2312, X11GBK and X11KSC5601) are in the extended charsets package
by default and there's no jdk/make/data/charsetmapping/stdcs-aix
configuration files which remaps them to "sun.nio.cs.*".
I can easily fix this by introducing a new
jdk/make/data/charsetmapping/stdcs-aix configuration file which maps
X11GB2312, X11GBK and X11KSC5601 to "sun.nio.cs.*" (and I'll do that
with a follow-up change request to fix the build as soon as possible).
But still the question remains if this is the "right way" to solve
this problem? I.e. if some sun.font.XXX classes depend on some
character sets being in "sun.nio.cs.*", shouldn't this be ensured
automatically without the need of keeping some per-platform
configuration files up to date?
And what is actually the exact semantics of the "stdcs-solaris" and
"stdcs-linux" files? For example it seems strange to me that
"JIS_X_0212_Solaris" is made a standard charset on Linux. As far as I
can see, it is enough to move the three charsets EUC_CN, GBK and
EUC_KR to "sun.nio.cs.*" in order to satisfy the new build
dependencies.
So maybe we should just declare this correctly right in the
"jdk/make/data/charsetmapping/charsets" file or otherwise have a
special "stdcs-REQUIRED" file for these three charsets and leave the
platform dependent files for _real_ platform specific customizations.
What do you think?
Thank you and best regards,
Volker
On Thu, Apr 9, 2015 at 10:26 PM, Phil Race wrote:
> Old "notes to self" from an earlier revision. I'll delete before pushing.
>
> -phil.
>
>
> On 04/09/2015 12:25 PM, Mandy Chung wrote:
>
> On 3/25/15 3:48 PM, Phil Race wrote:
>
> Updated webrev http://cr.openjdk.java.net/~prr/8035302.2/
>
> sun/font/XMap.java
> + jclass = "JIS0201"; // CHECK
> + jclass = "MS950_HKSCS_XP"; // CHECK
> What is the CHECK comment? Otherwise, looks okay. Thank you for
> removing java.desktop dependency to jdk.charsets.
>
>
> Mandy
>
>
From philip.race at oracle.com Wed May 27 17:14:20 2015
From: philip.race at oracle.com (Phil Race)
Date: Wed, 27 May 2015 10:14:20 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8035302: Eliminate dependency on
sun.nio.cs from AWT and Motif code
In-Reply-To:
References: <54E7ABB8.7010901@oracle.com> <54E7B587.70904@oracle.com>
<54E8499F.7060706@oracle.com> <55074BDE.1050602@oracle.com>
<550B14BF.3040209@oracle.com> <550B91D3.6000406@oracle.com>
<550C9375.8070404@oracle.com> <55133B36.5040109@oracle.com>
<5526D222.3080308@oracle.com> <5526E05E.5010906@oracle.com>
Message-ID: <5565FB6C.5060705@oracle.com>
Hi Volker,
Sorry for breaking AIX but I think it may be more related to these bugs
https://bugs.openjdk.java.net/browse/JDK-8073152
https://bugs.openjdk.java.net/browse/JDK-8073893
8035302 then takes advantage of these but did not create/update
the per-platform configuration. I think the variance is
in part about putting into base only what has to be there
to support boot-strapping and known dependencies whilst
otherwise keeping base as small as possible.
-phil.
On 05/27/2015 10:01 AM, Volker Simonis wrote:
> Hi everybody,
>
> sorry, but as usually, I'm a little late to the game:)
>
> This change, along with change "8073152: Update
> Standard/ExtendedCharsets to work with module system" causes build
> failures on AIX.
>
> It took me some time to dig trough the build system, but I think that
> I at least have a weak understanding of what's going on now:
>
> So this change removes the dependencies of the 'java.desktop' module
> on the 'jdk.charsets' module or to be more precise, it removes
> 'java.desktop's dependency on sun.nio.cs.ext.
>
> But unfortunately this only works on the current Oracle-supported
> platforms. The following dependencies still exist:
>
> sun.font.X11GB2312 -> sun.nio.cs.EUC_CN
> sun.font.X11GBK -> sun.nio.cs.GBK
> sun.font.X11KSC5601 -> sun.nio.cs.EUC_KR
>
> Before this change, the classes X11GB2312, X11GBK and X11KSC5601 were
> located in sun.awt.motif and they imported both "sun.nio.cs.*" and
> "sun.nio.cs.ext.*". After this change, they only import
> "sun.nio.cs.*", so if the required character sets aren?t located in
> the standard charsets package but in the extended one, this won't work
> any more.
>
> On the Oracle platforms this still works because both Linux and
> Solaris put the corresponding charsets (i.e. X11GB2312, X11GBK and
> X11KSC5601) into the standard charsets package sun.nio.cs by using the
> two configuration files jdk/make/data/charsetmapping/stdcs-linux and
> jdk/make/data/charsetmapping/stdcs-solaris. On MacOS X the build still
> works because the sun.font.* classes are excluded from the
> 'java.desktop' module altogether (see java.desktop_EXCLUDE_FILES in
> make/CompileJavaModules.gmk).
>
> On AIX the build fails because there the corresponding charsets (i.e.
> X11GB2312, X11GBK and X11KSC5601) are in the extended charsets package
> by default and there's no jdk/make/data/charsetmapping/stdcs-aix
> configuration files which remaps them to "sun.nio.cs.*".
>
> I can easily fix this by introducing a new
> jdk/make/data/charsetmapping/stdcs-aix configuration file which maps
> X11GB2312, X11GBK and X11KSC5601 to "sun.nio.cs.*" (and I'll do that
> with a follow-up change request to fix the build as soon as possible).
>
> But still the question remains if this is the "right way" to solve
> this problem? I.e. if some sun.font.XXX classes depend on some
> character sets being in "sun.nio.cs.*", shouldn't this be ensured
> automatically without the need of keeping some per-platform
> configuration files up to date?
>
> And what is actually the exact semantics of the "stdcs-solaris" and
> "stdcs-linux" files? For example it seems strange to me that
> "JIS_X_0212_Solaris" is made a standard charset on Linux. As far as I
> can see, it is enough to move the three charsets EUC_CN, GBK and
> EUC_KR to "sun.nio.cs.*" in order to satisfy the new build
> dependencies.
>
> So maybe we should just declare this correctly right in the
> "jdk/make/data/charsetmapping/charsets" file or otherwise have a
> special "stdcs-REQUIRED" file for these three charsets and leave the
> platform dependent files for _real_ platform specific customizations.
> What do you think?
>
> Thank you and best regards,
> Volker
>
>
> On Thu, Apr 9, 2015 at 10:26 PM, Phil Race wrote:
>> Old "notes to self" from an earlier revision. I'll delete before pushing.
>>
>> -phil.
>>
>>
>> On 04/09/2015 12:25 PM, Mandy Chung wrote:
>>
>> On 3/25/15 3:48 PM, Phil Race wrote:
>>
>> Updated webrev http://cr.openjdk.java.net/~prr/8035302.2/
>>
>> sun/font/XMap.java
>> + jclass = "JIS0201"; // CHECK
>> + jclass = "MS950_HKSCS_XP"; // CHECK
>> What is the CHECK comment? Otherwise, looks okay. Thank you for
>> removing java.desktop dependency to jdk.charsets.
>>
>>
>> Mandy
>>
>>
From philip.race at oracle.com Wed May 27 17:18:53 2015
From: philip.race at oracle.com (Phil Race)
Date: Wed, 27 May 2015 10:18:53 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8035302: Eliminate dependency on
sun.nio.cs from AWT and Motif code
In-Reply-To: <5565FB6C.5060705@oracle.com>
References: <54E7ABB8.7010901@oracle.com> <54E7B587.70904@oracle.com>
<54E8499F.7060706@oracle.com> <55074BDE.1050602@oracle.com>
<550B14BF.3040209@oracle.com> <550B91D3.6000406@oracle.com>
<550C9375.8070404@oracle.com> <55133B36.5040109@oracle.com>
<5526D222.3080308@oracle.com> <5526E05E.5010906@oracle.com>
<5565FB6C.5060705@oracle.com>
Message-ID: <5565FC7D.4030801@oracle.com>
Oh .. I see how 8035302 would be implicated on AIX.
It was the removal of the now redundant wildcard "ext" imports for the
Oracle
platforms in the X11 charsets that no longer mattered for those but
still did for AIX.
Most probably what you propose as quick solution is best but I'll defer to
Xueming and Alan to expand on my take on the reasons for this.
-phil.
On 05/27/2015 10:14 AM, Phil Race wrote:
> Hi Volker,
>
> Sorry for breaking AIX but I think it may be more related to these bugs
> https://bugs.openjdk.java.net/browse/JDK-8073152
> https://bugs.openjdk.java.net/browse/JDK-8073893
>
> 8035302 then takes advantage of these but did not create/update
> the per-platform configuration. I think the variance is
> in part about putting into base only what has to be there
> to support boot-strapping and known dependencies whilst
> otherwise keeping base as small as possible.
>
> -phil.
>
> On 05/27/2015 10:01 AM, Volker Simonis wrote:
>> Hi everybody,
>>
>> sorry, but as usually, I'm a little late to the game:)
>>
>> This change, along with change "8073152: Update
>> Standard/ExtendedCharsets to work with module system" causes build
>> failures on AIX.
>>
>> It took me some time to dig trough the build system, but I think that
>> I at least have a weak understanding of what's going on now:
>>
>> So this change removes the dependencies of the 'java.desktop' module
>> on the 'jdk.charsets' module or to be more precise, it removes
>> 'java.desktop's dependency on sun.nio.cs.ext.
>>
>> But unfortunately this only works on the current Oracle-supported
>> platforms. The following dependencies still exist:
>>
>> sun.font.X11GB2312 -> sun.nio.cs.EUC_CN
>> sun.font.X11GBK -> sun.nio.cs.GBK
>> sun.font.X11KSC5601 -> sun.nio.cs.EUC_KR
>>
>> Before this change, the classes X11GB2312, X11GBK and X11KSC5601 were
>> located in sun.awt.motif and they imported both "sun.nio.cs.*" and
>> "sun.nio.cs.ext.*". After this change, they only import
>> "sun.nio.cs.*", so if the required character sets aren?t located in
>> the standard charsets package but in the extended one, this won't work
>> any more.
>>
>> On the Oracle platforms this still works because both Linux and
>> Solaris put the corresponding charsets (i.e. X11GB2312, X11GBK and
>> X11KSC5601) into the standard charsets package sun.nio.cs by using the
>> two configuration files jdk/make/data/charsetmapping/stdcs-linux and
>> jdk/make/data/charsetmapping/stdcs-solaris. On MacOS X the build still
>> works because the sun.font.* classes are excluded from the
>> 'java.desktop' module altogether (see java.desktop_EXCLUDE_FILES in
>> make/CompileJavaModules.gmk).
>>
>> On AIX the build fails because there the corresponding charsets (i.e.
>> X11GB2312, X11GBK and X11KSC5601) are in the extended charsets package
>> by default and there's no jdk/make/data/charsetmapping/stdcs-aix
>> configuration files which remaps them to "sun.nio.cs.*".
>>
>> I can easily fix this by introducing a new
>> jdk/make/data/charsetmapping/stdcs-aix configuration file which maps
>> X11GB2312, X11GBK and X11KSC5601 to "sun.nio.cs.*" (and I'll do that
>> with a follow-up change request to fix the build as soon as possible).
>>
>> But still the question remains if this is the "right way" to solve
>> this problem? I.e. if some sun.font.XXX classes depend on some
>> character sets being in "sun.nio.cs.*", shouldn't this be ensured
>> automatically without the need of keeping some per-platform
>> configuration files up to date?
>>
>> And what is actually the exact semantics of the "stdcs-solaris" and
>> "stdcs-linux" files? For example it seems strange to me that
>> "JIS_X_0212_Solaris" is made a standard charset on Linux. As far as I
>> can see, it is enough to move the three charsets EUC_CN, GBK and
>> EUC_KR to "sun.nio.cs.*" in order to satisfy the new build
>> dependencies.
>>
>> So maybe we should just declare this correctly right in the
>> "jdk/make/data/charsetmapping/charsets" file or otherwise have a
>> special "stdcs-REQUIRED" file for these three charsets and leave the
>> platform dependent files for _real_ platform specific customizations.
>> What do you think?
>>
>> Thank you and best regards,
>> Volker
>>
>>
>> On Thu, Apr 9, 2015 at 10:26 PM, Phil Race
>> wrote:
>>> Old "notes to self" from an earlier revision. I'll delete before
>>> pushing.
>>>
>>> -phil.
>>>
>>>
>>> On 04/09/2015 12:25 PM, Mandy Chung wrote:
>>>
>>> On 3/25/15 3:48 PM, Phil Race wrote:
>>>
>>> Updated webrev http://cr.openjdk.java.net/~prr/8035302.2/
>>>
>>> sun/font/XMap.java
>>> + jclass = "JIS0201"; // CHECK
>>> + jclass = "MS950_HKSCS_XP"; // CHECK
>>> What is the CHECK comment? Otherwise, looks okay. Thank you for
>>> removing java.desktop dependency to jdk.charsets.
>>>
>>>
>>> Mandy
>>>
>>>
>
From volker.simonis at gmail.com Wed May 27 17:52:15 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 27 May 2015 19:52:15 +0200
Subject: [OpenJDK 2D-Dev] RFR(XS): 8081332: AIX: fix charset dependenicies
after 8035302:Eliminate dependency on jdk.charsets from 2D font code.
Message-ID:
Hi,
can you please review the following small build fix for AIX:
http://cr.openjdk.java.net/~simonis/webrevs/2015/8081332/
https://bugs.openjdk.java.net/browse/JDK-8081332
The bug as well as the discussion at
http://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005431.html
contain all the gory details and some other suggestions to fix this,
but I think for now this is the simplest and most non-intrusive,
AIX-only way to get the build on AIX up and running again.
Thanks,
Volker
From volker.simonis at gmail.com Wed May 27 17:53:18 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 27 May 2015 19:53:18 +0200
Subject: [OpenJDK 2D-Dev] RFR: 8035302: Eliminate dependency on
sun.nio.cs from AWT and Motif code
In-Reply-To: <5565FC7D.4030801@oracle.com>
References: <54E7ABB8.7010901@oracle.com> <54E7B587.70904@oracle.com>
<54E8499F.7060706@oracle.com> <55074BDE.1050602@oracle.com>
<550B14BF.3040209@oracle.com> <550B91D3.6000406@oracle.com>
<550C9375.8070404@oracle.com> <55133B36.5040109@oracle.com>
<5526D222.3080308@oracle.com> <5526E05E.5010906@oracle.com>
<5565FB6C.5060705@oracle.com> <5565FC7D.4030801@oracle.com>
Message-ID:
Hi Phil,
thanks for looking at this.
On Wed, May 27, 2015 at 7:18 PM, Phil Race wrote:
> Oh .. I see how 8035302 would be implicated on AIX.
> It was the removal of the now redundant wildcard "ext" imports for the
> Oracle
> platforms in the X11 charsets that no longer mattered for those but still
> did for AIX.
>
Yes, that's exactly the problem.
> Most probably what you propose as quick solution is best but I'll defer to
> Xueming and Alan to expand on my take on the reasons for this.
>
I've just opened https://bugs.openjdk.java.net/browse/JDK-8081332 for
this and posted a RFR on 2d-dev.
Regards,
Volker
> -phil.
>
>
> On 05/27/2015 10:14 AM, Phil Race wrote:
>>
>> Hi Volker,
>>
>> Sorry for breaking AIX but I think it may be more related to these bugs
>> https://bugs.openjdk.java.net/browse/JDK-8073152
>> https://bugs.openjdk.java.net/browse/JDK-8073893
>>
>> 8035302 then takes advantage of these but did not create/update
>> the per-platform configuration. I think the variance is
>> in part about putting into base only what has to be there
>> to support boot-strapping and known dependencies whilst
>> otherwise keeping base as small as possible.
>>
>> -phil.
>>
>> On 05/27/2015 10:01 AM, Volker Simonis wrote:
>>>
>>> Hi everybody,
>>>
>>> sorry, but as usually, I'm a little late to the game:)
>>>
>>> This change, along with change "8073152: Update
>>> Standard/ExtendedCharsets to work with module system" causes build
>>> failures on AIX.
>>>
>>> It took me some time to dig trough the build system, but I think that
>>> I at least have a weak understanding of what's going on now:
>>>
>>> So this change removes the dependencies of the 'java.desktop' module
>>> on the 'jdk.charsets' module or to be more precise, it removes
>>> 'java.desktop's dependency on sun.nio.cs.ext.
>>>
>>> But unfortunately this only works on the current Oracle-supported
>>> platforms. The following dependencies still exist:
>>>
>>> sun.font.X11GB2312 -> sun.nio.cs.EUC_CN
>>> sun.font.X11GBK -> sun.nio.cs.GBK
>>> sun.font.X11KSC5601 -> sun.nio.cs.EUC_KR
>>>
>>> Before this change, the classes X11GB2312, X11GBK and X11KSC5601 were
>>> located in sun.awt.motif and they imported both "sun.nio.cs.*" and
>>> "sun.nio.cs.ext.*". After this change, they only import
>>> "sun.nio.cs.*", so if the required character sets aren?t located in
>>> the standard charsets package but in the extended one, this won't work
>>> any more.
>>>
>>> On the Oracle platforms this still works because both Linux and
>>> Solaris put the corresponding charsets (i.e. X11GB2312, X11GBK and
>>> X11KSC5601) into the standard charsets package sun.nio.cs by using the
>>> two configuration files jdk/make/data/charsetmapping/stdcs-linux and
>>> jdk/make/data/charsetmapping/stdcs-solaris. On MacOS X the build still
>>> works because the sun.font.* classes are excluded from the
>>> 'java.desktop' module altogether (see java.desktop_EXCLUDE_FILES in
>>> make/CompileJavaModules.gmk).
>>>
>>> On AIX the build fails because there the corresponding charsets (i.e.
>>> X11GB2312, X11GBK and X11KSC5601) are in the extended charsets package
>>> by default and there's no jdk/make/data/charsetmapping/stdcs-aix
>>> configuration files which remaps them to "sun.nio.cs.*".
>>>
>>> I can easily fix this by introducing a new
>>> jdk/make/data/charsetmapping/stdcs-aix configuration file which maps
>>> X11GB2312, X11GBK and X11KSC5601 to "sun.nio.cs.*" (and I'll do that
>>> with a follow-up change request to fix the build as soon as possible).
>>>
>>> But still the question remains if this is the "right way" to solve
>>> this problem? I.e. if some sun.font.XXX classes depend on some
>>> character sets being in "sun.nio.cs.*", shouldn't this be ensured
>>> automatically without the need of keeping some per-platform
>>> configuration files up to date?
>>>
>>> And what is actually the exact semantics of the "stdcs-solaris" and
>>> "stdcs-linux" files? For example it seems strange to me that
>>> "JIS_X_0212_Solaris" is made a standard charset on Linux. As far as I
>>> can see, it is enough to move the three charsets EUC_CN, GBK and
>>> EUC_KR to "sun.nio.cs.*" in order to satisfy the new build
>>> dependencies.
>>>
>>> So maybe we should just declare this correctly right in the
>>> "jdk/make/data/charsetmapping/charsets" file or otherwise have a
>>> special "stdcs-REQUIRED" file for these three charsets and leave the
>>> platform dependent files for _real_ platform specific customizations.
>>> What do you think?
>>>
>>> Thank you and best regards,
>>> Volker
>>>
>>>
>>> On Thu, Apr 9, 2015 at 10:26 PM, Phil Race
>>> wrote:
>>>>
>>>> Old "notes to self" from an earlier revision. I'll delete before
>>>> pushing.
>>>>
>>>> -phil.
>>>>
>>>>
>>>> On 04/09/2015 12:25 PM, Mandy Chung wrote:
>>>>
>>>> On 3/25/15 3:48 PM, Phil Race wrote:
>>>>
>>>> Updated webrev http://cr.openjdk.java.net/~prr/8035302.2/
>>>>
>>>> sun/font/XMap.java
>>>> + jclass = "JIS0201"; // CHECK
>>>> + jclass = "MS950_HKSCS_XP"; // CHECK
>>>> What is the CHECK comment? Otherwise, looks okay. Thank you for
>>>> removing java.desktop dependency to jdk.charsets.
>>>>
>>>>
>>>> Mandy
>>>>
>>>>
>>
>
From philip.race at oracle.com Wed May 27 18:09:50 2015
From: philip.race at oracle.com (Phil Race)
Date: Wed, 27 May 2015 11:09:50 -0700
Subject: [OpenJDK 2D-Dev] [9] Review Request: JDK-8041900
[macosx] Java forces the use of discrete GPU
In-Reply-To: <0043AB18-6F14-42E0-9453-F0A74A11450D@gmail.com>
References:
<5565D518.1070001@oracle.com>
<0043AB18-6F14-42E0-9453-F0A74A11450D@gmail.com>
Message-ID: <5566086E.6050706@oracle.com>
I suppose that NSOpenGLPFAAllowOfflineRenderers must prevent whatever 'tickling'
of the discrete GPU we do from automatically making it the active GPU ?
This seems to merit a source code comment as at face value it seems like an API that allows
you to use that (other) discrete GPU alongside the active GPU, but so we don't
need that part, just the side-effect behaviour.
But do we want this fix in this form ? The integrated GPU is going to perform far less well
than the discrete GPU. If the issue is battery life, then perhaps it should be tied
to whether we are running on battery or mains power. And then perhaps you need to figure out
how to switch GPU on the fly when you go from mains to battery.
-phil.
On 05/27/2015 08:08 AM, Denis Fokin wrote:
> Hi, Sergey,
>
> Basically, you should close all apps that can switch the vc including the utility for switching video cards. Make sure in About This Mac -> Displays that the integrated card is enabled. Start an application with the patched version of Java. Check About This Mac -> Displays. Integrated video card should be still active.
>
>
>
>> 27 ??? 2015 ?., ? 17:30, Sergey Bylokhov ???????(?):
>>
>> Hi, Denis.
>> Can you describe the steps on how to test it. On my mac it still change the vc.
>>
>>> On 27.05.15 17:16, Denis Fokin wrote:
>>> Please review the fix for jdk9
>>>
>>> The fix allows do not force discrete video card usage on MacBook Pro models with two video cards. I have tested the fix on several MPBs.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8041900
>>> Webrev: http://cr.openjdk.java.net/~denis/8041900/webrev.00
>>
>> --
>> Best regards, Sergey.
>>
From philip.race at oracle.com Wed May 27 18:11:40 2015
From: philip.race at oracle.com (Phil Race)
Date: Wed, 27 May 2015 11:11:40 -0700
Subject: [OpenJDK 2D-Dev] RFR(XS): 8081332: AIX: fix charset
dependenicies after 8035302:Eliminate dependency on jdk.charsets from 2D
font code.
In-Reply-To:
References:
Message-ID: <556608DC.7040203@oracle.com>
+1.
-phil.
On 05/27/2015 10:52 AM, Volker Simonis wrote:
> Hi,
>
> can you please review the following small build fix for AIX:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8081332/
> https://bugs.openjdk.java.net/browse/JDK-8081332
>
> The bug as well as the discussion at
> http://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005431.html
> contain all the gory details and some other suggestions to fix this,
> but I think for now this is the simplest and most non-intrusive,
> AIX-only way to get the build on AIX up and running again.
>
> Thanks,
> Volker
From denis.fokin at gmail.com Wed May 27 21:44:27 2015
From: denis.fokin at gmail.com (Denis Fokin)
Date: Thu, 28 May 2015 00:44:27 +0300
Subject: [OpenJDK 2D-Dev] [9] Review Request: JDK-8041900
[macosx] Java forces the use of discrete GPU
In-Reply-To: <5566086E.6050706@oracle.com>
References:
<5565D518.1070001@oracle.com>
<0043AB18-6F14-42E0-9453-F0A74A11450D@gmail.com>
<5566086E.6050706@oracle.com>
Message-ID: <4B9151A0-1072-4F57-AB2F-57A28F0F24B8@gmail.com>
Hi Phil,
Thank you for the comments. Actually, the battery life is not the only issue that experience our customers. I am getting crash reports that are reproducible only with discrete cards on MBP. Some users report hangs with discrete cards. All this issues are eliminated by switching on the integrated GPU. I am not sure, that discrete card gives significant performance improvement in jdk implementation. Other applications, like Chrome, use discrete video card only for WebGl or similar tasks.
Thank you,
Denis
> 27 ??? 2015 ?., ? 21:09, Phil Race ???????(?):
>
> I suppose that NSOpenGLPFAAllowOfflineRenderers must prevent whatever 'tickling'
> of the discrete GPU we do from automatically making it the active GPU ?
>
> This seems to merit a source code comment as at face value it seems like an API that allows
> you to use that (other) discrete GPU alongside the active GPU, but so we don't
> need that part, just the side-effect behaviour.
>
> But do we want this fix in this form ? The integrated GPU is going to perform far less well
> than the discrete GPU. If the issue is battery life, then perhaps it should be tied
> to whether we are running on battery or mains power. And then perhaps you need to figure out
> how to switch GPU on the fly when you go from mains to battery.
>
>
> -phil.
>
>
>
>> On 05/27/2015 08:08 AM, Denis Fokin wrote:
>> Hi, Sergey,
>>
>> Basically, you should close all apps that can switch the vc including the utility for switching video cards. Make sure in About This Mac -> Displays that the integrated card is enabled. Start an application with the patched version of Java. Check About This Mac -> Displays. Integrated video card should be still active.
>>
>>
>>
>>> 27 ??? 2015 ?., ? 17:30, Sergey Bylokhov ???????(?):
>>>
>>> Hi, Denis.
>>> Can you describe the steps on how to test it. On my mac it still change the vc.
>>>
>>>> On 27.05.15 17:16, Denis Fokin wrote:
>>>> Please review the fix for jdk9
>>>>
>>>> The fix allows do not force discrete video card usage on MacBook Pro models with two video cards. I have tested the fix on several MPBs.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8041900
>>>> Webrev: http://cr.openjdk.java.net/~denis/8041900/webrev.00
>>>
>>> --
>>> Best regards, Sergey.
>
From philip.race at oracle.com Wed May 27 21:53:07 2015
From: philip.race at oracle.com (Phil Race)
Date: Wed, 27 May 2015 14:53:07 -0700
Subject: [OpenJDK 2D-Dev] [9] Review Request: JDK-8041900
[macosx] Java forces the use of discrete GPU
In-Reply-To: <4B9151A0-1072-4F57-AB2F-57A28F0F24B8@gmail.com>
References:
<5565D518.1070001@oracle.com>
<0043AB18-6F14-42E0-9453-F0A74A11450D@gmail.com>
<5566086E.6050706@oracle.com>
<4B9151A0-1072-4F57-AB2F-57A28F0F24B8@gmail.com>
Message-ID: <55663CC3.6070303@oracle.com>
Hello Denis,
Once lots of people start to use the integrated CPU I suppose there is a
non-zero
likelihood of crashes and other problems with that too.
I would like to see this (a) selected based on battery or similar, not
fixed,
(b) made controllable by a flag or similar,
and once that is done, get a lot of JDK9 bake time.
To be suitable for JDK 8u it would have to be "off by default".
-phil.
On 05/27/2015 02:44 PM, Denis Fokin wrote:
> Hi Phil,
>
> Thank you for the comments. Actually, the battery life is not the only issue that experience our customers. I am getting crash reports that are reproducible only with discrete cards on MBP. Some users report hangs with discrete cards. All this issues are eliminated by switching on the integrated GPU. I am not sure, that discrete card gives significant performance improvement in jdk implementation. Other applications, like Chrome, use discrete video card only for WebGl or similar tasks.
>
> Thank you,
> Denis
>
>
>> 27 ??? 2015 ?., ? 21:09, Phil Race ???????(?):
>>
>> I suppose that NSOpenGLPFAAllowOfflineRenderers must prevent whatever 'tickling'
>> of the discrete GPU we do from automatically making it the active GPU ?
>>
>> This seems to merit a source code comment as at face value it seems like an API that allows
>> you to use that (other) discrete GPU alongside the active GPU, but so we don't
>> need that part, just the side-effect behaviour.
>>
>> But do we want this fix in this form ? The integrated GPU is going to perform far less well
>> than the discrete GPU. If the issue is battery life, then perhaps it should be tied
>> to whether we are running on battery or mains power. And then perhaps you need to figure out
>> how to switch GPU on the fly when you go from mains to battery.
>>
>>
>> -phil.
>>
>>
>>
>>> On 05/27/2015 08:08 AM, Denis Fokin wrote:
>>> Hi, Sergey,
>>>
>>> Basically, you should close all apps that can switch the vc including the utility for switching video cards. Make sure in About This Mac -> Displays that the integrated card is enabled. Start an application with the patched version of Java. Check About This Mac -> Displays. Integrated video card should be still active.
>>>
>>>
>>>
>>>> 27 ??? 2015 ?., ? 17:30, Sergey Bylokhov ???????(?):
>>>>
>>>> Hi, Denis.
>>>> Can you describe the steps on how to test it. On my mac it still change the vc.
>>>>
>>>>> On 27.05.15 17:16, Denis Fokin wrote:
>>>>> Please review the fix for jdk9
>>>>>
>>>>> The fix allows do not force discrete video card usage on MacBook Pro models with two video cards. I have tested the fix on several MPBs.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8041900
>>>>> Webrev: http://cr.openjdk.java.net/~denis/8041900/webrev.00
>>>> --
>>>> Best regards, Sergey.
From james.graham at oracle.com Thu May 28 00:02:10 2015
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 27 May 2015 17:02:10 -0700
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8080847 Copying of
overlapping memory should be improved in java2d
In-Reply-To: <55659E18.8040903@oracle.com>
References: <5563172D.4080605@oracle.com> <556374FD.4020501@oracle.com> <556378C7.6090807@oracle.com> <55644E47.4040008@oracle.com>
<55645A46.70506@oracle.com> <5564BB02.40703@oracle.com>
<55659E18.8040903@oracle.com>
Message-ID: <55665B02.3020904@oracle.com>
I see no evidence that it can crash. Again, undefined does not mean
"can crash". Someone joked on that thread that they should probably
make memcpy crash on overlapping memory moves in a future release, but I
don't see any evidence that anyone took them seriously. The entire
thread is more about whether or not they should make the "undefined"
results consistent with historical versions of "undefined".
Having it switch from reliably, though unexpectedly, smearing one
direction to reliably, and also unexpectedly, smearing in another
direction - which is what the discussion you linked to is about - is
consistent with "undefined". I still see this as no reason to change
the code. They do discuss making memcpy default to memmove under the
covers, but I didn't see buy-in for that and there were only vague
references to "there is a patch already in flight that does what Bob
said". Even if it did default to memmove, then I still don't see that
as a reason to change any code here. It is still undefined since the
macro doesn't deal with overlaps in the Y direction and it doesn't
affect all platforms.
If we change the default blit to reliably always "do the right thing"
regardless of blit direction then we set the expectation that drawing an
image onto itself will always behave responsibly and then we invite the
bug that it will fail for XOR, or alpha composites/extra alpha, or
stretching or rotating. Until we are ready to commit to that, I don't
see any value in making this one version of blit "do the right thing".
For now, we do not promise any defined behavior for copying an image
onto itself. If we want to tackle that, then I'd support adding that
guarantee to our behaviors, but it should be done comprehensively - not
by making a change that only affects part of one implementation...
...jim
On 5/27/2015 3:36 AM, Sergey Bylokhov wrote:
> On 26.05.15 21:27, Jim Graham wrote:
>> Undefined doesn't mean "may crash" in this case, it means that the
>> contents of memory may not match what you would expect if the regions
>> overlap because it is just a dump copy loop that does not do any
>> aliasing checks.
> Since it is undefined it can crash, but even if it is not, it can
> produce the different results for the same application on different cpu.
> Because it can copy data in any direction based on the current cpu. It
> is not a simple copy loop. see discussion [1] for example.
> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=12518
> https://sourceware.org/bugzilla/show_bug.cgi?id=12518#c3
>
> I still insist that it is the simplest fix, which will relieve us of
> randomness and will bring into accord with the native specification. It
> is similar to this rule: Swing should be accessed on the EDT.
> Application can work for decades and contradict this rule, but can be
> broken in any updates of Swing.
>
>>
>> Is there a way to silence the warning? In this particular case we are
>> totally OK with the undefined behavior, in fact, the accidental
>> behavior that they are calling "undefined" because it is confusing to
>> most developers who don't know enough to worry about aliased memory
>> regions - is actually the behavior we want because it will match the
>> results of all of the other blits.
>>
>> If there is no way to silence the tool, then I'd recommend hard-coding
>> our own "dumb copy loop" instead so that the behavior continues to
>> match what memcpy should have been doing.
>>
>> Do not just fix this in the vertical direction as well - if you
>> continue on a path that makes the aliasing not happen then I will
>> insist that you modify all drawimage paths to all deal gracefully with
>> memory aliasing and write an extensive test suite to make sure that we
>> correctly manage the aliasing in all cases, all composite modes, the
>> bg versions as well as the non-bg versions, scaled and transformed
>> blits, etc. If you are not prepared to do all of that, then we should
>> drop this attempt to fix a "bug" that is really code working as
>> (un)expected and focus instead on silencing the warning...
>>
>> ...jim
>>
>> On 5/26/2015 4:34 AM, Sergey Bylokhov wrote:
>>> On 26.05.15 13:43, Jim Graham wrote:
>>>> What crash in memcpy?
>>> Simply because behavior of this function is undefined if the two arrays
>>> "to" and "from" overlap. Plus this clears an output for the tools like
>>> valgrind and some other issues can be found easily.
>>>
>>>> The issue you pointed to is about dealing with overlapping memory.
>>>> memcpy does not crash on overlapping memory copies, it just duplicates
>>>> data oddly in a way that most uses probably don't want.
>>>>
>>>> Also, the fix you gave only fixed the problem for the horizontal
>>>> direction, if the drawImage call were directed at 0,1 then we'd still
>>>> get all scan lines duplicated from the first...
>>> Right, I can take a look to this bug too.
>>>>
>>>> ...jim
>>>>
>>>> On 5/25/2015 12:32 PM, Sergey Bylokhov wrote:
>>>>> Hi, Jim.
>>>>> Actually there is a difference in support: it works but result is a
>>>>> little bit wrong, and it does not work and crashes. This fix is not a
>>>>> general solution for the incorrect result of the blit+aliasing, but
>>>>> for
>>>>> the possible crash of memcpy especially after some improvements
>>>>> like in
>>>>> glibc. I think this still an issue.
>>>>>
>>>>>> I don't recall if we ever promised that this case would work without
>>>>>> aliasing issues. I know that we went out of our way in the copyArea
>>>>>> method to prevent the aliasing issue, doing the blits piecemeal so
>>>>>> that they don't interfere with each other. Further, while it may be
>>>>>> easy enough to just call memmove to have the libraray do this for us
>>>>>> in the IsoBlit case, other cases that don't fall into the IsoBlit
>>>>>> macro will not be similarly protected. In particular, if you specify
>>>>>> an alpha value, you will not get this protection (at least not
>>>>>> without
>>>>>> a huge amount of work to overhaul the entire DrawImage pipeline).
>>>>>>
>>>>>> I would say that this would be OK if we planned to make this promise
>>>>>> about drawImage across all image formats and composition modes, but
>>>>>> that would be a far more complicated fix. Until then, we should not
>>>>>> open this can of worms by modifying this one specific Blit case...
>>>>>>
>>>>>> ...jim
>>>>>>
>>>>>> On 5/25/2015 5:35 AM, Sergey Bylokhov wrote:
>>>>>>> Hello.
>>>>>>> Please review the fix forjdk9.
>>>>>>>
>>>>>>> I found this issue during code review of another task, related to
>>>>>>> performance.
>>>>>>>
>>>>>>> The sample code below will call the IsomorphicCopy method which call
>>>>>>> memcpy on the overlapping memory(this is the simplest example)
>>>>>>>
>>>>>>> BufferedImage img = new BufferedImage(100, 100,
>>>>>>> BufferedImage.TYPE_INT_ARGB_PRE);
>>>>>>> Graphics2D g = img.createGraphics();
>>>>>>> g.setComposite(AlphaComposite.Src);
>>>>>>> g.drawImage(img, 0, 0, null);
>>>>>>> g.dispose();
>>>>>>>
>>>>>>> http://linux.die.net/man/3/memcpy
>>>>>>> "The memcpy() function copies n bytes from memory area src to memory
>>>>>>> area dest. The memory areas must not overlap. Use memmove(3) if the
>>>>>>> memory areas do overlap"
>>>>>>>
>>>>>>>
>>>>>>> I can confirm this bug using valgrind and a program above:
>>>>>>> command:
>>>>>>> valgrind --smc-check=all --tool=memcheck --leak-check=full -v
>>>>>>> ./9/client/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/java
>>>>>>>
>>>>>>>
>>>>>>> -Xint
>>>>>>> Main
>>>>>>>
>>>>>>> output:
>>>>>>> ==60975== Source and destination overlap in memcpy(0xe1b8b4d8,
>>>>>>> 0xe1b8b4d8, 400)
>>>>>>> ==60975== at 0x4C2F71C: memcpy@@GLIBC_2.14 (in
>>>>>>> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
>>>>>>> ==60975== by 0x1E0F504D: AnyIntIsomorphicCopy (in
>>>>>>> /moe/workspaces/jdk/9/client-work/build/linux-x86_64-normal-server-fastdebug/images/jdk/lib/amd64/libawt.so)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ==60975== by 0x1E0F5DE8: Java_sun_java2d_loops_Blit_Blit (in
>>>>>>> /moe/workspaces/jdk/9/client-work/build/linux-x86_64-normal-server-fastdebug/images/jdk/lib/amd64/libawt.so)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8080847
>>>>>>> Webrev can be found at:
>>>>>>> http://cr.openjdk.java.net/~serb/8080847/webrev.00
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
From james.graham at oracle.com Thu May 28 00:06:59 2015
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 27 May 2015 17:06:59 -0700
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8080847 Copying of
overlapping memory should be improved in java2d
In-Reply-To: <5565A275.2040909@redhat.com>
References: <5563172D.4080605@oracle.com> <556374FD.4020501@oracle.com> <556378C7.6090807@oracle.com> <55644E47.4040008@oracle.com>
<55645A46.70506@oracle.com> <5564BB02.40703@oracle.com>
<55659E18.8040903@oracle.com> <5565A275.2040909@redhat.com>
Message-ID: <55665C23.2090801@oracle.com>
Where do you see evidence that it can crash?
...jim
On 5/27/2015 3:54 AM, Andrew Haley wrote:
> On 05/27/2015 11:36 AM, Sergey Bylokhov wrote:
>> On 26.05.15 21:27, Jim Graham wrote:
>>> Undefined doesn't mean "may crash" in this case, it means that the
>>> contents of memory may not match what you would expect if the regions
>>> overlap because it is just a dump copy loop that does not do any
>>> aliasing checks.
>> Since it is undefined it can crash, but even if it is not, it can
>> produce the different results for the same application on different cpu.
>
> Definitely. It certainly can crash. There is no way that we should
> tolerate UB in any code which is part of Java. We can just use
> memmove().
>
> Andrew.
>
>
From torgeir.veimo at gmail.com Thu May 28 00:30:45 2015
From: torgeir.veimo at gmail.com (Torgeir Veimo)
Date: Thu, 28 May 2015 10:30:45 +1000
Subject: [OpenJDK 2D-Dev] [9] Review Request: JDK-8041900
[macosx] Java forces the use of discrete GPU
In-Reply-To: <55663CC3.6070303@oracle.com>
References:
<5565D518.1070001@oracle.com>
<0043AB18-6F14-42E0-9453-F0A74A11450D@gmail.com>
<5566086E.6050706@oracle.com>
<4B9151A0-1072-4F57-AB2F-57A28F0F24B8@gmail.com>
<55663CC3.6070303@oracle.com>
Message-ID:
This is one of the bugs that prevent IDEA to switching to JDK7/8 for
IntelliJ by default. The JDK is perceived by a lot of users as an
ill-behaved application on OS X because it forces use of the discrete
GPU, drastically reducing battery life.
This patch didn't work for me either, on a 2014 15" retina mbp.
On 28 May 2015 at 07:53, Phil Race wrote:
> Hello Denis,
>
> Once lots of people start to use the integrated CPU I suppose there is a
> non-zero
> likelihood of crashes and other problems with that too.
> I would like to see this (a) selected based on battery or similar, not
> fixed,
> (b) made controllable by a flag or similar,
> and once that is done, get a lot of JDK9 bake time.
> To be suitable for JDK 8u it would have to be "off by default".
>
> -phil.
>
>
> On 05/27/2015 02:44 PM, Denis Fokin wrote:
>>
>> Hi Phil,
>>
>> Thank you for the comments. Actually, the battery life is not the only
>> issue that experience our customers. I am getting crash reports that are
>> reproducible only with discrete cards on MBP. Some users report hangs with
>> discrete cards. All this issues are eliminated by switching on the
>> integrated GPU. I am not sure, that discrete card gives significant
>> performance improvement in jdk implementation. Other applications, like
>> Chrome, use discrete video card only for WebGl or similar tasks.
>>
>> Thank you,
>> Denis
>>
>>
>>> 27 ??? 2015 ?., ? 21:09, Phil Race ???????(?):
>>>
>>> I suppose that NSOpenGLPFAAllowOfflineRenderers must prevent whatever
>>> 'tickling'
>>> of the discrete GPU we do from automatically making it the active GPU ?
>>>
>>> This seems to merit a source code comment as at face value it seems like
>>> an API that allows
>>> you to use that (other) discrete GPU alongside the active GPU, but so we
>>> don't
>>> need that part, just the side-effect behaviour.
>>>
>>> But do we want this fix in this form ? The integrated GPU is going to
>>> perform far less well
>>> than the discrete GPU. If the issue is battery life, then perhaps it
>>> should be tied
>>> to whether we are running on battery or mains power. And then perhaps you
>>> need to figure out
>>> how to switch GPU on the fly when you go from mains to battery.
>>>
>>>
>>> -phil.
>>>
>>>
>>>
>>>> On 05/27/2015 08:08 AM, Denis Fokin wrote:
>>>> Hi, Sergey,
>>>>
>>>> Basically, you should close all apps that can switch the vc including
>>>> the utility for switching video cards. Make sure in About This Mac ->
>>>> Displays that the integrated card is enabled. Start an application with the
>>>> patched version of Java. Check About This Mac -> Displays. Integrated video
>>>> card should be still active.
>>>>
>>>>
>>>>
>>>>> 27 ??? 2015 ?., ? 17:30, Sergey Bylokhov
>>>>> ???????(?):
>>>>>
>>>>> Hi, Denis.
>>>>> Can you describe the steps on how to test it. On my mac it still change
>>>>> the vc.
>>>>>
>>>>>> On 27.05.15 17:16, Denis Fokin wrote:
>>>>>> Please review the fix for jdk9
>>>>>>
>>>>>> The fix allows do not force discrete video card usage on MacBook Pro
>>>>>> models with two video cards. I have tested the fix on several MPBs.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8041900
>>>>>> Webrev: http://cr.openjdk.java.net/~denis/8041900/webrev.00
>>>>>>
>>>>>
>>>>> --
>>>>> Best regards, Sergey.
>
>
--
-Tor
From yasuenag at gmail.com Thu May 28 03:19:45 2015
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Thu, 28 May 2015 12:19:45 +0900
Subject: [OpenJDK 2D-Dev] JDK-8081295: Build failed with GCC 5.1.1
Message-ID: <55668951.9070309@gmail.com>
Hi all,
I tried to build jdk9/dev on Fedora22 with GCC 5.1.1, however, it was failed.
I found several problems:
System:
Fedora release 22 (Twenty Two) x86_64
- gcc-5.1.1-1.fc22.x86_64
Problems:
1. Array bounds check in GCC
- jdk/src/java.desktop/share/native/libjavajpeg/jcmaster.c
- jdk/src/java.desktop/share/native/libjavajpeg/jquant1.c
- jdk/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_64.c
- jdk/src/java.desktop/share/native/libmlib_image/mlib_c_ImageLookUp_f.c
It seems to be bug of GCC:
Bug 59124: [4.8/4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
I think implementations of these files have no problem.
So I propose to ignore warning(s) of compiler through pragma option as
workaround when we use GCC [1].
2. Local variables might be clobbered
- jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c
SplashDecodePng() calls setjmp(3).
Some local variables initialize before setjmp() call, and use after it.
Their initial values are only used at cleanup code (*done* label) and
actual values are stored only after setjmp() call.
So I think we can ignore this error through pragma option [1].
3. Incorrect condition
- jdk/src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.c
searchAllSourceNames() returns int value. However, branch condition in
eventFilterRestricted_passesFilter() treats it as boolean value.
I received a comment from Erik to use --disable-warnings-as-errors,
however I could not avoid error in 3.
Thanks,
Yasumasa
[1] https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html
From yasuenag at gmail.com Thu May 28 03:27:15 2015
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Thu, 28 May 2015 12:27:15 +0900
Subject: [OpenJDK 2D-Dev] JDK-8081295: Build failed with GCC 5.1.1
In-Reply-To: <55668951.9070309@gmail.com>
References: <55668951.9070309@gmail.com>
Message-ID: <55668B13.1000303@gmail.com>
I've uploaded webrev:
http://cr.openjdk.java.net/~ysuenaga/JDK-8081295/webrev.01/
Please review.
Thanks,
Yasumasa
On 2015/05/28 12:19, Yasumasa Suenaga wrote:
> Hi all,
>
> I tried to build jdk9/dev on Fedora22 with GCC 5.1.1, however, it was failed.
> I found several problems:
>
>
> System:
> Fedora release 22 (Twenty Two) x86_64
> - gcc-5.1.1-1.fc22.x86_64
>
>
> Problems:
> 1. Array bounds check in GCC
> - jdk/src/java.desktop/share/native/libjavajpeg/jcmaster.c
> - jdk/src/java.desktop/share/native/libjavajpeg/jquant1.c
> - jdk/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_64.c
> - jdk/src/java.desktop/share/native/libmlib_image/mlib_c_ImageLookUp_f.c
>
> It seems to be bug of GCC:
> Bug 59124: [4.8/4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds"
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
>
> I think implementations of these files have no problem.
> So I propose to ignore warning(s) of compiler through pragma option as
> workaround when we use GCC [1].
>
>
> 2. Local variables might be clobbered
> - jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c
>
> SplashDecodePng() calls setjmp(3).
> Some local variables initialize before setjmp() call, and use after it.
> Their initial values are only used at cleanup code (*done* label) and
> actual values are stored only after setjmp() call.
> So I think we can ignore this error through pragma option [1].
>
>
> 3. Incorrect condition
> - jdk/src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.c
>
> searchAllSourceNames() returns int value. However, branch condition in
> eventFilterRestricted_passesFilter() treats it as boolean value.
>
>
> I received a comment from Erik to use --disable-warnings-as-errors,
> however I could not avoid error in 3.
>
>
> Thanks,
>
> Yasumasa
>
>
> [1] https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html
>
From Alan.Bateman at oracle.com Thu May 28 07:24:20 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 28 May 2015 08:24:20 +0100
Subject: [OpenJDK 2D-Dev] RFR: 8035302: Eliminate dependency on
sun.nio.cs from AWT and Motif code
In-Reply-To: <5565FB6C.5060705@oracle.com>
References: <54E7ABB8.7010901@oracle.com> <54E7B587.70904@oracle.com>
<54E8499F.7060706@oracle.com> <55074BDE.1050602@oracle.com>
<550B14BF.3040209@oracle.com> <550B91D3.6000406@oracle.com>
<550C9375.8070404@oracle.com> <55133B36.5040109@oracle.com>
<5526D222.3080308@oracle.com> <5526E05E.5010906@oracle.com>
<5565FB6C.5060705@oracle.com>
Message-ID: <5566C2A4.6040504@oracle.com>
On 27/05/2015 18:14, Phil Race wrote:
> Hi Volker,
>
> Sorry for breaking AIX but I think it may be more related to these bugs
> https://bugs.openjdk.java.net/browse/JDK-8073152
> https://bugs.openjdk.java.net/browse/JDK-8073893
>
> 8035302 then takes advantage of these but did not create/update
> the per-platform configuration. I think the variance is
> in part about putting into base only what has to be there
> to support boot-strapping and known dependencies whilst
> otherwise keeping base as small as possible.
Right, and I assume for AIX that the Volker will need to identify the
charsets needed to start-up in the environments where the AIX port is
supported. This is what the stdcs-* files are about and why some
charsets are generated to sun.nio.cs on some platforms and
sun.nio.cs.ext on others.
-Alan.
From aph at redhat.com Thu May 28 07:58:00 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 28 May 2015 08:58:00 +0100
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8080847 Copying of
overlapping memory should be improved in java2d
In-Reply-To: <55665C23.2090801@oracle.com>
References: <5563172D.4080605@oracle.com> <556374FD.4020501@oracle.com> <556378C7.6090807@oracle.com> <55644E47.4040008@oracle.com>
<55645A46.70506@oracle.com> <5564BB02.40703@oracle.com>
<55659E18.8040903@oracle.com> <5565A275.2040909@redhat.com>
<55665C23.2090801@oracle.com>
Message-ID: <5566CA88.2080200@redhat.com>
On 28/05/15 01:06, Jim Graham wrote:
> Where do you see evidence that it can crash?
It's what the language specification says. Undefined behaviour is
unconstrained: it can do anything. Demons might fly out of your nose.
We have seen with GCC that apparently "harmless" code (a read just
beyond the end of an array) can, for example, result in an infinite
loop. In this case, it is quite possible that GCC could infer that
the two memory regions accessed by memcpy do not overlap.
Andrew.
From volker.simonis at gmail.com Thu May 28 09:10:51 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 28 May 2015 11:10:51 +0200
Subject: [OpenJDK 2D-Dev] RFR: 8035302: Eliminate dependency on
sun.nio.cs from AWT and Motif code
In-Reply-To: <5566C2A4.6040504@oracle.com>
References: <54E7ABB8.7010901@oracle.com> <54E7B587.70904@oracle.com>
<54E8499F.7060706@oracle.com> <55074BDE.1050602@oracle.com>
<550B14BF.3040209@oracle.com> <550B91D3.6000406@oracle.com>
<550C9375.8070404@oracle.com> <55133B36.5040109@oracle.com>
<5526D222.3080308@oracle.com> <5526E05E.5010906@oracle.com>
<5565FB6C.5060705@oracle.com> <5566C2A4.6040504@oracle.com>
Message-ID:
On Thu, May 28, 2015 at 9:24 AM, Alan Bateman wrote:
> On 27/05/2015 18:14, Phil Race wrote:
>>
>> Hi Volker,
>>
>> Sorry for breaking AIX but I think it may be more related to these bugs
>> https://bugs.openjdk.java.net/browse/JDK-8073152
>> https://bugs.openjdk.java.net/browse/JDK-8073893
>>
>> 8035302 then takes advantage of these but did not create/update
>> the per-platform configuration. I think the variance is
>> in part about putting into base only what has to be there
>> to support boot-strapping and known dependencies whilst
>> otherwise keeping base as small as possible.
>
> Right, and I assume for AIX that the Volker will need to identify the
> charsets needed to start-up in the environments where the AIX port is
> supported. This is what the stdcs-* files are about and why some charsets
> are generated to sun.nio.cs on some platforms and sun.nio.cs.ext on others.
>
Yes, but as I wrote, there is a hard dependency from some of the
sun.font classes to some non-standard charsets:
sun.font.X11GB2312 -> sun.nio.cs.EUC_CN
sun.font.X11GBK -> sun.nio.cs.GBK
sun.font.X11KSC5601 -> sun.nio.cs.EUC_KR
If I decide that I don't want to put EUC_CN in the set of standard
charsets on a specific OS, I won't be able to build. I have opened
https://bugs.openjdk.java.net/browse/JDK-8081332 for this issue and
have an easy fix out for review which just adds the corresponding
stdcs-aix file on AIX.
But still I think it is bad that compiling the sun.font.* package
which is part of the 'java.desktop' module requires the manual
maintenance of an OS-dependent 'stdcs-' file. I think it would be
much better if either all the charsets referenced by 'sun.font.*' are
in the standard charset by default or the other way round if we only
reference standard charsets from 'sun.font.*'.
Regards,
Volker
> -Alan.
From alexander.zvegintsev at oracle.com Thu May 28 09:18:31 2015
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 28 May 2015 12:18:31 +0300
Subject: [OpenJDK 2D-Dev] JDK-8081295: Build failed with GCC 5.1.1
In-Reply-To: <55668B13.1000303@gmail.com>
References: <55668951.9070309@gmail.com> <55668B13.1000303@gmail.com>
Message-ID: <5566DD67.9000301@oracle.com>
Hello Yasumasa,
I prefer to avoid such pragma usage, as for me code is more readable
without it.
So we can add array-bounds to DISABLED_WARNINGS_gcc in
make/lib/Awt2dLibraries.gmk for BUILD_LIBJAVAJPEG and BUILD_LIBMLIB_IMAGE.
We can nullify row_pointers and image_data after setjmp call to remove
warnings in splashscreen_png.c:
diff -r 729dffc8afa0
src/java.desktop/share/native/libsplashscreen/splashscreen_png.c
--- a/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c
+++ b/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c
@@ -77,6 +77,8 @@ SplashDecodePng(Splash * splash, png_rw_
#else
if (setjmp(png_jmpbuf(png_ptr))) {
#endif
+ row_pointers = NULL;
+ image_data = NULL;
goto done;
}
(or declare them as volatile, but I prefer the first option).
BTW, there is another issue about this splashscreen_png.c gcc build
failure [1].
[1] https://bugs.openjdk.java.net/browse/JDK-8080695
Thanks,
Alexander.
On 05/28/2015 06:27 AM, Yasumasa Suenaga wrote:
> I've uploaded webrev:
> http://cr.openjdk.java.net/~ysuenaga/JDK-8081295/webrev.01/
>
> Please review.
>
>
> Thanks,
>
> Yasumasa
>
>
> On 2015/05/28 12:19, Yasumasa Suenaga wrote:
>> Hi all,
>>
>> I tried to build jdk9/dev on Fedora22 with GCC 5.1.1, however, it was failed.
>> I found several problems:
>>
>>
>> System:
>> Fedora release 22 (Twenty Two) x86_64
>> - gcc-5.1.1-1.fc22.x86_64
>>
>>
>> Problems:
>> 1. Array bounds check in GCC
>> - jdk/src/java.desktop/share/native/libjavajpeg/jcmaster.c
>> - jdk/src/java.desktop/share/native/libjavajpeg/jquant1.c
>> - jdk/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_64.c
>> - jdk/src/java.desktop/share/native/libmlib_image/mlib_c_ImageLookUp_f.c
>>
>> It seems to be bug of GCC:
>> Bug 59124: [4.8/4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds"
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
>>
>> I think implementations of these files have no problem.
>> So I propose to ignore warning(s) of compiler through pragma option as
>> workaround when we use GCC [1].
>>
>>
>> 2. Local variables might be clobbered
>> - jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c
>>
>> SplashDecodePng() calls setjmp(3).
>> Some local variables initialize before setjmp() call, and use after it.
>> Their initial values are only used at cleanup code (*done* label) and
>> actual values are stored only after setjmp() call.
>> So I think we can ignore this error through pragma option [1].
>>
>>
>> 3. Incorrect condition
>> - jdk/src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.c
>>
>> searchAllSourceNames() returns int value. However, branch condition in
>> eventFilterRestricted_passesFilter() treats it as boolean value.
>>
>>
>> I received a comment from Erik to use --disable-warnings-as-errors,
>> however I could not avoid error in 3.
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> [1] https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html
>>
From Alan.Bateman at oracle.com Thu May 28 09:27:06 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 28 May 2015 10:27:06 +0100
Subject: [OpenJDK 2D-Dev] RFR: 8035302: Eliminate dependency on
sun.nio.cs from AWT and Motif code
In-Reply-To:
References: <54E7ABB8.7010901@oracle.com> <54E7B587.70904@oracle.com> <54E8499F.7060706@oracle.com> <55074BDE.1050602@oracle.com> <550B14BF.3040209@oracle.com> <550B91D3.6000406@oracle.com> <550C9375.8070404@oracle.com> <55133B36.5040109@oracle.com> <5526D222.3080308@oracle.com> <5526E05E.5010906@oracle.com> <5565FB6C.5060705@oracle.com> <5566C2A4.6040504@oracle.com>
Message-ID: <5566DF6A.2030102@oracle.com>
On 28/05/2015 10:10, Volker Simonis wrote:
> :
> Yes, but as I wrote, there is a hard dependency from some of the
> sun.font classes to some non-standard charsets:
>
> sun.font.X11GB2312 -> sun.nio.cs.EUC_CN
> sun.font.X11GBK -> sun.nio.cs.GBK
> sun.font.X11KSC5601 -> sun.nio.cs.EUC_KR
>
> If I decide that I don't want to put EUC_CN in the set of standard
> charsets on a specific OS, I won't be able to build. I have opened
> https://bugs.openjdk.java.net/browse/JDK-8081332 for this issue and
> have an easy fix out for review which just adds the corresponding
> stdcs-aix file on AIX.
>
> But still I think it is bad that compiling the sun.font.* package
> which is part of the 'java.desktop' module requires the manual
> maintenance of an OS-dependent 'stdcs-' file. I think it would be
> much better if either all the charsets referenced by 'sun.font.*' are
> in the standard charset by default or the other way round if we only
> reference standard charsets from 'sun.font.*'.
>
Footprint is a concern for java.base so this is why it only contains the
6 standard charsets and any additional charsets that are needed to run
in supported configurations. For the AIX port then the size of java.base
might not be a concern and you might decide to put most or all of the
extended charsets into java.base.
It would be nice if sun.font.* did not directly depend on sun.nio.cs.*.
One of Phil's initial patches attempted to address this but at the cost
of copying charset code into the java.desktop module. Some of us have
maintenance concerns with doing that. Our main goal wasn't to address
this long standing dependency, instead it was to address the dependency
on classes in the provider module. Maybe it's time to re-visit the
dependency on sun.nio.cs too.
-Alan.
From yasuenag at gmail.com Thu May 28 11:52:49 2015
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Thu, 28 May 2015 20:52:49 +0900
Subject: [OpenJDK 2D-Dev] JDK-8081295: Build failed with GCC 5.1.1
In-Reply-To:
References: <55668951.9070309@gmail.com> <55668B13.1000303@gmail.com>
<5566DD67.9000301@oracle.com>
Message-ID:
Hi Alexander,
Thank you for your comment.
I agree to use DISABLED_WARNINGS_gcc.
Should I make a patch after JDK-8080695
committed?
Thanks,
Yasumasa
2015/05/28 18:19 "Alexander Zvegintsev" :
Hello Yasumasa,
I prefer to avoid such pragma usage, as for me code is more readable
without it.
So we can add array-bounds to DISABLED_WARNINGS_gcc in
make/lib/Awt2dLibraries.gmk for BUILD_LIBJAVAJPEG and BUILD_LIBMLIB_IMAGE.
We can nullify row_pointers and image_data after setjmp call to remove
warnings in splashscreen_png.c:
diff -r 729dffc8afa0
src/java.desktop/share/native/libsplashscreen/splashscreen_png.c
--- a/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c
+++ b/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c
@@ -77,6 +77,8 @@ SplashDecodePng(Splash * splash, png_rw_
#else
if (setjmp(png_jmpbuf(png_ptr))) {
#endif
+ row_pointers = NULL;
+ image_data = NULL;
goto done;
}
(or declare them as volatile, but I prefer the first option).
BTW, there is another issue about this splashscreen_png.c gcc build failure
[1].
[1] https://bugs.openjdk.java.net/browse/JDK-8080695
Thanks,
Alexander.
On 05/28/2015 06:27 AM, Yasumasa Suenaga wrote:
> I've uploaded webrev:
> http://cr.openjdk.java.net/~ysuenaga/JDK-8081295/webrev.01/
>
> Please review.
>
>
> Thanks,
>
> Yasumasa
>
>
> On 2015/05/28 12:19, Yasumasa Suenaga wrote:
>
>> Hi all,
>>
>> I tried to build jdk9/dev on Fedora22 with GCC 5.1.1, however, it was
>> failed.
>> I found several problems:
>>
>>
>> System:
>> Fedora release 22 (Twenty Two) x86_64
>> - gcc-5.1.1-1.fc22.x86_64
>>
>>
>> Problems:
>> 1. Array bounds check in GCC
>> - jdk/src/java.desktop/share/native/libjavajpeg/jcmaster.c
>> - jdk/src/java.desktop/share/native/libjavajpeg/jquant1.c
>> -
>> jdk/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_64.c
>> -
>> jdk/src/java.desktop/share/native/libmlib_image/mlib_c_ImageLookUp_f.c
>>
>> It seems to be bug of GCC:
>> Bug 59124: [4.8/4.9/5/6 Regression] Wrong warnings "array
>> subscript is above array bounds"
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
>>
>> I think implementations of these files have no problem.
>> So I propose to ignore warning(s) of compiler through pragma
>> option as
>> workaround when we use GCC [1].
>>
>>
>> 2. Local variables might be clobbered
>> -
>> jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c
>>
>> SplashDecodePng() calls setjmp(3).
>> Some local variables initialize before setjmp() call, and use
>> after it.
>> Their initial values are only used at cleanup code (*done* label)
>> and
>> actual values are stored only after setjmp() call.
>> So I think we can ignore this error through pragma option [1].
>>
>>
>> 3. Incorrect condition
>> - jdk/src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.c
>>
>> searchAllSourceNames() returns int value. However, branch
>> condition in
>> eventFilterRestricted_passesFilter() treats it as boolean value.
>>
>>
>> I received a comment from Erik to use --disable-warnings-as-errors,
>> however I could not avoid error in 3.
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> [1] https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From alexander.zvegintsev at oracle.com Thu May 28 13:00:20 2015
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 28 May 2015 16:00:20 +0300
Subject: [OpenJDK 2D-Dev] JDK-8081295: Build failed with GCC 5.1.1
In-Reply-To:
References: <55668951.9070309@gmail.com> <55668B13.1000303@gmail.com> <5566DD67.9000301@oracle.com>
Message-ID: <55671164.6070309@oracle.com>
I think that you can just exclude libsplashscreen part from your fix,
since it is covered by JDK-8080695.
Thanks,
Alexander.
On 05/28/2015 02:52 PM, Yasumasa Suenaga wrote:
>
> Hi Alexander,
>
> Thank you for your comment.
>
> I agree to use DISABLED_WARNINGS_gcc.
>
> Should I make a patch afterJDK-8080695
> committed?
>
> Thanks,
>
> Yasumasa
>
> 2015/05/28 18:19 "Alexander Zvegintsev"
> >:
>
> Hello Yasumasa,
>
> I prefer to avoid such pragma usage, as for me code is more
> readable without it.
> So we can add array-bounds to DISABLED_WARNINGS_gcc in
> make/lib/Awt2dLibraries.gmk for BUILD_LIBJAVAJPEG and
> BUILD_LIBMLIB_IMAGE.
>
> We can nullify row_pointers and image_data after setjmp call to
> remove warnings in splashscreen_png.c:
> diff -r 729dffc8afa0
> src/java.desktop/share/native/libsplashscreen/splashscreen_png.c
> --- a/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c
> +++ b/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c
> @@ -77,6 +77,8 @@ SplashDecodePng(Splash * splash, png_rw_
> #else
> if (setjmp(png_jmpbuf(png_ptr))) {
> #endif
> + row_pointers = NULL;
> + image_data = NULL;
> goto done;
> }
> (or declare them as volatile, but I prefer the first option).
> BTW, there is another issue about this splashscreen_png.c gcc
> build failure [1].
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8080695
>
> Thanks,
>
> Alexander.
>
>
> On 05/28/2015 06:27 AM, Yasumasa Suenaga wrote:
>
> I've uploaded webrev:
> http://cr.openjdk.java.net/~ysuenaga/JDK-8081295/webrev.01/
>
>
> Please review.
>
>
> Thanks,
>
> Yasumasa
>
>
> On 2015/05/28 12:19, Yasumasa Suenaga wrote:
>
> Hi all,
>
> I tried to build jdk9/dev on Fedora22 with GCC 5.1.1,
> however, it was failed.
> I found several problems:
>
>
> System:
> Fedora release 22 (Twenty Two) x86_64
> - gcc-5.1.1-1.fc22.x86_64
>
>
> Problems:
> 1. Array bounds check in GCC
> -
> jdk/src/java.desktop/share/native/libjavajpeg/jcmaster.c
> -
> jdk/src/java.desktop/share/native/libjavajpeg/jquant1.c
> -
> jdk/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_64.c
> -
> jdk/src/java.desktop/share/native/libmlib_image/mlib_c_ImageLookUp_f.c
>
> It seems to be bug of GCC:
> Bug 59124: [4.8/4.9/5/6 Regression] Wrong
> warnings "array subscript is above array bounds"
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
>
> I think implementations of these files have no problem.
> So I propose to ignore warning(s) of compiler
> through pragma option as
> workaround when we use GCC [1].
>
>
> 2. Local variables might be clobbered
> -
> jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c
>
> SplashDecodePng() calls setjmp(3).
> Some local variables initialize before setjmp()
> call, and use after it.
> Their initial values are only used at cleanup code
> (*done* label) and
> actual values are stored only after setjmp() call.
> So I think we can ignore this error through pragma
> option [1].
>
>
> 3. Incorrect condition
> -
> jdk/src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.c
>
> searchAllSourceNames() returns int value. However,
> branch condition in
> eventFilterRestricted_passesFilter() treats it as
> boolean value.
>
>
> I received a comment from Erik to use
> --disable-warnings-as-errors,
> however I could not avoid error in 3.
>
>
> Thanks,
>
> Yasumasa
>
>
> [1] https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From volker.simonis at gmail.com Thu May 28 14:11:54 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 28 May 2015 16:11:54 +0200
Subject: [OpenJDK 2D-Dev] RFR: 8035302: Eliminate dependency on
sun.nio.cs from AWT and Motif code
In-Reply-To: <5566DF6A.2030102@oracle.com>
References: <54E7ABB8.7010901@oracle.com> <54E7B587.70904@oracle.com>
<54E8499F.7060706@oracle.com> <55074BDE.1050602@oracle.com>
<550B14BF.3040209@oracle.com> <550B91D3.6000406@oracle.com>
<550C9375.8070404@oracle.com> <55133B36.5040109@oracle.com>
<5526D222.3080308@oracle.com> <5526E05E.5010906@oracle.com>
<5565FB6C.5060705@oracle.com> <5566C2A4.6040504@oracle.com>
<5566DF6A.2030102@oracle.com>
Message-ID:
On Thu, May 28, 2015 at 11:27 AM, Alan Bateman wrote:
> On 28/05/2015 10:10, Volker Simonis wrote:
>>
>> :
>> Yes, but as I wrote, there is a hard dependency from some of the
>> sun.font classes to some non-standard charsets:
>>
>> sun.font.X11GB2312 -> sun.nio.cs.EUC_CN
>> sun.font.X11GBK -> sun.nio.cs.GBK
>> sun.font.X11KSC5601 -> sun.nio.cs.EUC_KR
>>
>> If I decide that I don't want to put EUC_CN in the set of standard
>> charsets on a specific OS, I won't be able to build. I have opened
>> https://bugs.openjdk.java.net/browse/JDK-8081332 for this issue and
>> have an easy fix out for review which just adds the corresponding
>> stdcs-aix file on AIX.
>>
>> But still I think it is bad that compiling the sun.font.* package
>> which is part of the 'java.desktop' module requires the manual
>> maintenance of an OS-dependent 'stdcs-' file. I think it would be
>> much better if either all the charsets referenced by 'sun.font.*' are
>> in the standard charset by default or the other way round if we only
>> reference standard charsets from 'sun.font.*'.
>>
> Footprint is a concern for java.base so this is why it only contains the 6
> standard charsets and any additional charsets that are needed to run in
> supported configurations. For the AIX port then the size of java.base might
> not be a concern and you might decide to put most or all of the extended
> charsets into java.base.
>
> It would be nice if sun.font.* did not directly depend on sun.nio.cs.*. One
> of Phil's initial patches attempted to address this but at the cost of
> copying charset code into the java.desktop module. Some of us have
> maintenance concerns with doing that. Our main goal wasn't to address this
> long standing dependency, instead it was to address the dependency on
> classes in the provider module. Maybe it's time to re-visit the dependency
> on sun.nio.cs too.
>
I'm happy with the current solution (i.e. providing a corresponding
'stdcs-aix' file) and footprint isn't an issue on AIX indeed. All I
wanted to say is that if you are using 'sun.font.*' on your platform
you currently have no other choice than putting at least EUC_CN,
EUC_KR and GBK into the standard charsets as well. But as far as I
understood now, you're already aware of the problem :)
Regards,
Volker
> -Alan.
From yasuenag at gmail.com Thu May 28 14:41:37 2015
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Thu, 28 May 2015 23:41:37 +0900
Subject: [OpenJDK 2D-Dev] JDK-8081295: Build failed with GCC 5.1.1
In-Reply-To: <55671164.6070309@oracle.com>
References: <55668951.9070309@gmail.com> <55668B13.1000303@gmail.com> <5566DD67.9000301@oracle.com>
<55671164.6070309@oracle.com>
Message-ID: <55672921.3050508@gmail.com>
Hi Alexander,
I've uploaded new webrev:
http://cr.openjdk.java.net/~ysuenaga/JDK-8081295/webrev.02/
This patch excludes libsplashscreen, and fix Awt2dLibraries.gmk .
Could you review it?
Thanks,
Yasumasa
On 2015/05/28 22:00, Alexander Zvegintsev wrote:
> I think that you can just exclude libsplashscreen part from your fix,
> since it is covered by JDK-8080695.
>
> Thanks,
>
> Alexander.
>
> On 05/28/2015 02:52 PM, Yasumasa Suenaga wrote:
>>
>> Hi Alexander,
>>
>> Thank you for your comment.
>>
>> I agree to use DISABLED_WARNINGS_gcc.
>>
>> Should I make a patch afterJDK-8080695 committed?
>>
>> Thanks,
>>
>> Yasumasa
>>
>> 2015/05/28 18:19 "Alexander Zvegintsev" >:
>>
>> Hello Yasumasa,
>>
>> I prefer to avoid such pragma usage, as for me code is more readable without it.
>> So we can add array-bounds to DISABLED_WARNINGS_gcc in make/lib/Awt2dLibraries.gmk for BUILD_LIBJAVAJPEG and BUILD_LIBMLIB_IMAGE.
>>
>> We can nullify row_pointers and image_data after setjmp call to remove warnings in splashscreen_png.c:
>> diff -r 729dffc8afa0 src/java.desktop/share/native/libsplashscreen/splashscreen_png.c
>> --- a/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c
>> +++ b/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c
>> @@ -77,6 +77,8 @@ SplashDecodePng(Splash * splash, png_rw_
>> #else
>> if (setjmp(png_jmpbuf(png_ptr))) {
>> #endif
>> + row_pointers = NULL;
>> + image_data = NULL;
>> goto done;
>> }
>> (or declare them as volatile, but I prefer the first option).
>> BTW, there is another issue about this splashscreen_png.c gcc build failure [1].
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8080695
>>
>> Thanks,
>>
>> Alexander.
>>
>>
>> On 05/28/2015 06:27 AM, Yasumasa Suenaga wrote:
>>
>> I've uploaded webrev:
>> http://cr.openjdk.java.net/~ysuenaga/JDK-8081295/webrev.01/
>>
>> Please review.
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> On 2015/05/28 12:19, Yasumasa Suenaga wrote:
>>
>> Hi all,
>>
>> I tried to build jdk9/dev on Fedora22 with GCC 5.1.1, however, it was failed.
>> I found several problems:
>>
>>
>> System:
>> Fedora release 22 (Twenty Two) x86_64
>> - gcc-5.1.1-1.fc22.x86_64
>>
>>
>> Problems:
>> 1. Array bounds check in GCC
>> - jdk/src/java.desktop/share/native/libjavajpeg/jcmaster.c
>> - jdk/src/java.desktop/share/native/libjavajpeg/jquant1.c
>> - jdk/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_64.c
>> - jdk/src/java.desktop/share/native/libmlib_image/mlib_c_ImageLookUp_f.c
>>
>> It seems to be bug of GCC:
>> Bug 59124: [4.8/4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds"
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
>>
>> I think implementations of these files have no problem.
>> So I propose to ignore warning(s) of compiler through pragma option as
>> workaround when we use GCC [1].
>>
>>
>> 2. Local variables might be clobbered
>> - jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c
>>
>> SplashDecodePng() calls setjmp(3).
>> Some local variables initialize before setjmp() call, and use after it.
>> Their initial values are only used at cleanup code (*done* label) and
>> actual values are stored only after setjmp() call.
>> So I think we can ignore this error through pragma option [1].
>>
>>
>> 3. Incorrect condition
>> - jdk/src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.c
>>
>> searchAllSourceNames() returns int value. However, branch condition in
>> eventFilterRestricted_passesFilter() treats it as boolean value.
>>
>>
>> I received a comment from Erik to use --disable-warnings-as-errors,
>> however I could not avoid error in 3.
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> [1] https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html
>>
>>
>
From yasuenag at gmail.com Thu May 28 14:48:33 2015
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Thu, 28 May 2015 23:48:33 +0900
Subject: [OpenJDK 2D-Dev] JDK-8081295: Build failed with GCC 5.1.1
In-Reply-To: <55671FA0.40400@gmail.com>
References: <5565906D.4010508@gmail.com> <5565BF2F.7000504@oracle.com>
<556689C5.3020504@gmail.com> <55671D53.5040708@gmail.com>
<55671FA0.40400@gmail.com>
Message-ID: <55672AC1.7050107@gmail.com>
Hi Peter,
I CC'ed this email to 2d-dev and Alexander.
> I can pull my fix back in favor of yours which covers other issues too,
> if you want.
I think libsplashscreen should be fixed on JDK-8080695.
I posted new webrev about JDK-8081295 which exclude libsplashscreen [1].
And Alexxander suggested fix about JDK-8080695 [2].
I prefer to fix as so.
Thanks,
Yasumasa
[1] http://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005453.html
[2] http://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005448.html
On 2015/05/28 23:01, Peter Levart wrote:
>
>
> On 05/28/2015 03:51 PM, Peter Levart wrote:
>>
>> On 05/28/2015 05:21 AM, Yasumasa Suenaga wrote:
>>> Hi David,
>>>
>>> I posted email to 2d-dev and serviceability-dev.
>>> If my patch is reviewed, I will push it to jdk9/client .
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>> Hi Yasumasa,
>>
>> I think you have the same problem as I and I already filed an issue for it:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8080695
>>
>> The fix has already been approved. I'll push it shortly to jdk9/client.
>
> Well, my fix is only for the issue in JDK-8080695. I simply marked the
> locals as volatile. Do you know for sure that the variables can't be
> clobbered by longjump if you just disable the warning?
>
> I can pull my fix back in favor of yours which covers other issues too,
> if you want.
>
> Regards, Peter
>
>>
>> Regards, Peter
>>
>>> On 2015/05/27 21:57, David Holmes wrote:
>>>> Hi Yasumasa,
>>>>
>>>> As Erik wrote in the CR each part of this needs to be reviewed by the
>>>> appropriate component team - this seems to be mostly client-libs with a
>>>> dash of serviceability.
>>>>
>>>> Also note that only hotspot pushes need a sponsor as they have to go in
>>>> via our JPRT build/test system. In other areas any JDK9 committer can
>>>> push reviewed changes directly (with assumed sufficient build/test
>>>> coverage).
>>>>
>>>> David
>>>>
>>>> On 27/05/2015 7:37 PM, Yasumasa Suenaga wrote:
>>>>> Hi all,
>>>>>
>>>>> I don't know where should I post this issue - so I post jdk9-dev.
>>>>>
>>>>> I tried to build jdk9/dev on Fedora22 with GCC 5.1.1, however, it was failed.
>>>>> I found several problems:
>>>>>
>>>>>
>>>>> System:
>>>>> Fedora release 22 (Twenty Two) x86_64
>>>>> - gcc-5.1.1-1.fc22.x86_64
>>>>>
>>>>>
>>>>> Problems:
>>>>> 1. Array bounds check in GCC
>>>>> - jdk/src/java.desktop/share/native/libjavajpeg/jcmaster.c
>>>>> - jdk/src/java.desktop/share/native/libjavajpeg/jquant1.c
>>>>> - jdk/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_64.c
>>>>> - jdk/src/java.desktop/share/native/libmlib_image/mlib_c_ImageLookUp_f.c
>>>>>
>>>>> It seems to be bug of GCC:
>>>>> Bug 59124: [4.8/4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds"
>>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
>>>>>
>>>>> I think implementations of these files have no problem.
>>>>> So I propose to ignore warning(s) of compiler through pragma option as
>>>>> workaround when we use GCC [1].
>>>>>
>>>>>
>>>>> 2. Local variables might be clobbered
>>>>> - jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c
>>>>>
>>>>> SplashDecodePng() calls setjmp(3).
>>>>> Some local variables initialize before setjmp() call, and use after it.
>>>>> Their initial values are only used at cleanup code (*done* label) and
>>>>> actual values are stored only after setjmp() call.
>>>>> So I think we can ignore this error through pragma option [1].
>>>>>
>>>>> However, cleanup code (*done* label) might be occurred runtime error in
>>>>> libc when some pointers are NULL. So I add NULL check in it.
>>>>>
>>>>>
>>>>> 3. Incorrect condition
>>>>> - jdk/src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.c
>>>>>
>>>>> searchAllSourceNames() returns int value. However, branch condition in
>>>>> eventFilterRestricted_passesFilter() treats it as boolean value.
>>>>>
>>>>>
>>>>> I've created patch for this enhancement.
>>>>> Could you review it?
>>>>>
>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8081295/webrev.00/
>>>>>
>>>>>
>>>>> I'm jdk9 committer, but I'm not employee at Oracle.
>>>>> So I need a Sponsor.
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Yasumasa
>>>>>
>>>>>
>>>>> [1] https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html
>>>>>
>
From alexander.zvegintsev at oracle.com Thu May 28 15:48:57 2015
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 28 May 2015 18:48:57 +0300
Subject: [OpenJDK 2D-Dev] JDK-8081295: Build failed with GCC 5.1.1
In-Reply-To: <55672921.3050508@gmail.com>
References: <55668951.9070309@gmail.com> <55668B13.1000303@gmail.com> <5566DD67.9000301@oracle.com>
<55671164.6070309@oracle.com> <55672921.3050508@gmail.com>
Message-ID: <556738E9.1000304@oracle.com>
Hi Yasumasa,
the fix looks good to me.
Thanks,
Alexander.
On 05/28/2015 05:41 PM, Yasumasa Suenaga wrote:
> Hi Alexander,
>
> I've uploaded new webrev:
> http://cr.openjdk.java.net/~ysuenaga/JDK-8081295/webrev.02/
>
> This patch excludes libsplashscreen, and fix Awt2dLibraries.gmk .
> Could you review it?
>
>
> Thanks,
>
> Yasumasa
>
>
>
> On 2015/05/28 22:00, Alexander Zvegintsev wrote:
>> I think that you can just exclude libsplashscreen part from your fix,
>> since it is covered by JDK-8080695.
>>
>> Thanks,
>>
>> Alexander.
>>
>> On 05/28/2015 02:52 PM, Yasumasa Suenaga wrote:
>>>
>>> Hi Alexander,
>>>
>>> Thank you for your comment.
>>>
>>> I agree to use DISABLED_WARNINGS_gcc.
>>>
>>> Should I make a patch afterJDK-8080695
>>> committed?
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>> 2015/05/28 18:19 "Alexander Zvegintsev"
>>> >> >:
>>>
>>> Hello Yasumasa,
>>>
>>> I prefer to avoid such pragma usage, as for me code is more
>>> readable without it.
>>> So we can add array-bounds to DISABLED_WARNINGS_gcc in
>>> make/lib/Awt2dLibraries.gmk for BUILD_LIBJAVAJPEG and
>>> BUILD_LIBMLIB_IMAGE.
>>>
>>> We can nullify row_pointers and image_data after setjmp call to
>>> remove warnings in splashscreen_png.c:
>>> diff -r 729dffc8afa0
>>> src/java.desktop/share/native/libsplashscreen/splashscreen_png.c
>>> ---
>>> a/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c
>>> +++
>>> b/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c
>>> @@ -77,6 +77,8 @@ SplashDecodePng(Splash * splash, png_rw_
>>> #else
>>> if (setjmp(png_jmpbuf(png_ptr))) {
>>> #endif
>>> + row_pointers = NULL;
>>> + image_data = NULL;
>>> goto done;
>>> }
>>> (or declare them as volatile, but I prefer the first option).
>>> BTW, there is another issue about this splashscreen_png.c gcc
>>> build failure [1].
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8080695
>>>
>>> Thanks,
>>>
>>> Alexander.
>>>
>>>
>>> On 05/28/2015 06:27 AM, Yasumasa Suenaga wrote:
>>>
>>> I've uploaded webrev:
>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8081295/webrev.01/
>>>
>>>
>>> Please review.
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>>
>>> On 2015/05/28 12:19, Yasumasa Suenaga wrote:
>>>
>>> Hi all,
>>>
>>> I tried to build jdk9/dev on Fedora22 with GCC 5.1.1,
>>> however, it was failed.
>>> I found several problems:
>>>
>>>
>>> System:
>>> Fedora release 22 (Twenty Two) x86_64
>>> - gcc-5.1.1-1.fc22.x86_64
>>>
>>>
>>> Problems:
>>> 1. Array bounds check in GCC
>>> -
>>> jdk/src/java.desktop/share/native/libjavajpeg/jcmaster.c
>>> -
>>> jdk/src/java.desktop/share/native/libjavajpeg/jquant1.c
>>> -
>>> jdk/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_64.c
>>> -
>>> jdk/src/java.desktop/share/native/libmlib_image/mlib_c_ImageLookUp_f.c
>>>
>>> It seems to be bug of GCC:
>>> Bug 59124: [4.8/4.9/5/6 Regression] Wrong
>>> warnings "array subscript is above array bounds"
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
>>>
>>> I think implementations of these files have no
>>> problem.
>>> So I propose to ignore warning(s) of compiler
>>> through pragma option as
>>> workaround when we use GCC [1].
>>>
>>>
>>> 2. Local variables might be clobbered
>>> -
>>> jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c
>>>
>>> SplashDecodePng() calls setjmp(3).
>>> Some local variables initialize before setjmp()
>>> call, and use after it.
>>> Their initial values are only used at cleanup
>>> code (*done* label) and
>>> actual values are stored only after setjmp() call.
>>> So I think we can ignore this error through
>>> pragma option [1].
>>>
>>>
>>> 3. Incorrect condition
>>> -
>>> jdk/src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.c
>>>
>>> searchAllSourceNames() returns int value.
>>> However, branch condition in
>>> eventFilterRestricted_passesFilter() treats it as
>>> boolean value.
>>>
>>>
>>> I received a comment from Erik to use
>>> --disable-warnings-as-errors,
>>> however I could not avoid error in 3.
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>>
>>> [1]
>>> https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html
>>>
>>>
>>
From james.graham at oracle.com Thu May 28 20:33:47 2015
From: james.graham at oracle.com (Jim Graham)
Date: Thu, 28 May 2015 13:33:47 -0700
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8080847 Copying of
overlapping memory should be improved in java2d
In-Reply-To: <5566CA88.2080200@redhat.com>
References: <5563172D.4080605@oracle.com> <556374FD.4020501@oracle.com> <556378C7.6090807@oracle.com> <55644E47.4040008@oracle.com>
<55645A46.70506@oracle.com> <5564BB02.40703@oracle.com>
<55659E18.8040903@oracle.com> <5565A275.2040909@redhat.com>
<55665C23.2090801@oracle.com> <5566CA88.2080200@redhat.com>
Message-ID: <55677BAB.1060708@oracle.com>
I'm sorry, but memcpy has never crashed simply due to overlapping
regions and there is no evidence for this. We've been using it for
nearly 20 years now and never had a crash when the src and dst memory
regions are within the bounds of an image.
You are taking language meant to cover them for "we do not guarantee
that overlapping memory copies won't make a mess of the data you are
copying" to somehow infer that it can read or write outside the
indicated bounds. At worst the pixels will be jumbled and that would
not cause any crashes, it would simply look wrong on the screen. The
thread that Sergey pointed to even went so far as to have developers
claim that the exact specific way that it jumbles the data it is copying
is considered part of the contract even though the behavior is specified
as undefined. Crashing is completely outside the scope of its undefined
claim.
The only viable reason for switching to memmove is to either silence the
tool that reported the issue or to fix the data ordering issue. There
are other ways to silence the tool without making one of our blits have
behavior that doesn't match other similar blits, and if we are going to
fix the data ordering issue we should do it for all blits...
...jim
On 5/28/2015 12:58 AM, Andrew Haley wrote:
> On 28/05/15 01:06, Jim Graham wrote:
>> Where do you see evidence that it can crash?
>
> It's what the language specification says. Undefined behaviour is
> unconstrained: it can do anything. Demons might fly out of your nose.
>
> We have seen with GCC that apparently "harmless" code (a read just
> beyond the end of an array) can, for example, result in an infinite
> loop. In this case, it is quite possible that GCC could infer that
> the two memory regions accessed by memcpy do not overlap.
>
> Andrew.
>
From aph at redhat.com Fri May 29 08:09:04 2015
From: aph at redhat.com (Andrew Haley)
Date: Fri, 29 May 2015 09:09:04 +0100
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8080847 Copying of
overlapping memory should be improved in java2d
In-Reply-To: <55677BAB.1060708@oracle.com>
References: <5563172D.4080605@oracle.com> <556374FD.4020501@oracle.com> <556378C7.6090807@oracle.com> <55644E47.4040008@oracle.com>
<55645A46.70506@oracle.com> <5564BB02.40703@oracle.com>
<55659E18.8040903@oracle.com> <5565A275.2040909@redhat.com>
<55665C23.2090801@oracle.com> <5566CA88.2080200@redhat.com>
<55677BAB.1060708@oracle.com>
Message-ID: <55681EA0.9070700@redhat.com>
On 28/05/15 21:33, Jim Graham wrote:
> The only viable reason for switching to memmove is to either silence the
> tool that reported the issue or to fix the data ordering issue.
Or to remove the UB. Your opinion that UB is constrained is wrong in
principle and dangerous in practice. It is extrememly unlikely that
moving to memmove() will result in perciptible difference; I can't see
any reason not to simply fix your code.
> There are other ways to silence the tool without making one of our
> blits have behavior that doesn't match other similar blits, and if
> we are going to fix the data ordering issue we should do it for all
> blits...
Indeed.
Andrew.
From philip.race at oracle.com Fri May 29 16:45:43 2015
From: philip.race at oracle.com (Phil Race)
Date: Fri, 29 May 2015 09:45:43 -0700
Subject: [OpenJDK 2D-Dev] RFR [TestBug 8080086]: Test
javax/imageio/plugins/png/ItxtUtf8Test.java fails on Linux with G1 GC
In-Reply-To: <556449C9.40602@oracle.com>
References: <55630496.4030000@oracle.com> <55634481.2050404@oracle.com>
<55640EDD.9080407@oracle.com> <556449C9.40602@oracle.com>
Message-ID: <556897B7.4010309@oracle.com>
+1
-phil.
On 05/26/2015 03:24 AM, Sergey Bylokhov wrote:
> Thanks for clarification!
> The fix looks fine.
>
> On 26.05.15 9:12, prasanta sadhukhan wrote:
>> Hi Sergey,
>>
>> Yes, the original bugs can still be reproduced with jdk1.6 with
>> updated test.
>>
>> Regards
>> Prasanta
>> On 5/25/2015 9:19 PM, Sergey Bylokhov wrote:
>>> Hi, Prasanta.
>>> Can you confirm that an initial bugs( 6541476 6782079) still can be
>>> reproduced using an updated test on x86 and x64?
>>>
>>> On 25.05.15 14:16, prasanta sadhukhan wrote:
>>>> Hi All,
>>>>
>>>> The test throws OOME in 64bit linux but passes in 32bit linux. It
>>>> seems to require more memory for 64bit system so increasing the max
>>>> heap size from 2MB to 4MB to execute the test successfully on 64bit
>>>> linux.
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8080086
>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8080086/webrev.00/
>>>>
>>>> Regards
>>>> Prasanta
>>>
>>>
>>> --
>>> Best regards, Sergey.
>>
>
>
> --
> Best regards, Sergey.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From philip.race at oracle.com Fri May 29 22:16:49 2015
From: philip.race at oracle.com (Phil Race)
Date: Fri, 29 May 2015 15:16:49 -0700
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8080847 Copying of
overlapping memory should be improved in java2d
In-Reply-To: <55681EA0.9070700@redhat.com>
References: <5563172D.4080605@oracle.com> <556374FD.4020501@oracle.com> <556378C7.6090807@oracle.com> <55644E47.4040008@oracle.com>
<55645A46.70506@oracle.com> <5564BB02.40703@oracle.com>
<55659E18.8040903@oracle.com> <5565A275.2040909@redhat.com>
<55665C23.2090801@oracle.com> <5566CA88.2080200@redhat.com>
<55677BAB.1060708@oracle.com> <55681EA0.9070700@redhat.com>
Message-ID: <5568E551.3060207@oracle.com>
I've asked around internally and the overwhelming
consensus is that memcpy is not dangerous in
the overlapping case. Our security/vulnerability
expert does not see a problem - as long the
pointers are valid of course.
The long-ago author of the memcpy man page
surely meant that the end resulting bytes in memory
are up to the platform in this case to make
optimisations that won't follow the same pattern
as other platforms, not that the library call has a license
to do bad things.
The corollary to that is that the change to use
memmove is not really making things safer, and
without more changes is not making the code
usefully predictable.
A little research (and there could be more done)
shows that XCopyArea makes no promise about how
it handles such a case, whereas glCopyPixels
does specify the order it copies, of course whether it
results in the same output has having used
an intermediate buffer depends on the
specifics of your source and destination and
we are not going to be able to specify what
happens since we rely on pipelines that we
cannot control.
-phil.
On 05/29/2015 01:09 AM, Andrew Haley wrote:
> On 28/05/15 21:33, Jim Graham wrote:
>> The only viable reason for switching to memmove is to either silence the
>> tool that reported the issue or to fix the data ordering issue.
> Or to remove the UB. Your opinion that UB is constrained is wrong in
> principle and dangerous in practice. It is extrememly unlikely that
> moving to memmove() will result in perciptible difference; I can't see
> any reason not to simply fix your code.
>
>> There are other ways to silence the tool without making one of our
>> blits have behavior that doesn't match other similar blits, and if
>> we are going to fix the data ordering issue we should do it for all
>> blits...
> Indeed.
>
> Andrew.
From andrew.brygin at oracle.com Sat May 30 17:21:50 2015
From: andrew.brygin at oracle.com (Andrew Brygin)
Date: Sat, 30 May 2015 20:21:50 +0300
Subject: [OpenJDK 2D-Dev] RFR: 8u-dev backport: 8023794: [macosx] LCD
Rendering hints seems not working without FRACTIONALMETRICS=ON
Message-ID: <5569F1AE.1070804@oracle.com>
Hello Sergey, and Phil,
could you please review a backport of the fix for 8023794
to 8u-dev?
The change is exactly same, except a declaration of the loop counter 'i'
in getReverseGammaLut() routine (CGGlyphImages.m, lines 206-217):
it has to be moved in order to meet XCode 4.x expectations.
http://cr.openjdk.java.net/~bae/8023794/8u-dev/webrev.00/
Please take a look.
Thanks,
Andrew.