From james.graham at oracle.com Sat Nov 1 03:23:41 2014 From: james.graham at oracle.com (Jim Graham) Date: Fri, 31 Oct 2014 20:23:41 -0700 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8062164 Incorrect color conversion, when bicubic interpolation is used In-Reply-To: <5450FACB.3020207@oracle.com> References: <544E6B86.8060002@oracle.com> <544E8B20.9030805@oracle.com> <544F8C3F.1020907@oracle.com> <544FD255.40101@oracle.com> <544FE7D0.70300@oracle.com> <5450FACB.3020207@oracle.com> Message-ID: <5454523D.6070802@oracle.com> That looks good. Approved... ...jim On 10/29/2014 7:33 AM, Sergey Bylokhov wrote: > Hi, Jim. > The new version: > http://cr.openjdk.java.net/~serb/8062164/webrev.03 > On 28.10.2014 22:00, Jim Graham wrote: >> I wasn't aware that jtreg had a default timeout, but 2 minutes is rather long. It's one thing if you are waiting for a slow operation, but in this case I'm concerned about running on a machine that somehow faults its VolatileImages frequently, or somehow they just fail on creation. > I was under impression that in this case we should use VI implementation based on bufimg? >> That would mean that any test that uses this pattern takes 2 minutes to complete wherein it has looped several million times in a loop that is really only there for theoretical matters and should probably fail if it can't complete in a couple of iterations... > It is too optimistic. On my system it will be hundreds of iterations. >> >> ...jim >> >> On 10/28/14 10:28 AM, Phil Race wrote: >>> On 10/28/2014 5:29 AM, Sergey Bylokhov wrote: >>>> Hi, Jim. >>>> Thanks for review! >>>> >>>> On 27.10.2014 21:12, Jim Graham wrote: >>>>> In the test case you call new BufferedImage() with a Transparency >>>>> constant which is essentially a random number to determine the type >>>>> of BufferedImage since it is expecting its own values. You get lucky >>>>> with the value of the integer as it turns out, but the test case >>>>> really should be using the constants from BufferedImage in its own >>>>> constructor instead (too bad we didn't have typed enums back when >>>>> this was all happening). >>>> >>>> BufferedImage was incorrectly used, instead of CompatibleImage: >>>> http://cr.openjdk.java.net/~serb/8062164/webrev.02 >>> >>> That explains why you went to all the trouble to grab the data buffer. >>> >>> Looks good. >>> >>> -phil. >>> >>>>> >>>>> Also, a test case with an infinite loop should either have a timeout, >>>>> or a limit on "retries" in the loop - just in case we ever run the >>>>> test in an environment where VIs fail for some reason... >>>> >>>> I prefer to use default timeout, which is 2 minutes in jtreg. This >>>> timeout can be tweaked for slow machines for all tests at once. >>>>> >>>>> ...jim >>>>> >>>>> On 10/27/14 8:57 AM, Sergey Bylokhov wrote: >>>>>> Hello. >>>>>> Please review the fix for jdk 9. >>>>>> Type of the temporary buffer in DrawImage.renderImageXform() is >>>>>> incorrect. Note that we blit this buffer to the destination, using next >>>>>> maskblit/blit: >>>>>> >>>>>> line 463: maskblit = MaskBlit.getFromCache(SurfaceType.IntArgbPre, >>>>>> sg.imageComp, >>>>>> dstType); >>>>>> line 489: blit = Blit.getFromCache(SurfaceType.IntArgbPre, >>>>>> sg.imageComp, >>>>>> dstType); >>>>>> >>>>>> Type of source surface is IntArgbPre in both cases, but the type of >>>>>> tmpBuffer is IntArgb. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8062164 >>>>>> Webrev can be found at: >>>>>> http://cr.openjdk.java.net/~serb/8062164/webrev.01 >>>>>> >>>> >>>> >>> > > From denis.fokin at gmail.com Wed Nov 5 13:57:44 2014 From: denis.fokin at gmail.com (Denis S. Fokin) Date: Wed, 5 Nov 2014 16:57:44 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON In-Reply-To: <544A92CC.10406@oracle.com> References: <53BD5E45.4000805@oracle.com> <9A5D5D1C-F58F-4DFC-B327-9A9DB18B155E@gmail.com> <54297B00.5020604@oracle.com> <6B49FF00-8A8F-41DF-A574-B9537C1A2B94@gmail.com> <5437EE69.3090606@oracle.com> <54380F42.7060705@oracle.com> <54381FFC.5000507@oracle.com> <5438465D.5070503@oracle.com> <54384C03.5020006@oracle.com> <543ADF1B.9020802@oracle.com> <543BC85F.8050202@oracle.com> <543C62AC.2010907@oracle.com> <544A92CC.10406@oracle.com> Message-ID: <4C0A9BE6-EF50-4770-8F48-65943C362FB4@gmail.com> Hi Andrew, I have noticed an issue with quartz (at list with our way to use it). This is a simple project that allows to illustrate the issue with a pure Quartz and Cocoa. https://github.com/denis-fokin/OffscreenVsQuartzFontRendering Below you can see results. I used the same MBP with an external Thunderbolt display. Rendering of a glyph in the view and in the offscreen bitmap is the same for non-retina display. http://imgur.com/Y33C0tF,vnn5Ajt#0 In case of retina, it seems that the image uses improper number of pixels. http://imgur.com/Y33C0tF,vnn5Ajt#1 I see the same effect in the java-2d sub pixel rendering implementation. Right now I am not sure, how to handle this properly. Thank you, Denis. > On 24 Oct 2014, at 21:56, Andrew Brygin wrote: > > Hello, > > please take a look to updated version of the fix: > > http://cr.openjdk.java.net/~bae/8023794/9/webrev.03/ > > TODOs were removed: > * CGLSurfaceData.java > the condition for lcd rendering is inherited from OGL surface data, but > here we have to remove the check for the transparency, because we always > create transparent volatile images for swing backbuffers on macosx in order > to support shaped windows. > > * CGGlyphImages.m and AWTStrike.m > NSException is used to handle invalid (unevaluated) text antialising hint values. > We actually have already used NSException to handle memory allocation failure, > so this change just makes usage of get/release of primitive arrays a bit more safe. > > > Known differences comparing to apple jdk6: > > a) we do not interpret TEXT_ANTIALIASING_ON as lcd text. > > b) we do not render lcd text in a case of non-opaque paint. This behavior is common for > all cases (software loops, OGL, and D3D), so it seems to deserve a separate bug if we > want to handle this case. > > Thanks, > Andrew > > On 10/14/2014 3:39 AM, Phil Race wrote: >> On 10/13/2014 05:41 AM, Andrew Brygin wrote: >>> Hello Phil, >>> >>> please see my comments inline. >>> >>> On 10/13/2014 12:05 AM, Phil Race wrote: >>>> 373 fontHints.put(RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON); >>>> 374 fontHints.put(RenderingHints.KEY_TEXT_ANTIALIASING, RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HBGR); >>>> >>>> >>>> I am not sure why we have the graphics AA hint "ON" set here. >>>> Its not truly a font hint even though if its set it implcitly triggers font AA to be on too. >>>> If you remove that first line do you notice any problems with Swing apps ? >>> I failed to spot any difference in the SwingSet2 demo after removal the line 373. >> >> Hmm .. Sergey seemed to suggest it was needed. >> I was concerned that it might subvert the text rendering hint >> as it used to cause us to do everything via the graphics AA loops. >> So I guess I am not sure what the impact of removing it will be >> You probably should check if it changes Metal & Nimbus rendering >> in SwingSet as it looks to be read by those but I don't see anywhere >> Aqua is reading these hints which is puzzling as you'd think that's >> where they were wanted. >> >>> >>>> >>>> >>>> The logic in the following code looks odd to me .. >>>> 310 static CGGI_GlyphInfoDescriptor grey = >>>> 311 { 1, &CGGI_CopyImageFromCanvasToAlphaInfo }; >>>> 312 static CGGI_GlyphInfoDescriptor rgb = >>>> 313 { 3, &CGGI_CopyImageFromCanvasToRGBInfo }; >>>> 314 >>>> 315 static inline CGGI_RenderingMode >>>> 316 CGGI_GetRenderingMode(const AWTStrike *strike) >>>> 317 { >>>> 318 CGGI_RenderingMode mode; >>>> 319 mode.cgFontMode = strike->fStyle; >>>> 320 >>>> 321 switch (strike->fAAStyle) { >>>> >>>> 322 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_OFF: >>>> 323 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_ON: >>>> >>>> >>>> 324 mode.glyphDescriptor = &grey; >>>> 325 break; >>>> 326 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_LCD_HRGB: >>>> 327 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_LCD_HBGR: >>>> 328 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_LCD_VRGB: >>>> 329 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_LCD_VBGR: >>>> 330 mode.glyphDescriptor = &rgb; >>>> 331 break; >>>> 332 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_GASP: >>>> 333 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_DEFAULT: >>>> 334 default: >>>> 335 // TODO: generate an error? >>>> 336 break; >>>> 337 } >>>> >>>> >>>> .. If we get to default does this mean aliased rendering ? >>>> If so why would "OFF" go the grey path - seems it should go default >>>> And "GASP" looks like there is no support to specify the intended meaning there >>>> Given that OS X text is unhinted I'd think "ON" is a better option here >>>> even though most fonts would do "OFF" at typical screen sizes .. but that's >>>> because they are expecting hinted rendering. So I think you need to get >>>> hinted glyphs to default this to aliased .. >>> >>> If my understanding is correct, we never get TEXT_ANTIALIAS_GASP and >>> TEXT_ANTIALIAS_DEFAULT here, because these hints must be already evaluated >>> and translated to either TEXT_ANTIALIAS_OFF, or TEXT_ANTIALIAS_ON. >>> It should be done in SunGraphisc2D.checkFontInfo(), lines 699 - 775. >> >> this is probably right so its OK .. >> >> -phil. >> >>> >>> At this point we have no enough info to evaluate these hints properly, >>> and a best solution is probably to raise an error. >>> >>> Thanks, >>> Andrew >>> >>>> >>>> -phil. >>>> >>>> >>>> On 10/10/14 2:13 PM, Andrew Brygin wrote: >>>>> Hello Phil, >>>>> >>>>> please see my comments inline. >>>>> >>>>> On 10/11/2014 12:49 AM, Phil Race wrote: >>>>>> On 10/10/14 11:05 AM, Andrew Brygin wrote: >>>>>>> Hello Phil, >>>>>>> >>>>>>> changes in SunGraphics2D and SurfaceData were made in order to >>>>>>> implement an approach 'LCD instead of greyscale AA if possible'. >>>>>>> >>>>>>> Without this part of change, we get results according to the hints: >>>>>>> greyscale for TEXT_ANTIALIAS_ON, and subpixels for lcd hints: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~bae/8023794/9/webrev.01/ >>>>>> >>>>>> So you are changing the meaning of application-specified "ON" across platforms ? >>>>>> That sounds wrong - even for Mac ... >>>>> >>>>> now I do not: the fix revision 01 does not change the meaning of the hints, >>>>> and just makes text rendering on macosx to behave in a similar manner as >>>>> on windows. >>>>> >>>>> Please take a look at the webrev.01. >>>>> >>>>> Thanks, >>>>> Andrew >>>>>> >>>>>>> >>>>>>> I am not sure whether do we need to change the 'default' >>>>>>> behavior: at the moment it produces aliased text. >>>>>> >>>>>> default has meant aliased in all the non-mac sun/oracle implementations >>>>>> since JDK 1.2. We have talked about changing it to something >>>>>> more modern but should not do it lightly .. >>>>>> >>>>>> -phil. >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Andrew >>>>>>> >>>>>>> On 10/10/2014 8:54 PM, Phil Race wrote: >>>>>>>> I don't have my head around all these changes but a lot of it seems to >>>>>>>> imply we really weren't asking for LCDon Mac when we could/should. >>>>>>>> >>>>>>>> The change in the shared SurfaceData.javais something I want to >>>>>>>> ask about as you have commented out as follows .. >>>>>>>> ; >>>>>>>> 749 >>>>>>>> 750 // TODO: we have to take into account aaHint on macosx >>>>>>>> 751 //case SunHints.INTVAL_TEXT_ANTIALIAS_ON: >>>>>>>> 752 // return aaTextRenderer; >>>>>>>> >>>>>>>> ... >>>>>>>> >>>>>>>> that looks like the case where the application code has *explicitly* >>>>>>>> specified greyscale (ON==greyscale) so I don't see why you need >>>>>>>> to go check the fontinfo in this case ? >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> On 10/10/2014 07:34 AM, Andrew Brygin wrote: >>>>>>>>> Hello Denis, >>>>>>>>> >>>>>>>>> could you please take a look at a preliminary version of the fix? >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~bae/8023794/9/webrev.00/ >>>>>>>>> >>>>>>>>> This fix promotes the text antialiasing from grayscale to LCD if >>>>>>>>> destination surface data is able to render LCD, and provides >>>>>>>>> selection of an appropriate text pipeline for both cases. >>>>>>>>> It also separates production of gatyscale and LCD glyph images. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Andrew >>>>>>>>> >>>>>>>>> On 10/9/2014 4:13 PM, Denis Fokin wrote: >>>>>>>>>> Hi Andrew, >>>>>>>>>> >>>>>>>>>> I am happy about you participation in this work! >>>>>>>>>> >>>>>>>>>> Looks like, I have missed this letter, while being sick. Sorry about this. >>>>>>>>>> >>>>>>>>>> I signed OCA, but I have not gotten access to cr.openjdk.java.net yet. This is the reason why I have not updated the webrev. >>>>>>>>>> >>>>>>>>>> I think that an API that is consistent with other platforms is a great solution. It just requires more efforts and multi-platform testing. On the other hand, a property could be a safe start. >>>>>>>>>> >>>>>>>>>> As for the offscreen rendering, I have some kind of a workaround with the next approach. >>>>>>>>>> >>>>>>>>>> In BufImgSurfaceData.getRenderLoops() I always return super.getRenderLoops(sg2d), and never solid loops. >>>>>>>>>> >>>>>>>>>> In case if ?useQuartz" flag is specified, I return only lcdTextRenderer from SurfaceData.getTextPipe() >>>>>>>>>> >>>>>>>>>> Of course it is a brute force approach, but it allows producing a legible text in case of offscreen rendering. >>>>>>>>>> >>>>>>>>>> Thank you, >>>>>>>>>> Denis. >>>>>>>>>> >>>>>>>>>> On 29 Sep 2014, at 19:30, Andrew Brygin > wrote: >>>>>>>>>> >>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> 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 Sergey.Bylokhov at oracle.com Wed Nov 5 19:17:22 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 05 Nov 2014 22:17:22 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8061832 J2DBench can be improved Message-ID: <545A77C2.2090303@oracle.com> Hello. Please review the fix for jdk 9. Change description: - Test groups were wrapped by JScrollPane - Translucent volatile images now can be used as source and destination - Additional source/destination were added(TYPE_4BYTE_**) - Main window will be created on EDT at the center of the screen - Support of the huge shapes were added(4000x4000) - Support of the interpolation was added, by default nearest neighbor is used - Two cmm tests depended on the default enum.toString() implementation, and was broken when usage of enums were removed. I reused abbreviation as a name of the test - "Image Rendering Tests" tab was renamed to "image rendering benchmark", because now it has an options as well - "Touch src image before every operation" was moved from the "image rendering source" tab to the "image rendering benchmarks" and placed in the same group as interpolation - The new image rendering test was added: drawimage(img, x, y, w*0.5, h*0.5, obs); will simplify testing of some blits on the retina display Bug: https://bugs.openjdk.java.net/browse/JDK-8061832 Webrev can be found at: http://cr.openjdk.java.net/~serb/8061832/webrev.02 -- Best regards, Sergey. From philip.race at oracle.com Thu Nov 6 18:48:00 2014 From: philip.race at oracle.com (Phil Race) Date: Thu, 06 Nov 2014 10:48:00 -0800 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8061832 J2DBench can be improved In-Reply-To: <545A77C2.2090303@oracle.com> References: <545A77C2.2090303@oracle.com> Message-ID: <545BC260.6030904@oracle.com> 82 if (ImageTests.hasVolatileImage) { 83 if(ImageTests.hasTransparentVolatileImage) { 84 volimgdestroot = new Group.EnableSet(destroot, "volimg", 85 "Output to Volatile Image"); 86 87 volimgdestroot.setHorizontal(); 88 new VolatileImg(); 89 new VolatileImg(Transparency.OPAQUE); 90 new VolatileImg(Transparency.BITMASK); 91 new VolatileImg(Transparency.TRANSLUCENT); 92 } else if (ImageTests.hasVolatileImage){ 93 volimgdestroot = new Group.EnableSet(destroot, "volimg", 94 "Output to Volatile Image"); 95 96 volimgdestroot.setHorizontal(); 97 new VolatileImg(); 98 } 99 } The test at line 93 is redundant .. it just needs to be an else { ..} since we are only in this block if it passed at line 82. Also line 83 has "if(" - should be "if (" Am I right in understanding that the huge 4000x4000 option is disabled by default ? I think disabling by default is the right thing for that. -phil On 11/5/2014 11:17 AM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk 9. > > Change description: > - Test groups were wrapped by JScrollPane > - Translucent volatile images now can be used as source and destination > - Additional source/destination were added(TYPE_4BYTE_**) > - Main window will be created on EDT at the center of the screen > - Support of the huge shapes were added(4000x4000) > - Support of the interpolation was added, by default nearest neighbor > is used > - Two cmm tests depended on the default enum.toString() > implementation, and was broken when usage of enums were removed. I > reused abbreviation as a name of the test > - "Image Rendering Tests" tab was renamed to "image rendering > benchmark", because now it has an options as well > - "Touch src image before every operation" was moved from the "image > rendering source" tab to the "image rendering benchmarks" and placed > in the same group as interpolation > - The new image rendering test was added: drawimage(img, x, y, w*0.5, > h*0.5, obs); will simplify testing of some blits on the retina display > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8061832 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8061832/webrev.02 > From philip.race at oracle.com Thu Nov 6 18:50:17 2014 From: philip.race at oracle.com (Phil Race) Date: Thu, 06 Nov 2014 10:50:17 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8062163: java/awt/geom/AffineTransform/TestInvertMethods.java test fails In-Reply-To: <54527FFA.3000809@oracle.com> References: <54527FFA.3000809@oracle.com> Message-ID: <545BC2E9.10200@oracle.com> Any takers ? -phil. On 10/30/2014 11:14 AM, Phil Race wrote: > https://bugs.openjdk.java.net/browse/JDK-8062163 > http://cr.openjdk.java.net/~prr/8062163/ > > Fixes a test that currently fails because of a JDK9 b33 change > in the implementation of Math.toRadians(double) > > -phil. From jennifer.godinez at oracle.com Thu Nov 6 18:50:17 2014 From: jennifer.godinez at oracle.com (Jennifer Godinez) Date: Thu, 06 Nov 2014 10:50:17 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8062163: java/awt/geom/AffineTransform/TestInvertMethods.java test fails In-Reply-To: <545BC2E9.10200@oracle.com> References: <54527FFA.3000809@oracle.com> <545BC2E9.10200@oracle.com> Message-ID: <545BC2E9.8090308@oracle.com> Looks good. Jennifer On 11/06/2014 10:50 AM, Phil Race wrote: > Any takers ? > > -phil. > > On 10/30/2014 11:14 AM, Phil Race wrote: >> https://bugs.openjdk.java.net/browse/JDK-8062163 >> http://cr.openjdk.java.net/~prr/8062163/ >> >> Fixes a test that currently fails because of a JDK9 b33 change >> in the implementation of Math.toRadians(double) >> >> -phil. > From denis.fokin at gmail.com Thu Nov 6 19:35:23 2014 From: denis.fokin at gmail.com (Denis S. Fokin) Date: Thu, 6 Nov 2014 22:35:23 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD Rendering hints seems not working without FRACTIONALMETRICS=ON In-Reply-To: <4C0A9BE6-EF50-4770-8F48-65943C362FB4@gmail.com> References: <53BD5E45.4000805@oracle.com> <9A5D5D1C-F58F-4DFC-B327-9A9DB18B155E@gmail.com> <54297B00.5020604@oracle.com> <6B49FF00-8A8F-41DF-A574-B9537C1A2B94@gmail.com> <5437EE69.3090606@oracle.com> <54380F42.7060705@oracle.com> <54381FFC.5000507@oracle.com> <5438465D.5070503@oracle.com> <54384C03.5020006@oracle.com> <543ADF1B.9020802@oracle.com> <543BC85F.8050202@oracle.com> <543C62AC.2010907@oracle.com> <544A92CC.10406@oracle.com> <4C0A9BE6-EF50-4770-8F48-65943C362FB4@gmail.com> Message-ID: <8B0E161B-50F7-40D2-9BF2-A031007F94E5@gmail.com> Hi Andrew, I have added an OpenGL view in the project just to illustrate that OpenGL provides exactly the same results. I also wrote a simple test the results are below http://i.imgur.com/cEt6HYo.png The letters are written with the same font and the same size From left to right 1. Panel Graphics 2. BufferedImage Graphics -> Panel Graphics 3. NSView 4. CGImageRef -> NSView 5. CGImageRef -> OpenGL 1,3,5 give the same results 2,4 are give the same results but a little bit brighter than 1,3,5 I would prefer more consistent results. But again I am not sure how to handle this. Might be we should use some kind of ?compatible context? and proper colorspace. Thank you, Denis. Looks like the same > On 05 Nov 2014, at 16:57, Denis S. Fokin wrote: > > Hi Andrew, > > I have noticed an issue with quartz (at list with our way to use it). > > This is a simple project that allows to illustrate the issue with a pure Quartz and Cocoa. > > https://github.com/denis-fokin/OffscreenVsQuartzFontRendering > > Below you can see results. > > I used the same MBP with an external Thunderbolt display. > > Rendering of a glyph in the view and in the offscreen bitmap is the same for non-retina display. > > http://imgur.com/Y33C0tF,vnn5Ajt#0 > > In case of retina, it seems that the image uses improper number of pixels. > > http://imgur.com/Y33C0tF,vnn5Ajt#1 > > I see the same effect in the java-2d sub pixel rendering implementation. > > Right now I am not sure, how to handle this properly. > > Thank you, > Denis. > > >> On 24 Oct 2014, at 21:56, Andrew Brygin > wrote: >> >> Hello, >> >> please take a look to updated version of the fix: >> >> http://cr.openjdk.java.net/~bae/8023794/9/webrev.03/ >> >> TODOs were removed: >> * CGLSurfaceData.java >> the condition for lcd rendering is inherited from OGL surface data, but >> here we have to remove the check for the transparency, because we always >> create transparent volatile images for swing backbuffers on macosx in order >> to support shaped windows. >> >> * CGGlyphImages.m and AWTStrike.m >> NSException is used to handle invalid (unevaluated) text antialising hint values. >> We actually have already used NSException to handle memory allocation failure, >> so this change just makes usage of get/release of primitive arrays a bit more safe. >> >> >> Known differences comparing to apple jdk6: >> >> a) we do not interpret TEXT_ANTIALIASING_ON as lcd text. >> >> b) we do not render lcd text in a case of non-opaque paint. This behavior is common for >> all cases (software loops, OGL, and D3D), so it seems to deserve a separate bug if we >> want to handle this case. >> >> Thanks, >> Andrew >> >> On 10/14/2014 3:39 AM, Phil Race wrote: >>> On 10/13/2014 05:41 AM, Andrew Brygin wrote: >>>> Hello Phil, >>>> >>>> please see my comments inline. >>>> >>>> On 10/13/2014 12:05 AM, Phil Race wrote: >>>>> 373 fontHints.put(RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON); >>>>> 374 fontHints.put(RenderingHints.KEY_TEXT_ANTIALIASING, RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HBGR); >>>>> >>>>> >>>>> I am not sure why we have the graphics AA hint "ON" set here. >>>>> Its not truly a font hint even though if its set it implcitly triggers font AA to be on too. >>>>> If you remove that first line do you notice any problems with Swing apps ? >>>> I failed to spot any difference in the SwingSet2 demo after removal the line 373. >>> >>> Hmm .. Sergey seemed to suggest it was needed. >>> I was concerned that it might subvert the text rendering hint >>> as it used to cause us to do everything via the graphics AA loops. >>> So I guess I am not sure what the impact of removing it will be >>> You probably should check if it changes Metal & Nimbus rendering >>> in SwingSet as it looks to be read by those but I don't see anywhere >>> Aqua is reading these hints which is puzzling as you'd think that's >>> where they were wanted. >>> >>>> >>>>> >>>>> >>>>> The logic in the following code looks odd to me .. >>>>> 310 static CGGI_GlyphInfoDescriptor grey = >>>>> 311 { 1, &CGGI_CopyImageFromCanvasToAlphaInfo }; >>>>> 312 static CGGI_GlyphInfoDescriptor rgb = >>>>> 313 { 3, &CGGI_CopyImageFromCanvasToRGBInfo }; >>>>> 314 >>>>> 315 static inline CGGI_RenderingMode >>>>> 316 CGGI_GetRenderingMode(const AWTStrike *strike) >>>>> 317 { >>>>> 318 CGGI_RenderingMode mode; >>>>> 319 mode.cgFontMode = strike->fStyle; >>>>> 320 >>>>> 321 switch (strike->fAAStyle) { >>>>> >>>>> 322 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_OFF: >>>>> 323 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_ON: >>>>> >>>>> >>>>> 324 mode.glyphDescriptor = &grey; >>>>> 325 break; >>>>> 326 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_LCD_HRGB: >>>>> 327 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_LCD_HBGR: >>>>> 328 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_LCD_VRGB: >>>>> 329 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_LCD_VBGR: >>>>> 330 mode.glyphDescriptor = &rgb; >>>>> 331 break; >>>>> 332 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_GASP: >>>>> 333 case sun_awt_SunHints_INTVAL_TEXT_ANTIALIAS_DEFAULT: >>>>> 334 default: >>>>> 335 // TODO: generate an error? >>>>> 336 break; >>>>> 337 } >>>>> >>>>> >>>>> .. If we get to default does this mean aliased rendering ? >>>>> If so why would "OFF" go the grey path - seems it should go default >>>>> And "GASP" looks like there is no support to specify the intended meaning there >>>>> Given that OS X text is unhinted I'd think "ON" is a better option here >>>>> even though most fonts would do "OFF" at typical screen sizes .. but that's >>>>> because they are expecting hinted rendering. So I think you need to get >>>>> hinted glyphs to default this to aliased .. >>>> >>>> If my understanding is correct, we never get TEXT_ANTIALIAS_GASP and >>>> TEXT_ANTIALIAS_DEFAULT here, because these hints must be already evaluated >>>> and translated to either TEXT_ANTIALIAS_OFF, or TEXT_ANTIALIAS_ON. >>>> It should be done in SunGraphisc2D.checkFontInfo(), lines 699 - 775. >>> >>> this is probably right so its OK .. >>> >>> -phil. >>> >>>> >>>> At this point we have no enough info to evaluate these hints properly, >>>> and a best solution is probably to raise an error. >>>> >>>> Thanks, >>>> Andrew >>>> >>>>> >>>>> -phil. >>>>> >>>>> >>>>> On 10/10/14 2:13 PM, Andrew Brygin wrote: >>>>>> Hello Phil, >>>>>> >>>>>> please see my comments inline. >>>>>> >>>>>> On 10/11/2014 12:49 AM, Phil Race wrote: >>>>>>> On 10/10/14 11:05 AM, Andrew Brygin wrote: >>>>>>>> Hello Phil, >>>>>>>> >>>>>>>> changes in SunGraphics2D and SurfaceData were made in order to >>>>>>>> implement an approach 'LCD instead of greyscale AA if possible'. >>>>>>>> >>>>>>>> Without this part of change, we get results according to the hints: >>>>>>>> greyscale for TEXT_ANTIALIAS_ON, and subpixels for lcd hints: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~bae/8023794/9/webrev.01/ >>>>>>> >>>>>>> So you are changing the meaning of application-specified "ON" across platforms ? >>>>>>> That sounds wrong - even for Mac ... >>>>>> >>>>>> now I do not: the fix revision 01 does not change the meaning of the hints, >>>>>> and just makes text rendering on macosx to behave in a similar manner as >>>>>> on windows. >>>>>> >>>>>> Please take a look at the webrev.01. >>>>>> >>>>>> Thanks, >>>>>> Andrew >>>>>>> >>>>>>>> >>>>>>>> I am not sure whether do we need to change the 'default' >>>>>>>> behavior: at the moment it produces aliased text. >>>>>>> >>>>>>> default has meant aliased in all the non-mac sun/oracle implementations >>>>>>> since JDK 1.2. We have talked about changing it to something >>>>>>> more modern but should not do it lightly .. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Andrew >>>>>>>> >>>>>>>> On 10/10/2014 8:54 PM, Phil Race wrote: >>>>>>>>> I don't have my head around all these changes but a lot of it seems to >>>>>>>>> imply we really weren't asking for LCDon Mac when we could/should. >>>>>>>>> >>>>>>>>> The change in the shared SurfaceData.javais something I want to >>>>>>>>> ask about as you have commented out as follows .. >>>>>>>>> ; >>>>>>>>> 749 >>>>>>>>> 750 // TODO: we have to take into account aaHint on macosx >>>>>>>>> 751 //case SunHints.INTVAL_TEXT_ANTIALIAS_ON: >>>>>>>>> 752 // return aaTextRenderer; >>>>>>>>> >>>>>>>>> ... >>>>>>>>> >>>>>>>>> that looks like the case where the application code has *explicitly* >>>>>>>>> specified greyscale (ON==greyscale) so I don't see why you need >>>>>>>>> to go check the fontinfo in this case ? >>>>>>>>> >>>>>>>>> -phil. >>>>>>>>> >>>>>>>>> On 10/10/2014 07:34 AM, Andrew Brygin wrote: >>>>>>>>>> Hello Denis, >>>>>>>>>> >>>>>>>>>> could you please take a look at a preliminary version of the fix? >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~bae/8023794/9/webrev.00/ >>>>>>>>>> >>>>>>>>>> This fix promotes the text antialiasing from grayscale to LCD if >>>>>>>>>> destination surface data is able to render LCD, and provides >>>>>>>>>> selection of an appropriate text pipeline for both cases. >>>>>>>>>> It also separates production of gatyscale and LCD glyph images. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Andrew >>>>>>>>>> >>>>>>>>>> On 10/9/2014 4:13 PM, Denis Fokin wrote: >>>>>>>>>>> Hi Andrew, >>>>>>>>>>> >>>>>>>>>>> I am happy about you participation in this work! >>>>>>>>>>> >>>>>>>>>>> Looks like, I have missed this letter, while being sick. Sorry about this. >>>>>>>>>>> >>>>>>>>>>> I signed OCA, but I have not gotten access to cr.openjdk.java.net yet. This is the reason why I have not updated the webrev. >>>>>>>>>>> >>>>>>>>>>> I think that an API that is consistent with other platforms is a great solution. It just requires more efforts and multi-platform testing. On the other hand, a property could be a safe start. >>>>>>>>>>> >>>>>>>>>>> As for the offscreen rendering, I have some kind of a workaround with the next approach. >>>>>>>>>>> >>>>>>>>>>> In BufImgSurfaceData.getRenderLoops() I always return super.getRenderLoops(sg2d), and never solid loops. >>>>>>>>>>> >>>>>>>>>>> In case if ?useQuartz" flag is specified, I return only lcdTextRenderer from SurfaceData.getTextPipe() >>>>>>>>>>> >>>>>>>>>>> Of course it is a brute force approach, but it allows producing a legible text in case of offscreen rendering. >>>>>>>>>>> >>>>>>>>>>> Thank you, >>>>>>>>>>> Denis. >>>>>>>>>>> >>>>>>>>>>> On 29 Sep 2014, at 19:30, Andrew Brygin > wrote: >>>>>>>>>>> >>>>>>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>>> 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 Sergey.Bylokhov at oracle.com Fri Nov 7 08:50:34 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 07 Nov 2014 11:50:34 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8061832 J2DBench can be improved In-Reply-To: <545BC260.6030904@oracle.com> References: <545A77C2.2090303@oracle.com> <545BC260.6030904@oracle.com> Message-ID: <545C87DA.1060406@oracle.com> Hi, Phil. The new version of the fix: http://cr.openjdk.java.net/~serb/8061832/webrev.03 On 06.11.2014 21:48, Phil Race wrote: > Am I right in understanding that the huge 4000x4000 option is disabled > by default ? > I think disabling by default is the right thing for that. Yes, you are right. By default 20x20 and 250x250 are enabled only. > > -phil > > On 11/5/2014 11:17 AM, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for jdk 9. >> >> Change description: >> - Test groups were wrapped by JScrollPane >> - Translucent volatile images now can be used as source and destination >> - Additional source/destination were added(TYPE_4BYTE_**) >> - Main window will be created on EDT at the center of the screen >> - Support of the huge shapes were added(4000x4000) >> - Support of the interpolation was added, by default nearest neighbor >> is used >> - Two cmm tests depended on the default enum.toString() >> implementation, and was broken when usage of enums were removed. I >> reused abbreviation as a name of the test >> - "Image Rendering Tests" tab was renamed to "image rendering >> benchmark", because now it has an options as well >> - "Touch src image before every operation" was moved from the "image >> rendering source" tab to the "image rendering benchmarks" and placed >> in the same group as interpolation >> - The new image rendering test was added: drawimage(img, x, y, w*0.5, >> h*0.5, obs); will simplify testing of some blits on the retina display >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8061832 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/8061832/webrev.02 >> > -- Best regards, Sergey. From neugens at redhat.com Fri Nov 7 16:36:07 2014 From: neugens at redhat.com (Mario Torre) Date: Fri, 07 Nov 2014 17:36:07 +0100 Subject: [OpenJDK 2D-Dev] Printing to Postscript doesn't support dieresis Message-ID: <1415378167.7443.1.camel@nirvana.localdomain> Hi all, I've been working on a strange issue recently, this seems to affect all recent version of OpenJDK as well as Oracle JDK. The issue appears to be related to this change: http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/fbe9320339ea The issue as I could find by debugging OpenJDK is a mix of a couple of things. This change was addressing postscript size explosion, where missing font descriptor in version prior to this fix were causing characters to be rendered as paths. The new code creates an actual descriptor array, so fonts can be rendered directly by postscript. However, it seems that the postscript code assumes ISO_8859_1 encoding, so if I pass some characters with, say, umlaut, like '?', instead of creating a patch the character is encoded as (which is correct ihmo) but then mapped to ISOLatin1Encoding. This is a snippet of the generated postscript file, the file is generated using a modified verion of the PrintSE.java test in OpenJDK: http://cr.openjdk.java.net/~neugens/psDieresisBug/PrintSEUmlauts.java /ISOF { dup findfont dup length 1 add dict begin { 1 index /FID eq {pop pop} {D} ifelse } forall /Encoding ISOLatin1Encoding D currentdict end definefont } BD /NZ {dup 1 lt {pop 1} if} BD /S { moveto 1 index stringwidth pop NZ sub 1 index length 1 sub NZ div 0 3 2 roll ashow newpath} BD 12.0 12 F 7.44 100.0 100.0 S pgSave restore I'm not really confident with Postscript at this level, so I would like some hints of where to look for an actual fix. I have a workaround that seems to work, something like: GlyphVector gv = font.createGlyphVector(frc, "?"); g2d.drawGlyphVector(gv, 250, 220); which basically forces the glyph path again. And of course I could revert the original change, but in either case it doesn't seem correct. My guess is that we should either somehow force ISO_8859_1 when calling CharsetString[] makeMultiCharsetString from PSPrinterJob, or have a proper fix for the Postscript file. Any idea of hint is very much appreciated. Cheers, Mario From philip.race at oracle.com Fri Nov 7 18:52:49 2014 From: philip.race at oracle.com (Phil Race) Date: Fri, 07 Nov 2014 10:52:49 -0800 Subject: [OpenJDK 2D-Dev] RFR: JDK-8039444: Swing applications not being displayed properly Message-ID: <545D1501.1080100@oracle.com> http://cr.openjdk.java.net/~prr/8039444/ Historically we enabled D3D only on Nvidia & ATI hardware. Intel chipsets are a large part of the market but we continually encountered rendering artifacts that apparently were driver or hardware level issues. For JDK 8 we did some testing on the newest (at the time) Intel HD chipsets that FX was using successfully and enabled it under this bug ID https://bugs.openjdk.java.net/browse/JDK-8000936 However we are exercising a different set of features than FX and people have reported issues already, and there is a concern that now that auto-update to JDK 8 is kicking in that we'll get more. I've started to label these bugs as follows :- https://bugs.openjdk.java.net/issues/?jql=labels%20%3D%20d3d-driver-intel At this time I propose to fix only in 8u40 so we can try again for JDK9 on (even) later chipsets .. -phil. From vadim.pakhnushev at oracle.com Fri Nov 7 19:57:55 2014 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 07 Nov 2014 22:57:55 +0300 Subject: [OpenJDK 2D-Dev] RFR: JDK-8039444: Swing applications not being displayed properly In-Reply-To: <545D1501.1080100@oracle.com> References: <545D1501.1080100@oracle.com> Message-ID: <545D2443.7040506@oracle.com> Looks good to me. On 07.11.2014 21:52, Phil Race wrote: > http://cr.openjdk.java.net/~prr/8039444/ > > Historically we enabled D3D only on Nvidia & ATI hardware. > Intel chipsets are a large part of the market but we continually > encountered > rendering artifacts that apparently were driver or hardware level issues. > > For JDK 8 we did some testing on the newest (at the time) Intel HD > chipsets > that FX was using successfully and enabled it under this bug ID > https://bugs.openjdk.java.net/browse/JDK-8000936 > > However we are exercising a different set of features than FX and people > have reported issues already, and there is a concern that now that > auto-update > to JDK 8 is kicking in that we'll get more. I've started to label > these bugs as follows :- > > https://bugs.openjdk.java.net/issues/?jql=labels%20%3D%20d3d-driver-intel > > At this time I propose to fix only in 8u40 so we can try again for > JDK9 on > (even) later chipsets .. > > -phil. > > > From Sergey.Bylokhov at oracle.com Fri Nov 7 20:51:18 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 07 Nov 2014 23:51:18 +0300 Subject: [OpenJDK 2D-Dev] RFR: JDK-8039444: Swing applications not being displayed properly In-Reply-To: <545D1501.1080100@oracle.com> References: <545D1501.1080100@oracle.com> Message-ID: <545D30C6.20100@oracle.com> Hi, Phil. Looks fine . On 07.11.2014 21:52, Phil Race wrote: > http://cr.openjdk.java.net/~prr/8039444/ > > Historically we enabled D3D only on Nvidia & ATI hardware. > Intel chipsets are a large part of the market but we continually > encountered > rendering artifacts that apparently were driver or hardware level issues. > > For JDK 8 we did some testing on the newest (at the time) Intel HD > chipsets > that FX was using successfully and enabled it under this bug ID > https://bugs.openjdk.java.net/browse/JDK-8000936 > > However we are exercising a different set of features than FX and people > have reported issues already, and there is a concern that now that > auto-update > to JDK 8 is kicking in that we'll get more. I've started to label > these bugs as follows :- > > https://bugs.openjdk.java.net/issues/?jql=labels%20%3D%20d3d-driver-intel > > At this time I propose to fix only in 8u40 so we can try again for > JDK9 on > (even) later chipsets .. > > -phil. > > > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Nov 10 20:03:27 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 10 Nov 2014 23:03:27 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8059942 Default implementation of DrawImage.renderImageXform() should be improved for d3d/ogl Message-ID: <54611A0F.6040206@oracle.com> Hello. Please review the fix for jdk 9: - If interaction of dst&clip is empty we return immediately, without creation of intermediate buffers - Size of intermediate buffers now take into account the clip, this is especially effective if the we have a big scale, which much bigger than destination - One regular blit is used instead of scanline by scanline copying. Note that I plan to improve generation of the clip region of this method later. Bug: https://bugs.openjdk.java.net/browse/JDK-8059942 Webrev can be found at: http://cr.openjdk.java.net/~serb/8059942/webrev.14 Benchmarks, note that the spread is a big(+-50% on each rerun) , because we generate a lot of garbage(non cached intermediate buffers): ======================================================================= Windows 7 x64, lenovo T410, nvidia NVS 3100M D3D: http://cr.openjdk.java.net/~serb/8059942/ogl_nvidia_win_fix14/results_d3d.txt Comparison to basis: Best result: 24719.07% of basis Worst result: 63.97% of basis Number of wins: 78 Number of ties: 52 Number of losses: 14 OGL: http://cr.openjdk.java.net/~serb/8059942/ogl_nvidia_win_fix14/results_ogl.txt Comparison to basis: Best result: 7797.69% of basis Worst result: 91.25% of basis Number of wins: 85 Number of ties: 47 Number of losses: 12 GDI: http://cr.openjdk.java.net/~serb/8059942/ogl_nvidia_win_fix14/results_gdi.txt Comparison to basis: Best result: 106.21% of basis Worst result: 81.05% of basis Number of wins: 32 Number of ties: 97 Number of losses: 15 ======================================================================= OSX 10.9.5, macbook pro retina, nvidia GeForce GT 650M 1024 MB http://cr.openjdk.java.net/~serb/8059942/ogl_nvidia_osx_fix14/results.txt Comparison to basis: Best result: 26838.34% of basis Worst result: 87.3% of basis Number of wins: 78 Number of ties: 62 Number of losses: 4 ======================================================================= OSX 10.9.5, macbook pro retina, Intel HD Graphics 4000 http://cr.openjdk.java.net/~serb/8059942/ogl_intel_osx_fix14/results.txt Comparison to basis: Best result: 20700.43% of basis Worst result: 96.94% of basis Number of wins: 85 Number of ties: 57 Number of losses: 2 -- Best regards, Sergey. From james.graham at oracle.com Mon Nov 10 20:38:17 2014 From: james.graham at oracle.com (Jim Graham) Date: Mon, 10 Nov 2014 12:38:17 -0800 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8059942 Default implementation of DrawImage.renderImageXform() should be improved for d3d/ogl In-Reply-To: <54611A0F.6040206@oracle.com> References: <54611A0F.6040206@oracle.com> Message-ID: <54612239.2040302@oracle.com> Hi Sergey, Please don't use "union" to build up a region. There are methods for building regions that are very efficient and the "union" operation is meant to be used for occasional operations on 2 already established regions, not for repeated iterative operations in building up a single region from scratch. Pass the list of spans to a method on Region and have it build the object up in a single pass like any of the existing getScaled, getTranslated, or getInstance(Shape) methods... ...jim On 11/10/14 12:03 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk 9: > - If interaction of dst&clip is empty we return immediately, without > creation of intermediate buffers > - Size of intermediate buffers now take into account the clip, this is > especially effective if the we have a big scale, which much bigger than > destination > - One regular blit is used instead of scanline by scanline copying. > Note that I plan to improve generation of the clip region of this method > later. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8059942 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8059942/webrev.14 > > Benchmarks, note that the spread is a big(+-50% on each rerun) , because > we generate a lot of garbage(non cached intermediate buffers): > ======================================================================= > Windows 7 x64, lenovo T410, nvidia NVS 3100M > > D3D: > http://cr.openjdk.java.net/~serb/8059942/ogl_nvidia_win_fix14/results_d3d.txt > > Comparison to basis: > Best result: 24719.07% of basis > Worst result: 63.97% of basis > Number of wins: 78 > Number of ties: 52 > Number of losses: 14 > > OGL: > http://cr.openjdk.java.net/~serb/8059942/ogl_nvidia_win_fix14/results_ogl.txt > > Comparison to basis: > Best result: 7797.69% of basis > Worst result: 91.25% of basis > Number of wins: 85 > Number of ties: 47 > Number of losses: 12 > > GDI: > http://cr.openjdk.java.net/~serb/8059942/ogl_nvidia_win_fix14/results_gdi.txt > > Comparison to basis: > Best result: 106.21% of basis > Worst result: 81.05% of basis > Number of wins: 32 > Number of ties: 97 > Number of losses: 15 > > ======================================================================= > OSX 10.9.5, macbook pro retina, nvidia GeForce GT 650M 1024 MB > http://cr.openjdk.java.net/~serb/8059942/ogl_nvidia_osx_fix14/results.txt > Comparison to basis: > Best result: 26838.34% of basis > Worst result: 87.3% of basis > Number of wins: 78 > Number of ties: 62 > Number of losses: 4 > > ======================================================================= > OSX 10.9.5, macbook pro retina, Intel HD Graphics 4000 > http://cr.openjdk.java.net/~serb/8059942/ogl_intel_osx_fix14/results.txt > Comparison to basis: > Best result: 20700.43% of basis > Worst result: 96.94% of basis > Number of wins: 85 > Number of ties: 57 > Number of losses: 2 > From james.graham at oracle.com Mon Nov 10 20:41:30 2014 From: james.graham at oracle.com (Jim Graham) Date: Mon, 10 Nov 2014 12:41:30 -0800 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8059942 Default implementation of DrawImage.renderImageXform() should be improved for d3d/ogl In-Reply-To: <54611A0F.6040206@oracle.com> References: <54611A0F.6040206@oracle.com> Message-ID: <546122FA.1090105@oracle.com> On 11/10/14 12:03 PM, Sergey Bylokhov wrote: > Note that I plan to improve generation of the clip region of this method > later. Ah, I missed this. It should be fairly easy to write a tight loop in Region to fill in a spans buffer. I'm not sure it needs to be pushed off. It would either be filed and forgotten thereby leaving a bad code template in our code for someone else to come along and copy from - or it would be fixed immediately and so I'm not sure why we don't just fix it with the initial bug...? ...jim From sergey.bylokhov at oracle.com Mon Nov 10 22:52:36 2014 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 10 Nov 2014 14:52:36 -0800 (PST) Subject: [OpenJDK 2D-Dev] [9] Review Request: 8059942 Default implementation of DrawImage.renderImageXform() should be improved for d3d/ogl Message-ID: <264b44f6-2d26-4ace-8a43-0cc719801195@default> Hi, Jim. To simply fill a span in the Region, I'll need to open Region.appendSpan() method, but I do not want to do it. So I need to create my own EdgesSpanIterator, or totally eliminate this loop and return Region object from the TransformHelper directly. Probably some logic can be moved from TransformHelper to the java level(atleast generation of edges array). Additionally it will be simpler to check a performance improvement, because now it is not so obvious comparing to the current percents improvement. ----- james.graham at oracle.com wrote: > On 11/10/14 12:03 PM, Sergey Bylokhov wrote: > > Note that I plan to improve generation of the clip region of this > method > > later. > > Ah, I missed this. It should be fairly easy to write a tight loop in > > Region to fill in a spans buffer. I'm not sure it needs to be pushed > > off. It would either be filed and forgotten thereby leaving a bad > code > template in our code for someone else to come along and copy from - or > > it would be fixed immediately and so I'm not sure why we don't just > fix > it with the initial bug...? > > ...jim From james.graham at oracle.com Tue Nov 11 02:43:33 2014 From: james.graham at oracle.com (Jim Graham) Date: Mon, 10 Nov 2014 18:43:33 -0800 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8059942 Default implementation of DrawImage.renderImageXform() should be improved for d3d/ogl In-Reply-To: <264b44f6-2d26-4ace-8a43-0cc719801195@default> References: <264b44f6-2d26-4ace-8a43-0cc719801195@default> Message-ID: <546177D5.3050602@oracle.com> On 11/10/14 2:52 PM, Sergey Bylokhov wrote: > Hi, Jim. > To simply fill a span in the Region, I'll need to open Region.appendSpan() method, > but I do not want to do it. No, that method should remain private. All region objects should be fully constructed at all times when in the hands of calling code. > So I need to create my own EdgesSpanIterator, or totally eliminate this loop and > return Region object from the TransformHelper directly. No, all you need is a method: /** * (describe edges array - 0,1 are y range, 2N,2N+1 are x ranges, 1 per y range) * (dxoff, dyoff are offsets that the edges array values are relative to) */ static Region getInstance(int dxoff, int dyoff, int edges[]) { // copy loop from DrawImage.java here, but use direct manipulation // of the spans array instead of union operations. // You should be able to pre-allocate the spans array as well to // save on growth using appendSpan() et al. } That should take only a few minutes to write, then DrawImage simply does: Region blitclip = Region.getInstance(dx1, dy1, edges); > Probably some logic can be moved from TransformHelper to the java level >(at least generation of edges array). Additionally it will be simpler to > check a performance improvement, because now it is not so obvious comparing > to the current percents improvement. Unfortunately the exact calculations to compute the edges array depend on a lot of calculations done at the native level. This would be a major repartitioning of the code... ...jim From Sergey.Bylokhov at oracle.com Thu Nov 13 16:35:39 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 13 Nov 2014 19:35:39 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8059942 Default implementation of DrawImage.renderImageXform() should be improved for d3d/ogl In-Reply-To: <546177D5.3050602@oracle.com> References: <264b44f6-2d26-4ace-8a43-0cc719801195@default> <546177D5.3050602@oracle.com> Message-ID: <5464DDDB.7040503@oracle.com> Hi, Jim. Please review an updated version of the fix: http://cr.openjdk.java.net/~serb/8059942/webrev.16 The new method in Region class was added. On 11.11.2014 5:43, Jim Graham wrote: > > > On 11/10/14 2:52 PM, Sergey Bylokhov wrote: >> Hi, Jim. >> To simply fill a span in the Region, I'll need to open >> Region.appendSpan() method, >> but I do not want to do it. > > No, that method should remain private. All region objects should be > fully constructed at all times when in the hands of calling code. > >> So I need to create my own EdgesSpanIterator, or totally eliminate > this loop and >> return Region object from the TransformHelper directly. > > No, all you need is a method: > > /** > * (describe edges array - 0,1 are y range, 2N,2N+1 are x ranges, 1 > per y range) > * (dxoff, dyoff are offsets that the edges array values are relative to) > */ > static Region getInstance(int dxoff, int dyoff, int edges[]) { > // copy loop from DrawImage.java here, but use direct manipulation > // of the spans array instead of union operations. > // You should be able to pre-allocate the spans array as well to > // save on growth using appendSpan() et al. > } > > That should take only a few minutes to write, then DrawImage simply does: > > Region blitclip = Region.getInstance(dx1, dy1, edges); > >> Probably some logic can be moved from TransformHelper to the java level >> (at least generation of edges array). Additionally it will be simpler to >> check a performance improvement, because now it is not so obvious > comparing >> to the current percents improvement. > > Unfortunately the exact calculations to compute the edges array depend > on a lot of calculations done at the native level. This would be a > major repartitioning of the code... > > ...jim -- Best regards, Sergey. From neugens at redhat.com Thu Nov 13 18:20:18 2014 From: neugens at redhat.com (Mario Torre) Date: Thu, 13 Nov 2014 19:20:18 +0100 Subject: [OpenJDK 2D-Dev] Printing to Postscript doesn't support dieresis In-Reply-To: <1415378167.7443.1.camel@nirvana.localdomain> References: <1415378167.7443.1.camel@nirvana.localdomain> Message-ID: <1415902818.3847.42.camel@nirvana.localdomain> On Fri, 2014-11-07 at 17:36 +0100, Mario Torre wrote: > Hi all, > > I've been working on a strange issue recently, this seems to affect all > recent version of OpenJDK as well as Oracle JDK. > > The issue appears to be related to this change: > > http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/fbe9320339ea > > The issue as I could find by debugging OpenJDK is a mix of a couple of > things. > > This change was addressing postscript size explosion, where missing font > descriptor in version prior to this fix were causing characters to be > rendered as paths. > > The new code creates an actual descriptor array, so fonts can be > rendered directly by postscript. However, it seems that the postscript > code assumes ISO_8859_1 encoding, so if I pass some characters with, > say, umlaut, like '?', instead of creating a patch the character is > encoded as (which is correct ihmo) but then mapped to > ISOLatin1Encoding. > > This is a snippet of the generated postscript file, the file is > generated using a modified verion of the PrintSE.java test in OpenJDK: > > http://cr.openjdk.java.net/~neugens/psDieresisBug/PrintSEUmlauts.java > > /ISOF { > dup findfont dup length 1 add dict begin { > 1 index /FID eq {pop pop} {D} ifelse > } forall /Encoding ISOLatin1Encoding D > currentdict end definefont > } BD > /NZ {dup 1 lt {pop 1} if} BD > /S { > moveto 1 index stringwidth pop NZ sub > 1 index length 1 sub NZ div 0 > 3 2 roll ashow newpath} BD > 12.0 12 F > 7.44 100.0 100.0 S > pgSave restore > > I'm not really confident with Postscript at this level, so I would like > some hints of where to look for an actual fix. > > I have a workaround that seems to work, something like: > > GlyphVector gv = font.createGlyphVector(frc, "?"); > g2d.drawGlyphVector(gv, 250, 220); > > which basically forces the glyph path again. And of course I could > revert the original change, but in either case it doesn't seem correct. > > My guess is that we should either somehow force ISO_8859_1 when calling > CharsetString[] makeMultiCharsetString from PSPrinterJob, or have a > proper fix for the Postscript file. > > Any idea of hint is very much appreciated. > > Cheers, > Mario > > Ping? Mario From james.graham at oracle.com Thu Nov 13 22:30:03 2014 From: james.graham at oracle.com (Jim Graham) Date: Thu, 13 Nov 2014 14:30:03 -0800 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8059942 Default implementation of DrawImage.renderImageXform() should be improved for d3d/ogl In-Reply-To: <5464DDDB.7040503@oracle.com> References: <264b44f6-2d26-4ace-8a43-0cc719801195@default> <546177D5.3050602@oracle.com> <5464DDDB.7040503@oracle.com> Message-ID: <546530EB.1000108@oracle.com> Hi Sergey, Please revert all "iff => if" changes in Region - those are not typos. "iff" is mathematical shorthand for "if and only if" and those changes modify the correctness of those comments. The new method looks good, I was thinking it would be better to hand-code the filling of the array, but it looks like appendSpan() does clipping so we can be sure that the data remains in range/valid. Hand-coding would require adding a bunch of code for clipping, though it might be faster still by avoiding all of the "are we on a new row?" testing in appendSpan/endRow(). Why does line 272 add "+1" for ?endIndex? Other places simply use "#rows * 5". Other places in the code use the "clipAdd" and "dimAdd" methods to avoid overflow. In this particular case we might have overflow for box[0-3]. On the other hand, since appendSpan() clips against the bounds we'd end up with a valid, though potentially incorrect, region as a result. Validity is essential to prevent disasters, and that should be covered here. Correctness adds to the reliability of this code, but we seem to draw the line at "trusting the correctness" of the output of the SpanIterator for instance. I think the current code is OK, but it might be worth a comment "While we guarantee that all spans in the returned Region will be inside the bounding box, any overflow in adding the values in the edges array to the lox, loy values may cause one of the resulting spans to be missing or incorrect (though it will never exceed the indicated bounding box even with overflow occuring)". ...jim On 11/13/14 8:35 AM, Sergey Bylokhov wrote: > Hi, Jim. > Please review an updated version of the fix: > http://cr.openjdk.java.net/~serb/8059942/webrev.16 > The new method in Region class was added. > > > On 11.11.2014 5:43, Jim Graham wrote: >> >> >> On 11/10/14 2:52 PM, Sergey Bylokhov wrote: >>> Hi, Jim. >>> To simply fill a span in the Region, I'll need to open >>> Region.appendSpan() method, >>> but I do not want to do it. >> >> No, that method should remain private. All region objects should be >> fully constructed at all times when in the hands of calling code. >> >>> So I need to create my own EdgesSpanIterator, or totally eliminate >> this loop and >>> return Region object from the TransformHelper directly. >> >> No, all you need is a method: >> >> /** >> * (describe edges array - 0,1 are y range, 2N,2N+1 are x ranges, 1 >> per y range) >> * (dxoff, dyoff are offsets that the edges array values are relative to) >> */ >> static Region getInstance(int dxoff, int dyoff, int edges[]) { >> // copy loop from DrawImage.java here, but use direct manipulation >> // of the spans array instead of union operations. >> // You should be able to pre-allocate the spans array as well to >> // save on growth using appendSpan() et al. >> } >> >> That should take only a few minutes to write, then DrawImage simply does: >> >> Region blitclip = Region.getInstance(dx1, dy1, edges); >> >>> Probably some logic can be moved from TransformHelper to the java level >>> (at least generation of edges array). Additionally it will be simpler to >>> check a performance improvement, because now it is not so obvious >> comparing >>> to the current percents improvement. >> >> Unfortunately the exact calculations to compute the edges array depend >> on a lot of calculations done at the native level. This would be a >> major repartitioning of the code... >> >> ...jim > > From sergey.bylokhov at oracle.com Thu Nov 13 22:56:54 2014 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 13 Nov 2014 14:56:54 -0800 (PST) Subject: [OpenJDK 2D-Dev] [9] Review Request: 8059942 Default implementation of DrawImage.renderImageXform() should be improved for d3d/ogl Message-ID: Hi, Jim > Please revert all "iff => if" changes in Region - those are not typos. ok > Hand-coding would require adding a bunch of code for clipping, though > it might be faster still by avoiding all of the "are we on a new row?" > testing in appendSpan/endRow(). Looks like we get a big drawimage performance improvement from the previous fix - 30%(which is 10000% for the current jdk code) So I will try to go deeper and eliminate the call to appendSpan()/endRow. > > Why does line 272 add "+1" for ?endIndex? Other places simply use > "#rows * 5". This is because of needSpace() implementation: private void needSpace(int num) { if (endIndex + num >= bands.length) { } If we have only one row then we need 5 bytes and num will be 5 => equal to the bands.length => unnecessary copyArray will occures. I suppose this is because endIndex should be a valid index in the bands array. > > Other places in the code use the "clipAdd" and "dimAdd" methods to > avoid > overflow. In this particular case we might have overflow for > box[0-3]. > On the other hand, since appendSpan() clips against the bounds we'd > resulting spans to be missing or incorrect (though it will never > exceed > the indicated bounding box even with overflow occuring)". I do not clip edges intentionally, because I trust the output of TransformHelper, which I assume should validate possible overflow. I'll update a javadoc. > > ...jim > > On 11/13/14 8:35 AM, Sergey Bylokhov wrote: > > Hi, Jim. > > Please review an updated version of the fix: > > http://cr.openjdk.java.net/~serb/8059942/webrev.16 > > The new method in Region class was added. > > > > > > On 11.11.2014 5:43, Jim Graham wrote: > >> > >> > >> On 11/10/14 2:52 PM, Sergey Bylokhov wrote: > >>> Hi, Jim. > >>> To simply fill a span in the Region, I'll need to open > >>> Region.appendSpan() method, > >>> but I do not want to do it. > >> > >> No, that method should remain private. All region objects should > be > >> fully constructed at all times when in the hands of calling code. > >> > >>> So I need to create my own EdgesSpanIterator, or totally > eliminate > >> this loop and > >>> return Region object from the TransformHelper directly. > >> > >> No, all you need is a method: > >> > >> /** > >> * (describe edges array - 0,1 are y range, 2N,2N+1 are x ranges, > 1 > >> per y range) > >> * (dxoff, dyoff are offsets that the edges array values are > relative to) > >> */ > >> static Region getInstance(int dxoff, int dyoff, int edges[]) { > >> // copy loop from DrawImage.java here, but use direct > manipulation > >> // of the spans array instead of union operations. > >> // You should be able to pre-allocate the spans array as well > to > >> // save on growth using appendSpan() et al. > >> } > >> > >> That should take only a few minutes to write, then DrawImage simply > does: > >> > >> Region blitclip = Region.getInstance(dx1, dy1, edges); > >> > >>> Probably some logic can be moved from TransformHelper to the java > level > >>> (at least generation of edges array). Additionally it will be > simpler to > >>> check a performance improvement, because now it is not so > obvious > >> comparing > >>> to the current percents improvement. > >> > >> Unfortunately the exact calculations to compute the edges array > depend > >> on a lot of calculations done at the native level. This would be > a > >> major repartitioning of the code... > >> > >> ...jim > > > > From james.graham at oracle.com Fri Nov 14 01:15:26 2014 From: james.graham at oracle.com (Jim Graham) Date: Thu, 13 Nov 2014 17:15:26 -0800 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8059942 Default implementation of DrawImage.renderImageXform() should be improved for d3d/ogl In-Reply-To: References: Message-ID: <546557AE.2010800@oracle.com> On 11/13/14 2:56 PM, Sergey Bylokhov wrote: > Hi, Jim > >> Please revert all "iff => if" changes in Region - those are not typos. > > ok > >> Hand-coding would require adding a bunch of code for clipping, though >> it might be faster still by avoiding all of the "are we on a new row?" >> testing in appendSpan/endRow(). > > Looks like we get a big drawimage performance improvement from the previous fix - 30%(which is 10000% for the current jdk code) So I will try to go deeper and eliminate the call to appendSpan()/endRow. > >> >> Why does line 272 add "+1" for ?endIndex? Other places simply use >> "#rows * 5". > > This is because of needSpace() implementation: > private void needSpace(int num) { > if (endIndex + num >= bands.length) { } > If we have only one row then we need 5 bytes and num will be 5 => equal to the bands.length => unnecessary copyArray will occures. > I suppose this is because endIndex should be a valid index in the bands array. That is probably a bug. That should probably be just ">" since I don't see anywhere where we ever place anything in that last entry. >> Other places in the code use the "clipAdd" and "dimAdd" methods to >> avoid >> overflow. In this particular case we might have overflow for >> box[0-3]. >> On the other hand, since appendSpan() clips against the bounds we'd > >> resulting spans to be missing or incorrect (though it will never >> exceed >> the indicated bounding box even with overflow occuring)". > > I do not clip edges intentionally, because I trust the output of TransformHelper, which I assume should validate possible overflow. I'll update a javadoc. Exactly, this falls more under the realm of "we're creating a new API and even though it is only currently used by TransformHelper and we know how that works, we should consider that this API might get re-used in the future in other cases". As I said, this code ensures that the Region is valid, it just might produce unexpected (i.e. incorrect) results if we ever overflow. TransformHelper is unlikely to ever produce values that are much outside of the 0- range since it only generates drawable-bounded coordinates so we should be very far from overflow, though what if someone creates a BufferedImage that is 1<<30 in dimensions (with the 64-bit VM and a lot of RAM)? ...jim From sergey.bylokhov at oracle.com Fri Nov 14 01:45:17 2014 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 13 Nov 2014 17:45:17 -0800 (PST) Subject: [OpenJDK 2D-Dev] [9] Review Request: 8059942 Default implementation of DrawImage.renderImageXform() should be improved for d3d/ogl Message-ID: <2f43940e-affe-46bc-b8cf-aebc5c6f93a0@default> > That is probably a bug. That should probably be just ">" since I > don't > see anywhere where we ever place anything in that last entry. I will double check this. > Exactly, this falls more under the realm of "we're creating a new API > and even though it is only currently used by TransformHelper and we > know how that works, we should consider that this API might get re-used in > the future in other cases". This is not a pure new API since it is not public and can be used by our pipe package only, I'll add warning about this in javadoc. Moreover this code have a big impact(hundreds percents) on the performance of drawing, I consider we should return region from the TransformHelper directly in the future(or we should change format of edges array to the bands array format). I do not see that we do a lot of calculations at the native level in the TransformHelper.calculateEdges() so it should be possible, I think.... From sergey.bylokhov at oracle.com Fri Nov 14 14:40:01 2014 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 14 Nov 2014 06:40:01 -0800 (PST) Subject: [OpenJDK 2D-Dev] [9] Review Request: 8059942 Default implementation of DrawImage.renderImageXform() should be improved for d3d/ogl Message-ID: <7bd36a26-5168-4e30-a393-d2c9c36bf4dd@default> Hi, Jim. Please review an updated version of the fix: http://cr.openjdk.java.net/~serb/8059942/webrev.17 Two notes: - one additional byte still is added to the bands, since I am still checking the code where we use endIndex-1/endIndex+1/endIndex++ or swap it with curYrow, etc. This isn't urgent. - "end < bands.length" was added to the loop for the reason of overall loop performance(+15%). ----- james.graham at oracle.com wrote: > On 11/13/14 2:56 PM, Sergey Bylokhov wrote: > > Hi, Jim > > > >> Please revert all "iff => if" changes in Region - those are not > typos. > > > > ok > > > >> Hand-coding would require adding a bunch of code for clipping, > though > >> it might be faster still by avoiding all of the "are we on a new > row?" > >> testing in appendSpan/endRow(). > > > > Looks like we get a big drawimage performance improvement from the > previous fix - 30%(which is 10000% for the current jdk code) So I will > try to go deeper and eliminate the call to appendSpan()/endRow. > > > >> > >> Why does line 272 add "+1" for ?endIndex? Other places simply use > >> "#rows * 5". > > > > This is because of needSpace() implementation: > > private void needSpace(int num) { > > if (endIndex + num >= bands.length) { } > > If we have only one row then we need 5 bytes and num will be 5 => > equal to the bands.length => unnecessary copyArray will occures. > > I suppose this is because endIndex should be a valid index in the > bands array. > > That is probably a bug. That should probably be just ">" since I > don't > see anywhere where we ever place anything in that last entry. > > >> Other places in the code use the "clipAdd" and "dimAdd" methods to > >> avoid > >> overflow. In this particular case we might have overflow for > >> box[0-3]. > >> On the other hand, since appendSpan() clips against the bounds > we'd > > > >> resulting spans to be missing or incorrect (though it will never > >> exceed > >> the indicated bounding box even with overflow occuring)". > > > > I do not clip edges intentionally, because I trust the output of > TransformHelper, which I assume should validate possible overflow. > I'll update a javadoc. > > Exactly, this falls more under the realm of "we're creating a new API > > and even though it is only currently used by TransformHelper and we > know > how that works, we should consider that this API might get re-used in > > the future in other cases". As I said, this code ensures that the > Region is valid, it just might produce unexpected (i.e. incorrect) > results if we ever overflow. TransformHelper is unlikely to ever > produce values that are much outside of the 0- range > > since it only generates drawable-bounded coordinates so we should be > very far from overflow, though what if someone creates a BufferedImage > > that is 1<<30 in dimensions (with the 64-bit VM and a lot of RAM)? > > ...jim From james.graham at oracle.com Fri Nov 14 22:25:31 2014 From: james.graham at oracle.com (Jim Graham) Date: Fri, 14 Nov 2014 14:25:31 -0800 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8059942 Default implementation of DrawImage.renderImageXform() should be improved for d3d/ogl In-Reply-To: <2f43940e-affe-46bc-b8cf-aebc5c6f93a0@default> References: <2f43940e-affe-46bc-b8cf-aebc5c6f93a0@default> Message-ID: <5466815B.3000707@oracle.com> On 11/13/14 5:45 PM, Sergey Bylokhov wrote: > Moreover this code have a big impact(hundreds percents) on the performance > of drawing, I consider we should return region from the TransformHelper > directly in the future(or we should change format of edges array to the > bands array format). I do not see that we do a lot of calculations at the > native level in the TransformHelper.calculateEdges() so it should be > possible, I think.... One thing to consider, though, is that this code is only used in some rare cases - either that we don't have a direct native loop for the TH native code to use directly, or that it is a custom composite. The gains from the elimination of the Java-to-native transitions per scanline also probably swamp any other tuning operation we can do here so I think we've reached the knee of the curve for tuning this operation already. I'd rather have the (albeit internal to the implementation) API for Region be reliable in the results it generates than to go out of our way to create external loopholes for constructing the objects for some gains in this "backup code". Note that if any given Src/Dst transform operation is critical to any application, it would be better to make sure that we have a native MaskBlit for that combination than to make this clipping code go any faster... ...jim From james.graham at oracle.com Fri Nov 14 22:50:03 2014 From: james.graham at oracle.com (Jim Graham) Date: Fri, 14 Nov 2014 14:50:03 -0800 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8059942 Default implementation of DrawImage.renderImageXform() should be improved for d3d/ogl In-Reply-To: <7bd36a26-5168-4e30-a393-d2c9c36bf4dd@default> References: <7bd36a26-5168-4e30-a393-d2c9c36bf4dd@default> Message-ID: <5466871B.3030808@oracle.com> Hi Sergey, On 11/14/14 6:40 AM, Sergey Bylokhov wrote: > Hi, Jim. > Please review an updated version of the fix: > http://cr.openjdk.java.net/~serb/8059942/webrev.17 > Two notes: > - one additional byte still is added to the bands, since I am still checking the code where we use endIndex-1/endIndex+1/endIndex++ or swap it with curYrow, etc. This isn't urgent. Since you no longer call appendSpan(), you no longer need the additional byte in this new method. > - "end < bands.length" was added to the loop for the reason of overall loop performance(+15%). That's odd that it helps since you then consume 5 entries after that check, but I guess Hotspot works in mysterious ways. I wonder if "end+4" works as well or better since that would be a more accurate test of what is happening. Also, even for 15% performance difference of this one method, it might be better to take the AAIOBE as a double check against the caller feeding us bad data, such as edges[0,1] that end up overflowing? In either case, we generate valid data even in the face of such anomalies. I'd still prefer to have the code confirm the ranges. It would still be much simpler than the old code that called appendSpan/endRow a lot with just a few checks, like this: static Region getInstance(final int lox, final int loy, final int hix, final int hiy, final int edges[]) { // maybe?: if (hiy <= loy || hix <= lox) return EMPTY_REGION; final int y1 = loy + edges[0]; final int y2 = loy + edges[1]; // rowsNum * (3 + 1 * 2) final int[] bands = new int[(y2 - y1) * 5]; int end = 0; int index = 2; // Note to Sergey: Does end+4 also generate faster code? for (int y = y1; end+4 < bands.length && y < y2; ++y) { final int x1 = lox + edges[index++]; final int x2 = lox + edges[index++]; // Is the following comment too obvious? // Note: always consume both indices before rejecting span if (y < loy || y >= hiy) continue; if (x1 < lox) x1 = lox; if (x2 > hix) x2 = hix; if (x1 < x2) { bands[end++] = y; // spanloy bands[end++] = y + 1; // spanhiy bands[end++] = 1; // 1 span per row bands[end++] = x1; // spanlox bands[end++] = x2; // spanhix } } return end != 0 ? new Region(lox, loy, hix, hiy, bands, end) : EMPTY_REGION; } This code should ensure correctness/validity of the Region data structure without much performance impact, hopefully? ...jim From sergey.bylokhov at oracle.com Sat Nov 15 01:36:30 2014 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 14 Nov 2014 17:36:30 -0800 (PST) Subject: [OpenJDK 2D-Dev] [9] Review Request: 8059942 Default implementation of DrawImage.renderImageXform() should be improved for d3d/ogl Message-ID: ----- james.graham at oracle.com wrote: > One thing to consider, though, is that this code is only used in some > rare cases - either that we don't have a direct native loop for the TH > native code to use directly, or that it is a custom composite. or bicubic interpolation is used(in some cases bilinear), or drawImageBG operation. > gains from the elimination of the Java-to-native transitions per > scanline also probably swamp any other tuning operation we can do here > so I think we've reached the knee of the curve for tuning this > operation > already. > > I'd rather have the (albeit internal to the implementation) API for > Region be reliable in the results it generates than to go out of our > way > to create external loopholes for constructing the objects for some > gains > in this "backup code". > > Note that if any given Src/Dst transform operation is critical to any > > application, it would be better to make sure that we have a native > MaskBlit for that combination than to make this clipping code go any > faster... > > ...jim From james.graham at oracle.com Sat Nov 15 02:15:21 2014 From: james.graham at oracle.com (Jim Graham) Date: Fri, 14 Nov 2014 18:15:21 -0800 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8059942 Default implementation of DrawImage.renderImageXform() should be improved for d3d/ogl In-Reply-To: References: Message-ID: <5466B739.9080902@oracle.com> On 11/14/14 5:36 PM, Sergey Bylokhov wrote: > > ----- james.graham at oracle.com wrote: > >> One thing to consider, though, is that this code is only used in some >> rare cases - either that we don't have a direct native loop for the TH >> native code to use directly, or that it is a custom composite. > > or bicubic interpolation is used(in some cases bilinear), or drawImageBG operation. By "this code" I mean the new code that constructs a clip region from an edges array. That only happens if the tests at 478 and 491 fail and those have nothing to do with bicubic or BG operations. BG operations get folded into INT_RGB earlier in the method so we are actually more likely to end early at line 499 and not need the edges array. bicubic has absolutely no bearing on whether we make it past line 499 either. BG or bicubic may force us to not use a hw loop on a hw surface, but they have no bearing on whether we make it down to the edges array code... ...jim From sergey.bylokhov at oracle.com Sat Nov 15 02:32:20 2014 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 14 Nov 2014 18:32:20 -0800 (PST) Subject: [OpenJDK 2D-Dev] [9] Review Request: 8059942 Default implementation of DrawImage.renderImageXform() should be improved for d3d/ogl Message-ID: ----- james.graham at oracle.com wrote: > By "this code" I mean the new code that constructs a clip region from > an > edges array. That only happens if the tests at 478 and 491 fail and > those have nothing to do with bicubic or BG operations. > BG operations get folded into INT_RGB earlier in the method so we are > actually more likely to end early at line 499 and not need the edges > array. bicubic has absolutely no bearing on whether we make it past > line 499 either. We end at line 499 only if we find a nativemask blit, which is supported by TransformHelper directly, this is not the case for most of our java loops: sw->oglsurface, surface->oglsurface. So all blits which are filter out in OGLDrawImage,renderImageXform()(note it filter out BG,bicibic,bilinear,xorComp,customComp) will use TransformHelper->egdes->blit, I guess this is not a rare case. > > BG or bicubic may force us to not use a hw loop on a hw surface, but > they have no bearing on whether we make it down to the edges array > code... > > ...jim From james.graham at oracle.com Sat Nov 15 02:57:01 2014 From: james.graham at oracle.com (Jim Graham) Date: Fri, 14 Nov 2014 18:57:01 -0800 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8059942 Default implementation of DrawImage.renderImageXform() should be improved for d3d/ogl In-Reply-To: References: Message-ID: <5466C0FD.8020806@oracle.com> I see what you are saying, if we get in here with a native destination surface at all then we aren't likely to find a native maskblit. I don't think bicubic and BG operations are that common, though. And I don't think they are common enough to warrant creating a new pathway to potentially create an unverified Region. ...jim On 11/14/14 6:32 PM, Sergey Bylokhov wrote: > ----- james.graham at oracle.com wrote: > >> By "this code" I mean the new code that constructs a clip region from >> an >> edges array. That only happens if the tests at 478 and 491 fail and >> those have nothing to do with bicubic or BG operations. >> BG operations get folded into INT_RGB earlier in the method so we are >> actually more likely to end early at line 499 and not need the edges >> array. bicubic has absolutely no bearing on whether we make it past >> line 499 either. > > We end at line 499 only if we find a nativemask blit, which is supported by TransformHelper directly, this is not the case for most of our java loops: sw->oglsurface, surface->oglsurface. So all blits which are filter out in OGLDrawImage,renderImageXform()(note it filter out BG,bicibic,bilinear,xorComp,customComp) will use TransformHelper->egdes->blit, I guess this is not a rare case. > > >> >> BG or bicubic may force us to not use a hw loop on a hw surface, but >> they have no bearing on whether we make it down to the edges array >> code... >> >> ...jim From Sergey.Bylokhov at oracle.com Wed Nov 19 19:44:20 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 19 Nov 2014 22:44:20 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8059942 Default implementation of DrawImage.renderImageXform() should be improved for d3d/ogl In-Reply-To: <5466871B.3030808@oracle.com> References: <7bd36a26-5168-4e30-a393-d2c9c36bf4dd@default> <5466871B.3030808@oracle.com> Message-ID: <546CF314.2050007@oracle.com> Hi, Jim. Please review an updated version of the fix: http://cr.openjdk.java.net/~serb/8059942/webrev.18 I hope that all possible overflows/correctness/validity problems are checked now. On 15.11.2014 1:50, Jim Graham wrote: > Hi Sergey, > > On 11/14/14 6:40 AM, Sergey Bylokhov wrote: >> Hi, Jim. >> Please review an updated version of the fix: >> http://cr.openjdk.java.net/~serb/8059942/webrev.17 >> Two notes: >> - one additional byte still is added to the bands, since I am still >> checking the code where we use endIndex-1/endIndex+1/endIndex++ or >> swap it with curYrow, etc. This isn't urgent. > > Since you no longer call appendSpan(), you no longer need the > additional byte in this new method. > >> - "end < bands.length" was added to the loop for the reason of >> overall loop performance(+15%). > > That's odd that it helps since you then consume 5 entries after that > check, but I guess Hotspot works in mysterious ways. I wonder if > "end+4" works as well or better since that would be a more accurate > test of what is happening. Also, even for 15% performance difference > of this one method, it might be better to take the AAIOBE as a double > check against the caller feeding us bad data, such as edges[0,1] that > end up overflowing? In either case, we generate valid data even in > the face of such anomalies. > > I'd still prefer to have the code confirm the ranges. It would still > be much simpler than the old code that called appendSpan/endRow a lot > with just a few checks, like this: > > static Region getInstance(final int lox, final int loy, final int > hix, > final int hiy, final int edges[]) { > // maybe?: if (hiy <= loy || hix <= lox) return EMPTY_REGION; > final int y1 = loy + edges[0]; > final int y2 = loy + edges[1]; > // rowsNum * (3 + 1 * 2) > final int[] bands = new int[(y2 - y1) * 5]; > int end = 0; > int index = 2; > // Note to Sergey: Does end+4 also generate faster code? > for (int y = y1; end+4 < bands.length && y < y2; ++y) { > final int x1 = lox + edges[index++]; > final int x2 = lox + edges[index++]; > // Is the following comment too obvious? > // Note: always consume both indices before rejecting span > if (y < loy || y >= hiy) continue; > if (x1 < lox) x1 = lox; > if (x2 > hix) x2 = hix; > if (x1 < x2) { > bands[end++] = y; // spanloy > bands[end++] = y + 1; // spanhiy > bands[end++] = 1; // 1 span per row > bands[end++] = x1; // spanlox > bands[end++] = x2; // spanhix > } > } > return end != 0 ? new Region(lox, loy, hix, hiy, bands, end) > : EMPTY_REGION; > } > > This code should ensure correctness/validity of the Region data > structure without much performance impact, hopefully? > > ...jim -- Best regards, Sergey. From james.graham at oracle.com Thu Nov 20 04:01:59 2014 From: james.graham at oracle.com (Jim Graham) Date: Wed, 19 Nov 2014 20:01:59 -0800 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8059942 Default implementation of DrawImage.renderImageXform() should be improved for d3d/ogl In-Reply-To: <546CF314.2050007@oracle.com> References: <7bd36a26-5168-4e30-a393-d2c9c36bf4dd@default> <5466871B.3030808@oracle.com> <546CF314.2050007@oracle.com> Message-ID: <546D67B7.1040902@oracle.com> Looks good... ...jim On 11/19/14 11:44 AM, Sergey Bylokhov wrote: > Hi, Jim. > Please review an updated version of the fix: > http://cr.openjdk.java.net/~serb/8059942/webrev.18 > I hope that all possible overflows/correctness/validity problems are > checked now. > > On 15.11.2014 1:50, Jim Graham wrote: >> Hi Sergey, >> >> On 11/14/14 6:40 AM, Sergey Bylokhov wrote: >>> Hi, Jim. >>> Please review an updated version of the fix: >>> http://cr.openjdk.java.net/~serb/8059942/webrev.17 >>> Two notes: >>> - one additional byte still is added to the bands, since I am still >>> checking the code where we use endIndex-1/endIndex+1/endIndex++ or >>> swap it with curYrow, etc. This isn't urgent. >> >> Since you no longer call appendSpan(), you no longer need the >> additional byte in this new method. >> >>> - "end < bands.length" was added to the loop for the reason of >>> overall loop performance(+15%). >> >> That's odd that it helps since you then consume 5 entries after that >> check, but I guess Hotspot works in mysterious ways. I wonder if >> "end+4" works as well or better since that would be a more accurate >> test of what is happening. Also, even for 15% performance difference >> of this one method, it might be better to take the AAIOBE as a double >> check against the caller feeding us bad data, such as edges[0,1] that >> end up overflowing? In either case, we generate valid data even in >> the face of such anomalies. >> >> I'd still prefer to have the code confirm the ranges. It would still >> be much simpler than the old code that called appendSpan/endRow a lot >> with just a few checks, like this: >> >> static Region getInstance(final int lox, final int loy, final int >> hix, >> final int hiy, final int edges[]) { >> // maybe?: if (hiy <= loy || hix <= lox) return EMPTY_REGION; >> final int y1 = loy + edges[0]; >> final int y2 = loy + edges[1]; >> // rowsNum * (3 + 1 * 2) >> final int[] bands = new int[(y2 - y1) * 5]; >> int end = 0; >> int index = 2; >> // Note to Sergey: Does end+4 also generate faster code? >> for (int y = y1; end+4 < bands.length && y < y2; ++y) { >> final int x1 = lox + edges[index++]; >> final int x2 = lox + edges[index++]; >> // Is the following comment too obvious? >> // Note: always consume both indices before rejecting span >> if (y < loy || y >= hiy) continue; >> if (x1 < lox) x1 = lox; >> if (x2 > hix) x2 = hix; >> if (x1 < x2) { >> bands[end++] = y; // spanloy >> bands[end++] = y + 1; // spanhiy >> bands[end++] = 1; // 1 span per row >> bands[end++] = x1; // spanlox >> bands[end++] = x2; // spanhix >> } >> } >> return end != 0 ? new Region(lox, loy, hix, hiy, bands, end) >> : EMPTY_REGION; >> } >> >> This code should ensure correctness/validity of the Region data >> structure without much performance impact, hopefully? >> >> ...jim > > From Sergey.Bylokhov at oracle.com Fri Nov 21 07:11:17 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 21 Nov 2014 10:11:17 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8059942 Default implementation of DrawImage.renderImageXform() should be improved for d3d/ogl In-Reply-To: <546D67B7.1040902@oracle.com> References: <7bd36a26-5168-4e30-a393-d2c9c36bf4dd@default> <5466871B.3030808@oracle.com> <546CF314.2050007@oracle.com> <546D67B7.1040902@oracle.com> Message-ID: <546EE595.4020002@oracle.com> Thanks, Jim! Can anybody make the second review of this fix? Also I need a review of this change as well: http://mail.openjdk.java.net/pipermail/2d-dev/2014-November/004937.html On 20.11.2014 7:01, Jim Graham wrote: > Looks good... > > ...jim > > On 11/19/14 11:44 AM, Sergey Bylokhov wrote: >> Hi, Jim. >> Please review an updated version of the fix: >> http://cr.openjdk.java.net/~serb/8059942/webrev.18 >> I hope that all possible overflows/correctness/validity problems are >> checked now. >> >> On 15.11.2014 1:50, Jim Graham wrote: >>> Hi Sergey, >>> >>> On 11/14/14 6:40 AM, Sergey Bylokhov wrote: >>>> Hi, Jim. >>>> Please review an updated version of the fix: >>>> http://cr.openjdk.java.net/~serb/8059942/webrev.17 >>>> Two notes: >>>> - one additional byte still is added to the bands, since I am still >>>> checking the code where we use endIndex-1/endIndex+1/endIndex++ or >>>> swap it with curYrow, etc. This isn't urgent. >>> >>> Since you no longer call appendSpan(), you no longer need the >>> additional byte in this new method. >>> >>>> - "end < bands.length" was added to the loop for the reason of >>>> overall loop performance(+15%). >>> >>> That's odd that it helps since you then consume 5 entries after that >>> check, but I guess Hotspot works in mysterious ways. I wonder if >>> "end+4" works as well or better since that would be a more accurate >>> test of what is happening. Also, even for 15% performance difference >>> of this one method, it might be better to take the AAIOBE as a double >>> check against the caller feeding us bad data, such as edges[0,1] that >>> end up overflowing? In either case, we generate valid data even in >>> the face of such anomalies. >>> >>> I'd still prefer to have the code confirm the ranges. It would still >>> be much simpler than the old code that called appendSpan/endRow a lot >>> with just a few checks, like this: >>> >>> static Region getInstance(final int lox, final int loy, final int >>> hix, >>> final int hiy, final int edges[]) { >>> // maybe?: if (hiy <= loy || hix <= lox) return EMPTY_REGION; >>> final int y1 = loy + edges[0]; >>> final int y2 = loy + edges[1]; >>> // rowsNum * (3 + 1 * 2) >>> final int[] bands = new int[(y2 - y1) * 5]; >>> int end = 0; >>> int index = 2; >>> // Note to Sergey: Does end+4 also generate faster code? >>> for (int y = y1; end+4 < bands.length && y < y2; ++y) { >>> final int x1 = lox + edges[index++]; >>> final int x2 = lox + edges[index++]; >>> // Is the following comment too obvious? >>> // Note: always consume both indices before rejecting span >>> if (y < loy || y >= hiy) continue; >>> if (x1 < lox) x1 = lox; >>> if (x2 > hix) x2 = hix; >>> if (x1 < x2) { >>> bands[end++] = y; // spanloy >>> bands[end++] = y + 1; // spanhiy >>> bands[end++] = 1; // 1 span per row >>> bands[end++] = x1; // spanlox >>> bands[end++] = x2; // spanhix >>> } >>> } >>> return end != 0 ? new Region(lox, loy, hix, hiy, bands, end) >>> : EMPTY_REGION; >>> } >>> >>> This code should ensure correctness/validity of the Region data >>> structure without much performance impact, hopefully? >>> >>> ...jim >> >> -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Nov 24 18:00:52 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 24 Nov 2014 21:00:52 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8059944 [OGL] Metrics for a method choice copying of texture should be improved Message-ID: <54737254.6080608@oracle.com> Hello. Please review the fix for jdk 9. This fix initially was sent as a fix for JDK-8029253 [1], but was postponed because another issue became a bottleneck [2] Description: We have two codepaths to draw a raster to the opengl surface: - via glDrawPixels - via intermediate texture. We empirically checked, what way is better, based on benchmarks. Became obvious that on intel devices the glDrawPixels is slower than intermediate texture. Bug: https://bugs.openjdk.java.net/browse/JDK-8059944 Webrev can be found at: http://cr.openjdk.java.net/~serb/8059944/webrev.00 [1] http://mail.openjdk.java.net/pipermail/2d-dev/2014-June/004642.html [2] http://mail.openjdk.java.net/pipermail/2d-dev/2014-October/004870.html *SwingMark *on OSX 10.9.5, macbook pro retina, Intel HD Graphics 4000: Base: http://cr.openjdk.java.net/~serb/8059944/perf/swingmark/base Will run test 5 times in the same VM Setting L&F to: com.apple.laf.AquaLookAndFeel ...... Score: 54629 Fix: http://cr.openjdk.java.net/~serb/8059944/perf/swingmark/fix Will run test 5 times in the same VM Setting L&F to: com.apple.laf.AquaLookAndFeel ...... Score: 35296 *J2DBench: *Note that results are better on a newer devices and the fix is usually lose when 1x1 image is used ======================================================================= Windows 7 x64, lenovo T410, Intel 3200 http://cr.openjdk.java.net/~serb/8059944/perf/win_intel_hg3200/results_ogl.txt Comparison to basis: Best result: 177.62% of basis Worst result: 53.73% of basis Number of wins: 618 Number of ties: 238 Number of losses: 296 ======================================================================= OSX 10.9.5, macbook pro retina, Intel HD Graphics 4000 http://cr.openjdk.java.net/~serb/8059944/perf/osx_intel_hd4000/results.txt Comparison to basis: Best result: *22151.35%* of basis Worst result: 50.28% of basis Number of wins: 880 Number of ties: 168 Number of losses: 104 ======================================================================= OSX 10.9.5, macbook pro retina, Intel Iris (HD 5100) http://cr.openjdk.java.net/~serb/8059944/perf/osx_intel_hd5100/results.txt Comparison to basis: Best result: *25422.21% *of basis Worst result: 37.94% of basis Number of wins: 863 Number of ties: 193 Number of losses: 96 -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue Nov 25 12:34:44 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 25 Nov 2014 15:34:44 +0300 Subject: [OpenJDK 2D-Dev] How to draw HiDPI image resources as BufferedImage? In-Reply-To: References: Message-ID: <54747764.3060408@oracle.com> Hi Tobias, The public API that allows to do that is discussed on the following thread: JDK-8029339 Custom MultiResolution image support on HiDPI displays http://mail.openjdk.java.net/pipermail/awt-dev/2014-August/008371.html Thanks, Alexandr. On 11/25/2014 12:32 PM, Tobias Bley wrote: > Hi, > > Loading and drawing an HiDPI image resource (@2x) works with JDK8 very good (Image image = Toolkit.getDefaultToolkit().getImage("/dir/image.ext?)). But how to load a HiDPI image and convert it to a HiDPI buffered image? Is it possible without creating a double sized BufferedImage and and than draw it via Graphics2D and scale 0.5? > > Best regards, > Tobi > From philip.race at oracle.com Tue Nov 25 21:13:56 2014 From: philip.race at oracle.com (Phil Race) Date: Tue, 25 Nov 2014 13:13:56 -0800 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8059944 [OGL] Metrics for a method choice copying of texture should be improved In-Reply-To: <54737254.6080608@oracle.com> References: <54737254.6080608@oracle.com> Message-ID: <5474F114.3070103@oracle.com> Approved. -phil. On 11/24/2014 10:00 AM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk 9. > This fix initially was sent as a fix for JDK-8029253 [1], but was > postponed because another issue became a bottleneck [2] > > Description: > We have two codepaths to draw a raster to the opengl surface: > - via glDrawPixels > - via intermediate texture. > We empirically checked, what way is better, based on benchmarks. Became > obvious that on intel devices the glDrawPixels is slower than > intermediate texture. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8059944 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8059944/webrev.00 > > [1] http://mail.openjdk.java.net/pipermail/2d-dev/2014-June/004642.html > [2] http://mail.openjdk.java.net/pipermail/2d-dev/2014-October/004870.html > > *SwingMark *on OSX 10.9.5, macbook pro retina, Intel HD Graphics 4000: > Base: http://cr.openjdk.java.net/~serb/8059944/perf/swingmark/base > Will run test 5 times in the same VM > Setting L&F to: com.apple.laf.AquaLookAndFeel > ...... > Score: 54629 > > Fix: http://cr.openjdk.java.net/~serb/8059944/perf/swingmark/fix > Will run test 5 times in the same VM > Setting L&F to: com.apple.laf.AquaLookAndFeel > ...... > Score: 35296 > > *J2DBench: *Note that results are better on a newer devices and the > fix is usually lose when 1x1 image is used > ======================================================================= > Windows 7 x64, lenovo T410, Intel 3200 > http://cr.openjdk.java.net/~serb/8059944/perf/win_intel_hg3200/results_ogl.txt > Comparison to basis: > Best result: 177.62% of basis > Worst result: 53.73% of basis > Number of wins: 618 > Number of ties: 238 > Number of losses: 296 > ======================================================================= > OSX 10.9.5, macbook pro retina, Intel HD Graphics 4000 > http://cr.openjdk.java.net/~serb/8059944/perf/osx_intel_hd4000/results.txt > Comparison to basis: > Best result: *22151.35%* of basis > Worst result: 50.28% of basis > Number of wins: 880 > Number of ties: 168 > Number of losses: 104 > ======================================================================= > OSX 10.9.5, macbook pro retina, Intel Iris (HD 5100) > http://cr.openjdk.java.net/~serb/8059944/perf/osx_intel_hd5100/results.txt > Comparison to basis: > Best result: *25422.21% *of basis > Worst result: 37.94% of basis > Number of wins: 863 > Number of ties: 193 > Number of losses: 96 > -- > Best regards, Sergey. From philip.race at oracle.com Tue Nov 25 21:15:30 2014 From: philip.race at oracle.com (Phil Race) Date: Tue, 25 Nov 2014 13:15:30 -0800 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8061832 J2DBench can be improved In-Reply-To: <545C87DA.1060406@oracle.com> References: <545A77C2.2090303@oracle.com> <545BC260.6030904@oracle.com> <545C87DA.1060406@oracle.com> Message-ID: <5474F172.4020608@oracle.com> Approved -phil. On 11/7/2014 12:50 AM, Sergey Bylokhov wrote: > Hi, Phil. > The new version of the fix: > http://cr.openjdk.java.net/~serb/8061832/webrev.03 > On 06.11.2014 21:48, Phil Race wrote: >> Am I right in understanding that the huge 4000x4000 option is >> disabled by default ? >> I think disabling by default is the right thing for that. > Yes, you are right. By default 20x20 and 250x250 are enabled only. >> >> -phil >> >> On 11/5/2014 11:17 AM, Sergey Bylokhov wrote: >>> Hello. >>> Please review the fix for jdk 9. >>> >>> Change description: >>> - Test groups were wrapped by JScrollPane >>> - Translucent volatile images now can be used as source and destination >>> - Additional source/destination were added(TYPE_4BYTE_**) >>> - Main window will be created on EDT at the center of the screen >>> - Support of the huge shapes were added(4000x4000) >>> - Support of the interpolation was added, by default nearest >>> neighbor is used >>> - Two cmm tests depended on the default enum.toString() >>> implementation, and was broken when usage of enums were removed. I >>> reused abbreviation as a name of the test >>> - "Image Rendering Tests" tab was renamed to "image rendering >>> benchmark", because now it has an options as well >>> - "Touch src image before every operation" was moved from the "image >>> rendering source" tab to the "image rendering benchmarks" and placed >>> in the same group as interpolation >>> - The new image rendering test was added: drawimage(img, x, y, >>> w*0.5, h*0.5, obs); will simplify testing of some blits on the >>> retina display >>> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061832 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/8061832/webrev.02 >>> >> > > From andrew.brygin at oracle.com Wed Nov 26 15:08:46 2014 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Wed, 26 Nov 2014 18:08:46 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8059944 [OGL] Metrics for a method choice copying of texture should be improved In-Reply-To: <54737254.6080608@oracle.com> References: <54737254.6080608@oracle.com> Message-ID: <5475ECFE.5010200@oracle.com> Hello Sergey, the change looks fine to me. Thanks, Andrew On 11/24/2014 9:00 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk 9. > This fix initially was sent as a fix for JDK-8029253 [1], but was > postponed because another issue became a bottleneck [2] > > Description: > We have two codepaths to draw a raster to the opengl surface: > - via glDrawPixels > - via intermediate texture. > We empirically checked, what way is better, based on benchmarks. Became > obvious that on intel devices the glDrawPixels is slower than > intermediate texture. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8059944 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8059944/webrev.00 > > [1] http://mail.openjdk.java.net/pipermail/2d-dev/2014-June/004642.html > [2] http://mail.openjdk.java.net/pipermail/2d-dev/2014-October/004870.html > > *SwingMark *on OSX 10.9.5, macbook pro retina, Intel HD Graphics 4000: > Base: http://cr.openjdk.java.net/~serb/8059944/perf/swingmark/base > Will run test 5 times in the same VM > Setting L&F to: com.apple.laf.AquaLookAndFeel > ...... > Score: 54629 > > Fix: http://cr.openjdk.java.net/~serb/8059944/perf/swingmark/fix > Will run test 5 times in the same VM > Setting L&F to: com.apple.laf.AquaLookAndFeel > ...... > Score: 35296 > > *J2DBench: *Note that results are better on a newer devices and the > fix is usually lose when 1x1 image is used > ======================================================================= > Windows 7 x64, lenovo T410, Intel 3200 > http://cr.openjdk.java.net/~serb/8059944/perf/win_intel_hg3200/results_ogl.txt > Comparison to basis: > Best result: 177.62% of basis > Worst result: 53.73% of basis > Number of wins: 618 > Number of ties: 238 > Number of losses: 296 > ======================================================================= > OSX 10.9.5, macbook pro retina, Intel HD Graphics 4000 > http://cr.openjdk.java.net/~serb/8059944/perf/osx_intel_hd4000/results.txt > Comparison to basis: > Best result: *22151.35%* of basis > Worst result: 50.28% of basis > Number of wins: 880 > Number of ties: 168 > Number of losses: 104 > ======================================================================= > OSX 10.9.5, macbook pro retina, Intel Iris (HD 5100) > http://cr.openjdk.java.net/~serb/8059944/perf/osx_intel_hd5100/results.txt > Comparison to basis: > Best result: *25422.21% *of basis > Worst result: 37.94% of basis > Number of wins: 863 > Number of ties: 193 > Number of losses: 96 > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.brygin at oracle.com Wed Nov 26 15:27:14 2014 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Wed, 26 Nov 2014 18:27:14 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8061832 J2DBench can be improved In-Reply-To: <545C87DA.1060406@oracle.com> References: <545A77C2.2090303@oracle.com> <545BC260.6030904@oracle.com> <545C87DA.1060406@oracle.com> Message-ID: <5475F152.9020800@oracle.com> Hello Sergey, the fix looks fine to me. Thanks, Andrew On 11/7/2014 11:50 AM, Sergey Bylokhov wrote: > Hi, Phil. > The new version of the fix: > http://cr.openjdk.java.net/~serb/8061832/webrev.03 > On 06.11.2014 21:48, Phil Race wrote: >> Am I right in understanding that the huge 4000x4000 option is >> disabled by default ? >> I think disabling by default is the right thing for that. > Yes, you are right. By default 20x20 and 250x250 are enabled only. >> >> -phil >> >> On 11/5/2014 11:17 AM, Sergey Bylokhov wrote: >>> Hello. >>> Please review the fix for jdk 9. >>> >>> Change description: >>> - Test groups were wrapped by JScrollPane >>> - Translucent volatile images now can be used as source and destination >>> - Additional source/destination were added(TYPE_4BYTE_**) >>> - Main window will be created on EDT at the center of the screen >>> - Support of the huge shapes were added(4000x4000) >>> - Support of the interpolation was added, by default nearest >>> neighbor is used >>> - Two cmm tests depended on the default enum.toString() >>> implementation, and was broken when usage of enums were removed. I >>> reused abbreviation as a name of the test >>> - "Image Rendering Tests" tab was renamed to "image rendering >>> benchmark", because now it has an options as well >>> - "Touch src image before every operation" was moved from the "image >>> rendering source" tab to the "image rendering benchmarks" and placed >>> in the same group as interpolation >>> - The new image rendering test was added: drawimage(img, x, y, >>> w*0.5, h*0.5, obs); will simplify testing of some blits on the >>> retina display >>> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061832 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/8061832/webrev.02 >>> >> > > From philip.race at oracle.com Wed Nov 26 18:37:04 2014 From: philip.race at oracle.com (Phil Race) Date: Wed, 26 Nov 2014 10:37:04 -0800 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8059942 Default implementation of DrawImage.renderImageXform() should be improved for d3d/ogl In-Reply-To: <546EE595.4020002@oracle.com> References: <7bd36a26-5168-4e30-a393-d2c9c36bf4dd@default> <5466871B.3030808@oracle.com> <546CF314.2050007@oracle.com> <546D67B7.1040902@oracle.com> <546EE595.4020002@oracle.com> Message-ID: <54761DD0.8020904@oracle.com> Looks good : +1 -phil. On 11/20/2014 11:11 PM, Sergey Bylokhov wrote: > Thanks, Jim! > Can anybody make the second review of this fix? > > Also I need a review of this change as well: > http://mail.openjdk.java.net/pipermail/2d-dev/2014-November/004937.html > > On 20.11.2014 7:01, Jim Graham wrote: >> Looks good... >> >> ...jim >> >> On 11/19/14 11:44 AM, Sergey Bylokhov wrote: >>> Hi, Jim. >>> Please review an updated version of the fix: >>> http://cr.openjdk.java.net/~serb/8059942/webrev.18 >>> I hope that all possible overflows/correctness/validity problems are >>> checked now. >>> >>> On 15.11.2014 1:50, Jim Graham wrote: >>>> Hi Sergey, >>>> >>>> On 11/14/14 6:40 AM, Sergey Bylokhov wrote: >>>>> Hi, Jim. >>>>> Please review an updated version of the fix: >>>>> http://cr.openjdk.java.net/~serb/8059942/webrev.17 >>>>> Two notes: >>>>> - one additional byte still is added to the bands, since I am still >>>>> checking the code where we use endIndex-1/endIndex+1/endIndex++ or >>>>> swap it with curYrow, etc. This isn't urgent. >>>> >>>> Since you no longer call appendSpan(), you no longer need the >>>> additional byte in this new method. >>>> >>>>> - "end < bands.length" was added to the loop for the reason of >>>>> overall loop performance(+15%). >>>> >>>> That's odd that it helps since you then consume 5 entries after that >>>> check, but I guess Hotspot works in mysterious ways. I wonder if >>>> "end+4" works as well or better since that would be a more accurate >>>> test of what is happening. Also, even for 15% performance difference >>>> of this one method, it might be better to take the AAIOBE as a double >>>> check against the caller feeding us bad data, such as edges[0,1] that >>>> end up overflowing? In either case, we generate valid data even in >>>> the face of such anomalies. >>>> >>>> I'd still prefer to have the code confirm the ranges. It would still >>>> be much simpler than the old code that called appendSpan/endRow a lot >>>> with just a few checks, like this: >>>> >>>> static Region getInstance(final int lox, final int loy, final int >>>> hix, >>>> final int hiy, final int edges[]) { >>>> // maybe?: if (hiy <= loy || hix <= lox) return EMPTY_REGION; >>>> final int y1 = loy + edges[0]; >>>> final int y2 = loy + edges[1]; >>>> // rowsNum * (3 + 1 * 2) >>>> final int[] bands = new int[(y2 - y1) * 5]; >>>> int end = 0; >>>> int index = 2; >>>> // Note to Sergey: Does end+4 also generate faster code? >>>> for (int y = y1; end+4 < bands.length && y < y2; ++y) { >>>> final int x1 = lox + edges[index++]; >>>> final int x2 = lox + edges[index++]; >>>> // Is the following comment too obvious? >>>> // Note: always consume both indices before rejecting span >>>> if (y < loy || y >= hiy) continue; >>>> if (x1 < lox) x1 = lox; >>>> if (x2 > hix) x2 = hix; >>>> if (x1 < x2) { >>>> bands[end++] = y; // spanloy >>>> bands[end++] = y + 1; // spanhiy >>>> bands[end++] = 1; // 1 span per row >>>> bands[end++] = x1; // spanlox >>>> bands[end++] = x2; // spanhix >>>> } >>>> } >>>> return end != 0 ? new Region(lox, loy, hix, hiy, bands, end) >>>> : EMPTY_REGION; >>>> } >>>> >>>> This code should ensure correctness/validity of the Region data >>>> structure without much performance impact, hopefully? >>>> >>>> ...jim >>> >>> > >