Re: [OpenJDK 2D-Dev] RFR: 8039444: Swing applications not being displayed properly
> I guess we also should unify -Dsun.java2d option? in some cases it will force the pipeline(like xrender) and in some not like d3d. Yes, I have 3 things in the pipeline (pardon the pun) - clean up of legacy unused flags on windows, This is done and I expect to submit a review tonight or maybe tomorrow. Then once that noise is removed : - a way to force d3d at your own risk - an examination of how all the pipeline options for each platform and default interact and provide comprehensible documentation. The last one is the one you are getting at I think -phil. On 4/28/16, 2:22 PM, Sergey Bylokhov wrote: +1 On 29.04.16 0:13, Vadim Pakhnushev wrote: One thing I intend to do is make sure there is a way to force it on regardless. That will be a follow-up. I guess we also should unify -Dsun.java2d option? in some cases it will force the pipeline(like xrender) and in some not like d3d.
Re: [OpenJDK 2D-Dev] RFR: 8039444: Swing applications not being displayed properly
+1 On 29.04.16 0:13, Vadim Pakhnushev wrote: One thing I intend to do is make sure there is a way to force it on regardless. That will be a follow-up. I guess we also should unify -Dsun.java2d option? in some cases it will force the pipeline(like xrender) and in some not like d3d. -- Best regards, Sergey.
Re: [OpenJDK 2D-Dev] RFR: 8039444: Swing applications not being displayed properly
+1 Vadim On 28.04.2016 23:52, Phil Race wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8039444 Webrev: http://cr.openjdk.java.net/~prr/8039444/ This makes 9 consistent in black-listing all intel chipsets as we did in 8u40 : http://mail.openjdk.java.net/pipermail/2d-dev/2014-November/004939.html Ideally we would not have to do that but we have not made any solid progress in being to 'white list' any. One thing I intend to do is make sure there is a way to force it on regardless. That will be a follow-up. -phil.
[OpenJDK 2D-Dev] RFR: 8039444: Swing applications not being displayed properly
Bug: https://bugs.openjdk.java.net/browse/JDK-8039444 Webrev: http://cr.openjdk.java.net/~prr/8039444/ This makes 9 consistent in black-listing all intel chipsets as we did in 8u40 : http://mail.openjdk.java.net/pipermail/2d-dev/2014-November/004939.html Ideally we would not have to do that but we have not made any solid progress in being to 'white list' any. One thing I intend to do is make sure there is a way to force it on regardless. That will be a follow-up. -phil.
Re: [OpenJDK 2D-Dev] Fix for JDK-8074829 : Resolve disabled warnings for libawt_headless
Then I'm happy, thanks! /Erik On 2016-04-28 14:44, Ajit Ghaisas wrote: Hi, I tried excluding files under directory : jdk/src/java.desktop/share/native/common/java2d/opengl from libawt_headless. It resulted in compilation errors - as the headers in this directory (and under sub-directory J2D_GL) are used in other places. To Phil's question on - why I mentioned only OGLBlitLoops.c file? - this is the file where warning is reported and build stopped. Hence, I propose not to remove the suppression of warning E_EMPTY_TRANSLATION_UNIT in make file for Solaris. There is no change in original webrev : http://cr.openjdk.java.net/~aghaisas/8074829/webrev.00/ Based on Erik's suggestion, I have built it for arm and arm64 with no errors. Regards, Ajit -Original Message- From: Phil Race Sent: Friday, April 22, 2016 1:43 AM To: Ajit Ghaisas Cc: Sergey Bylokhov; 2d-dev; build-...@openjdk.java.net Subject: Re: Fix for JDK-8074829 : Resolve disabled warnings for libawt_headless > Another solution is to exclude this file from HEADLESS compilation. > I am not sure how to achieve it. Any suggestion? I suppose that is possible and I expect we can do that See in the make file, where I think you just need to add entries to LIBAWT_HEADLESS_EXCLUDES := medialib although I have not tried it. Hmm .. I wonder why medialib needs to be explicitly excluded from headless ? .. but that is for another day. I have another question: why do you mention only OGLBlitLoops.c ? I've flicked through a number of the C files in the same location and all look to have the same issue. -phil. On 04/21/2016 06:33 AM, Ajit Ghaisas wrote: On 04/20/2016 12:27 PM, Sergey Bylokhov wrote: 2d-dev added. In fact all these are 2D. No AWT warnings here. I am not sure but why "declaration in the code" is a bad thing and we should fix it? - DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE I cannot find the documentation in solaris studio for this warning. I don't mind fixing it if it is still an issue but does the current compiler actually complain about it ? The SS11 -> SS12 upgrade might have got a more modern C compiler .. [Ajit ] Yes. The Solaris compiler still complains about this declaration in code. Hence, I have fixed the reported warnings after removing the suppression from makefile. On 20.04.16 11:57, Ajit Ghaisas wrote: Hi, Bug : https://bugs.openjdk.java.net/browse/JDK-8074829 This bug is to remove warning suppressions from makefile and fix the warnings for libawt_headless library. I have removed following warning suppressions & fixed the warnings for libawt_headless library. DISABLED_WARNINGS_gcc := maybe-uninitialized int-to-pointer-cast What made that one go away ?? [Ajit] : I fixed warnings reported for 'maybe-uninitialized' and 'E_DECLARATION_IN_CODE' warning types in two .c files in webrev. There was no warning after removal of 'int-to-pointer-cast' suppression from makefile. No code change was made for this type of warning. DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE Warning suppression that cannot be removed : DISABLED_WARNINGS_solstudio := E_EMPTY_TRANSLATION_UNIT This is due to the fact that - jdk/src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops .c file becomes empty file in case of HEADLESS mode compilation. Sigh .. there ought to be "informational" warnings as well as "risky practice" warnings and this should be in the former category. You could move something like the jni.h and jlong.h imports outside to see if that shuts it up. Not saying that is what we want to do but it would be interesting to check. [Ajit] : Nope. Moving jni.h or jlong.h inclusions outside #ifndef HEADLESS did not help. We still get E_EMPTY_TRANSLATION_UNIT warning. To get rid of this warning, there are suggestions to make a typedef - and not use it anywhere - but, I would rather keep the suppression in makefile than defining a typedef without actual usage. Another solution is to exclude this file from HEADLESS compilation. I am not sure how to achieve it. Any suggestion? -phil. Request you to review following webrev : http://cr.openjdk.java.net/~aghaisas/8074829/webrev.00/ Regards, Ajit
Re: [OpenJDK 2D-Dev] Fix for JDK-8074829 : Resolve disabled warnings for libawt_headless
Hi, I tried excluding files under directory : jdk/src/java.desktop/share/native/common/java2d/opengl from libawt_headless. It resulted in compilation errors - as the headers in this directory (and under sub-directory J2D_GL) are used in other places. To Phil's question on - why I mentioned only OGLBlitLoops.c file? - this is the file where warning is reported and build stopped. Hence, I propose not to remove the suppression of warning E_EMPTY_TRANSLATION_UNIT in make file for Solaris. There is no change in original webrev : http://cr.openjdk.java.net/~aghaisas/8074829/webrev.00/ Based on Erik's suggestion, I have built it for arm and arm64 with no errors. Regards, Ajit -Original Message- From: Phil Race Sent: Friday, April 22, 2016 1:43 AM To: Ajit Ghaisas Cc: Sergey Bylokhov; 2d-dev; build-...@openjdk.java.net Subject: Re: Fix for JDK-8074829 : Resolve disabled warnings for libawt_headless > Another solution is to exclude this file from HEADLESS compilation. > I am not sure how to achieve it. Any suggestion? I suppose that is possible and I expect we can do that See in the make file, where I think you just need to add entries to LIBAWT_HEADLESS_EXCLUDES := medialib although I have not tried it. Hmm .. I wonder why medialib needs to be explicitly excluded from headless ? .. but that is for another day. I have another question: why do you mention only OGLBlitLoops.c ? I've flicked through a number of the C files in the same location and all look to have the same issue. -phil. On 04/21/2016 06:33 AM, Ajit Ghaisas wrote: >>> On 04/20/2016 12:27 PM, Sergey Bylokhov wrote: >>> 2d-dev added. >> In fact all these are 2D. No AWT warnings here. >>> I am not sure but why "declaration in the code" is a bad thing and >>> we should fix it? >>> - DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE >>> >>> I cannot find the documentation in solaris studio for this warning. >> I don't mind fixing it if it is still an issue but does the current compiler >> actually complain about it ? >> The SS11 -> SS12 upgrade might have got a more modern C compiler .. > [Ajit ] Yes. The Solaris compiler still complains about this declaration in > code. Hence, I have fixed the reported warnings after removing the > suppression from makefile. > >>> On 20.04.16 11:57, Ajit Ghaisas wrote: Hi, Bug : https://bugs.openjdk.java.net/browse/JDK-8074829 This bug is to remove warning suppressions from makefile and fix the warnings for libawt_headless library. I have removed following warning suppressions & fixed the warnings for libawt_headless library. DISABLED_WARNINGS_gcc := maybe-uninitialized int-to-pointer-cast >> What made that one go away ?? > [Ajit] : I fixed warnings reported for 'maybe-uninitialized' and > 'E_DECLARATION_IN_CODE' warning types in two .c files in webrev. > There was no warning after removal of 'int-to-pointer-cast' suppression from > makefile. No code change was made for this type of warning. > > DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE Warning suppression that cannot be removed : DISABLED_WARNINGS_solstudio := E_EMPTY_TRANSLATION_UNIT This is due to the fact that - jdk/src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops .c file becomes empty file in case of HEADLESS mode compilation. >> Sigh .. there ought to be "informational" warnings as well as "risky >> practice" warnings and this should be in the former category. >> You could move something like the jni.h and jlong.h imports outside to see >> if that shuts it up. >> Not saying that is what we want to do but it would be interesting to check. > [Ajit] : Nope. Moving jni.h or jlong.h inclusions outside #ifndef HEADLESS > did not help. We still get E_EMPTY_TRANSLATION_UNIT warning. > To get rid of this warning, there are suggestions to make a typedef - and not > use it anywhere - but, I would rather keep the suppression in makefile than > defining a typedef without actual usage. > Another solution is to exclude this file from HEADLESS compilation. I am not > sure how to achieve it. Any suggestion? > > >> -phil. Request you to review following webrev : http://cr.openjdk.java.net/~aghaisas/8074829/webrev.00/ Regards, Ajit
