From denis.fokin at gmail.com Wed Sep 3 11:32:51 2014 From: denis.fokin at gmail.com (Denis Fokin) Date: Wed, 3 Sep 2014 15:32:51 +0400 Subject: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON In-Reply-To: <53BD5E45.4000805@oracle.com> References: <53BD5E45.4000805@oracle.com> Message-ID: <9A5D5D1C-F58F-4DFC-B327-9A9DB18B155E@gmail.com> Hi Sergey and 2d team, I have rewritten the fix. It works fine for text rendered on window using OpenGL. http://web-dot.ru/openjdk/8023794/webrev.00/index.html It is incomplete though. It does not work for rendering in a buffered image. Additionally, I have not tested the code on other platforms except MacOS X. To enable the antialiasing you should pass -Dapple.awt.graphics.UseQuartz=true to java. The current issue now is the glyph info bytes that are passed from CGGlyphImage to AATextRenderer. To render data we use DEFINE_SOLID_DRAWGLYPHLIST* macros. Basing on the macros a set of functions is generated for the next loops. sun/java2d/loops/ByteGray.c sun/java2d/loops/ByteIndexed.c sun/java2d/loops/FourByteAbgr.c sun/java2d/loops/FourByteAbgrPre.c sun/java2d/loops/Index12Gray.c sun/java2d/loops/Index8Gray.c sun/java2d/loops/IntArgb.c sun/java2d/loops/IntArgbBm.c sun/java2d/loops/IntArgbPre.c sun/java2d/loops/IntBgr.c sun/java2d/loops/IntRgb.c sun/java2d/loops/IntRgbx.c sun/java2d/loops/LoopMacros.h sun/java2d/loops/ThreeByteBgr.c sun/java2d/loops/Ushort555Rgb.c sun/java2d/loops/Ushort555Rgbx.c sun/java2d/loops/Ushort565Rgb.c sun/java2d/loops/UshortGray.c sun/java2d/loops/UshortIndexed.c For instance, C preprocessor generates the next code for IntRgb.c void IntRgbDrawGlyphListLCD(/*?*/){ jint glyphCounter, bpp; jint scan = pRasInfo->scanStride; IntRgbDataType *pPix; fprintf(__stderrp, "NAME_SOLID_DRAWGLYPHLISTLC\n"); jint srcA; jint srcR , srcG, srcB;;;; do { (srcB) = (argbcolor) & 0xff; (srcG) = ((argbcolor) >> 8) & 0xff; (srcR) = ((argbcolor) >> 16) & 0xff; (srcA) = ((argbcolor) >> 24) & 0xff; } while (0);; // and so on? Looks like rgb loop expects to see 4 8-bit color channels per pixel. For now, I do not understand which contract should be honoured to meet DEFINE_SOLID_DRAWGLYPHLIST* expectations, i.e. how should I place bytes in GlyphInfo. May be it should be set somewhere in Java code. Could anyone share this knowledge with me? Thank you, Denis. On 09 Jul 2014, at 19:22, Sergey Bylokhov wrote: > Hello, Denis. > Thanks for this research! > On 09.07.2014 15:13, Denis Fokin wrote: >> The current version consist of three parts. >> >> 1. We are rendering glyphs in offscreen images using Quartz functions. This does not work without kCGBitmapByteOrder32Host mask. > I assume LCD hint does not work? this looks good. >> >> 2. We assume that subpixel antialiasing should not be used on a non-opaque surface. As I understand the vImage in CGLVolatileSurfaceManager is not related directly to our window. For a start, I have hardcoded Transparency.OPAQUE, but it requires much better understanding of the architecture to make a more proper solution. > It is related to the CGLOffScreenSurfaceData, which is used as a surface for VolatileImages. I check this code and looks like we ignore type of the ColorModel and create a transparent native texture anyway. >> >> 3. When I started using CGGI_CopyImageFromCanvasToRGBInfo as a rendering mode, I had found that the little endian mode should be undefined. Again, it might be an improper way to do this. > It seems __LITTLE_ENDIAN__usage in this file should be checked. >> >> Thank you, >> Denis. >> >> diff -r f87c5be90e01 src/macosx/classes/sun/java2d/opengl/CGLVolatileSurfaceManager.java >> >> --- a/src/macosx/classes/sun/java2d/opengl/CGLVolatileSurfaceManager.javaFri Jun 20 10:15:30 2014 -0700 >> >> +++ b/src/macosx/classes/sun/java2d/opengl/CGLVolatileSurfaceManager.javaWed Jul 09 14:50:09 2014 +0400 >> >> @@ -108,7 +108,7 @@ >> >> } else { >> >> CGLGraphicsConfig gc = >> >> (CGLGraphicsConfig)vImg.getGraphicsConfig(); >> >> - ColorModel cm = gc.getColorModel(vImg.getTransparency()); >> >> + ColorModel cm = gc.getColorModel(Transparency.OPAQUE); >> >> int type = vImg.getForcedAccelSurfaceType(); >> >> // if acceleration type is forced (type != UNDEFINED) then >> >> // use the forced type, otherwise choose one based on caps >> >> diff -r f87c5be90e01 src/macosx/native/sun/font/CGGlyphImages.m >> >> --- a/src/macosx/native/sun/font/CGGlyphImages.mFri Jun 20 10:15:30 2014 -0700 >> >> +++ b/src/macosx/native/sun/font/ .mWed Jul 09 14:50:09 2014 +0400 >> >> @@ -196,6 +196,8 @@ >> >> #pragma mark --- Font Rendering Mode Descriptors --- >> >> +#undef __LITTLE_ENDIAN__ >> >> + >> >> static inline void >> >> CGGI_CopyARGBPixelToRGBPixel(const UInt32 p, UInt8 *dst) >> >> { >> >> @@ -366,7 +368,8 @@ >> >> canvas->context = CGBitmapContextCreate(canvas->image->data, >> >> width, height, 8, bytesPerRow, >> >> colorSpace, >> >> - kCGImageAlphaPremultipliedFirst); >> >> + kCGImageAlphaPremultipliedFirst >> >> + | kCGBitmapByteOrder32Host); >> >> CGContextSetRGBFillColor(canvas->context, 0.0f, 0.0f, 0.0f, 1.0f); >> >> CGContextSetFontSize(canvas->context, 1); >> > > > -- > Best regards, Sergey. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.brygin at oracle.com Wed Sep 3 12:23:32 2014 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Wed, 03 Sep 2014 16:23:32 +0400 Subject: [OpenJDK 2D-Dev] [9] request for review: 8041465: BMPImageReader read error using ImageReadParam with set sourceRectangle Message-ID: <54070844.4010906@oracle.com> Hello, could you please review a fix for CR 8041465? Bug: https://bugs.openjdk.java.net/browse/JDK-8041465 Webrev: http://cr.openjdk.java.net/~bae/8041465/9/webrev.00/ The problem happens if we perform multiple read operations from a source which is set only once. For instance, we can try to read image in several tiles. The root case of the problem is that we set stream position to the start of raster data only once: when we complete the processing of BMP header. A peculiarity of BMP format is that raster data can be stored in reverse order, so if we request few leading scanlines first, then we skip rest of raster data, and subsequent read command does not copy anything to the destination buffer, because we never re-set the stream position to the start of bitmap. Suggested fix just saves the bitmap's start postilion and seeks the stream to to it each time when we read image. This change makes the BMP reader behavior exactly same as other standard plugin demonstrate. Supplied regression test demonstrates the problem. Please take a look. Thanks, Andrew. From philip.race at oracle.com Wed Sep 3 19:20:57 2014 From: philip.race at oracle.com (Phil Race) Date: Wed, 03 Sep 2014 12:20:57 -0700 Subject: [OpenJDK 2D-Dev] [9] request for review: 8041465: BMPImageReader read error using ImageReadParam with set sourceRectangle In-Reply-To: <54070844.4010906@oracle.com> References: <54070844.4010906@oracle.com> Message-ID: <54076A19.5080607@oracle.com> Looks good. -phil. On 9/3/2014 5:23 AM, Andrew Brygin wrote: > Hello, > > could you please review a fix for CR 8041465? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8041465 > Webrev: http://cr.openjdk.java.net/~bae/8041465/9/webrev.00/ > > The problem happens if we perform multiple read operations from > a source which is set only once. For instance, we can try to read > image in several tiles. > > The root case of the problem is that we set stream position > to the start of raster data only once: when we complete > the processing of BMP header. A peculiarity of BMP format > is that raster data can be stored in reverse order, so if we > request few leading scanlines first, then we skip rest of raster > data, and subsequent read command does not copy anything to the > destination buffer, because we never re-set the stream position > to the start of bitmap. > > Suggested fix just saves the bitmap's start postilion and seeks > the stream to to it each time when we read image. This change > makes the BMP reader behavior exactly same as other standard plugin > demonstrate. > > Supplied regression test demonstrates the problem. > > Please take a look. > > Thanks, > Andrew. From jennifer.godinez at oracle.com Wed Sep 3 21:41:23 2014 From: jennifer.godinez at oracle.com (Jennifer Godinez) Date: Wed, 03 Sep 2014 14:41:23 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8056122: Upgrade JDK to use LittleCMS 2.6 In-Reply-To: <53FD0991.4080700@oracle.com> References: <53FD0991.4080700@oracle.com> Message-ID: <54078B03.3040207@oracle.com> Hi Phil, Is there any change to the file cmsgats.c? This sdiff link, shows blank. http://cr.openjdk.java.net/~prr/8056122/src/java.desktop/share/native/liblcms/cmscgats.c.sdiff.html Jennifer On 08/26/2014 03:26 PM, Phil Race wrote: > Andrew (and at least one other brave soul), please review :- > > http://cr.openjdk.java.net/~prr/8056122/ > > -phil. From philip.race at oracle.com Wed Sep 3 21:54:25 2014 From: philip.race at oracle.com (Phil Race) Date: Wed, 03 Sep 2014 14:54:25 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8056122: Upgrade JDK to use LittleCMS 2.6 In-Reply-To: <54078B03.3040207@oracle.com> References: <53FD0991.4080700@oracle.com> <54078B03.3040207@oracle.com> Message-ID: <54078E11.7040505@oracle.com> No actual change. Perhaps there was white space .. -phil. On 9/3/2014 2:41 PM, Jennifer Godinez wrote: > Hi Phil, > > Is there any change to the file cmsgats.c? This sdiff link, shows blank. > http://cr.openjdk.java.net/~prr/8056122/src/java.desktop/share/native/liblcms/cmscgats.c.sdiff.html > > > Jennifer > > > On 08/26/2014 03:26 PM, Phil Race wrote: >> Andrew (and at least one other brave soul), please review :- >> >> http://cr.openjdk.java.net/~prr/8056122/ >> >> -phil. > From jennifer.godinez at oracle.com Wed Sep 3 21:52:59 2014 From: jennifer.godinez at oracle.com (Jennifer Godinez) Date: Wed, 03 Sep 2014 14:52:59 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8056122: Upgrade JDK to use LittleCMS 2.6 In-Reply-To: <54078E11.7040505@oracle.com> References: <53FD0991.4080700@oracle.com> <54078B03.3040207@oracle.com> <54078E11.7040505@oracle.com> Message-ID: <54078DBB.6050001@oracle.com> Everything looks good. Jennifer On 09/03/2014 02:54 PM, Phil Race wrote: > No actual change. Perhaps there was white space .. > > -phil. > > On 9/3/2014 2:41 PM, Jennifer Godinez wrote: >> Hi Phil, >> >> Is there any change to the file cmsgats.c? This sdiff link, shows blank. >> http://cr.openjdk.java.net/~prr/8056122/src/java.desktop/share/native/liblcms/cmscgats.c.sdiff.html >> >> >> Jennifer >> >> >> On 08/26/2014 03:26 PM, Phil Race wrote: >>> Andrew (and at least one other brave soul), please review :- >>> >>> http://cr.openjdk.java.net/~prr/8056122/ >>> >>> -phil. >> > From philip.race at oracle.com Thu Sep 4 16:11:13 2014 From: philip.race at oracle.com (Phil Race) Date: Thu, 04 Sep 2014 09:11:13 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8056122: Upgrade JDK to use LittleCMS 2.6 In-Reply-To: <54078DBB.6050001@oracle.com> References: <53FD0991.4080700@oracle.com> <54078B03.3040207@oracle.com> <54078E11.7040505@oracle.com> <54078DBB.6050001@oracle.com> Message-ID: <54088F21.6010905@oracle.com> PS just to confirm what I said I looked at the only changeset that touched this file : https://github.com/mm2/Little-CMS/commit/fda1211c344178b05b71b5c8e0b45412b49c0599#diff-a8708d889f42afb45a1c37b5fd2064d7 and if you locate (just) that file in there you'll see it was only white space changes. -phil. On 9/3/2014 2:52 PM, Jennifer Godinez wrote: > Everything looks good. > > Jennifer > On 09/03/2014 02:54 PM, Phil Race wrote: >> No actual change. Perhaps there was white space .. >> >> -phil. >> >> On 9/3/2014 2:41 PM, Jennifer Godinez wrote: >>> Hi Phil, >>> >>> Is there any change to the file cmsgats.c? This sdiff link, shows >>> blank. >>> http://cr.openjdk.java.net/~prr/8056122/src/java.desktop/share/native/liblcms/cmscgats.c.sdiff.html >>> >>> >>> Jennifer >>> >>> >>> On 08/26/2014 03:26 PM, Phil Race wrote: >>>> Andrew (and at least one other brave soul), please review :- >>>> >>>> http://cr.openjdk.java.net/~prr/8056122/ >>>> >>>> -phil. >>> >> > From philip.race at oracle.com Thu Sep 4 21:48:32 2014 From: philip.race at oracle.com (Phil Race) Date: Thu, 04 Sep 2014 14:48:32 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8056209 : Remove unused files for libawt Message-ID: <5408DE30.1050905@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8056209 Proposed removing several files ./windows/native/libawt/sun/java2d/d3d/D3DPipeline.cpp ./windows/native/libawt/sun/java2d/d3d/D3DShaderGen.c ./windows/native/libawt/sun/windows/WBufferStrategy.cpp After some analysis the actual list of files to remove is src/java.desktop/windows/native/libawt/sun/java2d/d3d/D3DPipeline.cpp - this file appears to be unneeded and has never been built src/java.desktop/windows/classes/sun/awt/windows\WBufferStrategy.java src/java.desktop/windows/native/libawt/sun/windows/WBufferStrategy.cpp - both of these files have not been built since 6u10 D3DShaderGen.c needs to remain. It perhaps should live somewhere else but it also needs a bit of maintenance. A new bug should be filed on that here's a webrev for what value it adds :- http://cr.openjdk.java.net/~prr/8056209/ I did a full clean windows build to test the change. -phil. From erik.joelsson at oracle.com Fri Sep 5 09:42:11 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 05 Sep 2014 11:42:11 +0200 Subject: [OpenJDK 2D-Dev] RFR: 8056209 : Remove unused files for libawt In-Reply-To: <5408DE30.1050905@oracle.com> References: <5408DE30.1050905@oracle.com> Message-ID: <54098573.7040107@oracle.com> Looks good to me. /Erik On 2014-09-04 23:48, Phil Race wrote: > https://bugs.openjdk.java.net/browse/JDK-8056209 > Proposed removing several files > ./windows/native/libawt/sun/java2d/d3d/D3DPipeline.cpp > ./windows/native/libawt/sun/java2d/d3d/D3DShaderGen.c > ./windows/native/libawt/sun/windows/WBufferStrategy.cpp > > After some analysis the actual list of files to remove is > > src/java.desktop/windows/native/libawt/sun/java2d/d3d/D3DPipeline.cpp > > - this file appears to be unneeded and has never been built > > src/java.desktop/windows/classes/sun/awt/windows\WBufferStrategy.java > src/java.desktop/windows/native/libawt/sun/windows/WBufferStrategy.cpp > > - both of these files have not been built since 6u10 > > D3DShaderGen.c needs to remain. It perhaps should live somewhere else > but it also needs a bit of maintenance. A new bug should be filed on that > > here's a webrev for what value it adds :- > http://cr.openjdk.java.net/~prr/8056209/ > > I did a full clean windows build to test the change. > > -phil. > > From magnus.ihse.bursie at oracle.com Fri Sep 5 10:01:18 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 05 Sep 2014 12:01:18 +0200 Subject: [OpenJDK 2D-Dev] RFR: 8056209 : Remove unused files for libawt In-Reply-To: <5408DE30.1050905@oracle.com> References: <5408DE30.1050905@oracle.com> Message-ID: <540989EE.3090800@oracle.com> On 2014-09-04 23:48, Phil Race wrote: > https://bugs.openjdk.java.net/browse/JDK-8056209 > Proposed removing several files > ./windows/native/libawt/sun/java2d/d3d/D3DPipeline.cpp > ./windows/native/libawt/sun/java2d/d3d/D3DShaderGen.c > ./windows/native/libawt/sun/windows/WBufferStrategy.cpp > > After some analysis the actual list of files to remove is > > src/java.desktop/windows/native/libawt/sun/java2d/d3d/D3DPipeline.cpp > > - this file appears to be unneeded and has never been built > > src/java.desktop/windows/classes/sun/awt/windows\WBufferStrategy.java > src/java.desktop/windows/native/libawt/sun/windows/WBufferStrategy.cpp > > - both of these files have not been built since 6u10 > > D3DShaderGen.c needs to remain. It perhaps should live somewhere else > but it also needs a bit of maintenance. A new bug should be filed on that > > here's a webrev for what value it adds :- > http://cr.openjdk.java.net/~prr/8056209/ Actually, we need to update the makefiles as well, since these are listed as exceptions. diff -r 99da8eb27d0a make/lib/Awt2dLibraries.gmk --- a/make/lib/Awt2dLibraries.gmk Wed Aug 27 10:14:16 2014 +0200 +++ b/make/lib/Awt2dLibraries.gmk Fri Sep 05 12:00:45 2014 +0200 @@ -216,10 +216,8 @@ -I$(JDK_OUTPUTDIR)/gensrc_headers/java.base \ # LIBAWT_EXFILES += \ - sun/java2d/d3d/D3DPipeline.cpp \ sun/java2d/d3d/D3DShaderGen.c \ sun/awt/image/cvutils/img_colors.c \ - sun/windows/WBufferStrategy.cpp \ # LIBAWT_LANG := C++ Thanks for addressing this Phil! /Magnus From philip.race at oracle.com Fri Sep 5 15:59:46 2014 From: philip.race at oracle.com (Phil Race) Date: Fri, 05 Sep 2014 08:59:46 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8056209 : Remove unused files for libawt In-Reply-To: <540989EE.3090800@oracle.com> References: <5408DE30.1050905@oracle.com> <540989EE.3090800@oracle.com> Message-ID: <5409DDF2.7050308@oracle.com> > Actually, we need to update the makefiles as well, since these are listed as exceptions. Gosh ... I should have remembered that to begin with. Here's the fixed patch http://cr.openjdk.java.net/~prr/8056209.1 -phil On 09/05/2014 03:01 AM, Magnus Ihse Bursie wrote: > On 2014-09-04 23:48, Phil Race wrote: >> https://bugs.openjdk.java.net/browse/JDK-8056209 >> Proposed removing several files >> ./windows/native/libawt/sun/java2d/d3d/D3DPipeline.cpp >> ./windows/native/libawt/sun/java2d/d3d/D3DShaderGen.c >> ./windows/native/libawt/sun/windows/WBufferStrategy.cpp >> >> After some analysis the actual list of files to remove is >> >> src/java.desktop/windows/native/libawt/sun/java2d/d3d/D3DPipeline.cpp >> >> - this file appears to be unneeded and has never been built >> >> src/java.desktop/windows/classes/sun/awt/windows\WBufferStrategy.java >> src/java.desktop/windows/native/libawt/sun/windows/WBufferStrategy.cpp >> >> - both of these files have not been built since 6u10 >> >> D3DShaderGen.c needs to remain. It perhaps should live somewhere else >> but it also needs a bit of maintenance. A new bug should be filed on >> that >> >> here's a webrev for what value it adds :- >> http://cr.openjdk.java.net/~prr/8056209/ > > Actually, we need to update the makefiles as well, since these are > listed as exceptions. > > diff -r 99da8eb27d0a make/lib/Awt2dLibraries.gmk > --- a/make/lib/Awt2dLibraries.gmk Wed Aug 27 10:14:16 2014 +0200 > +++ b/make/lib/Awt2dLibraries.gmk Fri Sep 05 12:00:45 2014 +0200 > @@ -216,10 +216,8 @@ > -I$(JDK_OUTPUTDIR)/gensrc_headers/java.base \ > # > LIBAWT_EXFILES += \ > - sun/java2d/d3d/D3DPipeline.cpp \ > sun/java2d/d3d/D3DShaderGen.c \ > sun/awt/image/cvutils/img_colors.c \ > - sun/windows/WBufferStrategy.cpp \ > # > > LIBAWT_LANG := C++ > > Thanks for addressing this Phil! > > /Magnus From philip.race at oracle.com Fri Sep 5 16:05:51 2014 From: philip.race at oracle.com (Phil Race) Date: Fri, 05 Sep 2014 09:05:51 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8056209 : Remove unused files for libawt In-Reply-To: <5409DDF2.7050308@oracle.com> References: <5408DE30.1050905@oracle.com> <540989EE.3090800@oracle.com> <5409DDF2.7050308@oracle.com> Message-ID: <5409DF5F.8050009@oracle.com> PS i filed https://bugs.openjdk.java.net/browse/JDK-8057711 to track D3DShaderGen.c -phil. On 09/05/2014 08:59 AM, Phil Race wrote: > > Actually, we need to update the makefiles as well, since these are > listed as exceptions. > > Gosh ... I should have remembered that to begin with. > > Here's the fixed patch http://cr.openjdk.java.net/~prr/8056209.1 > > -phil > > On 09/05/2014 03:01 AM, Magnus Ihse Bursie wrote: >> On 2014-09-04 23:48, Phil Race wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8056209 >>> Proposed removing several files >>> ./windows/native/libawt/sun/java2d/d3d/D3DPipeline.cpp >>> ./windows/native/libawt/sun/java2d/d3d/D3DShaderGen.c >>> ./windows/native/libawt/sun/windows/WBufferStrategy.cpp >>> >>> After some analysis the actual list of files to remove is >>> >>> src/java.desktop/windows/native/libawt/sun/java2d/d3d/D3DPipeline.cpp >>> >>> - this file appears to be unneeded and has never been built >>> >>> src/java.desktop/windows/classes/sun/awt/windows\WBufferStrategy.java >>> src/java.desktop/windows/native/libawt/sun/windows/WBufferStrategy.cpp >>> >>> - both of these files have not been built since 6u10 >>> >>> D3DShaderGen.c needs to remain. It perhaps should live somewhere else >>> but it also needs a bit of maintenance. A new bug should be filed on >>> that >>> >>> here's a webrev for what value it adds :- >>> http://cr.openjdk.java.net/~prr/8056209/ >> >> Actually, we need to update the makefiles as well, since these are >> listed as exceptions. >> >> diff -r 99da8eb27d0a make/lib/Awt2dLibraries.gmk >> --- a/make/lib/Awt2dLibraries.gmk Wed Aug 27 10:14:16 2014 +0200 >> +++ b/make/lib/Awt2dLibraries.gmk Fri Sep 05 12:00:45 2014 +0200 >> @@ -216,10 +216,8 @@ >> -I$(JDK_OUTPUTDIR)/gensrc_headers/java.base \ >> # >> LIBAWT_EXFILES += \ >> - sun/java2d/d3d/D3DPipeline.cpp \ >> sun/java2d/d3d/D3DShaderGen.c \ >> sun/awt/image/cvutils/img_colors.c \ >> - sun/windows/WBufferStrategy.cpp \ >> # >> >> LIBAWT_LANG := C++ >> >> Thanks for addressing this Phil! >> >> /Magnus > From martinrb at google.com Sat Sep 6 01:57:26 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 5 Sep 2014 18:57:26 -0700 Subject: [OpenJDK 2D-Dev] freetypescaler fix for fonts that start with a control point Message-ID: Hi font friends! I'm trying to share a font rendering bug fix contributed by my colleagues Behdad and Igor. http://cr.openjdk.java.net/~martin/webrevs/openjdk9/freetypeScaler-outline/ Repro recipe: (cd test/java/awt/font/GlyphVector/ && javac GlyphVectorOutline.java && wget -q -O/tmp/msgothic.ttc https://browserlinux-jp.googlecode.com/files/msgothic.ttc && java GlyphVectorOutline /tmp/msgothic.ttc /tmp/katakana.png) After successfully running that, examine the two rendered Japanese characters. Without our fix, the lower one is misrendered. I don't know how the fix works, and whether/how the manual test case can be turned into a real jtreg test. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Mon Sep 8 07:24:35 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 08 Sep 2014 09:24:35 +0200 Subject: [OpenJDK 2D-Dev] RFR: 8056209 : Remove unused files for libawt In-Reply-To: <5409DDF2.7050308@oracle.com> References: <5408DE30.1050905@oracle.com> <540989EE.3090800@oracle.com> <5409DDF2.7050308@oracle.com> Message-ID: <540D59B3.504@oracle.com> Looks even better now. Thanks Magnus for remembering the makefiles. /Erik On 2014-09-05 17:59, Phil Race wrote: > > Actually, we need to update the makefiles as well, since these are > listed as exceptions. > > Gosh ... I should have remembered that to begin with. > > Here's the fixed patch http://cr.openjdk.java.net/~prr/8056209.1 > > -phil > > On 09/05/2014 03:01 AM, Magnus Ihse Bursie wrote: >> On 2014-09-04 23:48, Phil Race wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8056209 >>> Proposed removing several files >>> ./windows/native/libawt/sun/java2d/d3d/D3DPipeline.cpp >>> ./windows/native/libawt/sun/java2d/d3d/D3DShaderGen.c >>> ./windows/native/libawt/sun/windows/WBufferStrategy.cpp >>> >>> After some analysis the actual list of files to remove is >>> >>> src/java.desktop/windows/native/libawt/sun/java2d/d3d/D3DPipeline.cpp >>> >>> - this file appears to be unneeded and has never been built >>> >>> src/java.desktop/windows/classes/sun/awt/windows\WBufferStrategy.java >>> src/java.desktop/windows/native/libawt/sun/windows/WBufferStrategy.cpp >>> >>> - both of these files have not been built since 6u10 >>> >>> D3DShaderGen.c needs to remain. It perhaps should live somewhere else >>> but it also needs a bit of maintenance. A new bug should be filed on >>> that >>> >>> here's a webrev for what value it adds :- >>> http://cr.openjdk.java.net/~prr/8056209/ >> >> Actually, we need to update the makefiles as well, since these are >> listed as exceptions. >> >> diff -r 99da8eb27d0a make/lib/Awt2dLibraries.gmk >> --- a/make/lib/Awt2dLibraries.gmk Wed Aug 27 10:14:16 2014 +0200 >> +++ b/make/lib/Awt2dLibraries.gmk Fri Sep 05 12:00:45 2014 +0200 >> @@ -216,10 +216,8 @@ >> -I$(JDK_OUTPUTDIR)/gensrc_headers/java.base \ >> # >> LIBAWT_EXFILES += \ >> - sun/java2d/d3d/D3DPipeline.cpp \ >> sun/java2d/d3d/D3DShaderGen.c \ >> sun/awt/image/cvutils/img_colors.c \ >> - sun/windows/WBufferStrategy.cpp \ >> # >> >> LIBAWT_LANG := C++ >> >> Thanks for addressing this Phil! >> >> /Magnus > From Sergey.Bylokhov at oracle.com Mon Sep 8 12:41:54 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 08 Sep 2014 16:41:54 +0400 Subject: [OpenJDK 2D-Dev] RFR: 8056209 : Remove unused files for libawt In-Reply-To: <5408DE30.1050905@oracle.com> References: <5408DE30.1050905@oracle.com> Message-ID: <540DA412.7070201@oracle.com> Hi, Phil. The fix looks good. On 05.09.2014 1:48, Phil Race wrote: > https://bugs.openjdk.java.net/browse/JDK-8056209 > Proposed removing several files > ./windows/native/libawt/sun/java2d/d3d/D3DPipeline.cpp > ./windows/native/libawt/sun/java2d/d3d/D3DShaderGen.c > ./windows/native/libawt/sun/windows/WBufferStrategy.cpp > > After some analysis the actual list of files to remove is > > src/java.desktop/windows/native/libawt/sun/java2d/d3d/D3DPipeline.cpp > > - this file appears to be unneeded and has never been built > > src/java.desktop/windows/classes/sun/awt/windows\WBufferStrategy.java > src/java.desktop/windows/native/libawt/sun/windows/WBufferStrategy.cpp > > - both of these files have not been built since 6u10 > > D3DShaderGen.c needs to remain. It perhaps should live somewhere else > but it also needs a bit of maintenance. A new bug should be filed on that > > here's a webrev for what value it adds :- > http://cr.openjdk.java.net/~prr/8056209/ > > I did a full clean windows build to test the change. > > -phil. > > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Sep 8 15:31:40 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 08 Sep 2014 19:31:40 +0400 Subject: [OpenJDK 2D-Dev] [9] request for review: 8041465: BMPImageReader read error using ImageReadParam with set sourceRectangle In-Reply-To: <54070844.4010906@oracle.com> References: <54070844.4010906@oracle.com> Message-ID: <540DCBDC.8020700@oracle.com> Hi, Andrew. I am not an expert in this area, but probably the bug can be fixed in the readHeader itself? Because currently it call iis.skipBytes(bitmapOffset) at the end only for the first time. On 03.09.2014 16:23, Andrew Brygin wrote: > Hello, > > could you please review a fix for CR 8041465? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8041465 > Webrev: http://cr.openjdk.java.net/~bae/8041465/9/webrev.00/ > > The problem happens if we perform multiple read operations from > a source which is set only once. For instance, we can try to read > image in several tiles. > > The root case of the problem is that we set stream position > to the start of raster data only once: when we complete > the processing of BMP header. A peculiarity of BMP format > is that raster data can be stored in reverse order, so if we > request few leading scanlines first, then we skip rest of raster > data, and subsequent read command does not copy anything to the > destination buffer, because we never re-set the stream position > to the start of bitmap. > > Suggested fix just saves the bitmap's start postilion and seeks > the stream to to it each time when we read image. This change > makes the BMP reader behavior exactly same as other standard plugin > demonstrate. > > Supplied regression test demonstrates the problem. > > Please take a look. > > Thanks, > Andrew. -- Best regards, Sergey. From magnus.ihse.bursie at oracle.com Tue Sep 9 11:58:33 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 09 Sep 2014 13:58:33 +0200 Subject: [OpenJDK 2D-Dev] RFR: 8056209 : Remove unused files for libawt In-Reply-To: <5409DF5F.8050009@oracle.com> References: <5408DE30.1050905@oracle.com> <540989EE.3090800@oracle.com> <5409DDF2.7050308@oracle.com> <5409DF5F.8050009@oracle.com> Message-ID: <540EEB69.4070807@oracle.com> On 2014-09-05 18:05, Phil Race wrote: > PS i filed https://bugs.openjdk.java.net/browse/JDK-8057711 to track > D3DShaderGen.c Thanks! /Magnus From andrew.brygin at oracle.com Tue Sep 9 12:32:16 2014 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Tue, 09 Sep 2014 16:32:16 +0400 Subject: [OpenJDK 2D-Dev] [9] request for review: 8041465: BMPImageReader read error using ImageReadParam with set sourceRectangle In-Reply-To: <540DCBDC.8020700@oracle.com> References: <54070844.4010906@oracle.com> <540DCBDC.8020700@oracle.com> Message-ID: <540EF350.6080609@oracle.com> Hello Sergey, my preference is to leave the seek(bitmapStart) in the read() method in order to reduce potential overhead because readHedaer() is called very often. Thanks, Andrew On 9/8/2014 7:31 PM, Sergey Bylokhov wrote: > Hi, Andrew. > I am not an expert in this area, but probably the bug can be fixed in > the readHeader itself? Because currently it call > iis.skipBytes(bitmapOffset) at the end only for the first time. > > On 03.09.2014 16:23, Andrew Brygin wrote: >> Hello, >> >> could you please review a fix for CR 8041465? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8041465 >> Webrev: http://cr.openjdk.java.net/~bae/8041465/9/webrev.00/ >> >> The problem happens if we perform multiple read operations from >> a source which is set only once. For instance, we can try to read >> image in several tiles. >> >> The root case of the problem is that we set stream position >> to the start of raster data only once: when we complete >> the processing of BMP header. A peculiarity of BMP format >> is that raster data can be stored in reverse order, so if we >> request few leading scanlines first, then we skip rest of raster >> data, and subsequent read command does not copy anything to the >> destination buffer, because we never re-set the stream position >> to the start of bitmap. >> >> Suggested fix just saves the bitmap's start postilion and seeks >> the stream to to it each time when we read image. This change >> makes the BMP reader behavior exactly same as other standard plugin >> demonstrate. >> >> Supplied regression test demonstrates the problem. >> >> Please take a look. >> >> Thanks, >> Andrew. > > From volker.simonis at gmail.com Tue Sep 9 13:51:00 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 9 Sep 2014 15:51:00 +0200 Subject: [OpenJDK 2D-Dev] RFR(XXS): 8057934: Upgrade to LittleCMS 2.6 breaks AIX build Message-ID: Hi, could you please review the following tiny fix for an AIX build problem intruduced by "8056122: Upgrade JDK to LittleCMS 2.6": http://cr.openjdk.java.net/~simonis/webrevs/8057934/ https://bugs.openjdk.java.net/browse/JDK-8057934 The problem is that the new version of LittleCMS now includes "pthread.h" in "lcms2_internal.h". Unfortunalty on AIX, "pthread.h" in turn includes "sys/proc.h" which uncoditionally defines a preprocessor constant "SNONE". In "cmscgats.c" this preprocessor constant "SNONE" collides with the enum value "SNONE" from the SYMBOL enumaration. The only solution I see is to rename "SNONE" in "cmscgats.c". I renamed it to "SVOID" but would be happy with any other name. Fortunately "SNONE" is only used locally in the file "cmscgats.c", so renaming it won't have any impact on other files. Once this bug is fixed I'll report the problem upstream to LittleCMS and try to get the fix in there. Finally, there's on last point I wan to bring up. I realized that "8056122: Upgrade JDK to LittleCMS 2.6" went from jdk9-client right into 8u-dev. That's why we caught this error only in 8u-dev and not already in jdk9-dev which we build on a daily basis on all our porting platforms. Is my assumption that changes have to through jdk9-dev before they get back ported wrong or has this been an exeption? Thank you and best regards, Volker From alexandr.scherbatiy at oracle.com Tue Sep 9 14:38:42 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 09 Sep 2014 18:38:42 +0400 Subject: [OpenJDK 2D-Dev] [9] Review request for 8057940 JCK test api/java_awt/Image/renderable/ParameterBlock fails with StackOverflowError Message-ID: <540F10F2.2030206@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8057940 webrev: http://cr.openjdk.java.net/~alexsch/8057940/webrev.00 The fix reverts JDK-8049893 change which introduces infinity loop in the ParameterBlock.add(int)/set(int) methods after replacing Integer value to int. Thanks, Alexandr. From Sergey.Bylokhov at oracle.com Tue Sep 9 16:29:57 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 09 Sep 2014 20:29:57 +0400 Subject: [OpenJDK 2D-Dev] [9] Review request for 8057940 JCK test api/java_awt/Image/renderable/ParameterBlock fails with StackOverflowError In-Reply-To: <540F10F2.2030206@oracle.com> References: <540F10F2.2030206@oracle.com> Message-ID: <540F2B05.1050109@oracle.com> Hi, Alexander. The fix looks good. On 09.09.2014 18:38, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8057940 > webrev: http://cr.openjdk.java.net/~alexsch/8057940/webrev.00 > > The fix reverts JDK-8049893 change which introduces infinity loop in > the ParameterBlock.add(int)/set(int) methods after replacing Integer > value to int. > > Thanks, > Alexandr. > -- Best regards, Sergey. From philip.race at oracle.com Tue Sep 9 17:00:01 2014 From: philip.race at oracle.com (Phil Race) Date: Tue, 09 Sep 2014 10:00:01 -0700 Subject: [OpenJDK 2D-Dev] [9] Review request for 8057940 JCK test api/java_awt/Image/renderable/ParameterBlock fails with StackOverflowError In-Reply-To: <540F2B05.1050109@oracle.com> References: <540F10F2.2030206@oracle.com> <540F2B05.1050109@oracle.com> Message-ID: <540F3211.5050500@oracle.com> Ditto. -phil. On 9/9/2014 9:29 AM, Sergey Bylokhov wrote: > Hi, Alexander. > The fix looks good. > > On 09.09.2014 18:38, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8057940 >> webrev: http://cr.openjdk.java.net/~alexsch/8057940/webrev.00 >> >> The fix reverts JDK-8049893 change which introduces infinity loop >> in the ParameterBlock.add(int)/set(int) methods after replacing >> Integer value to int. >> >> Thanks, >> Alexandr. >> > > From volker.simonis at gmail.com Tue Sep 9 18:11:57 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 9 Sep 2014 20:11:57 +0200 Subject: [OpenJDK 2D-Dev] RFR(XXS): 8057934: Upgrade to LittleCMS 2.6 breaks AIX build In-Reply-To: References: Message-ID: Hi, I've updated my webrev to reflect the fix which has now been pushed to LittleCMS mainline. It renames SNONE to SUNDEFINED :- https://github.com/mm2/Little-CMS/commit/5bc4f52ff6b2090863d824827a871cd6274e36e4 http://cr.openjdk.java.net/~simonis/webrevs/8057934.v1/ Pease review. Thank you and best regards, Volker PS: and I've verified that SUNDEFINED isn't defined on AIX... On Tue, Sep 9, 2014 at 3:51 PM, Volker Simonis wrote: > Hi, > > could you please review the following tiny fix for an AIX build > problem intruduced by "8056122: Upgrade JDK to LittleCMS 2.6": > > http://cr.openjdk.java.net/~simonis/webrevs/8057934/ > https://bugs.openjdk.java.net/browse/JDK-8057934 > > The problem is that the new version of LittleCMS now includes > "pthread.h" in "lcms2_internal.h". Unfortunalty on AIX, "pthread.h" in > turn includes "sys/proc.h" which uncoditionally defines a preprocessor > constant "SNONE". > > In "cmscgats.c" this preprocessor constant "SNONE" collides with the > enum value "SNONE" from the SYMBOL enumaration. > > The only solution I see is to rename "SNONE" in "cmscgats.c". I > renamed it to "SVOID" but would be happy with any other name. > Fortunately "SNONE" is only used locally in the file "cmscgats.c", so > renaming it won't have any impact on other files. > > Once this bug is fixed I'll report the problem upstream to LittleCMS > and try to get the fix in there. > > Finally, there's on last point I wan to bring up. I realized that > "8056122: Upgrade JDK to LittleCMS 2.6" went from jdk9-client right > into 8u-dev. That's why we caught this error only in 8u-dev and not > already in jdk9-dev which we build on a daily basis on all our porting > platforms. Is my assumption that changes have to through jdk9-dev > before they get back ported wrong or has this been an exeption? > > Thank you and best regards, > Volker From philip.race at oracle.com Tue Sep 9 18:18:35 2014 From: philip.race at oracle.com (Phil Race) Date: Tue, 09 Sep 2014 11:18:35 -0700 Subject: [OpenJDK 2D-Dev] RFR(XXS): 8057934: Upgrade to LittleCMS 2.6 breaks AIX build In-Reply-To: References: Message-ID: <540F447B.8030400@oracle.com> Approved -phil. On 09/09/2014 11:11 AM, Volker Simonis wrote: > Hi, > > I've updated my webrev to reflect the fix which has now been pushed to > LittleCMS mainline. It renames SNONE to SUNDEFINED :- > https://github.com/mm2/Little-CMS/commit/5bc4f52ff6b2090863d824827a871cd6274e36e4 > > http://cr.openjdk.java.net/~simonis/webrevs/8057934.v1/ > > Pease review. > > Thank you and best regards, > Volker > > PS: and I've verified that SUNDEFINED isn't defined on AIX... > > > On Tue, Sep 9, 2014 at 3:51 PM, Volker Simonis wrote: >> Hi, >> >> could you please review the following tiny fix for an AIX build >> problem intruduced by "8056122: Upgrade JDK to LittleCMS 2.6": >> >> http://cr.openjdk.java.net/~simonis/webrevs/8057934/ >> https://bugs.openjdk.java.net/browse/JDK-8057934 >> >> The problem is that the new version of LittleCMS now includes >> "pthread.h" in "lcms2_internal.h". Unfortunalty on AIX, "pthread.h" in >> turn includes "sys/proc.h" which uncoditionally defines a preprocessor >> constant "SNONE". >> >> In "cmscgats.c" this preprocessor constant "SNONE" collides with the >> enum value "SNONE" from the SYMBOL enumaration. >> >> The only solution I see is to rename "SNONE" in "cmscgats.c". I >> renamed it to "SVOID" but would be happy with any other name. >> Fortunately "SNONE" is only used locally in the file "cmscgats.c", so >> renaming it won't have any impact on other files. >> >> Once this bug is fixed I'll report the problem upstream to LittleCMS >> and try to get the fix in there. >> >> Finally, there's on last point I wan to bring up. I realized that >> "8056122: Upgrade JDK to LittleCMS 2.6" went from jdk9-client right >> into 8u-dev. That's why we caught this error only in 8u-dev and not >> already in jdk9-dev which we build on a daily basis on all our porting >> platforms. Is my assumption that changes have to through jdk9-dev >> before they get back ported wrong or has this been an exeption? >> >> Thank you and best regards, >> Volker From Sergey.Bylokhov at oracle.com Tue Sep 9 18:37:58 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 09 Sep 2014 22:37:58 +0400 Subject: [OpenJDK 2D-Dev] RFR(XXS): 8057934: Upgrade to LittleCMS 2.6 breaks AIX build In-Reply-To: <540F447B.8030400@oracle.com> References: <540F447B.8030400@oracle.com> Message-ID: <540F4906.7060900@oracle.com> The fix looks fine to me too. On 09.09.2014 22:18, Phil Race wrote: > Approved > > -phil. > > On 09/09/2014 11:11 AM, Volker Simonis wrote: >> Hi, >> >> I've updated my webrev to reflect the fix which has now been pushed to >> LittleCMS mainline. It renames SNONE to SUNDEFINED :- >> https://github.com/mm2/Little-CMS/commit/5bc4f52ff6b2090863d824827a871cd6274e36e4 >> >> >> http://cr.openjdk.java.net/~simonis/webrevs/8057934.v1/ >> >> Pease review. >> >> Thank you and best regards, >> Volker >> >> PS: and I've verified that SUNDEFINED isn't defined on AIX... >> >> >> On Tue, Sep 9, 2014 at 3:51 PM, Volker Simonis >> wrote: >>> Hi, >>> >>> could you please review the following tiny fix for an AIX build >>> problem intruduced by "8056122: Upgrade JDK to LittleCMS 2.6": >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8057934/ >>> https://bugs.openjdk.java.net/browse/JDK-8057934 >>> >>> The problem is that the new version of LittleCMS now includes >>> "pthread.h" in "lcms2_internal.h". Unfortunalty on AIX, "pthread.h" in >>> turn includes "sys/proc.h" which uncoditionally defines a preprocessor >>> constant "SNONE". >>> >>> In "cmscgats.c" this preprocessor constant "SNONE" collides with the >>> enum value "SNONE" from the SYMBOL enumaration. >>> >>> The only solution I see is to rename "SNONE" in "cmscgats.c". I >>> renamed it to "SVOID" but would be happy with any other name. >>> Fortunately "SNONE" is only used locally in the file "cmscgats.c", so >>> renaming it won't have any impact on other files. >>> >>> Once this bug is fixed I'll report the problem upstream to LittleCMS >>> and try to get the fix in there. >>> >>> Finally, there's on last point I wan to bring up. I realized that >>> "8056122: Upgrade JDK to LittleCMS 2.6" went from jdk9-client right >>> into 8u-dev. That's why we caught this error only in 8u-dev and not >>> already in jdk9-dev which we build on a daily basis on all our porting >>> platforms. Is my assumption that changes have to through jdk9-dev >>> before they get back ported wrong or has this been an exeption? >>> >>> Thank you and best regards, >>> Volker > -- Best regards, Sergey. From philip.race at oracle.com Tue Sep 9 21:17:01 2014 From: philip.race at oracle.com (Phil Race) Date: Tue, 09 Sep 2014 14:17:01 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8056213 : Clean up unix/native/common/sun/awt Message-ID: <540F6E4D.3060802@oracle.com> After looking at the issues in the bug report below I think the only think that must be fixed is the unnecessary inclusion of initIDS.c in libawt_xawt.so https://bugs.openjdk.java.net/browse/JDK-8056213 http://cr.openjdk.java.net/~prr/8056213/ I've tested this out on Linux and am submitting a full JPRT job. -phil. From philip.race at oracle.com Tue Sep 9 21:47:45 2014 From: philip.race at oracle.com (Phil Race) Date: Tue, 09 Sep 2014 14:47:45 -0700 Subject: [OpenJDK 2D-Dev] freetypescaler fix for fonts that start with a control point In-Reply-To: References: Message-ID: <540F7581.4010400@oracle.com> Martin, Although I have yet to test it, the fix looks reasonable to me. Probably this decompose outline function supporting the callbacks was overlooked when this code was written. A jtreg test is tricky as you need to have font data available that exercises the buggy case and then use the resulting Path2D. But there is no way to rely on a particular font with a known property being available without creating one and checking it in .. that might be overkill. Plus how do you test this in an automated way ? You can't compare the freetype glyph rasterisation with the pisces rasterisation (that done using fill(..)) as they are highly likely to differ in some tiny ways and knowing how much difference to allow is fraught too, leading to a fragile test. So noreg-hard and some alternative testing which likely involves a manual run through Font2DTest to make sure everything seems good. I think SQE have some image comparison testing but even if they cover much outline font rendering which I doubt, I don't think they run it on the open builds very often FWIW the test code could have been simpler as in :- public static void writeImage(File fontFile, File outputFile, String value) throws Exception { BufferedImage image = new BufferedImage(200, 200, BufferedImage.TYPE_INT_RGB); Graphics2D g = image.createGraphics(); g.setColor(Color.WHITE); g.fillRect(0, 0, image.getWidth(), image.getHeight()); g.setColor(Color.BLACK); Font font = Font.createFont(Font.TRUETYPE_FONT, fontFile); font = font.deriveFont(Font.PLAIN, 72f); FontRenderContext frc = new FontRenderContext(null, false, false); GlyphVector gv = font.createGlyphVector(frc, value); g.drawGlyphVector(gv, 10, 80); g.fill(gv.getOutline(10, 180)); ImageIO.write(image, "png", outputFile); } and then you don't need that G2D subclass. There should of course be a client-libs/2d bug on this. I submitted https://bugs.openjdk.java.net/browse/JDK-8057986 Next thing to do is test the fix on an openjdk build using Font2DTest. -phil. On 9/5/2014 6:57 PM, Martin Buchholz wrote: > Hi font friends! > > I'm trying to share a font rendering bug fix contributed by my > colleagues Behdad and Igor. > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/freetypeScaler-outline/ > > > Repro recipe: > > (cd test/java/awt/font/GlyphVector/ && javac GlyphVectorOutline.java > && wget -q -O/tmp/msgothic.ttc > https://browserlinux-jp.googlecode.com/files/msgothic.ttc && java > GlyphVectorOutline /tmp/msgothic.ttc /tmp/katakana.png) > > After successfully running that, examine the two rendered Japanese > characters. > > Without our fix, the lower one is misrendered. > > I don't know how the fix works, and whether/how the manual test case > can be turned into a real jtreg test. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Tue Sep 9 22:34:45 2014 From: philip.race at oracle.com (Phil Race) Date: Tue, 09 Sep 2014 15:34:45 -0700 Subject: [OpenJDK 2D-Dev] freetypescaler fix for fonts that start with a control point In-Reply-To: <540F7581.4010400@oracle.com> References: <540F7581.4010400@oracle.com> Message-ID: <540F8085.50009@oracle.com> I've tested the fix (manually) and it looks good. -phil. On 09/09/2014 02:47 PM, Phil Race wrote: > Martin, > > Although I have yet to test it, the fix looks reasonable to me. > Probably this decompose outline function supporting > the callbacks was overlooked when this code was written. > A jtreg test is tricky as you need to have font data available that > exercises > the buggy case and then use the resulting Path2D. But there is no way > to rely on a particular font with a known property being available > without creating one and checking it in .. that might be overkill. > > Plus how do you test this in an automated way ? > You can't compare the freetype glyph rasterisation with the pisces > rasterisation (that done using fill(..)) > as they are highly likely to differ in some tiny ways and knowing how > much difference to > allow is fraught too, leading to a fragile test. > > So noreg-hard and some alternative testing which likely involves a manual > run through Font2DTest to make sure everything seems good. > I think SQE have some image comparison testing but even if they cover much > outline font rendering which I doubt, I don't think they run it on the > open builds very often > > FWIW the test code could have been simpler as in :- > > public static void writeImage(File fontFile, File outputFile, > String value) throws Exception { > BufferedImage image = new BufferedImage(200, 200, > BufferedImage.TYPE_INT_RGB); > Graphics2D g = image.createGraphics(); > g.setColor(Color.WHITE); > g.fillRect(0, 0, image.getWidth(), image.getHeight()); > g.setColor(Color.BLACK); > > Font font = Font.createFont(Font.TRUETYPE_FONT, fontFile); > font = font.deriveFont(Font.PLAIN, 72f); > FontRenderContext frc = new FontRenderContext(null, false, false); > GlyphVector gv = font.createGlyphVector(frc, value); > g.drawGlyphVector(gv, 10, 80); > g.fill(gv.getOutline(10, 180)); > ImageIO.write(image, "png", outputFile); > } > > and then you don't need that G2D subclass. > > There should of course be a client-libs/2d bug on this. > I submitted https://bugs.openjdk.java.net/browse/JDK-8057986 > > Next thing to do is test the fix on an openjdk build using Font2DTest. > > > -phil. > > > On 9/5/2014 6:57 PM, Martin Buchholz wrote: >> Hi font friends! >> >> I'm trying to share a font rendering bug fix contributed by my >> colleagues Behdad and Igor. >> >> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/freetypeScaler-outline/ >> >> >> Repro recipe: >> >> (cd test/java/awt/font/GlyphVector/ && javac GlyphVectorOutline.java >> && wget -q -O/tmp/msgothic.ttc >> https://browserlinux-jp.googlecode.com/files/msgothic.ttc && java >> GlyphVectorOutline /tmp/msgothic.ttc /tmp/katakana.png) >> >> After successfully running that, examine the two rendered Japanese >> characters. >> >> Without our fix, the lower one is misrendered. >> >> I don't know how the fix works, and whether/how the manual test case >> can be turned into a real jtreg test. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Wed Sep 10 08:12:05 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 10 Sep 2014 10:12:05 +0200 Subject: [OpenJDK 2D-Dev] RFR: 8056213 : Clean up unix/native/common/sun/awt In-Reply-To: <540F6E4D.3060802@oracle.com> References: <540F6E4D.3060802@oracle.com> Message-ID: <541007D5.5060302@oracle.com> On 2014-09-09 23:17, Phil Race wrote: > After looking at the issues in the bug report below I think the only > think that must be fixed is the unnecessary inclusion of initIDS.c in > libawt_xawt.so You are correct indeed. I had missed the fact that awt_Font.c, fontpath.c and X11Color.c was included in libawt_headless. :-( > > https://bugs.openjdk.java.net/browse/JDK-8056213 > http://cr.openjdk.java.net/~prr/8056213/ Since initIDs.c are now only used in a single library, I think it is better to move it away from the "common" directory, into src/java.desktop/unix/native/libawt/sun/awt where it will get picked up automatically, but just for libawt. That means that instead of having to add even more excludes, you can delete some existing, like this: diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk --- a/make/lib/Awt2dLibraries.gmk +++ b/make/lib/Awt2dLibraries.gmk @@ -748,7 +748,6 @@ -I$(JDK_TOPDIR)/src/java.desktop/$(OPENJDK_TARGET_OS_API_DIR)/native/libsunwjdga/ \ $(LIBJAVA_HEADER_FLAGS) \ # - LIBAWT_HEADLESS_EXFILES := initIDs.c LIBAWT_HEADLESS_REORDER := ifeq ($(OPENJDK_TARGET_OS), solaris) @@ -761,7 +760,6 @@ LIBRARY := awt_headless, \ OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \ SRC := $(LIBAWT_HEADLESS_DIRS), \ - EXCLUDE_FILES := $(LIBAWT_HEADLESS_EXFILES), \ EXCLUDES := $(LIBAWT_HEADLESS_EXCLUDES), \ LANG := C, \ OPTIMIZATION := LOW, \ @@ -932,7 +930,7 @@ $(LIBJAVA_HEADER_FLAGS) \ # - LIBAWT_LWAWT_EXFILES := fontpath.c awt_Font.c X11Color.c initIDs.c + LIBAWT_LWAWT_EXFILES := fontpath.c awt_Font.c X11Color.c LIBAWT_LWAWT_EXCLUDES := $(JDK_TOPDIR)/src/java.desktop/unix/native/common/sun/awt/medialib $(eval $(call SetupNativeCompilation,BUILD_LIBAWT_LWAWT, \ /Magnus From volker.simonis at gmail.com Wed Sep 10 09:05:12 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 10 Sep 2014 11:05:12 +0200 Subject: [OpenJDK 2D-Dev] RFR(XXS): 8057934: Upgrade to LittleCMS 2.6 breaks AIX build In-Reply-To: <540F4906.7060900@oracle.com> References: <540F447B.8030400@oracle.com> <540F4906.7060900@oracle.com> Message-ID: Thanks a lot Phil and Sergey! I've just pushed the change. Regards, Volker On Tue, Sep 9, 2014 at 8:37 PM, Sergey Bylokhov wrote: > The fix looks fine to me too. > > > On 09.09.2014 22:18, Phil Race wrote: >> >> Approved >> >> -phil. >> >> On 09/09/2014 11:11 AM, Volker Simonis wrote: >>> >>> Hi, >>> >>> I've updated my webrev to reflect the fix which has now been pushed to >>> LittleCMS mainline. It renames SNONE to SUNDEFINED :- >>> >>> https://github.com/mm2/Little-CMS/commit/5bc4f52ff6b2090863d824827a871cd6274e36e4 >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8057934.v1/ >>> >>> Pease review. >>> >>> Thank you and best regards, >>> Volker >>> >>> PS: and I've verified that SUNDEFINED isn't defined on AIX... >>> >>> >>> On Tue, Sep 9, 2014 at 3:51 PM, Volker Simonis >>> wrote: >>>> >>>> Hi, >>>> >>>> could you please review the following tiny fix for an AIX build >>>> problem intruduced by "8056122: Upgrade JDK to LittleCMS 2.6": >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/8057934/ >>>> https://bugs.openjdk.java.net/browse/JDK-8057934 >>>> >>>> The problem is that the new version of LittleCMS now includes >>>> "pthread.h" in "lcms2_internal.h". Unfortunalty on AIX, "pthread.h" in >>>> turn includes "sys/proc.h" which uncoditionally defines a preprocessor >>>> constant "SNONE". >>>> >>>> In "cmscgats.c" this preprocessor constant "SNONE" collides with the >>>> enum value "SNONE" from the SYMBOL enumaration. >>>> >>>> The only solution I see is to rename "SNONE" in "cmscgats.c". I >>>> renamed it to "SVOID" but would be happy with any other name. >>>> Fortunately "SNONE" is only used locally in the file "cmscgats.c", so >>>> renaming it won't have any impact on other files. >>>> >>>> Once this bug is fixed I'll report the problem upstream to LittleCMS >>>> and try to get the fix in there. >>>> >>>> Finally, there's on last point I wan to bring up. I realized that >>>> "8056122: Upgrade JDK to LittleCMS 2.6" went from jdk9-client right >>>> into 8u-dev. That's why we caught this error only in 8u-dev and not >>>> already in jdk9-dev which we build on a daily basis on all our porting >>>> platforms. Is my assumption that changes have to through jdk9-dev >>>> before they get back ported wrong or has this been an exeption? >>>> >>>> Thank you and best regards, >>>> Volker >> >> > > > -- > Best regards, Sergey. > From Sergey.Bylokhov at oracle.com Wed Sep 10 12:11:18 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 10 Sep 2014 16:11:18 +0400 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8055326 Fix typos in client-related packages In-Reply-To: <53F634BB.7000905@oracle.com> References: <53F62E90.90401@oracle.com> <53F634BB.7000905@oracle.com> Message-ID: <54103FE6.5070104@oracle.com> Hi, Phil. It seems both changes are unnecessary: http://cr.openjdk.java.net/~serb/8055326/webrev.01 On 21.08.2014 22:04, Phil Race wrote: > Was the additional spce on the 2nd line intended here ? > > --- > old/src/java.desktop/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java > 2014-08-21 20:50:04.859532400 +0400 > +++ > new/src/java.desktop/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java > 2014-08-21 20:50:04.663521200 +0400 > @@ -166,8 +166,8 @@ > retComp = > cont.getFocusTraversalPolicy().getDefaultComponent(cont); > > if (retComp != null && > log.isLoggable(PlatformLogger.Level.FINE)) { > - log.fine("### Transfered focus down-cycle to > " + retComp + > - " in the focus cycle root " + cont); > + log.fine("### Transferred focus down-cycle to > " + retComp + > + " in the focus cycle root " + cont); > > > And I don't see what was so wrong with this, perhaps because I wrote > it :-) > > - * so that when the Font2D is GC'd it can also remove the file. > + * so that when the Font2D is GC'ed it can also remove the file. > > > Other than that, looks good. > Some fun new words in there. I particularly liked utilitized and unclude. > > -phil. > > On 8/21/2014 10:38 AM, Sergey Bylokhov wrote: >> Hello, >> Please review the fix for jdk 9. >> The fix was contributed by pavel.rappo at oracle.com >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8055326 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/8055326/webrev.00 >> > -- Best regards, Sergey. From philip.race at oracle.com Wed Sep 10 19:37:33 2014 From: philip.race at oracle.com (Phil Race) Date: Wed, 10 Sep 2014 12:37:33 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8056213 : Clean up unix/native/common/sun/awt In-Reply-To: <541007D5.5060302@oracle.com> References: <540F6E4D.3060802@oracle.com> <541007D5.5060302@oracle.com> Message-ID: <5410A87D.1030302@oracle.com> > That means that instead of having to add even more excludes, you can delete some existing Doing that leaves just this one :- ifeq ($(OPENJDK_TARGET_OS), macosx) LIBAWT_EXFILES += initIDs.c sun/awt/image/cvutils/img_colors.c endif So its actually excluded from the core libawt on OS X. It seems that instead they are defined there in libawt_lwawt in a file initIDs.m This might be necessary if they do something but it seems they are the same stubs used elsewhere and initIDs.h is no more than a GPL header with no content ! Its going to be a bit more work and testing but it seems like we could scrap the lwawt Objectionable C versions and just used the shared one. I don't believe the mapfiles are used on OSX (there isn't even a map file directory for lwawt) so it hasn't mattered that they were in a different DLL, so long as they were loaded in time. -phil. On 09/10/2014 01:12 AM, Magnus Ihse Bursie wrote: > On 2014-09-09 23:17, Phil Race wrote: >> After looking at the issues in the bug report below I think the only >> think that must be fixed is the unnecessary inclusion of initIDS.c in >> libawt_xawt.so > > You are correct indeed. I had missed the fact that awt_Font.c, > fontpath.c and X11Color.c was included in libawt_headless. :-( > >> >> https://bugs.openjdk.java.net/browse/JDK-8056213 >> http://cr.openjdk.java.net/~prr/8056213/ > > Since initIDs.c are now only used in a single library, I think it is > better to move it away from the "common" directory, into > src/java.desktop/unix/native/libawt/sun/awt where it will get picked > up automatically, but just for libawt. That means that instead of > having to add even more excludes, you can delete some existing, like > this: > > diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk > --- a/make/lib/Awt2dLibraries.gmk > +++ b/make/lib/Awt2dLibraries.gmk > @@ -748,7 +748,6 @@ > -I$(JDK_TOPDIR)/src/java.desktop/$(OPENJDK_TARGET_OS_API_DIR)/native/libsunwjdga/ > \ > $(LIBJAVA_HEADER_FLAGS) \ > # > - LIBAWT_HEADLESS_EXFILES := initIDs.c > > LIBAWT_HEADLESS_REORDER := > ifeq ($(OPENJDK_TARGET_OS), solaris) > @@ -761,7 +760,6 @@ > LIBRARY := awt_headless, \ > OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \ > SRC := $(LIBAWT_HEADLESS_DIRS), \ > - EXCLUDE_FILES := $(LIBAWT_HEADLESS_EXFILES), \ > EXCLUDES := $(LIBAWT_HEADLESS_EXCLUDES), \ > LANG := C, \ > OPTIMIZATION := LOW, \ > @@ -932,7 +930,7 @@ > $(LIBJAVA_HEADER_FLAGS) \ > # > > - LIBAWT_LWAWT_EXFILES := fontpath.c awt_Font.c X11Color.c initIDs.c > + LIBAWT_LWAWT_EXFILES := fontpath.c awt_Font.c X11Color.c > LIBAWT_LWAWT_EXCLUDES := > $(JDK_TOPDIR)/src/java.desktop/unix/native/common/sun/awt/medialib > > $(eval $(call SetupNativeCompilation,BUILD_LIBAWT_LWAWT, \ > > > /Magnus From philip.race at oracle.com Wed Sep 10 20:28:10 2014 From: philip.race at oracle.com (Phil Race) Date: Wed, 10 Sep 2014 13:28:10 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8056213 : Clean up unix/native/common/sun/awt In-Reply-To: <5410A87D.1030302@oracle.com> References: <540F6E4D.3060802@oracle.com> <541007D5.5060302@oracle.com> <5410A87D.1030302@oracle.com> Message-ID: <5410B45A.10103@oracle.com> I now see InitIDs.m defines more stubs than initIDs.c since 1) some stubs for xawt are instead defined in XToolkit.c 2) some xawt cases (eg Button) have more than an empty stub - actual content. 3) Some aren't defined at all in the case you have headless awt but they can't be reached because of checks in the classes for headless So I'll leave the OS X files alone -phil. On 09/10/2014 12:37 PM, Phil Race wrote: > > That means that instead of having to add even more excludes, you can > delete some existing > > > Doing that leaves just this one :- > > ifeq ($(OPENJDK_TARGET_OS), macosx) > LIBAWT_EXFILES += initIDs.c sun/awt/image/cvutils/img_colors.c > endif > > So its actually excluded from the core libawt on OS X. > It seems that instead they are defined there in libawt_lwawt > in a file initIDs.m > > This might be necessary if they do something but it seems > they are the same stubs used elsewhere and initIDs.h is no > more than a GPL header with no content ! > > Its going to be a bit more work and testing but it seems like we could > scrap the lwawt Objectionable C versions and just used the > shared one. > > I don't believe the mapfiles are used on OSX (there isn't > even a map file directory for lwawt) so it hasn't > mattered that they were in a different DLL, so long as they > were loaded in time. > > -phil. > > > On 09/10/2014 01:12 AM, Magnus Ihse Bursie wrote: >> On 2014-09-09 23:17, Phil Race wrote: >>> After looking at the issues in the bug report below I think the only >>> think that must be fixed is the unnecessary inclusion of initIDS.c >>> in libawt_xawt.so >> >> You are correct indeed. I had missed the fact that awt_Font.c, >> fontpath.c and X11Color.c was included in libawt_headless. :-( >> >>> >>> https://bugs.openjdk.java.net/browse/JDK-8056213 >>> http://cr.openjdk.java.net/~prr/8056213/ >> >> Since initIDs.c are now only used in a single library, I think it is >> better to move it away from the "common" directory, into >> src/java.desktop/unix/native/libawt/sun/awt where it will get picked >> up automatically, but just for libawt. That means that instead of >> having to add even more excludes, you can delete some existing, like >> this: >> >> diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk >> --- a/make/lib/Awt2dLibraries.gmk >> +++ b/make/lib/Awt2dLibraries.gmk >> @@ -748,7 +748,6 @@ >> -I$(JDK_TOPDIR)/src/java.desktop/$(OPENJDK_TARGET_OS_API_DIR)/native/libsunwjdga/ >> \ >> $(LIBJAVA_HEADER_FLAGS) \ >> # >> - LIBAWT_HEADLESS_EXFILES := initIDs.c >> >> LIBAWT_HEADLESS_REORDER := >> ifeq ($(OPENJDK_TARGET_OS), solaris) >> @@ -761,7 +760,6 @@ >> LIBRARY := awt_headless, \ >> OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \ >> SRC := $(LIBAWT_HEADLESS_DIRS), \ >> - EXCLUDE_FILES := $(LIBAWT_HEADLESS_EXFILES), \ >> EXCLUDES := $(LIBAWT_HEADLESS_EXCLUDES), \ >> LANG := C, \ >> OPTIMIZATION := LOW, \ >> @@ -932,7 +930,7 @@ >> $(LIBJAVA_HEADER_FLAGS) \ >> # >> >> - LIBAWT_LWAWT_EXFILES := fontpath.c awt_Font.c X11Color.c initIDs.c >> + LIBAWT_LWAWT_EXFILES := fontpath.c awt_Font.c X11Color.c >> LIBAWT_LWAWT_EXCLUDES := >> $(JDK_TOPDIR)/src/java.desktop/unix/native/common/sun/awt/medialib >> >> $(eval $(call SetupNativeCompilation,BUILD_LIBAWT_LWAWT, \ >> >> >> /Magnus > From philip.race at oracle.com Wed Sep 10 21:10:26 2014 From: philip.race at oracle.com (Phil Race) Date: Wed, 10 Sep 2014 14:10:26 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8056213 : Clean up unix/native/common/sun/awt In-Reply-To: <5410B45A.10103@oracle.com> References: <540F6E4D.3060802@oracle.com> <541007D5.5060302@oracle.com> <5410A87D.1030302@oracle.com> <5410B45A.10103@oracle.com> Message-ID: <5410BE42.6010504@oracle.com> Updated webrev :- http://cr.openjdk.java.net/~prr/8056213.1/ -phil. On 09/10/2014 01:28 PM, Phil Race wrote: > I now see InitIDs.m defines more stubs than initIDs.c since > 1) some stubs for xawt are instead defined in XToolkit.c > 2) some xawt cases (eg Button) have more than an empty stub - actual > content. > 3) Some aren't defined at all in the case you have headless awt but > they can't be reached because of checks in the classes for headless > > So I'll leave the OS X files alone > > -phil. > > > On 09/10/2014 12:37 PM, Phil Race wrote: >> > That means that instead of having to add even more excludes, you >> can delete some existing >> >> >> Doing that leaves just this one :- >> >> ifeq ($(OPENJDK_TARGET_OS), macosx) >> LIBAWT_EXFILES += initIDs.c sun/awt/image/cvutils/img_colors.c >> endif >> >> So its actually excluded from the core libawt on OS X. >> It seems that instead they are defined there in libawt_lwawt >> in a file initIDs.m >> >> This might be necessary if they do something but it seems >> they are the same stubs used elsewhere and initIDs.h is no >> more than a GPL header with no content ! >> >> Its going to be a bit more work and testing but it seems like we could >> scrap the lwawt Objectionable C versions and just used the >> shared one. >> >> I don't believe the mapfiles are used on OSX (there isn't >> even a map file directory for lwawt) so it hasn't >> mattered that they were in a different DLL, so long as they >> were loaded in time. >> >> -phil. >> >> >> On 09/10/2014 01:12 AM, Magnus Ihse Bursie wrote: >>> On 2014-09-09 23:17, Phil Race wrote: >>>> After looking at the issues in the bug report below I think the only >>>> think that must be fixed is the unnecessary inclusion of initIDS.c >>>> in libawt_xawt.so >>> >>> You are correct indeed. I had missed the fact that awt_Font.c, >>> fontpath.c and X11Color.c was included in libawt_headless. :-( >>> >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8056213 >>>> http://cr.openjdk.java.net/~prr/8056213/ >>> >>> Since initIDs.c are now only used in a single library, I think it is >>> better to move it away from the "common" directory, into >>> src/java.desktop/unix/native/libawt/sun/awt where it will get picked >>> up automatically, but just for libawt. That means that instead of >>> having to add even more excludes, you can delete some existing, like >>> this: >>> >>> diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk >>> --- a/make/lib/Awt2dLibraries.gmk >>> +++ b/make/lib/Awt2dLibraries.gmk >>> @@ -748,7 +748,6 @@ >>> -I$(JDK_TOPDIR)/src/java.desktop/$(OPENJDK_TARGET_OS_API_DIR)/native/libsunwjdga/ >>> \ >>> $(LIBJAVA_HEADER_FLAGS) \ >>> # >>> - LIBAWT_HEADLESS_EXFILES := initIDs.c >>> >>> LIBAWT_HEADLESS_REORDER := >>> ifeq ($(OPENJDK_TARGET_OS), solaris) >>> @@ -761,7 +760,6 @@ >>> LIBRARY := awt_headless, \ >>> OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \ >>> SRC := $(LIBAWT_HEADLESS_DIRS), \ >>> - EXCLUDE_FILES := $(LIBAWT_HEADLESS_EXFILES), \ >>> EXCLUDES := $(LIBAWT_HEADLESS_EXCLUDES), \ >>> LANG := C, \ >>> OPTIMIZATION := LOW, \ >>> @@ -932,7 +930,7 @@ >>> $(LIBJAVA_HEADER_FLAGS) \ >>> # >>> >>> - LIBAWT_LWAWT_EXFILES := fontpath.c awt_Font.c X11Color.c initIDs.c >>> + LIBAWT_LWAWT_EXFILES := fontpath.c awt_Font.c X11Color.c >>> LIBAWT_LWAWT_EXCLUDES := >>> $(JDK_TOPDIR)/src/java.desktop/unix/native/common/sun/awt/medialib >>> >>> $(eval $(call SetupNativeCompilation,BUILD_LIBAWT_LWAWT, \ >>> >>> >>> /Magnus >> > From martinrb at google.com Wed Sep 10 21:31:07 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 10 Sep 2014 14:31:07 -0700 Subject: [OpenJDK 2D-Dev] freetypescaler fix for fonts that start with a control point In-Reply-To: <540F7581.4010400@oracle.com> References: <540F7581.4010400@oracle.com> Message-ID: I have tried to cross all the t's left here. I took your suggestion and minimized the test greatly. I've taken ownership of the bug and it's now marked noreg-hard. I'm inclined to check in the test case as is, even though it's manual. But I leave that to you, the 2d maintainers. The only testing I've done is to run the one manual test. Hope that's OK. OK to commit this fix? On Tue, Sep 9, 2014 at 2:47 PM, Phil Race wrote: > Martin, > > Although I have yet to test it, the fix looks reasonable to me. > Probably this decompose outline function supporting > the callbacks was overlooked when this code was written. > A jtreg test is tricky as you need to have font data available that > exercises > the buggy case and then use the resulting Path2D. But there is no way > to rely on a particular font with a known property being available > without creating one and checking it in .. that might be overkill. > > Plus how do you test this in an automated way ? > You can't compare the freetype glyph rasterisation with the pisces > rasterisation (that done using fill(..)) > as they are highly likely to differ in some tiny ways and knowing how much > difference to > allow is fraught too, leading to a fragile test. > > So noreg-hard and some alternative testing which likely involves a manual > run through Font2DTest to make sure everything seems good. > I think SQE have some image comparison testing but even if they cover much > outline font rendering which I doubt, I don't think they run it on the > open builds very often > > FWIW the test code could have been simpler as in :- > > public static void writeImage(File fontFile, File outputFile, String > value) throws Exception { > BufferedImage image = new BufferedImage(200, 200, > BufferedImage.TYPE_INT_RGB); > Graphics2D g = image.createGraphics(); > g.setColor(Color.WHITE); > g.fillRect(0, 0, image.getWidth(), image.getHeight()); > g.setColor(Color.BLACK); > > Font font = Font.createFont(Font.TRUETYPE_FONT, fontFile); > font = font.deriveFont(Font.PLAIN, 72f); > FontRenderContext frc = new FontRenderContext(null, false, false); > GlyphVector gv = font.createGlyphVector(frc, value); > g.drawGlyphVector(gv, 10, 80); > g.fill(gv.getOutline(10, 180)); > ImageIO.write(image, "png", outputFile); > } > > and then you don't need that G2D subclass. > > There should of course be a client-libs/2d bug on this. > I submitted https://bugs.openjdk.java.net/browse/JDK-8057986 > > Next thing to do is test the fix on an openjdk build using Font2DTest. > > > -phil. > > > > On 9/5/2014 6:57 PM, Martin Buchholz wrote: > > Hi font friends! > > I'm trying to share a font rendering bug fix contributed by my > colleagues Behdad and Igor. > > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/freetypeScaler-outline/ > > Repro recipe: > > (cd test/java/awt/font/GlyphVector/ && javac GlyphVectorOutline.java && > wget -q -O/tmp/msgothic.ttc > https://browserlinux-jp.googlecode.com/files/msgothic.ttc && java > GlyphVectorOutline /tmp/msgothic.ttc /tmp/katakana.png) > > After successfully running that, examine the two rendered Japanese > characters. > > Without our fix, the lower one is misrendered. > > I don't know how the fix works, and whether/how the manual test case can > be turned into a real jtreg test. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Sep 10 21:38:42 2014 From: philip.race at oracle.com (Phil Race) Date: Wed, 10 Sep 2014 14:38:42 -0700 Subject: [OpenJDK 2D-Dev] freetypescaler fix for fonts that start with a control point In-Reply-To: References: <540F7581.4010400@oracle.com> Message-ID: <5410C4E2.6040900@oracle.com> On 9/10/2014 2:31 PM, Martin Buchholz wrote: > I have tried to cross all the t's left here. I took your suggestion > and minimized the test greatly. I've taken ownership of the bug and > it's now marked noreg-hard. > > I'm inclined to check in the test case as is, even though it's manual. > But I leave that to you, the 2d maintainers. > > The only testing I've done is to run the one manual test. Hope that's OK. > > OK to commit this fix? Do we yet have a 2nd reviewer on the change ? Other than that its fine by me. -phil. > > On Tue, Sep 9, 2014 at 2:47 PM, Phil Race > wrote: > > Martin, > > Although I have yet to test it, the fix looks reasonable to me. > Probably this decompose outline function supporting > the callbacks was overlooked when this code was written. > A jtreg test is tricky as you need to have font data available > that exercises > the buggy case and then use the resulting Path2D. But there is no way > to rely on a particular font with a known property being available > without creating one and checking it in .. that might be overkill. > > Plus how do you test this in an automated way ? > You can't compare the freetype glyph rasterisation with the pisces > rasterisation (that done using fill(..)) > as they are highly likely to differ in some tiny ways and knowing > how much difference to > allow is fraught too, leading to a fragile test. > > So noreg-hard and some alternative testing which likely involves a > manual > run through Font2DTest to make sure everything seems good. > I think SQE have some image comparison testing but even if they > cover much > outline font rendering which I doubt, I don't think they run it on > the open builds very often > > FWIW the test code could have been simpler as in :- > > public static void writeImage(File fontFile, File outputFile, > String value) throws Exception { > BufferedImage image = new BufferedImage(200, 200, > BufferedImage.TYPE_INT_RGB); > Graphics2D g = image.createGraphics(); > g.setColor(Color.WHITE); > g.fillRect(0, 0, image.getWidth(), image.getHeight()); > g.setColor(Color.BLACK); > > Font font = Font.createFont(Font.TRUETYPE_FONT, fontFile); > font = font.deriveFont(Font.PLAIN, 72f); > FontRenderContext frc = new FontRenderContext(null, false, > false); > GlyphVector gv = font.createGlyphVector(frc, value); > g.drawGlyphVector(gv, 10, 80); > g.fill(gv.getOutline(10, 180)); > ImageIO.write(image, "png", outputFile); > } > > and then you don't need that G2D subclass. > > There should of course be a client-libs/2d bug on this. > I submitted https://bugs.openjdk.java.net/browse/JDK-8057986 > > Next thing to do is test the fix on an openjdk build using Font2DTest. > > > -phil. > > > > On 9/5/2014 6:57 PM, Martin Buchholz wrote: >> Hi font friends! >> >> I'm trying to share a font rendering bug fix contributed by my >> colleagues Behdad and Igor. >> >> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/freetypeScaler-outline/ >> >> >> Repro recipe: >> >> (cd test/java/awt/font/GlyphVector/ && javac >> GlyphVectorOutline.java && wget -q -O/tmp/msgothic.ttc >> https://browserlinux-jp.googlecode.com/files/msgothic.ttc && java >> GlyphVectorOutline /tmp/msgothic.ttc /tmp/katakana.png) >> >> After successfully running that, examine the two rendered >> Japanese characters. >> >> Without our fix, the lower one is misrendered. >> >> I don't know how the fix works, and whether/how the manual test >> case can be turned into a real jtreg test. >> >> > > From martinrb at google.com Wed Sep 10 21:41:14 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 10 Sep 2014 14:41:14 -0700 Subject: [OpenJDK 2D-Dev] freetypescaler fix for fonts that start with a control point In-Reply-To: <5410C4E2.6040900@oracle.com> References: <540F7581.4010400@oracle.com> <5410C4E2.6040900@oracle.com> Message-ID: On Wed, Sep 10, 2014 at 2:38 PM, Phil Race wrote: > On 9/10/2014 2:31 PM, Martin Buchholz wrote: > >> I have tried to cross all the t's left here. I took your suggestion and >> minimized the test greatly. I've taken ownership of the bug and it's now >> marked noreg-hard. >> >> I'm inclined to check in the test case as is, even though it's manual. >> But I leave that to you, the 2d maintainers. >> >> The only testing I've done is to run the one manual test. Hope that's OK. >> >> OK to commit this fix? >> > > Do we yet have a 2nd reviewer on the change ? > Is that a client-libs-thing? In core-libs, one reviewer is enough for jdk9. This patch has been in use at Google for a while. > Other than that its fine by me. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Sep 10 21:51:25 2014 From: philip.race at oracle.com (Phil Race) Date: Wed, 10 Sep 2014 14:51:25 -0700 Subject: [OpenJDK 2D-Dev] freetypescaler fix for fonts that start with a control point In-Reply-To: References: <540F7581.4010400@oracle.com> <5410C4E2.6040900@oracle.com> Message-ID: <5410C7DD.4070105@oracle.com> Yes, its a client-libs thing. We've always (10 years+) asked for two reviewers except for trivial reviews. I don't think I can count the number of times one reviewer has spotted something the other one missed. Maybe Doug ? -phil. On 9/10/2014 2:41 PM, Martin Buchholz wrote: > > > On Wed, Sep 10, 2014 at 2:38 PM, Phil Race > wrote: > > On 9/10/2014 2:31 PM, Martin Buchholz wrote: > > I have tried to cross all the t's left here. I took your > suggestion and minimized the test greatly. I've taken > ownership of the bug and it's now marked noreg-hard. > > I'm inclined to check in the test case as is, even though it's > manual. But I leave that to you, the 2d maintainers. > > The only testing I've done is to run the one manual test. > Hope that's OK. > > OK to commit this fix? > > > Do we yet have a 2nd reviewer on the change ? > > > Is that a client-libs-thing? In core-libs, one reviewer is enough for > jdk9. > > This patch has been in use at Google for a while. > > Other than that its fine by me. > From dougfelt at google.com Thu Sep 11 01:15:28 2014 From: dougfelt at google.com (Doug Felt) Date: Wed, 10 Sep 2014 18:15:28 -0700 Subject: [OpenJDK 2D-Dev] freetypescaler fix for fonts that start with a control point In-Reply-To: <5410C7DD.4070105@oracle.com> References: <540F7581.4010400@oracle.com> <5410C4E2.6040900@oracle.com> <5410C7DD.4070105@oracle.com> Message-ID: Hi Phil. I looked at it and it seems fine. Like you I assume using FT_Outline_Decompose is a win over iterating through the control points by hand. On Wed, Sep 10, 2014 at 2:51 PM, Phil Race wrote: > Yes, its a client-libs thing. We've always (10 years+) asked for two > reviewers > except for trivial reviews. I don't think I can count the number of times > one reviewer has spotted something the other one missed. Maybe Doug ? > > -phil. > > On 9/10/2014 2:41 PM, Martin Buchholz wrote: > > >> >> On Wed, Sep 10, 2014 at 2:38 PM, Phil Race > > wrote: >> >> On 9/10/2014 2:31 PM, Martin Buchholz wrote: >> >> I have tried to cross all the t's left here. I took your >> suggestion and minimized the test greatly. I've taken >> ownership of the bug and it's now marked noreg-hard. >> >> I'm inclined to check in the test case as is, even though it's >> manual. But I leave that to you, the 2d maintainers. >> >> The only testing I've done is to run the one manual test. >> Hope that's OK. >> >> OK to commit this fix? >> >> >> Do we yet have a 2nd reviewer on the change ? >> >> >> Is that a client-libs-thing? In core-libs, one reviewer is enough for >> jdk9. >> >> This patch has been in use at Google for a while. >> >> Other than that its fine by me. >> >> > -- Doug Felt | Software Engineer | dougfelt at google.com | 1-650-253-2089 -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Thu Sep 11 08:56:32 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 11 Sep 2014 10:56:32 +0200 Subject: [OpenJDK 2D-Dev] RFR: 8056213 : Clean up unix/native/common/sun/awt In-Reply-To: <5410BE42.6010504@oracle.com> References: <540F6E4D.3060802@oracle.com> <541007D5.5060302@oracle.com> <5410A87D.1030302@oracle.com> <5410B45A.10103@oracle.com> <5410BE42.6010504@oracle.com> Message-ID: <541163C0.30903@oracle.com> This looks good to me. /Erik On 2014-09-10 23:10, Phil Race wrote: > Updated webrev :- http://cr.openjdk.java.net/~prr/8056213.1/ > > -phil. > > On 09/10/2014 01:28 PM, Phil Race wrote: >> I now see InitIDs.m defines more stubs than initIDs.c since >> 1) some stubs for xawt are instead defined in XToolkit.c >> 2) some xawt cases (eg Button) have more than an empty stub - actual >> content. >> 3) Some aren't defined at all in the case you have headless awt but >> they can't be reached because of checks in the classes for headless >> >> So I'll leave the OS X files alone >> >> -phil. >> >> >> On 09/10/2014 12:37 PM, Phil Race wrote: >>> > That means that instead of having to add even more excludes, you >>> can delete some existing >>> >>> >>> Doing that leaves just this one :- >>> >>> ifeq ($(OPENJDK_TARGET_OS), macosx) >>> LIBAWT_EXFILES += initIDs.c sun/awt/image/cvutils/img_colors.c >>> endif >>> >>> So its actually excluded from the core libawt on OS X. >>> It seems that instead they are defined there in libawt_lwawt >>> in a file initIDs.m >>> >>> This might be necessary if they do something but it seems >>> they are the same stubs used elsewhere and initIDs.h is no >>> more than a GPL header with no content ! >>> >>> Its going to be a bit more work and testing but it seems like we could >>> scrap the lwawt Objectionable C versions and just used the >>> shared one. >>> >>> I don't believe the mapfiles are used on OSX (there isn't >>> even a map file directory for lwawt) so it hasn't >>> mattered that they were in a different DLL, so long as they >>> were loaded in time. >>> >>> -phil. >>> >>> >>> On 09/10/2014 01:12 AM, Magnus Ihse Bursie wrote: >>>> On 2014-09-09 23:17, Phil Race wrote: >>>>> After looking at the issues in the bug report below I think the only >>>>> think that must be fixed is the unnecessary inclusion of initIDS.c >>>>> in libawt_xawt.so >>>> >>>> You are correct indeed. I had missed the fact that awt_Font.c, >>>> fontpath.c and X11Color.c was included in libawt_headless. :-( >>>> >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8056213 >>>>> http://cr.openjdk.java.net/~prr/8056213/ >>>> >>>> Since initIDs.c are now only used in a single library, I think it >>>> is better to move it away from the "common" directory, into >>>> src/java.desktop/unix/native/libawt/sun/awt where it will get >>>> picked up automatically, but just for libawt. That means that >>>> instead of having to add even more excludes, you can delete some >>>> existing, like this: >>>> >>>> diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk >>>> --- a/make/lib/Awt2dLibraries.gmk >>>> +++ b/make/lib/Awt2dLibraries.gmk >>>> @@ -748,7 +748,6 @@ >>>> -I$(JDK_TOPDIR)/src/java.desktop/$(OPENJDK_TARGET_OS_API_DIR)/native/libsunwjdga/ >>>> \ >>>> $(LIBJAVA_HEADER_FLAGS) \ >>>> # >>>> - LIBAWT_HEADLESS_EXFILES := initIDs.c >>>> >>>> LIBAWT_HEADLESS_REORDER := >>>> ifeq ($(OPENJDK_TARGET_OS), solaris) >>>> @@ -761,7 +760,6 @@ >>>> LIBRARY := awt_headless, \ >>>> OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \ >>>> SRC := $(LIBAWT_HEADLESS_DIRS), \ >>>> - EXCLUDE_FILES := $(LIBAWT_HEADLESS_EXFILES), \ >>>> EXCLUDES := $(LIBAWT_HEADLESS_EXCLUDES), \ >>>> LANG := C, \ >>>> OPTIMIZATION := LOW, \ >>>> @@ -932,7 +930,7 @@ >>>> $(LIBJAVA_HEADER_FLAGS) \ >>>> # >>>> >>>> - LIBAWT_LWAWT_EXFILES := fontpath.c awt_Font.c X11Color.c initIDs.c >>>> + LIBAWT_LWAWT_EXFILES := fontpath.c awt_Font.c X11Color.c >>>> LIBAWT_LWAWT_EXCLUDES := >>>> $(JDK_TOPDIR)/src/java.desktop/unix/native/common/sun/awt/medialib >>>> >>>> $(eval $(call SetupNativeCompilation,BUILD_LIBAWT_LWAWT, \ >>>> >>>> >>>> /Magnus >>> >> > From magnus.ihse.bursie at oracle.com Thu Sep 11 09:36:11 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 11 Sep 2014 11:36:11 +0200 Subject: [OpenJDK 2D-Dev] RFR: 8056213 : Clean up unix/native/common/sun/awt In-Reply-To: <5410BE42.6010504@oracle.com> References: <540F6E4D.3060802@oracle.com> <541007D5.5060302@oracle.com> <5410A87D.1030302@oracle.com> <5410B45A.10103@oracle.com> <5410BE42.6010504@oracle.com> Message-ID: <54116D0B.1040503@oracle.com> On 2014-09-10 23:10, Phil Race wrote: > Updated webrev :- http://cr.openjdk.java.net/~prr/8056213.1/ Looks good. However, the webrev shows the file as being moved outside the control of mercurial. That is, if you do "hg mv" to move the file, the history of the file will be kept intact. Otherwise it will look like a new file in the repo. (Sometimes this doesn't show up properly in the webrev, apologies if you already did this.) /Magnus From sergey.bylokhov at oracle.com Thu Sep 11 12:43:49 2014 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 11 Sep 2014 05:43:49 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] request for review: 8041465: BMPImageReader read error using ImageReadParam with set sourceRectangle Message-ID: <68fa78ee-6f6c-4c05-b13e-ad50f6798fe9@default> Hi, Andrew. The fix looks good then. > my preference is to leave the seek(bitmapStart) in the read() method > in order to reduce potential overhead because readHedaer() is called > very often. On 9/8/2014 7:31 PM, Sergey Bylokhov wrote: > Hi, Andrew. > I am not an expert in this area, but probably the bug can be fixed in > the readHeader itself? Because currently it call > iis.skipBytes(bitmapOffset) at the end only for the first time. > > On 03.09.2014 16:23, Andrew Brygin wrote: >> Hello, >> >> could you please review a fix for CR 8041465? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8041465 >> Webrev: http://cr.openjdk.java.net/~bae/8041465/9/webrev.00/ >> >> The problem happens if we perform multiple read operations from >> a source which is set only once. For instance, we can try to read >> image in several tiles. >> >> The root case of the problem is that we set stream position >> to the start of raster data only once: when we complete >> the processing of BMP header. A peculiarity of BMP format >> is that raster data can be stored in reverse order, so if we >> request few leading scanlines first, then we skip rest of raster >> data, and subsequent read command does not copy anything to the >> destination buffer, because we never re-set the stream position >> to the start of bitmap. >> >> Suggested fix just saves the bitmap's start postilion and seeks >> the stream to to it each time when we read image. This change >> makes the BMP reader behavior exactly same as other standard plugin >> demonstrate. >> >> Supplied regression test demonstrates the problem. >> >> Please take a look. >> >> Thanks, >> Andrew. > > From philip.race at oracle.com Thu Sep 11 20:11:00 2014 From: philip.race at oracle.com (Phil Race) Date: Thu, 11 Sep 2014 13:11:00 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8056213 : Clean up unix/native/common/sun/awt In-Reply-To: <54116D0B.1040503@oracle.com> References: <540F6E4D.3060802@oracle.com> <541007D5.5060302@oracle.com> <5410A87D.1030302@oracle.com> <5410B45A.10103@oracle.com> <5410BE42.6010504@oracle.com> <54116D0B.1040503@oracle.com> Message-ID: <541201D4.8060507@oracle.com> That may be just webrev. I did do an hg mv. But until you 'hg commit' the move, mercurial will claim no knowledge of the file :- $ hg log src/java.desktop/unix/native/libawt/sun/awt/initIDs.c abort: cannot follow file not in parent revision: "src/java.desktop/unix/native/libawt/sun/awt/initIDs.c" $ hg commit ..... $ hg log --follow src/java.desktop/unix/native/libawt/sun/awt/initIDs.c | head -12 changeset: 10615:3182de2cd0a4 tag: tip user: prr date: Thu Sep 11 13:07:37 2014 -0700 summary: 8056213: Clean up unix/native/common/sun/awt changeset: 10520:f08705540498 parent: 10505:88856f58680f user: chegar date: Sun Aug 17 15:54:13 2014 +0100 summary: 8054834: Modular Source Code -phil. On 09/11/2014 02:36 AM, Magnus Ihse Bursie wrote: > On 2014-09-10 23:10, Phil Race wrote: >> Updated webrev :- http://cr.openjdk.java.net/~prr/8056213.1/ > > Looks good. However, the webrev shows the file as being moved outside > the control of mercurial. That is, if you do "hg mv" to move the file, > the history of the file will be kept intact. Otherwise it will look > like a new file in the repo. (Sometimes this doesn't show up properly > in the webrev, apologies if you already did this.) > > /Magnus From anisha.nagarajan1 at gmail.com Sat Sep 13 01:47:26 2014 From: anisha.nagarajan1 at gmail.com (Anisha Nagarajan) Date: Fri, 12 Sep 2014 18:47:26 -0700 Subject: [OpenJDK 2D-Dev] Updated Review Request for JDK-6588417: Message-ID: Hi, Here is the updated Webrev for JDK-6588417: http://cr.openjdk.java.net/~ssides/6588417/6588417.1/ Thanks, Anisha -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Sun Sep 14 14:19:08 2014 From: philip.race at oracle.com (Phil Race) Date: Sun, 14 Sep 2014 07:19:08 -0700 Subject: [OpenJDK 2D-Dev] Updated Review Request for JDK-6588417: In-Reply-To: References: Message-ID: <5415A3DC.3030706@oracle.com> Hi, MemoryCache doesn't really have I/O Exceptions but does synthesise have to them so perhaps wording in MemoryCache.java like 148 * @throws IOException if there is an I/O exception while writing to the 149 * stream isn't 100% descriptive of what actually happens but is probably OK per the contract. So this change looks OK to me. BTW > Here is the updated Webrev for JDK-6588417: I don't remember seeing any previous version and so initially thought it was going to be a followup to http://mail.openjdk.java.net/pipermail/2d-dev/2014-August/004755.html which is still outstanding ... -phil. On 9/12/14 6:47 PM, Anisha Nagarajan wrote: > Hi, > > Here is the updated Webrev for JDK-6588417: > http://cr.openjdk.java.net/~ssides/6588417/6588417.1/ > > > Thanks, > Anisha -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Mon Sep 15 14:17:48 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 15 Sep 2014 18:17:48 +0400 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8055326 Fix typos in client-related packages In-Reply-To: <54103FE6.5070104@oracle.com> References: <53F62E90.90401@oracle.com> <53F634BB.7000905@oracle.com> <54103FE6.5070104@oracle.com> Message-ID: <5416F50C.3020706@oracle.com> The fix looks good to me. Thanks, Alexandr. On 9/10/2014 4:11 PM, Sergey Bylokhov wrote: > Hi, Phil. > It seems both changes are unnecessary: > http://cr.openjdk.java.net/~serb/8055326/webrev.01 > > On 21.08.2014 22:04, Phil Race wrote: >> Was the additional spce on the 2nd line intended here ? >> >> --- >> old/src/java.desktop/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java >> 2014-08-21 20:50:04.859532400 +0400 >> +++ >> new/src/java.desktop/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java >> 2014-08-21 20:50:04.663521200 +0400 >> @@ -166,8 +166,8 @@ >> retComp = >> cont.getFocusTraversalPolicy().getDefaultComponent(cont); >> >> if (retComp != null && >> log.isLoggable(PlatformLogger.Level.FINE)) { >> - log.fine("### Transfered focus down-cycle to >> " + retComp + >> - " in the focus cycle root " + cont); >> + log.fine("### Transferred focus down-cycle >> to " + retComp + >> + " in the focus cycle root " + cont); >> >> >> And I don't see what was so wrong with this, perhaps because I wrote >> it :-) >> >> - * so that when the Font2D is GC'd it can also remove the file. >> + * so that when the Font2D is GC'ed it can also remove the >> file. >> >> >> Other than that, looks good. >> Some fun new words in there. I particularly liked utilitized and >> unclude. >> >> -phil. >> >> On 8/21/2014 10:38 AM, Sergey Bylokhov wrote: >>> Hello, >>> Please review the fix for jdk 9. >>> The fix was contributed by pavel.rappo at oracle.com >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8055326 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/8055326/webrev.00 >>> >> > > From alexander.zvegintsev at oracle.com Mon Sep 15 15:37:29 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Mon, 15 Sep 2014 19:37:29 +0400 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8055326 Fix typos in client-related packages In-Reply-To: <54103FE6.5070104@oracle.com> References: <53F62E90.90401@oracle.com> <53F634BB.7000905@oracle.com> <54103FE6.5070104@oracle.com> Message-ID: <541707B9.2040908@oracle.com> Hello Sergey, The fix looks good to me in general, but I have a few comments: It would be nice to add @Override annotation to java.awt.Window.adjustDescendantsOnParent() --- old/src/java.desktop/share/classes/java/awt/Component.java 2014-09-10 15:11:22.601342000 +0400 +++ new/src/java.desktop/share/classes/java/awt/Component.java 2014-09-10 15:11:21.809727900 +0400 @@ -781,11 +781,12 @@ */ OTHER } /* - * The shape set with the applyCompoundShape() method. It uncludes the result + * The shape set with the applyCompoundShape() method. It includes the + * result * of the HW/LW mixing related shape computation. It may also include * the user-specified shape of the component. * The 'null' value means the component has normal shape (or has no shape at all) * and applyCompoundShape() will skip the following shape identical to normal. */ I think that result should not be at the next line. (80 chars per line limit already violated a few lines below so changing only one line does not make any sense to me). java/awt/Component.java "bootstrap class loader" vs java/awt/GraphicsEnvironment.java "bootstrap classloader" I think that we should choose and use only one title. This may be irrelevant to this issue, but after grepping sources for "Scirpt" usage I've found similar typo in CSS.java: ./java/awt/font/NumericShaper.java:92: * EnumSet.of(NumericShaper.Scirpt.ARABIC, NumericShaper.Range.TAMIL) ./javax/swing/text/html/CSS.java:879: * If the vertical alignment is set to either superscirpt or BTW, I like the idea of advertisement in source code :) : java/awt/image/ColorModel.java // algorithm for linear RGB to nonlinear sRGB conversion // is from the IEC 61966-2-1 International Standard, // Colour Management - Default RGB colour space - sRGB, // First Edition, 1999-10, // available for order at http://www.iec.ch Thanks, Alexander. On 09/10/2014 04:11 PM, Sergey Bylokhov wrote: > Hi, Phil. > It seems both changes are unnecessary: > http://cr.openjdk.java.net/~serb/8055326/webrev.01 > > On 21.08.2014 22:04, Phil Race wrote: >> Was the additional spce on the 2nd line intended here ? >> >> --- >> old/src/java.desktop/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java >> 2014-08-21 20:50:04.859532400 +0400 >> +++ >> new/src/java.desktop/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java >> 2014-08-21 20:50:04.663521200 +0400 >> @@ -166,8 +166,8 @@ >> retComp = >> cont.getFocusTraversalPolicy().getDefaultComponent(cont); >> >> if (retComp != null && >> log.isLoggable(PlatformLogger.Level.FINE)) { >> - log.fine("### Transfered focus down-cycle to >> " + retComp + >> - " in the focus cycle root " + cont); >> + log.fine("### Transferred focus down-cycle >> to " + retComp + >> + " in the focus cycle root " + cont); >> >> >> And I don't see what was so wrong with this, perhaps because I wrote >> it :-) >> >> - * so that when the Font2D is GC'd it can also remove the file. >> + * so that when the Font2D is GC'ed it can also remove the >> file. >> >> >> Other than that, looks good. >> Some fun new words in there. I particularly liked utilitized and >> unclude. >> >> -phil. >> >> On 8/21/2014 10:38 AM, Sergey Bylokhov wrote: >>> Hello, >>> Please review the fix for jdk 9. >>> The fix was contributed by pavel.rappo at oracle.com >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8055326 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/8055326/webrev.00 >>> >> > > From philip.race at oracle.com Mon Sep 15 15:51:23 2014 From: philip.race at oracle.com (Phil Race) Date: Mon, 15 Sep 2014 08:51:23 -0700 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8055326 Fix typos in client-related packages In-Reply-To: <54103FE6.5070104@oracle.com> References: <53F62E90.90401@oracle.com> <53F634BB.7000905@oracle.com> <54103FE6.5070104@oracle.com> Message-ID: <54170AFB.8080000@oracle.com> approved. -phil. On 9/10/2014 5:11 AM, Sergey Bylokhov wrote: > Hi, Phil. > It seems both changes are unnecessary: > http://cr.openjdk.java.net/~serb/8055326/webrev.01 > > On 21.08.2014 22:04, Phil Race wrote: >> Was the additional spce on the 2nd line intended here ? >> >> --- >> old/src/java.desktop/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java >> 2014-08-21 20:50:04.859532400 +0400 >> +++ >> new/src/java.desktop/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java >> 2014-08-21 20:50:04.663521200 +0400 >> @@ -166,8 +166,8 @@ >> retComp = >> cont.getFocusTraversalPolicy().getDefaultComponent(cont); >> >> if (retComp != null && >> log.isLoggable(PlatformLogger.Level.FINE)) { >> - log.fine("### Transfered focus down-cycle to >> " + retComp + >> - " in the focus cycle root " + cont); >> + log.fine("### Transferred focus down-cycle >> to " + retComp + >> + " in the focus cycle root " + cont); >> >> >> And I don't see what was so wrong with this, perhaps because I wrote >> it :-) >> >> - * so that when the Font2D is GC'd it can also remove the file. >> + * so that when the Font2D is GC'ed it can also remove the >> file. >> >> >> Other than that, looks good. >> Some fun new words in there. I particularly liked utilitized and >> unclude. >> >> -phil. >> >> On 8/21/2014 10:38 AM, Sergey Bylokhov wrote: >>> Hello, >>> Please review the fix for jdk 9. >>> The fix was contributed by pavel.rappo at oracle.com >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8055326 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/8055326/webrev.00 >>> >> > > From philip.race at oracle.com Thu Sep 18 20:42:00 2014 From: philip.race at oracle.com (Phil Race) Date: Thu, 18 Sep 2014 13:42:00 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8056216 : Remove "sun" directory layer from libawt and common Message-ID: <541B4398.8090605@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8056216 http://cr.openjdk.java.net/~prr/8056216/ This is all just removing the sequence "sun/" from various pathnames. Aside from the make file changes there are over 600 file moves which I don't think its worth including in the webrev but they are the result of the following 'hg mv' commands hg mv src/java.desktop/windows/native/libawt/sun/* src/java.desktop/windows/native/libawt/ hg mv src/java.desktop/windows/native/common/sun/awt src/java.desktop/windows/native/common hg mv src/java.desktop/share/native/libawt/sun/* src/java.desktop/share/native/libawt hg mv src/java.desktop/share/native/common/sun/* src/java.desktop/share/native/common hg mv src/java.desktop/macosx/native/libawt_lwawt/sun/* src/java.desktop/macosx/native/libawt_lwawt hg mv src/java.desktop/unix/native/libawt/sun/* src/java.desktop/unix/native/libawt hg mv src/java.desktop/unix/native/common/sun/* src/java.desktop/unix/native/common hg mv src/java.desktop/unix/native/libawt_headless/sun/awt src/java.desktop/unix/native/libawt_headless hg mv src/java.desktop/unix/native/libawt_xawt/sun/* src/java.desktop/unix/native/libawt_xawt/ I have done full open+closed builds via JPRT on all platforms ... -phil. From erik.joelsson at oracle.com Fri Sep 19 08:07:54 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 19 Sep 2014 10:07:54 +0200 Subject: [OpenJDK 2D-Dev] RFR: 8056216 : Remove "sun" directory layer from libawt and common In-Reply-To: <541B4398.8090605@oracle.com> References: <541B4398.8090605@oracle.com> Message-ID: <541BE45A.7030100@oracle.com> Looks good to me. Thanks for fixing this! /Erik On 2014-09-18 22:42, Phil Race wrote: > https://bugs.openjdk.java.net/browse/JDK-8056216 > http://cr.openjdk.java.net/~prr/8056216/ > > This is all just removing the sequence "sun/" from various pathnames. > > Aside from the make file changes there are over 600 file moves which I > don't think > its worth including in the webrev but they are the result of the > following 'hg mv' commands > > hg mv src/java.desktop/windows/native/libawt/sun/* > src/java.desktop/windows/native/libawt/ > hg mv src/java.desktop/windows/native/common/sun/awt > src/java.desktop/windows/native/common > hg mv src/java.desktop/share/native/libawt/sun/* > src/java.desktop/share/native/libawt > hg mv src/java.desktop/share/native/common/sun/* > src/java.desktop/share/native/common > hg mv src/java.desktop/macosx/native/libawt_lwawt/sun/* > src/java.desktop/macosx/native/libawt_lwawt > hg mv src/java.desktop/unix/native/libawt/sun/* > src/java.desktop/unix/native/libawt > hg mv src/java.desktop/unix/native/common/sun/* > src/java.desktop/unix/native/common > hg mv src/java.desktop/unix/native/libawt_headless/sun/awt > src/java.desktop/unix/native/libawt_headless > hg mv src/java.desktop/unix/native/libawt_xawt/sun/* > src/java.desktop/unix/native/libawt_xawt/ > > I have done full open+closed builds via JPRT on all platforms ... > > -phil. > > From magnus.ihse.bursie at oracle.com Fri Sep 19 08:28:55 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 19 Sep 2014 10:28:55 +0200 Subject: [OpenJDK 2D-Dev] RFR: 8056216 : Remove "sun" directory layer from libawt and common In-Reply-To: <541B4398.8090605@oracle.com> References: <541B4398.8090605@oracle.com> Message-ID: <541BE947.8070904@oracle.com> On 2014-09-18 22:42, Phil Race wrote: > https://bugs.openjdk.java.net/browse/JDK-8056216 > http://cr.openjdk.java.net/~prr/8056216/ Looks good to me. Thanks! /Magnus > > This is all just removing the sequence "sun/" from various pathnames. > > Aside from the make file changes there are over 600 file moves which I > don't think > its worth including in the webrev but they are the result of the > following 'hg mv' commands > > hg mv src/java.desktop/windows/native/libawt/sun/* > src/java.desktop/windows/native/libawt/ > hg mv src/java.desktop/windows/native/common/sun/awt > src/java.desktop/windows/native/common > hg mv src/java.desktop/share/native/libawt/sun/* > src/java.desktop/share/native/libawt > hg mv src/java.desktop/share/native/common/sun/* > src/java.desktop/share/native/common > hg mv src/java.desktop/macosx/native/libawt_lwawt/sun/* > src/java.desktop/macosx/native/libawt_lwawt > hg mv src/java.desktop/unix/native/libawt/sun/* > src/java.desktop/unix/native/libawt > hg mv src/java.desktop/unix/native/common/sun/* > src/java.desktop/unix/native/common > hg mv src/java.desktop/unix/native/libawt_headless/sun/awt > src/java.desktop/unix/native/libawt_headless > hg mv src/java.desktop/unix/native/libawt_xawt/sun/* > src/java.desktop/unix/native/libawt_xawt/ > > I have done full open+closed builds via JPRT on all platforms ... > > -phil. > > From sean.coffey at oracle.com Fri Sep 19 10:37:46 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Fri, 19 Sep 2014 11:37:46 +0100 Subject: [OpenJDK 2D-Dev] RFR: 8056216 : Remove "sun" directory layer from libawt and common In-Reply-To: <541BE947.8070904@oracle.com> References: <541B4398.8090605@oracle.com> <541BE947.8070904@oracle.com> Message-ID: <541C077A.6080902@oracle.com> Hi Phil, you'll need to update the unshuffle script[1] also given your path changes. A find/replace operation should work. It probably makes sense to push all changes together. Regards, Sean. [1] http://cr.openjdk.java.net/~chegar/docs/portingScript.html On 19/09/14 09:28, Magnus Ihse Bursie wrote: > On 2014-09-18 22:42, Phil Race wrote: >> https://bugs.openjdk.java.net/browse/JDK-8056216 >> http://cr.openjdk.java.net/~prr/8056216/ > > Looks good to me. Thanks! > > /Magnus > >> >> This is all just removing the sequence "sun/" from various pathnames. >> >> Aside from the make file changes there are over 600 file moves which >> I don't think >> its worth including in the webrev but they are the result of the >> following 'hg mv' commands >> >> hg mv src/java.desktop/windows/native/libawt/sun/* >> src/java.desktop/windows/native/libawt/ >> hg mv src/java.desktop/windows/native/common/sun/awt >> src/java.desktop/windows/native/common >> hg mv src/java.desktop/share/native/libawt/sun/* >> src/java.desktop/share/native/libawt >> hg mv src/java.desktop/share/native/common/sun/* >> src/java.desktop/share/native/common >> hg mv src/java.desktop/macosx/native/libawt_lwawt/sun/* >> src/java.desktop/macosx/native/libawt_lwawt >> hg mv src/java.desktop/unix/native/libawt/sun/* >> src/java.desktop/unix/native/libawt >> hg mv src/java.desktop/unix/native/common/sun/* >> src/java.desktop/unix/native/common >> hg mv src/java.desktop/unix/native/libawt_headless/sun/awt >> src/java.desktop/unix/native/libawt_headless >> hg mv src/java.desktop/unix/native/libawt_xawt/sun/* >> src/java.desktop/unix/native/libawt_xawt/ >> >> I have done full open+closed builds via JPRT on all platforms ... >> >> -phil. >> >> > From philip.race at oracle.com Fri Sep 19 16:22:26 2014 From: philip.race at oracle.com (Phil Race) Date: Fri, 19 Sep 2014 09:22:26 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8056216 : Remove "sun" directory layer from libawt and common In-Reply-To: <541C077A.6080902@oracle.com> References: <541B4398.8090605@oracle.com> <541BE947.8070904@oracle.com> <541C077A.6080902@oracle.com> Message-ID: <541C5842.1050308@oracle.com> Gosh that's going to be a pain to maintain .. here's an update to the 334 affected lines in that file ! Look ok ? http://cr.openjdk.java.net/~prr/8056216.1 -phil On 09/19/2014 03:37 AM, Se?n Coffey wrote: > Hi Phil, > > you'll need to update the unshuffle script[1] also given your path > changes. A find/replace operation should work. It probably makes sense > to push all changes together. > > Regards, > Sean. > > [1] http://cr.openjdk.java.net/~chegar/docs/portingScript.html > > On 19/09/14 09:28, Magnus Ihse Bursie wrote: >> On 2014-09-18 22:42, Phil Race wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8056216 >>> http://cr.openjdk.java.net/~prr/8056216/ >> >> Looks good to me. Thanks! >> >> /Magnus >> >>> >>> This is all just removing the sequence "sun/" from various pathnames. >>> >>> Aside from the make file changes there are over 600 file moves which >>> I don't think >>> its worth including in the webrev but they are the result of the >>> following 'hg mv' commands >>> >>> hg mv src/java.desktop/windows/native/libawt/sun/* >>> src/java.desktop/windows/native/libawt/ >>> hg mv src/java.desktop/windows/native/common/sun/awt >>> src/java.desktop/windows/native/common >>> hg mv src/java.desktop/share/native/libawt/sun/* >>> src/java.desktop/share/native/libawt >>> hg mv src/java.desktop/share/native/common/sun/* >>> src/java.desktop/share/native/common >>> hg mv src/java.desktop/macosx/native/libawt_lwawt/sun/* >>> src/java.desktop/macosx/native/libawt_lwawt >>> hg mv src/java.desktop/unix/native/libawt/sun/* >>> src/java.desktop/unix/native/libawt >>> hg mv src/java.desktop/unix/native/common/sun/* >>> src/java.desktop/unix/native/common >>> hg mv src/java.desktop/unix/native/libawt_headless/sun/awt >>> src/java.desktop/unix/native/libawt_headless >>> hg mv src/java.desktop/unix/native/libawt_xawt/sun/* >>> src/java.desktop/unix/native/libawt_xawt/ >>> >>> I have done full open+closed builds via JPRT on all platforms ... >>> >>> -phil. >>> >>> >> > From Alan.Bateman at oracle.com Fri Sep 19 16:33:48 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 19 Sep 2014 17:33:48 +0100 Subject: [OpenJDK 2D-Dev] RFR: 8056216 : Remove "sun" directory layer from libawt and common In-Reply-To: <541C5842.1050308@oracle.com> References: <541B4398.8090605@oracle.com> <541BE947.8070904@oracle.com> <541C077A.6080902@oracle.com> <541C5842.1050308@oracle.com> Message-ID: <541C5AEC.9060001@oracle.com> On 19/09/2014 17:22, Phil Race wrote: > Gosh that's going to be a pain to maintain .. here's an update to the > 334 affected lines in that file ! Look ok ? > http://cr.openjdk.java.net/~prr/8056216.1 > > -phil Ideally there should be just one line per directory, it should only list individual files for cases the files aren't all in the same directory in jdk8u-dev. It's hard to see from the webrev to know why there are individual source files listed. It would be great to collapse this down to 1 line if possible. -Alan From sean.coffey at oracle.com Fri Sep 19 16:41:46 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Fri, 19 Sep 2014 17:41:46 +0100 Subject: [OpenJDK 2D-Dev] RFR: 8056216 : Remove "sun" directory layer from libawt and common In-Reply-To: <541C5AEC.9060001@oracle.com> References: <541B4398.8090605@oracle.com> <541BE947.8070904@oracle.com> <541C077A.6080902@oracle.com> <541C5842.1050308@oracle.com> <541C5AEC.9060001@oracle.com> Message-ID: <541C5CCA.3080404@oracle.com> On 19/09/14 17:33, Alan Bateman wrote: > On 19/09/2014 17:22, Phil Race wrote: >> Gosh that's going to be a pain to maintain .. here's an update to the >> 334 affected lines in that file ! Look ok ? >> http://cr.openjdk.java.net/~prr/8056216.1 >> >> -phil > Ideally there should be just one line per directory, it should only > list individual files for cases the files aren't all in the same > directory in jdk8u-dev. It's hard to see from the webrev to know why > there are individual source files listed. It would be great to > collapse this down to 1 line if possible. For the simpler packages, this was possible : e.g. nashorn/src/jdk.scripting.nashorn/share/classes : nashorn/src for the more complex packages where java src, native src and config files got split up and where backwards (9 -> 8) and forwards (8 -> 9) shuffling remained functional - then the picture is not as clear. Thanks for the update Phil. Looks ok to me. regards, Sean. > > -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Sep 19 19:08:33 2014 From: philip.race at oracle.com (Phil Race) Date: Fri, 19 Sep 2014 12:08:33 -0700 Subject: [OpenJDK 2D-Dev] Updated Review Request for JDK-8054877 In-Reply-To: References: Message-ID: <541C7F31.3090400@oracle.com> Looks good now -phil. On 9/18/2014 7:58 PM, Anisha Nagarajan wrote: > Hi, > > Here is the updated werbev for JDK-8054877: > http://cr.openjdk.java.net/~ssides/8054877/8054877.3/ > > > Thanks, > Anisha From philip.race at oracle.com Fri Sep 19 19:19:56 2014 From: philip.race at oracle.com (Phil Race) Date: Fri, 19 Sep 2014 12:19:56 -0700 Subject: [OpenJDK 2D-Dev] PING: JDK-8017773: OpenJDK7 returns incorrect TrueType font metrics In-Reply-To: <535E5EE9.7010503@gmail.com> References: <52EF333C.2030208@lab.ntt.co.jp> <52FC767A.8070805@lab.ntt.co.jp> <53263B9E.1040606@lab.ntt.co.jp> <533D6C6D.7010006@gmail.com> <5345A992.3040005@oracle.com> <53468EAD.6060805@gmail.com> <535E5EE9.7010503@gmail.com> Message-ID: <541C81DC.3020702@oracle.com> Hi, It does seem like it may have been wrong to adjust the height of the overall font metrics because of a widened outline .. although there is likely to be less visible line gap and more chance of clipping, nonetheless I think this looks OK.. If we see such problems we can re-consider. - Please get a "+1" from some one else too .. - Please push it to 9-client, not 9-dev. ie http://hg.openjdk.java.net/jdk9/client/jdk .. and thanks for the off-list ping on this. -phil. On 4/28/2014 7:00 AM, Yasumasa Suenaga wrote: > Hi Phili, > > I've created patch for this issue and uploaded webrev: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8017773/webrev.00/ > > > Could you help me? > > Yasumasa > > > On 04/10/2014 09:29 PM, Yasumasa Suenaga wrote: >> Hi Phili, >> Thank you for replying. >> >>> I don't know the details of what is on the end of the various links you >>> provide and >>> I can't go grabbing code from somewhere else. >> You can get patches as following: >> http://icedtea.classpath.org/bugzilla/attachment.cgi?id=873&action=diff >> http://icedtea.classpath.org/bugzilla/attachment.cgi?id=1014&action=diff >> >> >>> So step #1 would be for you to provide a patch I can consider under >>> terms of the >>> OCA against hg.openjdk.java/net/jdk9/client/jdk .. >> I've agreed the OCA, and I'm an author of jdk9 project. >> http://openjdk.java.net/census#ysuenaga >> >> >> Thanks, >> >> Yasumasa >> >> >> On 04/10/2014 05:12 AM, Phil Race wrote: >>> All bugs should be fixed first in the main development release and back >>> ported if appropriate. >>> And in any case any targeting you see is purely what the manager-types >>> are doing >>> because of current rules that say a bug needs to be targeted to a release. >>> It doesn't actually mean a thing here as I currently have no time to >>> even consider this bug. >>> I agree with the general premise that bold fonts should only be wider, >>> not taller but >>> I don't know the details of what is on the end of the various links you >>> provide and >>> I can't go grabbing code from somewhere else. >>> >>> So step #1 would be for you to provide a patch I can consider under >>> terms of the >>> OCA against hg.openjdk.java/net/jdk9/client/jdk .. >>> >>> -phil. >>> >>> >>> On 4/3/2014 7:13 AM, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> Have you checked this issue? >>>> >>>> This issue will be fixed in JDK9. >>>> However, I want fix it in JDK7 and JDK8. >>>> >>>> >>>> Yasumasa >>>> >>>> >>>> On 2014/03/17 9:02, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> The "Fix version" of this issue has been changed into 9 from 8-pool. >>>>> Will this issue not be fixed in JDK7/8 ? >>>>> >>>>> I think this issue is bug of OpenJDK implementation. >>>>> So this issue should be fixed ASAP. >>>>> >>>>> >>>>> Yasumasa >>>>> >>>>> On 2014/02/13 16:38, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> I've reported about JDK-8017773 . Have you checked it ? >>>>>> >>>>>> I guess that many Linux distributor will ship OpenJDK8 after JDK8 GA is released. >>>>>> If this issue will not fix at JDK8 GA, many users who use 2D on JDK8 may encounter it. >>>>>> >>>>>> This issue occurs in OpenJDK only. >>>>>> However, I think there are many users who want to use 2D on OpenJDK. >>>>>> So I hope to fix this issue ASAP and hope to backport to JDK7. >>>>>> >>>>>> >>>>>> Please cooperate. >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2014/02/03 15:12, Yasumasa Suenaga wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> My customer encountered this issue. >>>>>>> I think this issue is caused by Bug 1435 [1] and 1659 [2] in IcedTea. >>>>>>> >>>>>>> I read source code of "freetype-2.5.0-4.fc20" . >>>>>>> Bold style should affect Font Glyph only. However, current implementation >>>>>>> of OpenJDK affects Font Face. Thus value of Ascent/Descent is incorrect. >>>>>>> >>>>>>> OracleJDK seems to use sun.font.T2KFontScaler to calculate these values. >>>>>>> So this issue occurs in OpenJDK only. >>>>>>> >>>>>>> >>>>>>> I think we need to merge patches of Bug 1435 and 1659 in IcedTea >>>>>>> to fix JDK-8017773 . >>>>>>> >>>>>>> Could you merge these patches ? >>>>>>> Please cooperate. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> [1] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1435 >>>>>>> [2] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1659 >>>>>>> >>>>>>> >>>>>>> ------ D E T A I L S ------ >>>>>>> >>>>>>> I've created testcase as "JavaApplication1.java" . >>>>>>> Result as: >>>>>>> >>>>>>> OracleJDK 6 Update 31 >>>>>>> ---------------- >>>>>>> [root at RHEL6-5 font]# /usr/local/jdk1.6.0_31/bin/java JavaApplication1 >>>>>>> JDK: 1.6.0_31 >>>>>>> VM: Java HotSpot(TM) 64-Bit Server VM >>>>>>> >>>>>>> java.awt.Font[family=IPAMincho,name=IPAMincho,style=plain,size=50] >>>>>>> Ascent: 43.99414 >>>>>>> Descent: 6.0058594 >>>>>>> >>>>>>> java.awt.Font[family=IPAMincho,name=IPAMincho,style=bold,size=50] >>>>>>> Ascent: 43.99414 >>>>>>> Descent: 6.0058594 >>>>>>> ---------------- >>>>>>> >>>>>>> OpenJDK7 (in RHEL6.5) >>>>>>> ---------------- >>>>>>> [root at RHEL6-5 font]# java JavaApplication1 >>>>>>> JDK: 1.7.0_45 >>>>>>> VM: OpenJDK 64-Bit Server VM >>>>>>> >>>>>>> java.awt.Font[family=IPAMincho,name=IPAMincho,style=plain,size=50] >>>>>>> Ascent: 43.99414 >>>>>>> Descent: 6.0058594 >>>>>>> >>>>>>> java.awt.Font[family=IPAMincho,name=IPAMincho,style=bold,size=50] >>>>>>> Ascent: 45.60547 >>>>>>> Descent: 4.3945312 >>>>>>> ---------------- From anisha.nagarajan1 at gmail.com Fri Sep 19 02:58:10 2014 From: anisha.nagarajan1 at gmail.com (Anisha Nagarajan) Date: Thu, 18 Sep 2014 19:58:10 -0700 Subject: [OpenJDK 2D-Dev] Updated Review Request for JDK-8054877 Message-ID: Hi, Here is the updated werbev for JDK-8054877: http://cr.openjdk.java.net/~ssides/8054877/8054877.3/ Thanks, Anisha -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Sat Sep 20 01:58:56 2014 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 20 Sep 2014 10:58:56 +0900 Subject: [OpenJDK 2D-Dev] RFR: JDK-8017773: OpenJDK7 returns incorrect TrueType font metrics In-Reply-To: <541C81DC.3020702@oracle.com> References: <52EF333C.2030208@lab.ntt.co.jp> <52FC767A.8070805@lab.ntt.co.jp> <53263B9E.1040606@lab.ntt.co.jp> <533D6C6D.7010006@gmail.com> <5345A992.3040005@oracle.com> <53468EAD.6060805@gmail.com> <535E5EE9.7010503@gmail.com> <541C81DC.3020702@oracle.com> Message-ID: <541CDF60.90608@gmail.com> Hi Phil, I changed subject of this email thread. webrev of this issue is here: http://cr.openjdk.java.net/~ysuenaga/JDK-8017773/webrev.00/ I'm just an author of jdk9, not a committer. So could you be a sponsor of this issue? Yasumasa On 2014/09/20 4:19, Phil Race wrote: > Hi, > > It does seem like it may have been wrong to adjust the height of the > overall font metrics because of > a widened outline .. although there is likely to be less visible line > gap and more chance of clipping, > nonetheless I think this looks OK.. If we see such problems we can > re-consider. > > - Please get a "+1" from some one else too .. > - Please push it to 9-client, not 9-dev. ie > http://hg.openjdk.java.net/jdk9/client/jdk > > .. and thanks for the off-list ping on this. > > -phil. > > On 4/28/2014 7:00 AM, Yasumasa Suenaga wrote: >> Hi Phili, >> >> I've created patch for this issue and uploaded webrev: >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8017773/webrev.00/ >> >> >> Could you help me? >> >> Yasumasa >> >> >> On 04/10/2014 09:29 PM, Yasumasa Suenaga wrote: >>> Hi Phili, >>> Thank you for replying. >>> >>>> I don't know the details of what is on the end of the various links you >>>> provide and >>>> I can't go grabbing code from somewhere else. >>> You can get patches as following: >>> http://icedtea.classpath.org/bugzilla/attachment.cgi?id=873&action=diff >>> http://icedtea.classpath.org/bugzilla/attachment.cgi?id=1014&action=diff >>> >>> >>>> So step #1 would be for you to provide a patch I can consider under >>>> terms of the >>>> OCA against hg.openjdk.java/net/jdk9/client/jdk .. >>> I've agreed the OCA, and I'm an author of jdk9 project. >>> http://openjdk.java.net/census#ysuenaga >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 04/10/2014 05:12 AM, Phil Race wrote: >>>> All bugs should be fixed first in the main development release and back >>>> ported if appropriate. >>>> And in any case any targeting you see is purely what the manager-types >>>> are doing >>>> because of current rules that say a bug needs to be targeted to a release. >>>> It doesn't actually mean a thing here as I currently have no time to >>>> even consider this bug. >>>> I agree with the general premise that bold fonts should only be wider, >>>> not taller but >>>> I don't know the details of what is on the end of the various links you >>>> provide and >>>> I can't go grabbing code from somewhere else. >>>> >>>> So step #1 would be for you to provide a patch I can consider under >>>> terms of the >>>> OCA against hg.openjdk.java/net/jdk9/client/jdk .. >>>> >>>> -phil. >>>> >>>> >>>> On 4/3/2014 7:13 AM, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> Have you checked this issue? >>>>> >>>>> This issue will be fixed in JDK9. >>>>> However, I want fix it in JDK7 and JDK8. >>>>> >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2014/03/17 9:02, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> The "Fix version" of this issue has been changed into 9 from 8-pool. >>>>>> Will this issue not be fixed in JDK7/8 ? >>>>>> >>>>>> I think this issue is bug of OpenJDK implementation. >>>>>> So this issue should be fixed ASAP. >>>>>> >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> On 2014/02/13 16:38, Yasumasa Suenaga wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> I've reported about JDK-8017773 . Have you checked it ? >>>>>>> >>>>>>> I guess that many Linux distributor will ship OpenJDK8 after JDK8 GA is released. >>>>>>> If this issue will not fix at JDK8 GA, many users who use 2D on JDK8 may encounter it. >>>>>>> >>>>>>> This issue occurs in OpenJDK only. >>>>>>> However, I think there are many users who want to use 2D on OpenJDK. >>>>>>> So I hope to fix this issue ASAP and hope to backport to JDK7. >>>>>>> >>>>>>> >>>>>>> Please cooperate. >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2014/02/03 15:12, Yasumasa Suenaga wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> My customer encountered this issue. >>>>>>>> I think this issue is caused by Bug 1435 [1] and 1659 [2] in IcedTea. >>>>>>>> >>>>>>>> I read source code of "freetype-2.5.0-4.fc20" . >>>>>>>> Bold style should affect Font Glyph only. However, current implementation >>>>>>>> of OpenJDK affects Font Face. Thus value of Ascent/Descent is incorrect. >>>>>>>> >>>>>>>> OracleJDK seems to use sun.font.T2KFontScaler to calculate these values. >>>>>>>> So this issue occurs in OpenJDK only. >>>>>>>> >>>>>>>> >>>>>>>> I think we need to merge patches of Bug 1435 and 1659 in IcedTea >>>>>>>> to fix JDK-8017773 . >>>>>>>> >>>>>>>> Could you merge these patches ? >>>>>>>> Please cooperate. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> [1] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1435 >>>>>>>> [2] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1659 >>>>>>>> >>>>>>>> >>>>>>>> ------ D E T A I L S ------ >>>>>>>> >>>>>>>> I've created testcase as "JavaApplication1.java" . >>>>>>>> Result as: >>>>>>>> >>>>>>>> OracleJDK 6 Update 31 >>>>>>>> ---------------- >>>>>>>> [root at RHEL6-5 font]# /usr/local/jdk1.6.0_31/bin/java JavaApplication1 >>>>>>>> JDK: 1.6.0_31 >>>>>>>> VM: Java HotSpot(TM) 64-Bit Server VM >>>>>>>> >>>>>>>> java.awt.Font[family=IPAMincho,name=IPAMincho,style=plain,size=50] >>>>>>>> Ascent: 43.99414 >>>>>>>> Descent: 6.0058594 >>>>>>>> >>>>>>>> java.awt.Font[family=IPAMincho,name=IPAMincho,style=bold,size=50] >>>>>>>> Ascent: 43.99414 >>>>>>>> Descent: 6.0058594 >>>>>>>> ---------------- >>>>>>>> >>>>>>>> OpenJDK7 (in RHEL6.5) >>>>>>>> ---------------- >>>>>>>> [root at RHEL6-5 font]# java JavaApplication1 >>>>>>>> JDK: 1.7.0_45 >>>>>>>> VM: OpenJDK 64-Bit Server VM >>>>>>>> >>>>>>>> java.awt.Font[family=IPAMincho,name=IPAMincho,style=plain,size=50] >>>>>>>> Ascent: 43.99414 >>>>>>>> Descent: 6.0058594 >>>>>>>> >>>>>>>> java.awt.Font[family=IPAMincho,name=IPAMincho,style=bold,size=50] >>>>>>>> Ascent: 45.60547 >>>>>>>> Descent: 4.3945312 >>>>>>>> ---------------- > From philip.race at oracle.com Sat Sep 20 02:47:08 2014 From: philip.race at oracle.com (Phil Race) Date: Fri, 19 Sep 2014 19:47:08 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8017773: OpenJDK7 returns incorrect TrueType font metrics In-Reply-To: <541CDF60.90608@gmail.com> References: <52EF333C.2030208@lab.ntt.co.jp> <52FC767A.8070805@lab.ntt.co.jp> <53263B9E.1040606@lab.ntt.co.jp> <533D6C6D.7010006@gmail.com> <5345A992.3040005@oracle.com> <53468EAD.6060805@gmail.com> <535E5EE9.7010503@gmail.com> <541C81DC.3020702@oracle.com> <541CDF60.90608@gmail.com> Message-ID: <541CEAAC.4020509@oracle.com> On 9/19/14 6:58 PM, Yasumasa Suenaga wrote: > Hi Phil, > > I changed subject of this email thread. > webrev of this issue is here: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8017773/webrev.00/ > > I'm just an author of jdk9, not a committer. > So could you be a sponsor of this issue? OK but I won't commit until you get the 2nd reviewer we require. -phil. > > > Yasumasa > > > On 2014/09/20 4:19, Phil Race wrote: >> Hi, >> >> It does seem like it may have been wrong to adjust the height of the >> overall font metrics because of >> a widened outline .. although there is likely to be less visible line >> gap and more chance of clipping, >> nonetheless I think this looks OK.. If we see such problems we can >> re-consider. >> >> - Please get a "+1" from some one else too .. >> - Please push it to 9-client, not 9-dev. ie >> http://hg.openjdk.java.net/jdk9/client/jdk >> >> .. and thanks for the off-list ping on this. >> >> -phil. >> >> On 4/28/2014 7:00 AM, Yasumasa Suenaga wrote: >>> Hi Phili, >>> >>> I've created patch for this issue and uploaded webrev: >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8017773/webrev.00/ >>> >>> >>> Could you help me? >>> >>> Yasumasa >>> >>> >>> On 04/10/2014 09:29 PM, Yasumasa Suenaga wrote: >>>> Hi Phili, >>>> Thank you for replying. >>>> >>>>> I don't know the details of what is on the end of the various links you >>>>> provide and >>>>> I can't go grabbing code from somewhere else. >>>> You can get patches as following: >>>> http://icedtea.classpath.org/bugzilla/attachment.cgi?id=873&action=diff >>>> http://icedtea.classpath.org/bugzilla/attachment.cgi?id=1014&action=diff >>>> >>>> >>>>> So step #1 would be for you to provide a patch I can consider under >>>>> terms of the >>>>> OCA against hg.openjdk.java/net/jdk9/client/jdk .. >>>> I've agreed the OCA, and I'm an author of jdk9 project. >>>> http://openjdk.java.net/census#ysuenaga >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 04/10/2014 05:12 AM, Phil Race wrote: >>>>> All bugs should be fixed first in the main development release and back >>>>> ported if appropriate. >>>>> And in any case any targeting you see is purely what the manager-types >>>>> are doing >>>>> because of current rules that say a bug needs to be targeted to a release. >>>>> It doesn't actually mean a thing here as I currently have no time to >>>>> even consider this bug. >>>>> I agree with the general premise that bold fonts should only be wider, >>>>> not taller but >>>>> I don't know the details of what is on the end of the various links you >>>>> provide and >>>>> I can't go grabbing code from somewhere else. >>>>> >>>>> So step #1 would be for you to provide a patch I can consider under >>>>> terms of the >>>>> OCA against hg.openjdk.java/net/jdk9/client/jdk .. >>>>> >>>>> -phil. >>>>> >>>>> >>>>> On 4/3/2014 7:13 AM, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> Have you checked this issue? >>>>>> >>>>>> This issue will be fixed in JDK9. >>>>>> However, I want fix it in JDK7 and JDK8. >>>>>> >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2014/03/17 9:02, Yasumasa Suenaga wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> The "Fix version" of this issue has been changed into 9 from 8-pool. >>>>>>> Will this issue not be fixed in JDK7/8 ? >>>>>>> >>>>>>> I think this issue is bug of OpenJDK implementation. >>>>>>> So this issue should be fixed ASAP. >>>>>>> >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> On 2014/02/13 16:38, Yasumasa Suenaga wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I've reported about JDK-8017773 . Have you checked it ? >>>>>>>> >>>>>>>> I guess that many Linux distributor will ship OpenJDK8 after JDK8 GA is released. >>>>>>>> If this issue will not fix at JDK8 GA, many users who use 2D on JDK8 may encounter it. >>>>>>>> >>>>>>>> This issue occurs in OpenJDK only. >>>>>>>> However, I think there are many users who want to use 2D on OpenJDK. >>>>>>>> So I hope to fix this issue ASAP and hope to backport to JDK7. >>>>>>>> >>>>>>>> >>>>>>>> Please cooperate. >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2014/02/03 15:12, Yasumasa Suenaga wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> My customer encountered this issue. >>>>>>>>> I think this issue is caused by Bug 1435 [1] and 1659 [2] in IcedTea. >>>>>>>>> >>>>>>>>> I read source code of "freetype-2.5.0-4.fc20" . >>>>>>>>> Bold style should affect Font Glyph only. However, current implementation >>>>>>>>> of OpenJDK affects Font Face. Thus value of Ascent/Descent is incorrect. >>>>>>>>> >>>>>>>>> OracleJDK seems to use sun.font.T2KFontScaler to calculate these values. >>>>>>>>> So this issue occurs in OpenJDK only. >>>>>>>>> >>>>>>>>> >>>>>>>>> I think we need to merge patches of Bug 1435 and 1659 in IcedTea >>>>>>>>> to fix JDK-8017773 . >>>>>>>>> >>>>>>>>> Could you merge these patches ? >>>>>>>>> Please cooperate. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> [1] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1435 >>>>>>>>> [2] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1659 >>>>>>>>> >>>>>>>>> >>>>>>>>> ------ D E T A I L S ------ >>>>>>>>> >>>>>>>>> I've created testcase as "JavaApplication1.java" . >>>>>>>>> Result as: >>>>>>>>> >>>>>>>>> OracleJDK 6 Update 31 >>>>>>>>> ---------------- >>>>>>>>> [root at RHEL6-5 font]# /usr/local/jdk1.6.0_31/bin/java JavaApplication1 >>>>>>>>> JDK: 1.6.0_31 >>>>>>>>> VM: Java HotSpot(TM) 64-Bit Server VM >>>>>>>>> >>>>>>>>> java.awt.Font[family=IPAMincho,name=IPAMincho,style=plain,size=50] >>>>>>>>> Ascent: 43.99414 >>>>>>>>> Descent: 6.0058594 >>>>>>>>> >>>>>>>>> java.awt.Font[family=IPAMincho,name=IPAMincho,style=bold,size=50] >>>>>>>>> Ascent: 43.99414 >>>>>>>>> Descent: 6.0058594 >>>>>>>>> ---------------- >>>>>>>>> >>>>>>>>> OpenJDK7 (in RHEL6.5) >>>>>>>>> ---------------- >>>>>>>>> [root at RHEL6-5 font]# java JavaApplication1 >>>>>>>>> JDK: 1.7.0_45 >>>>>>>>> VM: OpenJDK 64-Bit Server VM >>>>>>>>> >>>>>>>>> java.awt.Font[family=IPAMincho,name=IPAMincho,style=plain,size=50] >>>>>>>>> Ascent: 43.99414 >>>>>>>>> Descent: 6.0058594 >>>>>>>>> >>>>>>>>> java.awt.Font[family=IPAMincho,name=IPAMincho,style=bold,size=50] >>>>>>>>> Ascent: 45.60547 >>>>>>>>> Descent: 4.3945312 >>>>>>>>> ---------------- From hs at tagtraum.com Mon Sep 22 08:19:45 2014 From: hs at tagtraum.com (Hendrik Schreiber) Date: Mon, 22 Sep 2014 10:19:45 +0200 Subject: [OpenJDK 2D-Dev] RFR: JDK-8057830: Crash in Java2D Queue Flusher, OGLSD_SetScratchSurface Message-ID: Hi, Bug: https://bugs.openjdk.java.net/browse/JDK-8057830 On OS X, CGLGraphicsConfigInfo is destroyed by OGLGC_DestroyOGLGraphicsConfig, however the pointer to it still hangs around for a while and is not reset to NULL, until we get rid of it with a Disposer later on. In the meantime it appears to be possible that OGLSD_SetScratchSurface is called with the already destroyed CGLGraphicsConfigInfo as argument. The CGLGraphicsConfigInfo is not NULL, but its structs are in a bad state, most likely freed, leading to the observed crash. The suggested change does not solve the problem, of needing to NULL the pointer to CGLGraphicsConfigInfo right where it's destroyed in OGLRenderQueue.c (not really possible IMO). However, it improves the destruction by NULLing some of it struct members and thus allowing us in OGLSD_SetScratchSurface to test those for NULL values. I also added a trace call for when this happens, to aiding potentially creating a better fix in the future. Unfortunately, I have not been able to come up with a reasonable unit test for this, therefore I cannot be certain that it solves the problem. However, as the changes are minimal and obviously harmless, I would very much appreciate it, if somebody decided to sponsor and commit this patch. I have a live application out there based on 8u20 and this is the number one reason for user-reported crashes. Webrev: https://www.beatunes.com/download/webrev_8057830.zip I did a full clean OS X build to test the change. Before and after I encountered the same 11 jdk_2d failures (which made me wonder whether that is normal...). Cheers, -hendrik PS: I'm new to contributing OpenJDK patches, let me know, if I should have done it some other way. Thanks. From Sergey.Bylokhov at oracle.com Mon Sep 22 09:48:56 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 22 Sep 2014 13:48:56 +0400 Subject: [OpenJDK 2D-Dev] Updated Review Request for JDK-8054877 In-Reply-To: <541C7F31.3090400@oracle.com> References: <541C7F31.3090400@oracle.com> Message-ID: <541FF088.9000100@oracle.com> Hello. Just a small issue. The dot at the end of "@throws ClassNotFoundException" is not necessary. On 19.09.2014 23:08, Phil Race wrote: > Looks good now > > -phil. > > On 9/18/2014 7:58 PM, Anisha Nagarajan wrote: >> Hi, >> >> Here is the updated werbev for JDK-8054877: >> http://cr.openjdk.java.net/~ssides/8054877/8054877.3/ >> >> >> Thanks, >> Anisha > -- Best regards, Sergey. From andrew.brygin at oracle.com Tue Sep 23 07:51:24 2014 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Tue, 23 Sep 2014 11:51:24 +0400 Subject: [OpenJDK 2D-Dev] RFR: JDK-8017773: OpenJDK7 returns incorrect TrueType font metrics In-Reply-To: <541CDF60.90608@gmail.com> References: <52EF333C.2030208@lab.ntt.co.jp> <52FC767A.8070805@lab.ntt.co.jp> <53263B9E.1040606@lab.ntt.co.jp> <533D6C6D.7010006@gmail.com> <5345A992.3040005@oracle.com> <53468EAD.6060805@gmail.com> <535E5EE9.7010503@gmail.com> <541C81DC.3020702@oracle.com> <541CDF60.90608@gmail.com> Message-ID: <5421267C.6060507@oracle.com> Hello Yasumasa, the fix looks ok to me. Thanks, Andrew On 9/20/2014 5:58 AM, Yasumasa Suenaga wrote: > Hi Phil, > > I changed subject of this email thread. > webrev of this issue is here: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8017773/webrev.00/ > > I'm just an author of jdk9, not a committer. > So could you be a sponsor of this issue? > > > Yasumasa > > > On 2014/09/20 4:19, Phil Race wrote: >> Hi, >> >> It does seem like it may have been wrong to adjust the height of the >> overall font metrics because of >> a widened outline .. although there is likely to be less visible line >> gap and more chance of clipping, >> nonetheless I think this looks OK.. If we see such problems we can >> re-consider. >> >> - Please get a "+1" from some one else too .. >> - Please push it to 9-client, not 9-dev. ie >> http://hg.openjdk.java.net/jdk9/client/jdk >> >> .. and thanks for the off-list ping on this. >> >> -phil. >> >> On 4/28/2014 7:00 AM, Yasumasa Suenaga wrote: >>> Hi Phili, >>> >>> I've created patch for this issue and uploaded webrev: >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8017773/webrev.00/ >>> >>> >>> Could you help me? >>> >>> Yasumasa >>> >>> >>> On 04/10/2014 09:29 PM, Yasumasa Suenaga wrote: >>>> Hi Phili, >>>> Thank you for replying. >>>> >>>>> I don't know the details of what is on the end of the various links you >>>>> provide and >>>>> I can't go grabbing code from somewhere else. >>>> You can get patches as following: >>>> http://icedtea.classpath.org/bugzilla/attachment.cgi?id=873&action=diff >>>> http://icedtea.classpath.org/bugzilla/attachment.cgi?id=1014&action=diff >>>> >>>> >>>>> So step #1 would be for you to provide a patch I can consider under >>>>> terms of the >>>>> OCA against hg.openjdk.java/net/jdk9/client/jdk .. >>>> I've agreed the OCA, and I'm an author of jdk9 project. >>>> http://openjdk.java.net/census#ysuenaga >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 04/10/2014 05:12 AM, Phil Race wrote: >>>>> All bugs should be fixed first in the main development release and back >>>>> ported if appropriate. >>>>> And in any case any targeting you see is purely what the manager-types >>>>> are doing >>>>> because of current rules that say a bug needs to be targeted to a release. >>>>> It doesn't actually mean a thing here as I currently have no time to >>>>> even consider this bug. >>>>> I agree with the general premise that bold fonts should only be wider, >>>>> not taller but >>>>> I don't know the details of what is on the end of the various links you >>>>> provide and >>>>> I can't go grabbing code from somewhere else. >>>>> >>>>> So step #1 would be for you to provide a patch I can consider under >>>>> terms of the >>>>> OCA against hg.openjdk.java/net/jdk9/client/jdk .. >>>>> >>>>> -phil. >>>>> >>>>> >>>>> On 4/3/2014 7:13 AM, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> Have you checked this issue? >>>>>> >>>>>> This issue will be fixed in JDK9. >>>>>> However, I want fix it in JDK7 and JDK8. >>>>>> >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2014/03/17 9:02, Yasumasa Suenaga wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> The "Fix version" of this issue has been changed into 9 from 8-pool. >>>>>>> Will this issue not be fixed in JDK7/8 ? >>>>>>> >>>>>>> I think this issue is bug of OpenJDK implementation. >>>>>>> So this issue should be fixed ASAP. >>>>>>> >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> On 2014/02/13 16:38, Yasumasa Suenaga wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I've reported about JDK-8017773 . Have you checked it ? >>>>>>>> >>>>>>>> I guess that many Linux distributor will ship OpenJDK8 after JDK8 GA is released. >>>>>>>> If this issue will not fix at JDK8 GA, many users who use 2D on JDK8 may encounter it. >>>>>>>> >>>>>>>> This issue occurs in OpenJDK only. >>>>>>>> However, I think there are many users who want to use 2D on OpenJDK. >>>>>>>> So I hope to fix this issue ASAP and hope to backport to JDK7. >>>>>>>> >>>>>>>> >>>>>>>> Please cooperate. >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2014/02/03 15:12, Yasumasa Suenaga wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> My customer encountered this issue. >>>>>>>>> I think this issue is caused by Bug 1435 [1] and 1659 [2] in IcedTea. >>>>>>>>> >>>>>>>>> I read source code of "freetype-2.5.0-4.fc20" . >>>>>>>>> Bold style should affect Font Glyph only. However, current implementation >>>>>>>>> of OpenJDK affects Font Face. Thus value of Ascent/Descent is incorrect. >>>>>>>>> >>>>>>>>> OracleJDK seems to use sun.font.T2KFontScaler to calculate these values. >>>>>>>>> So this issue occurs in OpenJDK only. >>>>>>>>> >>>>>>>>> >>>>>>>>> I think we need to merge patches of Bug 1435 and 1659 in IcedTea >>>>>>>>> to fix JDK-8017773 . >>>>>>>>> >>>>>>>>> Could you merge these patches ? >>>>>>>>> Please cooperate. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> [1] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1435 >>>>>>>>> [2] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1659 >>>>>>>>> >>>>>>>>> >>>>>>>>> ------ D E T A I L S ------ >>>>>>>>> >>>>>>>>> I've created testcase as "JavaApplication1.java" . >>>>>>>>> Result as: >>>>>>>>> >>>>>>>>> OracleJDK 6 Update 31 >>>>>>>>> ---------------- >>>>>>>>> [root at RHEL6-5 font]# /usr/local/jdk1.6.0_31/bin/java JavaApplication1 >>>>>>>>> JDK: 1.6.0_31 >>>>>>>>> VM: Java HotSpot(TM) 64-Bit Server VM >>>>>>>>> >>>>>>>>> java.awt.Font[family=IPAMincho,name=IPAMincho,style=plain,size=50] >>>>>>>>> Ascent: 43.99414 >>>>>>>>> Descent: 6.0058594 >>>>>>>>> >>>>>>>>> java.awt.Font[family=IPAMincho,name=IPAMincho,style=bold,size=50] >>>>>>>>> Ascent: 43.99414 >>>>>>>>> Descent: 6.0058594 >>>>>>>>> ---------------- >>>>>>>>> >>>>>>>>> OpenJDK7 (in RHEL6.5) >>>>>>>>> ---------------- >>>>>>>>> [root at RHEL6-5 font]# java JavaApplication1 >>>>>>>>> JDK: 1.7.0_45 >>>>>>>>> VM: OpenJDK 64-Bit Server VM >>>>>>>>> >>>>>>>>> java.awt.Font[family=IPAMincho,name=IPAMincho,style=plain,size=50] >>>>>>>>> Ascent: 43.99414 >>>>>>>>> Descent: 6.0058594 >>>>>>>>> >>>>>>>>> java.awt.Font[family=IPAMincho,name=IPAMincho,style=bold,size=50] >>>>>>>>> Ascent: 45.60547 >>>>>>>>> Descent: 4.3945312 >>>>>>>>> ---------------- From yasuenag at gmail.com Tue Sep 23 08:53:58 2014 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 23 Sep 2014 17:53:58 +0900 Subject: [OpenJDK 2D-Dev] RFR: JDK-8017773: OpenJDK7 returns incorrect TrueType font metrics In-Reply-To: <5421267C.6060507@oracle.com> References: <52EF333C.2030208@lab.ntt.co.jp> <52FC767A.8070805@lab.ntt.co.jp> <53263B9E.1040606@lab.ntt.co.jp> <533D6C6D.7010006@gmail.com> <5345A992.3040005@oracle.com> <53468EAD.6060805@gmail.com> <535E5EE9.7010503@gmail.com> <541C81DC.3020702@oracle.com> <541CDF60.90608@gmail.com> <5421267C.6060507@oracle.com> Message-ID: <54213526.2040304@gmail.com> Thanks Phil, Andrew ! Phil, could you push it ? Yasumasa On 2014/09/23 16:51, Andrew Brygin wrote: > Hello Yasumasa, > > the fix looks ok to me. > > Thanks, > Andrew > > On 9/20/2014 5:58 AM, Yasumasa Suenaga wrote: >> Hi Phil, >> >> I changed subject of this email thread. >> webrev of this issue is here: >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8017773/webrev.00/ >> >> I'm just an author of jdk9, not a committer. >> So could you be a sponsor of this issue? >> >> >> Yasumasa >> >> >> On 2014/09/20 4:19, Phil Race wrote: >>> Hi, >>> >>> It does seem like it may have been wrong to adjust the height of the >>> overall font metrics because of >>> a widened outline .. although there is likely to be less visible line >>> gap and more chance of clipping, >>> nonetheless I think this looks OK.. If we see such problems we can >>> re-consider. >>> >>> - Please get a "+1" from some one else too .. >>> - Please push it to 9-client, not 9-dev. ie >>> http://hg.openjdk.java.net/jdk9/client/jdk >>> >>> .. and thanks for the off-list ping on this. >>> >>> -phil. >>> >>> On 4/28/2014 7:00 AM, Yasumasa Suenaga wrote: >>>> Hi Phili, >>>> >>>> I've created patch for this issue and uploaded webrev: >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8017773/webrev.00/ >>>> >>>> >>>> Could you help me? >>>> >>>> Yasumasa >>>> >>>> >>>> On 04/10/2014 09:29 PM, Yasumasa Suenaga wrote: >>>>> Hi Phili, >>>>> Thank you for replying. >>>>> >>>>>> I don't know the details of what is on the end of the various links you >>>>>> provide and >>>>>> I can't go grabbing code from somewhere else. >>>>> You can get patches as following: >>>>> http://icedtea.classpath.org/bugzilla/attachment.cgi?id=873&action=diff >>>>> http://icedtea.classpath.org/bugzilla/attachment.cgi?id=1014&action=diff >>>>> >>>>> >>>>>> So step #1 would be for you to provide a patch I can consider under >>>>>> terms of the >>>>>> OCA against hg.openjdk.java/net/jdk9/client/jdk .. >>>>> I've agreed the OCA, and I'm an author of jdk9 project. >>>>> http://openjdk.java.net/census#ysuenaga >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 04/10/2014 05:12 AM, Phil Race wrote: >>>>>> All bugs should be fixed first in the main development release and back >>>>>> ported if appropriate. >>>>>> And in any case any targeting you see is purely what the manager-types >>>>>> are doing >>>>>> because of current rules that say a bug needs to be targeted to a release. >>>>>> It doesn't actually mean a thing here as I currently have no time to >>>>>> even consider this bug. >>>>>> I agree with the general premise that bold fonts should only be wider, >>>>>> not taller but >>>>>> I don't know the details of what is on the end of the various links you >>>>>> provide and >>>>>> I can't go grabbing code from somewhere else. >>>>>> >>>>>> So step #1 would be for you to provide a patch I can consider under >>>>>> terms of the >>>>>> OCA against hg.openjdk.java/net/jdk9/client/jdk .. >>>>>> >>>>>> -phil. >>>>>> >>>>>> >>>>>> On 4/3/2014 7:13 AM, Yasumasa Suenaga wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Have you checked this issue? >>>>>>> >>>>>>> This issue will be fixed in JDK9. >>>>>>> However, I want fix it in JDK7 and JDK8. >>>>>>> >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2014/03/17 9:02, Yasumasa Suenaga wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> The "Fix version" of this issue has been changed into 9 from 8-pool. >>>>>>>> Will this issue not be fixed in JDK7/8 ? >>>>>>>> >>>>>>>> I think this issue is bug of OpenJDK implementation. >>>>>>>> So this issue should be fixed ASAP. >>>>>>>> >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> On 2014/02/13 16:38, Yasumasa Suenaga wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I've reported about JDK-8017773 . Have you checked it ? >>>>>>>>> >>>>>>>>> I guess that many Linux distributor will ship OpenJDK8 after JDK8 GA is released. >>>>>>>>> If this issue will not fix at JDK8 GA, many users who use 2D on JDK8 may encounter it. >>>>>>>>> >>>>>>>>> This issue occurs in OpenJDK only. >>>>>>>>> However, I think there are many users who want to use 2D on OpenJDK. >>>>>>>>> So I hope to fix this issue ASAP and hope to backport to JDK7. >>>>>>>>> >>>>>>>>> >>>>>>>>> Please cooperate. >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2014/02/03 15:12, Yasumasa Suenaga wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> My customer encountered this issue. >>>>>>>>>> I think this issue is caused by Bug 1435 [1] and 1659 [2] in IcedTea. >>>>>>>>>> >>>>>>>>>> I read source code of "freetype-2.5.0-4.fc20" . >>>>>>>>>> Bold style should affect Font Glyph only. However, current implementation >>>>>>>>>> of OpenJDK affects Font Face. Thus value of Ascent/Descent is incorrect. >>>>>>>>>> >>>>>>>>>> OracleJDK seems to use sun.font.T2KFontScaler to calculate these values. >>>>>>>>>> So this issue occurs in OpenJDK only. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I think we need to merge patches of Bug 1435 and 1659 in IcedTea >>>>>>>>>> to fix JDK-8017773 . >>>>>>>>>> >>>>>>>>>> Could you merge these patches ? >>>>>>>>>> Please cooperate. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> [1] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1435 >>>>>>>>>> [2] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1659 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ------ D E T A I L S ------ >>>>>>>>>> >>>>>>>>>> I've created testcase as "JavaApplication1.java" . >>>>>>>>>> Result as: >>>>>>>>>> >>>>>>>>>> OracleJDK 6 Update 31 >>>>>>>>>> ---------------- >>>>>>>>>> [root at RHEL6-5 font]# /usr/local/jdk1.6.0_31/bin/java JavaApplication1 >>>>>>>>>> JDK: 1.6.0_31 >>>>>>>>>> VM: Java HotSpot(TM) 64-Bit Server VM >>>>>>>>>> >>>>>>>>>> java.awt.Font[family=IPAMincho,name=IPAMincho,style=plain,size=50] >>>>>>>>>> Ascent: 43.99414 >>>>>>>>>> Descent: 6.0058594 >>>>>>>>>> >>>>>>>>>> java.awt.Font[family=IPAMincho,name=IPAMincho,style=bold,size=50] >>>>>>>>>> Ascent: 43.99414 >>>>>>>>>> Descent: 6.0058594 >>>>>>>>>> ---------------- >>>>>>>>>> >>>>>>>>>> OpenJDK7 (in RHEL6.5) >>>>>>>>>> ---------------- >>>>>>>>>> [root at RHEL6-5 font]# java JavaApplication1 >>>>>>>>>> JDK: 1.7.0_45 >>>>>>>>>> VM: OpenJDK 64-Bit Server VM >>>>>>>>>> >>>>>>>>>> java.awt.Font[family=IPAMincho,name=IPAMincho,style=plain,size=50] >>>>>>>>>> Ascent: 43.99414 >>>>>>>>>> Descent: 6.0058594 >>>>>>>>>> >>>>>>>>>> java.awt.Font[family=IPAMincho,name=IPAMincho,style=bold,size=50] >>>>>>>>>> Ascent: 45.60547 >>>>>>>>>> Descent: 4.3945312 >>>>>>>>>> ---------------- > From Sergey.Bylokhov at oracle.com Tue Sep 23 15:40:46 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 23 Sep 2014 19:40:46 +0400 Subject: [OpenJDK 2D-Dev] Review request for first part of 8049757 In-Reply-To: References: Message-ID: <5421947E.2020701@oracle.com> Hi, Clemens. The fix looks fine to me. On 03.08.2014 21:34, Clemens Eisserer wrote: > Hello, > > Please review my changes for the first patch of a series to come to > cleanup the Xrender Java2D pipeline. > > http://cr.openjdk.java.net/~ceisserer/8049757/webrev.00/ > > This patch removes support for the Jules rasterizer backend, which > relied on a modified version of the native Cairo library. > It has never really left experimental state, and with ongoing work to > improve pisces performance (I really hope Marlin will make it into > OpenJDK9 - https://github.com/bourgesl/marlin-renderer ) and way > better 2D drivers than 2008/2009 removing this code reduces the > codebase of the Xrender pipeline quite a bit (~ 1000 lines removed in > total). > > Thank you in advance, Clemens -- Best regards, Sergey. From philip.race at oracle.com Tue Sep 23 16:40:42 2014 From: philip.race at oracle.com (Phil Race) Date: Tue, 23 Sep 2014 09:40:42 -0700 Subject: [OpenJDK 2D-Dev] Review request for first part of 8049757 In-Reply-To: <5421947E.2020701@oracle.com> References: <5421947E.2020701@oracle.com> Message-ID: <5421A28A.1040306@oracle.com> Ditto. Sorry I completely missed this review request before .. -phil. On 9/23/2014 8:40 AM, Sergey Bylokhov wrote: > Hi, Clemens. > The fix looks fine to me. > > On 03.08.2014 21:34, Clemens Eisserer wrote: >> Hello, >> >> Please review my changes for the first patch of a series to come to >> cleanup the Xrender Java2D pipeline. >> >> http://cr.openjdk.java.net/~ceisserer/8049757/webrev.00/ >> >> This patch removes support for the Jules rasterizer backend, which >> relied on a modified version of the native Cairo library. >> It has never really left experimental state, and with ongoing work to >> improve pisces performance (I really hope Marlin will make it into >> OpenJDK9 - https://github.com/bourgesl/marlin-renderer ) and way >> better 2D drivers than 2008/2009 removing this code reduces the >> codebase of the Xrender pipeline quite a bit (~ 1000 lines removed in >> total). >> >> Thank you in advance, Clemens > > From philip.race at oracle.com Tue Sep 23 17:11:22 2014 From: philip.race at oracle.com (Phil Race) Date: Tue, 23 Sep 2014 10:11:22 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8017773: OpenJDK7 returns incorrect TrueType font metrics In-Reply-To: <54213526.2040304@gmail.com> References: <52EF333C.2030208@lab.ntt.co.jp> <52FC767A.8070805@lab.ntt.co.jp> <53263B9E.1040606@lab.ntt.co.jp> <533D6C6D.7010006@gmail.com> <5345A992.3040005@oracle.com> <53468EAD.6060805@gmail.com> <535E5EE9.7010503@gmail.com> <541C81DC.3020702@oracle.com> <541CDF60.90608@gmail.com> <5421267C.6060507@oracle.com> <54213526.2040304@gmail.com> Message-ID: <5421A9BA.9060101@oracle.com> OK .. I will push it -phil. On 9/23/2014 1:53 AM, Yasumasa Suenaga wrote: > Thanks Phil, Andrew ! > > Phil, could you push it ? > > > Yasumasa > > > On 2014/09/23 16:51, Andrew Brygin wrote: >> Hello Yasumasa, >> >> the fix looks ok to me. >> >> Thanks, >> Andrew >> >> On 9/20/2014 5:58 AM, Yasumasa Suenaga wrote: >>> Hi Phil, >>> >>> I changed subject of this email thread. >>> webrev of this issue is here: >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8017773/webrev.00/ >>> >>> I'm just an author of jdk9, not a committer. >>> So could you be a sponsor of this issue? >>> >>> >>> Yasumasa >>> >>> >>> On 2014/09/20 4:19, Phil Race wrote: >>>> Hi, >>>> >>>> It does seem like it may have been wrong to adjust the height of the >>>> overall font metrics because of >>>> a widened outline .. although there is likely to be less visible line >>>> gap and more chance of clipping, >>>> nonetheless I think this looks OK.. If we see such problems we can >>>> re-consider. >>>> >>>> - Please get a "+1" from some one else too .. >>>> - Please push it to 9-client, not 9-dev. ie >>>> http://hg.openjdk.java.net/jdk9/client/jdk >>>> >>>> .. and thanks for the off-list ping on this. >>>> >>>> -phil. >>>> >>>> On 4/28/2014 7:00 AM, Yasumasa Suenaga wrote: >>>>> Hi Phili, >>>>> >>>>> I've created patch for this issue and uploaded webrev: >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8017773/webrev.00/ >>>>> >>>>> >>>>> Could you help me? >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 04/10/2014 09:29 PM, Yasumasa Suenaga wrote: >>>>>> Hi Phili, >>>>>> Thank you for replying. >>>>>> >>>>>>> I don't know the details of what is on the end of the various links you >>>>>>> provide and >>>>>>> I can't go grabbing code from somewhere else. >>>>>> You can get patches as following: >>>>>> http://icedtea.classpath.org/bugzilla/attachment.cgi?id=873&action=diff >>>>>> http://icedtea.classpath.org/bugzilla/attachment.cgi?id=1014&action=diff >>>>>> >>>>>> >>>>>>> So step #1 would be for you to provide a patch I can consider under >>>>>>> terms of the >>>>>>> OCA against hg.openjdk.java/net/jdk9/client/jdk .. >>>>>> I've agreed the OCA, and I'm an author of jdk9 project. >>>>>> http://openjdk.java.net/census#ysuenaga >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 04/10/2014 05:12 AM, Phil Race wrote: >>>>>>> All bugs should be fixed first in the main development release and back >>>>>>> ported if appropriate. >>>>>>> And in any case any targeting you see is purely what the manager-types >>>>>>> are doing >>>>>>> because of current rules that say a bug needs to be targeted to a release. >>>>>>> It doesn't actually mean a thing here as I currently have no time to >>>>>>> even consider this bug. >>>>>>> I agree with the general premise that bold fonts should only be wider, >>>>>>> not taller but >>>>>>> I don't know the details of what is on the end of the various links you >>>>>>> provide and >>>>>>> I can't go grabbing code from somewhere else. >>>>>>> >>>>>>> So step #1 would be for you to provide a patch I can consider under >>>>>>> terms of the >>>>>>> OCA against hg.openjdk.java/net/jdk9/client/jdk .. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> >>>>>>> On 4/3/2014 7:13 AM, Yasumasa Suenaga wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Have you checked this issue? >>>>>>>> >>>>>>>> This issue will be fixed in JDK9. >>>>>>>> However, I want fix it in JDK7 and JDK8. >>>>>>>> >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2014/03/17 9:02, Yasumasa Suenaga wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> The "Fix version" of this issue has been changed into 9 from 8-pool. >>>>>>>>> Will this issue not be fixed in JDK7/8 ? >>>>>>>>> >>>>>>>>> I think this issue is bug of OpenJDK implementation. >>>>>>>>> So this issue should be fixed ASAP. >>>>>>>>> >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> On 2014/02/13 16:38, Yasumasa Suenaga wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I've reported about JDK-8017773 . Have you checked it ? >>>>>>>>>> >>>>>>>>>> I guess that many Linux distributor will ship OpenJDK8 after JDK8 GA is released. >>>>>>>>>> If this issue will not fix at JDK8 GA, many users who use 2D on JDK8 may encounter it. >>>>>>>>>> >>>>>>>>>> This issue occurs in OpenJDK only. >>>>>>>>>> However, I think there are many users who want to use 2D on OpenJDK. >>>>>>>>>> So I hope to fix this issue ASAP and hope to backport to JDK7. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Please cooperate. >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2014/02/03 15:12, Yasumasa Suenaga wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> My customer encountered this issue. >>>>>>>>>>> I think this issue is caused by Bug 1435 [1] and 1659 [2] in IcedTea. >>>>>>>>>>> >>>>>>>>>>> I read source code of "freetype-2.5.0-4.fc20" . >>>>>>>>>>> Bold style should affect Font Glyph only. However, current implementation >>>>>>>>>>> of OpenJDK affects Font Face. Thus value of Ascent/Descent is incorrect. >>>>>>>>>>> >>>>>>>>>>> OracleJDK seems to use sun.font.T2KFontScaler to calculate these values. >>>>>>>>>>> So this issue occurs in OpenJDK only. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I think we need to merge patches of Bug 1435 and 1659 in IcedTea >>>>>>>>>>> to fix JDK-8017773 . >>>>>>>>>>> >>>>>>>>>>> Could you merge these patches ? >>>>>>>>>>> Please cooperate. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> [1] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1435 >>>>>>>>>>> [2] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1659 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ------ D E T A I L S ------ >>>>>>>>>>> >>>>>>>>>>> I've created testcase as "JavaApplication1.java" . >>>>>>>>>>> Result as: >>>>>>>>>>> >>>>>>>>>>> OracleJDK 6 Update 31 >>>>>>>>>>> ---------------- >>>>>>>>>>> [root at RHEL6-5 font]# /usr/local/jdk1.6.0_31/bin/java JavaApplication1 >>>>>>>>>>> JDK: 1.6.0_31 >>>>>>>>>>> VM: Java HotSpot(TM) 64-Bit Server VM >>>>>>>>>>> >>>>>>>>>>> java.awt.Font[family=IPAMincho,name=IPAMincho,style=plain,size=50] >>>>>>>>>>> Ascent: 43.99414 >>>>>>>>>>> Descent: 6.0058594 >>>>>>>>>>> >>>>>>>>>>> java.awt.Font[family=IPAMincho,name=IPAMincho,style=bold,size=50] >>>>>>>>>>> Ascent: 43.99414 >>>>>>>>>>> Descent: 6.0058594 >>>>>>>>>>> ---------------- >>>>>>>>>>> >>>>>>>>>>> OpenJDK7 (in RHEL6.5) >>>>>>>>>>> ---------------- >>>>>>>>>>> [root at RHEL6-5 font]# java JavaApplication1 >>>>>>>>>>> JDK: 1.7.0_45 >>>>>>>>>>> VM: OpenJDK 64-Bit Server VM >>>>>>>>>>> >>>>>>>>>>> java.awt.Font[family=IPAMincho,name=IPAMincho,style=plain,size=50] >>>>>>>>>>> Ascent: 43.99414 >>>>>>>>>>> Descent: 6.0058594 >>>>>>>>>>> >>>>>>>>>>> java.awt.Font[family=IPAMincho,name=IPAMincho,style=bold,size=50] >>>>>>>>>>> Ascent: 45.60547 >>>>>>>>>>> Descent: 4.3945312 >>>>>>>>>>> ---------------- From Sergey.Bylokhov at oracle.com Thu Sep 25 09:37:30 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 25 Sep 2014 13:37:30 +0400 Subject: [OpenJDK 2D-Dev] Request for Approval: 8015376 - Remove jnlp and applet files from the JDK samples In-Reply-To: <5423584D.60502@oracle.com> References: <5423584D.60502@oracle.com> Message-ID: <5423E25A.3090204@oracle.com> Hi, Daniil. Does it mean that these demos will be removed? Where this change were reviewed? On 25.09.2014 3:48, daniil titov wrote: > Please approve the changes that remove applets from JDK samples. 8u40 > changes were already integrated in the team forest. They were reviewed > by the team members at time of integration. JDK 9 changes are ready > for integration as well. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8015376 > JDK 8u40 webrev: http://cr.openjdk.java.net/~dtitov/8015376/webrev.00 > > JDK 9 webrev: http://cr.openjdk.java.net/~dtitov/8015376.9/webrev.00 > > > Thanks, > Daniil -- Best regards, Sergey. From hs at tagtraum.com Thu Sep 25 11:40:17 2014 From: hs at tagtraum.com (Hendrik Schreiber) Date: Thu, 25 Sep 2014 13:40:17 +0200 Subject: [OpenJDK 2D-Dev] JDK-8038998: buttons/checkboxes/menus etc have disapearing text or fail to repaint properly Message-ID: Hey, I have a customer experiencing https://bugs.openjdk.java.net/browse/JDK-8038998 (buttons/checkboxes/menus etc have disapearing text or fail to repaint properly), which unfortunately was closed. Ketan Shah documented that more information was requested, but fails to state what information was requested. I would love to ask my customer to provide whatever info is necessary, so that the bug is re-openend and eventually resolved. Could someone please let me know, what kind of info would be helpful? Thank you, -hendrik From andrew.brygin at oracle.com Thu Sep 25 12:07:28 2014 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Thu, 25 Sep 2014 16:07:28 +0400 Subject: [OpenJDK 2D-Dev] JDK-8038998: buttons/checkboxes/menus etc have disapearing text or fail to repaint properly In-Reply-To: References: Message-ID: <54240580.3020900@oracle.com> Hello Hendrik, the bug report mentions that the problem is reproducible on 1.8.0-b132. Is the problem reproducible with 8u20? Also, according to comments in the bug, it looks like D3D pipeline was activated on Intel video board: [I] Description : Intel(R) HD Graphics 4000 [I] D3DContext::ConfigureContext: successfully created device: 0 Does the option -Dsun.java2d.d3d=false help in that case? Thanks, Andrew On 9/25/2014 3:40 PM, Hendrik Schreiber wrote: > Hey, > > I have a customer experiencing https://bugs.openjdk.java.net/browse/JDK-8038998 (buttons/checkboxes/menus etc have disapearing text or fail to repaint properly), which unfortunately was closed. > > Ketan Shah documented that more information was requested, but fails to state what information was requested. > > I would love to ask my customer to provide whatever info is necessary, so that the bug is re-openend and eventually resolved. > > Could someone please let me know, what kind of info would be helpful? > > Thank you, > > -hendrik From hs at tagtraum.com Thu Sep 25 13:16:51 2014 From: hs at tagtraum.com (Hendrik Schreiber) Date: Thu, 25 Sep 2014 15:16:51 +0200 Subject: [OpenJDK 2D-Dev] JDK-8038998: buttons/checkboxes/menus etc have disapearing text or fail to repaint properly In-Reply-To: <54240580.3020900@oracle.com> References: <54240580.3020900@oracle.com> Message-ID: On Sep 25, 2014, at 14:07, Andrew Brygin wrote: > the bug report mentions that the problem is reproducible on 1.8.0-b132. > Is the problem reproducible with 8u20? The customer runs 8u20. I have asked him to collect the j2d trace output and run the testcase code. > Also, according to comments in the bug, it looks like D3D pipeline > was activated on Intel video board: > [I] Description : Intel(R) HD Graphics 4000 > [I] D3DContext::ConfigureContext: successfully created device: 0 > > Does the option -Dsun.java2d.d3d=false help in that case? I will ask him to try this and post results as soon as I have them. Thanks, Andrew. -hendrik From philip.race at oracle.com Thu Sep 25 16:46:01 2014 From: philip.race at oracle.com (Phil Race) Date: Thu, 25 Sep 2014 09:46:01 -0700 Subject: [OpenJDK 2D-Dev] Request for Approval: 8015376 - Remove jnlp and applet files from the JDK samples In-Reply-To: <5423E25A.3090204@oracle.com> References: <5423584D.60502@oracle.com> <5423E25A.3090204@oracle.com> Message-ID: <542446C9.5010801@oracle.com> The applet demos are a *standard* part of our integration testing to make sure basic functionality works. So not a good idea to remove these. I veto this change. -phil. On 9/25/2014 2:37 AM, Sergey Bylokhov wrote: > Hi, Daniil. > Does it mean that these demos will be removed? Where this change were > reviewed? > > On 25.09.2014 3:48, daniil titov wrote: >> Please approve the changes that remove applets from JDK samples. 8u40 >> changes were already integrated in the team forest. They were >> reviewed by the team members at time of integration. JDK 9 changes >> are ready for integration as well. >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8015376 >> JDK 8u40 webrev: http://cr.openjdk.java.net/~dtitov/8015376/webrev.00 >> >> JDK 9 webrev: http://cr.openjdk.java.net/~dtitov/8015376.9/webrev.00 >> >> >> Thanks, >> Daniil > > From philip.race at oracle.com Thu Sep 25 16:49:02 2014 From: philip.race at oracle.com (Phil Race) Date: Thu, 25 Sep 2014 09:49:02 -0700 Subject: [OpenJDK 2D-Dev] Request for Approval: 8015376 - Remove jnlp and applet files from the JDK samples In-Reply-To: <542446C9.5010801@oracle.com> References: <5423584D.60502@oracle.com> <5423E25A.3090204@oracle.com> <542446C9.5010801@oracle.com> Message-ID: <5424477E.6050901@oracle.com> Note that if this is just removing them from the *redistributed* samples.zip file I am not concerned. But I need clarification that when I do 'make demos' and 'make all' I still end up with these applets in the resulting tree and jdk images .. -phil. On 9/25/2014 9:46 AM, Phil Race wrote: > The applet demos are a *standard* part of our integration testing to > make sure > basic functionality works. So not a good idea to remove these. I veto > this change. > > -phil. > > On 9/25/2014 2:37 AM, Sergey Bylokhov wrote: >> Hi, Daniil. >> Does it mean that these demos will be removed? Where this change were >> reviewed? >> >> On 25.09.2014 3:48, daniil titov wrote: >>> Please approve the changes that remove applets from JDK samples. >>> 8u40 changes were already integrated in the team forest. They were >>> reviewed by the team members at time of integration. JDK 9 changes >>> are ready for integration as well. >>> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8015376 >>> JDK 8u40 webrev: >>> http://cr.openjdk.java.net/~dtitov/8015376/webrev.00 >>> >>> JDK 9 webrev: http://cr.openjdk.java.net/~dtitov/8015376.9/webrev.00 >>> >>> >>> Thanks, >>> Daniil >> >> > From philip.race at oracle.com Thu Sep 25 17:06:41 2014 From: philip.race at oracle.com (Phil Race) Date: Thu, 25 Sep 2014 10:06:41 -0700 Subject: [OpenJDK 2D-Dev] Request for Approval: 8015376 - Remove jnlp and applet files from the JDK samples In-Reply-To: <5424477E.6050901@oracle.com> References: <5423584D.60502@oracle.com> <5423E25A.3090204@oracle.com> <542446C9.5010801@oracle.com> <5424477E.6050901@oracle.com> Message-ID: <54244BA1.5090100@oracle.com> Although even then .. the redistribution must still contain the standalone versions of SwingSet2, Font2DTest and Java2Demo, even if the applet invocations of these is not provided. -phil. On 9/25/2014 9:49 AM, Phil Race wrote: > Note that if this is just removing them from the *redistributed* > samples.zip file I am not concerned. > But I need clarification that when I do 'make demos' and 'make all' I > still end up with these applets > in the resulting tree and jdk images .. > > -phil. > > On 9/25/2014 9:46 AM, Phil Race wrote: >> The applet demos are a *standard* part of our integration testing to >> make sure >> basic functionality works. So not a good idea to remove these. I veto >> this change. >> >> -phil. >> >> On 9/25/2014 2:37 AM, Sergey Bylokhov wrote: >>> Hi, Daniil. >>> Does it mean that these demos will be removed? Where this change >>> were reviewed? >>> >>> On 25.09.2014 3:48, daniil titov wrote: >>>> Please approve the changes that remove applets from JDK samples. >>>> 8u40 changes were already integrated in the team forest. They were >>>> reviewed by the team members at time of integration. JDK 9 changes >>>> are ready for integration as well. >>>> >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8015376 >>>> JDK 8u40 webrev: >>>> http://cr.openjdk.java.net/~dtitov/8015376/webrev.00 >>>> >>>> JDK 9 webrev: >>>> http://cr.openjdk.java.net/~dtitov/8015376.9/webrev.00 >>>> >>>> >>>> Thanks, >>>> Daniil >>> >>> >> > From daniil.x.titov at oracle.com Thu Sep 25 17:03:07 2014 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 25 Sep 2014 10:03:07 -0700 Subject: [OpenJDK 2D-Dev] Request for Approval: 8015376 - Remove jnlp and applet files from the JDK samples In-Reply-To: <5424477E.6050901@oracle.com> References: <5423584D.60502@oracle.com> <5423E25A.3090204@oracle.com> <542446C9.5010801@oracle.com> <5424477E.6050901@oracle.com> Message-ID: <54244ACB.5020806@oracle.com> Hi Phil and Sergey, We are reverting the changes from the team repository. The issue was already solved in the different way in https://bugs.openjdk.java.net/browse/JDK-8015376. An issue to revert changes is created at https://bugs.openjdk.java.net/browse/JDK-8059136 . Thanks, -Daniil On 9/25/2014 9:49 AM, Phil Race wrote: > Note that if this is just removing them from the *redistributed* > samples.zip file I am not concerned. > But I need clarification that when I do 'make demos' and 'make all' I > still end up with these applets > in the resulting tree and jdk images .. > > -phil. > > On 9/25/2014 9:46 AM, Phil Race wrote: >> The applet demos are a *standard* part of our integration testing to >> make sure >> basic functionality works. So not a good idea to remove these. I veto >> this change. >> >> -phil. >> >> On 9/25/2014 2:37 AM, Sergey Bylokhov wrote: >>> Hi, Daniil. >>> Does it mean that these demos will be removed? Where this change >>> were reviewed? >>> >>> On 25.09.2014 3:48, daniil titov wrote: >>>> Please approve the changes that remove applets from JDK samples. >>>> 8u40 changes were already integrated in the team forest. They were >>>> reviewed by the team members at time of integration. JDK 9 changes >>>> are ready for integration as well. >>>> >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8015376 >>>> JDK 8u40 webrev: >>>> http://cr.openjdk.java.net/~dtitov/8015376/webrev.00 >>>> >>>> JDK 9 webrev: >>>> http://cr.openjdk.java.net/~dtitov/8015376.9/webrev.00 >>>> >>>> >>>> Thanks, >>>> Daniil >>> >>> >> > From daniil.x.titov at oracle.com Thu Sep 25 17:39:42 2014 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 25 Sep 2014 10:39:42 -0700 Subject: [OpenJDK 2D-Dev] Request for Approval: 8015376 - Remove jnlp and applet files from the JDK samples In-Reply-To: <54244ACB.5020806@oracle.com> References: <5423584D.60502@oracle.com> <5423E25A.3090204@oracle.com> <542446C9.5010801@oracle.com> <5424477E.6050901@oracle.com> <54244ACB.5020806@oracle.com> Message-ID: <5424535E.3070401@oracle.com> Resending the last email with corrected link to https://bugs.openjdk.java.net/browse/JDK-8025917. --Daniil On 9/25/2014 10:03 AM, Daniil Titov wrote: > Hi Phil and Sergey, > > We are reverting the changes from the team repository. The issue was > already solved in the different way in > https://bugs.openjdk.java.net/browse/JDK-8025917. > An issue to revert changes is created at > https://bugs.openjdk.java.net/browse/JDK-8059136 . > > Thanks, > -Daniil > > > > > On 9/25/2014 9:49 AM, Phil Race wrote: >> Note that if this is just removing them from the *redistributed* >> samples.zip file I am not concerned. >> But I need clarification that when I do 'make demos' and 'make all' I >> still end up with these applets >> in the resulting tree and jdk images .. >> >> -phil. >> >> On 9/25/2014 9:46 AM, Phil Race wrote: >>> The applet demos are a *standard* part of our integration testing to >>> make sure >>> basic functionality works. So not a good idea to remove these. I >>> veto this change. >>> >>> -phil. >>> >>> On 9/25/2014 2:37 AM, Sergey Bylokhov wrote: >>>> Hi, Daniil. >>>> Does it mean that these demos will be removed? Where this change >>>> were reviewed? >>>> >>>> On 25.09.2014 3:48, daniil titov wrote: >>>>> Please approve the changes that remove applets from JDK samples. >>>>> 8u40 changes were already integrated in the team forest. They were >>>>> reviewed by the team members at time of integration. JDK 9 changes >>>>> are ready for integration as well. >>>>> >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8015376 >>>>> JDK 8u40 webrev: >>>>> http://cr.openjdk.java.net/~dtitov/8015376/webrev.00 >>>>> >>>>> JDK 9 webrev: >>>>> http://cr.openjdk.java.net/~dtitov/8015376.9/webrev.00 >>>>> >>>>> >>>>> Thanks, >>>>> Daniil >>>> >>>> >>> >> > From andrew.brygin at oracle.com Mon Sep 29 15:30:08 2014 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Mon, 29 Sep 2014 19:30:08 +0400 Subject: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON In-Reply-To: <9A5D5D1C-F58F-4DFC-B327-9A9DB18B155E@gmail.com> References: <53BD5E45.4000805@oracle.com> <9A5D5D1C-F58F-4DFC-B327-9A9DB18B155E@gmail.com> Message-ID: <54297B00.5020604@oracle.com> Hello Denis, I am not sure whether we should use 'apple.awt.graphics.UseQuartz' property. Probably we have to change the text antialiasing defaults for macosx instead. I am working on the issue with software loops. I will update the thread with my findings. Thanks, Andrew On 9/3/2014 3:32 PM, Denis Fokin wrote: > Hi Sergey and 2d team, > > I have rewritten the fix. It works fine for text rendered on window > using OpenGL. > > http://web-dot.ru/openjdk/8023794/webrev.00/index.html > > It is incomplete though. It does not work for rendering in a buffered > image. > > Additionally, I have not tested the code on other platforms except > MacOS X. > > To enable the antialiasing you should pass > > -Dapple.awt.graphics.UseQuartz=true > > to java. > > The current issue now is the glyph info bytes that are passed from > CGGlyphImage to AATextRenderer. > > To render data we use DEFINE_SOLID_DRAWGLYPHLIST* macros. Basing on > the macros a set of functions is generated for the next loops. > > sun/java2d/loops/ByteGray.c > sun/java2d/loops/ByteIndexed.c > sun/java2d/loops/FourByteAbgr.c > sun/java2d/loops/FourByteAbgrPre.c > sun/java2d/loops/Index12Gray.c > sun/java2d/loops/Index8Gray.c > sun/java2d/loops/IntArgb.c > sun/java2d/loops/IntArgbBm.c > sun/java2d/loops/IntArgbPre.c > sun/java2d/loops/IntBgr.c > sun/java2d/loops/IntRgb.c > sun/java2d/loops/IntRgbx.c > sun/java2d/loops/LoopMacros.h > sun/java2d/loops/ThreeByteBgr.c > sun/java2d/loops/Ushort555Rgb.c > sun/java2d/loops/Ushort555Rgbx.c > sun/java2d/loops/Ushort565Rgb.c > sun/java2d/loops/UshortGray.c > sun/java2d/loops/UshortIndexed.c > > For instance, C preprocessor generates the next code for IntRgb.c > > voidIntRgbDrawGlyphListLCD(/*?*/){ > jint glyphCounter, bpp; > jint scan = pRasInfo->scanStride; > IntRgbDataType *pPix; > fprintf(__stderrp, "NAME_SOLID_DRAWGLYPHLISTLC\n"); > jint srcA; > jint srcR , srcG, srcB;;;; > do { > (srcB) = (argbcolor) & 0xff; > (srcG) = ((argbcolor) >> 8) & 0xff; > (srcR) = ((argbcolor) >> 16) & 0xff; > (srcA) = ((argbcolor) >> 24) & 0xff; > } while (0);; > // and so on? > > Looks like rgb loop expects to see 4 8-bit color channels per pixel. > > For now, I do not understand which contract should be honoured to meet > DEFINE_SOLID_DRAWGLYPHLIST* expectations, i.e. how should I place > bytes in GlyphInfo. > > May be it should be set somewhere in Java code. > > Could anyone share this knowledge with me? > > Thank you, > Denis. > > > On 09 Jul 2014, at 19:22, Sergey Bylokhov > wrote: > >> Hello, Denis. >> Thanks for this research! >> On 09.07.2014 15:13, Denis Fokin wrote: >>> The current version consist of three parts. >>> >>> 1. We are rendering glyphs in offscreen images using Quartz >>> functions. This does not work without kCGBitmapByteOrder32Host mask. >> I assume LCD hint does not work? this looks good. >>> >>> 2. We assume that subpixel antialiasing should not be used on a >>> non-opaque surface. As I understand the vImage in >>> CGLVolatileSurfaceManager is not related directly to our window. For >>> a start, I have hardcoded Transparency.OPAQUE, but it requires much >>> better understanding of the architecture to make a more proper solution. >> It is related to the CGLOffScreenSurfaceData, which is used as a >> surface for VolatileImages. I check this code and looks like we >> ignore type of the ColorModel and create a transparent native texture >> anyway. >>> >>> 3. When I started using CGGI_CopyImageFromCanvasToRGBInfo as a >>> rendering mode, I had found that the little endian mode should be >>> undefined. Again, it might be an improper way to do this. >> It seems __LITTLE_ENDIAN__usage in this file should be checked. >>> >>> Thank you, >>> Denis. >>> >>> diff -r f87c5be90e01 >>> src/macosx/classes/sun/java2d/opengl/CGLVolatileSurfaceManager.java >>> >>> --- >>> a/src/macosx/classes/sun/java2d/opengl/CGLVolatileSurfaceManager.javaFri >>> Jun 20 10:15:30 2014 -0700 >>> >>> +++ >>> b/src/macosx/classes/sun/java2d/opengl/CGLVolatileSurfaceManager.javaWed >>> Jul 09 14:50:09 2014 +0400 >>> >>> @@ -108,7 +108,7 @@ >>> >>> } else { >>> >>> CGLGraphicsConfig gc = >>> >>> (CGLGraphicsConfig)vImg.getGraphicsConfig(); >>> >>> - ColorModel cm = >>> gc.getColorModel(vImg.getTransparency()); >>> >>> + ColorModel cm = gc.getColorModel(Transparency.OPAQUE); >>> >>> int type = vImg.getForcedAccelSurfaceType(); >>> >>> // if acceleration type is forced (type != >>> UNDEFINED) then >>> >>> // use the forced type, otherwise choose one based >>> on caps >>> >>> diff -r f87c5be90e01 src/macosx/native/sun/font/CGGlyphImages.m >>> >>> --- a/src/macosx/native/sun/font/CGGlyphImages.mFri Jun 20 10:15:30 >>> 2014 -0700 >>> >>> +++ b/src/macosx/native/sun/font/ .mWed Jul 09 14:50:09 2014 +0400 >>> >>> @@ -196,6 +196,8 @@ >>> >>> #pragma mark --- Font Rendering Mode Descriptors --- >>> >>> +#undef __LITTLE_ENDIAN__ >>> >>> + >>> >>> static inline void >>> >>> CGGI_CopyARGBPixelToRGBPixel(const UInt32 p, UInt8 *dst) >>> >>> { >>> >>> @@ -366,7 +368,8 @@ >>> >>> canvas->context = CGBitmapContextCreate(canvas->image->data, >>> >>> width, height, 8, bytesPerRow, >>> >>> colorSpace, >>> >>> - kCGImageAlphaPremultipliedFirst); >>> >>> + kCGImageAlphaPremultipliedFirst >>> >>> + | >>> kCGBitmapByteOrder32Host); >>> >>> CGContextSetRGBFillColor(canvas->context, 0.0f, 0.0f, 0.0f, 1.0f); >>> >>> CGContextSetFontSize(canvas->context, 1); >>> >> >> >> -- >> Best regards, Sergey. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From linuxhippy at gmail.com Tue Sep 30 09:58:48 2014 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Tue, 30 Sep 2014 11:58:48 +0200 Subject: [OpenJDK 2D-Dev] Review request for first part of 8049757 In-Reply-To: <54249B94.8000903@oracle.com> References: <5421A28A.1040306@oracle.com> <54249B94.8000903@oracle.com> Message-ID: Hi Phil, > Do you want me to commit this ? > We'd then need a new bug for the next chunk > of course .. Please. I'll provide a seperate patch for removing the unused methods you mentioned earlier. Thanks & best regards, Clemens