From Sergey.Bylokhov at oracle.com Mon Jan 12 10:50:02 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 12 Jan 2015 13:50:02 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8066132 BufferedImage::getPropertyNames() always returns null Message-ID: <54B3A6DA.6070707@oracle.com> Hello. Please review a fix for jdk 9. BufferedImage::getPropertyNames() was implemented according to specification. Notes: - The properties map in the constructor is defined as , which means it can have non-String keys. Long time ago (in 2004) it was defined as but was changed to in some of (5054615, 5056707, 5060820, 5061476, 5073707). I am not sure, it is safe to change it back to or not, so I decided to filter out non-String keys. - Unused isAlphaPremultiplied field was removed. Bug: https://bugs.openjdk.java.net/browse/JDK-8066132 Webrev can be found at: http://cr.openjdk.java.net/~serb/8066132/webrev.00 -- Best regards, Sergey. From philip.race at oracle.com Thu Jan 15 22:32:39 2015 From: philip.race at oracle.com (Phil Race) Date: Thu, 15 Jan 2015 14:32:39 -0800 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8066132 BufferedImage::getPropertyNames() always returns null In-Reply-To: <54B3A6DA.6070707@oracle.com> References: <54B3A6DA.6070707@oracle.com> Message-ID: <54B84007.4030806@oracle.com> Approved -phil. On 1/12/2015 2:50 AM, Sergey Bylokhov wrote: > Hello. > Please review a fix for jdk 9. > BufferedImage::getPropertyNames() was implemented according to > specification. > Notes: > - The properties map in the constructor is defined as , which > means it can have non-String keys. Long time ago (in 2004) it was > defined as but was changed to in some of (5054615, > 5056707, 5060820, 5061476, 5073707). I am not sure, it is safe to > change it back to or not, so I decided to filter out > non-String keys. > - Unused isAlphaPremultiplied field was removed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066132 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8066132/webrev.00 > From philip.race at oracle.com Thu Jan 15 22:53:13 2015 From: philip.race at oracle.com (Phil Race) Date: Thu, 15 Jan 2015 14:53:13 -0800 Subject: [OpenJDK 2D-Dev] What is the point of CloseTTFontFileFunc? In-Reply-To: <54A1351D.9090108@redhat.com> References: <54940734.5090401@redhat.com> <54A1351D.9090108@redhat.com> Message-ID: <54B844D9.40703@oracle.com> I can only suppose the author thought he was going to pass the platName (which would be the font file path) to some code that would use it to somehow close an open descriptor on that file. But clearly it does nothing of the sort and an up-call to the java font object (like in the read function) would not need that information anyway. So it looks redundant. I don't see how it would relate to the crash. That *may* be caused by some simultaneous use and/or freeing in different threads of files created using Font.createFont(..) and are now bing released. I've also seen crashes where admins clean out the /tmp folder whilst the JRE is running using font files there. But that would probably not involve the disposer code. -phil. On 12/29/2014 3:03 AM, Andrew Dinn wrote: > Hi again, > > Trying a second time . . . anyone have an answer to this question? > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in UK and Wales under Company Registration No. 3798903 > Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters > (USA), Michael O'Neill (Ireland) > > On 19/12/14 11:08, Andrew Dinn wrote: >> Hi All, >> >> I am looking at a problem Red Hat customers have reported with True Type >> fonts where they are seeing a Hotspot crash using JDK7. the problem >> relates to the use of TT font scalers and, in particular to code called >> under native methods initNativeScaler and disposeNativeScaler of class >> sun.font.FreetypeFontScaler. >> >> While investigating this I looked at the stream close function >> CloseTTFontFileFunc provided for the scaler in freetypeScaler.c and was >> rather confused as to what it was supposed to achieve. n.b. the code >> below from the release version of Icedtea7 which caused the problem >> appears still to exist unchanged in the latest jdk7u, jdk8u and jdk9). >> >> /* NB: is it ever called? */ >> static void CloseTTFontFileFunc(FT_Stream stream) { >> FTScalerInfo *scalerInfo = (FTScalerInfo *) stream->pathname.pointer; >> JNIEnv* env = scalerInfo->env; >> jclass tmpClass = (*env)->FindClass(env, "sun/font/TrueTypeFont"); >> jfieldID platNameField = >> (*env)->GetFieldID(env, tmpClass, "platName", >> "Ljava/lang/String;"); >> jstring platName = (*env)->GetObjectField(env, >> scalerInfo->font2D, >> platNameField); >> const char *name = JNU_GetStringPlatformChars(env, platName, NULL); >> JNU_ReleaseStringPlatformChars(env, platName, name); >> } >> >> Is there any point in calling JNU_GetStringPlatformChars and then >> JNU_ReleaseStringPlatformChars? This appears simply to malloc a copy of >> the platname string, albeit perhaps with some multibyte chars replaced >> with '?', and then to immediately free the allocated string. Is there >> any good reason for this? >> >> regards, >> >> >> Andrew Dinn >> ----------- >> >> >> From adinn at redhat.com Fri Jan 16 09:19:33 2015 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 16 Jan 2015 09:19:33 +0000 Subject: [OpenJDK 2D-Dev] What is the point of CloseTTFontFileFunc? In-Reply-To: <54B844D9.40703@oracle.com> References: <54940734.5090401@redhat.com> <54A1351D.9090108@redhat.com> <54B844D9.40703@oracle.com> Message-ID: <54B8D7A5.9030903@redhat.com> On 15/01/15 22:53, Phil Race wrote: > I can only suppose the author thought he was going to pass the > platName (which would be the font file path) to some code that would > use it to somehow close an open descriptor on that file. But clearly > it does nothing of the sort and an up-call to the java font object > (like in the read function) would not need that information anyway. > So it looks redundant. I don't see how it would relate to the crash. > That *may* be caused by some simultaneous use and/or freeing in > different threads of files created using Font.createFont(..) and are > now bing released. I've also seen crashes where admins clean out the > /tmp folder whilst the JRE is running using font files there. But > that would probably not involve the disposer code. The crash has been pinned down to some faulty argument passing. However, I am glad to hear that the code appears to be redundant. My concern was that it might be worse than that since the native code calls JNU_ReleaseStringPlatformChars which, potentially***, can release memory. Since platName is created by Java code (Using a combination of String literals and String+ operations) that would be a /very bad/ thing. So, I think this callback should probably be removed (as an a fortiori argument I'll note that it is, at best, redundant). ***n.b. I say potentially because the implementation of JNU_ReleaseStringPlatformChars is platform-specific and has many different code paths depending upon the type of the text the String holds. So, I am not sure the callback will ever free memory on any platform (Windows looks to be the most likely candidate). regards, Andrew Dinn ----------- From james.graham at oracle.com Sat Jan 17 04:43:36 2015 From: james.graham at oracle.com (Jim Graham) Date: Fri, 16 Jan 2015 20:43:36 -0800 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8066132 BufferedImage::getPropertyNames() always returns null In-Reply-To: <54B3A6DA.6070707@oracle.com> References: <54B3A6DA.6070707@oracle.com> Message-ID: <54B9E878.1050609@oracle.com> Looks good... ...jim On 1/12/15 2:50 AM, Sergey Bylokhov wrote: > Hello. > Please review a fix for jdk 9. > BufferedImage::getPropertyNames() was implemented according to > specification. > Notes: > - The properties map in the constructor is defined as , which means > it can have non-String keys. Long time ago (in 2004) it was defined as > but was changed to in some of (5054615, 5056707, > 5060820, 5061476, 5073707). I am not sure, it is safe to change it back > to or not, so I decided to filter out non-String keys. > - Unused isAlphaPremultiplied field was removed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066132 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8066132/webrev.00 > From rkennke at redhat.com Tue Jan 20 15:42:10 2015 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 20 Jan 2015 16:42:10 +0100 Subject: [OpenJDK 2D-Dev] [PATCH] Refactor X11FontManager Message-ID: <1421768530.30104.16.camel@localhost> I already sent that patch to awt-dev for review, a while ago: http://mail.openjdk.java.net/pipermail/awt-dev/2015-January/008819.html I got no reply, so I'm sending it here, maybe it's a better fit? ;-) Hello, I am currently working on a port of AWT/Java2D to DirectFB (using Caciocavallo [1] as a porting layer). I hit one obstacle that is the X11FontManager. I want to use fontconfig to work with fonts, but can't use anything X11. I refactored X11FontManager and related classes and native code to avoid calling anything X11 specific. Basically I created a superclass of X11FontManager called FcFontManager that does all the fontconfig related stuff, and use that in my backend. The changes should not affect the X11 implementation. Can you please review the changes here: http://cr.openjdk.java.net/~rkennke/refactor-x11fm/webrev.00/ I would like to push this into jdk9-client if you think it's ok. Best regards, Roman [1] http://openjdk.java.net/projects/caciocavallo/ From mljeroen+jdk at gmail.com Thu Jan 22 06:43:04 2015 From: mljeroen+jdk at gmail.com (Jeroen) Date: Thu, 22 Jan 2015 07:43:04 +0100 Subject: [OpenJDK 2D-Dev] JDK-8068529 XSync when xrender is turned off Message-ID: Hello, I'm the submitter of JDK-8068529 and I'd like to respond to the comments of this bug, but I don't have a openjdk account. Help at openjdk suggested to post this here. In reply to the comments of 2015-01-12: without xrender, XSync is indeed called in X11SurfaceData.c, in function X11SD_GetSharedImage. If you change the code to include a counter and a printf/fflush statement, you can see that XSync is called each time the Java-method paint() is called. *int xsync_counter = 0;*XImage* X11SD_GetSharedImage(X11SDOps *xsdo, jint width, jint height, jint maxWidth, jint maxHeight, jboolean readBits) { XImage * retImage = NULL; if (cachedXImage != NULL && X11SD_CachedXImageFits(width, height, maxWidth, maxHeight, xsdo->depth, readBits)) { /* sync so previous data gets flushed */ * xsync_counter++; printf("XSync %d in X11SurfaceData.c:GetSharedImage\r\n", xsync_counter); fflush(stdout);* XSync(awt_display, False); retImage = cachedXImage; cachedXImage = (XImage *)NULL; } else if (width * height * xsdo->depth > 0x10000) { retImage = X11SD_CreateSharedImage(xsdo, width, height); } return retImage; } This XSync call causes each paint to be displayed on the screen. Regards, Jeroen -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Thu Jan 22 14:49:42 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 22 Jan 2015 17:49:42 +0300 Subject: [OpenJDK 2D-Dev] Review request for 8029339 Custom MultiResolution image support on HiDPI displays Message-ID: <54C10E06.6090407@oracle.com> Hi Phil, I have prepared two versions of the proposed API: I) Resolution variants are added directly to the Image: http://cr.openjdk.java.net/~alexsch/8029339/list/webrev.00 II) MultiResolutionImage interface is used: http://cr.openjdk.java.net/~alexsch/8029339/webrev.05 It could help to decide which way should be chosen for the the multi-resolution image support. Below are some comments: 1. High level goal: Introduce an API that allows to create and handle an image with resolution variants. 2. What is not subject of the provided API - Scale naming convention for high-resolution images - Providing pixel scale factor for the screen/window 3. Use cases 3.1 Loading and drawing high-resolution icons in IntelliJ IDEA A high-resolution image is loaded from resources and stored in JBHiDPIScaledImage class which is a subclass of the buffered image. The high-resolution image is used to create a disabled icon in the IconLoader.getDisabledIcon(icon) method. https://github.com/JetBrains/intellij-community/blob/master/platform/util/src/com/intellij/openapi/util/IconLoader.java 3.2 Loading and drawing high-resolution icons in NetBeans NetBeans does not have support for the high-resolution icons loading. It loads an icon from the file system using Toolkit.getDefaultToolkit().getImage(url) method or from resources by ImageReader and store it in ToolTipImage class which is subclass of the buffered image. ImageUtilities.createDisabledIcon(icon) method creates a disabled icon by applying RGBImageFilter to the icon. http://hg.netbeans.org/main/file/97dcf49eb4a7/openide.util/src/org/openide/util/ImageUtilities.java 3.3 Loading system icons in JDK 1.8 JDK requests icons from the native system for system L&Fs and applies filters for them. See for example AquaUtils.generateLightenedImage() method: http://hg.openjdk.java.net/jdk9/client/jdk/file/e6f48c4fad38/src/java.desktop/macosx/classes/com/apple/laf/AquaUtils.java 4. HiDPI support for Images on different OSes 4.1 Mac OS X Cocoa API contains NSImage that allows to work with image representations: add/remove/get all representations. It picks up an image with necessary resolution based on the screen backing store pixel scale factor and applied transforms. https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSImage_Class/Reference/Reference.html 4.2 Linux GTK+ 3 API has gtkcssimagescaled lib (it seems that it is not public/stable) that parses the -gtk-scaled css property and draws a GtkCssImage according to the given scale factor. I have not found information about the HiDPI support in Xlib. 4.3 Windows I have only found the tutorial that suggests to select and draw a bitmap using the queried DPI and scale the coordinates for drawing a rectangular frame http://msdn.microsoft.com/en-us/library/dd464659%28v=vs.85%29.aspx Windows also provides the horizontal and vertical DPI of the desktop http://msdn.microsoft.com/en-us/library/windows/apps/dd371316 5. Pseudo API Below are some ways which illustrates how multi-resolution images can be created and used. 5.1 Resolution variants are stored directly in Image class. To query a resolution variant it needs to compare the resolution variant width/height with the requested high-resolution size. ------------ public abstract class Image { public void addResolutionVariant(Image image) {...} public List getResolutionVariants() {...} } ------------ // create a disabled image with resolution variants Image disabledImage = getDisabledImage(image); for (Image rv : image.getResolutionVariants()) { disabledImage.addResolutionVariant(getDisabledImage(rv)); } ------------ This approach requires that all resolution variants have been created even not of them are really used. 5.2 Resolution variants are stored in a separate object that allows to create them by demand. To query a resolution variant it needs to compare the resolution variant scale factor with the requested scale (that can include both screen DPI scale and applied transforms). ------------ public abstract class Image { public static interface ResolutionVariant { Image getImage(); float getScaleFactor(); } public void addResolutionVariant(ResolutionVariant resolutionVariant) {...} public List getResolutionVariants() {...} } ------------ // create a disabled image with resolution variants Image disabledImage = getDisabledImage(image); for (Image.ResolutionVariant rv : image.getResolutionVariants()) { disabledImage.addResolutionVariant(new Image.ResolutionVariant() { public Image getImage() { return getDisabledImage(rv.getImage()); } public float getScaleFactor() { return rv.getScaleFactor(); } }); } ------------ It does not have problem if a predefined set of images is provided (like image.png and image at 2x.png on the file system). This does not cover cases where a resolution variant can be created using the exact requested size (like loading icons from the native system). A resolution variant can be queried based on a scale factor and applied transforms. 5.3 The provided example allows to create a resolution variant using the requested high-resolution image size. ------------ public interface MultiResolutionImage { Image getResolutionVariant(float width, float height); } ------------ // create a multi-resolution image Image mrImage = new AbstractMultiResolutionImage() { public Image getResolutionVariant(float width, float height) { // create and return a resolution variant with exact requested width/height size } protected Image getBaseImage() { return baseImage; } }; ------------ // create a disabled image with resolution variants Image disabledImage = null; if (image instanceof MultiResolutionImage) { final MultiResolutionImage mrImage = (MultiResolutionImage) image; disabledImage = new AbstractMultiResolutionImage(){ public Image getResolutionVariant(float width, float height) { return getDisabledImage(mrImage.getResolutionVariant(width, height)); } protected Image getBaseImage() { return getDisabledImage(mrImage); } }; } else { disabledImage = getDisabledImage(image); } ------------ Thanks, Alexandr. From linuxhippy at gmail.com Thu Jan 22 23:18:53 2015 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Fri, 23 Jan 2015 00:18:53 +0100 Subject: [OpenJDK 2D-Dev] JDK-8068529 XSync when xrender is turned off In-Reply-To: References: Message-ID: Hi Jeroen, I'm the submitter of JDK-8068529 > and I'd like to > respond to the comments of this bug > Thanks for reporting this issue. > In reply to the comments of 2015-01-12: without xrender, XSync is indeed > called in X11SurfaceData.c, in function X11SD_GetSharedImage. If you change > the code to include a counter and a printf/fflush statement, you can see > that XSync is called each time the Java-method paint() is called. > This XSync call causes each paint to be displayed on the screen. > Great that you were able to find the spot where the sync happens, thanks! It seems it is what I suspected, an implementation artifact. However at least on my system I don't get a completly smooth animation even with the X11 pipeline - although it is a lot better than with the xrender pipeline. The D3D & OpenGL pipelines have some code to work around the issue by performing a sync for blits which are equal to the blits of Swing's backbuffer operations. However, I am not very satisfied with the D3d/OpenGL way. X is a network based system where sync/flush-operations are quite expensive and it would actually slow down every direct blit to screen. My plan was to introduce flush-points in AWT to get the content on screen where appropriate instead of guessing in the pipeline which operations could be backbuffer blits. However I am not even sure this is feasable, so it will take some time for to figure out a sane way. Best regards and thanks for your investigations, Clemens -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Fri Jan 23 09:24:13 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 23 Jan 2015 12:24:13 +0300 Subject: [OpenJDK 2D-Dev] JDK-8068529 XSync when xrender is turned off In-Reply-To: References: Message-ID: <54C2133D.4090608@oracle.com> Hi, Clemens. On 23.01.2015 2:18, Clemens Eisserer wrote: > The D3D & OpenGL pipelines have some code to work around the issue by > performing a sync for blits which are equal to the blits of Swing's > backbuffer operations. Actually it will do this for any blits to the window, because the swing can use different paint strategy(w/ or w/o buffer) or the user can draw something to the window directly via BufferStrategy. > My plan was to introduce flush-points in AWT to get the content on > screen where appropriate instead of guessing in the pipeline which > operations could be backbuffer blits. However I am not even sure this > is feasable, so it will take some time for to figure out a sane way. > > Best regards and thanks for your investigations, Clemens > -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From linuxhippy at gmail.com Fri Jan 23 10:01:30 2015 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Fri, 23 Jan 2015 11:01:30 +0100 Subject: [OpenJDK 2D-Dev] JDK-8068529 XSync when xrender is turned off In-Reply-To: <54C2133D.4090608@oracle.com> References: <54C2133D.4090608@oracle.com> Message-ID: Hi Sergey, Actually it will do this for any blits to the window, because the swing > can use different paint strategy(w/ or w/o buffer) or the user can draw > something to the window directly via BufferStrategy. > Thanks for the clarification. Is there a reason why AWT doesn't explicitly flush and why the flush-after-blit approach was chosen? Thanks & best regards, Clemens -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Fri Jan 23 10:14:49 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 23 Jan 2015 13:14:49 +0300 Subject: [OpenJDK 2D-Dev] JDK-8068529 XSync when xrender is turned off In-Reply-To: References: <54C2133D.4090608@oracle.com> Message-ID: <54C21F19.5020008@oracle.com> On 23.01.2015 13:01, Clemens Eisserer wrote: > Is there a reason why AWT doesn't explicitly flush and why the > flush-after-blit approach was chosen? If a sync will be implemented in a Swing, then will be necessary to add a sync to all places where we paint an images to the screen, and this is equivalent of current solution, no? -- Best regards, Sergey. From linuxhippy at gmail.com Fri Jan 23 11:04:52 2015 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Fri, 23 Jan 2015 12:04:52 +0100 Subject: [OpenJDK 2D-Dev] JDK-8068529 XSync when xrender is turned off In-Reply-To: <54C21F19.5020008@oracle.com> References: <54C2133D.4090608@oracle.com> <54C21F19.5020008@oracle.com> Message-ID: Hi Sergey, > Is there a reason why AWT doesn't explicitly flush and whythe >> flush-after-blit approach was chosen? >> > If a sync will be implemented in a Swing, then will be necessary to add a > sync to all places where we paint an images to the screen, and this is > equivalent of current solution, no? Instead of thinking on the j2d level (blits), wouldn't it be enough to flush after handling of events that can possibly issue paint-operations to screen? This would also have the advantage to have contents flushed to screen even for the non-doublebuffered case (if I modify the example to use a Frame instead a double-buffered JFrame I get stutter with all j2d pipelines). The reason why I am not very happy with the current way is because: 1. It doesn't cover all cases, like non-doublebuffered frames. 2. It can lead to excessive sync'ing. Imagine an AWT based J2D based game which renderes hundreds or even thousands of sprites directly to screen. While this might be acceptable for OGL/D3D, it for sure is a no-go for Xrender over network. 3. It is in my opinion at the wrong layer of abstraction, leading to semantics/heuristics encoded into J2D which don't belong there. Actually AWT knows when contents should be flushed to screen. J2D currently flushes after *every* Blit, regardless wether it is required or not. Also, it doesn't flush for other primitives like rects or lines making it's behaviour inconsistent. Best regards, Clemens -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Jan 23 18:48:11 2015 From: philip.race at oracle.com (Phil Race) Date: Fri, 23 Jan 2015 10:48:11 -0800 Subject: [OpenJDK 2D-Dev] [PATCH] Refactor X11FontManager In-Reply-To: <1421768530.30104.16.camel@localhost> References: <1421768530.30104.16.camel@localhost> Message-ID: <54C2976B.2030200@oracle.com> On 01/20/2015 07:42 AM, Roman Kennke wrote: > I already sent that patch to awt-dev for review, a while ago: > > http://mail.openjdk.java.net/pipermail/awt-dev/2015-January/008819.html > > I got no reply, so I'm sending it here, maybe it's a better fit? ;-) font related discussions should go to 2d-dev. The change looks OK. But test it as much as you can. The previous re-factoring in JDK7 had a fairly long bug trail. - Do submit a bug and mark it noreg-cleanup - Do get a 2nd reviewer before committing. - Do update the (C) in the new file to 2015 since the clock ticked since you first sent the review. -phil. > > > Hello, > > I am currently working on a port of AWT/Java2D to DirectFB (using > Caciocavallo [1] as a porting layer). > > I hit one obstacle that is the X11FontManager. I want to use fontconfig > to work with fonts, but can't use anything X11. > > I refactored X11FontManager and related classes and native code to avoid > calling anything X11 specific. Basically I created a superclass of > X11FontManager called FcFontManager that does all the fontconfig related > stuff, and use that in my backend. The changes should not affect the X11 > implementation. > > Can you please review the changes here: > > http://cr.openjdk.java.net/~rkennke/refactor-x11fm/webrev.00/ > > I would like to push this into jdk9-client if you think it's ok. > > Best regards, > Roman > > [1] http://openjdk.java.net/projects/caciocavallo/ > > > From philip.race at oracle.com Fri Jan 23 18:51:56 2015 From: philip.race at oracle.com (Phil Race) Date: Fri, 23 Jan 2015 10:51:56 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8064833 : [macosx] Native font lookup uses family+style, not full name/postscript name In-Reply-To: <54A3B6C0.7070600@oracle.com> References: <548F4279.5040002@oracle.com> <54A3B6C0.7070600@oracle.com> Message-ID: <54C2984C.4090709@oracle.com> 280-282 is creating an italic version of the plain font 285-287 is creating an italic version of the bold font : 285 registerGenericFont(bold.createItalicVariant(), true); 286 CFont f = bold.createItalicVariant(); 287 registerGenericFont(f, true); so its not the same variant. -phil. On 12/31/2014 12:41 AM, Andrew Brygin wrote: > Hello Phil, > > could you please clarify why do we need to register italic variant > twice: > CFontManager.java: > > 280 registerGenericFont(plain.createItalicVariant(), true); > 281 CFont f = plain.createItalicVariant(); > 282 registerGenericFont(f, true); > > the same thing is done for bold font on lines 285 - 287. > > Thanks, > Andrew > > On 12/15/2014 11:20 PM, Phil Race wrote: > >> https://bugs.openjdk.java.net/browse/JDK-8064833 >> http://cr.openjdk.java.net/~prr/8064833/ >> >> OS X font look up is using family name + style - even when using >> deriveFont >> from a specific font. Since the family name like "Helvetica" is >> insufficient to >> convey that you are using the "Helvetica Light" subfamily and we get the >> wronf font. >> The provided test shows that the results can be completely garbage >> rendering. >> >> Some clean up included here is remove the unconditional define of >> DEBUG and >> the native 'isFakeItalic' variable which was not used anywhere. >> >> -phil. > From philip.race at oracle.com Fri Jan 23 18:53:28 2015 From: philip.race at oracle.com (Phil Race) Date: Fri, 23 Jan 2015 10:53:28 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8064833 : [macosx] Native font lookup uses family+style, not full name/postscript name In-Reply-To: <54A136DA.2070009@oracle.com> References: <548F4279.5040002@oracle.com> <5499BE3E.4060808@oracle.com> <5499DEFB.3070808@oracle.com> <54A136DA.2070009@oracle.com> Message-ID: <54C298A8.8060008@oracle.com> On 12/29/2014 03:11 AM, Sergey Bylokhov wrote: > Hi, Phil. > The fix looks fine. Note that necessary tags are absent in the test > (@test etc). oops. I'll fix that before I push. This thread got lost over the long break and Andrew had a question (which) I just answered so I'll push awhen he comes back as OK with the answer. -phil. > > On 24.12.2014 0:30, Phil Race wrote: >> On 12/23/2014 11:10 AM, Sergey Bylokhov wrote: >>> Hi, Phil. >>> Probably it is possible to move the new code in >>> CFontManager.loadFonts() to the SunFontManager.loadFonts()? >> >> No .. its completely mac-specific. >> >>> Note that in the test the text "Big italic red text" should be >>> ..."black text", >> >> that was taken from the original bug. >> >>> and the window should be disposed at the end of the test. >> >> I can update the test before I push. >> >> > Why this test is mac specific? >> >> Because the whole problem is mac-specific and you can't find the >> situation >> with the fonts that cause this problem elsewhere. Its really iffy to >> test at all .. >> Note that I am using glyphcodes, which means you have to know exactly >> what font you have. >> >> -phil. >> >>> >>> On 15.12.2014 23:20, Phil Race wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8064833 >>>> http://cr.openjdk.java.net/~prr/8064833/ >>>> >>>> OS X font look up is using family name + style - even when using >>>> deriveFont >>>> from a specific font. Since the family name like "Helvetica" is >>>> insufficient to >>>> convey that you are using the "Helvetica Light" subfamily and we >>>> get the >>>> wronf font. >>>> The provided test shows that the results can be completely garbage >>>> rendering. >>>> >>>> Some clean up included here is remove the unconditional define of >>>> DEBUG and >>>> the native 'isFakeItalic' variable which was not used anywhere. >>>> >>>> -phil. >>> >>> >> > > From andrew.brygin at oracle.com Fri Jan 23 20:29:35 2015 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Fri, 23 Jan 2015 23:29:35 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8064833 : [macosx] Native font lookup uses family+style, not full name/postscript name In-Reply-To: <54C2984C.4090709@oracle.com> References: <548F4279.5040002@oracle.com> <54A3B6C0.7070600@oracle.com> <54C2984C.4090709@oracle.com> Message-ID: <54C2AF2F.1090309@oracle.com> Hi Phil, please see my comments inline. On 1/23/2015 9:51 PM, Phil Race wrote: > 280-282 is creating an italic version of the plain font > > 285-287 is creating an italic version of the bold font : > > 285 registerGenericFont(bold.createItalicVariant(), true); If my understanding is correct, here we have registered the bold italic first time > 286 CFont f = bold.createItalicVariant(); > 287 registerGenericFont(f, true); Here we have registered the same bold italic second time. My question was why do we have to register italic variant two times in row. Could you please clarify this? Thanks, Andrew > > so its not the same variant. > > -phil. > > > On 12/31/2014 12:41 AM, Andrew Brygin wrote: >> Hello Phil, >> >> could you please clarify why do we need to register italic variant >> twice: >> CFontManager.java: >> >> 280 registerGenericFont(plain.createItalicVariant(), true); >> 281 CFont f = plain.createItalicVariant(); >> 282 registerGenericFont(f, true); >> >> the same thing is done for bold font on lines 285 - 287. >> >> Thanks, >> Andrew >> >> On 12/15/2014 11:20 PM, Phil Race wrote: >> >>> https://bugs.openjdk.java.net/browse/JDK-8064833 >>> http://cr.openjdk.java.net/~prr/8064833/ >>> >>> OS X font look up is using family name + style - even when using >>> deriveFont >>> from a specific font. Since the family name like "Helvetica" is >>> insufficient to >>> convey that you are using the "Helvetica Light" subfamily and we get >>> the >>> wronf font. >>> The provided test shows that the results can be completely garbage >>> rendering. >>> >>> Some clean up included here is remove the unconditional define of >>> DEBUG and >>> the native 'isFakeItalic' variable which was not used anywhere. >>> >>> -phil. >> > From philip.race at oracle.com Fri Jan 23 20:42:31 2015 From: philip.race at oracle.com (Phil Race) Date: Fri, 23 Jan 2015 12:42:31 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8064833 : [macosx] Native font lookup uses family+style, not full name/postscript name In-Reply-To: <54C2AF2F.1090309@oracle.com> References: <548F4279.5040002@oracle.com> <54A3B6C0.7070600@oracle.com> <54C2984C.4090709@oracle.com> <54C2AF2F.1090309@oracle.com> Message-ID: <54C2B237.6070401@oracle.com> Ah you're right I don't need to do that :) It was a while ago now but it looks like I was using the assigned variable to do some debugging. I'll update the webrev - including the test. -phil. On 1/23/15 12:29 PM, Andrew Brygin wrote: > Hi Phil, > > please see my comments inline. > > On 1/23/2015 9:51 PM, Phil Race wrote: >> 280-282 is creating an italic version of the plain font >> >> 285-287 is creating an italic version of the bold font : >> >> 285 registerGenericFont(bold.createItalicVariant(), true); > If my understanding is correct, here we have registered the bold > italic first time >> 286 CFont f = bold.createItalicVariant(); >> 287 registerGenericFont(f, true); > Here we have registered the same bold italic second time. > My question was why do we have to register italic variant two times in > row. > Could you please clarify this? > > Thanks, > Andrew > >> >> so its not the same variant. >> >> -phil. >> >> >> On 12/31/2014 12:41 AM, Andrew Brygin wrote: >>> Hello Phil, >>> >>> could you please clarify why do we need to register italic variant >>> twice: >>> CFontManager.java: >>> >>> 280 registerGenericFont(plain.createItalicVariant(), true); >>> 281 CFont f = plain.createItalicVariant(); >>> 282 registerGenericFont(f, true); >>> >>> the same thing is done for bold font on lines 285 - 287. >>> >>> Thanks, >>> Andrew >>> >>> On 12/15/2014 11:20 PM, Phil Race wrote: >>> >>>> https://bugs.openjdk.java.net/browse/JDK-8064833 >>>> http://cr.openjdk.java.net/~prr/8064833/ >>>> >>>> OS X font look up is using family name + style - even when using >>>> deriveFont >>>> from a specific font. Since the family name like "Helvetica" is >>>> insufficient to >>>> convey that you are using the "Helvetica Light" subfamily and we >>>> get the >>>> wronf font. >>>> The provided test shows that the results can be completely garbage >>>> rendering. >>>> >>>> Some clean up included here is remove the unconditional define of >>>> DEBUG and >>>> the native 'isFakeItalic' variable which was not used anywhere. >>>> >>>> -phil. >>> >> > From philip.race at oracle.com Fri Jan 23 21:18:57 2015 From: philip.race at oracle.com (Phil Race) Date: Fri, 23 Jan 2015 13:18:57 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8064833 : [macosx] Native font lookup uses family+style, not full name/postscript name In-Reply-To: <54C2B237.6070401@oracle.com> References: <548F4279.5040002@oracle.com> <54A3B6C0.7070600@oracle.com> <54C2984C.4090709@oracle.com> <54C2AF2F.1090309@oracle.com> <54C2B237.6070401@oracle.com> Message-ID: <54C2BAC1.6000003@oracle.com> Updated webrev : http://cr.openjdk.java.net/~prr/8064833.1/ -phil On 1/23/15 12:42 PM, Phil Race wrote: > Ah you're right I don't need to do that :) > It was a while ago now but it looks like I was using the assigned > variable > to do some debugging. I'll update the webrev - including the test. > > -phil. > > On 1/23/15 12:29 PM, Andrew Brygin wrote: >> Hi Phil, >> >> please see my comments inline. >> >> On 1/23/2015 9:51 PM, Phil Race wrote: >>> 280-282 is creating an italic version of the plain font >>> >>> 285-287 is creating an italic version of the bold font : >>> >>> 285 registerGenericFont(bold.createItalicVariant(), true); >> If my understanding is correct, here we have registered the bold >> italic first time >>> 286 CFont f = bold.createItalicVariant(); >>> 287 registerGenericFont(f, true); >> Here we have registered the same bold italic second time. >> My question was why do we have to register italic variant two times >> in row. >> Could you please clarify this? >> >> Thanks, >> Andrew >> >>> >>> so its not the same variant. >>> >>> -phil. >>> >>> >>> On 12/31/2014 12:41 AM, Andrew Brygin wrote: >>>> Hello Phil, >>>> >>>> could you please clarify why do we need to register italic variant >>>> twice: >>>> CFontManager.java: >>>> >>>> 280 registerGenericFont(plain.createItalicVariant(), true); >>>> 281 CFont f = plain.createItalicVariant(); >>>> 282 registerGenericFont(f, true); >>>> >>>> the same thing is done for bold font on lines 285 - 287. >>>> >>>> Thanks, >>>> Andrew >>>> >>>> On 12/15/2014 11:20 PM, Phil Race wrote: >>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8064833 >>>>> http://cr.openjdk.java.net/~prr/8064833/ >>>>> >>>>> OS X font look up is using family name + style - even when using >>>>> deriveFont >>>>> from a specific font. Since the family name like "Helvetica" is >>>>> insufficient to >>>>> convey that you are using the "Helvetica Light" subfamily and we >>>>> get the >>>>> wronf font. >>>>> The provided test shows that the results can be completely garbage >>>>> rendering. >>>>> >>>>> Some clean up included here is remove the unconditional define of >>>>> DEBUG and >>>>> the native 'isFakeItalic' variable which was not used anywhere. >>>>> >>>>> -phil. >>>> >>> >> > From andrew.brygin at oracle.com Sat Jan 24 05:34:36 2015 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Sat, 24 Jan 2015 08:34:36 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8064833 : [macosx] Native font lookup uses family+style, not full name/postscript name In-Reply-To: <54C2BAC1.6000003@oracle.com> References: <548F4279.5040002@oracle.com> <54A3B6C0.7070600@oracle.com> <54C2984C.4090709@oracle.com> <54C2AF2F.1090309@oracle.com> <54C2B237.6070401@oracle.com> <54C2BAC1.6000003@oracle.com> Message-ID: <54C32EEC.4010801@oracle.com> Hello Phil, the fix looks fine to me. Thanks, Andrew On 1/24/2015 12:18 AM, Phil Race wrote: > Updated webrev : http://cr.openjdk.java.net/~prr/8064833.1/ > > -phil > > On 1/23/15 12:42 PM, Phil Race wrote: >> Ah you're right I don't need to do that :) >> It was a while ago now but it looks like I was using the assigned >> variable >> to do some debugging. I'll update the webrev - including the test. >> >> -phil. >> >> On 1/23/15 12:29 PM, Andrew Brygin wrote: >>> Hi Phil, >>> >>> please see my comments inline. >>> >>> On 1/23/2015 9:51 PM, Phil Race wrote: >>>> 280-282 is creating an italic version of the plain font >>>> >>>> 285-287 is creating an italic version of the bold font : >>>> >>>> 285 registerGenericFont(bold.createItalicVariant(), true); >>> If my understanding is correct, here we have registered the bold >>> italic first time >>>> 286 CFont f = bold.createItalicVariant(); >>>> 287 registerGenericFont(f, true); >>> Here we have registered the same bold italic second time. >>> My question was why do we have to register italic variant two times >>> in row. >>> Could you please clarify this? >>> >>> Thanks, >>> Andrew >>> >>>> >>>> so its not the same variant. >>>> >>>> -phil. >>>> >>>> >>>> On 12/31/2014 12:41 AM, Andrew Brygin wrote: >>>>> Hello Phil, >>>>> >>>>> could you please clarify why do we need to register italic >>>>> variant twice: >>>>> CFontManager.java: >>>>> >>>>> 280 registerGenericFont(plain.createItalicVariant(), true); >>>>> 281 CFont f = plain.createItalicVariant(); >>>>> 282 registerGenericFont(f, true); >>>>> >>>>> the same thing is done for bold font on lines 285 - 287. >>>>> >>>>> Thanks, >>>>> Andrew >>>>> >>>>> On 12/15/2014 11:20 PM, Phil Race wrote: >>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8064833 >>>>>> http://cr.openjdk.java.net/~prr/8064833/ >>>>>> >>>>>> OS X font look up is using family name + style - even when using >>>>>> deriveFont >>>>>> from a specific font. Since the family name like "Helvetica" is >>>>>> insufficient to >>>>>> convey that you are using the "Helvetica Light" subfamily and we >>>>>> get the >>>>>> wronf font. >>>>>> The provided test shows that the results can be completely >>>>>> garbage rendering. >>>>>> >>>>>> Some clean up included here is remove the unconditional define of >>>>>> DEBUG and >>>>>> the native 'isFakeItalic' variable which was not used anywhere. >>>>>> >>>>>> -phil. >>>>> >>>> >>> >> > From philip.race at oracle.com Tue Jan 27 21:24:09 2015 From: philip.race at oracle.com (Phil Race) Date: Tue, 27 Jan 2015 13:24:09 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8071710: [solaris] libfontmanager should be linked against headless awt library Message-ID: <54C801F9.1050005@oracle.com> Hi, A mistake was made in JDK 8 so that the font libraries for Solaris are now being linked against X11 libraries and this is a problem for headless (server) use For more details see : https://bugs.openjdk.java.net/browse/JDK-8071710 I am presenting jdk 9 & 8 fixes here since this needs a backport and the change is not identical The open part of the JDK 9 fix : http://cr.openjdk.java.net/~prr/8071710/ The complete JDK 8 fix : http://cr.openjdk.java.net/~prr/8071710.8u/ (the t2k linking was moved to closed at some point) I've submitted JPRT jobs and also verified that UI demos (like SwingSet2) still run -phil. From erik.joelsson at oracle.com Wed Jan 28 09:02:26 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 28 Jan 2015 10:02:26 +0100 Subject: [OpenJDK 2D-Dev] RFR: 8071710: [solaris] libfontmanager should be linked against headless awt library In-Reply-To: <54C801F9.1050005@oracle.com> References: <54C801F9.1050005@oracle.com> Message-ID: <54C8A5A2.3070506@oracle.com> Looks good to me. Nice to get rid of the weird X_LIBS dependency. /Erik On 2015-01-27 22:24, Phil Race wrote: > Hi, > > A mistake was made in JDK 8 so that the font libraries for Solaris are > now > being linked against X11 libraries and this is a problem for headless > (server) use > For more details see : > https://bugs.openjdk.java.net/browse/JDK-8071710 > > I am presenting jdk 9 & 8 fixes here since this needs a backport and the > change is not identical > > The open part of the JDK 9 fix : http://cr.openjdk.java.net/~prr/8071710/ > > The complete JDK 8 fix : http://cr.openjdk.java.net/~prr/8071710.8u/ > (the t2k linking was moved to closed at some point) > > I've submitted JPRT jobs and also verified that UI demos (like > SwingSet2) still run > > -phil. > > > From magnus.ihse.bursie at oracle.com Wed Jan 28 13:15:27 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 28 Jan 2015 14:15:27 +0100 Subject: [OpenJDK 2D-Dev] RFR: 8071710: [solaris] libfontmanager should be linked against headless awt library In-Reply-To: <54C801F9.1050005@oracle.com> References: <54C801F9.1050005@oracle.com> Message-ID: <54C8E0EF.2010107@oracle.com> On 2015-01-27 22:24, Phil Race wrote: > Hi, > > A mistake was made in JDK 8 so that the font libraries for Solaris are > now > being linked against X11 libraries and this is a problem for headless > (server) use > For more details see : > https://bugs.openjdk.java.net/browse/JDK-8071710 > > I am presenting jdk 9 & 8 fixes here since this needs a backport and the > change is not identical > > The open part of the JDK 9 fix : http://cr.openjdk.java.net/~prr/8071710/ > > The complete JDK 8 fix : http://cr.openjdk.java.net/~prr/8071710.8u/ > (the t2k linking was moved to closed at some point) > > I've submitted JPRT jobs and also verified that UI demos (like > SwingSet2) still run There is an additional fix you need to to, otherwise you will introduce a race condition. This code: ifneq (, $(findstring $(OPENJDK_TARGET_OS), solaris aix)) $(BUILD_LIBFONTMANAGER): $(BUILD_LIBAWT_XAWT) endif makes sure that libfontmanager is not built until libawt_xawt is present (otherwise linking will fail). With your patch, you should change this to ifeq ($(OPENJDK_TARGET_OS), aix)) $(BUILD_LIBFONTMANAGER): $(BUILD_LIBAWT_XAWT) else ifeq ($(OPENJDK_TARGET_OS), solaris)) $(BUILD_LIBFONTMANAGER): $(BUILD_LIBAWT_HEADLESS) endif Otherwise, it looks good. Erik and I have been discussing for some time to change the framework so this kind of dependencies will be automatically enforced, but somehow that idea always gets pushed down the priority slide. :( /Magnus From erik.joelsson at oracle.com Wed Jan 28 13:20:40 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 28 Jan 2015 14:20:40 +0100 Subject: [OpenJDK 2D-Dev] RFR: 8071710: [solaris] libfontmanager should be linked against headless awt library In-Reply-To: <54C8E0EF.2010107@oracle.com> References: <54C801F9.1050005@oracle.com> <54C8E0EF.2010107@oracle.com> Message-ID: <54C8E228.2050008@oracle.com> Hello, On 2015-01-28 14:15, Magnus Ihse Bursie wrote: > On 2015-01-27 22:24, Phil Race wrote: >> Hi, >> >> A mistake was made in JDK 8 so that the font libraries for Solaris >> are now >> being linked against X11 libraries and this is a problem for headless >> (server) use >> For more details see : >> https://bugs.openjdk.java.net/browse/JDK-8071710 >> >> I am presenting jdk 9 & 8 fixes here since this needs a backport and the >> change is not identical >> >> The open part of the JDK 9 fix : >> http://cr.openjdk.java.net/~prr/8071710/ >> >> The complete JDK 8 fix : http://cr.openjdk.java.net/~prr/8071710.8u/ >> (the t2k linking was moved to closed at some point) >> >> I've submitted JPRT jobs and also verified that UI demos (like >> SwingSet2) still run > > There is an additional fix you need to to, otherwise you will > introduce a race condition. > > This code: > ifneq (, $(findstring $(OPENJDK_TARGET_OS), solaris aix)) > $(BUILD_LIBFONTMANAGER): $(BUILD_LIBAWT_XAWT) > endif > Thanks for noticing this Magnus! > makes sure that libfontmanager is not built until libawt_xawt is > present (otherwise linking will fail). With your patch, you should > change this to > > ifeq ($(OPENJDK_TARGET_OS), aix)) > $(BUILD_LIBFONTMANAGER): $(BUILD_LIBAWT_XAWT) > else ifeq ($(OPENJDK_TARGET_OS), solaris)) > $(BUILD_LIBFONTMANAGER): $(BUILD_LIBAWT_HEADLESS) > endif > Actually, in the jdk8 patch, only solaris is changed, but in the jdk9 patch, both aix and solaris are changed. If that is indeed the intention, the above is correct for jdk8, but I suspect the changes should match? /Erik > Otherwise, it looks good. > > Erik and I have been discussing for some time to change the framework > so this kind of dependencies will be automatically enforced, but > somehow that idea always gets pushed down the priority slide. :( > > /Magnus From philip.race at oracle.com Wed Jan 28 19:04:10 2015 From: philip.race at oracle.com (Phil Race) Date: Wed, 28 Jan 2015 11:04:10 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8071710: [solaris] libfontmanager should be linked against headless awt library In-Reply-To: <54C8E0EF.2010107@oracle.com> References: <54C801F9.1050005@oracle.com> <54C8E0EF.2010107@oracle.com> Message-ID: <54C932AA.7040701@oracle.com> I have updated both the patches to add the dependency that headless awt must be built first and also corrected that AIX should be given the same treatment as Solaris in both releases : jdk9: http://cr.openjdk.java.net/~prr/8071710.1/ jdk8u: http://cr.openjdk.java.net/~prr/8071710.8u.1/ -phil. On 01/28/2015 05:15 AM, Magnus Ihse Bursie wrote: > On 2015-01-27 22:24, Phil Race wrote: >> Hi, >> >> A mistake was made in JDK 8 so that the font libraries for Solaris >> are now >> being linked against X11 libraries and this is a problem for headless >> (server) use >> For more details see : >> https://bugs.openjdk.java.net/browse/JDK-8071710 >> >> I am presenting jdk 9 & 8 fixes here since this needs a backport and the >> change is not identical >> >> The open part of the JDK 9 fix : >> http://cr.openjdk.java.net/~prr/8071710/ >> >> The complete JDK 8 fix : http://cr.openjdk.java.net/~prr/8071710.8u/ >> (the t2k linking was moved to closed at some point) >> >> I've submitted JPRT jobs and also verified that UI demos (like >> SwingSet2) still run > > There is an additional fix you need to to, otherwise you will > introduce a race condition. > > This code: > ifneq (, $(findstring $(OPENJDK_TARGET_OS), solaris aix)) > $(BUILD_LIBFONTMANAGER): $(BUILD_LIBAWT_XAWT) > endif > > makes sure that libfontmanager is not built until libawt_xawt is > present (otherwise linking will fail). With your patch, you should > change this to > > ifeq ($(OPENJDK_TARGET_OS), aix)) > $(BUILD_LIBFONTMANAGER): $(BUILD_LIBAWT_XAWT) > else ifeq ($(OPENJDK_TARGET_OS), solaris)) > $(BUILD_LIBFONTMANAGER): $(BUILD_LIBAWT_HEADLESS) > endif > > Otherwise, it looks good. > > Erik and I have been discussing for some time to change the framework > so this kind of dependencies will be automatically enforced, but > somehow that idea always gets pushed down the priority slide. :( > > /Magnus From erik.joelsson at oracle.com Thu Jan 29 08:22:38 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 29 Jan 2015 09:22:38 +0100 Subject: [OpenJDK 2D-Dev] RFR: 8071710: [solaris] libfontmanager should be linked against headless awt library In-Reply-To: <54C932AA.7040701@oracle.com> References: <54C801F9.1050005@oracle.com> <54C8E0EF.2010107@oracle.com> <54C932AA.7040701@oracle.com> Message-ID: <54C9EDCE.5080005@oracle.com> Thanks, that looks good to me. /Erik On 2015-01-28 20:04, Phil Race wrote: > I have updated both the patches to add the dependency that headless awt > must be built first and also corrected that AIX should be given the > same treatment > as Solaris in both releases : > jdk9: http://cr.openjdk.java.net/~prr/8071710.1/ > jdk8u: http://cr.openjdk.java.net/~prr/8071710.8u.1/ > > -phil. > > On 01/28/2015 05:15 AM, Magnus Ihse Bursie wrote: >> On 2015-01-27 22:24, Phil Race wrote: >>> Hi, >>> >>> A mistake was made in JDK 8 so that the font libraries for Solaris >>> are now >>> being linked against X11 libraries and this is a problem for >>> headless (server) use >>> For more details see : >>> https://bugs.openjdk.java.net/browse/JDK-8071710 >>> >>> I am presenting jdk 9 & 8 fixes here since this needs a backport and >>> the >>> change is not identical >>> >>> The open part of the JDK 9 fix : >>> http://cr.openjdk.java.net/~prr/8071710/ >>> >>> The complete JDK 8 fix : http://cr.openjdk.java.net/~prr/8071710.8u/ >>> (the t2k linking was moved to closed at some point) >>> >>> I've submitted JPRT jobs and also verified that UI demos (like >>> SwingSet2) still run >> >> There is an additional fix you need to to, otherwise you will >> introduce a race condition. >> >> This code: >> ifneq (, $(findstring $(OPENJDK_TARGET_OS), solaris aix)) >> $(BUILD_LIBFONTMANAGER): $(BUILD_LIBAWT_XAWT) >> endif >> >> makes sure that libfontmanager is not built until libawt_xawt is >> present (otherwise linking will fail). With your patch, you should >> change this to >> >> ifeq ($(OPENJDK_TARGET_OS), aix)) >> $(BUILD_LIBFONTMANAGER): $(BUILD_LIBAWT_XAWT) >> else ifeq ($(OPENJDK_TARGET_OS), solaris)) >> $(BUILD_LIBFONTMANAGER): $(BUILD_LIBAWT_HEADLESS) >> endif >> >> Otherwise, it looks good. >> >> Erik and I have been discussing for some time to change the framework >> so this kind of dependencies will be automatically enforced, but >> somehow that idea always gets pushed down the priority slide. :( >> >> /Magnus > From sergey.bylokhov at oracle.com Thu Jan 29 10:51:58 2015 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 29 Jan 2015 02:51:58 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review Request: 4952954 abort flag is not cleared for every write operation for JPEG ImageWriter Message-ID: <75b6e773-19eb-43a1-8a2f-41a845e45c18@default> Hello. Please review the fix for jdk 9. After the fix a jpeg plugin will clear abort flag and reset the native state when the write method will be called after abort. Bug: https://bugs.openjdk.java.net/browse/JDK-4952954 Webrev can be found at: http://cr.openjdk.java.net/~serb/4952954/webrev.00 -- Best regards, Sergey. From magnus.ihse.bursie at oracle.com Fri Jan 30 10:35:57 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 30 Jan 2015 11:35:57 +0100 Subject: [OpenJDK 2D-Dev] RFR: 8071710: [solaris] libfontmanager should be linked against headless awt library In-Reply-To: <54C932AA.7040701@oracle.com> References: <54C801F9.1050005@oracle.com> <54C8E0EF.2010107@oracle.com> <54C932AA.7040701@oracle.com> Message-ID: <54CB5E8D.3030601@oracle.com> On 2015-01-28 20:04, Phil Race wrote: > I have updated both the patches to add the dependency that headless awt > must be built first and also corrected that AIX should be given the > same treatment > as Solaris in both releases : > jdk9: http://cr.openjdk.java.net/~prr/8071710.1/ > jdk8u: http://cr.openjdk.java.net/~prr/8071710.8u.1/ Looks good to me. /Magnus