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.