From prahalad.kumar.narayanan at oracle.com Tue Mar 1 05:10:44 2016 From: prahalad.kumar.narayanan at oracle.com (Prahalad kumar Narayanan) Date: Tue, 1 Mar 2016 10:40:44 +0530 Subject: [OpenJDK 2D-Dev] Review Request: (JDK-8044788) [D3D] clip is ignored during surface->sw blit In-Reply-To: <56CD97EA.9030904@oracle.com> References: <56CAB11E.7040703@oracle.com> <56CACD71.9040006@oracle.com> <56CD97EA.9030904@oracle.com> Message-ID: <56D52454.4040006@oracle.com> Hello Everyone, 2D-Dev Group. Good day to you. First, thanks to Sergey for his accurate review & suggestions. I.Review Fixes: 1. Upon inspection into the code, I found that native D3D interfaces support on-the-fly conversion of pixels in D3DSurface to Sysmem based BufferedImage of type "IntARGB only". 2. Hence, the if(...) condition present in complexClipBlit method is not valid. This change has been incorporated in the code now. 3. The webrev.01 is available for review under: http://cr.openjdk.java.net/~psadhukhan/prahlad/webrev.01/ II.Next Steps: 1. Further discussions with Sergey revealed the fact that, D3DBlitLoops.java registers a primitive for SurfaceToSw blit as follows: static void register() { ... new D3DSurfaceToSwBlit(SurfaceType.IntArgb, D3DSurfaceData.ST_INT_ARGB); ... }; 2. The above code implies that there is no single/ direct blit method if the destination is of SurfaceType.IntArgbPre. 3. When no registered primitive exists for the source and destination type, the conversion might be implemented through GeneralBlits causing many CPU cycles. 4. Sergey suggested that, we could enhance the native D3D interface to support on the fly conversion to destination of type IntArgbPre. This will help improve the performance. But this can be taken up after the current fix. Kindly review the fix for current issue from the link - http://cr.openjdk.java.net/~psadhukhan/prahlad/webrev.01/ Thank you for your time in review Have a good day Prahalad N. On 2/24/2016 5:15 PM, Sergey Bylokhov wrote: > Hi, Prahalad. > The fix looks good in general. I have only one question: > In the complexClipBlit() you have this code: > 552 // Type- indicates the pixel format of Sysmem based BufferedImage. > 553 // Native side D3D interface supports copying surface contents to > 554 // ST_INT_ARGB, ST_INT_ARGB_PRE and other pixel formats > 555 final int type = typeval == D3DSurfaceData.ST_INT_ARGB_PRE ? > 556 BufferedImage.TYPE_INT_ARGB_PRE : > 557 BufferedImage.TYPE_INT_ARGB; > > This code was copied from the OGL version of the fix and it have two > assumptions: > - The type of the native texture can be ST_INT_ARGB_PRE, or can > contains "other"(???) value. Please take a look to the > OGLBlitLoops.java code. In OGL we register two different blits: > OGLSurfaceToSwBlit blitSurfaceToIntArgbPre = > new > OGLSurfaceToSwBlit(SurfaceType.IntArgbPre,OGLSurfaceData.PF_INT_ARGB_PRE); > // surface->sw ops > new OGLSurfaceToSwBlit(SurfaceType.IntArgb,OGLSurfaceData.PF_INT_ARGB), > blitSurfaceToIntArgbPre, > > So in OGL when the blit is called the type can be PF_INT_ARGB_PRE or > PF_INT_ARGB. This is why we have "if" statement in the complexClipBlit. > > - The second assumption is that the native code is able to copy the > d3d texture to the system memory and do conversion on the fly. The ogl > code have such conversion(argb_pre is converted to argb in the > OGLBlitLoops.c in the flip() method). Do you know our native d3d part > is able to do the same? If yes, then we should register separate blits > in D3DBlitLoops to cover different source/destination and change the > "if". > > On 22.02.16 11:57, Prahalad kumar Narayanan wrote: >> Hello Everyone, 2D-Dev Group >> >> I continued to inspect the bug : JDK-8044788: [D3D] Clip is ignored >> during Surface > Sw Blit issue. >> Link : https://bugs.openjdk.java.net/browse/JDK-8044788 >> >> Here is a quick brief on root cause, solutions experimented and the >> webrev link for review. >> Kindly go through each of these items and provide your review so that we >> could check-in the bug fix. >> >> Root Cause: >> 1. D3DSurfaceToSw Blit does not pass clip value to the native cpp >> interface >> 2. Even if the clip were to be passed through JNI, the native interface >> ignores the clip because it uses d3d's StretRect API. >> 3. Henceforth, in the current implementation, clipping in SurfaceToSw >> usecase will work ' only ' for Rect bounds provided proper src(x, y), >> dst(x, y), width and height are provided. >> 4. It can be noted that : the proper src(x, y), dst(x, y) are also not >> calculated considering the intersection of these rectangles with the >> clip bounds. >> >> Different Solutions & Results >> 1. Three solutions are feasible to fix this issue: >> a. Solution 1: Convert the input Surface to Sysmem image, >> followed by regular Blit. To optimize this further, the conversion can >> be taken up only for Shape clips. >> b. Solution 2: Using existing classes in D3DBlitLoops, execute >> SwToSurface (copy dest to accel Surface), SurfaceToSurface (supports >> clip), SurfaceToSw (full copy) in order. >> c. Solution 3: Modify the native side interfaces to accept clip >> and execute Solution2 's logic in native code. >> 2. Upon various experiments, Solution 1 has been found to be faster than >> the rest. >> a. This can be attributed to fewer draw /or copy iterations >> compared to the other two solutions. >> b. In addition to the above fact, the code retains the same >> approach as used by the OGL pipeline making it easier to understand. >> >> Webrev Link: http://cr.openjdk.java.net/~psadhukhan/prahlad/webrev.00/ >> Sufficient comments have been added so that developers could easily get >> understanding of the issue and solution checked in. >> >> Thank you >> Have a great day >> >> Prahalad N. >> >> >> >> Subject: Re: [OpenJDK 2D-Dev] Review Request: (JDK-8044788) [D3D] >> clip >> is ignored during surface->sw blit >> Date: Wed, 15 Apr 2015 16:17:37 +0300 >> From: Sergey Bylokhov >> To: prasanta sadhukhan , >> 2d-dev at openjdk.java.net >> >> >> >> Hi, Prasanta. >> The same approach was used in OGL pipeline for the reason. Because we >> use glReadPixels and there is no way to apply the clip. So we read >> pixels to the temporary buffer and apply the clip later. Can you >> additionaly investigate is it possible to apply the clip in d3d directly >> or not? >> >> Note that this [1] comment is not correct in d3d, because d3d have only >> one direct blit D3d surface -> SW which is D3DSurfaceToSwBlit(IntArgb, >> ST_INT_ARGB), all other blits will be done via temporary buffer in >> D3DGeneralBlit. >> >> [1] >>> 523 // We can convert argb_pre data from D3d surface in two >>> places: >>> 524 // - During D3d surface -> SW blit >>> 525 // - During SW -> SW blit >>> 526 // The first one is faster when we use opaque D3d >>> surface, because in >>> 527 // this case we simply skip conversion and use color >>> components as is. >>> 528 // Because of this we align intermediate buffer type with >>> type of >>> 529 // destination not source. >> >> >> On 15.04.15 11:57, prasanta sadhukhan wrote: >>> Hi, >>> >>> I would like a review for a solution of this bug in jdk9. >>> The clip was ignored during surface->sw blit in d3d pipeline. The fix >>> is to use the clip parameter to calculate the blit coordinates >>> correctly. >>> >>> Bug:https://bugs.openjdk.java.net/browse/JDK-8044788 >>> webrev:http://cr.openjdk.java.net/~psadhukhan/8044788/webrev.00/ >>> >>> Regards >>> Prasanta >> >> >> -- >> Best regards, Sergey. >> >> >> >> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Tue Mar 1 09:21:21 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Tue, 1 Mar 2016 14:51:21 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8138749, , Revisited: PrinterJob.printDialog() does not support multi-mon, always displayed on primary In-Reply-To: <56C55CFB.50707@oracle.com> References: <569F6AC2.7060103@oracle.com> <569FFC46.8040700@oracle.com> <56A0A8BD.306@oracle.com> <56A169C3.2010903@oracle.com> <56A1D85B.3020804@oracle.com> <56AA2B15.90900@oracle.com> <56AB323C.7090706@oracle.com> <56B14B37.6010706@oracle.com> <56B19180.70207@oracle.com> <56B244AA.8060707@oracle.com> <56B2E223.1050400@oracle.com> <56B463FC.9070702@oracle.com> <56BBC0D7.9080401@oracle.com> <56C1B8D9.7030805@oracle.com> <56C50EED.2020609@oracle.com> <56C55CFB.50707@oracle.com> Message-ID: <56D55F11.3050800@oracle.com> Hi Phil, Please find my modified webrev http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.07/ which takes care of the fact (as compared to webrev.06), if dialog does not exceed window bounds at both left or top, do not modify dialog at both x,y coordinates. Only modify that coordinate in which dialog has exceeded window bounds. Regards Prasanta On 2/18/2016 11:26 AM, prasanta sadhukhan wrote: > Hi Phil, > > On 2/18/2016 5:53 AM, Philip Race wrote: >> I don't think we should be adjusting the width of the dialog so that >> part of the change >> should be removed which will simplify the logic. >> >> Of course anyone calling the ServiceUI public API does not have any >> insight into the size of the dialog since it is not explicitly >> returned so they >> could inadvertently position it so that it is partly off the bottom >> or right side of the screen. >> Perhaps in a multi-monitor environment with two side by side screens >> they want >> the dialog centred such that it spans the two >> Perhaps they want these behaviours but I suspect not so it is >> probably worth >> 'fixing up' some of these cases. >> >> So our 'tweaking' of the position should be limited so that it >> positions the dialog >> such that its moved the minimum amount to that the bottom right is on >> (the specified) screen. >> If - and only if - that would cause it to be partially off the >> top-left - possible only >> if the screen is smaller than the dialog, should we adjust the dialog >> position in >> a way that allows the bottom or right to be off-screen. >> > Please find the updated webrev that takes care of your review comments > http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.06/ > > As for the below proposal, I guess we could handle it as part of > future enhancements, can we? > > Regards > Prasanta >> I think we are mostly there and it is not important enough to add new >> API to >> ServiceUI at this time to give us hints about how to handle such >> cases - although >> I have given it some consideration. >> >> There are lot of things we *could* do here >> - expose the pageDialog (now commented out) >> - provide a way to pass in the owner Dialog or Frame and stop >> ignoring it in ServiceDialog. >> That would be useful for modality. >> - provide those hints I mentioned >> >> I think #1 and #2 on that list might be the most useful to some >> people but >> don't invalidate this fix even if it might need to be revised if we >> ever do them .. >> >> >> -phil. >> >> On 2/15/16, 3:39 AM, prasanta sadhukhan wrote: >>> Hi Phil, >>> >>> >> Line 836 should be >>> >> x = (bounds.x + bounds.width) - dlgBound.width >>> >>> can be wrong if (bounds.x + bounds.width) - dlgBound.width comes out >>> to be negative (or less than window top-left x,y coordiantes) >>> For example, if window bounds for secondary monitor is (x=1600, y=0, >>> width=489, height =361) >>> and dialog bounds is (x=1650, y=50, width=460, height=353) then >>> above calc will set x to (1629, 8) [ x=1600+489-460=1629 , y = >>> 0+361-353=8] which is ok >>> >>> but if we have dialog bounds (x=1650, y=50, width=554, height = 390) >>> then x becomes 1600+489-554=1535 and y becomes 0+361-390= -29 so it >>> will go beyond the top-left corner of window. >>> >>> so for those cases, I am >>> setting x and y to bounds.x, bounds.y so that atmost it can go to >>> top-left and not beyond that and >>> also setting the dialog width /height to window width/height (as if >>> we keep the same dialog width,height it will become 1600,0,554,390 >>> which is again going beyond window bounds 1600,0,489,361) >>> >>> Please find the updated webrev >>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.05/ >>> >>> Regards >>> Prasanta >>> On 2/11/2016 4:29 AM, Phil Race wrote: >>>> if (dlgBounds.x + dlgBounds.width > bounds.x + bounds.width) { >>>> 836 x = bounds.x; >>>> >>>> >>>> Line 836 should be >>>> x = (bounds.x + bounds.width) - dlgBound.width >>>> >>>> Same logic for y. >>>> >>>> 841 pageDialog.setBounds(x, y, bounds.width, >>>> bounds.height); >>>> >>>> That looks wrong. It is setting the width/height of the dialog to >>>> be the width/height of the screen. Should be dlgBounds.width + >>>> height. >>>> >>>> >>>> -phil. >>>> >>>> >>>> On 02/05/2016 12:57 AM, prasanta sadhukhan wrote: >>>>> >>>>> >>>>> On 2/4/2016 11:01 AM, prasanta sadhukhan wrote: >>>>>> Hi Phil, >>>>>> >>>>>> On 2/3/2016 11:49 PM, Phil Race wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I think it is worth addressing all this at once and I think it >>>>>>> can be done >>>>>>> entirely in RPJ, leaving ServiceUI alone. Ie fix it just for the >>>>>>> case where >>>>>>> RPJ displays the dialog(s). >>>>>> RPJ display the dialog only for pageDialog >>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/b9a92b2a8b37/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java#l820 >>>>>> >>>>>> whereas ServiceUI display the printDialog >>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/b9a92b2a8b37/src/java.desktop/share/classes/javax/print/ServiceUI.java#l227 >>>>>> >>>>>> >>>>>> So, are you saying we fix it only for pageDialog and leave out >>>>>> printDialog()? >>>>>> >>>>> Please find updated webrev >>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.04/ >>>>> >>>>> where both RPJ and ServiceUI is modified to show the dialog >>>>> entirely on-screen. >>>>> I could not leave ServiceUI without modification as >>>>> // if portion of dialog is not within the gc boundary >>>>> if (!gcBounds.contains(dlgBounds)) { >>>>> // put in the center relative to parent frame/dialog >>>>> dialog.setLocationRelativeTo(owner); >>>>> } >>>>> this code was drawing the dialog in primary so I have to delete >>>>> the code to make sure dialog is displayed on secondary to fix the >>>>> bug. And since anyway, I was modifying ServiceUI, I thought of >>>>> adding the >>>>> check to draw the printDialog on screen in ServiceUI same as >>>>> pageDialog. >>>>> >>>>> Regards >>>>> Prasanta >>>>>> Regards >>>>>> Prasanta >>>>>>> When an application calls ServiceUI directly, it >>>>>>> can decide where it would like the dialog subject to the >>>>>>> existing constraint. >>>>>>> >>>>>>> The test really should be one test so that the behaviours can be >>>>>>> tested as one with lower overhead. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 02/02/2016 09:34 PM, prasanta sadhukhan wrote: >>>>>>>> Hi Phil, >>>>>>>> >>>>>>>> On 2/3/2016 6:05 AM, Phil Race wrote: >>>>>>>>> The RasterPrinterJob changes are now OK however >>>>>>>>> >>>>>>>>> - I am not sure I understand how removing the check in ServiceUI >>>>>>>>> will address the issue about the dialog needing to be entirely >>>>>>>>> on-screen. >>>>>>>>> It reads to me as if now you allow that in preference to >>>>>>>>> having it centred. >>>>>>>>> But I am not sure the old code would have worked in all cases >>>>>>>>> either >>>>>>>>> since centering on a very small owner window in the corner of >>>>>>>>> the screen >>>>>>>>> would result in the same problem. >>>>>>>> Since this issue was about showing the dialog on primary vs >>>>>>>> secondary, can we address this issue of showing the dialog >>>>>>>> entirely on-screen in separate bug id (since this issue is >>>>>>>> present in primary screen too if dialog is bigger than >>>>>>>> top-level window)? >>>>>>>> The present change in ServiceUI address the issue of showing >>>>>>>> the dialog on secondary monitor if dialog is bigger than >>>>>>>> top-level. >>>>>>>>> Probably what is needed is some code that moves it just enough >>>>>>>>> to fit. >>>>>>>>> ie downwards if it is off the top, left if it is off the right >>>>>>>>> and so forth ? >>>>>>>>> >>>>>>>>> - The two tests do not share the same bug ID. I expected they >>>>>>>>> should now do so .. and I was further supposing you would merge >>>>>>>>> the two tests into one. >>>>>>>> I will change the bug id of 2nd test. Is it ok if I keep these >>>>>>>> 2 tests separate to make it easier? >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>>>> >>>>>>>>> -phil. >>>>>>>>> >>>>>>>>> On 01/29/2016 01:34 AM, prasanta sadhukhan wrote: >>>>>>>>>> Hi Phil, >>>>>>>>>> >>>>>>>>>> On 1/28/2016 8:22 PM, Philip Race wrote: >>>>>>>>>>> "in consistent" >>>>>>>>>>> >>>>>>>>>>> On 1/21/16, 11:20 PM, prasanta sadhukhan wrote: >>>>>>>>>>>> Hi Phil, >>>>>>>>>>>> >>>>>>>>>>>> I checked with NATIVE print dialog and with other app print >>>>>>>>>>>> dialog, they are positioning the dialog a little ahead of >>>>>>>>>>>> top-left corner (not at 1/3rd of the window as we are doing >>>>>>>>>>>> now) >>>>>>>>>>>> so I did the same and positioned the dialog in consistent >>>>>>>>>>>> with our NATIVE print dialog. >>>>>>>>>>> >>>>>>>>>>> You mean consistently. in consistent means the opposite >>>>>>>>>>> Please adjust that in the code comment. >>>>>>>>>>> >>>>>>>>>>> 50,50 is probably OK so long as you verified this is >>>>>>>>>>> approximately >>>>>>>>>>> what happens on most platforms, not just windows 8 or similar. >>>>>>>>>>> I don't think you will find complete consistency because >>>>>>>>>>> apps may >>>>>>>>>>> control it and use different dialogs even on the same platform. >>>>>>>>>>> On hidpi screens this may be closer to the top-left than you >>>>>>>>>>> intend >>>>>>>>>>> but I expect it is fine. >>>>>>>>>>> >>>>>>>>>> Tested on windows, linux and it works ok. We showed the >>>>>>>>>> dialog at x+50,y+50 where x,y is the coordinate of the active >>>>>>>>>> window. >>>>>>>>>> Do not have local mac system to test multimonitor setup. >>>>>>>>>>> The one main thing that you should verify is what happens in >>>>>>>>>>> the case >>>>>>>>>>> a native app top-level window is smaller than the print >>>>>>>>>>> dialog and is positioned >>>>>>>>>>> at the bottom right (of the right-most display). Does the >>>>>>>>>>> native app ensure >>>>>>>>>>> that the dialog is wholly on-screen ? I don't think your >>>>>>>>>>> code will do that. >>>>>>>>>>> And Safari on Mac at least seems to do that. I guess that >>>>>>>>>>> most apps try >>>>>>>>>>> their best to keep the dialog wholly on-screen. >>>>>>>>>>> >>>>>>>>>> Tested this case where window bounds is smaller than print >>>>>>>>>> dialog >>>>>>>>>> but because of this check in ServiceUI.java >>>>>>>>>> >>>>>>>>>> // if portion of dialog is not within the gc boundary >>>>>>>>>> if (!gcBounds.contains(dlgBounds)) { >>>>>>>>>> // put in the center relative to parent frame/dialog >>>>>>>>>> dialog.setLocationRelativeTo(owner); >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> the dialog is shown in the primary window. >>>>>>>>>> I saw we did not have this check for pageDialog(attr) where >>>>>>>>>> the dialog is shown in secondary monitor despite gcBounds >>>>>>>>>> smaller than print dialog. >>>>>>>>>> Therefore, I removed this check from ServiceUI. >>>>>>>>>> >>>>>>>>>> Please find the updated webrev: >>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.03/ >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Prasanta >>>>>>>>>>> -phil. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Please find the updated webrev >>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.02/ >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> Prasanta >>>>>>>>>>>> On 1/22/2016 4:59 AM, Phil Race wrote: >>>>>>>>>>>>> That is definitely better .. although I wonder if it would >>>>>>>>>>>>> be even better >>>>>>>>>>>>> if you found when there is an 'active' window that you >>>>>>>>>>>>> tried to >>>>>>>>>>>>> position the dialog such that it is near the upper-left >>>>>>>>>>>>> corner of that window ? >>>>>>>>>>>>> Please experiment and see how that looks compared to what >>>>>>>>>>>>> other apps are doing. >>>>>>>>>>>>> >>>>>>>>>>>>> -phil. >>>>>>>>>>>>> >>>>>>>>>>>>> On 01/21/2016 01:45 AM, prasanta sadhukhan wrote: >>>>>>>>>>>>>> Hi Phil, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please find the updated webrev >>>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.01/ >>>>>>>>>>>>>> which do away with the change in ServiceUI. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards >>>>>>>>>>>>>> Prasanta >>>>>>>>>>>>>> On 1/21/2016 2:59 AM, Phil Race wrote: >>>>>>>>>>>>>>> The changes in ServiceUI seem like they can cause the >>>>>>>>>>>>>>> spec. to be contradicted. >>>>>>>>>>>>>>> It says >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> * @param gc used to select screen. null means primary >>>>>>>>>>>>>>> or default screen. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> but you update the code such that it will use the active >>>>>>>>>>>>>>> window. >>>>>>>>>>>>>>> If that is on a secondary screen but null was passed in. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I am not entirely sure why ServiceUI needs to be changed >>>>>>>>>>>>>>> at all. >>>>>>>>>>>>>>> It is just the caller of ServiceUI .. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -phil. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 01/20/2016 03:08 AM, prasanta sadhukhan wrote: >>>>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8138749 >>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.00/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please review a fix for a long standing issue whereby >>>>>>>>>>>>>>>> it is seen that >>>>>>>>>>>>>>>> PrinterJob.printDialog(attr set) does not support >>>>>>>>>>>>>>>> multi-monitor setup. When this API is invoked, the >>>>>>>>>>>>>>>> print dialog is always displayed on the default screen >>>>>>>>>>>>>>>> device regardless of where the application is running. >>>>>>>>>>>>>>>> This is because this method >>>>>>>>>>>>>>>> uses ServiceDialog class for creating the dialog and >>>>>>>>>>>>>>>> that indeed supports passing a GC in which we would >>>>>>>>>>>>>>>> like to have the dialog. But printer job always uses >>>>>>>>>>>>>>>> the GraphicsConfig of the default screen device >>>>>>>>>>>>>>>> resulting in print dialog to be shown on primary >>>>>>>>>>>>>>>> device/monitor. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I have not considered pageDialog() for this fix. Will >>>>>>>>>>>>>>>> create a separate bugid and send a patch for that as >>>>>>>>>>>>>>>> well once this fix is approved. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>> Prasanta >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> > From prasanta.sadhukhan at oracle.com Tue Mar 1 11:14:57 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Tue, 1 Mar 2016 16:44:57 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8066139, , Null return from PrintJob.getGraphics() running closed/java/awt/PrintJob/HighResTest/HighResTest.java In-Reply-To: <56CAC14F.4030602@oracle.com> References: <56C6DDF1.1020009@oracle.com> <56C764B3.9020005@oracle.com> <56C77A50.7010605@oracle.com> <56CAAAC8.40009@oracle.com> <56CAC14F.4030602@oracle.com> Message-ID: <56D579B1.7090204@oracle.com> Hi Phil, Please find an updated webrev: http://cr.openjdk.java.net/~psadhukhan/8066139/webrev.01/ It seems if printerJobThread finished printing, it will set graphicsToBeDrawn/graphicsDrawn ArrayList to null resulting in getGraphics() returning null in the 2nd iteration causing NPE so I have modified printerJobThread#run so that when it has finished printing, do not set the arrayList to null but set a flag. In getGraphics(), I check that flag and start a new printerJobThread to handle the next printing. I have tested "All" and "Pages" selection. Regards Prasanta On 2/22/2016 1:35 PM, Philip Race wrote: > > It seems this behaviour is same in linux too for this HighResTest > testcase. > > OK that is good information .. so is not really a regression from > 8061267 as that is > not in > any way touching linux .. it is a pre-existing issue in a code path > that was not being tested. > > -phil. > > On 2/22/16, 11:59 AM, prasanta sadhukhan wrote: >> Hi Phil, >> >> >>Additionally, have you tried running the original test case >> provided with 8061267 >> >> against your fix ? >> The 8061267 testcase behaves similarly before and after my fix. >> >> >> If I manually select it, (ie select that "Pages" radio button) >> then press print, >> >> then voila, the NPE is back! >> It seems this behaviour is same in linux too for this HighResTest >> testcase. >> >> Regards >> Prasanta >> On 2/20/2016 1:55 AM, Phil Race wrote: >>> I am having trouble building JDK 9 at the moment so i applied >>> 8061267 to jdk8u-dev >>> and was able to reproduce the regression and have a couple of >>> observations >>> >>> - I am now seeing the NPE after the first page as you did .. puzzling. >>> - I next applied your fix but still see the NPE ! >>> >>> It appears that all your fix did is stop the "PD_PAGENUMS" flag >>> being automatically >>> set. If I manually select it, (ie select that "Pages" radio button) >>> then press print, >>> then voila, the NPE is back! >>> >>> -phil. >>> >>> >>> On 02/19/2016 10:53 AM, Phil Race wrote: >>>> I am not sure I can be correctly understanding the fix as the >>>> ramification seems >>>> to be that if the users wants to print only Page 3 of a 10 page >>>> document and so sets >>>> from page=3 and to page=3, that this request will be ignored and >>>> all pages will >>>> be printed .. can you test such a scenario. >>>> >>>> Additionally, have you tried running the original test case >>>> provided with 8061267 >>>> against your fix ? >>>> >>>> Also when I ran the HighResTest on a current build I saw a null >>>> graphics on >>>> the very first call to getGraphics() which is different than what I >>>> interpret >>>> you as saying - you see the null *after* the first page is printed. >>>> >>>> -phil. >>>> >>>> On 02/19/2016 01:18 AM, prasanta sadhukhan wrote: >>>>> Hi Phil, All, >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066139 >>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8066139/webrev.00/ >>>>> >>>>> It was seen after fix of JDK-8061267 >>>>> : PrinterJob: >>>>> Specified Page Ranges not displayed in Windows Native Print Dialog >>>>> the closed/java/awt/PrintJob/HighResTest/HighResTest.java was >>>>> failing with NPE when PrinterJob.getGraphics() is called the 2nd >>>>> time before calling PrinterJob.end(). >>>>> >>>>> The above fix caused this regression because it sets the >>>>> PD_PAGENUMS flag for windows PrintDlg struct which causes *Pages* >>>>> radio button to be selected in print dialog. >>>>> However, fromPage and toPage was both set to 1 so after the 1st >>>>> page is printed, RasterPrinterJob.print(attributes) finishes and >>>>> graphicsToBeDrawn.closeWhenEmpty() gets called >>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/d8def65c6c00/src/java.desktop/share/classes/sun/print/PrintJob2D.java#l1006 >>>>> >>>>> which sets the queue to null so when PrinterJob2D#getGraphics() >>>>> calls graphicsToBeDrawn.pop() it sees queue to be null and sets >>>>> graphics object to be null so >>>>> PrinterJob.getGraphics() gets null and g.drawLine in testcase >>>>> causes NPE since g is null. >>>>> >>>>> Fix was done to set the PD_PAGENUMS flag only when toPage is more >>>>> than fromPage in which case, "All" will be selected in printer >>>>> dialog and RasterPrinterJob.print() will finish only after >>>>> printing all the pages. >>>>> >>>>> Regards >>>>> Prasanta >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Tue Mar 1 23:59:06 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 2 Mar 2016 02:59:06 +0300 Subject: [OpenJDK 2D-Dev] Review Request: (JDK-8044788) [D3D] clip is ignored during surface->sw blit In-Reply-To: <56D52454.4040006@oracle.com> References: <56CAB11E.7040703@oracle.com> <56CACD71.9040006@oracle.com> <56CD97EA.9030904@oracle.com> <56D52454.4040006@oracle.com> Message-ID: <56D62CCA.6000801@oracle.com> Hi, Prahalad. The fix looks good. But you should remove the "-Dsun.java2d.d3d" option in the test(don't change it to true) otherwise it will fail on non-windows platform, because the "=false" is ignored if pipeline is not available. On 01.03.16 8:10, Prahalad kumar Narayanan wrote: > Hello Everyone, 2D-Dev Group. > > Good day to you. > > First, thanks to Sergey for his accurate review & suggestions. > I.Review Fixes: > 1. Upon inspection into the code, I found that native D3D > interfaces support on-the-fly conversion of pixels in D3DSurface to > Sysmem based BufferedImage of type "IntARGB only". > 2. Hence, the if(...) condition present in complexClipBlit method > is not valid. This change has been incorporated in the code now. > 3. The webrev.01 is available for review under: > http://cr.openjdk.java.net/~psadhukhan/prahlad/webrev.01/ > > II.Next Steps: > 1. Further discussions with Sergey revealed the fact that, > D3DBlitLoops.java registers a primitive for SurfaceToSw blit as follows: > static void register() { > ... > new D3DSurfaceToSwBlit(SurfaceType.IntArgb, > D3DSurfaceData.ST_INT_ARGB); > ... > }; > 2. The above code implies that there is no single/ direct blit > method if the destination is of SurfaceType.IntArgbPre. > 3. When no registered primitive exists for the source and > destination type, the conversion might be implemented through > GeneralBlits causing many CPU cycles. > 4. Sergey suggested that, we could enhance the native D3D interface > to support on the fly conversion to destination of type IntArgbPre. This > will help improve the performance. But this can be taken up after the > current fix. > > Kindly review the fix for current issue from the link - > http://cr.openjdk.java.net/~psadhukhan/prahlad/webrev.01/ > > Thank you for your time in review > Have a good day > > Prahalad N. > > > On 2/24/2016 5:15 PM, Sergey Bylokhov wrote: >> Hi, Prahalad. >> The fix looks good in general. I have only one question: >> In the complexClipBlit() you have this code: >> 552 // Type- indicates the pixel format of Sysmem based BufferedImage. >> 553 // Native side D3D interface supports copying surface contents to >> 554 // ST_INT_ARGB, ST_INT_ARGB_PRE and other pixel formats >> 555 final int type = typeval == D3DSurfaceData.ST_INT_ARGB_PRE ? >> 556 BufferedImage.TYPE_INT_ARGB_PRE : >> 557 BufferedImage.TYPE_INT_ARGB; >> >> This code was copied from the OGL version of the fix and it have two >> assumptions: >> - The type of the native texture can be ST_INT_ARGB_PRE, or can >> contains "other"(???) value. Please take a look to the >> OGLBlitLoops.java code. In OGL we register two different blits: >> OGLSurfaceToSwBlit blitSurfaceToIntArgbPre = >> new >> OGLSurfaceToSwBlit(SurfaceType.IntArgbPre,OGLSurfaceData.PF_INT_ARGB_PRE); >> // surface->sw ops >> new OGLSurfaceToSwBlit(SurfaceType.IntArgb,OGLSurfaceData.PF_INT_ARGB), >> blitSurfaceToIntArgbPre, >> >> So in OGL when the blit is called the type can be PF_INT_ARGB_PRE or >> PF_INT_ARGB. This is why we have "if" statement in the complexClipBlit. >> >> - The second assumption is that the native code is able to copy the >> d3d texture to the system memory and do conversion on the fly. The ogl >> code have such conversion(argb_pre is converted to argb in the >> OGLBlitLoops.c in the flip() method). Do you know our native d3d part >> is able to do the same? If yes, then we should register separate blits >> in D3DBlitLoops to cover different source/destination and change the >> "if". >> >> On 22.02.16 11:57, Prahalad kumar Narayanan wrote: >>> Hello Everyone, 2D-Dev Group >>> >>> I continued to inspect the bug : JDK-8044788: [D3D] Clip is ignored >>> during Surface > Sw Blit issue. >>> Link : https://bugs.openjdk.java.net/browse/JDK-8044788 >>> >>> Here is a quick brief on root cause, solutions experimented and the >>> webrev link for review. >>> Kindly go through each of these items and provide your review so that we >>> could check-in the bug fix. >>> >>> Root Cause: >>> 1. D3DSurfaceToSw Blit does not pass clip value to the native cpp >>> interface >>> 2. Even if the clip were to be passed through JNI, the native interface >>> ignores the clip because it uses d3d's StretRect API. >>> 3. Henceforth, in the current implementation, clipping in SurfaceToSw >>> usecase will work ' only ' for Rect bounds provided proper src(x, y), >>> dst(x, y), width and height are provided. >>> 4. It can be noted that : the proper src(x, y), dst(x, y) are also not >>> calculated considering the intersection of these rectangles with the >>> clip bounds. >>> >>> Different Solutions & Results >>> 1. Three solutions are feasible to fix this issue: >>> a. Solution 1: Convert the input Surface to Sysmem image, >>> followed by regular Blit. To optimize this further, the conversion can >>> be taken up only for Shape clips. >>> b. Solution 2: Using existing classes in D3DBlitLoops, execute >>> SwToSurface (copy dest to accel Surface), SurfaceToSurface (supports >>> clip), SurfaceToSw (full copy) in order. >>> c. Solution 3: Modify the native side interfaces to accept clip >>> and execute Solution2 's logic in native code. >>> 2. Upon various experiments, Solution 1 has been found to be faster than >>> the rest. >>> a. This can be attributed to fewer draw /or copy iterations >>> compared to the other two solutions. >>> b. In addition to the above fact, the code retains the same >>> approach as used by the OGL pipeline making it easier to understand. >>> >>> Webrev Link: http://cr.openjdk.java.net/~psadhukhan/prahlad/webrev.00/ >>> Sufficient comments have been added so that developers could easily get >>> understanding of the issue and solution checked in. >>> >>> Thank you >>> Have a great day >>> >>> Prahalad N. >>> >>> >>> >>> Subject: Re: [OpenJDK 2D-Dev] Review Request: (JDK-8044788) [D3D] >>> clip >>> is ignored during surface->sw blit >>> Date: Wed, 15 Apr 2015 16:17:37 +0300 >>> From: Sergey Bylokhov >>> To: prasanta sadhukhan , >>> 2d-dev at openjdk.java.net >>> >>> >>> >>> Hi, Prasanta. >>> The same approach was used in OGL pipeline for the reason. Because we >>> use glReadPixels and there is no way to apply the clip. So we read >>> pixels to the temporary buffer and apply the clip later. Can you >>> additionaly investigate is it possible to apply the clip in d3d directly >>> or not? >>> >>> Note that this [1] comment is not correct in d3d, because d3d have only >>> one direct blit D3d surface -> SW which is D3DSurfaceToSwBlit(IntArgb, >>> ST_INT_ARGB), all other blits will be done via temporary buffer in >>> D3DGeneralBlit. >>> >>> [1] >>>> 523 // We can convert argb_pre data from D3d surface in two >>>> places: >>>> 524 // - During D3d surface -> SW blit >>>> 525 // - During SW -> SW blit >>>> 526 // The first one is faster when we use opaque D3d >>>> surface, because in >>>> 527 // this case we simply skip conversion and use color >>>> components as is. >>>> 528 // Because of this we align intermediate buffer type with >>>> type of >>>> 529 // destination not source. >>> >>> >>> On 15.04.15 11:57, prasanta sadhukhan wrote: >>>> Hi, >>>> >>>> I would like a review for a solution of this bug in jdk9. >>>> The clip was ignored during surface->sw blit in d3d pipeline. The fix >>>> is to use the clip parameter to calculate the blit coordinates >>>> correctly. >>>> >>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8044788 >>>> webrev:http://cr.openjdk.java.net/~psadhukhan/8044788/webrev.00/ >>>> >>>> Regards >>>> Prasanta >>> >>> >>> -- >>> Best regards, Sergey. >>> >>> >>> >>> >>> >>> >>> >> >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Mar 2 00:37:54 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 2 Mar 2016 03:37:54 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8146042 Offscreen rendering is different from onscreen one In-Reply-To: <569898C4.1030404@oracle.com> References: <5697E44B.2040100@oracle.com> <5697E7B1.2080207@oracle.com> <569898C4.1030404@oracle.com> Message-ID: <56D635E2.6000706@oracle.com> On 15.01.16 9:59, Semyon Sadetsky wrote: > Hi Phil & Sergey, > > I have integrated Intel GPU i5 and cannot test other hardware. > On Mac's retina display the screen capture doesn't return exact pixel to > pixel image but the scaled one. So Mac platform should be excluded from > testing: > http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.01/ I run the latest test(webrev.03) on my nvidia card, and it fails after the fix, but pass before =(. I have no ati to check. Also I cannot check the fix on intel card, because I cannot enable d3d on it. > > --Semyon > > On 1/14/2016 9:23 PM, Phil Race wrote: >> This fudge factor was last adjusted in >> https://bugs.openjdk.java.net/browse/JDK-6597822 >> way back before the D3D pipeline was released and the comments seem to >> indicate that >> there was a fair amount of testing on different hardware. >> >> I don't know why this seems to be in un-specified hardware-dependent >> territory but >> it seems quite possible that this could just as easily introduce a >> different artifact >> on some other hardware. >> >> What exactly are you testing on ? And I think it needs to include at >> least one Nvidia >> and one AMD/ATI card. >> >> -phil. >> >> On 1/14/2016 10:09 AM, Semyon Sadetsky wrote: >>> Hello, >>> >>> Please review the fix for jdk9. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8146042 >>> webrev: http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.00/ >>> >>> The root cause is incorrect coordinate rounding in D3D renderer. To >>> fix the issue one of fudge factors was adjusted. >>> >>> Another issue mentioning in the JIRA ticket is taken out as a >>> separate bug. >>> >>> --Semyon >>> >> > -- Best regards, Sergey. From prahalad.kumar.narayanan at oracle.com Wed Mar 2 07:16:21 2016 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Tue, 1 Mar 2016 23:16:21 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review Request: (JDK-8044788) [D3D] clip is ignored during surface->sw blit In-Reply-To: <56D62CCA.6000801@oracle.com> References: <56CAB11E.7040703@oracle.com> <56CACD71.9040006@oracle.com> <56CD97EA.9030904@oracle.com> <56D52454.4040006@oracle.com> <56D62CCA.6000801@oracle.com> Message-ID: <4037a83a-d998-4f27-88ae-40b6fb86bb1f@default> Dear Sergey, Phil & Java 2D-Dev Group Good day to you. A Quick Follow-up to Bug: JDK-8044788 Bug Link: https://bugs.openjdk.java.net/browse/JDK-8044788 Review Fixes: The following fixes have been incorporated collating all of Sergey's valuable feedback. 1. File: D3DBlitLoops.java. Method: complexClipBlit. Removed if(...) condition pertaining to setting of BufferedImage's pixel format type. Proper type has been set with appropriate comment indicating why the setting has been done. 2. File: IncorrectClipSurface2SW.java. The option -Dsun.java2d.d3d=true has been removed from the test file. This will be required inorder to run the test across all platforms (incl. non-windows platforms) The webrev incorporating the above review fixes is available under: http://cr.openjdk.java.net/~psadhukhan/prahlad/webrev.02/ Kindly review the fix and provide your opinion. Thank you for your time in review Have a good day Prahalad N. -----Original Message----- From: Sergey Bylokhov Sent: Wednesday, March 02, 2016 5:29 AM To: Prahalad kumar Narayanan; Philip Race; prasanta sadhukhan; 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request: (JDK-8044788) [D3D] clip is ignored during surface->sw blit Hi, Prahalad. The fix looks good. But you should remove the "-Dsun.java2d.d3d" option in the test(don't change it to true) otherwise it will fail on non-windows platform, because the "=false" is ignored if pipeline is not available. On 01.03.16 8:10, Prahalad kumar Narayanan wrote: > Hello Everyone, 2D-Dev Group. > > Good day to you. > > First, thanks to Sergey for his accurate review & suggestions. > I.Review Fixes: > 1. Upon inspection into the code, I found that native D3D > interfaces support on-the-fly conversion of pixels in D3DSurface to > Sysmem based BufferedImage of type "IntARGB only". > 2. Hence, the if(...) condition present in complexClipBlit > method is not valid. This change has been incorporated in the code now. > 3. The webrev.01 is available for review under: > http://cr.openjdk.java.net/~psadhukhan/prahlad/webrev.01/ > > II.Next Steps: > 1. Further discussions with Sergey revealed the fact that, > D3DBlitLoops.java registers a primitive for SurfaceToSw blit as follows: > static void register() { > ... > new D3DSurfaceToSwBlit(SurfaceType.IntArgb, > D3DSurfaceData.ST_INT_ARGB); > ... > }; > 2. The above code implies that there is no single/ direct blit > method if the destination is of SurfaceType.IntArgbPre. > 3. When no registered primitive exists for the source and > destination type, the conversion might be implemented through > GeneralBlits causing many CPU cycles. > 4. Sergey suggested that, we could enhance the native D3D > interface to support on the fly conversion to destination of type > IntArgbPre. This will help improve the performance. But this can be > taken up after the current fix. > > Kindly review the fix for current issue from the link - > http://cr.openjdk.java.net/~psadhukhan/prahlad/webrev.01/ > > Thank you for your time in review > Have a good day > > Prahalad N. > > > On 2/24/2016 5:15 PM, Sergey Bylokhov wrote: >> Hi, Prahalad. >> The fix looks good in general. I have only one question: >> In the complexClipBlit() you have this code: >> 552 // Type- indicates the pixel format of Sysmem based BufferedImage. >> 553 // Native side D3D interface supports copying surface contents to >> 554 // ST_INT_ARGB, ST_INT_ARGB_PRE and other pixel formats >> 555 final int type = typeval == D3DSurfaceData.ST_INT_ARGB_PRE ? >> 556 BufferedImage.TYPE_INT_ARGB_PRE : >> 557 BufferedImage.TYPE_INT_ARGB; >> >> This code was copied from the OGL version of the fix and it have two >> assumptions: >> - The type of the native texture can be ST_INT_ARGB_PRE, or can >> contains "other"(???) value. Please take a look to the >> OGLBlitLoops.java code. In OGL we register two different blits: >> OGLSurfaceToSwBlit blitSurfaceToIntArgbPre = new >> OGLSurfaceToSwBlit(SurfaceType.IntArgbPre,OGLSurfaceData.PF_INT_ARGB_ >> PRE); >> // surface->sw ops >> new >> OGLSurfaceToSwBlit(SurfaceType.IntArgb,OGLSurfaceData.PF_INT_ARGB), >> blitSurfaceToIntArgbPre, >> >> So in OGL when the blit is called the type can be PF_INT_ARGB_PRE or >> PF_INT_ARGB. This is why we have "if" statement in the complexClipBlit. >> >> - The second assumption is that the native code is able to copy the >> d3d texture to the system memory and do conversion on the fly. The >> ogl code have such conversion(argb_pre is converted to argb in the >> OGLBlitLoops.c in the flip() method). Do you know our native d3d part >> is able to do the same? If yes, then we should register separate >> blits in D3DBlitLoops to cover different source/destination and >> change the "if". >> >> On 22.02.16 11:57, Prahalad kumar Narayanan wrote: >>> Hello Everyone, 2D-Dev Group >>> >>> I continued to inspect the bug : JDK-8044788: [D3D] Clip is ignored >>> during Surface > Sw Blit issue. >>> Link : https://bugs.openjdk.java.net/browse/JDK-8044788 >>> >>> Here is a quick brief on root cause, solutions experimented and the >>> webrev link for review. >>> Kindly go through each of these items and provide your review so >>> that we could check-in the bug fix. >>> >>> Root Cause: >>> 1. D3DSurfaceToSw Blit does not pass clip value to the native cpp >>> interface 2. Even if the clip were to be passed through JNI, the >>> native interface ignores the clip because it uses d3d's StretRect >>> API. >>> 3. Henceforth, in the current implementation, clipping in >>> SurfaceToSw usecase will work ' only ' for Rect bounds provided >>> proper src(x, y), dst(x, y), width and height are provided. >>> 4. It can be noted that : the proper src(x, y), dst(x, y) are also >>> not calculated considering the intersection of these rectangles with >>> the clip bounds. >>> >>> Different Solutions & Results >>> 1. Three solutions are feasible to fix this issue: >>> a. Solution 1: Convert the input Surface to Sysmem image, >>> followed by regular Blit. To optimize this further, the conversion >>> can be taken up only for Shape clips. >>> b. Solution 2: Using existing classes in D3DBlitLoops, >>> execute SwToSurface (copy dest to accel Surface), SurfaceToSurface >>> (supports clip), SurfaceToSw (full copy) in order. >>> c. Solution 3: Modify the native side interfaces to accept >>> clip and execute Solution2 's logic in native code. >>> 2. Upon various experiments, Solution 1 has been found to be faster >>> than the rest. >>> a. This can be attributed to fewer draw /or copy iterations >>> compared to the other two solutions. >>> b. In addition to the above fact, the code retains the same >>> approach as used by the OGL pipeline making it easier to understand. >>> >>> Webrev Link: >>> http://cr.openjdk.java.net/~psadhukhan/prahlad/webrev.00/ >>> Sufficient comments have been added so that developers could easily >>> get understanding of the issue and solution checked in. >>> >>> Thank you >>> Have a great day >>> >>> Prahalad N. >>> >>> >>> >>> Subject: Re: [OpenJDK 2D-Dev] Review Request: (JDK-8044788) [D3D] >>> clip >>> is ignored during surface->sw blit >>> Date: Wed, 15 Apr 2015 16:17:37 +0300 >>> From: Sergey Bylokhov >>> To: prasanta sadhukhan , >>> 2d-dev at openjdk.java.net >>> >>> >>> >>> Hi, Prasanta. >>> The same approach was used in OGL pipeline for the reason. Because >>> we use glReadPixels and there is no way to apply the clip. So we >>> read pixels to the temporary buffer and apply the clip later. Can >>> you additionaly investigate is it possible to apply the clip in d3d >>> directly or not? >>> >>> Note that this [1] comment is not correct in d3d, because d3d have >>> only one direct blit D3d surface -> SW which is >>> D3DSurfaceToSwBlit(IntArgb, ST_INT_ARGB), all other blits will be >>> done via temporary buffer in D3DGeneralBlit. >>> >>> [1] >>>> 523 // We can convert argb_pre data from D3d surface in two >>>> places: >>>> 524 // - During D3d surface -> SW blit >>>> 525 // - During SW -> SW blit >>>> 526 // The first one is faster when we use opaque D3d >>>> surface, because in >>>> 527 // this case we simply skip conversion and use color >>>> components as is. >>>> 528 // Because of this we align intermediate buffer type with >>>> type of >>>> 529 // destination not source. >>> >>> >>> On 15.04.15 11:57, prasanta sadhukhan wrote: >>>> Hi, >>>> >>>> I would like a review for a solution of this bug in jdk9. >>>> The clip was ignored during surface->sw blit in d3d pipeline. The >>>> fix is to use the clip parameter to calculate the blit coordinates >>>> correctly. >>>> >>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8044788 >>>> webrev:http://cr.openjdk.java.net/~psadhukhan/8044788/webrev.00/ >>>> >>>> Regards >>>> Prasanta >>> >>> >>> -- >>> Best regards, Sergey. >>> >>> >>> >>> >>> >>> >>> >> >> > -- Best regards, Sergey. From jayathirth.d.v at oracle.com Wed Mar 2 11:31:54 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 2 Mar 2016 03:31:54 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : drawImage misses background's alpha channel Message-ID: Hi, Please review the following fix in JDK9: Bug : https://bugs.openjdk.java.net/browse/JDK-8139183 Webrev : http://cr.openjdk.java.net/~jdv/8139183/webrev.00/ Issue : When we scale any buffered image using drawImage() API which takes scale coordinates we are losing alpha channel in background color. Root cause : We are creating opaque temporary image when we have background color and scale is happening in renderImageXform() API of DrawImage.java. By making it opaque we are losing translucency. Solution : Instead of creating opaque RGB temporary image use ARGB temporary image to maintain translucency of image. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Wed Mar 2 13:17:19 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 2 Mar 2016 05:17:19 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : drawImage misses background's alpha channel In-Reply-To: References: Message-ID: <05dd240c-0f46-486e-b9d9-be51984415d3@default> Hi, I have updated the changes to select proper Buffer Image type based on source transparency and not just using ARGB directly. Please find the updated webrev for review: http://cr.openjdk.java.net/~jdv/8139183/webrev.01/ Thanks, Jay From: Jayathirth D V Sent: Wednesday, March 02, 2016 5:02 PM To: 2d-dev at openjdk.java.net; Philip Race; Prasanta Sadhukhan Subject: Review Request for JDK-8139183 : drawImage misses background's alpha channel Hi, Please review the following fix in JDK9: Bug : https://bugs.openjdk.java.net/browse/JDK-8139183 Webrev : http://cr.openjdk.java.net/~jdv/8139183/webrev.00/ Issue : When we scale any buffered image using drawImage() API which takes scale coordinates we are losing alpha channel in background color. Root cause : We are creating opaque temporary image when we have background color and scale is happening in renderImageXform() API of DrawImage.java. By making it opaque we are losing translucency. Solution : Instead of creating opaque RGB temporary image use ARGB temporary image to maintain translucency of image. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Wed Mar 2 14:01:43 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 2 Mar 2016 17:01:43 +0300 Subject: [OpenJDK 2D-Dev] Review Request: (JDK-8044788) [D3D] clip is ignored during surface->sw blit In-Reply-To: <4037a83a-d998-4f27-88ae-40b6fb86bb1f@default> References: <56CAB11E.7040703@oracle.com> <56CACD71.9040006@oracle.com> <56CD97EA.9030904@oracle.com> <56D52454.4040006@oracle.com> <56D62CCA.6000801@oracle.com> <4037a83a-d998-4f27-88ae-40b6fb86bb1f@default> Message-ID: <56D6F247.1040308@oracle.com> Looks fine. On 02.03.16 10:16, Prahalad Kumar Narayanan wrote: > Dear Sergey, Phil & Java 2D-Dev Group > > Good day to you. > > A Quick Follow-up to Bug: JDK-8044788 > Bug Link: https://bugs.openjdk.java.net/browse/JDK-8044788 > > Review Fixes: > The following fixes have been incorporated collating all of Sergey's valuable feedback. > 1. File: D3DBlitLoops.java. Method: complexClipBlit. > Removed if(...) condition pertaining to setting of BufferedImage's pixel format type. > Proper type has been set with appropriate comment indicating why the setting has been done. > 2. File: IncorrectClipSurface2SW.java. > The option -Dsun.java2d.d3d=true has been removed from the test file. > This will be required inorder to run the test across all platforms (incl. non-windows platforms) > > The webrev incorporating the above review fixes is available under: > http://cr.openjdk.java.net/~psadhukhan/prahlad/webrev.02/ > > Kindly review the fix and provide your opinion. > > Thank you for your time in review > Have a good day > > Prahalad N. > > > -----Original Message----- > From: Sergey Bylokhov > Sent: Wednesday, March 02, 2016 5:29 AM > To: Prahalad kumar Narayanan; Philip Race; prasanta sadhukhan; 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request: (JDK-8044788) [D3D] clip is ignored during surface->sw blit > > Hi, Prahalad. > The fix looks good. But you should remove the "-Dsun.java2d.d3d" option in the test(don't change it to true) otherwise it will fail on non-windows platform, because the "=false" is ignored if pipeline is not available. > > On 01.03.16 8:10, Prahalad kumar Narayanan wrote: >> Hello Everyone, 2D-Dev Group. >> >> Good day to you. >> >> First, thanks to Sergey for his accurate review & suggestions. >> I.Review Fixes: >> 1. Upon inspection into the code, I found that native D3D >> interfaces support on-the-fly conversion of pixels in D3DSurface to >> Sysmem based BufferedImage of type "IntARGB only". >> 2. Hence, the if(...) condition present in complexClipBlit >> method is not valid. This change has been incorporated in the code now. >> 3. The webrev.01 is available for review under: >> http://cr.openjdk.java.net/~psadhukhan/prahlad/webrev.01/ >> >> II.Next Steps: >> 1. Further discussions with Sergey revealed the fact that, >> D3DBlitLoops.java registers a primitive for SurfaceToSw blit as follows: >> static void register() { >> ... >> new D3DSurfaceToSwBlit(SurfaceType.IntArgb, >> D3DSurfaceData.ST_INT_ARGB); >> ... >> }; >> 2. The above code implies that there is no single/ direct blit >> method if the destination is of SurfaceType.IntArgbPre. >> 3. When no registered primitive exists for the source and >> destination type, the conversion might be implemented through >> GeneralBlits causing many CPU cycles. >> 4. Sergey suggested that, we could enhance the native D3D >> interface to support on the fly conversion to destination of type >> IntArgbPre. This will help improve the performance. But this can be >> taken up after the current fix. >> >> Kindly review the fix for current issue from the link - >> http://cr.openjdk.java.net/~psadhukhan/prahlad/webrev.01/ >> >> Thank you for your time in review >> Have a good day >> >> Prahalad N. >> >> >> On 2/24/2016 5:15 PM, Sergey Bylokhov wrote: >>> Hi, Prahalad. >>> The fix looks good in general. I have only one question: >>> In the complexClipBlit() you have this code: >>> 552 // Type- indicates the pixel format of Sysmem based BufferedImage. >>> 553 // Native side D3D interface supports copying surface contents to >>> 554 // ST_INT_ARGB, ST_INT_ARGB_PRE and other pixel formats >>> 555 final int type = typeval == D3DSurfaceData.ST_INT_ARGB_PRE ? >>> 556 BufferedImage.TYPE_INT_ARGB_PRE : >>> 557 BufferedImage.TYPE_INT_ARGB; >>> >>> This code was copied from the OGL version of the fix and it have two >>> assumptions: >>> - The type of the native texture can be ST_INT_ARGB_PRE, or can >>> contains "other"(???) value. Please take a look to the >>> OGLBlitLoops.java code. In OGL we register two different blits: >>> OGLSurfaceToSwBlit blitSurfaceToIntArgbPre = new >>> OGLSurfaceToSwBlit(SurfaceType.IntArgbPre,OGLSurfaceData.PF_INT_ARGB_ >>> PRE); >>> // surface->sw ops >>> new >>> OGLSurfaceToSwBlit(SurfaceType.IntArgb,OGLSurfaceData.PF_INT_ARGB), >>> blitSurfaceToIntArgbPre, >>> >>> So in OGL when the blit is called the type can be PF_INT_ARGB_PRE or >>> PF_INT_ARGB. This is why we have "if" statement in the complexClipBlit. >>> >>> - The second assumption is that the native code is able to copy the >>> d3d texture to the system memory and do conversion on the fly. The >>> ogl code have such conversion(argb_pre is converted to argb in the >>> OGLBlitLoops.c in the flip() method). Do you know our native d3d part >>> is able to do the same? If yes, then we should register separate >>> blits in D3DBlitLoops to cover different source/destination and >>> change the "if". >>> >>> On 22.02.16 11:57, Prahalad kumar Narayanan wrote: >>>> Hello Everyone, 2D-Dev Group >>>> >>>> I continued to inspect the bug : JDK-8044788: [D3D] Clip is ignored >>>> during Surface > Sw Blit issue. >>>> Link : https://bugs.openjdk.java.net/browse/JDK-8044788 >>>> >>>> Here is a quick brief on root cause, solutions experimented and the >>>> webrev link for review. >>>> Kindly go through each of these items and provide your review so >>>> that we could check-in the bug fix. >>>> >>>> Root Cause: >>>> 1. D3DSurfaceToSw Blit does not pass clip value to the native cpp >>>> interface 2. Even if the clip were to be passed through JNI, the >>>> native interface ignores the clip because it uses d3d's StretRect >>>> API. >>>> 3. Henceforth, in the current implementation, clipping in >>>> SurfaceToSw usecase will work ' only ' for Rect bounds provided >>>> proper src(x, y), dst(x, y), width and height are provided. >>>> 4. It can be noted that : the proper src(x, y), dst(x, y) are also >>>> not calculated considering the intersection of these rectangles with >>>> the clip bounds. >>>> >>>> Different Solutions & Results >>>> 1. Three solutions are feasible to fix this issue: >>>> a. Solution 1: Convert the input Surface to Sysmem image, >>>> followed by regular Blit. To optimize this further, the conversion >>>> can be taken up only for Shape clips. >>>> b. Solution 2: Using existing classes in D3DBlitLoops, >>>> execute SwToSurface (copy dest to accel Surface), SurfaceToSurface >>>> (supports clip), SurfaceToSw (full copy) in order. >>>> c. Solution 3: Modify the native side interfaces to accept >>>> clip and execute Solution2 's logic in native code. >>>> 2. Upon various experiments, Solution 1 has been found to be faster >>>> than the rest. >>>> a. This can be attributed to fewer draw /or copy iterations >>>> compared to the other two solutions. >>>> b. In addition to the above fact, the code retains the same >>>> approach as used by the OGL pipeline making it easier to understand. >>>> >>>> Webrev Link: >>>> http://cr.openjdk.java.net/~psadhukhan/prahlad/webrev.00/ >>>> Sufficient comments have been added so that developers could easily >>>> get understanding of the issue and solution checked in. >>>> >>>> Thank you >>>> Have a great day >>>> >>>> Prahalad N. >>>> >>>> >>>> >>>> Subject: Re: [OpenJDK 2D-Dev] Review Request: (JDK-8044788) [D3D] >>>> clip >>>> is ignored during surface->sw blit >>>> Date: Wed, 15 Apr 2015 16:17:37 +0300 >>>> From: Sergey Bylokhov >>>> To: prasanta sadhukhan , >>>> 2d-dev at openjdk.java.net >>>> >>>> >>>> >>>> Hi, Prasanta. >>>> The same approach was used in OGL pipeline for the reason. Because >>>> we use glReadPixels and there is no way to apply the clip. So we >>>> read pixels to the temporary buffer and apply the clip later. Can >>>> you additionaly investigate is it possible to apply the clip in d3d >>>> directly or not? >>>> >>>> Note that this [1] comment is not correct in d3d, because d3d have >>>> only one direct blit D3d surface -> SW which is >>>> D3DSurfaceToSwBlit(IntArgb, ST_INT_ARGB), all other blits will be >>>> done via temporary buffer in D3DGeneralBlit. >>>> >>>> [1] >>>>> 523 // We can convert argb_pre data from D3d surface in two >>>>> places: >>>>> 524 // - During D3d surface -> SW blit >>>>> 525 // - During SW -> SW blit >>>>> 526 // The first one is faster when we use opaque D3d >>>>> surface, because in >>>>> 527 // this case we simply skip conversion and use color >>>>> components as is. >>>>> 528 // Because of this we align intermediate buffer type with >>>>> type of >>>>> 529 // destination not source. >>>> >>>> >>>> On 15.04.15 11:57, prasanta sadhukhan wrote: >>>>> Hi, >>>>> >>>>> I would like a review for a solution of this bug in jdk9. >>>>> The clip was ignored during surface->sw blit in d3d pipeline. The >>>>> fix is to use the clip parameter to calculate the blit coordinates >>>>> correctly. >>>>> >>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8044788 >>>>> webrev:http://cr.openjdk.java.net/~psadhukhan/8044788/webrev.00/ >>>>> >>>>> Regards >>>>> Prasanta >>>> >>>> >>>> -- >>>> Best regards, Sergey. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Mar 2 14:46:09 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 2 Mar 2016 17:46:09 +0300 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : drawImage misses background's alpha channel In-Reply-To: <05dd240c-0f46-486e-b9d9-be51984415d3@default> References: <05dd240c-0f46-486e-b9d9-be51984415d3@default> Message-ID: <56D6FCB1.1030607@oracle.com> Hi, Jay. The fix looks fine. Probably we can improve the fix a little bit. It seems that makeBufferedImage() is used only in two places in DrawImage.java. And after the fix in both cases we have: int type = ((srcData.getTransparency() == Transparency.OPAQUE) ? BufferedImage.TYPE_INT_RGB : BufferedImage.TYPE_INT_ARGB); img = makeBufferedImage(img, null, type, sx1, sy1, sx2, sy2); Probably makeBufferedImage can be made private and the logic for type selection can be moved to the makeBufferedImage()? the "type" parameter can be changed to "opaque" or something like that. In this we can move the description why we use ARGB instead of ARGB_PRE to the spec of makeBufferedImage(). Can we check VolatileImage in the test as well? and probably some other image types(argb_pre, etc)? On 02.03.16 16:17, Jayathirth D V wrote: > Hi, > > I have updated the changes to select proper Buffer Image type based on > source transparency and not just using ARGB directly. > > Please find the updated webrev for review: > > http://cr.openjdk.java.net/~jdv/8139183/webrev.01/ > > Thanks, > > Jay > > *From:* Jayathirth D V > *Sent:* Wednesday, March 02, 2016 5:02 PM > *To:* 2d-dev at openjdk.java.net; Philip Race; Prasanta Sadhukhan > *Subject:* Review Request for JDK-8139183 : drawImage misses > background's alpha channel > > Hi, > > _Please review the following fix in JDK9:_ > > __ > > Bug : https://bugs.openjdk.java.net/browse/JDK-8139183 > > Webrev : http://cr.openjdk.java.net/~jdv/8139183/webrev.00/ > > Issue : When we scale any buffered image using drawImage() API which > takes scale coordinates we are losing alpha channel in background color. > > Root cause : We are creating opaque temporary image when we have > background color and scale is happening in renderImageXform() API of > DrawImage.java. By making it opaque we are losing translucency. > > Solution : Instead of creating opaque RGB temporary image use ARGB > temporary image to maintain translucency of image. > > Thanks, > > Jay > -- Best regards, Sergey. From philip.race at oracle.com Wed Mar 2 16:03:52 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 02 Mar 2016 08:03:52 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8138749, , Revisited: PrinterJob.printDialog() does not support multi-mon, always displayed on primary In-Reply-To: <56D55F11.3050800@oracle.com> References: <569F6AC2.7060103@oracle.com> <569FFC46.8040700@oracle.com> <56A0A8BD.306@oracle.com> <56A169C3.2010903@oracle.com> <56A1D85B.3020804@oracle.com> <56AA2B15.90900@oracle.com> <56AB323C.7090706@oracle.com> <56B14B37.6010706@oracle.com> <56B19180.70207@oracle.com> <56B244AA.8060707@oracle.com> <56B2E223.1050400@oracle.com> <56B463FC.9070702@oracle.com> <56BBC0D7.9080401@oracle.com> <56C1B8D9.7030805@oracle.com> <56C50EED.2020609@oracle.com> <56C55CFB.50707@oracle.com> <56D55F11.3050800@oracle.com> Message-ID: <56D70EE8.20500@oracle.com> approved. On 3/1/16, 1:21 AM, prasanta sadhukhan wrote: > Hi Phil, > > Please find my modified webrev > http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.07/ > > which takes care of the fact (as compared to webrev.06), if dialog > does not exceed window bounds at both left or top, do not modify > dialog at both x,y coordinates. Only modify that coordinate in which > dialog has exceeded window bounds. > > Regards > Prasanta > On 2/18/2016 11:26 AM, prasanta sadhukhan wrote: >> Hi Phil, >> >> On 2/18/2016 5:53 AM, Philip Race wrote: >>> I don't think we should be adjusting the width of the dialog so that >>> part of the change >>> should be removed which will simplify the logic. >>> >>> Of course anyone calling the ServiceUI public API does not have any >>> insight into the size of the dialog since it is not explicitly >>> returned so they >>> could inadvertently position it so that it is partly off the bottom >>> or right side of the screen. >>> Perhaps in a multi-monitor environment with two side by side screens >>> they want >>> the dialog centred such that it spans the two >>> Perhaps they want these behaviours but I suspect not so it is >>> probably worth >>> 'fixing up' some of these cases. >>> >>> So our 'tweaking' of the position should be limited so that it >>> positions the dialog >>> such that its moved the minimum amount to that the bottom right is >>> on (the specified) screen. >>> If - and only if - that would cause it to be partially off the >>> top-left - possible only >>> if the screen is smaller than the dialog, should we adjust the >>> dialog position in >>> a way that allows the bottom or right to be off-screen. >>> >> Please find the updated webrev that takes care of your review comments >> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.06/ >> >> As for the below proposal, I guess we could handle it as part of >> future enhancements, can we? >> >> Regards >> Prasanta >>> I think we are mostly there and it is not important enough to add >>> new API to >>> ServiceUI at this time to give us hints about how to handle such >>> cases - although >>> I have given it some consideration. >>> >>> There are lot of things we *could* do here >>> - expose the pageDialog (now commented out) >>> - provide a way to pass in the owner Dialog or Frame and stop >>> ignoring it in ServiceDialog. >>> That would be useful for modality. >>> - provide those hints I mentioned >>> >>> I think #1 and #2 on that list might be the most useful to some >>> people but >>> don't invalidate this fix even if it might need to be revised if we >>> ever do them .. >>> >>> >>> -phil. >>> >>> On 2/15/16, 3:39 AM, prasanta sadhukhan wrote: >>>> Hi Phil, >>>> >>>> >> Line 836 should be >>>> >> x = (bounds.x + bounds.width) - dlgBound.width >>>> >>>> can be wrong if (bounds.x + bounds.width) - dlgBound.width comes >>>> out to be negative (or less than window top-left x,y coordiantes) >>>> For example, if window bounds for secondary monitor is (x=1600, >>>> y=0, width=489, height =361) >>>> and dialog bounds is (x=1650, y=50, width=460, height=353) then >>>> above calc will set x to (1629, 8) [ x=1600+489-460=1629 , y = >>>> 0+361-353=8] which is ok >>>> >>>> but if we have dialog bounds (x=1650, y=50, width=554, height = >>>> 390) then x becomes 1600+489-554=1535 and y becomes 0+361-390= -29 >>>> so it will go beyond the top-left corner of window. >>>> >>>> so for those cases, I am >>>> setting x and y to bounds.x, bounds.y so that atmost it can go to >>>> top-left and not beyond that and >>>> also setting the dialog width /height to window width/height (as if >>>> we keep the same dialog width,height it will become 1600,0,554,390 >>>> which is again going beyond window bounds 1600,0,489,361) >>>> >>>> Please find the updated webrev >>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.05/ >>>> >>>> Regards >>>> Prasanta >>>> On 2/11/2016 4:29 AM, Phil Race wrote: >>>>> if (dlgBounds.x + dlgBounds.width > bounds.x + bounds.width) { >>>>> 836 x = bounds.x; >>>>> >>>>> >>>>> Line 836 should be >>>>> x = (bounds.x + bounds.width) - dlgBound.width >>>>> >>>>> Same logic for y. >>>>> >>>>> 841 pageDialog.setBounds(x, y, bounds.width, >>>>> bounds.height); >>>>> >>>>> That looks wrong. It is setting the width/height of the dialog to >>>>> be the width/height of the screen. Should be dlgBounds.width + >>>>> height. >>>>> >>>>> >>>>> -phil. >>>>> >>>>> >>>>> On 02/05/2016 12:57 AM, prasanta sadhukhan wrote: >>>>>> >>>>>> >>>>>> On 2/4/2016 11:01 AM, prasanta sadhukhan wrote: >>>>>>> Hi Phil, >>>>>>> >>>>>>> On 2/3/2016 11:49 PM, Phil Race wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I think it is worth addressing all this at once and I think it >>>>>>>> can be done >>>>>>>> entirely in RPJ, leaving ServiceUI alone. Ie fix it just for >>>>>>>> the case where >>>>>>>> RPJ displays the dialog(s). >>>>>>> RPJ display the dialog only for pageDialog >>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/b9a92b2a8b37/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java#l820 >>>>>>> >>>>>>> whereas ServiceUI display the printDialog >>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/b9a92b2a8b37/src/java.desktop/share/classes/javax/print/ServiceUI.java#l227 >>>>>>> >>>>>>> >>>>>>> So, are you saying we fix it only for pageDialog and leave out >>>>>>> printDialog()? >>>>>>> >>>>>> Please find updated webrev >>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.04/ >>>>>> >>>>>> where both RPJ and ServiceUI is modified to show the dialog >>>>>> entirely on-screen. >>>>>> I could not leave ServiceUI without modification as >>>>>> // if portion of dialog is not within the gc boundary >>>>>> if (!gcBounds.contains(dlgBounds)) { >>>>>> // put in the center relative to parent frame/dialog >>>>>> dialog.setLocationRelativeTo(owner); >>>>>> } >>>>>> this code was drawing the dialog in primary so I have to delete >>>>>> the code to make sure dialog is displayed on secondary to fix the >>>>>> bug. And since anyway, I was modifying ServiceUI, I thought of >>>>>> adding the >>>>>> check to draw the printDialog on screen in ServiceUI same as >>>>>> pageDialog. >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>>> Regards >>>>>>> Prasanta >>>>>>>> When an application calls ServiceUI directly, it >>>>>>>> can decide where it would like the dialog subject to the >>>>>>>> existing constraint. >>>>>>>> >>>>>>>> The test really should be one test so that the behaviours can be >>>>>>>> tested as one with lower overhead. >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> On 02/02/2016 09:34 PM, prasanta sadhukhan wrote: >>>>>>>>> Hi Phil, >>>>>>>>> >>>>>>>>> On 2/3/2016 6:05 AM, Phil Race wrote: >>>>>>>>>> The RasterPrinterJob changes are now OK however >>>>>>>>>> >>>>>>>>>> - I am not sure I understand how removing the check in ServiceUI >>>>>>>>>> will address the issue about the dialog needing to be >>>>>>>>>> entirely on-screen. >>>>>>>>>> It reads to me as if now you allow that in preference to >>>>>>>>>> having it centred. >>>>>>>>>> But I am not sure the old code would have worked in all cases >>>>>>>>>> either >>>>>>>>>> since centering on a very small owner window in the corner of >>>>>>>>>> the screen >>>>>>>>>> would result in the same problem. >>>>>>>>> Since this issue was about showing the dialog on primary vs >>>>>>>>> secondary, can we address this issue of showing the dialog >>>>>>>>> entirely on-screen in separate bug id (since this issue is >>>>>>>>> present in primary screen too if dialog is bigger than >>>>>>>>> top-level window)? >>>>>>>>> The present change in ServiceUI address the issue of showing >>>>>>>>> the dialog on secondary monitor if dialog is bigger than >>>>>>>>> top-level. >>>>>>>>>> Probably what is needed is some code that moves it just >>>>>>>>>> enough to fit. >>>>>>>>>> ie downwards if it is off the top, left if it is off the >>>>>>>>>> right and so forth ? >>>>>>>>>> >>>>>>>>>> - The two tests do not share the same bug ID. I expected they >>>>>>>>>> should now do so .. and I was further supposing you would merge >>>>>>>>>> the two tests into one. >>>>>>>>> I will change the bug id of 2nd test. Is it ok if I keep these >>>>>>>>> 2 tests separate to make it easier? >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Prasanta >>>>>>>>>> >>>>>>>>>> -phil. >>>>>>>>>> >>>>>>>>>> On 01/29/2016 01:34 AM, prasanta sadhukhan wrote: >>>>>>>>>>> Hi Phil, >>>>>>>>>>> >>>>>>>>>>> On 1/28/2016 8:22 PM, Philip Race wrote: >>>>>>>>>>>> "in consistent" >>>>>>>>>>>> >>>>>>>>>>>> On 1/21/16, 11:20 PM, prasanta sadhukhan wrote: >>>>>>>>>>>>> Hi Phil, >>>>>>>>>>>>> >>>>>>>>>>>>> I checked with NATIVE print dialog and with other app >>>>>>>>>>>>> print dialog, they are positioning the dialog a little >>>>>>>>>>>>> ahead of top-left corner (not at 1/3rd of the window as we >>>>>>>>>>>>> are doing now) >>>>>>>>>>>>> so I did the same and positioned the dialog in consistent >>>>>>>>>>>>> with our NATIVE print dialog. >>>>>>>>>>>> >>>>>>>>>>>> You mean consistently. in consistent means the opposite >>>>>>>>>>>> Please adjust that in the code comment. >>>>>>>>>>>> >>>>>>>>>>>> 50,50 is probably OK so long as you verified this is >>>>>>>>>>>> approximately >>>>>>>>>>>> what happens on most platforms, not just windows 8 or similar. >>>>>>>>>>>> I don't think you will find complete consistency because >>>>>>>>>>>> apps may >>>>>>>>>>>> control it and use different dialogs even on the same >>>>>>>>>>>> platform. >>>>>>>>>>>> On hidpi screens this may be closer to the top-left than >>>>>>>>>>>> you intend >>>>>>>>>>>> but I expect it is fine. >>>>>>>>>>>> >>>>>>>>>>> Tested on windows, linux and it works ok. We showed the >>>>>>>>>>> dialog at x+50,y+50 where x,y is the coordinate of the >>>>>>>>>>> active window. >>>>>>>>>>> Do not have local mac system to test multimonitor setup. >>>>>>>>>>>> The one main thing that you should verify is what happens >>>>>>>>>>>> in the case >>>>>>>>>>>> a native app top-level window is smaller than the print >>>>>>>>>>>> dialog and is positioned >>>>>>>>>>>> at the bottom right (of the right-most display). Does the >>>>>>>>>>>> native app ensure >>>>>>>>>>>> that the dialog is wholly on-screen ? I don't think your >>>>>>>>>>>> code will do that. >>>>>>>>>>>> And Safari on Mac at least seems to do that. I guess that >>>>>>>>>>>> most apps try >>>>>>>>>>>> their best to keep the dialog wholly on-screen. >>>>>>>>>>>> >>>>>>>>>>> Tested this case where window bounds is smaller than print >>>>>>>>>>> dialog >>>>>>>>>>> but because of this check in ServiceUI.java >>>>>>>>>>> >>>>>>>>>>> // if portion of dialog is not within the gc boundary >>>>>>>>>>> if (!gcBounds.contains(dlgBounds)) { >>>>>>>>>>> // put in the center relative to parent >>>>>>>>>>> frame/dialog >>>>>>>>>>> dialog.setLocationRelativeTo(owner); >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> the dialog is shown in the primary window. >>>>>>>>>>> I saw we did not have this check for pageDialog(attr) where >>>>>>>>>>> the dialog is shown in secondary monitor despite gcBounds >>>>>>>>>>> smaller than print dialog. >>>>>>>>>>> Therefore, I removed this check from ServiceUI. >>>>>>>>>>> >>>>>>>>>>> Please find the updated webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.03/ >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> Prasanta >>>>>>>>>>>> -phil. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Please find the updated webrev >>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.02/ >>>>>>>>>>>>> >>>>>>>>>>>>> Regards >>>>>>>>>>>>> Prasanta >>>>>>>>>>>>> On 1/22/2016 4:59 AM, Phil Race wrote: >>>>>>>>>>>>>> That is definitely better .. although I wonder if it >>>>>>>>>>>>>> would be even better >>>>>>>>>>>>>> if you found when there is an 'active' window that you >>>>>>>>>>>>>> tried to >>>>>>>>>>>>>> position the dialog such that it is near the upper-left >>>>>>>>>>>>>> corner of that window ? >>>>>>>>>>>>>> Please experiment and see how that looks compared to what >>>>>>>>>>>>>> other apps are doing. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -phil. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 01/21/2016 01:45 AM, prasanta sadhukhan wrote: >>>>>>>>>>>>>>> Hi Phil, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please find the updated webrev >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.01/ >>>>>>>>>>>>>>> which do away with the change in ServiceUI. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>> Prasanta >>>>>>>>>>>>>>> On 1/21/2016 2:59 AM, Phil Race wrote: >>>>>>>>>>>>>>>> The changes in ServiceUI seem like they can cause the >>>>>>>>>>>>>>>> spec. to be contradicted. >>>>>>>>>>>>>>>> It says >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * @param gc used to select screen. null means >>>>>>>>>>>>>>>> primary or default screen. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> but you update the code such that it will use the >>>>>>>>>>>>>>>> active window. >>>>>>>>>>>>>>>> If that is on a secondary screen but null was passed in. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I am not entirely sure why ServiceUI needs to be >>>>>>>>>>>>>>>> changed at all. >>>>>>>>>>>>>>>> It is just the caller of ServiceUI .. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -phil. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 01/20/2016 03:08 AM, prasanta sadhukhan wrote: >>>>>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8138749 >>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.00/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Please review a fix for a long standing issue whereby >>>>>>>>>>>>>>>>> it is seen that >>>>>>>>>>>>>>>>> PrinterJob.printDialog(attr set) does not support >>>>>>>>>>>>>>>>> multi-monitor setup. When this API is invoked, the >>>>>>>>>>>>>>>>> print dialog is always displayed on the default screen >>>>>>>>>>>>>>>>> device regardless of where the application is running. >>>>>>>>>>>>>>>>> This is because this method >>>>>>>>>>>>>>>>> uses ServiceDialog class for creating the dialog and >>>>>>>>>>>>>>>>> that indeed supports passing a GC in which we would >>>>>>>>>>>>>>>>> like to have the dialog. But printer job always uses >>>>>>>>>>>>>>>>> the GraphicsConfig of the default screen device >>>>>>>>>>>>>>>>> resulting in print dialog to be shown on primary >>>>>>>>>>>>>>>>> device/monitor. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I have not considered pageDialog() for this fix. Will >>>>>>>>>>>>>>>>> create a separate bugid and send a patch for that as >>>>>>>>>>>>>>>>> well once this fix is approved. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>> Prasanta >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> > From philip.race at oracle.com Wed Mar 2 22:20:58 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 02 Mar 2016 14:20:58 -0800 Subject: [OpenJDK 2D-Dev] Review Request: (JDK-8044788) [D3D] clip is ignored during surface->sw blit In-Reply-To: <56D6F247.1040308@oracle.com> References: <56CAB11E.7040703@oracle.com> <56CACD71.9040006@oracle.com> <56CD97EA.9030904@oracle.com> <56D52454.4040006@oracle.com> <56D62CCA.6000801@oracle.com> <4037a83a-d998-4f27-88ae-40b6fb86bb1f@default> <56D6F247.1040308@oracle.com> Message-ID: <56D7674A.8030104@oracle.com> +1 >The fix looks good. But you should remove the "-Dsun.java2d.d3d" option in th > test(don't change it to true) otherwise it will fail on non-windows platform, because the "=false" is > ignored if pipeline is not available. Removing it was the right thing to do but it would not have failed on non-windows platforms .. they simply would not recognise the system property name. No more harm than -Dfoo.bar=xyz -phil. On 3/2/16, 6:01 AM, Sergey Bylokhov wrote: > Looks fine. > > On 02.03.16 10:16, Prahalad Kumar Narayanan wrote: >> Dear Sergey, Phil & Java 2D-Dev Group >> >> Good day to you. >> >> A Quick Follow-up to Bug: JDK-8044788 >> Bug Link: https://bugs.openjdk.java.net/browse/JDK-8044788 >> >> Review Fixes: >> The following fixes have been incorporated collating all of Sergey's >> valuable feedback. >> 1. File: D3DBlitLoops.java. Method: complexClipBlit. >> Removed if(...) condition pertaining to setting of >> BufferedImage's pixel format type. >> Proper type has been set with appropriate comment indicating >> why the setting has been done. >> 2. File: IncorrectClipSurface2SW.java. >> The option -Dsun.java2d.d3d=true has been removed from the >> test file. >> This will be required inorder to run the test across all >> platforms (incl. non-windows platforms) >> >> The webrev incorporating the above review fixes is available under: >> http://cr.openjdk.java.net/~psadhukhan/prahlad/webrev.02/ >> >> Kindly review the fix and provide your opinion. >> >> Thank you for your time in review >> Have a good day >> >> Prahalad N. >> >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Wednesday, March 02, 2016 5:29 AM >> To: Prahalad kumar Narayanan; Philip Race; prasanta sadhukhan; >> 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] Review Request: (JDK-8044788) [D3D] >> clip is ignored during surface->sw blit >> >> Hi, Prahalad. >> The fix looks good. But you should remove the "-Dsun.java2d.d3d" >> option in the test(don't change it to true) otherwise it will fail on >> non-windows platform, because the "=false" is ignored if pipeline is >> not available. >> >> On 01.03.16 8:10, Prahalad kumar Narayanan wrote: >>> Hello Everyone, 2D-Dev Group. >>> >>> Good day to you. >>> >>> First, thanks to Sergey for his accurate review & suggestions. >>> I.Review Fixes: >>> 1. Upon inspection into the code, I found that native D3D >>> interfaces support on-the-fly conversion of pixels in D3DSurface to >>> Sysmem based BufferedImage of type "IntARGB only". >>> 2. Hence, the if(...) condition present in complexClipBlit >>> method is not valid. This change has been incorporated in the code now. >>> 3. The webrev.01 is available for review under: >>> http://cr.openjdk.java.net/~psadhukhan/prahlad/webrev.01/ >>> >>> II.Next Steps: >>> 1. Further discussions with Sergey revealed the fact that, >>> D3DBlitLoops.java registers a primitive for SurfaceToSw blit as >>> follows: >>> static void register() { >>> ... >>> new D3DSurfaceToSwBlit(SurfaceType.IntArgb, >>> D3DSurfaceData.ST_INT_ARGB); >>> ... >>> }; >>> 2. The above code implies that there is no single/ direct blit >>> method if the destination is of SurfaceType.IntArgbPre. >>> 3. When no registered primitive exists for the source and >>> destination type, the conversion might be implemented through >>> GeneralBlits causing many CPU cycles. >>> 4. Sergey suggested that, we could enhance the native D3D >>> interface to support on the fly conversion to destination of type >>> IntArgbPre. This will help improve the performance. But this can be >>> taken up after the current fix. >>> >>> Kindly review the fix for current issue from the link - >>> http://cr.openjdk.java.net/~psadhukhan/prahlad/webrev.01/ >>> >>> Thank you for your time in review >>> Have a good day >>> >>> Prahalad N. >>> >>> >>> On 2/24/2016 5:15 PM, Sergey Bylokhov wrote: >>>> Hi, Prahalad. >>>> The fix looks good in general. I have only one question: >>>> In the complexClipBlit() you have this code: >>>> 552 // Type- indicates the pixel format of Sysmem based BufferedImage. >>>> 553 // Native side D3D interface supports copying surface contents to >>>> 554 // ST_INT_ARGB, ST_INT_ARGB_PRE and other pixel formats >>>> 555 final int type = typeval == D3DSurfaceData.ST_INT_ARGB_PRE ? >>>> 556 BufferedImage.TYPE_INT_ARGB_PRE : >>>> 557 BufferedImage.TYPE_INT_ARGB; >>>> >>>> This code was copied from the OGL version of the fix and it have two >>>> assumptions: >>>> - The type of the native texture can be ST_INT_ARGB_PRE, or can >>>> contains "other"(???) value. Please take a look to the >>>> OGLBlitLoops.java code. In OGL we register two different blits: >>>> OGLSurfaceToSwBlit blitSurfaceToIntArgbPre = new >>>> OGLSurfaceToSwBlit(SurfaceType.IntArgbPre,OGLSurfaceData.PF_INT_ARGB_ >>>> PRE); >>>> // surface->sw ops >>>> new >>>> OGLSurfaceToSwBlit(SurfaceType.IntArgb,OGLSurfaceData.PF_INT_ARGB), >>>> blitSurfaceToIntArgbPre, >>>> >>>> So in OGL when the blit is called the type can be PF_INT_ARGB_PRE or >>>> PF_INT_ARGB. This is why we have "if" statement in the >>>> complexClipBlit. >>>> >>>> - The second assumption is that the native code is able to copy the >>>> d3d texture to the system memory and do conversion on the fly. The >>>> ogl code have such conversion(argb_pre is converted to argb in the >>>> OGLBlitLoops.c in the flip() method). Do you know our native d3d part >>>> is able to do the same? If yes, then we should register separate >>>> blits in D3DBlitLoops to cover different source/destination and >>>> change the "if". >>>> >>>> On 22.02.16 11:57, Prahalad kumar Narayanan wrote: >>>>> Hello Everyone, 2D-Dev Group >>>>> >>>>> I continued to inspect the bug : JDK-8044788: [D3D] Clip is ignored >>>>> during Surface > Sw Blit issue. >>>>> Link : https://bugs.openjdk.java.net/browse/JDK-8044788 >>>>> >>>>> Here is a quick brief on root cause, solutions experimented and the >>>>> webrev link for review. >>>>> Kindly go through each of these items and provide your review so >>>>> that we could check-in the bug fix. >>>>> >>>>> Root Cause: >>>>> 1. D3DSurfaceToSw Blit does not pass clip value to the native cpp >>>>> interface 2. Even if the clip were to be passed through JNI, the >>>>> native interface ignores the clip because it uses d3d's StretRect >>>>> API. >>>>> 3. Henceforth, in the current implementation, clipping in >>>>> SurfaceToSw usecase will work ' only ' for Rect bounds provided >>>>> proper src(x, y), dst(x, y), width and height are provided. >>>>> 4. It can be noted that : the proper src(x, y), dst(x, y) are also >>>>> not calculated considering the intersection of these rectangles with >>>>> the clip bounds. >>>>> >>>>> Different Solutions & Results >>>>> 1. Three solutions are feasible to fix this issue: >>>>> a. Solution 1: Convert the input Surface to Sysmem image, >>>>> followed by regular Blit. To optimize this further, the conversion >>>>> can be taken up only for Shape clips. >>>>> b. Solution 2: Using existing classes in D3DBlitLoops, >>>>> execute SwToSurface (copy dest to accel Surface), SurfaceToSurface >>>>> (supports clip), SurfaceToSw (full copy) in order. >>>>> c. Solution 3: Modify the native side interfaces to accept >>>>> clip and execute Solution2 's logic in native code. >>>>> 2. Upon various experiments, Solution 1 has been found to be faster >>>>> than the rest. >>>>> a. This can be attributed to fewer draw /or copy iterations >>>>> compared to the other two solutions. >>>>> b. In addition to the above fact, the code retains the same >>>>> approach as used by the OGL pipeline making it easier to understand. >>>>> >>>>> Webrev Link: >>>>> http://cr.openjdk.java.net/~psadhukhan/prahlad/webrev.00/ >>>>> Sufficient comments have been added so that developers could easily >>>>> get understanding of the issue and solution checked in. >>>>> >>>>> Thank you >>>>> Have a great day >>>>> >>>>> Prahalad N. >>>>> >>>>> >>>>> >>>>> Subject: Re: [OpenJDK 2D-Dev] Review Request: (JDK-8044788) [D3D] >>>>> clip >>>>> is ignored during surface->sw blit >>>>> Date: Wed, 15 Apr 2015 16:17:37 +0300 >>>>> From: Sergey Bylokhov >>>>> To: prasanta sadhukhan , >>>>> 2d-dev at openjdk.java.net >>>>> >>>>> >>>>> >>>>> Hi, Prasanta. >>>>> The same approach was used in OGL pipeline for the reason. Because >>>>> we use glReadPixels and there is no way to apply the clip. So we >>>>> read pixels to the temporary buffer and apply the clip later. Can >>>>> you additionaly investigate is it possible to apply the clip in d3d >>>>> directly or not? >>>>> >>>>> Note that this [1] comment is not correct in d3d, because d3d have >>>>> only one direct blit D3d surface -> SW which is >>>>> D3DSurfaceToSwBlit(IntArgb, ST_INT_ARGB), all other blits will be >>>>> done via temporary buffer in D3DGeneralBlit. >>>>> >>>>> [1] >>>>>> 523 // We can convert argb_pre data from D3d surface in >>>>>> two >>>>>> places: >>>>>> 524 // - During D3d surface -> SW blit >>>>>> 525 // - During SW -> SW blit >>>>>> 526 // The first one is faster when we use opaque D3d >>>>>> surface, because in >>>>>> 527 // this case we simply skip conversion and use color >>>>>> components as is. >>>>>> 528 // Because of this we align intermediate buffer >>>>>> type with >>>>>> type of >>>>>> 529 // destination not source. >>>>> >>>>> >>>>> On 15.04.15 11:57, prasanta sadhukhan wrote: >>>>>> Hi, >>>>>> >>>>>> I would like a review for a solution of this bug in jdk9. >>>>>> The clip was ignored during surface->sw blit in d3d pipeline. The >>>>>> fix is to use the clip parameter to calculate the blit coordinates >>>>>> correctly. >>>>>> >>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8044788 >>>>>> webrev:http://cr.openjdk.java.net/~psadhukhan/8044788/webrev.00/ >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >> >> >> -- >> Best regards, Sergey. >> > > From philip.race at oracle.com Wed Mar 2 22:22:20 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 02 Mar 2016 14:22:20 -0800 Subject: [OpenJDK 2D-Dev] Review Request: (JDK-8044788) [D3D] clip is ignored during surface->sw blit In-Reply-To: <56D7674A.8030104@oracle.com> References: <56CAB11E.7040703@oracle.com> <56CACD71.9040006@oracle.com> <56CD97EA.9030904@oracle.com> <56D52454.4040006@oracle.com> <56D62CCA.6000801@oracle.com> <4037a83a-d998-4f27-88ae-40b6fb86bb1f@default> <56D6F247.1040308@oracle.com> <56D7674A.8030104@oracle.com> Message-ID: <56D7679C.8090207@oracle.com> Oh sorry, I just realised you did not add the new bug id to the test it should now say @bug 8041644 8044788 No need for an updated webrev .. -phil. On 3/2/16, 2:20 PM, Philip Race wrote: > +1 > > >The fix looks good. But you should remove the "-Dsun.java2d.d3d" > option in th > > test(don't change it to true) otherwise it will fail on non-windows > platform, because the "=false" is > > ignored if pipeline is not available. > > Removing it was the right thing to do but it would not have failed on > non-windows > platforms .. they simply would not recognise the system property name. > No more harm than -Dfoo.bar=xyz > > -phil. > > On 3/2/16, 6:01 AM, Sergey Bylokhov wrote: >> Looks fine. >> >> On 02.03.16 10:16, Prahalad Kumar Narayanan wrote: >>> Dear Sergey, Phil & Java 2D-Dev Group >>> >>> Good day to you. >>> >>> A Quick Follow-up to Bug: JDK-8044788 >>> Bug Link: https://bugs.openjdk.java.net/browse/JDK-8044788 >>> >>> Review Fixes: >>> The following fixes have been incorporated collating all of Sergey's >>> valuable feedback. >>> 1. File: D3DBlitLoops.java. Method: complexClipBlit. >>> Removed if(...) condition pertaining to setting of >>> BufferedImage's pixel format type. >>> Proper type has been set with appropriate comment indicating >>> why the setting has been done. >>> 2. File: IncorrectClipSurface2SW.java. >>> The option -Dsun.java2d.d3d=true has been removed from the >>> test file. >>> This will be required inorder to run the test across all >>> platforms (incl. non-windows platforms) >>> >>> The webrev incorporating the above review fixes is available under: >>> http://cr.openjdk.java.net/~psadhukhan/prahlad/webrev.02/ >>> >>> Kindly review the fix and provide your opinion. >>> >>> Thank you for your time in review >>> Have a good day >>> >>> Prahalad N. >>> >>> >>> -----Original Message----- >>> From: Sergey Bylokhov >>> Sent: Wednesday, March 02, 2016 5:29 AM >>> To: Prahalad kumar Narayanan; Philip Race; prasanta sadhukhan; >>> 2d-dev at openjdk.java.net >>> Subject: Re: [OpenJDK 2D-Dev] Review Request: (JDK-8044788) [D3D] >>> clip is ignored during surface->sw blit >>> >>> Hi, Prahalad. >>> The fix looks good. But you should remove the "-Dsun.java2d.d3d" >>> option in the test(don't change it to true) otherwise it will fail >>> on non-windows platform, because the "=false" is ignored if pipeline >>> is not available. >>> >>> On 01.03.16 8:10, Prahalad kumar Narayanan wrote: >>>> Hello Everyone, 2D-Dev Group. >>>> >>>> Good day to you. >>>> >>>> First, thanks to Sergey for his accurate review & suggestions. >>>> I.Review Fixes: >>>> 1. Upon inspection into the code, I found that native D3D >>>> interfaces support on-the-fly conversion of pixels in D3DSurface to >>>> Sysmem based BufferedImage of type "IntARGB only". >>>> 2. Hence, the if(...) condition present in complexClipBlit >>>> method is not valid. This change has been incorporated in the code >>>> now. >>>> 3. The webrev.01 is available for review under: >>>> http://cr.openjdk.java.net/~psadhukhan/prahlad/webrev.01/ >>>> >>>> II.Next Steps: >>>> 1. Further discussions with Sergey revealed the fact that, >>>> D3DBlitLoops.java registers a primitive for SurfaceToSw blit as >>>> follows: >>>> static void register() { >>>> ... >>>> new D3DSurfaceToSwBlit(SurfaceType.IntArgb, >>>> D3DSurfaceData.ST_INT_ARGB); >>>> ... >>>> }; >>>> 2. The above code implies that there is no single/ direct blit >>>> method if the destination is of SurfaceType.IntArgbPre. >>>> 3. When no registered primitive exists for the source and >>>> destination type, the conversion might be implemented through >>>> GeneralBlits causing many CPU cycles. >>>> 4. Sergey suggested that, we could enhance the native D3D >>>> interface to support on the fly conversion to destination of type >>>> IntArgbPre. This will help improve the performance. But this can be >>>> taken up after the current fix. >>>> >>>> Kindly review the fix for current issue from the link - >>>> http://cr.openjdk.java.net/~psadhukhan/prahlad/webrev.01/ >>>> >>>> Thank you for your time in review >>>> Have a good day >>>> >>>> Prahalad N. >>>> >>>> >>>> On 2/24/2016 5:15 PM, Sergey Bylokhov wrote: >>>>> Hi, Prahalad. >>>>> The fix looks good in general. I have only one question: >>>>> In the complexClipBlit() you have this code: >>>>> 552 // Type- indicates the pixel format of Sysmem based >>>>> BufferedImage. >>>>> 553 // Native side D3D interface supports copying surface contents to >>>>> 554 // ST_INT_ARGB, ST_INT_ARGB_PRE and other pixel formats >>>>> 555 final int type = typeval == D3DSurfaceData.ST_INT_ARGB_PRE ? >>>>> 556 BufferedImage.TYPE_INT_ARGB_PRE : >>>>> 557 BufferedImage.TYPE_INT_ARGB; >>>>> >>>>> This code was copied from the OGL version of the fix and it have two >>>>> assumptions: >>>>> - The type of the native texture can be ST_INT_ARGB_PRE, or can >>>>> contains "other"(???) value. Please take a look to the >>>>> OGLBlitLoops.java code. In OGL we register two different blits: >>>>> OGLSurfaceToSwBlit blitSurfaceToIntArgbPre = new >>>>> OGLSurfaceToSwBlit(SurfaceType.IntArgbPre,OGLSurfaceData.PF_INT_ARGB_ >>>>> PRE); >>>>> // surface->sw ops >>>>> new >>>>> OGLSurfaceToSwBlit(SurfaceType.IntArgb,OGLSurfaceData.PF_INT_ARGB), >>>>> blitSurfaceToIntArgbPre, >>>>> >>>>> So in OGL when the blit is called the type can be PF_INT_ARGB_PRE or >>>>> PF_INT_ARGB. This is why we have "if" statement in the >>>>> complexClipBlit. >>>>> >>>>> - The second assumption is that the native code is able to copy the >>>>> d3d texture to the system memory and do conversion on the fly. The >>>>> ogl code have such conversion(argb_pre is converted to argb in the >>>>> OGLBlitLoops.c in the flip() method). Do you know our native d3d part >>>>> is able to do the same? If yes, then we should register separate >>>>> blits in D3DBlitLoops to cover different source/destination and >>>>> change the "if". >>>>> >>>>> On 22.02.16 11:57, Prahalad kumar Narayanan wrote: >>>>>> Hello Everyone, 2D-Dev Group >>>>>> >>>>>> I continued to inspect the bug : JDK-8044788: [D3D] Clip is ignored >>>>>> during Surface > Sw Blit issue. >>>>>> Link : https://bugs.openjdk.java.net/browse/JDK-8044788 >>>>>> >>>>>> Here is a quick brief on root cause, solutions experimented and the >>>>>> webrev link for review. >>>>>> Kindly go through each of these items and provide your review so >>>>>> that we could check-in the bug fix. >>>>>> >>>>>> Root Cause: >>>>>> 1. D3DSurfaceToSw Blit does not pass clip value to the native cpp >>>>>> interface 2. Even if the clip were to be passed through JNI, the >>>>>> native interface ignores the clip because it uses d3d's StretRect >>>>>> API. >>>>>> 3. Henceforth, in the current implementation, clipping in >>>>>> SurfaceToSw usecase will work ' only ' for Rect bounds provided >>>>>> proper src(x, y), dst(x, y), width and height are provided. >>>>>> 4. It can be noted that : the proper src(x, y), dst(x, y) are also >>>>>> not calculated considering the intersection of these rectangles with >>>>>> the clip bounds. >>>>>> >>>>>> Different Solutions & Results >>>>>> 1. Three solutions are feasible to fix this issue: >>>>>> a. Solution 1: Convert the input Surface to Sysmem image, >>>>>> followed by regular Blit. To optimize this further, the conversion >>>>>> can be taken up only for Shape clips. >>>>>> b. Solution 2: Using existing classes in D3DBlitLoops, >>>>>> execute SwToSurface (copy dest to accel Surface), SurfaceToSurface >>>>>> (supports clip), SurfaceToSw (full copy) in order. >>>>>> c. Solution 3: Modify the native side interfaces to accept >>>>>> clip and execute Solution2 's logic in native code. >>>>>> 2. Upon various experiments, Solution 1 has been found to be faster >>>>>> than the rest. >>>>>> a. This can be attributed to fewer draw /or copy >>>>>> iterations >>>>>> compared to the other two solutions. >>>>>> b. In addition to the above fact, the code retains the >>>>>> same >>>>>> approach as used by the OGL pipeline making it easier to understand. >>>>>> >>>>>> Webrev Link: >>>>>> http://cr.openjdk.java.net/~psadhukhan/prahlad/webrev.00/ >>>>>> Sufficient comments have been added so that developers could easily >>>>>> get understanding of the issue and solution checked in. >>>>>> >>>>>> Thank you >>>>>> Have a great day >>>>>> >>>>>> Prahalad N. >>>>>> >>>>>> >>>>>> >>>>>> Subject: Re: [OpenJDK 2D-Dev] Review Request: (JDK-8044788) >>>>>> [D3D] >>>>>> clip >>>>>> is ignored during surface->sw blit >>>>>> Date: Wed, 15 Apr 2015 16:17:37 +0300 >>>>>> From: Sergey Bylokhov >>>>>> To: prasanta sadhukhan , >>>>>> 2d-dev at openjdk.java.net >>>>>> >>>>>> >>>>>> >>>>>> Hi, Prasanta. >>>>>> The same approach was used in OGL pipeline for the reason. Because >>>>>> we use glReadPixels and there is no way to apply the clip. So we >>>>>> read pixels to the temporary buffer and apply the clip later. Can >>>>>> you additionaly investigate is it possible to apply the clip in d3d >>>>>> directly or not? >>>>>> >>>>>> Note that this [1] comment is not correct in d3d, because d3d have >>>>>> only one direct blit D3d surface -> SW which is >>>>>> D3DSurfaceToSwBlit(IntArgb, ST_INT_ARGB), all other blits will be >>>>>> done via temporary buffer in D3DGeneralBlit. >>>>>> >>>>>> [1] >>>>>>> 523 // We can convert argb_pre data from D3d surface >>>>>>> in two >>>>>>> places: >>>>>>> 524 // - During D3d surface -> SW blit >>>>>>> 525 // - During SW -> SW blit >>>>>>> 526 // The first one is faster when we use opaque D3d >>>>>>> surface, because in >>>>>>> 527 // this case we simply skip conversion and use color >>>>>>> components as is. >>>>>>> 528 // Because of this we align intermediate buffer >>>>>>> type with >>>>>>> type of >>>>>>> 529 // destination not source. >>>>>> >>>>>> >>>>>> On 15.04.15 11:57, prasanta sadhukhan wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I would like a review for a solution of this bug in jdk9. >>>>>>> The clip was ignored during surface->sw blit in d3d pipeline. The >>>>>>> fix is to use the clip parameter to calculate the blit coordinates >>>>>>> correctly. >>>>>>> >>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8044788 >>>>>>> webrev:http://cr.openjdk.java.net/~psadhukhan/8044788/webrev.00/ >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, Sergey. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> Best regards, Sergey. >>> >> >> From james.graham at oracle.com Wed Mar 2 23:48:39 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 2 Mar 2016 15:48:39 -0800 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : drawImage misses background's alpha channel In-Reply-To: <05dd240c-0f46-486e-b9d9-be51984415d3@default> References: <05dd240c-0f46-486e-b9d9-be51984415d3@default> Message-ID: <56D77BD7.2020302@oracle.com> The logic here has mixed up the opacities and what needs to be done about them. If the source image is opaque, then this is not a BG operation at all because the bg color would not show through an opaque image, so checking the srcData is both wrong and should be a NOP here. If we get into that block with a srcData that is opaque then something has gone wrong somewhere else. In particular, isBgOp should have returned false in that case. The transparency that matters is when the bg color has transparency and that is not what is being tested here. The test for xRGB and ARGB should be using the bg color... ...jim On 3/2/16 5:17 AM, Jayathirth D V wrote: > Hi, > > I have updated the changes to select proper Buffer Image type based on > source transparency and not just using ARGB directly. > > Please find the updated webrev for review: > > http://cr.openjdk.java.net/~jdv/8139183/webrev.01/ > > Thanks, > > Jay > > *From:* Jayathirth D V > *Sent:* Wednesday, March 02, 2016 5:02 PM > *To:* 2d-dev at openjdk.java.net; Philip Race; Prasanta Sadhukhan > *Subject:* Review Request for JDK-8139183 : drawImage misses > background's alpha channel > > Hi, > > _Please review the following fix in JDK9:_ > > __ > > Bug : https://bugs.openjdk.java.net/browse/JDK-8139183 > > Webrev : http://cr.openjdk.java.net/~jdv/8139183/webrev.00/ > > Issue : When we scale any buffered image using drawImage() API which > takes scale coordinates we are losing alpha channel in background color. > > Root cause : We are creating opaque temporary image when we have > background color and scale is happening in renderImageXform() API of > DrawImage.java. By making it opaque we are losing translucency. > > Solution : Instead of creating opaque RGB temporary image use ARGB > temporary image to maintain translucency of image. > > Thanks, > > Jay > From jayathirth.d.v at oracle.com Thu Mar 3 06:33:26 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 2 Mar 2016 22:33:26 -0800 (PST) Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8138749, , Revisited: PrinterJob.printDialog() does not support multi-mon, always displayed on primary In-Reply-To: <56D70EE8.20500@oracle.com> References: <569F6AC2.7060103@oracle.com> <569FFC46.8040700@oracle.com> <56A0A8BD.306@oracle.com> <56A169C3.2010903@oracle.com> <56A1D85B.3020804@oracle.com> <56AA2B15.90900@oracle.com> <56AB323C.7090706@oracle.com> <56B14B37.6010706@oracle.com> <56B19180.70207@oracle.com> <56B244AA.8060707@oracle.com> <56B2E223.1050400@oracle.com> <56B463FC.9070702@oracle.com> <56BBC0D7.9080401@oracle.com> <56C1B8D9.7030805@oracle.com> <56C50EED.2020609@oracle.com> <56C55CFB.50707@oracle.com> <56D55F11.3050800@oracle.com> <56D70EE8.20500@oracle.com> Message-ID: <3849a2ad-32b0-4a25-9d78-bbc7f646153f@default> Hi Prasanta, Fix looks fine to me. We are taking care of both having the dialog within proper monitor and also making sure that it stays within the window bounds and also consistent with native print dialog. Thanks, Jay -----Original Message----- From: Philip Race Sent: Wednesday, March 02, 2016 9:34 PM To: prasanta sadhukhan Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9] RFR: JDK-8138749, , Revisited: PrinterJob.printDialog() does not support multi-mon, always displayed on primary approved. On 3/1/16, 1:21 AM, prasanta sadhukhan wrote: > Hi Phil, > > Please find my modified webrev > http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.07/ > > which takes care of the fact (as compared to webrev.06), if dialog > does not exceed window bounds at both left or top, do not modify > dialog at both x,y coordinates. Only modify that coordinate in which > dialog has exceeded window bounds. > > Regards > Prasanta > On 2/18/2016 11:26 AM, prasanta sadhukhan wrote: >> Hi Phil, >> >> On 2/18/2016 5:53 AM, Philip Race wrote: >>> I don't think we should be adjusting the width of the dialog so that >>> part of the change should be removed which will simplify the logic. >>> >>> Of course anyone calling the ServiceUI public API does not have any >>> insight into the size of the dialog since it is not explicitly >>> returned so they could inadvertently position it so that it is >>> partly off the bottom or right side of the screen. >>> Perhaps in a multi-monitor environment with two side by side screens >>> they want the dialog centred such that it spans the two Perhaps they >>> want these behaviours but I suspect not so it is probably worth >>> 'fixing up' some of these cases. >>> >>> So our 'tweaking' of the position should be limited so that it >>> positions the dialog such that its moved the minimum amount to that >>> the bottom right is on (the specified) screen. >>> If - and only if - that would cause it to be partially off the >>> top-left - possible only if the screen is smaller than the dialog, >>> should we adjust the dialog position in a way that allows the bottom >>> or right to be off-screen. >>> >> Please find the updated webrev that takes care of your review >> comments http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.06/ >> >> As for the below proposal, I guess we could handle it as part of >> future enhancements, can we? >> >> Regards >> Prasanta >>> I think we are mostly there and it is not important enough to add >>> new API to ServiceUI at this time to give us hints about how to >>> handle such cases - although I have given it some consideration. >>> >>> There are lot of things we *could* do here >>> - expose the pageDialog (now commented out) >>> - provide a way to pass in the owner Dialog or Frame and stop >>> ignoring it in ServiceDialog. >>> That would be useful for modality. >>> - provide those hints I mentioned >>> >>> I think #1 and #2 on that list might be the most useful to some >>> people but don't invalidate this fix even if it might need to be >>> revised if we ever do them .. >>> >>> >>> -phil. >>> >>> On 2/15/16, 3:39 AM, prasanta sadhukhan wrote: >>>> Hi Phil, >>>> >>>> >> Line 836 should be >>>> >> x = (bounds.x + bounds.width) - dlgBound.width >>>> >>>> can be wrong if (bounds.x + bounds.width) - dlgBound.width comes >>>> out to be negative (or less than window top-left x,y coordiantes) >>>> For example, if window bounds for secondary monitor is (x=1600, >>>> y=0, width=489, height =361) >>>> and dialog bounds is (x=1650, y=50, width=460, height=353) then >>>> above calc will set x to (1629, 8) [ x=1600+489-460=1629 , y = >>>> 0+361-353=8] which is ok >>>> >>>> but if we have dialog bounds (x=1650, y=50, width=554, height = >>>> 390) then x becomes 1600+489-554=1535 and y becomes 0+361-390= -29 >>>> so it will go beyond the top-left corner of window. >>>> >>>> so for those cases, I am >>>> setting x and y to bounds.x, bounds.y so that atmost it can go to >>>> top-left and not beyond that and >>>> also setting the dialog width /height to window width/height (as if >>>> we keep the same dialog width,height it will become 1600,0,554,390 >>>> which is again going beyond window bounds 1600,0,489,361) >>>> >>>> Please find the updated webrev >>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.05/ >>>> >>>> Regards >>>> Prasanta >>>> On 2/11/2016 4:29 AM, Phil Race wrote: >>>>> if (dlgBounds.x + dlgBounds.width > bounds.x + bounds.width) { >>>>> 836 x = bounds.x; >>>>> >>>>> >>>>> Line 836 should be >>>>> x = (bounds.x + bounds.width) - dlgBound.width >>>>> >>>>> Same logic for y. >>>>> >>>>> 841 pageDialog.setBounds(x, y, bounds.width, >>>>> bounds.height); >>>>> >>>>> That looks wrong. It is setting the width/height of the dialog to >>>>> be the width/height of the screen. Should be dlgBounds.width + >>>>> height. >>>>> >>>>> >>>>> -phil. >>>>> >>>>> >>>>> On 02/05/2016 12:57 AM, prasanta sadhukhan wrote: >>>>>> >>>>>> >>>>>> On 2/4/2016 11:01 AM, prasanta sadhukhan wrote: >>>>>>> Hi Phil, >>>>>>> >>>>>>> On 2/3/2016 11:49 PM, Phil Race wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I think it is worth addressing all this at once and I think it >>>>>>>> can be done >>>>>>>> entirely in RPJ, leaving ServiceUI alone. Ie fix it just for >>>>>>>> the case where >>>>>>>> RPJ displays the dialog(s). >>>>>>> RPJ display the dialog only for pageDialog >>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/b9a92b2a8b37/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java#l820 >>>>>>> >>>>>>> whereas ServiceUI display the printDialog >>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/b9a92b2a8b37/src/java.desktop/share/classes/javax/print/ServiceUI.java#l227 >>>>>>> >>>>>>> >>>>>>> So, are you saying we fix it only for pageDialog and leave out >>>>>>> printDialog()? >>>>>>> >>>>>> Please find updated webrev >>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.04/ >>>>>> >>>>>> where both RPJ and ServiceUI is modified to show the dialog >>>>>> entirely on-screen. >>>>>> I could not leave ServiceUI without modification as >>>>>> // if portion of dialog is not within the gc boundary >>>>>> if (!gcBounds.contains(dlgBounds)) { >>>>>> // put in the center relative to parent frame/dialog >>>>>> dialog.setLocationRelativeTo(owner); >>>>>> } >>>>>> this code was drawing the dialog in primary so I have to delete >>>>>> the code to make sure dialog is displayed on secondary to fix the >>>>>> bug. And since anyway, I was modifying ServiceUI, I thought of >>>>>> adding the >>>>>> check to draw the printDialog on screen in ServiceUI same as >>>>>> pageDialog. >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>>> Regards >>>>>>> Prasanta >>>>>>>> When an application calls ServiceUI directly, it >>>>>>>> can decide where it would like the dialog subject to the >>>>>>>> existing constraint. >>>>>>>> >>>>>>>> The test really should be one test so that the behaviours can be >>>>>>>> tested as one with lower overhead. >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> On 02/02/2016 09:34 PM, prasanta sadhukhan wrote: >>>>>>>>> Hi Phil, >>>>>>>>> >>>>>>>>> On 2/3/2016 6:05 AM, Phil Race wrote: >>>>>>>>>> The RasterPrinterJob changes are now OK however >>>>>>>>>> >>>>>>>>>> - I am not sure I understand how removing the check in ServiceUI >>>>>>>>>> will address the issue about the dialog needing to be >>>>>>>>>> entirely on-screen. >>>>>>>>>> It reads to me as if now you allow that in preference to >>>>>>>>>> having it centred. >>>>>>>>>> But I am not sure the old code would have worked in all cases >>>>>>>>>> either >>>>>>>>>> since centering on a very small owner window in the corner of >>>>>>>>>> the screen >>>>>>>>>> would result in the same problem. >>>>>>>>> Since this issue was about showing the dialog on primary vs >>>>>>>>> secondary, can we address this issue of showing the dialog >>>>>>>>> entirely on-screen in separate bug id (since this issue is >>>>>>>>> present in primary screen too if dialog is bigger than >>>>>>>>> top-level window)? >>>>>>>>> The present change in ServiceUI address the issue of showing >>>>>>>>> the dialog on secondary monitor if dialog is bigger than >>>>>>>>> top-level. >>>>>>>>>> Probably what is needed is some code that moves it just >>>>>>>>>> enough to fit. >>>>>>>>>> ie downwards if it is off the top, left if it is off the >>>>>>>>>> right and so forth ? >>>>>>>>>> >>>>>>>>>> - The two tests do not share the same bug ID. I expected they >>>>>>>>>> should now do so .. and I was further supposing you would merge >>>>>>>>>> the two tests into one. >>>>>>>>> I will change the bug id of 2nd test. Is it ok if I keep these >>>>>>>>> 2 tests separate to make it easier? >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Prasanta >>>>>>>>>> >>>>>>>>>> -phil. >>>>>>>>>> >>>>>>>>>> On 01/29/2016 01:34 AM, prasanta sadhukhan wrote: >>>>>>>>>>> Hi Phil, >>>>>>>>>>> >>>>>>>>>>> On 1/28/2016 8:22 PM, Philip Race wrote: >>>>>>>>>>>> "in consistent" >>>>>>>>>>>> >>>>>>>>>>>> On 1/21/16, 11:20 PM, prasanta sadhukhan wrote: >>>>>>>>>>>>> Hi Phil, >>>>>>>>>>>>> >>>>>>>>>>>>> I checked with NATIVE print dialog and with other app >>>>>>>>>>>>> print dialog, they are positioning the dialog a little >>>>>>>>>>>>> ahead of top-left corner (not at 1/3rd of the window as we >>>>>>>>>>>>> are doing now) >>>>>>>>>>>>> so I did the same and positioned the dialog in consistent >>>>>>>>>>>>> with our NATIVE print dialog. >>>>>>>>>>>> >>>>>>>>>>>> You mean consistently. in consistent means the opposite >>>>>>>>>>>> Please adjust that in the code comment. >>>>>>>>>>>> >>>>>>>>>>>> 50,50 is probably OK so long as you verified this is >>>>>>>>>>>> approximately >>>>>>>>>>>> what happens on most platforms, not just windows 8 or similar. >>>>>>>>>>>> I don't think you will find complete consistency because >>>>>>>>>>>> apps may >>>>>>>>>>>> control it and use different dialogs even on the same >>>>>>>>>>>> platform. >>>>>>>>>>>> On hidpi screens this may be closer to the top-left than >>>>>>>>>>>> you intend >>>>>>>>>>>> but I expect it is fine. >>>>>>>>>>>> >>>>>>>>>>> Tested on windows, linux and it works ok. We showed the >>>>>>>>>>> dialog at x+50,y+50 where x,y is the coordinate of the >>>>>>>>>>> active window. >>>>>>>>>>> Do not have local mac system to test multimonitor setup. >>>>>>>>>>>> The one main thing that you should verify is what happens >>>>>>>>>>>> in the case >>>>>>>>>>>> a native app top-level window is smaller than the print >>>>>>>>>>>> dialog and is positioned >>>>>>>>>>>> at the bottom right (of the right-most display). Does the >>>>>>>>>>>> native app ensure >>>>>>>>>>>> that the dialog is wholly on-screen ? I don't think your >>>>>>>>>>>> code will do that. >>>>>>>>>>>> And Safari on Mac at least seems to do that. I guess that >>>>>>>>>>>> most apps try >>>>>>>>>>>> their best to keep the dialog wholly on-screen. >>>>>>>>>>>> >>>>>>>>>>> Tested this case where window bounds is smaller than print >>>>>>>>>>> dialog >>>>>>>>>>> but because of this check in ServiceUI.java >>>>>>>>>>> >>>>>>>>>>> // if portion of dialog is not within the gc boundary >>>>>>>>>>> if (!gcBounds.contains(dlgBounds)) { >>>>>>>>>>> // put in the center relative to parent >>>>>>>>>>> frame/dialog >>>>>>>>>>> dialog.setLocationRelativeTo(owner); >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> the dialog is shown in the primary window. >>>>>>>>>>> I saw we did not have this check for pageDialog(attr) where >>>>>>>>>>> the dialog is shown in secondary monitor despite gcBounds >>>>>>>>>>> smaller than print dialog. >>>>>>>>>>> Therefore, I removed this check from ServiceUI. >>>>>>>>>>> >>>>>>>>>>> Please find the updated webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.03/ >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> Prasanta >>>>>>>>>>>> -phil. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Please find the updated webrev >>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.02/ >>>>>>>>>>>>> >>>>>>>>>>>>> Regards >>>>>>>>>>>>> Prasanta >>>>>>>>>>>>> On 1/22/2016 4:59 AM, Phil Race wrote: >>>>>>>>>>>>>> That is definitely better .. although I wonder if it >>>>>>>>>>>>>> would be even better >>>>>>>>>>>>>> if you found when there is an 'active' window that you >>>>>>>>>>>>>> tried to >>>>>>>>>>>>>> position the dialog such that it is near the upper-left >>>>>>>>>>>>>> corner of that window ? >>>>>>>>>>>>>> Please experiment and see how that looks compared to what >>>>>>>>>>>>>> other apps are doing. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -phil. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 01/21/2016 01:45 AM, prasanta sadhukhan wrote: >>>>>>>>>>>>>>> Hi Phil, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please find the updated webrev >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.01/ >>>>>>>>>>>>>>> which do away with the change in ServiceUI. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>> Prasanta >>>>>>>>>>>>>>> On 1/21/2016 2:59 AM, Phil Race wrote: >>>>>>>>>>>>>>>> The changes in ServiceUI seem like they can cause the >>>>>>>>>>>>>>>> spec. to be contradicted. >>>>>>>>>>>>>>>> It says >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * @param gc used to select screen. null means >>>>>>>>>>>>>>>> primary or default screen. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> but you update the code such that it will use the >>>>>>>>>>>>>>>> active window. >>>>>>>>>>>>>>>> If that is on a secondary screen but null was passed in. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I am not entirely sure why ServiceUI needs to be >>>>>>>>>>>>>>>> changed at all. >>>>>>>>>>>>>>>> It is just the caller of ServiceUI .. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -phil. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 01/20/2016 03:08 AM, prasanta sadhukhan wrote: >>>>>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8138749 >>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.00/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Please review a fix for a long standing issue whereby >>>>>>>>>>>>>>>>> it is seen that >>>>>>>>>>>>>>>>> PrinterJob.printDialog(attr set) does not support >>>>>>>>>>>>>>>>> multi-monitor setup. When this API is invoked, the >>>>>>>>>>>>>>>>> print dialog is always displayed on the default screen >>>>>>>>>>>>>>>>> device regardless of where the application is running. >>>>>>>>>>>>>>>>> This is because this method >>>>>>>>>>>>>>>>> uses ServiceDialog class for creating the dialog and >>>>>>>>>>>>>>>>> that indeed supports passing a GC in which we would >>>>>>>>>>>>>>>>> like to have the dialog. But printer job always uses >>>>>>>>>>>>>>>>> the GraphicsConfig of the default screen device >>>>>>>>>>>>>>>>> resulting in print dialog to be shown on primary >>>>>>>>>>>>>>>>> device/monitor. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I have not considered pageDialog() for this fix. Will >>>>>>>>>>>>>>>>> create a separate bugid and send a patch for that as >>>>>>>>>>>>>>>>> well once this fix is approved. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>> Prasanta >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> > From prasanta.sadhukhan at oracle.com Thu Mar 3 10:39:09 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Thu, 3 Mar 2016 16:09:09 +0530 Subject: [OpenJDK 2D-Dev] [9]: RFR JDK-8058316, , lookupDefaultPrintService returns null on Solaris 11 Message-ID: <56D8144D.9050308@oracle.com> Hi Phil, Bug: https://bugs.openjdk.java.net/browse/JDK-8058316 webrev: http://cr.openjdk.java.net/~psadhukhan/8058316/webrev.00/ The issue was on some Solaris 11 hosts lookupDefaultPrintService() returns null while lpstat -d reports an ipp printer. The issue was found to exist in linux too since it uses CUPS. What was happening was that CUPSPrinter.java#getDefaultPrinter() searches for server-defined default destination by connection to CUPS server but if the user sets the default printer using "lpoptions -d " command, server will not have any knowledge of this settings and this user-set default printer (which is stored in ~/.cups/lpoptions file) was not searched and getDefaultPrinter() returns null since it could not find any server default printer. Fix is to call cupsGetDest API to search for a lpoptions-defined default printer and if not set, then search for server-defined destination. I could not provide a regression testcase for this as it involves setting default printer using lpoptions command. Regards Prasanta From yuri.nesterenko at oracle.com Thu Mar 3 11:31:46 2016 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Thu, 3 Mar 2016 14:31:46 +0300 Subject: [OpenJDK 2D-Dev] [9]: RFR JDK-8058316, , lookupDefaultPrintService returns null on Solaris 11 In-Reply-To: <56D8144D.9050308@oracle.com> References: <56D8144D.9050308@oracle.com> Message-ID: <56D820A2.2080602@oracle.com> Thank you, Prasanta! Could you please add this or similar explanation to that JDK-8058316? Please use all the words/phrases a desperate tester would search. If we cannot have a regression test we should have enough search terms to find this bug in case of (apparent) regression. -yan On 03/03/2016 01:39 PM, prasanta sadhukhan wrote: > Hi Phil, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8058316 > webrev: http://cr.openjdk.java.net/~psadhukhan/8058316/webrev.00/ > > The issue was on some Solaris 11 hosts lookupDefaultPrintService() > returns null while lpstat -d reports an ipp printer. > The issue was found to exist in linux too since it uses CUPS. > > What was happening was that CUPSPrinter.java#getDefaultPrinter() > searches for server-defined default destination by connection to CUPS > server but > if the user sets the default printer using "lpoptions -d " > command, server will not have any knowledge of this settings and this > user-set default printer (which is stored in ~/.cups/lpoptions file) was > not searched > and getDefaultPrinter() returns null since it could not find any server > default printer. > > Fix is to call cupsGetDest API to search for a lpoptions-defined default > printer and if not set, then search for server-defined destination. > > I could not provide a regression testcase for this as it involves > setting default printer using lpoptions command. > > Regards > Prasanta > From jayathirth.d.v at oracle.com Thu Mar 3 14:13:00 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 3 Mar 2016 06:13:00 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : drawImage misses background's alpha channel In-Reply-To: <56D77BD7.2020302@oracle.com> References: <05dd240c-0f46-486e-b9d9-be51984415d3@default> <56D77BD7.2020302@oracle.com> Message-ID: Hi, Thanks for pointing to logical mistake I made Jim. I have made changes to use bg color transparency to determine what type of buffered image should be used in makeBufferedImage(). Also based on Sergey's suggestions included other source types like ARGB_PRE in test case and made makeBufferedImage() API private since it is only used in DrawImage.java. But I was not able to include VolatileImage as source type as I didn't find a way to automate the test to verify alpha value after drawImage(), since there is no API to get pixel value from VolatileImage. While debugging I was able to make sure that in case VolatileImage also proper type is selected before makeBufferedImage() is called. Please review updated webrev: http://cr.openjdk.java.net/~jdv/8139183/webrev.02/ Thanks, Jay -----Original Message----- From: Jim Graham Sent: Thursday, March 03, 2016 5:19 AM To: Jayathirth D V; 2d-dev at openjdk.java.net; Philip Race; Prasanta Sadhukhan Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : drawImage misses background's alpha channel The logic here has mixed up the opacities and what needs to be done about them. If the source image is opaque, then this is not a BG operation at all because the bg color would not show through an opaque image, so checking the srcData is both wrong and should be a NOP here. If we get into that block with a srcData that is opaque then something has gone wrong somewhere else. In particular, isBgOp should have returned false in that case. The transparency that matters is when the bg color has transparency and that is not what is being tested here. The test for xRGB and ARGB should be using the bg color... ...jim On 3/2/16 5:17 AM, Jayathirth D V wrote: > Hi, > > I have updated the changes to select proper Buffer Image type based on > source transparency and not just using ARGB directly. > > Please find the updated webrev for review: > > http://cr.openjdk.java.net/~jdv/8139183/webrev.01/ > > Thanks, > > Jay > > *From:* Jayathirth D V > *Sent:* Wednesday, March 02, 2016 5:02 PM > *To:* 2d-dev at openjdk.java.net; Philip Race; Prasanta Sadhukhan > *Subject:* Review Request for JDK-8139183 : drawImage misses > background's alpha channel > > Hi, > > _Please review the following fix in JDK9:_ > > __ > > Bug : https://bugs.openjdk.java.net/browse/JDK-8139183 > > Webrev : http://cr.openjdk.java.net/~jdv/8139183/webrev.00/ > > Issue : When we scale any buffered image using drawImage() API which > takes scale coordinates we are losing alpha channel in background color. > > Root cause : We are creating opaque temporary image when we have > background color and scale is happening in renderImageXform() API of > DrawImage.java. By making it opaque we are losing translucency. > > Solution : Instead of creating opaque RGB temporary image use ARGB > temporary image to maintain translucency of image. > > Thanks, > > Jay > From philip.race at oracle.com Thu Mar 3 21:51:39 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 03 Mar 2016 13:51:39 -0800 Subject: [OpenJDK 2D-Dev] [9]: RFR JDK-8058316, , lookupDefaultPrintService returns null on Solaris 11 In-Reply-To: <56D8144D.9050308@oracle.com> References: <56D8144D.9050308@oracle.com> Message-ID: <56D8B1EB.3030302@oracle.com> I think there is a small memory leak with this code : https://www.cups.org/documentation.php/doc-2.0/api-cups.html#cupsGetDests "Use the cupsFreeDests function to free the destination list" Also I am not sure if you are using cupsGetDest as intended :- 202 cups_dest_t *dest = j2d_cupsGetDest(NULL, NULL, num_dests, dests); 203 if (dest != NULL) { 204 for (i = 0; i < num_dests; i++) { 205 if (dest[i].is_default) { 206 defaultPrinter = dest[i].name; 207 break; 208 } 209 } 210 } I don't think you are expected to iterate over the result here. I think it is already the pointer to the default. In other words the function will already have done what your for loop is doing. If there is no default you will iterate off the end .. -phil. On 03/03/2016 02:39 AM, prasanta sadhukhan wrote: > Hi Phil, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8058316 > webrev: http://cr.openjdk.java.net/~psadhukhan/8058316/webrev.00/ > > The issue was on some Solaris 11 hosts lookupDefaultPrintService() > returns null while lpstat -d reports an ipp printer. > The issue was found to exist in linux too since it uses CUPS. > > What was happening was that CUPSPrinter.java#getDefaultPrinter() > searches for server-defined default destination by connection to CUPS > server but > if the user sets the default printer using "lpoptions -d > " command, server will not have any knowledge of this > settings and this user-set default printer (which is stored in > ~/.cups/lpoptions file) was not searched > and getDefaultPrinter() returns null since it could not find any > server default printer. > > Fix is to call cupsGetDest API to search for a lpoptions-defined > default printer and if not set, then search for server-defined > destination. > > I could not provide a regression testcase for this as it involves > setting default printer using lpoptions command. > > Regards > Prasanta > From james.graham at oracle.com Thu Mar 3 23:51:20 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 3 Mar 2016 15:51:20 -0800 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : drawImage misses background's alpha channel In-Reply-To: References: <05dd240c-0f46-486e-b9d9-be51984415d3@default> <56D77BD7.2020302@oracle.com> Message-ID: <56D8CDF8.5020404@oracle.com> Hi Jay, The new code looks good except for one minor indentation problem on the argument list of the method after you added the private keyword. Either back out the keyword or re-indent the argument list continuation line to match either the "(" of the method or the standard indent. And, VolatileImage.getSnapshot() should help with testing VolatileImage results... ...jim On 3/3/2016 6:13 AM, Jayathirth D V wrote: > Hi, > > Thanks for pointing to logical mistake I made Jim. I have made changes to use bg color transparency to determine what type of buffered image should be used in makeBufferedImage(). > > Also based on Sergey's suggestions included other source types like ARGB_PRE in test case and made makeBufferedImage() API private since it is only used in DrawImage.java. But I was not able to include VolatileImage as source type as I didn't find a way to automate the test to verify alpha value after drawImage(), since there is no API to get pixel value from VolatileImage. While debugging I was able to make sure that in case VolatileImage also proper type is selected before makeBufferedImage() is called. > > Please review updated webrev: > http://cr.openjdk.java.net/~jdv/8139183/webrev.02/ > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Thursday, March 03, 2016 5:19 AM > To: Jayathirth D V; 2d-dev at openjdk.java.net; Philip Race; Prasanta Sadhukhan > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : drawImage misses background's alpha channel > > The logic here has mixed up the opacities and what needs to be done about them. > > If the source image is opaque, then this is not a BG operation at all because the bg color would not show through an opaque image, so checking the srcData is both wrong and should be a NOP here. If we get into that block with a srcData that is opaque then something has gone wrong somewhere else. In particular, isBgOp should have returned false in that case. > > The transparency that matters is when the bg color has transparency and that is not what is being tested here. The test for xRGB and ARGB should be using the bg color... > > ...jim > > On 3/2/16 5:17 AM, Jayathirth D V wrote: >> Hi, >> >> I have updated the changes to select proper Buffer Image type based on >> source transparency and not just using ARGB directly. >> >> Please find the updated webrev for review: >> >> http://cr.openjdk.java.net/~jdv/8139183/webrev.01/ >> >> Thanks, >> >> Jay >> >> *From:* Jayathirth D V >> *Sent:* Wednesday, March 02, 2016 5:02 PM >> *To:* 2d-dev at openjdk.java.net; Philip Race; Prasanta Sadhukhan >> *Subject:* Review Request for JDK-8139183 : drawImage misses >> background's alpha channel >> >> Hi, >> >> _Please review the following fix in JDK9:_ >> >> __ >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8139183 >> >> Webrev : http://cr.openjdk.java.net/~jdv/8139183/webrev.00/ >> >> Issue : When we scale any buffered image using drawImage() API which >> takes scale coordinates we are losing alpha channel in background color. >> >> Root cause : We are creating opaque temporary image when we have >> background color and scale is happening in renderImageXform() API of >> DrawImage.java. By making it opaque we are losing translucency. >> >> Solution : Instead of creating opaque RGB temporary image use ARGB >> temporary image to maintain translucency of image. >> >> Thanks, >> >> Jay >> From prasanta.sadhukhan at oracle.com Fri Mar 4 10:47:06 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Fri, 4 Mar 2016 16:17:06 +0530 Subject: [OpenJDK 2D-Dev] [9]: RFR JDK-8058316, , lookupDefaultPrintService returns null on Solaris 11 In-Reply-To: <56D8B1EB.3030302@oracle.com> References: <56D8144D.9050308@oracle.com> <56D8B1EB.3030302@oracle.com> Message-ID: <56D967AA.9080804@oracle.com> Hi Phil, Please find the modified webrev http://cr.openjdk.java.net/~psadhukhan/8058316/webrev.01/ Regards Prasanta On 3/4/2016 3:21 AM, Phil Race wrote: > I think there is a small memory leak with this code : > https://www.cups.org/documentation.php/doc-2.0/api-cups.html#cupsGetDests > > "Use the cupsFreeDests function to free the destination list" > > Also I am not sure if you are using cupsGetDest as intended :- > > 202 cups_dest_t *dest = j2d_cupsGetDest(NULL, NULL, num_dests, > dests); > 203 if (dest != NULL) { > 204 for (i = 0; i < num_dests; i++) { > 205 if (dest[i].is_default) { > 206 defaultPrinter = dest[i].name; > 207 break; > 208 } > 209 } > 210 } > > > I don't think you are expected to iterate over the result here. > I think it is already the pointer to the default. In other words > the function will already have done what your for loop is doing. > If there is no default you will iterate off the end .. > > -phil. > > On 03/03/2016 02:39 AM, prasanta sadhukhan wrote: >> Hi Phil, >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8058316 >> webrev: http://cr.openjdk.java.net/~psadhukhan/8058316/webrev.00/ >> >> The issue was on some Solaris 11 hosts lookupDefaultPrintService() >> returns null while lpstat -d reports an ipp printer. >> The issue was found to exist in linux too since it uses CUPS. >> >> What was happening was that CUPSPrinter.java#getDefaultPrinter() >> searches for server-defined default destination by connection to CUPS >> server but >> if the user sets the default printer using "lpoptions -d >> " command, server will not have any knowledge of this >> settings and this user-set default printer (which is stored in >> ~/.cups/lpoptions file) was not searched >> and getDefaultPrinter() returns null since it could not find any >> server default printer. >> >> Fix is to call cupsGetDest API to search for a lpoptions-defined >> default printer and if not set, then search for server-defined >> destination. >> >> I could not provide a regression testcase for this as it involves >> setting default printer using lpoptions command. >> >> Regards >> Prasanta >> > From prasanta.sadhukhan at oracle.com Fri Mar 4 10:48:00 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Fri, 4 Mar 2016 16:18:00 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8034239, , PrintServiceLookup.lookupPrintServices() returns different amount of services in comparison with lpstat -v Message-ID: <56D967E0.3030903@oracle.com> Hi Phil, Please review a print service fix for jdk9 Bug: https://bugs.openjdk.java.net/browse/JDK-8034239 webrev: http://cr.openjdk.java.net/~psadhukhan/8034239/webrev.00/ The issue was lpstat -v was reporting 2 printer service but PrintServiceLookup.lookupPrintServices() list only 1. #lpstat -v device for tta_printer: ipp:///printers/tta_printer device for Xerox-WorkCentre-4250: socket://spb04p12.ru.oracle.com:9100 but lookupPrintServices() listed only "Xerox" printer and not "tta_printer". It seems "tta_printer" was added using *lpadmin -p printer-name -E -v device -m ppd * so it becomes a "Remote Printer" and even though Java sees that printer, it calls getUnsupportedAttributes() on that printer service to see if that printer matches the DocFlavor. In this case, this remote printer does not have any supported doc flavor listed so when getSupportedDocFlavors() is called, it does not see any "document-format-supported" attribute. Although JDK-8040139 fixed this problem by adding DocFlavor.SERVICE_FORMATTED.PAGEABLE and DocFlavor.SERVICE_FORMATTED.PRINTABLE to the supported DocFlavors since as per spec, as per spec /https://docs.oracle.com/javase/8/docs/api/index.html?javax/print/PrintService.html// //it clearly says, / getSupportedDocFlavors() /Returns:/ /Array of supported doc flavors, should have at least one element./ the returned flavours are not populated to supported DocFlavors called by IPPPrintService.java#getUnsupportedAttributes() -> isDocFlavorSupported() so "supportedDocFlavors" was still false for this case. I added a fix to populate the PAGEABLE & PRINTABLE docflavor to "supportedDocFlavors" and tested in sqe machine and found it working. I could not add a regression testcase as it involves adding a "remote printer" using lpadmin command. I would add "noreg-sqe" to the bug. Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Fri Mar 4 11:05:38 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Fri, 4 Mar 2016 03:05:38 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : drawImage misses background's alpha channel In-Reply-To: <56D8CDF8.5020404@oracle.com> References: <05dd240c-0f46-486e-b9d9-be51984415d3@default> <56D77BD7.2020302@oracle.com> <56D8CDF8.5020404@oracle.com> Message-ID: <993df6ff-6bd6-43a1-b0c7-33dcedb27b24@default> Hi Jim, I have updated the code to remove indentation problem and added VolatileImage also for testing. Please find the updated webrev for review : http://cr.openjdk.java.net/~jdv/8139183/webrev.03/ Thanks, Jay -----Original Message----- From: Jim Graham Sent: Friday, March 04, 2016 5:21 AM To: Jayathirth D V; Sergey Bylokhov Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : drawImage misses background's alpha channel Hi Jay, The new code looks good except for one minor indentation problem on the argument list of the method after you added the private keyword. Either back out the keyword or re-indent the argument list continuation line to match either the "(" of the method or the standard indent. And, VolatileImage.getSnapshot() should help with testing VolatileImage results... ...jim On 3/3/2016 6:13 AM, Jayathirth D V wrote: > Hi, > > Thanks for pointing to logical mistake I made Jim. I have made changes to use bg color transparency to determine what type of buffered image should be used in makeBufferedImage(). > > Also based on Sergey's suggestions included other source types like ARGB_PRE in test case and made makeBufferedImage() API private since it is only used in DrawImage.java. But I was not able to include VolatileImage as source type as I didn't find a way to automate the test to verify alpha value after drawImage(), since there is no API to get pixel value from VolatileImage. While debugging I was able to make sure that in case VolatileImage also proper type is selected before makeBufferedImage() is called. > > Please review updated webrev: > http://cr.openjdk.java.net/~jdv/8139183/webrev.02/ > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Thursday, March 03, 2016 5:19 AM > To: Jayathirth D V; 2d-dev at openjdk.java.net; Philip Race; Prasanta > Sadhukhan > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : > drawImage misses background's alpha channel > > The logic here has mixed up the opacities and what needs to be done about them. > > If the source image is opaque, then this is not a BG operation at all because the bg color would not show through an opaque image, so checking the srcData is both wrong and should be a NOP here. If we get into that block with a srcData that is opaque then something has gone wrong somewhere else. In particular, isBgOp should have returned false in that case. > > The transparency that matters is when the bg color has transparency and that is not what is being tested here. The test for xRGB and ARGB should be using the bg color... > > ...jim > > On 3/2/16 5:17 AM, Jayathirth D V wrote: >> Hi, >> >> I have updated the changes to select proper Buffer Image type based >> on source transparency and not just using ARGB directly. >> >> Please find the updated webrev for review: >> >> http://cr.openjdk.java.net/~jdv/8139183/webrev.01/ >> >> Thanks, >> >> Jay >> >> *From:* Jayathirth D V >> *Sent:* Wednesday, March 02, 2016 5:02 PM >> *To:* 2d-dev at openjdk.java.net; Philip Race; Prasanta Sadhukhan >> *Subject:* Review Request for JDK-8139183 : drawImage misses >> background's alpha channel >> >> Hi, >> >> _Please review the following fix in JDK9:_ >> >> __ >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8139183 >> >> Webrev : http://cr.openjdk.java.net/~jdv/8139183/webrev.00/ >> >> Issue : When we scale any buffered image using drawImage() API which >> takes scale coordinates we are losing alpha channel in background color. >> >> Root cause : We are creating opaque temporary image when we have >> background color and scale is happening in renderImageXform() API of >> DrawImage.java. By making it opaque we are losing translucency. >> >> Solution : Instead of creating opaque RGB temporary image use ARGB >> temporary image to maintain translucency of image. >> >> Thanks, >> >> Jay >> From philip.race at oracle.com Fri Mar 4 19:29:52 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 04 Mar 2016 11:29:52 -0800 Subject: [OpenJDK 2D-Dev] [9]: RFR JDK-8058316, , lookupDefaultPrintService returns null on Solaris 11 In-Reply-To: <56D967AA.9080804@oracle.com> References: <56D8144D.9050308@oracle.com> <56D8B1EB.3030302@oracle.com> <56D967AA.9080804@oracle.com> Message-ID: <56D9E230.5000909@oracle.com> Approved. -phil. On 03/04/2016 02:47 AM, prasanta sadhukhan wrote: > Hi Phil, > > Please find the modified webrev > http://cr.openjdk.java.net/~psadhukhan/8058316/webrev.01/ > > Regards > Prasanta > On 3/4/2016 3:21 AM, Phil Race wrote: >> I think there is a small memory leak with this code : >> https://www.cups.org/documentation.php/doc-2.0/api-cups.html#cupsGetDests >> >> >> "Use the cupsFreeDests function to free the destination list" >> >> Also I am not sure if you are using cupsGetDest as intended :- >> >> 202 cups_dest_t *dest = j2d_cupsGetDest(NULL, NULL, num_dests, >> dests); >> 203 if (dest != NULL) { >> 204 for (i = 0; i < num_dests; i++) { >> 205 if (dest[i].is_default) { >> 206 defaultPrinter = dest[i].name; >> 207 break; >> 208 } >> 209 } >> 210 } >> >> >> I don't think you are expected to iterate over the result here. >> I think it is already the pointer to the default. In other words >> the function will already have done what your for loop is doing. >> If there is no default you will iterate off the end .. >> >> -phil. >> >> On 03/03/2016 02:39 AM, prasanta sadhukhan wrote: >>> Hi Phil, >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8058316 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8058316/webrev.00/ >>> >>> The issue was on some Solaris 11 hosts lookupDefaultPrintService() >>> returns null while lpstat -d reports an ipp printer. >>> The issue was found to exist in linux too since it uses CUPS. >>> >>> What was happening was that CUPSPrinter.java#getDefaultPrinter() >>> searches for server-defined default destination by connection to >>> CUPS server but >>> if the user sets the default printer using "lpoptions -d >>> " command, server will not have any knowledge of this >>> settings and this user-set default printer (which is stored in >>> ~/.cups/lpoptions file) was not searched >>> and getDefaultPrinter() returns null since it could not find any >>> server default printer. >>> >>> Fix is to call cupsGetDest API to search for a lpoptions-defined >>> default printer and if not set, then search for server-defined >>> destination. >>> >>> I could not provide a regression testcase for this as it involves >>> setting default printer using lpoptions command. >>> >>> Regards >>> Prasanta >>> >> > From philip.race at oracle.com Fri Mar 4 19:44:31 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 04 Mar 2016 11:44:31 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8034239, , PrintServiceLookup.lookupPrintServices() returns different amount of services in comparison with lpstat -v In-Reply-To: <56D967E0.3030903@oracle.com> References: <56D967E0.3030903@oracle.com> Message-ID: <56D9E59F.4040006@oracle.com> if the class is supposed to use the return value in this way what about these lines :- 1209 1210 public boolean isIPPSupportedImages(String mimeType) { 1211 if (supportedDocFlavors == null) { 1212 getSupportedDocFlavors(); 1213 } It looks to me as if what you should really be doing is modifying the last few lines of getSupportedDocFlavors() as you are using the return value to update the variable which it should have assigned itself. -phil On 03/04/2016 02:48 AM, prasanta sadhukhan wrote: > Hi Phil, > > Please review a print service fix for jdk9 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8034239 > webrev: http://cr.openjdk.java.net/~psadhukhan/8034239/webrev.00/ > > The issue was lpstat -v was reporting 2 printer service but > PrintServiceLookup.lookupPrintServices() list only 1. > #lpstat -v > device for tta_printer: > ipp:///printers/tta_printer > > device for Xerox-WorkCentre-4250: socket://spb04p12.ru.oracle.com:9100 > > but lookupPrintServices() listed only "Xerox" printer and not > "tta_printer". > > It seems "tta_printer" was added using > *lpadmin -pprinter-name -E -vdevice -m ppd > > * > so it becomes a "Remote Printer" and even though Java sees that > printer, it calls getUnsupportedAttributes() on that printer service > to see if that printer matches the DocFlavor. > In this case, this remote printer does not have any supported doc > flavor listed so when getSupportedDocFlavors() is called, it does not > see any "document-format-supported" attribute. > Although JDK-8040139 fixed this problem by adding > DocFlavor.SERVICE_FORMATTED.PAGEABLE andDocFlavor.SERVICE_FORMATTED.PRINTABLE > > to the supported DocFlavors since as per spec, > as per spec > /https://docs.oracle.com/javase/8/docs/api/index.html?javax/print/PrintService.html// > //it clearly says, / > getSupportedDocFlavors() > > /Returns:/ > /Array of supported doc flavors, should have at least one element./ > > > the returned flavours are not populated to supported DocFlavors called > by IPPPrintService.java#getUnsupportedAttributes() -> > isDocFlavorSupported() so "supportedDocFlavors" was still false for > this case. > > I added a fix to populate the PAGEABLE & PRINTABLE docflavor to > "supportedDocFlavors" and tested in sqe machine and found it working. > > I could not add a regression testcase as it involves adding a "remote > printer" using lpadmin command. I would add "noreg-sqe" to the bug. > > Regards > Prasanta > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Mon Mar 7 06:18:32 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Sun, 6 Mar 2016 22:18:32 -0800 (PST) Subject: [OpenJDK 2D-Dev] [9]: RFR JDK-8058316, , lookupDefaultPrintService returns null on Solaris 11 In-Reply-To: <56D9E230.5000909@oracle.com> References: <56D8144D.9050308@oracle.com> <56D8B1EB.3030302@oracle.com> <56D967AA.9080804@oracle.com> <56D9E230.5000909@oracle.com> Message-ID: Fix looks fine. Please add relevant noreg label in bug before resolving it, since there is no test case. Thanks, Jay -----Original Message----- From: Phil Race Sent: Saturday, March 05, 2016 1:00 AM To: prasanta sadhukhan Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9]: RFR JDK-8058316, , lookupDefaultPrintService returns null on Solaris 11 Approved. -phil. On 03/04/2016 02:47 AM, prasanta sadhukhan wrote: > Hi Phil, > > Please find the modified webrev > http://cr.openjdk.java.net/~psadhukhan/8058316/webrev.01/ > > Regards > Prasanta > On 3/4/2016 3:21 AM, Phil Race wrote: >> I think there is a small memory leak with this code : >> https://www.cups.org/documentation.php/doc-2.0/api-cups.html#cupsGetD >> ests >> >> >> "Use the cupsFreeDests function to free the destination list" >> >> Also I am not sure if you are using cupsGetDest as intended :- >> >> 202 cups_dest_t *dest = j2d_cupsGetDest(NULL, NULL, num_dests, >> dests); >> 203 if (dest != NULL) { >> 204 for (i = 0; i < num_dests; i++) { >> 205 if (dest[i].is_default) { >> 206 defaultPrinter = dest[i].name; >> 207 break; >> 208 } >> 209 } >> 210 } >> >> >> I don't think you are expected to iterate over the result here. >> I think it is already the pointer to the default. In other words the >> function will already have done what your for loop is doing. >> If there is no default you will iterate off the end .. >> >> -phil. >> >> On 03/03/2016 02:39 AM, prasanta sadhukhan wrote: >>> Hi Phil, >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8058316 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8058316/webrev.00/ >>> >>> The issue was on some Solaris 11 hosts lookupDefaultPrintService() >>> returns null while lpstat -d reports an ipp printer. >>> The issue was found to exist in linux too since it uses CUPS. >>> >>> What was happening was that CUPSPrinter.java#getDefaultPrinter() >>> searches for server-defined default destination by connection to >>> CUPS server but if the user sets the default printer using >>> "lpoptions -d " command, server will not have any >>> knowledge of this settings and this user-set default printer (which >>> is stored in ~/.cups/lpoptions file) was not searched and >>> getDefaultPrinter() returns null since it could not find any server >>> default printer. >>> >>> Fix is to call cupsGetDest API to search for a lpoptions-defined >>> default printer and if not set, then search for server-defined >>> destination. >>> >>> I could not provide a regression testcase for this as it involves >>> setting default printer using lpoptions command. >>> >>> Regards >>> Prasanta >>> >> > From prasanta.sadhukhan at oracle.com Mon Mar 7 11:20:33 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Mon, 7 Mar 2016 16:50:33 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8034239, , PrintServiceLookup.lookupPrintServices() returns different amount of services in comparison with lpstat -v In-Reply-To: <56D9E59F.4040006@oracle.com> References: <56D967E0.3030903@oracle.com> <56D9E59F.4040006@oracle.com> Message-ID: <56DD6401.2060907@oracle.com> Hi Phil, Please find the updated webrev: http://cr.openjdk.java.net/~psadhukhan/8034239/webrev.01/ I checked JDK-8040139 also passed with this modification. Regards Prasanya On 3/5/2016 1:14 AM, Phil Race wrote: > if the class is supposed to use the return value in this way what > about these lines :- > > 1209 > 1210 public boolean isIPPSupportedImages(String mimeType) { > 1211 if (supportedDocFlavors == null) { > 1212 getSupportedDocFlavors(); > 1213 } > > It looks to me as if what you should really be doing is modifying > the last few lines of getSupportedDocFlavors() as you are using > the return value to update the variable which it should have > assigned itself. > > -phil > > > > On 03/04/2016 02:48 AM, prasanta sadhukhan wrote: >> Hi Phil, >> >> Please review a print service fix for jdk9 >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8034239 >> webrev: http://cr.openjdk.java.net/~psadhukhan/8034239/webrev.00/ >> >> The issue was lpstat -v was reporting 2 printer service but >> PrintServiceLookup.lookupPrintServices() list only 1. >> #lpstat -v >> device for tta_printer: >> ipp:///printers/tta_printer >> >> device for Xerox-WorkCentre-4250: socket://spb04p12.ru.oracle.com:9100 >> >> but lookupPrintServices() listed only "Xerox" printer and not >> "tta_printer". >> >> It seems "tta_printer" was added using >> *lpadmin -p printer-name -E -v device -m ppd * >> so it becomes a "Remote Printer" and even though Java sees that >> printer, it calls getUnsupportedAttributes() on that printer service >> to see if that printer matches the DocFlavor. >> In this case, this remote printer does not have any supported doc >> flavor listed so when getSupportedDocFlavors() is called, it does not >> see any "document-format-supported" attribute. >> Although JDK-8040139 fixed this problem by adding >> DocFlavor.SERVICE_FORMATTED.PAGEABLE and >> DocFlavor.SERVICE_FORMATTED.PRINTABLE >> to the supported DocFlavors since as per spec, >> as per spec >> /https://docs.oracle.com/javase/8/docs/api/index.html?javax/print/PrintService.html// >> //it clearly says, / >> getSupportedDocFlavors() >> >> /Returns:/ >> /Array of supported doc flavors, should have at least one element./ >> >> >> the returned flavours are not populated to supported DocFlavors >> called by IPPPrintService.java#getUnsupportedAttributes() -> >> isDocFlavorSupported() so "supportedDocFlavors" was still false for >> this case. >> >> I added a fix to populate the PAGEABLE & PRINTABLE docflavor to >> "supportedDocFlavors" and tested in sqe machine and found it working. >> >> I could not add a regression testcase as it involves adding a "remote >> printer" using lpadmin command. I would add "noreg-sqe" to the bug. >> >> Regards >> Prasanta >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Mar 7 20:28:08 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 07 Mar 2016 12:28:08 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8034239, , PrintServiceLookup.lookupPrintServices() returns different amount of services in comparison with lpstat -v In-Reply-To: <56DD6401.2060907@oracle.com> References: <56D967E0.3030903@oracle.com> <56D9E59F.4040006@oracle.com> <56DD6401.2060907@oracle.com> Message-ID: <56DDE458.6010605@oracle.com> Why do the copy ? Why not just add one line supportedDocFlavors = flavor -phil. On 03/07/2016 03:20 AM, prasanta sadhukhan wrote: > Hi Phil, > > Please find the updated webrev: > http://cr.openjdk.java.net/~psadhukhan/8034239/webrev.01/ > > I checked JDK-8040139 also passed with this modification. > > Regards > Prasanya > On 3/5/2016 1:14 AM, Phil Race wrote: >> if the class is supposed to use the return value in this way what >> about these lines :- >> >> 1209 >> 1210 public boolean isIPPSupportedImages(String mimeType) { >> 1211 if (supportedDocFlavors == null) { >> 1212 getSupportedDocFlavors(); >> 1213 } >> >> It looks to me as if what you should really be doing is modifying >> the last few lines of getSupportedDocFlavors() as you are using >> the return value to update the variable which it should have >> assigned itself. >> >> -phil >> >> >> >> On 03/04/2016 02:48 AM, prasanta sadhukhan wrote: >>> Hi Phil, >>> >>> Please review a print service fix for jdk9 >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8034239 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8034239/webrev.00/ >>> >>> The issue was lpstat -v was reporting 2 printer service but >>> PrintServiceLookup.lookupPrintServices() list only 1. >>> #lpstat -v >>> device for tta_printer: >>> ipp:///printers/tta_printer >>> >>> device for Xerox-WorkCentre-4250: socket://spb04p12.ru.oracle.com:9100 >>> >>> but lookupPrintServices() listed only "Xerox" printer and not >>> "tta_printer". >>> >>> It seems "tta_printer" was added using >>> *lpadmin -pprinter-name -E -vdevice -m ppd >>> >>> * >>> so it becomes a "Remote Printer" and even though Java sees that >>> printer, it calls getUnsupportedAttributes() on that printer service >>> to see if that printer matches the DocFlavor. >>> In this case, this remote printer does not have any supported doc >>> flavor listed so when getSupportedDocFlavors() is called, it does >>> not see any "document-format-supported" attribute. >>> Although JDK-8040139 fixed this problem by adding >>> DocFlavor.SERVICE_FORMATTED.PAGEABLE andDocFlavor.SERVICE_FORMATTED.PRINTABLE >>> >>> to the supported DocFlavors since as per spec, >>> as per spec >>> /https://docs.oracle.com/javase/8/docs/api/index.html?javax/print/PrintService.html// >>> //it clearly says, / >>> getSupportedDocFlavors() >>> >>> /Returns:/ >>> /Array of supported doc flavors, should have at least one element./ >>> >>> >>> the returned flavours are not populated to supported DocFlavors >>> called by IPPPrintService.java#getUnsupportedAttributes() -> >>> isDocFlavorSupported() so "supportedDocFlavors" was still false for >>> this case. >>> >>> I added a fix to populate the PAGEABLE & PRINTABLE docflavor to >>> "supportedDocFlavors" and tested in sqe machine and found it working. >>> >>> I could not add a regression testcase as it involves adding a >>> "remote printer" using lpadmin command. I would add "noreg-sqe" to >>> the bug. >>> >>> Regards >>> Prasanta >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Mar 7 20:47:46 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 07 Mar 2016 12:47:46 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8066139, , Null return from PrintJob.getGraphics() running closed/java/awt/PrintJob/HighResTest/HighResTest.java In-Reply-To: <56D579B1.7090204@oracle.com> References: <56C6DDF1.1020009@oracle.com> <56C764B3.9020005@oracle.com> <56C77A50.7010605@oracle.com> <56CAAAC8.40009@oracle.com> <56CAC14F.4030602@oracle.com> <56D579B1.7090204@oracle.com> Message-ID: <56DDE8F2.3000707@oracle.com> I don't think starting a new thread can be right. That would re-invoke printerJob.print() which even if you can reuse a PrinterJob (something that was never set out in spec.) you are surely getting a new spool job .. not a continuation. There a couple of other things I am not sure about either. I've looked into this - only on Linux - and I believe the issue is that the test program has decided up-front how many pages it is going to print and it is paying no attention to the selected page ranges. Not what the 'user' asked for but it is perfectly within its rights to do so. However the 2D PrinterJob operates in a way where it calls back asking for the specific pages it wants to be printed and there the app. must comply. The PrinterJob terminates once it has done. In the case when the 2D PrinterJob is being used to 'run' a PrintJob then it must *never* return until the application has called "end" - or some exception occurs. So we need to remove the elements that will cause the job to exit. --- a/src/java.desktop/share/classes/sun/print/PrintJob2D.java +++ b/src/java.desktop/share/classes/sun/print/PrintJob2D.java @@ -995,6 +995,7 @@ public void run() { try { + attributes.remove(PageRanges.class); printerJob.print(attributes); } catch (PrinterException e) { //REMIND: need to store this away and not rethrow it. diff --git a/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java b/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java --- a/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java +++ b/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java @@ -1172,6 +1172,7 @@ pageRangesAttr = (PageRanges)attributes.get(PageRanges.class); if (!isSupportedValue(pageRangesAttr, attributes)) { pageRangesAttr = null; + setPageRange(-1, -1); } else { if ((SunPageSelection)attributes.get(SunPageSelection.class) == SunPageSelection.RANGE) { This works for me on Linux although a) I have not tried Windows) b) I have not verified if there are no negative consequences from the 2nd change. -phil. On 03/01/2016 03:14 AM, prasanta sadhukhan wrote: > Hi Phil, > > Please find an updated webrev: > http://cr.openjdk.java.net/~psadhukhan/8066139/webrev.01/ > > It seems if printerJobThread finished printing, it will set > graphicsToBeDrawn/graphicsDrawn ArrayList to null resulting in > getGraphics() returning null in the 2nd iteration causing NPE so > I have modified printerJobThread#run so that when it has finished > printing, do not set the arrayList to null but set a flag. In > getGraphics(), I check that flag and start a new printerJobThread to > handle the next printing. > I have tested "All" and "Pages" selection. > > Regards > Prasanta > On 2/22/2016 1:35 PM, Philip Race wrote: >> > It seems this behaviour is same in linux too for this HighResTest >> testcase. >> >> OK that is good information .. so is not really a regression from >> 8061267 as that is >> not in >> any way touching linux .. it is a pre-existing issue in a code path >> that was not being tested. >> >> -phil. >> >> On 2/22/16, 11:59 AM, prasanta sadhukhan wrote: >>> Hi Phil, >>> >>> >>Additionally, have you tried running the original test case >>> provided with 8061267 >>> >> against your fix ? >>> The 8061267 testcase behaves similarly before and after my fix. >>> >>> >> If I manually select it, (ie select that "Pages" radio button) >>> then press print, >>> >> then voila, the NPE is back! >>> It seems this behaviour is same in linux too for this HighResTest >>> testcase. >>> >>> Regards >>> Prasanta >>> On 2/20/2016 1:55 AM, Phil Race wrote: >>>> I am having trouble building JDK 9 at the moment so i applied >>>> 8061267 to jdk8u-dev >>>> and was able to reproduce the regression and have a couple of >>>> observations >>>> >>>> - I am now seeing the NPE after the first page as you did .. puzzling. >>>> - I next applied your fix but still see the NPE ! >>>> >>>> It appears that all your fix did is stop the "PD_PAGENUMS" flag >>>> being automatically >>>> set. If I manually select it, (ie select that "Pages" radio button) >>>> then press print, >>>> then voila, the NPE is back! >>>> >>>> -phil. >>>> >>>> >>>> On 02/19/2016 10:53 AM, Phil Race wrote: >>>>> I am not sure I can be correctly understanding the fix as the >>>>> ramification seems >>>>> to be that if the users wants to print only Page 3 of a 10 page >>>>> document and so sets >>>>> from page=3 and to page=3, that this request will be ignored and >>>>> all pages will >>>>> be printed .. can you test such a scenario. >>>>> >>>>> Additionally, have you tried running the original test case >>>>> provided with 8061267 >>>>> against your fix ? >>>>> >>>>> Also when I ran the HighResTest on a current build I saw a null >>>>> graphics on >>>>> the very first call to getGraphics() which is different than what >>>>> I interpret >>>>> you as saying - you see the null *after* the first page is printed. >>>>> >>>>> -phil. >>>>> >>>>> On 02/19/2016 01:18 AM, prasanta sadhukhan wrote: >>>>>> Hi Phil, All, >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066139 >>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8066139/webrev.00/ >>>>>> >>>>>> It was seen after fix of JDK-8061267 >>>>>> : PrinterJob: >>>>>> Specified Page Ranges not displayed in Windows Native Print Dialog >>>>>> the closed/java/awt/PrintJob/HighResTest/HighResTest.java was >>>>>> failing with NPE when PrinterJob.getGraphics() is called the 2nd >>>>>> time before calling PrinterJob.end(). >>>>>> >>>>>> The above fix caused this regression because it sets the >>>>>> PD_PAGENUMS flag for windows PrintDlg struct which causes *Pages* >>>>>> radio button to be selected in print dialog. >>>>>> However, fromPage and toPage was both set to 1 so after the 1st >>>>>> page is printed, RasterPrinterJob.print(attributes) finishes and >>>>>> graphicsToBeDrawn.closeWhenEmpty() gets called >>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/d8def65c6c00/src/java.desktop/share/classes/sun/print/PrintJob2D.java#l1006 >>>>>> >>>>>> which sets the queue to null so when PrinterJob2D#getGraphics() >>>>>> calls graphicsToBeDrawn.pop() it sees queue to be null and sets >>>>>> graphics object to be null so >>>>>> PrinterJob.getGraphics() gets null and g.drawLine in testcase >>>>>> causes NPE since g is null. >>>>>> >>>>>> Fix was done to set the PD_PAGENUMS flag only when toPage is more >>>>>> than fromPage in which case, "All" will be selected in printer >>>>>> dialog and RasterPrinterJob.print() will finish only after >>>>>> printing all the pages. >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>> >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Tue Mar 8 00:30:26 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 7 Mar 2016 16:30:26 -0800 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : drawImage misses background's alpha channel In-Reply-To: <993df6ff-6bd6-43a1-b0c7-33dcedb27b24@default> References: <05dd240c-0f46-486e-b9d9-be51984415d3@default> <56D77BD7.2020302@oracle.com> <56D8CDF8.5020404@oracle.com> <993df6ff-6bd6-43a1-b0c7-33dcedb27b24@default> Message-ID: <56DE1D22.3000205@oracle.com> Hi Jay, The code changes look fine. There are a few issues with the use of VolatileImage in the test case, though. First, contentsLost is meant to be executed after an operation, not before. The class comments give an example of using it both during rendering to the VI and also during copying from the VI. You are doing both in one operation here, but in both cases, the contentsLost test is after the operation has completed. To be clear, you should fill the VI, draw the test image into it, snapshot it, and then after all of that is done, test contentsLost and loop back around. Second, the test for IMAGE_INCOMPATIBLE and the way you recurse could end up in an infinite loop in theory. In practice, these issues are rare and only happen if we have a change in screen configurations during the use of a VI. The validate() call is meant to check a VI that has been sitting around from a previous operation to see if it can be used again for a new operation on a new repaint cycle. If you look at the sample code in the VI documentation the response to an INCOMPATIBLE image is to just create a new one and go on, assuming that it will be OK because it would be nearly impossible for an image to become incompatible between creating it and immediately using it. As such, I'd just delete the test here as it won't add any value. If it were to be left in, it should only be done a couple of times before giving up and throwing a test error as something must be wrong in the system if it happens more than once (actually something is likely wrong in the system even if it happens just once immediately after creating a brand new image). So, either delete the check or throw a test failure (even though it isn't a failure for the bug at hand, it indicates something wrong in the 2D code). Finally, AlphaComposite.CLEAR ignores the color so there is no need to also set a transparent color to clear the VI. If it wasn't being cleared by using AlphaComposite.CLEAR, then there is another bug going on there. An alternative is to use AlphaComposite.SRC and the transparent color, but just using CLEAR and setting no color at all should be fine... ...jim On 3/4/16 3:05 AM, Jayathirth D V wrote: > Hi Jim, > > I have updated the code to remove indentation problem and added VolatileImage also for testing. > > Please find the updated webrev for review : > http://cr.openjdk.java.net/~jdv/8139183/webrev.03/ > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Friday, March 04, 2016 5:21 AM > To: Jayathirth D V; Sergey Bylokhov > Cc: 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : drawImage misses background's alpha channel > > Hi Jay, > > The new code looks good except for one minor indentation problem on the argument list of the method after you added the private keyword. Either back out the keyword or re-indent the argument list continuation line to match either the "(" of the method or the standard indent. > > And, VolatileImage.getSnapshot() should help with testing VolatileImage results... > > ...jim > > On 3/3/2016 6:13 AM, Jayathirth D V wrote: >> Hi, >> >> Thanks for pointing to logical mistake I made Jim. I have made changes to use bg color transparency to determine what type of buffered image should be used in makeBufferedImage(). >> >> Also based on Sergey's suggestions included other source types like ARGB_PRE in test case and made makeBufferedImage() API private since it is only used in DrawImage.java. But I was not able to include VolatileImage as source type as I didn't find a way to automate the test to verify alpha value after drawImage(), since there is no API to get pixel value from VolatileImage. While debugging I was able to make sure that in case VolatileImage also proper type is selected before makeBufferedImage() is called. >> >> Please review updated webrev: >> http://cr.openjdk.java.net/~jdv/8139183/webrev.02/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Thursday, March 03, 2016 5:19 AM >> To: Jayathirth D V; 2d-dev at openjdk.java.net; Philip Race; Prasanta >> Sadhukhan >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : >> drawImage misses background's alpha channel >> >> The logic here has mixed up the opacities and what needs to be done about them. >> >> If the source image is opaque, then this is not a BG operation at all because the bg color would not show through an opaque image, so checking the srcData is both wrong and should be a NOP here. If we get into that block with a srcData that is opaque then something has gone wrong somewhere else. In particular, isBgOp should have returned false in that case. >> >> The transparency that matters is when the bg color has transparency and that is not what is being tested here. The test for xRGB and ARGB should be using the bg color... >> >> ...jim >> >> On 3/2/16 5:17 AM, Jayathirth D V wrote: >>> Hi, >>> >>> I have updated the changes to select proper Buffer Image type based >>> on source transparency and not just using ARGB directly. >>> >>> Please find the updated webrev for review: >>> >>> http://cr.openjdk.java.net/~jdv/8139183/webrev.01/ >>> >>> Thanks, >>> >>> Jay >>> >>> *From:* Jayathirth D V >>> *Sent:* Wednesday, March 02, 2016 5:02 PM >>> *To:* 2d-dev at openjdk.java.net; Philip Race; Prasanta Sadhukhan >>> *Subject:* Review Request for JDK-8139183 : drawImage misses >>> background's alpha channel >>> >>> Hi, >>> >>> _Please review the following fix in JDK9:_ >>> >>> __ >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8139183 >>> >>> Webrev : http://cr.openjdk.java.net/~jdv/8139183/webrev.00/ >>> >>> Issue : When we scale any buffered image using drawImage() API which >>> takes scale coordinates we are losing alpha channel in background color. >>> >>> Root cause : We are creating opaque temporary image when we have >>> background color and scale is happening in renderImageXform() API of >>> DrawImage.java. By making it opaque we are losing translucency. >>> >>> Solution : Instead of creating opaque RGB temporary image use ARGB >>> temporary image to maintain translucency of image. >>> >>> Thanks, >>> >>> Jay >>> From jayathirth.d.v at oracle.com Tue Mar 8 08:56:56 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 8 Mar 2016 00:56:56 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : drawImage misses background's alpha channel In-Reply-To: <56DE1D22.3000205@oracle.com> References: <05dd240c-0f46-486e-b9d9-be51984415d3@default> <56D77BD7.2020302@oracle.com> <56D8CDF8.5020404@oracle.com> <993df6ff-6bd6-43a1-b0c7-33dcedb27b24@default> <56DE1D22.3000205@oracle.com> Message-ID: Hi Jim, Thanks for the review. I have made changes in test case based on input provided. 1) Added contentsLost() after we drawImage() and getSnapshot() to verify the content and if it is lost loop again. 2) Removed recursive creation of VolatileImage based IMAGE_INCOMPATIBLE property. 3) Removed setColor() with transparent color for AlphaComposite.Clear as it is not needed. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/8139183/webrev.04/ Thanks, Jay -----Original Message----- From: Jim Graham Sent: Tuesday, March 08, 2016 6:00 AM To: Jayathirth D V Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : drawImage misses background's alpha channel Hi Jay, The code changes look fine. There are a few issues with the use of VolatileImage in the test case, though. First, contentsLost is meant to be executed after an operation, not before. The class comments give an example of using it both during rendering to the VI and also during copying from the VI. You are doing both in one operation here, but in both cases, the contentsLost test is after the operation has completed. To be clear, you should fill the VI, draw the test image into it, snapshot it, and then after all of that is done, test contentsLost and loop back around. Second, the test for IMAGE_INCOMPATIBLE and the way you recurse could end up in an infinite loop in theory. In practice, these issues are rare and only happen if we have a change in screen configurations during the use of a VI. The validate() call is meant to check a VI that has been sitting around from a previous operation to see if it can be used again for a new operation on a new repaint cycle. If you look at the sample code in the VI documentation the response to an INCOMPATIBLE image is to just create a new one and go on, assuming that it will be OK because it would be nearly impossible for an image to become incompatible between creating it and immediately using it. As such, I'd just delete the test here as it won't add any value. If it were to be left in, it should only be done a couple of times before giving up and throwing a test error as something must be wrong in the system if it happens more than once (actually something is likely wrong in the system even if it happens just once immediately after creating a brand new image). So, either delete the check or throw a test failure (even though it isn't a failure for the bug at hand, it indicates something wrong in the 2D code). Finally, AlphaComposite.CLEAR ignores the color so there is no need to also set a transparent color to clear the VI. If it wasn't being cleared by using AlphaComposite.CLEAR, then there is another bug going on there. An alternative is to use AlphaComposite.SRC and the transparent color, but just using CLEAR and setting no color at all should be fine... ...jim On 3/4/16 3:05 AM, Jayathirth D V wrote: > Hi Jim, > > I have updated the code to remove indentation problem and added VolatileImage also for testing. > > Please find the updated webrev for review : > http://cr.openjdk.java.net/~jdv/8139183/webrev.03/ > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Friday, March 04, 2016 5:21 AM > To: Jayathirth D V; Sergey Bylokhov > Cc: 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : > drawImage misses background's alpha channel > > Hi Jay, > > The new code looks good except for one minor indentation problem on the argument list of the method after you added the private keyword. Either back out the keyword or re-indent the argument list continuation line to match either the "(" of the method or the standard indent. > > And, VolatileImage.getSnapshot() should help with testing VolatileImage results... > > ...jim > > On 3/3/2016 6:13 AM, Jayathirth D V wrote: >> Hi, >> >> Thanks for pointing to logical mistake I made Jim. I have made changes to use bg color transparency to determine what type of buffered image should be used in makeBufferedImage(). >> >> Also based on Sergey's suggestions included other source types like ARGB_PRE in test case and made makeBufferedImage() API private since it is only used in DrawImage.java. But I was not able to include VolatileImage as source type as I didn't find a way to automate the test to verify alpha value after drawImage(), since there is no API to get pixel value from VolatileImage. While debugging I was able to make sure that in case VolatileImage also proper type is selected before makeBufferedImage() is called. >> >> Please review updated webrev: >> http://cr.openjdk.java.net/~jdv/8139183/webrev.02/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Thursday, March 03, 2016 5:19 AM >> To: Jayathirth D V; 2d-dev at openjdk.java.net; Philip Race; Prasanta >> Sadhukhan >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : >> drawImage misses background's alpha channel >> >> The logic here has mixed up the opacities and what needs to be done about them. >> >> If the source image is opaque, then this is not a BG operation at all because the bg color would not show through an opaque image, so checking the srcData is both wrong and should be a NOP here. If we get into that block with a srcData that is opaque then something has gone wrong somewhere else. In particular, isBgOp should have returned false in that case. >> >> The transparency that matters is when the bg color has transparency and that is not what is being tested here. The test for xRGB and ARGB should be using the bg color... >> >> ...jim >> >> On 3/2/16 5:17 AM, Jayathirth D V wrote: >>> Hi, >>> >>> I have updated the changes to select proper Buffer Image type based >>> on source transparency and not just using ARGB directly. >>> >>> Please find the updated webrev for review: >>> >>> http://cr.openjdk.java.net/~jdv/8139183/webrev.01/ >>> >>> Thanks, >>> >>> Jay >>> >>> *From:* Jayathirth D V >>> *Sent:* Wednesday, March 02, 2016 5:02 PM >>> *To:* 2d-dev at openjdk.java.net; Philip Race; Prasanta Sadhukhan >>> *Subject:* Review Request for JDK-8139183 : drawImage misses >>> background's alpha channel >>> >>> Hi, >>> >>> _Please review the following fix in JDK9:_ >>> >>> __ >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8139183 >>> >>> Webrev : http://cr.openjdk.java.net/~jdv/8139183/webrev.00/ >>> >>> Issue : When we scale any buffered image using drawImage() API which >>> takes scale coordinates we are losing alpha channel in background color. >>> >>> Root cause : We are creating opaque temporary image when we have >>> background color and scale is happening in renderImageXform() API of >>> DrawImage.java. By making it opaque we are losing translucency. >>> >>> Solution : Instead of creating opaque RGB temporary image use ARGB >>> temporary image to maintain translucency of image. >>> >>> Thanks, >>> >>> Jay >>> From prasanta.sadhukhan at oracle.com Tue Mar 8 10:26:46 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Tue, 8 Mar 2016 15:56:46 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8034239, , PrintServiceLookup.lookupPrintServices() returns different amount of services in comparison with lpstat -v In-Reply-To: <56DDE458.6010605@oracle.com> References: <56D967E0.3030903@oracle.com> <56D9E59F.4040006@oracle.com> <56DD6401.2060907@oracle.com> <56DDE458.6010605@oracle.com> Message-ID: <56DEA8E6.7000708@oracle.com> Hi Phil, It's my mistake. There's no need to copy as we are not passing the supportedDocFlavors outside the class. I was influenced by the lines before this where copyFlavors was copied from supportedDocFlavors. Please find the updated webrev: http://cr.openjdk.java.net/~psadhukhan/8034239/webrev.02/ Regards Prasanta On 3/8/2016 1:58 AM, Phil Race wrote: > Why do the copy ? Why not just add one line > > supportedDocFlavors = flavor > > -phil. > > On 03/07/2016 03:20 AM, prasanta sadhukhan wrote: >> Hi Phil, >> >> Please find the updated webrev: >> http://cr.openjdk.java.net/~psadhukhan/8034239/webrev.01/ >> >> I checked JDK-8040139 also passed with this modification. >> >> Regards >> Prasanya >> On 3/5/2016 1:14 AM, Phil Race wrote: >>> if the class is supposed to use the return value in this way what >>> about these lines :- >>> >>> 1209 >>> 1210 public boolean isIPPSupportedImages(String mimeType) { >>> 1211 if (supportedDocFlavors == null) { >>> 1212 getSupportedDocFlavors(); >>> 1213 } >>> >>> It looks to me as if what you should really be doing is modifying >>> the last few lines of getSupportedDocFlavors() as you are using >>> the return value to update the variable which it should have >>> assigned itself. >>> >>> -phil >>> >>> >>> >>> On 03/04/2016 02:48 AM, prasanta sadhukhan wrote: >>>> Hi Phil, >>>> >>>> Please review a print service fix for jdk9 >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8034239 >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8034239/webrev.00/ >>>> >>>> The issue was lpstat -v was reporting 2 printer service but >>>> PrintServiceLookup.lookupPrintServices() list only 1. >>>> #lpstat -v >>>> device for tta_printer: >>>> ipp:///printers/tta_printer >>>> >>>> device for Xerox-WorkCentre-4250: socket://spb04p12.ru.oracle.com:9100 >>>> >>>> but lookupPrintServices() listed only "Xerox" printer and not >>>> "tta_printer". >>>> >>>> It seems "tta_printer" was added using >>>> *lpadmin -p printer-name -E -v device -m ppd * >>>> so it becomes a "Remote Printer" and even though Java sees that >>>> printer, it calls getUnsupportedAttributes() on that printer >>>> service to see if that printer matches the DocFlavor. >>>> In this case, this remote printer does not have any supported doc >>>> flavor listed so when getSupportedDocFlavors() is called, it does >>>> not see any "document-format-supported" attribute. >>>> Although JDK-8040139 fixed this problem by adding >>>> DocFlavor.SERVICE_FORMATTED.PAGEABLE and >>>> DocFlavor.SERVICE_FORMATTED.PRINTABLE >>>> to the supported DocFlavors since as per spec, >>>> as per spec >>>> /https://docs.oracle.com/javase/8/docs/api/index.html?javax/print/PrintService.html// >>>> //it clearly says, / >>>> getSupportedDocFlavors() >>>> >>>> /Returns:/ >>>> /Array of supported doc flavors, should have at least one element./ >>>> >>>> >>>> the returned flavours are not populated to supported DocFlavors >>>> called by IPPPrintService.java#getUnsupportedAttributes() -> >>>> isDocFlavorSupported() so "supportedDocFlavors" was still false for >>>> this case. >>>> >>>> I added a fix to populate the PAGEABLE & PRINTABLE docflavor to >>>> "supportedDocFlavors" and tested in sqe machine and found it working. >>>> >>>> I could not add a regression testcase as it involves adding a >>>> "remote printer" using lpadmin command. I would add "noreg-sqe" to >>>> the bug. >>>> >>>> Regards >>>> Prasanta >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Tue Mar 8 10:30:10 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Tue, 8 Mar 2016 16:00:10 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8066139, , Null return from PrintJob.getGraphics() running closed/java/awt/PrintJob/HighResTest/HighResTest.java In-Reply-To: <56DDE8F2.3000707@oracle.com> References: <56C6DDF1.1020009@oracle.com> <56C764B3.9020005@oracle.com> <56C77A50.7010605@oracle.com> <56CAAAC8.40009@oracle.com> <56CAC14F.4030602@oracle.com> <56D579B1.7090204@oracle.com> <56DDE8F2.3000707@oracle.com> Message-ID: <56DEA9B2.8020702@oracle.com> On 3/8/2016 2:17 AM, Phil Race wrote: > I don't think starting a new thread can be right. That would re-invoke > printerJob.print() which even if you can reuse a PrinterJob (something > that > was never set out in spec.) you are surely getting a new spool job .. not > a continuation. There a couple of other things I am not sure about either. > > I've looked into this - only on Linux - and I believe the issue is that > the test program has decided up-front how many pages it is going to > print and it is paying no attention to the selected page ranges. > Not what the 'user' asked for but it is perfectly within its rights to > do so. > > However the 2D PrinterJob operates in a way where it calls back > asking for the specific pages it wants to be printed and there the > app. must comply. The PrinterJob terminates once it has done. > > In the case when the 2D PrinterJob is being used to 'run' a > PrintJob then it must *never* return until the application has > called "end" - or some exception occurs. > > So we need to remove the elements that will cause the job to exit. > > --- a/src/java.desktop/share/classes/sun/print/PrintJob2D.java > +++ b/src/java.desktop/share/classes/sun/print/PrintJob2D.java > @@ -995,6 +995,7 @@ > public void run() { > > try { > + attributes.remove(PageRanges.class); > printerJob.print(attributes); > } catch (PrinterException e) { > //REMIND: need to store this away and not rethrow it. > diff --git > a/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java > b/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java > --- a/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java > +++ b/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java > @@ -1172,6 +1172,7 @@ > pageRangesAttr = (PageRanges)attributes.get(PageRanges.class); > if (!isSupportedValue(pageRangesAttr, attributes)) { > pageRangesAttr = null; > + setPageRange(-1, -1); > } else { > if ((SunPageSelection)attributes.get(SunPageSelection.class) > == SunPageSelection.RANGE) { > > > This works for me on Linux although > a) I have not tried Windows) I tried on windows. The NPE is not seen and it prints 2 pages. However, I am finding a strange issue with and without this fix too. The "Center" string is not printed in the 1st page in both "Portrait" and "Landscape" mode (although the rectangles are printed) but is printed in the 2nd page. I do not find this issue in linux. Regards Prasanta > b) I have not verified if there are no negative consequences from the > 2nd change. > > -phil. > > On 03/01/2016 03:14 AM, prasanta sadhukhan wrote: >> Hi Phil, >> >> Please find an updated webrev: >> http://cr.openjdk.java.net/~psadhukhan/8066139/webrev.01/ >> >> It seems if printerJobThread finished printing, it will set >> graphicsToBeDrawn/graphicsDrawn ArrayList to null resulting in >> getGraphics() returning null in the 2nd iteration causing NPE so >> I have modified printerJobThread#run so that when it has finished >> printing, do not set the arrayList to null but set a flag. In >> getGraphics(), I check that flag and start a new printerJobThread to >> handle the next printing. >> I have tested "All" and "Pages" selection. >> >> Regards >> Prasanta >> On 2/22/2016 1:35 PM, Philip Race wrote: >>> > It seems this behaviour is same in linux too for this HighResTest >>> testcase. >>> >>> OK that is good information .. so is not really a regression from >>> 8061267 as that >>> is not in >>> any way touching linux .. it is a pre-existing issue in a code path >>> that was not being tested. >>> >>> -phil. >>> >>> On 2/22/16, 11:59 AM, prasanta sadhukhan wrote: >>>> Hi Phil, >>>> >>>> >>Additionally, have you tried running the original test case >>>> provided with 8061267 >>>> >> against your fix ? >>>> The 8061267 testcase behaves similarly before and after my fix. >>>> >>>> >> If I manually select it, (ie select that "Pages" radio button) >>>> then press print, >>>> >> then voila, the NPE is back! >>>> It seems this behaviour is same in linux too for this HighResTest >>>> testcase. >>>> >>>> Regards >>>> Prasanta >>>> On 2/20/2016 1:55 AM, Phil Race wrote: >>>>> I am having trouble building JDK 9 at the moment so i applied >>>>> 8061267 to jdk8u-dev >>>>> and was able to reproduce the regression and have a couple of >>>>> observations >>>>> >>>>> - I am now seeing the NPE after the first page as you did .. puzzling. >>>>> - I next applied your fix but still see the NPE ! >>>>> >>>>> It appears that all your fix did is stop the "PD_PAGENUMS" flag >>>>> being automatically >>>>> set. If I manually select it, (ie select that "Pages" radio >>>>> button) then press print, >>>>> then voila, the NPE is back! >>>>> >>>>> -phil. >>>>> >>>>> >>>>> On 02/19/2016 10:53 AM, Phil Race wrote: >>>>>> I am not sure I can be correctly understanding the fix as the >>>>>> ramification seems >>>>>> to be that if the users wants to print only Page 3 of a 10 page >>>>>> document and so sets >>>>>> from page=3 and to page=3, that this request will be ignored and >>>>>> all pages will >>>>>> be printed .. can you test such a scenario. >>>>>> >>>>>> Additionally, have you tried running the original test case >>>>>> provided with 8061267 >>>>>> against your fix ? >>>>>> >>>>>> Also when I ran the HighResTest on a current build I saw a null >>>>>> graphics on >>>>>> the very first call to getGraphics() which is different than what >>>>>> I interpret >>>>>> you as saying - you see the null *after* the first page is printed. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 02/19/2016 01:18 AM, prasanta sadhukhan wrote: >>>>>>> Hi Phil, All, >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066139 >>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8066139/webrev.00/ >>>>>>> >>>>>>> It was seen after fix of JDK-8061267 >>>>>>> : PrinterJob: >>>>>>> Specified Page Ranges not displayed in Windows Native Print Dialog >>>>>>> the closed/java/awt/PrintJob/HighResTest/HighResTest.java was >>>>>>> failing with NPE when PrinterJob.getGraphics() is called the 2nd >>>>>>> time before calling PrinterJob.end(). >>>>>>> >>>>>>> The above fix caused this regression because it sets the >>>>>>> PD_PAGENUMS flag for windows PrintDlg struct which causes >>>>>>> *Pages* radio button to be selected in print dialog. >>>>>>> However, fromPage and toPage was both set to 1 so after the 1st >>>>>>> page is printed, RasterPrinterJob.print(attributes) finishes and >>>>>>> graphicsToBeDrawn.closeWhenEmpty() gets called >>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/d8def65c6c00/src/java.desktop/share/classes/sun/print/PrintJob2D.java#l1006 >>>>>>> >>>>>>> which sets the queue to null so when PrinterJob2D#getGraphics() >>>>>>> calls graphicsToBeDrawn.pop() it sees queue to be null and sets >>>>>>> graphics object to be null so >>>>>>> PrinterJob.getGraphics() gets null and g.drawLine in testcase >>>>>>> causes NPE since g is null. >>>>>>> >>>>>>> Fix was done to set the PD_PAGENUMS flag only when toPage is >>>>>>> more than fromPage in which case, "All" will be selected in >>>>>>> printer dialog and RasterPrinterJob.print() will finish only >>>>>>> after printing all the pages. >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>> >>>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Tue Mar 8 16:12:01 2016 From: philip.race at oracle.com (Philip Race) Date: Tue, 08 Mar 2016 08:12:01 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8034239, , PrintServiceLookup.lookupPrintServices() returns different amount of services in comparison with lpstat -v In-Reply-To: <56DEA8E6.7000708@oracle.com> References: <56D967E0.3030903@oracle.com> <56D9E59F.4040006@oracle.com> <56DD6401.2060907@oracle.com> <56DDE458.6010605@oracle.com> <56DEA8E6.7000708@oracle.com> Message-ID: <56DEF9D1.8050301@oracle.com> Approved. -phil On 3/8/16, 2:26 AM, prasanta sadhukhan wrote: > Hi Phil, > > It's my mistake. There's no need to copy as we are not passing the > supportedDocFlavors outside the class. I was influenced by the lines > before this where copyFlavors was copied from supportedDocFlavors. > Please find the updated webrev: > http://cr.openjdk.java.net/~psadhukhan/8034239/webrev.02/ > > Regards > Prasanta > On 3/8/2016 1:58 AM, Phil Race wrote: >> Why do the copy ? Why not just add one line >> >> supportedDocFlavors = flavor >> >> -phil. >> >> On 03/07/2016 03:20 AM, prasanta sadhukhan wrote: >>> Hi Phil, >>> >>> Please find the updated webrev: >>> http://cr.openjdk.java.net/~psadhukhan/8034239/webrev.01/ >>> >>> I checked JDK-8040139 also passed with this modification. >>> >>> Regards >>> Prasanya >>> On 3/5/2016 1:14 AM, Phil Race wrote: >>>> if the class is supposed to use the return value in this way what >>>> about these lines :- >>>> >>>> 1209 >>>> 1210 public boolean isIPPSupportedImages(String mimeType) { >>>> 1211 if (supportedDocFlavors == null) { >>>> 1212 getSupportedDocFlavors(); >>>> 1213 } >>>> >>>> It looks to me as if what you should really be doing is modifying >>>> the last few lines of getSupportedDocFlavors() as you are using >>>> the return value to update the variable which it should have >>>> assigned itself. >>>> >>>> -phil >>>> >>>> >>>> >>>> On 03/04/2016 02:48 AM, prasanta sadhukhan wrote: >>>>> Hi Phil, >>>>> >>>>> Please review a print service fix for jdk9 >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8034239 >>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8034239/webrev.00/ >>>>> >>>>> The issue was lpstat -v was reporting 2 printer service but >>>>> PrintServiceLookup.lookupPrintServices() list only 1. >>>>> #lpstat -v >>>>> device for tta_printer: >>>>> ipp:///printers/tta_printer >>>>> >>>>> device for Xerox-WorkCentre-4250: socket://spb04p12.ru.oracle.com:9100 >>>>> >>>>> but lookupPrintServices() listed only "Xerox" printer and not >>>>> "tta_printer". >>>>> >>>>> It seems "tta_printer" was added using >>>>> *lpadmin -pprinter-name -E -vdevice -m ppd >>>>> >>>>> * >>>>> so it becomes a "Remote Printer" and even though Java sees that >>>>> printer, it calls getUnsupportedAttributes() on that printer >>>>> service to see if that printer matches the DocFlavor. >>>>> In this case, this remote printer does not have any supported doc >>>>> flavor listed so when getSupportedDocFlavors() is called, it does >>>>> not see any "document-format-supported" attribute. >>>>> Although JDK-8040139 fixed this problem by adding >>>>> DocFlavor.SERVICE_FORMATTED.PAGEABLE andDocFlavor.SERVICE_FORMATTED.PRINTABLE >>>>> >>>>> to the supported DocFlavors since as per spec, >>>>> as per spec >>>>> /https://docs.oracle.com/javase/8/docs/api/index.html?javax/print/PrintService.html// >>>>> //it clearly says, / >>>>> getSupportedDocFlavors() >>>>> >>>>> /Returns:/ >>>>> /Array of supported doc flavors, should have at least one >>>>> element./ >>>>> >>>>> >>>>> the returned flavours are not populated to supported DocFlavors >>>>> called by IPPPrintService.java#getUnsupportedAttributes() -> >>>>> isDocFlavorSupported() so "supportedDocFlavors" was still false >>>>> for this case. >>>>> >>>>> I added a fix to populate the PAGEABLE & PRINTABLE docflavor to >>>>> "supportedDocFlavors" and tested in sqe machine and found it working. >>>>> >>>>> I could not add a regression testcase as it involves adding a >>>>> "remote printer" using lpadmin command. I would add "noreg-sqe" to >>>>> the bug. >>>>> >>>>> Regards >>>>> Prasanta >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Tue Mar 8 16:15:10 2016 From: philip.race at oracle.com (Philip Race) Date: Tue, 08 Mar 2016 08:15:10 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8066139, , Null return from PrintJob.getGraphics() running closed/java/awt/PrintJob/HighResTest/HighResTest.java In-Reply-To: <56DEA9B2.8020702@oracle.com> References: <56C6DDF1.1020009@oracle.com> <56C764B3.9020005@oracle.com> <56C77A50.7010605@oracle.com> <56CAAAC8.40009@oracle.com> <56CAC14F.4030602@oracle.com> <56D579B1.7090204@oracle.com> <56DDE8F2.3000707@oracle.com> <56DEA9B2.8020702@oracle.com> Message-ID: <56DEFA8E.3080203@oracle.com> > However, I am finding a strange issue with and without this fix too. The "Center" string is not printed Sounds completely unrelated to anything to do with the NPE bug. It is probably appropriate to file that as a separate bug. No big surprise that the behaviour is platform-specific as there is a lot of difference in Windows vs Linux (or vs Mac) in the printing code. -phil. On 3/8/16, 2:30 AM, prasanta sadhukhan wrote: > > > On 3/8/2016 2:17 AM, Phil Race wrote: >> I don't think starting a new thread can be right. That would re-invoke >> printerJob.print() which even if you can reuse a PrinterJob >> (something that >> was never set out in spec.) you are surely getting a new spool job .. not >> a continuation. There a couple of other things I am not sure about >> either. >> >> I've looked into this - only on Linux - and I believe the issue is that >> the test program has decided up-front how many pages it is going to >> print and it is paying no attention to the selected page ranges. >> Not what the 'user' asked for but it is perfectly within its rights >> to do so. >> >> However the 2D PrinterJob operates in a way where it calls back >> asking for the specific pages it wants to be printed and there the >> app. must comply. The PrinterJob terminates once it has done. >> >> In the case when the 2D PrinterJob is being used to 'run' a >> PrintJob then it must *never* return until the application has >> called "end" - or some exception occurs. >> >> So we need to remove the elements that will cause the job to exit. >> >> --- a/src/java.desktop/share/classes/sun/print/PrintJob2D.java >> +++ b/src/java.desktop/share/classes/sun/print/PrintJob2D.java >> @@ -995,6 +995,7 @@ >> public void run() { >> >> try { >> + attributes.remove(PageRanges.class); >> printerJob.print(attributes); >> } catch (PrinterException e) { >> //REMIND: need to store this away and not rethrow it. >> diff --git >> a/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java >> b/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java >> --- a/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java >> +++ b/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java >> @@ -1172,6 +1172,7 @@ >> pageRangesAttr = (PageRanges)attributes.get(PageRanges.class); >> if (!isSupportedValue(pageRangesAttr, attributes)) { >> pageRangesAttr = null; >> + setPageRange(-1, -1); >> } else { >> if ((SunPageSelection)attributes.get(SunPageSelection.class) >> == SunPageSelection.RANGE) { >> >> >> This works for me on Linux although >> a) I have not tried Windows) > I tried on windows. The NPE is not seen and it prints 2 pages. > However, I am finding a strange issue with and without this fix too. > The "Center" string is not printed in the 1st page in both "Portrait" > and "Landscape" mode (although the rectangles are printed) but is > printed in the 2nd page. > I do not find this issue in linux. > > Regards > Prasanta >> b) I have not verified if there are no negative consequences from the >> 2nd change. >> >> -phil. >> >> On 03/01/2016 03:14 AM, prasanta sadhukhan wrote: >>> Hi Phil, >>> >>> Please find an updated webrev: >>> http://cr.openjdk.java.net/~psadhukhan/8066139/webrev.01/ >>> >>> It seems if printerJobThread finished printing, it will set >>> graphicsToBeDrawn/graphicsDrawn ArrayList to null resulting in >>> getGraphics() returning null in the 2nd iteration causing NPE so >>> I have modified printerJobThread#run so that when it has finished >>> printing, do not set the arrayList to null but set a flag. In >>> getGraphics(), I check that flag and start a new printerJobThread to >>> handle the next printing. >>> I have tested "All" and "Pages" selection. >>> >>> Regards >>> Prasanta >>> On 2/22/2016 1:35 PM, Philip Race wrote: >>>> > It seems this behaviour is same in linux too for this HighResTest >>>> testcase. >>>> >>>> OK that is good information .. so is not really a regression from >>>> 8061267 as that >>>> is not in >>>> any way touching linux .. it is a pre-existing issue in a code path >>>> that was not being tested. >>>> >>>> -phil. >>>> >>>> On 2/22/16, 11:59 AM, prasanta sadhukhan wrote: >>>>> Hi Phil, >>>>> >>>>> >>Additionally, have you tried running the original test case >>>>> provided with 8061267 >>>>> >> against your fix ? >>>>> The 8061267 testcase behaves similarly before and after my fix. >>>>> >>>>> >> If I manually select it, (ie select that "Pages" radio button) >>>>> then press print, >>>>> >> then voila, the NPE is back! >>>>> It seems this behaviour is same in linux too for this HighResTest >>>>> testcase. >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 2/20/2016 1:55 AM, Phil Race wrote: >>>>>> I am having trouble building JDK 9 at the moment so i applied >>>>>> 8061267 to jdk8u-dev >>>>>> and was able to reproduce the regression and have a couple of >>>>>> observations >>>>>> >>>>>> - I am now seeing the NPE after the first page as you did .. >>>>>> puzzling. >>>>>> - I next applied your fix but still see the NPE ! >>>>>> >>>>>> It appears that all your fix did is stop the "PD_PAGENUMS" flag >>>>>> being automatically >>>>>> set. If I manually select it, (ie select that "Pages" radio >>>>>> button) then press print, >>>>>> then voila, the NPE is back! >>>>>> >>>>>> -phil. >>>>>> >>>>>> >>>>>> On 02/19/2016 10:53 AM, Phil Race wrote: >>>>>>> I am not sure I can be correctly understanding the fix as the >>>>>>> ramification seems >>>>>>> to be that if the users wants to print only Page 3 of a 10 page >>>>>>> document and so sets >>>>>>> from page=3 and to page=3, that this request will be ignored and >>>>>>> all pages will >>>>>>> be printed .. can you test such a scenario. >>>>>>> >>>>>>> Additionally, have you tried running the original test case >>>>>>> provided with 8061267 >>>>>>> against your fix ? >>>>>>> >>>>>>> Also when I ran the HighResTest on a current build I saw a null >>>>>>> graphics on >>>>>>> the very first call to getGraphics() which is different than >>>>>>> what I interpret >>>>>>> you as saying - you see the null *after* the first page is printed. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 02/19/2016 01:18 AM, prasanta sadhukhan wrote: >>>>>>>> Hi Phil, All, >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066139 >>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8066139/webrev.00/ >>>>>>>> >>>>>>>> It was seen after fix of JDK-8061267 >>>>>>>> : PrinterJob: >>>>>>>> Specified Page Ranges not displayed in Windows Native Print Dialog >>>>>>>> the closed/java/awt/PrintJob/HighResTest/HighResTest.java was >>>>>>>> failing with NPE when PrinterJob.getGraphics() is called the >>>>>>>> 2nd time before calling PrinterJob.end(). >>>>>>>> >>>>>>>> The above fix caused this regression because it sets the >>>>>>>> PD_PAGENUMS flag for windows PrintDlg struct which causes >>>>>>>> *Pages* radio button to be selected in print dialog. >>>>>>>> However, fromPage and toPage was both set to 1 so after the 1st >>>>>>>> page is printed, RasterPrinterJob.print(attributes) finishes >>>>>>>> and graphicsToBeDrawn.closeWhenEmpty() gets called >>>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/d8def65c6c00/src/java.desktop/share/classes/sun/print/PrintJob2D.java#l1006 >>>>>>>> >>>>>>>> which sets the queue to null so when PrinterJob2D#getGraphics() >>>>>>>> calls graphicsToBeDrawn.pop() it sees queue to be null and sets >>>>>>>> graphics object to be null so >>>>>>>> PrinterJob.getGraphics() gets null and g.drawLine in testcase >>>>>>>> causes NPE since g is null. >>>>>>>> >>>>>>>> Fix was done to set the PD_PAGENUMS flag only when toPage is >>>>>>>> more than fromPage in which case, "All" will be selected in >>>>>>>> printer dialog and RasterPrinterJob.print() will finish only >>>>>>>> after printing all the pages. >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>> >>>>>> >>>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jennifer.godinez at oracle.com Tue Mar 8 17:59:52 2016 From: jennifer.godinez at oracle.com (Jennifer Godinez) Date: Tue, 08 Mar 2016 09:59:52 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8034239, , PrintServiceLookup.lookupPrintServices() returns different amount of services in comparison with lpstat -v In-Reply-To: <56DEA8E6.7000708@oracle.com> References: <56D967E0.3030903@oracle.com> <56D9E59F.4040006@oracle.com> <56DD6401.2060907@oracle.com> <56DDE458.6010605@oracle.com> <56DEA8E6.7000708@oracle.com> Message-ID: <56DF1318.1060200@oracle.com> Hi Prasanta, Looks good. Jennifer On 03/08/2016 02:26 AM, prasanta sadhukhan wrote: > Hi Phil, > > It's my mistake. There's no need to copy as we are not passing the > supportedDocFlavors outside the class. I was influenced by the lines > before this where copyFlavors was copied from supportedDocFlavors. > Please find the updated webrev: > http://cr.openjdk.java.net/~psadhukhan/8034239/webrev.02/ > > Regards > Prasanta > On 3/8/2016 1:58 AM, Phil Race wrote: >> Why do the copy ? Why not just add one line >> >> supportedDocFlavors = flavor >> >> -phil. >> >> On 03/07/2016 03:20 AM, prasanta sadhukhan wrote: >>> Hi Phil, >>> >>> Please find the updated webrev: >>> http://cr.openjdk.java.net/~psadhukhan/8034239/webrev.01/ >>> >>> I checked JDK-8040139 also passed with this modification. >>> >>> Regards >>> Prasanya >>> On 3/5/2016 1:14 AM, Phil Race wrote: >>>> if the class is supposed to use the return value in this way what >>>> about these lines :- >>>> >>>> 1209 >>>> 1210 public boolean isIPPSupportedImages(String mimeType) { >>>> 1211 if (supportedDocFlavors == null) { >>>> 1212 getSupportedDocFlavors(); >>>> 1213 } >>>> >>>> It looks to me as if what you should really be doing is modifying >>>> the last few lines of getSupportedDocFlavors() as you are using >>>> the return value to update the variable which it should have >>>> assigned itself. >>>> >>>> -phil >>>> >>>> >>>> >>>> On 03/04/2016 02:48 AM, prasanta sadhukhan wrote: >>>>> Hi Phil, >>>>> >>>>> Please review a print service fix for jdk9 >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8034239 >>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8034239/webrev.00/ >>>>> >>>>> The issue was lpstat -v was reporting 2 printer service but >>>>> PrintServiceLookup.lookupPrintServices() list only 1. >>>>> #lpstat -v >>>>> device for tta_printer: >>>>> ipp:///printers/tta_printer >>>>> >>>>> device for Xerox-WorkCentre-4250: socket://spb04p12.ru.oracle.com:9100 >>>>> >>>>> but lookupPrintServices() listed only "Xerox" printer and not >>>>> "tta_printer". >>>>> >>>>> It seems "tta_printer" was added using >>>>> *lpadmin -pprinter-name -E -vdevice -m ppd >>>>> >>>>> * >>>>> so it becomes a "Remote Printer" and even though Java sees that >>>>> printer, it calls getUnsupportedAttributes() on that printer >>>>> service to see if that printer matches the DocFlavor. >>>>> In this case, this remote printer does not have any supported doc >>>>> flavor listed so when getSupportedDocFlavors() is called, it does >>>>> not see any "document-format-supported" attribute. >>>>> Although JDK-8040139 fixed this problem by adding >>>>> DocFlavor.SERVICE_FORMATTED.PAGEABLE andDocFlavor.SERVICE_FORMATTED.PRINTABLE >>>>> >>>>> to the supported DocFlavors since as per spec, >>>>> as per spec >>>>> /https://docs.oracle.com/javase/8/docs/api/index.html?javax/print/PrintService.html// >>>>> //it clearly says, / >>>>> getSupportedDocFlavors() >>>>> >>>>> /Returns:/ >>>>> /Array of supported doc flavors, should have at least one >>>>> element./ >>>>> >>>>> >>>>> the returned flavours are not populated to supported DocFlavors >>>>> called by IPPPrintService.java#getUnsupportedAttributes() -> >>>>> isDocFlavorSupported() so "supportedDocFlavors" was still false >>>>> for this case. >>>>> >>>>> I added a fix to populate the PAGEABLE & PRINTABLE docflavor to >>>>> "supportedDocFlavors" and tested in sqe machine and found it working. >>>>> >>>>> I could not add a regression testcase as it involves adding a >>>>> "remote printer" using lpadmin command. I would add "noreg-sqe" to >>>>> the bug. >>>>> >>>>> Regards >>>>> Prasanta >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Tue Mar 8 21:53:04 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 8 Mar 2016 13:53:04 -0800 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : drawImage misses background's alpha channel In-Reply-To: References: <05dd240c-0f46-486e-b9d9-be51984415d3@default> <56D77BD7.2020302@oracle.com> <56D8CDF8.5020404@oracle.com> <993df6ff-6bd6-43a1-b0c7-33dcedb27b24@default> <56DE1D22.3000205@oracle.com> Message-ID: <56DF49C0.4070200@oracle.com> Hi Jay, On 3/8/16 12:56 AM, Jayathirth D V wrote: > Hi Jim, > > Thanks for the review. I have made changes in test case based on input provided. > 1) Added contentsLost() after we drawImage() and getSnapshot() to verify the content and if it is lost loop again. Unfortunately, if contents are lost you need to loop back to where you create the image, which means you don't have enough code inside the while loop. All of the items I mentioned below in my comment need to be included in that "loop back around". To be painfully clear here, the loop should look like this: backgroundColor = ...; /* no need to create this inside the loop */ do { img = ...; Graphics2D imgGraphics = img.createGraphics(); // fill img with transparency imgGraphics.drawImage(..., bgColor); img.getSnapShot(); imgGraphics.dispose(); } while (img.contentsLost()); The rest looked fine... ...jim From jayathirth.d.v at oracle.com Wed Mar 9 06:44:01 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 8 Mar 2016 22:44:01 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : drawImage misses background's alpha channel In-Reply-To: <56DF49C0.4070200@oracle.com> References: <05dd240c-0f46-486e-b9d9-be51984415d3@default> <56D77BD7.2020302@oracle.com> <56D8CDF8.5020404@oracle.com> <993df6ff-6bd6-43a1-b0c7-33dcedb27b24@default> <56DE1D22.3000205@oracle.com> <56DF49C0.4070200@oracle.com> Message-ID: Hi Jim, I have made changes mentioned by you. Please find updated webrev: http://cr.openjdk.java.net/~jdv/8139183/webrev.05/ Thanks, Jay -----Original Message----- From: Jim Graham Sent: Wednesday, March 09, 2016 3:23 AM To: Jayathirth D V Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : drawImage misses background's alpha channel Hi Jay, On 3/8/16 12:56 AM, Jayathirth D V wrote: > Hi Jim, > > Thanks for the review. I have made changes in test case based on input provided. > 1) Added contentsLost() after we drawImage() and getSnapshot() to verify the content and if it is lost loop again. Unfortunately, if contents are lost you need to loop back to where you create the image, which means you don't have enough code inside the while loop. All of the items I mentioned below in my comment need to be included in that "loop back around". To be painfully clear here, the loop should look like this: backgroundColor = ...; /* no need to create this inside the loop */ do { img = ...; Graphics2D imgGraphics = img.createGraphics(); // fill img with transparency imgGraphics.drawImage(..., bgColor); img.getSnapShot(); imgGraphics.dispose(); } while (img.contentsLost()); The rest looked fine... ...jim From Sergey.Bylokhov at oracle.com Wed Mar 9 10:36:15 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 9 Mar 2016 13:36:15 +0300 Subject: [OpenJDK 2D-Dev] [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception In-Reply-To: <3969befd-57cd-48ee-bed5-173a28e7bd08@default> References: <3969befd-57cd-48ee-bed5-173a28e7bd08@default> Message-ID: <56DFFC9F.4020403@oracle.com> Changes for 2d area.(cc) On 07.03.16 11:20, Ajit Ghaisas wrote: > Hi, > > Bug : https://bugs.openjdk.java.net/browse/JDK-6353518 > > Issue : (Text from bug description) > > An attempt to create a WritableRaster via > Raster.createWritableRaster(SampleModel sm, DataBuffer db, Point > location) using a custom DataBuffer causes an erroneous > RasterFormatException. > Apparently the reason for this bug is that IntegerComponentRaster > insists on being passed an instance of DataBufferInt rather than just a > DataBuffer with a DataType of TYPE_INT. > This is quite annoying since DataBufferInt is declared final and thus > cannot be extended. > > Fix : > > The last line of Raster.createWritableRaster() method already has a way > to handle generic case if the input does not match any of the cases in > switch statements in that method. > > The fact that ? *InterleavedRaster() constructors throw exception if > DataBuffer passed to them does not match the expected type? was ignored > earlier. > > This fix adds a check of ?DataBuffer type? before creating respective > *InterleavedRaster() objects. > > It constructs the SunWritableRaster in case DataBuffer type does not > match any data specific DataBuffer classes (DataBufferByte, > DataBufferUShort, DataBufferInt) > > Request to review webrev containing this fix : > > http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.00/ > > Regards, > > Ajit > -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Wed Mar 9 12:43:05 2016 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 9 Mar 2016 16:43:05 +0400 Subject: [OpenJDK 2D-Dev] [9] Review request for 8142966 Wrong cursor position in text components on HiDPI display In-Reply-To: <56BE3D82.5010506@oracle.com> References: <56A935F0.5060504@oracle.com> <56B4FA69.9000604@oracle.com> <56B6112F.1050708@oracle.com> <56B8E930.9000405@oracle.com> <56B9FC1F.9090607@oracle.com> <56B9FE27.4040204@oracle.com> <56BE3D82.5010506@oracle.com> Message-ID: <56E01A59.8070604@oracle.com> Hello, Could you review the proposed fix? Thanks, Alexandr. On 13/02/16 00:16, Alexander Scherbatiy wrote: > On 09/02/16 18:56, Sergey Bylokhov wrote: >> Also probably it will be possible to test this via the public api >> only(using the mix of the graphics transform + font transform). >> >> On 09.02.16 17:47, Sergey Bylokhov wrote: >>> Some additional information. >>> The Swing calculates the size of the components and location of the >>> cursor based on the text metrics. And these text metrics based on >>> advance. The Swing do not know to what destination it will be painted, >>> it calculates the size based on the non-scaled(non-retina) destination. >>> The problem occurs when we paint such component to the hidpi screen, >>> because we get small round errors per glyph -> this causes a visible >>> issue? when the text string is long. As a solution on the macosx the >>> round operation was done in the users space instead of dev space. >>> >>> For example before the fix the size 1.4px was rounded to 3 (1.4 * 2 = >>> 2.8 -> 3), but after the fix it will be 2 (1.4-> 1 * 2 = 2). So the >>> Swing will be able to calculate correct size/location without >>> information of the device scale. Note that the 3px(in dev space) is a >>> kind of fractional coordinate in the user space(1.5). And the Swing >>> does >>> not work properly when fractional metrics are used, because it use ints >>> as a coordinates. >>> >>> Note that the fix should be applied only when fractional metrics is >>> off, >>> otherwise we should not use any rounding. I am not sure that the >>> current >>> fix take it into account. > The proposed fix is applied only when the fractional metrics are off. >>> >>> >>> On 08.02.16 22:14, Jim Graham wrote: >>>> Isn't the problem there that we are returning an integer as the >>>> advance? >>>> Why aren't we returning 7.35 as a value instead of 8? > 7.35 is returned when fractional metrics are on. >>>> >>>> Also, shouldn't 7.35 round to 7 and 14.7 round to 15? > This happens because when fractional metrics are on the glyph > linearAdvance value is returned (for current case > ftglyph->linearHoriAdvance = 7.35). > But when fractional metrics are off the glyph advance is returned > (ftglyph->advance.x = 8). > This calculation is done by freetype library. > > Thanks, > Alexandr. > >>>> >>>> ...jim >>>> >>>> On 2/6/2016 7:28 AM, Alexander Scherbatiy wrote: >>>>> On 05/02/16 23:39, Phil Race wrote: >>>>>> Two things strike me when I read this >>>>>> >>>>>> 1) Initial surprise at how deep into the font code it goes. >>>>>> Perhaps there are alternatives. >>>>>> >>>>>> 2) That it changes to using the linear metrics for measuring >>>>>> advance. >>>>>> Regardless of (1) I do not think (2) is correct. I am fairly sure >>>>>> this >>>>>> will lead to changes in text advance. It seems like it must throw >>>>>> away adjusted metrics as a result of glyph hinting. >>>>>> >>>>>> I don't know what the fix should be, since I have not looked at the >>>>>> problem top-down, I am just seeing the bottom-up proposed solution. >>>>>> So all I can say for now is that it needs to be at least somewhat >>>>>> different. >>>>> >>>>> There was the same issue on Mac OS X which has been fixed in the >>>>> similar way: >>>>> 8013569 [macosx] JLabel preferred size incorrect on retina >>>>> displays >>>>> with non-default font size >>>>> https://bugs.openjdk.java.net/browse/JDK-8013569 >>>>> http://cr.openjdk.java.net/~serb/7190349/webrev.04/ >>>>> >>>>> The problem is that in many case for UI scale 2 we return to a >>>>> user >>>>> an unscaled value. >>>>> But a value for transformed glyph advance, rounded and descaled >>>>> can >>>>> differ from just rounded glyph advance. >>>>> >>>>> For example, font[dialog, plain, 12] char 'a': >>>>> transform: 12, advance: 7.35, rounded advance: 8 >>>>> transform: 24, advance: 14.70 round advance: 14 >>>>> >>>>> and 8 does not equal 14 / 2. >>>>> >>>>> The solution for Mac OS X was to get the glyph advance using only >>>>> font transform, round it and then apply the dev transform: >>>>> >>>>> CGGlyphImages.m: >>>>> 481 advance = CGSizeApplyAffineTransform(advance, >>>>> strike->fFontTx); >>>>> 482 if (!JRSFontStyleUsesFractionalMetrics(strike->fStyle)) { >>>>> 483 advance.width = round(advance.width); >>>>> 484 advance.height = round(advance.height); >>>>> 485 } >>>>> 486 advance = CGSizeApplyAffineTransform(advance, >>>>> strike->fDevTx); >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 01/27/2016 01:26 PM, Alexander Scherbatiy wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Could you review the fix: >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8142966 >>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8142966/webev.00/ >>>>>>> >>>>>>> The proposed fix rounds a glyph advance first and then scales >>>>>>> it if >>>>>>> UI scales do not equal to one. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>> >>>>> >>> >>> >> >> > From Sergey.Bylokhov at oracle.com Wed Mar 9 12:58:15 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 9 Mar 2016 15:58:15 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8151303 [macosx] [hidpi] JButton's low-res. icon is visible when clicking on it In-Reply-To: <56E01777.1030202@oracle.com> References: <56E01777.1030202@oracle.com> Message-ID: <56E01DE7.9040103@oracle.com> Probably we should enhance ImageProducer/Tk.createImage/ImageFilter to support this functionality? It seems that the number of usage of this check "image instanceof MultiResolutionImage" will grow over time. I think that at least our own API should support MultiResolutionImage w/o such checks, otherwise the user will need to do the same. cc 2d-dev On 09.03.16 15:30, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8151303 > webrev: http://cr.openjdk.java.net/~alexsch/8151303/webrev.00 > > The AquaUtils does not take into account MultiResolutionImage for > selected/disabled/lightened images generation. > The fix also leaves the MultiResolutionCachedImage check because the > base system icon size can be differ from the requested painted size. > > Thanks, > Alexandr. -- Best regards, Sergey. From ajit.ghaisas at oracle.com Wed Mar 9 14:38:31 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Wed, 9 Mar 2016 06:38:31 -0800 (PST) Subject: [OpenJDK 2D-Dev] [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception In-Reply-To: <56DFFC9F.4020403@oracle.com> References: <3969befd-57cd-48ee-bed5-173a28e7bd08@default> <56DFFC9F.4020403@oracle.com> Message-ID: <70f247c0-6f3e-472a-b7b0-b02814010e30@default> Hi, Modified the test and added check for MultiPixelPackedSampleModel condition. Please review updated webrev : http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.01/ Regards, Ajit -----Original Message----- From: Sergey Bylokhov Sent: Wednesday, March 09, 2016 4:06 PM To: Ajit Ghaisas; awt-dev at openjdk.java.net; Semyon Sadetsky; Ambarish Rapte; 2d-dev Subject: Re: [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception Changes for 2d area.(cc) On 07.03.16 11:20, Ajit Ghaisas wrote: > Hi, > > Bug : https://bugs.openjdk.java.net/browse/JDK-6353518 > > Issue : (Text from bug description) > > An attempt to create a WritableRaster via > Raster.createWritableRaster(SampleModel sm, DataBuffer db, Point > location) using a custom DataBuffer causes an erroneous > RasterFormatException. > Apparently the reason for this bug is that IntegerComponentRaster > insists on being passed an instance of DataBufferInt rather than just > a DataBuffer with a DataType of TYPE_INT. > This is quite annoying since DataBufferInt is declared final and thus > cannot be extended. > > Fix : > > The last line of Raster.createWritableRaster() method already has a > way to handle generic case if the input does not match any of the > cases in switch statements in that method. > > The fact that " *InterleavedRaster() constructors throw exception if > DataBuffer passed to them does not match the expected type" was > ignored earlier. > > This fix adds a check of "DataBuffer type" before creating respective > *InterleavedRaster() objects. > > It constructs the SunWritableRaster in case DataBuffer type does not > match any data specific DataBuffer classes (DataBufferByte, > DataBufferUShort, DataBufferInt) > > Request to review webrev containing this fix : > > http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.00/ > > Regards, > > Ajit > -- Best regards, Sergey. From james.graham at oracle.com Wed Mar 9 23:30:49 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 9 Mar 2016 15:30:49 -0800 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : drawImage misses background's alpha channel In-Reply-To: References: <05dd240c-0f46-486e-b9d9-be51984415d3@default> <56D77BD7.2020302@oracle.com> <56D8CDF8.5020404@oracle.com> <993df6ff-6bd6-43a1-b0c7-33dcedb27b24@default> <56DE1D22.3000205@oracle.com> <56DF49C0.4070200@oracle.com> Message-ID: <56E0B229.4000602@oracle.com> That looks good to go. A couple of code indentation issues in the test case: Per: http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-142311.html#454 for statements should have a space as in "for (...)" otherwise it looks like a call to a function named "for()". do-while statements also need a space before/after the braces and between while and the parentheses, as in: do { } while (...); I don't need to review those code style issues, but please fix them before you push it... ...jim On 3/8/16 10:44 PM, Jayathirth D V wrote: > Hi Jim, > > I have made changes mentioned by you. > > Please find updated webrev: > http://cr.openjdk.java.net/~jdv/8139183/webrev.05/ > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Wednesday, March 09, 2016 3:23 AM > To: Jayathirth D V > Cc: 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : drawImage misses background's alpha channel > > Hi Jay, > > On 3/8/16 12:56 AM, Jayathirth D V wrote: >> Hi Jim, >> >> Thanks for the review. I have made changes in test case based on input provided. >> 1) Added contentsLost() after we drawImage() and getSnapshot() to verify the content and if it is lost loop again. > > Unfortunately, if contents are lost you need to loop back to where you create the image, which means you don't have enough code inside the while loop. All of the items I mentioned below in my comment need to be included in that "loop back around". To be painfully clear here, the loop should look like this: > > backgroundColor = ...; /* no need to create this inside the loop */ > do { > img = ...; > Graphics2D imgGraphics = img.createGraphics(); > // fill img with transparency > imgGraphics.drawImage(..., bgColor); > img.getSnapShot(); > imgGraphics.dispose(); > } while (img.contentsLost()); > > The rest looked fine... > > ...jim > From james.graham at oracle.com Wed Mar 9 23:57:44 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 9 Mar 2016 15:57:44 -0800 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : drawImage misses background's alpha channel In-Reply-To: <56E0B229.4000602@oracle.com> References: <05dd240c-0f46-486e-b9d9-be51984415d3@default> <56D77BD7.2020302@oracle.com> <56D8CDF8.5020404@oracle.com> <993df6ff-6bd6-43a1-b0c7-33dcedb27b24@default> <56DE1D22.3000205@oracle.com> <56DF49C0.4070200@oracle.com> <56E0B229.4000602@oracle.com> Message-ID: <56E0B878.6090502@oracle.com> Also, line 59, "if{" => "if {"... ...jim On 3/9/16 3:30 PM, Jim Graham wrote: > That looks good to go. > > A couple of code indentation issues in the test case: > > Per: > http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-142311.html#454 > > > for statements should have a space as in "for (...)" otherwise it looks > like a call to a function named "for()". > > do-while statements also need a space before/after the braces and > between while and the parentheses, as in: > do { > } while (...); > > I don't need to review those code style issues, but please fix them > before you push it... > > ...jim > > On 3/8/16 10:44 PM, Jayathirth D V wrote: >> Hi Jim, >> >> I have made changes mentioned by you. >> >> Please find updated webrev: >> http://cr.openjdk.java.net/~jdv/8139183/webrev.05/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Wednesday, March 09, 2016 3:23 AM >> To: Jayathirth D V >> Cc: 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : >> drawImage misses background's alpha channel >> >> Hi Jay, >> >> On 3/8/16 12:56 AM, Jayathirth D V wrote: >>> Hi Jim, >>> >>> Thanks for the review. I have made changes in test case based on >>> input provided. >>> 1) Added contentsLost() after we drawImage() and getSnapshot() to >>> verify the content and if it is lost loop again. >> >> Unfortunately, if contents are lost you need to loop back to where you >> create the image, which means you don't have enough code inside the >> while loop. All of the items I mentioned below in my comment need to >> be included in that "loop back around". To be painfully clear here, >> the loop should look like this: >> >> backgroundColor = ...; /* no need to create this inside the >> loop */ >> do { >> img = ...; >> Graphics2D imgGraphics = img.createGraphics(); >> // fill img with transparency >> imgGraphics.drawImage(..., bgColor); >> img.getSnapShot(); >> imgGraphics.dispose(); >> } while (img.contentsLost()); >> >> The rest looked fine... >> >> ...jim >> From jayathirth.d.v at oracle.com Thu Mar 10 06:23:11 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 9 Mar 2016 22:23:11 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : drawImage misses background's alpha channel In-Reply-To: <56E0B878.6090502@oracle.com> References: <05dd240c-0f46-486e-b9d9-be51984415d3@default> <56D77BD7.2020302@oracle.com> <56D8CDF8.5020404@oracle.com> <993df6ff-6bd6-43a1-b0c7-33dcedb27b24@default> <56DE1D22.3000205@oracle.com> <56DF49C0.4070200@oracle.com> <56E0B229.4000602@oracle.com> <56E0B878.6090502@oracle.com> Message-ID: <8467c9c3-cdd1-42b7-87ab-4c646e5875db@default> Jim thanks for the review. Prasanta I have updated the webrev to address indentation issues. Please review: http://cr.openjdk.java.net/~jdv/8139183/webrev.06/ Thanks, Jay -----Original Message----- From: Jim Graham Sent: Thursday, March 10, 2016 5:28 AM To: Jayathirth D V Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : drawImage misses background's alpha channel Also, line 59, "if{" => "if {"... ...jim On 3/9/16 3:30 PM, Jim Graham wrote: > That looks good to go. > > A couple of code indentation issues in the test case: > > Per: > http://www.oracle.com/technetwork/java/javase/documentation/codeconven > tions-142311.html#454 > > > for statements should have a space as in "for (...)" otherwise it > looks like a call to a function named "for()". > > do-while statements also need a space before/after the braces and > between while and the parentheses, as in: > do { > } while (...); > > I don't need to review those code style issues, but please fix them > before you push it... > > ...jim > > On 3/8/16 10:44 PM, Jayathirth D V wrote: >> Hi Jim, >> >> I have made changes mentioned by you. >> >> Please find updated webrev: >> http://cr.openjdk.java.net/~jdv/8139183/webrev.05/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Wednesday, March 09, 2016 3:23 AM >> To: Jayathirth D V >> Cc: 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : >> drawImage misses background's alpha channel >> >> Hi Jay, >> >> On 3/8/16 12:56 AM, Jayathirth D V wrote: >>> Hi Jim, >>> >>> Thanks for the review. I have made changes in test case based on >>> input provided. >>> 1) Added contentsLost() after we drawImage() and getSnapshot() to >>> verify the content and if it is lost loop again. >> >> Unfortunately, if contents are lost you need to loop back to where >> you create the image, which means you don't have enough code inside >> the while loop. All of the items I mentioned below in my comment >> need to be included in that "loop back around". To be painfully >> clear here, the loop should look like this: >> >> backgroundColor = ...; /* no need to create this inside the >> loop */ >> do { >> img = ...; >> Graphics2D imgGraphics = img.createGraphics(); >> // fill img with transparency >> imgGraphics.drawImage(..., bgColor); >> img.getSnapShot(); >> imgGraphics.dispose(); >> } while (img.contentsLost()); >> >> The rest looked fine... >> >> ...jim >> From prasanta.sadhukhan at oracle.com Thu Mar 10 06:39:34 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Thu, 10 Mar 2016 12:09:34 +0530 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : drawImage misses background's alpha channel In-Reply-To: <8467c9c3-cdd1-42b7-87ab-4c646e5875db@default> References: <05dd240c-0f46-486e-b9d9-be51984415d3@default> <56D77BD7.2020302@oracle.com> <56D8CDF8.5020404@oracle.com> <993df6ff-6bd6-43a1-b0c7-33dcedb27b24@default> <56DE1D22.3000205@oracle.com> <56DF49C0.4070200@oracle.com> <56E0B229.4000602@oracle.com> <56E0B878.6090502@oracle.com> <8467c9c3-cdd1-42b7-87ab-4c646e5875db@default> Message-ID: <56E116A6.8060507@oracle.com> Looks good to me. Only thing that can be improved is instead of wildcard imports, you can have specific imports in testcase. Regards Prasanta On 3/10/2016 11:53 AM, Jayathirth D V wrote: > Jim thanks for the review. > > Prasanta I have updated the webrev to address indentation issues. Please review: > http://cr.openjdk.java.net/~jdv/8139183/webrev.06/ > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Thursday, March 10, 2016 5:28 AM > To: Jayathirth D V > Cc: 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : drawImage misses background's alpha channel > > Also, line 59, "if{" => "if {"... > > ...jim > > On 3/9/16 3:30 PM, Jim Graham wrote: >> That looks good to go. >> >> A couple of code indentation issues in the test case: >> >> Per: >> http://www.oracle.com/technetwork/java/javase/documentation/codeconven >> tions-142311.html#454 >> >> >> for statements should have a space as in "for (...)" otherwise it >> looks like a call to a function named "for()". >> >> do-while statements also need a space before/after the braces and >> between while and the parentheses, as in: >> do { >> } while (...); >> >> I don't need to review those code style issues, but please fix them >> before you push it... >> >> ...jim >> >> On 3/8/16 10:44 PM, Jayathirth D V wrote: >>> Hi Jim, >>> >>> I have made changes mentioned by you. >>> >>> Please find updated webrev: >>> http://cr.openjdk.java.net/~jdv/8139183/webrev.05/ >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Jim Graham >>> Sent: Wednesday, March 09, 2016 3:23 AM >>> To: Jayathirth D V >>> Cc: 2d-dev at openjdk.java.net >>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : >>> drawImage misses background's alpha channel >>> >>> Hi Jay, >>> >>> On 3/8/16 12:56 AM, Jayathirth D V wrote: >>>> Hi Jim, >>>> >>>> Thanks for the review. I have made changes in test case based on >>>> input provided. >>>> 1) Added contentsLost() after we drawImage() and getSnapshot() to >>>> verify the content and if it is lost loop again. >>> Unfortunately, if contents are lost you need to loop back to where >>> you create the image, which means you don't have enough code inside >>> the while loop. All of the items I mentioned below in my comment >>> need to be included in that "loop back around". To be painfully >>> clear here, the loop should look like this: >>> >>> backgroundColor = ...; /* no need to create this inside the >>> loop */ >>> do { >>> img = ...; >>> Graphics2D imgGraphics = img.createGraphics(); >>> // fill img with transparency >>> imgGraphics.drawImage(..., bgColor); >>> img.getSnapShot(); >>> imgGraphics.dispose(); >>> } while (img.contentsLost()); >>> >>> The rest looked fine... >>> >>> ...jim >>> From prasanta.sadhukhan at oracle.com Thu Mar 10 10:34:24 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Thu, 10 Mar 2016 16:04:24 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8066139, , Null return from PrintJob.getGraphics() running closed/java/awt/PrintJob/HighResTest/HighResTest.java In-Reply-To: <56DEFA8E.3080203@oracle.com> References: <56C6DDF1.1020009@oracle.com> <56C764B3.9020005@oracle.com> <56C77A50.7010605@oracle.com> <56CAAAC8.40009@oracle.com> <56CAC14F.4030602@oracle.com> <56D579B1.7090204@oracle.com> <56DDE8F2.3000707@oracle.com> <56DEA9B2.8020702@oracle.com> <56DEFA8E.3080203@oracle.com> Message-ID: <56E14DB0.8030506@oracle.com> Hi Phil, Please find the modified webrev http://cr.openjdk.java.net/~psadhukhan/8066139/webrev.02/ I tested in Mac too but there it seems to be working (ie no NPE) without and with this fix. For issue seen on windows , I have raised a bug JDK-8151589 (strangely it is not seen in jdk1.8.0_76 but seen from 1.9.0-ea-b01 onwards, can you tell me what is the release version before b01?] Regards Prasanta On 3/8/2016 9:45 PM, Philip Race wrote: > > However, I am finding a strange issue with and without this fix too. > The "Center" string is not printed > > Sounds completely unrelated to anything to do with the NPE bug. > > It is probably appropriate to file that as a separate bug. > No big surprise that the behaviour is platform-specific as there > is a lot of difference in Windows vs Linux (or vs Mac) in the printing > code. > > -phil. > > On 3/8/16, 2:30 AM, prasanta sadhukhan wrote: >> >> >> On 3/8/2016 2:17 AM, Phil Race wrote: >>> I don't think starting a new thread can be right. That would re-invoke >>> printerJob.print() which even if you can reuse a PrinterJob >>> (something that >>> was never set out in spec.) you are surely getting a new spool job >>> .. not >>> a continuation. There a couple of other things I am not sure about >>> either. >>> >>> I've looked into this - only on Linux - and I believe the issue is that >>> the test program has decided up-front how many pages it is going to >>> print and it is paying no attention to the selected page ranges. >>> Not what the 'user' asked for but it is perfectly within its rights >>> to do so. >>> >>> However the 2D PrinterJob operates in a way where it calls back >>> asking for the specific pages it wants to be printed and there the >>> app. must comply. The PrinterJob terminates once it has done. >>> >>> In the case when the 2D PrinterJob is being used to 'run' a >>> PrintJob then it must *never* return until the application has >>> called "end" - or some exception occurs. >>> >>> So we need to remove the elements that will cause the job to exit. >>> >>> --- a/src/java.desktop/share/classes/sun/print/PrintJob2D.java >>> +++ b/src/java.desktop/share/classes/sun/print/PrintJob2D.java >>> @@ -995,6 +995,7 @@ >>> public void run() { >>> >>> try { >>> + attributes.remove(PageRanges.class); >>> printerJob.print(attributes); >>> } catch (PrinterException e) { >>> //REMIND: need to store this away and not rethrow it. >>> diff --git >>> a/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java >>> b/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java >>> --- a/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java >>> +++ b/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java >>> @@ -1172,6 +1172,7 @@ >>> pageRangesAttr = (PageRanges)attributes.get(PageRanges.class); >>> if (!isSupportedValue(pageRangesAttr, attributes)) { >>> pageRangesAttr = null; >>> + setPageRange(-1, -1); >>> } else { >>> if >>> ((SunPageSelection)attributes.get(SunPageSelection.class) >>> == SunPageSelection.RANGE) { >>> >>> >>> This works for me on Linux although >>> a) I have not tried Windows) >> I tried on windows. The NPE is not seen and it prints 2 pages. >> However, I am finding a strange issue with and without this fix too. >> The "Center" string is not printed in the 1st page in both "Portrait" >> and "Landscape" mode (although the rectangles are printed) but is >> printed in the 2nd page. >> I do not find this issue in linux. >> >> Regards >> Prasanta >>> b) I have not verified if there are no negative consequences from >>> the 2nd change. >>> >>> -phil. >>> >>> On 03/01/2016 03:14 AM, prasanta sadhukhan wrote: >>>> Hi Phil, >>>> >>>> Please find an updated webrev: >>>> http://cr.openjdk.java.net/~psadhukhan/8066139/webrev.01/ >>>> >>>> It seems if printerJobThread finished printing, it will set >>>> graphicsToBeDrawn/graphicsDrawn ArrayList to null resulting in >>>> getGraphics() returning null in the 2nd iteration causing NPE so >>>> I have modified printerJobThread#run so that when it has finished >>>> printing, do not set the arrayList to null but set a flag. In >>>> getGraphics(), I check that flag and start a new printerJobThread >>>> to handle the next printing. >>>> I have tested "All" and "Pages" selection. >>>> >>>> Regards >>>> Prasanta >>>> On 2/22/2016 1:35 PM, Philip Race wrote: >>>>> > It seems this behaviour is same in linux too for this >>>>> HighResTest testcase. >>>>> >>>>> OK that is good information .. so is not really a regression from >>>>> 8061267 as that >>>>> is not in >>>>> any way touching linux .. it is a pre-existing issue in a code >>>>> path that was not being tested. >>>>> >>>>> -phil. >>>>> >>>>> On 2/22/16, 11:59 AM, prasanta sadhukhan wrote: >>>>>> Hi Phil, >>>>>> >>>>>> >>Additionally, have you tried running the original test case >>>>>> provided with 8061267 >>>>>> >> against your fix ? >>>>>> The 8061267 testcase behaves similarly before and after my fix. >>>>>> >>>>>> >> If I manually select it, (ie select that "Pages" radio button) >>>>>> then press print, >>>>>> >> then voila, the NPE is back! >>>>>> It seems this behaviour is same in linux too for this HighResTest >>>>>> testcase. >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> On 2/20/2016 1:55 AM, Phil Race wrote: >>>>>>> I am having trouble building JDK 9 at the moment so i applied >>>>>>> 8061267 to jdk8u-dev >>>>>>> and was able to reproduce the regression and have a couple of >>>>>>> observations >>>>>>> >>>>>>> - I am now seeing the NPE after the first page as you did .. >>>>>>> puzzling. >>>>>>> - I next applied your fix but still see the NPE ! >>>>>>> >>>>>>> It appears that all your fix did is stop the "PD_PAGENUMS" flag >>>>>>> being automatically >>>>>>> set. If I manually select it, (ie select that "Pages" radio >>>>>>> button) then press print, >>>>>>> then voila, the NPE is back! >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> >>>>>>> On 02/19/2016 10:53 AM, Phil Race wrote: >>>>>>>> I am not sure I can be correctly understanding the fix as the >>>>>>>> ramification seems >>>>>>>> to be that if the users wants to print only Page 3 of a 10 page >>>>>>>> document and so sets >>>>>>>> from page=3 and to page=3, that this request will be ignored >>>>>>>> and all pages will >>>>>>>> be printed .. can you test such a scenario. >>>>>>>> >>>>>>>> Additionally, have you tried running the original test case >>>>>>>> provided with 8061267 >>>>>>>> against your fix ? >>>>>>>> >>>>>>>> Also when I ran the HighResTest on a current build I saw a null >>>>>>>> graphics on >>>>>>>> the very first call to getGraphics() which is different than >>>>>>>> what I interpret >>>>>>>> you as saying - you see the null *after* the first page is printed. >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> On 02/19/2016 01:18 AM, prasanta sadhukhan wrote: >>>>>>>>> Hi Phil, All, >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066139 >>>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8066139/webrev.00/ >>>>>>>>> >>>>>>>>> It was seen after fix of JDK-8061267 >>>>>>>>> : >>>>>>>>> PrinterJob: Specified Page Ranges not displayed in Windows >>>>>>>>> Native Print Dialog >>>>>>>>> the closed/java/awt/PrintJob/HighResTest/HighResTest.java was >>>>>>>>> failing with NPE when PrinterJob.getGraphics() is called the >>>>>>>>> 2nd time before calling PrinterJob.end(). >>>>>>>>> >>>>>>>>> The above fix caused this regression because it sets the >>>>>>>>> PD_PAGENUMS flag for windows PrintDlg struct which causes >>>>>>>>> *Pages* radio button to be selected in print dialog. >>>>>>>>> However, fromPage and toPage was both set to 1 so after the >>>>>>>>> 1st page is printed, RasterPrinterJob.print(attributes) >>>>>>>>> finishes and graphicsToBeDrawn.closeWhenEmpty() gets called >>>>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/d8def65c6c00/src/java.desktop/share/classes/sun/print/PrintJob2D.java#l1006 >>>>>>>>> >>>>>>>>> which sets the queue to null so when >>>>>>>>> PrinterJob2D#getGraphics() calls graphicsToBeDrawn.pop() it >>>>>>>>> sees queue to be null and sets graphics object to be null so >>>>>>>>> PrinterJob.getGraphics() gets null and g.drawLine in testcase >>>>>>>>> causes NPE since g is null. >>>>>>>>> >>>>>>>>> Fix was done to set the PD_PAGENUMS flag only when toPage is >>>>>>>>> more than fromPage in which case, "All" will be selected in >>>>>>>>> printer dialog and RasterPrinterJob.print() will finish only >>>>>>>>> after printing all the pages. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Prasanta >>>>>>>> >>>>>>> >>>>>> >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Thu Mar 10 10:34:40 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Thu, 10 Mar 2016 16:04:40 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8151590, , "ALL" radio button is not selected in printDialog when we call DefaultSelectionType.ALL in windows Message-ID: <56E14DC0.6020505@oracle.com> Hi Phil, Bug: https://bugs.openjdk.java.net/browse/JDK-8151590 webrev: http://cr.openjdk.java.net/~psadhukhan/8151590/webrev.00/ The issue is if application calls JobAttributes.setDefaultSelection(JobAttributes.DefaultSelectionType.ALL); along with JobAttributes.setFromPage(2); JobAttributes.setToPage(5); then "Page" radio button is selected in windows. In linux and mac, "All" radio button is selected. Although the spec is not very clear as to what should get preference, it seems logically DefaultSelection should hold preference. This is a regression from 8061267 where PD_PAGENUMS was added to the flags resulting in "Page" radio button getting selected. I added a fix to add PD_PAGENUMS to the flags only if the selection attribute is not "PD_ALLPAGES" [which gets selected when JobAttributes.setDefaultSelection(JobAttributes.DefaultSelectionType.ALL); is called] I tested 8061267 testcase behaviour is same with this fix. Regards Prasanta From Sergey.Bylokhov at oracle.com Thu Mar 10 12:48:10 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 10 Mar 2016 15:48:10 +0300 Subject: [OpenJDK 2D-Dev] [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception In-Reply-To: <70f247c0-6f3e-472a-b7b0-b02814010e30@default> References: <3969befd-57cd-48ee-bed5-173a28e7bd08@default> <56DFFC9F.4020403@oracle.com> <70f247c0-6f3e-472a-b7b0-b02814010e30@default> Message-ID: <56E16D0A.3060807@oracle.com> Hi, Ajit. What about other cases in Raster.java, where the DataBuffer is passed as a parameter? Probably we can simplify the code and find all such issues if we changes the ByteInterleavedRaster/etc. For example: ByteInterleavedRaster(SampleModel sampleModel,DataBuffer dataBuffer,...) to ByteInterleavedRaster(SampleModel sampleModel,DataBufferByte dataBuffer,...) Because we throw an exception in such cases anyway: if (!(dataBuffer instanceof DataBufferByte)) { throw new RasterFormatException("ByteInterleavedRasters must have " + "byte DataBuffers"); } And the compiler will help us, what everybody think about it? On 09.03.16 17:38, Ajit Ghaisas wrote: > Hi, > > Modified the test and added check for MultiPixelPackedSampleModel condition. > > Please review updated webrev : > http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.01/ > > Regards, > Ajit > > -----Original Message----- > From: Sergey Bylokhov > Sent: Wednesday, March 09, 2016 4:06 PM > To: Ajit Ghaisas; awt-dev at openjdk.java.net; Semyon Sadetsky; Ambarish Rapte; 2d-dev > Subject: Re: [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception > > Changes for 2d area.(cc) > > > On 07.03.16 11:20, Ajit Ghaisas wrote: >> Hi, >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-6353518 >> >> Issue : (Text from bug description) >> >> An attempt to create a WritableRaster via >> Raster.createWritableRaster(SampleModel sm, DataBuffer db, Point >> location) using a custom DataBuffer causes an erroneous >> RasterFormatException. >> Apparently the reason for this bug is that IntegerComponentRaster >> insists on being passed an instance of DataBufferInt rather than just >> a DataBuffer with a DataType of TYPE_INT. >> This is quite annoying since DataBufferInt is declared final and thus >> cannot be extended. >> >> Fix : >> >> The last line of Raster.createWritableRaster() method already has a >> way to handle generic case if the input does not match any of the >> cases in switch statements in that method. >> >> The fact that " *InterleavedRaster() constructors throw exception if >> DataBuffer passed to them does not match the expected type" was >> ignored earlier. >> >> This fix adds a check of "DataBuffer type" before creating respective >> *InterleavedRaster() objects. >> >> It constructs the SunWritableRaster in case DataBuffer type does not >> match any data specific DataBuffer classes (DataBufferByte, >> DataBufferUShort, DataBufferInt) >> >> Request to review webrev containing this fix : >> >> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.00/ >> >> Regards, >> >> Ajit >> > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From bourges.laurent at gmail.com Thu Mar 10 15:09:50 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 10 Mar 2016 16:09:50 +0100 Subject: [OpenJDK 2D-Dev] RFR 8144938: Handle properly coordinate overflow in Marlin Renderer Message-ID: Hi, Please review this bug fix for the Marlin renderer to properly ignore point coordinates with NaN/Infinity values: bug: https://bugs.openjdk.java.net/browse/JDK-8144938 webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144938.0/ Changes: - MarlinRenderingEngine.pathToLoop(): added bound checks for point coordinates by porting DuctusRenderingEngine#feedConsumer() - CrashNaNTest: check output image to detect incorrect rendering - minor: unused import in AAShapePipe + Version incremented Regards, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Thu Mar 10 21:07:39 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 10 Mar 2016 13:07:39 -0800 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : drawImage misses background's alpha channel In-Reply-To: <56E116A6.8060507@oracle.com> References: <05dd240c-0f46-486e-b9d9-be51984415d3@default> <56D77BD7.2020302@oracle.com> <56D8CDF8.5020404@oracle.com> <993df6ff-6bd6-43a1-b0c7-33dcedb27b24@default> <56DE1D22.3000205@oracle.com> <56DF49C0.4070200@oracle.com> <56E0B229.4000602@oracle.com> <56E0B878.6090502@oracle.com> <8467c9c3-cdd1-42b7-87ab-4c646e5875db@default> <56E116A6.8060507@oracle.com> Message-ID: <56E1E21B.2070506@oracle.com> Yes, that is the only issue I see now as well... ...jim On 3/9/16 10:39 PM, prasanta sadhukhan wrote: > Looks good to me. Only thing that can be improved is instead of wildcard > imports, you can have specific imports in testcase. > > Regards > Prasanta > On 3/10/2016 11:53 AM, Jayathirth D V wrote: >> Jim thanks for the review. >> >> Prasanta I have updated the webrev to address indentation issues. >> Please review: >> http://cr.openjdk.java.net/~jdv/8139183/webrev.06/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Thursday, March 10, 2016 5:28 AM >> To: Jayathirth D V >> Cc: 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : >> drawImage misses background's alpha channel >> >> Also, line 59, "if{" => "if {"... >> >> ...jim >> >> On 3/9/16 3:30 PM, Jim Graham wrote: >>> That looks good to go. >>> >>> A couple of code indentation issues in the test case: >>> >>> Per: >>> http://www.oracle.com/technetwork/java/javase/documentation/codeconven >>> tions-142311.html#454 >>> >>> >>> for statements should have a space as in "for (...)" otherwise it >>> looks like a call to a function named "for()". >>> >>> do-while statements also need a space before/after the braces and >>> between while and the parentheses, as in: >>> do { >>> } while (...); >>> >>> I don't need to review those code style issues, but please fix them >>> before you push it... >>> >>> ...jim >>> >>> On 3/8/16 10:44 PM, Jayathirth D V wrote: >>>> Hi Jim, >>>> >>>> I have made changes mentioned by you. >>>> >>>> Please find updated webrev: >>>> http://cr.openjdk.java.net/~jdv/8139183/webrev.05/ >>>> >>>> Thanks, >>>> Jay >>>> >>>> -----Original Message----- >>>> From: Jim Graham >>>> Sent: Wednesday, March 09, 2016 3:23 AM >>>> To: Jayathirth D V >>>> Cc: 2d-dev at openjdk.java.net >>>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : >>>> drawImage misses background's alpha channel >>>> >>>> Hi Jay, >>>> >>>> On 3/8/16 12:56 AM, Jayathirth D V wrote: >>>>> Hi Jim, >>>>> >>>>> Thanks for the review. I have made changes in test case based on >>>>> input provided. >>>>> 1) Added contentsLost() after we drawImage() and getSnapshot() to >>>>> verify the content and if it is lost loop again. >>>> Unfortunately, if contents are lost you need to loop back to where >>>> you create the image, which means you don't have enough code inside >>>> the while loop. All of the items I mentioned below in my comment >>>> need to be included in that "loop back around". To be painfully >>>> clear here, the loop should look like this: >>>> >>>> backgroundColor = ...; /* no need to create this inside the >>>> loop */ >>>> do { >>>> img = ...; >>>> Graphics2D imgGraphics = img.createGraphics(); >>>> // fill img with transparency >>>> imgGraphics.drawImage(..., bgColor); >>>> img.getSnapShot(); >>>> imgGraphics.dispose(); >>>> } while (img.contentsLost()); >>>> >>>> The rest looked fine... >>>> >>>> ...jim >>>> > From james.graham at oracle.com Thu Mar 10 21:09:57 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 10 Mar 2016 13:09:57 -0800 Subject: [OpenJDK 2D-Dev] [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception In-Reply-To: <56E16D0A.3060807@oracle.com> References: <3969befd-57cd-48ee-bed5-173a28e7bd08@default> <56DFFC9F.4020403@oracle.com> <70f247c0-6f3e-472a-b7b0-b02814010e30@default> <56E16D0A.3060807@oracle.com> Message-ID: <56E1E2A5.1020008@oracle.com> Yes, those constructors should be type-safe. Perhaps that was done to save code in the caller, but that is a small price to pay to avoid errors in the future, and it makes sure there is a backup plan for different kinds of buffers... ...jim On 3/10/16 4:48 AM, Sergey Bylokhov wrote: > Hi, Ajit. > What about other cases in Raster.java, where the DataBuffer is passed as > a parameter? Probably we can simplify the code and find all such issues > if we changes the ByteInterleavedRaster/etc. For example: > > ByteInterleavedRaster(SampleModel sampleModel,DataBuffer dataBuffer,...) > to > > ByteInterleavedRaster(SampleModel sampleModel,DataBufferByte > dataBuffer,...) > > Because we throw an exception in such cases anyway: > > if (!(dataBuffer instanceof DataBufferByte)) { > throw new RasterFormatException("ByteInterleavedRasters must have " > + "byte DataBuffers"); > } > > And the compiler will help us, what everybody think about it? > > On 09.03.16 17:38, Ajit Ghaisas wrote: >> Hi, >> >> Modified the test and added check for MultiPixelPackedSampleModel >> condition. >> >> Please review updated webrev : >> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.01/ >> >> Regards, >> Ajit >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Wednesday, March 09, 2016 4:06 PM >> To: Ajit Ghaisas; awt-dev at openjdk.java.net; Semyon Sadetsky; Ambarish >> Rapte; 2d-dev >> Subject: Re: [9] Review-request for 6353518: Creation of a >> WritableRaster with a custom DataBuffer causes erroneous Exception >> >> Changes for 2d area.(cc) >> >> >> On 07.03.16 11:20, Ajit Ghaisas wrote: >>> Hi, >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-6353518 >>> >>> Issue : (Text from bug description) >>> >>> An attempt to create a WritableRaster via >>> Raster.createWritableRaster(SampleModel sm, DataBuffer db, Point >>> location) using a custom DataBuffer causes an erroneous >>> RasterFormatException. >>> Apparently the reason for this bug is that IntegerComponentRaster >>> insists on being passed an instance of DataBufferInt rather than just >>> a DataBuffer with a DataType of TYPE_INT. >>> This is quite annoying since DataBufferInt is declared final and thus >>> cannot be extended. >>> >>> Fix : >>> >>> The last line of Raster.createWritableRaster() method already has a >>> way to handle generic case if the input does not match any of the >>> cases in switch statements in that method. >>> >>> The fact that " *InterleavedRaster() constructors throw exception if >>> DataBuffer passed to them does not match the expected type" was >>> ignored earlier. >>> >>> This fix adds a check of "DataBuffer type" before creating respective >>> *InterleavedRaster() objects. >>> >>> It constructs the SunWritableRaster in case DataBuffer type does not >>> match any data specific DataBuffer classes (DataBufferByte, >>> DataBufferUShort, DataBufferInt) >>> >>> Request to review webrev containing this fix : >>> >>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.00/ >>> >>> Regards, >>> >>> Ajit >>> >> >> >> -- >> Best regards, Sergey. >> > > From philip.race at oracle.com Thu Mar 10 22:53:48 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 10 Mar 2016 14:53:48 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8055463: Needs public API allowing full access to font collections in Font.createFont() Message-ID: <56E1FAFC.6040609@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8055463 http://cr.openjdk.java.net/~prr/8055463/ Proposal is to add two new methods in the Font class paralleling the existing ones that return only a single font. Font[] createFont(File) Font[] createFont(InputStream) I tried to make the single & multiple code be shared as much as possible to avoid duplication and I eliminated code in the OSX sub-class which seemed to be a pointless copy of the superclass. The test checks the various assertions I intend by probing for platform fonts. -phil. From philip.race at oracle.com Thu Mar 10 23:02:52 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 10 Mar 2016 15:02:52 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8055463: Needs public API allowing full access to font collections in Font.createFont() In-Reply-To: <56E1FAFC.6040609@oracle.com> References: <56E1FAFC.6040609@oracle.com> Message-ID: <56E1FD1C.5060008@oracle.com> PS there are a couple of other test files updated here BigFont is one of the tests I ran whilst checking I didn't create regressions and it failed because it assumes a SecurityManager. I could not find an open bug on that.* *GetLCIDFromLocale happened to be the one I chose to paste in the GPL and then I noticed it incorrectly had the classpath exception so I am fixing that here too. -phil. On 03/10/2016 02:53 PM, Phil Race wrote: > https://bugs.openjdk.java.net/browse/JDK-8055463 > http://cr.openjdk.java.net/~prr/8055463/ > > Proposal is to add two new methods in the Font class paralleling the > existing ones > that return only a single font. > > Font[] createFont(File) > Font[] createFont(InputStream) > > I tried to make the single & multiple code be shared as much as possible > to avoid duplication and I eliminated code in the OSX sub-class which > seemed to be a pointless copy of the superclass. > > The test checks the various assertions I intend by probing for > platform fonts. > > -phil. -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Fri Mar 11 00:47:26 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 10 Mar 2016 16:47:26 -0800 Subject: [OpenJDK 2D-Dev] RFR 8144938: Handle properly coordinate overflow in Marlin Renderer In-Reply-To: References: Message-ID: <56E2159E.8000209@oracle.com> I can confirm that this is the same solution provided for the Ductus code so it will bring us to par with the former rasterizer. I would also check what happens when you try to render and createStrokedPath() for a path that is so full of NaN values that it never gets any segments out, and/or if it only manages a moveto - just make sure that we render nothing rather than get an exception because something in the code isn't set up for that. I'm guessing that this may already be covered by a test case that ensures that we don't blow up with g2d.fill/draw(new Path2D.Double()); but it couldn't hurt to add a quick test. Finally, I'll mention that I was never very comfortable with the way that code was written in the Ductus pipeline. It does the trick and I don't see it passing through any NaN or infinite values, but it just seems like it might be overly complicated and it's hard to make sure that it is doing something "sensible" in the face of a partially constructed secondary sub-path (i.e. pathClosed handling). For one thing, I'm >80% sure that skip and subpathStarted could be folded into the same boolean, and/or that our output in the case where skip/subpathStarted disagree is what we want it to be, but this is all beyond the scope of this fix. I'd say add another test for completely bogus path(s) and it's good to go, but at least keep it in the back of your mind that this code might not represent the best solution to the problem... ...jim On 3/10/16 7:09 AM, Laurent Bourg?s wrote: > Hi, > > Please review this bug fix for the Marlin renderer to properly ignore > point coordinates with NaN/Infinity values: > bug: https://bugs.openjdk.java.net/browse/JDK-8144938 > webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144938.0/ > > Changes: > - MarlinRenderingEngine.pathToLoop(): added bound checks for point > coordinates by portingDuctusRenderingEngine#feedConsumer() > - CrashNaNTest: check output image to detect incorrect rendering > - minor: unused import in AAShapePipe + Version incremented > > Regards, > Laurent From james.graham at oracle.com Fri Mar 11 02:02:28 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 10 Mar 2016 18:02:28 -0800 Subject: [OpenJDK 2D-Dev] RFR 8144938: Handle properly coordinate overflow in Marlin Renderer In-Reply-To: <56E2159E.8000209@oracle.com> References: <56E2159E.8000209@oracle.com> Message-ID: <56E22734.7020707@oracle.com> Actually, there is one functional difference between this implementation and the Ductus pipeline... The similar method in the Ductus pipeline is operating entirely on device space coordinates after all transformation (which is why it can have normalization built-in). The method you modified is sometimes called on transformed device space coordinates, but in the case of a draw operation it can be called on user space coordinates if the transform is non-uniform. Since this change will solve the issue for fills and uniform-scaled draws(), it handles the 90% case, but if you use a non-uniform scale of more than 2x, then it will still allow overflow in the final rendered path if a coordinate is near UPPER_BND... ...jim On 3/10/16 4:47 PM, Jim Graham wrote: > I can confirm that this is the same solution provided for the Ductus > code so it will bring us to par with the former rasterizer. > > I would also check what happens when you try to render and > createStrokedPath() for a path that is so full of NaN values that it > never gets any segments out, and/or if it only manages a moveto - just > make sure that we render nothing rather than get an exception because > something in the code isn't set up for that. I'm guessing that this may > already be covered by a test case that ensures that we don't blow up > with g2d.fill/draw(new Path2D.Double()); but it couldn't hurt to add a > quick test. > > Finally, I'll mention that I was never very comfortable with the way > that code was written in the Ductus pipeline. It does the trick and I > don't see it passing through any NaN or infinite values, but it just > seems like it might be overly complicated and it's hard to make sure > that it is doing something "sensible" in the face of a partially > constructed secondary sub-path (i.e. pathClosed handling). For one > thing, I'm >80% sure that skip and subpathStarted could be folded into > the same boolean, and/or that our output in the case where > skip/subpathStarted disagree is what we want it to be, but this is all > beyond the scope of this fix. > > I'd say add another test for completely bogus path(s) and it's good to > go, but at least keep it in the back of your mind that this code might > not represent the best solution to the problem... > > ...jim > > On 3/10/16 7:09 AM, Laurent Bourg?s wrote: >> Hi, >> >> Please review this bug fix for the Marlin renderer to properly ignore >> point coordinates with NaN/Infinity values: >> bug: https://bugs.openjdk.java.net/browse/JDK-8144938 >> webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144938.0/ >> >> Changes: >> - MarlinRenderingEngine.pathToLoop(): added bound checks for point >> coordinates by portingDuctusRenderingEngine#feedConsumer() >> - CrashNaNTest: check output image to detect incorrect rendering >> - minor: unused import in AAShapePipe + Version incremented >> >> Regards, >> Laurent From jayathirth.d.v at oracle.com Fri Mar 11 06:19:56 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 10 Mar 2016 22:19:56 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : drawImage misses background's alpha channel In-Reply-To: <56E1E21B.2070506@oracle.com> References: <05dd240c-0f46-486e-b9d9-be51984415d3@default> <56D77BD7.2020302@oracle.com> <56D8CDF8.5020404@oracle.com> <993df6ff-6bd6-43a1-b0c7-33dcedb27b24@default> <56DE1D22.3000205@oracle.com> <56DF49C0.4070200@oracle.com> <56E0B229.4000602@oracle.com> <56E0B878.6090502@oracle.com> <8467c9c3-cdd1-42b7-87ab-4c646e5875db@default> <56E116A6.8060507@oracle.com> <56E1E21B.2070506@oracle.com> Message-ID: <934ffba7-872d-4db3-82bb-8df14d0e871e@default> Hi Jim, I have replaced wildcard imports with specific import and shared webrev to Prasanta before pushing. Please find the webrev that is pushed for reference. http://cr.openjdk.java.net/~jdv/8139183/webrev.07/ Thanks, Jay -----Original Message----- From: Jim Graham Sent: Friday, March 11, 2016 2:38 AM To: prasanta sadhukhan; Jayathirth D V Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : drawImage misses background's alpha channel Yes, that is the only issue I see now as well... ...jim On 3/9/16 10:39 PM, prasanta sadhukhan wrote: > Looks good to me. Only thing that can be improved is instead of > wildcard imports, you can have specific imports in testcase. > > Regards > Prasanta > On 3/10/2016 11:53 AM, Jayathirth D V wrote: >> Jim thanks for the review. >> >> Prasanta I have updated the webrev to address indentation issues. >> Please review: >> http://cr.openjdk.java.net/~jdv/8139183/webrev.06/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Thursday, March 10, 2016 5:28 AM >> To: Jayathirth D V >> Cc: 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : >> drawImage misses background's alpha channel >> >> Also, line 59, "if{" => "if {"... >> >> ...jim >> >> On 3/9/16 3:30 PM, Jim Graham wrote: >>> That looks good to go. >>> >>> A couple of code indentation issues in the test case: >>> >>> Per: >>> http://www.oracle.com/technetwork/java/javase/documentation/codeconv >>> en >>> tions-142311.html#454 >>> >>> >>> for statements should have a space as in "for (...)" otherwise it >>> looks like a call to a function named "for()". >>> >>> do-while statements also need a space before/after the braces and >>> between while and the parentheses, as in: >>> do { >>> } while (...); >>> >>> I don't need to review those code style issues, but please fix them >>> before you push it... >>> >>> ...jim >>> >>> On 3/8/16 10:44 PM, Jayathirth D V wrote: >>>> Hi Jim, >>>> >>>> I have made changes mentioned by you. >>>> >>>> Please find updated webrev: >>>> http://cr.openjdk.java.net/~jdv/8139183/webrev.05/ >>>> >>>> Thanks, >>>> Jay >>>> >>>> -----Original Message----- >>>> From: Jim Graham >>>> Sent: Wednesday, March 09, 2016 3:23 AM >>>> To: Jayathirth D V >>>> Cc: 2d-dev at openjdk.java.net >>>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : >>>> drawImage misses background's alpha channel >>>> >>>> Hi Jay, >>>> >>>> On 3/8/16 12:56 AM, Jayathirth D V wrote: >>>>> Hi Jim, >>>>> >>>>> Thanks for the review. I have made changes in test case based on >>>>> input provided. >>>>> 1) Added contentsLost() after we drawImage() and getSnapshot() to >>>>> verify the content and if it is lost loop again. >>>> Unfortunately, if contents are lost you need to loop back to where >>>> you create the image, which means you don't have enough code inside >>>> the while loop. All of the items I mentioned below in my comment >>>> need to be included in that "loop back around". To be painfully >>>> clear here, the loop should look like this: >>>> >>>> backgroundColor = ...; /* no need to create this inside the >>>> loop */ >>>> do { >>>> img = ...; >>>> Graphics2D imgGraphics = img.createGraphics(); >>>> // fill img with transparency >>>> imgGraphics.drawImage(..., bgColor); >>>> img.getSnapShot(); >>>> imgGraphics.dispose(); >>>> } while (img.contentsLost()); >>>> >>>> The rest looked fine... >>>> >>>> ...jim >>>> > From prasanta.sadhukhan at oracle.com Fri Mar 11 11:34:55 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Fri, 11 Mar 2016 17:04:55 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8151621, , [TEST_BUG] java/awt/print/PrinterJob/MultiMonPrintDlgTest.java doesn't work with jtreg Message-ID: <56E2AD5F.8050507@oracle.com> Hi Yuri, All, Bug: https://bugs.openjdk.java.net/browse/JDK-8151621 webrev: http://cr.openjdk.java.net/~psadhukhan/8151621/webrev.00/ It seems when the testcase is executed through jtreg, the main thread finishes without waiting for any user action. Added a sleep time and modified the testcase to wait for user interaction to finish which will then notify the main thread of completion . Regards Prasanta From yuri.nesterenko at oracle.com Fri Mar 11 11:56:09 2016 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Fri, 11 Mar 2016 14:56:09 +0300 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8151621, , [TEST_BUG] java/awt/print/PrinterJob/MultiMonPrintDlgTest.java doesn't work with jtreg In-Reply-To: <56E2AD5F.8050507@oracle.com> References: <56E2AD5F.8050507@oracle.com> Message-ID: <56E2B259.9000402@oracle.com> Looks fine, and works well. -yan On 03/11/2016 02:34 PM, prasanta sadhukhan wrote: > Hi Yuri, All, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8151621 > webrev: http://cr.openjdk.java.net/~psadhukhan/8151621/webrev.00/ > > It seems when the testcase is executed through jtreg, the main thread > finishes without waiting for any user action. > Added a sleep time and modified the testcase to wait for user > interaction to finish which will then notify the main thread of > completion . > > Regards > Prasanta > From prasanta.sadhukhan at oracle.com Fri Mar 11 12:06:13 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Fri, 11 Mar 2016 17:36:13 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8151590, , "ALL" radio button is not selected in printDialog when we call DefaultSelectionType.ALL in windows In-Reply-To: <56E14DC0.6020505@oracle.com> References: <56E14DC0.6020505@oracle.com> Message-ID: <56E2B4B5.9010607@oracle.com> Please find modified webrev with updated testcase. http://cr.openjdk.java.net/~psadhukhan/8151590/webrev.01/ Regards Prasanta On 3/10/2016 4:04 PM, prasanta sadhukhan wrote: > Hi Phil, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8151590 > webrev: http://cr.openjdk.java.net/~psadhukhan/8151590/webrev.00/ > > The issue is if application calls > JobAttributes.setDefaultSelection(JobAttributes.DefaultSelectionType.ALL); > > along with > JobAttributes.setFromPage(2); > JobAttributes.setToPage(5); > > then "Page" radio button is selected in windows. In linux and mac, > "All" radio button is selected. > Although the spec is not very clear as to what should get preference, > it seems logically DefaultSelection should hold preference. > > This is a regression from 8061267 where PD_PAGENUMS was added to the > flags resulting in "Page" radio button getting selected. > I added a fix to add PD_PAGENUMS to the flags only if the selection > attribute is not "PD_ALLPAGES" [which gets selected when > JobAttributes.setDefaultSelection(JobAttributes.DefaultSelectionType.ALL); > is called] > > I tested 8061267 testcase behaviour is same with this fix. > > Regards > Prasanta From alexandr.scherbatiy at oracle.com Fri Mar 11 13:42:39 2016 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 11 Mar 2016 17:42:39 +0400 Subject: [OpenJDK 2D-Dev] [9] Review request for 8151303 [macosx] [hidpi] JButton's low-res. icon is visible when clicking on it In-Reply-To: <56E01DE7.9040103@oracle.com> References: <56E01777.1030202@oracle.com> <56E01DE7.9040103@oracle.com> Message-ID: <56E2CB4F.6040301@oracle.com> On 09/03/16 16:58, Sergey Bylokhov wrote: > Probably we should enhance ImageProducer/Tk.createImage/ImageFilter to > support this functionality? It seems that the number of usage of this > check "image instanceof MultiResolutionImage" will grow over time. ImageProducer produces pixels for an image and is not able to take an information about the image resolution variants. May be we can add Toolkit.createImage(Image image, ImageFilter imageFilter) method which takes MultiResolutionImage into account to cover the common case where filtered image is created. Thanks, Alexandr. > I think that at least our own API should support MultiResolutionImage > w/o such checks, otherwise the user will need to do the same. > > cc 2d-dev > > On 09.03.16 15:30, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8151303 >> webrev: http://cr.openjdk.java.net/~alexsch/8151303/webrev.00 >> >> The AquaUtils does not take into account MultiResolutionImage for >> selected/disabled/lightened images generation. >> The fix also leaves the MultiResolutionCachedImage check because the >> base system icon size can be differ from the requested painted size. >> >> Thanks, >> Alexandr. > > From alexandr.scherbatiy at oracle.com Fri Mar 11 14:27:07 2016 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 11 Mar 2016 18:27:07 +0400 Subject: [OpenJDK 2D-Dev] thoughts on multiresolution images In-Reply-To: References: Message-ID: <56E2D5BB.4050209@oracle.com> Hello Alan, Thank you for the feedback. On 04/03/16 19:59, Alan Snyder wrote: > I am writing to share some thoughts based on recent experience using multiresolution images. My experience was not entirely pleasant. I am using JDK 8, although I see no relevant differences in JDK 9. > > One of the critical issues using multiresolution images is that the selection of a specific image is not made until the application attempts to draw the image. If the returned image is fully available at that time, then it is drawn with no problem. Otherwise, the image observer is called. Typically, this will call repaint() on a component. > > There are two potential problems: > > (1) If the component drawing the image is actually a cell renderer, then probably repaint() does nothing. The drawing will be incomplete and may not be fixed. Does the same problem exist if ordinary non multi-resolution image is used? Could you provide a code sample which illustrate the issue? > > (2) Otherwise, if the resolution variant was created on the fly and not cached, then when the repainting occurs, a new resolution variant image will be created. Most likely, it will not be fully available, either, so the result is a possibly endless repaint loop. > > I don't know of a solution to problem (1). It is not a new problem. However, what is new is that the common workaround of creating an ImageIcon may not work in this case, because only certain platform created multiresolution images are recognized by ImageIcon/MediaTracker/SunToolkit. In the general case, the component does not know which resolution variant is actually needed and thus is unable to wait for its full availability. The approach of waiting for all variants to be available is suboptimal and limiting (see below). > > Problem (2) can be solved by caching. Given the importance of caching when arbitrary images might be in use, it is surprising that there is no public support for caching. The MultiResolutionCachedImage class is JDK internal, as is the supporting ImageCache class. > > Another problem with multiresolution images is that anything that uses the getSource() method to obtain an ImageProducer will probably not do the right thing. An important example is using FilteredImageSource and an ImageFilter to create a derived image. There is no specific specification of what getSource() should return when invoked on a multiresolution image, but whatever it returns is a single-resolution image and therefore will not be the proper image in some circumstances. The ImageProducer does not contain information about Image resolution variants. Where is a discussion about it: http://mail.openjdk.java.net/pipermail/2d-dev/2016-March/006448.html > > Perhaps getSource() on a multiresolution image should thrown an exception. It could break existing applications which starts to use multi-resolution images and calls getSource() on it. In the current case these images are silently handled as ordinary images. > > There seems to be an assumption that a multiresolution image should contain a "base image" at 1x. I do not see any basis for making that assumption. It seems reasonable to me to create a multiresolution image with a single, higher resolution image. The effective result is a dynamically scaled image, where the scaling factor is determined at the last possible moment, so that no resolution is lost unnecessarily. I also observe that in the future, 1x representations will be less and less useful. The base image is used to get size/properties/source/... from the main image. It is possible to override them without the base image usage. The base image width and height are really necessary for the resolution variant size calculation. SunGraphics2D calls mrImage.getResolutionVariant(scale * baseImageWidth, scale * baseImageHeight) to obtain the high-resolution image. MultiResolutionCachedImage takes base image width and height as a parameter to avoid triggering base image creation. > > I also question the rationale for the getResolutionVariants() method. This method assumes that a MultiResolutionImage contains a fixed number of variants. I do not see any reason to make that restriction. The resolution variants might be created from a scalable description, such as vector graphics. Even if the number of variants is fixed, if the image is served remotely, it might be very expensive to obtain them all. A lazy approach to creating derived multiresolution images is better. This is mostly used for native image construction when it is passed to the native system. For example to set a high-resolution cursor it is only necessary to call Toolkit.getDefaultToolkit().createCustomCursor(mrImage, ...). Then the NSImage with given low and high resolution representation are created on Mac OS X. > > To work around some of these problems, I created my own API that includes a method similar to the map() method of MultiResolutionCachedImage. It seems to me that a method like this is needed, not just in MultiResolutionImage, but in Image itself, so that applications can write code that works on Images in general, including the MultiResolutionImage variety. > > Previously [1], the following code was suggested as a way to create a filtered MultiResolutionImage: > > static Image applyFilter(Image image) { > // apply a filter to create ligtened image > } > > static class LigtenedMultiresolutionImage extends AbstractMultiResolutionImage { > > private final Image baseImage; > > public LigtenedMultiresolutionImage(Image baseImage) { > this.baseImage = baseImage; > } > > @Override > public Image getResolutionVariant(float destImageWidth, float destImageHeight) { > Image rvImage = ((MultiResolutionImage) baseImage). > getResolutionVariant(destImageWidth, destImageHeight); > return applyFilter(rvImage); > } > > @Override > public List getResolutionVariants() { > List resolutionvariants = new LinkedList<>(); > for (Image image : ((MultiResolutionImage) baseImage). > getResolutionVariants()) { > resolutionvariants.add(applyFilter(image)); > } > return resolutionvariants; > } > > @Override > protected Image getBaseImage() { > return applyFilter(baseImage); > } > } > > I note that the lack of caching means that this code will be reliable only if applyFilter() returns a fully available image. > > My observation is one needs to know a lot more than one might expect to succeed at using multiresolution images. Will the public CachedMultiResolutionImage class and "Image map(Image image, Function mapper)" method help to solve most of the described problems? Could your create an enhancement on it: http://bugs.java.com ? Thanks, Alexandr. > [1] http://mail.openjdk.java.net/pipermail/2d-dev/2014-June/004638.html > From bourges.laurent at gmail.com Fri Mar 11 17:06:23 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Fri, 11 Mar 2016 18:06:23 +0100 Subject: [OpenJDK 2D-Dev] RFR 8144938: Handle properly coordinate overflow in Marlin Renderer In-Reply-To: <56E22734.7020707@oracle.com> References: <56E2159E.8000209@oracle.com> <56E22734.7020707@oracle.com> Message-ID: Jim, Thanks for your comments. I agree the filtering algorithm is not very obvious with too many flags (skip, pathClosed, subpathStarted) that represent lots of conditionnal statements and possibly corner cases. If I have time, I may try simplify it but in a second step. I will a new tests for createStrokedShape () and also draw(shape) with non-uniform transformation. Le 11 mars 2016 03:02, "Jim Graham" a ?crit : > > Actually, there is one functional difference between this implementation and the Ductus pipeline... > > The similar method in the Ductus pipeline is operating entirely on device space coordinates after all transformation (which is why it can have normalization built-in). > > The method you modified is sometimes called on transformed device space coordinates, but in the case of a draw operation it can be called on user space coordinates if the transform is non-uniform. Good catch. > Since this change will solve the issue for fills and uniform-scaled draws(), it handles the 90% case, but if you use a non-uniform scale of more than 2x, then it will still allow overflow in the final rendered path if a coordinate is near UPPER_BND... I wonder if such case is not only theorethical, as a typical canvas is integer based ie MAX_INTEGER << MAX_FLOAT. By the way I started refactoring MRE.strokeTo () to get rid of outat ie I propose to remove the optimisation for non-uniform at as I prefer filtering transformed coordinates once even if it requires invDelta / Delta transform stages in the pipeline. I hope it will not impact too much the performance but it simplifies notably the logic and the code. Do you have an alternative solution (simple) ? Besides, we should also check early if the transformation matrix contains NaN or Infinity values avoiding the path iteration. I advocate it is an extreme case. Ps: I will send another patch during the week end. Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Fri Mar 11 18:54:11 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Fri, 11 Mar 2016 10:54:11 -0800 Subject: [OpenJDK 2D-Dev] [9] Review request for 8076545 Text size is twice bigger under Windows L&F on Win 8.1 with HiDPI display In-Reply-To: <56C225D4.4030909@oracle.com> References: <5596C117.1040806@oracle.com> <559DB2FB.5000208@oracle.com> <55A902D4.1050603@oracle.com> <563208A9.50702@oracle.com> <56328355.1010608@oracle.com> <5633C7C8.2030804@oracle.com> <5649E312.2010606@oracle.com> <564A41D3.5010202@oracle.com> <564A4DE9.1040102@oracle.com> <56ABB269.6030808@oracle.com> <56ABD6B2.10302@oracle.com> <56AF4F4C.4030504@oracle.com> <56B00B8B.9040102@oracle.com> <56B47579.3090309@oracle.com> <56B4FA0A.3080505@oracle.com> <56B60EE4.2070501@oracle.com> <56B91F12.9070909@oracle.com> <56BE467A.8060403@oracle.com> <56C225D4.4030909@oracle.com> Message-ID: <56E31453.3010601@oracle.com> Hello, I need one more reviewer for the fix. On 2/15/2016 11:24 AM, Jim Graham wrote: > Thanks Alexandr, > > The AWT changes all look good. > > I'll leave it to others as to whether the test case represents the > best way to test this. I have no idea how those two font values in > those two L&F's in a Swing button should compare - maybe a difference > of 8 is ordinary under some circumstances? Also, the test will only > be conclusive when run on a HiDPI display larger than a certain scale > factor so it may not even be testing anything in most test environments. Should I add a manual test where it will be required to run it on HiDPI displays? Thanks, Alexandr. > > In either case, the AWT code changes look fine... > > ...jim > > On 2/12/16 12:54 PM, Alexandr Scherbatiy wrote: >> On 2/8/2016 3:04 PM, Jim Graham wrote: >>> I don't understand the issue with the fonts that you are saying have >>> different sizes for different DPIs. Those are pixel sizes, aren't >>> they? They still need to be turned into user-space units for our >>> applications to know what to do with them. Or, are you saying that >>> they are not representing pixel sizes as the rest of the font units do >>> and so they are already in DPI-relative "user space" units? >>> >>> AT 192 DPI, oemFixed.font is 18, but are they saying 18 pixels? Which >>> would be a 9-point font in our automatically scaled coordinate >>> systems, wouldn't it? >> >> The font size in the AwtDesktopProperties is calculated as (tmHeight >> - tmInternalLeading) values from TEXTMETRIC: >> jint pointSize = metrics.tmHeight - metrics.tmInternalLeading; >> According to MSDN "All sizes are specified in logical units; that is, >> they depend on the current mapping mode of the display context." >> >> The calculated size value is proportional to the scale factor for the >> fonts like win.frame.captionFont : >> DPI 96 (scale 100%), size: 15 >> DPI 144 (scale 150%), size: 23 >> DPI 192 (scale 200%), size: 30 >> >> That means that for each DPI it is possible to scale down the font >> size to its base value just using the formula: >> baseFontSize = fontSize / scaleFactor >> >> However, for win.ansiFixed.font the TEXTMETRIC returns the same values >> for each display DPI: >> DPI 96 (scale 100%), size: 13 >> DPI 144 (scale 150%), size: 13 >> DPI 192 (scale 200%), size: 13 >> >> Now scaling the size down for DPI 192 ( 13/ 2) it does not give the >> font size for the DPI 96. >> That is why the scale factor 1.0 is used in this case in the fix. >> >> Thanks, >> Alexandr. >> >>> >>> ...jim >>> >>> On 2/6/16 7:19 AM, Alexander Scherbatiy wrote: >>>> On 2/5/2016 11:37 AM, Jim Graham wrote: >>>>> Hi Alexandr, >>>>> >>>>> awt_DesktopProperties.cpp, line 300 - is the "1.0f /" a typo? >>>> Sorry. Here is the updated fix without the typo: >>>> http://cr.openjdk.java.net/~alexsch/8076545/webrev.06/ >>>>> >>>>> Also, is there a still a need for the setFontProperty() variants that >>>>> don't have a scale as the last parameter? >>>> There are fonts like win.ansiFixed.font, win.ansiVar.font, and >>>> win.deviceDefault.font which size is the same for any display DPI. >>>> >>>> And there are fonts like win.oemFixed.font, win.system.font, and >>>> win.systemFixed.font which have one size for DPI 96 and another >>>> size for >>>> all other DPI. >>>> For example win.oemFixed.font: >>>> DPI 96, size: 12 >>>> DPI 144, size: 18 >>>> DPI 192, size: 18 >>>> DPI 240, size: 18 >>>> >>>> I left them unscaled but may be it is better to have one >>>> precalculated scale for this fonts which is used when DPI is not 96. >>>> >>>> I updated the setFontProperty() method without scale parameter >>>> usage >>>> to call with scale 1.0f. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>> >>>>> ...jim >>>>> >>>>> On 2/5/2016 2:12 AM, Alexandr Scherbatiy wrote: >>>>>> >>>>>> Could you review the updated fix: >>>>>> http://cr.openjdk.java.net/~alexsch/8076545/webrev.05 >>>>>> >>>>>> - The awt_DesktopProperties.cpp file is updated to use scaleX for >>>>>> width rescaling and scaleY for height rescaling >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> On 2/1/2016 5:51 PM, Jim Graham wrote: >>>>>>> Hi Alexandr, >>>>>>> >>>>>>> In awt_DesktopProperties.cpp you are using the Y scaling factor to >>>>>>> scale widths still - see lines 287 (and others in that same >>>>>>> function) >>>>>>> and then 322 in another function. It looks like you'll need >>>>>>> getInvScaleX() and getInvScaleY(). >>>>>>> >>>>>>> I'll leave it to Phil to comment on the unit test... >>>>>>> >>>>>>> ...jim >>>>>>> >>>>>>> On 2/1/16 4:27 AM, Alexandr Scherbatiy wrote: >>>>>>>> >>>>>>>> Could you review the updated fix: >>>>>>>> http://cr.openjdk.java.net/~alexsch/8076545/webrev.04/ >>>>>>>> >>>>>>>> - both LOGPIXELSX and Y are used for the theme size scaling. >>>>>>>> - LOGPIXELSY is used for text metrics height rescaling >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>> On 1/29/2016 1:16 PM, Jim Graham wrote: >>>>>>>>> Hi Alexandr, >>>>>>>>> >>>>>>>>> Thanks for investigating the behaviors. >>>>>>>>> >>>>>>>>> With respect to using LOGPIXELSX or Y, these methods are used to >>>>>>>>> scale >>>>>>>>> both horizontal and vertical measurements so we really should >>>>>>>>> have 2 >>>>>>>>> scale values and rescale methods, one for horizontal use and one >>>>>>>>> for >>>>>>>>> vertical... >>>>>>>>> >>>>>>>>> ...jim >>>>>>>>> >>>>>>>>> On 1/29/2016 10:41 AM, Alexandr Scherbatiy wrote: >>>>>>>>>> Could you review the updated fix: >>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8076545/webrev.03 >>>>>>>>>> >>>>>>>>>> - LOGPIXELSX is changed to LOGPIXELSY >>>>>>>>>> >>>>>>>>>> On 11/16/2015 1:43 PM, Jim Graham wrote: >>>>>>>>>>> Note that LOGPIXELSY is global and static between reboots so it >>>>>>>>>>> doesn't really matter which monitor is used to get the value. >>>>>>>>>>> >>>>>>>>>>> Also, the issue is that the measurements are in pixels, so >>>>>>>>>>> if we >>>>>>>>>>> convert them into a resolution independent measurement then the >>>>>>>>>>> rest >>>>>>>>>>> of the scaling in the AWT/2D will be correct regardless of any >>>>>>>>>>> given >>>>>>>>>>> monitor's resolution. We just have to make sure the >>>>>>>>>>> "de-pixelization" >>>>>>>>>>> of the measurement is an apples-to-apples calculation. >>>>>>>>>>> >>>>>>>>>>> The question in my mind is whether the values they get from >>>>>>>>>>> GetTheme*() and SPI_GETNONCLIENTMETRICS are relative to >>>>>>>>>>> LOGPIXELSY, or >>>>>>>>>>> the more recent Per-Monitor aware DPI APIs, or ...? It would be >>>>>>>>>>> interesting to see what happens to those values when you >>>>>>>>>>> change the >>>>>>>>>>> DPI settings on Windows 8.1 and not reboot. If they stay >>>>>>>>>>> constant >>>>>>>>>>> until you reboot then LOGPIXELSY on the main screen would be >>>>>>>>>>> the >>>>>>>>>>> value >>>>>>>>>>> to use to de-scale them... >>>>>>>>>> >>>>>>>>>> I tried to use the "Change the size of all items" slider on >>>>>>>>>> Windows >>>>>>>>>> 8.1 without rebooting. >>>>>>>>>> GetDpiForMonitor() returns the updated DPI values: 192, >>>>>>>>>> 144, 96 >>>>>>>>>> LOGPIXELSY returns unchanged values: 192, 192, 192 >>>>>>>>>> SystemParametersInfo(SPI_GETNONCLIENTMETRICS,...) returns >>>>>>>>>> unchanged >>>>>>>>>> NONCLIENTMETRICS >>>>>>>>>> GetThemePartSize() returns unchanged theme part sizes >>>>>>>>>> >>>>>>>>>> It seems that theme part sizes behave in the same way as the >>>>>>>>>> LOGPIXELSY in this case. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ...jim >>>>>>>>>>> >>>>>>>>>>> On 11/16/2015 12:51 PM, Phil Race wrote: >>>>>>>>>>>> That seems better. But one more question to get a point >>>>>>>>>>>> clarified. >>>>>>>>>>>> You are using getDesktopWindow() which is for the primary >>>>>>>>>>>> monitor. >>>>>>>>>>>> I assume that the 'inversion' results in the value being used >>>>>>>>>>>> to be >>>>>>>>>>>> independent >>>>>>>>>>>> of the monitor in a multi-mon situation and so when we move to >>>>>>>>>>>> a 2nd >>>>>>>>>>>> monitor >>>>>>>>>>>> that inverted size remains valid ? >>>>>>>>>>>> >>>>>>>>>>>> If so looks good to me. >>>>>>>>>>>> >>>>>>>>>>>> -phil. >>>>>>>>>>>> >>>>>>>>>>>> On 11/16/2015 06:07 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> >>>>>>>>>>>>> Could you review the updated fix: >>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8076545/webrev.02 >>>>>>>>>>>>> >>>>>>>>>>>>> - round is used instead of ceil >>>>>>>>>>>>> - inverted scales are used >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 10/30/2015 10:40 PM, Jim Graham wrote: >>>>>>>>>>>>>> In this case round may be better. ceil() is more for cases >>>>>>>>>>>>>> where you >>>>>>>>>>>>>> needed "at least X amount of room", but I don't think a font >>>>>>>>>>>>>> size is >>>>>>>>>>>>>> an "at least this much" kind of case. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Also, I've been toying with the idea that use of ceil() and >>>>>>>>>>>>>> floor() >>>>>>>>>>>>>> in any DPI-adjustment equations should really be "ceil(val - >>>>>>>>>>>>>> epsilon)" or "floor(ceil + epsilon)" for some small value of >>>>>>>>>>>>>> epsilon >>>>>>>>>>>>>> chosen just large enough to prevent various round-off errors >>>>>>>>>>>>>> from >>>>>>>>>>>>>> affecting the outcome. One idea is for 1/256 as the >>>>>>>>>>>>>> value of >>>>>>>>>>>>>> epsilon >>>>>>>>>>>>>> since that could equate to the smallest measurable >>>>>>>>>>>>>> difference in >>>>>>>>>>>>>> terms of alpha or interpolation results (or 1/512 for "half >>>>>>>>>>>>>> the >>>>>>>>>>>>>> smallest quantum")... >>>>>>>>>>>>>> >>>>>>>>>>>>>> ...jim >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 10/29/15 1:36 PM, Phil Race wrote: >>>>>>>>>>>>>>> size->cx = (int)ceil(size->cx / scale); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So if size->cx / scale works out to be 12.0001 you will >>>>>>>>>>>>>>> round >>>>>>>>>>>>>>> it up >>>>>>>>>>>>>>> to 13? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Can you check what pixel size windows gives you in such a >>>>>>>>>>>>>>> case ? >>>>>>>>>>>>>>> I'd be a little surprised if they did that rather than >>>>>>>>>>>>>>> round. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Is the SetFontProperty that does not accept a scale >>>>>>>>>>>>>>> parameter >>>>>>>>>>>>>>> still >>>>>>>>>>>>>>> used >>>>>>>>>>>>>>> somewhere ? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -phil. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 10/29/2015 04:53 AM, Sergey Bylokhov wrote: >>>>>>>>>>>>>>>> On 17.07.15 16:27, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> - Sergey's point about multi-mon should be checked out. >>>>>>>>>>>>>>>>> Windows 8.1 has option "Let me choose one scaling >>>>>>>>>>>>>>>>> level >>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>> all my >>>>>>>>>>>>>>>>> displays". >>>>>>>>>>>>>>>>> If I unset it I am able to change the size of all >>>>>>>>>>>>>>>>> items. >>>>>>>>>>>>>>>>> However, >>>>>>>>>>>>>>>>> the DPI which returns GetDPIForMonitor is still 2 on >>>>>>>>>>>>>>>>> HiDPI >>>>>>>>>>>>>>>>> displays. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This version looks fine, but I am sure it can be double >>>>>>>>>>>>>>>> checked on >>>>>>>>>>>>>>>> windows 10 at some moment as well. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >> From james.graham at oracle.com Fri Mar 11 20:04:18 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 11 Mar 2016 12:04:18 -0800 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : drawImage misses background's alpha channel In-Reply-To: <934ffba7-872d-4db3-82bb-8df14d0e871e@default> References: <05dd240c-0f46-486e-b9d9-be51984415d3@default> <56D77BD7.2020302@oracle.com> <56D8CDF8.5020404@oracle.com> <993df6ff-6bd6-43a1-b0c7-33dcedb27b24@default> <56DE1D22.3000205@oracle.com> <56DF49C0.4070200@oracle.com> <56E0B229.4000602@oracle.com> <56E0B878.6090502@oracle.com> <8467c9c3-cdd1-42b7-87ab-4c646e5875db@default> <56E116A6.8060507@oracle.com> <56E1E21B.2070506@oracle.com> <934ffba7-872d-4db3-82bb-8df14d0e871e@default> Message-ID: <56E324C2.10409@oracle.com> Thanks! ...jim On 3/10/16 10:19 PM, Jayathirth D V wrote: > Hi Jim, > > I have replaced wildcard imports with specific import and shared webrev to Prasanta before pushing. Please find the webrev that is pushed for reference. > > http://cr.openjdk.java.net/~jdv/8139183/webrev.07/ > > Thanks, > Jay > -----Original Message----- > From: Jim Graham > Sent: Friday, March 11, 2016 2:38 AM > To: prasanta sadhukhan; Jayathirth D V > Cc: 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : drawImage misses background's alpha channel > > Yes, that is the only issue I see now as well... > > ...jim > > On 3/9/16 10:39 PM, prasanta sadhukhan wrote: >> Looks good to me. Only thing that can be improved is instead of >> wildcard imports, you can have specific imports in testcase. >> >> Regards >> Prasanta >> On 3/10/2016 11:53 AM, Jayathirth D V wrote: >>> Jim thanks for the review. >>> >>> Prasanta I have updated the webrev to address indentation issues. >>> Please review: >>> http://cr.openjdk.java.net/~jdv/8139183/webrev.06/ >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Jim Graham >>> Sent: Thursday, March 10, 2016 5:28 AM >>> To: Jayathirth D V >>> Cc: 2d-dev at openjdk.java.net >>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : >>> drawImage misses background's alpha channel >>> >>> Also, line 59, "if{" => "if {"... >>> >>> ...jim >>> >>> On 3/9/16 3:30 PM, Jim Graham wrote: >>>> That looks good to go. >>>> >>>> A couple of code indentation issues in the test case: >>>> >>>> Per: >>>> http://www.oracle.com/technetwork/java/javase/documentation/codeconv >>>> en >>>> tions-142311.html#454 >>>> >>>> >>>> for statements should have a space as in "for (...)" otherwise it >>>> looks like a call to a function named "for()". >>>> >>>> do-while statements also need a space before/after the braces and >>>> between while and the parentheses, as in: >>>> do { >>>> } while (...); >>>> >>>> I don't need to review those code style issues, but please fix them >>>> before you push it... >>>> >>>> ...jim >>>> >>>> On 3/8/16 10:44 PM, Jayathirth D V wrote: >>>>> Hi Jim, >>>>> >>>>> I have made changes mentioned by you. >>>>> >>>>> Please find updated webrev: >>>>> http://cr.openjdk.java.net/~jdv/8139183/webrev.05/ >>>>> >>>>> Thanks, >>>>> Jay >>>>> >>>>> -----Original Message----- >>>>> From: Jim Graham >>>>> Sent: Wednesday, March 09, 2016 3:23 AM >>>>> To: Jayathirth D V >>>>> Cc: 2d-dev at openjdk.java.net >>>>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8139183 : >>>>> drawImage misses background's alpha channel >>>>> >>>>> Hi Jay, >>>>> >>>>> On 3/8/16 12:56 AM, Jayathirth D V wrote: >>>>>> Hi Jim, >>>>>> >>>>>> Thanks for the review. I have made changes in test case based on >>>>>> input provided. >>>>>> 1) Added contentsLost() after we drawImage() and getSnapshot() to >>>>>> verify the content and if it is lost loop again. >>>>> Unfortunately, if contents are lost you need to loop back to where >>>>> you create the image, which means you don't have enough code inside >>>>> the while loop. All of the items I mentioned below in my comment >>>>> need to be included in that "loop back around". To be painfully >>>>> clear here, the loop should look like this: >>>>> >>>>> backgroundColor = ...; /* no need to create this inside the >>>>> loop */ >>>>> do { >>>>> img = ...; >>>>> Graphics2D imgGraphics = img.createGraphics(); >>>>> // fill img with transparency >>>>> imgGraphics.drawImage(..., bgColor); >>>>> img.getSnapShot(); >>>>> imgGraphics.dispose(); >>>>> } while (img.contentsLost()); >>>>> >>>>> The rest looked fine... >>>>> >>>>> ...jim >>>>> >> From james.graham at oracle.com Fri Mar 11 20:15:55 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 11 Mar 2016 12:15:55 -0800 Subject: [OpenJDK 2D-Dev] [9] Review request for 8151303 [macosx] [hidpi] JButton's low-res. icon is visible when clicking on it In-Reply-To: <56E2CB4F.6040301@oracle.com> References: <56E01777.1030202@oracle.com> <56E01DE7.9040103@oracle.com> <56E2CB4F.6040301@oracle.com> Message-ID: <56E3277B.3000309@oracle.com> Is this tied in with ImageFilter/FilteredImageSource? It looks like since FIS takes only a Producer, it has lost the handle to the image to get a source for a particular resolution. What happens if we introduce MultiResolution[Image]Producer? It would provide a single method that would mimic .getRV().getProducer()? I imagine this would greatly complicate the internals of ToolkitImage to support this, though... ...jim On 3/11/16 5:42 AM, Alexander Scherbatiy wrote: > On 09/03/16 16:58, Sergey Bylokhov wrote: >> Probably we should enhance ImageProducer/Tk.createImage/ImageFilter to >> support this functionality? It seems that the number of usage of this >> check "image instanceof MultiResolutionImage" will grow over time. > ImageProducer produces pixels for an image and is not able to take > an information about the image resolution variants. > > May be we can add Toolkit.createImage(Image image, ImageFilter > imageFilter) method which takes MultiResolutionImage into account to > cover the common case where filtered image is created. > > Thanks, > Alexandr. >> I think that at least our own API should support MultiResolutionImage >> w/o such checks, otherwise the user will need to do the same. >> >> cc 2d-dev >> >> On 09.03.16 15:30, Alexander Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the fix: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8151303 >>> webrev: http://cr.openjdk.java.net/~alexsch/8151303/webrev.00 >>> >>> The AquaUtils does not take into account MultiResolutionImage for >>> selected/disabled/lightened images generation. >>> The fix also leaves the MultiResolutionCachedImage check because the >>> base system icon size can be differ from the requested painted size. >>> >>> Thanks, >>> Alexandr. >> >> > From james.graham at oracle.com Fri Mar 11 20:20:04 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 11 Mar 2016 12:20:04 -0800 Subject: [OpenJDK 2D-Dev] RFR 8144938: Handle properly coordinate overflow in Marlin Renderer In-Reply-To: References: <56E2159E.8000209@oracle.com> <56E22734.7020707@oracle.com> Message-ID: <56E32874.2050606@oracle.com> Hi Laurent, On 3/11/16 9:06 AM, Laurent Bourg?s wrote: >> Since this change will solve the issue for fills and uniform-scaled draws(), it handles the 90% case, but if you use a non-uniform scale of more than 2x, then it will still allow overflow in the final rendered path if a coordinate is near UPPER_BND... > > I wonder if such case is not only theorethical, as a typical canvas is > integer based ie MAX_INTEGER << MAX_FLOAT. Then the opposite might happen. A path with coordinates > MAX_FLOAT/2 could be scaled down to be a reasonable size on the BufferedImage, but we'd have chopped out a lot of its geometry before it gets to the transform and comes back into range. Again, that would only happen in the case of a stroke with a non-uniform transform, though... ...jim From Sergey.Bylokhov at oracle.com Fri Mar 11 20:22:28 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 11 Mar 2016 23:22:28 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8055463: Needs public API allowing full access to font collections in Font.createFont() In-Reply-To: <56E1FD1C.5060008@oracle.com> References: <56E1FAFC.6040609@oracle.com> <56E1FD1C.5060008@oracle.com> Message-ID: <56E32904.4050501@oracle.com> Hi, Phil. The FileFont.java contains debug code: System.out.println("COUNT="+count); System.out.println("FILE="+fontFile); On 11.03.16 2:02, Phil Race wrote: > PS there are a couple of other test files updated here > > BigFont is one of the tests I ran whilst checking I didn't create > regressions > and it failed because it assumes a SecurityManager. I could not find an > open bug on that.* > > *GetLCIDFromLocale happened to be the one I chose to paste in > the GPL and then I noticed it incorrectly had the classpath exception > so I am fixing that here too. > > -phil. > > > On 03/10/2016 02:53 PM, Phil Race wrote: >> https://bugs.openjdk.java.net/browse/JDK-8055463 >> http://cr.openjdk.java.net/~prr/8055463/ >> >> Proposal is to add two new methods in the Font class paralleling the >> existing ones >> that return only a single font. >> >> Font[] createFont(File) >> Font[] createFont(InputStream) >> >> I tried to make the single & multiple code be shared as much as possible >> to avoid duplication and I eliminated code in the OSX sub-class which >> seemed to be a pointless copy of the superclass. >> >> The test checks the various assertions I intend by probing for >> platform fonts. >> >> -phil. > -- Best regards, Sergey. From philip.race at oracle.com Fri Mar 11 20:34:21 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 11 Mar 2016 12:34:21 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8055463: Needs public API allowing full access to font collections in Font.createFont() In-Reply-To: <56E32904.4050501@oracle.com> References: <56E1FAFC.6040609@oracle.com> <56E1FD1C.5060008@oracle.com> <56E32904.4050501@oracle.com> Message-ID: <56E32BCD.3070002@oracle.com> Oops. Fixed : http://cr.openjdk.java.net/~prr/8055463.1/ -phil. On 03/11/2016 12:22 PM, Sergey Bylokhov wrote: > Hi, Phil. > The FileFont.java contains debug code: > > System.out.println("COUNT="+count); > System.out.println("FILE="+fontFile); > > > On 11.03.16 2:02, Phil Race wrote: >> PS there are a couple of other test files updated here >> >> BigFont is one of the tests I ran whilst checking I didn't create >> regressions >> and it failed because it assumes a SecurityManager. I could not find an >> open bug on that.* >> >> *GetLCIDFromLocale happened to be the one I chose to paste in >> the GPL and then I noticed it incorrectly had the classpath exception >> so I am fixing that here too. >> >> -phil. >> >> >> On 03/10/2016 02:53 PM, Phil Race wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8055463 >>> http://cr.openjdk.java.net/~prr/8055463/ >>> >>> Proposal is to add two new methods in the Font class paralleling the >>> existing ones >>> that return only a single font. >>> >>> Font[] createFont(File) >>> Font[] createFont(InputStream) >>> >>> I tried to make the single & multiple code be shared as much as >>> possible >>> to avoid duplication and I eliminated code in the OSX sub-class which >>> seemed to be a pointless copy of the superclass. >>> >>> The test checks the various assertions I intend by probing for >>> platform fonts. >>> >>> -phil. >> > > From james.graham at oracle.com Fri Mar 11 21:02:01 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 11 Mar 2016 13:02:01 -0800 Subject: [OpenJDK 2D-Dev] RFR 8144938: Handle properly coordinate overflow in Marlin Renderer In-Reply-To: References: <56E2159E.8000209@oracle.com> <56E22734.7020707@oracle.com> Message-ID: <56E33249.2030300@oracle.com> Hi Laurent, On 3/11/16 9:06 AM, Laurent Bourg?s wrote: > By the way I started refactoring MRE.strokeTo () to get rid of outat ie > I propose to remove the optimisation for non-uniform at as I prefer > filtering transformed coordinates once even if it requires invDelta / > Delta transform stages in the pipeline. > I hope it will not impact too much the performance but it simplifies > notably the logic and the code. > Do you have an alternative solution (simple) ? Yes, if we can take a non-uniform transform and express the pen size as a tilted ellipse, then we can supply the tilted ellipse parameters to the stroker and it could perform device-space widening of non-uniform pens. Basically, we have a method right now that takes the dx,dy of a path and turns it into a unit vector, does a simplistic 90 degree transform, and then scales it by the line width. It looks something like (adapted from Stroker.computeOffset()): mdx = dy / len(dx,dy) * halfwidth; mdy = -dx / len(dx,dy) * halfwidth; which is shorthand for: (1) normalize dx,dy (2) rotate dx,dy by 90 degrees (3) multiply by half the transformed line width What we'd need to do for the general case is: (1) inverse delta transform to user space (2) normalize dx,dy to unit vector (3) rotate by 90 degrees (4) scale by (half) user space line width (5) transform back to device space (1) and (3) through (5) are all 2x2 transforms and they could be able to be flattened into a single transform, but we have that pesky normalize step at (2) that gets in the way. If not for that, we could replace the contents of computeOffset with just a 2x2 matrix multiply, but I punted when I looked at how to introduce the normalization step. I'm pretty sure that (1) and (2) could be swapped somehow because all we really have is an elliptical pen and we should be able to take a normalized vector in device space and compute a transform that rotates it to the proper orientation that comes from "inverseTx, rotate90, Tx" and applies the proper scale, but how to compute that? When done we'd just have a 2x2 matrix to multiply by, but since the construction of that 2x2 matrix wasn't immediately obvious from concatenating component matrices I punted to other problems. Another thing to consider is that dash length will vary based on angle so we'd need a way to compute "user length of device dx,dy" quickly. It's essentially computing "len(inverseTransform(dx,dy))", which is: udx = inverseMxx * dx + inverseMxy * dy; udy = inverseMyx * dx + inverseMyy * dy; return sqrt(udx * udx + udy * udy); which is (renaming inverseM* to I*), and please check my math: sqrt((Ixx * dx + Ixy * dy)^2 + (Iyx * dx + Iyy * dy)^2); sqrt(Ixx*Ixx*dx*dx + 2Ixx*Ixy*dx*dy + Ixy*Ixy*dy*dy + Iyx*Iyx*dx*dx + 2Iyx*Iyy*dx*dy + Iyy*Iyy*dy*dy); sqrt( (Ixx*Ixx + Iyx*Iyx)*dx*dx + 2(Ixx*Ixy + Iyx*Iyy)*dx*dy + (Ixy*Ixy + Iyy*Iyy)*dy*dy); sqrt(K1 * dx * dx + K2 * dx * dy + K3 * dy * dy); For a uniform scale K1 == K3 == squared inverse scale and K2 == 0 and K1,K3 can then be factored out of the sqrt into a constant and applied to the dash lengths instead. which is only a little more complicated than a regular length computation. Unfortunately, since the angle changes over the course of a curve, it might prove a little tricky for the iterator that computes the length of the dashes along the curve, but it could be as simple as calling a different length method as it iterates. > Besides, we should also check early if the transformation matrix > contains NaN or Infinity values avoiding the path iteration. I advocate > it is an extreme case. That could be a short-cut optimization, but it depends on how much it costs compared to just letting the path degeneracy elimination turn it all into a NOP segment by segment... ...jim From bourges.laurent at gmail.com Fri Mar 11 22:14:47 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Fri, 11 Mar 2016 23:14:47 +0100 Subject: [OpenJDK 2D-Dev] RFR 8144938: Handle properly coordinate overflow in Marlin Renderer In-Reply-To: <56E33249.2030300@oracle.com> References: <56E2159E.8000209@oracle.com> <56E22734.7020707@oracle.com> <56E33249.2030300@oracle.com> Message-ID: Jim, Here is a webrev illustrating my 'simple' approach: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144938.1/ Changes: - MarlinRenderingEngine.strokeTo(): removed outat ie always call src.getPathIterator(at) that ensures Marlin is working in device-space coordinates; so pathTo() can filter out NaN / Infinity points - TransformingPathConsumer2D: removed transformConsumer() and all its related inner classes (simplification) I will perform a MapBench benchmark focused on non-uniform transformation to check the possible performance 'regression'. Please give me your point of view on the NaN/Infinity overflow handling that I think it is now correct as all path coordinates are in the device-space. I think you proposed an optimized approach to refine my solution and get rid of all inverseDelta/delta transformations at all, does it ? I am not sure to have understood all the maths here (after my first 2/3 reads) but it seems quite complex and I am a bit reluctant as computing curve offsets or curved lengths seems to me very very tricky and error-prone ! I think your advices are very interesting but I need more concrete directions to try making changes myself in the Stroker / Dasher code. What is the use case for non-uniform transformations ? how important is it ? In other words, is it worth such effort ? Do you have an alternative solution (simple) ? >> > > Yes, if we can take a non-uniform transform and express the pen size as a > tilted ellipse, then we can supply the tilted ellipse parameters to the > stroker and it could perform device-space widening of non-uniform pens. > Basically, we have a method right now that takes the dx,dy of a path and > turns it into a unit vector, does a simplistic 90 degree transform, and > then scales it by the line width. It looks something like (adapted from > Stroker.computeOffset()): > > mdx = dy / len(dx,dy) * halfwidth; > mdy = -dx / len(dx,dy) * halfwidth; > > which is shorthand for: > > (1) normalize dx,dy > (2) rotate dx,dy by 90 degrees > (3) multiply by half the transformed line width > > What we'd need to do for the general case is: > > (1) inverse delta transform to user space > (2) normalize dx,dy to unit vector > (3) rotate by 90 degrees > (4) scale by (half) user space line width > (5) transform back to device space > I agree. > (1) and (3) through (5) are all 2x2 transforms and they could be able to > be flattened into a single transform, but we have that pesky normalize step > at (2) that gets in the way. If not for that, we could replace the > contents of computeOffset with just a 2x2 matrix multiply, but I punted > when I looked at how to introduce the normalization step. I'm pretty sure > that (1) and (2) could be swapped somehow because all we really have is an > elliptical pen and we should be able to take a normalized vector in device > space and compute a transform that rotates it to the proper orientation > that comes from "inverseTx, rotate90, Tx" and applies the proper scale, but > how to compute that? When done we'd just have a 2x2 matrix to multiply by, > but since the construction of that 2x2 matrix wasn't immediately obvious > from concatenating component matrices I punted to other problems. > A bit lost, but globally I understand. Probably some degenated cases may apperar (matrix inversion ?) > Another thing to consider is that dash length will vary based on angle so > we'd need a way to compute "user length of device dx,dy" quickly. It's > essentially computing "len(inverseTransform(dx,dy))", which is: > > udx = inverseMxx * dx + inverseMxy * dy; > udy = inverseMyx * dx + inverseMyy * dy; > return sqrt(udx * udx + udy * udy); > > which is (renaming inverseM* to I*), and please check my math: > > sqrt((Ixx * dx + Ixy * dy)^2 + (Iyx * dx + Iyy * dy)^2); > sqrt(Ixx*Ixx*dx*dx + 2Ixx*Ixy*dx*dy + Ixy*Ixy*dy*dy + > Iyx*Iyx*dx*dx + 2Iyx*Iyy*dx*dy + Iyy*Iyy*dy*dy); > sqrt( (Ixx*Ixx + Iyx*Iyx)*dx*dx + > 2(Ixx*Ixy + Iyx*Iyy)*dx*dy + > (Ixy*Ixy + Iyy*Iyy)*dy*dy); > sqrt(K1 * dx * dx + K2 * dx * dy + K3 * dy * dy); > Will check later (as it is late here) but it looks correct. > > For a uniform scale K1 == K3 == squared inverse scale and K2 == 0 and > K1,K3 can then be factored out of the sqrt into a constant and applied to > the dash lengths instead. > > which is only a little more complicated than a regular length > computation. Unfortunately, since the angle changes over the course of a > curve, it might prove a little tricky for the iterator that computes the > length of the dashes along the curve, but it could be as simple as calling > a different length method as it iterates. > It seems too simple to be true. I have doubts I can handle such changes myself. > Besides, we should also check early if the transformation matrix >> contains NaN or Infinity values avoiding the path iteration. I advocate >> it is an extreme case. >> > > That could be a short-cut optimization, but it depends on how much it > costs compared to just letting the path degeneracy elimination turn it all > into a NOP segment by segment... > I agree this shortcut is only worth if it happens in reality... To conclude tonight, I will run few benchmarks and am looking forward your comments. Cheers, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From bourges.laurent at gmail.com Fri Mar 11 23:10:30 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Sat, 12 Mar 2016 00:10:30 +0100 Subject: [OpenJDK 2D-Dev] RFR 8144938: Handle properly coordinate overflow in Marlin Renderer In-Reply-To: References: <56E2159E.8000209@oracle.com> <56E22734.7020707@oracle.com> <56E33249.2030300@oracle.com> Message-ID: Jim, Here are MapBench results comparing Marlin 0.7.3.2 (before) vs patched 0.7.3.3 (latest patch) on JDK 1.8_72: Synthetic results: Tests 36 12 12 12 Threads 4 1 2 4 Before = Marlin 0.7.3.2: *Med 168.535 165.403 166.940 173.263 * *Pct95 170.256 166.011 167.495 177.260 FPS 43.200 43.404 43.203 42.993 * Patched = Marlin 0.7.3.3: *Med 169.481 166.344 168.096 174.004 * *Pct95 170.295 166.800 168.751 175.335 FPS 42.194 42.340 42.211 42.031 * The difference is very minor ~ 1/2ms in global average (36 or 12 tests) ie within error margin ! Only FPS (based on median timings) seem indicating that Marlin 0.7.3.2 is 'very slightly' faster. Complete results: Before = Marlin 0.7.3.2: Test Threads Ops Med Pct95 Avg StdDev Min Max FPS(med) TotalOps [ms/op] CircleTests.ser 1 146 71.663 72.225 71.735 0.321 71.162 73.045 13.954 146 CircleTests.ser 2 292 72.652 73.153 72.683 0.284 72.001 73.818 13.764 292 CircleTests.ser 4 584 73.675 75.495 73.944 1.152 72.320 91.951 13.573 584 EllipseTests-fill-false.ser 1 35 295.363 297.853 295.594 0.764 295.097 298.280 3.386 35 EllipseTests-fill-false.ser 2 70 294.418 295.059 294.345 0.613 293.191 295.685 3.397 70 EllipseTests-fill-false.ser 4 140 295.378 303.661 298.108 14.352 293.428 422.684 3.385 140 EllipseTests-fill-true.ser 1 25 436.748 437.658 436.816 0.445 436.180 438.120 2.290 25 EllipseTests-fill-true.ser 2 50 449.424 451.158 449.191 2.426 446.658 458.887 2.225 50 EllipseTests-fill-true.ser 4 100 513.228 520.717 514.442 3.673 497.246 533.654 1.948 100 dc_boulder_2013-13-30-06-13-17.ser 1 123 82.827 83.351 82.818 0.278 82.156 83.620 12.073 123 dc_boulder_2013-13-30-06-13-17.ser 2 246 83.840 84.142 83.796 0.255 83.175 84.301 11.928 246 dc_boulder_2013-13-30-06-13-17.ser 4 492 84.501 86.983 85.032 1.522 83.268 105.370 11.834 492 dc_boulder_2013-13-30-06-13-20.ser 1 240 42.740 43.061 42.702 0.281 42.126 44.237 23.397 240 dc_boulder_2013-13-30-06-13-20.ser 2 480 43.979 44.183 44.001 0.135 43.253 45.934 22.738 480 dc_boulder_2013-13-30-06-13-20.ser 4 960 44.466 45.612 44.584 0.943 43.499 65.537 22.489 960 dc_shp_alllayers_2013-00-30-07-00-43.ser 1 264 39.132 39.390 39.070 0.258 38.541 39.631 25.554 264 dc_shp_alllayers_2013-00-30-07-00-43.ser 2 528 39.543 40.107 39.599 0.338 38.938 40.982 25.289 528 dc_shp_alllayers_2013-00-30-07-00-43.ser 4 1056 40.429 41.233 40.504 0.769 39.267 62.092 24.735 1056 dc_shp_alllayers_2013-00-30-07-00-47.ser 1 25 828.145 829.424 828.236 0.701 826.863 830.275 1.208 25 dc_shp_alllayers_2013-00-30-07-00-47.ser 2 50 829.794 831.670 829.920 1.326 827.584 833.811 1.205 50 dc_shp_alllayers_2013-00-30-07-00-47.ser 4 100 835.829 859.380 841.386 10.144 831.585 863.487 1.196 100 dc_spearfish_2013-11-30-06-11-15.ser 1 822 12.424 12.518 12.438 0.039 12.396 12.721 80.492 822 dc_spearfish_2013-11-30-06-11-15.ser 2 1644 12.472 12.621 12.499 0.059 12.429 12.860 80.177 1644 dc_spearfish_2013-11-30-06-11-15.ser 4 3288 12.499 12.888 12.602 0.407 12.416 31.385 80.004 3288 dc_spearfish_2013-11-30-06-11-19.ser 1 1647 6.368 6.431 6.374 0.023 6.353 6.548 157.047 1647 dc_spearfish_2013-11-30-06-11-19.ser 2 3294 6.370 6.435 6.375 0.025 6.350 7.025 156.982 3294 dc_spearfish_2013-11-30-06-11-19.ser 4 6588 6.379 6.443 6.392 0.235 6.353 24.259 156.755 6588 dc_topp:states_2013-11-30-06-11-06.ser 1 791 13.258 13.435 13.285 0.080 13.194 13.576 75.424 791 dc_topp:states_2013-11-30-06-11-06.ser 2 1582 13.383 13.541 13.366 0.095 13.207 13.680 74.720 1582 dc_topp:states_2013-11-30-06-11-06.ser 4 3164 13.318 13.529 13.353 0.373 13.205 31.555 75.084 3164 dc_topp:states_2013-11-30-06-11-07.ser 1 1221 8.385 8.555 8.415 0.082 8.329 9.306 119.254 1221 dc_topp:states_2013-11-30-06-11-07.ser 2 2442 8.382 8.563 8.419 0.077 8.336 8.680 119.303 2442 dc_topp:states_2013-11-30-06-11-07.ser 4 4884 8.454 8.666 8.473 0.253 8.332 19.872 118.291 4884 test_z_625k.ser 1 71 147.778 148.236 147.762 0.324 146.781 148.338 6.767 71 test_z_625k.ser 2 142 149.019 149.311 149.002 0.218 148.444 149.558 6.711 142 test_z_625k.ser 4 284 150.994 152.514 151.185 1.326 149.368 171.277 6.623 284 Scores: Tests 36 12 12 12 Threads 4 1 2 4 *Med 168.535 165.403 166.940 173.263 * *Pct95 170.256 166.011 167.495 177.260 FPS 43.200 43.404 43.203 42.993 * Patched = Marlin 0.7.3.3: Test Threads Ops Med Pct95 Avg StdDev Min Max FPS(med) TotalOps [ms/op] CircleTests.ser 1 141 74.384 74.900 74.404 0.304 73.822 75.428 13.444 141 CircleTests.ser 2 282 75.187 75.542 75.200 0.212 74.667 76.527 13.300 282 CircleTests.ser 4 564 78.456 79.359 78.047 1.544 75.002 101.072 12.746 564 EllipseTests-fill-false.ser 1 35 293.541 294.431 293.563 0.710 292.023 294.603 3.407 35 EllipseTests-fill-false.ser 2 70 294.290 296.877 294.578 1.547 291.809 297.005 3.398 70 EllipseTests-fill-false.ser 4 140 293.914 297.667 294.655 2.639 292.165 319.054 3.402 140 EllipseTests-fill-true.ser 1 25 435.423 436.001 435.500 0.372 435.051 436.990 2.297 25 EllipseTests-fill-true.ser 2 50 446.800 448.429 446.907 1.960 444.852 455.553 2.238 50 EllipseTests-fill-true.ser 4 100 510.117 512.215 510.355 2.718 507.249 533.946 1.960 100 dc_boulder_2013-13-30-06-13-17.ser 1 123 85.126 85.689 85.185 0.279 84.913 87.077 11.747 123 dc_boulder_2013-13-30-06-13-17.ser 2 246 85.914 86.276 85.944 0.150 85.715 86.638 11.640 246 dc_boulder_2013-13-30-06-13-17.ser 4 492 86.984 87.633 87.053 1.207 85.843 109.197 11.496 492 dc_boulder_2013-13-30-06-13-20.ser 1 240 43.508 44.306 43.638 0.348 43.308 46.308 22.984 240 dc_boulder_2013-13-30-06-13-20.ser 2 480 44.452 44.909 44.500 0.206 44.109 45.435 22.496 480 dc_boulder_2013-13-30-06-13-20.ser 4 960 45.897 46.231 45.823 0.849 44.521 66.349 21.788 960 dc_shp_alllayers_2013-00-30-07-00-43.ser 1 265 39.453 40.006 39.472 0.279 39.037 40.216 25.346 265 dc_shp_alllayers_2013-00-30-07-00-43.ser 2 530 40.118 40.689 40.114 0.329 39.268 41.028 24.927 530 dc_shp_alllayers_2013-00-30-07-00-43.ser 4 1060 40.700 41.181 40.735 0.744 40.026 62.110 24.570 1060 dc_shp_alllayers_2013-00-30-07-00-47.ser 1 25 832.892 833.254 832.836 0.321 832.124 833.376 1.201 25 dc_shp_alllayers_2013-00-30-07-00-47.ser 2 50 836.860 838.171 836.882 0.903 834.890 838.289 1.195 50 dc_shp_alllayers_2013-00-30-07-00-47.ser 4 100 837.405 843.556 837.978 4.264 835.075 858.780 1.194 100 dc_spearfish_2013-11-30-06-11-15.ser 1 818 12.826 12.948 12.843 0.057 12.804 13.663 77.969 818 dc_spearfish_2013-11-30-06-11-15.ser 2 1636 12.851 12.941 12.854 0.047 12.801 13.271 77.816 1636 dc_spearfish_2013-11-30-06-11-15.ser 4 3272 12.843 12.989 12.879 0.325 12.813 28.151 77.866 3272 dc_spearfish_2013-11-30-06-11-19.ser 1 1606 6.525 6.589 6.532 0.027 6.507 6.734 153.267 1606 dc_spearfish_2013-11-30-06-11-19.ser 2 3212 6.523 6.573 6.527 0.025 6.502 6.992 153.309 3212 dc_spearfish_2013-11-30-06-11-19.ser 4 6424 6.526 6.578 6.538 0.233 6.503 23.834 153.242 6424 dc_topp:states_2013-11-30-06-11-06.ser 1 781 13.488 13.596 13.469 0.084 13.335 13.678 74.141 781 dc_topp:states_2013-11-30-06-11-06.ser 2 1562 13.502 13.632 13.491 0.089 13.343 13.760 74.060 1562 dc_topp:states_2013-11-30-06-11-06.ser 4 3124 13.499 13.635 13.503 0.295 13.344 26.397 74.081 3124 dc_topp:states_2013-11-30-06-11-07.ser 1 1209 8.648 8.719 8.626 0.074 8.489 8.913 115.627 1209 dc_topp:states_2013-11-30-06-11-07.ser 2 2418 8.652 8.718 8.626 0.072 8.500 8.811 115.578 2418 dc_topp:states_2013-11-30-06-11-07.ser 4 4836 8.659 8.730 8.647 0.269 8.494 23.649 115.487 4836 test_z_625k.ser 1 69 150.311 151.154 150.448 0.408 149.847 151.557 6.653 69 test_z_625k.ser 2 138 152.004 152.252 152.013 0.114 151.744 152.410 6.579 138 test_z_625k.ser 4 276 153.049 154.245 153.266 1.418 152.792 175.424 6.534 276 Scores: Tests 36 12 12 12 Threads 4 1 2 4 *Med 169.481 166.344 168.096 174.004 * *Pct95 170.295 166.800 168.751 175.335 FPS 42.194 42.340 42.211 42.031 * Cheers, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From javalists at cbfiddle.com Fri Mar 11 23:05:30 2016 From: javalists at cbfiddle.com (Alan Snyder) Date: Fri, 11 Mar 2016 15:05:30 -0800 Subject: [OpenJDK 2D-Dev] thoughts on multiresolution images In-Reply-To: <56E2D5BB.4050209@oracle.com> References: <56E2D5BB.4050209@oracle.com> Message-ID: > On Mar 11, 2016, at 6:27 AM, Alexander Scherbatiy wrote: > > > Hello Alan, > > Thank you for the feedback. > > On 04/03/16 19:59, Alan Snyder wrote: >> I am writing to share some thoughts based on recent experience using multiresolution images. My experience was not entirely pleasant. I am using JDK 8, although I see no relevant differences in JDK 9. >> >> One of the critical issues using multiresolution images is that the selection of a specific image is not made until the application attempts to draw the image. If the returned image is fully available at that time, then it is drawn with no problem. Otherwise, the image observer is called. Typically, this will call repaint() on a component. >> >> There are two potential problems: >> >> (1) If the component drawing the image is actually a cell renderer, then probably repaint() does nothing. The drawing will be incomplete and may not be fixed. > Does the same problem exist if ordinary non multi-resolution image is used? Could you provide a code sample which illustrate the issue? In theory, the same problem can arise with an ordinary image, but in practice it would be unlikely. Most cell renderers are based on JLabel, which takes icons, not images. Creating an icon from an image using ImageIcon solves the problem for most ordinary images because the constructor waits for the image to be available. Perhaps this is why it waits! A test case could be developed using a custom asynchronous image that is not a ToolkitImage, since SunToolkit.checkImage() only understands ToolkitImages. >> >> (2) Otherwise, if the resolution variant was created on the fly and not cached, then when the repainting occurs, a new resolution variant image will be created. Most likely, it will not be fully available, either, so the result is a possibly endless repaint loop. >> >> I don't know of a solution to problem (1). It is not a new problem. However, what is new is that the common workaround of creating an ImageIcon may not work in this case, because only certain platform created multiresolution images are recognized by ImageIcon/MediaTracker/SunToolkit. In the general case, the component does not know which resolution variant is actually needed and thus is unable to wait for its full availability. The approach of waiting for all variants to be available is suboptimal and limiting (see below). >> >> Problem (2) can be solved by caching. Given the importance of caching when arbitrary images might be in use, it is surprising that there is no public support for caching. The MultiResolutionCachedImage class is JDK internal, as is the supporting ImageCache class. >> >> Another problem with multiresolution images is that anything that uses the getSource() method to obtain an ImageProducer will probably not do the right thing. An important example is using FilteredImageSource and an ImageFilter to create a derived image. There is no specific specification of what getSource() should return when invoked on a multiresolution image, but whatever it returns is a single-resolution image and therefore will not be the proper image in some circumstances. > The ImageProducer does not contain information about Image resolution variants. > Where is a discussion about it: > http://mail.openjdk.java.net/pipermail/2d-dev/2016-March/006448.html >> >> Perhaps getSource() on a multiresolution image should thrown an exception. > It could break existing applications which starts to use multi-resolution images and calls getSource() on it. In the current case these images are silently handled as ordinary images. This issue is moot if multiresolution image producers are used. In the current situation, an incorrect image may be produced - either the right size and fuzzy or the wrong size. Throwing an exception alerts the developer that his code needs to be changed. Otherwise, the problem may not be discovered until someone runs the program on an appropriate display and notices the problem. >> >> There seems to be an assumption that a multiresolution image should contain a "base image" at 1x. I do not see any basis for making that assumption. It seems reasonable to me to create a multiresolution image with a single, higher resolution image. The effective result is a dynamically scaled image, where the scaling factor is determined at the last possible moment, so that no resolution is lost unnecessarily. I also observe that in the future, 1x representations will be less and less useful. > The base image is used to get size/properties/source/... from the main image. It is possible to override them without the base image usage. > > The base image width and height are really necessary for the resolution variant size calculation. SunGraphics2D calls mrImage.getResolutionVariant(scale * baseImageWidth, scale * baseImageHeight) to obtain the high-resolution image. > > MultiResolutionCachedImage takes base image width and height as a parameter to avoid triggering base image creation. > I agree that every image needs to have a ?layout size? and that a 1x base image may be used to get the layout size and to get properties. I do not believe that the base image needs to be 1x or that there needs to be a base image at all (even if it is constructed lazily). I disagree that a base image is appropriate for getSource(), per the above discussion. SunGraphics2D does not use the base image sizes. It calls getWidth() and getHeight(). I?m being picky here because only if you make the assumption of a 1x base image does your statement make sense. I think ?layout size? is a better term for what you are calling the base image size. An image needs to have a size for layout. It does not need to have a base image. >> >> I also question the rationale for the getResolutionVariants() method. This method assumes that a MultiResolutionImage contains a fixed number of variants. I do not see any reason to make that restriction. The resolution variants might be created from a scalable description, such as vector graphics. Even if the number of variants is fixed, if the image is served remotely, it might be very expensive to obtain them all. A lazy approach to creating derived multiresolution images is better. > This is mostly used for native image construction when it is passed to the native system. > > For example to set a high-resolution cursor it is only necessary to call > Toolkit.getDefaultToolkit().createCustomCursor(mrImage, ...). > > Then the NSImage with given low and high resolution representation are created on Mac OS X. There are two options that would work for this usage without needing to enumerate image representations. The simplest option is to determine which two resolutions you need and ask for them directly using getResolutionVariant(). The other option, if you cannot determine which resolutions might be needed, is a lazy implementation. Admittedly, that would be more work. I would recommend either removing getResolutionVariants() from the MultiResolutionImage interface or making its implementation optional (e.g. return null). >> >> To work around some of these problems, I created my own API that includes a method similar to the map() method of MultiResolutionCachedImage. It seems to me that a method like this is needed, not just in MultiResolutionImage, but in Image itself, so that applications can write code that works on Images in general, including the MultiResolutionImage variety. >> >> Previously [1], the following code was suggested as a way to create a filtered MultiResolutionImage: >> >> static Image applyFilter(Image image) { >> // apply a filter to create ligtened image >> } >> >> static class LigtenedMultiresolutionImage extends AbstractMultiResolutionImage { >> >> private final Image baseImage; >> >> public LigtenedMultiresolutionImage(Image baseImage) { >> this.baseImage = baseImage; >> } >> >> @Override >> public Image getResolutionVariant(float destImageWidth, float destImageHeight) { >> Image rvImage = ((MultiResolutionImage) baseImage). >> getResolutionVariant(destImageWidth, destImageHeight); >> return applyFilter(rvImage); >> } >> >> @Override >> public List getResolutionVariants() { >> List resolutionvariants = new LinkedList<>(); >> for (Image image : ((MultiResolutionImage) baseImage). >> getResolutionVariants()) { >> resolutionvariants.add(applyFilter(image)); >> } >> return resolutionvariants; >> } >> >> @Override >> protected Image getBaseImage() { >> return applyFilter(baseImage); >> } >> } >> >> I note that the lack of caching means that this code will be reliable only if applyFilter() returns a fully available image. >> >> My observation is one needs to know a lot more than one might expect to succeed at using multiresolution images. > Will the public CachedMultiResolutionImage class and "Image map(Image image, Function mapper)" method help to solve most of the described problems? > Could your create an enhancement on it: http://bugs.java.com ? > I will consider this and submit an RFE if appropriate. > Thanks, > Alexandr. >> [1] http://mail.openjdk.java.net/pipermail/2d-dev/2014-June/004638.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Sat Mar 12 16:22:48 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sat, 12 Mar 2016 19:22:48 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8055463: Needs public API allowing full access to font collections in Font.createFont() In-Reply-To: <56E32BCD.3070002@oracle.com> References: <56E1FAFC.6040609@oracle.com> <56E1FD1C.5060008@oracle.com> <56E32904.4050501@oracle.com> <56E32BCD.3070002@oracle.com> Message-ID: <56E44258.6050000@oracle.com> Looks fine. ps: for the record - long time ago the OSX code was different: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/e910dde2c36c On 11.03.16 23:34, Phil Race wrote: > Oops. Fixed : http://cr.openjdk.java.net/~prr/8055463.1/ > > -phil. > > On 03/11/2016 12:22 PM, Sergey Bylokhov wrote: >> Hi, Phil. >> The FileFont.java contains debug code: >> >> System.out.println("COUNT="+count); >> System.out.println("FILE="+fontFile); >> >> >> On 11.03.16 2:02, Phil Race wrote: >>> PS there are a couple of other test files updated here >>> >>> BigFont is one of the tests I ran whilst checking I didn't create >>> regressions >>> and it failed because it assumes a SecurityManager. I could not find an >>> open bug on that.* >>> >>> *GetLCIDFromLocale happened to be the one I chose to paste in >>> the GPL and then I noticed it incorrectly had the classpath exception >>> so I am fixing that here too. >>> >>> -phil. >>> >>> >>> On 03/10/2016 02:53 PM, Phil Race wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8055463 >>>> http://cr.openjdk.java.net/~prr/8055463/ >>>> >>>> Proposal is to add two new methods in the Font class paralleling the >>>> existing ones >>>> that return only a single font. >>>> >>>> Font[] createFont(File) >>>> Font[] createFont(InputStream) >>>> >>>> I tried to make the single & multiple code be shared as much as >>>> possible >>>> to avoid duplication and I eliminated code in the OSX sub-class which >>>> seemed to be a pointless copy of the superclass. >>>> >>>> The test checks the various assertions I intend by probing for >>>> platform fonts. >>>> >>>> -phil. >>> >> >> > -- Best regards, Sergey. From jayathirth.d.v at oracle.com Mon Mar 14 07:35:26 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 14 Mar 2016 00:35:26 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8151621, , [TEST_BUG] java/awt/print/PrinterJob/MultiMonPrintDlgTest.java doesn't work with jtreg In-Reply-To: <56E2B259.9000402@oracle.com> References: <56E2AD5F.8050507@oracle.com> <56E2B259.9000402@oracle.com> Message-ID: <8b00c1b4-91fc-456e-8eff-8b079cb87ad8@default> Changes are fine. -----Original Message----- From: Yuri Nesterenko Sent: Friday, March 11, 2016 5:26 PM To: prasanta sadhukhan; 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-8151621, , [TEST_BUG] java/awt/print/PrinterJob/MultiMonPrintDlgTest.java doesn't work with jtreg Looks fine, and works well. -yan On 03/11/2016 02:34 PM, prasanta sadhukhan wrote: > Hi Yuri, All, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8151621 > webrev: http://cr.openjdk.java.net/~psadhukhan/8151621/webrev.00/ > > It seems when the testcase is executed through jtreg, the main thread > finishes without waiting for any user action. > Added a sleep time and modified the testcase to wait for user > interaction to finish which will then notify the main thread of > completion . > > Regards > Prasanta > From prasanta.sadhukhan at oracle.com Mon Mar 14 10:33:24 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Mon, 14 Mar 2016 16:03:24 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8151590, , "ALL" radio button is not selected in printDialog when we call DefaultSelectionType.ALL in windows In-Reply-To: <56E2B4B5.9010607@oracle.com> References: <56E14DC0.6020505@oracle.com> <56E2B4B5.9010607@oracle.com> Message-ID: <56E69374.1020101@oracle.com> Hi Phil, Gentle reminder to review this fix. Regards Prasanta On 3/11/2016 5:36 PM, prasanta sadhukhan wrote: > > Please find modified webrev with updated testcase. > http://cr.openjdk.java.net/~psadhukhan/8151590/webrev.01/ > > Regards > Prasanta > On 3/10/2016 4:04 PM, prasanta sadhukhan wrote: >> Hi Phil, >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8151590 >> webrev: http://cr.openjdk.java.net/~psadhukhan/8151590/webrev.00/ >> >> The issue is if application calls >> JobAttributes.setDefaultSelection(JobAttributes.DefaultSelectionType.ALL); >> >> along with >> JobAttributes.setFromPage(2); >> JobAttributes.setToPage(5); >> >> then "Page" radio button is selected in windows. In linux and mac, >> "All" radio button is selected. >> Although the spec is not very clear as to what should get preference, >> it seems logically DefaultSelection should hold preference. >> >> This is a regression from 8061267 where PD_PAGENUMS was added to the >> flags resulting in "Page" radio button getting selected. >> I added a fix to add PD_PAGENUMS to the flags only if the selection >> attribute is not "PD_ALLPAGES" [which gets selected when >> JobAttributes.setDefaultSelection(JobAttributes.DefaultSelectionType.ALL); >> is called] >> >> I tested 8061267 testcase behaviour is same with this fix. >> >> Regards >> Prasanta > From prasanta.sadhukhan at oracle.com Mon Mar 14 10:33:58 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Mon, 14 Mar 2016 16:03:58 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8066139, , Null return from PrintJob.getGraphics() running closed/java/awt/PrintJob/HighResTest/HighResTest.java In-Reply-To: <56E14DB0.8030506@oracle.com> References: <56C6DDF1.1020009@oracle.com> <56C764B3.9020005@oracle.com> <56C77A50.7010605@oracle.com> <56CAAAC8.40009@oracle.com> <56CAC14F.4030602@oracle.com> <56D579B1.7090204@oracle.com> <56DDE8F2.3000707@oracle.com> <56DEA9B2.8020702@oracle.com> <56DEFA8E.3080203@oracle.com> <56E14DB0.8030506@oracle.com> Message-ID: <56E69396.3010809@oracle.com> Gentle reminder . Regards Prasanta On 3/10/2016 4:04 PM, prasanta sadhukhan wrote: > Hi Phil, > > Please find the modified webrev > http://cr.openjdk.java.net/~psadhukhan/8066139/webrev.02/ > > I tested in Mac too but there it seems to be working (ie no NPE) > without and with this fix. > For issue seen on windows , I have raised a bug JDK-8151589 > (strangely it is > not seen in jdk1.8.0_76 but seen from 1.9.0-ea-b01 onwards, can you > tell me what is the release version before b01?] > > Regards > Prasanta > On 3/8/2016 9:45 PM, Philip Race wrote: >> > However, I am finding a strange issue with and without this fix >> too. The "Center" string is not printed >> >> Sounds completely unrelated to anything to do with the NPE bug. >> >> It is probably appropriate to file that as a separate bug. >> No big surprise that the behaviour is platform-specific as there >> is a lot of difference in Windows vs Linux (or vs Mac) in the >> printing code. >> >> -phil. >> >> On 3/8/16, 2:30 AM, prasanta sadhukhan wrote: >>> >>> >>> On 3/8/2016 2:17 AM, Phil Race wrote: >>>> I don't think starting a new thread can be right. That would re-invoke >>>> printerJob.print() which even if you can reuse a PrinterJob >>>> (something that >>>> was never set out in spec.) you are surely getting a new spool job >>>> .. not >>>> a continuation. There a couple of other things I am not sure about >>>> either. >>>> >>>> I've looked into this - only on Linux - and I believe the issue is that >>>> the test program has decided up-front how many pages it is going to >>>> print and it is paying no attention to the selected page ranges. >>>> Not what the 'user' asked for but it is perfectly within its rights >>>> to do so. >>>> >>>> However the 2D PrinterJob operates in a way where it calls back >>>> asking for the specific pages it wants to be printed and there the >>>> app. must comply. The PrinterJob terminates once it has done. >>>> >>>> In the case when the 2D PrinterJob is being used to 'run' a >>>> PrintJob then it must *never* return until the application has >>>> called "end" - or some exception occurs. >>>> >>>> So we need to remove the elements that will cause the job to exit. >>>> >>>> --- a/src/java.desktop/share/classes/sun/print/PrintJob2D.java >>>> +++ b/src/java.desktop/share/classes/sun/print/PrintJob2D.java >>>> @@ -995,6 +995,7 @@ >>>> public void run() { >>>> >>>> try { >>>> + attributes.remove(PageRanges.class); >>>> printerJob.print(attributes); >>>> } catch (PrinterException e) { >>>> //REMIND: need to store this away and not rethrow it. >>>> diff --git >>>> a/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java >>>> b/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java >>>> --- a/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java >>>> +++ b/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java >>>> @@ -1172,6 +1172,7 @@ >>>> pageRangesAttr = (PageRanges)attributes.get(PageRanges.class); >>>> if (!isSupportedValue(pageRangesAttr, attributes)) { >>>> pageRangesAttr = null; >>>> + setPageRange(-1, -1); >>>> } else { >>>> if >>>> ((SunPageSelection)attributes.get(SunPageSelection.class) >>>> == SunPageSelection.RANGE) { >>>> >>>> >>>> This works for me on Linux although >>>> a) I have not tried Windows) >>> I tried on windows. The NPE is not seen and it prints 2 pages. >>> However, I am finding a strange issue with and without this fix too. >>> The "Center" string is not printed in the 1st page in both >>> "Portrait" and "Landscape" mode (although the rectangles are >>> printed) but is printed in the 2nd page. >>> I do not find this issue in linux. >>> >>> Regards >>> Prasanta >>>> b) I have not verified if there are no negative consequences from >>>> the 2nd change. >>>> >>>> -phil. >>>> >>>> On 03/01/2016 03:14 AM, prasanta sadhukhan wrote: >>>>> Hi Phil, >>>>> >>>>> Please find an updated webrev: >>>>> http://cr.openjdk.java.net/~psadhukhan/8066139/webrev.01/ >>>>> >>>>> It seems if printerJobThread finished printing, it will set >>>>> graphicsToBeDrawn/graphicsDrawn ArrayList to null resulting in >>>>> getGraphics() returning null in the 2nd iteration causing NPE so >>>>> I have modified printerJobThread#run so that when it has finished >>>>> printing, do not set the arrayList to null but set a flag. In >>>>> getGraphics(), I check that flag and start a new printerJobThread >>>>> to handle the next printing. >>>>> I have tested "All" and "Pages" selection. >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 2/22/2016 1:35 PM, Philip Race wrote: >>>>>> > It seems this behaviour is same in linux too for this >>>>>> HighResTest testcase. >>>>>> >>>>>> OK that is good information .. so is not really a regression from >>>>>> 8061267 as >>>>>> that is not in >>>>>> any way touching linux .. it is a pre-existing issue in a code >>>>>> path that was not being tested. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 2/22/16, 11:59 AM, prasanta sadhukhan wrote: >>>>>>> Hi Phil, >>>>>>> >>>>>>> >>Additionally, have you tried running the original test case >>>>>>> provided with 8061267 >>>>>>> >> against your fix ? >>>>>>> The 8061267 testcase behaves similarly before and after my fix. >>>>>>> >>>>>>> >> If I manually select it, (ie select that "Pages" radio >>>>>>> button) then press print, >>>>>>> >> then voila, the NPE is back! >>>>>>> It seems this behaviour is same in linux too for this >>>>>>> HighResTest testcase. >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>> On 2/20/2016 1:55 AM, Phil Race wrote: >>>>>>>> I am having trouble building JDK 9 at the moment so i applied >>>>>>>> 8061267 to jdk8u-dev >>>>>>>> and was able to reproduce the regression and have a couple of >>>>>>>> observations >>>>>>>> >>>>>>>> - I am now seeing the NPE after the first page as you did .. >>>>>>>> puzzling. >>>>>>>> - I next applied your fix but still see the NPE ! >>>>>>>> >>>>>>>> It appears that all your fix did is stop the "PD_PAGENUMS" >>>>>>>> flag being automatically >>>>>>>> set. If I manually select it, (ie select that "Pages" radio >>>>>>>> button) then press print, >>>>>>>> then voila, the NPE is back! >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> >>>>>>>> On 02/19/2016 10:53 AM, Phil Race wrote: >>>>>>>>> I am not sure I can be correctly understanding the fix as the >>>>>>>>> ramification seems >>>>>>>>> to be that if the users wants to print only Page 3 of a 10 >>>>>>>>> page document and so sets >>>>>>>>> from page=3 and to page=3, that this request will be ignored >>>>>>>>> and all pages will >>>>>>>>> be printed .. can you test such a scenario. >>>>>>>>> >>>>>>>>> Additionally, have you tried running the original test case >>>>>>>>> provided with 8061267 >>>>>>>>> against your fix ? >>>>>>>>> >>>>>>>>> Also when I ran the HighResTest on a current build I saw a >>>>>>>>> null graphics on >>>>>>>>> the very first call to getGraphics() which is different than >>>>>>>>> what I interpret >>>>>>>>> you as saying - you see the null *after* the first page is >>>>>>>>> printed. >>>>>>>>> >>>>>>>>> -phil. >>>>>>>>> >>>>>>>>> On 02/19/2016 01:18 AM, prasanta sadhukhan wrote: >>>>>>>>>> Hi Phil, All, >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066139 >>>>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8066139/webrev.00/ >>>>>>>>>> >>>>>>>>>> It was seen after fix of JDK-8061267 >>>>>>>>>> : >>>>>>>>>> PrinterJob: Specified Page Ranges not displayed in Windows >>>>>>>>>> Native Print Dialog >>>>>>>>>> the closed/java/awt/PrintJob/HighResTest/HighResTest.java was >>>>>>>>>> failing with NPE when PrinterJob.getGraphics() is called the >>>>>>>>>> 2nd time before calling PrinterJob.end(). >>>>>>>>>> >>>>>>>>>> The above fix caused this regression because it sets the >>>>>>>>>> PD_PAGENUMS flag for windows PrintDlg struct which causes >>>>>>>>>> *Pages* radio button to be selected in print dialog. >>>>>>>>>> However, fromPage and toPage was both set to 1 so after the >>>>>>>>>> 1st page is printed, RasterPrinterJob.print(attributes) >>>>>>>>>> finishes and graphicsToBeDrawn.closeWhenEmpty() gets called >>>>>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/d8def65c6c00/src/java.desktop/share/classes/sun/print/PrintJob2D.java#l1006 >>>>>>>>>> >>>>>>>>>> which sets the queue to null so when >>>>>>>>>> PrinterJob2D#getGraphics() calls graphicsToBeDrawn.pop() it >>>>>>>>>> sees queue to be null and sets graphics object to be null so >>>>>>>>>> PrinterJob.getGraphics() gets null and g.drawLine in testcase >>>>>>>>>> causes NPE since g is null. >>>>>>>>>> >>>>>>>>>> Fix was done to set the PD_PAGENUMS flag only when toPage is >>>>>>>>>> more than fromPage in which case, "All" will be selected in >>>>>>>>>> printer dialog and RasterPrinterJob.print() will finish only >>>>>>>>>> after printing all the pages. >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Prasanta >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Mon Mar 14 23:34:48 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 14 Mar 2016 16:34:48 -0700 Subject: [OpenJDK 2D-Dev] RFR 8144938: Handle properly coordinate overflow in Marlin Renderer In-Reply-To: References: <56E2159E.8000209@oracle.com> <56E22734.7020707@oracle.com> <56E33249.2030300@oracle.com> Message-ID: <56E74A98.30503@oracle.com> Hi Laurent, Did you consider adding a test with a completely degenerate path to make sure that we don't have any state errors if all of the segments are eaten by the "finite path" filter? I like your approach. It is worth noting that: - non-uniform scales are not common - your "always overflow-filter path at device resolution" fixes the issues with measuring overflow in user space that I pointed out in my prior email and only does so at a likely small expense in terms of non-uniform scale performance. Common cases will see no change (other than the fact that you have new code in the path feeder). With respect to the optimization that I gave a rough outline of. It is true that: - it should help eliminate all of the inverse transforms in the strokeTo code - the math is incomplete and would need some work - it only targets the non-uniform case which may not be a high priority - it would probably get rid of the entire TransformingPathConsumer module, but that module is not complex or trouble-prone and seems to be working fine ...jim On 3/11/2016 2:14 PM, Laurent Bourg?s wrote: > Jim, > > Here is a webrev illustrating my 'simple' approach: > http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144938.1/ > > Changes: > - MarlinRenderingEngine.strokeTo(): removed outat ie always call > src.getPathIterator(at) that ensures Marlin is working in device-space > coordinates; so pathTo() can filter out NaN / Infinity points > - TransformingPathConsumer2D: removed transformConsumer() and all its > related inner classes (simplification) > > I will perform a MapBench benchmark focused on non-uniform > transformation to check the possible performance 'regression'. > > Please give me your point of view on the NaN/Infinity overflow handling > that I think it is now correct as all path coordinates are in > the device-space. > > > I think you proposed an optimized approach to refine my solution and get > rid of all inverseDelta/delta transformations at all, does it ? > > I am not sure to have understood all the maths here (after my first 2/3 > reads) but it seems quite complex and I am a bit reluctant as computing > curve offsets or curved lengths seems to me very very tricky and > error-prone ! > > I think your advices are very interesting but I need more concrete > directions to try making changes myself in the Stroker / Dasher code. > > What is the use case for non-uniform transformations ? how important is > it ? In other words, is it worth such effort ? > > > Do you have an alternative solution (simple) ? > > > Yes, if we can take a non-uniform transform and express the pen size > as a tilted ellipse, then we can supply the tilted ellipse > parameters to the stroker and it could perform device-space widening > of non-uniform pens. Basically, we have a method right now that > takes the dx,dy of a path and turns it into a unit vector, does a > simplistic 90 degree transform, and then scales it by the line > width. It looks something like (adapted from Stroker.computeOffset()): > > mdx = dy / len(dx,dy) * halfwidth; > mdy = -dx / len(dx,dy) * halfwidth; > > which is shorthand for: > > (1) normalize dx,dy > (2) rotate dx,dy by 90 degrees > (3) multiply by half the transformed line width > > What we'd need to do for the general case is: > > (1) inverse delta transform to user space > (2) normalize dx,dy to unit vector > (3) rotate by 90 degrees > (4) scale by (half) user space line width > (5) transform back to device space > > > I agree. > > (1) and (3) through (5) are all 2x2 transforms and they could be > able to be flattened into a single transform, but we have that pesky > normalize step at (2) that gets in the way. If not for that, we > could replace the contents of computeOffset with just a 2x2 matrix > multiply, but I punted when I looked at how to introduce the > normalization step. I'm pretty sure that (1) and (2) could be > swapped somehow because all we really have is an elliptical pen and > we should be able to take a normalized vector in device space and > compute a transform that rotates it to the proper orientation that > comes from "inverseTx, rotate90, Tx" and applies the proper scale, > but how to compute that? When done we'd just have a 2x2 matrix to > multiply by, but since the construction of that 2x2 matrix wasn't > immediately obvious from concatenating component matrices I punted > to other problems. > > > A bit lost, but globally I understand. Probably some degenated cases may > apperar (matrix inversion ?) > > Another thing to consider is that dash length will vary based on > angle so we'd need a way to compute "user length of device dx,dy" > quickly. It's essentially computing "len(inverseTransform(dx,dy))", > which is: > > udx = inverseMxx * dx + inverseMxy * dy; > udy = inverseMyx * dx + inverseMyy * dy; > return sqrt(udx * udx + udy * udy); > > which is (renaming inverseM* to I*), and please check my math: > > sqrt((Ixx * dx + Ixy * dy)^2 + (Iyx * dx + Iyy * dy)^2); > sqrt(Ixx*Ixx*dx*dx + 2Ixx*Ixy*dx*dy + Ixy*Ixy*dy*dy + > Iyx*Iyx*dx*dx + 2Iyx*Iyy*dx*dy + Iyy*Iyy*dy*dy); > sqrt( (Ixx*Ixx + Iyx*Iyx)*dx*dx + > 2(Ixx*Ixy + Iyx*Iyy)*dx*dy + > (Ixy*Ixy + Iyy*Iyy)*dy*dy); > sqrt(K1 * dx * dx + K2 * dx * dy + K3 * dy * dy); > > > Will check later (as it is late here) but it looks correct. > > > For a uniform scale K1 == K3 == squared inverse scale and K2 == 0 > and K1,K3 can then be factored out of the sqrt into a constant and > applied to the dash lengths instead. > > which is only a little more complicated than a regular length > computation. Unfortunately, since the angle changes over the course > of a curve, it might prove a little tricky for the iterator that > computes the length of the dashes along the curve, but it could be > as simple as calling a different length method as it iterates. > > > It seems too simple to be true. I have doubts I can handle such changes > myself. > > Besides, we should also check early if the transformation matrix > contains NaN or Infinity values avoiding the path iteration. I > advocate > it is an extreme case. > > > That could be a short-cut optimization, but it depends on how much > it costs compared to just letting the path degeneracy elimination > turn it all into a NOP segment by segment... > > > I agree this shortcut is only worth if it happens in reality... > > To conclude tonight, I will run few benchmarks and am looking forward > your comments. > > Cheers, > Laurent From james.graham at oracle.com Mon Mar 14 23:35:41 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 14 Mar 2016 16:35:41 -0700 Subject: [OpenJDK 2D-Dev] RFR 8144938: Handle properly coordinate overflow in Marlin Renderer In-Reply-To: References: <56E2159E.8000209@oracle.com> <56E22734.7020707@oracle.com> <56E33249.2030300@oracle.com> Message-ID: <56E74ACD.9030102@oracle.com> Was this on a uniform scale? Did you do a test with a non-uniform scale? ...jim On 3/11/2016 3:10 PM, Laurent Bourg?s wrote: > Jim, > > Here are MapBench results comparing Marlin 0.7.3.2 (before) vs patched > 0.7.3.3 (latest patch) on JDK 1.8_72: > > Synthetic results: > > Tests 36 12 12 12 > Threads 4 1 2 4 > > Before = Marlin 0.7.3.2 : > *Med 168.535 165.403 166.940 173.263 * > *Pct95 170.256 166.011 167.495 177.260 > FPS 43.200 43.404 43.203 42.993 * > > Patched = Marlin 0.7.3.3 : > *Med 169.481 166.344 168.096 174.004 * > *Pct95 170.295 166.800 168.751 175.335 > FPS 42.194 42.340 42.211 42.031 > > * > The difference is very minor ~ 1/2ms in global average (36 or 12 tests) > ie within error margin ! > Only FPS (based on median timings) seem indicating that Marlin 0.7.3.2 > is 'very slightly' faster.* > * > * > > * > Complete results: > > Before = Marlin 0.7.3.2 : > > Test Threads Ops > Med Pct95 Avg StdDev Min Max FPS(med) TotalOps > [ms/op] > CircleTests.ser 1 146 71.663 > 72.225 71.735 0.321 71.162 73.045 13.954 146 > CircleTests.ser 2 292 72.652 > 73.153 72.683 0.284 72.001 73.818 13.764 292 > CircleTests.ser 4 584 73.675 > 75.495 73.944 1.152 72.320 91.951 13.573 584 > EllipseTests-fill-false.ser 1 35 295.363 > 297.853 295.594 0.764 295.097 298.280 3.386 35 > EllipseTests-fill-false.ser 2 70 294.418 > 295.059 294.345 0.613 293.191 295.685 3.397 70 > EllipseTests-fill-false.ser 4 140 295.378 > 303.661 298.108 14.352 293.428 422.684 3.385 140 > EllipseTests-fill-true.ser 1 25 436.748 > 437.658 436.816 0.445 436.180 438.120 2.290 25 > EllipseTests-fill-true.ser 2 50 449.424 > 451.158 449.191 2.426 446.658 458.887 2.225 50 > EllipseTests-fill-true.ser 4 100 513.228 > 520.717 514.442 3.673 497.246 533.654 1.948 100 > dc_boulder_2013-13-30-06-13-17.ser 1 123 82.827 > 83.351 82.818 0.278 82.156 83.620 12.073 123 > dc_boulder_2013-13-30-06-13-17.ser 2 246 83.840 > 84.142 83.796 0.255 83.175 84.301 11.928 246 > dc_boulder_2013-13-30-06-13-17.ser 4 492 84.501 > 86.983 85.032 1.522 83.268 105.370 11.834 492 > dc_boulder_2013-13-30-06-13-20.ser 1 240 42.740 > 43.061 42.702 0.281 42.126 44.237 23.397 240 > dc_boulder_2013-13-30-06-13-20.ser 2 480 43.979 > 44.183 44.001 0.135 43.253 45.934 22.738 480 > dc_boulder_2013-13-30-06-13-20.ser 4 960 44.466 > 45.612 44.584 0.943 43.499 65.537 22.489 960 > dc_shp_alllayers_2013-00-30-07-00-43.ser 1 264 39.132 > 39.390 39.070 0.258 38.541 39.631 25.554 264 > dc_shp_alllayers_2013-00-30-07-00-43.ser 2 528 39.543 > 40.107 39.599 0.338 38.938 40.982 25.289 528 > dc_shp_alllayers_2013-00-30-07-00-43.ser 4 1056 40.429 > 41.233 40.504 0.769 39.267 62.092 24.735 1056 > dc_shp_alllayers_2013-00-30-07-00-47.ser 1 25 828.145 > 829.424 828.236 0.701 826.863 830.275 1.208 25 > dc_shp_alllayers_2013-00-30-07-00-47.ser 2 50 829.794 > 831.670 829.920 1.326 827.584 833.811 1.205 50 > dc_shp_alllayers_2013-00-30-07-00-47.ser 4 100 835.829 > 859.380 841.386 10.144 831.585 863.487 1.196 100 > dc_spearfish_2013-11-30-06-11-15.ser 1 822 12.424 > 12.518 12.438 0.039 12.396 12.721 80.492 822 > dc_spearfish_2013-11-30-06-11-15.ser 2 1644 12.472 > 12.621 12.499 0.059 12.429 12.860 80.177 1644 > dc_spearfish_2013-11-30-06-11-15.ser 4 3288 12.499 > 12.888 12.602 0.407 12.416 31.385 80.004 3288 > dc_spearfish_2013-11-30-06-11-19.ser 1 1647 6.368 > 6.431 6.374 0.023 6.353 6.548 157.047 1647 > dc_spearfish_2013-11-30-06-11-19.ser 2 3294 6.370 > 6.435 6.375 0.025 6.350 7.025 156.982 3294 > dc_spearfish_2013-11-30-06-11-19.ser 4 6588 6.379 > 6.443 6.392 0.235 6.353 24.259 156.755 6588 > dc_topp:states_2013-11-30-06-11-06.ser 1 791 13.258 > 13.435 13.285 0.080 13.194 13.576 75.424 791 > dc_topp:states_2013-11-30-06-11-06.ser 2 1582 13.383 > 13.541 13.366 0.095 13.207 13.680 74.720 1582 > dc_topp:states_2013-11-30-06-11-06.ser 4 3164 13.318 > 13.529 13.353 0.373 13.205 31.555 75.084 3164 > dc_topp:states_2013-11-30-06-11-07.ser 1 1221 8.385 > 8.555 8.415 0.082 8.329 9.306 119.254 1221 > dc_topp:states_2013-11-30-06-11-07.ser 2 2442 8.382 > 8.563 8.419 0.077 8.336 8.680 119.303 2442 > dc_topp:states_2013-11-30-06-11-07.ser 4 4884 8.454 > 8.666 8.473 0.253 8.332 19.872 118.291 4884 > test_z_625k.ser 1 71 147.778 > 148.236 147.762 0.324 146.781 148.338 6.767 71 > test_z_625k.ser 2 142 149.019 > 149.311 149.002 0.218 148.444 149.558 6.711 142 > test_z_625k.ser 4 284 150.994 > 152.514 151.185 1.326 149.368 171.277 6.623 284 > > Scores: > Tests 36 12 12 12 > Threads 4 1 2 4 > *Med 168.535 165.403 166.940 173.263 * > *Pct95 170.256 166.011 167.495 177.260 > FPS 43.200 43.404 43.203 42.993 * > > > Patched = Marlin 0.7.3.3 : > > Test Threads Ops > Med Pct95 Avg StdDev Min Max FPS(med) TotalOps > [ms/op] > CircleTests.ser 1 141 74.384 > 74.900 74.404 0.304 73.822 75.428 13.444 141 > CircleTests.ser 2 282 75.187 > 75.542 75.200 0.212 74.667 76.527 13.300 282 > CircleTests.ser 4 564 78.456 > 79.359 78.047 1.544 75.002 101.072 12.746 564 > EllipseTests-fill-false.ser 1 35 293.541 > 294.431 293.563 0.710 292.023 294.603 3.407 35 > EllipseTests-fill-false.ser 2 70 294.290 > 296.877 294.578 1.547 291.809 297.005 3.398 70 > EllipseTests-fill-false.ser 4 140 293.914 > 297.667 294.655 2.639 292.165 319.054 3.402 140 > EllipseTests-fill-true.ser 1 25 435.423 > 436.001 435.500 0.372 435.051 436.990 2.297 25 > EllipseTests-fill-true.ser 2 50 446.800 > 448.429 446.907 1.960 444.852 455.553 2.238 50 > EllipseTests-fill-true.ser 4 100 510.117 > 512.215 510.355 2.718 507.249 533.946 1.960 100 > dc_boulder_2013-13-30-06-13-17.ser 1 123 85.126 > 85.689 85.185 0.279 84.913 87.077 11.747 123 > dc_boulder_2013-13-30-06-13-17.ser 2 246 85.914 > 86.276 85.944 0.150 85.715 86.638 11.640 246 > dc_boulder_2013-13-30-06-13-17.ser 4 492 86.984 > 87.633 87.053 1.207 85.843 109.197 11.496 492 > dc_boulder_2013-13-30-06-13-20.ser 1 240 43.508 > 44.306 43.638 0.348 43.308 46.308 22.984 240 > dc_boulder_2013-13-30-06-13-20.ser 2 480 44.452 > 44.909 44.500 0.206 44.109 45.435 22.496 480 > dc_boulder_2013-13-30-06-13-20.ser 4 960 45.897 > 46.231 45.823 0.849 44.521 66.349 21.788 960 > dc_shp_alllayers_2013-00-30-07-00-43.ser 1 265 39.453 > 40.006 39.472 0.279 39.037 40.216 25.346 265 > dc_shp_alllayers_2013-00-30-07-00-43.ser 2 530 40.118 > 40.689 40.114 0.329 39.268 41.028 24.927 530 > dc_shp_alllayers_2013-00-30-07-00-43.ser 4 1060 40.700 > 41.181 40.735 0.744 40.026 62.110 24.570 1060 > dc_shp_alllayers_2013-00-30-07-00-47.ser 1 25 832.892 > 833.254 832.836 0.321 832.124 833.376 1.201 25 > dc_shp_alllayers_2013-00-30-07-00-47.ser 2 50 836.860 > 838.171 836.882 0.903 834.890 838.289 1.195 50 > dc_shp_alllayers_2013-00-30-07-00-47.ser 4 100 837.405 > 843.556 837.978 4.264 835.075 858.780 1.194 100 > dc_spearfish_2013-11-30-06-11-15.ser 1 818 12.826 > 12.948 12.843 0.057 12.804 13.663 77.969 818 > dc_spearfish_2013-11-30-06-11-15.ser 2 1636 12.851 > 12.941 12.854 0.047 12.801 13.271 77.816 1636 > dc_spearfish_2013-11-30-06-11-15.ser 4 3272 12.843 > 12.989 12.879 0.325 12.813 28.151 77.866 3272 > dc_spearfish_2013-11-30-06-11-19.ser 1 1606 6.525 > 6.589 6.532 0.027 6.507 6.734 153.267 1606 > dc_spearfish_2013-11-30-06-11-19.ser 2 3212 6.523 > 6.573 6.527 0.025 6.502 6.992 153.309 3212 > dc_spearfish_2013-11-30-06-11-19.ser 4 6424 6.526 > 6.578 6.538 0.233 6.503 23.834 153.242 6424 > dc_topp:states_2013-11-30-06-11-06.ser 1 781 13.488 > 13.596 13.469 0.084 13.335 13.678 74.141 781 > dc_topp:states_2013-11-30-06-11-06.ser 2 1562 13.502 > 13.632 13.491 0.089 13.343 13.760 74.060 1562 > dc_topp:states_2013-11-30-06-11-06.ser 4 3124 13.499 > 13.635 13.503 0.295 13.344 26.397 74.081 3124 > dc_topp:states_2013-11-30-06-11-07.ser 1 1209 8.648 > 8.719 8.626 0.074 8.489 8.913 115.627 1209 > dc_topp:states_2013-11-30-06-11-07.ser 2 2418 8.652 > 8.718 8.626 0.072 8.500 8.811 115.578 2418 > dc_topp:states_2013-11-30-06-11-07.ser 4 4836 8.659 > 8.730 8.647 0.269 8.494 23.649 115.487 4836 > test_z_625k.ser 1 69 150.311 > 151.154 150.448 0.408 149.847 151.557 6.653 69 > test_z_625k.ser 2 138 152.004 > 152.252 152.013 0.114 151.744 152.410 6.579 138 > test_z_625k.ser 4 276 153.049 > 154.245 153.266 1.418 152.792 175.424 6.534 276 > > Scores: > Tests 36 12 12 12 > Threads 4 1 2 4 > *Med 169.481 166.344 168.096 174.004 * > *Pct95 170.295 166.800 168.751 175.335 > FPS 42.194 42.340 42.211 42.031 > * > Cheers, > Laurent From bourges.laurent at gmail.com Tue Mar 15 08:24:34 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 15 Mar 2016 09:24:34 +0100 Subject: [OpenJDK 2D-Dev] RFR 8144938: Handle properly coordinate overflow in Marlin Renderer In-Reply-To: <56E74ACD.9030102@oracle.com> References: <56E2159E.8000209@oracle.com> <56E22734.7020707@oracle.com> <56E33249.2030300@oracle.com> <56E74ACD.9030102@oracle.com> Message-ID: Jim, Yes these results were obtained with MapBench and a specific profile: Loading profile file: /home/marlin/mapbench/bin/../profiles/shared_nu-tx.properties Profile properties (merged with defaults): doRotate=true doScale=true rotateAngle=3.123456789 (deg) scaleX=1.156 scaleY=0.945 Moreover, I checked in the code (system.out.println) that this benchmark really tests the modified pipeline (non-uniform case). Cheers, Laurent 2016-03-15 0:35 GMT+01:00 Jim Graham : > Was this on a uniform scale? Did you do a test with a non-uniform scale? > > ...jim > > On 3/11/2016 3:10 PM, Laurent Bourg?s wrote: > >> Jim, >> >> Here are MapBench results comparing Marlin 0.7.3.2 (before) vs patched >> 0.7.3.3 (latest patch) on JDK 1.8_72: >> >> Synthetic results: >> >> Tests 36 12 12 12 >> Threads 4 1 2 4 >> >> Before = Marlin 0.7.3.2 : >> *Med 168.535 165.403 166.940 173.263 * >> *Pct95 170.256 166.011 167.495 177.260 >> FPS 43.200 43.404 43.203 42.993 * >> >> Patched = Marlin 0.7.3.3 : >> *Med 169.481 166.344 168.096 174.004 * >> *Pct95 170.295 166.800 168.751 175.335 >> FPS 42.194 42.340 42.211 42.031 >> >> * >> The difference is very minor ~ 1/2ms in global average (36 or 12 tests) >> ie within error margin ! >> Only FPS (based on median timings) seem indicating that Marlin 0.7.3.2 >> is 'very slightly' faster.* >> * >> * >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Tue Mar 15 11:48:04 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 15 Mar 2016 14:48:04 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8076545 Text size is twice bigger under Windows L&F on Win 8.1 with HiDPI display In-Reply-To: <56E31453.3010601@oracle.com> References: <5596C117.1040806@oracle.com> <559DB2FB.5000208@oracle.com> <55A902D4.1050603@oracle.com> <563208A9.50702@oracle.com> <56328355.1010608@oracle.com> <5633C7C8.2030804@oracle.com> <5649E312.2010606@oracle.com> <564A41D3.5010202@oracle.com> <564A4DE9.1040102@oracle.com> <56ABB269.6030808@oracle.com> <56ABD6B2.10302@oracle.com> <56AF4F4C.4030504@oracle.com> <56B00B8B.9040102@oracle.com> <56B47579.3090309@oracle.com> <56B4FA0A.3080505@oracle.com> <56B60EE4.2070501@oracle.com> <56B91F12.9070909@oracle.com> <56BE467A.8060403@oracle.com> <56C225D4.4030909@oracle.com> <56E31453.3010601@oracle.com> Message-ID: <56E7F674.2010207@oracle.com> On 11.03.16 21:54, Alexandr Scherbatiy wrote: > I need one more reviewer for the fix. Looks fine. > > On 2/15/2016 11:24 AM, Jim Graham wrote: >> Thanks Alexandr, >> >> The AWT changes all look good. >> >> I'll leave it to others as to whether the test case represents the >> best way to test this. I have no idea how those two font values in >> those two L&F's in a Swing button should compare - maybe a difference >> of 8 is ordinary under some circumstances? Also, the test will only >> be conclusive when run on a HiDPI display larger than a certain scale >> factor so it may not even be testing anything in most test environments. > > Should I add a manual test where it will be required to run it on > HiDPI displays? > > Thanks, > Alexandr. > >> >> In either case, the AWT code changes look fine... >> >> ...jim >> >> On 2/12/16 12:54 PM, Alexandr Scherbatiy wrote: >>> On 2/8/2016 3:04 PM, Jim Graham wrote: >>>> I don't understand the issue with the fonts that you are saying have >>>> different sizes for different DPIs. Those are pixel sizes, aren't >>>> they? They still need to be turned into user-space units for our >>>> applications to know what to do with them. Or, are you saying that >>>> they are not representing pixel sizes as the rest of the font units do >>>> and so they are already in DPI-relative "user space" units? >>>> >>>> AT 192 DPI, oemFixed.font is 18, but are they saying 18 pixels? Which >>>> would be a 9-point font in our automatically scaled coordinate >>>> systems, wouldn't it? >>> >>> The font size in the AwtDesktopProperties is calculated as (tmHeight >>> - tmInternalLeading) values from TEXTMETRIC: >>> jint pointSize = metrics.tmHeight - metrics.tmInternalLeading; >>> According to MSDN "All sizes are specified in logical units; that is, >>> they depend on the current mapping mode of the display context." >>> >>> The calculated size value is proportional to the scale factor for the >>> fonts like win.frame.captionFont : >>> DPI 96 (scale 100%), size: 15 >>> DPI 144 (scale 150%), size: 23 >>> DPI 192 (scale 200%), size: 30 >>> >>> That means that for each DPI it is possible to scale down the font >>> size to its base value just using the formula: >>> baseFontSize = fontSize / scaleFactor >>> >>> However, for win.ansiFixed.font the TEXTMETRIC returns the same values >>> for each display DPI: >>> DPI 96 (scale 100%), size: 13 >>> DPI 144 (scale 150%), size: 13 >>> DPI 192 (scale 200%), size: 13 >>> >>> Now scaling the size down for DPI 192 ( 13/ 2) it does not give the >>> font size for the DPI 96. >>> That is why the scale factor 1.0 is used in this case in the fix. >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> ...jim >>>> >>>> On 2/6/16 7:19 AM, Alexander Scherbatiy wrote: >>>>> On 2/5/2016 11:37 AM, Jim Graham wrote: >>>>>> Hi Alexandr, >>>>>> >>>>>> awt_DesktopProperties.cpp, line 300 - is the "1.0f /" a typo? >>>>> Sorry. Here is the updated fix without the typo: >>>>> http://cr.openjdk.java.net/~alexsch/8076545/webrev.06/ >>>>>> >>>>>> Also, is there a still a need for the setFontProperty() variants that >>>>>> don't have a scale as the last parameter? >>>>> There are fonts like win.ansiFixed.font, win.ansiVar.font, and >>>>> win.deviceDefault.font which size is the same for any display DPI. >>>>> >>>>> And there are fonts like win.oemFixed.font, win.system.font, and >>>>> win.systemFixed.font which have one size for DPI 96 and another >>>>> size for >>>>> all other DPI. >>>>> For example win.oemFixed.font: >>>>> DPI 96, size: 12 >>>>> DPI 144, size: 18 >>>>> DPI 192, size: 18 >>>>> DPI 240, size: 18 >>>>> >>>>> I left them unscaled but may be it is better to have one >>>>> precalculated scale for this fonts which is used when DPI is not 96. >>>>> >>>>> I updated the setFontProperty() method without scale parameter >>>>> usage >>>>> to call with scale 1.0f. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>>> >>>>>> ...jim >>>>>> >>>>>> On 2/5/2016 2:12 AM, Alexandr Scherbatiy wrote: >>>>>>> >>>>>>> Could you review the updated fix: >>>>>>> http://cr.openjdk.java.net/~alexsch/8076545/webrev.05 >>>>>>> >>>>>>> - The awt_DesktopProperties.cpp file is updated to use scaleX for >>>>>>> width rescaling and scaleY for height rescaling >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> On 2/1/2016 5:51 PM, Jim Graham wrote: >>>>>>>> Hi Alexandr, >>>>>>>> >>>>>>>> In awt_DesktopProperties.cpp you are using the Y scaling factor to >>>>>>>> scale widths still - see lines 287 (and others in that same >>>>>>>> function) >>>>>>>> and then 322 in another function. It looks like you'll need >>>>>>>> getInvScaleX() and getInvScaleY(). >>>>>>>> >>>>>>>> I'll leave it to Phil to comment on the unit test... >>>>>>>> >>>>>>>> ...jim >>>>>>>> >>>>>>>> On 2/1/16 4:27 AM, Alexandr Scherbatiy wrote: >>>>>>>>> >>>>>>>>> Could you review the updated fix: >>>>>>>>> http://cr.openjdk.java.net/~alexsch/8076545/webrev.04/ >>>>>>>>> >>>>>>>>> - both LOGPIXELSX and Y are used for the theme size scaling. >>>>>>>>> - LOGPIXELSY is used for text metrics height rescaling >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> On 1/29/2016 1:16 PM, Jim Graham wrote: >>>>>>>>>> Hi Alexandr, >>>>>>>>>> >>>>>>>>>> Thanks for investigating the behaviors. >>>>>>>>>> >>>>>>>>>> With respect to using LOGPIXELSX or Y, these methods are used to >>>>>>>>>> scale >>>>>>>>>> both horizontal and vertical measurements so we really should >>>>>>>>>> have 2 >>>>>>>>>> scale values and rescale methods, one for horizontal use and one >>>>>>>>>> for >>>>>>>>>> vertical... >>>>>>>>>> >>>>>>>>>> ...jim >>>>>>>>>> >>>>>>>>>> On 1/29/2016 10:41 AM, Alexandr Scherbatiy wrote: >>>>>>>>>>> Could you review the updated fix: >>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8076545/webrev.03 >>>>>>>>>>> >>>>>>>>>>> - LOGPIXELSX is changed to LOGPIXELSY >>>>>>>>>>> >>>>>>>>>>> On 11/16/2015 1:43 PM, Jim Graham wrote: >>>>>>>>>>>> Note that LOGPIXELSY is global and static between reboots so it >>>>>>>>>>>> doesn't really matter which monitor is used to get the value. >>>>>>>>>>>> >>>>>>>>>>>> Also, the issue is that the measurements are in pixels, so >>>>>>>>>>>> if we >>>>>>>>>>>> convert them into a resolution independent measurement then the >>>>>>>>>>>> rest >>>>>>>>>>>> of the scaling in the AWT/2D will be correct regardless of any >>>>>>>>>>>> given >>>>>>>>>>>> monitor's resolution. We just have to make sure the >>>>>>>>>>>> "de-pixelization" >>>>>>>>>>>> of the measurement is an apples-to-apples calculation. >>>>>>>>>>>> >>>>>>>>>>>> The question in my mind is whether the values they get from >>>>>>>>>>>> GetTheme*() and SPI_GETNONCLIENTMETRICS are relative to >>>>>>>>>>>> LOGPIXELSY, or >>>>>>>>>>>> the more recent Per-Monitor aware DPI APIs, or ...? It would be >>>>>>>>>>>> interesting to see what happens to those values when you >>>>>>>>>>>> change the >>>>>>>>>>>> DPI settings on Windows 8.1 and not reboot. If they stay >>>>>>>>>>>> constant >>>>>>>>>>>> until you reboot then LOGPIXELSY on the main screen would be >>>>>>>>>>>> the >>>>>>>>>>>> value >>>>>>>>>>>> to use to de-scale them... >>>>>>>>>>> >>>>>>>>>>> I tried to use the "Change the size of all items" slider on >>>>>>>>>>> Windows >>>>>>>>>>> 8.1 without rebooting. >>>>>>>>>>> GetDpiForMonitor() returns the updated DPI values: 192, >>>>>>>>>>> 144, 96 >>>>>>>>>>> LOGPIXELSY returns unchanged values: 192, 192, 192 >>>>>>>>>>> SystemParametersInfo(SPI_GETNONCLIENTMETRICS,...) returns >>>>>>>>>>> unchanged >>>>>>>>>>> NONCLIENTMETRICS >>>>>>>>>>> GetThemePartSize() returns unchanged theme part sizes >>>>>>>>>>> >>>>>>>>>>> It seems that theme part sizes behave in the same way as the >>>>>>>>>>> LOGPIXELSY in this case. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ...jim >>>>>>>>>>>> >>>>>>>>>>>> On 11/16/2015 12:51 PM, Phil Race wrote: >>>>>>>>>>>>> That seems better. But one more question to get a point >>>>>>>>>>>>> clarified. >>>>>>>>>>>>> You are using getDesktopWindow() which is for the primary >>>>>>>>>>>>> monitor. >>>>>>>>>>>>> I assume that the 'inversion' results in the value being used >>>>>>>>>>>>> to be >>>>>>>>>>>>> independent >>>>>>>>>>>>> of the monitor in a multi-mon situation and so when we move to >>>>>>>>>>>>> a 2nd >>>>>>>>>>>>> monitor >>>>>>>>>>>>> that inverted size remains valid ? >>>>>>>>>>>>> >>>>>>>>>>>>> If so looks good to me. >>>>>>>>>>>>> >>>>>>>>>>>>> -phil. >>>>>>>>>>>>> >>>>>>>>>>>>> On 11/16/2015 06:07 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Could you review the updated fix: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8076545/webrev.02 >>>>>>>>>>>>>> >>>>>>>>>>>>>> - round is used instead of ceil >>>>>>>>>>>>>> - inverted scales are used >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 10/30/2015 10:40 PM, Jim Graham wrote: >>>>>>>>>>>>>>> In this case round may be better. ceil() is more for cases >>>>>>>>>>>>>>> where you >>>>>>>>>>>>>>> needed "at least X amount of room", but I don't think a font >>>>>>>>>>>>>>> size is >>>>>>>>>>>>>>> an "at least this much" kind of case. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Also, I've been toying with the idea that use of ceil() and >>>>>>>>>>>>>>> floor() >>>>>>>>>>>>>>> in any DPI-adjustment equations should really be "ceil(val - >>>>>>>>>>>>>>> epsilon)" or "floor(ceil + epsilon)" for some small value of >>>>>>>>>>>>>>> epsilon >>>>>>>>>>>>>>> chosen just large enough to prevent various round-off errors >>>>>>>>>>>>>>> from >>>>>>>>>>>>>>> affecting the outcome. One idea is for 1/256 as the >>>>>>>>>>>>>>> value of >>>>>>>>>>>>>>> epsilon >>>>>>>>>>>>>>> since that could equate to the smallest measurable >>>>>>>>>>>>>>> difference in >>>>>>>>>>>>>>> terms of alpha or interpolation results (or 1/512 for "half >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> smallest quantum")... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ...jim >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 10/29/15 1:36 PM, Phil Race wrote: >>>>>>>>>>>>>>>> size->cx = (int)ceil(size->cx / scale); >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So if size->cx / scale works out to be 12.0001 you will >>>>>>>>>>>>>>>> round >>>>>>>>>>>>>>>> it up >>>>>>>>>>>>>>>> to 13? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Can you check what pixel size windows gives you in such a >>>>>>>>>>>>>>>> case ? >>>>>>>>>>>>>>>> I'd be a little surprised if they did that rather than >>>>>>>>>>>>>>>> round. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Is the SetFontProperty that does not accept a scale >>>>>>>>>>>>>>>> parameter >>>>>>>>>>>>>>>> still >>>>>>>>>>>>>>>> used >>>>>>>>>>>>>>>> somewhere ? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -phil. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 10/29/2015 04:53 AM, Sergey Bylokhov wrote: >>>>>>>>>>>>>>>>> On 17.07.15 16:27, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> - Sergey's point about multi-mon should be checked out. >>>>>>>>>>>>>>>>>> Windows 8.1 has option "Let me choose one scaling >>>>>>>>>>>>>>>>>> level >>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>> all my >>>>>>>>>>>>>>>>>> displays". >>>>>>>>>>>>>>>>>> If I unset it I am able to change the size of all >>>>>>>>>>>>>>>>>> items. >>>>>>>>>>>>>>>>>> However, >>>>>>>>>>>>>>>>>> the DPI which returns GetDPIForMonitor is still 2 on >>>>>>>>>>>>>>>>>> HiDPI >>>>>>>>>>>>>>>>>> displays. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This version looks fine, but I am sure it can be double >>>>>>>>>>>>>>>>> checked on >>>>>>>>>>>>>>>>> windows 10 at some moment as well. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> > -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Tue Mar 15 12:05:48 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Tue, 15 Mar 2016 17:35:48 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6379088, , Suboptimal expression in javax.imageio.ImageTypeSpecifier.getBitsPerBand(int) Message-ID: <56E7FA9C.4000603@oracle.com> Hi All, Bug: https://bugs.openjdk.java.net/browse/JDK-6379088 webrev: http://cr.openjdk.java.net/~psadhukhan/6379088/webrev.00/ Please review a simple fix where we should be using short-circuit logical operators so that if left side of the expression is false, right side will not be evaluated. I intend to put noreg-trivial label for this fix. Regards Prasanta From bourges.laurent at gmail.com Tue Mar 15 13:46:47 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 15 Mar 2016 14:46:47 +0100 Subject: [OpenJDK 2D-Dev] RFR 8144938: Handle properly coordinate overflow in Marlin Renderer In-Reply-To: <56E74A98.30503@oracle.com> References: <56E2159E.8000209@oracle.com> <56E22734.7020707@oracle.com> <56E33249.2030300@oracle.com> <56E74A98.30503@oracle.com> Message-ID: Dear Jim, Here is a new webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144938.2/ Changes: - pathToLoop() rewritten to simplify the logic (skip and pathClosed flags removed) - added several createStrokedShape() tests in CrashNaNTest class I hope my changes to the filtering algorithm are correct: I advocate not understanding why it was so complicated (3 flags => 1) but maybe I am wrong and I missed several corner cases... My comments below: 2016-03-15 0:34 GMT+01:00 Jim Graham : > Hi Laurent, > > Did you consider adding a test with a completely degenerate path to make > sure that we don't have any state errors if all of the segments are eaten > by the "finite path" filter? > Fixed and it produces empty paths (only pathDone): I wonder if it is time to remove the following lines 317-322 in MarlinRenderingEngine.strokeTo(): // Every path needs an initial moveTo and a pathDone. If these // are not there this causes a SIGSEGV in libawt.so (at the time // of writing of this comment (September 16, 2010)). Actually, // I am not sure if the moveTo is necessary to avoid the SIGSEGV // but the pathDone is definitely needed. pc2d.moveTo(0f, 0f); For me, it is useless as only pc2d.pathDone() is mandatory. > > I like your approach. It is worth noting that: > > - non-uniform scales are not common > - your "always overflow-filter path at device resolution" fixes the issues > with measuring overflow in user space that I pointed out in my prior email > and only does so at a likely small expense in terms of non-uniform scale > performance. Common cases will see no change (other than the fact that you > have new code in the path feeder). > Thanks. It has an important consequence for me: it's possible to introduce a new stage in the pipeline (before inverseDeltaTransformConsumer) that implements path clipping in device-space ONLY compatible with the rectangular bounding box. > > With respect to the optimization that I gave a rough outline of. It is > true that: > > - it should help eliminate all of the inverse transforms in the strokeTo > code > - the math is incomplete and would need some work > - it only targets the non-uniform case which may not be a high priority > - it would probably get rid of the entire TransformingPathConsumer module, > but that module is not complex or trouble-prone and seems to be working fine > I totally agree. I think improving Marlin's Stroker to better optimize square caps / mitter joins or adding path clipping would provide more benefits as it would minimize the number of point / edges used later by the Renderer stage. Thanks for your comments, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue Mar 15 14:01:39 2016 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 15 Mar 2016 18:01:39 +0400 Subject: [OpenJDK 2D-Dev] [9] Review request for 8151303 [macosx] [hidpi] JButton's low-res. icon is visible when clicking on it In-Reply-To: <56E3277B.3000309@oracle.com> References: <56E01777.1030202@oracle.com> <56E01DE7.9040103@oracle.com> <56E2CB4F.6040301@oracle.com> <56E3277B.3000309@oracle.com> Message-ID: <56E815C3.40208@oracle.com> On 12/03/16 00:15, Jim Graham wrote: > Is this tied in with ImageFilter/FilteredImageSource? > > It looks like since FIS takes only a Producer, it has lost the handle > to the image to get a source for a particular resolution. What happens > if we introduce MultiResolution[Image]Producer? It would provide a > single method that would mimic .getRV().getProducer()? > > I imagine this would greatly complicate the internals of ToolkitImage > to support this, though... It is possible to introduce MultiResolutionImageProducer to make the code below work without changes: Image mrImage = createMultiResolutionImage(); Image img = toolkit.createImage(new FilteredImageSource(mrImage.getSource(), filter)); One update will be that FilteredImageSource should implement MultiResolutionImageProducer even it is used for non multi-resolution images. The MRI can be created using two general ways: using fixed number of resolution variants or generating a resolution variant with necessary quality on demand. The current implementation is rely on that MRToolkitImage contains a fixed number of resolution variants. In this case MediaTracker can iterate over resolution variants and load them all. Using MultiResolutionImageProducer leads that MRToolkitImage will not know about number of resolution variants in case when they are generated on the fly and there will be no way to load all of them by MediaTracker. As I see, the way to solve it is only using MRI.getResolutionVariants() method for the MultiResolutionImageProducer creation. So the result of the call toolkit.createImage(new FilteredImageSource(mrImage.getSource(), filter)); will be a MRToolkitImage which is based on fixed number of filtered resolution variants from the original MRI. Thanks, Alexandr. > ...jim > > On 3/11/16 5:42 AM, Alexander Scherbatiy wrote: >> On 09/03/16 16:58, Sergey Bylokhov wrote: >>> Probably we should enhance ImageProducer/Tk.createImage/ImageFilter to >>> support this functionality? It seems that the number of usage of this >>> check "image instanceof MultiResolutionImage" will grow over time. >> ImageProducer produces pixels for an image and is not able to take >> an information about the image resolution variants. >> >> May be we can add Toolkit.createImage(Image image, ImageFilter >> imageFilter) method which takes MultiResolutionImage into account to >> cover the common case where filtered image is created. >> >> Thanks, >> Alexandr. >>> I think that at least our own API should support MultiResolutionImage >>> w/o such checks, otherwise the user will need to do the same. >>> >>> cc 2d-dev >>> >>> On 09.03.16 15:30, Alexander Scherbatiy wrote: >>>> >>>> Hello, >>>> >>>> Could you review the fix: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8151303 >>>> webrev: http://cr.openjdk.java.net/~alexsch/8151303/webrev.00 >>>> >>>> The AquaUtils does not take into account MultiResolutionImage for >>>> selected/disabled/lightened images generation. >>>> The fix also leaves the MultiResolutionCachedImage check because >>>> the >>>> base system icon size can be differ from the requested painted size. >>>> >>>> Thanks, >>>> Alexandr. >>> >>> >> From ajit.ghaisas at oracle.com Tue Mar 15 14:05:12 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Tue, 15 Mar 2016 07:05:12 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception In-Reply-To: <56E1E2A5.1020008@oracle.com> References: <3969befd-57cd-48ee-bed5-173a28e7bd08@default> <56DFFC9F.4020403@oracle.com> <70f247c0-6f3e-472a-b7b0-b02814010e30@default> <56E16D0A.3060807@oracle.com> <56E1E2A5.1020008@oracle.com> Message-ID: Hi, Thanks Sergey and Jim for suggestions. I have made the data specific Raster constructors type safe now. Also, I have modified all Raster creations in Raster.java to support custom DataBuffer classes. Please review the changes present in updated webrev : http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.02/ Regards, Ajit -----Original Message----- From: Jim Graham Sent: Friday, March 11, 2016 2:40 AM To: Sergey Bylokhov; Ajit Ghaisas; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception Yes, those constructors should be type-safe. Perhaps that was done to save code in the caller, but that is a small price to pay to avoid errors in the future, and it makes sure there is a backup plan for different kinds of buffers... ...jim On 3/10/16 4:48 AM, Sergey Bylokhov wrote: > Hi, Ajit. > What about other cases in Raster.java, where the DataBuffer is passed > as a parameter? Probably we can simplify the code and find all such > issues if we changes the ByteInterleavedRaster/etc. For example: > > ByteInterleavedRaster(SampleModel sampleModel,DataBuffer > dataBuffer,...) to > > ByteInterleavedRaster(SampleModel sampleModel,DataBufferByte > dataBuffer,...) > > Because we throw an exception in such cases anyway: > > if (!(dataBuffer instanceof DataBufferByte)) { > throw new RasterFormatException("ByteInterleavedRasters must have " > + "byte DataBuffers"); > } > > And the compiler will help us, what everybody think about it? > > On 09.03.16 17:38, Ajit Ghaisas wrote: >> Hi, >> >> Modified the test and added check for MultiPixelPackedSampleModel >> condition. >> >> Please review updated webrev : >> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.01/ >> >> Regards, >> Ajit >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Wednesday, March 09, 2016 4:06 PM >> To: Ajit Ghaisas; awt-dev at openjdk.java.net; Semyon Sadetsky; Ambarish >> Rapte; 2d-dev >> Subject: Re: [9] Review-request for 6353518: Creation of a >> WritableRaster with a custom DataBuffer causes erroneous Exception >> >> Changes for 2d area.(cc) >> >> >> On 07.03.16 11:20, Ajit Ghaisas wrote: >>> Hi, >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-6353518 >>> >>> Issue : (Text from bug description) >>> >>> An attempt to create a WritableRaster via >>> Raster.createWritableRaster(SampleModel sm, DataBuffer db, Point >>> location) using a custom DataBuffer causes an erroneous >>> RasterFormatException. >>> Apparently the reason for this bug is that IntegerComponentRaster >>> insists on being passed an instance of DataBufferInt rather than >>> just a DataBuffer with a DataType of TYPE_INT. >>> This is quite annoying since DataBufferInt is declared final and >>> thus cannot be extended. >>> >>> Fix : >>> >>> The last line of Raster.createWritableRaster() method already has a >>> way to handle generic case if the input does not match any of the >>> cases in switch statements in that method. >>> >>> The fact that " *InterleavedRaster() constructors throw exception >>> if DataBuffer passed to them does not match the expected type" was >>> ignored earlier. >>> >>> This fix adds a check of "DataBuffer type" before creating >>> respective >>> *InterleavedRaster() objects. >>> >>> It constructs the SunWritableRaster in case DataBuffer type does not >>> match any data specific DataBuffer classes (DataBufferByte, >>> DataBufferUShort, DataBufferInt) >>> >>> Request to review webrev containing this fix : >>> >>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.00/ >>> >>> Regards, >>> >>> Ajit >>> >> >> >> -- >> Best regards, Sergey. >> > > From Sergey.Bylokhov at oracle.com Tue Mar 15 14:06:33 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 15 Mar 2016 17:06:33 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8151303 [macosx] [hidpi] JButton's low-res. icon is visible when clicking on it In-Reply-To: <56E815C3.40208@oracle.com> References: <56E01777.1030202@oracle.com> <56E01DE7.9040103@oracle.com> <56E2CB4F.6040301@oracle.com> <56E3277B.3000309@oracle.com> <56E815C3.40208@oracle.com> Message-ID: <56E816E9.1010308@oracle.com> On 15.03.16 17:01, Alexander Scherbatiy wrote: > One update will be that FilteredImageSource should implement > MultiResolutionImageProducer even it is used for non multi-resolution > images. > > The MRI can be created using two general ways: using fixed number of > resolution variants or generating a resolution variant with necessary > quality on demand. > > The current implementation is rely on that MRToolkitImage contains a > fixed number of resolution variants. In this case MediaTracker can > iterate over resolution variants and load them all. > > Using MultiResolutionImageProducer leads that MRToolkitImage will not > know about number of resolution variants in case when they are generated > on the fly and there will be no way to load all of them by MediaTracker. Just an idea to thinking about, can we save this filter to the MRI itself and apply it after some resolution variant will be created on the fly? > > As I see, the way to solve it is only using MRI.getResolutionVariants() > method for the MultiResolutionImageProducer creation. So the result of > the call > toolkit.createImage(new FilteredImageSource(mrImage.getSource(), > filter)); > will be a MRToolkitImage which is based on fixed number of filtered > resolution variants from the original MRI. > > Thanks, > Alexandr. > >> ...jim >> >> On 3/11/16 5:42 AM, Alexander Scherbatiy wrote: >>> On 09/03/16 16:58, Sergey Bylokhov wrote: >>>> Probably we should enhance ImageProducer/Tk.createImage/ImageFilter to >>>> support this functionality? It seems that the number of usage of this >>>> check "image instanceof MultiResolutionImage" will grow over time. >>> ImageProducer produces pixels for an image and is not able to take >>> an information about the image resolution variants. >>> >>> May be we can add Toolkit.createImage(Image image, ImageFilter >>> imageFilter) method which takes MultiResolutionImage into account to >>> cover the common case where filtered image is created. >>> >>> Thanks, >>> Alexandr. >>>> I think that at least our own API should support MultiResolutionImage >>>> w/o such checks, otherwise the user will need to do the same. >>>> >>>> cc 2d-dev >>>> >>>> On 09.03.16 15:30, Alexander Scherbatiy wrote: >>>>> >>>>> Hello, >>>>> >>>>> Could you review the fix: >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8151303 >>>>> webrev: http://cr.openjdk.java.net/~alexsch/8151303/webrev.00 >>>>> >>>>> The AquaUtils does not take into account MultiResolutionImage for >>>>> selected/disabled/lightened images generation. >>>>> The fix also leaves the MultiResolutionCachedImage check because >>>>> the >>>>> base system icon size can be differ from the requested painted size. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>> >>>> >>> > -- Best regards, Sergey. From alexander.v.stepanov at oracle.com Tue Mar 15 16:12:15 2016 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Tue, 15 Mar 2016 19:12:15 +0300 Subject: [OpenJDK 2D-Dev] RFR 8149558: [TEST] add regression test for JDK-8150154 In-Reply-To: <56D07546.4010906@oracle.com> References: <56BDB583.5020806@oracle.com> <56CF1B0A.2030603@oracle.com> <56D069FB.4050503@oracle.com> <56D07546.4010906@oracle.com> Message-ID: <56E8345F.4040006@oracle.com> Please see the updated fix: http://cr.openjdk.java.net/~avstepan/8149558/webrev.01/ Thanks, Alexander On 2/26/2016 6:54 PM, Alexander Stepanov wrote: > > Should we also test bmp and jpg? > > couldn't use writer for these formats "as is" (simply > "writer.write(img)") - this causes IOExceptions. JPEGImageWriteParam > or BMPImageWriteParam should be used and another signature for write() > method. Extended test logic looks quite bulky with all this additions. > > > but you do not check that the saved information actually relates to > the particular image (all of them have a white color and same size) > > even in this case we have color check failure for pair > (TYPE_USHORT_565_RGB, TYPE_USHORT_555_RGB). but yes, probably it is > better to use different images for the 1st and 2nd write attempts. > > Thanks, > Alexander > > On 2/26/2016 6:06 PM, Sergey Bylokhov wrote: >> Should we also test bmp and jpg? You tested a different BI formats, >> but you do not check that the saved information actually relates to >> the particular image(all of them have a white color and same size). >> So you will not notice if the Writer will write the same(first) image >> in all subsequent calls. >> >> On 25.02.16 18:17, Alexander Stepanov wrote: >>> Sorry, just a reminder. >>> >>> Thanks, >>> Alexander >>> >>> On 2/12/2016 1:35 PM, Alexander Stepanov wrote: >>>> Hello, >>>> >>>> Could you please review the following fix >>>> http://cr.openjdk.java.net/~avstepan/8149558/webrev.00/ >>>> for >>>> https://bugs.openjdk.java.net/browse/JDK-8149558 >>>> >>>> Just a single regression test added (still failing), plus minor >>>> correction for other test. >>>> >>>> Thanks, >>>> Alexander >>>> >>> >> >> > From alexandr.scherbatiy at oracle.com Tue Mar 15 16:35:40 2016 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 15 Mar 2016 20:35:40 +0400 Subject: [OpenJDK 2D-Dev] [9] Review request for 8151303 [macosx] [hidpi] JButton's low-res. icon is visible when clicking on it In-Reply-To: <56E816E9.1010308@oracle.com> References: <56E01777.1030202@oracle.com> <56E01DE7.9040103@oracle.com> <56E2CB4F.6040301@oracle.com> <56E3277B.3000309@oracle.com> <56E815C3.40208@oracle.com> <56E816E9.1010308@oracle.com> Message-ID: <56E839DC.2040904@oracle.com> On 15/03/16 18:06, Sergey Bylokhov wrote: > On 15.03.16 17:01, Alexander Scherbatiy wrote: > >> One update will be that FilteredImageSource should implement >> MultiResolutionImageProducer even it is used for non multi-resolution >> images. >> >> The MRI can be created using two general ways: using fixed number of >> resolution variants or generating a resolution variant with necessary >> quality on demand. >> >> The current implementation is rely on that MRToolkitImage contains a >> fixed number of resolution variants. In this case MediaTracker can >> iterate over resolution variants and load them all. >> >> Using MultiResolutionImageProducer leads that MRToolkitImage will not >> know about number of resolution variants in case when they are generated >> on the fly and there will be no way to load all of them by MediaTracker. > > Just an idea to thinking about, can we save this filter to the MRI > itself and apply it after some resolution variant will be created on > the fly? Do you mean that it helps to leave the code in the AquaUtils class unchanged: --------------- 124 static Image generateLightenedImage(final Image image, final int percent) { 125 final GrayFilter filter = new GrayFilter(true, percent); 126 final ImageProducer prod = new FilteredImageSource(image.getSource(), filter); 127 return Toolkit.getDefaultToolkit().createImage(prod); 128 } --------------- or it is just an a better way for a filtered multi-resolution image generation? Thanks, Alexandr. > >> >> As I see, the way to solve it is only using MRI.getResolutionVariants() >> method for the MultiResolutionImageProducer creation. So the result of >> the call >> toolkit.createImage(new FilteredImageSource(mrImage.getSource(), >> filter)); >> will be a MRToolkitImage which is based on fixed number of filtered >> resolution variants from the original MRI. >> >> Thanks, >> Alexandr. >> >>> ...jim >>> >>> On 3/11/16 5:42 AM, Alexander Scherbatiy wrote: >>>> On 09/03/16 16:58, Sergey Bylokhov wrote: >>>>> Probably we should enhance >>>>> ImageProducer/Tk.createImage/ImageFilter to >>>>> support this functionality? It seems that the number of usage of this >>>>> check "image instanceof MultiResolutionImage" will grow over time. >>>> ImageProducer produces pixels for an image and is not able to take >>>> an information about the image resolution variants. >>>> >>>> May be we can add Toolkit.createImage(Image image, ImageFilter >>>> imageFilter) method which takes MultiResolutionImage into account to >>>> cover the common case where filtered image is created. >>>> >>>> Thanks, >>>> Alexandr. >>>>> I think that at least our own API should support MultiResolutionImage >>>>> w/o such checks, otherwise the user will need to do the same. >>>>> >>>>> cc 2d-dev >>>>> >>>>> On 09.03.16 15:30, Alexander Scherbatiy wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Could you review the fix: >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8151303 >>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8151303/webrev.00 >>>>>> >>>>>> The AquaUtils does not take into account MultiResolutionImage for >>>>>> selected/disabled/lightened images generation. >>>>>> The fix also leaves the MultiResolutionCachedImage check because >>>>>> the >>>>>> base system icon size can be differ from the requested painted size. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>> >>>>> >>>> >> > > From philip.race at oracle.com Tue Mar 15 22:14:45 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 15 Mar 2016 15:14:45 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8066139, , Null return from PrintJob.getGraphics() running closed/java/awt/PrintJob/HighResTest/HighResTest.java In-Reply-To: <56E14DB0.8030506@oracle.com> References: <56C6DDF1.1020009@oracle.com> <56C764B3.9020005@oracle.com> <56C77A50.7010605@oracle.com> <56CAAAC8.40009@oracle.com> <56CAC14F.4030602@oracle.com> <56D579B1.7090204@oracle.com> <56DDE8F2.3000707@oracle.com> <56DEA9B2.8020702@oracle.com> <56DEFA8E.3080203@oracle.com> <56E14DB0.8030506@oracle.com> Message-ID: <56E88955.80006@oracle.com> On 03/10/2016 02:34 AM, prasanta sadhukhan wrote: > Hi Phil, > > Please find the modified webrev > http://cr.openjdk.java.net/~psadhukhan/8066139/webrev.02/ +1 > > I tested in Mac too but there it seems to be working (ie no NPE) > without and with this fix. > The mac code is sufficiently different that it is not a surprise that it behaves differently. > For issue seen on windows , I have raised a bug JDK-8151589 > (strangely it is > not seen in jdk1.8.0_76 but seen from 1.9.0-ea-b01 onwards, can you > tell me what is the release version before b01?] That suggests a bug introduced before 8GA, fixed in an 8-update, but not in 9. But I find that a bit unlikely and I don't want to speculate more. It just needs investigation. -phil. > > Regards > Prasanta > On 3/8/2016 9:45 PM, Philip Race wrote: >> > However, I am finding a strange issue with and without this fix >> too. The "Center" string is not printed >> >> Sounds completely unrelated to anything to do with the NPE bug. >> >> It is probably appropriate to file that as a separate bug. >> No big surprise that the behaviour is platform-specific as there >> is a lot of difference in Windows vs Linux (or vs Mac) in the >> printing code. >> >> -phil. >> >> On 3/8/16, 2:30 AM, prasanta sadhukhan wrote: >>> >>> >>> On 3/8/2016 2:17 AM, Phil Race wrote: >>>> I don't think starting a new thread can be right. That would re-invoke >>>> printerJob.print() which even if you can reuse a PrinterJob >>>> (something that >>>> was never set out in spec.) you are surely getting a new spool job >>>> .. not >>>> a continuation. There a couple of other things I am not sure about >>>> either. >>>> >>>> I've looked into this - only on Linux - and I believe the issue is that >>>> the test program has decided up-front how many pages it is going to >>>> print and it is paying no attention to the selected page ranges. >>>> Not what the 'user' asked for but it is perfectly within its rights >>>> to do so. >>>> >>>> However the 2D PrinterJob operates in a way where it calls back >>>> asking for the specific pages it wants to be printed and there the >>>> app. must comply. The PrinterJob terminates once it has done. >>>> >>>> In the case when the 2D PrinterJob is being used to 'run' a >>>> PrintJob then it must *never* return until the application has >>>> called "end" - or some exception occurs. >>>> >>>> So we need to remove the elements that will cause the job to exit. >>>> >>>> --- a/src/java.desktop/share/classes/sun/print/PrintJob2D.java >>>> +++ b/src/java.desktop/share/classes/sun/print/PrintJob2D.java >>>> @@ -995,6 +995,7 @@ >>>> public void run() { >>>> >>>> try { >>>> + attributes.remove(PageRanges.class); >>>> printerJob.print(attributes); >>>> } catch (PrinterException e) { >>>> //REMIND: need to store this away and not rethrow it. >>>> diff --git >>>> a/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java >>>> b/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java >>>> --- a/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java >>>> +++ b/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java >>>> @@ -1172,6 +1172,7 @@ >>>> pageRangesAttr = (PageRanges)attributes.get(PageRanges.class); >>>> if (!isSupportedValue(pageRangesAttr, attributes)) { >>>> pageRangesAttr = null; >>>> + setPageRange(-1, -1); >>>> } else { >>>> if >>>> ((SunPageSelection)attributes.get(SunPageSelection.class) >>>> == SunPageSelection.RANGE) { >>>> >>>> >>>> This works for me on Linux although >>>> a) I have not tried Windows) >>> I tried on windows. The NPE is not seen and it prints 2 pages. >>> However, I am finding a strange issue with and without this fix too. >>> The "Center" string is not printed in the 1st page in both >>> "Portrait" and "Landscape" mode (although the rectangles are >>> printed) but is printed in the 2nd page. >>> I do not find this issue in linux. >>> >>> Regards >>> Prasanta >>>> b) I have not verified if there are no negative consequences from >>>> the 2nd change. >>>> >>>> -phil. >>>> >>>> On 03/01/2016 03:14 AM, prasanta sadhukhan wrote: >>>>> Hi Phil, >>>>> >>>>> Please find an updated webrev: >>>>> http://cr.openjdk.java.net/~psadhukhan/8066139/webrev.01/ >>>>> >>>>> It seems if printerJobThread finished printing, it will set >>>>> graphicsToBeDrawn/graphicsDrawn ArrayList to null resulting in >>>>> getGraphics() returning null in the 2nd iteration causing NPE so >>>>> I have modified printerJobThread#run so that when it has finished >>>>> printing, do not set the arrayList to null but set a flag. In >>>>> getGraphics(), I check that flag and start a new printerJobThread >>>>> to handle the next printing. >>>>> I have tested "All" and "Pages" selection. >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 2/22/2016 1:35 PM, Philip Race wrote: >>>>>> > It seems this behaviour is same in linux too for this >>>>>> HighResTest testcase. >>>>>> >>>>>> OK that is good information .. so is not really a regression from >>>>>> 8061267 as >>>>>> that is not in >>>>>> any way touching linux .. it is a pre-existing issue in a code >>>>>> path that was not being tested. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 2/22/16, 11:59 AM, prasanta sadhukhan wrote: >>>>>>> Hi Phil, >>>>>>> >>>>>>> >>Additionally, have you tried running the original test case >>>>>>> provided with 8061267 >>>>>>> >> against your fix ? >>>>>>> The 8061267 testcase behaves similarly before and after my fix. >>>>>>> >>>>>>> >> If I manually select it, (ie select that "Pages" radio >>>>>>> button) then press print, >>>>>>> >> then voila, the NPE is back! >>>>>>> It seems this behaviour is same in linux too for this >>>>>>> HighResTest testcase. >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>> On 2/20/2016 1:55 AM, Phil Race wrote: >>>>>>>> I am having trouble building JDK 9 at the moment so i applied >>>>>>>> 8061267 to jdk8u-dev >>>>>>>> and was able to reproduce the regression and have a couple of >>>>>>>> observations >>>>>>>> >>>>>>>> - I am now seeing the NPE after the first page as you did .. >>>>>>>> puzzling. >>>>>>>> - I next applied your fix but still see the NPE ! >>>>>>>> >>>>>>>> It appears that all your fix did is stop the "PD_PAGENUMS" >>>>>>>> flag being automatically >>>>>>>> set. If I manually select it, (ie select that "Pages" radio >>>>>>>> button) then press print, >>>>>>>> then voila, the NPE is back! >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> >>>>>>>> On 02/19/2016 10:53 AM, Phil Race wrote: >>>>>>>>> I am not sure I can be correctly understanding the fix as the >>>>>>>>> ramification seems >>>>>>>>> to be that if the users wants to print only Page 3 of a 10 >>>>>>>>> page document and so sets >>>>>>>>> from page=3 and to page=3, that this request will be ignored >>>>>>>>> and all pages will >>>>>>>>> be printed .. can you test such a scenario. >>>>>>>>> >>>>>>>>> Additionally, have you tried running the original test case >>>>>>>>> provided with 8061267 >>>>>>>>> against your fix ? >>>>>>>>> >>>>>>>>> Also when I ran the HighResTest on a current build I saw a >>>>>>>>> null graphics on >>>>>>>>> the very first call to getGraphics() which is different than >>>>>>>>> what I interpret >>>>>>>>> you as saying - you see the null *after* the first page is >>>>>>>>> printed. >>>>>>>>> >>>>>>>>> -phil. >>>>>>>>> >>>>>>>>> On 02/19/2016 01:18 AM, prasanta sadhukhan wrote: >>>>>>>>>> Hi Phil, All, >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066139 >>>>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8066139/webrev.00/ >>>>>>>>>> >>>>>>>>>> It was seen after fix of JDK-8061267 >>>>>>>>>> : >>>>>>>>>> PrinterJob: Specified Page Ranges not displayed in Windows >>>>>>>>>> Native Print Dialog >>>>>>>>>> the closed/java/awt/PrintJob/HighResTest/HighResTest.java was >>>>>>>>>> failing with NPE when PrinterJob.getGraphics() is called the >>>>>>>>>> 2nd time before calling PrinterJob.end(). >>>>>>>>>> >>>>>>>>>> The above fix caused this regression because it sets the >>>>>>>>>> PD_PAGENUMS flag for windows PrintDlg struct which causes >>>>>>>>>> *Pages* radio button to be selected in print dialog. >>>>>>>>>> However, fromPage and toPage was both set to 1 so after the >>>>>>>>>> 1st page is printed, RasterPrinterJob.print(attributes) >>>>>>>>>> finishes and graphicsToBeDrawn.closeWhenEmpty() gets called >>>>>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/d8def65c6c00/src/java.desktop/share/classes/sun/print/PrintJob2D.java#l1006 >>>>>>>>>> >>>>>>>>>> which sets the queue to null so when >>>>>>>>>> PrinterJob2D#getGraphics() calls graphicsToBeDrawn.pop() it >>>>>>>>>> sees queue to be null and sets graphics object to be null so >>>>>>>>>> PrinterJob.getGraphics() gets null and g.drawLine in testcase >>>>>>>>>> causes NPE since g is null. >>>>>>>>>> >>>>>>>>>> Fix was done to set the PD_PAGENUMS flag only when toPage is >>>>>>>>>> more than fromPage in which case, "All" will be selected in >>>>>>>>>> printer dialog and RasterPrinterJob.print() will finish only >>>>>>>>>> after printing all the pages. >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Prasanta >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Tue Mar 15 22:45:22 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 15 Mar 2016 15:45:22 -0700 Subject: [OpenJDK 2D-Dev] RFR 8144938: Handle properly coordinate overflow in Marlin Renderer In-Reply-To: References: <56E2159E.8000209@oracle.com> <56E22734.7020707@oracle.com> <56E33249.2030300@oracle.com> <56E74A98.30503@oracle.com> Message-ID: <56E89082.5040703@oracle.com> The new tests look good. There is one logic error in the new version of the degenerate coordinate filter. It is valid to have a PATH_CLOSE immediately followed by a To call and the subpath will start at the previous close/moveto point. For example: moveto 40, 40 lineto 0, 0 lineto 80, 0 closepath lineto 80, 80 lineto 0, 80 closepath should draw an hourglass, but with your fix it will lose the lower half because the lineto after the close will be turned into a moveto (and the second subpath then becomes empty. I think it should be fine just getting rid of the subpath=false in the close case. It is arguable, though, if we have closepath followed by a NaN if perhaps that NaN should break the subpath from the previous close, but I don't think that is in keeping with the current philosophy of simply pretending that bad coordinates don't exist. Essentially, the close of a previously valid path gives us a valid start to the new subpath regardless if it immediately feeds into more bad coordinates - it still started its run on a valid point. So, I'd argue that simply passing along the prior value of the subpath flag would be appropriate, whether it is true or false (and, obviously, also closing the path in the consumer if it is true)... ...jim On 3/15/2016 6:46 AM, Laurent Bourg?s wrote: > Dear Jim, > > Here is a new webrev: > http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144938.2/ > > Changes: > - pathToLoop() rewritten to simplify the logic (skip and pathClosed > flags removed) > - added several createStrokedShape() tests in CrashNaNTest class > > I hope my changes to the filtering algorithm are correct: > I advocate not understanding why it was so complicated (3 flags => 1) > but maybe I am wrong and I missed several corner cases... > > > My comments below: > > 2016-03-15 0:34 GMT+01:00 Jim Graham >: > > Hi Laurent, > > Did you consider adding a test with a completely degenerate path to > make sure that we don't have any state errors if all of the segments > are eaten by the "finite path" filter? > > > Fixed and it produces empty paths (only pathDone): > > I wonder if it is time to remove the following lines 317-322 in > MarlinRenderingEngine.strokeTo(): > // Every path needs an initial moveTo and a pathDone. > If these > // are not there this causes a SIGSEGV in libawt.so (at > the time > // of writing of this comment (September 16, 2010)). > Actually, > // I am not sure if the moveTo is necessary to avoid > the SIGSEGV > // but the pathDone is definitely needed. > pc2d.moveTo(0f, 0f); > > For me, it is useless as only pc2d.pathDone() is mandatory. > > > I like your approach. It is worth noting that: > > - non-uniform scales are not common > - your "always overflow-filter path at device resolution" fixes the > issues with measuring overflow in user space that I pointed out in > my prior email and only does so at a likely small expense in terms > of non-uniform scale performance. Common cases will see no change > (other than the fact that you have new code in the path feeder). > > > Thanks. > It has an important consequence for me: > it's possible to introduce a new stage in the pipeline (before > inverseDeltaTransformConsumer) that implements path clipping in > device-space ONLY compatible with the rectangular bounding box. > > > With respect to the optimization that I gave a rough outline of. It > is true that: > > - it should help eliminate all of the inverse transforms in the > strokeTo code > - the math is incomplete and would need some work > - it only targets the non-uniform case which may not be a high priority > - it would probably get rid of the entire TransformingPathConsumer > module, but that module is not complex or trouble-prone and seems to > be working fine > > > I totally agree. > > I think improving Marlin's Stroker to better optimize square caps / > mitter joins or adding path clipping would provide more benefits as it > would minimize the number of point / edges used later by the Renderer stage. > > Thanks for your comments, > Laurent From jayathirth.d.v at oracle.com Wed Mar 16 05:50:56 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 15 Mar 2016 22:50:56 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream Message-ID: <99cb1549-30b5-44af-b399-ebed22255cf8@default> Hi Phil,All Please review the following fix in JDK9: Bug : https://bugs.openjdk.java.net/browse/JDK-8044289 Webrev : http://cr.openjdk.java.net/~jdv/8044289/webrev.00/ Issue : When createImageInputStream() or createImageOutputStream returns null in ImageIO.read() or ImageIO.write() we are seeing NPE as it stream is used further without null check. Root cause : "stream" is used without checking whether it is null or not. Solution : Handle null pointer of stream and throw IIOException. Test case contains all possible scenarios where createImageInputStream() or createImageOutputStream can return null. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Wed Mar 16 06:33:26 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Wed, 16 Mar 2016 12:03:26 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8151110, , libfontmanager should free memory with delete[] if it was allocated with new[] Message-ID: <56E8FE36.3090406@oracle.com> Hi Phil, Please review a small fix for bug: https://bugs.openjdk.java.net/browse/JDK-8151110 webrev: http://cr.openjdk.java.net/~psadhukhan/8151110/webrev.00/ where the issue was found that the allocation of memory was done through new operator but free was done through free(). Since they operate on different heaps and can pose problem if the code was to be run on new machine/compiler it's better to allocate through calloc for free() to delete memory correctly. noreg-cleanup is added for this bug. Regards Prasanta From jayathirth.d.v at oracle.com Wed Mar 16 07:28:00 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 16 Mar 2016 00:28:00 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8066139, , Null return from PrintJob.getGraphics() running closed/java/awt/PrintJob/HighResTest/HighResTest.java In-Reply-To: <56E88955.80006@oracle.com> References: <56C6DDF1.1020009@oracle.com> <56C764B3.9020005@oracle.com> <56C77A50.7010605@oracle.com> <56CAAAC8.40009@oracle.com> <56CAC14F.4030602@oracle.com> <56D579B1.7090204@oracle.com> <56DDE8F2.3000707@oracle.com> <56DEA9B2.8020702@oracle.com> <56DEFA8E.3080203@oracle.com> <56E14DB0.8030506@oracle.com> <56E88955.80006@oracle.com> Message-ID: HI Prasanta, ? Changes are fine. Both the print dialogs are coming and there is no NPE. In test case please change copyright year to 2016 and also it is better to have jtreg comments before import statements for readability. ? Thanks, Jay ? From: Phil Race Sent: Wednesday, March 16, 2016 3:45 AM To: prasanta sadhukhan Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9] RFR: JDK-8066139, , Null return from PrintJob.getGraphics() running closed/java/awt/PrintJob/HighResTest/HighResTest.java ? On 03/10/2016 02:34 AM, prasanta sadhukhan wrote: Hi Phil, Please find the modified webrev HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/8066139/webrev.02/"http://cr.openjdk.java.net/~psadhukhan/8066139/webrev.02/ +1 I tested in Mac too but there it seems to be working (ie no NPE) without and with this fix. The mac code is sufficiently different that it is not a surprise that it behaves differently. For issue seen on windows , I have raised a bug HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8151589"JDK-8151589 (strangely it is not seen in jdk1.8.0_76 but seen from? 1.9.0-ea-b01 onwards, can you tell me what is the release version before b01?] That suggests a bug introduced before 8GA, fixed in an 8-update, but not in 9. But I find that a bit unlikely and I don't want to speculate more. It just needs investigation. -phil. Regards Prasanta On 3/8/2016 9:45 PM, Philip Race wrote: > However, I am finding a strange issue with and without this fix too. The "Center" string is not printed Sounds completely unrelated to anything to do with the NPE bug. It is probably appropriate to file that as a separate bug. No big surprise that the behaviour is platform-specific as there is a lot of difference in Windows vs Linux (or vs Mac) in the printing code. -phil. On 3/8/16, 2:30 AM, prasanta sadhukhan wrote: ? On 3/8/2016 2:17 AM, Phil Race wrote: I don't think starting a new thread can be right. That would re-invoke printerJob.print() which even if you can reuse a PrinterJob (something that was never set out in spec.) you are surely getting a new spool job .. not a continuation. There a couple of other things I am not sure about either. I've looked into this - only on Linux - and I believe the issue is that the test program has decided up-front how many pages it is going to print and it is paying no attention to the selected page ranges. Not what the 'user' asked for but it is perfectly within its rights to do so. However the 2D PrinterJob operates in a way where it calls back asking for the specific pages it wants to be printed and there the app. must comply. The PrinterJob terminates once it has done. In the case when the 2D PrinterJob is being used to 'run' a PrintJob then it must *never* return until the application has called "end" - or some exception occurs. So we need to remove the elements that will cause the job to exit. --- a/src/java.desktop/share/classes/sun/print/PrintJob2D.java +++ b/src/java.desktop/share/classes/sun/print/PrintJob2D.java @@ -995,6 +995,7 @@ ???? public void run() { ? ???????? try { +??????????? attributes.remove(PageRanges.class); ???????????? printerJob.print(attributes); ???????? } catch (PrinterException e) { ???????????? //REMIND: need to store this away and not rethrow it. diff --git a/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java b/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java --- a/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java +++ b/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java @@ -1172,6 +1172,7 @@ ???????? pageRangesAttr =? (PageRanges)attributes.get(PageRanges.class); ???????? if (!isSupportedValue(pageRangesAttr, attributes)) { ???????????? pageRangesAttr = null; +??????????? setPageRange(-1, -1); ???????? } else { ???????????? if ((SunPageSelection)attributes.get(SunPageSelection.class) ????????????????????? == SunPageSelection.RANGE) { This works for me on Linux although a) I have not tried Windows) I tried on windows. The NPE is not seen and it prints 2 pages. However, I am finding a strange issue with and without this fix too. The "Center" string is not printed in the 1st page in both "Portrait" and "Landscape" mode (although the rectangles are printed) but is printed in the 2nd page. I do not find this issue in linux. Regards Prasanta b) I have not verified if there are no negative consequences from the 2nd change. -phil. On 03/01/2016 03:14 AM, prasanta sadhukhan wrote: Hi Phil, Please find an updated webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/8066139/webrev.01/"http://cr.openjdk.java.net/~psadhukhan/8066139/webrev.01/ It seems if printerJobThread finished printing, it will set graphicsToBeDrawn/graphicsDrawn ArrayList to null resulting in getGraphics() returning null in the 2nd iteration causing NPE so ?I have modified printerJobThread#run so that when it has finished printing, do not set the arrayList to null but set a flag. In getGraphics(), I check that flag and start a new printerJobThread to handle the next printing. I have tested "All" and "Pages" selection. Regards Prasanta On 2/22/2016 1:35 PM, Philip Race wrote: > It seems this behaviour is same in linux too for this HighResTest testcase. OK that is good information .. so is not really a regression from HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8061267"8061267 as that is not in any way touching linux .. it is a pre-existing issue in a code path that was not being tested. -phil. On 2/22/16, 11:59 AM, prasanta sadhukhan wrote: Hi Phil, >>Additionally, have you tried running the original test case provided with 8061267 >> against your fix ? The 8061267 testcase behaves similarly before and after my fix. >> If I manually select it, (ie select that "Pages" radio button) then press print, >> then voila, the NPE is back! It seems this behaviour is same in linux too for this HighResTest testcase. Regards Prasanta On 2/20/2016 1:55 AM, Phil Race wrote: I am having trouble building JDK 9 at the moment so i applied 8061267 to jdk8u-dev and was able to reproduce the regression and have a couple of observations - I am now seeing the NPE after the first page as you did .. puzzling. - I next applied your fix but still see the NPE ! It appears that all your fix did is stop the "PD_PAGENUMS"? flag being automatically set. If I manually select it, (ie select that "Pages" radio button) then press print, then voila, the NPE is back! -phil. On 02/19/2016 10:53 AM, Phil Race wrote: I am not sure I can be correctly understanding the fix as the ramification seems to be that if the users wants to print only Page 3 of a 10 page document and so sets from page=3 and to page=3, that this request will be ignored and all pages will be printed .. can you test such a scenario. Additionally, have you tried running the original test case provided with 8061267 against your fix ? Also when I ran the HighResTest on a current build I saw a null graphics on the very first call to getGraphics() which is different than what I interpret you as saying - you see the null *after* the first page is printed. -phil. On 02/19/2016 01:18 AM, prasanta sadhukhan wrote: Hi Phil, All, Bug: https://bugs.openjdk.java.net/browse/JDK-8066139 webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/8066139/webrev.00/"http://cr.openjdk.java.net/~psadhukhan/8066139/webrev.00/ It was seen after fix of HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8061267"JDK-8061267: PrinterJob: Specified Page Ranges not displayed in Windows Native Print Dialog the closed/java/awt/PrintJob/HighResTest/HighResTest.java was failing with NPE when PrinterJob.getGraphics() is called the 2nd time before calling PrinterJob.end(). The above fix caused this regression because it sets the PD_PAGENUMS flag for windows PrintDlg struct which causes Pages radio button to be selected in print dialog. However, fromPage and toPage was both set to 1 so after the 1st page is printed, RasterPrinterJob.print(attributes) finishes and graphicsToBeDrawn.closeWhenEmpty() gets called http://hg.openjdk.java.net/jdk9/client/jdk/file/d8def65c6c00/src/java.desktop/share/classes/sun/print/PrintJob2D.java#l1006 which sets the queue to null so when PrinterJob2D#getGraphics() calls graphicsToBeDrawn.pop() it sees queue to be null and sets graphics object to be null so PrinterJob.getGraphics() gets null and g.drawLine in testcase causes NPE since g is null. Fix was done to set the PD_PAGENUMS flag only when toPage is more than fromPage in which case, "All" will be selected in printer dialog and RasterPrinterJob.print() will finish only after printing all the pages. Regards Prasanta ? ? ? ? ? ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Wed Mar 16 08:46:56 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Wed, 16 Mar 2016 14:16:56 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8066139, , Null return from PrintJob.getGraphics() running closed/java/awt/PrintJob/HighResTest/HighResTest.java In-Reply-To: References: <56C6DDF1.1020009@oracle.com> <56C764B3.9020005@oracle.com> <56C77A50.7010605@oracle.com> <56CAAAC8.40009@oracle.com> <56CAC14F.4030602@oracle.com> <56D579B1.7090204@oracle.com> <56DDE8F2.3000707@oracle.com> <56DEA9B2.8020702@oracle.com> <56DEFA8E.3080203@oracle.com> <56E14DB0.8030506@oracle.com> <56E88955.80006@oracle.com> Message-ID: <56E91D80.10203@oracle.com> Hi Jay, Updated testcase http://cr.openjdk.java.net/~psadhukhan/8066139/webrev.03/ Regards Prasanta On 3/16/2016 12:58 PM, Jayathirth D V wrote: > > HI Prasanta, > > Changes are fine. Both the print dialogs are coming and there is no NPE. > > In test case please change copyright year to 2016 and also it is > better to have jtreg comments before import statements for readability. > > Thanks, > > Jay > > *From:*Phil Race > *Sent:* Wednesday, March 16, 2016 3:45 AM > *To:* prasanta sadhukhan > *Cc:* 2d-dev at openjdk.java.net > *Subject:* Re: [OpenJDK 2D-Dev] [9] RFR: JDK-8066139, , Null return > from PrintJob.getGraphics() running > closed/java/awt/PrintJob/HighResTest/HighResTest.java > > On 03/10/2016 02:34 AM, prasanta sadhukhan wrote: > > Hi Phil, > > Please find the modified webrev > http://cr.openjdk.java.net/~psadhukhan/8066139/webrev.02/ > > > > +1 > > > I tested in Mac too but there it seems to be working (ie no NPE) > without and with this fix. > > > The mac code is sufficiently different that it is not a surprise that > it behaves differently. > > > > For issue seen on windows , I have raised a bug JDK-8151589 > (strangely it > is not seen in jdk1.8.0_76 but seen from 1.9.0-ea-b01 onwards, > can you tell me what is the release version before b01?] > > > That suggests a bug introduced before 8GA, fixed in an 8-update, but > not in 9. > But I find that a bit unlikely and I don't want to speculate more. It > just needs investigation. > > -phil. > > > > Regards > Prasanta > > On 3/8/2016 9:45 PM, Philip Race wrote: > > > However, I am finding a strange issue with and without this > fix too. The "Center" string is not printed > > Sounds completely unrelated to anything to do with the NPE bug. > > It is probably appropriate to file that as a separate bug. > No big surprise that the behaviour is platform-specific as there > is a lot of difference in Windows vs Linux (or vs Mac) in the > printing code. > > -phil. > > On 3/8/16, 2:30 AM, prasanta sadhukhan wrote: > > On 3/8/2016 2:17 AM, Phil Race wrote: > > I don't think starting a new thread can be right. That > would re-invoke > printerJob.print() which even if you can reuse a > PrinterJob (something that > was never set out in spec.) you are surely getting a > new spool job .. not > a continuation. There a couple of other things I am > not sure about either. > > I've looked into this - only on Linux - and I believe > the issue is that > the test program has decided up-front how many pages > it is going to > print and it is paying no attention to the selected > page ranges. > Not what the 'user' asked for but it is perfectly > within its rights to do so. > > However the 2D PrinterJob operates in a way where it > calls back > asking for the specific pages it wants to be printed > and there the > app. must comply. The PrinterJob terminates once it > has done. > > In the case when the 2D PrinterJob is being used to > 'run' a > PrintJob then it must *never* return until the > application has > called "end" - or some exception occurs. > > So we need to remove the elements that will cause the > job to exit. > > --- > a/src/java.desktop/share/classes/sun/print/PrintJob2D.java > +++ > b/src/java.desktop/share/classes/sun/print/PrintJob2D.java > @@ -995,6 +995,7 @@ > public void run() { > > try { > + attributes.remove(PageRanges.class); > printerJob.print(attributes); > } catch (PrinterException e) { > //REMIND: need to store this away and not > rethrow it. > diff --git > a/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java > b/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java > --- > a/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java > +++ > b/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java > @@ -1172,6 +1172,7 @@ > pageRangesAttr = > (PageRanges)attributes.get(PageRanges.class); > if (!isSupportedValue(pageRangesAttr, > attributes)) { > pageRangesAttr = null; > + setPageRange(-1, -1); > } else { > if > ((SunPageSelection)attributes.get(SunPageSelection.class) > == SunPageSelection.RANGE) { > > > This works for me on Linux although > a) I have not tried Windows) > > I tried on windows. The NPE is not seen and it prints 2 pages. > However, I am finding a strange issue with and without > this fix too. The "Center" string is not printed in the > 1st page in both "Portrait" and "Landscape" mode (although > the rectangles are printed) but is printed in the 2nd page. > I do not find this issue in linux. > > Regards > Prasanta > > b) I have not verified if there are no negative > consequences from the 2nd change. > > -phil. > > On 03/01/2016 03:14 AM, prasanta sadhukhan wrote: > > Hi Phil, > > Please find an updated webrev: > http://cr.openjdk.java.net/~psadhukhan/8066139/webrev.01/ > > > It seems if printerJobThread finished printing, it > will set graphicsToBeDrawn/graphicsDrawn ArrayList > to null resulting in getGraphics() returning null > in the 2nd iteration causing NPE so > I have modified printerJobThread#run so that when > it has finished printing, do not set the arrayList > to null but set a flag. In getGraphics(), I check > that flag and start a new printerJobThread to > handle the next printing. > I have tested "All" and "Pages" selection. > > Regards > Prasanta > > On 2/22/2016 1:35 PM, Philip Race wrote: > > > It seems this behaviour is same in linux too > for this HighResTest testcase. > > OK that is good information .. so is not > really a regression from 8061267 > > as that is not in > any way touching linux .. it is a pre-existing > issue in a code path that was not being tested. > > -phil. > > On 2/22/16, 11:59 AM, prasanta sadhukhan wrote: > > Hi Phil, > > >>Additionally, have you tried running the > original test case provided with 8061267 > >> against your fix ? > The 8061267 testcase behaves similarly > before and after my fix. > > >> If I manually select it, (ie select > that "Pages" radio button) then press print, > >> then voila, the NPE is back! > It seems this behaviour is same in linux > too for this HighResTest testcase. > > Regards > Prasanta > > On 2/20/2016 1:55 AM, Phil Race wrote: > > I am having trouble building JDK 9 at > the moment so i applied 8061267 to > jdk8u-dev > and was able to reproduce the > regression and have a couple of > observations > > - I am now seeing the NPE after the > first page as you did .. puzzling. > - I next applied your fix but still > see the NPE ! > > It appears that all your fix did is > stop the "PD_PAGENUMS" flag being > automatically > set. If I manually select it, (ie > select that "Pages" radio button) then > press print, > then voila, the NPE is back! > > -phil. > > > On 02/19/2016 10:53 AM, Phil Race wrote: > > I am not sure I can be correctly > understanding the fix as the > ramification seems > to be that if the users wants to > print only Page 3 of a 10 page > document and so sets > from page=3 and to page=3, that > this request will be ignored and > all pages will > be printed .. can you test such a > scenario. > > Additionally, have you tried > running the original test case > provided with 8061267 > against your fix ? > > Also when I ran the HighResTest on > a current build I saw a null > graphics on > the very first call to > getGraphics() which is different > than what I interpret > you as saying - you see the null > *after* the first page is printed. > > -phil. > > On 02/19/2016 01:18 AM, prasanta > sadhukhan wrote: > > Hi Phil, All, > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8066139 > webrev: > http://cr.openjdk.java.net/~psadhukhan/8066139/webrev.00/ > > > It was seen after fix of > JDK-8061267 > : > PrinterJob: Specified Page > Ranges not displayed in > Windows Native Print Dialog > the > closed/java/awt/PrintJob/HighResTest/HighResTest.java > was failing with NPE when > PrinterJob.getGraphics() is > called the 2nd time before > calling PrinterJob.end(). > > The above fix caused this > regression because it sets the > PD_PAGENUMS flag for windows > PrintDlg struct which causes > *Pages* radio button to be > selected in print dialog. > However, fromPage and toPage > was both set to 1 so after the > 1st page is printed, > RasterPrinterJob.print(attributes) > finishes and > graphicsToBeDrawn.closeWhenEmpty() > gets called > http://hg.openjdk.java.net/jdk9/client/jdk/file/d8def65c6c00/src/java.desktop/share/classes/sun/print/PrintJob2D.java#l1006 > > which sets the queue to null > so when > PrinterJob2D#getGraphics() > calls graphicsToBeDrawn.pop() > it sees queue to be null and > sets graphics object to be null so > PrinterJob.getGraphics() gets > null and g.drawLine in > testcase causes NPE since g is > null. > > Fix was done to set the > PD_PAGENUMS flag only when > toPage is more than fromPage > in which case, "All" will be > selected in printer dialog and > RasterPrinterJob.print() will > finish only after printing all > the pages. > > Regards > Prasanta > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Wed Mar 16 08:51:23 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 16 Mar 2016 01:51:23 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8066139, , Null return from PrintJob.getGraphics() running closed/java/awt/PrintJob/HighResTest/HighResTest.java In-Reply-To: <56E91D80.10203@oracle.com> References: <56C6DDF1.1020009@oracle.com> <56C764B3.9020005@oracle.com> <56C77A50.7010605@oracle.com> <56CAAAC8.40009@oracle.com> <56CAC14F.4030602@oracle.com> <56D579B1.7090204@oracle.com> <56DDE8F2.3000707@oracle.com> <56DEA9B2.8020702@oracle.com> <56DEFA8E.3080203@oracle.com> <56E14DB0.8030506@oracle.com> <56E88955.80006@oracle.com> <56E91D80.10203@oracle.com> Message-ID: Looks good to go. ? Thanks, Jay ? From: prasanta sadhukhan Sent: Wednesday, March 16, 2016 2:17 PM To: Jayathirth D V Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9] RFR: JDK-8066139, , Null return from PrintJob.getGraphics() running closed/java/awt/PrintJob/HighResTest/HighResTest.java ? Hi Jay, Updated testcase http://cr.openjdk.java.net/~psadhukhan/8066139/webrev.03/ Regards Prasanta On 3/16/2016 12:58 PM, Jayathirth D V wrote: HI Prasanta, ? Changes are fine. Both the print dialogs are coming and there is no NPE. In test case please change copyright year to 2016 and also it is better to have jtreg comments before import statements for readability. ? Thanks, Jay ? From: Phil Race Sent: Wednesday, March 16, 2016 3:45 AM To: prasanta sadhukhan Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9] RFR: JDK-8066139, , Null return from PrintJob.getGraphics() running closed/java/awt/PrintJob/HighResTest/HighResTest.java ? On 03/10/2016 02:34 AM, prasanta sadhukhan wrote: Hi Phil, Please find the modified webrev HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/8066139/webrev.02/"http://cr.openjdk.java.net/~psadhukhan/8066139/webrev.02/ +1 I tested in Mac too but there it seems to be working (ie no NPE) without and with this fix. The mac code is sufficiently different that it is not a surprise that it behaves differently. For issue seen on windows , I have raised a bug HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8151589"JDK-8151589 (strangely it is not seen in jdk1.8.0_76 but seen from? 1.9.0-ea-b01 onwards, can you tell me what is the release version before b01?] That suggests a bug introduced before 8GA, fixed in an 8-update, but not in 9. But I find that a bit unlikely and I don't want to speculate more. It just needs investigation. -phil. Regards Prasanta On 3/8/2016 9:45 PM, Philip Race wrote: > However, I am finding a strange issue with and without this fix too. The "Center" string is not printed Sounds completely unrelated to anything to do with the NPE bug. It is probably appropriate to file that as a separate bug. No big surprise that the behaviour is platform-specific as there is a lot of difference in Windows vs Linux (or vs Mac) in the printing code. -phil. On 3/8/16, 2:30 AM, prasanta sadhukhan wrote: ? On 3/8/2016 2:17 AM, Phil Race wrote: I don't think starting a new thread can be right. That would re-invoke printerJob.print() which even if you can reuse a PrinterJob (something that was never set out in spec.) you are surely getting a new spool job .. not a continuation. There a couple of other things I am not sure about either. I've looked into this - only on Linux - and I believe the issue is that the test program has decided up-front how many pages it is going to print and it is paying no attention to the selected page ranges. Not what the 'user' asked for but it is perfectly within its rights to do so. However the 2D PrinterJob operates in a way where it calls back asking for the specific pages it wants to be printed and there the app. must comply. The PrinterJob terminates once it has done. In the case when the 2D PrinterJob is being used to 'run' a PrintJob then it must *never* return until the application has called "end" - or some exception occurs. So we need to remove the elements that will cause the job to exit. --- a/src/java.desktop/share/classes/sun/print/PrintJob2D.java +++ b/src/java.desktop/share/classes/sun/print/PrintJob2D.java @@ -995,6 +995,7 @@ ???? public void run() { ? ???????? try { +??????????? attributes.remove(PageRanges.class); ???????????? printerJob.print(attributes); ???????? } catch (PrinterException e) { ???????????? //REMIND: need to store this away and not rethrow it. diff --git a/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java b/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java --- a/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java +++ b/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java @@ -1172,6 +1172,7 @@ ???????? pageRangesAttr =? (PageRanges)attributes.get(PageRanges.class); ???????? if (!isSupportedValue(pageRangesAttr, attributes)) { ???????????? pageRangesAttr = null; +??????????? setPageRange(-1, -1); ???????? } else { ???????????? if ((SunPageSelection)attributes.get(SunPageSelection.class) ????????????????????? == SunPageSelection.RANGE) { This works for me on Linux although a) I have not tried Windows) I tried on windows. The NPE is not seen and it prints 2 pages. However, I am finding a strange issue with and without this fix too. The "Center" string is not printed in the 1st page in both "Portrait" and "Landscape" mode (although the rectangles are printed) but is printed in the 2nd page. I do not find this issue in linux. Regards Prasanta b) I have not verified if there are no negative consequences from the 2nd change. -phil. On 03/01/2016 03:14 AM, prasanta sadhukhan wrote: Hi Phil, Please find an updated webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/8066139/webrev.01/"http://cr.openjdk.java.net/~psadhukhan/8066139/webrev.01/ It seems if printerJobThread finished printing, it will set graphicsToBeDrawn/graphicsDrawn ArrayList to null resulting in getGraphics() returning null in the 2nd iteration causing NPE so ?I have modified printerJobThread#run so that when it has finished printing, do not set the arrayList to null but set a flag. In getGraphics(), I check that flag and start a new printerJobThread to handle the next printing. I have tested "All" and "Pages" selection. Regards Prasanta On 2/22/2016 1:35 PM, Philip Race wrote: > It seems this behaviour is same in linux too for this HighResTest testcase. OK that is good information .. so is not really a regression from HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8061267"8061267 as that is not in any way touching linux .. it is a pre-existing issue in a code path that was not being tested. -phil. On 2/22/16, 11:59 AM, prasanta sadhukhan wrote: Hi Phil, >>Additionally, have you tried running the original test case provided with 8061267 >> against your fix ? The 8061267 testcase behaves similarly before and after my fix. >> If I manually select it, (ie select that "Pages" radio button) then press print, >> then voila, the NPE is back! It seems this behaviour is same in linux too for this HighResTest testcase. Regards Prasanta On 2/20/2016 1:55 AM, Phil Race wrote: I am having trouble building JDK 9 at the moment so i applied 8061267 to jdk8u-dev and was able to reproduce the regression and have a couple of observations - I am now seeing the NPE after the first page as you did .. puzzling. - I next applied your fix but still see the NPE ! It appears that all your fix did is stop the "PD_PAGENUMS"? flag being automatically set. If I manually select it, (ie select that "Pages" radio button) then press print, then voila, the NPE is back! -phil. On 02/19/2016 10:53 AM, Phil Race wrote: I am not sure I can be correctly understanding the fix as the ramification seems to be that if the users wants to print only Page 3 of a 10 page document and so sets from page=3 and to page=3, that this request will be ignored and all pages will be printed .. can you test such a scenario. Additionally, have you tried running the original test case provided with 8061267 against your fix ? Also when I ran the HighResTest on a current build I saw a null graphics on the very first call to getGraphics() which is different than what I interpret you as saying - you see the null *after* the first page is printed. -phil. On 02/19/2016 01:18 AM, prasanta sadhukhan wrote: Hi Phil, All, Bug: https://bugs.openjdk.java.net/browse/JDK-8066139 webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/8066139/webrev.00/"http://cr.openjdk.java.net/~psadhukhan/8066139/webrev.00/ It was seen after fix of HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8061267"JDK-8061267: PrinterJob: Specified Page Ranges not displayed in Windows Native Print Dialog the closed/java/awt/PrintJob/HighResTest/HighResTest.java was failing with NPE when PrinterJob.getGraphics() is called the 2nd time before calling PrinterJob.end(). The above fix caused this regression because it sets the PD_PAGENUMS flag for windows PrintDlg struct which causes Pages radio button to be selected in print dialog. However, fromPage and toPage was both set to 1 so after the 1st page is printed, RasterPrinterJob.print(attributes) finishes and graphicsToBeDrawn.closeWhenEmpty() gets called http://hg.openjdk.java.net/jdk9/client/jdk/file/d8def65c6c00/src/java.desktop/share/classes/sun/print/PrintJob2D.java#l1006 which sets the queue to null so when PrinterJob2D#getGraphics() calls graphicsToBeDrawn.pop() it sees queue to be null and sets graphics object to be null so PrinterJob.getGraphics() gets null and g.drawLine in testcase causes NPE since g is null. Fix was done to set the PD_PAGENUMS flag only when toPage is more than fromPage in which case, "All" will be selected in printer dialog and RasterPrinterJob.print() will finish only after printing all the pages. Regards Prasanta ? ? ? ? ? ? ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Wed Mar 16 09:16:00 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 16 Mar 2016 02:16:00 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6379088, , Suboptimal expression in javax.imageio.ImageTypeSpecifier.getBitsPerBand(int) In-Reply-To: <56E7FA9C.4000603@oracle.com> References: <56E7FA9C.4000603@oracle.com> Message-ID: <1615ef5e-5d16-4973-891f-a8983281731b@default> Change is fine. Looks like this is the only place in ImageTypeSpecifier where we are not using short-circuit logical "or". -----Original Message----- From: prasanta sadhukhan Sent: Tuesday, March 15, 2016 5:36 PM To: Sergey Bylokhov; Jayathirth D V; 2d-dev at openjdk.java.net Subject: [9] RFR: JDK-6379088,,Suboptimal expression in javax.imageio.ImageTypeSpecifier.getBitsPerBand(int) Hi All, Bug: https://bugs.openjdk.java.net/browse/JDK-6379088 webrev: http://cr.openjdk.java.net/~psadhukhan/6379088/webrev.00/ Please review a simple fix where we should be using short-circuit logical operators so that if left side of the expression is false, right side will not be evaluated. I intend to put noreg-trivial label for this fix. Regards Prasanta From prasanta.sadhukhan at oracle.com Wed Mar 16 09:25:30 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Wed, 16 Mar 2016 14:55:30 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6379088, , Suboptimal expression in javax.imageio.ImageTypeSpecifier.getBitsPerBand(int) In-Reply-To: <1615ef5e-5d16-4973-891f-a8983281731b@default> References: <56E7FA9C.4000603@oracle.com> <1615ef5e-5d16-4973-891f-a8983281731b@default> Message-ID: <56E9268A.7060308@oracle.com> Thanks Jay. Sergey, could you please give your +1 on this? Regards Prasanta On 3/16/2016 2:46 PM, Jayathirth D V wrote: > Change is fine. Looks like this is the only place in ImageTypeSpecifier where we are not using short-circuit logical "or". > > -----Original Message----- > From: prasanta sadhukhan > Sent: Tuesday, March 15, 2016 5:36 PM > To: Sergey Bylokhov; Jayathirth D V; 2d-dev at openjdk.java.net > Subject: [9] RFR: JDK-6379088,,Suboptimal expression in javax.imageio.ImageTypeSpecifier.getBitsPerBand(int) > > Hi All, > > Bug: https://bugs.openjdk.java.net/browse/JDK-6379088 > webrev: http://cr.openjdk.java.net/~psadhukhan/6379088/webrev.00/ > > Please review a simple fix where we should be using short-circuit logical operators so that if left side of the expression is false, right side will not be evaluated. > I intend to put noreg-trivial label for this fix. > > Regards > Prasanta From ajit.ghaisas at oracle.com Wed Mar 16 10:27:57 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Wed, 16 Mar 2016 03:27:57 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-6185114: Undefined Exception in SampleModel, method createCompatibleSampleModel Message-ID: <06287367-8efc-4f33-b16a-b7f898b53259@default> Hi, Bug : https://bugs.openjdk.java.net/browse/JDK-6185114 Issue : Undefined Exception in SampleModel, method createCompatibleSampleModel Root Cause : The SampleModel constructor documentation says - it throws the IllegalArgumentException if the product of width and height parameters is greater than Integer.MAX_VALUE. The condition for this check is incorrectly checks for "greater than equal to" where it should be only "greater than". Fix : Corrected the erroneous condition in below webrev and added a test. http://cr.openjdk.java.net/~arapte/ajit/6185114/webrev.00/ Regards, Ajit -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Wed Mar 16 10:55:01 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Wed, 16 Mar 2016 16:25:01 +0530 Subject: [OpenJDK 2D-Dev] Review Request for JDK-6185114: Undefined Exception in SampleModel, method createCompatibleSampleModel In-Reply-To: <06287367-8efc-4f33-b16a-b7f898b53259@default> References: <06287367-8efc-4f33-b16a-b7f898b53259@default> Message-ID: <56E93B85.2060208@oracle.com> Fix Looks ok. Test failure message does not say what it is failing for. Maybe you can mention "Expected IAE count <>, got IAE count <>" . lune 52 has a typo heiht Regards Prasanta On 3/16/2016 3:57 PM, Ajit Ghaisas wrote: > > Hi, > > Bug : https://bugs.openjdk.java.net/browse/JDK-6185114 > > Issue : Undefined Exception in SampleModel, method > createCompatibleSampleModel > > Root Cause : > > The SampleModel constructor documentation says ? it throws the > IllegalArgumentException if the product of width and height parameters > is greater than Integer.MAX_VALUE. > > The condition for this check is incorrectly checks for ?greater than > equal to? where it should be only ?greater than?. > > Fix : > > Corrected the erroneous condition in below webrev and added a test. > > http://cr.openjdk.java.net/~arapte/ajit/6185114/webrev.00/ > > > Regards, > > Ajit > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajit.ghaisas at oracle.com Wed Mar 16 11:45:58 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Wed, 16 Mar 2016 04:45:58 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-6185114: Undefined Exception in SampleModel, method createCompatibleSampleModel In-Reply-To: <56E93B85.2060208@oracle.com> References: <06287367-8efc-4f33-b16a-b7f898b53259@default> <56E93B85.2060208@oracle.com> Message-ID: <84527e90-602d-4c04-94a8-69eda977ff7e@default> Hi, I have corrected the typo and modified the failure message string. Please review the updated webrev. http://cr.openjdk.java.net/~arapte/ajit/6185114/webrev.01/ Regards, Ajit From: prasanta sadhukhan Sent: Wednesday, March 16, 2016 4:25 PM To: Ajit Ghaisas; 2d-dev; Philip Race Subject: Re: Review Request for JDK-6185114: Undefined Exception in SampleModel, method createCompatibleSampleModel Fix Looks ok. Test failure message does not say what it is failing for. Maybe you can mention "Expected IAE count <>, got IAE count <>" . lune 52 has a typo heiht Regards Prasanta On 3/16/2016 3:57 PM, Ajit Ghaisas wrote: Hi, Bug : https://bugs.openjdk.java.net/browse/JDK-6185114 Issue : Undefined Exception in SampleModel, method createCompatibleSampleModel Root Cause : The SampleModel constructor documentation says - it throws the IllegalArgumentException if the product of width and height parameters is greater than Integer.MAX_VALUE. The condition for this check is incorrectly checks for "greater than equal to" where it should be only "greater than". Fix : Corrected the erroneous condition in below webrev and added a test. HYPERLINK "http://cr.openjdk.java.net/%7Earapte/ajit/6185114/webrev.00/"http://cr.openjdk.java.net/~arapte/ajit/6185114/webrev.00/ Regards, Ajit -------------- next part -------------- An HTML attachment was scrubbed... URL: From bourges.laurent at gmail.com Wed Mar 16 15:16:48 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 16 Mar 2016 16:16:48 +0100 Subject: [OpenJDK 2D-Dev] RFR 8144938: Handle properly coordinate overflow in Marlin Renderer In-Reply-To: <56E89082.5040703@oracle.com> References: <56E2159E.8000209@oracle.com> <56E22734.7020707@oracle.com> <56E33249.2030300@oracle.com> <56E74A98.30503@oracle.com> <56E89082.5040703@oracle.com> Message-ID: Jim, Here is another webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144938.3/ Changes: - restored pathClosed flag to fix the 'hour glass' issue below - added pathClosedTest in CrashNaNTest Comments below: 2016-03-15 23:45 GMT+01:00 Jim Graham : > The new tests look good. > Thanks. > There is one logic error in the new version of the degenerate coordinate > filter. > > It is valid to have a PATH_CLOSE immediately followed by a To call > and the subpath will start at the previous close/moveto point. For example: > > moveto 40, 40 > lineto 0, 0 > lineto 80, 0 > closepath > lineto 80, 80 > lineto 0, 80 > closepath > > should draw an hourglass, but with your fix it will lose the lower half > because the lineto after the close will be turned into a moveto (and the > second subpath then becomes empty. > I tested my previous patch and you were right: it was buggy. > I think it should be fine just getting rid of the subpath=false in the > close case. > I prefered reverting to the ductus approach even if your proposal seems working. I agree my patch is a bit tricky but it explicitely emits a moveTo() after pathClosed() instead of relying to the path consumer to implement the same behaviour (in dasher / stroker)... It is arguable, though, if we have closepath followed by a NaN if perhaps > that NaN should break the subpath from the previous close, but I don't > think that is in keeping with the current philosophy of simply pretending > that bad coordinates don't exist. Essentially, the close of a previously > valid path gives us a valid start to the new subpath regardless if it > immediately feeds into more bad coordinates - it still started its run on a > valid point. So, I'd argue that simply passing along the prior value of > the subpath flag would be appropriate, whether it is true or false (and, > obviously, also closing the path in the consumer if it is true)... > Please tell me what solution do you prefer. I can adopt yours which seems really simple. Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From bourges.laurent at gmail.com Wed Mar 16 15:24:44 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 16 Mar 2016 16:24:44 +0100 Subject: [OpenJDK 2D-Dev] Java2d code using @ForceInline or @Stable annotations Message-ID: Hi, In the marlin renderer, I am wondering if I could use the compiler annotations @ForceInline / @Stable (in java.base module). It would provide hints to the hotspot compiler and maybe bring some performance benefits. Of course, it means adding a qualified export in the modules.xml: jdk.internal.vm.annotation java.desktop Please give me your opinion & comments. Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Mar 16 16:51:06 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 16 Mar 2016 09:51:06 -0700 Subject: [OpenJDK 2D-Dev] Java2d code using @ForceInline or @Stable annotations In-Reply-To: References: Message-ID: <56E98EFA.3090200@oracle.com> The jigsaw team would need to sign off on any changes to the module graph and in addition I think the VM team might have some input on this since I don't think this is intended to be used other than extremely sparingly. I see @Stable used only by String and java.lang.invoke which has deep ties to the VM. In other words I am not sure we should do this or if, for ForceIine, it would bring any benefits over what hotspot is doing without prompting. -phil. On 3/16/16, 8:24 AM, Laurent Bourg?s wrote: > Hi, > > In the marlin renderer, I am wondering if I could use the compiler > annotations @ForceInline / @Stable (in java.base module). > > It would provide hints to the hotspot compiler and maybe bring some > performance benefits. > > Of course, it means adding a qualified export in the modules.xml: > > jdk.internal.vm.annotation > java.desktop > > > Please give me your opinion & comments. > > Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Mar 16 17:29:21 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 16 Mar 2016 10:29:21 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream In-Reply-To: <99cb1549-30b5-44af-b399-ebed22255cf8@default> References: <99cb1549-30b5-44af-b399-ebed22255cf8@default> Message-ID: <56E997F1.2070605@oracle.com> The test writes out into "test.src". I believe that you should treat that as a "read-only" location. Write to a tempfile (File.createTempFile()) or TESTCLASSES. -phil. On 3/15/16, 10:50 PM, Jayathirth D V wrote: > > Hi Phil,All > > _Please review the following fix in JDK9:_ > > __ > > Bug : https://bugs.openjdk.java.net/browse/JDK-8044289 > > Webrev : http://cr.openjdk.java.net/~jdv/8044289/webrev.00/ > > > Issue : When createImageInputStream() or createImageOutputStream > returns null in ImageIO.read() or ImageIO.write() we are seeing NPE as > it stream is used further without null check. > > Root cause : "stream" is used without checking whether it is null or not. > > Solution : Handle null pointer of stream and throw IIOException. > > Test case contains all possible scenarios where > createImageInputStream() or createImageOutputStream can return null. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Mar 16 18:46:50 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 16 Mar 2016 11:46:50 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8151110, , libfontmanager should free memory with delete[] if it was allocated with new[] In-Reply-To: <56E8FE36.3090406@oracle.com> References: <56E8FE36.3090406@oracle.com> Message-ID: <56E9AA1A.7010907@oracle.com> +1 -phil. On 3/15/16, 11:33 PM, prasanta sadhukhan wrote: > Hi Phil, > > Please review a small fix for > bug: https://bugs.openjdk.java.net/browse/JDK-8151110 > webrev: http://cr.openjdk.java.net/~psadhukhan/8151110/webrev.00/ > > where the issue was found that the allocation of memory was done > through new operator but free was done through free(). > Since they operate on different heaps and can pose problem if the code > was to be run on new machine/compiler it's better to allocate through > calloc for free() to delete memory correctly. > noreg-cleanup is added for this bug. > > Regards > Prasanta From philip.race at oracle.com Wed Mar 16 18:50:07 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 16 Mar 2016 11:50:07 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8151590, , "ALL" radio button is not selected in printDialog when we call DefaultSelectionType.ALL in windows In-Reply-To: <56E2B4B5.9010607@oracle.com> References: <56E14DC0.6020505@oracle.com> <56E2B4B5.9010607@oracle.com> Message-ID: <56E9AADF.4040206@oracle.com> As I mentioned off-line please remove the extraneous stuff from the test. And why is the (c) 2015 ? -phil. On 3/11/16, 4:06 AM, prasanta sadhukhan wrote: > > Please find modified webrev with updated testcase. > http://cr.openjdk.java.net/~psadhukhan/8151590/webrev.01/ > > Regards > Prasanta > On 3/10/2016 4:04 PM, prasanta sadhukhan wrote: >> Hi Phil, >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8151590 >> webrev: http://cr.openjdk.java.net/~psadhukhan/8151590/webrev.00/ >> >> The issue is if application calls >> JobAttributes.setDefaultSelection(JobAttributes.DefaultSelectionType.ALL); >> >> along with >> JobAttributes.setFromPage(2); >> JobAttributes.setToPage(5); >> >> then "Page" radio button is selected in windows. In linux and mac, >> "All" radio button is selected. >> Although the spec is not very clear as to what should get preference, >> it seems logically DefaultSelection should hold preference. >> >> This is a regression from 8061267 where PD_PAGENUMS was added to the >> flags resulting in "Page" radio button getting selected. >> I added a fix to add PD_PAGENUMS to the flags only if the selection >> attribute is not "PD_ALLPAGES" [which gets selected when >> JobAttributes.setDefaultSelection(JobAttributes.DefaultSelectionType.ALL); >> is called] >> >> I tested 8061267 testcase behaviour is same with this fix. >> >> Regards >> Prasanta > From Sergey.Bylokhov at oracle.com Wed Mar 16 20:09:34 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 16 Mar 2016 23:09:34 +0300 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6379088, , Suboptimal expression in javax.imageio.ImageTypeSpecifier.getBitsPerBand(int) In-Reply-To: <1615ef5e-5d16-4973-891f-a8983281731b@default> References: <56E7FA9C.4000603@oracle.com> <1615ef5e-5d16-4973-891f-a8983281731b@default> Message-ID: <56E9BD7E.1020207@oracle.com> +1 On 16.03.16 12:16, Jayathirth D V wrote: > Change is fine. Looks like this is the only place in ImageTypeSpecifier where we are not using short-circuit logical "or". > > -----Original Message----- > From: prasanta sadhukhan > Sent: Tuesday, March 15, 2016 5:36 PM > To: Sergey Bylokhov; Jayathirth D V; 2d-dev at openjdk.java.net > Subject: [9] RFR: JDK-6379088,,Suboptimal expression in javax.imageio.ImageTypeSpecifier.getBitsPerBand(int) > > Hi All, > > Bug: https://bugs.openjdk.java.net/browse/JDK-6379088 > webrev: http://cr.openjdk.java.net/~psadhukhan/6379088/webrev.00/ > > Please review a simple fix where we should be using short-circuit logical operators so that if left side of the expression is false, right side will not be evaluated. > I intend to put noreg-trivial label for this fix. > > Regards > Prasanta > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Mar 16 20:15:56 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 16 Mar 2016 23:15:56 +0300 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8151110, , libfontmanager should free memory with delete[] if it was allocated with new[] In-Reply-To: <56E9AA1A.7010907@oracle.com> References: <56E8FE36.3090406@oracle.com> <56E9AA1A.7010907@oracle.com> Message-ID: <56E9BEFC.1030804@oracle.com> Looks fine. On 16.03.16 21:46, Philip Race wrote: > +1 > > -phil. > > On 3/15/16, 11:33 PM, prasanta sadhukhan wrote: >> Hi Phil, >> >> Please review a small fix for >> bug: https://bugs.openjdk.java.net/browse/JDK-8151110 >> webrev: http://cr.openjdk.java.net/~psadhukhan/8151110/webrev.00/ >> >> where the issue was found that the allocation of memory was done >> through new operator but free was done through free(). >> Since they operate on different heaps and can pose problem if the code >> was to be run on new machine/compiler it's better to allocate through >> calloc for free() to delete memory correctly. >> noreg-cleanup is added for this bug. >> >> Regards >> Prasanta -- Best regards, Sergey. From philip.race at oracle.com Wed Mar 16 20:22:36 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 16 Mar 2016 13:22:36 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6379088, , Suboptimal expression in javax.imageio.ImageTypeSpecifier.getBitsPerBand(int) In-Reply-To: <56E9BD7E.1020207@oracle.com> References: <56E7FA9C.4000603@oracle.com> <1615ef5e-5d16-4973-891f-a8983281731b@default> <56E9BD7E.1020207@oracle.com> Message-ID: <56E9C08C.2070308@oracle.com> +1 noreg-hard may be better than noreg-trivial. -phil. On 03/16/2016 01:09 PM, Sergey Bylokhov wrote: > +1 > > On 16.03.16 12:16, Jayathirth D V wrote: >> Change is fine. Looks like this is the only place in >> ImageTypeSpecifier where we are not using short-circuit logical "or". >> >> -----Original Message----- >> From: prasanta sadhukhan >> Sent: Tuesday, March 15, 2016 5:36 PM >> To: Sergey Bylokhov; Jayathirth D V; 2d-dev at openjdk.java.net >> Subject: [9] RFR: JDK-6379088,,Suboptimal expression in >> javax.imageio.ImageTypeSpecifier.getBitsPerBand(int) >> >> Hi All, >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-6379088 >> webrev: http://cr.openjdk.java.net/~psadhukhan/6379088/webrev.00/ >> >> Please review a simple fix where we should be using short-circuit >> logical operators so that if left side of the expression is false, >> right side will not be evaluated. >> I intend to put noreg-trivial label for this fix. >> >> Regards >> Prasanta >> > > From Sergey.Bylokhov at oracle.com Wed Mar 16 20:35:41 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 16 Mar 2016 23:35:41 +0300 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream In-Reply-To: <56E997F1.2070605@oracle.com> References: <99cb1549-30b5-44af-b399-ebed22255cf8@default> <56E997F1.2070605@oracle.com> Message-ID: <56E9C39D.6090701@oracle.com> As far as I understand the createImageInputStream() returns null is this stream is unsupported by current plugins via spi. Probably the read() method should return null too? /** * Returns a {@code BufferedImage} as the result of decoding * a supplied {@code InputStream} with an {@code ImageReader} * chosen automatically from among those currently registered. * The {@code InputStream} is wrapped in an * {@code ImageInputStream}. If no registered * {@code ImageReader} claims to be able to read the * resulting stream, {@code null} is returned. * ....... * @return a {@code BufferedImage} containing the decoded * contents of the input, or {@code null}. */ public static BufferedImage read(InputStream input) throws IOException On 16.03.16 20:29, Philip Race wrote: > The test writes out into "test.src". > I believe that you should treat that as a "read-only" location. > Write to a tempfile (File.createTempFile()) or TESTCLASSES. > > -phil. > > On 3/15/16, 10:50 PM, Jayathirth D V wrote: >> >> Hi Phil,All >> >> _Please review the following fix in JDK9:_ >> >> __ >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8044289 >> >> Webrev : http://cr.openjdk.java.net/~jdv/8044289/webrev.00/ >> >> >> Issue : When createImageInputStream() or createImageOutputStream >> returns null in ImageIO.read() or ImageIO.write() we are seeing NPE as >> it stream is used further without null check. >> >> Root cause : ?stream? is used without checking whether it is null or not. >> >> Solution : Handle null pointer of stream and throw IIOException. >> >> Test case contains all possible scenarios where >> createImageInputStream() or createImageOutputStream can return null. >> >> Thanks, >> >> Jay >> -- Best regards, Sergey. From philip.race at oracle.com Wed Mar 16 21:36:21 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 16 Mar 2016 14:36:21 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream In-Reply-To: <56E9C39D.6090701@oracle.com> References: <99cb1549-30b5-44af-b399-ebed22255cf8@default> <56E997F1.2070605@oracle.com> <56E9C39D.6090701@oracle.com> Message-ID: <56E9D1D5.8090500@oracle.com> I don't think that is the actual reason here - it seems likely that there was some kind of internal error or bad SPI causing this. So throwing an exception seems more appropriate. And also the bug was originally solely about write(..). -phil. On 03/16/2016 01:35 PM, Sergey Bylokhov wrote: > As far as I understand the createImageInputStream() returns null is > this stream is unsupported by current plugins via spi. Probably the > read() method should return null too? > > /** > * Returns a {@code BufferedImage} as the result of decoding > * a supplied {@code InputStream} with an {@code ImageReader} > * chosen automatically from among those currently registered. > * The {@code InputStream} is wrapped in an > * {@code ImageInputStream}. If no registered > * {@code ImageReader} claims to be able to read the > * resulting stream, {@code null} is returned. > * > ....... > * @return a {@code BufferedImage} containing the decoded > * contents of the input, or {@code null}. > */ > public static BufferedImage read(InputStream input) throws > IOException > > > On 16.03.16 20:29, Philip Race wrote: >> The test writes out into "test.src". >> I believe that you should treat that as a "read-only" location. >> Write to a tempfile (File.createTempFile()) or TESTCLASSES. >> >> -phil. >> >> On 3/15/16, 10:50 PM, Jayathirth D V wrote: >>> >>> Hi Phil,All >>> >>> _Please review the following fix in JDK9:_ >>> >>> __ >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8044289 >>> >>> Webrev : http://cr.openjdk.java.net/~jdv/8044289/webrev.00/ >>> >>> >>> Issue : When createImageInputStream() or createImageOutputStream >>> returns null in ImageIO.read() or ImageIO.write() we are seeing NPE as >>> it stream is used further without null check. >>> >>> Root cause : ?stream? is used without checking whether it is null or >>> not. >>> >>> Solution : Handle null pointer of stream and throw IIOException. >>> >>> Test case contains all possible scenarios where >>> createImageInputStream() or createImageOutputStream can return null. >>> >>> Thanks, >>> >>> Jay >>> > > From bourges.laurent at gmail.com Wed Mar 16 22:25:20 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 16 Mar 2016 23:25:20 +0100 Subject: [OpenJDK 2D-Dev] Java2d code using @ForceInline or @Stable annotations In-Reply-To: <56E98EFA.3090200@oracle.com> References: <56E98EFA.3090200@oracle.com> Message-ID: Phil, I tested adding @ForceInline to few important methods in marlin that jitwatch detected as too large (>325 byte codes). It seems hotspot perform inlining with the hint and few long tests are a bit faster (max 10%). I agree it is border line and java2d must respect vm and module rules. Cheers, Laurent Le 16 mars 2016 17:51, "Philip Race" a ?crit : > > The jigsaw team would need to sign off on any changes > to the module graph and in addition I think the VM team > might have some input on this since I don't think this > is intended to be used other than extremely sparingly. > I see @Stable used only by String and java.lang.invoke > which has deep ties to the VM. > In other words I am not sure we should do this or if, for ForceIine, > it would bring any benefits over what hotspot is doing without prompting. > > -phil. > > > On 3/16/16, 8:24 AM, Laurent Bourg?s wrote: >> >> Hi, >> >> In the marlin renderer, I am wondering if I could use the compiler annotations @ForceInline / @Stable (in java.base module). >> >> It would provide hints to the hotspot compiler and maybe bring some performance benefits. >> >> Of course, it means adding a qualified export in the modules.xml: >> >> jdk.internal.vm.annotation >> java.desktop >> >> >> Please give me your opinion & comments. >> >> Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Mar 17 00:29:19 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 16 Mar 2016 17:29:19 -0700 Subject: [OpenJDK 2D-Dev] Java2d code using @ForceInline or @Stable annotations In-Reply-To: References: <56E98EFA.3090200@oracle.com> Message-ID: <56E9FA5F.4040902@oracle.com> A demonstrable 5-10% on a "real program" - one that does something that is at least representative of a real world benefit is something you could (should) take to the hotspot team (probably hotspot-compiler-dev) and point them directly at the program and the results and see what they say. Who knows .. they could say 325 is the result of lots of careful analysis or they may make some changes as a result, perhaps not to that metric but to something else. -phil. On 3/16/16, 3:25 PM, Laurent Bourg?s wrote: > > Phil, > > I tested adding @ForceInline to few important methods in marlin that > jitwatch detected as too large (>325 byte codes). > > It seems hotspot perform inlining with the hint and few long tests are > a bit faster (max 10%). > > I agree it is border line and java2d must respect vm and module rules. > > Cheers, > Laurent > > Le 16 mars 2016 17:51, "Philip Race" > a ?crit : > > > > The jigsaw team would need to sign off on any changes > > to the module graph and in addition I think the VM team > > might have some input on this since I don't think this > > is intended to be used other than extremely sparingly. > > I see @Stable used only by String and java.lang.invoke > > which has deep ties to the VM. > > In other words I am not sure we should do this or if, for ForceIine, > > it would bring any benefits over what hotspot is doing without > prompting. > > > > -phil. > > > > > > On 3/16/16, 8:24 AM, Laurent Bourg?s wrote: > >> > >> Hi, > >> > >> In the marlin renderer, I am wondering if I could use the compiler > annotations @ForceInline / @Stable (in java.base module). > >> > >> It would provide hints to the hotspot compiler and maybe bring some > performance benefits. > >> > >> Of course, it means adding a qualified export in the modules.xml: > >> > >> jdk.internal.vm.annotation > >> java.desktop > >> > >> > >> Please give me your opinion & comments. > >> > >> Laurent > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Thu Mar 17 00:49:48 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 16 Mar 2016 17:49:48 -0700 Subject: [OpenJDK 2D-Dev] RFR 8144938: Handle properly coordinate overflow in Marlin Renderer In-Reply-To: References: <56E2159E.8000209@oracle.com> <56E22734.7020707@oracle.com> <56E33249.2030300@oracle.com> <56E74A98.30503@oracle.com> <56E89082.5040703@oracle.com> Message-ID: <56E9FF2C.4020308@oracle.com> Hi Laurent, I'm not sure why you added the pathClosed variable back. Before your fix we used to rely on all of the downstream consumers correctly implementing the case of CLOSE followed by a non-MOVE command so specifically enforcing a MOVE here should be unnecessary and just complicates the code...? ...jim On 3/16/16 8:16 AM, Laurent Bourg?s wrote: > Jim, > > Here is another webrev: > http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144938.3/ > > Changes: > - restored pathClosed flag to fix the 'hour glass' issue below > - added pathClosedTest in CrashNaNTest > > Comments below: > > 2016-03-15 23:45 GMT+01:00 Jim Graham >: > > The new tests look good. > > > Thanks. > > > There is one logic error in the new version of the degenerate > coordinate filter. > > It is valid to have a PATH_CLOSE immediately followed by a To > call and the subpath will start at the previous close/moveto point. > For example: > > moveto 40, 40 > lineto 0, 0 > lineto 80, 0 > closepath > lineto 80, 80 > lineto 0, 80 > closepath > > should draw an hourglass, but with your fix it will lose the lower > half because the lineto after the close will be turned into a moveto > (and the second subpath then becomes empty. > > > I tested my previous patch and you were right: it was buggy. > > I think it should be fine just getting rid of the subpath=false in > the close case. > > > I prefered reverting to the ductus approach even if your proposal seems > working. > > I agree my patch is a bit tricky but it explicitely emits a moveTo() > after pathClosed() instead of relying to the path consumer to implement > the same behaviour (in dasher / stroker)... > > It is arguable, though, if we have closepath followed by a NaN if > perhaps that NaN should break the subpath from the previous close, > but I don't think that is in keeping with the current philosophy of > simply pretending that bad coordinates don't exist. Essentially, > the close of a previously valid path gives us a valid start to the > new subpath regardless if it immediately feeds into more bad > coordinates - it still started its run on a valid point. So, I'd > argue that simply passing along the prior value of the subpath flag > would be appropriate, whether it is true or false (and, obviously, > also closing the path in the consumer if it is true)... > > > Please tell me what solution do you prefer. > I can adopt yours which seems really simple. > > Laurent From prasanta.sadhukhan at oracle.com Thu Mar 17 08:35:08 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Thu, 17 Mar 2016 14:05:08 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8151590, , "ALL" radio button is not selected in printDialog when we call DefaultSelectionType.ALL in windows In-Reply-To: <56E9AADF.4040206@oracle.com> References: <56E14DC0.6020505@oracle.com> <56E2B4B5.9010607@oracle.com> <56E9AADF.4040206@oracle.com> Message-ID: <56EA6C3C.9070802@oracle.com> Hi Phil, Please find the updated webrev: http://cr.openjdk.java.net/~psadhukhan/8151590/webrev.02/ Regards Prasanta On 3/17/2016 12:20 AM, Philip Race wrote: > As I mentioned off-line please remove the extraneous stuff > from the test. And why is the (c) 2015 ? > > -phil. > > On 3/11/16, 4:06 AM, prasanta sadhukhan wrote: >> >> Please find modified webrev with updated testcase. >> http://cr.openjdk.java.net/~psadhukhan/8151590/webrev.01/ >> >> Regards >> Prasanta >> On 3/10/2016 4:04 PM, prasanta sadhukhan wrote: >>> Hi Phil, >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151590 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8151590/webrev.00/ >>> >>> The issue is if application calls >>> JobAttributes.setDefaultSelection(JobAttributes.DefaultSelectionType.ALL); >>> >>> along with >>> JobAttributes.setFromPage(2); >>> JobAttributes.setToPage(5); >>> >>> then "Page" radio button is selected in windows. In linux and mac, >>> "All" radio button is selected. >>> Although the spec is not very clear as to what should get >>> preference, it seems logically DefaultSelection should hold preference. >>> >>> This is a regression from 8061267 where PD_PAGENUMS was added to the >>> flags resulting in "Page" radio button getting selected. >>> I added a fix to add PD_PAGENUMS to the flags only if the selection >>> attribute is not "PD_ALLPAGES" [which gets selected when >>> JobAttributes.setDefaultSelection(JobAttributes.DefaultSelectionType.ALL); >>> is called] >>> >>> I tested 8061267 testcase behaviour is same with this fix. >>> >>> Regards >>> Prasanta >> From prahalad.kumar.narayanan at oracle.com Thu Mar 17 10:00:32 2016 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Thu, 17 Mar 2016 03:00:32 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: Antialiased text on translucent backgrounds gets bright artifacts Message-ID: <63d69ba8-d5cf-4697-bb5c-f51aaaa8c427@default> Hello Everyone on Java2D Group Good day to you. Herewith, I 'm sharing the webrev for two identical Java2D Bugs. Bug ID : JDK-8015070 Title : Antialiased text on translucent backgrounds gets bright artifacts Link : https://bugs.openjdk.java.net/browse/JDK-8015070 Bug ID : JDK-8013564 ( currently closed as duplicate ) Title : Font rendering anti-aliasing in translucent BufferedImages broken Link : https://bugs.openjdk.java.net/browse/JDK-8013564 Webrev Link : http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.00/ Quick Summary on Bugs : ```````````````````````````````````````````````` 1. Artifacts appear on Edges of text characters when anti-aliased text is drawn on Translucent background 2. The issue is reproducible on all platforms - windows, linux and mac os. 3. Besides, the issue is reproduced with the commonly used pixel format- 4ByteArgb. Root Cause & Solution : ```````````````````````````````````````````````` 1. The Macro: GlyphListAABlend4ByteArgb in File: LoopMacros.h uses the standard blending algorithm dstColor = [ srcColor * glyphAlpha + dstColor * (1 - glyphAlpha) ] / dstAlpha 2. The above equation works only when the srcColor and dstColor are Opaque. 3. When srcColor and dstColor are Translucent, their alphaComponent will influence the visibility of the color, and visibility of the color below. 4. The new set of calculations for blending Translucent source and destination colors is given as resAlpha = 1 - ((1 - srcAlpha) * (1 - dstAlpha)) resColor = [ srcColor * srcAlpha + dstColor * dstAlpha * (1 - srcAlpha) ] / resAlpha 5. Reference text for the equation: https://en.wikipedia.org/wiki/Alpha_compositing 6. With the above modification to the blending logic, the artifacts do not appear and issues are fixed. Jtreg & Jprt Results : ```````````````````````````````````````````````` 1. A simple test-file: AADrawStringArtifact.java has been created to be a part of jtreg test cases. The test file is well commented to explain - nature of artifact and how the test tries to identify them. As required, the test case fails with Jdk 7, Jdk 8 and succeeds with Jdk 9-internal (built with changes for the bug fix) 2. The changes to blending logic lies within java.desktop/src/share/native/... Henceforth, JPRT was used to ensure successful build across all supported platforms Jprt Job Link : http://scaaa637.us.oracle.com//archive/2016/03/2016-03-17-072001.prahnara-linux.client The build succeeds on all platforms. Kindly review the webrev link and provide your views and suggestions. Webrev Link : http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.00/ If the changes look good, we could take up the changes for source checkin. Thank you for your time in review Have a good day Prahalad N. -------------- next part -------------- An HTML attachment was scrubbed... URL: From torgeir.veimo at gmail.com Thu Mar 17 11:19:54 2016 From: torgeir.veimo at gmail.com (Torgeir Veimo) Date: Thu, 17 Mar 2016 21:19:54 +1000 Subject: [OpenJDK 2D-Dev] Fwd: [2D-Dev] Review Request: JDK-8015070: Antialiased text on translucent backgrounds gets bright artifacts In-Reply-To: References: <63d69ba8-d5cf-4697-bb5c-f51aaaa8c427@default> Message-ID: Hi, has this technique also been tested with the new subpixel antialiasing font rendering on OSX, that is currently disabled by default for translucent surfaces? http://cr.openjdk.java.net/~bae/8023794/9/webrev.10/ On 17 March 2016 at 20:00, Prahalad Kumar Narayanan < prahalad.kumar.narayanan at oracle.com> wrote: > Hello Everyone on Java2D Group > > > > Good day to you. > > > > Herewith, I 'm sharing the webrev for two identical Java2D Bugs. > > Bug ID : JDK-8015070 > > Title : Antialiased text on translucent backgrounds gets bright > artifacts > > Link : https://bugs.openjdk.java.net/browse/JDK-8015070 > > > > Bug ID : JDK-8013564 ( currently closed as duplicate ) > > Title : Font rendering anti-aliasing in translucent > BufferedImages broken > > Link : https://bugs.openjdk.java.net/browse/JDK-8013564 > > > > Webrev Link : > http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.00/ > > > > Quick Summary on Bugs : > > ```````````````````````````````````````````````` > > 1. Artifacts appear on Edges of text characters when anti-aliased text is > drawn on Translucent background > > 2. The issue is reproducible on all platforms - windows, linux and mac os. > > 3. Besides, the issue is reproduced with the commonly used pixel format- > 4ByteArgb. > > > > Root Cause & Solution : > > ```````````````````````````````````````````````` > > 1. The Macro: GlyphListAABlend4ByteArgb in File: LoopMacros.h uses the > standard blending algorithm > > dstColor = [ srcColor * glyphAlpha + dstColor * (1 - glyphAlpha) ] > / dstAlpha > > 2. The above equation works only when the srcColor and dstColor are > Opaque. > > > > 3. When srcColor and dstColor are Translucent, their alphaComponent will > influence the visibility of the color, and visibility of the color below. > > 4. The new set of calculations for blending Translucent source and > destination colors is given as > > resAlpha = 1 - ((1 - srcAlpha) * (1 - dstAlpha)) > > resColor = [ srcColor * srcAlpha + dstColor * dstAlpha * (1 - > srcAlpha) ] / resAlpha > > 5. Reference text for the equation: > https://en.wikipedia.org/wiki/Alpha_compositing > > 6. With the above modification to the blending logic, the artifacts do > not appear and issues are fixed. > > > > Jtreg & Jprt Results : > > ```````````````````````````````````````````````` > > 1. A simple test-file: AADrawStringArtifact.java has been created to be a > part of jtreg test cases. > > The test file is well commented to explain - nature of artifact > and how the test tries to identify them. > > As required, the test case fails with Jdk 7, Jdk 8 and succeeds > with Jdk 9-internal (built with changes for the bug fix) > > > > 2. The changes to blending logic lies within > java.desktop/src/share/native/... > > Henceforth, JPRT was used to ensure successful build across all > supported platforms > > Jprt Job Link : > http://scaaa637.us.oracle.com//archive/2016/03/2016-03-17-072001.prahnara-linux.client > > The build succeeds on all platforms. > > > > Kindly review the webrev link and provide your views and suggestions. > > Webrev Link : > http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.00/ > > > > If the changes look good, we could take up the changes for source checkin. > > > > Thank you for your time in review > > Have a good day > > > > Prahalad N. > -- -Tor -- -Tor -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Thu Mar 17 11:39:18 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 17 Mar 2016 04:39:18 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream In-Reply-To: <56E997F1.2070605@oracle.com> References: <99cb1549-30b5-44af-b399-ebed22255cf8@default> <56E997F1.2070605@oracle.com> Message-ID: Hi Phil, Thanks for the review. I have made following changes : 1) I am using File.createTempFile() both in case of read and write as a result of which we don't need external .png file which was there in previous webrev. 2) Also since I am using temporary file for read(url), I observed one more bug where I am not able to delete temporary file referenced by URL. This is happening because we are using the input url with openStream() API in ImageIO.read() and when createImageInputStream() returns null we are not closing the stream. So I have added additional code to close this stream so that temporary file can be deleted. 3) Corrected some typo's in test case comments. Please find updated webrev for review : http://cr.openjdk.java.net/~jdv/8044289/webrev.01/ Thanks, Jay From: Philip Race Sent: Wednesday, March 16, 2016 10:59 PM To: Jayathirth D V Cc: 2d-dev at openjdk.java.net Subject: Re: Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream The test writes out into "test.src". I believe that you should treat that as a "read-only" location. Write to a tempfile (File.createTempFile()) or TESTCLASSES. -phil. On 3/15/16, 10:50 PM, Jayathirth D V wrote: Hi Phil,All Please review the following fix in JDK9: Bug : https://bugs.openjdk.java.net/browse/JDK-8044289 Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8044289/webrev.00/"http://cr.openjdk.java.net/~jdv/8044289/webrev.00/ Issue : When createImageInputStream() or createImageOutputStream returns null in ImageIO.read() or ImageIO.write() we are seeing NPE as it stream is used further without null check. Root cause : "stream" is used without checking whether it is null or not. Solution : Handle null pointer of stream and throw IIOException. Test case contains all possible scenarios where createImageInputStream() or createImageOutputStream can return null. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Mar 17 13:56:44 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 17 Mar 2016 16:56:44 +0300 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream In-Reply-To: <56E9D1D5.8090500@oracle.com> References: <99cb1549-30b5-44af-b399-ebed22255cf8@default> <56E997F1.2070605@oracle.com> <56E9C39D.6090701@oracle.com> <56E9D1D5.8090500@oracle.com> Message-ID: <56EAB79C.1080503@oracle.com> On 17.03.16 0:36, Phil Race wrote: > I don't think that is the actual reason here But the test doing exactly this thing -> deregister all spi => in this case according to specification all related methods(read/write/creatImageInputStream/creatImageOutputStream) should return null or false. - it seems likely that there > was some kind of internal error or bad SPI causing this. > So throwing an exception seems more appropriate. the problem was in some of our methods which do not expect null in some places(like stream.close() from the bug description). > And also the bug was originally solely about write(..). > > -phil. > > > On 03/16/2016 01:35 PM, Sergey Bylokhov wrote: >> As far as I understand the createImageInputStream() returns null is >> this stream is unsupported by current plugins via spi. Probably the >> read() method should return null too? >> >> /** >> * Returns a {@code BufferedImage} as the result of decoding >> * a supplied {@code InputStream} with an {@code ImageReader} >> * chosen automatically from among those currently registered. >> * The {@code InputStream} is wrapped in an >> * {@code ImageInputStream}. If no registered >> * {@code ImageReader} claims to be able to read the >> * resulting stream, {@code null} is returned. >> * >> ....... >> * @return a {@code BufferedImage} containing the decoded >> * contents of the input, or {@code null}. >> */ >> public static BufferedImage read(InputStream input) throws >> IOException >> >> >> On 16.03.16 20:29, Philip Race wrote: >>> The test writes out into "test.src". >>> I believe that you should treat that as a "read-only" location. >>> Write to a tempfile (File.createTempFile()) or TESTCLASSES. >>> >>> -phil. >>> >>> On 3/15/16, 10:50 PM, Jayathirth D V wrote: >>>> >>>> Hi Phil,All >>>> >>>> _Please review the following fix in JDK9:_ >>>> >>>> __ >>>> >>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8044289 >>>> >>>> Webrev : http://cr.openjdk.java.net/~jdv/8044289/webrev.00/ >>>> >>>> >>>> Issue : When createImageInputStream() or createImageOutputStream >>>> returns null in ImageIO.read() or ImageIO.write() we are seeing NPE as >>>> it stream is used further without null check. >>>> >>>> Root cause : ?stream? is used without checking whether it is null or >>>> not. >>>> >>>> Solution : Handle null pointer of stream and throw IIOException. >>>> >>>> Test case contains all possible scenarios where >>>> createImageInputStream() or createImageOutputStream can return null. >>>> >>>> Thanks, >>>> >>>> Jay >>>> >> >> > -- Best regards, Sergey. From bourges.laurent at gmail.com Thu Mar 17 17:15:03 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 17 Mar 2016 18:15:03 +0100 Subject: [OpenJDK 2D-Dev] RFR 8144938: Handle properly coordinate overflow in Marlin Renderer In-Reply-To: <56E9FF2C.4020308@oracle.com> References: <56E2159E.8000209@oracle.com> <56E22734.7020707@oracle.com> <56E33249.2030300@oracle.com> <56E74A98.30503@oracle.com> <56E89082.5040703@oracle.com> <56E9FF2C.4020308@oracle.com> Message-ID: Hi Jim, Here is the updated webrev using your approach: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144938.4/ It is more close to 2nd webrev as it does not set subpathStarted to false in SEG_CLOSE case. Laurent 2016-03-17 1:49 GMT+01:00 Jim Graham : > Hi Laurent, > > I'm not sure why you added the pathClosed variable back. Before your fix > we used to rely on all of the downstream consumers correctly implementing > the case of CLOSE followed by a non-MOVE command so specifically enforcing > a MOVE here should be unnecessary and just complicates the code...? > > ...jim > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Thu Mar 17 18:14:44 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 17 Mar 2016 11:14:44 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream In-Reply-To: <56EAB79C.1080503@oracle.com> References: <99cb1549-30b5-44af-b399-ebed22255cf8@default> <56E997F1.2070605@oracle.com> <56E9C39D.6090701@oracle.com> <56E9D1D5.8090500@oracle.com> <56EAB79C.1080503@oracle.com> Message-ID: <88e50a67-fdd2-4b97-aa19-3ac5d419e2cf@default> Hi Sergey, My Observations: There are many places in createImageInputStream() and createImageOutputStream() where it will return null for stream. So for NPE described in bug to occur there can be multiple paths: 1) One of the path described in bug is when theRegistry.getServiceProviders() throws IAE and we return null. 2) When we pass non-existent file path to ImageIO (as described in http://stackoverflow.com/questions/11153200/with-imageio-write-api-call-i-get-nullpointerexception ). Here we catch FileNotFoundException but still we return stream as null at the end which will cause NPE further. 3) When we don't support the provider and theRegistry.getServiceProviders() return iterator with size zero. For us to follow first scenario we need access to categoryMap of IIORegistry and delete the ImageInputStreamSpi/ ImageOutputStreamSpi but I was not able to find a way to tamper it from test case. If we follow second case FileNotFoundException will be thrown by default eventhough we handle NPE. In the test case we are trying to following third scenario to get stream as null to verify the code changes. As part of collective fix we are throwing IOException which will indicate that we are not able to create required stream. Thanks, Jay -----Original Message----- From: Sergey Bylokhov Sent: Thursday, March 17, 2016 7:27 PM To: Phil Race Cc: Jayathirth D V; 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream On 17.03.16 0:36, Phil Race wrote: > I don't think that is the actual reason here But the test doing exactly this thing -> deregister all spi => in this case according to specification all related methods(read/write/creatImageInputStream/creatImageOutputStream) should return null or false. - it seems likely that there > was some kind of internal error or bad SPI causing this. > So throwing an exception seems more appropriate. the problem was in some of our methods which do not expect null in some places(like stream.close() from the bug description). > And also the bug was originally solely about write(..). > > -phil. > > > On 03/16/2016 01:35 PM, Sergey Bylokhov wrote: >> As far as I understand the createImageInputStream() returns null is >> this stream is unsupported by current plugins via spi. Probably the >> read() method should return null too? >> >> /** >> * Returns a {@code BufferedImage} as the result of decoding >> * a supplied {@code InputStream} with an {@code ImageReader} >> * chosen automatically from among those currently registered. >> * The {@code InputStream} is wrapped in an >> * {@code ImageInputStream}. If no registered >> * {@code ImageReader} claims to be able to read the >> * resulting stream, {@code null} is returned. >> * >> ....... >> * @return a {@code BufferedImage} containing the decoded >> * contents of the input, or {@code null}. >> */ >> public static BufferedImage read(InputStream input) throws >> IOException >> >> >> On 16.03.16 20:29, Philip Race wrote: >>> The test writes out into "test.src". >>> I believe that you should treat that as a "read-only" location. >>> Write to a tempfile (File.createTempFile()) or TESTCLASSES. >>> >>> -phil. >>> >>> On 3/15/16, 10:50 PM, Jayathirth D V wrote: >>>> >>>> Hi Phil,All >>>> >>>> _Please review the following fix in JDK9:_ >>>> >>>> __ >>>> >>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8044289 >>>> >>>> Webrev : http://cr.openjdk.java.net/~jdv/8044289/webrev.00/ >>>> >>>> >>>> Issue : When createImageInputStream() or createImageOutputStream >>>> returns null in ImageIO.read() or ImageIO.write() we are seeing NPE >>>> as it stream is used further without null check. >>>> >>>> Root cause : "stream" is used without checking whether it is null >>>> or not. >>>> >>>> Solution : Handle null pointer of stream and throw IIOException. >>>> >>>> Test case contains all possible scenarios where >>>> createImageInputStream() or createImageOutputStream can return null. >>>> >>>> Thanks, >>>> >>>> Jay >>>> >> >> > -- Best regards, Sergey. From philip.race at oracle.com Thu Mar 17 18:23:41 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 17 Mar 2016 11:23:41 -0700 Subject: [OpenJDK 2D-Dev] [8u-dev] Request for review and approval for bug 8147807: crash in libkcms.so on linux-sparc In-Reply-To: <56C1941F.3040900@oracle.com> References: <56BC9860.7050006@oracle.com> <56BD9576.4090904@oracle.com> <56BDA2AF.9000209@oracle.com> <56C1941F.3040900@oracle.com> Message-ID: <56EAF62D.60102@oracle.com> +1 -phil. On 02/15/2016 01:02 AM, Erik Joelsson wrote: > Looks good. > /Erik > > On 2016-02-12 10:15, Se?n Coffey wrote: >> Approved for jdk8u-dev once you have a peer code review. >> >> Regards, >> Sean. >> >> On 12/02/2016 08:19, Alexey Ivanov wrote: >>> I forgot to add jdk8u-dev list... >>> >>> On 11.02.2016 17:19, Alexey Ivanov wrote: >>>> Hello, >>>> >>>> Could you please review the fix for JDK-8147807 and approve push to >>>> 8u-dev? >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8147807 >>>> Webrev: http://cr.openjdk.java.net/~aivanov/8147807/jdk8/webrev.00/ >>>> >>>> The issue is not relevant to jdk 9. >>>> >>>> The fix just removes kcms service leaving lcms as the only option >>>> which is the default in jdk8. >>>> >>>> >>>> Thanks in advance, >>>> Alexey >>> >> > From Sergey.Bylokhov at oracle.com Thu Mar 17 18:53:44 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 17 Mar 2016 21:53:44 +0300 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream In-Reply-To: <88e50a67-fdd2-4b97-aa19-3ac5d419e2cf@default> References: <99cb1549-30b5-44af-b399-ebed22255cf8@default> <56E997F1.2070605@oracle.com> <56E9C39D.6090701@oracle.com> <56E9D1D5.8090500@oracle.com> <56EAB79C.1080503@oracle.com> <88e50a67-fdd2-4b97-aa19-3ac5d419e2cf@default> Message-ID: <56EAFD38.80604@oracle.com> On 17.03.16 21:14, Jayathirth D V wrote: > There are many places in createImageInputStream() and createImageOutputStream() where it will return null for stream. But when why you change the write/read methods? They should take null into account and work according to specification. If some bogus null returns from createImageInputStream/createImageOutputStream then it should be fixed in these methods. > > So for NPE described in bug to occur there can be multiple paths: > 1) One of the path described in bug is when theRegistry.getServiceProviders() throws IAE and we return null. This is the case when we have no installed spi and should return null/false. > 2) When we pass non-existent file path to ImageIO (as described in http://stackoverflow.com/questions/11153200/with-imageio-write-api-call-i-get-nullpointerexception ). Here we catch FileNotFoundException but still we return stream as null at the end which will cause NPE further. This is same thing described in the bug(about stream.close()). The write method call createImageOutputStream() and got FileNotFoundException. This exception should be propagated to the user, but it is replaced in the finally block, because we try to close the stream=null. So the fix for this particular case is to check the stream to null in finally, No? > 3) When we don't support the provider and theRegistry.getServiceProviders() return iterator with size zero. This means that our providers do not support this case, and we should return null/false. > > For us to follow first scenario we need access to categoryMap of IIORegistry and delete the ImageInputStreamSpi/ ImageOutputStreamSpi but I was not able to find a way to tamper it from test case. If we follow second case FileNotFoundException will be thrown by default eventhough we handle NPE. But you change the code and we now contradicts the specification, in your case the test should expect false/null from write()/read(). > > In the test case we are trying to following third scenario to get stream as null to verify the code changes. To catch the bogus null we should try to use another approach, or change the spec. But it seems all null values above are correct, we should be ready for them. > > As part of collective fix we are throwing IOException which will indicate that we are not able to create required stream. > > Thanks, > Jay > > -----Original Message----- > From: Sergey Bylokhov > Sent: Thursday, March 17, 2016 7:27 PM > To: Phil Race > Cc: Jayathirth D V; 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream > > On 17.03.16 0:36, Phil Race wrote: >> I don't think that is the actual reason here > > But the test doing exactly this thing -> deregister all spi => in this case according to specification all related > methods(read/write/creatImageInputStream/creatImageOutputStream) should return null or false. > > - it seems likely that there >> was some kind of internal error or bad SPI causing this. >> So throwing an exception seems more appropriate. > > the problem was in some of our methods which do not expect null in some places(like stream.close() from the bug description). > >> And also the bug was originally solely about write(..). >> >> -phil. >> >> >> On 03/16/2016 01:35 PM, Sergey Bylokhov wrote: >>> As far as I understand the createImageInputStream() returns null is >>> this stream is unsupported by current plugins via spi. Probably the >>> read() method should return null too? >>> >>> /** >>> * Returns a {@code BufferedImage} as the result of decoding >>> * a supplied {@code InputStream} with an {@code ImageReader} >>> * chosen automatically from among those currently registered. >>> * The {@code InputStream} is wrapped in an >>> * {@code ImageInputStream}. If no registered >>> * {@code ImageReader} claims to be able to read the >>> * resulting stream, {@code null} is returned. >>> * >>> ....... >>> * @return a {@code BufferedImage} containing the decoded >>> * contents of the input, or {@code null}. >>> */ >>> public static BufferedImage read(InputStream input) throws >>> IOException >>> >>> >>> On 16.03.16 20:29, Philip Race wrote: >>>> The test writes out into "test.src". >>>> I believe that you should treat that as a "read-only" location. >>>> Write to a tempfile (File.createTempFile()) or TESTCLASSES. >>>> >>>> -phil. >>>> >>>> On 3/15/16, 10:50 PM, Jayathirth D V wrote: >>>>> >>>>> Hi Phil,All >>>>> >>>>> _Please review the following fix in JDK9:_ >>>>> >>>>> __ >>>>> >>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8044289 >>>>> >>>>> Webrev : http://cr.openjdk.java.net/~jdv/8044289/webrev.00/ >>>>> >>>>> >>>>> Issue : When createImageInputStream() or createImageOutputStream >>>>> returns null in ImageIO.read() or ImageIO.write() we are seeing NPE >>>>> as it stream is used further without null check. >>>>> >>>>> Root cause : "stream" is used without checking whether it is null >>>>> or not. >>>>> >>>>> Solution : Handle null pointer of stream and throw IIOException. >>>>> >>>>> Test case contains all possible scenarios where >>>>> createImageInputStream() or createImageOutputStream can return null. >>>>> >>>>> Thanks, >>>>> >>>>> Jay >>>>> >>> >>> >> > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From philip.race at oracle.com Thu Mar 17 19:54:25 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 17 Mar 2016 12:54:25 -0700 Subject: [OpenJDK 2D-Dev] [9] Review request for 8073400: Some Monospaced logical fonts have a different width In-Reply-To: <56C46F35.6030107@oracle.com> References: <56977953.10604@oracle.com> <56BB9CAC.3050408@oracle.com> <56C46F35.6030107@oracle.com> Message-ID: <56EB0B71.8090000@oracle.com> I think you are still waiting on i18n to reply here since the exclusion ranges are mainly used for ensuring that the glyphs come from the right font which is mainly for locale reasons. If i18n see no problems then I am OK with this. -phil. On 02/17/2016 05:01 AM, dmitry markov wrote: > Hello Phil, > > Thank you for the review. > > According to unicode table the characters u201c and u201d are in > General Punctuation block, see > http://unicode-table.com/en/blocks/general-punctuation/ > Many characters from this block are not supported by Courier New. So I > do not think we need to remove the whole block from the exclusion > range, since it will not have any effect except few characters like > u201c and u201d. That's why I removed such small characters set (u2018 > - u201F) from the exclusion range, but I can change this if it is > necessary. > > At the same time the characters set (u2018 - u201F) is supported by > Arial and Times New Roman which are mapped to other logical fonts. The > adjusted exclusion range seems 'quite safe' from this point of view. > So I do not think we need to modify any code such as FontConfiguration > class and so on to apply these changes only to monospaced fonts. > Please correct me if I am wrong. > > Adding i18n-dev. > > Internationalization team, > Could you review a small change in windows.fontconfig.properties, please? > > bug: https://bugs.openjdk.java.net/browse/JDK-8073400 > webrev: http://cr.openjdk.java.net/~dmarkov/8073400/jdk9/webrev.00/ > > Problem description: > On Windows some characters (in particular, left and right double > quotation marks) have width differing from other characters' widths, > when Monospaced logical font is used. > The default monospaced font for windows platform is Courier New. It > contains the desired characters, (i.e. '\u201c' and '\u201d'). However > the characters are in 'exclusion ranges' for this font due to settings > in windows.fontconfig.properties. So when we try to obtain glyphs for > these characters and calculate their bounds, we fallback to another > font (Lucida) and use its glyphs. > > Fix: > Remove the following set of characters u2018 - u201F from the > exclusion ranges. > > Thank you in advance, > Dmitry > On 10/02/2016 23:25, Phil Race wrote: >> I expect the exclusion range is there for a reason. >> I think (guess) that the intent was that where there is a sequence >> like this : >> >> sequence.sansserif.x-windows-950=alphabetic,chinese-ms950,dingbats,symbol,chinese-ms950-extb >> >> >> then those code points should come from the chinese font. >> >> Perhaps your adjusted exclusion range should apply only to the >> monospaced fonts >> which are already putting the locale font first. >> >> Unfortunately it doesn't appear that this is possible with the >> supported syntax >> https://docs.oracle.com/javase/1.5.0/docs/guide/intl/fontconfig.html#windows >> >> >> i.e it supports selection only by charactersubsetname, not also by >> logicalfontname. >> But you should check the code to see if this is in fact the case. >> There may need to be a non-ideal decision or a revision to that spec. >> and its >> supporting code. >> >> And why be so narrow ? It seems you have made an even odder situation >> in having just those two code points 'un'-excluded. >> The argument that those were the two a customer complained about does >> not >> hold up very well. >> >> I think you should also run this whole change+discussion by i18n-dev .. >> >> >> -phil. >> >> On 01/14/2016 02:32 AM, dmitry markov wrote: >>> Hello, >>> >>> Could you review the fix for jdk9, please? >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8073400 >>> webrev: http://cr.openjdk.java.net/~dmarkov/8073400/jdk9/webrev.00/ >>> >>> Problem description: >>> On Windows some characters (in particular, left and right double >>> quotation marks) have width differing from other characters' widths, >>> when Monospaced logical font is used. >>> The default monospaced font for windows platform is Courier New. It >>> contains the desired characters, (i.e. '\u201c' and '\u201d'). >>> However the characters are in 'exclusion ranges' for this font due >>> to settings in windows.fontconfig.properties. So when we try to >>> obtain glyphs for these characters and calculate their bounds, we >>> fallback to another font (Lucida) and use its glyphs. >>> >>> Fix: >>> Remove the following set of characters u2018 - u201F from the >>> exclusion ranges. >>> >>> Thanks, >>> Dmitry >> > From philip.race at oracle.com Thu Mar 17 20:05:09 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 17 Mar 2016 13:05:09 -0700 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8146042 Offscreen rendering is different from onscreen one In-Reply-To: <56D635E2.6000706@oracle.com> References: <5697E44B.2040100@oracle.com> <5697E7B1.2080207@oracle.com> <569898C4.1030404@oracle.com> <56D635E2.6000706@oracle.com> Message-ID: <56EB0DF5.6050803@oracle.com> Semyon, Any update on this ? FWIW I used jprt to build your patch as I am having windows build problems and it passed on my ATI card. -phil. On 03/01/2016 04:37 PM, Sergey Bylokhov wrote: > On 15.01.16 9:59, Semyon Sadetsky wrote: >> Hi Phil & Sergey, >> >> I have integrated Intel GPU i5 and cannot test other hardware. >> On Mac's retina display the screen capture doesn't return exact pixel to >> pixel image but the scaled one. So Mac platform should be excluded from >> testing: >> http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.01/ > > I run the latest test(webrev.03) on my nvidia card, and it fails after > the fix, but pass before =(. I have no ati to check. Also I cannot > check the fix on intel card, because I cannot enable d3d on it. > >> >> --Semyon >> >> On 1/14/2016 9:23 PM, Phil Race wrote: >>> This fudge factor was last adjusted in >>> https://bugs.openjdk.java.net/browse/JDK-6597822 >>> way back before the D3D pipeline was released and the comments seem to >>> indicate that >>> there was a fair amount of testing on different hardware. >>> >>> I don't know why this seems to be in un-specified hardware-dependent >>> territory but >>> it seems quite possible that this could just as easily introduce a >>> different artifact >>> on some other hardware. >>> >>> What exactly are you testing on ? And I think it needs to include at >>> least one Nvidia >>> and one AMD/ATI card. >>> >>> -phil. >>> >>> On 1/14/2016 10:09 AM, Semyon Sadetsky wrote: >>>> Hello, >>>> >>>> Please review the fix for jdk9. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8146042 >>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.00/ >>>> >>>> The root cause is incorrect coordinate rounding in D3D renderer. To >>>> fix the issue one of fudge factors was adjusted. >>>> >>>> Another issue mentioning in the JIRA ticket is taken out as a >>>> separate bug. >>>> >>>> --Semyon >>>> >>> >> > > From philip.race at oracle.com Thu Mar 17 22:49:09 2016 From: philip.race at oracle.com (Philip Race) Date: Thu, 17 Mar 2016 15:49:09 -0700 Subject: [OpenJDK 2D-Dev] CFV: New 2D Group Member: Alexander Scherbatiy Message-ID: <56EB3465.7070709@oracle.com> I hereby nominate Alexander Scherbatiy to membership in the 2D group. Alexander Scherbatiy is a current member of the Swing group and has contributed almost 200 changesets to OpenJDK :- http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000&rev=author%28%22alexsch%22%29 Increasingly, and particularly over the last 18 months he has made many of these significant contributions in the 2D area notably hi-dpi graphics support and so I hereby nominate Alexander to membership of the 2D group Votes are due by 1st April 2016 //Only current Members of the 2D Group [1] are eligible to vote on this nomination. For Lazy Consensus voting instructions, see [2]. [1] http://openjdk.java.net/census#2d [2] http://openjdk.java.net/groups/#member-vote -phil -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Fri Mar 18 00:37:15 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 17 Mar 2016 17:37:15 -0700 Subject: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: Antialiased text on translucent backgrounds gets bright artifacts In-Reply-To: <63d69ba8-d5cf-4697-bb5c-f51aaaa8c427@default> References: <63d69ba8-d5cf-4697-bb5c-f51aaaa8c427@default> Message-ID: <56EB4DBB.9080802@oracle.com> Hi Prahalad, This basically boils down to "alpha blending math needs to be performed in premultiplied form" and the existing code was not doing that. Your changes do add a pre-multiplication step to the math in two places - when you mix the src alpha and the glyph alpha at the top of the macro, and again when you do the Multiply(dst, dstA, dst) step in the middle. In that sense, the new math is correct. However, it is not the optimal way to implement this. In particular, the macro used here to load the data from the destination is the one that loads it into 4 ARGB non-premultiplied values. If the destination is non-PRE, then your added multiply step is exactly what is needed, but it could be combined with the multiply that will happen later in the blending equation, so it is an added step rather than a fixed fraction in the existing MultMultAdd parameters. Additionally, if the destination is already PRE, then the macro being used to load the dst pixel data there will have done a divide step to divide out the alpha from the destination, only to have you reverse that math with your new Multiply() step. That's a lot of math to end up with a NOP. The MUL8 you added for the srcA and glyph value is needed, that change is good. Since it is common for glyph pixels to have zero alpha, you might want to test the glyph alpha for 0 and skip the pixel before you do the multiply, though. This would add one more if, but it would be a common case. The trickier part is to load the destination components without un-premultiplying them. Unfortunately there is no "Load...ToArgbPre" macro to parallel the Load macro used in the function. Perhaps there should be, but you'd still end up with an extra multiply step as I mentioned above because you can fold the premultiplication of the dst data into the MultMultAdd by carefully choosing the parameters you use in the math there. The good news is that the way that the SRCOVER_MASKFILL uses the various type-specific macros works around this a bit and minimizes the number of multiplies that happen. You could check out DEFINE_SRCOVER_MASKFILL and see how it works in the case where pMask is not null (pMask is an alpha mask with values very similar to the glyphAA data). Modeling this code on that code would correct the math and minimize it as well... ...jim On 3/17/16 3:00 AM, Prahalad Kumar Narayanan wrote: > Hello Everyone on Java2D Group > > Good day to you. > > Herewith, I 'm sharing the webrev for two identical Java2D Bugs. > > Bug ID : JDK-8015070 > > Title : Antialiased text on translucent backgrounds gets > bright artifacts > > Link : https://bugs.openjdk.java.net/browse/JDK-8015070 > > Bug ID : JDK-8013564 ( currently closed as duplicate ) > > Title : Font rendering anti-aliasing in translucent > BufferedImages broken > > Link : https://bugs.openjdk.java.net/browse/JDK-8013564 > > Webrev Link : > http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.00/ > > Quick Summary on Bugs : > > ```````````````````````````````````````````````` > > 1. Artifacts appear on Edges of text characters when anti-aliased text > is drawn on Translucent background > > 2. The issue is reproducible on all platforms - windows, linux and mac os. > > 3. Besides, the issue is reproduced with the commonly used pixel > format- 4ByteArgb. > > Root Cause & Solution : > > ```````````````````````````````````````````````` > > 1. The Macro: GlyphListAABlend4ByteArgb in File: LoopMacros.h uses the > standard blending algorithm > > dstColor = [ srcColor * glyphAlpha + dstColor * (1 - > glyphAlpha) ] / dstAlpha > > 2. The above equation works only when the srcColor and dstColor are Opaque. > > 3. When srcColor and dstColor are Translucent, their alphaComponent > will influence the visibility of the color, and visibility of the color > below. > > 4. The new set of calculations for blending Translucent source and > destination colors is given as > > resAlpha = 1 - ((1 - srcAlpha) * (1 - dstAlpha)) > > resColor = [ srcColor * srcAlpha + dstColor * dstAlpha * (1 - > srcAlpha) ] / resAlpha > > 5. Reference text for the equation: > https://en.wikipedia.org/wiki/Alpha_compositing > > 6. With the above modification to the blending logic, the artifacts do > not appear and issues are fixed. > > Jtreg & Jprt Results : > > ```````````````````````````````````````````````` > > 1. A simple test-file: AADrawStringArtifact.java has been created to be > a part of jtreg test cases. > > The test file is well commented to explain - nature of > artifact and how the test tries to identify them. > > As required, the test case fails with Jdk 7, Jdk 8 and > succeeds with Jdk 9-internal (built with changes for the bug fix) > > 2. The changes to blending logic lies within > java.desktop/src/share/native/... > > Henceforth, JPRT was used to ensure successful build across > all supported platforms > > Jprt Job Link : > http://scaaa637.us.oracle.com//archive/2016/03/2016-03-17-072001.prahnara-linux.client > > The build succeeds on all platforms. > > Kindly review the webrev link and provide your views and suggestions. > > Webrev Link : > http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.00/ > > If the changes look good, we could take up the changes for source checkin. > > Thank you for your time in review > > Have a good day > > Prahalad N. > From james.graham at oracle.com Fri Mar 18 00:44:54 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 17 Mar 2016 17:44:54 -0700 Subject: [OpenJDK 2D-Dev] RFR 8144938: Handle properly coordinate overflow in Marlin Renderer In-Reply-To: References: <56E2159E.8000209@oracle.com> <56E22734.7020707@oracle.com> <56E33249.2030300@oracle.com> <56E74A98.30503@oracle.com> <56E89082.5040703@oracle.com> <56E9FF2C.4020308@oracle.com> Message-ID: <56EB4F86.7000002@oracle.com> Hi Laurent, That looks fine. If the subPathStarted changes are the only changes then it's good to go. If there was some other change that I missed, let me know so I can review it as well. One curiosity - in the test case, why are there 3 for loops that perform exactly one pass? (lines 134, 221, 282) I'm guessing that maybe in a former life this code may have been part of a performance suite or something? It's not a bug, just an odd bit of code. You can delete them if you want, but I don't need to see a review of that... ...jim On 3/17/16 10:15 AM, Laurent Bourg?s wrote: > Hi Jim, > > Here is the updated webrev using your approach: > http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144938.4/ > > It is more close to 2nd webrev as it does not set subpathStarted to > false in SEG_CLOSE case. > > Laurent > > 2016-03-17 1:49 GMT+01:00 Jim Graham >: > > Hi Laurent, > > I'm not sure why you added the pathClosed variable back. Before > your fix we used to rely on all of the downstream consumers > correctly implementing the case of CLOSE followed by a non-MOVE > command so specifically enforcing a MOVE here should be unnecessary > and just complicates the code...? > > ...jim > > From prasanta.sadhukhan at oracle.com Fri Mar 18 05:44:08 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Fri, 18 Mar 2016 11:14:08 +0530 Subject: [OpenJDK 2D-Dev] Review Request for JDK-6185114: Undefined Exception in SampleModel, method createCompatibleSampleModel In-Reply-To: <84527e90-602d-4c04-94a8-69eda977ff7e@default> References: <06287367-8efc-4f33-b16a-b7f898b53259@default> <56E93B85.2060208@oracle.com> <84527e90-602d-4c04-94a8-69eda977ff7e@default> Message-ID: <56EB95A8.8040805@oracle.com> Looks ok to me. Regards Prasanta On 3/16/2016 5:15 PM, Ajit Ghaisas wrote: > > Hi, > > I have corrected the typo and modified the failure message string. > > Please review the updated webrev. > > http://cr.openjdk.java.net/~arapte/ajit/6185114/webrev.01/ > > > Regards, > > Ajit > > *From:*prasanta sadhukhan > *Sent:* Wednesday, March 16, 2016 4:25 PM > *To:* Ajit Ghaisas; 2d-dev; Philip Race > *Subject:* Re: Review Request for JDK-6185114: Undefined Exception in > SampleModel, method createCompatibleSampleModel > > Fix Looks ok. Test failure message does not say what it is failing > for. Maybe you can mention "Expected IAE count <>, got IAE count <>" . > lune 52 has a typo heiht > > Regards > Prasanta > > On 3/16/2016 3:57 PM, Ajit Ghaisas wrote: > > Hi, > > Bug : https://bugs.openjdk.java.net/browse/JDK-6185114 > > Issue : Undefined Exception in SampleModel, method > createCompatibleSampleModel > > Root Cause : > > The SampleModel constructor documentation says ? it throws the > IllegalArgumentException if the product of width and height > parameters is greater than Integer.MAX_VALUE. > > The condition for this check is incorrectly checks for ?greater > than equal to? where it should be only ?greater than?. > > Fix : > > Corrected the erroneous condition in below webrev and added a test. > > http://cr.openjdk.java.net/~arapte/ajit/6185114/webrev.00/ > > > Regards, > > Ajit > -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Fri Mar 18 06:12:21 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 18 Mar 2016 09:12:21 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8146042 Offscreen rendering is different from onscreen one In-Reply-To: <56EB0DF5.6050803@oracle.com> References: <5697E44B.2040100@oracle.com> <5697E7B1.2080207@oracle.com> <569898C4.1030404@oracle.com> <56D635E2.6000706@oracle.com> <56EB0DF5.6050803@oracle.com> Message-ID: <56EB9C45.4020704@oracle.com> Hi Phil, Sergey wrote it fails on nvidia cards. I could play with fudge factors values but I don't have nvidia based video to test. --Semyon On 3/17/2016 11:05 PM, Phil Race wrote: > Semyon, > > Any update on this ? > FWIW I used jprt to build your patch as I am having windows build > problems and > it passed on my ATI card. > > -phil. > > > On 03/01/2016 04:37 PM, Sergey Bylokhov wrote: >> On 15.01.16 9:59, Semyon Sadetsky wrote: >>> Hi Phil & Sergey, >>> >>> I have integrated Intel GPU i5 and cannot test other hardware. >>> On Mac's retina display the screen capture doesn't return exact >>> pixel to >>> pixel image but the scaled one. So Mac platform should be excluded from >>> testing: >>> http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.01/ >> >> I run the latest test(webrev.03) on my nvidia card, and it fails >> after the fix, but pass before =(. I have no ati to check. Also I >> cannot check the fix on intel card, because I cannot enable d3d on it. >> >>> >>> --Semyon >>> >>> On 1/14/2016 9:23 PM, Phil Race wrote: >>>> This fudge factor was last adjusted in >>>> https://bugs.openjdk.java.net/browse/JDK-6597822 >>>> way back before the D3D pipeline was released and the comments seem to >>>> indicate that >>>> there was a fair amount of testing on different hardware. >>>> >>>> I don't know why this seems to be in un-specified hardware-dependent >>>> territory but >>>> it seems quite possible that this could just as easily introduce a >>>> different artifact >>>> on some other hardware. >>>> >>>> What exactly are you testing on ? And I think it needs to include at >>>> least one Nvidia >>>> and one AMD/ATI card. >>>> >>>> -phil. >>>> >>>> On 1/14/2016 10:09 AM, Semyon Sadetsky wrote: >>>>> Hello, >>>>> >>>>> Please review the fix for jdk9. >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8146042 >>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.00/ >>>>> >>>>> The root cause is incorrect coordinate rounding in D3D renderer. To >>>>> fix the issue one of fudge factors was adjusted. >>>>> >>>>> Another issue mentioning in the JIRA ticket is taken out as a >>>>> separate bug. >>>>> >>>>> --Semyon >>>>> >>>> >>> >> >> > From jayathirth.d.v at oracle.com Fri Mar 18 08:52:36 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Fri, 18 Mar 2016 01:52:36 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream In-Reply-To: <56EAFD38.80604@oracle.com> References: <99cb1549-30b5-44af-b399-ebed22255cf8@default> <56E997F1.2070605@oracle.com> <56E9C39D.6090701@oracle.com> <56E9D1D5.8090500@oracle.com> <56EAB79C.1080503@oracle.com> <88e50a67-fdd2-4b97-aa19-3ac5d419e2cf@default> <56EAFD38.80604@oracle.com> Message-ID: Hi Sergey, Thanks for your inputs. Indeed all the null values returned by createImageInputStream() and createImageInputStream() are valid only. I went through the code more and found that there is no need for fix in ImageIO.read() methods as null stream is handled in read(ImageInputStream stream) which is called by all the remaining read() API's through IAE. So i can remove the changes made in ImageIO.read() functions. Also istream is closed in finally block of read(url). For ImageIO.write(File) & ImageIO.write(OutputStream) NPE we have two approaches for fix: 1) Keep the present changes of throwing IOException when stream is null and change the throw clause of write() spec mentioning: "IOException - if an error occurs during writing or not able to create required ImageOutputStream" 2) Remove the present changes and handle null in doWrite() method by returning false when stream is null & add code in finally block to close the stream only when stream is not null. Along with this we can also change Returns clause of spec to mention that write() might return false when we are not able to create ImageOutputStream. private static boolean doWrite(RenderedImage im, ImageWriter writer, ImageOutputStream output) throws IOException { if (writer == null) { return false; } + if (output == null) { + return false; + } try { return doWrite(im, writer, stream); } finally { + if (stream != null) stream.close(); } Returns : false if no appropriate writer is found or not able to create required ImageOutputStream. Please let me know your inputs. Thanks, Jay -----Original Message----- From: Sergey Bylokhov Sent: Friday, March 18, 2016 12:24 AM To: Jayathirth D V Cc: 2d-dev at openjdk.java.net; Philip Race Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream On 17.03.16 21:14, Jayathirth D V wrote: > There are many places in createImageInputStream() and createImageOutputStream() where it will return null for stream. But when why you change the write/read methods? They should take null into account and work according to specification. If some bogus null returns from createImageInputStream/createImageOutputStream then it should be fixed in these methods. > > So for NPE described in bug to occur there can be multiple paths: > 1) One of the path described in bug is when theRegistry.getServiceProviders() throws IAE and we return null. This is the case when we have no installed spi and should return null/false. > 2) When we pass non-existent file path to ImageIO (as described in http://stackoverflow.com/questions/11153200/with-imageio-write-api-call-i-get-nullpointerexception ). Here we catch FileNotFoundException but still we return stream as null at the end which will cause NPE further. This is same thing described in the bug(about stream.close()). The write method call createImageOutputStream() and got FileNotFoundException. This exception should be propagated to the user, but it is replaced in the finally block, because we try to close the stream=null. So the fix for this particular case is to check the stream to null in finally, No? > 3) When we don't support the provider and theRegistry.getServiceProviders() return iterator with size zero. This means that our providers do not support this case, and we should return null/false. > > For us to follow first scenario we need access to categoryMap of IIORegistry and delete the ImageInputStreamSpi/ ImageOutputStreamSpi but I was not able to find a way to tamper it from test case. If we follow second case FileNotFoundException will be thrown by default eventhough we handle NPE. But you change the code and we now contradicts the specification, in your case the test should expect false/null from write()/read(). > > In the test case we are trying to following third scenario to get stream as null to verify the code changes. To catch the bogus null we should try to use another approach, or change the spec. But it seems all null values above are correct, we should be ready for them. > > As part of collective fix we are throwing IOException which will indicate that we are not able to create required stream. > > Thanks, > Jay > > -----Original Message----- > From: Sergey Bylokhov > Sent: Thursday, March 17, 2016 7:27 PM > To: Phil Race > Cc: Jayathirth D V; 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream > > On 17.03.16 0:36, Phil Race wrote: >> I don't think that is the actual reason here > > But the test doing exactly this thing -> deregister all spi => in this case according to specification all related > methods(read/write/creatImageInputStream/creatImageOutputStream) should return null or false. > > - it seems likely that there >> was some kind of internal error or bad SPI causing this. >> So throwing an exception seems more appropriate. > > the problem was in some of our methods which do not expect null in some places(like stream.close() from the bug description). > >> And also the bug was originally solely about write(..). >> >> -phil. >> >> >> On 03/16/2016 01:35 PM, Sergey Bylokhov wrote: >>> As far as I understand the createImageInputStream() returns null is >>> this stream is unsupported by current plugins via spi. Probably the >>> read() method should return null too? >>> >>> /** >>> * Returns a {@code BufferedImage} as the result of decoding >>> * a supplied {@code InputStream} with an {@code ImageReader} >>> * chosen automatically from among those currently registered. >>> * The {@code InputStream} is wrapped in an >>> * {@code ImageInputStream}. If no registered >>> * {@code ImageReader} claims to be able to read the >>> * resulting stream, {@code null} is returned. >>> * >>> ....... >>> * @return a {@code BufferedImage} containing the decoded >>> * contents of the input, or {@code null}. >>> */ >>> public static BufferedImage read(InputStream input) throws >>> IOException >>> >>> >>> On 16.03.16 20:29, Philip Race wrote: >>>> The test writes out into "test.src". >>>> I believe that you should treat that as a "read-only" location. >>>> Write to a tempfile (File.createTempFile()) or TESTCLASSES. >>>> >>>> -phil. >>>> >>>> On 3/15/16, 10:50 PM, Jayathirth D V wrote: >>>>> >>>>> Hi Phil,All >>>>> >>>>> _Please review the following fix in JDK9:_ >>>>> >>>>> __ >>>>> >>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8044289 >>>>> >>>>> Webrev : http://cr.openjdk.java.net/~jdv/8044289/webrev.00/ >>>>> >>>>> >>>>> Issue : When createImageInputStream() or createImageOutputStream >>>>> returns null in ImageIO.read() or ImageIO.write() we are seeing NPE >>>>> as it stream is used further without null check. >>>>> >>>>> Root cause : "stream" is used without checking whether it is null >>>>> or not. >>>>> >>>>> Solution : Handle null pointer of stream and throw IIOException. >>>>> >>>>> Test case contains all possible scenarios where >>>>> createImageInputStream() or createImageOutputStream can return null. >>>>> >>>>> Thanks, >>>>> >>>>> Jay >>>>> >>> >>> >> > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Fri Mar 18 09:02:25 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Fri, 18 Mar 2016 14:32:25 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8042713, , [macosx] Print dialog does not update attribute set with page range Message-ID: <56EBC421.7050109@oracle.com> Hi Phil, Please review a fix for bug: https://bugs.openjdk.java.net/browse/JDK-8042713 webrev: http://cr.openjdk.java.net/~psadhukhan/8042713/webrev.00/ The OS X platform print dialog has an option to set the page ranges. If this is done it ought to be reported back in the AttributeSet. but it was found that the page range attribute is not reported back . This is because nsPrintInfoToJavaPrinterJob() does not call correct Java setxxxAttributes methods to set the attributes. I added the corresponding setPageRangeAttribute method along with setCopiesAttribute method to report back the "page range" and "copies" in AttributeSet. Regards Prasanta From bourges.laurent at gmail.com Fri Mar 18 16:52:36 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Fri, 18 Mar 2016 17:52:36 +0100 Subject: [OpenJDK 2D-Dev] RFR 8144938: Handle properly coordinate overflow in Marlin Renderer In-Reply-To: <56EB4F86.7000002@oracle.com> References: <56E2159E.8000209@oracle.com> <56E22734.7020707@oracle.com> <56E33249.2030300@oracle.com> <56E74A98.30503@oracle.com> <56E89082.5040703@oracle.com> <56E9FF2C.4020308@oracle.com> <56EB4F86.7000002@oracle.com> Message-ID: Jim, Here is a final webrev (for archive): http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144938.5/ Changes: - remove loops in CrashNaNTest Hope it is ready to go ! I need another reviewer, please. 2016-03-18 1:44 GMT+01:00 Jim Graham : > Hi Laurent, > > That looks fine. If the subPathStarted changes are the only changes then > it's good to go. If there was some other change that I missed, let me know > so I can review it as well. > No this webrev had only changes in MRE.pathToLoop() you reviewed. > > One curiosity - in the test case, why are there 3 for loops that perform > exactly one pass? (lines 134, 221, 282) I'm guessing that maybe in a > former life this code may have been part of a performance suite or > something? It's not a bug, just an odd bit of code. You can delete them > if you want, but I don't need to see a review of that... > Fixed, now. Cheers, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From naoto.sato at oracle.com Fri Mar 18 18:09:42 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 18 Mar 2016 11:09:42 -0700 Subject: [OpenJDK 2D-Dev] [9] Review request for 8073400: Some Monospaced logical fonts have a different width In-Reply-To: <56EB0B71.8090000@oracle.com> References: <56977953.10604@oracle.com> <56BB9CAC.3050408@oracle.com> <56C46F35.6030107@oracle.com> <56EB0B71.8090000@oracle.com> Message-ID: <56EC4466.8020506@oracle.com> So this fix will replace those left-right quotation marks in those CJK locales from locale-specific font to "alphabetic", right? I don't know much about the history (and personally I am fine with the fix), but should we consult with the globalization team? Naoto On 3/17/16 12:54 PM, Phil Race wrote: > I think you are still waiting on i18n to reply here since the exclusion > ranges > are mainly used for ensuring that the glyphs come from the right font which > is mainly for locale reasons. If i18n see no problems then I am OK with > this. > > -phil. > > On 02/17/2016 05:01 AM, dmitry markov wrote: >> Hello Phil, >> >> Thank you for the review. >> >> According to unicode table the characters u201c and u201d are in >> General Punctuation block, see >> http://unicode-table.com/en/blocks/general-punctuation/ >> Many characters from this block are not supported by Courier New. So I >> do not think we need to remove the whole block from the exclusion >> range, since it will not have any effect except few characters like >> u201c and u201d. That's why I removed such small characters set (u2018 >> - u201F) from the exclusion range, but I can change this if it is >> necessary. >> >> At the same time the characters set (u2018 - u201F) is supported by >> Arial and Times New Roman which are mapped to other logical fonts. The >> adjusted exclusion range seems 'quite safe' from this point of view. >> So I do not think we need to modify any code such as FontConfiguration >> class and so on to apply these changes only to monospaced fonts. >> Please correct me if I am wrong. >> >> Adding i18n-dev. >> >> Internationalization team, >> Could you review a small change in windows.fontconfig.properties, please? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8073400 >> webrev: http://cr.openjdk.java.net/~dmarkov/8073400/jdk9/webrev.00/ >> >> Problem description: >> On Windows some characters (in particular, left and right double >> quotation marks) have width differing from other characters' widths, >> when Monospaced logical font is used. >> The default monospaced font for windows platform is Courier New. It >> contains the desired characters, (i.e. '\u201c' and '\u201d'). However >> the characters are in 'exclusion ranges' for this font due to settings >> in windows.fontconfig.properties. So when we try to obtain glyphs for >> these characters and calculate their bounds, we fallback to another >> font (Lucida) and use its glyphs. >> >> Fix: >> Remove the following set of characters u2018 - u201F from the >> exclusion ranges. >> >> Thank you in advance, >> Dmitry >> On 10/02/2016 23:25, Phil Race wrote: >>> I expect the exclusion range is there for a reason. >>> I think (guess) that the intent was that where there is a sequence >>> like this : >>> >>> sequence.sansserif.x-windows-950=alphabetic,chinese-ms950,dingbats,symbol,chinese-ms950-extb >>> >>> >>> then those code points should come from the chinese font. >>> >>> Perhaps your adjusted exclusion range should apply only to the >>> monospaced fonts >>> which are already putting the locale font first. >>> >>> Unfortunately it doesn't appear that this is possible with the >>> supported syntax >>> https://docs.oracle.com/javase/1.5.0/docs/guide/intl/fontconfig.html#windows >>> >>> >>> i.e it supports selection only by charactersubsetname, not also by >>> logicalfontname. >>> But you should check the code to see if this is in fact the case. >>> There may need to be a non-ideal decision or a revision to that spec. >>> and its >>> supporting code. >>> >>> And why be so narrow ? It seems you have made an even odder situation >>> in having just those two code points 'un'-excluded. >>> The argument that those were the two a customer complained about does >>> not >>> hold up very well. >>> >>> I think you should also run this whole change+discussion by i18n-dev .. >>> >>> >>> -phil. >>> >>> On 01/14/2016 02:32 AM, dmitry markov wrote: >>>> Hello, >>>> >>>> Could you review the fix for jdk9, please? >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8073400 >>>> webrev: http://cr.openjdk.java.net/~dmarkov/8073400/jdk9/webrev.00/ >>>> >>>> Problem description: >>>> On Windows some characters (in particular, left and right double >>>> quotation marks) have width differing from other characters' widths, >>>> when Monospaced logical font is used. >>>> The default monospaced font for windows platform is Courier New. It >>>> contains the desired characters, (i.e. '\u201c' and '\u201d'). >>>> However the characters are in 'exclusion ranges' for this font due >>>> to settings in windows.fontconfig.properties. So when we try to >>>> obtain glyphs for these characters and calculate their bounds, we >>>> fallback to another font (Lucida) and use its glyphs. >>>> >>>> Fix: >>>> Remove the following set of characters u2018 - u201F from the >>>> exclusion ranges. >>>> >>>> Thanks, >>>> Dmitry >>> >> > From philip.race at oracle.com Fri Mar 18 19:21:08 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 18 Mar 2016 12:21:08 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8042713, , [macosx] Print dialog does not update attribute set with page range In-Reply-To: <56EBC421.7050109@oracle.com> References: <56EBC421.7050109@oracle.com> Message-ID: <56EC5524.8040601@oracle.com> The bug report seems to be lacking a proper (any) evaluation. It is probably not accurate to say it did not call the "correct" methods since the problem is actually that there was no method that did this and you needed to add them and make sure they also did what they in turn called what native had been calling after setting the attribute. The change itself seems to be mimicing what happens in Windows printing code, ie WPrinterJob.setRangeCopiesAttribute(..) ? Is this intentional ? If so that would have been useful to point out so I did not need to hunt it down. Looking at that code I see that is does a couple of other things (1) has a way of indicating an explicitly set number of copies vs default copies, (2) accepts a boolean indicating if in the dialog a range was actually requested. It looks like in the OSX code we only make the upcall in that case, but I need you to verify that all this works as it is supposed to. Also native used to use a zero-based index and you have changed that without commenting on it. First it is still zero-based in the initialisation and may not always be changed. Secondly if you want 1-based then you seem to have a problem as the new Java method calls setPageRange(from, to); with the 1-based values and that seems to be the method which accepted the zero-based values. This seems very fishy. -phil. On 03/18/2016 02:02 AM, prasanta sadhukhan wrote: > Hi Phil, > > Please review a fix for > bug: https://bugs.openjdk.java.net/browse/JDK-8042713 > webrev: http://cr.openjdk.java.net/~psadhukhan/8042713/webrev.00/ > > The OS X platform print dialog has an option to set the page ranges. > If this is done it ought to be reported back in the AttributeSet. > but it was found that the page range attribute is not reported back . > > This is because nsPrintInfoToJavaPrinterJob() does not call correct > Java setxxxAttributes methods to set the attributes. > > I added the corresponding setPageRangeAttribute method along with > setCopiesAttribute method to report back the "page range" and "copies" > in AttributeSet. > > Regards > Prasanta From philip.race at oracle.com Fri Mar 18 20:17:17 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 18 Mar 2016 13:17:17 -0700 Subject: [OpenJDK 2D-Dev] [9] Review request for 8073400: Some Monospaced logical fonts have a different width In-Reply-To: <56EC4466.8020506@oracle.com> References: <56977953.10604@oracle.com> <56BB9CAC.3050408@oracle.com> <56C46F35.6030107@oracle.com> <56EB0B71.8090000@oracle.com> <56EC4466.8020506@oracle.com> Message-ID: <56EC624D.60700@oracle.com> I doubt that the G11N team would have any clue about this .. -phil. On 03/18/2016 11:09 AM, Naoto Sato wrote: > So this fix will replace those left-right quotation marks in those CJK > locales from locale-specific font to "alphabetic", right? I don't know > much about the history (and personally I am fine with the fix), but > should we consult with the globalization team? > > Naoto > > On 3/17/16 12:54 PM, Phil Race wrote: >> I think you are still waiting on i18n to reply here since the exclusion >> ranges >> are mainly used for ensuring that the glyphs come from the right font >> which >> is mainly for locale reasons. If i18n see no problems then I am OK with >> this. >> >> -phil. >> >> On 02/17/2016 05:01 AM, dmitry markov wrote: >>> Hello Phil, >>> >>> Thank you for the review. >>> >>> According to unicode table the characters u201c and u201d are in >>> General Punctuation block, see >>> http://unicode-table.com/en/blocks/general-punctuation/ >>> Many characters from this block are not supported by Courier New. So I >>> do not think we need to remove the whole block from the exclusion >>> range, since it will not have any effect except few characters like >>> u201c and u201d. That's why I removed such small characters set (u2018 >>> - u201F) from the exclusion range, but I can change this if it is >>> necessary. >>> >>> At the same time the characters set (u2018 - u201F) is supported by >>> Arial and Times New Roman which are mapped to other logical fonts. The >>> adjusted exclusion range seems 'quite safe' from this point of view. >>> So I do not think we need to modify any code such as FontConfiguration >>> class and so on to apply these changes only to monospaced fonts. >>> Please correct me if I am wrong. >>> >>> Adding i18n-dev. >>> >>> Internationalization team, >>> Could you review a small change in windows.fontconfig.properties, >>> please? >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8073400 >>> webrev: http://cr.openjdk.java.net/~dmarkov/8073400/jdk9/webrev.00/ >>> >>> Problem description: >>> On Windows some characters (in particular, left and right double >>> quotation marks) have width differing from other characters' widths, >>> when Monospaced logical font is used. >>> The default monospaced font for windows platform is Courier New. It >>> contains the desired characters, (i.e. '\u201c' and '\u201d'). However >>> the characters are in 'exclusion ranges' for this font due to settings >>> in windows.fontconfig.properties. So when we try to obtain glyphs for >>> these characters and calculate their bounds, we fallback to another >>> font (Lucida) and use its glyphs. >>> >>> Fix: >>> Remove the following set of characters u2018 - u201F from the >>> exclusion ranges. >>> >>> Thank you in advance, >>> Dmitry >>> On 10/02/2016 23:25, Phil Race wrote: >>>> I expect the exclusion range is there for a reason. >>>> I think (guess) that the intent was that where there is a sequence >>>> like this : >>>> >>>> sequence.sansserif.x-windows-950=alphabetic,chinese-ms950,dingbats,symbol,chinese-ms950-extb >>>> >>>> >>>> >>>> then those code points should come from the chinese font. >>>> >>>> Perhaps your adjusted exclusion range should apply only to the >>>> monospaced fonts >>>> which are already putting the locale font first. >>>> >>>> Unfortunately it doesn't appear that this is possible with the >>>> supported syntax >>>> https://docs.oracle.com/javase/1.5.0/docs/guide/intl/fontconfig.html#windows >>>> >>>> >>>> >>>> i.e it supports selection only by charactersubsetname, not also by >>>> logicalfontname. >>>> But you should check the code to see if this is in fact the case. >>>> There may need to be a non-ideal decision or a revision to that spec. >>>> and its >>>> supporting code. >>>> >>>> And why be so narrow ? It seems you have made an even odder situation >>>> in having just those two code points 'un'-excluded. >>>> The argument that those were the two a customer complained about does >>>> not >>>> hold up very well. >>>> >>>> I think you should also run this whole change+discussion by >>>> i18n-dev .. >>>> >>>> >>>> -phil. >>>> >>>> On 01/14/2016 02:32 AM, dmitry markov wrote: >>>>> Hello, >>>>> >>>>> Could you review the fix for jdk9, please? >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8073400 >>>>> webrev: >>>>> http://cr.openjdk.java.net/~dmarkov/8073400/jdk9/webrev.00/ >>>>> >>>>> Problem description: >>>>> On Windows some characters (in particular, left and right double >>>>> quotation marks) have width differing from other characters' widths, >>>>> when Monospaced logical font is used. >>>>> The default monospaced font for windows platform is Courier New. It >>>>> contains the desired characters, (i.e. '\u201c' and '\u201d'). >>>>> However the characters are in 'exclusion ranges' for this font due >>>>> to settings in windows.fontconfig.properties. So when we try to >>>>> obtain glyphs for these characters and calculate their bounds, we >>>>> fallback to another font (Lucida) and use its glyphs. >>>>> >>>>> Fix: >>>>> Remove the following set of characters u2018 - u201F from the >>>>> exclusion ranges. >>>>> >>>>> Thanks, >>>>> Dmitry >>>> >>> >> From james.graham at oracle.com Fri Mar 18 22:47:15 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 18 Mar 2016 15:47:15 -0700 Subject: [OpenJDK 2D-Dev] RFR 8144938: Handle properly coordinate overflow in Marlin Renderer In-Reply-To: References: <56E2159E.8000209@oracle.com> <56E22734.7020707@oracle.com> <56E33249.2030300@oracle.com> <56E74A98.30503@oracle.com> <56E89082.5040703@oracle.com> <56E9FF2C.4020308@oracle.com> <56EB4F86.7000002@oracle.com> Message-ID: <56EC8573.3090307@oracle.com> The edit looks fine to me... Phil? ...jim On 3/18/16 9:52 AM, Laurent Bourg?s wrote: > Jim, > > Here is a final webrev (for archive): > http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144938.5/ > > Changes: > - remove loops in CrashNaNTest > > Hope it is ready to go ! > > I need another reviewer, please. > > > 2016-03-18 1:44 GMT+01:00 Jim Graham >: > > Hi Laurent, > > That looks fine. If the subPathStarted changes are the only changes > then it's good to go. If there was some other change that I missed, > let me know so I can review it as well. > > > No this webrev had only changes in MRE.pathToLoop() you reviewed. > > > One curiosity - in the test case, why are there 3 for loops that > perform exactly one pass? (lines 134, 221, 282) I'm guessing that > maybe in a former life this code may have been part of a performance > suite or something? It's not a bug, just an odd bit of code. You > can delete them if you want, but I don't need to see a review of that... > > > Fixed, now. > > Cheers, > Laurent From Sergey.Bylokhov at oracle.com Sat Mar 19 11:28:08 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sat, 19 Mar 2016 14:28:08 +0300 Subject: [OpenJDK 2D-Dev] CFV: New 2D Group Member: Alexander Scherbatiy In-Reply-To: <56EB3465.7070709@oracle.com> References: <56EB3465.7070709@oracle.com> Message-ID: <56ED37C8.9060003@oracle.com> Vote: yes On 18.03.16 1:49, Philip Race wrote: > I hereby nominate Alexander Scherbatiy to membership in the 2D group. > > Alexander Scherbatiy is a current member of the Swing group > and has contributed almost 200 changesets to OpenJDK :- > http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000&rev=author%28%22alexsch%22%29 > > Increasingly, and particularly over the last 18 months he has made many > of these significant contributions in the 2D area notably hi-dpi > graphics support and so I hereby nominate Alexander to membership of the > 2D group > > Votes are due by 1st April 2016 > > //Only current Members of the 2D Group [1] are eligible to vote on this > nomination. > For Lazy Consensus voting instructions, see [2]. > > [1] http://openjdk.java.net/census#2d > [2] http://openjdk.java.net/groups/#member-vote > > > -phil -- Best regards, Sergey. From philip.race at oracle.com Sat Mar 19 18:38:27 2016 From: philip.race at oracle.com (Philip Race) Date: Sat, 19 Mar 2016 11:38:27 -0700 Subject: [OpenJDK 2D-Dev] CFV: New 2D Group Member: Alexander Scherbatiy In-Reply-To: <56EB3465.7070709@oracle.com> References: <56EB3465.7070709@oracle.com> Message-ID: <56ED9CA3.8040709@oracle.com> Vote: yes On 3/17/16, 3:49 PM, Philip Race wrote: > I hereby nominate Alexander Scherbatiy to membership in the 2D group. > > Alexander Scherbatiy is a current member of the Swing group > and has contributed almost 200 changesets to OpenJDK :- > http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000&rev=author%28%22alexsch%22%29 > > Increasingly, and particularly over the last 18 months he has made many > of these significant contributions in the 2D area notably hi-dpi > graphics support and so I hereby nominate Alexander to membership of > the 2D group > > Votes are due by 1st April 2016 > > //Only current Members of the 2D Group [1] are eligible to vote on > this nomination. > For Lazy Consensus voting instructions, see [2]. > > [1] http://openjdk.java.net/census#2d > > [2] http://openjdk.java.net/groups/#member-vote > > > -phil -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.zvegintsev at oracle.com Sat Mar 19 22:13:52 2016 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Sun, 20 Mar 2016 01:13:52 +0300 Subject: [OpenJDK 2D-Dev] CFV: New 2D Group Member: Alexander Scherbatiy In-Reply-To: <56EB3465.7070709@oracle.com> References: <56EB3465.7070709@oracle.com> Message-ID: <56EDCF20.1090002@oracle.com> Vote: yes Thanks, Alexander. On 18/03/16 01:49, Philip Race wrote: > I hereby nominate Alexander Scherbatiy to membership in the 2D group. > > Alexander Scherbatiy is a current member of the Swing group > and has contributed almost 200 changesets to OpenJDK :- > http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000&rev=author%28%22alexsch%22%29 > > Increasingly, and particularly over the last 18 months he has made many > of these significant contributions in the 2D area notably hi-dpi > graphics support and so I hereby nominate Alexander to membership of > the 2D group > > Votes are due by 1st April 2016 > > //Only current Members of the 2D Group [1] are eligible to vote on > this nomination. > For Lazy Consensus voting instructions, see [2]. > > [1] http://openjdk.java.net/census#2d > > [2] http://openjdk.java.net/groups/#member-vote > > > -phil -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Mon Mar 21 07:26:24 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 21 Mar 2016 00:26:24 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream In-Reply-To: References: <99cb1549-30b5-44af-b399-ebed22255cf8@default> <56E997F1.2070605@oracle.com> <56E9C39D.6090701@oracle.com> <56E9D1D5.8090500@oracle.com> <56EAB79C.1080503@oracle.com> <88e50a67-fdd2-4b97-aa19-3ac5d419e2cf@default> <56EAFD38.80604@oracle.com> Message-ID: Hi Sergey, For the second approach I have created webrev for review. Please review updated webrev : http://cr.openjdk.java.net/~jdv/8044289/webrev.02/ Thanks, Jay -----Original Message----- From: Jayathirth D V Sent: Friday, March 18, 2016 2:23 PM To: Sergey Bylokhov Cc: 2d-dev at openjdk.java.net; Philip Race Subject: RE: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream Hi Sergey, Thanks for your inputs. Indeed all the null values returned by createImageInputStream() and createImageInputStream() are valid only. I went through the code more and found that there is no need for fix in ImageIO.read() methods as null stream is handled in read(ImageInputStream stream) which is called by all the remaining read() API's through IAE. So i can remove the changes made in ImageIO.read() functions. Also istream is closed in finally block of read(url). For ImageIO.write(File) & ImageIO.write(OutputStream) NPE we have two approaches for fix: 1) Keep the present changes of throwing IOException when stream is null and change the throw clause of write() spec mentioning: "IOException - if an error occurs during writing or not able to create required ImageOutputStream" 2) Remove the present changes and handle null in doWrite() method by returning false when stream is null & add code in finally block to close the stream only when stream is not null. Along with this we can also change Returns clause of spec to mention that write() might return false when we are not able to create ImageOutputStream. private static boolean doWrite(RenderedImage im, ImageWriter writer, ImageOutputStream output) throws IOException { if (writer == null) { return false; } + if (output == null) { + return false; + } try { return doWrite(im, writer, stream); } finally { + if (stream != null) stream.close(); } Returns : false if no appropriate writer is found or not able to create required ImageOutputStream. Please let me know your inputs. Thanks, Jay -----Original Message----- From: Sergey Bylokhov Sent: Friday, March 18, 2016 12:24 AM To: Jayathirth D V Cc: 2d-dev at openjdk.java.net; Philip Race Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream On 17.03.16 21:14, Jayathirth D V wrote: > There are many places in createImageInputStream() and createImageOutputStream() where it will return null for stream. But when why you change the write/read methods? They should take null into account and work according to specification. If some bogus null returns from createImageInputStream/createImageOutputStream then it should be fixed in these methods. > > So for NPE described in bug to occur there can be multiple paths: > 1) One of the path described in bug is when theRegistry.getServiceProviders() throws IAE and we return null. This is the case when we have no installed spi and should return null/false. > 2) When we pass non-existent file path to ImageIO (as described in http://stackoverflow.com/questions/11153200/with-imageio-write-api-call-i-get-nullpointerexception ). Here we catch FileNotFoundException but still we return stream as null at the end which will cause NPE further. This is same thing described in the bug(about stream.close()). The write method call createImageOutputStream() and got FileNotFoundException. This exception should be propagated to the user, but it is replaced in the finally block, because we try to close the stream=null. So the fix for this particular case is to check the stream to null in finally, No? > 3) When we don't support the provider and theRegistry.getServiceProviders() return iterator with size zero. This means that our providers do not support this case, and we should return null/false. > > For us to follow first scenario we need access to categoryMap of IIORegistry and delete the ImageInputStreamSpi/ ImageOutputStreamSpi but I was not able to find a way to tamper it from test case. If we follow second case FileNotFoundException will be thrown by default eventhough we handle NPE. But you change the code and we now contradicts the specification, in your case the test should expect false/null from write()/read(). > > In the test case we are trying to following third scenario to get stream as null to verify the code changes. To catch the bogus null we should try to use another approach, or change the spec. But it seems all null values above are correct, we should be ready for them. > > As part of collective fix we are throwing IOException which will indicate that we are not able to create required stream. > > Thanks, > Jay > > -----Original Message----- > From: Sergey Bylokhov > Sent: Thursday, March 17, 2016 7:27 PM > To: Phil Race > Cc: Jayathirth D V; 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In > ImageIO.read() and write() NPE is not handled properly for stream > > On 17.03.16 0:36, Phil Race wrote: >> I don't think that is the actual reason here > > But the test doing exactly this thing -> deregister all spi => in this > case according to specification all related > methods(read/write/creatImageInputStream/creatImageOutputStream) should return null or false. > > - it seems likely that there >> was some kind of internal error or bad SPI causing this. >> So throwing an exception seems more appropriate. > > the problem was in some of our methods which do not expect null in some places(like stream.close() from the bug description). > >> And also the bug was originally solely about write(..). >> >> -phil. >> >> >> On 03/16/2016 01:35 PM, Sergey Bylokhov wrote: >>> As far as I understand the createImageInputStream() returns null is >>> this stream is unsupported by current plugins via spi. Probably the >>> read() method should return null too? >>> >>> /** >>> * Returns a {@code BufferedImage} as the result of decoding >>> * a supplied {@code InputStream} with an {@code ImageReader} >>> * chosen automatically from among those currently registered. >>> * The {@code InputStream} is wrapped in an >>> * {@code ImageInputStream}. If no registered >>> * {@code ImageReader} claims to be able to read the >>> * resulting stream, {@code null} is returned. >>> * >>> ....... >>> * @return a {@code BufferedImage} containing the decoded >>> * contents of the input, or {@code null}. >>> */ >>> public static BufferedImage read(InputStream input) throws >>> IOException >>> >>> >>> On 16.03.16 20:29, Philip Race wrote: >>>> The test writes out into "test.src". >>>> I believe that you should treat that as a "read-only" location. >>>> Write to a tempfile (File.createTempFile()) or TESTCLASSES. >>>> >>>> -phil. >>>> >>>> On 3/15/16, 10:50 PM, Jayathirth D V wrote: >>>>> >>>>> Hi Phil,All >>>>> >>>>> _Please review the following fix in JDK9:_ >>>>> >>>>> __ >>>>> >>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8044289 >>>>> >>>>> Webrev : http://cr.openjdk.java.net/~jdv/8044289/webrev.00/ >>>>> >>>>> >>>>> Issue : When createImageInputStream() or createImageOutputStream >>>>> returns null in ImageIO.read() or ImageIO.write() we are seeing >>>>> NPE as it stream is used further without null check. >>>>> >>>>> Root cause : "stream" is used without checking whether it is null >>>>> or not. >>>>> >>>>> Solution : Handle null pointer of stream and throw IIOException. >>>>> >>>>> Test case contains all possible scenarios where >>>>> createImageInputStream() or createImageOutputStream can return null. >>>>> >>>>> Thanks, >>>>> >>>>> Jay >>>>> >>> >>> >> > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From dmitry.markov at oracle.com Mon Mar 21 07:56:05 2016 From: dmitry.markov at oracle.com (dmitry markov) Date: Mon, 21 Mar 2016 10:56:05 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8073400: Some Monospaced logical fonts have a different width In-Reply-To: <56EE22EE.8070803@oracle.com> References: <56977953.10604@oracle.com> <56BB9CAC.3050408@oracle.com> <56C46F35.6030107@oracle.com> <56EB0B71.8090000@oracle.com> <56EE22EE.8070803@oracle.com> Message-ID: <56EFA915.8010700@oracle.com> Hello, Thank you very much for the review. I added a simple test for the fix. Please find the updated webrev here: http://cr.openjdk.java.net/~dmarkov/8073400/jdk9/webrev.01/ Could you take a look at it, please? thank you in advance, Dmitry On 20/03/2016 07:11, Masayoshi Okutsu wrote: > The fix looks Okay to me. But there should be a regression test for > this particular case? I wonder if we can have a test case to verify > width(s) of monospaced glyphs. > > Masayoshi > > > On 3/18/2016 4:54 AM, Phil Race wrote: >> I think you are still waiting on i18n to reply here since the >> exclusion ranges >> are mainly used for ensuring that the glyphs come from the right font >> which >> is mainly for locale reasons. If i18n see no problems then I am OK >> with this. >> >> -phil. >> >> On 02/17/2016 05:01 AM, dmitry markov wrote: >>> Hello Phil, >>> >>> Thank you for the review. >>> >>> According to unicode table the characters u201c and u201d are in >>> General Punctuation block, see >>> http://unicode-table.com/en/blocks/general-punctuation/ >>> Many characters from this block are not supported by Courier New. So >>> I do not think we need to remove the whole block from the exclusion >>> range, since it will not have any effect except few characters like >>> u201c and u201d. That's why I removed such small characters set >>> (u2018 - u201F) from the exclusion range, but I can change this if >>> it is necessary. >>> >>> At the same time the characters set (u2018 - u201F) is supported by >>> Arial and Times New Roman which are mapped to other logical fonts. >>> The adjusted exclusion range seems 'quite safe' from this point of >>> view. So I do not think we need to modify any code such as >>> FontConfiguration class and so on to apply these changes only to >>> monospaced fonts. Please correct me if I am wrong. >>> >>> Adding i18n-dev. >>> >>> Internationalization team, >>> Could you review a small change in windows.fontconfig.properties, >>> please? >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8073400 >>> webrev: http://cr.openjdk.java.net/~dmarkov/8073400/jdk9/webrev.00/ >>> >>> Problem description: >>> On Windows some characters (in particular, left and right double >>> quotation marks) have width differing from other characters' widths, >>> when Monospaced logical font is used. >>> The default monospaced font for windows platform is Courier New. It >>> contains the desired characters, (i.e. '\u201c' and '\u201d'). >>> However the characters are in 'exclusion ranges' for this font due >>> to settings in windows.fontconfig.properties. So when we try to >>> obtain glyphs for these characters and calculate their bounds, we >>> fallback to another font (Lucida) and use its glyphs. >>> >>> Fix: >>> Remove the following set of characters u2018 - u201F from the >>> exclusion ranges. >>> >>> Thank you in advance, >>> Dmitry >>> On 10/02/2016 23:25, Phil Race wrote: >>>> I expect the exclusion range is there for a reason. >>>> I think (guess) that the intent was that where there is a sequence >>>> like this : >>>> >>>> sequence.sansserif.x-windows-950=alphabetic,chinese-ms950,dingbats,symbol,chinese-ms950-extb >>>> >>>> >>>> then those code points should come from the chinese font. >>>> >>>> Perhaps your adjusted exclusion range should apply only to the >>>> monospaced fonts >>>> which are already putting the locale font first. >>>> >>>> Unfortunately it doesn't appear that this is possible with the >>>> supported syntax >>>> https://docs.oracle.com/javase/1.5.0/docs/guide/intl/fontconfig.html#windows >>>> >>>> >>>> i.e it supports selection only by charactersubsetname, not also by >>>> logicalfontname. >>>> But you should check the code to see if this is in fact the case. >>>> There may need to be a non-ideal decision or a revision to that >>>> spec. and its >>>> supporting code. >>>> >>>> And why be so narrow ? It seems you have made an even odder situation >>>> in having just those two code points 'un'-excluded. >>>> The argument that those were the two a customer complained about >>>> does not >>>> hold up very well. >>>> >>>> I think you should also run this whole change+discussion by >>>> i18n-dev .. >>>> >>>> >>>> -phil. >>>> >>>> On 01/14/2016 02:32 AM, dmitry markov wrote: >>>>> Hello, >>>>> >>>>> Could you review the fix for jdk9, please? >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8073400 >>>>> webrev: >>>>> http://cr.openjdk.java.net/~dmarkov/8073400/jdk9/webrev.00/ >>>>> >>>>> Problem description: >>>>> On Windows some characters (in particular, left and right double >>>>> quotation marks) have width differing from other characters' >>>>> widths, when Monospaced logical font is used. >>>>> The default monospaced font for windows platform is Courier New. >>>>> It contains the desired characters, (i.e. '\u201c' and '\u201d'). >>>>> However the characters are in 'exclusion ranges' for this font due >>>>> to settings in windows.fontconfig.properties. So when we try to >>>>> obtain glyphs for these characters and calculate their bounds, we >>>>> fallback to another font (Lucida) and use its glyphs. >>>>> >>>>> Fix: >>>>> Remove the following set of characters u2018 - u201F from the >>>>> exclusion ranges. >>>>> >>>>> Thanks, >>>>> Dmitry >>>> >>> >> > From alexandr.scherbatiy at oracle.com Mon Mar 21 15:54:09 2016 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 21 Mar 2016 19:54:09 +0400 Subject: [OpenJDK 2D-Dev] [9] Review request for 8151303 [macosx] [hidpi] JButton's low-res. icon is visible when clicking on it In-Reply-To: <56E839DC.2040904@oracle.com> References: <56E01777.1030202@oracle.com> <56E01DE7.9040103@oracle.com> <56E2CB4F.6040301@oracle.com> <56E3277B.3000309@oracle.com> <56E815C3.40208@oracle.com> <56E816E9.1010308@oracle.com> <56E839DC.2040904@oracle.com> Message-ID: <56F01921.6060305@oracle.com> The one more thing is that image filters should also be updated to use them with multi-resolution images. For example, consider the case: ---------- Image mrImage = getMultiResolutionImage(); ImageProducer mriProducer = new FilteredImageSource(mrImage.getSource(), new CropImageFilter(0, 0, w, h)); Toolkit.getDefaultToolkit().createImage(mriProducer); ---------- The crop image filter applied to each resolution variant just cuts images with the same size. It seems that there should be added API which allows to set a scale for a provided image filter to be properly used with the given resolution variant. I have created a separated issue for multi-resolution images filtering support: JDK-8152309 Seamless way of using image filters with multi-resolution images https://bugs.openjdk.java.net/browse/JDK-8152309 Thanks, Alexandr. On 15/03/16 20:35, Alexander Scherbatiy wrote: > On 15/03/16 18:06, Sergey Bylokhov wrote: >> On 15.03.16 17:01, Alexander Scherbatiy wrote: >> >>> One update will be that FilteredImageSource should implement >>> MultiResolutionImageProducer even it is used for non multi-resolution >>> images. >>> >>> The MRI can be created using two general ways: using fixed number of >>> resolution variants or generating a resolution variant with necessary >>> quality on demand. >>> >>> The current implementation is rely on that MRToolkitImage contains a >>> fixed number of resolution variants. In this case MediaTracker can >>> iterate over resolution variants and load them all. >>> >>> Using MultiResolutionImageProducer leads that MRToolkitImage will not >>> know about number of resolution variants in case when they are >>> generated >>> on the fly and there will be no way to load all of them by >>> MediaTracker. >> >> Just an idea to thinking about, can we save this filter to the MRI >> itself and apply it after some resolution variant will be created on >> the fly? > > Do you mean that it helps to leave the code in the AquaUtils class > unchanged: > --------------- > 124 static Image generateLightenedImage(final Image image, final > int percent) { > 125 final GrayFilter filter = new GrayFilter(true, percent); > 126 final ImageProducer prod = new > FilteredImageSource(image.getSource(), filter); > 127 return Toolkit.getDefaultToolkit().createImage(prod); > 128 } > --------------- > > or it is just an a better way for a filtered multi-resolution image > generation? > > Thanks, > Alexandr. >> >>> >>> As I see, the way to solve it is only using MRI.getResolutionVariants() >>> method for the MultiResolutionImageProducer creation. So the result of >>> the call >>> toolkit.createImage(new FilteredImageSource(mrImage.getSource(), >>> filter)); >>> will be a MRToolkitImage which is based on fixed number of filtered >>> resolution variants from the original MRI. >>> >>> Thanks, >>> Alexandr. >>> >>>> ...jim >>>> >>>> On 3/11/16 5:42 AM, Alexander Scherbatiy wrote: >>>>> On 09/03/16 16:58, Sergey Bylokhov wrote: >>>>>> Probably we should enhance >>>>>> ImageProducer/Tk.createImage/ImageFilter to >>>>>> support this functionality? It seems that the number of usage of >>>>>> this >>>>>> check "image instanceof MultiResolutionImage" will grow over time. >>>>> ImageProducer produces pixels for an image and is not able to >>>>> take >>>>> an information about the image resolution variants. >>>>> >>>>> May be we can add Toolkit.createImage(Image image, ImageFilter >>>>> imageFilter) method which takes MultiResolutionImage into account to >>>>> cover the common case where filtered image is created. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>>> I think that at least our own API should support >>>>>> MultiResolutionImage >>>>>> w/o such checks, otherwise the user will need to do the same. >>>>>> >>>>>> cc 2d-dev >>>>>> >>>>>> On 09.03.16 15:30, Alexander Scherbatiy wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Could you review the fix: >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8151303 >>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8151303/webrev.00 >>>>>>> >>>>>>> The AquaUtils does not take into account MultiResolutionImage >>>>>>> for >>>>>>> selected/disabled/lightened images generation. >>>>>>> The fix also leaves the MultiResolutionCachedImage check because >>>>>>> the >>>>>>> base system icon size can be differ from the requested painted >>>>>>> size. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>> >>>>>> >>>>> >>> >> >> > From philip.race at oracle.com Mon Mar 21 17:52:17 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 21 Mar 2016 10:52:17 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8055463: Needs public API allowing full access to font collections in Font.createFont() In-Reply-To: <56E44258.6050000@oracle.com> References: <56E1FAFC.6040609@oracle.com> <56E1FD1C.5060008@oracle.com> <56E32904.4050501@oracle.com> <56E32BCD.3070002@oracle.com> <56E44258.6050000@oracle.com> Message-ID: <56F034D1.5090607@oracle.com> After some CCC discussion the method name was changed from createFont to createFonts since it is expected to suport returning > 1. No other changes. http://cr.openjdk.java.net/~prr/8055463.2 I am still looking for a 2nd reviewer ! -phil. On 03/12/2016 08:22 AM, Sergey Bylokhov wrote: > Looks fine. > ps: for the record - long time ago the OSX code was different: > http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/e910dde2c36c > > On 11.03.16 23:34, Phil Race wrote: >> Oops. Fixed : http://cr.openjdk.java.net/~prr/8055463.1/ >> >> -phil. >> >> On 03/11/2016 12:22 PM, Sergey Bylokhov wrote: >>> Hi, Phil. >>> The FileFont.java contains debug code: >>> >>> System.out.println("COUNT="+count); >>> System.out.println("FILE="+fontFile); >>> >>> >>> On 11.03.16 2:02, Phil Race wrote: >>>> PS there are a couple of other test files updated here >>>> >>>> BigFont is one of the tests I ran whilst checking I didn't create >>>> regressions >>>> and it failed because it assumes a SecurityManager. I could not >>>> find an >>>> open bug on that.* >>>> >>>> *GetLCIDFromLocale happened to be the one I chose to paste in >>>> the GPL and then I noticed it incorrectly had the classpath exception >>>> so I am fixing that here too. >>>> >>>> -phil. >>>> >>>> >>>> On 03/10/2016 02:53 PM, Phil Race wrote: >>>>> https://bugs.openjdk.java.net/browse/JDK-8055463 >>>>> http://cr.openjdk.java.net/~prr/8055463/ >>>>> >>>>> Proposal is to add two new methods in the Font class paralleling the >>>>> existing ones >>>>> that return only a single font. >>>>> >>>>> Font[] createFont(File) >>>>> Font[] createFont(InputStream) >>>>> >>>>> I tried to make the single & multiple code be shared as much as >>>>> possible >>>>> to avoid duplication and I eliminated code in the OSX sub-class which >>>>> seemed to be a pointless copy of the superclass. >>>>> >>>>> The test checks the various assertions I intend by probing for >>>>> platform fonts. >>>>> >>>>> -phil. >>>> >>> >>> >> > > From masayoshi.okutsu at oracle.com Sun Mar 20 04:11:26 2016 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Sun, 20 Mar 2016 13:11:26 +0900 Subject: [OpenJDK 2D-Dev] [9] Review request for 8073400: Some Monospaced logical fonts have a different width In-Reply-To: <56EB0B71.8090000@oracle.com> References: <56977953.10604@oracle.com> <56BB9CAC.3050408@oracle.com> <56C46F35.6030107@oracle.com> <56EB0B71.8090000@oracle.com> Message-ID: <56EE22EE.8070803@oracle.com> The fix looks Okay to me. But there should be a regression test for this particular case? I wonder if we can have a test case to verify width(s) of monospaced glyphs. Masayoshi On 3/18/2016 4:54 AM, Phil Race wrote: > I think you are still waiting on i18n to reply here since the > exclusion ranges > are mainly used for ensuring that the glyphs come from the right font > which > is mainly for locale reasons. If i18n see no problems then I am OK > with this. > > -phil. > > On 02/17/2016 05:01 AM, dmitry markov wrote: >> Hello Phil, >> >> Thank you for the review. >> >> According to unicode table the characters u201c and u201d are in >> General Punctuation block, see >> http://unicode-table.com/en/blocks/general-punctuation/ >> Many characters from this block are not supported by Courier New. So >> I do not think we need to remove the whole block from the exclusion >> range, since it will not have any effect except few characters like >> u201c and u201d. That's why I removed such small characters set >> (u2018 - u201F) from the exclusion range, but I can change this if it >> is necessary. >> >> At the same time the characters set (u2018 - u201F) is supported by >> Arial and Times New Roman which are mapped to other logical fonts. >> The adjusted exclusion range seems 'quite safe' from this point of >> view. So I do not think we need to modify any code such as >> FontConfiguration class and so on to apply these changes only to >> monospaced fonts. Please correct me if I am wrong. >> >> Adding i18n-dev. >> >> Internationalization team, >> Could you review a small change in windows.fontconfig.properties, >> please? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8073400 >> webrev: http://cr.openjdk.java.net/~dmarkov/8073400/jdk9/webrev.00/ >> >> Problem description: >> On Windows some characters (in particular, left and right double >> quotation marks) have width differing from other characters' widths, >> when Monospaced logical font is used. >> The default monospaced font for windows platform is Courier New. It >> contains the desired characters, (i.e. '\u201c' and '\u201d'). >> However the characters are in 'exclusion ranges' for this font due to >> settings in windows.fontconfig.properties. So when we try to obtain >> glyphs for these characters and calculate their bounds, we fallback >> to another font (Lucida) and use its glyphs. >> >> Fix: >> Remove the following set of characters u2018 - u201F from the >> exclusion ranges. >> >> Thank you in advance, >> Dmitry >> On 10/02/2016 23:25, Phil Race wrote: >>> I expect the exclusion range is there for a reason. >>> I think (guess) that the intent was that where there is a sequence >>> like this : >>> >>> sequence.sansserif.x-windows-950=alphabetic,chinese-ms950,dingbats,symbol,chinese-ms950-extb >>> >>> >>> then those code points should come from the chinese font. >>> >>> Perhaps your adjusted exclusion range should apply only to the >>> monospaced fonts >>> which are already putting the locale font first. >>> >>> Unfortunately it doesn't appear that this is possible with the >>> supported syntax >>> https://docs.oracle.com/javase/1.5.0/docs/guide/intl/fontconfig.html#windows >>> >>> >>> i.e it supports selection only by charactersubsetname, not also by >>> logicalfontname. >>> But you should check the code to see if this is in fact the case. >>> There may need to be a non-ideal decision or a revision to that >>> spec. and its >>> supporting code. >>> >>> And why be so narrow ? It seems you have made an even odder situation >>> in having just those two code points 'un'-excluded. >>> The argument that those were the two a customer complained about >>> does not >>> hold up very well. >>> >>> I think you should also run this whole change+discussion by i18n-dev .. >>> >>> >>> -phil. >>> >>> On 01/14/2016 02:32 AM, dmitry markov wrote: >>>> Hello, >>>> >>>> Could you review the fix for jdk9, please? >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8073400 >>>> webrev: >>>> http://cr.openjdk.java.net/~dmarkov/8073400/jdk9/webrev.00/ >>>> >>>> Problem description: >>>> On Windows some characters (in particular, left and right double >>>> quotation marks) have width differing from other characters' >>>> widths, when Monospaced logical font is used. >>>> The default monospaced font for windows platform is Courier New. It >>>> contains the desired characters, (i.e. '\u201c' and '\u201d'). >>>> However the characters are in 'exclusion ranges' for this font due >>>> to settings in windows.fontconfig.properties. So when we try to >>>> obtain glyphs for these characters and calculate their bounds, we >>>> fallback to another font (Lucida) and use its glyphs. >>>> >>>> Fix: >>>> Remove the following set of characters u2018 - u201F from the >>>> exclusion ranges. >>>> >>>> Thanks, >>>> Dmitry >>> >> > From james.graham at oracle.com Mon Mar 21 18:19:43 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 21 Mar 2016 11:19:43 -0700 Subject: [OpenJDK 2D-Dev] CFV: New 2D Group Member: Alexander Scherbatiy In-Reply-To: <56EB3465.7070709@oracle.com> References: <56EB3465.7070709@oracle.com> Message-ID: <56F03B3F.2010602@oracle.com> Vote: yes ...jim On 3/17/16 3:49 PM, Philip Race wrote: > I hereby nominate Alexander Scherbatiy to membership in the 2D group. > > Alexander Scherbatiy is a current member of the Swing group > and has contributed almost 200 changesets to OpenJDK :- > http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000&rev=author%28%22alexsch%22%29 > > Increasingly, and particularly over the last 18 months he has made many > of these significant contributions in the 2D area notably hi-dpi > graphics support and so I hereby nominate Alexander to membership of the > 2D group > > Votes are due by 1st April 2016 > > //Only current Members of the 2D Group [1] are eligible to vote on this > nomination. > For Lazy Consensus voting instructions, see [2]. > > [1] http://openjdk.java.net/census#2d > [2] http://openjdk.java.net/groups/#member-vote > > > -phil From james.graham at oracle.com Mon Mar 21 18:31:39 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 21 Mar 2016 11:31:39 -0700 Subject: [OpenJDK 2D-Dev] [9] Review request for 8151303 [macosx] [hidpi] JButton's low-res. icon is visible when clicking on it In-Reply-To: <56F01921.6060305@oracle.com> References: <56E01777.1030202@oracle.com> <56E01DE7.9040103@oracle.com> <56E2CB4F.6040301@oracle.com> <56E3277B.3000309@oracle.com> <56E815C3.40208@oracle.com> <56E816E9.1010308@oracle.com> <56E839DC.2040904@oracle.com> <56F01921.6060305@oracle.com> Message-ID: <56F03E0B.1080703@oracle.com> We could do that for our own filters, but any random custom filter could run into the same issue, so it might not make sense to upgrade the existing filter mechanism to always attempt to do MR filtering. We could either create a parallel set of MR-aware filter mechanisms (such as the previously suggested new method on Toolkit, or a new MR-aware version of FilteredImageSource for instance) and leave the existing mechanism as clearly documented as MR-unaware. Another idea is to tag a filter with an interface that indicates that it is MR aware? In any case, some thought needs to be given to feeding an MR image to a filter that (potentially or demonstrably) cannot deal with MR images. Alternately, we could then recommend that the old image filtering code isn't combined with multi-resolution images. It seems to me that the programmer is mostly in control over this happening since they've either manually created the MR image using the custiom MR image mechanism or they've supplied media with multiple resolution files (i.e. "@2x"). Is that really the case? Whether it is a new filtering mechanism that must be adopted or simply declaring the old filtering mechanism as "obsolete with respect to MR images"... That recommendation then "restricts forward" in that, for example, since Swing relies on the old mechanism, Swing then becomes "not recommended for use with MR images", or "not MR aware". That's probably not a restriction we want to promote so it should be viewed as a temporary restriction reality and a bug that we'll fix soon, whether by using some other mechanism to achieve the desired affects, or creating a new MR-aware filtering mechanism and using it in Swing. Similarly, other 3rd party libraries that accept images and do anything more than display them will have to be upgraded as well before they become "MR aware" or "MR accepting" or whatever term applies here... ...jim On 3/21/16 8:54 AM, Alexander Scherbatiy wrote: > > The one more thing is that image filters should also be updated to use > them with multi-resolution images. > For example, consider the case: > ---------- > Image mrImage = getMultiResolutionImage(); > ImageProducer mriProducer = new > FilteredImageSource(mrImage.getSource(), new CropImageFilter(0, 0, w, h)); > Toolkit.getDefaultToolkit().createImage(mriProducer); > ---------- > > The crop image filter applied to each resolution variant just cuts > images with the same size. > It seems that there should be added API which allows to set a scale for > a provided image filter to be properly used with the given resolution > variant. > > I have created a separated issue for multi-resolution images filtering > support: > JDK-8152309 Seamless way of using image filters with multi-resolution > images > https://bugs.openjdk.java.net/browse/JDK-8152309 > > Thanks, > Alexandr. > > On 15/03/16 20:35, Alexander Scherbatiy wrote: >> On 15/03/16 18:06, Sergey Bylokhov wrote: >>> On 15.03.16 17:01, Alexander Scherbatiy wrote: >>> >>>> One update will be that FilteredImageSource should implement >>>> MultiResolutionImageProducer even it is used for non multi-resolution >>>> images. >>>> >>>> The MRI can be created using two general ways: using fixed number of >>>> resolution variants or generating a resolution variant with necessary >>>> quality on demand. >>>> >>>> The current implementation is rely on that MRToolkitImage contains a >>>> fixed number of resolution variants. In this case MediaTracker can >>>> iterate over resolution variants and load them all. >>>> >>>> Using MultiResolutionImageProducer leads that MRToolkitImage will not >>>> know about number of resolution variants in case when they are >>>> generated >>>> on the fly and there will be no way to load all of them by >>>> MediaTracker. >>> >>> Just an idea to thinking about, can we save this filter to the MRI >>> itself and apply it after some resolution variant will be created on >>> the fly? >> >> Do you mean that it helps to leave the code in the AquaUtils class >> unchanged: >> --------------- >> 124 static Image generateLightenedImage(final Image image, final >> int percent) { >> 125 final GrayFilter filter = new GrayFilter(true, percent); >> 126 final ImageProducer prod = new >> FilteredImageSource(image.getSource(), filter); >> 127 return Toolkit.getDefaultToolkit().createImage(prod); >> 128 } >> --------------- >> >> or it is just an a better way for a filtered multi-resolution image >> generation? >> >> Thanks, >> Alexandr. >>> >>>> >>>> As I see, the way to solve it is only using MRI.getResolutionVariants() >>>> method for the MultiResolutionImageProducer creation. So the result of >>>> the call >>>> toolkit.createImage(new FilteredImageSource(mrImage.getSource(), >>>> filter)); >>>> will be a MRToolkitImage which is based on fixed number of filtered >>>> resolution variants from the original MRI. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>> ...jim >>>>> >>>>> On 3/11/16 5:42 AM, Alexander Scherbatiy wrote: >>>>>> On 09/03/16 16:58, Sergey Bylokhov wrote: >>>>>>> Probably we should enhance >>>>>>> ImageProducer/Tk.createImage/ImageFilter to >>>>>>> support this functionality? It seems that the number of usage of >>>>>>> this >>>>>>> check "image instanceof MultiResolutionImage" will grow over time. >>>>>> ImageProducer produces pixels for an image and is not able to >>>>>> take >>>>>> an information about the image resolution variants. >>>>>> >>>>>> May be we can add Toolkit.createImage(Image image, ImageFilter >>>>>> imageFilter) method which takes MultiResolutionImage into account to >>>>>> cover the common case where filtered image is created. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>>> I think that at least our own API should support >>>>>>> MultiResolutionImage >>>>>>> w/o such checks, otherwise the user will need to do the same. >>>>>>> >>>>>>> cc 2d-dev >>>>>>> >>>>>>> On 09.03.16 15:30, Alexander Scherbatiy wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> Could you review the fix: >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8151303 >>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8151303/webrev.00 >>>>>>>> >>>>>>>> The AquaUtils does not take into account MultiResolutionImage >>>>>>>> for >>>>>>>> selected/disabled/lightened images generation. >>>>>>>> The fix also leaves the MultiResolutionCachedImage check because >>>>>>>> the >>>>>>>> base system icon size can be differ from the requested painted >>>>>>>> size. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>> >>>>>>> >>>>>> >>>> >>> >>> >> > From vadim.pakhnushev at oracle.com Mon Mar 21 20:15:24 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Mon, 21 Mar 2016 23:15:24 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8055463: Needs public API allowing full access to font collections in Font.createFont() In-Reply-To: <56F034D1.5090607@oracle.com> References: <56E1FAFC.6040609@oracle.com> <56E1FD1C.5060008@oracle.com> <56E32904.4050501@oracle.com> <56E32BCD.3070002@oracle.com> <56E44258.6050000@oracle.com> <56F034D1.5090607@oracle.com> Message-ID: <56F0565C.1090208@oracle.com> Phil, Now the javadoc for both java.awt.Font.createFonts methods is incorrect: * The explicit purpose of this overloading of the * {@code createFont(int, InputStream)} method It's not an overload anymore. Other than that, looks good. Vadim On 21.03.2016 20:52, Phil Race wrote: > After some CCC discussion the method name was changed from createFont > to createFonts > since it is expected to suport returning > 1. No other changes. > http://cr.openjdk.java.net/~prr/8055463.2 > > I am still looking for a 2nd reviewer ! > > -phil. > > > On 03/12/2016 08:22 AM, Sergey Bylokhov wrote: >> Looks fine. >> ps: for the record - long time ago the OSX code was different: >> http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/e910dde2c36c >> >> On 11.03.16 23:34, Phil Race wrote: >>> Oops. Fixed : http://cr.openjdk.java.net/~prr/8055463.1/ >>> >>> -phil. >>> >>> On 03/11/2016 12:22 PM, Sergey Bylokhov wrote: >>>> Hi, Phil. >>>> The FileFont.java contains debug code: >>>> >>>> System.out.println("COUNT="+count); >>>> System.out.println("FILE="+fontFile); >>>> >>>> >>>> On 11.03.16 2:02, Phil Race wrote: >>>>> PS there are a couple of other test files updated here >>>>> >>>>> BigFont is one of the tests I ran whilst checking I didn't create >>>>> regressions >>>>> and it failed because it assumes a SecurityManager. I could not >>>>> find an >>>>> open bug on that.* >>>>> >>>>> *GetLCIDFromLocale happened to be the one I chose to paste in >>>>> the GPL and then I noticed it incorrectly had the classpath exception >>>>> so I am fixing that here too. >>>>> >>>>> -phil. >>>>> >>>>> >>>>> On 03/10/2016 02:53 PM, Phil Race wrote: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8055463 >>>>>> http://cr.openjdk.java.net/~prr/8055463/ >>>>>> >>>>>> Proposal is to add two new methods in the Font class paralleling the >>>>>> existing ones >>>>>> that return only a single font. >>>>>> >>>>>> Font[] createFont(File) >>>>>> Font[] createFont(InputStream) >>>>>> >>>>>> I tried to make the single & multiple code be shared as much as >>>>>> possible >>>>>> to avoid duplication and I eliminated code in the OSX sub-class >>>>>> which >>>>>> seemed to be a pointless copy of the superclass. >>>>>> >>>>>> The test checks the various assertions I intend by probing for >>>>>> platform fonts. >>>>>> >>>>>> -phil. >>>>> >>>> >>>> >>> >> >> > From Sergey.Bylokhov at oracle.com Mon Mar 21 20:20:09 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 21 Mar 2016 23:20:09 +0300 Subject: [OpenJDK 2D-Dev] [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception In-Reply-To: References: <3969befd-57cd-48ee-bed5-173a28e7bd08@default> <56DFFC9F.4020403@oracle.com> <70f247c0-6f3e-472a-b7b0-b02814010e30@default> <56E16D0A.3060807@oracle.com> <56E1E2A5.1020008@oracle.com> Message-ID: <56F05779.5070801@oracle.com> This version looks fine to me. On 15.03.16 17:05, Ajit Ghaisas wrote: > Please review the changes present in updated webrev : > http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.02/ > > Regards, > Ajit > > -----Original Message----- > From: Jim Graham > Sent: Friday, March 11, 2016 2:40 AM > To: Sergey Bylokhov; Ajit Ghaisas; 2d-dev > Subject: Re: [OpenJDK 2D-Dev] [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception > > Yes, those constructors should be type-safe. Perhaps that was done to save code in the caller, but that is a small price to pay to avoid errors in the future, and it makes sure there is a backup plan for different kinds of buffers... > > ...jim > > On 3/10/16 4:48 AM, Sergey Bylokhov wrote: >> Hi, Ajit. >> What about other cases in Raster.java, where the DataBuffer is passed >> as a parameter? Probably we can simplify the code and find all such >> issues if we changes the ByteInterleavedRaster/etc. For example: >> >> ByteInterleavedRaster(SampleModel sampleModel,DataBuffer >> dataBuffer,...) to >> >> ByteInterleavedRaster(SampleModel sampleModel,DataBufferByte >> dataBuffer,...) >> >> Because we throw an exception in such cases anyway: >> >> if (!(dataBuffer instanceof DataBufferByte)) { >> throw new RasterFormatException("ByteInterleavedRasters must have " >> + "byte DataBuffers"); >> } >> >> And the compiler will help us, what everybody think about it? >> >> On 09.03.16 17:38, Ajit Ghaisas wrote: >>> Hi, >>> >>> Modified the test and added check for MultiPixelPackedSampleModel >>> condition. >>> >>> Please review updated webrev : >>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.01/ >>> >>> Regards, >>> Ajit >>> >>> -----Original Message----- >>> From: Sergey Bylokhov >>> Sent: Wednesday, March 09, 2016 4:06 PM >>> To: Ajit Ghaisas; awt-dev at openjdk.java.net; Semyon Sadetsky; Ambarish >>> Rapte; 2d-dev >>> Subject: Re: [9] Review-request for 6353518: Creation of a >>> WritableRaster with a custom DataBuffer causes erroneous Exception >>> >>> Changes for 2d area.(cc) >>> >>> >>> On 07.03.16 11:20, Ajit Ghaisas wrote: >>>> Hi, >>>> >>>> Bug : https://bugs.openjdk.java.net/browse/JDK-6353518 >>>> >>>> Issue : (Text from bug description) >>>> >>>> An attempt to create a WritableRaster via >>>> Raster.createWritableRaster(SampleModel sm, DataBuffer db, Point >>>> location) using a custom DataBuffer causes an erroneous >>>> RasterFormatException. >>>> Apparently the reason for this bug is that IntegerComponentRaster >>>> insists on being passed an instance of DataBufferInt rather than >>>> just a DataBuffer with a DataType of TYPE_INT. >>>> This is quite annoying since DataBufferInt is declared final and >>>> thus cannot be extended. >>>> >>>> Fix : >>>> >>>> The last line of Raster.createWritableRaster() method already has a >>>> way to handle generic case if the input does not match any of the >>>> cases in switch statements in that method. >>>> >>>> The fact that " *InterleavedRaster() constructors throw exception >>>> if DataBuffer passed to them does not match the expected type" was >>>> ignored earlier. >>>> >>>> This fix adds a check of "DataBuffer type" before creating >>>> respective >>>> *InterleavedRaster() objects. >>>> >>>> It constructs the SunWritableRaster in case DataBuffer type does not >>>> match any data specific DataBuffer classes (DataBufferByte, >>>> DataBufferUShort, DataBufferInt) >>>> >>>> Request to review webrev containing this fix : >>>> >>>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.00/ >>>> >>>> Regards, >>>> >>>> Ajit >>>> >>> >>> >>> -- >>> Best regards, Sergey. >>> >> >> -- Best regards, Sergey. From philip.race at oracle.com Mon Mar 21 20:28:08 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 21 Mar 2016 13:28:08 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8055463: Needs public API allowing full access to font collections in Font.createFont() In-Reply-To: <56F0565C.1090208@oracle.com> References: <56E1FAFC.6040609@oracle.com> <56E1FD1C.5060008@oracle.com> <56E32904.4050501@oracle.com> <56E32BCD.3070002@oracle.com> <56E44258.6050000@oracle.com> <56F034D1.5090607@oracle.com> <56F0565C.1090208@oracle.com> Message-ID: <56F05958.9040105@oracle.com> On 03/21/2016 01:15 PM, Vadim Pakhnushev wrote: > Phil, > > Now the javadoc for both java.awt.Font.createFonts methods is incorrect: > * The explicit purpose of this overloading of the > * {@code createFont(int, InputStream)} method > > It's not an overload anymore. That is true. I'll just change "overloading" to "variation on" -phil. > > Other than that, looks good. > > Vadim > > On 21.03.2016 20:52, Phil Race wrote: >> After some CCC discussion the method name was changed from createFont >> to createFonts >> since it is expected to suport returning > 1. No other changes. >> http://cr.openjdk.java.net/~prr/8055463.2 >> >> I am still looking for a 2nd reviewer ! >> >> -phil. >> >> >> On 03/12/2016 08:22 AM, Sergey Bylokhov wrote: >>> Looks fine. >>> ps: for the record - long time ago the OSX code was different: >>> http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/e910dde2c36c >>> >>> On 11.03.16 23:34, Phil Race wrote: >>>> Oops. Fixed : http://cr.openjdk.java.net/~prr/8055463.1/ >>>> >>>> -phil. >>>> >>>> On 03/11/2016 12:22 PM, Sergey Bylokhov wrote: >>>>> Hi, Phil. >>>>> The FileFont.java contains debug code: >>>>> >>>>> System.out.println("COUNT="+count); >>>>> System.out.println("FILE="+fontFile); >>>>> >>>>> >>>>> On 11.03.16 2:02, Phil Race wrote: >>>>>> PS there are a couple of other test files updated here >>>>>> >>>>>> BigFont is one of the tests I ran whilst checking I didn't create >>>>>> regressions >>>>>> and it failed because it assumes a SecurityManager. I could not >>>>>> find an >>>>>> open bug on that.* >>>>>> >>>>>> *GetLCIDFromLocale happened to be the one I chose to paste in >>>>>> the GPL and then I noticed it incorrectly had the classpath >>>>>> exception >>>>>> so I am fixing that here too. >>>>>> >>>>>> -phil. >>>>>> >>>>>> >>>>>> On 03/10/2016 02:53 PM, Phil Race wrote: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8055463 >>>>>>> http://cr.openjdk.java.net/~prr/8055463/ >>>>>>> >>>>>>> Proposal is to add two new methods in the Font class paralleling >>>>>>> the >>>>>>> existing ones >>>>>>> that return only a single font. >>>>>>> >>>>>>> Font[] createFont(File) >>>>>>> Font[] createFont(InputStream) >>>>>>> >>>>>>> I tried to make the single & multiple code be shared as much as >>>>>>> possible >>>>>>> to avoid duplication and I eliminated code in the OSX sub-class >>>>>>> which >>>>>>> seemed to be a pointless copy of the superclass. >>>>>>> >>>>>>> The test checks the various assertions I intend by probing for >>>>>>> platform fonts. >>>>>>> >>>>>>> -phil. >>>>>> >>>>> >>>>> >>>> >>> >>> >> > From Sergey.Bylokhov at oracle.com Tue Mar 22 02:09:16 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 22 Mar 2016 05:09:16 +0300 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream In-Reply-To: References: <99cb1549-30b5-44af-b399-ebed22255cf8@default> <56E997F1.2070605@oracle.com> <56E9C39D.6090701@oracle.com> <56E9D1D5.8090500@oracle.com> <56EAB79C.1080503@oracle.com> <88e50a67-fdd2-4b97-aa19-3ac5d419e2cf@default> <56EAFD38.80604@oracle.com> Message-ID: <56F0A94C.8080703@oracle.com> Hi, Jay. Since we decided to update the specification we get an additional flexibility in the fix, because we can update the "@exception IOException" part of javadoc and describe that it can be thrown if ImageXXXStream cannot be created. I don't see a big differences of both approaches in case of write() methods, but in case of read(which has the similar issue but was skipped in the fix) there is a difference. Note that the read(File) unlike other methods throws the unspecified IIOException exception if ImageXXXStream cannot be created. We can think about unification of read/write methods in ImageIO. Hmm but even then read() in some cases will return null and in some cases throw an exception.... and createImageInputStream/createImageOutputStream() will look alien as they always return null not an exception. Another possible unification is to update javadoc for all methods, that they will return null if related providers are not found(in this case "throw new IIOException("Can't create an ImageInputStream!"))" should be removed from read(File); On 21.03.16 10:26, Jayathirth D V wrote: > Hi Sergey, > > For the second approach I have created webrev for review. > > Please review updated webrev : > http://cr.openjdk.java.net/~jdv/8044289/webrev.02/ > > Thanks, > Jay > > -----Original Message----- > From: Jayathirth D V > Sent: Friday, March 18, 2016 2:23 PM > To: Sergey Bylokhov > Cc: 2d-dev at openjdk.java.net; Philip Race > Subject: RE: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream > > Hi Sergey, > > Thanks for your inputs. > > Indeed all the null values returned by createImageInputStream() and createImageInputStream() are valid only. > > I went through the code more and found that there is no need for fix in ImageIO.read() methods as null stream is handled in read(ImageInputStream stream) which is called by all the remaining read() API's through IAE. So i can remove the changes made in ImageIO.read() functions. Also istream is closed in finally block of read(url). > > For ImageIO.write(File) & ImageIO.write(OutputStream) NPE we have two approaches for fix: > > 1) Keep the present changes of throwing IOException when stream is null and change the throw clause of write() spec mentioning: > "IOException - if an error occurs during writing or not able to create required ImageOutputStream" > > 2) Remove the present changes and handle null in doWrite() method by returning false when stream is null & add code in finally block to close the stream only when stream is not null. Along with this we can also change Returns clause of spec to mention that write() might return false when we are not able to create ImageOutputStream. > > private static boolean doWrite(RenderedImage im, ImageWriter writer, > ImageOutputStream output) throws IOException { > if (writer == null) { > return false; > } > + if (output == null) { > + return false; > + } > > try { > return doWrite(im, writer, stream); > } finally { > + if (stream != null) > stream.close(); > } > > Returns : > false if no appropriate writer is found or not able to create required ImageOutputStream. > > Please let me know your inputs. > > Thanks, > Jay > > -----Original Message----- > From: Sergey Bylokhov > Sent: Friday, March 18, 2016 12:24 AM > To: Jayathirth D V > Cc: 2d-dev at openjdk.java.net; Philip Race > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream > > On 17.03.16 21:14, Jayathirth D V wrote: >> There are many places in createImageInputStream() and createImageOutputStream() where it will return null for stream. > > But when why you change the write/read methods? They should take null into account and work according to specification. If some bogus null returns from createImageInputStream/createImageOutputStream then it should be fixed in these methods. >> >> So for NPE described in bug to occur there can be multiple paths: >> 1) One of the path described in bug is when theRegistry.getServiceProviders() throws IAE and we return null. > > This is the case when we have no installed spi and should return null/false. > >> 2) When we pass non-existent file path to ImageIO (as described in http://stackoverflow.com/questions/11153200/with-imageio-write-api-call-i-get-nullpointerexception ). Here we catch FileNotFoundException but still we return stream as null at the end which will cause NPE further. > > This is same thing described in the bug(about stream.close()). The write method call createImageOutputStream() and got FileNotFoundException. > This exception should be propagated to the user, but it is replaced in the finally block, because we try to close the stream=null. So the fix for this particular case is to check the stream to null in finally, No? > >> 3) When we don't support the provider and theRegistry.getServiceProviders() return iterator with size zero. > > This means that our providers do not support this case, and we should return null/false. > >> >> For us to follow first scenario we need access to categoryMap of IIORegistry and delete the ImageInputStreamSpi/ ImageOutputStreamSpi but I was not able to find a way to tamper it from test case. If we follow second case FileNotFoundException will be thrown by default eventhough we handle NPE. > > But you change the code and we now contradicts the specification, in your case the test should expect false/null from write()/read(). > >> >> In the test case we are trying to following third scenario to get stream as null to verify the code changes. > > To catch the bogus null we should try to use another approach, or change the spec. But it seems all null values above are correct, we should be ready for them. > >> >> As part of collective fix we are throwing IOException which will indicate that we are not able to create required stream. >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Thursday, March 17, 2016 7:27 PM >> To: Phil Race >> Cc: Jayathirth D V; 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >> ImageIO.read() and write() NPE is not handled properly for stream >> >> On 17.03.16 0:36, Phil Race wrote: >>> I don't think that is the actual reason here >> >> But the test doing exactly this thing -> deregister all spi => in this >> case according to specification all related >> methods(read/write/creatImageInputStream/creatImageOutputStream) should return null or false. >> >> - it seems likely that there >>> was some kind of internal error or bad SPI causing this. >>> So throwing an exception seems more appropriate. >> >> the problem was in some of our methods which do not expect null in some places(like stream.close() from the bug description). >> >>> And also the bug was originally solely about write(..). >>> >>> -phil. >>> >>> >>> On 03/16/2016 01:35 PM, Sergey Bylokhov wrote: >>>> As far as I understand the createImageInputStream() returns null is >>>> this stream is unsupported by current plugins via spi. Probably the >>>> read() method should return null too? >>>> >>>> /** >>>> * Returns a {@code BufferedImage} as the result of decoding >>>> * a supplied {@code InputStream} with an {@code ImageReader} >>>> * chosen automatically from among those currently registered. >>>> * The {@code InputStream} is wrapped in an >>>> * {@code ImageInputStream}. If no registered >>>> * {@code ImageReader} claims to be able to read the >>>> * resulting stream, {@code null} is returned. >>>> * >>>> ....... >>>> * @return a {@code BufferedImage} containing the decoded >>>> * contents of the input, or {@code null}. >>>> */ >>>> public static BufferedImage read(InputStream input) throws >>>> IOException >>>> >>>> >>>> On 16.03.16 20:29, Philip Race wrote: >>>>> The test writes out into "test.src". >>>>> I believe that you should treat that as a "read-only" location. >>>>> Write to a tempfile (File.createTempFile()) or TESTCLASSES. >>>>> >>>>> -phil. >>>>> >>>>> On 3/15/16, 10:50 PM, Jayathirth D V wrote: >>>>>> >>>>>> Hi Phil,All >>>>>> >>>>>> _Please review the following fix in JDK9:_ >>>>>> >>>>>> __ >>>>>> >>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8044289 >>>>>> >>>>>> Webrev : http://cr.openjdk.java.net/~jdv/8044289/webrev.00/ >>>>>> >>>>>> >>>>>> Issue : When createImageInputStream() or createImageOutputStream >>>>>> returns null in ImageIO.read() or ImageIO.write() we are seeing >>>>>> NPE as it stream is used further without null check. >>>>>> >>>>>> Root cause : "stream" is used without checking whether it is null >>>>>> or not. >>>>>> >>>>>> Solution : Handle null pointer of stream and throw IIOException. >>>>>> >>>>>> Test case contains all possible scenarios where >>>>>> createImageInputStream() or createImageOutputStream can return null. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jay >>>>>> >>>> >>>> >>> >> >> >> -- >> Best regards, Sergey. >> > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From jayathirth.d.v at oracle.com Tue Mar 22 09:34:01 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 22 Mar 2016 02:34:01 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream In-Reply-To: <56F0A94C.8080703@oracle.com> References: <99cb1549-30b5-44af-b399-ebed22255cf8@default> <56E997F1.2070605@oracle.com> <56E9C39D.6090701@oracle.com> <56E9D1D5.8090500@oracle.com> <56EAB79C.1080503@oracle.com> <88e50a67-fdd2-4b97-aa19-3ac5d419e2cf@default> <56EAFD38.80604@oracle.com> <56F0A94C.8080703@oracle.com> Message-ID: Hi Sergey, I have unified changes related to ImageIO.read() and ImageIO.write(). In case of read() we will be returning null when createImageInputStream() returns null. In case of write() we will be returning false when createImageOutputStream() returns null. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/8044289/webrev.03/ Thanks, Jay -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, March 22, 2016 7:39 AM To: Jayathirth D V; Philip Race Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream Hi, Jay. Since we decided to update the specification we get an additional flexibility in the fix, because we can update the "@exception IOException" part of javadoc and describe that it can be thrown if ImageXXXStream cannot be created. I don't see a big differences of both approaches in case of write() methods, but in case of read(which has the similar issue but was skipped in the fix) there is a difference. Note that the read(File) unlike other methods throws the unspecified IIOException exception if ImageXXXStream cannot be created. We can think about unification of read/write methods in ImageIO. Hmm but even then read() in some cases will return null and in some cases throw an exception.... and createImageInputStream/createImageOutputStream() will look alien as they always return null not an exception. Another possible unification is to update javadoc for all methods, that they will return null if related providers are not found(in this case "throw new IIOException("Can't create an ImageInputStream!"))" should be removed from read(File); On 21.03.16 10:26, Jayathirth D V wrote: > Hi Sergey, > > For the second approach I have created webrev for review. > > Please review updated webrev : > http://cr.openjdk.java.net/~jdv/8044289/webrev.02/ > > Thanks, > Jay > > -----Original Message----- > From: Jayathirth D V > Sent: Friday, March 18, 2016 2:23 PM > To: Sergey Bylokhov > Cc: 2d-dev at openjdk.java.net; Philip Race > Subject: RE: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In > ImageIO.read() and write() NPE is not handled properly for stream > > Hi Sergey, > > Thanks for your inputs. > > Indeed all the null values returned by createImageInputStream() and createImageInputStream() are valid only. > > I went through the code more and found that there is no need for fix in ImageIO.read() methods as null stream is handled in read(ImageInputStream stream) which is called by all the remaining read() API's through IAE. So i can remove the changes made in ImageIO.read() functions. Also istream is closed in finally block of read(url). > > For ImageIO.write(File) & ImageIO.write(OutputStream) NPE we have two approaches for fix: > > 1) Keep the present changes of throwing IOException when stream is null and change the throw clause of write() spec mentioning: > "IOException - if an error occurs during writing or not able to create required ImageOutputStream" > > 2) Remove the present changes and handle null in doWrite() method by returning false when stream is null & add code in finally block to close the stream only when stream is not null. Along with this we can also change Returns clause of spec to mention that write() might return false when we are not able to create ImageOutputStream. > > private static boolean doWrite(RenderedImage im, ImageWriter writer, > ImageOutputStream output) throws IOException { > if (writer == null) { > return false; > } > + if (output == null) { > + return false; > + } > > try { > return doWrite(im, writer, stream); > } finally { > + if (stream != null) > stream.close(); > } > > Returns : > false if no appropriate writer is found or not able to create required ImageOutputStream. > > Please let me know your inputs. > > Thanks, > Jay > > -----Original Message----- > From: Sergey Bylokhov > Sent: Friday, March 18, 2016 12:24 AM > To: Jayathirth D V > Cc: 2d-dev at openjdk.java.net; Philip Race > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In > ImageIO.read() and write() NPE is not handled properly for stream > > On 17.03.16 21:14, Jayathirth D V wrote: >> There are many places in createImageInputStream() and createImageOutputStream() where it will return null for stream. > > But when why you change the write/read methods? They should take null into account and work according to specification. If some bogus null returns from createImageInputStream/createImageOutputStream then it should be fixed in these methods. >> >> So for NPE described in bug to occur there can be multiple paths: >> 1) One of the path described in bug is when theRegistry.getServiceProviders() throws IAE and we return null. > > This is the case when we have no installed spi and should return null/false. > >> 2) When we pass non-existent file path to ImageIO (as described in http://stackoverflow.com/questions/11153200/with-imageio-write-api-call-i-get-nullpointerexception ). Here we catch FileNotFoundException but still we return stream as null at the end which will cause NPE further. > > This is same thing described in the bug(about stream.close()). The write method call createImageOutputStream() and got FileNotFoundException. > This exception should be propagated to the user, but it is replaced in the finally block, because we try to close the stream=null. So the fix for this particular case is to check the stream to null in finally, No? > >> 3) When we don't support the provider and theRegistry.getServiceProviders() return iterator with size zero. > > This means that our providers do not support this case, and we should return null/false. > >> >> For us to follow first scenario we need access to categoryMap of IIORegistry and delete the ImageInputStreamSpi/ ImageOutputStreamSpi but I was not able to find a way to tamper it from test case. If we follow second case FileNotFoundException will be thrown by default eventhough we handle NPE. > > But you change the code and we now contradicts the specification, in your case the test should expect false/null from write()/read(). > >> >> In the test case we are trying to following third scenario to get stream as null to verify the code changes. > > To catch the bogus null we should try to use another approach, or change the spec. But it seems all null values above are correct, we should be ready for them. > >> >> As part of collective fix we are throwing IOException which will indicate that we are not able to create required stream. >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Thursday, March 17, 2016 7:27 PM >> To: Phil Race >> Cc: Jayathirth D V; 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >> ImageIO.read() and write() NPE is not handled properly for stream >> >> On 17.03.16 0:36, Phil Race wrote: >>> I don't think that is the actual reason here >> >> But the test doing exactly this thing -> deregister all spi => in >> this case according to specification all related >> methods(read/write/creatImageInputStream/creatImageOutputStream) should return null or false. >> >> - it seems likely that there >>> was some kind of internal error or bad SPI causing this. >>> So throwing an exception seems more appropriate. >> >> the problem was in some of our methods which do not expect null in some places(like stream.close() from the bug description). >> >>> And also the bug was originally solely about write(..). >>> >>> -phil. >>> >>> >>> On 03/16/2016 01:35 PM, Sergey Bylokhov wrote: >>>> As far as I understand the createImageInputStream() returns null is >>>> this stream is unsupported by current plugins via spi. Probably the >>>> read() method should return null too? >>>> >>>> /** >>>> * Returns a {@code BufferedImage} as the result of decoding >>>> * a supplied {@code InputStream} with an {@code ImageReader} >>>> * chosen automatically from among those currently registered. >>>> * The {@code InputStream} is wrapped in an >>>> * {@code ImageInputStream}. If no registered >>>> * {@code ImageReader} claims to be able to read the >>>> * resulting stream, {@code null} is returned. >>>> * >>>> ....... >>>> * @return a {@code BufferedImage} containing the decoded >>>> * contents of the input, or {@code null}. >>>> */ >>>> public static BufferedImage read(InputStream input) throws >>>> IOException >>>> >>>> >>>> On 16.03.16 20:29, Philip Race wrote: >>>>> The test writes out into "test.src". >>>>> I believe that you should treat that as a "read-only" location. >>>>> Write to a tempfile (File.createTempFile()) or TESTCLASSES. >>>>> >>>>> -phil. >>>>> >>>>> On 3/15/16, 10:50 PM, Jayathirth D V wrote: >>>>>> >>>>>> Hi Phil,All >>>>>> >>>>>> _Please review the following fix in JDK9:_ >>>>>> >>>>>> __ >>>>>> >>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8044289 >>>>>> >>>>>> Webrev : http://cr.openjdk.java.net/~jdv/8044289/webrev.00/ >>>>>> >>>>>> >>>>>> Issue : When createImageInputStream() or createImageOutputStream >>>>>> returns null in ImageIO.read() or ImageIO.write() we are seeing >>>>>> NPE as it stream is used further without null check. >>>>>> >>>>>> Root cause : "stream" is used without checking whether it is null >>>>>> or not. >>>>>> >>>>>> Solution : Handle null pointer of stream and throw IIOException. >>>>>> >>>>>> Test case contains all possible scenarios where >>>>>> createImageInputStream() or createImageOutputStream can return null. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jay >>>>>> >>>> >>>> >>> >> >> >> -- >> Best regards, Sergey. >> > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Tue Mar 22 11:25:18 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Tue, 22 Mar 2016 16:55:18 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8042713, , [macosx] Print dialog does not update attribute set with page range In-Reply-To: <56EC5524.8040601@oracle.com> References: <56EBC421.7050109@oracle.com> <56EC5524.8040601@oracle.com> Message-ID: <56F12B9E.9000804@oracle.com> Hi Phil, I have modified the webrev as per your review comment regarding 0-based page indices that osx native supports. http://cr.openjdk.java.net/~psadhukhan/8042713/webrev.01/ I have tested with copies and pageranges set with my testcase and also test/java/awt/print/PrinterJob/PageRanges.java Also, I found one issue with the previous change in that if we select PageRange and then print and then we select ALL, then also previous page ranges was getting printed and not "All" pages. This was because osx CPrinterJob.setAttributes() checks for SunPageSelection.class but nowhere SunPageSelection.RANGE/ALL is getting added to attribute in osx so attributes.get(SunPageSelection.class) was returning null and setPageRange() was getting set with wrong values. I added SunPageSelection.RANGE/ALL to attribute and also made sure if SunPageSelection.ALL is selected, then setPageRange(-1, -1) is set similar to windows. Regards Prasanta On 3/19/2016 12:51 AM, Phil Race wrote: > The bug report seems to be lacking a proper (any) evaluation. > > It is probably not accurate to say it did not call the "correct" > methods since > the problem is actually that there was no method that did this and you > needed > to add them and make sure they also did what they in turn called what > native > had been calling after setting the attribute. > > > The change itself seems to be mimicing what happens in Windows > printing code, > ie WPrinterJob.setRangeCopiesAttribute(..) ? > > Is this intentional ? If so that would have been useful to point out > so I did not > need to hunt it down. Looking at that code I see that is does a couple of > other things (1) has a way of indicating an explicitly set number of > copies > vs default copies, (2) accepts a boolean indicating if in the dialog a > range > was actually requested. It looks like in the OSX code we only make the > upcall > in that case, but I need you to verify that all this works as it is > supposed to. > > Also native used to use a zero-based index and you have changed that > without > commenting on it. First it is still zero-based in the initialisation > and may not > always be changed. Secondly if you want 1-based then you seem to have > a problem as the new Java method calls > > setPageRange(from, to); > > with the 1-based values and that seems to be the method which accepted > the zero-based values. > This seems very fishy. > > > -phil. > > > On 03/18/2016 02:02 AM, prasanta sadhukhan wrote: >> Hi Phil, >> >> Please review a fix for >> bug: https://bugs.openjdk.java.net/browse/JDK-8042713 >> webrev: http://cr.openjdk.java.net/~psadhukhan/8042713/webrev.00/ >> >> The OS X platform print dialog has an option to set the page ranges. >> If this is done it ought to be reported back in the AttributeSet. >> but it was found that the page range attribute is not reported back . >> >> This is because nsPrintInfoToJavaPrinterJob() does not call correct >> Java setxxxAttributes methods to set the attributes. >> >> I added the corresponding setPageRangeAttribute method along with >> setCopiesAttribute method to report back the "page range" and >> "copies" in AttributeSet. >> >> Regards >> Prasanta > From prahalad.kumar.narayanan at oracle.com Tue Mar 22 11:35:06 2016 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Tue, 22 Mar 2016 04:35:06 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: Antialiased text on translucent backgrounds gets bright artifacts In-Reply-To: <56EB4DBB.9080802@oracle.com> References: <63d69ba8-d5cf-4697-bb5c-f51aaaa8c427@default> <56EB4DBB.9080802@oracle.com> Message-ID: Hello Everyone on Java2D Group Good day to you. This is a Follow-up to Review Request on the bug: Bug : JDK-8015070 Anti-aliased Text on Translucent background gets bright artifacts Bug Link : https://bugs.openjdk.java.net/browse/JDK-8015070 First, Sincere thanks to Jim for his valuable feedback. 1. As Jim correctly mentioned, SRCOVER_MASKFILL has a similar logic to blend two Translucent colors based on an Alpha mask. 2. The calculations are exactly the same as the changes in previous webrev. However the logic of SRCOVER_MASKFILL is 'Optimized' to reduce the number of computations. 3. This optimization is definitely required because, the logic is executed for every single pixel in a glyph. Example: If a string is made up of 5 English characters with each character having 32 x 32 pixels, The anti-aliasing logic will be executed for 5 x 32 x 32 iterations. Reducing computation per pixel will imply a huge benefit for complete drawString operation. Observation from SRCOVER_MASKFILL 1. The mask fill reduces computations by through multiple if(...) conditions. Each if condition affirms whether the next set of computations are required. 2. Optimization 1: If mask value is 0- skip entire logic. 3. Optimization 2: If mask value is maximum, say 255, take srcA directly without multiplying with maskAlpha ( Reason: 1 * srcAlpha = srcAlpha ) 4. Optimization 3: Compute pre-multiplied resColor in two steps. First with srcColor and then with dstColor. If the resAlpha from 1st step (i.e., srcColor) is fully opaque, avoid blending dstColor altogether. Changes in Current Webrev.01 1. The fix for the current bug is modelled based on SRCOVER_MASKFILL. 2. The changes have been verified to work on windows, linux and mac operating systems. 3. The automated Test file- AADrawStringArtifact.java runs as expected Identifies artifact & throws exception when run on JDK 7 and 8. With JDK9, the test file returns without error. 3. JPRT build has been run to ensure, changes build on all supported platforms. JPRT job link : http://scaaa637.us.oracle.com//archive/2016/03/2016-03-22-070604.prahnara-linux.client Kindly review the changes in the below mentioned link and provide your views Webrev Link : http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.01/ Thank you for your time in review Have a good day Prahalad N. -----Original Message----- From: Jim Graham Sent: Friday, March 18, 2016 6:07 AM To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: Antialiased text on translucent backgrounds gets bright artifacts Hi Prahalad, This basically boils down to "alpha blending math needs to be performed in premultiplied form" and the existing code was not doing that. Your changes do add a pre-multiplication step to the math in two places - when you mix the src alpha and the glyph alpha at the top of the macro, and again when you do the Multiply(dst, dstA, dst) step in the middle. In that sense, the new math is correct. However, it is not the optimal way to implement this. In particular, the macro used here to load the data from the destination is the one that loads it into 4 ARGB non-premultiplied values. If the destination is non-PRE, then your added multiply step is exactly what is needed, but it could be combined with the multiply that will happen later in the blending equation, so it is an added step rather than a fixed fraction in the existing MultMultAdd parameters. Additionally, if the destination is already PRE, then the macro being used to load the dst pixel data there will have done a divide step to divide out the alpha from the destination, only to have you reverse that math with your new Multiply() step. That's a lot of math to end up with a NOP. The MUL8 you added for the srcA and glyph value is needed, that change is good. Since it is common for glyph pixels to have zero alpha, you might want to test the glyph alpha for 0 and skip the pixel before you do the multiply, though. This would add one more if, but it would be a common case. The trickier part is to load the destination components without un-premultiplying them. Unfortunately there is no "Load...ToArgbPre" macro to parallel the Load macro used in the function. Perhaps there should be, but you'd still end up with an extra multiply step as I mentioned above because you can fold the premultiplication of the dst data into the MultMultAdd by carefully choosing the parameters you use in the math there. The good news is that the way that the SRCOVER_MASKFILL uses the various type-specific macros works around this a bit and minimizes the number of multiplies that happen. You could check out DEFINE_SRCOVER_MASKFILL and see how it works in the case where pMask is not null (pMask is an alpha mask with values very similar to the glyphAA data). Modeling this code on that code would correct the math and minimize it as well... ...jim On 3/17/16 3:00 AM, Prahalad Kumar Narayanan wrote: > Hello Everyone on Java2D Group > > Good day to you. > > Herewith, I 'm sharing the webrev for two identical Java2D Bugs. > > Bug ID : JDK-8015070 > > Title : Antialiased text on translucent backgrounds gets > bright artifacts > > Link : https://bugs.openjdk.java.net/browse/JDK-8015070 > > Bug ID : JDK-8013564 ( currently closed as duplicate ) > > Title : Font rendering anti-aliasing in translucent > BufferedImages broken > > Link : https://bugs.openjdk.java.net/browse/JDK-8013564 > > Webrev Link : > http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.00/ > > Quick Summary on Bugs : > > ```````````````````````````````````````````````` > > 1. Artifacts appear on Edges of text characters when anti-aliased > text is drawn on Translucent background > > 2. The issue is reproducible on all platforms - windows, linux and mac os. > > 3. Besides, the issue is reproduced with the commonly used pixel > format- 4ByteArgb. > > Root Cause & Solution : > > ```````````````````````````````````````````````` > > 1. The Macro: GlyphListAABlend4ByteArgb in File: LoopMacros.h uses > the standard blending algorithm > > dstColor = [ srcColor * glyphAlpha + dstColor * (1 - > glyphAlpha) ] / dstAlpha > > 2. The above equation works only when the srcColor and dstColor are Opaque. > > 3. When srcColor and dstColor are Translucent, their alphaComponent > will influence the visibility of the color, and visibility of the > color below. > > 4. The new set of calculations for blending Translucent source and > destination colors is given as > > resAlpha = 1 - ((1 - srcAlpha) * (1 - dstAlpha)) > > resColor = [ srcColor * srcAlpha + dstColor * dstAlpha * (1 - > srcAlpha) ] / resAlpha > > 5. Reference text for the equation: > https://en.wikipedia.org/wiki/Alpha_compositing > > 6. With the above modification to the blending logic, the artifacts > do not appear and issues are fixed. > > Jtreg & Jprt Results : > > ```````````````````````````````````````````````` > > 1. A simple test-file: AADrawStringArtifact.java has been created to > be a part of jtreg test cases. > > The test file is well commented to explain - nature of > artifact and how the test tries to identify them. > > As required, the test case fails with Jdk 7, Jdk 8 and > succeeds with Jdk 9-internal (built with changes for the bug fix) > > 2. The changes to blending logic lies within > java.desktop/src/share/native/... > > Henceforth, JPRT was used to ensure successful build across > all supported platforms > > Jprt Job Link : > http://scaaa637.us.oracle.com//archive/2016/03/2016-03-17-072001.prahn > ara-linux.client > > The build succeeds on all platforms. > > Kindly review the webrev link and provide your views and suggestions. > > Webrev Link : > http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.00/ > > If the changes look good, we could take up the changes for source checkin. > > Thank you for your time in review > > Have a good day > > Prahalad N. > From Sergey.Bylokhov at oracle.com Tue Mar 22 12:50:43 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 22 Mar 2016 15:50:43 +0300 Subject: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: Antialiased text on translucent backgrounds gets bright artifacts In-Reply-To: References: <63d69ba8-d5cf-4697-bb5c-f51aaaa8c427@default> <56EB4DBB.9080802@oracle.com> Message-ID: <56F13FA3.6030305@oracle.com> Just curious, is the approach in SRCOVER_MASKFILL faster? I think yes, but it adds and an additional branches which can affect performance. Did you measure the difference? On 22.03.16 14:35, Prahalad Kumar Narayanan wrote: > Observation from SRCOVER_MASKFILL > 1. The mask fill reduces computations by through multiple if(...) conditions. > Each if condition affirms whether the next set of computations are required. > 2. Optimization 1: If mask value is 0- skip entire logic. > 3. Optimization 2: If mask value is maximum, say 255, take srcA directly without multiplying with maskAlpha ( Reason: 1 * srcAlpha = srcAlpha ) > 4. Optimization 3: Compute pre-multiplied resColor in two steps. First with srcColor and then with dstColor. > If the resAlpha from 1st step (i.e., srcColor) is fully opaque, avoid blending dstColor altogether. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Mar 22 16:22:24 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 22 Mar 2016 19:22:24 +0300 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream In-Reply-To: References: <99cb1549-30b5-44af-b399-ebed22255cf8@default> <56E997F1.2070605@oracle.com> <56E9C39D.6090701@oracle.com> <56E9D1D5.8090500@oracle.com> <56EAB79C.1080503@oracle.com> <88e50a67-fdd2-4b97-aa19-3ac5d419e2cf@default> <56EAFD38.80604@oracle.com> <56F0A94C.8080703@oracle.com> Message-ID: <56F17140.2070208@oracle.com> This fix looks fine to me. At least it made all code work in a similar way. But probably someone will have other opinion? On 22.03.16 12:34, Jayathirth D V wrote: > Hi Sergey, > > I have unified changes related to ImageIO.read() and ImageIO.write(). > > In case of read() we will be returning null when createImageInputStream() returns null. > In case of write() we will be returning false when createImageOutputStream() returns null. > > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/8044289/webrev.03/ > > Thanks, > Jay > > -----Original Message----- > From: Sergey Bylokhov > Sent: Tuesday, March 22, 2016 7:39 AM > To: Jayathirth D V; Philip Race > Cc: 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream > > Hi, Jay. > Since we decided to update the specification we get an additional flexibility in the fix, because we can update the "@exception IOException" part of javadoc and describe that it can be thrown if ImageXXXStream cannot be created. > > I don't see a big differences of both approaches in case of write() methods, but in case of read(which has the similar issue but was skipped in the fix) there is a difference. > Note that the read(File) unlike other methods throws the unspecified IIOException exception if ImageXXXStream cannot be created. We can think about unification of read/write methods in ImageIO. Hmm but even then > read() in some cases will return null and in some cases throw an exception.... > and createImageInputStream/createImageOutputStream() will look alien as they always return null not an exception. > > Another possible unification is to update javadoc for all methods, that they will return null if related providers are not found(in this case "throw new IIOException("Can't create an ImageInputStream!"))" should be removed from read(File); > > On 21.03.16 10:26, Jayathirth D V wrote: >> Hi Sergey, >> >> For the second approach I have created webrev for review. >> >> Please review updated webrev : >> http://cr.openjdk.java.net/~jdv/8044289/webrev.02/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jayathirth D V >> Sent: Friday, March 18, 2016 2:23 PM >> To: Sergey Bylokhov >> Cc: 2d-dev at openjdk.java.net; Philip Race >> Subject: RE: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >> ImageIO.read() and write() NPE is not handled properly for stream >> >> Hi Sergey, >> >> Thanks for your inputs. >> >> Indeed all the null values returned by createImageInputStream() and createImageInputStream() are valid only. >> >> I went through the code more and found that there is no need for fix in ImageIO.read() methods as null stream is handled in read(ImageInputStream stream) which is called by all the remaining read() API's through IAE. So i can remove the changes made in ImageIO.read() functions. Also istream is closed in finally block of read(url). >> >> For ImageIO.write(File) & ImageIO.write(OutputStream) NPE we have two approaches for fix: >> >> 1) Keep the present changes of throwing IOException when stream is null and change the throw clause of write() spec mentioning: >> "IOException - if an error occurs during writing or not able to create required ImageOutputStream" >> >> 2) Remove the present changes and handle null in doWrite() method by returning false when stream is null & add code in finally block to close the stream only when stream is not null. Along with this we can also change Returns clause of spec to mention that write() might return false when we are not able to create ImageOutputStream. >> >> private static boolean doWrite(RenderedImage im, ImageWriter writer, >> ImageOutputStream output) throws IOException { >> if (writer == null) { >> return false; >> } >> + if (output == null) { >> + return false; >> + } >> >> try { >> return doWrite(im, writer, stream); >> } finally { >> + if (stream != null) >> stream.close(); >> } >> >> Returns : >> false if no appropriate writer is found or not able to create required ImageOutputStream. >> >> Please let me know your inputs. >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Friday, March 18, 2016 12:24 AM >> To: Jayathirth D V >> Cc: 2d-dev at openjdk.java.net; Philip Race >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >> ImageIO.read() and write() NPE is not handled properly for stream >> >> On 17.03.16 21:14, Jayathirth D V wrote: >>> There are many places in createImageInputStream() and createImageOutputStream() where it will return null for stream. >> >> But when why you change the write/read methods? They should take null into account and work according to specification. If some bogus null returns from createImageInputStream/createImageOutputStream then it should be fixed in these methods. >>> >>> So for NPE described in bug to occur there can be multiple paths: >>> 1) One of the path described in bug is when theRegistry.getServiceProviders() throws IAE and we return null. >> >> This is the case when we have no installed spi and should return null/false. >> >>> 2) When we pass non-existent file path to ImageIO (as described in http://stackoverflow.com/questions/11153200/with-imageio-write-api-call-i-get-nullpointerexception ). Here we catch FileNotFoundException but still we return stream as null at the end which will cause NPE further. >> >> This is same thing described in the bug(about stream.close()). The write method call createImageOutputStream() and got FileNotFoundException. >> This exception should be propagated to the user, but it is replaced in the finally block, because we try to close the stream=null. So the fix for this particular case is to check the stream to null in finally, No? >> >>> 3) When we don't support the provider and theRegistry.getServiceProviders() return iterator with size zero. >> >> This means that our providers do not support this case, and we should return null/false. >> >>> >>> For us to follow first scenario we need access to categoryMap of IIORegistry and delete the ImageInputStreamSpi/ ImageOutputStreamSpi but I was not able to find a way to tamper it from test case. If we follow second case FileNotFoundException will be thrown by default eventhough we handle NPE. >> >> But you change the code and we now contradicts the specification, in your case the test should expect false/null from write()/read(). >> >>> >>> In the test case we are trying to following third scenario to get stream as null to verify the code changes. >> >> To catch the bogus null we should try to use another approach, or change the spec. But it seems all null values above are correct, we should be ready for them. >> >>> >>> As part of collective fix we are throwing IOException which will indicate that we are not able to create required stream. >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Sergey Bylokhov >>> Sent: Thursday, March 17, 2016 7:27 PM >>> To: Phil Race >>> Cc: Jayathirth D V; 2d-dev at openjdk.java.net >>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >>> ImageIO.read() and write() NPE is not handled properly for stream >>> >>> On 17.03.16 0:36, Phil Race wrote: >>>> I don't think that is the actual reason here >>> >>> But the test doing exactly this thing -> deregister all spi => in >>> this case according to specification all related >>> methods(read/write/creatImageInputStream/creatImageOutputStream) should return null or false. >>> >>> - it seems likely that there >>>> was some kind of internal error or bad SPI causing this. >>>> So throwing an exception seems more appropriate. >>> >>> the problem was in some of our methods which do not expect null in some places(like stream.close() from the bug description). >>> >>>> And also the bug was originally solely about write(..). >>>> >>>> -phil. >>>> >>>> >>>> On 03/16/2016 01:35 PM, Sergey Bylokhov wrote: >>>>> As far as I understand the createImageInputStream() returns null is >>>>> this stream is unsupported by current plugins via spi. Probably the >>>>> read() method should return null too? >>>>> >>>>> /** >>>>> * Returns a {@code BufferedImage} as the result of decoding >>>>> * a supplied {@code InputStream} with an {@code ImageReader} >>>>> * chosen automatically from among those currently registered. >>>>> * The {@code InputStream} is wrapped in an >>>>> * {@code ImageInputStream}. If no registered >>>>> * {@code ImageReader} claims to be able to read the >>>>> * resulting stream, {@code null} is returned. >>>>> * >>>>> ....... >>>>> * @return a {@code BufferedImage} containing the decoded >>>>> * contents of the input, or {@code null}. >>>>> */ >>>>> public static BufferedImage read(InputStream input) throws >>>>> IOException >>>>> >>>>> >>>>> On 16.03.16 20:29, Philip Race wrote: >>>>>> The test writes out into "test.src". >>>>>> I believe that you should treat that as a "read-only" location. >>>>>> Write to a tempfile (File.createTempFile()) or TESTCLASSES. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 3/15/16, 10:50 PM, Jayathirth D V wrote: >>>>>>> >>>>>>> Hi Phil,All >>>>>>> >>>>>>> _Please review the following fix in JDK9:_ >>>>>>> >>>>>>> __ >>>>>>> >>>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8044289 >>>>>>> >>>>>>> Webrev : http://cr.openjdk.java.net/~jdv/8044289/webrev.00/ >>>>>>> >>>>>>> >>>>>>> Issue : When createImageInputStream() or createImageOutputStream >>>>>>> returns null in ImageIO.read() or ImageIO.write() we are seeing >>>>>>> NPE as it stream is used further without null check. >>>>>>> >>>>>>> Root cause : "stream" is used without checking whether it is null >>>>>>> or not. >>>>>>> >>>>>>> Solution : Handle null pointer of stream and throw IIOException. >>>>>>> >>>>>>> Test case contains all possible scenarios where >>>>>>> createImageInputStream() or createImageOutputStream can return null. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Jay >>>>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> Best regards, Sergey. >>> >> >> >> -- >> Best regards, Sergey. >> > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From alexander.v.stepanov at oracle.com Tue Mar 22 16:31:03 2016 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Tue, 22 Mar 2016 19:31:03 +0300 Subject: [OpenJDK 2D-Dev] RFR 8149558: [TEST] add regression test for JDK-8150154 In-Reply-To: <56E8345F.4040006@oracle.com> References: <56BDB583.5020806@oracle.com> <56CF1B0A.2030603@oracle.com> <56D069FB.4050503@oracle.com> <56D07546.4010906@oracle.com> <56E8345F.4040006@oracle.com> Message-ID: <56F17347.90102@oracle.com> Sorry, just a reminder. Thanks, Alexander On 3/15/2016 7:12 PM, Alexander Stepanov wrote: > Please see the updated fix: > http://cr.openjdk.java.net/~avstepan/8149558/webrev.01/ > > Thanks, > Alexander > > On 2/26/2016 6:54 PM, Alexander Stepanov wrote: >> > Should we also test bmp and jpg? >> >> couldn't use writer for these formats "as is" (simply >> "writer.write(img)") - this causes IOExceptions. JPEGImageWriteParam >> or BMPImageWriteParam should be used and another signature for >> write() method. Extended test logic looks quite bulky with all this >> additions. >> >> > but you do not check that the saved information actually relates to >> the particular image (all of them have a white color and same size) >> >> even in this case we have color check failure for pair >> (TYPE_USHORT_565_RGB, TYPE_USHORT_555_RGB). but yes, probably it is >> better to use different images for the 1st and 2nd write attempts. >> >> Thanks, >> Alexander >> >> On 2/26/2016 6:06 PM, Sergey Bylokhov wrote: >>> Should we also test bmp and jpg? You tested a different BI formats, >>> but you do not check that the saved information actually relates to >>> the particular image(all of them have a white color and same size). >>> So you will not notice if the Writer will write the same(first) >>> image in all subsequent calls. >>> >>> On 25.02.16 18:17, Alexander Stepanov wrote: >>>> Sorry, just a reminder. >>>> >>>> Thanks, >>>> Alexander >>>> >>>> On 2/12/2016 1:35 PM, Alexander Stepanov wrote: >>>>> Hello, >>>>> >>>>> Could you please review the following fix >>>>> http://cr.openjdk.java.net/~avstepan/8149558/webrev.00/ >>>>> for >>>>> https://bugs.openjdk.java.net/browse/JDK-8149558 >>>>> >>>>> Just a single regression test added (still failing), plus minor >>>>> correction for other test. >>>>> >>>>> Thanks, >>>>> Alexander >>>>> >>>> >>> >>> >> > From Sergey.Bylokhov at oracle.com Tue Mar 22 17:27:46 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 22 Mar 2016 20:27:46 +0300 Subject: [OpenJDK 2D-Dev] RFR 8149558: [TEST] add regression test for JDK-8150154 In-Reply-To: <56F17347.90102@oracle.com> References: <56BDB583.5020806@oracle.com> <56CF1B0A.2030603@oracle.com> <56D069FB.4050503@oracle.com> <56D07546.4010906@oracle.com> <56E8345F.4040006@oracle.com> <56F17347.90102@oracle.com> Message-ID: <56F18092.20300@oracle.com> On 22.03.16 19:31, Alexander Stepanov wrote: > Sorry, just a reminder. Can you provide an information what was changed in this version? > > Thanks, > Alexander > > On 3/15/2016 7:12 PM, Alexander Stepanov wrote: >> Please see the updated fix: >> http://cr.openjdk.java.net/~avstepan/8149558/webrev.01/ >> >> Thanks, >> Alexander >> >> On 2/26/2016 6:54 PM, Alexander Stepanov wrote: >>> > Should we also test bmp and jpg? >>> >>> couldn't use writer for these formats "as is" (simply >>> "writer.write(img)") - this causes IOExceptions. JPEGImageWriteParam >>> or BMPImageWriteParam should be used and another signature for >>> write() method. Extended test logic looks quite bulky with all this >>> additions. >>> >>> > but you do not check that the saved information actually relates to >>> the particular image (all of them have a white color and same size) >>> >>> even in this case we have color check failure for pair >>> (TYPE_USHORT_565_RGB, TYPE_USHORT_555_RGB). but yes, probably it is >>> better to use different images for the 1st and 2nd write attempts. >>> >>> Thanks, >>> Alexander >>> >>> On 2/26/2016 6:06 PM, Sergey Bylokhov wrote: >>>> Should we also test bmp and jpg? You tested a different BI formats, >>>> but you do not check that the saved information actually relates to >>>> the particular image(all of them have a white color and same size). >>>> So you will not notice if the Writer will write the same(first) >>>> image in all subsequent calls. >>>> >>>> On 25.02.16 18:17, Alexander Stepanov wrote: >>>>> Sorry, just a reminder. >>>>> >>>>> Thanks, >>>>> Alexander >>>>> >>>>> On 2/12/2016 1:35 PM, Alexander Stepanov wrote: >>>>>> Hello, >>>>>> >>>>>> Could you please review the following fix >>>>>> http://cr.openjdk.java.net/~avstepan/8149558/webrev.00/ >>>>>> for >>>>>> https://bugs.openjdk.java.net/browse/JDK-8149558 >>>>>> >>>>>> Just a single regression test added (still failing), plus minor >>>>>> correction for other test. >>>>>> >>>>>> Thanks, >>>>>> Alexander >>>>>> >>>>> >>>> >>>> >>> >> > -- Best regards, Sergey. From jayathirth.d.v at oracle.com Tue Mar 22 17:49:34 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 22 Mar 2016 10:49:34 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream In-Reply-To: <56F17140.2070208@oracle.com> References: <99cb1549-30b5-44af-b399-ebed22255cf8@default> <56E997F1.2070605@oracle.com> <56E9C39D.6090701@oracle.com> <56E9D1D5.8090500@oracle.com> <56EAB79C.1080503@oracle.com> <88e50a67-fdd2-4b97-aa19-3ac5d419e2cf@default> <56EAFD38.80604@oracle.com> <56F0A94C.8080703@oracle.com> <56F17140.2070208@oracle.com> Message-ID: <481ff313-103f-4a71-bec9-44a3fa0a70ef@default> Thanks for the review Sergey. Can I get +1 for this please? -Jay -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, March 22, 2016 9:52 PM To: Jayathirth D V; Philip Race Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream This fix looks fine to me. At least it made all code work in a similar way. But probably someone will have other opinion? On 22.03.16 12:34, Jayathirth D V wrote: > Hi Sergey, > > I have unified changes related to ImageIO.read() and ImageIO.write(). > > In case of read() we will be returning null when createImageInputStream() returns null. > In case of write() we will be returning false when createImageOutputStream() returns null. > > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/8044289/webrev.03/ > > Thanks, > Jay > > -----Original Message----- > From: Sergey Bylokhov > Sent: Tuesday, March 22, 2016 7:39 AM > To: Jayathirth D V; Philip Race > Cc: 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In > ImageIO.read() and write() NPE is not handled properly for stream > > Hi, Jay. > Since we decided to update the specification we get an additional flexibility in the fix, because we can update the "@exception IOException" part of javadoc and describe that it can be thrown if ImageXXXStream cannot be created. > > I don't see a big differences of both approaches in case of write() methods, but in case of read(which has the similar issue but was skipped in the fix) there is a difference. > Note that the read(File) unlike other methods throws the unspecified > IIOException exception if ImageXXXStream cannot be created. We can > think about unification of read/write methods in ImageIO. Hmm but even > then > read() in some cases will return null and in some cases throw an exception.... > and createImageInputStream/createImageOutputStream() will look alien as they always return null not an exception. > > Another possible unification is to update javadoc for all methods, > that they will return null if related providers are not found(in this > case "throw new IIOException("Can't create an ImageInputStream!"))" > should be removed from read(File); > > On 21.03.16 10:26, Jayathirth D V wrote: >> Hi Sergey, >> >> For the second approach I have created webrev for review. >> >> Please review updated webrev : >> http://cr.openjdk.java.net/~jdv/8044289/webrev.02/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jayathirth D V >> Sent: Friday, March 18, 2016 2:23 PM >> To: Sergey Bylokhov >> Cc: 2d-dev at openjdk.java.net; Philip Race >> Subject: RE: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >> ImageIO.read() and write() NPE is not handled properly for stream >> >> Hi Sergey, >> >> Thanks for your inputs. >> >> Indeed all the null values returned by createImageInputStream() and createImageInputStream() are valid only. >> >> I went through the code more and found that there is no need for fix in ImageIO.read() methods as null stream is handled in read(ImageInputStream stream) which is called by all the remaining read() API's through IAE. So i can remove the changes made in ImageIO.read() functions. Also istream is closed in finally block of read(url). >> >> For ImageIO.write(File) & ImageIO.write(OutputStream) NPE we have two approaches for fix: >> >> 1) Keep the present changes of throwing IOException when stream is null and change the throw clause of write() spec mentioning: >> "IOException - if an error occurs during writing or not able to create required ImageOutputStream" >> >> 2) Remove the present changes and handle null in doWrite() method by returning false when stream is null & add code in finally block to close the stream only when stream is not null. Along with this we can also change Returns clause of spec to mention that write() might return false when we are not able to create ImageOutputStream. >> >> private static boolean doWrite(RenderedImage im, ImageWriter writer, >> ImageOutputStream output) throws IOException { >> if (writer == null) { >> return false; >> } >> + if (output == null) { >> + return false; >> + } >> >> try { >> return doWrite(im, writer, stream); >> } finally { >> + if (stream != null) >> stream.close(); >> } >> >> Returns : >> false if no appropriate writer is found or not able to create required ImageOutputStream. >> >> Please let me know your inputs. >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Friday, March 18, 2016 12:24 AM >> To: Jayathirth D V >> Cc: 2d-dev at openjdk.java.net; Philip Race >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >> ImageIO.read() and write() NPE is not handled properly for stream >> >> On 17.03.16 21:14, Jayathirth D V wrote: >>> There are many places in createImageInputStream() and createImageOutputStream() where it will return null for stream. >> >> But when why you change the write/read methods? They should take null into account and work according to specification. If some bogus null returns from createImageInputStream/createImageOutputStream then it should be fixed in these methods. >>> >>> So for NPE described in bug to occur there can be multiple paths: >>> 1) One of the path described in bug is when theRegistry.getServiceProviders() throws IAE and we return null. >> >> This is the case when we have no installed spi and should return null/false. >> >>> 2) When we pass non-existent file path to ImageIO (as described in http://stackoverflow.com/questions/11153200/with-imageio-write-api-call-i-get-nullpointerexception ). Here we catch FileNotFoundException but still we return stream as null at the end which will cause NPE further. >> >> This is same thing described in the bug(about stream.close()). The write method call createImageOutputStream() and got FileNotFoundException. >> This exception should be propagated to the user, but it is replaced in the finally block, because we try to close the stream=null. So the fix for this particular case is to check the stream to null in finally, No? >> >>> 3) When we don't support the provider and theRegistry.getServiceProviders() return iterator with size zero. >> >> This means that our providers do not support this case, and we should return null/false. >> >>> >>> For us to follow first scenario we need access to categoryMap of IIORegistry and delete the ImageInputStreamSpi/ ImageOutputStreamSpi but I was not able to find a way to tamper it from test case. If we follow second case FileNotFoundException will be thrown by default eventhough we handle NPE. >> >> But you change the code and we now contradicts the specification, in your case the test should expect false/null from write()/read(). >> >>> >>> In the test case we are trying to following third scenario to get stream as null to verify the code changes. >> >> To catch the bogus null we should try to use another approach, or change the spec. But it seems all null values above are correct, we should be ready for them. >> >>> >>> As part of collective fix we are throwing IOException which will indicate that we are not able to create required stream. >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Sergey Bylokhov >>> Sent: Thursday, March 17, 2016 7:27 PM >>> To: Phil Race >>> Cc: Jayathirth D V; 2d-dev at openjdk.java.net >>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >>> ImageIO.read() and write() NPE is not handled properly for stream >>> >>> On 17.03.16 0:36, Phil Race wrote: >>>> I don't think that is the actual reason here >>> >>> But the test doing exactly this thing -> deregister all spi => in >>> this case according to specification all related >>> methods(read/write/creatImageInputStream/creatImageOutputStream) should return null or false. >>> >>> - it seems likely that there >>>> was some kind of internal error or bad SPI causing this. >>>> So throwing an exception seems more appropriate. >>> >>> the problem was in some of our methods which do not expect null in some places(like stream.close() from the bug description). >>> >>>> And also the bug was originally solely about write(..). >>>> >>>> -phil. >>>> >>>> >>>> On 03/16/2016 01:35 PM, Sergey Bylokhov wrote: >>>>> As far as I understand the createImageInputStream() returns null >>>>> is this stream is unsupported by current plugins via spi. Probably >>>>> the >>>>> read() method should return null too? >>>>> >>>>> /** >>>>> * Returns a {@code BufferedImage} as the result of decoding >>>>> * a supplied {@code InputStream} with an {@code ImageReader} >>>>> * chosen automatically from among those currently registered. >>>>> * The {@code InputStream} is wrapped in an >>>>> * {@code ImageInputStream}. If no registered >>>>> * {@code ImageReader} claims to be able to read the >>>>> * resulting stream, {@code null} is returned. >>>>> * >>>>> ....... >>>>> * @return a {@code BufferedImage} containing the decoded >>>>> * contents of the input, or {@code null}. >>>>> */ >>>>> public static BufferedImage read(InputStream input) throws >>>>> IOException >>>>> >>>>> >>>>> On 16.03.16 20:29, Philip Race wrote: >>>>>> The test writes out into "test.src". >>>>>> I believe that you should treat that as a "read-only" location. >>>>>> Write to a tempfile (File.createTempFile()) or TESTCLASSES. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 3/15/16, 10:50 PM, Jayathirth D V wrote: >>>>>>> >>>>>>> Hi Phil,All >>>>>>> >>>>>>> _Please review the following fix in JDK9:_ >>>>>>> >>>>>>> __ >>>>>>> >>>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8044289 >>>>>>> >>>>>>> Webrev : http://cr.openjdk.java.net/~jdv/8044289/webrev.00/ >>>>>>> >>>>>>> >>>>>>> Issue : When createImageInputStream() or createImageOutputStream >>>>>>> returns null in ImageIO.read() or ImageIO.write() we are seeing >>>>>>> NPE as it stream is used further without null check. >>>>>>> >>>>>>> Root cause : "stream" is used without checking whether it is >>>>>>> null or not. >>>>>>> >>>>>>> Solution : Handle null pointer of stream and throw IIOException. >>>>>>> >>>>>>> Test case contains all possible scenarios where >>>>>>> createImageInputStream() or createImageOutputStream can return null. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Jay >>>>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> Best regards, Sergey. >>> >> >> >> -- >> Best regards, Sergey. >> > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From philip.race at oracle.com Tue Mar 22 19:51:32 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 22 Mar 2016 12:51:32 -0700 Subject: [OpenJDK 2D-Dev] RFR 8144938: Handle properly coordinate overflow in Marlin Renderer In-Reply-To: <56EC8573.3090307@oracle.com> References: <56E2159E.8000209@oracle.com> <56E22734.7020707@oracle.com> <56E33249.2030300@oracle.com> <56E74A98.30503@oracle.com> <56E89082.5040703@oracle.com> <56E9FF2C.4020308@oracle.com> <56EB4F86.7000002@oracle.com> <56EC8573.3090307@oracle.com> Message-ID: <56F1A244.9000408@oracle.com> +1 .. looks like a nice simplification. Sorry it took me a couple of days to get back to this. -phil. On 03/18/2016 03:47 PM, Jim Graham wrote: > The edit looks fine to me... Phil? > > ...jim > > On 3/18/16 9:52 AM, Laurent Bourg?s wrote: >> Jim, >> >> Here is a final webrev (for archive): >> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144938.5/ >> >> Changes: >> - remove loops in CrashNaNTest >> >> Hope it is ready to go ! >> >> I need another reviewer, please. >> >> >> 2016-03-18 1:44 GMT+01:00 Jim Graham > >: >> >> Hi Laurent, >> >> That looks fine. If the subPathStarted changes are the only changes >> then it's good to go. If there was some other change that I missed, >> let me know so I can review it as well. >> >> >> No this webrev had only changes in MRE.pathToLoop() you reviewed. >> >> >> One curiosity - in the test case, why are there 3 for loops that >> perform exactly one pass? (lines 134, 221, 282) I'm guessing that >> maybe in a former life this code may have been part of a performance >> suite or something? It's not a bug, just an odd bit of code. You >> can delete them if you want, but I don't need to see a review of >> that... >> >> >> Fixed, now. >> >> Cheers, >> Laurent From james.graham at oracle.com Tue Mar 22 22:28:02 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 22 Mar 2016 15:28:02 -0700 Subject: [OpenJDK 2D-Dev] [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception In-Reply-To: References: <3969befd-57cd-48ee-bed5-173a28e7bd08@default> <56DFFC9F.4020403@oracle.com> <70f247c0-6f3e-472a-b7b0-b02814010e30@default> <56E16D0A.3060807@oracle.com> <56E1E2A5.1020008@oracle.com> Message-ID: <56F1C6F2.6000305@oracle.com> Hi Ajit, Most of your if statements are spaced wrong. There should be a space between "if" and the parentheses. I'll review more later, but I noticed that issue in the first couple of files I looked at... ...jim On 3/15/16 7:05 AM, Ajit Ghaisas wrote: > Hi, > > Thanks Sergey and Jim for suggestions. > > I have made the data specific Raster constructors type safe now. Also, I have modified all Raster creations in Raster.java to support custom DataBuffer classes. > > Please review the changes present in updated webrev : > http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.02/ > > Regards, > Ajit > > -----Original Message----- > From: Jim Graham > Sent: Friday, March 11, 2016 2:40 AM > To: Sergey Bylokhov; Ajit Ghaisas; 2d-dev > Subject: Re: [OpenJDK 2D-Dev] [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception > > Yes, those constructors should be type-safe. Perhaps that was done to save code in the caller, but that is a small price to pay to avoid errors in the future, and it makes sure there is a backup plan for different kinds of buffers... > > ...jim > > On 3/10/16 4:48 AM, Sergey Bylokhov wrote: >> Hi, Ajit. >> What about other cases in Raster.java, where the DataBuffer is passed >> as a parameter? Probably we can simplify the code and find all such >> issues if we changes the ByteInterleavedRaster/etc. For example: >> >> ByteInterleavedRaster(SampleModel sampleModel,DataBuffer >> dataBuffer,...) to >> >> ByteInterleavedRaster(SampleModel sampleModel,DataBufferByte >> dataBuffer,...) >> >> Because we throw an exception in such cases anyway: >> >> if (!(dataBuffer instanceof DataBufferByte)) { >> throw new RasterFormatException("ByteInterleavedRasters must have " >> + "byte DataBuffers"); >> } >> >> And the compiler will help us, what everybody think about it? >> >> On 09.03.16 17:38, Ajit Ghaisas wrote: >>> Hi, >>> >>> Modified the test and added check for MultiPixelPackedSampleModel >>> condition. >>> >>> Please review updated webrev : >>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.01/ >>> >>> Regards, >>> Ajit >>> >>> -----Original Message----- >>> From: Sergey Bylokhov >>> Sent: Wednesday, March 09, 2016 4:06 PM >>> To: Ajit Ghaisas; awt-dev at openjdk.java.net; Semyon Sadetsky; Ambarish >>> Rapte; 2d-dev >>> Subject: Re: [9] Review-request for 6353518: Creation of a >>> WritableRaster with a custom DataBuffer causes erroneous Exception >>> >>> Changes for 2d area.(cc) >>> >>> >>> On 07.03.16 11:20, Ajit Ghaisas wrote: >>>> Hi, >>>> >>>> Bug : https://bugs.openjdk.java.net/browse/JDK-6353518 >>>> >>>> Issue : (Text from bug description) >>>> >>>> An attempt to create a WritableRaster via >>>> Raster.createWritableRaster(SampleModel sm, DataBuffer db, Point >>>> location) using a custom DataBuffer causes an erroneous >>>> RasterFormatException. >>>> Apparently the reason for this bug is that IntegerComponentRaster >>>> insists on being passed an instance of DataBufferInt rather than >>>> just a DataBuffer with a DataType of TYPE_INT. >>>> This is quite annoying since DataBufferInt is declared final and >>>> thus cannot be extended. >>>> >>>> Fix : >>>> >>>> The last line of Raster.createWritableRaster() method already has a >>>> way to handle generic case if the input does not match any of the >>>> cases in switch statements in that method. >>>> >>>> The fact that " *InterleavedRaster() constructors throw exception >>>> if DataBuffer passed to them does not match the expected type" was >>>> ignored earlier. >>>> >>>> This fix adds a check of "DataBuffer type" before creating >>>> respective >>>> *InterleavedRaster() objects. >>>> >>>> It constructs the SunWritableRaster in case DataBuffer type does not >>>> match any data specific DataBuffer classes (DataBufferByte, >>>> DataBufferUShort, DataBufferInt) >>>> >>>> Request to review webrev containing this fix : >>>> >>>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.00/ >>>> >>>> Regards, >>>> >>>> Ajit >>>> >>> >>> >>> -- >>> Best regards, Sergey. >>> >> >> From philip.race at oracle.com Tue Mar 22 23:10:19 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 22 Mar 2016 16:10:19 -0700 Subject: [OpenJDK 2D-Dev] [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception In-Reply-To: <56F1C6F2.6000305@oracle.com> References: <3969befd-57cd-48ee-bed5-173a28e7bd08@default> <56DFFC9F.4020403@oracle.com> <70f247c0-6f3e-472a-b7b0-b02814010e30@default> <56E16D0A.3060807@oracle.com> <56E1E2A5.1020008@oracle.com> <56F1C6F2.6000305@oracle.com> Message-ID: <56F1D0DB.9000508@oracle.com> Ajit, There is also some odd indentation in ByteBandedRaster.java which is not yours but 98 public ByteBandedRaster(SampleModel sampleModel, 99 DataBufferByte dataBuffer, 100 Point origin) { This appears to be the result of someone using tabs a long time ago. Since you are touching the method signature lines anyway may be better fixed so we have these aligned public ByteBandedRaster(SampleModel sampleModel, DataBufferByte dataBuffer, Point origin) { [not sure if that will make it through mail as intended]. Here in Raster.java, the first condition now seems to be redundant .. 890 if (dataType == DataBuffer.TYPE_BYTE && 891 dataBuffer instanceof DataBufferByte && -phil. On 03/22/2016 03:28 PM, Jim Graham wrote: > Hi Ajit, > > Most of your if statements are spaced wrong. There should be a space > between "if" and the parentheses. I'll review more later, but I > noticed that issue in the first couple of files I looked at... > > ...jim > > On 3/15/16 7:05 AM, Ajit Ghaisas wrote: >> Hi, >> >> Thanks Sergey and Jim for suggestions. >> >> I have made the data specific Raster constructors type safe >> now. Also, I have modified all Raster creations in Raster.java to >> support custom DataBuffer classes. >> >> Please review the changes present in updated webrev : >> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.02/ >> >> Regards, >> Ajit >> >> -----Original Message----- >> From: Jim Graham >> Sent: Friday, March 11, 2016 2:40 AM >> To: Sergey Bylokhov; Ajit Ghaisas; 2d-dev >> Subject: Re: [OpenJDK 2D-Dev] [9] Review-request for 6353518: >> Creation of a WritableRaster with a custom DataBuffer causes >> erroneous Exception >> >> Yes, those constructors should be type-safe. Perhaps that was done >> to save code in the caller, but that is a small price to pay to avoid >> errors in the future, and it makes sure there is a backup plan for >> different kinds of buffers... >> >> ...jim >> >> On 3/10/16 4:48 AM, Sergey Bylokhov wrote: >>> Hi, Ajit. >>> What about other cases in Raster.java, where the DataBuffer is passed >>> as a parameter? Probably we can simplify the code and find all such >>> issues if we changes the ByteInterleavedRaster/etc. For example: >>> >>> ByteInterleavedRaster(SampleModel sampleModel,DataBuffer >>> dataBuffer,...) to >>> >>> ByteInterleavedRaster(SampleModel sampleModel,DataBufferByte >>> dataBuffer,...) >>> >>> Because we throw an exception in such cases anyway: >>> >>> if (!(dataBuffer instanceof DataBufferByte)) { >>> throw new RasterFormatException("ByteInterleavedRasters must >>> have " >>> + "byte DataBuffers"); >>> } >>> >>> And the compiler will help us, what everybody think about it? >>> >>> On 09.03.16 17:38, Ajit Ghaisas wrote: >>>> Hi, >>>> >>>> Modified the test and added check for MultiPixelPackedSampleModel >>>> condition. >>>> >>>> Please review updated webrev : >>>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.01/ >>>> >>>> Regards, >>>> Ajit >>>> >>>> -----Original Message----- >>>> From: Sergey Bylokhov >>>> Sent: Wednesday, March 09, 2016 4:06 PM >>>> To: Ajit Ghaisas; awt-dev at openjdk.java.net; Semyon Sadetsky; Ambarish >>>> Rapte; 2d-dev >>>> Subject: Re: [9] Review-request for 6353518: Creation of a >>>> WritableRaster with a custom DataBuffer causes erroneous Exception >>>> >>>> Changes for 2d area.(cc) >>>> >>>> >>>> On 07.03.16 11:20, Ajit Ghaisas wrote: >>>>> Hi, >>>>> >>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-6353518 >>>>> >>>>> Issue : (Text from bug description) >>>>> >>>>> An attempt to create a WritableRaster via >>>>> Raster.createWritableRaster(SampleModel sm, DataBuffer db, Point >>>>> location) using a custom DataBuffer causes an erroneous >>>>> RasterFormatException. >>>>> Apparently the reason for this bug is that IntegerComponentRaster >>>>> insists on being passed an instance of DataBufferInt rather than >>>>> just a DataBuffer with a DataType of TYPE_INT. >>>>> This is quite annoying since DataBufferInt is declared final and >>>>> thus cannot be extended. >>>>> >>>>> Fix : >>>>> >>>>> The last line of Raster.createWritableRaster() method already has a >>>>> way to handle generic case if the input does not match any of the >>>>> cases in switch statements in that method. >>>>> >>>>> The fact that " *InterleavedRaster() constructors throw exception >>>>> if DataBuffer passed to them does not match the expected type" was >>>>> ignored earlier. >>>>> >>>>> This fix adds a check of "DataBuffer type" before creating >>>>> respective >>>>> *InterleavedRaster() objects. >>>>> >>>>> It constructs the SunWritableRaster in case DataBuffer type does not >>>>> match any data specific DataBuffer classes (DataBufferByte, >>>>> DataBufferUShort, DataBufferInt) >>>>> >>>>> Request to review webrev containing this fix : >>>>> >>>>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.00/ >>>>> >>>>> Regards, >>>>> >>>>> Ajit >>>>> >>>> >>>> >>>> -- >>>> Best regards, Sergey. >>>> >>> >>> From prasanta.sadhukhan at oracle.com Wed Mar 23 07:26:00 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Wed, 23 Mar 2016 12:56:00 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-7107620, , Need to round in test java/awt/print/PageFormat/PageFormatFromAttributes.java Message-ID: <56F24508.2060703@oracle.com> Hi Phil, Please review a simple fix for jdk9. Bug: https://bugs.openjdk.java.net/browse/JDK-7107620 webrev: http://cr.openjdk.java.net/~psadhukhan/7107620/webrev.00/ It was seen width/height obtained by calculating via MediaSize/units is not same as obtained from Paper.getWIdth/getHeight(). It seems the testcase is storing the result of the calculations in "int" varible whereas MediaSize.getX()/getY() is "float" and units is "double" variable thereby resulting is loss of precision. It was only seen in osx as osx returns a integer value for getWidth()/getHeight() ie 842 instead of ~841.889 maybe because it rounds off to nearest whereas MediaSize/units value is stored as 841 when typecasted to int resulting in failure. Modified testcase to store in "double" to avoid loss of precision and use Math.round() to round off to nearest value before comparing these 2 values (from MediaSize/units and getWidth/getHeight). Tested in windows, linux, mac to be working. Regards Prasanta From alexander.v.stepanov at oracle.com Wed Mar 23 09:46:36 2016 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Wed, 23 Mar 2016 12:46:36 +0300 Subject: [OpenJDK 2D-Dev] RFR 8149558: [TEST] add regression test for JDK-8150154 In-Reply-To: <56F18092.20300@oracle.com> References: <56BDB583.5020806@oracle.com> <56CF1B0A.2030603@oracle.com> <56D069FB.4050503@oracle.com> <56D07546.4010906@oracle.com> <56E8345F.4040006@oracle.com> <56F17347.90102@oracle.com> <56F18092.20300@oracle.com> Message-ID: <56F265FC.9090807@oracle.com> Hello, Sergey, > Should we also test bmp and jpg? covered as well > all of them have a white color and same size for the 2nd version the images used for the 1st and 2nd checks have different sizes and colors Thanks, Alexander On 3/22/2016 8:27 PM, Sergey Bylokhov wrote: > On 22.03.16 19:31, Alexander Stepanov wrote: >> Sorry, just a reminder. > > Can you provide an information what was changed in this version? > >> >> Thanks, >> Alexander >> >> On 3/15/2016 7:12 PM, Alexander Stepanov wrote: >>> Please see the updated fix: >>> http://cr.openjdk.java.net/~avstepan/8149558/webrev.01/ >>> >>> Thanks, >>> Alexander >>> >>> On 2/26/2016 6:54 PM, Alexander Stepanov wrote: >>>> > Should we also test bmp and jpg? >>>> >>>> couldn't use writer for these formats "as is" (simply >>>> "writer.write(img)") - this causes IOExceptions. JPEGImageWriteParam >>>> or BMPImageWriteParam should be used and another signature for >>>> write() method. Extended test logic looks quite bulky with all this >>>> additions. >>>> >>>> > but you do not check that the saved information actually relates to >>>> the particular image (all of them have a white color and same size) >>>> >>>> even in this case we have color check failure for pair >>>> (TYPE_USHORT_565_RGB, TYPE_USHORT_555_RGB). but yes, probably it is >>>> better to use different images for the 1st and 2nd write attempts. >>>> >>>> Thanks, >>>> Alexander >>>> >>>> On 2/26/2016 6:06 PM, Sergey Bylokhov wrote: >>>>> Should we also test bmp and jpg? You tested a different BI formats, >>>>> but you do not check that the saved information actually relates to >>>>> the particular image(all of them have a white color and same size). >>>>> So you will not notice if the Writer will write the same(first) >>>>> image in all subsequent calls. >>>>> >>>>> On 25.02.16 18:17, Alexander Stepanov wrote: >>>>>> Sorry, just a reminder. >>>>>> >>>>>> Thanks, >>>>>> Alexander >>>>>> >>>>>> On 2/12/2016 1:35 PM, Alexander Stepanov wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Could you please review the following fix >>>>>>> http://cr.openjdk.java.net/~avstepan/8149558/webrev.00/ >>>>>>> for >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8149558 >>>>>>> >>>>>>> Just a single regression test added (still failing), plus minor >>>>>>> correction for other test. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexander >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> > > From prasanta.sadhukhan at oracle.com Wed Mar 23 11:02:35 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Wed, 23 Mar 2016 16:32:35 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8061258, , [macosx] PrinterJob's native Print Dialog does not reflect specified Copies or Page Ranges Message-ID: <56F277CB.40207@oracle.com> Hi Phil, Please review a fix for jdk9 Bug: https://bugs.openjdk.java.net/browse/JDK-8061258 webrev :http://cr.openjdk.java.net/~psadhukhan/8061258/webrev.00/ When user attempts to pre-populate the native dialog with copies and page ranges by calling PrintRequestAttributeSet aset = new HashPrintRequestAttributeSet(); aset.add(new Copies(2)); aset.add(new PageRanges(3,4)); the print dialog does not reflect the user-defined setting. This is because osx native code was calling getNumberOfPages() from OpenBook.java which was returning UNKNOWN_NUMBER_OF_PAGES (-1). Since getNumberOfPages() returned -1, osx always selected NSPrintAllPages or All Radio button. I fixed it by removing this call to getNumberOfPages() and rely on getMinPage/getMaxPage() as was done in windows (awt_PrintControl.cpp:AwtPrintControl::InitPrintDialog) to select which radio button to be selected. If fromPage > minPage or toPage < maxPage, it means user has selected page ranges so PageRange radio button is to be selected else "All" radio button to be selected. Regards Prasanta From ajit.ghaisas at oracle.com Wed Mar 23 12:41:58 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Wed, 23 Mar 2016 05:41:58 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception In-Reply-To: <56F1D0DB.9000508@oracle.com> References: <3969befd-57cd-48ee-bed5-173a28e7bd08@default> <56DFFC9F.4020403@oracle.com> <70f247c0-6f3e-472a-b7b0-b02814010e30@default> <56E16D0A.3060807@oracle.com> <56E1E2A5.1020008@oracle.com> <56F1C6F2.6000305@oracle.com> <56F1D0DB.9000508@oracle.com> Message-ID: <05f9f1e8-6f29-4863-a95e-060eaa09c5b4@default> Thanks Jim and Phil. Yes. It was a mistake to omit spaces in 'if' conditions. I have corrected the spacing issues for my changes now. I have corrected the indentation of the lines similar to those mentioned by Phil. I have also removed the redundant first condition check on line 890 in Raster.java mentioned as a review comment. Please review updated webrev : http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.03/ Regards, Ajit -----Original Message----- From: Phil Race Sent: Wednesday, March 23, 2016 4:40 AM To: Jim Graham Cc: Ajit Ghaisas; Sergey Bylokhov; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception Ajit, There is also some odd indentation in ByteBandedRaster.java which is not yours but 98 public ByteBandedRaster(SampleModel sampleModel, 99 DataBufferByte dataBuffer, 100 Point origin) { This appears to be the result of someone using tabs a long time ago. Since you are touching the method signature lines anyway may be better fixed so we have these aligned public ByteBandedRaster(SampleModel sampleModel, DataBufferByte dataBuffer, Point origin) { [not sure if that will make it through mail as intended]. Here in Raster.java, the first condition now seems to be redundant .. 890 if (dataType == DataBuffer.TYPE_BYTE && 891 dataBuffer instanceof DataBufferByte && -phil. On 03/22/2016 03:28 PM, Jim Graham wrote: > Hi Ajit, > > Most of your if statements are spaced wrong. There should be a space > between "if" and the parentheses. I'll review more later, but I > noticed that issue in the first couple of files I looked at... > > ...jim > > On 3/15/16 7:05 AM, Ajit Ghaisas wrote: >> Hi, >> >> Thanks Sergey and Jim for suggestions. >> >> I have made the data specific Raster constructors type safe now. >> Also, I have modified all Raster creations in Raster.java to support >> custom DataBuffer classes. >> >> Please review the changes present in updated webrev : >> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.02/ >> >> Regards, >> Ajit >> >> -----Original Message----- >> From: Jim Graham >> Sent: Friday, March 11, 2016 2:40 AM >> To: Sergey Bylokhov; Ajit Ghaisas; 2d-dev >> Subject: Re: [OpenJDK 2D-Dev] [9] Review-request for 6353518: >> Creation of a WritableRaster with a custom DataBuffer causes >> erroneous Exception >> >> Yes, those constructors should be type-safe. Perhaps that was done >> to save code in the caller, but that is a small price to pay to avoid >> errors in the future, and it makes sure there is a backup plan for >> different kinds of buffers... >> >> ...jim >> >> On 3/10/16 4:48 AM, Sergey Bylokhov wrote: >>> Hi, Ajit. >>> What about other cases in Raster.java, where the DataBuffer is >>> passed as a parameter? Probably we can simplify the code and find >>> all such issues if we changes the ByteInterleavedRaster/etc. For example: >>> >>> ByteInterleavedRaster(SampleModel sampleModel,DataBuffer >>> dataBuffer,...) to >>> >>> ByteInterleavedRaster(SampleModel sampleModel,DataBufferByte >>> dataBuffer,...) >>> >>> Because we throw an exception in such cases anyway: >>> >>> if (!(dataBuffer instanceof DataBufferByte)) { >>> throw new RasterFormatException("ByteInterleavedRasters must >>> have " >>> + "byte DataBuffers"); >>> } >>> >>> And the compiler will help us, what everybody think about it? >>> >>> On 09.03.16 17:38, Ajit Ghaisas wrote: >>>> Hi, >>>> >>>> Modified the test and added check for >>>> MultiPixelPackedSampleModel condition. >>>> >>>> Please review updated webrev : >>>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.01/ >>>> >>>> Regards, >>>> Ajit >>>> >>>> -----Original Message----- >>>> From: Sergey Bylokhov >>>> Sent: Wednesday, March 09, 2016 4:06 PM >>>> To: Ajit Ghaisas; awt-dev at openjdk.java.net; Semyon Sadetsky; >>>> Ambarish Rapte; 2d-dev >>>> Subject: Re: [9] Review-request for 6353518: Creation of a >>>> WritableRaster with a custom DataBuffer causes erroneous Exception >>>> >>>> Changes for 2d area.(cc) >>>> >>>> >>>> On 07.03.16 11:20, Ajit Ghaisas wrote: >>>>> Hi, >>>>> >>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-6353518 >>>>> >>>>> Issue : (Text from bug description) >>>>> >>>>> An attempt to create a WritableRaster via >>>>> Raster.createWritableRaster(SampleModel sm, DataBuffer db, Point >>>>> location) using a custom DataBuffer causes an erroneous >>>>> RasterFormatException. >>>>> Apparently the reason for this bug is that IntegerComponentRaster >>>>> insists on being passed an instance of DataBufferInt rather than >>>>> just a DataBuffer with a DataType of TYPE_INT. >>>>> This is quite annoying since DataBufferInt is declared final and >>>>> thus cannot be extended. >>>>> >>>>> Fix : >>>>> >>>>> The last line of Raster.createWritableRaster() method already has >>>>> a way to handle generic case if the input does not match any of >>>>> the cases in switch statements in that method. >>>>> >>>>> The fact that " *InterleavedRaster() constructors throw exception >>>>> if DataBuffer passed to them does not match the expected type" was >>>>> ignored earlier. >>>>> >>>>> This fix adds a check of "DataBuffer type" before creating >>>>> respective >>>>> *InterleavedRaster() objects. >>>>> >>>>> It constructs the SunWritableRaster in case DataBuffer type does >>>>> not match any data specific DataBuffer classes (DataBufferByte, >>>>> DataBufferUShort, DataBufferInt) >>>>> >>>>> Request to review webrev containing this fix : >>>>> >>>>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.00/ >>>>> >>>>> Regards, >>>>> >>>>> Ajit >>>>> >>>> >>>> >>>> -- >>>> Best regards, Sergey. >>>> >>> >>> From alexander.v.stepanov at oracle.com Wed Mar 23 14:09:11 2016 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Wed, 23 Mar 2016 17:09:11 +0300 Subject: [OpenJDK 2D-Dev] RFR 8152183: [TEST] add test for TIFFField Message-ID: <56F2A387.8070506@oracle.com> Hello, Could you please review the following fix http://cr.openjdk.java.net/~avstepan/8152183/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8152183 Just a single test added. Thanks, Alexander From philip.race at oracle.com Wed Mar 23 15:37:20 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 23 Mar 2016 08:37:20 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8151590, , "ALL" radio button is not selected in printDialog when we call DefaultSelectionType.ALL in windows In-Reply-To: <56EA6C3C.9070802@oracle.com> References: <56E14DC0.6020505@oracle.com> <56E2B4B5.9010607@oracle.com> <56E9AADF.4040206@oracle.com> <56EA6C3C.9070802@oracle.com> Message-ID: <56F2B830.70901@oracle.com> Hi, There are three typos which you need to fix before you push No need for another webrev. 79 // seeting this dialog to native pritdialog 100 + " A print dialog wil lbe shown.\n " -phil. On 3/17/16, 1:35 AM, prasanta sadhukhan wrote: > Hi Phil, > > Please find the updated webrev: > http://cr.openjdk.java.net/~psadhukhan/8151590/webrev.02/ > > Regards > Prasanta > On 3/17/2016 12:20 AM, Philip Race wrote: >> As I mentioned off-line please remove the extraneous stuff >> from the test. And why is the (c) 2015 ? >> >> -phil. >> >> On 3/11/16, 4:06 AM, prasanta sadhukhan wrote: >>> >>> Please find modified webrev with updated testcase. >>> http://cr.openjdk.java.net/~psadhukhan/8151590/webrev.01/ >>> >>> Regards >>> Prasanta >>> On 3/10/2016 4:04 PM, prasanta sadhukhan wrote: >>>> Hi Phil, >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151590 >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8151590/webrev.00/ >>>> >>>> The issue is if application calls >>>> JobAttributes.setDefaultSelection(JobAttributes.DefaultSelectionType.ALL); >>>> >>>> along with >>>> JobAttributes.setFromPage(2); >>>> JobAttributes.setToPage(5); >>>> >>>> then "Page" radio button is selected in windows. In linux and mac, >>>> "All" radio button is selected. >>>> Although the spec is not very clear as to what should get >>>> preference, it seems logically DefaultSelection should hold >>>> preference. >>>> >>>> This is a regression from 8061267 where PD_PAGENUMS was added to >>>> the flags resulting in "Page" radio button getting selected. >>>> I added a fix to add PD_PAGENUMS to the flags only if the selection >>>> attribute is not "PD_ALLPAGES" [which gets selected when >>>> JobAttributes.setDefaultSelection(JobAttributes.DefaultSelectionType.ALL); >>>> is called] >>>> >>>> I tested 8061267 testcase behaviour is same with this fix. >>>> >>>> Regards >>>> Prasanta >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Mar 23 16:56:44 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 23 Mar 2016 09:56:44 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-6185114: Undefined Exception in SampleModel, method createCompatibleSampleModel In-Reply-To: <84527e90-602d-4c04-94a8-69eda977ff7e@default> References: <06287367-8efc-4f33-b16a-b7f898b53259@default> <56E93B85.2060208@oracle.com> <84527e90-602d-4c04-94a8-69eda977ff7e@default> Message-ID: <56F2CACC.1010208@oracle.com> +1 -phil. On 3/16/16, 4:45 AM, Ajit Ghaisas wrote: > > Hi, > > I have corrected the typo and modified the failure message string. > > Please review the updated webrev. > > http://cr.openjdk.java.net/~arapte/ajit/6185114/webrev.01/ > > > Regards, > > Ajit > > *From:*prasanta sadhukhan > *Sent:* Wednesday, March 16, 2016 4:25 PM > *To:* Ajit Ghaisas; 2d-dev; Philip Race > *Subject:* Re: Review Request for JDK-6185114: Undefined Exception in > SampleModel, method createCompatibleSampleModel > > Fix Looks ok. Test failure message does not say what it is failing > for. Maybe you can mention "Expected IAE count <>, got IAE count <>" . > lune 52 has a typo heiht > > Regards > Prasanta > > On 3/16/2016 3:57 PM, Ajit Ghaisas wrote: > > Hi, > > Bug : https://bugs.openjdk.java.net/browse/JDK-6185114 > > Issue : Undefined Exception in SampleModel, method > createCompatibleSampleModel > > Root Cause : > > The SampleModel constructor documentation says -- it throws the > IllegalArgumentException if the product of width and height > parameters is greater than Integer.MAX_VALUE. > > The condition for this check is incorrectly checks for "greater > than equal to" where it should be only "greater than". > > Fix : > > Corrected the erroneous condition in below webrev and added a test. > > http://cr.openjdk.java.net/~arapte/ajit/6185114/webrev.00/ > > > Regards, > > Ajit > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bourges.laurent at gmail.com Wed Mar 23 20:41:44 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 23 Mar 2016 21:41:44 +0100 Subject: [OpenJDK 2D-Dev] RFR 8144938: Handle properly coordinate overflow in Marlin Renderer In-Reply-To: <56F1A244.9000408@oracle.com> References: <56E2159E.8000209@oracle.com> <56E22734.7020707@oracle.com> <56E33249.2030300@oracle.com> <56E74A98.30503@oracle.com> <56E89082.5040703@oracle.com> <56E9FF2C.4020308@oracle.com> <56EB4F86.7000002@oracle.com> <56EC8573.3090307@oracle.com> <56F1A244.9000408@oracle.com> Message-ID: Phil & Jim, Thanks for the reviews ! I just pushed this patch after a complete synch (jigsaw): build & tested with MapBench. Laurent 2016-03-22 20:51 GMT+01:00 Phil Race : > +1 .. looks like a nice simplification. > > Sorry it took me a couple of days to get back to this. > > -phil. > > > On 03/18/2016 03:47 PM, Jim Graham wrote: > >> The edit looks fine to me... Phil? >> >> ...jim >> >> On 3/18/16 9:52 AM, Laurent Bourg?s wrote: >> >>> Jim, >>> >>> Here is a final webrev (for archive): >>> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144938.5/ >>> >>> Changes: >>> - remove loops in CrashNaNTest >>> >>> Hope it is ready to go ! >>> >>> I need another reviewer, please. >>> >>> >>> 2016-03-18 1:44 GMT+01:00 Jim Graham >> >: >>> >>> Hi Laurent, >>> >>> That looks fine. If the subPathStarted changes are the only changes >>> then it's good to go. If there was some other change that I missed, >>> let me know so I can review it as well. >>> >>> >>> No this webrev had only changes in MRE.pathToLoop() you reviewed. >>> >>> >>> One curiosity - in the test case, why are there 3 for loops that >>> perform exactly one pass? (lines 134, 221, 282) I'm guessing that >>> maybe in a former life this code may have been part of a performance >>> suite or something? It's not a bug, just an odd bit of code. You >>> can delete them if you want, but I don't need to see a review of >>> that... >>> >>> >>> Fixed, now. >>> >>> Cheers, >>> Laurent >>> >> > -- -- Laurent Bourg?s -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Mar 23 22:28:21 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 23 Mar 2016 15:28:21 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-7107620, , Need to round in test java/awt/print/PageFormat/PageFormatFromAttributes.java In-Reply-To: <56F24508.2060703@oracle.com> References: <56F24508.2060703@oracle.com> Message-ID: <56F31885.2040300@oracle.com> +1. I think one reviewer will suffice for this test fix. -phil. On 3/23/16, 12:26 AM, prasanta sadhukhan wrote: > Hi Phil, > > Please review a simple fix for jdk9. > Bug: https://bugs.openjdk.java.net/browse/JDK-7107620 > webrev: http://cr.openjdk.java.net/~psadhukhan/7107620/webrev.00/ > > It was seen width/height obtained by calculating via MediaSize/units > is not same as obtained from Paper.getWIdth/getHeight(). > It seems the testcase is storing the result of the calculations in > "int" varible whereas MediaSize.getX()/getY() is "float" and units is > "double" variable thereby resulting is loss of precision. > > It was only seen in osx as osx returns a integer value for > getWidth()/getHeight() ie 842 instead of ~841.889 maybe because it > rounds off to nearest whereas MediaSize/units value is stored as 841 > when typecasted to int > resulting in failure. > Modified testcase to store in "double" to avoid loss of precision and > use Math.round() to round off to nearest value before comparing these > 2 values (from MediaSize/units and getWidth/getHeight). > > Tested in windows, linux, mac to be working. > > Regards > Prasanta From philip.race at oracle.com Wed Mar 23 23:09:03 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 23 Mar 2016 16:09:03 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8061258, , [macosx] PrinterJob's native Print Dialog does not reflect specified Copies or Page Ranges In-Reply-To: <56F277CB.40207@oracle.com> References: <56F277CB.40207@oracle.com> Message-ID: <56F3220F.1020304@oracle.com> On 3/23/16, 4:02 AM, prasanta sadhukhan wrote: > Hi Phil, > > Please review a fix for jdk9 > Bug: https://bugs.openjdk.java.net/browse/JDK-8061258 Gosh, it appears I submitted that bug 18 months ago although I don't remember how I came across the problem. I need to understand the fix better and it doesn't help that I don't understand this line :- } else if (selectID == 3) { SelectID is set from a single flag bit .. so it will never be 3, at least not anywhere I can find. What case is that supposed to be covering ? -phil. > webrev :http://cr.openjdk.java.net/~psadhukhan/8061258/webrev.00/ > > When user attempts to pre-populate the native dialog with copies and > page ranges by calling > PrintRequestAttributeSet aset = new HashPrintRequestAttributeSet(); > aset.add(new Copies(2)); > aset.add(new PageRanges(3,4)); > the print dialog does not reflect the user-defined setting. > > This is because osx native code was calling getNumberOfPages() from > OpenBook.java which was returning UNKNOWN_NUMBER_OF_PAGES (-1). > Since getNumberOfPages() returned -1, osx always selected > NSPrintAllPages or All Radio button. > > I fixed it by removing this call to getNumberOfPages() and rely on > getMinPage/getMaxPage() as was done in windows > (awt_PrintControl.cpp:AwtPrintControl::InitPrintDialog) to select > which radio button to be selected. > If fromPage > minPage or toPage < maxPage, it means user has selected > page ranges so PageRange radio button is to be selected else "All" > radio button to be selected. > > Regards > Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven.loomis at oracle.com Wed Mar 23 23:37:45 2016 From: steven.loomis at oracle.com (Steven Loomis) Date: Wed, 23 Mar 2016 16:37:45 -0700 Subject: [OpenJDK 2D-Dev] CFV: New 2D Group Member: Alexander Scherbatiy In-Reply-To: <56EB3465.7070709@oracle.com> References: <56EB3465.7070709@oracle.com> Message-ID: <56F328C9.7040703@oracle.com> Vote: yes On 3/17/2016 3:49 PM, Philip Race wrote: > I hereby nominate Alexander Scherbatiy to membership in the 2D group. > > Alexander Scherbatiy is a current member of the Swing group > and has contributed almost 200 changesets to OpenJDK :- > http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000&rev=author%28%22alexsch%22%29 > > Increasingly, and particularly over the last 18 months he has made many > of these significant contributions in the 2D area notably hi-dpi > graphics support and so I hereby nominate Alexander to membership of > the 2D group > > Votes are due by 1st April 2016 > > //Only current Members of the 2D Group [1] are eligible to vote on > this nomination. > For Lazy Consensus voting instructions, see [2]. > > [1] http://openjdk.java.net/census#2d > > [2] http://openjdk.java.net/groups/#member-vote > > > -phil -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Mar 23 23:39:58 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 23 Mar 2016 16:39:58 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream In-Reply-To: <481ff313-103f-4a71-bec9-44a3fa0a70ef@default> References: <99cb1549-30b5-44af-b399-ebed22255cf8@default> <56E997F1.2070605@oracle.com> <56E9C39D.6090701@oracle.com> <56E9D1D5.8090500@oracle.com> <56EAB79C.1080503@oracle.com> <88e50a67-fdd2-4b97-aa19-3ac5d419e2cf@default> <56EAFD38.80604@oracle.com> <56F0A94C.8080703@oracle.com> <56F17140.2070208@oracle.com> <481ff313-103f-4a71-bec9-44a3fa0a70ef@default> Message-ID: <56F3294E.1040306@oracle.com> I don't think this is ready and we need to discuss whether to rework it. In general I think I prefer IIO rather than null when we have a stream problem. For one thing you have this change :- 1522 * @returnfalse if no appropriate writer is found or 1523 * not able to create required ImageOutputStream. yet the implementation says :- 1545 try { 1546 output.delete(); 1547 stream = createImageOutputStream(output); 1548 } catch (IOException e) { 1549 throw new IIOException("Can't create output stream!", e); 1550 } So whilst "null" would mean we cannot find an IOS SPI it isn't the only reason we fail to create the IOS A null return seems to get passed through to doWrite() which probably throws IIOE And I think that the implementation is actually right here where it throws an exception. The ability to create an image input or output stream could be because of some kind of problem opening the file, or with the IIS or IOS implementations - like they were de-registered. I think in many if not all of these cases IOE - or IIOE is what we want. Also since we call createImageInputStream() - which is public - we need to look at that, and what it does, which is also something to consider. If it returns null, that seems to mean that no suitable SPI is registered which can only happen if they are de-registered. For the methods where we use createImageInputStream() I think it is fair to turn that into IIOE BTW I note that the code there says :- 350 351 boolean usecache = getUseCache()&& hasCachePermission(); 352 353 while (iter.hasNext()) { 354 ImageInputStreamSpi spi = iter.next(); 355 if (spi.getInputClass().isInstance(input)) { 356 try { 357 return spi.createInputStreamInstance(input, 358 usecache, 359 getCacheDirectory()); 360 } catch (IOException e) { 361 throw new IIOException("Can't create cache file!", e); 362 } 363 } 364 } So far I can see that means it will claim any Exception that is generated is because it could not create the cache file without any proof of that and even if "useCache" is false. It seems to imply to me that the author was not considering things like someone passing a closed InputStream .. probably we ought to be more vague in this case or look more deeply at what we can tell from whether it is IIOE or IOE. -phil. On 3/22/16, 10:49 AM, Jayathirth D V wrote: > Thanks for the review Sergey. > Can I get +1 for this please? > > -Jay > > -----Original Message----- > From: Sergey Bylokhov > Sent: Tuesday, March 22, 2016 9:52 PM > To: Jayathirth D V; Philip Race > Cc: 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream > > This fix looks fine to me. > At least it made all code work in a similar way. But probably someone will have other opinion? > > On 22.03.16 12:34, Jayathirth D V wrote: >> Hi Sergey, >> >> I have unified changes related to ImageIO.read() and ImageIO.write(). >> >> In case of read() we will be returning null when createImageInputStream() returns null. >> In case of write() we will be returning false when createImageOutputStream() returns null. >> >> Please find updated webrev for review: >> http://cr.openjdk.java.net/~jdv/8044289/webrev.03/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Tuesday, March 22, 2016 7:39 AM >> To: Jayathirth D V; Philip Race >> Cc: 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >> ImageIO.read() and write() NPE is not handled properly for stream >> >> Hi, Jay. >> Since we decided to update the specification we get an additional flexibility in the fix, because we can update the "@exception IOException" part of javadoc and describe that it can be thrown if ImageXXXStream cannot be created. >> >> I don't see a big differences of both approaches in case of write() methods, but in case of read(which has the similar issue but was skipped in the fix) there is a difference. >> Note that the read(File) unlike other methods throws the unspecified >> IIOException exception if ImageXXXStream cannot be created. We can >> think about unification of read/write methods in ImageIO. Hmm but even >> then >> read() in some cases will return null and in some cases throw an exception.... >> and createImageInputStream/createImageOutputStream() will look alien as they always return null not an exception. >> >> Another possible unification is to update javadoc for all methods, >> that they will return null if related providers are not found(in this >> case "throw new IIOException("Can't create an ImageInputStream!"))" >> should be removed from read(File); >> >> On 21.03.16 10:26, Jayathirth D V wrote: >>> Hi Sergey, >>> >>> For the second approach I have created webrev for review. >>> >>> Please review updated webrev : >>> http://cr.openjdk.java.net/~jdv/8044289/webrev.02/ >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Jayathirth D V >>> Sent: Friday, March 18, 2016 2:23 PM >>> To: Sergey Bylokhov >>> Cc: 2d-dev at openjdk.java.net; Philip Race >>> Subject: RE: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >>> ImageIO.read() and write() NPE is not handled properly for stream >>> >>> Hi Sergey, >>> >>> Thanks for your inputs. >>> >>> Indeed all the null values returned by createImageInputStream() and createImageInputStream() are valid only. >>> >>> I went through the code more and found that there is no need for fix in ImageIO.read() methods as null stream is handled in read(ImageInputStream stream) which is called by all the remaining read() API's through IAE. So i can remove the changes made in ImageIO.read() functions. Also istream is closed in finally block of read(url). >>> >>> For ImageIO.write(File)& ImageIO.write(OutputStream) NPE we have two approaches for fix: >>> >>> 1) Keep the present changes of throwing IOException when stream is null and change the throw clause of write() spec mentioning: >>> "IOException - if an error occurs during writing or not able to create required ImageOutputStream" >>> >>> 2) Remove the present changes and handle null in doWrite() method by returning false when stream is null& add code in finally block to close the stream only when stream is not null. Along with this we can also change Returns clause of spec to mention that write() might return false when we are not able to create ImageOutputStream. >>> >>> private static boolean doWrite(RenderedImage im, ImageWriter writer, >>> ImageOutputStream output) throws IOException { >>> if (writer == null) { >>> return false; >>> } >>> + if (output == null) { >>> + return false; >>> + } >>> >>> try { >>> return doWrite(im, writer, stream); >>> } finally { >>> + if (stream != null) >>> stream.close(); >>> } >>> >>> Returns : >>> false if no appropriate writer is found or not able to create required ImageOutputStream. >>> >>> Please let me know your inputs. >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Sergey Bylokhov >>> Sent: Friday, March 18, 2016 12:24 AM >>> To: Jayathirth D V >>> Cc: 2d-dev at openjdk.java.net; Philip Race >>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >>> ImageIO.read() and write() NPE is not handled properly for stream >>> >>> On 17.03.16 21:14, Jayathirth D V wrote: >>>> There are many places in createImageInputStream() and createImageOutputStream() where it will return null for stream. >>> But when why you change the write/read methods? They should take null into account and work according to specification. If some bogus null returns from createImageInputStream/createImageOutputStream then it should be fixed in these methods. >>>> So for NPE described in bug to occur there can be multiple paths: >>>> 1) One of the path described in bug is when theRegistry.getServiceProviders() throws IAE and we return null. >>> This is the case when we have no installed spi and should return null/false. >>> >>>> 2) When we pass non-existent file path to ImageIO (as described in http://stackoverflow.com/questions/11153200/with-imageio-write-api-call-i-get-nullpointerexception ). Here we catch FileNotFoundException but still we return stream as null at the end which will cause NPE further. >>> This is same thing described in the bug(about stream.close()). The write method call createImageOutputStream() and got FileNotFoundException. >>> This exception should be propagated to the user, but it is replaced in the finally block, because we try to close the stream=null. So the fix for this particular case is to check the stream to null in finally, No? >>> >>>> 3) When we don't support the provider and theRegistry.getServiceProviders() return iterator with size zero. >>> This means that our providers do not support this case, and we should return null/false. >>> >>>> For us to follow first scenario we need access to categoryMap of IIORegistry and delete the ImageInputStreamSpi/ ImageOutputStreamSpi but I was not able to find a way to tamper it from test case. If we follow second case FileNotFoundException will be thrown by default eventhough we handle NPE. >>> But you change the code and we now contradicts the specification, in your case the test should expect false/null from write()/read(). >>> >>>> In the test case we are trying to following third scenario to get stream as null to verify the code changes. >>> To catch the bogus null we should try to use another approach, or change the spec. But it seems all null values above are correct, we should be ready for them. >>> >>>> As part of collective fix we are throwing IOException which will indicate that we are not able to create required stream. >>>> >>>> Thanks, >>>> Jay >>>> >>>> -----Original Message----- >>>> From: Sergey Bylokhov >>>> Sent: Thursday, March 17, 2016 7:27 PM >>>> To: Phil Race >>>> Cc: Jayathirth D V; 2d-dev at openjdk.java.net >>>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >>>> ImageIO.read() and write() NPE is not handled properly for stream >>>> >>>> On 17.03.16 0:36, Phil Race wrote: >>>>> I don't think that is the actual reason here >>>> But the test doing exactly this thing -> deregister all spi => in >>>> this case according to specification all related >>>> methods(read/write/creatImageInputStream/creatImageOutputStream) should return null or false. >>>> >>>> - it seems likely that there >>>>> was some kind of internal error or bad SPI causing this. >>>>> So throwing an exception seems more appropriate. >>>> the problem was in some of our methods which do not expect null in some places(like stream.close() from the bug description). >>>> >>>>> And also the bug was originally solely about write(..). >>>>> >>>>> -phil. >>>>> >>>>> >>>>> On 03/16/2016 01:35 PM, Sergey Bylokhov wrote: >>>>>> As far as I understand the createImageInputStream() returns null >>>>>> is this stream is unsupported by current plugins via spi. Probably >>>>>> the >>>>>> read() method should return null too? >>>>>> >>>>>> /** >>>>>> * Returns a {@code BufferedImage} as the result of decoding >>>>>> * a supplied {@code InputStream} with an {@code ImageReader} >>>>>> * chosen automatically from among those currently registered. >>>>>> * The {@code InputStream} is wrapped in an >>>>>> * {@code ImageInputStream}. If no registered >>>>>> * {@code ImageReader} claims to be able to read the >>>>>> * resulting stream, {@code null} is returned. >>>>>> * >>>>>> ....... >>>>>> * @return a {@code BufferedImage} containing the decoded >>>>>> * contents of the input, or {@code null}. >>>>>> */ >>>>>> public static BufferedImage read(InputStream input) throws >>>>>> IOException >>>>>> >>>>>> >>>>>> On 16.03.16 20:29, Philip Race wrote: >>>>>>> The test writes out into "test.src". >>>>>>> I believe that you should treat that as a "read-only" location. >>>>>>> Write to a tempfile (File.createTempFile()) or TESTCLASSES. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 3/15/16, 10:50 PM, Jayathirth D V wrote: >>>>>>>> Hi Phil,All >>>>>>>> >>>>>>>> _Please review the following fix in JDK9:_ >>>>>>>> >>>>>>>> __ >>>>>>>> >>>>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8044289 >>>>>>>> >>>>>>>> Webrev : http://cr.openjdk.java.net/~jdv/8044289/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> Issue : When createImageInputStream() or createImageOutputStream >>>>>>>> returns null in ImageIO.read() or ImageIO.write() we are seeing >>>>>>>> NPE as it stream is used further without null check. >>>>>>>> >>>>>>>> Root cause : "stream" is used without checking whether it is >>>>>>>> null or not. >>>>>>>> >>>>>>>> Solution : Handle null pointer of stream and throw IIOException. >>>>>>>> >>>>>>>> Test case contains all possible scenarios where >>>>>>>> createImageInputStream() or createImageOutputStream can return null. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Jay >>>>>>>> >>>>>> >>>> >>>> -- >>>> Best regards, Sergey. >>>> >>> >>> -- >>> Best regards, Sergey. >>> >> >> -- >> Best regards, Sergey. >> > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Thu Mar 24 00:14:56 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 23 Mar 2016 17:14:56 -0700 Subject: [OpenJDK 2D-Dev] [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception In-Reply-To: <56F1D0DB.9000508@oracle.com> References: <3969befd-57cd-48ee-bed5-173a28e7bd08@default> <56DFFC9F.4020403@oracle.com> <70f247c0-6f3e-472a-b7b0-b02814010e30@default> <56E16D0A.3060807@oracle.com> <56E1E2A5.1020008@oracle.com> <56F1C6F2.6000305@oracle.com> <56F1D0DB.9000508@oracle.com> Message-ID: <56F33180.8060408@oracle.com> For the record, in many places in the 2D code we also adopt a slight extension of the indentation rules such that the below might be written as: public ByteBandedRaster(SampleModel sampleModel, DataBufferByte dataBuffer, Point origin) { // body lines of the method... } with the open curly brace on the following line so that it more visually points out the beginning of the body block of the method and it's easy to find the start/end of the block by sighting down the left margin. The official policy is for the "{" to be at the end of the previous line after "Point origin) {" and as more new engineers work on the code and follow the official rules, the above form becomes less common. (Sad face since I particularly like the above form...) ...jim On 3/22/16 4:10 PM, Phil Race wrote: > Ajit, > > There is also some odd indentation in ByteBandedRaster.java which is not > yours but > > 98 public ByteBandedRaster(SampleModel sampleModel, > 99 DataBufferByte dataBuffer, > 100 Point origin) { > > > This appears to be the result of someone using tabs a long time ago. > > Since you are touching the method signature lines anyway may be > better fixed so we have these aligned > > public ByteBandedRaster(SampleModel sampleModel, > DataBufferByte dataBuffer, > Point origin) { > > [not sure if that will make it through mail as intended]. > > Here in Raster.java, the first condition now seems to be redundant .. > 890 if (dataType == DataBuffer.TYPE_BYTE && > 891 dataBuffer instanceof DataBufferByte && > > > > -phil. > > > On 03/22/2016 03:28 PM, Jim Graham wrote: >> Hi Ajit, >> >> Most of your if statements are spaced wrong. There should be a space >> between "if" and the parentheses. I'll review more later, but I >> noticed that issue in the first couple of files I looked at... >> >> ...jim >> >> On 3/15/16 7:05 AM, Ajit Ghaisas wrote: >>> Hi, >>> >>> Thanks Sergey and Jim for suggestions. >>> >>> I have made the data specific Raster constructors type safe >>> now. Also, I have modified all Raster creations in Raster.java to >>> support custom DataBuffer classes. >>> >>> Please review the changes present in updated webrev : >>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.02/ >>> >>> Regards, >>> Ajit >>> >>> -----Original Message----- >>> From: Jim Graham >>> Sent: Friday, March 11, 2016 2:40 AM >>> To: Sergey Bylokhov; Ajit Ghaisas; 2d-dev >>> Subject: Re: [OpenJDK 2D-Dev] [9] Review-request for 6353518: >>> Creation of a WritableRaster with a custom DataBuffer causes >>> erroneous Exception >>> >>> Yes, those constructors should be type-safe. Perhaps that was done >>> to save code in the caller, but that is a small price to pay to avoid >>> errors in the future, and it makes sure there is a backup plan for >>> different kinds of buffers... >>> >>> ...jim >>> >>> On 3/10/16 4:48 AM, Sergey Bylokhov wrote: >>>> Hi, Ajit. >>>> What about other cases in Raster.java, where the DataBuffer is passed >>>> as a parameter? Probably we can simplify the code and find all such >>>> issues if we changes the ByteInterleavedRaster/etc. For example: >>>> >>>> ByteInterleavedRaster(SampleModel sampleModel,DataBuffer >>>> dataBuffer,...) to >>>> >>>> ByteInterleavedRaster(SampleModel sampleModel,DataBufferByte >>>> dataBuffer,...) >>>> >>>> Because we throw an exception in such cases anyway: >>>> >>>> if (!(dataBuffer instanceof DataBufferByte)) { >>>> throw new RasterFormatException("ByteInterleavedRasters must >>>> have " >>>> + "byte DataBuffers"); >>>> } >>>> >>>> And the compiler will help us, what everybody think about it? >>>> >>>> On 09.03.16 17:38, Ajit Ghaisas wrote: >>>>> Hi, >>>>> >>>>> Modified the test and added check for MultiPixelPackedSampleModel >>>>> condition. >>>>> >>>>> Please review updated webrev : >>>>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.01/ >>>>> >>>>> Regards, >>>>> Ajit >>>>> >>>>> -----Original Message----- >>>>> From: Sergey Bylokhov >>>>> Sent: Wednesday, March 09, 2016 4:06 PM >>>>> To: Ajit Ghaisas; awt-dev at openjdk.java.net; Semyon Sadetsky; Ambarish >>>>> Rapte; 2d-dev >>>>> Subject: Re: [9] Review-request for 6353518: Creation of a >>>>> WritableRaster with a custom DataBuffer causes erroneous Exception >>>>> >>>>> Changes for 2d area.(cc) >>>>> >>>>> >>>>> On 07.03.16 11:20, Ajit Ghaisas wrote: >>>>>> Hi, >>>>>> >>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-6353518 >>>>>> >>>>>> Issue : (Text from bug description) >>>>>> >>>>>> An attempt to create a WritableRaster via >>>>>> Raster.createWritableRaster(SampleModel sm, DataBuffer db, Point >>>>>> location) using a custom DataBuffer causes an erroneous >>>>>> RasterFormatException. >>>>>> Apparently the reason for this bug is that IntegerComponentRaster >>>>>> insists on being passed an instance of DataBufferInt rather than >>>>>> just a DataBuffer with a DataType of TYPE_INT. >>>>>> This is quite annoying since DataBufferInt is declared final and >>>>>> thus cannot be extended. >>>>>> >>>>>> Fix : >>>>>> >>>>>> The last line of Raster.createWritableRaster() method already has a >>>>>> way to handle generic case if the input does not match any of the >>>>>> cases in switch statements in that method. >>>>>> >>>>>> The fact that " *InterleavedRaster() constructors throw exception >>>>>> if DataBuffer passed to them does not match the expected type" was >>>>>> ignored earlier. >>>>>> >>>>>> This fix adds a check of "DataBuffer type" before creating >>>>>> respective >>>>>> *InterleavedRaster() objects. >>>>>> >>>>>> It constructs the SunWritableRaster in case DataBuffer type does not >>>>>> match any data specific DataBuffer classes (DataBufferByte, >>>>>> DataBufferUShort, DataBufferInt) >>>>>> >>>>>> Request to review webrev containing this fix : >>>>>> >>>>>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.00/ >>>>>> >>>>>> Regards, >>>>>> >>>>>> Ajit >>>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >>>>> >>>> >>>> > From james.graham at oracle.com Thu Mar 24 00:19:30 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 23 Mar 2016 17:19:30 -0700 Subject: [OpenJDK 2D-Dev] [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception In-Reply-To: <05f9f1e8-6f29-4863-a95e-060eaa09c5b4@default> References: <3969befd-57cd-48ee-bed5-173a28e7bd08@default> <56DFFC9F.4020403@oracle.com> <70f247c0-6f3e-472a-b7b0-b02814010e30@default> <56E16D0A.3060807@oracle.com> <56E1E2A5.1020008@oracle.com> <56F1C6F2.6000305@oracle.com> <56F1D0DB.9000508@oracle.com> <05f9f1e8-6f29-4863-a95e-060eaa09c5b4@default> Message-ID: <56F33292.4070307@oracle.com> Whoops, I didn't see this before... Casts should be followed by a space as in: (Foo) bar // correct (Foo)bar // incorrect ...jim On 3/23/16 5:41 AM, Ajit Ghaisas wrote: > Thanks Jim and Phil. > Yes. It was a mistake to omit spaces in 'if' conditions. I have corrected the spacing issues for my changes now. > > I have corrected the indentation of the lines similar to those mentioned by Phil. > I have also removed the redundant first condition check on line 890 in Raster.java mentioned as a review comment. > > Please review updated webrev : > http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.03/ > > Regards, > Ajit > > -----Original Message----- > From: Phil Race > Sent: Wednesday, March 23, 2016 4:40 AM > To: Jim Graham > Cc: Ajit Ghaisas; Sergey Bylokhov; 2d-dev > Subject: Re: [OpenJDK 2D-Dev] [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception > > Ajit, > > There is also some odd indentation in ByteBandedRaster.java which is not yours but > > 98 public ByteBandedRaster(SampleModel sampleModel, > 99 DataBufferByte dataBuffer, > 100 Point origin) { > > > This appears to be the result of someone using tabs a long time ago. > > Since you are touching the method signature lines anyway may be better fixed so we have these aligned > > public ByteBandedRaster(SampleModel sampleModel, > DataBufferByte dataBuffer, > Point origin) { > > [not sure if that will make it through mail as intended]. > > Here in Raster.java, the first condition now seems to be redundant .. > 890 if (dataType == DataBuffer.TYPE_BYTE && > 891 dataBuffer instanceof DataBufferByte && > > > > -phil. > > > On 03/22/2016 03:28 PM, Jim Graham wrote: >> Hi Ajit, >> >> Most of your if statements are spaced wrong. There should be a space >> between "if" and the parentheses. I'll review more later, but I >> noticed that issue in the first couple of files I looked at... >> >> ...jim >> >> On 3/15/16 7:05 AM, Ajit Ghaisas wrote: >>> Hi, >>> >>> Thanks Sergey and Jim for suggestions. >>> >>> I have made the data specific Raster constructors type safe now. >>> Also, I have modified all Raster creations in Raster.java to support >>> custom DataBuffer classes. >>> >>> Please review the changes present in updated webrev : >>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.02/ >>> >>> Regards, >>> Ajit >>> >>> -----Original Message----- >>> From: Jim Graham >>> Sent: Friday, March 11, 2016 2:40 AM >>> To: Sergey Bylokhov; Ajit Ghaisas; 2d-dev >>> Subject: Re: [OpenJDK 2D-Dev] [9] Review-request for 6353518: >>> Creation of a WritableRaster with a custom DataBuffer causes >>> erroneous Exception >>> >>> Yes, those constructors should be type-safe. Perhaps that was done >>> to save code in the caller, but that is a small price to pay to avoid >>> errors in the future, and it makes sure there is a backup plan for >>> different kinds of buffers... >>> >>> ...jim >>> >>> On 3/10/16 4:48 AM, Sergey Bylokhov wrote: >>>> Hi, Ajit. >>>> What about other cases in Raster.java, where the DataBuffer is >>>> passed as a parameter? Probably we can simplify the code and find >>>> all such issues if we changes the ByteInterleavedRaster/etc. For example: >>>> >>>> ByteInterleavedRaster(SampleModel sampleModel,DataBuffer >>>> dataBuffer,...) to >>>> >>>> ByteInterleavedRaster(SampleModel sampleModel,DataBufferByte >>>> dataBuffer,...) >>>> >>>> Because we throw an exception in such cases anyway: >>>> >>>> if (!(dataBuffer instanceof DataBufferByte)) { >>>> throw new RasterFormatException("ByteInterleavedRasters must >>>> have " >>>> + "byte DataBuffers"); >>>> } >>>> >>>> And the compiler will help us, what everybody think about it? >>>> >>>> On 09.03.16 17:38, Ajit Ghaisas wrote: >>>>> Hi, >>>>> >>>>> Modified the test and added check for >>>>> MultiPixelPackedSampleModel condition. >>>>> >>>>> Please review updated webrev : >>>>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.01/ >>>>> >>>>> Regards, >>>>> Ajit >>>>> >>>>> -----Original Message----- >>>>> From: Sergey Bylokhov >>>>> Sent: Wednesday, March 09, 2016 4:06 PM >>>>> To: Ajit Ghaisas; awt-dev at openjdk.java.net; Semyon Sadetsky; >>>>> Ambarish Rapte; 2d-dev >>>>> Subject: Re: [9] Review-request for 6353518: Creation of a >>>>> WritableRaster with a custom DataBuffer causes erroneous Exception >>>>> >>>>> Changes for 2d area.(cc) >>>>> >>>>> >>>>> On 07.03.16 11:20, Ajit Ghaisas wrote: >>>>>> Hi, >>>>>> >>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-6353518 >>>>>> >>>>>> Issue : (Text from bug description) >>>>>> >>>>>> An attempt to create a WritableRaster via >>>>>> Raster.createWritableRaster(SampleModel sm, DataBuffer db, Point >>>>>> location) using a custom DataBuffer causes an erroneous >>>>>> RasterFormatException. >>>>>> Apparently the reason for this bug is that IntegerComponentRaster >>>>>> insists on being passed an instance of DataBufferInt rather than >>>>>> just a DataBuffer with a DataType of TYPE_INT. >>>>>> This is quite annoying since DataBufferInt is declared final and >>>>>> thus cannot be extended. >>>>>> >>>>>> Fix : >>>>>> >>>>>> The last line of Raster.createWritableRaster() method already has >>>>>> a way to handle generic case if the input does not match any of >>>>>> the cases in switch statements in that method. >>>>>> >>>>>> The fact that " *InterleavedRaster() constructors throw exception >>>>>> if DataBuffer passed to them does not match the expected type" was >>>>>> ignored earlier. >>>>>> >>>>>> This fix adds a check of "DataBuffer type" before creating >>>>>> respective >>>>>> *InterleavedRaster() objects. >>>>>> >>>>>> It constructs the SunWritableRaster in case DataBuffer type does >>>>>> not match any data specific DataBuffer classes (DataBufferByte, >>>>>> DataBufferUShort, DataBufferInt) >>>>>> >>>>>> Request to review webrev containing this fix : >>>>>> >>>>>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.00/ >>>>>> >>>>>> Regards, >>>>>> >>>>>> Ajit >>>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >>>>> >>>> >>>> > From james.graham at oracle.com Thu Mar 24 00:29:07 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 23 Mar 2016 17:29:07 -0700 Subject: [OpenJDK 2D-Dev] [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception In-Reply-To: <56F33180.8060408@oracle.com> References: <3969befd-57cd-48ee-bed5-173a28e7bd08@default> <56DFFC9F.4020403@oracle.com> <70f247c0-6f3e-472a-b7b0-b02814010e30@default> <56E16D0A.3060807@oracle.com> <56E1E2A5.1020008@oracle.com> <56F1C6F2.6000305@oracle.com> <56F1D0DB.9000508@oracle.com> <56F33180.8060408@oracle.com> Message-ID: <56F334D3.5060106@oracle.com> I should point out that this form I demonstrate below is only used when there are continuation lines on the prefix to the code block (conditionals, method declarations, loop controls, etc.), so: if (some simple condition) { ... } and: if (some complex condition && some additional condition) { ... } but, not: if (some single line condition) { // blech ... } The reason for this is that the standard indentation would recommend: if (some complex condition && some additional condition) { // code block } or void foomethod(int sx, int sy, int dx, int dy) { // code block } which may be more compact, but the lack of a breaking line means you have to vary the indentation of the declarations/conditionals and as a result they don't line up nicely which makes them harder to scan if they are all related (and frequently in graphics code you end up with a series of very similar arguments or conditionals that are more readable if they line up nicely), and the only indication of when the multiple lines of continued declaration/conditionals end and the body of the method begins is the number of spaces - noting that frequently the indentation on lines in practice is just wrong so this form makes it hard to distinguish between "that line is a continuation line" and "someone indented that line wrong"... ...jim On 3/23/16 5:14 PM, Jim Graham wrote: > For the record, in many places in the 2D code we also adopt a slight > extension of the indentation rules such that the below might be written as: > > public ByteBandedRaster(SampleModel sampleModel, > DataBufferByte dataBuffer, > Point origin) > { > // body lines of the method... > } > > with the open curly brace on the following line so that it more visually > points out the beginning of the body block of the method and it's easy > to find the start/end of the block by sighting down the left margin. The > official policy is for the "{" to be at the end of the previous line > after "Point origin) {" and as more new engineers work on the code and > follow the official rules, the above form becomes less common. (Sad > face since I particularly like the above form...) > > ...jim > > On 3/22/16 4:10 PM, Phil Race wrote: >> Ajit, >> >> There is also some odd indentation in ByteBandedRaster.java which is not >> yours but >> >> 98 public ByteBandedRaster(SampleModel sampleModel, >> 99 DataBufferByte dataBuffer, >> 100 Point origin) { >> >> >> This appears to be the result of someone using tabs a long time ago. >> >> Since you are touching the method signature lines anyway may be >> better fixed so we have these aligned >> >> public ByteBandedRaster(SampleModel sampleModel, >> DataBufferByte dataBuffer, >> Point origin) { >> >> [not sure if that will make it through mail as intended]. >> >> Here in Raster.java, the first condition now seems to be redundant .. >> 890 if (dataType == DataBuffer.TYPE_BYTE && >> 891 dataBuffer instanceof DataBufferByte && >> >> >> >> -phil. >> >> >> On 03/22/2016 03:28 PM, Jim Graham wrote: >>> Hi Ajit, >>> >>> Most of your if statements are spaced wrong. There should be a space >>> between "if" and the parentheses. I'll review more later, but I >>> noticed that issue in the first couple of files I looked at... >>> >>> ...jim >>> >>> On 3/15/16 7:05 AM, Ajit Ghaisas wrote: >>>> Hi, >>>> >>>> Thanks Sergey and Jim for suggestions. >>>> >>>> I have made the data specific Raster constructors type safe >>>> now. Also, I have modified all Raster creations in Raster.java to >>>> support custom DataBuffer classes. >>>> >>>> Please review the changes present in updated webrev : >>>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.02/ >>>> >>>> Regards, >>>> Ajit >>>> >>>> -----Original Message----- >>>> From: Jim Graham >>>> Sent: Friday, March 11, 2016 2:40 AM >>>> To: Sergey Bylokhov; Ajit Ghaisas; 2d-dev >>>> Subject: Re: [OpenJDK 2D-Dev] [9] Review-request for 6353518: >>>> Creation of a WritableRaster with a custom DataBuffer causes >>>> erroneous Exception >>>> >>>> Yes, those constructors should be type-safe. Perhaps that was done >>>> to save code in the caller, but that is a small price to pay to avoid >>>> errors in the future, and it makes sure there is a backup plan for >>>> different kinds of buffers... >>>> >>>> ...jim >>>> >>>> On 3/10/16 4:48 AM, Sergey Bylokhov wrote: >>>>> Hi, Ajit. >>>>> What about other cases in Raster.java, where the DataBuffer is passed >>>>> as a parameter? Probably we can simplify the code and find all such >>>>> issues if we changes the ByteInterleavedRaster/etc. For example: >>>>> >>>>> ByteInterleavedRaster(SampleModel sampleModel,DataBuffer >>>>> dataBuffer,...) to >>>>> >>>>> ByteInterleavedRaster(SampleModel sampleModel,DataBufferByte >>>>> dataBuffer,...) >>>>> >>>>> Because we throw an exception in such cases anyway: >>>>> >>>>> if (!(dataBuffer instanceof DataBufferByte)) { >>>>> throw new RasterFormatException("ByteInterleavedRasters must >>>>> have " >>>>> + "byte DataBuffers"); >>>>> } >>>>> >>>>> And the compiler will help us, what everybody think about it? >>>>> >>>>> On 09.03.16 17:38, Ajit Ghaisas wrote: >>>>>> Hi, >>>>>> >>>>>> Modified the test and added check for >>>>>> MultiPixelPackedSampleModel >>>>>> condition. >>>>>> >>>>>> Please review updated webrev : >>>>>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.01/ >>>>>> >>>>>> Regards, >>>>>> Ajit >>>>>> >>>>>> -----Original Message----- >>>>>> From: Sergey Bylokhov >>>>>> Sent: Wednesday, March 09, 2016 4:06 PM >>>>>> To: Ajit Ghaisas; awt-dev at openjdk.java.net; Semyon Sadetsky; Ambarish >>>>>> Rapte; 2d-dev >>>>>> Subject: Re: [9] Review-request for 6353518: Creation of a >>>>>> WritableRaster with a custom DataBuffer causes erroneous Exception >>>>>> >>>>>> Changes for 2d area.(cc) >>>>>> >>>>>> >>>>>> On 07.03.16 11:20, Ajit Ghaisas wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-6353518 >>>>>>> >>>>>>> Issue : (Text from bug description) >>>>>>> >>>>>>> An attempt to create a WritableRaster via >>>>>>> Raster.createWritableRaster(SampleModel sm, DataBuffer db, Point >>>>>>> location) using a custom DataBuffer causes an erroneous >>>>>>> RasterFormatException. >>>>>>> Apparently the reason for this bug is that IntegerComponentRaster >>>>>>> insists on being passed an instance of DataBufferInt rather than >>>>>>> just a DataBuffer with a DataType of TYPE_INT. >>>>>>> This is quite annoying since DataBufferInt is declared final and >>>>>>> thus cannot be extended. >>>>>>> >>>>>>> Fix : >>>>>>> >>>>>>> The last line of Raster.createWritableRaster() method already has a >>>>>>> way to handle generic case if the input does not match any of the >>>>>>> cases in switch statements in that method. >>>>>>> >>>>>>> The fact that " *InterleavedRaster() constructors throw exception >>>>>>> if DataBuffer passed to them does not match the expected type" was >>>>>>> ignored earlier. >>>>>>> >>>>>>> This fix adds a check of "DataBuffer type" before creating >>>>>>> respective >>>>>>> *InterleavedRaster() objects. >>>>>>> >>>>>>> It constructs the SunWritableRaster in case DataBuffer type does not >>>>>>> match any data specific DataBuffer classes (DataBufferByte, >>>>>>> DataBufferUShort, DataBufferInt) >>>>>>> >>>>>>> Request to review webrev containing this fix : >>>>>>> >>>>>>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.00/ >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Ajit >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, Sergey. >>>>>> >>>>> >>>>> >> From james.graham at oracle.com Thu Mar 24 02:26:35 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 23 Mar 2016 19:26:35 -0700 Subject: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: Antialiased text on translucent backgrounds gets bright artifacts In-Reply-To: References: <63d69ba8-d5cf-4697-bb5c-f51aaaa8c427@default> <56EB4DBB.9080802@oracle.com> Message-ID: <56F3505B.2070101@oracle.com> Hi Prahalad, (On a side note - ouch! I came up with these macros in the first place, but 20 years later I'm now realizing just how hard they are to navigate and review. My apologies...) The macro you are still using to load the destination data is one that loads it to non-premultiplied components, which means it will divide out the alpha if the destination is PRE. The rest of the logic assumes that the components were loaded without any adjustment of their premultiplication so not only is that division an unnecessary operation, it makes the following math wrong. The SRCOVER_MASKFILL macro seems to use "Postload ## STRATEGY ## From ## TYPE" which seems to load them into separate components without any adjustment of their pre-multiplication status. This is paired with "LoadAlphaFrom ## TYPE ## For ## STRATEGY" to load just the destination alpha for computing dstF... ...jim On 3/22/16 4:35 AM, Prahalad Kumar Narayanan wrote: > Hello Everyone on Java2D Group > > Good day to you. > > This is a Follow-up to Review Request on the bug: > Bug : JDK-8015070 Anti-aliased Text on Translucent background gets bright artifacts > Bug Link : https://bugs.openjdk.java.net/browse/JDK-8015070 > > First, Sincere thanks to Jim for his valuable feedback. > 1. As Jim correctly mentioned, SRCOVER_MASKFILL has a similar logic to blend two Translucent colors based on an Alpha mask. > 2. The calculations are exactly the same as the changes in previous webrev. > However the logic of SRCOVER_MASKFILL is 'Optimized' to reduce the number of computations. > 3. This optimization is definitely required because, the logic is executed for every single pixel in a glyph. > Example: If a string is made up of 5 English characters with each character having 32 x 32 pixels, > The anti-aliasing logic will be executed for 5 x 32 x 32 iterations. > Reducing computation per pixel will imply a huge benefit for complete drawString operation. > > Observation from SRCOVER_MASKFILL > 1. The mask fill reduces computations by through multiple if(...) conditions. > Each if condition affirms whether the next set of computations are required. > 2. Optimization 1: If mask value is 0- skip entire logic. > 3. Optimization 2: If mask value is maximum, say 255, take srcA directly without multiplying with maskAlpha ( Reason: 1 * srcAlpha = srcAlpha ) > 4. Optimization 3: Compute pre-multiplied resColor in two steps. First with srcColor and then with dstColor. > If the resAlpha from 1st step (i.e., srcColor) is fully opaque, avoid blending dstColor altogether. > > Changes in Current Webrev.01 > 1. The fix for the current bug is modelled based on SRCOVER_MASKFILL. > 2. The changes have been verified to work on windows, linux and mac operating systems. > 3. The automated Test file- AADrawStringArtifact.java runs as expected > Identifies artifact & throws exception when run on JDK 7 and 8. > With JDK9, the test file returns without error. > 3. JPRT build has been run to ensure, changes build on all supported platforms. > JPRT job link : http://scaaa637.us.oracle.com//archive/2016/03/2016-03-22-070604.prahnara-linux.client > > Kindly review the changes in the below mentioned link and provide your views > Webrev Link : http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.01/ > > > Thank you for your time in review > Have a good day > > Prahalad N. > > > -----Original Message----- > From: Jim Graham > Sent: Friday, March 18, 2016 6:07 AM > To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: Antialiased text on translucent backgrounds gets bright artifacts > > Hi Prahalad, > > This basically boils down to "alpha blending math needs to be performed in premultiplied form" and the existing code was not doing that. > > Your changes do add a pre-multiplication step to the math in two places > - when you mix the src alpha and the glyph alpha at the top of the macro, and again when you do the Multiply(dst, dstA, dst) step in the middle. In that sense, the new math is correct. > > However, it is not the optimal way to implement this. In particular, the macro used here to load the data from the destination is the one that loads it into 4 ARGB non-premultiplied values. If the destination is non-PRE, then your added multiply step is exactly what is needed, but it could be combined with the multiply that will happen later in the blending equation, so it is an added step rather than a fixed fraction in the existing MultMultAdd parameters. Additionally, if the destination is already PRE, then the macro being used to load the dst pixel data there will have done a divide step to divide out the alpha from the destination, only to have you reverse that math with your new > Multiply() step. That's a lot of math to end up with a NOP. > > The MUL8 you added for the srcA and glyph value is needed, that change is good. Since it is common for glyph pixels to have zero alpha, you might want to test the glyph alpha for 0 and skip the pixel before you do the multiply, though. This would add one more if, but it would be a common case. > > The trickier part is to load the destination components without un-premultiplying them. Unfortunately there is no "Load...ToArgbPre" > macro to parallel the Load macro used in the function. Perhaps there should be, but you'd still end up with an extra multiply step as I mentioned above because you can fold the premultiplication of the dst data into the MultMultAdd by carefully choosing the parameters you use in the math there. > > The good news is that the way that the SRCOVER_MASKFILL uses the various type-specific macros works around this a bit and minimizes the number of multiplies that happen. You could check out DEFINE_SRCOVER_MASKFILL and see how it works in the case where pMask is not null (pMask is an alpha mask with values very similar to the glyphAA data). Modeling this code on that code would correct the math and minimize it as well... > > ...jim > > On 3/17/16 3:00 AM, Prahalad Kumar Narayanan wrote: >> Hello Everyone on Java2D Group >> >> Good day to you. >> >> Herewith, I 'm sharing the webrev for two identical Java2D Bugs. >> >> Bug ID : JDK-8015070 >> >> Title : Antialiased text on translucent backgrounds gets >> bright artifacts >> >> Link : https://bugs.openjdk.java.net/browse/JDK-8015070 >> >> Bug ID : JDK-8013564 ( currently closed as duplicate ) >> >> Title : Font rendering anti-aliasing in translucent >> BufferedImages broken >> >> Link : https://bugs.openjdk.java.net/browse/JDK-8013564 >> >> Webrev Link : >> http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.00/ >> >> Quick Summary on Bugs : >> >> ```````````````````````````````````````````````` >> >> 1. Artifacts appear on Edges of text characters when anti-aliased >> text is drawn on Translucent background >> >> 2. The issue is reproducible on all platforms - windows, linux and mac os. >> >> 3. Besides, the issue is reproduced with the commonly used pixel >> format- 4ByteArgb. >> >> Root Cause & Solution : >> >> ```````````````````````````````````````````````` >> >> 1. The Macro: GlyphListAABlend4ByteArgb in File: LoopMacros.h uses >> the standard blending algorithm >> >> dstColor = [ srcColor * glyphAlpha + dstColor * (1 - >> glyphAlpha) ] / dstAlpha >> >> 2. The above equation works only when the srcColor and dstColor are Opaque. >> >> 3. When srcColor and dstColor are Translucent, their alphaComponent >> will influence the visibility of the color, and visibility of the >> color below. >> >> 4. The new set of calculations for blending Translucent source and >> destination colors is given as >> >> resAlpha = 1 - ((1 - srcAlpha) * (1 - dstAlpha)) >> >> resColor = [ srcColor * srcAlpha + dstColor * dstAlpha * (1 - >> srcAlpha) ] / resAlpha >> >> 5. Reference text for the equation: >> https://en.wikipedia.org/wiki/Alpha_compositing >> >> 6. With the above modification to the blending logic, the artifacts >> do not appear and issues are fixed. >> >> Jtreg & Jprt Results : >> >> ```````````````````````````````````````````````` >> >> 1. A simple test-file: AADrawStringArtifact.java has been created to >> be a part of jtreg test cases. >> >> The test file is well commented to explain - nature of >> artifact and how the test tries to identify them. >> >> As required, the test case fails with Jdk 7, Jdk 8 and >> succeeds with Jdk 9-internal (built with changes for the bug fix) >> >> 2. The changes to blending logic lies within >> java.desktop/src/share/native/... >> >> Henceforth, JPRT was used to ensure successful build across >> all supported platforms >> >> Jprt Job Link : >> http://scaaa637.us.oracle.com//archive/2016/03/2016-03-17-072001.prahn >> ara-linux.client >> >> The build succeeds on all platforms. >> >> Kindly review the webrev link and provide your views and suggestions. >> >> Webrev Link : >> http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.00/ >> >> If the changes look good, we could take up the changes for source checkin. >> >> Thank you for your time in review >> >> Have a good day >> >> Prahalad N. >> From prasanta.sadhukhan at oracle.com Thu Mar 24 06:47:19 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Thu, 24 Mar 2016 12:17:19 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8061258, , [macosx] PrinterJob's native Print Dialog does not reflect specified Copies or Page Ranges In-Reply-To: <56F3220F.1020304@oracle.com> References: <56F277CB.40207@oracle.com> <56F3220F.1020304@oracle.com> Message-ID: <56F38D77.4060207@oracle.com> Hi Phil, On 3/24/2016 4:39 AM, Philip Race wrote: > > > On 3/23/16, 4:02 AM, prasanta sadhukhan wrote: >> Hi Phil, >> >> Please review a fix for jdk9 >> Bug: https://bugs.openjdk.java.net/browse/JDK-8061258 > > Gosh, it appears I submitted that bug 18 months ago although > I don't remember how I came across the problem. > > I need to understand the fix better and it doesn't help that I don't > understand this line :- > } else if (selectID == 3) { Yes, this is wrong. I was thinking selectID ==3 was for PD_SELECTION but it was not. Anyways, I have rectified this and updated the webrev: http://cr.openjdk.java.net/~psadhukhan/8061258/webrev.01/ where the else part handles both PD_SELECTION or PD_NOSELECTION I tested with JobAttributes.setDefaultSelection(ALL/RANGE/SELECTION) and also without defaultselection and all are working fine. Regards Prasanta > SelectID is set from a single flag bit .. so it will never be 3, at > least not anywhere I can find. What case is that supposed to be > covering ? -phil. > >> webrev :http://cr.openjdk.java.net/~psadhukhan/8061258/webrev.00/ >> >> When user attempts to pre-populate the native dialog with copies and >> page ranges by calling >> PrintRequestAttributeSet aset = new HashPrintRequestAttributeSet(); >> aset.add(new Copies(2)); >> aset.add(new PageRanges(3,4)); >> the print dialog does not reflect the user-defined setting. >> >> This is because osx native code was calling getNumberOfPages() from >> OpenBook.java which was returning UNKNOWN_NUMBER_OF_PAGES (-1). >> Since getNumberOfPages() returned -1, osx always selected >> NSPrintAllPages or All Radio button. >> >> I fixed it by removing this call to getNumberOfPages() and rely on >> getMinPage/getMaxPage() as was done in windows >> (awt_PrintControl.cpp:AwtPrintControl::InitPrintDialog) to select >> which radio button to be selected. >> If fromPage > minPage or toPage < maxPage, it means user has selected >> page ranges so PageRange radio button is to be selected else "All" >> radio button to be selected. >> >> Regards >> Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Thu Mar 24 08:00:30 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 24 Mar 2016 01:00:30 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8151590, , "ALL" radio button is not selected in printDialog when we call DefaultSelectionType.ALL in windows In-Reply-To: <56F2B830.70901@oracle.com> References: <56E14DC0.6020505@oracle.com> <56E2B4B5.9010607@oracle.com> <56E9AADF.4040206@oracle.com> <56EA6C3C.9070802@oracle.com> <56F2B830.70901@oracle.com> Message-ID: <0d5e6bcd-fa2b-43b5-b0aa-ab9bac982b6d@default> Hi Prasanta, ? Here we are giving priority to setDefaultSelection() over setXXXPage() and since we are following the same rule among all platforms changes are fine. Before and after change test is working fine. But test case needs little changes: ? 1)????? There are unused imports : Line 31????????????????? import java.awt.Component; Line 40????????????????? import javax.swing.JOptionPane; ? 2)????? There are places in test case where we have changes over 80 character length : Line 81????????????????? PrintJob pj = tk.getPrintJob(new JFrame(), "testing the attribute setting ", job, page); Line 102??????????????? + " If ALL radio button is selected, press PASS else press FAIL"; ? Apart from this test and code changes are fine. ? Thanks, Jay From: Philip Race Sent: Wednesday, March 23, 2016 9:07 PM To: prasanta sadhukhan Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9] RFR: JDK-8151590, , "ALL" radio button is not selected in printDialog when we call DefaultSelectionType.ALL in windows ? Hi, There are three typos which you need to fix before you push No need for another webrev. ? 79???????? // seeting this dialog to native pritdialog 100???????????????? + " A print dialog wil lbe shown.\n " -phil. On 3/17/16, 1:35 AM, prasanta sadhukhan wrote: Hi Phil, Please find the updated webrev: http://cr.openjdk.java.net/~psadhukhan/8151590/webrev.02/ Regards Prasanta On 3/17/2016 12:20 AM, Philip Race wrote: As I mentioned off-line please remove the extraneous stuff from the test. And why is the (c) 2015 ? -phil. On 3/11/16, 4:06 AM, prasanta sadhukhan wrote: Please find modified webrev with updated testcase. http://cr.openjdk.java.net/~psadhukhan/8151590/webrev.01/ Regards Prasanta On 3/10/2016 4:04 PM, prasanta sadhukhan wrote: Hi Phil, Bug: https://bugs.openjdk.java.net/browse/JDK-8151590 webrev: http://cr.openjdk.java.net/~psadhukhan/8151590/webrev.00/ The issue is if application calls JobAttributes.setDefaultSelection(JobAttributes.DefaultSelectionType.ALL); along with JobAttributes.setFromPage(2); ?JobAttributes.setToPage(5); then "Page" radio button is selected in windows. In linux and mac, "All" radio button is selected. Although the spec is not very clear as to what should get preference, it seems logically DefaultSelection should hold preference. This is a regression from 8061267 where PD_PAGENUMS was added to the flags resulting in "Page" radio button getting selected. I added a fix to add PD_PAGENUMS to the flags only if the selection attribute is not "PD_ALLPAGES" [which gets selected when JobAttributes.setDefaultSelection(JobAttributes.DefaultSelectionType.ALL); is called] I tested 8061267 testcase behaviour is same with this fix. Regards Prasanta ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Thu Mar 24 10:22:00 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 24 Mar 2016 03:22:00 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream In-Reply-To: <56F3294E.1040306@oracle.com> References: <99cb1549-30b5-44af-b399-ebed22255cf8@default> <56E997F1.2070605@oracle.com> <56E9C39D.6090701@oracle.com> <56E9D1D5.8090500@oracle.com> <56EAB79C.1080503@oracle.com> <88e50a67-fdd2-4b97-aa19-3ac5d419e2cf@default> <56EAFD38.80604@oracle.com> <56F0A94C.8080703@oracle.com> <56F17140.2070208@oracle.com> <481ff313-103f-4a71-bec9-44a3fa0a70ef@default> <56F3294E.1040306@oracle.com> Message-ID: Hi Phil, We can change the code to something like : 1522 * @return false if no appropriate writer is found or 1523 * when needed stream is null. 1545 try { 1546 output.delete(); 1547 stream = createImageOutputStream(output); 1548 } catch (IOException e) { 1549 throw e; 1550 } In this case we will be throwing IOException when we are not able to create cache file and stream is null. And return null/false when createImageXXXStream returns null. Also we can add check before throwing IIOException from createImageXXXStream for usecache. 350 351 boolean usecache = getUseCache() && hasCachePermission(); 352 353 while (iter.hasNext()) { 354 ImageInputStreamSpi spi = iter.next(); 355 if (spi.getInputClass().isInstance(input)) { 356 try { 357 return spi.createInputStreamInstance(input, 358 usecache, 359 getCacheDirectory()); 360 } catch (IOException e) { 361 if (usecache) 362 throw new IIOException("Can't create cache file!", e); 363 } 364 } 365 } This will be one of the approach. Or we can throw IOException in all the cases with additional check in createImageXXXStream for usecache. This will be like throwing IOException when createImageXXXStream returns null/false or it throws IIOException when it cant create cache file. This will be another approach. Please let us know your inputs. Thanks, Jay From: Philip Race Sent: Thursday, March 24, 2016 5:10 AM To: Jayathirth D V Cc: Sergey Bylokhov; 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream I don't think this is ready and we need to discuss whether to rework it. In general I think I prefer IIO rather than null when we have a stream problem. For one thing you have this change :- 1522 * @return false if no appropriate writer is found or 1523 * not able to create required ImageOutputStream. yet the implementation says :- 1545 try { 1546 output.delete(); 1547 stream = createImageOutputStream(output); 1548 } catch (IOException e) { 1549 throw new IIOException("Can't create output stream!", e); 1550 } So whilst "null" would mean we cannot find an IOS SPI it isn't the only reason we fail to create the IOS A null return seems to get passed through to doWrite() which probably throws IIOE And I think that the implementation is actually right here where it throws an exception. The ability to create an image input or output stream could be because of some kind of problem opening the file, or with the IIS or IOS implementations - like they were de-registered. I think in many if not all of these cases IOE - or IIOE is what we want. Also since we call createImageInputStream() - which is public - we need to look at that, and what it does, which is also something to consider. If it returns null, that seems to mean that no suitable SPI is registered which can only happen if they are de-registered. For the methods where we use createImageInputStream() I think it is fair to turn that into IIOE BTW I note that the code there says :- 350 351 boolean usecache = getUseCache() && hasCachePermission(); 352 353 while (iter.hasNext()) { 354 ImageInputStreamSpi spi = iter.next(); 355 if (spi.getInputClass().isInstance(input)) { 356 try { 357 return spi.createInputStreamInstance(input, 358 usecache, 359 getCacheDirectory()); 360 } catch (IOException e) { 361 throw new IIOException("Can't create cache file!", e); 362 } 363 } 364 } So far I can see that means it will claim any Exception that is generated is because it could not create the cache file without any proof of that and even if "useCache" is false. It seems to imply to me that the author was not considering things like someone passing a closed InputStream .. probably we ought to be more vague in this case or look more deeply at what we can tell from whether it is IIOE or IOE. -phil. On 3/22/16, 10:49 AM, Jayathirth D V wrote: Thanks for the review Sergey. Can I get +1 for this please? -Jay -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, March 22, 2016 9:52 PM To: Jayathirth D V; Philip Race Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream This fix looks fine to me. At least it made all code work in a similar way. But probably someone will have other opinion? On 22.03.16 12:34, Jayathirth D V wrote: Hi Sergey, I have unified changes related to ImageIO.read() and ImageIO.write(). In case of read() we will be returning null when createImageInputStream() returns null. In case of write() we will be returning false when createImageOutputStream() returns null. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/8044289/webrev.03/ Thanks, Jay -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, March 22, 2016 7:39 AM To: Jayathirth D V; Philip Race Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream Hi, Jay. Since we decided to update the specification we get an additional flexibility in the fix, because we can update the "@exception IOException" part of javadoc and describe that it can be thrown if ImageXXXStream cannot be created. I don't see a big differences of both approaches in case of write() methods, but in case of read(which has the similar issue but was skipped in the fix) there is a difference. Note that the read(File) unlike other methods throws the unspecified IIOException exception if ImageXXXStream cannot be created. We can think about unification of read/write methods in ImageIO. Hmm but even then read() in some cases will return null and in some cases throw an exception.... and createImageInputStream/createImageOutputStream() will look alien as they always return null not an exception. Another possible unification is to update javadoc for all methods, that they will return null if related providers are not found(in this case "throw new IIOException("Can't create an ImageInputStream!"))" should be removed from read(File); On 21.03.16 10:26, Jayathirth D V wrote: Hi Sergey, For the second approach I have created webrev for review. Please review updated webrev : http://cr.openjdk.java.net/~jdv/8044289/webrev.02/ Thanks, Jay -----Original Message----- From: Jayathirth D V Sent: Friday, March 18, 2016 2:23 PM To: Sergey Bylokhov Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net; Philip Race Subject: RE: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream Hi Sergey, Thanks for your inputs. Indeed all the null values returned by createImageInputStream() and createImageInputStream() are valid only. I went through the code more and found that there is no need for fix in ImageIO.read() methods as null stream is handled in read(ImageInputStream stream) which is called by all the remaining read() API's through IAE. So i can remove the changes made in ImageIO.read() functions. Also istream is closed in finally block of read(url). For ImageIO.write(File) & ImageIO.write(OutputStream) NPE we have two approaches for fix: 1) Keep the present changes of throwing IOException when stream is null and change the throw clause of write() spec mentioning: "IOException - if an error occurs during writing or not able to create required ImageOutputStream" 2) Remove the present changes and handle null in doWrite() method by returning false when stream is null & add code in finally block to close the stream only when stream is not null. Along with this we can also change Returns clause of spec to mention that write() might return false when we are not able to create ImageOutputStream. private static boolean doWrite(RenderedImage im, ImageWriter writer, ImageOutputStream output) throws IOException { if (writer == null) { return false; } + if (output == null) { + return false; + } try { return doWrite(im, writer, stream); } finally { + if (stream != null) stream.close(); } Returns : false if no appropriate writer is found or not able to create required ImageOutputStream. Please let me know your inputs. Thanks, Jay -----Original Message----- From: Sergey Bylokhov Sent: Friday, March 18, 2016 12:24 AM To: Jayathirth D V Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net; Philip Race Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream On 17.03.16 21:14, Jayathirth D V wrote: There are many places in createImageInputStream() and createImageOutputStream() where it will return null for stream. But when why you change the write/read methods? They should take null into account and work according to specification. If some bogus null returns from createImageInputStream/createImageOutputStream then it should be fixed in these methods. So for NPE described in bug to occur there can be multiple paths: 1) One of the path described in bug is when theRegistry.getServiceProviders() throws IAE and we return null. This is the case when we have no installed spi and should return null/false. 2) When we pass non-existent file path to ImageIO (as described in http://stackoverflow.com/questions/11153200/with-imageio-write-api-call-i-get-nullpointerexception ). Here we catch FileNotFoundException but still we return stream as null at the end which will cause NPE further. This is same thing described in the bug(about stream.close()). The write method call createImageOutputStream() and got FileNotFoundException. This exception should be propagated to the user, but it is replaced in the finally block, because we try to close the stream=null. So the fix for this particular case is to check the stream to null in finally, No? 3) When we don't support the provider and theRegistry.getServiceProviders() return iterator with size zero. This means that our providers do not support this case, and we should return null/false. For us to follow first scenario we need access to categoryMap of IIORegistry and delete the ImageInputStreamSpi/ ImageOutputStreamSpi but I was not able to find a way to tamper it from test case. If we follow second case FileNotFoundException will be thrown by default eventhough we handle NPE. But you change the code and we now contradicts the specification, in your case the test should expect false/null from write()/read(). In the test case we are trying to following third scenario to get stream as null to verify the code changes. To catch the bogus null we should try to use another approach, or change the spec. But it seems all null values above are correct, we should be ready for them. As part of collective fix we are throwing IOException which will indicate that we are not able to create required stream. Thanks, Jay -----Original Message----- From: Sergey Bylokhov Sent: Thursday, March 17, 2016 7:27 PM To: Phil Race Cc: Jayathirth D V; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream On 17.03.16 0:36, Phil Race wrote: I don't think that is the actual reason here But the test doing exactly this thing -> deregister all spi => in this case according to specification all related methods(read/write/creatImageInputStream/creatImageOutputStream) should return null or false. - it seems likely that there was some kind of internal error or bad SPI causing this. So throwing an exception seems more appropriate. the problem was in some of our methods which do not expect null in some places(like stream.close() from the bug description). And also the bug was originally solely about write(..). -phil. On 03/16/2016 01:35 PM, Sergey Bylokhov wrote: As far as I understand the createImageInputStream() returns null is this stream is unsupported by current plugins via spi. Probably the read() method should return null too? /** * Returns a {@code BufferedImage} as the result of decoding * a supplied {@code InputStream} with an {@code ImageReader} * chosen automatically from among those currently registered. * The {@code InputStream} is wrapped in an * {@code ImageInputStream}. If no registered * {@code ImageReader} claims to be able to read the * resulting stream, {@code null} is returned. * ....... * @return a {@code BufferedImage} containing the decoded * contents of the input, or {@code null}. */ public static BufferedImage read(InputStream input) throws IOException On 16.03.16 20:29, Philip Race wrote: The test writes out into "test.src". I believe that you should treat that as a "read-only" location. Write to a tempfile (File.createTempFile()) or TESTCLASSES. -phil. On 3/15/16, 10:50 PM, Jayathirth D V wrote: Hi Phil,All _Please review the following fix in JDK9:_ __ Bug : https://bugs.openjdk.java.net/browse/JDK-8044289 Webrev : http://cr.openjdk.java.net/~jdv/8044289/webrev.00/ HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8044289/webrev.00/" Issue : When createImageInputStream() or createImageOutputStream returns null in ImageIO.read() or ImageIO.write() we are seeing NPE as it stream is used further without null check. Root cause : "stream" is used without checking whether it is null or not. Solution : Handle null pointer of stream and throw IIOException. Test case contains all possible scenarios where createImageInputStream() or createImageOutputStream can return null. Thanks, Jay -- Best regards, Sergey. -- Best regards, Sergey. -- Best regards, Sergey. -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Mar 24 11:02:04 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 24 Mar 2016 14:02:04 +0300 Subject: [OpenJDK 2D-Dev] RFR 8149558: [TEST] add regression test for JDK-8150154 In-Reply-To: <56F265FC.9090807@oracle.com> References: <56BDB583.5020806@oracle.com> <56CF1B0A.2030603@oracle.com> <56D069FB.4050503@oracle.com> <56D07546.4010906@oracle.com> <56E8345F.4040006@oracle.com> <56F17347.90102@oracle.com> <56F18092.20300@oracle.com> <56F265FC.9090807@oracle.com> Message-ID: <56F3C92C.2010207@oracle.com> Looks fine to me. On 23.03.16 12:46, Alexander Stepanov wrote: > Hello, Sergey, > > > Should we also test bmp and jpg? > covered as well > > > all of them have a white color and same size > for the 2nd version the images used for the 1st and 2nd checks have > different sizes and colors > > Thanks, > Alexander > > > On 3/22/2016 8:27 PM, Sergey Bylokhov wrote: >> On 22.03.16 19:31, Alexander Stepanov wrote: >>> Sorry, just a reminder. >> >> Can you provide an information what was changed in this version? >> >>> >>> Thanks, >>> Alexander >>> >>> On 3/15/2016 7:12 PM, Alexander Stepanov wrote: >>>> Please see the updated fix: >>>> http://cr.openjdk.java.net/~avstepan/8149558/webrev.01/ >>>> >>>> Thanks, >>>> Alexander >>>> >>>> On 2/26/2016 6:54 PM, Alexander Stepanov wrote: >>>>> > Should we also test bmp and jpg? >>>>> >>>>> couldn't use writer for these formats "as is" (simply >>>>> "writer.write(img)") - this causes IOExceptions. JPEGImageWriteParam >>>>> or BMPImageWriteParam should be used and another signature for >>>>> write() method. Extended test logic looks quite bulky with all this >>>>> additions. >>>>> >>>>> > but you do not check that the saved information actually relates to >>>>> the particular image (all of them have a white color and same size) >>>>> >>>>> even in this case we have color check failure for pair >>>>> (TYPE_USHORT_565_RGB, TYPE_USHORT_555_RGB). but yes, probably it is >>>>> better to use different images for the 1st and 2nd write attempts. >>>>> >>>>> Thanks, >>>>> Alexander >>>>> >>>>> On 2/26/2016 6:06 PM, Sergey Bylokhov wrote: >>>>>> Should we also test bmp and jpg? You tested a different BI formats, >>>>>> but you do not check that the saved information actually relates to >>>>>> the particular image(all of them have a white color and same size). >>>>>> So you will not notice if the Writer will write the same(first) >>>>>> image in all subsequent calls. >>>>>> >>>>>> On 25.02.16 18:17, Alexander Stepanov wrote: >>>>>>> Sorry, just a reminder. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexander >>>>>>> >>>>>>> On 2/12/2016 1:35 PM, Alexander Stepanov wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Could you please review the following fix >>>>>>>> http://cr.openjdk.java.net/~avstepan/8149558/webrev.00/ >>>>>>>> for >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8149558 >>>>>>>> >>>>>>>> Just a single regression test added (still failing), plus minor >>>>>>>> correction for other test. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexander >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >> > -- Best regards, Sergey. From alexander.v.stepanov at oracle.com Thu Mar 24 11:03:30 2016 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Thu, 24 Mar 2016 14:03:30 +0300 Subject: [OpenJDK 2D-Dev] RFR 8149558: [TEST] add regression test for JDK-8150154 In-Reply-To: <56F3C92C.2010207@oracle.com> References: <56BDB583.5020806@oracle.com> <56CF1B0A.2030603@oracle.com> <56D069FB.4050503@oracle.com> <56D07546.4010906@oracle.com> <56E8345F.4040006@oracle.com> <56F17347.90102@oracle.com> <56F18092.20300@oracle.com> <56F265FC.9090807@oracle.com> <56F3C92C.2010207@oracle.com> Message-ID: <56F3C982.2050804@oracle.com> Thanks! On 3/24/2016 2:02 PM, Sergey Bylokhov wrote: > Looks fine to me. > > On 23.03.16 12:46, Alexander Stepanov wrote: >> Hello, Sergey, >> >> > Should we also test bmp and jpg? >> covered as well >> >> > all of them have a white color and same size >> for the 2nd version the images used for the 1st and 2nd checks have >> different sizes and colors >> >> Thanks, >> Alexander >> >> >> On 3/22/2016 8:27 PM, Sergey Bylokhov wrote: >>> On 22.03.16 19:31, Alexander Stepanov wrote: >>>> Sorry, just a reminder. >>> >>> Can you provide an information what was changed in this version? >>> >>>> >>>> Thanks, >>>> Alexander >>>> >>>> On 3/15/2016 7:12 PM, Alexander Stepanov wrote: >>>>> Please see the updated fix: >>>>> http://cr.openjdk.java.net/~avstepan/8149558/webrev.01/ >>>>> >>>>> Thanks, >>>>> Alexander >>>>> >>>>> On 2/26/2016 6:54 PM, Alexander Stepanov wrote: >>>>>> > Should we also test bmp and jpg? >>>>>> >>>>>> couldn't use writer for these formats "as is" (simply >>>>>> "writer.write(img)") - this causes IOExceptions. JPEGImageWriteParam >>>>>> or BMPImageWriteParam should be used and another signature for >>>>>> write() method. Extended test logic looks quite bulky with all this >>>>>> additions. >>>>>> >>>>>> > but you do not check that the saved information actually >>>>>> relates to >>>>>> the particular image (all of them have a white color and same size) >>>>>> >>>>>> even in this case we have color check failure for pair >>>>>> (TYPE_USHORT_565_RGB, TYPE_USHORT_555_RGB). but yes, probably it is >>>>>> better to use different images for the 1st and 2nd write attempts. >>>>>> >>>>>> Thanks, >>>>>> Alexander >>>>>> >>>>>> On 2/26/2016 6:06 PM, Sergey Bylokhov wrote: >>>>>>> Should we also test bmp and jpg? You tested a different BI formats, >>>>>>> but you do not check that the saved information actually relates to >>>>>>> the particular image(all of them have a white color and same size). >>>>>>> So you will not notice if the Writer will write the same(first) >>>>>>> image in all subsequent calls. >>>>>>> >>>>>>> On 25.02.16 18:17, Alexander Stepanov wrote: >>>>>>>> Sorry, just a reminder. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexander >>>>>>>> >>>>>>>> On 2/12/2016 1:35 PM, Alexander Stepanov wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Could you please review the following fix >>>>>>>>> http://cr.openjdk.java.net/~avstepan/8149558/webrev.00/ >>>>>>>>> for >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8149558 >>>>>>>>> >>>>>>>>> Just a single regression test added (still failing), plus minor >>>>>>>>> correction for other test. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexander >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> >> > > From yuri.nesterenko at oracle.com Thu Mar 24 15:14:57 2016 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Thu, 24 Mar 2016 18:14:57 +0300 Subject: [OpenJDK 2D-Dev] RFR 8149558: [TEST] add regression test for JDK-8150154 In-Reply-To: <56F265FC.9090807@oracle.com> References: <56BDB583.5020806@oracle.com> <56CF1B0A.2030603@oracle.com> <56D069FB.4050503@oracle.com> <56D07546.4010906@oracle.com> <56E8345F.4040006@oracle.com> <56F17347.90102@oracle.com> <56F18092.20300@oracle.com> <56F265FC.9090807@oracle.com> Message-ID: <56F40471.4050405@oracle.com> Looks OK. -yan On 03/23/2016 12:46 PM, Alexander Stepanov wrote: > Hello, Sergey, > > > Should we also test bmp and jpg? > covered as well > > > all of them have a white color and same size > for the 2nd version the images used for the 1st and 2nd checks have > different sizes and colors > > Thanks, > Alexander > > > On 3/22/2016 8:27 PM, Sergey Bylokhov wrote: >> On 22.03.16 19:31, Alexander Stepanov wrote: >>> Sorry, just a reminder. >> >> Can you provide an information what was changed in this version? >> >>> >>> Thanks, >>> Alexander >>> >>> On 3/15/2016 7:12 PM, Alexander Stepanov wrote: >>>> Please see the updated fix: >>>> http://cr.openjdk.java.net/~avstepan/8149558/webrev.01/ >>>> >>>> Thanks, >>>> Alexander >>>> >>>> On 2/26/2016 6:54 PM, Alexander Stepanov wrote: >>>>> > Should we also test bmp and jpg? >>>>> >>>>> couldn't use writer for these formats "as is" (simply >>>>> "writer.write(img)") - this causes IOExceptions. JPEGImageWriteParam >>>>> or BMPImageWriteParam should be used and another signature for >>>>> write() method. Extended test logic looks quite bulky with all this >>>>> additions. >>>>> >>>>> > but you do not check that the saved information actually relates to >>>>> the particular image (all of them have a white color and same size) >>>>> >>>>> even in this case we have color check failure for pair >>>>> (TYPE_USHORT_565_RGB, TYPE_USHORT_555_RGB). but yes, probably it is >>>>> better to use different images for the 1st and 2nd write attempts. >>>>> >>>>> Thanks, >>>>> Alexander >>>>> >>>>> On 2/26/2016 6:06 PM, Sergey Bylokhov wrote: >>>>>> Should we also test bmp and jpg? You tested a different BI formats, >>>>>> but you do not check that the saved information actually relates to >>>>>> the particular image(all of them have a white color and same size). >>>>>> So you will not notice if the Writer will write the same(first) >>>>>> image in all subsequent calls. >>>>>> >>>>>> On 25.02.16 18:17, Alexander Stepanov wrote: >>>>>>> Sorry, just a reminder. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexander >>>>>>> >>>>>>> On 2/12/2016 1:35 PM, Alexander Stepanov wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Could you please review the following fix >>>>>>>> http://cr.openjdk.java.net/~avstepan/8149558/webrev.00/ >>>>>>>> for >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8149558 >>>>>>>> >>>>>>>> Just a single regression test added (still failing), plus minor >>>>>>>> correction for other test. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexander >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >> > From alexander.v.stepanov at oracle.com Thu Mar 24 17:18:18 2016 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Thu, 24 Mar 2016 20:18:18 +0300 Subject: [OpenJDK 2D-Dev] RFR 8149558: [TEST] add regression test for JDK-8150154 In-Reply-To: <56F3C92C.2010207@oracle.com> References: <56BDB583.5020806@oracle.com> <56CF1B0A.2030603@oracle.com> <56D069FB.4050503@oracle.com> <56D07546.4010906@oracle.com> <56E8345F.4040006@oracle.com> <56F17347.90102@oracle.com> <56F18092.20300@oracle.com> <56F265FC.9090807@oracle.com> <56F3C92C.2010207@oracle.com> Message-ID: <56F4215A.6040506@oracle.com> Hello Sergey, Sorry, could you please look at the new test once more? the following lines 124 // some type checks: avoid IO exceptions 125 126 if ((format.equals("jpeg") || format.equals("bmp")) && 127 pair.contains("USHORT_GRAY")) { 128 return; 129 } 130 131 if (format.equals("bmp") && 132 (pair.contains("ARGB") || pair.contains("ABGR"))) { 133 return; 134 } were replaced with 124 // some type checks: avoid IO exceptions 125 if ((format.equals("jpeg") || format.equals("bmp")) && 126 (pair.contains("USHORT_GRAY") || 127 pair.contains("ARGB") || pair.contains("ABGR"))) { 128 return; 129 } to make possible to run the test with OpenJDK (didn't check that initially). Thanks, Alexander On 3/24/2016 2:02 PM, Sergey Bylokhov wrote: > Looks fine to me. > > On 23.03.16 12:46, Alexander Stepanov wrote: >> Hello, Sergey, >> >> > Should we also test bmp and jpg? >> covered as well >> >> > all of them have a white color and same size >> for the 2nd version the images used for the 1st and 2nd checks have >> different sizes and colors >> >> Thanks, >> Alexander >> >> >> On 3/22/2016 8:27 PM, Sergey Bylokhov wrote: >>> On 22.03.16 19:31, Alexander Stepanov wrote: >>>> Sorry, just a reminder. >>> >>> Can you provide an information what was changed in this version? >>> >>>> >>>> Thanks, >>>> Alexander >>>> >>>> On 3/15/2016 7:12 PM, Alexander Stepanov wrote: >>>>> Please see the updated fix: >>>>> http://cr.openjdk.java.net/~avstepan/8149558/webrev.01/ >>>>> >>>>> Thanks, >>>>> Alexander >>>>> >>>>> On 2/26/2016 6:54 PM, Alexander Stepanov wrote: >>>>>> > Should we also test bmp and jpg? >>>>>> >>>>>> couldn't use writer for these formats "as is" (simply >>>>>> "writer.write(img)") - this causes IOExceptions. JPEGImageWriteParam >>>>>> or BMPImageWriteParam should be used and another signature for >>>>>> write() method. Extended test logic looks quite bulky with all this >>>>>> additions. >>>>>> >>>>>> > but you do not check that the saved information actually >>>>>> relates to >>>>>> the particular image (all of them have a white color and same size) >>>>>> >>>>>> even in this case we have color check failure for pair >>>>>> (TYPE_USHORT_565_RGB, TYPE_USHORT_555_RGB). but yes, probably it is >>>>>> better to use different images for the 1st and 2nd write attempts. >>>>>> >>>>>> Thanks, >>>>>> Alexander >>>>>> >>>>>> On 2/26/2016 6:06 PM, Sergey Bylokhov wrote: >>>>>>> Should we also test bmp and jpg? You tested a different BI formats, >>>>>>> but you do not check that the saved information actually relates to >>>>>>> the particular image(all of them have a white color and same size). >>>>>>> So you will not notice if the Writer will write the same(first) >>>>>>> image in all subsequent calls. >>>>>>> >>>>>>> On 25.02.16 18:17, Alexander Stepanov wrote: >>>>>>>> Sorry, just a reminder. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexander >>>>>>>> >>>>>>>> On 2/12/2016 1:35 PM, Alexander Stepanov wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Could you please review the following fix >>>>>>>>> http://cr.openjdk.java.net/~avstepan/8149558/webrev.00/ >>>>>>>>> for >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8149558 >>>>>>>>> >>>>>>>>> Just a single regression test added (still failing), plus minor >>>>>>>>> correction for other test. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexander >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> >> > > From philip.race at oracle.com Thu Mar 24 18:27:20 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 24 Mar 2016 11:27:20 -0700 Subject: [OpenJDK 2D-Dev] [9] Review request for 8142966 Wrong cursor position in text components on HiDPI display In-Reply-To: <56E01A59.8070604@oracle.com> References: <56A935F0.5060504@oracle.com> <56B4FA69.9000604@oracle.com> <56B6112F.1050708@oracle.com> <56B8E930.9000405@oracle.com> <56B9FC1F.9090607@oracle.com> <56B9FE27.4040204@oracle.com> <56BE3D82.5010506@oracle.com> <56E01A59.8070604@oracle.com> Message-ID: <56F43188.7030801@oracle.com> I am not sure developers on OS X have the same history of expectation that metrics will not be changed but I think they may find it harder to spot there anyway because the rendering on OS X does not use hinting but it is an issue everywhere else. So pointing to a similar change on OS X doesn't help. The question is if you take a "low-dpi" display and draw a variety of the same long strings before and after the fix, with a variety of fonts, is there any case where they measure any differently. I think there must be if you throw away the hinted advances. Note that the most important case is Windows, not Linux, and you need to look at T2K not just freetype. -phil. On 03/09/2016 04:43 AM, Alexander Scherbatiy wrote: > > Hello, > > Could you review the proposed fix? > > Thanks, > Alexandr. > > On 13/02/16 00:16, Alexander Scherbatiy wrote: >> On 09/02/16 18:56, Sergey Bylokhov wrote: >>> Also probably it will be possible to test this via the public api >>> only(using the mix of the graphics transform + font transform). >>> >>> On 09.02.16 17:47, Sergey Bylokhov wrote: >>>> Some additional information. >>>> The Swing calculates the size of the components and location of the >>>> cursor based on the text metrics. And these text metrics based on >>>> advance. The Swing do not know to what destination it will be painted, >>>> it calculates the size based on the non-scaled(non-retina) >>>> destination. >>>> The problem occurs when we paint such component to the hidpi screen, >>>> because we get small round errors per glyph -> this causes a visible >>>> issue? when the text string is long. As a solution on the macosx the >>>> round operation was done in the users space instead of dev space. >>>> >>>> For example before the fix the size 1.4px was rounded to 3 (1.4 * 2 = >>>> 2.8 -> 3), but after the fix it will be 2 (1.4-> 1 * 2 = 2). So the >>>> Swing will be able to calculate correct size/location without >>>> information of the device scale. Note that the 3px(in dev space) is a >>>> kind of fractional coordinate in the user space(1.5). And the Swing >>>> does >>>> not work properly when fractional metrics are used, because it use >>>> ints >>>> as a coordinates. >>>> >>>> Note that the fix should be applied only when fractional metrics is >>>> off, >>>> otherwise we should not use any rounding. I am not sure that the >>>> current >>>> fix take it into account. >> The proposed fix is applied only when the fractional metrics are off. >>>> >>>> >>>> On 08.02.16 22:14, Jim Graham wrote: >>>>> Isn't the problem there that we are returning an integer as the >>>>> advance? >>>>> Why aren't we returning 7.35 as a value instead of 8? >> 7.35 is returned when fractional metrics are on. >>>>> >>>>> Also, shouldn't 7.35 round to 7 and 14.7 round to 15? >> This happens because when fractional metrics are on the glyph >> linearAdvance value is returned (for current case >> ftglyph->linearHoriAdvance = 7.35). >> But when fractional metrics are off the glyph advance is returned >> (ftglyph->advance.x = 8). >> This calculation is done by freetype library. >> >> Thanks, >> Alexandr. >> >>>>> >>>>> ...jim >>>>> >>>>> On 2/6/2016 7:28 AM, Alexander Scherbatiy wrote: >>>>>> On 05/02/16 23:39, Phil Race wrote: >>>>>>> Two things strike me when I read this >>>>>>> >>>>>>> 1) Initial surprise at how deep into the font code it goes. >>>>>>> Perhaps there are alternatives. >>>>>>> >>>>>>> 2) That it changes to using the linear metrics for measuring >>>>>>> advance. >>>>>>> Regardless of (1) I do not think (2) is correct. I am fairly >>>>>>> sure this >>>>>>> will lead to changes in text advance. It seems like it must throw >>>>>>> away adjusted metrics as a result of glyph hinting. >>>>>>> >>>>>>> I don't know what the fix should be, since I have not looked at the >>>>>>> problem top-down, I am just seeing the bottom-up proposed solution. >>>>>>> So all I can say for now is that it needs to be at least somewhat >>>>>>> different. >>>>>> >>>>>> There was the same issue on Mac OS X which has been fixed in the >>>>>> similar way: >>>>>> 8013569 [macosx] JLabel preferred size incorrect on retina >>>>>> displays >>>>>> with non-default font size >>>>>> https://bugs.openjdk.java.net/browse/JDK-8013569 >>>>>> http://cr.openjdk.java.net/~serb/7190349/webrev.04/ >>>>>> >>>>>> The problem is that in many case for UI scale 2 we return to a >>>>>> user >>>>>> an unscaled value. >>>>>> But a value for transformed glyph advance, rounded and >>>>>> descaled can >>>>>> differ from just rounded glyph advance. >>>>>> >>>>>> For example, font[dialog, plain, 12] char 'a': >>>>>> transform: 12, advance: 7.35, rounded advance: 8 >>>>>> transform: 24, advance: 14.70 round advance: 14 >>>>>> >>>>>> and 8 does not equal 14 / 2. >>>>>> >>>>>> The solution for Mac OS X was to get the glyph advance using only >>>>>> font transform, round it and then apply the dev transform: >>>>>> >>>>>> CGGlyphImages.m: >>>>>> 481 advance = CGSizeApplyAffineTransform(advance, >>>>>> strike->fFontTx); >>>>>> 482 if (!JRSFontStyleUsesFractionalMetrics(strike->fStyle)) { >>>>>> 483 advance.width = round(advance.width); >>>>>> 484 advance.height = round(advance.height); >>>>>> 485 } >>>>>> 486 advance = CGSizeApplyAffineTransform(advance, >>>>>> strike->fDevTx); >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 01/27/2016 01:26 PM, Alexander Scherbatiy wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> Could you review the fix: >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8142966 >>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8142966/webev.00/ >>>>>>>> >>>>>>>> The proposed fix rounds a glyph advance first and then scales >>>>>>>> it if >>>>>>>> UI scales do not equal to one. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>> >>>>>> >>>> >>>> >>> >>> >> > From philip.race at oracle.com Thu Mar 24 21:16:35 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 24 Mar 2016 14:16:35 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8146324: Add sun.font.FontUtilities.isComplexCharCode or related method to public API Message-ID: <56F45933.2030705@oracle.com> bug : https://bugs.openjdk.java.net/browse/JDK-8146324 fix : http://cr.openjdk.java.net/~prr/8146324/ Developers have used an internal API to detect when TextLayout or GlyphVector.layoutGlyphVectorwill be needed since that is a slower path. This provides a public equivalent capability. I have included a test which checks the assertions of the API. A CCC will be filed. -phil. From Sergey.Bylokhov at oracle.com Thu Mar 24 21:37:56 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 25 Mar 2016 00:37:56 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8146324: Add sun.font.FontUtilities.isComplexCharCode or related method to public API In-Reply-To: <56F45933.2030705@oracle.com> References: <56F45933.2030705@oracle.com> Message-ID: <56F45E34.4030806@oracle.com> Hi, Phil. Should this new method throw IAE? It seems that NPE can be thrown instead, At least other methods in Font.java including the newly added createFonts() throw NPE. On 25.03.16 0:16, Phil Race wrote: > bug : https://bugs.openjdk.java.net/browse/JDK-8146324 > fix : http://cr.openjdk.java.net/~prr/8146324/ > > Developers have used an internal API to detect when TextLayout or > GlyphVector.layoutGlyphVectorwill be needed since that is a slower path. > > This provides a public equivalent capability. > > I have included a test which checks the assertions of the API. > > A CCC will be filed. > > -phil. -- Best regards, Sergey. From andrej.golovnin at gmail.com Thu Mar 24 21:41:46 2016 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Thu, 24 Mar 2016 22:41:46 +0100 Subject: [OpenJDK 2D-Dev] RFR: 8146324: Add sun.font.FontUtilities.isComplexCharCode or related method to public API In-Reply-To: <56F45933.2030705@oracle.com> References: <56F45933.2030705@oracle.com> Message-ID: Hi Phil, > bug : https://bugs.openjdk.java.net/browse/JDK-8146324 > fix : http://cr.openjdk.java.net/~prr/8146324/ maybe the line 794: 794 * @return true if the specified text will need special layout. should be changed to: 794 * @return {@code true} if the specified text will need special layout. Best regards, Andrej Golovnin From masayoshi.okutsu at oracle.com Thu Mar 24 06:18:23 2016 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 24 Mar 2016 15:18:23 +0900 Subject: [OpenJDK 2D-Dev] [9] Review request for 8073400: Some Monospaced logical fonts have a different width In-Reply-To: <56EFA915.8010700@oracle.com> References: <56977953.10604@oracle.com> <56BB9CAC.3050408@oracle.com> <56C46F35.6030107@oracle.com> <56EB0B71.8090000@oracle.com> <56EE22EE.8070803@oracle.com> <56EFA915.8010700@oracle.com> Message-ID: <56F386AF.4040807@oracle.com> Looks good to me. Masayoshi On 3/21/2016 4:56 PM, dmitry markov wrote: > Hello, > Thank you very much for the review. > > I added a simple test for the fix. Please find the updated webrev > here: http://cr.openjdk.java.net/~dmarkov/8073400/jdk9/webrev.01/ > Could you take a look at it, please? > > thank you in advance, > Dmitry > On 20/03/2016 07:11, Masayoshi Okutsu wrote: >> The fix looks Okay to me. But there should be a regression test for >> this particular case? I wonder if we can have a test case to verify >> width(s) of monospaced glyphs. >> >> Masayoshi >> >> >> On 3/18/2016 4:54 AM, Phil Race wrote: >>> I think you are still waiting on i18n to reply here since the >>> exclusion ranges >>> are mainly used for ensuring that the glyphs come from the right >>> font which >>> is mainly for locale reasons. If i18n see no problems then I am OK >>> with this. >>> >>> -phil. >>> >>> On 02/17/2016 05:01 AM, dmitry markov wrote: >>>> Hello Phil, >>>> >>>> Thank you for the review. >>>> >>>> According to unicode table the characters u201c and u201d are in >>>> General Punctuation block, see >>>> http://unicode-table.com/en/blocks/general-punctuation/ >>>> Many characters from this block are not supported by Courier New. >>>> So I do not think we need to remove the whole block from the >>>> exclusion range, since it will not have any effect except few >>>> characters like u201c and u201d. That's why I removed such small >>>> characters set (u2018 - u201F) from the exclusion range, but I can >>>> change this if it is necessary. >>>> >>>> At the same time the characters set (u2018 - u201F) is supported by >>>> Arial and Times New Roman which are mapped to other logical fonts. >>>> The adjusted exclusion range seems 'quite safe' from this point of >>>> view. So I do not think we need to modify any code such as >>>> FontConfiguration class and so on to apply these changes only to >>>> monospaced fonts. Please correct me if I am wrong. >>>> >>>> Adding i18n-dev. >>>> >>>> Internationalization team, >>>> Could you review a small change in windows.fontconfig.properties, >>>> please? >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8073400 >>>> webrev: >>>> http://cr.openjdk.java.net/~dmarkov/8073400/jdk9/webrev.00/ >>>> >>>> Problem description: >>>> On Windows some characters (in particular, left and right double >>>> quotation marks) have width differing from other characters' >>>> widths, when Monospaced logical font is used. >>>> The default monospaced font for windows platform is Courier New. It >>>> contains the desired characters, (i.e. '\u201c' and '\u201d'). >>>> However the characters are in 'exclusion ranges' for this font due >>>> to settings in windows.fontconfig.properties. So when we try to >>>> obtain glyphs for these characters and calculate their bounds, we >>>> fallback to another font (Lucida) and use its glyphs. >>>> >>>> Fix: >>>> Remove the following set of characters u2018 - u201F from the >>>> exclusion ranges. >>>> >>>> Thank you in advance, >>>> Dmitry >>>> On 10/02/2016 23:25, Phil Race wrote: >>>>> I expect the exclusion range is there for a reason. >>>>> I think (guess) that the intent was that where there is a sequence >>>>> like this : >>>>> >>>>> sequence.sansserif.x-windows-950=alphabetic,chinese-ms950,dingbats,symbol,chinese-ms950-extb >>>>> >>>>> >>>>> then those code points should come from the chinese font. >>>>> >>>>> Perhaps your adjusted exclusion range should apply only to the >>>>> monospaced fonts >>>>> which are already putting the locale font first. >>>>> >>>>> Unfortunately it doesn't appear that this is possible with the >>>>> supported syntax >>>>> https://docs.oracle.com/javase/1.5.0/docs/guide/intl/fontconfig.html#windows >>>>> >>>>> >>>>> i.e it supports selection only by charactersubsetname, not also by >>>>> logicalfontname. >>>>> But you should check the code to see if this is in fact the case. >>>>> There may need to be a non-ideal decision or a revision to that >>>>> spec. and its >>>>> supporting code. >>>>> >>>>> And why be so narrow ? It seems you have made an even odder situation >>>>> in having just those two code points 'un'-excluded. >>>>> The argument that those were the two a customer complained about >>>>> does not >>>>> hold up very well. >>>>> >>>>> I think you should also run this whole change+discussion by >>>>> i18n-dev .. >>>>> >>>>> >>>>> -phil. >>>>> >>>>> On 01/14/2016 02:32 AM, dmitry markov wrote: >>>>>> Hello, >>>>>> >>>>>> Could you review the fix for jdk9, please? >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8073400 >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~dmarkov/8073400/jdk9/webrev.00/ >>>>>> >>>>>> Problem description: >>>>>> On Windows some characters (in particular, left and right double >>>>>> quotation marks) have width differing from other characters' >>>>>> widths, when Monospaced logical font is used. >>>>>> The default monospaced font for windows platform is Courier New. >>>>>> It contains the desired characters, (i.e. '\u201c' and '\u201d'). >>>>>> However the characters are in 'exclusion ranges' for this font >>>>>> due to settings in windows.fontconfig.properties. So when we try >>>>>> to obtain glyphs for these characters and calculate their bounds, >>>>>> we fallback to another font (Lucida) and use its glyphs. >>>>>> >>>>>> Fix: >>>>>> Remove the following set of characters u2018 - u201F from the >>>>>> exclusion ranges. >>>>>> >>>>>> Thanks, >>>>>> Dmitry >>>>> >>>> >>> >> > From philip.race at oracle.com Thu Mar 24 22:22:22 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 24 Mar 2016 15:22:22 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8146324: Add sun.font.FontUtilities.isComplexCharCode or related method to public API In-Reply-To: <56F45E34.4030806@oracle.com> References: <56F45933.2030705@oracle.com> <56F45E34.4030806@oracle.com> Message-ID: <56F4689E.5090802@oracle.com> That is true .. although I think I have previously been convinced that IAE is generally the better choice for such a case, I found only deriveFont that throws IAE for null in this file. So the question is whether to be consistent or to start picking the better option. So if there were no existing IAEs or NPEs in this file, which would you choose now ? -phil. On 03/24/2016 02:37 PM, Sergey Bylokhov wrote: > Hi, Phil. > Should this new method throw IAE? It seems that NPE can be thrown > instead, At least other methods in Font.java including the newly added > createFonts() throw NPE. > > On 25.03.16 0:16, Phil Race wrote: >> bug : https://bugs.openjdk.java.net/browse/JDK-8146324 >> fix : http://cr.openjdk.java.net/~prr/8146324/ >> >> Developers have used an internal API to detect when TextLayout or >> GlyphVector.layoutGlyphVectorwill be needed since that is a slower path. >> >> This provides a public equivalent capability. >> >> I have included a test which checks the assertions of the API. >> >> A CCC will be filed. >> >> -phil. > > From andrej.golovnin at gmail.com Thu Mar 24 22:43:01 2016 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Thu, 24 Mar 2016 23:43:01 +0100 Subject: [OpenJDK 2D-Dev] RFR: 8146324: Add sun.font.FontUtilities.isComplexCharCode or related method to public API In-Reply-To: <56F4689E.5090802@oracle.com> References: <56F45933.2030705@oracle.com> <56F45E34.4030806@oracle.com> <56F4689E.5090802@oracle.com> Message-ID: <2D664EB2-0C0E-45DC-8ECF-21FFBF13682E@gmail.com> Hi Phil, > That is true .. although I think I have previously been convinced that IAE > is generally the better choice for such a case, I found only deriveFont > that throws IAE for null in this file. > So the question is whether to be consistent or to start picking the better option. > So if there were no existing IAEs or NPEs in this file, which would you choose now ? From my standpoint of view you should use NPE. And maybe java.util.Objects.requireNonNull() may help you to answer this question if you rewrite your code to use it instead of doing manual check. :-) Best regards, Andrej Golovnin From Sergey.Bylokhov at oracle.com Thu Mar 24 22:59:50 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 25 Mar 2016 01:59:50 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8146324: Add sun.font.FontUtilities.isComplexCharCode or related method to public API In-Reply-To: <56F4689E.5090802@oracle.com> References: <56F45933.2030705@oracle.com> <56F45E34.4030806@oracle.com> <56F4689E.5090802@oracle.com> Message-ID: <56F47166.3000303@oracle.com> On 25.03.16 1:22, Phil Race wrote: > That is true .. although I think I have previously been convinced that IAE > is generally the better choice for such a case, I found only deriveFont > that throws IAE for null in this file. deriveFont were changed(NPE to IAE) in 2001, but other methods and the new code still use NPE. I think that in the most cases the null is not taken into account and the specification is updated later(like the new createFonts()). > So the question is whether to be consistent or to start picking the > better option. > So if there were no existing IAEs or NPEs in this file, which would you > choose now ? Personally I always use NPE for null(via Objects.requireNonNull(...)). and IAE for other incorrect arguments/types. or if the file(or the same method) uses IAE already for null. As an example I use System.getProperty(String). But in Font.java we specify NPE for a few methods already, some other methods throw NPE but w/o specification(except deriveFont...) > > -phil. > > On 03/24/2016 02:37 PM, Sergey Bylokhov wrote: >> Hi, Phil. >> Should this new method throw IAE? It seems that NPE can be thrown >> instead, At least other methods in Font.java including the newly added >> createFonts() throw NPE. >> >> On 25.03.16 0:16, Phil Race wrote: >>> bug : https://bugs.openjdk.java.net/browse/JDK-8146324 >>> fix : http://cr.openjdk.java.net/~prr/8146324/ >>> >>> Developers have used an internal API to detect when TextLayout or >>> GlyphVector.layoutGlyphVectorwill be needed since that is a slower path. >>> >>> This provides a public equivalent capability. >>> >>> I have included a test which checks the assertions of the API. >>> >>> A CCC will be filed. >>> >>> -phil. >> >> > -- Best regards, Sergey. From semyon.sadetsky at oracle.com Fri Mar 25 07:03:33 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 25 Mar 2016 10:03:33 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8146324: Add sun.font.FontUtilities.isComplexCharCode or related method to public API In-Reply-To: <2D664EB2-0C0E-45DC-8ECF-21FFBF13682E@gmail.com> References: <56F45933.2030705@oracle.com> <56F45E34.4030806@oracle.com> <56F4689E.5090802@oracle.com> <2D664EB2-0C0E-45DC-8ECF-21FFBF13682E@gmail.com> Message-ID: <56F4E2C5.6000801@oracle.com> On 3/25/2016 1:43 AM, Andrej Golovnin wrote: > Hi Phil, > >> That is true .. although I think I have previously been convinced that IAE >> is generally the better choice for such a case, I found only deriveFont >> that throws IAE for null in this file. >> So the question is whether to be consistent or to start picking the better option. >> So if there were no existing IAEs or NPEs in this file, which would you choose now ? > From my standpoint of view you should use NPE. > And maybe java.util.Objects.requireNonNull() may help you to answer this question > if you rewrite your code to use it instead of doing manual check. :-) requireNonNull() just checks null value regardless of where is it found. While the question is about about method argument values specifically. I would be grateful to those who can prove why NPE is preferred to IAE in case if the invalid argument value equals to null. > > Best regards, > Andrej Golovnin From Sergey.Bylokhov at oracle.com Fri Mar 25 12:25:47 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 25 Mar 2016 15:25:47 +0300 Subject: [OpenJDK 2D-Dev] RFR 8149558: [TEST] add regression test for JDK-8150154 In-Reply-To: <56F4215A.6040506@oracle.com> References: <56BDB583.5020806@oracle.com> <56CF1B0A.2030603@oracle.com> <56D069FB.4050503@oracle.com> <56D07546.4010906@oracle.com> <56E8345F.4040006@oracle.com> <56F17347.90102@oracle.com> <56F18092.20300@oracle.com> <56F265FC.9090807@oracle.com> <56F3C92C.2010207@oracle.com> <56F4215A.6040506@oracle.com> Message-ID: <56F52E4B.4040208@oracle.com> +1 On 24.03.16 20:18, Alexander Stepanov wrote: > Hello Sergey, > > Sorry, could you please look at the new test once more? > > the following lines > 124 // some type checks: avoid IO exceptions > 125 > 126 if ((format.equals("jpeg") || format.equals("bmp")) && > 127 pair.contains("USHORT_GRAY")) { > 128 return; > 129 } > 130 > 131 if (format.equals("bmp") && > 132 (pair.contains("ARGB") || pair.contains("ABGR"))) { > 133 return; > 134 } > > were replaced with > 124 // some type checks: avoid IO exceptions > 125 if ((format.equals("jpeg") || format.equals("bmp")) && > 126 (pair.contains("USHORT_GRAY") || > 127 pair.contains("ARGB") || pair.contains("ABGR"))) { > 128 return; > 129 } > > to make possible to run the test with OpenJDK (didn't check that > initially). > > Thanks, > Alexander > > On 3/24/2016 2:02 PM, Sergey Bylokhov wrote: >> Looks fine to me. >> >> On 23.03.16 12:46, Alexander Stepanov wrote: >>> Hello, Sergey, >>> >>> > Should we also test bmp and jpg? >>> covered as well >>> >>> > all of them have a white color and same size >>> for the 2nd version the images used for the 1st and 2nd checks have >>> different sizes and colors >>> >>> Thanks, >>> Alexander >>> >>> >>> On 3/22/2016 8:27 PM, Sergey Bylokhov wrote: >>>> On 22.03.16 19:31, Alexander Stepanov wrote: >>>>> Sorry, just a reminder. >>>> >>>> Can you provide an information what was changed in this version? >>>> >>>>> >>>>> Thanks, >>>>> Alexander >>>>> >>>>> On 3/15/2016 7:12 PM, Alexander Stepanov wrote: >>>>>> Please see the updated fix: >>>>>> http://cr.openjdk.java.net/~avstepan/8149558/webrev.01/ >>>>>> >>>>>> Thanks, >>>>>> Alexander >>>>>> >>>>>> On 2/26/2016 6:54 PM, Alexander Stepanov wrote: >>>>>>> > Should we also test bmp and jpg? >>>>>>> >>>>>>> couldn't use writer for these formats "as is" (simply >>>>>>> "writer.write(img)") - this causes IOExceptions. JPEGImageWriteParam >>>>>>> or BMPImageWriteParam should be used and another signature for >>>>>>> write() method. Extended test logic looks quite bulky with all this >>>>>>> additions. >>>>>>> >>>>>>> > but you do not check that the saved information actually >>>>>>> relates to >>>>>>> the particular image (all of them have a white color and same size) >>>>>>> >>>>>>> even in this case we have color check failure for pair >>>>>>> (TYPE_USHORT_565_RGB, TYPE_USHORT_555_RGB). but yes, probably it is >>>>>>> better to use different images for the 1st and 2nd write attempts. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexander >>>>>>> >>>>>>> On 2/26/2016 6:06 PM, Sergey Bylokhov wrote: >>>>>>>> Should we also test bmp and jpg? You tested a different BI formats, >>>>>>>> but you do not check that the saved information actually relates to >>>>>>>> the particular image(all of them have a white color and same size). >>>>>>>> So you will not notice if the Writer will write the same(first) >>>>>>>> image in all subsequent calls. >>>>>>>> >>>>>>>> On 25.02.16 18:17, Alexander Stepanov wrote: >>>>>>>>> Sorry, just a reminder. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexander >>>>>>>>> >>>>>>>>> On 2/12/2016 1:35 PM, Alexander Stepanov wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Could you please review the following fix >>>>>>>>>> http://cr.openjdk.java.net/~avstepan/8149558/webrev.00/ >>>>>>>>>> for >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8149558 >>>>>>>>>> >>>>>>>>>> Just a single regression test added (still failing), plus minor >>>>>>>>>> correction for other test. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexander >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > -- Best regards, Sergey. From alexander.v.stepanov at oracle.com Fri Mar 25 12:27:14 2016 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Fri, 25 Mar 2016 15:27:14 +0300 Subject: [OpenJDK 2D-Dev] RFR 8149558: [TEST] add regression test for JDK-8150154 In-Reply-To: <56F52E4B.4040208@oracle.com> References: <56BDB583.5020806@oracle.com> <56CF1B0A.2030603@oracle.com> <56D069FB.4050503@oracle.com> <56D07546.4010906@oracle.com> <56E8345F.4040006@oracle.com> <56F17347.90102@oracle.com> <56F18092.20300@oracle.com> <56F265FC.9090807@oracle.com> <56F3C92C.2010207@oracle.com> <56F4215A.6040506@oracle.com> <56F52E4B.4040208@oracle.com> Message-ID: <56F52EA2.3000506@oracle.com> Thanks! On 3/25/2016 3:25 PM, Sergey Bylokhov wrote: > +1 > > On 24.03.16 20:18, Alexander Stepanov wrote: >> Hello Sergey, >> >> Sorry, could you please look at the new test once more? >> >> the following lines >> 124 // some type checks: avoid IO exceptions >> 125 >> 126 if ((format.equals("jpeg") || format.equals("bmp")) && >> 127 pair.contains("USHORT_GRAY")) { >> 128 return; >> 129 } >> 130 >> 131 if (format.equals("bmp") && >> 132 (pair.contains("ARGB") || pair.contains("ABGR"))) { >> 133 return; >> 134 } >> >> were replaced with >> 124 // some type checks: avoid IO exceptions >> 125 if ((format.equals("jpeg") || format.equals("bmp")) && >> 126 (pair.contains("USHORT_GRAY") || >> 127 pair.contains("ARGB") || pair.contains("ABGR"))) { >> 128 return; >> 129 } >> >> to make possible to run the test with OpenJDK (didn't check that >> initially). >> >> Thanks, >> Alexander >> >> On 3/24/2016 2:02 PM, Sergey Bylokhov wrote: >>> Looks fine to me. >>> >>> On 23.03.16 12:46, Alexander Stepanov wrote: >>>> Hello, Sergey, >>>> >>>> > Should we also test bmp and jpg? >>>> covered as well >>>> >>>> > all of them have a white color and same size >>>> for the 2nd version the images used for the 1st and 2nd checks have >>>> different sizes and colors >>>> >>>> Thanks, >>>> Alexander >>>> >>>> >>>> On 3/22/2016 8:27 PM, Sergey Bylokhov wrote: >>>>> On 22.03.16 19:31, Alexander Stepanov wrote: >>>>>> Sorry, just a reminder. >>>>> >>>>> Can you provide an information what was changed in this version? >>>>> >>>>>> >>>>>> Thanks, >>>>>> Alexander >>>>>> >>>>>> On 3/15/2016 7:12 PM, Alexander Stepanov wrote: >>>>>>> Please see the updated fix: >>>>>>> http://cr.openjdk.java.net/~avstepan/8149558/webrev.01/ >>>>>>> >>>>>>> Thanks, >>>>>>> Alexander >>>>>>> >>>>>>> On 2/26/2016 6:54 PM, Alexander Stepanov wrote: >>>>>>>> > Should we also test bmp and jpg? >>>>>>>> >>>>>>>> couldn't use writer for these formats "as is" (simply >>>>>>>> "writer.write(img)") - this causes IOExceptions. >>>>>>>> JPEGImageWriteParam >>>>>>>> or BMPImageWriteParam should be used and another signature for >>>>>>>> write() method. Extended test logic looks quite bulky with all >>>>>>>> this >>>>>>>> additions. >>>>>>>> >>>>>>>> > but you do not check that the saved information actually >>>>>>>> relates to >>>>>>>> the particular image (all of them have a white color and same >>>>>>>> size) >>>>>>>> >>>>>>>> even in this case we have color check failure for pair >>>>>>>> (TYPE_USHORT_565_RGB, TYPE_USHORT_555_RGB). but yes, probably >>>>>>>> it is >>>>>>>> better to use different images for the 1st and 2nd write attempts. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexander >>>>>>>> >>>>>>>> On 2/26/2016 6:06 PM, Sergey Bylokhov wrote: >>>>>>>>> Should we also test bmp and jpg? You tested a different BI >>>>>>>>> formats, >>>>>>>>> but you do not check that the saved information actually >>>>>>>>> relates to >>>>>>>>> the particular image(all of them have a white color and same >>>>>>>>> size). >>>>>>>>> So you will not notice if the Writer will write the same(first) >>>>>>>>> image in all subsequent calls. >>>>>>>>> >>>>>>>>> On 25.02.16 18:17, Alexander Stepanov wrote: >>>>>>>>>> Sorry, just a reminder. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexander >>>>>>>>>> >>>>>>>>>> On 2/12/2016 1:35 PM, Alexander Stepanov wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> Could you please review the following fix >>>>>>>>>>> http://cr.openjdk.java.net/~avstepan/8149558/webrev.00/ >>>>>>>>>>> for >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8149558 >>>>>>>>>>> >>>>>>>>>>> Just a single regression test added (still failing), plus minor >>>>>>>>>>> correction for other test. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexander >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From alexander.v.stepanov at oracle.com Fri Mar 25 15:46:30 2016 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Fri, 25 Mar 2016 18:46:30 +0300 Subject: [OpenJDK 2D-Dev] RFR 8149028: [TEST] add test for TIFFDirectory Message-ID: <56F55D56.4090408@oracle.com> Hello, Could you please review the following fix http://cr.openjdk.java.net/~avstepan/8149028/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8149028 Just a single test added. Thanks, Alexander From philip.race at oracle.com Fri Mar 25 17:56:43 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 25 Mar 2016 10:56:43 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8146324: Add sun.font.FontUtilities.isComplexCharCode or related method to public API In-Reply-To: <56F47166.3000303@oracle.com> References: <56F45933.2030705@oracle.com> <56F45E34.4030806@oracle.com> <56F4689E.5090802@oracle.com> <56F47166.3000303@oracle.com> Message-ID: <56F57BDB.1020905@oracle.com> After a hallway conversation I have decided to change it to NPE. Not that I think it matters greatly either way since I don't think developers will be passing null to this method anyway :-) The test is changed to match .. http://cr.openjdk.java.net/~prr/8146324.1 -phil. On 03/24/2016 03:59 PM, Sergey Bylokhov wrote: > On 25.03.16 1:22, Phil Race wrote: >> That is true .. although I think I have previously been convinced >> that IAE >> is generally the better choice for such a case, I found only deriveFont >> that throws IAE for null in this file. > > deriveFont were changed(NPE to IAE) in 2001, but other methods and the > new code still use NPE. I think that in the most cases the null is not > taken into account and the specification is updated later(like the new > createFonts()). > >> So the question is whether to be consistent or to start picking the >> better option. >> So if there were no existing IAEs or NPEs in this file, which would you >> choose now ? > > Personally I always use NPE for null(via Objects.requireNonNull(...)). > and IAE for other incorrect arguments/types. or if the file(or the > same method) uses IAE already for null. As an example I use > System.getProperty(String). > > But in Font.java we specify NPE for a few methods already, some other > methods throw NPE but w/o specification(except deriveFont...) > >> >> -phil. >> >> On 03/24/2016 02:37 PM, Sergey Bylokhov wrote: >>> Hi, Phil. >>> Should this new method throw IAE? It seems that NPE can be thrown >>> instead, At least other methods in Font.java including the newly added >>> createFonts() throw NPE. >>> >>> On 25.03.16 0:16, Phil Race wrote: >>>> bug : https://bugs.openjdk.java.net/browse/JDK-8146324 >>>> fix : http://cr.openjdk.java.net/~prr/8146324/ >>>> >>>> Developers have used an internal API to detect when TextLayout or >>>> GlyphVector.layoutGlyphVectorwill be needed since that is a slower >>>> path. >>>> >>>> This provides a public equivalent capability. >>>> >>>> I have included a test which checks the assertions of the API. >>>> >>>> A CCC will be filed. >>>> >>>> -phil. >>> >>> >> > > From Sergey.Bylokhov at oracle.com Fri Mar 25 18:31:06 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 25 Mar 2016 21:31:06 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8146324: Add sun.font.FontUtilities.isComplexCharCode or related method to public API In-Reply-To: <56F57BDB.1020905@oracle.com> References: <56F45933.2030705@oracle.com> <56F45E34.4030806@oracle.com> <56F4689E.5090802@oracle.com> <56F47166.3000303@oracle.com> <56F57BDB.1020905@oracle.com> Message-ID: <56F583EA.8080402@oracle.com> Looks fine. On 25.03.16 20:56, Phil Race wrote: > After a hallway conversation I have decided to change it to NPE. > Not that I think it matters greatly either way since I don't think > developers will be passing null to this method anyway :-) > > The test is changed to match .. > > http://cr.openjdk.java.net/~prr/8146324.1 > > -phil. > > On 03/24/2016 03:59 PM, Sergey Bylokhov wrote: >> On 25.03.16 1:22, Phil Race wrote: >>> That is true .. although I think I have previously been convinced >>> that IAE >>> is generally the better choice for such a case, I found only deriveFont >>> that throws IAE for null in this file. >> >> deriveFont were changed(NPE to IAE) in 2001, but other methods and the >> new code still use NPE. I think that in the most cases the null is not >> taken into account and the specification is updated later(like the new >> createFonts()). >> >>> So the question is whether to be consistent or to start picking the >>> better option. >>> So if there were no existing IAEs or NPEs in this file, which would you >>> choose now ? >> >> Personally I always use NPE for null(via Objects.requireNonNull(...)). >> and IAE for other incorrect arguments/types. or if the file(or the >> same method) uses IAE already for null. As an example I use >> System.getProperty(String). >> >> But in Font.java we specify NPE for a few methods already, some other >> methods throw NPE but w/o specification(except deriveFont...) >> >>> >>> -phil. >>> >>> On 03/24/2016 02:37 PM, Sergey Bylokhov wrote: >>>> Hi, Phil. >>>> Should this new method throw IAE? It seems that NPE can be thrown >>>> instead, At least other methods in Font.java including the newly added >>>> createFonts() throw NPE. >>>> >>>> On 25.03.16 0:16, Phil Race wrote: >>>>> bug : https://bugs.openjdk.java.net/browse/JDK-8146324 >>>>> fix : http://cr.openjdk.java.net/~prr/8146324/ >>>>> >>>>> Developers have used an internal API to detect when TextLayout or >>>>> GlyphVector.layoutGlyphVectorwill be needed since that is a slower >>>>> path. >>>>> >>>>> This provides a public equivalent capability. >>>>> >>>>> I have included a test which checks the assertions of the API. >>>>> >>>>> A CCC will be filed. >>>>> >>>>> -phil. >>>> >>>> >>> >> >> > -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Fri Mar 25 18:35:16 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Fri, 25 Mar 2016 11:35:16 -0700 Subject: [OpenJDK 2D-Dev] [9] Review request for 8142966 Wrong cursor position in text components on HiDPI display In-Reply-To: <56F43188.7030801@oracle.com> References: <56A935F0.5060504@oracle.com> <56B4FA69.9000604@oracle.com> <56B6112F.1050708@oracle.com> <56B8E930.9000405@oracle.com> <56B9FC1F.9090607@oracle.com> <56B9FE27.4040204@oracle.com> <56BE3D82.5010506@oracle.com> <56E01A59.8070604@oracle.com> <56F43188.7030801@oracle.com> Message-ID: <56F584E4.3090103@oracle.com> On 3/24/2016 11:27 AM, Phil Race wrote: > > I am not sure developers on OS X have the same history of expectation > that metrics will not be changed but I think they may find it harder to > spot there anyway because the rendering on OS X does not use hinting > but it is an issue everywhere else. > So pointing to a similar change on OS X doesn't help. > The question is if you take a "low-dpi" display and draw a variety of > the same long > strings before and after the fix, with a variety of fonts, > is there any case where they measure any differently. > I think there must be if you throw away the hinted advances. > Note that the most important case is Windows, not Linux, and > you need to look at T2K not just freetype. I generated difference for all fonts from local graphics environment with size 12 between jdk with and without the fix for "low-dpi" display. Results are in file [1] with simple format: ------------------------ Font: java.awt.Font[family=Aharoni,name=Aharoni Bold,style=plain,size=12] [upper text width: 305] [upper text width: 306] [long text width: 553] [long text width: 554] [char [A] = 8] [char [A] = 9] Font: java.awt.Font[family=Andalus,name=Andalus,style=plain,size=12] [lower text width: 222] [lower text width: 220] [upper text width: 279] [upper text width: 275] [long text width: 501] [long text width: 495] [char [t] = 4] [char [t] = 3] [char [B] = 7] [char [B] = 6] [char [J] = 4] [char [J] = 3] [char [R] = 7] [char [R] = 6] ------------------------ Where lower text width is width of the text "the quick brown fox jumps over the lazy dog", upper text width is width of the same text with upper case and long text is sum of these both texts. 166 fonts out of 362 have difference. Links [2] and [3] contains some images with difference between drawn text before and after the fix. The text on the top is text before the fix, the text on the bottom is text after the fix and text between them shows the difference by red color. [1] http://cr.openjdk.java.net/~alexsch/8142966/font-size-diff/font-size-diff_00.txt [2] http://cr.openjdk.java.net/~alexsch/8142966/diff-images.00/low-case [3] http://cr.openjdk.java.net/~alexsch/8142966/diff-images.00/upper-case Thanks, Alexandr. > > -phil. > > On 03/09/2016 04:43 AM, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the proposed fix? >> >> Thanks, >> Alexandr. >> >> On 13/02/16 00:16, Alexander Scherbatiy wrote: >>> On 09/02/16 18:56, Sergey Bylokhov wrote: >>>> Also probably it will be possible to test this via the public api >>>> only(using the mix of the graphics transform + font transform). >>>> >>>> On 09.02.16 17:47, Sergey Bylokhov wrote: >>>>> Some additional information. >>>>> The Swing calculates the size of the components and location of the >>>>> cursor based on the text metrics. And these text metrics based on >>>>> advance. The Swing do not know to what destination it will be >>>>> painted, >>>>> it calculates the size based on the non-scaled(non-retina) >>>>> destination. >>>>> The problem occurs when we paint such component to the hidpi screen, >>>>> because we get small round errors per glyph -> this causes a visible >>>>> issue? when the text string is long. As a solution on the macosx the >>>>> round operation was done in the users space instead of dev space. >>>>> >>>>> For example before the fix the size 1.4px was rounded to 3 (1.4 * 2 = >>>>> 2.8 -> 3), but after the fix it will be 2 (1.4-> 1 * 2 = 2). So the >>>>> Swing will be able to calculate correct size/location without >>>>> information of the device scale. Note that the 3px(in dev space) is a >>>>> kind of fractional coordinate in the user space(1.5). And the >>>>> Swing does >>>>> not work properly when fractional metrics are used, because it use >>>>> ints >>>>> as a coordinates. >>>>> >>>>> Note that the fix should be applied only when fractional metrics >>>>> is off, >>>>> otherwise we should not use any rounding. I am not sure that the >>>>> current >>>>> fix take it into account. >>> The proposed fix is applied only when the fractional metrics are off. >>>>> >>>>> >>>>> On 08.02.16 22:14, Jim Graham wrote: >>>>>> Isn't the problem there that we are returning an integer as the >>>>>> advance? >>>>>> Why aren't we returning 7.35 as a value instead of 8? >>> 7.35 is returned when fractional metrics are on. >>>>>> >>>>>> Also, shouldn't 7.35 round to 7 and 14.7 round to 15? >>> This happens because when fractional metrics are on the glyph >>> linearAdvance value is returned (for current case >>> ftglyph->linearHoriAdvance = 7.35). >>> But when fractional metrics are off the glyph advance is returned >>> (ftglyph->advance.x = 8). >>> This calculation is done by freetype library. >>> >>> Thanks, >>> Alexandr. >>> >>>>>> >>>>>> ...jim >>>>>> >>>>>> On 2/6/2016 7:28 AM, Alexander Scherbatiy wrote: >>>>>>> On 05/02/16 23:39, Phil Race wrote: >>>>>>>> Two things strike me when I read this >>>>>>>> >>>>>>>> 1) Initial surprise at how deep into the font code it goes. >>>>>>>> Perhaps there are alternatives. >>>>>>>> >>>>>>>> 2) That it changes to using the linear metrics for measuring >>>>>>>> advance. >>>>>>>> Regardless of (1) I do not think (2) is correct. I am fairly >>>>>>>> sure this >>>>>>>> will lead to changes in text advance. It seems like it must throw >>>>>>>> away adjusted metrics as a result of glyph hinting. >>>>>>>> >>>>>>>> I don't know what the fix should be, since I have not looked at >>>>>>>> the >>>>>>>> problem top-down, I am just seeing the bottom-up proposed >>>>>>>> solution. >>>>>>>> So all I can say for now is that it needs to be at least somewhat >>>>>>>> different. >>>>>>> >>>>>>> There was the same issue on Mac OS X which has been fixed in the >>>>>>> similar way: >>>>>>> 8013569 [macosx] JLabel preferred size incorrect on retina >>>>>>> displays >>>>>>> with non-default font size >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8013569 >>>>>>> http://cr.openjdk.java.net/~serb/7190349/webrev.04/ >>>>>>> >>>>>>> The problem is that in many case for UI scale 2 we return to >>>>>>> a user >>>>>>> an unscaled value. >>>>>>> But a value for transformed glyph advance, rounded and >>>>>>> descaled can >>>>>>> differ from just rounded glyph advance. >>>>>>> >>>>>>> For example, font[dialog, plain, 12] char 'a': >>>>>>> transform: 12, advance: 7.35, rounded advance: 8 >>>>>>> transform: 24, advance: 14.70 round advance: 14 >>>>>>> >>>>>>> and 8 does not equal 14 / 2. >>>>>>> >>>>>>> The solution for Mac OS X was to get the glyph advance using >>>>>>> only >>>>>>> font transform, round it and then apply the dev transform: >>>>>>> >>>>>>> CGGlyphImages.m: >>>>>>> 481 advance = CGSizeApplyAffineTransform(advance, >>>>>>> strike->fFontTx); >>>>>>> 482 if (!JRSFontStyleUsesFractionalMetrics(strike->fStyle)) { >>>>>>> 483 advance.width = round(advance.width); >>>>>>> 484 advance.height = round(advance.height); >>>>>>> 485 } >>>>>>> 486 advance = CGSizeApplyAffineTransform(advance, >>>>>>> strike->fDevTx); >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> On 01/27/2016 01:26 PM, Alexander Scherbatiy wrote: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Could you review the fix: >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8142966 >>>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8142966/webev.00/ >>>>>>>>> >>>>>>>>> The proposed fix rounds a glyph advance first and then scales >>>>>>>>> it if >>>>>>>>> UI scales do not equal to one. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>>> >>>> >>>> >>> >> > From Sergey.Bylokhov at oracle.com Fri Mar 25 21:29:22 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sat, 26 Mar 2016 00:29:22 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8142966 Wrong cursor position in text components on HiDPI display In-Reply-To: <56F584E4.3090103@oracle.com> References: <56A935F0.5060504@oracle.com> <56B4FA69.9000604@oracle.com> <56B6112F.1050708@oracle.com> <56B8E930.9000405@oracle.com> <56B9FC1F.9090607@oracle.com> <56B9FE27.4040204@oracle.com> <56BE3D82.5010506@oracle.com> <56E01A59.8070604@oracle.com> <56F43188.7030801@oracle.com> <56F584E4.3090103@oracle.com> Message-ID: <56F5ADB2.8000909@oracle.com> On 25.03.16 21:35, Alexandr Scherbatiy wrote: > > I generated difference for all fonts from local graphics environment > with size 12 between jdk with and without the fix for "low-dpi" display. > Results are in file [1] with simple format: It will be useful to check the difference when the FontMetrics are ON. > ------------------------ > Font: java.awt.Font[family=Aharoni,name=Aharoni Bold,style=plain,size=12] > [upper text width: 305] [upper text width: 306] > [long text width: 553] [long text width: 554] > [char [A] = 8] [char [A] = 9] > > Font: java.awt.Font[family=Andalus,name=Andalus,style=plain,size=12] > [lower text width: 222] [lower text width: 220] > [upper text width: 279] [upper text width: 275] > [long text width: 501] [long text width: 495] > [char [t] = 4] [char [t] = 3] > [char [B] = 7] [char [B] = 6] > [char [J] = 4] [char [J] = 3] > [char [R] = 7] [char [R] = 6] > ------------------------ > > Where lower text width is width of the text "the quick brown fox > jumps over the lazy dog", upper text width is width of the same text > with upper case and long text is sum of these both texts. > > 166 fonts out of 362 have difference. > > Links [2] and [3] contains some images with difference between drawn > text before and after the fix. The text on the top is text before the > fix, the text on the bottom is text after the fix and text between them > shows the difference by red color. > > [1] > http://cr.openjdk.java.net/~alexsch/8142966/font-size-diff/font-size-diff_00.txt > > [2] http://cr.openjdk.java.net/~alexsch/8142966/diff-images.00/low-case > [3] > http://cr.openjdk.java.net/~alexsch/8142966/diff-images.00/upper-case > > Thanks, > Alexandr. >> >> -phil. >> >> On 03/09/2016 04:43 AM, Alexander Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the proposed fix? >>> >>> Thanks, >>> Alexandr. >>> >>> On 13/02/16 00:16, Alexander Scherbatiy wrote: >>>> On 09/02/16 18:56, Sergey Bylokhov wrote: >>>>> Also probably it will be possible to test this via the public api >>>>> only(using the mix of the graphics transform + font transform). >>>>> >>>>> On 09.02.16 17:47, Sergey Bylokhov wrote: >>>>>> Some additional information. >>>>>> The Swing calculates the size of the components and location of the >>>>>> cursor based on the text metrics. And these text metrics based on >>>>>> advance. The Swing do not know to what destination it will be >>>>>> painted, >>>>>> it calculates the size based on the non-scaled(non-retina) >>>>>> destination. >>>>>> The problem occurs when we paint such component to the hidpi screen, >>>>>> because we get small round errors per glyph -> this causes a visible >>>>>> issue? when the text string is long. As a solution on the macosx the >>>>>> round operation was done in the users space instead of dev space. >>>>>> >>>>>> For example before the fix the size 1.4px was rounded to 3 (1.4 * 2 = >>>>>> 2.8 -> 3), but after the fix it will be 2 (1.4-> 1 * 2 = 2). So the >>>>>> Swing will be able to calculate correct size/location without >>>>>> information of the device scale. Note that the 3px(in dev space) is a >>>>>> kind of fractional coordinate in the user space(1.5). And the >>>>>> Swing does >>>>>> not work properly when fractional metrics are used, because it use >>>>>> ints >>>>>> as a coordinates. >>>>>> >>>>>> Note that the fix should be applied only when fractional metrics >>>>>> is off, >>>>>> otherwise we should not use any rounding. I am not sure that the >>>>>> current >>>>>> fix take it into account. >>>> The proposed fix is applied only when the fractional metrics are off. >>>>>> >>>>>> >>>>>> On 08.02.16 22:14, Jim Graham wrote: >>>>>>> Isn't the problem there that we are returning an integer as the >>>>>>> advance? >>>>>>> Why aren't we returning 7.35 as a value instead of 8? >>>> 7.35 is returned when fractional metrics are on. >>>>>>> >>>>>>> Also, shouldn't 7.35 round to 7 and 14.7 round to 15? >>>> This happens because when fractional metrics are on the glyph >>>> linearAdvance value is returned (for current case >>>> ftglyph->linearHoriAdvance = 7.35). >>>> But when fractional metrics are off the glyph advance is returned >>>> (ftglyph->advance.x = 8). >>>> This calculation is done by freetype library. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>>>> >>>>>>> ...jim >>>>>>> >>>>>>> On 2/6/2016 7:28 AM, Alexander Scherbatiy wrote: >>>>>>>> On 05/02/16 23:39, Phil Race wrote: >>>>>>>>> Two things strike me when I read this >>>>>>>>> >>>>>>>>> 1) Initial surprise at how deep into the font code it goes. >>>>>>>>> Perhaps there are alternatives. >>>>>>>>> >>>>>>>>> 2) That it changes to using the linear metrics for measuring >>>>>>>>> advance. >>>>>>>>> Regardless of (1) I do not think (2) is correct. I am fairly >>>>>>>>> sure this >>>>>>>>> will lead to changes in text advance. It seems like it must throw >>>>>>>>> away adjusted metrics as a result of glyph hinting. >>>>>>>>> >>>>>>>>> I don't know what the fix should be, since I have not looked at >>>>>>>>> the >>>>>>>>> problem top-down, I am just seeing the bottom-up proposed >>>>>>>>> solution. >>>>>>>>> So all I can say for now is that it needs to be at least somewhat >>>>>>>>> different. >>>>>>>> >>>>>>>> There was the same issue on Mac OS X which has been fixed in the >>>>>>>> similar way: >>>>>>>> 8013569 [macosx] JLabel preferred size incorrect on retina >>>>>>>> displays >>>>>>>> with non-default font size >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8013569 >>>>>>>> http://cr.openjdk.java.net/~serb/7190349/webrev.04/ >>>>>>>> >>>>>>>> The problem is that in many case for UI scale 2 we return to >>>>>>>> a user >>>>>>>> an unscaled value. >>>>>>>> But a value for transformed glyph advance, rounded and >>>>>>>> descaled can >>>>>>>> differ from just rounded glyph advance. >>>>>>>> >>>>>>>> For example, font[dialog, plain, 12] char 'a': >>>>>>>> transform: 12, advance: 7.35, rounded advance: 8 >>>>>>>> transform: 24, advance: 14.70 round advance: 14 >>>>>>>> >>>>>>>> and 8 does not equal 14 / 2. >>>>>>>> >>>>>>>> The solution for Mac OS X was to get the glyph advance using >>>>>>>> only >>>>>>>> font transform, round it and then apply the dev transform: >>>>>>>> >>>>>>>> CGGlyphImages.m: >>>>>>>> 481 advance = CGSizeApplyAffineTransform(advance, >>>>>>>> strike->fFontTx); >>>>>>>> 482 if (!JRSFontStyleUsesFractionalMetrics(strike->fStyle)) { >>>>>>>> 483 advance.width = round(advance.width); >>>>>>>> 484 advance.height = round(advance.height); >>>>>>>> 485 } >>>>>>>> 486 advance = CGSizeApplyAffineTransform(advance, >>>>>>>> strike->fDevTx); >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> -phil. >>>>>>>>> >>>>>>>>> On 01/27/2016 01:26 PM, Alexander Scherbatiy wrote: >>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Could you review the fix: >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8142966 >>>>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8142966/webev.00/ >>>>>>>>>> >>>>>>>>>> The proposed fix rounds a glyph advance first and then scales >>>>>>>>>> it if >>>>>>>>>> UI scales do not equal to one. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> > -- Best regards, Sergey. From philip.race at oracle.com Fri Mar 25 21:53:39 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 25 Mar 2016 14:53:39 -0700 Subject: [OpenJDK 2D-Dev] [9] Review request for 8142966 Wrong cursor position in text components on HiDPI display In-Reply-To: <56F5ADB2.8000909@oracle.com> References: <56A935F0.5060504@oracle.com> <56B4FA69.9000604@oracle.com> <56B6112F.1050708@oracle.com> <56B8E930.9000405@oracle.com> <56B9FC1F.9090607@oracle.com> <56B9FE27.4040204@oracle.com> <56BE3D82.5010506@oracle.com> <56E01A59.8070604@oracle.com> <56F43188.7030801@oracle.com> <56F584E4.3090103@oracle.com> <56F5ADB2.8000909@oracle.com> Message-ID: <56F5B363.8080903@oracle.com> On 3/25/2016 2:29 PM, Sergey Bylokhov wrote: > On 25.03.16 21:35, Alexandr Scherbatiy wrote: >> >> I generated difference for all fonts from local graphics environment >> with size 12 between jdk with and without the fix for "low-dpi" display. >> Results are in file [1] with simple format: > > It will be useful to check the difference when the FontMetrics are ON. > Do you mean FRACTIONALMETRICS=ON ? I think that the difference in that case could (or should) be zero. But FM_OFF is the important case for normal Swing-type text so the differences seen appear to be demonstrating what I am concerned about. -phil. >> ------------------------ >> Font: java.awt.Font[family=Aharoni,name=Aharoni >> Bold,style=plain,size=12] >> [upper text width: 305] [upper text width: 306] >> [long text width: 553] [long text width: 554] >> [char [A] = 8] [char [A] = 9] >> >> Font: java.awt.Font[family=Andalus,name=Andalus,style=plain,size=12] >> [lower text width: 222] [lower text width: 220] >> [upper text width: 279] [upper text width: 275] >> [long text width: 501] [long text width: 495] >> [char [t] = 4] [char [t] = 3] >> [char [B] = 7] [char [B] = 6] >> [char [J] = 4] [char [J] = 3] >> [char [R] = 7] [char [R] = 6] >> ------------------------ >> >> Where lower text width is width of the text "the quick brown fox >> jumps over the lazy dog", upper text width is width of the same text >> with upper case and long text is sum of these both texts. >> >> 166 fonts out of 362 have difference. >> >> Links [2] and [3] contains some images with difference between drawn >> text before and after the fix. The text on the top is text before the >> fix, the text on the bottom is text after the fix and text between them >> shows the difference by red color. >> >> [1] >> http://cr.openjdk.java.net/~alexsch/8142966/font-size-diff/font-size-diff_00.txt >> >> >> [2] >> http://cr.openjdk.java.net/~alexsch/8142966/diff-images.00/low-case >> [3] >> http://cr.openjdk.java.net/~alexsch/8142966/diff-images.00/upper-case >> >> Thanks, >> Alexandr. >>> >>> -phil. >>> >>> On 03/09/2016 04:43 AM, Alexander Scherbatiy wrote: >>>> >>>> Hello, >>>> >>>> Could you review the proposed fix? >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 13/02/16 00:16, Alexander Scherbatiy wrote: >>>>> On 09/02/16 18:56, Sergey Bylokhov wrote: >>>>>> Also probably it will be possible to test this via the public api >>>>>> only(using the mix of the graphics transform + font transform). >>>>>> >>>>>> On 09.02.16 17:47, Sergey Bylokhov wrote: >>>>>>> Some additional information. >>>>>>> The Swing calculates the size of the components and location >>>>>>> of the >>>>>>> cursor based on the text metrics. And these text metrics based on >>>>>>> advance. The Swing do not know to what destination it will be >>>>>>> painted, >>>>>>> it calculates the size based on the non-scaled(non-retina) >>>>>>> destination. >>>>>>> The problem occurs when we paint such component to the hidpi >>>>>>> screen, >>>>>>> because we get small round errors per glyph -> this causes a >>>>>>> visible >>>>>>> issue? when the text string is long. As a solution on the macosx >>>>>>> the >>>>>>> round operation was done in the users space instead of dev space. >>>>>>> >>>>>>> For example before the fix the size 1.4px was rounded to 3 (1.4 >>>>>>> * 2 = >>>>>>> 2.8 -> 3), but after the fix it will be 2 (1.4-> 1 * 2 = 2). So the >>>>>>> Swing will be able to calculate correct size/location without >>>>>>> information of the device scale. Note that the 3px(in dev space) >>>>>>> is a >>>>>>> kind of fractional coordinate in the user space(1.5). And the >>>>>>> Swing does >>>>>>> not work properly when fractional metrics are used, because it use >>>>>>> ints >>>>>>> as a coordinates. >>>>>>> >>>>>>> Note that the fix should be applied only when fractional metrics >>>>>>> is off, >>>>>>> otherwise we should not use any rounding. I am not sure that the >>>>>>> current >>>>>>> fix take it into account. >>>>> The proposed fix is applied only when the fractional metrics are >>>>> off. >>>>>>> >>>>>>> >>>>>>> On 08.02.16 22:14, Jim Graham wrote: >>>>>>>> Isn't the problem there that we are returning an integer as the >>>>>>>> advance? >>>>>>>> Why aren't we returning 7.35 as a value instead of 8? >>>>> 7.35 is returned when fractional metrics are on. >>>>>>>> >>>>>>>> Also, shouldn't 7.35 round to 7 and 14.7 round to 15? >>>>> This happens because when fractional metrics are on the glyph >>>>> linearAdvance value is returned (for current case >>>>> ftglyph->linearHoriAdvance = 7.35). >>>>> But when fractional metrics are off the glyph advance is returned >>>>> (ftglyph->advance.x = 8). >>>>> This calculation is done by freetype library. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>>>>> >>>>>>>> ...jim >>>>>>>> >>>>>>>> On 2/6/2016 7:28 AM, Alexander Scherbatiy wrote: >>>>>>>>> On 05/02/16 23:39, Phil Race wrote: >>>>>>>>>> Two things strike me when I read this >>>>>>>>>> >>>>>>>>>> 1) Initial surprise at how deep into the font code it goes. >>>>>>>>>> Perhaps there are alternatives. >>>>>>>>>> >>>>>>>>>> 2) That it changes to using the linear metrics for measuring >>>>>>>>>> advance. >>>>>>>>>> Regardless of (1) I do not think (2) is correct. I am fairly >>>>>>>>>> sure this >>>>>>>>>> will lead to changes in text advance. It seems like it must >>>>>>>>>> throw >>>>>>>>>> away adjusted metrics as a result of glyph hinting. >>>>>>>>>> >>>>>>>>>> I don't know what the fix should be, since I have not looked at >>>>>>>>>> the >>>>>>>>>> problem top-down, I am just seeing the bottom-up proposed >>>>>>>>>> solution. >>>>>>>>>> So all I can say for now is that it needs to be at least >>>>>>>>>> somewhat >>>>>>>>>> different. >>>>>>>>> >>>>>>>>> There was the same issue on Mac OS X which has been fixed >>>>>>>>> in the >>>>>>>>> similar way: >>>>>>>>> 8013569 [macosx] JLabel preferred size incorrect on retina >>>>>>>>> displays >>>>>>>>> with non-default font size >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8013569 >>>>>>>>> http://cr.openjdk.java.net/~serb/7190349/webrev.04/ >>>>>>>>> >>>>>>>>> The problem is that in many case for UI scale 2 we return to >>>>>>>>> a user >>>>>>>>> an unscaled value. >>>>>>>>> But a value for transformed glyph advance, rounded and >>>>>>>>> descaled can >>>>>>>>> differ from just rounded glyph advance. >>>>>>>>> >>>>>>>>> For example, font[dialog, plain, 12] char 'a': >>>>>>>>> transform: 12, advance: 7.35, rounded advance: 8 >>>>>>>>> transform: 24, advance: 14.70 round advance: 14 >>>>>>>>> >>>>>>>>> and 8 does not equal 14 / 2. >>>>>>>>> >>>>>>>>> The solution for Mac OS X was to get the glyph advance using >>>>>>>>> only >>>>>>>>> font transform, round it and then apply the dev transform: >>>>>>>>> >>>>>>>>> CGGlyphImages.m: >>>>>>>>> 481 advance = CGSizeApplyAffineTransform(advance, >>>>>>>>> strike->fFontTx); >>>>>>>>> 482 if >>>>>>>>> (!JRSFontStyleUsesFractionalMetrics(strike->fStyle)) { >>>>>>>>> 483 advance.width = round(advance.width); >>>>>>>>> 484 advance.height = round(advance.height); >>>>>>>>> 485 } >>>>>>>>> 486 advance = CGSizeApplyAffineTransform(advance, >>>>>>>>> strike->fDevTx); >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>> -phil. >>>>>>>>>> >>>>>>>>>> On 01/27/2016 01:26 PM, Alexander Scherbatiy wrote: >>>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> Could you review the fix: >>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8142966 >>>>>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8142966/webev.00/ >>>>>>>>>>> >>>>>>>>>>> The proposed fix rounds a glyph advance first and then scales >>>>>>>>>>> it if >>>>>>>>>>> UI scales do not equal to one. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > > From Sergey.Bylokhov at oracle.com Fri Mar 25 22:24:01 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sat, 26 Mar 2016 01:24:01 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8142966 Wrong cursor position in text components on HiDPI display In-Reply-To: <56F5B363.8080903@oracle.com> References: <56A935F0.5060504@oracle.com> <56B4FA69.9000604@oracle.com> <56B6112F.1050708@oracle.com> <56B8E930.9000405@oracle.com> <56B9FC1F.9090607@oracle.com> <56B9FE27.4040204@oracle.com> <56BE3D82.5010506@oracle.com> <56E01A59.8070604@oracle.com> <56F43188.7030801@oracle.com> <56F584E4.3090103@oracle.com> <56F5ADB2.8000909@oracle.com> <56F5B363.8080903@oracle.com> Message-ID: <56F5BA81.2000801@oracle.com> On 26.03.16 0:53, Phil Race wrote: > On 3/25/2016 2:29 PM, Sergey Bylokhov wrote: >> On 25.03.16 21:35, Alexandr Scherbatiy wrote: >>> >>> I generated difference for all fonts from local graphics environment >>> with size 12 between jdk with and without the fix for "low-dpi" display. >>> Results are in file [1] with simple format: >> >> It will be useful to check the difference when the FontMetrics are ON. >> > > Do you mean FRACTIONALMETRICS=ON ? Yes. > > I think that the difference in that case could (or should) be zero. I think so, but it will be good to check. > But FM_OFF is the important case for normal Swing-type text so > the differences seen appear to be demonstrating what I am concerned about. It depends on where this text is used, for example in a situation when the Swing will try to paint a selected words in the middle of text(like in the textfield): "the quick brown fox jumps over the lazy dog." Imagine "uick brown fo" should be selected and painted with a different background. In this situation the swing should start to paint after the "q" but before the "uick" uses integral coordinate in the userspace. If the real coordinate will be fractional then the selected text will be shifted(the selected text cannot be drawn in the same place as unselected). We also should take into account that the current big(?) difference can come from issues in the fix(like wrong round or incorrect assumptions somewhere.) > > -phil. > > > >>> ------------------------ >>> Font: java.awt.Font[family=Aharoni,name=Aharoni >>> Bold,style=plain,size=12] >>> [upper text width: 305] [upper text width: 306] >>> [long text width: 553] [long text width: 554] >>> [char [A] = 8] [char [A] = 9] >>> >>> Font: java.awt.Font[family=Andalus,name=Andalus,style=plain,size=12] >>> [lower text width: 222] [lower text width: 220] >>> [upper text width: 279] [upper text width: 275] >>> [long text width: 501] [long text width: 495] >>> [char [t] = 4] [char [t] = 3] >>> [char [B] = 7] [char [B] = 6] >>> [char [J] = 4] [char [J] = 3] >>> [char [R] = 7] [char [R] = 6] >>> ------------------------ >>> >>> Where lower text width is width of the text "the quick brown fox >>> jumps over the lazy dog", upper text width is width of the same text >>> with upper case and long text is sum of these both texts. >>> >>> 166 fonts out of 362 have difference. >>> >>> Links [2] and [3] contains some images with difference between drawn >>> text before and after the fix. The text on the top is text before the >>> fix, the text on the bottom is text after the fix and text between them >>> shows the difference by red color. >>> >>> [1] >>> http://cr.openjdk.java.net/~alexsch/8142966/font-size-diff/font-size-diff_00.txt >>> >>> >>> [2] >>> http://cr.openjdk.java.net/~alexsch/8142966/diff-images.00/low-case >>> [3] >>> http://cr.openjdk.java.net/~alexsch/8142966/diff-images.00/upper-case >>> >>> Thanks, >>> Alexandr. >>>> >>>> -phil. >>>> >>>> On 03/09/2016 04:43 AM, Alexander Scherbatiy wrote: >>>>> >>>>> Hello, >>>>> >>>>> Could you review the proposed fix? >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 13/02/16 00:16, Alexander Scherbatiy wrote: >>>>>> On 09/02/16 18:56, Sergey Bylokhov wrote: >>>>>>> Also probably it will be possible to test this via the public api >>>>>>> only(using the mix of the graphics transform + font transform). >>>>>>> >>>>>>> On 09.02.16 17:47, Sergey Bylokhov wrote: >>>>>>>> Some additional information. >>>>>>>> The Swing calculates the size of the components and location >>>>>>>> of the >>>>>>>> cursor based on the text metrics. And these text metrics based on >>>>>>>> advance. The Swing do not know to what destination it will be >>>>>>>> painted, >>>>>>>> it calculates the size based on the non-scaled(non-retina) >>>>>>>> destination. >>>>>>>> The problem occurs when we paint such component to the hidpi >>>>>>>> screen, >>>>>>>> because we get small round errors per glyph -> this causes a >>>>>>>> visible >>>>>>>> issue? when the text string is long. As a solution on the macosx >>>>>>>> the >>>>>>>> round operation was done in the users space instead of dev space. >>>>>>>> >>>>>>>> For example before the fix the size 1.4px was rounded to 3 (1.4 >>>>>>>> * 2 = >>>>>>>> 2.8 -> 3), but after the fix it will be 2 (1.4-> 1 * 2 = 2). So the >>>>>>>> Swing will be able to calculate correct size/location without >>>>>>>> information of the device scale. Note that the 3px(in dev space) >>>>>>>> is a >>>>>>>> kind of fractional coordinate in the user space(1.5). And the >>>>>>>> Swing does >>>>>>>> not work properly when fractional metrics are used, because it use >>>>>>>> ints >>>>>>>> as a coordinates. >>>>>>>> >>>>>>>> Note that the fix should be applied only when fractional metrics >>>>>>>> is off, >>>>>>>> otherwise we should not use any rounding. I am not sure that the >>>>>>>> current >>>>>>>> fix take it into account. >>>>>> The proposed fix is applied only when the fractional metrics are >>>>>> off. >>>>>>>> >>>>>>>> >>>>>>>> On 08.02.16 22:14, Jim Graham wrote: >>>>>>>>> Isn't the problem there that we are returning an integer as the >>>>>>>>> advance? >>>>>>>>> Why aren't we returning 7.35 as a value instead of 8? >>>>>> 7.35 is returned when fractional metrics are on. >>>>>>>>> >>>>>>>>> Also, shouldn't 7.35 round to 7 and 14.7 round to 15? >>>>>> This happens because when fractional metrics are on the glyph >>>>>> linearAdvance value is returned (for current case >>>>>> ftglyph->linearHoriAdvance = 7.35). >>>>>> But when fractional metrics are off the glyph advance is returned >>>>>> (ftglyph->advance.x = 8). >>>>>> This calculation is done by freetype library. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>>>>> >>>>>>>>> ...jim >>>>>>>>> >>>>>>>>> On 2/6/2016 7:28 AM, Alexander Scherbatiy wrote: >>>>>>>>>> On 05/02/16 23:39, Phil Race wrote: >>>>>>>>>>> Two things strike me when I read this >>>>>>>>>>> >>>>>>>>>>> 1) Initial surprise at how deep into the font code it goes. >>>>>>>>>>> Perhaps there are alternatives. >>>>>>>>>>> >>>>>>>>>>> 2) That it changes to using the linear metrics for measuring >>>>>>>>>>> advance. >>>>>>>>>>> Regardless of (1) I do not think (2) is correct. I am fairly >>>>>>>>>>> sure this >>>>>>>>>>> will lead to changes in text advance. It seems like it must >>>>>>>>>>> throw >>>>>>>>>>> away adjusted metrics as a result of glyph hinting. >>>>>>>>>>> >>>>>>>>>>> I don't know what the fix should be, since I have not looked at >>>>>>>>>>> the >>>>>>>>>>> problem top-down, I am just seeing the bottom-up proposed >>>>>>>>>>> solution. >>>>>>>>>>> So all I can say for now is that it needs to be at least >>>>>>>>>>> somewhat >>>>>>>>>>> different. >>>>>>>>>> >>>>>>>>>> There was the same issue on Mac OS X which has been fixed >>>>>>>>>> in the >>>>>>>>>> similar way: >>>>>>>>>> 8013569 [macosx] JLabel preferred size incorrect on retina >>>>>>>>>> displays >>>>>>>>>> with non-default font size >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8013569 >>>>>>>>>> http://cr.openjdk.java.net/~serb/7190349/webrev.04/ >>>>>>>>>> >>>>>>>>>> The problem is that in many case for UI scale 2 we return to >>>>>>>>>> a user >>>>>>>>>> an unscaled value. >>>>>>>>>> But a value for transformed glyph advance, rounded and >>>>>>>>>> descaled can >>>>>>>>>> differ from just rounded glyph advance. >>>>>>>>>> >>>>>>>>>> For example, font[dialog, plain, 12] char 'a': >>>>>>>>>> transform: 12, advance: 7.35, rounded advance: 8 >>>>>>>>>> transform: 24, advance: 14.70 round advance: 14 >>>>>>>>>> >>>>>>>>>> and 8 does not equal 14 / 2. >>>>>>>>>> >>>>>>>>>> The solution for Mac OS X was to get the glyph advance using >>>>>>>>>> only >>>>>>>>>> font transform, round it and then apply the dev transform: >>>>>>>>>> >>>>>>>>>> CGGlyphImages.m: >>>>>>>>>> 481 advance = CGSizeApplyAffineTransform(advance, >>>>>>>>>> strike->fFontTx); >>>>>>>>>> 482 if >>>>>>>>>> (!JRSFontStyleUsesFractionalMetrics(strike->fStyle)) { >>>>>>>>>> 483 advance.width = round(advance.width); >>>>>>>>>> 484 advance.height = round(advance.height); >>>>>>>>>> 485 } >>>>>>>>>> 486 advance = CGSizeApplyAffineTransform(advance, >>>>>>>>>> strike->fDevTx); >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>> -phil. >>>>>>>>>>> >>>>>>>>>>> On 01/27/2016 01:26 PM, Alexander Scherbatiy wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> Could you review the fix: >>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8142966 >>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8142966/webev.00/ >>>>>>>>>>>> >>>>>>>>>>>> The proposed fix rounds a glyph advance first and then scales >>>>>>>>>>>> it if >>>>>>>>>>>> UI scales do not equal to one. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> > -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Mon Mar 28 08:38:39 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Mon, 28 Mar 2016 14:08:39 +0530 Subject: [OpenJDK 2D-Dev] [9]: RFR JDK-6357905, , java.awt.JobAttributes.getFromPage() and getToPage() always returns "1". Message-ID: <56F8ED8F.6030007@oracle.com> Hi All, Please review a print job attribute fix for jdk9. Bug: https://bugs.openjdk.java.net/browse/JDK-6357905 webrev: http://cr.openjdk.java.net/~psadhukhan/6357905/webrev.00/ The issue was in the Print-dialog, when some pages are specified using "Pages" within "Page range", java.awt.JobAttributes.getFromPage() and getToPage() always returns "1" and not the values as updated by the user. The fix was to get the pageranges attribute as set by the user and obtain the from and to Page range and update the JobAttribute's from and to Page. Regards Prasanta From alexander.v.stepanov at oracle.com Mon Mar 28 10:07:04 2016 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Mon, 28 Mar 2016 13:07:04 +0300 Subject: [OpenJDK 2D-Dev] RFR 8152183: [TEST] add test for TIFFField In-Reply-To: <56F2A387.8070506@oracle.com> References: <56F2A387.8070506@oracle.com> Message-ID: <56F90248.7000609@oracle.com> Sorry, just a reminder. Thanks, Alexander On 3/23/2016 5:09 PM, Alexander Stepanov wrote: > Hello, > > Could you please review the following fix > http://cr.openjdk.java.net/~avstepan/8152183/webrev.00/ > for > https://bugs.openjdk.java.net/browse/JDK-8152183 > > Just a single test added. > > Thanks, > Alexander From ajit.ghaisas at oracle.com Mon Mar 28 10:18:32 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Mon, 28 Mar 2016 03:18:32 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception In-Reply-To: <56F334D3.5060106@oracle.com> References: <3969befd-57cd-48ee-bed5-173a28e7bd08@default> <56DFFC9F.4020403@oracle.com> <70f247c0-6f3e-472a-b7b0-b02814010e30@default> <56E16D0A.3060807@oracle.com> <56E1E2A5.1020008@oracle.com> <56F1C6F2.6000305@oracle.com> <56F1D0DB.9000508@oracle.com> <56F33180.8060408@oracle.com> <56F334D3.5060106@oracle.com> Message-ID: Hi, Thanks Jim for thorough review. Here is the updated webrev : http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.04/ In this update : 1) I have corrected missing space after casting 2) I have modified code to adapt suggested indentation for blocks having conditionals & method declaration split on multiple lines. Please note that, I have done indentation change only if it is related to the code changes done as part of this fix. The files in this review already have indentation issues and fixing all of them will result in multiple changes masking the actual code changes that fixes the reported issue. Request you to review the updated webrev. Regards, Ajit -----Original Message----- From: Jim Graham Sent: Thursday, March 24, 2016 5:59 AM To: Phil Race Cc: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception I should point out that this form I demonstrate below is only used when there are continuation lines on the prefix to the code block (conditionals, method declarations, loop controls, etc.), so: if (some simple condition) { ... } and: if (some complex condition && some additional condition) { ... } but, not: if (some single line condition) { // blech ... } The reason for this is that the standard indentation would recommend: if (some complex condition && some additional condition) { // code block } or void foomethod(int sx, int sy, int dx, int dy) { // code block } which may be more compact, but the lack of a breaking line means you have to vary the indentation of the declarations/conditionals and as a result they don't line up nicely which makes them harder to scan if they are all related (and frequently in graphics code you end up with a series of very similar arguments or conditionals that are more readable if they line up nicely), and the only indication of when the multiple lines of continued declaration/conditionals end and the body of the method begins is the number of spaces - noting that frequently the indentation on lines in practice is just wrong so this form makes it hard to distinguish between "that line is a continuation line" and "someone indented that line wrong"... ...jim On 3/23/16 5:14 PM, Jim Graham wrote: > For the record, in many places in the 2D code we also adopt a slight > extension of the indentation rules such that the below might be written as: > > public ByteBandedRaster(SampleModel sampleModel, > DataBufferByte dataBuffer, > Point origin) > { > // body lines of the method... > } > > with the open curly brace on the following line so that it more visually > points out the beginning of the body block of the method and it's easy > to find the start/end of the block by sighting down the left margin. The > official policy is for the "{" to be at the end of the previous line > after "Point origin) {" and as more new engineers work on the code and > follow the official rules, the above form becomes less common. (Sad > face since I particularly like the above form...) > > ...jim > > On 3/22/16 4:10 PM, Phil Race wrote: >> Ajit, >> >> There is also some odd indentation in ByteBandedRaster.java which is not >> yours but >> >> 98 public ByteBandedRaster(SampleModel sampleModel, >> 99 DataBufferByte dataBuffer, >> 100 Point origin) { >> >> >> This appears to be the result of someone using tabs a long time ago. >> >> Since you are touching the method signature lines anyway may be >> better fixed so we have these aligned >> >> public ByteBandedRaster(SampleModel sampleModel, >> DataBufferByte dataBuffer, >> Point origin) { >> >> [not sure if that will make it through mail as intended]. >> >> Here in Raster.java, the first condition now seems to be redundant .. >> 890 if (dataType == DataBuffer.TYPE_BYTE && >> 891 dataBuffer instanceof DataBufferByte && >> >> >> >> -phil. >> >> >> On 03/22/2016 03:28 PM, Jim Graham wrote: >>> Hi Ajit, >>> >>> Most of your if statements are spaced wrong. There should be a space >>> between "if" and the parentheses. I'll review more later, but I >>> noticed that issue in the first couple of files I looked at... >>> >>> ...jim >>> >>> On 3/15/16 7:05 AM, Ajit Ghaisas wrote: >>>> Hi, >>>> >>>> Thanks Sergey and Jim for suggestions. >>>> >>>> I have made the data specific Raster constructors type safe >>>> now. Also, I have modified all Raster creations in Raster.java to >>>> support custom DataBuffer classes. >>>> >>>> Please review the changes present in updated webrev : >>>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.02/ >>>> >>>> Regards, >>>> Ajit >>>> >>>> -----Original Message----- >>>> From: Jim Graham >>>> Sent: Friday, March 11, 2016 2:40 AM >>>> To: Sergey Bylokhov; Ajit Ghaisas; 2d-dev >>>> Subject: Re: [OpenJDK 2D-Dev] [9] Review-request for 6353518: >>>> Creation of a WritableRaster with a custom DataBuffer causes >>>> erroneous Exception >>>> >>>> Yes, those constructors should be type-safe. Perhaps that was done >>>> to save code in the caller, but that is a small price to pay to avoid >>>> errors in the future, and it makes sure there is a backup plan for >>>> different kinds of buffers... >>>> >>>> ...jim >>>> >>>> On 3/10/16 4:48 AM, Sergey Bylokhov wrote: >>>>> Hi, Ajit. >>>>> What about other cases in Raster.java, where the DataBuffer is passed >>>>> as a parameter? Probably we can simplify the code and find all such >>>>> issues if we changes the ByteInterleavedRaster/etc. For example: >>>>> >>>>> ByteInterleavedRaster(SampleModel sampleModel,DataBuffer >>>>> dataBuffer,...) to >>>>> >>>>> ByteInterleavedRaster(SampleModel sampleModel,DataBufferByte >>>>> dataBuffer,...) >>>>> >>>>> Because we throw an exception in such cases anyway: >>>>> >>>>> if (!(dataBuffer instanceof DataBufferByte)) { >>>>> throw new RasterFormatException("ByteInterleavedRasters must >>>>> have " >>>>> + "byte DataBuffers"); >>>>> } >>>>> >>>>> And the compiler will help us, what everybody think about it? >>>>> >>>>> On 09.03.16 17:38, Ajit Ghaisas wrote: >>>>>> Hi, >>>>>> >>>>>> Modified the test and added check for >>>>>> MultiPixelPackedSampleModel >>>>>> condition. >>>>>> >>>>>> Please review updated webrev : >>>>>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.01/ >>>>>> >>>>>> Regards, >>>>>> Ajit >>>>>> >>>>>> -----Original Message----- >>>>>> From: Sergey Bylokhov >>>>>> Sent: Wednesday, March 09, 2016 4:06 PM >>>>>> To: Ajit Ghaisas; awt-dev at openjdk.java.net; Semyon Sadetsky; Ambarish >>>>>> Rapte; 2d-dev >>>>>> Subject: Re: [9] Review-request for 6353518: Creation of a >>>>>> WritableRaster with a custom DataBuffer causes erroneous Exception >>>>>> >>>>>> Changes for 2d area.(cc) >>>>>> >>>>>> >>>>>> On 07.03.16 11:20, Ajit Ghaisas wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-6353518 >>>>>>> >>>>>>> Issue : (Text from bug description) >>>>>>> >>>>>>> An attempt to create a WritableRaster via >>>>>>> Raster.createWritableRaster(SampleModel sm, DataBuffer db, Point >>>>>>> location) using a custom DataBuffer causes an erroneous >>>>>>> RasterFormatException. >>>>>>> Apparently the reason for this bug is that IntegerComponentRaster >>>>>>> insists on being passed an instance of DataBufferInt rather than >>>>>>> just a DataBuffer with a DataType of TYPE_INT. >>>>>>> This is quite annoying since DataBufferInt is declared final and >>>>>>> thus cannot be extended. >>>>>>> >>>>>>> Fix : >>>>>>> >>>>>>> The last line of Raster.createWritableRaster() method already has a >>>>>>> way to handle generic case if the input does not match any of the >>>>>>> cases in switch statements in that method. >>>>>>> >>>>>>> The fact that " *InterleavedRaster() constructors throw exception >>>>>>> if DataBuffer passed to them does not match the expected type" was >>>>>>> ignored earlier. >>>>>>> >>>>>>> This fix adds a check of "DataBuffer type" before creating >>>>>>> respective >>>>>>> *InterleavedRaster() objects. >>>>>>> >>>>>>> It constructs the SunWritableRaster in case DataBuffer type does not >>>>>>> match any data specific DataBuffer classes (DataBufferByte, >>>>>>> DataBufferUShort, DataBufferInt) >>>>>>> >>>>>>> Request to review webrev containing this fix : >>>>>>> >>>>>>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.00/ >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Ajit >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, Sergey. >>>>>> >>>>> >>>>> >> From jayathirth.d.v at oracle.com Mon Mar 28 10:30:15 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 28 Mar 2016 03:30:15 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream In-Reply-To: References: <99cb1549-30b5-44af-b399-ebed22255cf8@default> <56E997F1.2070605@oracle.com> <56E9C39D.6090701@oracle.com> <56E9D1D5.8090500@oracle.com> <56EAB79C.1080503@oracle.com> <88e50a67-fdd2-4b97-aa19-3ac5d419e2cf@default> <56EAFD38.80604@oracle.com> <56F0A94C.8080703@oracle.com> <56F17140.2070208@oracle.com> <481ff313-103f-4a71-bec9-44a3fa0a70ef@default> <56F3294E.1040306@oracle.com> Message-ID: <387cc752-40cd-4d3a-9350-e53193d80dfd@default> Hi Phil, After discussion with Sergey we have come to conclusion that Sergey is okay with throwing exception or returning null/false. So I have modified the webrev to throw exception. Also in write() I have modified the catch block to just throw the caught exception without adding message since it will create confusion between the case where we are not able to create cache and when createImageOutputStream() returns null. Regarding catch block of createImageOutputStream() only when we usecache is true we use FileCacheImageOutputStream() and it throws IOException so I think there is no need to add extra check before throwing IOException. Please find updated webrev for review : http://cr.openjdk.java.net/~jdv/8044289/webrev.04/ Thanks, Jay From: Jayathirth D V Sent: Thursday, March 24, 2016 3:52 PM To: Philip Race Cc: Sergey Bylokhov; 2d-dev at openjdk.java.net Subject: RE: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream Hi Phil, We can change the code to something like : 1522 * @return false if no appropriate writer is found or 1523 * when needed stream is null. 1545 try { 1546 output.delete(); 1547 stream = createImageOutputStream(output); 1548 } catch (IOException e) { 1549 throw e; 1550 } In this case we will be throwing IOException when we are not able to create cache file and stream is null. And return null/false when createImageXXXStream returns null. Also we can add check before throwing IIOException from createImageXXXStream for usecache. 350 351 boolean usecache = getUseCache() && hasCachePermission(); 352 353 while (iter.hasNext()) { 354 ImageInputStreamSpi spi = iter.next(); 355 if (spi.getInputClass().isInstance(input)) { 356 try { 357 return spi.createInputStreamInstance(input, 358 usecache, 359 getCacheDirectory()); 360 } catch (IOException e) { 361 if (usecache) 362 throw new IIOException("Can't create cache file!", e); 363 } 364 } 365 } This will be one of the approach. Or we can throw IOException in all the cases with additional check in createImageXXXStream for usecache. This will be like throwing IOException when createImageXXXStream returns null/false or it throws IIOException when it cant create cache file. This will be another approach. Please let us know your inputs. Thanks, Jay From: Philip Race Sent: Thursday, March 24, 2016 5:10 AM To: Jayathirth D V Cc: Sergey Bylokhov; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream I don't think this is ready and we need to discuss whether to rework it. In general I think I prefer IIO rather than null when we have a stream problem. For one thing you have this change :- 1522 * @return false if no appropriate writer is found or 1523 * not able to create required ImageOutputStream. yet the implementation says :- 1545 try { 1546 output.delete(); 1547 stream = createImageOutputStream(output); 1548 } catch (IOException e) { 1549 throw new IIOException("Can't create output stream!", e); 1550 } So whilst "null" would mean we cannot find an IOS SPI it isn't the only reason we fail to create the IOS A null return seems to get passed through to doWrite() which probably throws IIOE And I think that the implementation is actually right here where it throws an exception. The ability to create an image input or output stream could be because of some kind of problem opening the file, or with the IIS or IOS implementations - like they were de-registered. I think in many if not all of these cases IOE - or IIOE is what we want. Also since we call createImageInputStream() - which is public - we need to look at that, and what it does, which is also something to consider. If it returns null, that seems to mean that no suitable SPI is registered which can only happen if they are de-registered. For the methods where we use createImageInputStream() I think it is fair to turn that into IIOE BTW I note that the code there says :- 350 351 boolean usecache = getUseCache() && hasCachePermission(); 352 353 while (iter.hasNext()) { 354 ImageInputStreamSpi spi = iter.next(); 355 if (spi.getInputClass().isInstance(input)) { 356 try { 357 return spi.createInputStreamInstance(input, 358 usecache, 359 getCacheDirectory()); 360 } catch (IOException e) { 361 throw new IIOException("Can't create cache file!", e); 362 } 363 } 364 } So far I can see that means it will claim any Exception that is generated is because it could not create the cache file without any proof of that and even if "useCache" is false. It seems to imply to me that the author was not considering things like someone passing a closed InputStream .. probably we ought to be more vague in this case or look more deeply at what we can tell from whether it is IIOE or IOE. -phil. On 3/22/16, 10:49 AM, Jayathirth D V wrote: Thanks for the review Sergey. Can I get +1 for this please? -Jay -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, March 22, 2016 9:52 PM To: Jayathirth D V; Philip Race Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream This fix looks fine to me. At least it made all code work in a similar way. But probably someone will have other opinion? On 22.03.16 12:34, Jayathirth D V wrote: Hi Sergey, I have unified changes related to ImageIO.read() and ImageIO.write(). In case of read() we will be returning null when createImageInputStream() returns null. In case of write() we will be returning false when createImageOutputStream() returns null. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/8044289/webrev.03/ Thanks, Jay -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, March 22, 2016 7:39 AM To: Jayathirth D V; Philip Race Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream Hi, Jay. Since we decided to update the specification we get an additional flexibility in the fix, because we can update the "@exception IOException" part of javadoc and describe that it can be thrown if ImageXXXStream cannot be created. I don't see a big differences of both approaches in case of write() methods, but in case of read(which has the similar issue but was skipped in the fix) there is a difference. Note that the read(File) unlike other methods throws the unspecified IIOException exception if ImageXXXStream cannot be created. We can think about unification of read/write methods in ImageIO. Hmm but even then read() in some cases will return null and in some cases throw an exception.... and createImageInputStream/createImageOutputStream() will look alien as they always return null not an exception. Another possible unification is to update javadoc for all methods, that they will return null if related providers are not found(in this case "throw new IIOException("Can't create an ImageInputStream!"))" should be removed from read(File); On 21.03.16 10:26, Jayathirth D V wrote: Hi Sergey, For the second approach I have created webrev for review. Please review updated webrev : http://cr.openjdk.java.net/~jdv/8044289/webrev.02/ Thanks, Jay -----Original Message----- From: Jayathirth D V Sent: Friday, March 18, 2016 2:23 PM To: Sergey Bylokhov Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net; Philip Race Subject: RE: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream Hi Sergey, Thanks for your inputs. Indeed all the null values returned by createImageInputStream() and createImageInputStream() are valid only. I went through the code more and found that there is no need for fix in ImageIO.read() methods as null stream is handled in read(ImageInputStream stream) which is called by all the remaining read() API's through IAE. So i can remove the changes made in ImageIO.read() functions. Also istream is closed in finally block of read(url). For ImageIO.write(File) & ImageIO.write(OutputStream) NPE we have two approaches for fix: 1) Keep the present changes of throwing IOException when stream is null and change the throw clause of write() spec mentioning: "IOException - if an error occurs during writing or not able to create required ImageOutputStream" 2) Remove the present changes and handle null in doWrite() method by returning false when stream is null & add code in finally block to close the stream only when stream is not null. Along with this we can also change Returns clause of spec to mention that write() might return false when we are not able to create ImageOutputStream. private static boolean doWrite(RenderedImage im, ImageWriter writer, ImageOutputStream output) throws IOException { if (writer == null) { return false; } + if (output == null) { + return false; + } try { return doWrite(im, writer, stream); } finally { + if (stream != null) stream.close(); } Returns : false if no appropriate writer is found or not able to create required ImageOutputStream. Please let me know your inputs. Thanks, Jay -----Original Message----- From: Sergey Bylokhov Sent: Friday, March 18, 2016 12:24 AM To: Jayathirth D V Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net; Philip Race Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream On 17.03.16 21:14, Jayathirth D V wrote: There are many places in createImageInputStream() and createImageOutputStream() where it will return null for stream. But when why you change the write/read methods? They should take null into account and work according to specification. If some bogus null returns from createImageInputStream/createImageOutputStream then it should be fixed in these methods. So for NPE described in bug to occur there can be multiple paths: 1) One of the path described in bug is when theRegistry.getServiceProviders() throws IAE and we return null. This is the case when we have no installed spi and should return null/false. 2) When we pass non-existent file path to ImageIO (as described in http://stackoverflow.com/questions/11153200/with-imageio-write-api-call-i-get-nullpointerexception ). Here we catch FileNotFoundException but still we return stream as null at the end which will cause NPE further. This is same thing described in the bug(about stream.close()). The write method call createImageOutputStream() and got FileNotFoundException. This exception should be propagated to the user, but it is replaced in the finally block, because we try to close the stream=null. So the fix for this particular case is to check the stream to null in finally, No? 3) When we don't support the provider and theRegistry.getServiceProviders() return iterator with size zero. This means that our providers do not support this case, and we should return null/false. For us to follow first scenario we need access to categoryMap of IIORegistry and delete the ImageInputStreamSpi/ ImageOutputStreamSpi but I was not able to find a way to tamper it from test case. If we follow second case FileNotFoundException will be thrown by default eventhough we handle NPE. But you change the code and we now contradicts the specification, in your case the test should expect false/null from write()/read(). In the test case we are trying to following third scenario to get stream as null to verify the code changes. To catch the bogus null we should try to use another approach, or change the spec. But it seems all null values above are correct, we should be ready for them. As part of collective fix we are throwing IOException which will indicate that we are not able to create required stream. Thanks, Jay -----Original Message----- From: Sergey Bylokhov Sent: Thursday, March 17, 2016 7:27 PM To: Phil Race Cc: Jayathirth D V; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream On 17.03.16 0:36, Phil Race wrote: I don't think that is the actual reason here But the test doing exactly this thing -> deregister all spi => in this case according to specification all related methods(read/write/creatImageInputStream/creatImageOutputStream) should return null or false. - it seems likely that there was some kind of internal error or bad SPI causing this. So throwing an exception seems more appropriate. the problem was in some of our methods which do not expect null in some places(like stream.close() from the bug description). And also the bug was originally solely about write(..). -phil. On 03/16/2016 01:35 PM, Sergey Bylokhov wrote: As far as I understand the createImageInputStream() returns null is this stream is unsupported by current plugins via spi. Probably the read() method should return null too? /** * Returns a {@code BufferedImage} as the result of decoding * a supplied {@code InputStream} with an {@code ImageReader} * chosen automatically from among those currently registered. * The {@code InputStream} is wrapped in an * {@code ImageInputStream}. If no registered * {@code ImageReader} claims to be able to read the * resulting stream, {@code null} is returned. * ....... * @return a {@code BufferedImage} containing the decoded * contents of the input, or {@code null}. */ public static BufferedImage read(InputStream input) throws IOException On 16.03.16 20:29, Philip Race wrote: The test writes out into "test.src". I believe that you should treat that as a "read-only" location. Write to a tempfile (File.createTempFile()) or TESTCLASSES. -phil. On 3/15/16, 10:50 PM, Jayathirth D V wrote: Hi Phil,All _Please review the following fix in JDK9:_ __ Bug : https://bugs.openjdk.java.net/browse/JDK-8044289 Webrev : http://cr.openjdk.java.net/~jdv/8044289/webrev.00/ HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8044289/webrev.00/" Issue : When createImageInputStream() or createImageOutputStream returns null in ImageIO.read() or ImageIO.write() we are seeing NPE as it stream is used further without null check. Root cause : "stream" is used without checking whether it is null or not. Solution : Handle null pointer of stream and throw IIOException. Test case contains all possible scenarios where createImageInputStream() or createImageOutputStream can return null. Thanks, Jay -- Best regards, Sergey. -- Best regards, Sergey. -- Best regards, Sergey. -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prahalad.kumar.narayanan at oracle.com Mon Mar 28 12:33:31 2016 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Mon, 28 Mar 2016 05:33:31 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: Antialiased text on translucent backgrounds gets bright artifacts In-Reply-To: <56F3505B.2070101@oracle.com> References: <63d69ba8-d5cf-4697-bb5c-f51aaaa8c427@default> <56EB4DBB.9080802@oracle.com> <56F3505B.2070101@oracle.com> Message-ID: <215e497a-db82-4f6f-99e9-bd44f25d5999@default> Hello Everyone on Java2D Group Good day to you. This is a follow-up to Review Request on bug: Bug : JDK-8015070 Bug Link : https://bugs.openjdk.java.net/browse/JDK-8015070 First, Thanks to Jim and Sergey for their feedback on the changes so far. Inferences from Jim 's Feedback on Loading destination colors: 1. The API or Macro that I had earlier used to Load DST colors, indeed, adjusted destination color components with divide-by-alpha if destination was already pre-multiplied. My apologies.. I should have spotted this error at the first iteration itself. 2. Due to the divide-by-alpha adjustment, the remaining logic would become incorrect. ( Especially, the multiplication with dstF based on pre-mulitplication status ) 3. Correct API is being used now, and the dstColor components are loaded directly without any divide-by-alpha adjustment. Inferences from Sergey's Feedback on Performance. 1. To set the context for everyone, the logic present in the current webrev.02 is modelled as per SRCOVER_MASKFILL. There are multiple if (...) conditions that remove un-necessary blending calculations. Ideally this should improve performance. However, since some data are not readily available (as present in SRCOVER_MASKFILL), few additional calculations have been added. They are: pre-multiplying srcColor with alpha and assigning to res. Finding the correct address of Pixel using DST_PTR and PixelStride. Henceforth, as Sergey suggests, Observation on performance will be beneficial. 2. The performance of the new logic was measured with linux-x86_64-normal-server-release config and compared with the logic used in un-optimized code in webrev.00 3. Result: The newer logic provides a fractional gain (about 15 - 20 ms) over the older logic. Other Subtle Changes: 1. The test file has been renamed from AADrawStringArtifact.java to more meaningful - AntialiasedTextArtifact.java 2. The test file tests for both TYPE_INT_ARGB and TYPE_INT_ARGB_PRE BufferedImage formats. The code has been well commented to explain the logic used in every function. Kindly take your time to review the changes in the webrev link mentioned below and provide your suggestions. Webrev Link: http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.02/ Thank you for your time in review Have a good day Prahalad N. -----Original Message----- From: Jim Graham Sent: Thursday, March 24, 2016 7:57 AM To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: Antialiased text on translucent backgrounds gets bright artifacts Hi Prahalad, (On a side note - ouch! I came up with these macros in the first place, but 20 years later I'm now realizing just how hard they are to navigate and review. My apologies...) The macro you are still using to load the destination data is one that loads it to non-premultiplied components, which means it will divide out the alpha if the destination is PRE. The rest of the logic assumes that the components were loaded without any adjustment of their premultiplication so not only is that division an unnecessary operation, it makes the following math wrong. The SRCOVER_MASKFILL macro seems to use "Postload ## STRATEGY ## From ## TYPE" which seems to load them into separate components without any adjustment of their pre-multiplication status. This is paired with "LoadAlphaFrom ## TYPE ## For ## STRATEGY" to load just the destination alpha for computing dstF... ...jim On 3/22/16 4:35 AM, Prahalad Kumar Narayanan wrote: > Hello Everyone on Java2D Group > > Good day to you. > > This is a Follow-up to Review Request on the bug: > Bug : JDK-8015070 Anti-aliased Text on Translucent background gets bright artifacts > Bug Link : https://bugs.openjdk.java.net/browse/JDK-8015070 > > First, Sincere thanks to Jim for his valuable feedback. > 1. As Jim correctly mentioned, SRCOVER_MASKFILL has a similar logic to blend two Translucent colors based on an Alpha mask. > 2. The calculations are exactly the same as the changes in previous webrev. > However the logic of SRCOVER_MASKFILL is 'Optimized' to reduce the number of computations. > 3. This optimization is definitely required because, the logic is executed for every single pixel in a glyph. > Example: If a string is made up of 5 English characters with each character having 32 x 32 pixels, > The anti-aliasing logic will be executed for 5 x 32 x 32 iterations. > Reducing computation per pixel will imply a huge benefit for complete drawString operation. > > Observation from SRCOVER_MASKFILL > 1. The mask fill reduces computations by through multiple if(...) conditions. > Each if condition affirms whether the next set of computations are required. > 2. Optimization 1: If mask value is 0- skip entire logic. > 3. Optimization 2: If mask value is maximum, say 255, take srcA directly without multiplying with maskAlpha ( Reason: 1 * srcAlpha = srcAlpha ) > 4. Optimization 3: Compute pre-multiplied resColor in two steps. First with srcColor and then with dstColor. > If the resAlpha from 1st step (i.e., srcColor) is fully opaque, avoid blending dstColor altogether. > > Changes in Current Webrev.01 > 1. The fix for the current bug is modelled based on SRCOVER_MASKFILL. > 2. The changes have been verified to work on windows, linux and mac operating systems. > 3. The automated Test file- AADrawStringArtifact.java runs as expected > Identifies artifact & throws exception when run on JDK 7 and 8. > With JDK9, the test file returns without error. > 3. JPRT build has been run to ensure, changes build on all supported platforms. > JPRT job link : > http://scaaa637.us.oracle.com//archive/2016/03/2016-03-22-070604.prahn > ara-linux.client > > Kindly review the changes in the below mentioned link and provide your views > Webrev Link : > http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.01/ > > > Thank you for your time in review > Have a good day > > Prahalad N. > > > -----Original Message----- > From: Jim Graham > Sent: Friday, March 18, 2016 6:07 AM > To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: > Antialiased text on translucent backgrounds gets bright artifacts > > Hi Prahalad, > > This basically boils down to "alpha blending math needs to be performed in premultiplied form" and the existing code was not doing that. > > Your changes do add a pre-multiplication step to the math in two > places > - when you mix the src alpha and the glyph alpha at the top of the macro, and again when you do the Multiply(dst, dstA, dst) step in the middle. In that sense, the new math is correct. > > However, it is not the optimal way to implement this. In particular, > the macro used here to load the data from the destination is the one > that loads it into 4 ARGB non-premultiplied values. If the > destination is non-PRE, then your added multiply step is exactly what > is needed, but it could be combined with the multiply that will happen > later in the blending equation, so it is an added step rather than a > fixed fraction in the existing MultMultAdd parameters. Additionally, > if the destination is already PRE, then the macro being used to load > the dst pixel data there will have done a divide step to divide out > the alpha from the destination, only to have you reverse that math > with your new > Multiply() step. That's a lot of math to end up with a NOP. > > The MUL8 you added for the srcA and glyph value is needed, that change is good. Since it is common for glyph pixels to have zero alpha, you might want to test the glyph alpha for 0 and skip the pixel before you do the multiply, though. This would add one more if, but it would be a common case. > > The trickier part is to load the destination components without un-premultiplying them. Unfortunately there is no "Load...ToArgbPre" > macro to parallel the Load macro used in the function. Perhaps there should be, but you'd still end up with an extra multiply step as I mentioned above because you can fold the premultiplication of the dst data into the MultMultAdd by carefully choosing the parameters you use in the math there. > > The good news is that the way that the SRCOVER_MASKFILL uses the various type-specific macros works around this a bit and minimizes the number of multiplies that happen. You could check out DEFINE_SRCOVER_MASKFILL and see how it works in the case where pMask is not null (pMask is an alpha mask with values very similar to the glyphAA data). Modeling this code on that code would correct the math and minimize it as well... > > ...jim > > On 3/17/16 3:00 AM, Prahalad Kumar Narayanan wrote: >> Hello Everyone on Java2D Group >> >> Good day to you. >> >> Herewith, I 'm sharing the webrev for two identical Java2D Bugs. >> >> Bug ID : JDK-8015070 >> >> Title : Antialiased text on translucent backgrounds gets >> bright artifacts >> >> Link : https://bugs.openjdk.java.net/browse/JDK-8015070 >> >> Bug ID : JDK-8013564 ( currently closed as duplicate ) >> >> Title : Font rendering anti-aliasing in translucent >> BufferedImages broken >> >> Link : https://bugs.openjdk.java.net/browse/JDK-8013564 >> >> Webrev Link : >> http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.00/ >> >> Quick Summary on Bugs : >> >> ```````````````````````````````````````````````` >> >> 1. Artifacts appear on Edges of text characters when anti-aliased >> text is drawn on Translucent background >> >> 2. The issue is reproducible on all platforms - windows, linux and mac os. >> >> 3. Besides, the issue is reproduced with the commonly used pixel >> format- 4ByteArgb. >> >> Root Cause & Solution : >> >> ```````````````````````````````````````````````` >> >> 1. The Macro: GlyphListAABlend4ByteArgb in File: LoopMacros.h uses >> the standard blending algorithm >> >> dstColor = [ srcColor * glyphAlpha + dstColor * (1 - >> glyphAlpha) ] / dstAlpha >> >> 2. The above equation works only when the srcColor and dstColor are Opaque. >> >> 3. When srcColor and dstColor are Translucent, their alphaComponent >> will influence the visibility of the color, and visibility of the >> color below. >> >> 4. The new set of calculations for blending Translucent source and >> destination colors is given as >> >> resAlpha = 1 - ((1 - srcAlpha) * (1 - dstAlpha)) >> >> resColor = [ srcColor * srcAlpha + dstColor * dstAlpha * (1 >> - >> srcAlpha) ] / resAlpha >> >> 5. Reference text for the equation: >> https://en.wikipedia.org/wiki/Alpha_compositing >> >> 6. With the above modification to the blending logic, the artifacts >> do not appear and issues are fixed. >> >> Jtreg & Jprt Results : >> >> ```````````````````````````````````````````````` >> >> 1. A simple test-file: AADrawStringArtifact.java has been created to >> be a part of jtreg test cases. >> >> The test file is well commented to explain - nature of >> artifact and how the test tries to identify them. >> >> As required, the test case fails with Jdk 7, Jdk 8 and >> succeeds with Jdk 9-internal (built with changes for the bug fix) >> >> 2. The changes to blending logic lies within >> java.desktop/src/share/native/... >> >> Henceforth, JPRT was used to ensure successful build >> across all supported platforms >> >> Jprt Job Link : >> http://scaaa637.us.oracle.com//archive/2016/03/2016-03-17-072001.prah >> n >> ara-linux.client >> >> The build succeeds on all platforms. >> >> Kindly review the webrev link and provide your views and suggestions. >> >> Webrev Link : >> http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.00/ >> >> If the changes look good, we could take up the changes for source checkin. >> >> Thank you for your time in review >> >> Have a good day >> >> Prahalad N. >> From philip.race at oracle.com Mon Mar 28 22:12:46 2016 From: philip.race at oracle.com (Philip Race) Date: Mon, 28 Mar 2016 15:12:46 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream In-Reply-To: <387cc752-40cd-4d3a-9350-e53193d80dfd@default> References: <99cb1549-30b5-44af-b399-ebed22255cf8@default> <56E997F1.2070605@oracle.com> <56E9C39D.6090701@oracle.com> <56E9D1D5.8090500@oracle.com> <56EAB79C.1080503@oracle.com> <88e50a67-fdd2-4b97-aa19-3ac5d419e2cf@default> <56EAFD38.80604@oracle.com> <56F0A94C.8080703@oracle.com> <56F17140.2070208@oracle.com> <481ff313-103f-4a71-bec9-44a3fa0a70ef@default> <56F3294E.1040306@oracle.com> <387cc752-40cd-4d3a-9350-e53193d80dfd@default> Message-ID: <56F9AC5E.8010107@oracle.com> This all looks fine to me. Although no new Exception types are thrown I think we need a CCC anyway, so please prepare and get that approved before pushing. -phil. On 3/28/16, 3:30 AM, Jayathirth D V wrote: > > Hi Phil, > > After discussion with Sergey we have come to conclusion that Sergey is > okay with throwing exception or returning null/false. > > So I have modified the webrev to throw exception. > > Also in write() I have modified the catch block to just throw the > caught exception without adding message since it will create confusion > between the case where we are not able to create cache and when > createImageOutputStream() returns null. > > Regarding catch block of createImageOutputStream() only when we > usecache is true we use FileCacheImageOutputStream() and it throws > IOException so I think there is no need to add extra check before > throwing IOException. > > Please find updated webrev for review : > > http://cr.openjdk.java.net/~jdv/8044289/webrev.04/ > > > Thanks, > > Jay > > *From:*Jayathirth D V > *Sent:* Thursday, March 24, 2016 3:52 PM > *To:* Philip Race > *Cc:* Sergey Bylokhov; 2d-dev at openjdk.java.net > *Subject:* RE: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In > ImageIO.read() and write() NPE is not handled properly for stream > > Hi Phil, > > We can change the code to something like : > > 1522 * @returnfalse if no appropriate writer is found or > 1523 * when needed stream is null. > > 1545 try { > 1546 output.delete(); > 1547 stream = createImageOutputStream(output); > 1548 } catch (IOException e) { > 1549*throw e;* > 1550 } > > In this case we will be throwing IOException when we are not able to > create cache file and stream is null. > > And return null/false when createImageXXXStream returns null. Also we > can add check before throwing IIOException from createImageXXXStream > for usecache. > > 350 > 351 boolean usecache = getUseCache()&& hasCachePermission(); > 352 > 353 while (iter.hasNext()) { > 354 ImageInputStreamSpi spi = iter.next(); > 355 if (spi.getInputClass().isInstance(input)) { > 356 try { > 357 return spi.createInputStreamInstance(input, > 358 usecache, > 359 getCacheDirectory()); > 360 } catch (IOException e) { > 361*if (usecache)* > 362 throw new IIOException("Can't create cache file!", e); > 363 } > 364 } > 365 } > > This will be one of the approach. > > Or we can throw IOException in all the cases with additional check in > createImageXXXStream for usecache. This will be like throwing > IOException when createImageXXXStream returns null/false or it throws > IIOException when it cant create cache file. This will be another > approach. Please let us know your inputs. > > Thanks, > > Jay > > *From:*Philip Race > *Sent:* Thursday, March 24, 2016 5:10 AM > *To:* Jayathirth D V > *Cc:* Sergey Bylokhov; 2d-dev at openjdk.java.net > > *Subject:* Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In > ImageIO.read() and write() NPE is not handled properly for stream > > I don't think this is ready and we need to discuss whether to rework it. > > In general I think I prefer IIO rather than null when we have a stream problem. > > > For one thing you have this change :- > > 1522 * @returnfalse if no appropriate writer is found or > 1523 * not able to create required ImageOutputStream. > > yet the implementation says :- > 1545 try { > 1546 output.delete(); > 1547 stream = createImageOutputStream(output); > 1548 } catch (IOException e) { > 1549 throw new IIOException("Can't create output stream!", e); > 1550 } > > > So whilst "null" would mean we cannot find an IOS SPI it isn't > the only reason we fail to create the IOS > A null return seems to get passed through to doWrite() which probably throws IIOE > And I think that the implementation is actually right here where > it throws an exception. > > The ability to create an image input or output stream could be because > of some kind of problem opening the file, or with the IIS or IOS implementations - > like they were de-registered. I think in many if not all of these cases IOE - or IIOE is > what we want. > > Also since we call createImageInputStream() - which is public - we > need to look at that, and what it does, which is also something to consider. > If it returns null, that seems to mean that no suitable SPI is registered > which can only happen if they are de-registered. For the methods where > we use createImageInputStream() I think it is fair to turn that into IIOE > > BTW I note that the code there says :- > 350 > 351 boolean usecache = getUseCache()&& hasCachePermission(); > 352 > 353 while (iter.hasNext()) { > 354 ImageInputStreamSpi spi = iter.next(); > 355 if (spi.getInputClass().isInstance(input)) { > 356 try { > 357 return spi.createInputStreamInstance(input, > 358 usecache, > 359 getCacheDirectory()); > 360 } catch (IOException e) { > 361 throw new IIOException("Can't create cache file!", e); > 362 } > 363 } > 364 } > > So far I can see that means it will claim any Exception that is generated is because it > could not create the cache file without any proof of that and even if "useCache" is false. > It seems to imply to me that the author was not considering things like someone > passing a closed InputStream .. probably we ought to be more vague in this case > or look more deeply at what we can tell from whether it is IIOE or IOE. > > -phil. > > > > On 3/22/16, 10:49 AM, Jayathirth D V wrote: > > Thanks for the review Sergey. > > Can I get +1 for this please? > > > > -Jay > > > > -----Original Message----- > > From: Sergey Bylokhov > > Sent: Tuesday, March 22, 2016 9:52 PM > > To: Jayathirth D V; Philip Race > > Cc:2d-dev at openjdk.java.net > > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream > > > > This fix looks fine to me. > > At least it made all code work in a similar way. But probably someone will have other opinion? > > > > On 22.03.16 12:34, Jayathirth D V wrote: > > Hi Sergey, > > > > I have unified changes related to ImageIO.read() and ImageIO.write(). > > > > In case of read() we will be returning null when createImageInputStream() returns null. > > In case of write() we will be returning false when createImageOutputStream() returns null. > > > > Please find updated webrev for review: > > http://cr.openjdk.java.net/~jdv/8044289/webrev.03/ > > > > Thanks, > > Jay > > > > -----Original Message----- > > From: Sergey Bylokhov > > Sent: Tuesday, March 22, 2016 7:39 AM > > To: Jayathirth D V; Philip Race > > Cc:2d-dev at openjdk.java.net > > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In > > ImageIO.read() and write() NPE is not handled properly for stream > > > > Hi, Jay. > > Since we decided to update the specification we get an additional flexibility in the fix, because we can update the "@exception IOException" part of javadoc and describe that it can be thrown if ImageXXXStream cannot be created. > > > > I don't see a big differences of both approaches in case of write() methods, but in case of read(which has the similar issue but was skipped in the fix) there is a difference. > > Note that the read(File) unlike other methods throws the unspecified > > IIOException exception if ImageXXXStream cannot be created. We can > > think about unification of read/write methods in ImageIO. Hmm but even > > then > > read() in some cases will return null and in some cases throw an exception.... > > and createImageInputStream/createImageOutputStream() will look alien as they always return null not an exception. > > > > Another possible unification is to update javadoc for all methods, > > that they will return null if related providers are not found(in this > > case "throw new IIOException("Can't create an ImageInputStream!"))" > > should be removed from read(File); > > > > On 21.03.16 10:26, Jayathirth D V wrote: > > Hi Sergey, > > > > For the second approach I have created webrev for review. > > > > Please review updated webrev : > > http://cr.openjdk.java.net/~jdv/8044289/webrev.02/ > > > > Thanks, > > Jay > > > > -----Original Message----- > > From: Jayathirth D V > > Sent: Friday, March 18, 2016 2:23 PM > > To: Sergey Bylokhov > > Cc:2d-dev at openjdk.java.net ; Philip Race > > Subject: RE: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In > > ImageIO.read() and write() NPE is not handled properly for stream > > > > Hi Sergey, > > > > Thanks for your inputs. > > > > Indeed all the null values returned by createImageInputStream() and createImageInputStream() are valid only. > > > > I went through the code more and found that there is no need for fix in ImageIO.read() methods as null stream is handled in read(ImageInputStream stream) which is called by all the remaining read() API's through IAE. So i can remove the changes made in ImageIO.read() functions. Also istream is closed in finally block of read(url). > > > > For ImageIO.write(File)& ImageIO.write(OutputStream) NPE we have two approaches for fix: > > > > 1) Keep the present changes of throwing IOException when stream is null and change the throw clause of write() spec mentioning: > > "IOException - if an error occurs during writing or not able to create required ImageOutputStream" > > > > 2) Remove the present changes and handle null in doWrite() method by returning false when stream is null& add code in finally block to close the stream only when stream is not null. Along with this we can also change Returns clause of spec to mention that write() might return false when we are not able to create ImageOutputStream. > > > > private static boolean doWrite(RenderedImage im, ImageWriter writer, > > ImageOutputStream output) throws IOException { > > if (writer == null) { > > return false; > > } > > + if (output == null) { > > + return false; > > + } > > > > try { > > return doWrite(im, writer, stream); > > } finally { > > + if (stream != null) > > stream.close(); > > } > > > > Returns : > > false if no appropriate writer is found or not able to create required ImageOutputStream. > > > > Please let me know your inputs. > > > > Thanks, > > Jay > > > > -----Original Message----- > > From: Sergey Bylokhov > > Sent: Friday, March 18, 2016 12:24 AM > > To: Jayathirth D V > > Cc:2d-dev at openjdk.java.net ; Philip Race > > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In > > ImageIO.read() and write() NPE is not handled properly for stream > > > > On 17.03.16 21:14, Jayathirth D V wrote: > > There are many places in createImageInputStream() and createImageOutputStream() where it will return null for stream. > > > > But when why you change the write/read methods? They should take null into account and work according to specification. If some bogus null returns from createImageInputStream/createImageOutputStream then it should be fixed in these methods. > > > > So for NPE described in bug to occur there can be multiple paths: > > 1) One of the path described in bug is when theRegistry.getServiceProviders() throws IAE and we return null. > > > > This is the case when we have no installed spi and should return null/false. > > > > 2) When we pass non-existent file path to ImageIO (as described inhttp://stackoverflow.com/questions/11153200/with-imageio-write-api-call-i-get-nullpointerexception ). Here we catch FileNotFoundException but still we return stream as null at the end which will cause NPE further. > > > > This is same thing described in the bug(about stream.close()). The write method call createImageOutputStream() and got FileNotFoundException. > > This exception should be propagated to the user, but it is replaced in the finally block, because we try to close the stream=null. So the fix for this particular case is to check the stream to null in finally, No? > > > > 3) When we don't support the provider and theRegistry.getServiceProviders() return iterator with size zero. > > > > This means that our providers do not support this case, and we should return null/false. > > > > > > For us to follow first scenario we need access to categoryMap of IIORegistry and delete the ImageInputStreamSpi/ ImageOutputStreamSpi but I was not able to find a way to tamper it from test case. If we follow second case FileNotFoundException will be thrown by default eventhough we handle NPE. > > > > But you change the code and we now contradicts the specification, in your case the test should expect false/null from write()/read(). > > > > > > In the test case we are trying to following third scenario to get stream as null to verify the code changes. > > > > To catch the bogus null we should try to use another approach, or change the spec. But it seems all null values above are correct, we should be ready for them. > > > > > > As part of collective fix we are throwing IOException which will indicate that we are not able to create required stream. > > > > Thanks, > > Jay > > > > -----Original Message----- > > From: Sergey Bylokhov > > Sent: Thursday, March 17, 2016 7:27 PM > > To: Phil Race > > Cc: Jayathirth D V;2d-dev at openjdk.java.net > > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In > > ImageIO.read() and write() NPE is not handled properly for stream > > > > On 17.03.16 0:36, Phil Race wrote: > > I don't think that is the actual reason here > > > > But the test doing exactly this thing -> deregister all spi => in > > this case according to specification all related > > methods(read/write/creatImageInputStream/creatImageOutputStream) should return null or false. > > > > - it seems likely that there > > was some kind of internal error or bad SPI causing this. > > So throwing an exception seems more appropriate. > > > > the problem was in some of our methods which do not expect null in some places(like stream.close() from the bug description). > > > > And also the bug was originally solely about write(..). > > > > -phil. > > > > > > On 03/16/2016 01:35 PM, Sergey Bylokhov wrote: > > As far as I understand the createImageInputStream() returns null > > is this stream is unsupported by current plugins via spi. Probably > > the > > read() method should return null too? > > > > /** > > * Returns a {@code BufferedImage} as the result of decoding > > * a supplied {@code InputStream} with an {@code ImageReader} > > * chosen automatically from among those currently registered. > > * The {@code InputStream} is wrapped in an > > * {@code ImageInputStream}. If no registered > > * {@code ImageReader} claims to be able to read the > > * resulting stream, {@code null} is returned. > > * > > ....... > > * @return a {@code BufferedImage} containing the decoded > > * contents of the input, or {@code null}. > > */ > > public static BufferedImage read(InputStream input) throws > > IOException > > > > > > On 16.03.16 20:29, Philip Race wrote: > > The test writes out into "test.src". > > I believe that you should treat that as a "read-only" location. > > Write to a tempfile (File.createTempFile()) or TESTCLASSES. > > > > -phil. > > > > On 3/15/16, 10:50 PM, Jayathirth D V wrote: > > > > Hi Phil,All > > > > _Please review the following fix in JDK9:_ > > > > __ > > > > Bug :https://bugs.openjdk.java.net/browse/JDK-8044289 > > > > Webrev :http://cr.openjdk.java.net/~jdv/8044289/webrev.00/ > > > > > > Issue : When createImageInputStream() or createImageOutputStream > > returns null in ImageIO.read() or ImageIO.write() we are seeing > > NPE as it stream is used further without null check. > > > > Root cause : "stream" is used without checking whether it is > > null or not. > > > > Solution : Handle null pointer of stream and throw IIOException. > > > > Test case contains all possible scenarios where > > createImageInputStream() or createImageOutputStream can return null. > > > > Thanks, > > > > Jay > > > > > > > > > > > > > > -- > > Best regards, Sergey. > > > > > > > > -- > > Best regards, Sergey. > > > > > > > > -- > > Best regards, Sergey. > > > > > > > > -- > > Best regards, Sergey. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Tue Mar 29 01:15:16 2016 From: philip.race at oracle.com (Philip Race) Date: Mon, 28 Mar 2016 18:15:16 -0700 Subject: [OpenJDK 2D-Dev] [9]: RFR JDK-6357905, , java.awt.JobAttributes.getFromPage() and getToPage() always returns "1". In-Reply-To: <56F8ED8F.6030007@oracle.com> References: <56F8ED8F.6030007@oracle.com> Message-ID: <56F9D724.3060104@oracle.com> Please add an evaluation to the bug report. As to the fix I am under the impression that min&max page are meant to constrain what the user can enter in the dialog so if min page & max page are set to "1" then the problem may be with those settings ? i.e the application can set those values and expect the user can't change them so updating our code to circumvent that seems wrong. -phil. On 3/28/16, 1:38 AM, prasanta sadhukhan wrote: > Hi All, > > Please review a print job attribute fix for jdk9. > Bug: https://bugs.openjdk.java.net/browse/JDK-6357905 > webrev: http://cr.openjdk.java.net/~psadhukhan/6357905/webrev.00/ > > The issue was in the Print-dialog, when some pages are specified using > "Pages" within "Page range", java.awt.JobAttributes.getFromPage() and > getToPage() always returns "1" > and not the values as updated by the user. > The fix was to get the pageranges attribute as set by the user and > obtain the from and to Page range and update the JobAttribute's from > and to Page. > > Regards > Prasanta From prasanta.sadhukhan at oracle.com Tue Mar 29 05:35:21 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Tue, 29 Mar 2016 11:05:21 +0530 Subject: [OpenJDK 2D-Dev] [9]: RFR JDK-6357905, , java.awt.JobAttributes.getFromPage() and getToPage() always returns "1". In-Reply-To: <56F9D724.3060104@oracle.com> References: <56F8ED8F.6030007@oracle.com> <56F9D724.3060104@oracle.com> Message-ID: <56FA1419.6080005@oracle.com> Hi Phil, On 3/29/2016 6:45 AM, Philip Race wrote: > Please add an evaluation to the bug report. > > As to the fix I am under the impression that min&max page are > meant to constrain what the user can enter in the dialog so > if min page & max page are set to "1" then the problem > may be with those settings ? > min Page is set to 1, max page is set to Integer.MAX_VALUE which I guess is right so am not sure what to change in those settings. In PrintJob2D.java#initPrintJob2D(), it sets the page ranges and to and from page and in setPageRanges() http://hg.openjdk.java.net/jdk9/client/jdk/file/41e5cfe957cb/src/java.desktop/share/classes/java/awt/JobAttributes.java#l790 it throws an IAE if firstPage < minPage. We can also do the same instead of updating the min Page so to force the user to update the min Page first before updating the page ranges. or we can transparently change the min page (without resetting back to initial minpage after setting the to/from page as I was doing in my fix) to from page when user sets the page ranges. Your thoughts? Regards Prasanta > i.e the application can set those values and expect the user > can't change them so updating our code to circumvent that > seems wrong. > > -phil. > > On 3/28/16, 1:38 AM, prasanta sadhukhan wrote: >> Hi All, >> >> Please review a print job attribute fix for jdk9. >> Bug: https://bugs.openjdk.java.net/browse/JDK-6357905 >> webrev: http://cr.openjdk.java.net/~psadhukhan/6357905/webrev.00/ >> >> The issue was in the Print-dialog, when some pages are specified >> using "Pages" within "Page range", >> java.awt.JobAttributes.getFromPage() and getToPage() always returns "1" >> and not the values as updated by the user. >> The fix was to get the pageranges attribute as set by the user and >> obtain the from and to Page range and update the JobAttribute's from >> and to Page. >> >> Regards >> Prasanta From prasanta.sadhukhan at oracle.com Tue Mar 29 08:51:11 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Tue, 29 Mar 2016 14:21:11 +0530 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream In-Reply-To: <56F9AC5E.8010107@oracle.com> References: <99cb1549-30b5-44af-b399-ebed22255cf8@default> <56E997F1.2070605@oracle.com> <56E9C39D.6090701@oracle.com> <56E9D1D5.8090500@oracle.com> <56EAB79C.1080503@oracle.com> <88e50a67-fdd2-4b97-aa19-3ac5d419e2cf@default> <56EAFD38.80604@oracle.com> <56F0A94C.8080703@oracle.com> <56F17140.2070208@oracle.com> <481ff313-103f-4a71-bec9-44a3fa0a70ef@default> <56F3294E.1040306@oracle.com> <387cc752-40cd-4d3a-9350-e53193d80dfd@default> <56F9AC5E.8010107@oracle.com> Message-ID: <56FA41FF.9000704@oracle.com> +1. Looks ok to me. Only thing is that whether the test summary is appropriate " Test verifies that when createImageInputStream() or 28 * createImageOutputStream() returns null while read or write," Should it not be "verifies whether ...throws appropriate exception"? Regards Prasanta On 3/29/2016 3:42 AM, Philip Race wrote: > This all looks fine to me. Although no new Exception types are thrown > I think we need a CCC anyway, so please prepare and get that approved > before pushing. > > -phil. > > On 3/28/16, 3:30 AM, Jayathirth D V wrote: >> >> Hi Phil, >> >> After discussion with Sergey we have come to conclusion that Sergey >> is okay with throwing exception or returning null/false. >> >> So I have modified the webrev to throw exception. >> >> Also in write() I have modified the catch block to just throw the >> caught exception without adding message since it will create >> confusion between the case where we are not able to create cache and >> when createImageOutputStream() returns null. >> >> Regarding catch block of createImageOutputStream() only when we >> usecache is true we use FileCacheImageOutputStream() and it throws >> IOException so I think there is no need to add extra check before >> throwing IOException. >> >> Please find updated webrev for review : >> >> http://cr.openjdk.java.net/~jdv/8044289/webrev.04/ >> >> >> Thanks, >> >> Jay >> >> *From:*Jayathirth D V >> *Sent:* Thursday, March 24, 2016 3:52 PM >> *To:* Philip Race >> *Cc:* Sergey Bylokhov; 2d-dev at openjdk.java.net >> *Subject:* RE: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >> ImageIO.read() and write() NPE is not handled properly for stream >> >> Hi Phil, >> >> We can change the code to something like : >> >> 1522 * @return false if no appropriate writer is >> found or >> 1523 * when needed stream is null. >> >> 1545 try { >> 1546 output.delete(); >> 1547 stream = createImageOutputStream(output); >> 1548 } catch (IOException e) { >> 1549 *throw e;* >> 1550 } >> >> In this case we will be throwing IOException when we are not able to >> create cache file and stream is null. >> >> And return null/false when createImageXXXStream returns null. Also we >> can add check before throwing IIOException from createImageXXXStream >> for usecache. >> >> 350 >> 351 boolean usecache = getUseCache() && hasCachePermission(); >> 352 >> 353 while (iter.hasNext()) { >> 354 ImageInputStreamSpi spi = iter.next(); >> 355 if (spi.getInputClass().isInstance(input)) { >> 356 try { >> 357 return spi.createInputStreamInstance(input, >> 358 usecache, >> 359 >> getCacheDirectory()); >> 360 } catch (IOException e) { >> 361 *if (usecache)* >> 362 throw new IIOException("Can't create >> cache file!", e); >> 363 } >> 364 } >> 365 } >> >> This will be one of the approach. >> >> Or we can throw IOException in all the cases with additional check in >> createImageXXXStream for usecache. This will be like throwing >> IOException when createImageXXXStream returns null/false or it throws >> IIOException when it cant create cache file. This will be another >> approach. Please let us know your inputs. >> >> Thanks, >> >> Jay >> >> *From:*Philip Race >> *Sent:* Thursday, March 24, 2016 5:10 AM >> *To:* Jayathirth D V >> *Cc:* Sergey Bylokhov; 2d-dev at openjdk.java.net >> >> *Subject:* Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >> ImageIO.read() and write() NPE is not handled properly for stream >> >> I don't think this is ready and we need to discuss whether to rework it. >> >> In general I think I prefer IIO rather than null when we have a stream problem. >> >> >> For one thing you have this change :- >> >> 1522 * @return false if no appropriate writer is >> found or >> 1523 * not able to create required ImageOutputStream. >> yet the implementation says :- >> 1545 try { >> 1546 output.delete(); >> 1547 stream = createImageOutputStream(output); >> 1548 } catch (IOException e) { >> 1549 throw new IIOException("Can't create output stream!", e); >> 1550 } >> So whilst "null" would mean we cannot find an IOS SPI it isn't >> the only reason we fail to create the IOS >> A null return seems to get passed through to doWrite() which probably throws IIOE >> And I think that the implementation is actually right here where >> it throws an exception. >> The ability to create an image input or output stream could be because >> of some kind of problem opening the file, or with the IIS or IOS implementations - >> like they were de-registered. I think in many if not all of these cases IOE - or IIOE is >> what we want. >> Also since we call createImageInputStream() - which is public - we >> need to look at that, and what it does, which is also something to consider. >> If it returns null, that seems to mean that no suitable SPI is registered >> which can only happen if they are de-registered. For the methods where >> we use createImageInputStream() I think it is fair to turn that into IIOE >> BTW I note that the code there says :- >> 350 >> 351 boolean usecache = getUseCache() && hasCachePermission(); >> 352 >> 353 while (iter.hasNext()) { >> 354 ImageInputStreamSpi spi = iter.next(); >> 355 if (spi.getInputClass().isInstance(input)) { >> 356 try { >> 357 return spi.createInputStreamInstance(input, >> 358 usecache, >> 359 getCacheDirectory()); >> 360 } catch (IOException e) { >> 361 throw new IIOException("Can't create cache file!", e); >> 362 } >> 363 } >> 364 } >> So far I can see that means it will claim any Exception that is generated is because it >> could not create the cache file without any proof of that and even if "useCache" is false. >> It seems to imply to me that the author was not considering things like someone >> passing a closed InputStream .. probably we ought to be more vague in this case >> or look more deeply at what we can tell from whether it is IIOE or IOE. >> -phil. >> >> On 3/22/16, 10:49 AM, Jayathirth D V wrote: >> >> Thanks for the review Sergey. >> >> Can I get +1 for this please? >> >> -Jay >> >> -----Original Message----- >> >> From: Sergey Bylokhov >> >> Sent: Tuesday, March 22, 2016 9:52 PM >> >> To: Jayathirth D V; Philip Race >> >> Cc:2d-dev at openjdk.java.net >> >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream >> >> This fix looks fine to me. >> >> At least it made all code work in a similar way. But probably someone will have other opinion? >> >> On 22.03.16 12:34, Jayathirth D V wrote: >> >> Hi Sergey, >> >> I have unified changes related to ImageIO.read() and ImageIO.write(). >> >> In case of read() we will be returning null when createImageInputStream() returns null. >> >> In case of write() we will be returning false when createImageOutputStream() returns null. >> >> Please find updated webrev for review: >> >> http://cr.openjdk.java.net/~jdv/8044289/webrev.03/ >> >> >> Thanks, >> >> Jay >> >> -----Original Message----- >> >> From: Sergey Bylokhov >> >> Sent: Tuesday, March 22, 2016 7:39 AM >> >> To: Jayathirth D V; Philip Race >> >> Cc:2d-dev at openjdk.java.net >> >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >> >> ImageIO.read() and write() NPE is not handled properly for stream >> >> Hi, Jay. >> >> Since we decided to update the specification we get an additional flexibility in the fix, because we can update the "@exception IOException" part of javadoc and describe that it can be thrown if ImageXXXStream cannot be created. >> >> I don't see a big differences of both approaches in case of write() methods, but in case of read(which has the similar issue but was skipped in the fix) there is a difference. >> >> Note that the read(File) unlike other methods throws the unspecified >> >> IIOException exception if ImageXXXStream cannot be created. We can >> >> think about unification of read/write methods in ImageIO. Hmm but even >> >> then >> >> read() in some cases will return null and in some cases throw an exception.... >> >> and createImageInputStream/createImageOutputStream() will look alien as they always return null not an exception. >> >> Another possible unification is to update javadoc for all methods, >> >> that they will return null if related providers are not found(in this >> >> case "throw new IIOException("Can't create an ImageInputStream!"))" >> >> should be removed from read(File); >> >> On 21.03.16 10:26, Jayathirth D V wrote: >> >> Hi Sergey, >> >> For the second approach I have created webrev for review. >> >> Please review updated webrev : >> >> http://cr.openjdk.java.net/~jdv/8044289/webrev.02/ >> >> >> Thanks, >> >> Jay >> >> -----Original Message----- >> >> From: Jayathirth D V >> >> Sent: Friday, March 18, 2016 2:23 PM >> >> To: Sergey Bylokhov >> >> Cc:2d-dev at openjdk.java.net ; Philip Race >> >> Subject: RE: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >> >> ImageIO.read() and write() NPE is not handled properly for stream >> >> Hi Sergey, >> >> Thanks for your inputs. >> >> Indeed all the null values returned by createImageInputStream() and createImageInputStream() are valid only. >> >> I went through the code more and found that there is no need for fix in ImageIO.read() methods as null stream is handled in read(ImageInputStream stream) which is called by all the remaining read() API's through IAE. So i can remove the changes made in ImageIO.read() functions. Also istream is closed in finally block of read(url). >> >> For ImageIO.write(File) & ImageIO.write(OutputStream) NPE we have two approaches for fix: >> >> 1) Keep the present changes of throwing IOException when stream is null and change the throw clause of write() spec mentioning: >> >> "IOException - if an error occurs during writing or not able to create required ImageOutputStream" >> >> 2) Remove the present changes and handle null in doWrite() method by returning false when stream is null & add code in finally block to close the stream only when stream is not null. Along with this we can also change Returns clause of spec to mention that write() might return false when we are not able to create ImageOutputStream. >> >> >> >> private static boolean doWrite(RenderedImage im, ImageWriter writer, >> >> ImageOutputStream output) throws IOException { >> >> if (writer == null) { >> >> return false; >> >> } >> >> + if (output == null) { >> >> + return false; >> >> + } >> >> >> >> try { >> >> return doWrite(im, writer, stream); >> >> } finally { >> >> + if (stream != null) >> >> stream.close(); >> >> } >> >> >> >> Returns : >> >> false if no appropriate writer is found or not able to create required ImageOutputStream. >> >> Please let me know your inputs. >> >> Thanks, >> >> Jay >> >> -----Original Message----- >> >> From: Sergey Bylokhov >> >> Sent: Friday, March 18, 2016 12:24 AM >> >> To: Jayathirth D V >> >> Cc:2d-dev at openjdk.java.net ; Philip Race >> >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >> >> ImageIO.read() and write() NPE is not handled properly for stream >> >> On 17.03.16 21:14, Jayathirth D V wrote: >> >> There are many places in createImageInputStream() and createImageOutputStream() where it will return null for stream. >> >> But when why you change the write/read methods? They should take null into account and work according to specification. If some bogus null returns from createImageInputStream/createImageOutputStream then it should be fixed in these methods. >> >> So for NPE described in bug to occur there can be multiple paths: >> >> 1) One of the path described in bug is when theRegistry.getServiceProviders() throws IAE and we return null. >> >> This is the case when we have no installed spi and should return null/false. >> >> 2) When we pass non-existent file path to ImageIO (as described inhttp://stackoverflow.com/questions/11153200/with-imageio-write-api-call-i-get-nullpointerexception ). Here we catch FileNotFoundException but still we return stream as null at the end which will cause NPE further. >> >> This is same thing described in the bug(about stream.close()). The write method call createImageOutputStream() and got FileNotFoundException. >> >> This exception should be propagated to the user, but it is replaced in the finally block, because we try to close the stream=null. So the fix for this particular case is to check the stream to null in finally, No? >> >> 3) When we don't support the provider and theRegistry.getServiceProviders() return iterator with size zero. >> >> This means that our providers do not support this case, and we should return null/false. >> >> For us to follow first scenario we need access to categoryMap of IIORegistry and delete the ImageInputStreamSpi/ ImageOutputStreamSpi but I was not able to find a way to tamper it from test case. If we follow second case FileNotFoundException will be thrown by default eventhough we handle NPE. >> >> But you change the code and we now contradicts the specification, in your case the test should expect false/null from write()/read(). >> >> In the test case we are trying to following third scenario to get stream as null to verify the code changes. >> >> To catch the bogus null we should try to use another approach, or change the spec. But it seems all null values above are correct, we should be ready for them. >> >> As part of collective fix we are throwing IOException which will indicate that we are not able to create required stream. >> >> Thanks, >> >> Jay >> >> -----Original Message----- >> >> From: Sergey Bylokhov >> >> Sent: Thursday, March 17, 2016 7:27 PM >> >> To: Phil Race >> >> Cc: Jayathirth D V;2d-dev at openjdk.java.net >> >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >> >> ImageIO.read() and write() NPE is not handled properly for stream >> >> On 17.03.16 0:36, Phil Race wrote: >> >> I don't think that is the actual reason here >> >> But the test doing exactly this thing -> deregister all spi => in >> >> this case according to specification all related >> >> methods(read/write/creatImageInputStream/creatImageOutputStream) should return null or false. >> >> - it seems likely that there >> >> was some kind of internal error or bad SPI causing this. >> >> So throwing an exception seems more appropriate. >> >> the problem was in some of our methods which do not expect null in some places(like stream.close() from the bug description). >> >> And also the bug was originally solely about write(..). >> >> -phil. >> >> On 03/16/2016 01:35 PM, Sergey Bylokhov wrote: >> >> As far as I understand the createImageInputStream() returns null >> >> is this stream is unsupported by current plugins via spi. Probably >> >> the >> >> read() method should return null too? >> >> /** >> >> * Returns a {@code BufferedImage} as the result of decoding >> >> * a supplied {@code InputStream} with an {@code ImageReader} >> >> * chosen automatically from among those currently registered. >> >> * The {@code InputStream} is wrapped in an >> >> * {@code ImageInputStream}. If no registered >> >> * {@code ImageReader} claims to be able to read the >> >> * resulting stream, {@code null} is returned. >> >> * >> >> ....... >> >> * @return a {@code BufferedImage} containing the decoded >> >> * contents of the input, or {@code null}. >> >> */ >> >> public static BufferedImage read(InputStream input) throws >> >> IOException >> >> On 16.03.16 20:29, Philip Race wrote: >> >> The test writes out into "test.src". >> >> I believe that you should treat that as a "read-only" location. >> >> Write to a tempfile (File.createTempFile()) or TESTCLASSES. >> >> -phil. >> >> On 3/15/16, 10:50 PM, Jayathirth D V wrote: >> >> Hi Phil,All >> >> _Please review the following fix in JDK9:_ >> >> __ >> >> Bug :https://bugs.openjdk.java.net/browse/JDK-8044289 >> >> Webrev :http://cr.openjdk.java.net/~jdv/8044289/webrev.00/ >> >> >> >> >> >> Issue : When createImageInputStream() or createImageOutputStream >> >> returns null in ImageIO.read() or ImageIO.write() we are seeing >> >> NPE as it stream is used further without null check. >> >> Root cause : "stream" is used without checking whether it is >> >> null or not. >> >> Solution : Handle null pointer of stream and throw IIOException. >> >> Test case contains all possible scenarios where >> >> createImageInputStream() or createImageOutputStream can return null. >> >> Thanks, >> >> Jay >> >> -- >> >> Best regards, Sergey. >> >> -- >> >> Best regards, Sergey. >> >> -- >> >> Best regards, Sergey. >> >> -- >> >> Best regards, Sergey. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Tue Mar 29 09:27:27 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 29 Mar 2016 02:27:27 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream In-Reply-To: <56FA41FF.9000704@oracle.com> References: <99cb1549-30b5-44af-b399-ebed22255cf8@default> <56E997F1.2070605@oracle.com> <56E9C39D.6090701@oracle.com> <56E9D1D5.8090500@oracle.com> <56EAB79C.1080503@oracle.com> <88e50a67-fdd2-4b97-aa19-3ac5d419e2cf@default> <56EAFD38.80604@oracle.com> <56F0A94C.8080703@oracle.com> <56F17140.2070208@oracle.com> <481ff313-103f-4a71-bec9-44a3fa0a70ef@default> <56F3294E.1040306@oracle.com> <387cc752-40cd-4d3a-9350-e53193d80dfd@default> <56F9AC5E.8010107@oracle.com> <56FA41FF.9000704@oracle.com> Message-ID: Hi Prasanta, Actually returns null in test description is for createImageXXXStream() and not for read() and write() functions. But for more clarity I have added why we catch IOException also in test description. Please review the updated webrev: http://cr.openjdk.java.net/~jdv/8044289/webrev.05/ Thanks, Jay From: prasanta sadhukhan Sent: Tuesday, March 29, 2016 2:21 PM To: Jayathirth D V Cc: Philip Race; 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream +1. Looks ok to me. Only thing is that whether the test summary is appropriate " Test verifies that when createImageInputStream() or 28 * createImageOutputStream() returns null while read or write," Should it not be "verifies whether ...throws appropriate exception"? Regards Prasanta On 3/29/2016 3:42 AM, Philip Race wrote: This all looks fine to me. Although no new Exception types are thrown I think we need a CCC anyway, so please prepare and get that approved before pushing. -phil. On 3/28/16, 3:30 AM, Jayathirth D V wrote: Hi Phil, After discussion with Sergey we have come to conclusion that Sergey is okay with throwing exception or returning null/false. So I have modified the webrev to throw exception. Also in write() I have modified the catch block to just throw the caught exception without adding message since it will create confusion between the case where we are not able to create cache and when createImageOutputStream() returns null. Regarding catch block of createImageOutputStream() only when we usecache is true we use FileCacheImageOutputStream() and it throws IOException so I think there is no need to add extra check before throwing IOException. Please find updated webrev for review : http://cr.openjdk.java.net/~jdv/8044289/webrev.04/ Thanks, Jay From: Jayathirth D V Sent: Thursday, March 24, 2016 3:52 PM To: Philip Race Cc: Sergey Bylokhov; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: RE: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream Hi Phil, We can change the code to something like : 1522 * @return false if no appropriate writer is found or 1523 * when needed stream is null. 1545 try { 1546 output.delete(); 1547 stream = createImageOutputStream(output); 1548 } catch (IOException e) { 1549 throw e; 1550 } In this case we will be throwing IOException when we are not able to create cache file and stream is null. And return null/false when createImageXXXStream returns null. Also we can add check before throwing IIOException from createImageXXXStream for usecache. 350 351 boolean usecache = getUseCache() && hasCachePermission(); 352 353 while (iter.hasNext()) { 354 ImageInputStreamSpi spi = iter.next(); 355 if (spi.getInputClass().isInstance(input)) { 356 try { 357 return spi.createInputStreamInstance(input, 358 usecache, 359 getCacheDirectory()); 360 } catch (IOException e) { 361 if (usecache) 362 throw new IIOException("Can't create cache file!", e); 363 } 364 } 365 } This will be one of the approach. Or we can throw IOException in all the cases with additional check in createImageXXXStream for usecache. This will be like throwing IOException when createImageXXXStream returns null/false or it throws IIOException when it cant create cache file. This will be another approach. Please let us know your inputs. Thanks, Jay From: Philip Race Sent: Thursday, March 24, 2016 5:10 AM To: Jayathirth D V Cc: Sergey Bylokhov; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream I don't think this is ready and we need to discuss whether to rework it. In general I think I prefer IIO rather than null when we have a stream problem. For one thing you have this change :- 1522 * @return false if no appropriate writer is found or 1523 * not able to create required ImageOutputStream. yet the implementation says :- 1545 try { 1546 output.delete(); 1547 stream = createImageOutputStream(output); 1548 } catch (IOException e) { 1549 throw new IIOException("Can't create output stream!", e); 1550 } So whilst "null" would mean we cannot find an IOS SPI it isn't the only reason we fail to create the IOS A null return seems to get passed through to doWrite() which probably throws IIOE And I think that the implementation is actually right here where it throws an exception. The ability to create an image input or output stream could be because of some kind of problem opening the file, or with the IIS or IOS implementations - like they were de-registered. I think in many if not all of these cases IOE - or IIOE is what we want. Also since we call createImageInputStream() - which is public - we need to look at that, and what it does, which is also something to consider. If it returns null, that seems to mean that no suitable SPI is registered which can only happen if they are de-registered. For the methods where we use createImageInputStream() I think it is fair to turn that into IIOE BTW I note that the code there says :- 350 351 boolean usecache = getUseCache() && hasCachePermission(); 352 353 while (iter.hasNext()) { 354 ImageInputStreamSpi spi = iter.next(); 355 if (spi.getInputClass().isInstance(input)) { 356 try { 357 return spi.createInputStreamInstance(input, 358 usecache, 359 getCacheDirectory()); 360 } catch (IOException e) { 361 throw new IIOException("Can't create cache file!", e); 362 } 363 } 364 } So far I can see that means it will claim any Exception that is generated is because it could not create the cache file without any proof of that and even if "useCache" is false. It seems to imply to me that the author was not considering things like someone passing a closed InputStream .. probably we ought to be more vague in this case or look more deeply at what we can tell from whether it is IIOE or IOE. -phil. On 3/22/16, 10:49 AM, Jayathirth D V wrote: Thanks for the review Sergey. Can I get +1 for this please? -Jay -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, March 22, 2016 9:52 PM To: Jayathirth D V; Philip Race Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream This fix looks fine to me. At least it made all code work in a similar way. But probably someone will have other opinion? On 22.03.16 12:34, Jayathirth D V wrote: Hi Sergey, I have unified changes related to ImageIO.read() and ImageIO.write(). In case of read() we will be returning null when createImageInputStream() returns null. In case of write() we will be returning false when createImageOutputStream() returns null. Please find updated webrev for review: HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8044289/webrev.03/"http://cr.openjdk.java.net/~jdv/8044289/webrev.03/ Thanks, Jay -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, March 22, 2016 7:39 AM To: Jayathirth D V; Philip Race Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream Hi, Jay. Since we decided to update the specification we get an additional flexibility in the fix, because we can update the "@exception IOException" part of javadoc and describe that it can be thrown if ImageXXXStream cannot be created. I don't see a big differences of both approaches in case of write() methods, but in case of read(which has the similar issue but was skipped in the fix) there is a difference. Note that the read(File) unlike other methods throws the unspecified IIOException exception if ImageXXXStream cannot be created. We can think about unification of read/write methods in ImageIO. Hmm but even then read() in some cases will return null and in some cases throw an exception.... and createImageInputStream/createImageOutputStream() will look alien as they always return null not an exception. Another possible unification is to update javadoc for all methods, that they will return null if related providers are not found(in this case "throw new IIOException("Can't create an ImageInputStream!"))" should be removed from read(File); On 21.03.16 10:26, Jayathirth D V wrote: Hi Sergey, For the second approach I have created webrev for review. Please review updated webrev : HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8044289/webrev.02/"http://cr.openjdk.java.net/~jdv/8044289/webrev.02/ Thanks, Jay -----Original Message----- From: Jayathirth D V Sent: Friday, March 18, 2016 2:23 PM To: Sergey Bylokhov Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net; Philip Race Subject: RE: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream Hi Sergey, Thanks for your inputs. Indeed all the null values returned by createImageInputStream() and createImageInputStream() are valid only. I went through the code more and found that there is no need for fix in ImageIO.read() methods as null stream is handled in read(ImageInputStream stream) which is called by all the remaining read() API's through IAE. So i can remove the changes made in ImageIO.read() functions. Also istream is closed in finally block of read(url). For ImageIO.write(File) & ImageIO.write(OutputStream) NPE we have two approaches for fix: 1) Keep the present changes of throwing IOException when stream is null and change the throw clause of write() spec mentioning: "IOException - if an error occurs during writing or not able to create required ImageOutputStream" 2) Remove the present changes and handle null in doWrite() method by returning false when stream is null & add code in finally block to close the stream only when stream is not null. Along with this we can also change Returns clause of spec to mention that write() might return false when we are not able to create ImageOutputStream. private static boolean doWrite(RenderedImage im, ImageWriter writer, ImageOutputStream output) throws IOException { if (writer == null) { return false; } + if (output == null) { + return false; + } try { return doWrite(im, writer, stream); } finally { + if (stream != null) stream.close(); } Returns : false if no appropriate writer is found or not able to create required ImageOutputStream. Please let me know your inputs. Thanks, Jay -----Original Message----- From: Sergey Bylokhov Sent: Friday, March 18, 2016 12:24 AM To: Jayathirth D V Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net; Philip Race Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream On 17.03.16 21:14, Jayathirth D V wrote: There are many places in createImageInputStream() and createImageOutputStream() where it will return null for stream. But when why you change the write/read methods? They should take null into account and work according to specification. If some bogus null returns from createImageInputStream/createImageOutputStream then it should be fixed in these methods. So for NPE described in bug to occur there can be multiple paths: 1) One of the path described in bug is when theRegistry.getServiceProviders() throws IAE and we return null. This is the case when we have no installed spi and should return null/false. 2) When we pass non-existent file path to ImageIO (as described in http://stackoverflow.com/questions/11153200/with-imageio-write-api-call-i-get-nullpointerexception ). Here we catch FileNotFoundException but still we return stream as null at the end which will cause NPE further. This is same thing described in the bug(about stream.close()). The write method call createImageOutputStream() and got FileNotFoundException. This exception should be propagated to the user, but it is replaced in the finally block, because we try to close the stream=null. So the fix for this particular case is to check the stream to null in finally, No? 3) When we don't support the provider and theRegistry.getServiceProviders() return iterator with size zero. This means that our providers do not support this case, and we should return null/false. For us to follow first scenario we need access to categoryMap of IIORegistry and delete the ImageInputStreamSpi/ ImageOutputStreamSpi but I was not able to find a way to tamper it from test case. If we follow second case FileNotFoundException will be thrown by default eventhough we handle NPE. But you change the code and we now contradicts the specification, in your case the test should expect false/null from write()/read(). In the test case we are trying to following third scenario to get stream as null to verify the code changes. To catch the bogus null we should try to use another approach, or change the spec. But it seems all null values above are correct, we should be ready for them. As part of collective fix we are throwing IOException which will indicate that we are not able to create required stream. Thanks, Jay -----Original Message----- From: Sergey Bylokhov Sent: Thursday, March 17, 2016 7:27 PM To: Phil Race Cc: Jayathirth D V; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream On 17.03.16 0:36, Phil Race wrote: I don't think that is the actual reason here But the test doing exactly this thing -> deregister all spi => in this case according to specification all related methods(read/write/creatImageInputStream/creatImageOutputStream) should return null or false. - it seems likely that there was some kind of internal error or bad SPI causing this. So throwing an exception seems more appropriate. the problem was in some of our methods which do not expect null in some places(like stream.close() from the bug description). And also the bug was originally solely about write(..). -phil. On 03/16/2016 01:35 PM, Sergey Bylokhov wrote: As far as I understand the createImageInputStream() returns null is this stream is unsupported by current plugins via spi. Probably the read() method should return null too? /** * Returns a {@code BufferedImage} as the result of decoding * a supplied {@code InputStream} with an {@code ImageReader} * chosen automatically from among those currently registered. * The {@code InputStream} is wrapped in an * {@code ImageInputStream}. If no registered * {@code ImageReader} claims to be able to read the * resulting stream, {@code null} is returned. * ....... * @return a {@code BufferedImage} containing the decoded * contents of the input, or {@code null}. */ public static BufferedImage read(InputStream input) throws IOException On 16.03.16 20:29, Philip Race wrote: The test writes out into "test.src". I believe that you should treat that as a "read-only" location. Write to a tempfile (File.createTempFile()) or TESTCLASSES. -phil. On 3/15/16, 10:50 PM, Jayathirth D V wrote: Hi Phil,All _Please review the following fix in JDK9:_ __ Bug : https://bugs.openjdk.java.net/browse/JDK-8044289 Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8044289/webrev.00/"http://cr.openjdk.java.net/~jdv/8044289/webrev.00/ HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8044289/webrev.00/" Issue : When createImageInputStream() or createImageOutputStream returns null in ImageIO.read() or ImageIO.write() we are seeing NPE as it stream is used further without null check. Root cause : "stream" is used without checking whether it is null or not. Solution : Handle null pointer of stream and throw IIOException. Test case contains all possible scenarios where createImageInputStream() or createImageOutputStream can return null. Thanks, Jay -- Best regards, Sergey. -- Best regards, Sergey. -- Best regards, Sergey. -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Tue Mar 29 09:31:25 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Tue, 29 Mar 2016 15:01:25 +0530 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream In-Reply-To: References: <99cb1549-30b5-44af-b399-ebed22255cf8@default> <56E997F1.2070605@oracle.com> <56E9C39D.6090701@oracle.com> <56E9D1D5.8090500@oracle.com> <56EAB79C.1080503@oracle.com> <88e50a67-fdd2-4b97-aa19-3ac5d419e2cf@default> <56EAFD38.80604@oracle.com> <56F0A94C.8080703@oracle.com> <56F17140.2070208@oracle.com> <481ff313-103f-4a71-bec9-44a3fa0a70ef@default> <56F3294E.1040306@oracle.com> <387cc752-40cd-4d3a-9350-e53193d80dfd@default> <56F9AC5E.8010107@oracle.com> <56FA41FF.9000704@oracle.com> Message-ID: <56FA4B6D.80408@oracle.com> Looks ok. Regards Prasanta On 3/29/2016 2:57 PM, Jayathirth D V wrote: > > Hi Prasanta, > > Actually returns null in test description is for > createImageXXXStream() and not for read() and write() functions. But > for more clarity I have added why we catch IOException also in test > description. > > Please review the updated webrev: > > http://cr.openjdk.java.net/~jdv/8044289/webrev.05/ > > > Thanks, > > Jay > > *From:*prasanta sadhukhan > *Sent:* Tuesday, March 29, 2016 2:21 PM > *To:* Jayathirth D V > *Cc:* Philip Race; 2d-dev at openjdk.java.net > *Subject:* Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In > ImageIO.read() and write() NPE is not handled properly for stream > > +1. > Looks ok to me. Only thing is that whether the test summary is > appropriate " > > Test verifies that when createImageInputStream() or > 28 * createImageOutputStream() returns null while read or write," > Should it not be "verifies whether ...throws appropriate exception"? > Regards > Prasanta > > On 3/29/2016 3:42 AM, Philip Race wrote: > > This all looks fine to me. Although no new Exception types are thrown > I think we need a CCC anyway, so please prepare and get that approved > before pushing. > > -phil. > > On 3/28/16, 3:30 AM, Jayathirth D V wrote: > > Hi Phil, > > After discussion with Sergey we have come to conclusion that > Sergey is okay with throwing exception or returning null/false. > > So I have modified the webrev to throw exception. > > Also in write() I have modified the catch block to just throw > the caught exception without adding message since it will > create confusion between the case where we are not able to > create cache and when createImageOutputStream() returns null. > > Regarding catch block of createImageOutputStream() only when > we usecache is true we use FileCacheImageOutputStream() and it > throws IOException so I think there is no need to add extra > check before throwing IOException. > > Please find updated webrev for review : > > http://cr.openjdk.java.net/~jdv/8044289/webrev.04/ > > > Thanks, > > Jay > > *From:*Jayathirth D V > *Sent:* Thursday, March 24, 2016 3:52 PM > *To:* Philip Race > *Cc:* Sergey Bylokhov; 2d-dev at openjdk.java.net > > *Subject:* RE: [OpenJDK 2D-Dev] Review Request for JDK-8044289 > : In ImageIO.read() and write() NPE is not handled properly > for stream > > Hi Phil, > > We can change the code to something like : > > 1522 * @return false if no appropriate > writer is found or > > 1523 * when needed stream is null. > > 1545 try { > > 1546 output.delete(); > > 1547 stream = createImageOutputStream(output); > > 1548 } catch (IOException e) { > > 1549 *throw e;* > > 1550 } > > In this case we will be throwing IOException when we are not > able to create cache file and stream is null. > > And return null/false when createImageXXXStream returns null. > Also we can add check before throwing IIOException from > createImageXXXStream for usecache. > > 350 > > 351 boolean usecache = getUseCache() && > hasCachePermission(); > > 352 > > 353 while (iter.hasNext()) { > > 354 ImageInputStreamSpi spi = iter.next(); > > 355 if (spi.getInputClass().isInstance(input)) { > > 356 try { > > 357 return > spi.createInputStreamInstance(input, > > 358 > usecache, > > 359 > getCacheDirectory()); > > 360 } catch (IOException e) { > > 361 *if (usecache)* > > 362 throw new IIOException("Can't > create cache file!", e); > > 363 } > > 364 } > > 365 } > > This will be one of the approach. > > Or we can throw IOException in all the cases with additional > check in createImageXXXStream for usecache. This will be like > throwing IOException when createImageXXXStream returns > null/false or it throws IIOException when it cant create cache > file. This will be another approach. Please let us know your > inputs. > > Thanks, > > Jay > > *From:*Philip Race > *Sent:* Thursday, March 24, 2016 5:10 AM > *To:* Jayathirth D V > *Cc:* Sergey Bylokhov; 2d-dev at openjdk.java.net > > *Subject:* Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 > : In ImageIO.read() and write() NPE is not handled properly > for stream > > I don't think this is ready and we need to discuss whether to > rework it. > > In general I think I prefer IIO rather than null when we have a stream problem. > > > For one thing you have this change :- > > 1522 * @return false if no appropriate > writer is found or > > 1523 * not able to create required ImageOutputStream. > > yet the implementation says :- > > 1545 try { > > 1546 output.delete(); > > 1547 stream = createImageOutputStream(output); > > 1548 } catch (IOException e) { > > 1549 throw new IIOException("Can't create output stream!", e); > > 1550 } > > > > > > So whilst "null" would mean we cannot find an IOS SPI it isn't > > the only reason we fail to create the IOS > > A null return seems to get passed through to doWrite() which probably throws IIOE > > And I think that the implementation is actually right here where > > it throws an exception. > > > > The ability to create an image input or output stream could be because > > of some kind of problem opening the file, or with the IIS or IOS implementations - > > like they were de-registered. I think in many if not all of these cases IOE - or IIOE is > > what we want. > > > > Also since we call createImageInputStream() - which is public - we > > need to look at that, and what it does, which is also something to consider. > > If it returns null, that seems to mean that no suitable SPI is registered > > which can only happen if they are de-registered. For the methods where > > we use createImageInputStream() I think it is fair to turn that into IIOE > > > > BTW I note that the code there says :- > > 350 > > 351 boolean usecache = getUseCache() && hasCachePermission(); > > 352 > > 353 while (iter.hasNext()) { > > 354 ImageInputStreamSpi spi = iter.next(); > > 355 if (spi.getInputClass().isInstance(input)) { > > 356 try { > > 357 return spi.createInputStreamInstance(input, > > 358 usecache, > > 359 getCacheDirectory()); > > 360 } catch (IOException e) { > > 361 throw new IIOException("Can't create cache file!", e); > > 362 } > > 363 } > > 364 } > > > > So far I can see that means it will claim any Exception that is generated is because it > > could not create the cache file without any proof of that and even if "useCache" is false. > > It seems to imply to me that the author was not considering things like someone > > passing a closed InputStream .. probably we ought to be more vague in this case > > or look more deeply at what we can tell from whether it is IIOE or IOE. > > > > -phil. > > > > > > On 3/22/16, 10:49 AM, Jayathirth D V wrote: > > Thanks for the review Sergey. > > Can I get +1 for this please? > > > > -Jay > > > > -----Original Message----- > > From: Sergey Bylokhov > > Sent: Tuesday, March 22, 2016 9:52 PM > > To: Jayathirth D V; Philip Race > > Cc:2d-dev at openjdk.java.net > > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream > > > > This fix looks fine to me. > > At least it made all code work in a similar way. But probably someone will have other opinion? > > > > On 22.03.16 12:34, Jayathirth D V wrote: > > Hi Sergey, > > > > I have unified changes related to ImageIO.read() and ImageIO.write(). > > > > In case of read() we will be returning null when createImageInputStream() returns null. > > In case of write() we will be returning false when createImageOutputStream() returns null. > > > > Please find updated webrev for review: > > http://cr.openjdk.java.net/~jdv/8044289/webrev.03/ > > > > > Thanks, > > Jay > > > > -----Original Message----- > > From: Sergey Bylokhov > > Sent: Tuesday, March 22, 2016 7:39 AM > > To: Jayathirth D V; Philip Race > > Cc:2d-dev at openjdk.java.net > > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In > > ImageIO.read() and write() NPE is not handled properly for stream > > > > Hi, Jay. > > Since we decided to update the specification we get an additional flexibility in the fix, because we can update the "@exception IOException" part of javadoc and describe that it can be thrown if ImageXXXStream cannot be created. > > > > I don't see a big differences of both approaches in case of write() methods, but in case of read(which has the similar issue but was skipped in the fix) there is a difference. > > Note that the read(File) unlike other methods throws the unspecified > > IIOException exception if ImageXXXStream cannot be created. We can > > think about unification of read/write methods in ImageIO. Hmm but even > > then > > read() in some cases will return null and in some cases throw an exception.... > > and createImageInputStream/createImageOutputStream() will look alien as they always return null not an exception. > > > > Another possible unification is to update javadoc for all methods, > > that they will return null if related providers are not found(in this > > case "throw new IIOException("Can't create an ImageInputStream!"))" > > should be removed from read(File); > > > > On 21.03.16 10:26, Jayathirth D V wrote: > > Hi Sergey, > > > > For the second approach I have created webrev for review. > > > > Please review updated webrev : > > http://cr.openjdk.java.net/~jdv/8044289/webrev.02/ > > > > > Thanks, > > Jay > > > > -----Original Message----- > > From: Jayathirth D V > > Sent: Friday, March 18, 2016 2:23 PM > > To: Sergey Bylokhov > > Cc:2d-dev at openjdk.java.net > ; Philip Race > > Subject: RE: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In > > ImageIO.read() and write() NPE is not handled properly for stream > > > > Hi Sergey, > > > > Thanks for your inputs. > > > > Indeed all the null values returned by createImageInputStream() and createImageInputStream() are valid only. > > > > I went through the code more and found that there is no need for fix in ImageIO.read() methods as null stream is handled in read(ImageInputStream stream) which is called by all the remaining read() API's through IAE. So i can remove the changes made in ImageIO.read() functions. Also istream is closed in finally block of read(url). > > > > For ImageIO.write(File) & ImageIO.write(OutputStream) NPE we have two approaches for fix: > > > > 1) Keep the present changes of throwing IOException when stream is null and change the throw clause of write() spec mentioning: > > "IOException - if an error occurs during writing or not able to create required ImageOutputStream" > > > > 2) Remove the present changes and handle null in doWrite() method by returning false when stream is null & add code in finally block to close the stream only when stream is not null. Along with this we can also change Returns clause of spec to mention that write() might return false when we are not able to create ImageOutputStream. > > > > private static boolean doWrite(RenderedImage im, ImageWriter writer, > > ImageOutputStream output) throws IOException { > > if (writer == null) { > > return false; > > } > > + if (output == null) { > > + return false; > > + } > > > > try { > > return doWrite(im, writer, stream); > > } finally { > > + if (stream != null) > > stream.close(); > > } > > > > Returns : > > false if no appropriate writer is found or not able to create required ImageOutputStream. > > > > Please let me know your inputs. > > > > Thanks, > > Jay > > > > -----Original Message----- > > From: Sergey Bylokhov > > Sent: Friday, March 18, 2016 12:24 AM > > To: Jayathirth D V > > Cc:2d-dev at openjdk.java.net > ; Philip Race > > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In > > ImageIO.read() and write() NPE is not handled properly for stream > > > > On 17.03.16 21:14, Jayathirth D V wrote: > > There are many places in createImageInputStream() and createImageOutputStream() where it will return null for stream. > > > > But when why you change the write/read methods? They should take null into account and work according to specification. If some bogus null returns from createImageInputStream/createImageOutputStream then it should be fixed in these methods. > > > > So for NPE described in bug to occur there can be multiple paths: > > 1) One of the path described in bug is when theRegistry.getServiceProviders() throws IAE and we return null. > > > > This is the case when we have no installed spi and should return null/false. > > > > 2) When we pass non-existent file path to ImageIO (as described inhttp://stackoverflow.com/questions/11153200/with-imageio-write-api-call-i-get-nullpointerexception ). Here we catch FileNotFoundException but still we return stream as null at the end which will cause NPE further. > > > > This is same thing described in the bug(about stream.close()). The write method call createImageOutputStream() and got FileNotFoundException. > > This exception should be propagated to the user, but it is replaced in the finally block, because we try to close the stream=null. So the fix for this particular case is to check the stream to null in finally, No? > > > > 3) When we don't support the provider and theRegistry.getServiceProviders() return iterator with size zero. > > > > This means that our providers do not support this case, and we should return null/false. > > > > > > For us to follow first scenario we need access to categoryMap of IIORegistry and delete the ImageInputStreamSpi/ ImageOutputStreamSpi but I was not able to find a way to tamper it from test case. If we follow second case FileNotFoundException will be thrown by default eventhough we handle NPE. > > > > But you change the code and we now contradicts the specification, in your case the test should expect false/null from write()/read(). > > > > > > In the test case we are trying to following third scenario to get stream as null to verify the code changes. > > > > To catch the bogus null we should try to use another approach, or change the spec. But it seems all null values above are correct, we should be ready for them. > > > > > > As part of collective fix we are throwing IOException which will indicate that we are not able to create required stream. > > > > Thanks, > > Jay > > > > -----Original Message----- > > From: Sergey Bylokhov > > Sent: Thursday, March 17, 2016 7:27 PM > > To: Phil Race > > Cc: Jayathirth D V;2d-dev at openjdk.java.net > > > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In > > ImageIO.read() and write() NPE is not handled properly for stream > > > > On 17.03.16 0:36, Phil Race wrote: > > I don't think that is the actual reason here > > > > But the test doing exactly this thing -> deregister all spi => in > > this case according to specification all related > > methods(read/write/creatImageInputStream/creatImageOutputStream) should return null or false. > > > > - it seems likely that there > > was some kind of internal error or bad SPI causing this. > > So throwing an exception seems more appropriate. > > > > the problem was in some of our methods which do not expect null in some places(like stream.close() from the bug description). > > > > And also the bug was originally solely about write(..). > > > > -phil. > > > > > > On 03/16/2016 01:35 PM, Sergey Bylokhov wrote: > > As far as I understand the createImageInputStream() returns null > > is this stream is unsupported by current plugins via spi. Probably > > the > > read() method should return null too? > > > > /** > > * Returns a {@code BufferedImage} as the result of decoding > > * a supplied {@code InputStream} with an {@code ImageReader} > > * chosen automatically from among those currently registered. > > * The {@code InputStream} is wrapped in an > > * {@code ImageInputStream}. If no registered > > * {@code ImageReader} claims to be able to read the > > * resulting stream, {@code null} is returned. > > * > > ....... > > * @return a {@code BufferedImage} containing the decoded > > * contents of the input, or {@code null}. > > */ > > public static BufferedImage read(InputStream input) throws > > IOException > > > > > > On 16.03.16 20:29, Philip Race wrote: > > The test writes out into "test.src". > > I believe that you should treat that as a "read-only" location. > > Write to a tempfile (File.createTempFile()) or TESTCLASSES. > > > > -phil. > > > > On 3/15/16, 10:50 PM, Jayathirth D V wrote: > > > > Hi Phil,All > > > > _Please review the following fix in JDK9:_ > > > > __ > > > > Bug :https://bugs.openjdk.java.net/browse/JDK-8044289 > > > > Webrev :http://cr.openjdk.java.net/~jdv/8044289/webrev.00/ > > > > > > > > Issue : When createImageInputStream() or createImageOutputStream > > returns null in ImageIO.read() or ImageIO.write() we are seeing > > NPE as it stream is used further without null check. > > > > Root cause : "stream" is used without checking whether it is > > null or not. > > > > Solution : Handle null pointer of stream and throw IIOException. > > > > Test case contains all possible scenarios where > > createImageInputStream() or createImageOutputStream can return null. > > > > Thanks, > > > > Jay > > > > > > > > > > > > > > -- > > Best regards, Sergey. > > > > > > > > -- > > Best regards, Sergey. > > > > > > > > -- > > Best regards, Sergey. > > > > > > > > -- > > Best regards, Sergey. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Tue Mar 29 12:40:56 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 29 Mar 2016 15:40:56 +0300 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream In-Reply-To: <56F9AC5E.8010107@oracle.com> References: <99cb1549-30b5-44af-b399-ebed22255cf8@default> <56E997F1.2070605@oracle.com> <56E9C39D.6090701@oracle.com> <56E9D1D5.8090500@oracle.com> <56EAB79C.1080503@oracle.com> <88e50a67-fdd2-4b97-aa19-3ac5d419e2cf@default> <56EAFD38.80604@oracle.com> <56F0A94C.8080703@oracle.com> <56F17140.2070208@oracle.com> <481ff313-103f-4a71-bec9-44a3fa0a70ef@default> <56F3294E.1040306@oracle.com> <387cc752-40cd-4d3a-9350-e53193d80dfd@default> <56F9AC5E.8010107@oracle.com> Message-ID: <56FA77D8.3030108@oracle.com> I am not sure what is the reason of this code? 1546 try { 1547 output.delete(); 1548 stream = createImageOutputStream(output); 1549 } catch (IOException e) { 1550 throw e; 1551 } On 29.03.16 1:12, Philip Race wrote: > This all looks fine to me. Although no new Exception types are thrown > I think we need a CCC anyway, so please prepare and get that approved > before pushing. > > -phil. > > On 3/28/16, 3:30 AM, Jayathirth D V wrote: >> >> Hi Phil, >> >> After discussion with Sergey we have come to conclusion that Sergey is >> okay with throwing exception or returning null/false. >> >> So I have modified the webrev to throw exception. >> >> Also in write() I have modified the catch block to just throw the >> caught exception without adding message since it will create confusion >> between the case where we are not able to create cache and when >> createImageOutputStream() returns null. >> >> Regarding catch block of createImageOutputStream() only when we >> usecache is true we use FileCacheImageOutputStream() and it throws >> IOException so I think there is no need to add extra check before >> throwing IOException. >> >> Please find updated webrev for review : >> >> http://cr.openjdk.java.net/~jdv/8044289/webrev.04/ >> >> >> Thanks, >> >> Jay >> >> *From:*Jayathirth D V >> *Sent:* Thursday, March 24, 2016 3:52 PM >> *To:* Philip Race >> *Cc:* Sergey Bylokhov; 2d-dev at openjdk.java.net >> *Subject:* RE: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >> ImageIO.read() and write() NPE is not handled properly for stream >> >> Hi Phil, >> >> We can change the code to something like : >> >> 1522 * @return false if no appropriate writer is >> found or >> 1523 * when needed stream is null. >> >> 1545 try { >> 1546 output.delete(); >> 1547 stream = createImageOutputStream(output); >> 1548 } catch (IOException e) { >> 1549 *throw e;* >> 1550 } >> >> In this case we will be throwing IOException when we are not able to >> create cache file and stream is null. >> >> And return null/false when createImageXXXStream returns null. Also we >> can add check before throwing IIOException from createImageXXXStream >> for usecache. >> >> 350 >> 351 boolean usecache = getUseCache() && hasCachePermission(); >> 352 >> 353 while (iter.hasNext()) { >> 354 ImageInputStreamSpi spi = iter.next(); >> 355 if (spi.getInputClass().isInstance(input)) { >> 356 try { >> 357 return spi.createInputStreamInstance(input, >> 358 usecache, >> 359 >> getCacheDirectory()); >> 360 } catch (IOException e) { >> 361 *if (usecache)* >> 362 throw new IIOException("Can't create cache >> file!", e); >> 363 } >> 364 } >> 365 } >> >> This will be one of the approach. >> >> Or we can throw IOException in all the cases with additional check in >> createImageXXXStream for usecache. This will be like throwing >> IOException when createImageXXXStream returns null/false or it throws >> IIOException when it cant create cache file. This will be another >> approach. Please let us know your inputs. >> >> Thanks, >> >> Jay >> >> *From:*Philip Race >> *Sent:* Thursday, March 24, 2016 5:10 AM >> *To:* Jayathirth D V >> *Cc:* Sergey Bylokhov; 2d-dev at openjdk.java.net >> >> *Subject:* Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >> ImageIO.read() and write() NPE is not handled properly for stream >> >> I don't think this is ready and we need to discuss whether to rework it. >> >> In general I think I prefer IIO rather than null when we have a stream problem. >> >> >> For one thing you have this change :- >> >> 1522 * @return false if no appropriate writer is >> found or >> 1523 * not able to create required ImageOutputStream. >> yet the implementation says :- >> 1545 try { >> 1546 output.delete(); >> 1547 stream = createImageOutputStream(output); >> 1548 } catch (IOException e) { >> 1549 throw new IIOException("Can't create output stream!", e); >> 1550 } >> So whilst "null" would mean we cannot find an IOS SPI it isn't >> the only reason we fail to create the IOS >> A null return seems to get passed through to doWrite() which probably throws IIOE >> And I think that the implementation is actually right here where >> it throws an exception. >> The ability to create an image input or output stream could be because >> of some kind of problem opening the file, or with the IIS or IOS implementations - >> like they were de-registered. I think in many if not all of these cases IOE - or IIOE is >> what we want. >> Also since we call createImageInputStream() - which is public - we >> need to look at that, and what it does, which is also something to consider. >> If it returns null, that seems to mean that no suitable SPI is registered >> which can only happen if they are de-registered. For the methods where >> we use createImageInputStream() I think it is fair to turn that into IIOE >> BTW I note that the code there says :- >> 350 >> 351 boolean usecache = getUseCache() && hasCachePermission(); >> 352 >> 353 while (iter.hasNext()) { >> 354 ImageInputStreamSpi spi = iter.next(); >> 355 if (spi.getInputClass().isInstance(input)) { >> 356 try { >> 357 return spi.createInputStreamInstance(input, >> 358 usecache, >> 359 getCacheDirectory()); >> 360 } catch (IOException e) { >> 361 throw new IIOException("Can't create cache file!", e); >> 362 } >> 363 } >> 364 } >> So far I can see that means it will claim any Exception that is generated is because it >> could not create the cache file without any proof of that and even if "useCache" is false. >> It seems to imply to me that the author was not considering things like someone >> passing a closed InputStream .. probably we ought to be more vague in this case >> or look more deeply at what we can tell from whether it is IIOE or IOE. >> -phil. >> >> On 3/22/16, 10:49 AM, Jayathirth D V wrote: >> >> Thanks for the review Sergey. >> >> Can I get +1 for this please? >> >> -Jay >> >> -----Original Message----- >> >> From: Sergey Bylokhov >> >> Sent: Tuesday, March 22, 2016 9:52 PM >> >> To: Jayathirth D V; Philip Race >> >> Cc:2d-dev at openjdk.java.net >> >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream >> >> This fix looks fine to me. >> >> At least it made all code work in a similar way. But probably someone will have other opinion? >> >> On 22.03.16 12:34, Jayathirth D V wrote: >> >> Hi Sergey, >> >> I have unified changes related to ImageIO.read() and ImageIO.write(). >> >> In case of read() we will be returning null when createImageInputStream() returns null. >> >> In case of write() we will be returning false when createImageOutputStream() returns null. >> >> Please find updated webrev for review: >> >> http://cr.openjdk.java.net/~jdv/8044289/webrev.03/ >> >> >> Thanks, >> >> Jay >> >> -----Original Message----- >> >> From: Sergey Bylokhov >> >> Sent: Tuesday, March 22, 2016 7:39 AM >> >> To: Jayathirth D V; Philip Race >> >> Cc:2d-dev at openjdk.java.net >> >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >> >> ImageIO.read() and write() NPE is not handled properly for stream >> >> Hi, Jay. >> >> Since we decided to update the specification we get an additional flexibility in the fix, because we can update the "@exception IOException" part of javadoc and describe that it can be thrown if ImageXXXStream cannot be created. >> >> I don't see a big differences of both approaches in case of write() methods, but in case of read(which has the similar issue but was skipped in the fix) there is a difference. >> >> Note that the read(File) unlike other methods throws the unspecified >> >> IIOException exception if ImageXXXStream cannot be created. We can >> >> think about unification of read/write methods in ImageIO. Hmm but even >> >> then >> >> read() in some cases will return null and in some cases throw an exception.... >> >> and createImageInputStream/createImageOutputStream() will look alien as they always return null not an exception. >> >> Another possible unification is to update javadoc for all methods, >> >> that they will return null if related providers are not found(in this >> >> case "throw new IIOException("Can't create an ImageInputStream!"))" >> >> should be removed from read(File); >> >> On 21.03.16 10:26, Jayathirth D V wrote: >> >> Hi Sergey, >> >> For the second approach I have created webrev for review. >> >> Please review updated webrev : >> >> http://cr.openjdk.java.net/~jdv/8044289/webrev.02/ >> >> >> Thanks, >> >> Jay >> >> -----Original Message----- >> >> From: Jayathirth D V >> >> Sent: Friday, March 18, 2016 2:23 PM >> >> To: Sergey Bylokhov >> >> Cc:2d-dev at openjdk.java.net ; Philip Race >> >> Subject: RE: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >> >> ImageIO.read() and write() NPE is not handled properly for stream >> >> Hi Sergey, >> >> Thanks for your inputs. >> >> Indeed all the null values returned by createImageInputStream() and createImageInputStream() are valid only. >> >> I went through the code more and found that there is no need for fix in ImageIO.read() methods as null stream is handled in read(ImageInputStream stream) which is called by all the remaining read() API's through IAE. So i can remove the changes made in ImageIO.read() functions. Also istream is closed in finally block of read(url). >> >> For ImageIO.write(File) & ImageIO.write(OutputStream) NPE we have two approaches for fix: >> >> 1) Keep the present changes of throwing IOException when stream is null and change the throw clause of write() spec mentioning: >> >> "IOException - if an error occurs during writing or not able to create required ImageOutputStream" >> >> 2) Remove the present changes and handle null in doWrite() method by returning false when stream is null & add code in finally block to close the stream only when stream is not null. Along with this we can also change Returns clause of spec to mention that write() might return false when we are not able to create ImageOutputStream. >> >> >> >> private static boolean doWrite(RenderedImage im, ImageWriter writer, >> >> ImageOutputStream output) throws IOException { >> >> if (writer == null) { >> >> return false; >> >> } >> >> + if (output == null) { >> >> + return false; >> >> + } >> >> >> >> try { >> >> return doWrite(im, writer, stream); >> >> } finally { >> >> + if (stream != null) >> >> stream.close(); >> >> } >> >> >> >> Returns : >> >> false if no appropriate writer is found or not able to create required ImageOutputStream. >> >> Please let me know your inputs. >> >> Thanks, >> >> Jay >> >> -----Original Message----- >> >> From: Sergey Bylokhov >> >> Sent: Friday, March 18, 2016 12:24 AM >> >> To: Jayathirth D V >> >> Cc:2d-dev at openjdk.java.net ; Philip Race >> >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >> >> ImageIO.read() and write() NPE is not handled properly for stream >> >> On 17.03.16 21:14, Jayathirth D V wrote: >> >> There are many places in createImageInputStream() and createImageOutputStream() where it will return null for stream. >> >> But when why you change the write/read methods? They should take null into account and work according to specification. If some bogus null returns from createImageInputStream/createImageOutputStream then it should be fixed in these methods. >> >> So for NPE described in bug to occur there can be multiple paths: >> >> 1) One of the path described in bug is when theRegistry.getServiceProviders() throws IAE and we return null. >> >> This is the case when we have no installed spi and should return null/false. >> >> 2) When we pass non-existent file path to ImageIO (as described inhttp://stackoverflow.com/questions/11153200/with-imageio-write-api-call-i-get-nullpointerexception ). Here we catch FileNotFoundException but still we return stream as null at the end which will cause NPE further. >> >> This is same thing described in the bug(about stream.close()). The write method call createImageOutputStream() and got FileNotFoundException. >> >> This exception should be propagated to the user, but it is replaced in the finally block, because we try to close the stream=null. So the fix for this particular case is to check the stream to null in finally, No? >> >> 3) When we don't support the provider and theRegistry.getServiceProviders() return iterator with size zero. >> >> This means that our providers do not support this case, and we should return null/false. >> >> For us to follow first scenario we need access to categoryMap of IIORegistry and delete the ImageInputStreamSpi/ ImageOutputStreamSpi but I was not able to find a way to tamper it from test case. If we follow second case FileNotFoundException will be thrown by default eventhough we handle NPE. >> >> But you change the code and we now contradicts the specification, in your case the test should expect false/null from write()/read(). >> >> In the test case we are trying to following third scenario to get stream as null to verify the code changes. >> >> To catch the bogus null we should try to use another approach, or change the spec. But it seems all null values above are correct, we should be ready for them. >> >> As part of collective fix we are throwing IOException which will indicate that we are not able to create required stream. >> >> Thanks, >> >> Jay >> >> -----Original Message----- >> >> From: Sergey Bylokhov >> >> Sent: Thursday, March 17, 2016 7:27 PM >> >> To: Phil Race >> >> Cc: Jayathirth D V;2d-dev at openjdk.java.net >> >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >> >> ImageIO.read() and write() NPE is not handled properly for stream >> >> On 17.03.16 0:36, Phil Race wrote: >> >> I don't think that is the actual reason here >> >> But the test doing exactly this thing -> deregister all spi => in >> >> this case according to specification all related >> >> methods(read/write/creatImageInputStream/creatImageOutputStream) should return null or false. >> >> - it seems likely that there >> >> was some kind of internal error or bad SPI causing this. >> >> So throwing an exception seems more appropriate. >> >> the problem was in some of our methods which do not expect null in some places(like stream.close() from the bug description). >> >> And also the bug was originally solely about write(..). >> >> -phil. >> >> On 03/16/2016 01:35 PM, Sergey Bylokhov wrote: >> >> As far as I understand the createImageInputStream() returns null >> >> is this stream is unsupported by current plugins via spi. Probably >> >> the >> >> read() method should return null too? >> >> /** >> >> * Returns a {@code BufferedImage} as the result of decoding >> >> * a supplied {@code InputStream} with an {@code ImageReader} >> >> * chosen automatically from among those currently registered. >> >> * The {@code InputStream} is wrapped in an >> >> * {@code ImageInputStream}. If no registered >> >> * {@code ImageReader} claims to be able to read the >> >> * resulting stream, {@code null} is returned. >> >> * >> >> ....... >> >> * @return a {@code BufferedImage} containing the decoded >> >> * contents of the input, or {@code null}. >> >> */ >> >> public static BufferedImage read(InputStream input) throws >> >> IOException >> >> On 16.03.16 20:29, Philip Race wrote: >> >> The test writes out into "test.src". >> >> I believe that you should treat that as a "read-only" location. >> >> Write to a tempfile (File.createTempFile()) or TESTCLASSES. >> >> -phil. >> >> On 3/15/16, 10:50 PM, Jayathirth D V wrote: >> >> Hi Phil,All >> >> _Please review the following fix in JDK9:_ >> >> __ >> >> Bug :https://bugs.openjdk.java.net/browse/JDK-8044289 >> >> Webrev :http://cr.openjdk.java.net/~jdv/8044289/webrev.00/ >> >> >> >> >> >> Issue : When createImageInputStream() or createImageOutputStream >> >> returns null in ImageIO.read() or ImageIO.write() we are seeing >> >> NPE as it stream is used further without null check. >> >> Root cause : "stream" is used without checking whether it is >> >> null or not. >> >> Solution : Handle null pointer of stream and throw IIOException. >> >> Test case contains all possible scenarios where >> >> createImageInputStream() or createImageOutputStream can return null. >> >> Thanks, >> >> Jay >> >> -- >> >> Best regards, Sergey. >> >> -- >> >> Best regards, Sergey. >> >> -- >> >> Best regards, Sergey. >> >> -- >> >> Best regards, Sergey. >> -- Best regards, Sergey. From alexander.potochkin at oracle.com Tue Mar 29 14:16:04 2016 From: alexander.potochkin at oracle.com (Alexander Potochkin) Date: Tue, 29 Mar 2016 17:16:04 +0300 Subject: [OpenJDK 2D-Dev] CFV: New 2D Group Member: Alexander Scherbatiy In-Reply-To: <56EB3465.7070709@oracle.com> References: <56EB3465.7070709@oracle.com> Message-ID: <56FA8E24.6080805@oracle.com> Vote: yes On 3/18/2016 01:49, Philip Race wrote: > I hereby nominate Alexander Scherbatiy to membership in the 2D group. > > Alexander Scherbatiy is a current member of the Swing group > and has contributed almost 200 changesets to OpenJDK :- > http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000&rev=author%28%22alexsch%22%29 > > Increasingly, and particularly over the last 18 months he has made many > of these significant contributions in the 2D area notably hi-dpi > graphics support and so I hereby nominate Alexander to membership of > the 2D group > > Votes are due by 1st April 2016 > > //Only current Members of the 2D Group [1] are eligible to vote on > this nomination. > For Lazy Consensus voting instructions, see [2]. > > [1] http://openjdk.java.net/census#2d > > [2] http://openjdk.java.net/groups/#member-vote > > > -phil -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Tue Mar 29 17:07:52 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 29 Mar 2016 10:07:52 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream In-Reply-To: References: <99cb1549-30b5-44af-b399-ebed22255cf8@default> <56E997F1.2070605@oracle.com> <56E9C39D.6090701@oracle.com> <56E9D1D5.8090500@oracle.com> <56EAB79C.1080503@oracle.com> <88e50a67-fdd2-4b97-aa19-3ac5d419e2cf@default> <56EAFD38.80604@oracle.com> <56F0A94C.8080703@oracle.com> <56F17140.2070208@oracle.com> <481ff313-103f-4a71-bec9-44a3fa0a70ef@default> <56F3294E.1040306@oracle.com> <387cc752-40cd-4d3a-9350-e53193d80dfd@default> <56F9AC5E.8010107@oracle.com> <56FA41FF.9000704@oracle.com> Message-ID: <56FAB668.3000106@oracle.com> This is OK but you ought to remember that read() and write() only HAPPEN to use createImageXXXStream(). They could get the stream in some other way and still be a spec. compliant implementation. -phil. On 03/29/2016 02:27 AM, Jayathirth D V wrote: > > Hi Prasanta, > > Actually returns null in test description is for > createImageXXXStream() and not for read() and write() functions. But > for more clarity I have added why we catch IOException also in test > description. > > Please review the updated webrev: > > http://cr.openjdk.java.net/~jdv/8044289/webrev.05/ > > > Thanks, > > Jay > > *From:*prasanta sadhukhan > *Sent:* Tuesday, March 29, 2016 2:21 PM > *To:* Jayathirth D V > *Cc:* Philip Race; 2d-dev at openjdk.java.net > *Subject:* Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In > ImageIO.read() and write() NPE is not handled properly for stream > > +1. > Looks ok to me. Only thing is that whether the test summary is > appropriate " > > Test verifies that when createImageInputStream() or > 28 * createImageOutputStream() returns null while read or write," > Should it not be "verifies whether ...throws appropriate exception"? > > Regards > Prasanta > > On 3/29/2016 3:42 AM, Philip Race wrote: > > This all looks fine to me. Although no new Exception types are thrown > I think we need a CCC anyway, so please prepare and get that approved > before pushing. > > -phil. > > On 3/28/16, 3:30 AM, Jayathirth D V wrote: > > Hi Phil, > > After discussion with Sergey we have come to conclusion that > Sergey is okay with throwing exception or returning null/false. > > So I have modified the webrev to throw exception. > > Also in write() I have modified the catch block to just throw > the caught exception without adding message since it will > create confusion between the case where we are not able to > create cache and when createImageOutputStream() returns null. > > Regarding catch block of createImageOutputStream() only when > we usecache is true we use FileCacheImageOutputStream() and it > throws IOException so I think there is no need to add extra > check before throwing IOException. > > Please find updated webrev for review : > > http://cr.openjdk.java.net/~jdv/8044289/webrev.04/ > > > Thanks, > > Jay > > *From:*Jayathirth D V > *Sent:* Thursday, March 24, 2016 3:52 PM > *To:* Philip Race > *Cc:* Sergey Bylokhov; 2d-dev at openjdk.java.net > > *Subject:* RE: [OpenJDK 2D-Dev] Review Request for JDK-8044289 > : In ImageIO.read() and write() NPE is not handled properly > for stream > > Hi Phil, > > We can change the code to something like : > > 1522 * @return false if no appropriate writer is found or > > 1523 * when needed stream is null. > > 1545 try { > > 1546 output.delete(); > > 1547 stream = createImageOutputStream(output); > > 1548 } catch (IOException e) { > > 1549*throw e;* > > 1550 } > > In this case we will be throwing IOException when we are not > able to create cache file and stream is null. > > And return null/false when createImageXXXStream returns null. > Also we can add check before throwing IIOException from > createImageXXXStream for usecache. > > 350 > > 351 boolean usecache = getUseCache() && hasCachePermission(); > > 352 > > 353 while (iter.hasNext()) { > > 354 ImageInputStreamSpi spi = iter.next(); > > 355 if (spi.getInputClass().isInstance(input)) { > > 356 try { > > 357 return spi.createInputStreamInstance(input, > > 358 usecache, > > 359 getCacheDirectory()); > > 360 } catch (IOException e) { > > 361*if (usecache)* > > 362 throw new IIOException("Can't create cache file!", e); > > 363 } > > 364 } > > 365 } > > This will be one of the approach. > > Or we can throw IOException in all the cases with additional > check in createImageXXXStream for usecache. This will be like > throwing IOException when createImageXXXStream returns > null/false or it throws IIOException when it cant create cache > file. This will be another approach. Please let us know your > inputs. > > Thanks, > > Jay > > *From:*Philip Race > *Sent:* Thursday, March 24, 2016 5:10 AM > *To:* Jayathirth D V > *Cc:* Sergey Bylokhov; 2d-dev at openjdk.java.net > > *Subject:* Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 > : In ImageIO.read() and write() NPE is not handled properly > for stream > > I don't think this is ready and we need to discuss whether to > rework it. > > In general I think I prefer IIO rather than null when we have a stream problem. > > > For one thing you have this change :- > > 1522 * @return false if no appropriate writer is found or > > 1523 * not able to create required ImageOutputStream. > > > > yet the implementation says :- > > 1545 try { > > 1546 output.delete(); > > 1547 stream = createImageOutputStream(output); > > 1548 } catch (IOException e) { > > 1549 throw new IIOException("Can't create output stream!", e); > > 1550 } > > > > > > So whilst "null" would mean we cannot find an IOS SPI it isn't > > the only reason we fail to create the IOS > > A null return seems to get passed through to doWrite() which probably throws IIOE > > And I think that the implementation is actually right here where > > it throws an exception. > > > > The ability to create an image input or output stream could be because > > of some kind of problem opening the file, or with the IIS or IOS implementations - > > like they were de-registered. I think in many if not all of these cases IOE - or IIOE is > > what we want. > > > > Also since we call createImageInputStream() - which is public - we > > need to look at that, and what it does, which is also something to consider. > > If it returns null, that seems to mean that no suitable SPI is registered > > which can only happen if they are de-registered. For the methods where > > we use createImageInputStream() I think it is fair to turn that into IIOE > > > > BTW I note that the code there says :- > > 350 > > 351 boolean usecache = getUseCache() && hasCachePermission(); > > 352 > > 353 while (iter.hasNext()) { > > 354 ImageInputStreamSpi spi = iter.next(); > > 355 if (spi.getInputClass().isInstance(input)) { > > 356 try { > > 357 return spi.createInputStreamInstance(input, > > 358 usecache, > > 359 getCacheDirectory()); > > 360 } catch (IOException e) { > > 361 throw new IIOException("Can't create cache file!", e); > > 362 } > > 363 } > > 364 } > > > > So far I can see that means it will claim any Exception that is generated is because it > > could not create the cache file without any proof of that and even if "useCache" is false. > > It seems to imply to me that the author was not considering things like someone > > passing a closed InputStream .. probably we ought to be more vague in this case > > or look more deeply at what we can tell from whether it is IIOE or IOE. > > > > -phil. > > > > > > On 3/22/16, 10:49 AM, Jayathirth D V wrote: > > Thanks for the review Sergey. > > Can I get +1 for this please? > > > > -Jay > > > > -----Original Message----- > > From: Sergey Bylokhov > > Sent: Tuesday, March 22, 2016 9:52 PM > > To: Jayathirth D V; Philip Race > > Cc:2d-dev at openjdk.java.net > > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream > > > > This fix looks fine to me. > > At least it made all code work in a similar way. But probably someone will have other opinion? > > > > On 22.03.16 12:34, Jayathirth D V wrote: > > Hi Sergey, > > > > I have unified changes related to ImageIO.read() and ImageIO.write(). > > > > In case of read() we will be returning null when createImageInputStream() returns null. > > In case of write() we will be returning false when createImageOutputStream() returns null. > > > > Please find updated webrev for review: > > http://cr.openjdk.java.net/~jdv/8044289/webrev.03/ > > > > Thanks, > > Jay > > > > -----Original Message----- > > From: Sergey Bylokhov > > Sent: Tuesday, March 22, 2016 7:39 AM > > To: Jayathirth D V; Philip Race > > Cc:2d-dev at openjdk.java.net > > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In > > ImageIO.read() and write() NPE is not handled properly for stream > > > > Hi, Jay. > > Since we decided to update the specification we get an additional flexibility in the fix, because we can update the "@exception IOException" part of javadoc and describe that it can be thrown if ImageXXXStream cannot be created. > > > > I don't see a big differences of both approaches in case of write() methods, but in case of read(which has the similar issue but was skipped in the fix) there is a difference. > > Note that the read(File) unlike other methods throws the unspecified > > IIOException exception if ImageXXXStream cannot be created. We can > > think about unification of read/write methods in ImageIO. Hmm but even > > then > > read() in some cases will return null and in some cases throw an exception.... > > and createImageInputStream/createImageOutputStream() will look alien as they always return null not an exception. > > > > Another possible unification is to update javadoc for all methods, > > that they will return null if related providers are not found(in this > > case "throw new IIOException("Can't create an ImageInputStream!"))" > > should be removed from read(File); > > > > On 21.03.16 10:26, Jayathirth D V wrote: > > Hi Sergey, > > > > For the second approach I have created webrev for review. > > > > Please review updated webrev : > > http://cr.openjdk.java.net/~jdv/8044289/webrev.02/ > > > > Thanks, > > Jay > > > > -----Original Message----- > > From: Jayathirth D V > > Sent: Friday, March 18, 2016 2:23 PM > > To: Sergey Bylokhov > > Cc:2d-dev at openjdk.java.net ; Philip Race > > Subject: RE: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In > > ImageIO.read() and write() NPE is not handled properly for stream > > > > Hi Sergey, > > > > Thanks for your inputs. > > > > Indeed all the null values returned by createImageInputStream() and createImageInputStream() are valid only. > > > > I went through the code more and found that there is no need for fix in ImageIO.read() methods as null stream is handled in read(ImageInputStream stream) which is called by all the remaining read() API's through IAE. So i can remove the changes made in ImageIO.read() functions. Also istream is closed in finally block of read(url). > > > > For ImageIO.write(File) & ImageIO.write(OutputStream) NPE we have two approaches for fix: > > > > 1) Keep the present changes of throwing IOException when stream is null and change the throw clause of write() spec mentioning: > > "IOException - if an error occurs during writing or not able to create required ImageOutputStream" > > > > 2) Remove the present changes and handle null in doWrite() method by returning false when stream is null & add code in finally block to close the stream only when stream is not null. Along with this we can also change Returns clause of spec to mention that write() might return false when we are not able to create ImageOutputStream. > > > > private static boolean doWrite(RenderedImage im, ImageWriter writer, > > ImageOutputStream output) throws IOException { > > if (writer == null) { > > return false; > > } > > + if (output == null) { > > + return false; > > + } > > > > try { > > return doWrite(im, writer, stream); > > } finally { > > + if (stream != null) > > stream.close(); > > } > > > > Returns : > > false if no appropriate writer is found or not able to create required ImageOutputStream. > > > > Please let me know your inputs. > > > > Thanks, > > Jay > > > > -----Original Message----- > > From: Sergey Bylokhov > > Sent: Friday, March 18, 2016 12:24 AM > > To: Jayathirth D V > > Cc:2d-dev at openjdk.java.net ; Philip Race > > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In > > ImageIO.read() and write() NPE is not handled properly for stream > > > > On 17.03.16 21:14, Jayathirth D V wrote: > > There are many places in createImageInputStream() and createImageOutputStream() where it will return null for stream. > > > > But when why you change the write/read methods? They should take null into account and work according to specification. If some bogus null returns from createImageInputStream/createImageOutputStream then it should be fixed in these methods. > > > > So for NPE described in bug to occur there can be multiple paths: > > 1) One of the path described in bug is when theRegistry.getServiceProviders() throws IAE and we return null. > > > > This is the case when we have no installed spi and should return null/false. > > > > 2) When we pass non-existent file path to ImageIO (as described inhttp://stackoverflow.com/questions/11153200/with-imageio-write-api-call-i-get-nullpointerexception ). Here we catch FileNotFoundException but still we return stream as null at the end which will cause NPE further. > > > > This is same thing described in the bug(about stream.close()). The write method call createImageOutputStream() and got FileNotFoundException. > > This exception should be propagated to the user, but it is replaced in the finally block, because we try to close the stream=null. So the fix for this particular case is to check the stream to null in finally, No? > > > > 3) When we don't support the provider and theRegistry.getServiceProviders() return iterator with size zero. > > > > This means that our providers do not support this case, and we should return null/false. > > > > > > For us to follow first scenario we need access to categoryMap of IIORegistry and delete the ImageInputStreamSpi/ ImageOutputStreamSpi but I was not able to find a way to tamper it from test case. If we follow second case FileNotFoundException will be thrown by default eventhough we handle NPE. > > > > But you change the code and we now contradicts the specification, in your case the test should expect false/null from write()/read(). > > > > > > In the test case we are trying to following third scenario to get stream as null to verify the code changes. > > > > To catch the bogus null we should try to use another approach, or change the spec. But it seems all null values above are correct, we should be ready for them. > > > > > > As part of collective fix we are throwing IOException which will indicate that we are not able to create required stream. > > > > Thanks, > > Jay > > > > -----Original Message----- > > From: Sergey Bylokhov > > Sent: Thursday, March 17, 2016 7:27 PM > > To: Phil Race > > Cc: Jayathirth D V;2d-dev at openjdk.java.net > > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In > > ImageIO.read() and write() NPE is not handled properly for stream > > > > On 17.03.16 0:36, Phil Race wrote: > > I don't think that is the actual reason here > > > > But the test doing exactly this thing -> deregister all spi => in > > this case according to specification all related > > methods(read/write/creatImageInputStream/creatImageOutputStream) should return null or false. > > > > - it seems likely that there > > was some kind of internal error or bad SPI causing this. > > So throwing an exception seems more appropriate. > > > > the problem was in some of our methods which do not expect null in some places(like stream.close() from the bug description). > > > > And also the bug was originally solely about write(..). > > > > -phil. > > > > > > On 03/16/2016 01:35 PM, Sergey Bylokhov wrote: > > As far as I understand the createImageInputStream() returns null > > is this stream is unsupported by current plugins via spi. Probably > > the > > read() method should return null too? > > > > /** > > * Returns a {@code BufferedImage} as the result of decoding > > * a supplied {@code InputStream} with an {@code ImageReader} > > * chosen automatically from among those currently registered. > > * The {@code InputStream} is wrapped in an > > * {@code ImageInputStream}. If no registered > > * {@code ImageReader} claims to be able to read the > > * resulting stream, {@code null} is returned. > > * > > ....... > > * @return a {@code BufferedImage} containing the decoded > > * contents of the input, or {@code null}. > > */ > > public static BufferedImage read(InputStream input) throws > > IOException > > > > > > On 16.03.16 20:29, Philip Race wrote: > > The test writes out into "test.src". > > I believe that you should treat that as a "read-only" location. > > Write to a tempfile (File.createTempFile()) or TESTCLASSES. > > > > -phil. > > > > On 3/15/16, 10:50 PM, Jayathirth D V wrote: > > > > Hi Phil,All > > > > _Please review the following fix in JDK9:_ > > > > __ > > > > Bug :https://bugs.openjdk.java.net/browse/JDK-8044289 > > > > Webrev :http://cr.openjdk.java.net/~jdv/8044289/webrev.00/ > > > > > > Issue : When createImageInputStream() or createImageOutputStream > > returns null in ImageIO.read() or ImageIO.write() we are seeing > > NPE as it stream is used further without null check. > > > > Root cause : "stream" is used without checking whether it is > > null or not. > > > > Solution : Handle null pointer of stream and throw IIOException. > > > > Test case contains all possible scenarios where > > createImageInputStream() or createImageOutputStream can return null. > > > > Thanks, > > > > Jay > > > > > > > > > > > > > > -- > > Best regards, Sergey. > > > > > > > > -- > > Best regards, Sergey. > > > > > > > > -- > > Best regards, Sergey. > > > > > > > > -- > > Best regards, Sergey. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.v.stepanov at oracle.com Tue Mar 29 17:21:55 2016 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Tue, 29 Mar 2016 20:21:55 +0300 Subject: [OpenJDK 2D-Dev] RFR 8149028: [TEST] add test for TIFFDirectory In-Reply-To: <56F55D56.4090408@oracle.com> References: <56F55D56.4090408@oracle.com> Message-ID: <56FAB9B3.6050209@oracle.com> Please see the updated webrev: http://cr.openjdk.java.net/~avstepan/8149028/webrev.01/ (one more test was added). Thanks, Alexander On 3/25/2016 6:46 PM, Alexander Stepanov wrote: > Hello, > > Could you please review the following fix > http://cr.openjdk.java.net/~avstepan/8149028/webrev.00/ > for > https://bugs.openjdk.java.net/browse/JDK-8149028 > > Just a single test added. > > Thanks, > Alexander > From philip.race at oracle.com Tue Mar 29 17:47:26 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 29 Mar 2016 10:47:26 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8061258, , [macosx] PrinterJob's native Print Dialog does not reflect specified Copies or Page Ranges In-Reply-To: <56F38D77.4060207@oracle.com> References: <56F277CB.40207@oracle.com> <56F3220F.1020304@oracle.com> <56F38D77.4060207@oracle.com> Message-ID: <56FABFAE.5080008@oracle.com> Hi, You are calling these unconditionally : 387 jint minPage = JNFCallIntMethod(env, srcPrinterJob, jm_getMinPage); 388 jint maxPage = JNFCallIntMethod(env, srcPrinterJob, jm_getMaxPage); But it seems they are only used/needed in the else {..} Other than that it looks reasonable but I have not had time to apply the patch and verify it .. -phil. On 03/23/2016 11:47 PM, prasanta sadhukhan wrote: > Hi Phil, > > On 3/24/2016 4:39 AM, Philip Race wrote: >> >> >> On 3/23/16, 4:02 AM, prasanta sadhukhan wrote: >>> Hi Phil, >>> >>> Please review a fix for jdk9 >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061258 >> >> Gosh, it appears I submitted that bug 18 months ago although >> I don't remember how I came across the problem. >> >> I need to understand the fix better and it doesn't help that I don't >> understand this line :- >> } else if (selectID == 3) { > Yes, this is wrong. I was thinking selectID ==3 was for PD_SELECTION > but it was not. > Anyways, I have rectified this and updated the webrev: > http://cr.openjdk.java.net/~psadhukhan/8061258/webrev.01/ > > where the else part handles both > PD_SELECTION or PD_NOSELECTION > > I tested with JobAttributes.setDefaultSelection(ALL/RANGE/SELECTION) and also without defaultselection and all are working fine. > Regards > Prasanta >> >> SelectID is set from a single flag bit .. so it will never be 3, >> at least not anywhere I can find. What case is that supposed to >> be covering ? >> >> -phil. >> >>> webrev :http://cr.openjdk.java.net/~psadhukhan/8061258/webrev.00/ >>> >>> When user attempts to pre-populate the native dialog with copies and >>> page ranges by calling >>> PrintRequestAttributeSet aset = new HashPrintRequestAttributeSet(); >>> aset.add(new Copies(2)); >>> aset.add(new PageRanges(3,4)); >>> the print dialog does not reflect the user-defined setting. >>> >>> This is because osx native code was calling getNumberOfPages() from >>> OpenBook.java which was returning UNKNOWN_NUMBER_OF_PAGES (-1). >>> Since getNumberOfPages() returned -1, osx always selected >>> NSPrintAllPages or All Radio button. >>> >>> I fixed it by removing this call to getNumberOfPages() and rely on >>> getMinPage/getMaxPage() as was done in windows >>> (awt_PrintControl.cpp:AwtPrintControl::InitPrintDialog) to select >>> which radio button to be selected. >>> If fromPage > minPage or toPage < maxPage, it means user has >>> selected page ranges so PageRange radio button is to be selected >>> else "All" radio button to be selected. >>> >>> Regards >>> Prasanta > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Tue Mar 29 18:43:58 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 29 Mar 2016 11:43:58 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8042713, , [macosx] Print dialog does not update attribute set with page range In-Reply-To: <56F12B9E.9000804@oracle.com> References: <56EBC421.7050109@oracle.com> <56EC5524.8040601@oracle.com> <56F12B9E.9000804@oracle.com> Message-ID: <56FACCEE.3010207@oracle.com> Like the related fix passing down page ranges to the dialog this looks reasonable but I have not had time to apply the patch and test it. You should test the combination of this fix + that for 8061258 before pushing .. -phil. On 03/22/2016 04:25 AM, prasanta sadhukhan wrote: > Hi Phil, > > I have modified the webrev as per your review comment regarding > 0-based page indices that osx native supports. > http://cr.openjdk.java.net/~psadhukhan/8042713/webrev.01/ > I have tested with copies and pageranges set with my testcase and also > test/java/awt/print/PrinterJob/PageRanges.java > > Also, I found one issue with the previous change in that if we select > PageRange and then print and then we select ALL, then also previous > page ranges was getting printed and not "All" pages. > This was because osx CPrinterJob.setAttributes() checks for > SunPageSelection.class but nowhere SunPageSelection.RANGE/ALL is > getting added to attribute in osx > so attributes.get(SunPageSelection.class) was returning null and > setPageRange() was getting set with wrong values. > I added SunPageSelection.RANGE/ALL to attribute and also made sure if > SunPageSelection.ALL is selected, then setPageRange(-1, -1) is set > similar to windows. > > Regards > Prasanta > On 3/19/2016 12:51 AM, Phil Race wrote: >> The bug report seems to be lacking a proper (any) evaluation. >> >> It is probably not accurate to say it did not call the "correct" >> methods since >> the problem is actually that there was no method that did this and >> you needed >> to add them and make sure they also did what they in turn called what >> native >> had been calling after setting the attribute. >> >> >> The change itself seems to be mimicing what happens in Windows >> printing code, >> ie WPrinterJob.setRangeCopiesAttribute(..) ? >> >> Is this intentional ? If so that would have been useful to point out >> so I did not >> need to hunt it down. Looking at that code I see that is does a >> couple of >> other things (1) has a way of indicating an explicitly set number of >> copies >> vs default copies, (2) accepts a boolean indicating if in the dialog >> a range >> was actually requested. It looks like in the OSX code we only make >> the upcall >> in that case, but I need you to verify that all this works as it is >> supposed to. >> >> Also native used to use a zero-based index and you have changed that >> without >> commenting on it. First it is still zero-based in the initialisation >> and may not >> always be changed. Secondly if you want 1-based then you seem to have >> a problem as the new Java method calls >> >> setPageRange(from, to); >> >> with the 1-based values and that seems to be the method which >> accepted the zero-based values. >> This seems very fishy. >> >> >> -phil. >> >> >> On 03/18/2016 02:02 AM, prasanta sadhukhan wrote: >>> Hi Phil, >>> >>> Please review a fix for >>> bug: https://bugs.openjdk.java.net/browse/JDK-8042713 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8042713/webrev.00/ >>> >>> The OS X platform print dialog has an option to set the page ranges. >>> If this is done it ought to be reported back in the AttributeSet. >>> but it was found that the page range attribute is not reported back . >>> >>> This is because nsPrintInfoToJavaPrinterJob() does not call correct >>> Java setxxxAttributes methods to set the attributes. >>> >>> I added the corresponding setPageRangeAttribute method along with >>> setCopiesAttribute method to report back the "page range" and >>> "copies" in AttributeSet. >>> >>> Regards >>> Prasanta >> > From philip.race at oracle.com Tue Mar 29 18:56:17 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 29 Mar 2016 11:56:17 -0700 Subject: [OpenJDK 2D-Dev] [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception In-Reply-To: References: <3969befd-57cd-48ee-bed5-173a28e7bd08@default> <56DFFC9F.4020403@oracle.com> <70f247c0-6f3e-472a-b7b0-b02814010e30@default> <56E16D0A.3060807@oracle.com> <56E1E2A5.1020008@oracle.com> <56F1C6F2.6000305@oracle.com> <56F1D0DB.9000508@oracle.com> <56F33180.8060408@oracle.com> <56F334D3.5060106@oracle.com> Message-ID: <56FACFD1.3050409@oracle.com> Looks good to me. -phil. On 03/28/2016 03:18 AM, Ajit Ghaisas wrote: > Hi, > > Thanks Jim for thorough review. > > Here is the updated webrev : > http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.04/ > > In this update : > 1) I have corrected missing space after casting > 2) I have modified code to adapt suggested indentation for blocks having conditionals & method declaration split on multiple lines. > > Please note that, I have done indentation change only if it is related to the code changes done as part of this fix. > The files in this review already have indentation issues and fixing all of them will result in multiple changes masking the actual code changes that fixes the reported issue. > > Request you to review the updated webrev. > > Regards, > Ajit > > -----Original Message----- > From: Jim Graham > Sent: Thursday, March 24, 2016 5:59 AM > To: Phil Race > Cc: 2d-dev > Subject: Re: [OpenJDK 2D-Dev] [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception > > I should point out that this form I demonstrate below is only used when there are continuation lines on the prefix to the code block (conditionals, method declarations, loop controls, etc.), so: > > if (some simple condition) { > ... > } > > and: > > if (some complex condition && > some additional condition) > { > ... > } > > but, not: > > if (some single line condition) > { > // blech > ... > } > > The reason for this is that the standard indentation would recommend: > > if (some complex condition && > some additional condition) { > // code block > } > or > void foomethod(int sx, int sy, > int dx, int dy) { > // code block > } > > which may be more compact, but the lack of a breaking line means you have to vary the indentation of the declarations/conditionals and as a result they don't line up nicely which makes them harder to scan if they are all related (and frequently in graphics code you end up with a series of very similar arguments or conditionals that are more readable if they line up nicely), and the only indication of when the multiple lines of continued declaration/conditionals end and the body of the method begins is the number of spaces - noting that frequently the indentation on lines in practice is just wrong so this form makes it hard to distinguish between "that line is a continuation line" and "someone indented that line wrong"... > > ...jim > > On 3/23/16 5:14 PM, Jim Graham wrote: >> For the record, in many places in the 2D code we also adopt a slight >> extension of the indentation rules such that the below might be written as: >> >> public ByteBandedRaster(SampleModel sampleModel, >> DataBufferByte dataBuffer, >> Point origin) >> { >> // body lines of the method... >> } >> >> with the open curly brace on the following line so that it more visually >> points out the beginning of the body block of the method and it's easy >> to find the start/end of the block by sighting down the left margin. The >> official policy is for the "{" to be at the end of the previous line >> after "Point origin) {" and as more new engineers work on the code and >> follow the official rules, the above form becomes less common. (Sad >> face since I particularly like the above form...) >> >> ...jim >> >> On 3/22/16 4:10 PM, Phil Race wrote: >>> Ajit, >>> >>> There is also some odd indentation in ByteBandedRaster.java which is not >>> yours but >>> >>> 98 public ByteBandedRaster(SampleModel sampleModel, >>> 99 DataBufferByte dataBuffer, >>> 100 Point origin) { >>> >>> >>> This appears to be the result of someone using tabs a long time ago. >>> >>> Since you are touching the method signature lines anyway may be >>> better fixed so we have these aligned >>> >>> public ByteBandedRaster(SampleModel sampleModel, >>> DataBufferByte dataBuffer, >>> Point origin) { >>> >>> [not sure if that will make it through mail as intended]. >>> >>> Here in Raster.java, the first condition now seems to be redundant .. >>> 890 if (dataType == DataBuffer.TYPE_BYTE && >>> 891 dataBuffer instanceof DataBufferByte && >>> >>> >>> >>> -phil. >>> >>> >>> On 03/22/2016 03:28 PM, Jim Graham wrote: >>>> Hi Ajit, >>>> >>>> Most of your if statements are spaced wrong. There should be a space >>>> between "if" and the parentheses. I'll review more later, but I >>>> noticed that issue in the first couple of files I looked at... >>>> >>>> ...jim >>>> >>>> On 3/15/16 7:05 AM, Ajit Ghaisas wrote: >>>>> Hi, >>>>> >>>>> Thanks Sergey and Jim for suggestions. >>>>> >>>>> I have made the data specific Raster constructors type safe >>>>> now. Also, I have modified all Raster creations in Raster.java to >>>>> support custom DataBuffer classes. >>>>> >>>>> Please review the changes present in updated webrev : >>>>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.02/ >>>>> >>>>> Regards, >>>>> Ajit >>>>> >>>>> -----Original Message----- >>>>> From: Jim Graham >>>>> Sent: Friday, March 11, 2016 2:40 AM >>>>> To: Sergey Bylokhov; Ajit Ghaisas; 2d-dev >>>>> Subject: Re: [OpenJDK 2D-Dev] [9] Review-request for 6353518: >>>>> Creation of a WritableRaster with a custom DataBuffer causes >>>>> erroneous Exception >>>>> >>>>> Yes, those constructors should be type-safe. Perhaps that was done >>>>> to save code in the caller, but that is a small price to pay to avoid >>>>> errors in the future, and it makes sure there is a backup plan for >>>>> different kinds of buffers... >>>>> >>>>> ...jim >>>>> >>>>> On 3/10/16 4:48 AM, Sergey Bylokhov wrote: >>>>>> Hi, Ajit. >>>>>> What about other cases in Raster.java, where the DataBuffer is passed >>>>>> as a parameter? Probably we can simplify the code and find all such >>>>>> issues if we changes the ByteInterleavedRaster/etc. For example: >>>>>> >>>>>> ByteInterleavedRaster(SampleModel sampleModel,DataBuffer >>>>>> dataBuffer,...) to >>>>>> >>>>>> ByteInterleavedRaster(SampleModel sampleModel,DataBufferByte >>>>>> dataBuffer,...) >>>>>> >>>>>> Because we throw an exception in such cases anyway: >>>>>> >>>>>> if (!(dataBuffer instanceof DataBufferByte)) { >>>>>> throw new RasterFormatException("ByteInterleavedRasters must >>>>>> have " >>>>>> + "byte DataBuffers"); >>>>>> } >>>>>> >>>>>> And the compiler will help us, what everybody think about it? >>>>>> >>>>>> On 09.03.16 17:38, Ajit Ghaisas wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Modified the test and added check for >>>>>>> MultiPixelPackedSampleModel >>>>>>> condition. >>>>>>> >>>>>>> Please review updated webrev : >>>>>>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.01/ >>>>>>> >>>>>>> Regards, >>>>>>> Ajit >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Sergey Bylokhov >>>>>>> Sent: Wednesday, March 09, 2016 4:06 PM >>>>>>> To: Ajit Ghaisas; awt-dev at openjdk.java.net; Semyon Sadetsky; Ambarish >>>>>>> Rapte; 2d-dev >>>>>>> Subject: Re: [9] Review-request for 6353518: Creation of a >>>>>>> WritableRaster with a custom DataBuffer causes erroneous Exception >>>>>>> >>>>>>> Changes for 2d area.(cc) >>>>>>> >>>>>>> >>>>>>> On 07.03.16 11:20, Ajit Ghaisas wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-6353518 >>>>>>>> >>>>>>>> Issue : (Text from bug description) >>>>>>>> >>>>>>>> An attempt to create a WritableRaster via >>>>>>>> Raster.createWritableRaster(SampleModel sm, DataBuffer db, Point >>>>>>>> location) using a custom DataBuffer causes an erroneous >>>>>>>> RasterFormatException. >>>>>>>> Apparently the reason for this bug is that IntegerComponentRaster >>>>>>>> insists on being passed an instance of DataBufferInt rather than >>>>>>>> just a DataBuffer with a DataType of TYPE_INT. >>>>>>>> This is quite annoying since DataBufferInt is declared final and >>>>>>>> thus cannot be extended. >>>>>>>> >>>>>>>> Fix : >>>>>>>> >>>>>>>> The last line of Raster.createWritableRaster() method already has a >>>>>>>> way to handle generic case if the input does not match any of the >>>>>>>> cases in switch statements in that method. >>>>>>>> >>>>>>>> The fact that " *InterleavedRaster() constructors throw exception >>>>>>>> if DataBuffer passed to them does not match the expected type" was >>>>>>>> ignored earlier. >>>>>>>> >>>>>>>> This fix adds a check of "DataBuffer type" before creating >>>>>>>> respective >>>>>>>> *InterleavedRaster() objects. >>>>>>>> >>>>>>>> It constructs the SunWritableRaster in case DataBuffer type does not >>>>>>>> match any data specific DataBuffer classes (DataBufferByte, >>>>>>>> DataBufferUShort, DataBufferInt) >>>>>>>> >>>>>>>> Request to review webrev containing this fix : >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.00/ >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Ajit >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, Sergey. >>>>>>> >>>>>> From james.graham at oracle.com Tue Mar 29 20:19:15 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 29 Mar 2016 13:19:15 -0700 Subject: [OpenJDK 2D-Dev] [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception In-Reply-To: <56E16D0A.3060807@oracle.com> References: <3969befd-57cd-48ee-bed5-173a28e7bd08@default> <56DFFC9F.4020403@oracle.com> <70f247c0-6f3e-472a-b7b0-b02814010e30@default> <56E16D0A.3060807@oracle.com> Message-ID: <56FAE343.3010606@oracle.com> This sounded like such a great idea that I don't think we realized the one obvious reason we can't do this... You are talking about changing the method signatures on existing public constructors. While it might be nice to have had them typed from the get-go, I don't think we can change them now. We might be able to add new overloaded typed constructors (or typed factories?), but we can't just delete or modify the existing constructors without creating a compatibility issue... ...jim On 3/10/16 4:48 AM, Sergey Bylokhov wrote: > Hi, Ajit. > What about other cases in Raster.java, where the DataBuffer is passed as > a parameter? Probably we can simplify the code and find all such issues > if we changes the ByteInterleavedRaster/etc. For example: > > ByteInterleavedRaster(SampleModel sampleModel,DataBuffer dataBuffer,...) > to > > ByteInterleavedRaster(SampleModel sampleModel,DataBufferByte > dataBuffer,...) > > Because we throw an exception in such cases anyway: > > if (!(dataBuffer instanceof DataBufferByte)) { > throw new RasterFormatException("ByteInterleavedRasters must have " > + "byte DataBuffers"); > } > > And the compiler will help us, what everybody think about it? > > On 09.03.16 17:38, Ajit Ghaisas wrote: >> Hi, >> >> Modified the test and added check for MultiPixelPackedSampleModel >> condition. >> >> Please review updated webrev : >> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.01/ >> >> Regards, >> Ajit >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Wednesday, March 09, 2016 4:06 PM >> To: Ajit Ghaisas; awt-dev at openjdk.java.net; Semyon Sadetsky; Ambarish >> Rapte; 2d-dev >> Subject: Re: [9] Review-request for 6353518: Creation of a >> WritableRaster with a custom DataBuffer causes erroneous Exception >> >> Changes for 2d area.(cc) >> >> >> On 07.03.16 11:20, Ajit Ghaisas wrote: >>> Hi, >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-6353518 >>> >>> Issue : (Text from bug description) >>> >>> An attempt to create a WritableRaster via >>> Raster.createWritableRaster(SampleModel sm, DataBuffer db, Point >>> location) using a custom DataBuffer causes an erroneous >>> RasterFormatException. >>> Apparently the reason for this bug is that IntegerComponentRaster >>> insists on being passed an instance of DataBufferInt rather than just >>> a DataBuffer with a DataType of TYPE_INT. >>> This is quite annoying since DataBufferInt is declared final and thus >>> cannot be extended. >>> >>> Fix : >>> >>> The last line of Raster.createWritableRaster() method already has a >>> way to handle generic case if the input does not match any of the >>> cases in switch statements in that method. >>> >>> The fact that " *InterleavedRaster() constructors throw exception if >>> DataBuffer passed to them does not match the expected type" was >>> ignored earlier. >>> >>> This fix adds a check of "DataBuffer type" before creating respective >>> *InterleavedRaster() objects. >>> >>> It constructs the SunWritableRaster in case DataBuffer type does not >>> match any data specific DataBuffer classes (DataBufferByte, >>> DataBufferUShort, DataBufferInt) >>> >>> Request to review webrev containing this fix : >>> >>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.00/ >>> >>> Regards, >>> >>> Ajit >>> >> >> >> -- >> Best regards, Sergey. >> > > From Sergey.Bylokhov at oracle.com Tue Mar 29 20:24:06 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 29 Mar 2016 23:24:06 +0300 Subject: [OpenJDK 2D-Dev] [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception In-Reply-To: <56FAE343.3010606@oracle.com> References: <3969befd-57cd-48ee-bed5-173a28e7bd08@default> <56DFFC9F.4020403@oracle.com> <70f247c0-6f3e-472a-b7b0-b02814010e30@default> <56E16D0A.3060807@oracle.com> <56FAE343.3010606@oracle.com> Message-ID: <56FAE466.5020105@oracle.com> On 29.03.16 23:19, Jim Graham wrote: > This sounded like such a great idea that I don't think we realized the > one obvious reason we can't do this... We should take into account that this classes in sun/awt/image and is not accessible on old jdk when the securitymanager is enabled, and will be completely encapsulated in jdk9. > > You are talking about changing the method signatures on existing public > constructors. While it might be nice to have had them typed from the > get-go, I don't think we can change them now. We might be able to add > new overloaded typed constructors (or typed factories?), but we can't > just delete or modify the existing constructors without creating a > compatibility issue... > > ...jim > > On 3/10/16 4:48 AM, Sergey Bylokhov wrote: >> Hi, Ajit. >> What about other cases in Raster.java, where the DataBuffer is passed as >> a parameter? Probably we can simplify the code and find all such issues >> if we changes the ByteInterleavedRaster/etc. For example: >> >> ByteInterleavedRaster(SampleModel sampleModel,DataBuffer dataBuffer,...) >> to >> >> ByteInterleavedRaster(SampleModel sampleModel,DataBufferByte >> dataBuffer,...) >> >> Because we throw an exception in such cases anyway: >> >> if (!(dataBuffer instanceof DataBufferByte)) { >> throw new RasterFormatException("ByteInterleavedRasters must have " >> + "byte DataBuffers"); >> } >> >> And the compiler will help us, what everybody think about it? >> >> On 09.03.16 17:38, Ajit Ghaisas wrote: >>> Hi, >>> >>> Modified the test and added check for MultiPixelPackedSampleModel >>> condition. >>> >>> Please review updated webrev : >>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.01/ >>> >>> Regards, >>> Ajit >>> >>> -----Original Message----- >>> From: Sergey Bylokhov >>> Sent: Wednesday, March 09, 2016 4:06 PM >>> To: Ajit Ghaisas; awt-dev at openjdk.java.net; Semyon Sadetsky; Ambarish >>> Rapte; 2d-dev >>> Subject: Re: [9] Review-request for 6353518: Creation of a >>> WritableRaster with a custom DataBuffer causes erroneous Exception >>> >>> Changes for 2d area.(cc) >>> >>> >>> On 07.03.16 11:20, Ajit Ghaisas wrote: >>>> Hi, >>>> >>>> Bug : https://bugs.openjdk.java.net/browse/JDK-6353518 >>>> >>>> Issue : (Text from bug description) >>>> >>>> An attempt to create a WritableRaster via >>>> Raster.createWritableRaster(SampleModel sm, DataBuffer db, Point >>>> location) using a custom DataBuffer causes an erroneous >>>> RasterFormatException. >>>> Apparently the reason for this bug is that IntegerComponentRaster >>>> insists on being passed an instance of DataBufferInt rather than just >>>> a DataBuffer with a DataType of TYPE_INT. >>>> This is quite annoying since DataBufferInt is declared final and thus >>>> cannot be extended. >>>> >>>> Fix : >>>> >>>> The last line of Raster.createWritableRaster() method already has a >>>> way to handle generic case if the input does not match any of the >>>> cases in switch statements in that method. >>>> >>>> The fact that " *InterleavedRaster() constructors throw exception if >>>> DataBuffer passed to them does not match the expected type" was >>>> ignored earlier. >>>> >>>> This fix adds a check of "DataBuffer type" before creating respective >>>> *InterleavedRaster() objects. >>>> >>>> It constructs the SunWritableRaster in case DataBuffer type does not >>>> match any data specific DataBuffer classes (DataBufferByte, >>>> DataBufferUShort, DataBufferInt) >>>> >>>> Request to review webrev containing this fix : >>>> >>>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.00/ >>>> >>>> Regards, >>>> >>>> Ajit >>>> >>> >>> >>> -- >>> Best regards, Sergey. >>> >> >> -- Best regards, Sergey. From james.graham at oracle.com Tue Mar 29 21:15:52 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 29 Mar 2016 14:15:52 -0700 Subject: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: Antialiased text on translucent backgrounds gets bright artifacts In-Reply-To: <215e497a-db82-4f6f-99e9-bd44f25d5999@default> References: <63d69ba8-d5cf-4697-bb5c-f51aaaa8c427@default> <56EB4DBB.9080802@oracle.com> <56F3505B.2070101@oracle.com> <215e497a-db82-4f6f-99e9-bd44f25d5999@default> Message-ID: <56FAF088.70300@oracle.com> Hi Prahalad, This latest version looks like it should produce correct answers. I'd like to see benchmark results on more platforms, particularly Windows since the different compilers may optimize these things differently. Also, you didn't mention what data set you used for benchmarking. I'd like to see benchmark results for small, medium and large font sizes, and possibly bold and italic fonts as well. The reason is that the relative ratios of "empty glyph pixels" to "partial glyph pixels" to "fully covered glyph pixels" changes depending on the font type and size so if you made one of those faster and another slower then the results may be seen as a gain in one type of test if you only test one font type and size and it happens to match the part of the code that is more streamlined. Also, for small font sizes the per-glyph overhead might hide per-pixel issues. Please share which fonts and sizes you used for testing and consider using some different sizes, including something very large like 36 or 48 points (something with large areas of opaque pixels) as well as more normal sizes that appear in GUIs. Also, bold fonts can have a higher percentage of opaque pixels. In particular... This latest version is missing the "fast path" from the existing code for the case of srcA == 255 and glyphA == 255 where it just stores the FG_PIXEL values directly. For large fonts/glyphs that case may be as important as detecting empty glyph pixels. On the other hand, an additional "if" may cause the compiler to generate less efficient code as per Sergey's concern. Since this "if" eliminates some multiplies and possibly some divides, I'd hope it would be a win-win. You could add the fast path back inside the case where mixValSrc is 255 and just test srcA for 255 and do the Store ## DST ## PixelData() macro that used to be at the end of the block in the existing code, and then use "break;" to escape out of the do/while surrounding the whole macro so it moves on to the next pixel. (Arguably, we might want to consider teaching our SRCOVER_MASKFILL to do the same thing. I think that was one of the added values of having a separate GLYPH loop, but really both should be optimizing that case...) I can see now that the macro switch to use the same macro set as SRCOVER_MASKFILL required you to compute the pixel address, as you noted in your summary. It makes the new macro more cumbersome and makes it look like it's doing a bit more work per-pixel, but in reality I think the overall operations end up being the same as long as the compiler optimizes the deliberate multiplications the same way it did for implicit multiplications in the "pRas[foo]" and "pRas[foo*4]" code that was being generated previously. Benchmarks will tell us if we're good there... ...jim On 3/28/16 5:33 AM, Prahalad Kumar Narayanan wrote: > Hello Everyone on Java2D Group > > Good day to you. > > This is a follow-up to Review Request on bug: > Bug : JDK-8015070 > Bug Link : https://bugs.openjdk.java.net/browse/JDK-8015070 > > First, Thanks to Jim and Sergey for their feedback on the changes so far. > > Inferences from Jim 's Feedback on Loading destination colors: > 1. The API or Macro that I had earlier used to Load DST colors, indeed, adjusted destination color components with divide-by-alpha if destination was already pre-multiplied. > My apologies.. I should have spotted this error at the first iteration itself. > 2. Due to the divide-by-alpha adjustment, the remaining logic would become incorrect. ( Especially, the multiplication with dstF based on pre-mulitplication status ) > 3. Correct API is being used now, and the dstColor components are loaded directly without any divide-by-alpha adjustment. > > Inferences from Sergey's Feedback on Performance. > 1. To set the context for everyone, the logic present in the current webrev.02 is modelled as per SRCOVER_MASKFILL. > There are multiple if (...) conditions that remove un-necessary blending calculations. Ideally this should improve performance. > However, since some data are not readily available (as present in SRCOVER_MASKFILL), few additional calculations have been added. > They are: pre-multiplying srcColor with alpha and assigning to res. > Finding the correct address of Pixel using DST_PTR and PixelStride. > Henceforth, as Sergey suggests, Observation on performance will be beneficial. > 2. The performance of the new logic was measured with linux-x86_64-normal-server-release config and compared with the logic used in un-optimized code in webrev.00 > 3. Result: The newer logic provides a fractional gain (about 15 - 20 ms) over the older logic. > > Other Subtle Changes: > 1. The test file has been renamed from AADrawStringArtifact.java to more meaningful - AntialiasedTextArtifact.java > 2. The test file tests for both TYPE_INT_ARGB and TYPE_INT_ARGB_PRE BufferedImage formats. > The code has been well commented to explain the logic used in every function. > > Kindly take your time to review the changes in the webrev link mentioned below and provide your suggestions. > Webrev Link: http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.02/ > > > Thank you for your time in review > Have a good day > > Prahalad N. > > > -----Original Message----- > From: Jim Graham > Sent: Thursday, March 24, 2016 7:57 AM > To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: Antialiased text on translucent backgrounds gets bright artifacts > > Hi Prahalad, > > (On a side note - ouch! I came up with these macros in the first place, but 20 years later I'm now realizing just how hard they are to navigate and review. My apologies...) > > The macro you are still using to load the destination data is one that loads it to non-premultiplied components, which means it will divide out the alpha if the destination is PRE. The rest of the logic assumes that the components were loaded without any adjustment of their premultiplication so not only is that division an unnecessary operation, it makes the following math wrong. > > The SRCOVER_MASKFILL macro seems to use "Postload ## STRATEGY ## From ## TYPE" which seems to load them into separate components without any adjustment of their pre-multiplication status. This is paired with "LoadAlphaFrom ## TYPE ## For ## STRATEGY" to load just the destination alpha for computing dstF... > > ...jim > > On 3/22/16 4:35 AM, Prahalad Kumar Narayanan wrote: >> Hello Everyone on Java2D Group >> >> Good day to you. >> >> This is a Follow-up to Review Request on the bug: >> Bug : JDK-8015070 Anti-aliased Text on Translucent background gets bright artifacts >> Bug Link : https://bugs.openjdk.java.net/browse/JDK-8015070 >> >> First, Sincere thanks to Jim for his valuable feedback. >> 1. As Jim correctly mentioned, SRCOVER_MASKFILL has a similar logic to blend two Translucent colors based on an Alpha mask. >> 2. The calculations are exactly the same as the changes in previous webrev. >> However the logic of SRCOVER_MASKFILL is 'Optimized' to reduce the number of computations. >> 3. This optimization is definitely required because, the logic is executed for every single pixel in a glyph. >> Example: If a string is made up of 5 English characters with each character having 32 x 32 pixels, >> The anti-aliasing logic will be executed for 5 x 32 x 32 iterations. >> Reducing computation per pixel will imply a huge benefit for complete drawString operation. >> >> Observation from SRCOVER_MASKFILL >> 1. The mask fill reduces computations by through multiple if(...) conditions. >> Each if condition affirms whether the next set of computations are required. >> 2. Optimization 1: If mask value is 0- skip entire logic. >> 3. Optimization 2: If mask value is maximum, say 255, take srcA directly without multiplying with maskAlpha ( Reason: 1 * srcAlpha = srcAlpha ) >> 4. Optimization 3: Compute pre-multiplied resColor in two steps. First with srcColor and then with dstColor. >> If the resAlpha from 1st step (i.e., srcColor) is fully opaque, avoid blending dstColor altogether. >> >> Changes in Current Webrev.01 >> 1. The fix for the current bug is modelled based on SRCOVER_MASKFILL. >> 2. The changes have been verified to work on windows, linux and mac operating systems. >> 3. The automated Test file- AADrawStringArtifact.java runs as expected >> Identifies artifact & throws exception when run on JDK 7 and 8. >> With JDK9, the test file returns without error. >> 3. JPRT build has been run to ensure, changes build on all supported platforms. >> JPRT job link : >> http://scaaa637.us.oracle.com//archive/2016/03/2016-03-22-070604.prahn >> ara-linux.client >> >> Kindly review the changes in the below mentioned link and provide your views >> Webrev Link : >> http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.01/ >> >> >> Thank you for your time in review >> Have a good day >> >> Prahalad N. >> >> >> -----Original Message----- >> From: Jim Graham >> Sent: Friday, March 18, 2016 6:07 AM >> To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: >> Antialiased text on translucent backgrounds gets bright artifacts >> >> Hi Prahalad, >> >> This basically boils down to "alpha blending math needs to be performed in premultiplied form" and the existing code was not doing that. >> >> Your changes do add a pre-multiplication step to the math in two >> places >> - when you mix the src alpha and the glyph alpha at the top of the macro, and again when you do the Multiply(dst, dstA, dst) step in the middle. In that sense, the new math is correct. >> >> However, it is not the optimal way to implement this. In particular, >> the macro used here to load the data from the destination is the one >> that loads it into 4 ARGB non-premultiplied values. If the >> destination is non-PRE, then your added multiply step is exactly what >> is needed, but it could be combined with the multiply that will happen >> later in the blending equation, so it is an added step rather than a >> fixed fraction in the existing MultMultAdd parameters. Additionally, >> if the destination is already PRE, then the macro being used to load >> the dst pixel data there will have done a divide step to divide out >> the alpha from the destination, only to have you reverse that math >> with your new >> Multiply() step. That's a lot of math to end up with a NOP. >> >> The MUL8 you added for the srcA and glyph value is needed, that change is good. Since it is common for glyph pixels to have zero alpha, you might want to test the glyph alpha for 0 and skip the pixel before you do the multiply, though. This would add one more if, but it would be a common case. >> >> The trickier part is to load the destination components without un-premultiplying them. Unfortunately there is no "Load...ToArgbPre" >> macro to parallel the Load macro used in the function. Perhaps there should be, but you'd still end up with an extra multiply step as I mentioned above because you can fold the premultiplication of the dst data into the MultMultAdd by carefully choosing the parameters you use in the math there. >> >> The good news is that the way that the SRCOVER_MASKFILL uses the various type-specific macros works around this a bit and minimizes the number of multiplies that happen. You could check out DEFINE_SRCOVER_MASKFILL and see how it works in the case where pMask is not null (pMask is an alpha mask with values very similar to the glyphAA data). Modeling this code on that code would correct the math and minimize it as well... >> >> ...jim >> >> On 3/17/16 3:00 AM, Prahalad Kumar Narayanan wrote: >>> Hello Everyone on Java2D Group >>> >>> Good day to you. >>> >>> Herewith, I 'm sharing the webrev for two identical Java2D Bugs. >>> >>> Bug ID : JDK-8015070 >>> >>> Title : Antialiased text on translucent backgrounds gets >>> bright artifacts >>> >>> Link : https://bugs.openjdk.java.net/browse/JDK-8015070 >>> >>> Bug ID : JDK-8013564 ( currently closed as duplicate ) >>> >>> Title : Font rendering anti-aliasing in translucent >>> BufferedImages broken >>> >>> Link : https://bugs.openjdk.java.net/browse/JDK-8013564 >>> >>> Webrev Link : >>> http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.00/ >>> >>> Quick Summary on Bugs : >>> >>> ```````````````````````````````````````````````` >>> >>> 1. Artifacts appear on Edges of text characters when anti-aliased >>> text is drawn on Translucent background >>> >>> 2. The issue is reproducible on all platforms - windows, linux and mac os. >>> >>> 3. Besides, the issue is reproduced with the commonly used pixel >>> format- 4ByteArgb. >>> >>> Root Cause & Solution : >>> >>> ```````````````````````````````````````````````` >>> >>> 1. The Macro: GlyphListAABlend4ByteArgb in File: LoopMacros.h uses >>> the standard blending algorithm >>> >>> dstColor = [ srcColor * glyphAlpha + dstColor * (1 - >>> glyphAlpha) ] / dstAlpha >>> >>> 2. The above equation works only when the srcColor and dstColor are Opaque. >>> >>> 3. When srcColor and dstColor are Translucent, their alphaComponent >>> will influence the visibility of the color, and visibility of the >>> color below. >>> >>> 4. The new set of calculations for blending Translucent source and >>> destination colors is given as >>> >>> resAlpha = 1 - ((1 - srcAlpha) * (1 - dstAlpha)) >>> >>> resColor = [ srcColor * srcAlpha + dstColor * dstAlpha * (1 >>> - >>> srcAlpha) ] / resAlpha >>> >>> 5. Reference text for the equation: >>> https://en.wikipedia.org/wiki/Alpha_compositing >>> >>> 6. With the above modification to the blending logic, the artifacts >>> do not appear and issues are fixed. >>> >>> Jtreg & Jprt Results : >>> >>> ```````````````````````````````````````````````` >>> >>> 1. A simple test-file: AADrawStringArtifact.java has been created to >>> be a part of jtreg test cases. >>> >>> The test file is well commented to explain - nature of >>> artifact and how the test tries to identify them. >>> >>> As required, the test case fails with Jdk 7, Jdk 8 and >>> succeeds with Jdk 9-internal (built with changes for the bug fix) >>> >>> 2. The changes to blending logic lies within >>> java.desktop/src/share/native/... >>> >>> Henceforth, JPRT was used to ensure successful build >>> across all supported platforms >>> >>> Jprt Job Link : >>> http://scaaa637.us.oracle.com//archive/2016/03/2016-03-17-072001.prah >>> n >>> ara-linux.client >>> >>> The build succeeds on all platforms. >>> >>> Kindly review the webrev link and provide your views and suggestions. >>> >>> Webrev Link : >>> http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.00/ >>> >>> If the changes look good, we could take up the changes for source checkin. >>> >>> Thank you for your time in review >>> >>> Have a good day >>> >>> Prahalad N. >>> From james.graham at oracle.com Tue Mar 29 21:19:26 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 29 Mar 2016 14:19:26 -0700 Subject: [OpenJDK 2D-Dev] [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception In-Reply-To: <56FAE466.5020105@oracle.com> References: <3969befd-57cd-48ee-bed5-173a28e7bd08@default> <56DFFC9F.4020403@oracle.com> <70f247c0-6f3e-472a-b7b0-b02814010e30@default> <56E16D0A.3060807@oracle.com> <56FAE343.3010606@oracle.com> <56FAE466.5020105@oracle.com> Message-ID: <56FAF15E.2040509@oracle.com> Ah, yes, now I see it. I was combing through the various classes in java/awt/image that *are* public to do some research while I was reading the code review and somehow thought that the classes being modified were in the same directory/package. I now see that all of the modified constructors are in sun/awt which is fine. Apologies for the diversion... ...jim On 3/29/16 1:24 PM, Sergey Bylokhov wrote: > On 29.03.16 23:19, Jim Graham wrote: >> This sounded like such a great idea that I don't think we realized the >> one obvious reason we can't do this... > > We should take into account that this classes in sun/awt/image and is > not accessible on old jdk when the securitymanager is enabled, and will > be completely encapsulated in jdk9. > >> >> You are talking about changing the method signatures on existing public >> constructors. While it might be nice to have had them typed from the >> get-go, I don't think we can change them now. We might be able to add >> new overloaded typed constructors (or typed factories?), but we can't >> just delete or modify the existing constructors without creating a >> compatibility issue... >> >> ...jim >> >> On 3/10/16 4:48 AM, Sergey Bylokhov wrote: >>> Hi, Ajit. >>> What about other cases in Raster.java, where the DataBuffer is passed as >>> a parameter? Probably we can simplify the code and find all such issues >>> if we changes the ByteInterleavedRaster/etc. For example: >>> >>> ByteInterleavedRaster(SampleModel sampleModel,DataBuffer dataBuffer,...) >>> to >>> >>> ByteInterleavedRaster(SampleModel sampleModel,DataBufferByte >>> dataBuffer,...) >>> >>> Because we throw an exception in such cases anyway: >>> >>> if (!(dataBuffer instanceof DataBufferByte)) { >>> throw new RasterFormatException("ByteInterleavedRasters must have " >>> + "byte DataBuffers"); >>> } >>> >>> And the compiler will help us, what everybody think about it? >>> >>> On 09.03.16 17:38, Ajit Ghaisas wrote: >>>> Hi, >>>> >>>> Modified the test and added check for MultiPixelPackedSampleModel >>>> condition. >>>> >>>> Please review updated webrev : >>>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.01/ >>>> >>>> Regards, >>>> Ajit >>>> >>>> -----Original Message----- >>>> From: Sergey Bylokhov >>>> Sent: Wednesday, March 09, 2016 4:06 PM >>>> To: Ajit Ghaisas; awt-dev at openjdk.java.net; Semyon Sadetsky; Ambarish >>>> Rapte; 2d-dev >>>> Subject: Re: [9] Review-request for 6353518: Creation of a >>>> WritableRaster with a custom DataBuffer causes erroneous Exception >>>> >>>> Changes for 2d area.(cc) >>>> >>>> >>>> On 07.03.16 11:20, Ajit Ghaisas wrote: >>>>> Hi, >>>>> >>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-6353518 >>>>> >>>>> Issue : (Text from bug description) >>>>> >>>>> An attempt to create a WritableRaster via >>>>> Raster.createWritableRaster(SampleModel sm, DataBuffer db, Point >>>>> location) using a custom DataBuffer causes an erroneous >>>>> RasterFormatException. >>>>> Apparently the reason for this bug is that IntegerComponentRaster >>>>> insists on being passed an instance of DataBufferInt rather than just >>>>> a DataBuffer with a DataType of TYPE_INT. >>>>> This is quite annoying since DataBufferInt is declared final and thus >>>>> cannot be extended. >>>>> >>>>> Fix : >>>>> >>>>> The last line of Raster.createWritableRaster() method already has a >>>>> way to handle generic case if the input does not match any of the >>>>> cases in switch statements in that method. >>>>> >>>>> The fact that " *InterleavedRaster() constructors throw exception if >>>>> DataBuffer passed to them does not match the expected type" was >>>>> ignored earlier. >>>>> >>>>> This fix adds a check of "DataBuffer type" before creating respective >>>>> *InterleavedRaster() objects. >>>>> >>>>> It constructs the SunWritableRaster in case DataBuffer type does not >>>>> match any data specific DataBuffer classes (DataBufferByte, >>>>> DataBufferUShort, DataBufferInt) >>>>> >>>>> Request to review webrev containing this fix : >>>>> >>>>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.00/ >>>>> >>>>> Regards, >>>>> >>>>> Ajit >>>>> >>>> >>>> >>>> -- >>>> Best regards, Sergey. >>>> >>> >>> > > From james.graham at oracle.com Tue Mar 29 21:37:18 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 29 Mar 2016 14:37:18 -0700 Subject: [OpenJDK 2D-Dev] [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception In-Reply-To: References: <3969befd-57cd-48ee-bed5-173a28e7bd08@default> <56DFFC9F.4020403@oracle.com> <70f247c0-6f3e-472a-b7b0-b02814010e30@default> <56E16D0A.3060807@oracle.com> <56E1E2A5.1020008@oracle.com> <56F1C6F2.6000305@oracle.com> <56F1D0DB.9000508@oracle.com> <56F33180.8060408@oracle.com> <56F334D3.5060106@oracle.com> Message-ID: <56FAF58E.5060208@oracle.com> Raster.java, line 742: This branch of the switch statement instantiates a SWR which doesn't have a specific buffer type. It could be replaced with just "break;" and let the code after the switch create the raster (it can't be deleted from the switch statement because the default would throw an exception, but it could just "break;" on that dataType). At a minimum, though, it didn't need the instanceof or cast that was added since it will just fall through to exactly the same code anyway. Raster.java, line 894: Why was the test for dataType removed from this if statement? Raster.java: line 980: Something to file as a potential bug for future work. The test for getSampleSize(0) in this method is much more permissive than the test for bitsPerPixel in createPackedRaster just above this method. Both determine whether to return a BytePackedRaster so they should probably agree. Raster.java, line 986: Something to file as a potential bug for future work since the fix would have to be verified that it doesn't disrupt the other parts of this method, but... The set of if statements in this method never checked for a BandedSampleModel to try to create a BandedRaster as in createBandedRaster. On the other hand, no developer has complained so far (that I know of, but maybe we have an old bug filed on it that I'm not aware of). Raster.java: the same comments for createRaster above apply for createWritableRaster at line 1033. The following 2 comments are identical for all of the raster types { ByteBandedRaster.java, line 76: This code will throw a ClassCastException now instead of the RasterFormatException that used to be thrown. Do we care? It would be easy enough to add a test to just this method (and the similar versions in other files). ByteBandedRaster.java, line 668: Extra credit: This cast could be avoided if we make SunWritableRaster employ generics for a strongly typed DataBuffer. } ShortInterleavedRaster - I think the import of DataBuffer can be eliminated now? ...jim On 3/28/16 3:18 AM, Ajit Ghaisas wrote: > Hi, > > Thanks Jim for thorough review. > > Here is the updated webrev : > http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.04/ > > In this update : > 1) I have corrected missing space after casting > 2) I have modified code to adapt suggested indentation for blocks having conditionals & method declaration split on multiple lines. > > Please note that, I have done indentation change only if it is related to the code changes done as part of this fix. > The files in this review already have indentation issues and fixing all of them will result in multiple changes masking the actual code changes that fixes the reported issue. > > Request you to review the updated webrev. > > Regards, > Ajit > > -----Original Message----- > From: Jim Graham > Sent: Thursday, March 24, 2016 5:59 AM > To: Phil Race > Cc: 2d-dev > Subject: Re: [OpenJDK 2D-Dev] [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception > > I should point out that this form I demonstrate below is only used when there are continuation lines on the prefix to the code block (conditionals, method declarations, loop controls, etc.), so: > > if (some simple condition) { > ... > } > > and: > > if (some complex condition && > some additional condition) > { > ... > } > > but, not: > > if (some single line condition) > { > // blech > ... > } > > The reason for this is that the standard indentation would recommend: > > if (some complex condition && > some additional condition) { > // code block > } > or > void foomethod(int sx, int sy, > int dx, int dy) { > // code block > } > > which may be more compact, but the lack of a breaking line means you have to vary the indentation of the declarations/conditionals and as a result they don't line up nicely which makes them harder to scan if they are all related (and frequently in graphics code you end up with a series of very similar arguments or conditionals that are more readable if they line up nicely), and the only indication of when the multiple lines of continued declaration/conditionals end and the body of the method begins is the number of spaces - noting that frequently the indentation on lines in practice is just wrong so this form makes it hard to distinguish between "that line is a continuation line" and "someone indented that line wrong"... > > ...jim > > On 3/23/16 5:14 PM, Jim Graham wrote: >> For the record, in many places in the 2D code we also adopt a slight >> extension of the indentation rules such that the below might be written as: >> >> public ByteBandedRaster(SampleModel sampleModel, >> DataBufferByte dataBuffer, >> Point origin) >> { >> // body lines of the method... >> } >> >> with the open curly brace on the following line so that it more visually >> points out the beginning of the body block of the method and it's easy >> to find the start/end of the block by sighting down the left margin. The >> official policy is for the "{" to be at the end of the previous line >> after "Point origin) {" and as more new engineers work on the code and >> follow the official rules, the above form becomes less common. (Sad >> face since I particularly like the above form...) >> >> ...jim >> >> On 3/22/16 4:10 PM, Phil Race wrote: >>> Ajit, >>> >>> There is also some odd indentation in ByteBandedRaster.java which is not >>> yours but >>> >>> 98 public ByteBandedRaster(SampleModel sampleModel, >>> 99 DataBufferByte dataBuffer, >>> 100 Point origin) { >>> >>> >>> This appears to be the result of someone using tabs a long time ago. >>> >>> Since you are touching the method signature lines anyway may be >>> better fixed so we have these aligned >>> >>> public ByteBandedRaster(SampleModel sampleModel, >>> DataBufferByte dataBuffer, >>> Point origin) { >>> >>> [not sure if that will make it through mail as intended]. >>> >>> Here in Raster.java, the first condition now seems to be redundant .. >>> 890 if (dataType == DataBuffer.TYPE_BYTE && >>> 891 dataBuffer instanceof DataBufferByte && >>> >>> >>> >>> -phil. >>> >>> >>> On 03/22/2016 03:28 PM, Jim Graham wrote: >>>> Hi Ajit, >>>> >>>> Most of your if statements are spaced wrong. There should be a space >>>> between "if" and the parentheses. I'll review more later, but I >>>> noticed that issue in the first couple of files I looked at... >>>> >>>> ...jim >>>> >>>> On 3/15/16 7:05 AM, Ajit Ghaisas wrote: >>>>> Hi, >>>>> >>>>> Thanks Sergey and Jim for suggestions. >>>>> >>>>> I have made the data specific Raster constructors type safe >>>>> now. Also, I have modified all Raster creations in Raster.java to >>>>> support custom DataBuffer classes. >>>>> >>>>> Please review the changes present in updated webrev : >>>>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.02/ >>>>> >>>>> Regards, >>>>> Ajit >>>>> >>>>> -----Original Message----- >>>>> From: Jim Graham >>>>> Sent: Friday, March 11, 2016 2:40 AM >>>>> To: Sergey Bylokhov; Ajit Ghaisas; 2d-dev >>>>> Subject: Re: [OpenJDK 2D-Dev] [9] Review-request for 6353518: >>>>> Creation of a WritableRaster with a custom DataBuffer causes >>>>> erroneous Exception >>>>> >>>>> Yes, those constructors should be type-safe. Perhaps that was done >>>>> to save code in the caller, but that is a small price to pay to avoid >>>>> errors in the future, and it makes sure there is a backup plan for >>>>> different kinds of buffers... >>>>> >>>>> ...jim >>>>> >>>>> On 3/10/16 4:48 AM, Sergey Bylokhov wrote: >>>>>> Hi, Ajit. >>>>>> What about other cases in Raster.java, where the DataBuffer is passed >>>>>> as a parameter? Probably we can simplify the code and find all such >>>>>> issues if we changes the ByteInterleavedRaster/etc. For example: >>>>>> >>>>>> ByteInterleavedRaster(SampleModel sampleModel,DataBuffer >>>>>> dataBuffer,...) to >>>>>> >>>>>> ByteInterleavedRaster(SampleModel sampleModel,DataBufferByte >>>>>> dataBuffer,...) >>>>>> >>>>>> Because we throw an exception in such cases anyway: >>>>>> >>>>>> if (!(dataBuffer instanceof DataBufferByte)) { >>>>>> throw new RasterFormatException("ByteInterleavedRasters must >>>>>> have " >>>>>> + "byte DataBuffers"); >>>>>> } >>>>>> >>>>>> And the compiler will help us, what everybody think about it? >>>>>> >>>>>> On 09.03.16 17:38, Ajit Ghaisas wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Modified the test and added check for >>>>>>> MultiPixelPackedSampleModel >>>>>>> condition. >>>>>>> >>>>>>> Please review updated webrev : >>>>>>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.01/ >>>>>>> >>>>>>> Regards, >>>>>>> Ajit >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Sergey Bylokhov >>>>>>> Sent: Wednesday, March 09, 2016 4:06 PM >>>>>>> To: Ajit Ghaisas; awt-dev at openjdk.java.net; Semyon Sadetsky; Ambarish >>>>>>> Rapte; 2d-dev >>>>>>> Subject: Re: [9] Review-request for 6353518: Creation of a >>>>>>> WritableRaster with a custom DataBuffer causes erroneous Exception >>>>>>> >>>>>>> Changes for 2d area.(cc) >>>>>>> >>>>>>> >>>>>>> On 07.03.16 11:20, Ajit Ghaisas wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-6353518 >>>>>>>> >>>>>>>> Issue : (Text from bug description) >>>>>>>> >>>>>>>> An attempt to create a WritableRaster via >>>>>>>> Raster.createWritableRaster(SampleModel sm, DataBuffer db, Point >>>>>>>> location) using a custom DataBuffer causes an erroneous >>>>>>>> RasterFormatException. >>>>>>>> Apparently the reason for this bug is that IntegerComponentRaster >>>>>>>> insists on being passed an instance of DataBufferInt rather than >>>>>>>> just a DataBuffer with a DataType of TYPE_INT. >>>>>>>> This is quite annoying since DataBufferInt is declared final and >>>>>>>> thus cannot be extended. >>>>>>>> >>>>>>>> Fix : >>>>>>>> >>>>>>>> The last line of Raster.createWritableRaster() method already has a >>>>>>>> way to handle generic case if the input does not match any of the >>>>>>>> cases in switch statements in that method. >>>>>>>> >>>>>>>> The fact that " *InterleavedRaster() constructors throw exception >>>>>>>> if DataBuffer passed to them does not match the expected type" was >>>>>>>> ignored earlier. >>>>>>>> >>>>>>>> This fix adds a check of "DataBuffer type" before creating >>>>>>>> respective >>>>>>>> *InterleavedRaster() objects. >>>>>>>> >>>>>>>> It constructs the SunWritableRaster in case DataBuffer type does not >>>>>>>> match any data specific DataBuffer classes (DataBufferByte, >>>>>>>> DataBufferUShort, DataBufferInt) >>>>>>>> >>>>>>>> Request to review webrev containing this fix : >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.00/ >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Ajit >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, Sergey. >>>>>>> >>>>>> >>>>>> >>> From philip.race at oracle.com Tue Mar 29 22:31:07 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 29 Mar 2016 15:31:07 -0700 Subject: [OpenJDK 2D-Dev] [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception In-Reply-To: <56FAF58E.5060208@oracle.com> References: <3969befd-57cd-48ee-bed5-173a28e7bd08@default> <56DFFC9F.4020403@oracle.com> <70f247c0-6f3e-472a-b7b0-b02814010e30@default> <56E16D0A.3060807@oracle.com> <56E1E2A5.1020008@oracle.com> <56F1C6F2.6000305@oracle.com> <56F1D0DB.9000508@oracle.com> <56F33180.8060408@oracle.com> <56F334D3.5060106@oracle.com> <56FAF58E.5060208@oracle.com> Message-ID: <56FB022B.7050609@oracle.com> On 03/29/2016 02:37 PM, Jim Graham wrote: > Raster.java, line 894: Why was the test for dataType removed from this > if statement? In a previous version .. http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.02/src/java.desktop/share/classes/java/awt/image/Raster.java.sdiff.html Ajit had added a condition : 890 if (dataType == DataBuffer.TYPE_BYTE && 891 dataBuffer instanceof DataBufferByte && But we don't need both of these. DataBufferByte should always be DataBuffer.TYPE_BYTE and we do the cast so it had better be DataBufferByte. -phil. From james.graham at oracle.com Wed Mar 30 02:17:22 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 29 Mar 2016 19:17:22 -0700 Subject: [OpenJDK 2D-Dev] [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception In-Reply-To: <56FB022B.7050609@oracle.com> References: <3969befd-57cd-48ee-bed5-173a28e7bd08@default> <56DFFC9F.4020403@oracle.com> <70f247c0-6f3e-472a-b7b0-b02814010e30@default> <56E16D0A.3060807@oracle.com> <56E1E2A5.1020008@oracle.com> <56F1C6F2.6000305@oracle.com> <56F1D0DB.9000508@oracle.com> <56F33180.8060408@oracle.com> <56F334D3.5060106@oracle.com> <56FAF58E.5060208@oracle.com> <56FB022B.7050609@oracle.com> Message-ID: <56FB3732.8090306@oracle.com> One comes from the SampleModel, the other comes from the DataBuffer. The reason to check them both is to make sure they agree. There is no "it must be DataBuffer.TYPE_BYTE" here, there is only "it *should* be DataBuffer.TYPE_BYTE" and that warrants a test and a fallback to the generic SunWritableRaster if they ever send in the wrong type. Otherwise why do we bother to switch on the dataType in the other sections of the code before we check instanceof? For the same reason as we need both checks here. If we expanded out this final else clause in parallel to match the way that the other blocks are written, then we would have: } else if (sm instanceof MPPSM) { switch (dataType) { case DataBuffer.TYPE_BYTE: if (dataBuffer instanceof DataBufferByte) { if (sm.getSampleSize(0) < 8) { return new BPP(...); } } break; } } The tests in the prior version were a perfect compaction of all of the above constructs into a single if statement. The new one omits the switch test that all of the other blocks have... ...jim On 3/29/16 3:31 PM, Phil Race wrote: > On 03/29/2016 02:37 PM, Jim Graham wrote: >> Raster.java, line 894: Why was the test for dataType removed from this >> if statement? > > In a previous version .. > http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.02/src/java.desktop/share/classes/java/awt/image/Raster.java.sdiff.html > > > Ajit had added a condition : > > 890 if (dataType == DataBuffer.TYPE_BYTE && > 891 dataBuffer instanceof DataBufferByte && > > > But we don't need both of these. > DataBufferByte should always be DataBuffer.TYPE_BYTE and we do the cast > so it had better be DataBufferByte. > > -phil. > From philip.race at oracle.com Wed Mar 30 03:59:19 2016 From: philip.race at oracle.com (Philip Race) Date: Tue, 29 Mar 2016 20:59:19 -0700 Subject: [OpenJDK 2D-Dev] [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception In-Reply-To: <56FB3732.8090306@oracle.com> References: <3969befd-57cd-48ee-bed5-173a28e7bd08@default> <56DFFC9F.4020403@oracle.com> <70f247c0-6f3e-472a-b7b0-b02814010e30@default> <56E16D0A.3060807@oracle.com> <56E1E2A5.1020008@oracle.com> <56F1C6F2.6000305@oracle.com> <56F1D0DB.9000508@oracle.com> <56F33180.8060408@oracle.com> <56F334D3.5060106@oracle.com> <56FAF58E.5060208@oracle.com> <56FB022B.7050609@oracle.com> <56FB3732.8090306@oracle.com> Message-ID: <56FB4F17.90109@oracle.com> > One comes from the SampleModel, the other comes from the DataBuffer. In the other methods that is true but not in this one. This method creates the SampleModel using the type of the DataBuffer. The webrev diff is insufficient to make this apparent. -phil. On 3/29/16, 7:17 PM, Jim Graham wrote: > One comes from the SampleModel, the other comes from the DataBuffer. > The reason to check them both is to make sure they agree. There is no > "it must be DataBuffer.TYPE_BYTE" here, there is only "it *should* be > DataBuffer.TYPE_BYTE" and that warrants a test and a fallback to the > generic SunWritableRaster if they ever send in the wrong type. > > Otherwise why do we bother to switch on the dataType in the other > sections of the code before we check instanceof? For the same reason > as we need both checks here. If we expanded out this final else > clause in parallel to match the way that the other blocks are written, > then we would have: > > } else if (sm instanceof MPPSM) { > switch (dataType) { > case DataBuffer.TYPE_BYTE: > if (dataBuffer instanceof DataBufferByte) { > if (sm.getSampleSize(0) < 8) { > return new BPP(...); > } > } > break; > } > } > > The tests in the prior version were a perfect compaction of all of the > above constructs into a single if statement. The new one omits the > switch test that all of the other blocks have... > > ...jim > > On 3/29/16 3:31 PM, Phil Race wrote: >> On 03/29/2016 02:37 PM, Jim Graham wrote: >>> Raster.java, line 894: Why was the test for dataType removed from this >>> if statement? >> >> In a previous version .. >> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.02/src/java.desktop/share/classes/java/awt/image/Raster.java.sdiff.html >> >> >> >> Ajit had added a condition : >> >> 890 if (dataType == DataBuffer.TYPE_BYTE && >> 891 dataBuffer instanceof DataBufferByte && >> >> >> But we don't need both of these. >> DataBufferByte should always be DataBuffer.TYPE_BYTE and we do the cast >> so it had better be DataBufferByte. >> >> -phil. >> From jayathirth.d.v at oracle.com Wed Mar 30 05:15:03 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 29 Mar 2016 22:15:03 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream In-Reply-To: <56FAB668.3000106@oracle.com> References: <99cb1549-30b5-44af-b399-ebed22255cf8@default> <56E997F1.2070605@oracle.com> <56E9C39D.6090701@oracle.com> <56E9D1D5.8090500@oracle.com> <56EAB79C.1080503@oracle.com> <88e50a67-fdd2-4b97-aa19-3ac5d419e2cf@default> <56EAFD38.80604@oracle.com> <56F0A94C.8080703@oracle.com> <56F17140.2070208@oracle.com> <481ff313-103f-4a71-bec9-44a3fa0a70ef@default> <56F3294E.1040306@oracle.com> <387cc752-40cd-4d3a-9350-e53193d80dfd@default> <56F9AC5E.8010107@oracle.com> <56FA41FF.9000704@oracle.com> <56FAB668.3000106@oracle.com> Message-ID: Hi Phil, Yes I agree with that. This test case is only for those read() and write() functions which tend to use createImageXXXStream() and not for those which get stream directly as part of argument and follow the spec. Thanks for your inputs. -Jay From: Phil Race Sent: Tuesday, March 29, 2016 10:38 PM To: Jayathirth D V Cc: Prasanta Sadhukhan; 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream This is OK but you ought to remember that read() and write() only HAPPEN to use createImageXXXStream(). They could get the stream in some other way and still be a spec. compliant implementation. -phil. On 03/29/2016 02:27 AM, Jayathirth D V wrote: Hi Prasanta, Actually returns null in test description is for createImageXXXStream() and not for read() and write() functions. But for more clarity I have added why we catch IOException also in test description. Please review the updated webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8044289/webrev.05/"http://cr.openjdk.java.net/~jdv/8044289/webrev.05/ Thanks, Jay From: prasanta sadhukhan Sent: Tuesday, March 29, 2016 2:21 PM To: Jayathirth D V Cc: Philip Race; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream +1. Looks ok to me. Only thing is that whether the test summary is appropriate " Test verifies that when createImageInputStream() or 28 * createImageOutputStream() returns null while read or write," Should it not be "verifies whether ...throws appropriate exception"? Regards Prasanta On 3/29/2016 3:42 AM, Philip Race wrote: This all looks fine to me. Although no new Exception types are thrown I think we need a CCC anyway, so please prepare and get that approved before pushing. -phil. On 3/28/16, 3:30 AM, Jayathirth D V wrote: Hi Phil, After discussion with Sergey we have come to conclusion that Sergey is okay with throwing exception or returning null/false. So I have modified the webrev to throw exception. Also in write() I have modified the catch block to just throw the caught exception without adding message since it will create confusion between the case where we are not able to create cache and when createImageOutputStream() returns null. Regarding catch block of createImageOutputStream() only when we usecache is true we use FileCacheImageOutputStream() and it throws IOException so I think there is no need to add extra check before throwing IOException. Please find updated webrev for review : HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8044289/webrev.04/"http://cr.openjdk.java.net/~jdv/8044289/webrev.04/ Thanks, Jay From: Jayathirth D V Sent: Thursday, March 24, 2016 3:52 PM To: Philip Race Cc: Sergey Bylokhov; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: RE: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream Hi Phil, We can change the code to something like : 1522 * @return false if no appropriate writer is found or 1523 * when needed stream is null. 1545 try { 1546 output.delete(); 1547 stream = createImageOutputStream(output); 1548 } catch (IOException e) { 1549 throw e; 1550 } In this case we will be throwing IOException when we are not able to create cache file and stream is null. And return null/false when createImageXXXStream returns null. Also we can add check before throwing IIOException from createImageXXXStream for usecache. 350 351 boolean usecache = getUseCache() && hasCachePermission(); 352 353 while (iter.hasNext()) { 354 ImageInputStreamSpi spi = iter.next(); 355 if (spi.getInputClass().isInstance(input)) { 356 try { 357 return spi.createInputStreamInstance(input, 358 usecache, 359 getCacheDirectory()); 360 } catch (IOException e) { 361 if (usecache) 362 throw new IIOException("Can't create cache file!", e); 363 } 364 } 365 } This will be one of the approach. Or we can throw IOException in all the cases with additional check in createImageXXXStream for usecache. This will be like throwing IOException when createImageXXXStream returns null/false or it throws IIOException when it cant create cache file. This will be another approach. Please let us know your inputs. Thanks, Jay From: Philip Race Sent: Thursday, March 24, 2016 5:10 AM To: Jayathirth D V Cc: Sergey Bylokhov; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream I don't think this is ready and we need to discuss whether to rework it. In general I think I prefer IIO rather than null when we have a stream problem. For one thing you have this change :- 1522 * @return false if no appropriate writer is found or 1523 * not able to create required ImageOutputStream. yet the implementation says :- 1545 try { 1546 output.delete(); 1547 stream = createImageOutputStream(output); 1548 } catch (IOException e) { 1549 throw new IIOException("Can't create output stream!", e); 1550 } So whilst "null" would mean we cannot find an IOS SPI it isn't the only reason we fail to create the IOS A null return seems to get passed through to doWrite() which probably throws IIOE And I think that the implementation is actually right here where it throws an exception. The ability to create an image input or output stream could be because of some kind of problem opening the file, or with the IIS or IOS implementations - like they were de-registered. I think in many if not all of these cases IOE - or IIOE is what we want. Also since we call createImageInputStream() - which is public - we need to look at that, and what it does, which is also something to consider. If it returns null, that seems to mean that no suitable SPI is registered which can only happen if they are de-registered. For the methods where we use createImageInputStream() I think it is fair to turn that into IIOE BTW I note that the code there says :- 350 351 boolean usecache = getUseCache() && hasCachePermission(); 352 353 while (iter.hasNext()) { 354 ImageInputStreamSpi spi = iter.next(); 355 if (spi.getInputClass().isInstance(input)) { 356 try { 357 return spi.createInputStreamInstance(input, 358 usecache, 359 getCacheDirectory()); 360 } catch (IOException e) { 361 throw new IIOException("Can't create cache file!", e); 362 } 363 } 364 } So far I can see that means it will claim any Exception that is generated is because it could not create the cache file without any proof of that and even if "useCache" is false. It seems to imply to me that the author was not considering things like someone passing a closed InputStream .. probably we ought to be more vague in this case or look more deeply at what we can tell from whether it is IIOE or IOE. -phil. On 3/22/16, 10:49 AM, Jayathirth D V wrote: Thanks for the review Sergey. Can I get +1 for this please? -Jay -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, March 22, 2016 9:52 PM To: Jayathirth D V; Philip Race Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream This fix looks fine to me. At least it made all code work in a similar way. But probably someone will have other opinion? On 22.03.16 12:34, Jayathirth D V wrote: Hi Sergey, I have unified changes related to ImageIO.read() and ImageIO.write(). In case of read() we will be returning null when createImageInputStream() returns null. In case of write() we will be returning false when createImageOutputStream() returns null. Please find updated webrev for review: HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8044289/webrev.03/"http://cr.openjdk.java.net/~jdv/8044289/webrev.03/ Thanks, Jay -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, March 22, 2016 7:39 AM To: Jayathirth D V; Philip Race Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream Hi, Jay. Since we decided to update the specification we get an additional flexibility in the fix, because we can update the "@exception IOException" part of javadoc and describe that it can be thrown if ImageXXXStream cannot be created. I don't see a big differences of both approaches in case of write() methods, but in case of read(which has the similar issue but was skipped in the fix) there is a difference. Note that the read(File) unlike other methods throws the unspecified IIOException exception if ImageXXXStream cannot be created. We can think about unification of read/write methods in ImageIO. Hmm but even then read() in some cases will return null and in some cases throw an exception.... and createImageInputStream/createImageOutputStream() will look alien as they always return null not an exception. Another possible unification is to update javadoc for all methods, that they will return null if related providers are not found(in this case "throw new IIOException("Can't create an ImageInputStream!"))" should be removed from read(File); On 21.03.16 10:26, Jayathirth D V wrote: Hi Sergey, For the second approach I have created webrev for review. Please review updated webrev : HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8044289/webrev.02/"http://cr.openjdk.java.net/~jdv/8044289/webrev.02/ Thanks, Jay -----Original Message----- From: Jayathirth D V Sent: Friday, March 18, 2016 2:23 PM To: Sergey Bylokhov Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net; Philip Race Subject: RE: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream Hi Sergey, Thanks for your inputs. Indeed all the null values returned by createImageInputStream() and createImageInputStream() are valid only. I went through the code more and found that there is no need for fix in ImageIO.read() methods as null stream is handled in read(ImageInputStream stream) which is called by all the remaining read() API's through IAE. So i can remove the changes made in ImageIO.read() functions. Also istream is closed in finally block of read(url). For ImageIO.write(File) & ImageIO.write(OutputStream) NPE we have two approaches for fix: 1) Keep the present changes of throwing IOException when stream is null and change the throw clause of write() spec mentioning: "IOException - if an error occurs during writing or not able to create required ImageOutputStream" 2) Remove the present changes and handle null in doWrite() method by returning false when stream is null & add code in finally block to close the stream only when stream is not null. Along with this we can also change Returns clause of spec to mention that write() might return false when we are not able to create ImageOutputStream. private static boolean doWrite(RenderedImage im, ImageWriter writer, ImageOutputStream output) throws IOException { if (writer == null) { return false; } + if (output == null) { + return false; + } try { return doWrite(im, writer, stream); } finally { + if (stream != null) stream.close(); } Returns : false if no appropriate writer is found or not able to create required ImageOutputStream. Please let me know your inputs. Thanks, Jay -----Original Message----- From: Sergey Bylokhov Sent: Friday, March 18, 2016 12:24 AM To: Jayathirth D V Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net; Philip Race Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream On 17.03.16 21:14, Jayathirth D V wrote: There are many places in createImageInputStream() and createImageOutputStream() where it will return null for stream. But when why you change the write/read methods? They should take null into account and work according to specification. If some bogus null returns from createImageInputStream/createImageOutputStream then it should be fixed in these methods. So for NPE described in bug to occur there can be multiple paths: 1) One of the path described in bug is when theRegistry.getServiceProviders() throws IAE and we return null. This is the case when we have no installed spi and should return null/false. 2) When we pass non-existent file path to ImageIO (as described in http://stackoverflow.com/questions/11153200/with-imageio-write-api-call-i-get-nullpointerexception ). Here we catch FileNotFoundException but still we return stream as null at the end which will cause NPE further. This is same thing described in the bug(about stream.close()). The write method call createImageOutputStream() and got FileNotFoundException. This exception should be propagated to the user, but it is replaced in the finally block, because we try to close the stream=null. So the fix for this particular case is to check the stream to null in finally, No? 3) When we don't support the provider and theRegistry.getServiceProviders() return iterator with size zero. This means that our providers do not support this case, and we should return null/false. For us to follow first scenario we need access to categoryMap of IIORegistry and delete the ImageInputStreamSpi/ ImageOutputStreamSpi but I was not able to find a way to tamper it from test case. If we follow second case FileNotFoundException will be thrown by default eventhough we handle NPE. But you change the code and we now contradicts the specification, in your case the test should expect false/null from write()/read(). In the test case we are trying to following third scenario to get stream as null to verify the code changes. To catch the bogus null we should try to use another approach, or change the spec. But it seems all null values above are correct, we should be ready for them. As part of collective fix we are throwing IOException which will indicate that we are not able to create required stream. Thanks, Jay -----Original Message----- From: Sergey Bylokhov Sent: Thursday, March 17, 2016 7:27 PM To: Phil Race Cc: Jayathirth D V; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream On 17.03.16 0:36, Phil Race wrote: I don't think that is the actual reason here But the test doing exactly this thing -> deregister all spi => in this case according to specification all related methods(read/write/creatImageInputStream/creatImageOutputStream) should return null or false. - it seems likely that there was some kind of internal error or bad SPI causing this. So throwing an exception seems more appropriate. the problem was in some of our methods which do not expect null in some places(like stream.close() from the bug description). And also the bug was originally solely about write(..). -phil. On 03/16/2016 01:35 PM, Sergey Bylokhov wrote: As far as I understand the createImageInputStream() returns null is this stream is unsupported by current plugins via spi. Probably the read() method should return null too? /** * Returns a {@code BufferedImage} as the result of decoding * a supplied {@code InputStream} with an {@code ImageReader} * chosen automatically from among those currently registered. * The {@code InputStream} is wrapped in an * {@code ImageInputStream}. If no registered * {@code ImageReader} claims to be able to read the * resulting stream, {@code null} is returned. * ....... * @return a {@code BufferedImage} containing the decoded * contents of the input, or {@code null}. */ public static BufferedImage read(InputStream input) throws IOException On 16.03.16 20:29, Philip Race wrote: The test writes out into "test.src". I believe that you should treat that as a "read-only" location. Write to a tempfile (File.createTempFile()) or TESTCLASSES. -phil. On 3/15/16, 10:50 PM, Jayathirth D V wrote: Hi Phil,All _Please review the following fix in JDK9:_ __ Bug : https://bugs.openjdk.java.net/browse/JDK-8044289 Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8044289/webrev.00/"http://cr.openjdk.java.net/~jdv/8044289/webrev.00/ HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8044289/webrev.00/" Issue : When createImageInputStream() or createImageOutputStream returns null in ImageIO.read() or ImageIO.write() we are seeing NPE as it stream is used further without null check. Root cause : "stream" is used without checking whether it is null or not. Solution : Handle null pointer of stream and throw IIOException. Test case contains all possible scenarios where createImageInputStream() or createImageOutputStream can return null. Thanks, Jay -- Best regards, Sergey. -- Best regards, Sergey. -- Best regards, Sergey. -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Wed Mar 30 06:47:43 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Wed, 30 Mar 2016 12:17:43 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8061258, , [macosx] PrinterJob's native Print Dialog does not reflect specified Copies or Page Ranges In-Reply-To: <56FABFAE.5080008@oracle.com> References: <56F277CB.40207@oracle.com> <56F3220F.1020304@oracle.com> <56F38D77.4060207@oracle.com> <56FABFAE.5080008@oracle.com> Message-ID: <56FB768F.8060605@oracle.com> Hi Phil, I have updated the webrev with your proposed change. http://cr.openjdk.java.net/~psadhukhan/8061258/webrev.02/ Jay, can you please review and give your +1 on this? Regards Prasanta On 3/29/2016 11:17 PM, Phil Race wrote: > Hi, > > You are calling these unconditionally : > 387 jint minPage = JNFCallIntMethod(env, srcPrinterJob, jm_getMinPage); > 388 jint maxPage = JNFCallIntMethod(env, srcPrinterJob, jm_getMaxPage); > > But it seems they are only used/needed in the else {..} > > Other than that it looks reasonable but I have not had time to > apply the patch and verify it .. > > -phil. > > On 03/23/2016 11:47 PM, prasanta sadhukhan wrote: >> Hi Phil, >> >> On 3/24/2016 4:39 AM, Philip Race wrote: >>> >>> >>> On 3/23/16, 4:02 AM, prasanta sadhukhan wrote: >>>> Hi Phil, >>>> >>>> Please review a fix for jdk9 >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061258 >>> >>> Gosh, it appears I submitted that bug 18 months ago although >>> I don't remember how I came across the problem. >>> >>> I need to understand the fix better and it doesn't help that I don't >>> understand this line :- >>> } else if (selectID == 3) { >> Yes, this is wrong. I was thinking selectID ==3 was for PD_SELECTION >> but it was not. >> Anyways, I have rectified this and updated the webrev: >> http://cr.openjdk.java.net/~psadhukhan/8061258/webrev.01/ >> >> where the else part handles both >> PD_SELECTION or PD_NOSELECTION I tested with >> JobAttributes.setDefaultSelection(ALL/RANGE/SELECTION) and also >> without defaultselection and all are working fine. >> Regards >> Prasanta >>> SelectID is set from a single flag bit .. so it will never be 3, at >>> least not anywhere I can find. What case is that supposed to be >>> covering ? -phil. >>> >>>> webrev :http://cr.openjdk.java.net/~psadhukhan/8061258/webrev.00/ >>>> >>>> When user attempts to pre-populate the native dialog with copies >>>> and page ranges by calling >>>> PrintRequestAttributeSet aset = new HashPrintRequestAttributeSet(); >>>> aset.add(new Copies(2)); >>>> aset.add(new PageRanges(3,4)); >>>> the print dialog does not reflect the user-defined setting. >>>> >>>> This is because osx native code was calling getNumberOfPages() from >>>> OpenBook.java which was returning UNKNOWN_NUMBER_OF_PAGES (-1). >>>> Since getNumberOfPages() returned -1, osx always selected >>>> NSPrintAllPages or All Radio button. >>>> >>>> I fixed it by removing this call to getNumberOfPages() and rely on >>>> getMinPage/getMaxPage() as was done in windows >>>> (awt_PrintControl.cpp:AwtPrintControl::InitPrintDialog) to select >>>> which radio button to be selected. >>>> If fromPage > minPage or toPage < maxPage, it means user has >>>> selected page ranges so PageRange radio button is to be selected >>>> else "All" radio button to be selected. >>>> >>>> Regards >>>> Prasanta >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Wed Mar 30 06:48:57 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 29 Mar 2016 23:48:57 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream In-Reply-To: <56FA77D8.3030108@oracle.com> References: <99cb1549-30b5-44af-b399-ebed22255cf8@default> <56E997F1.2070605@oracle.com> <56E9C39D.6090701@oracle.com> <56E9D1D5.8090500@oracle.com> <56EAB79C.1080503@oracle.com> <88e50a67-fdd2-4b97-aa19-3ac5d419e2cf@default> <56EAFD38.80604@oracle.com> <56F0A94C.8080703@oracle.com> <56F17140.2070208@oracle.com> <481ff313-103f-4a71-bec9-44a3fa0a70ef@default> <56F3294E.1040306@oracle.com> <387cc752-40cd-4d3a-9350-e53193d80dfd@default> <56F9AC5E.8010107@oracle.com> <56FA77D8.3030108@oracle.com> Message-ID: <111c7914-e6c1-4805-9c3c-d8f092f3faa3@default> Hi Sergey, Thanks for pointing it out. It looks like redundant try-catch block. I have removed these blocks in write() methods so that we are handling "cant create cache file" exception in common way in all read() and write() methods. Also I have updated test case description to hold true for only those read() and write() methods where we are using createImageXXXStream() for readability. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/8044289/webrev.06/ After CCC is done we will push above change to repo. Thanks, Jay -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, March 29, 2016 6:11 PM To: Philip Race; Jayathirth D V Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In ImageIO.read() and write() NPE is not handled properly for stream I am not sure what is the reason of this code? 1546 try { 1547 output.delete(); 1548 stream = createImageOutputStream(output); 1549 } catch (IOException e) { 1550 throw e; 1551 } On 29.03.16 1:12, Philip Race wrote: > This all looks fine to me. Although no new Exception types are thrown > I think we need a CCC anyway, so please prepare and get that approved > before pushing. > > -phil. > > On 3/28/16, 3:30 AM, Jayathirth D V wrote: >> >> Hi Phil, >> >> After discussion with Sergey we have come to conclusion that Sergey >> is okay with throwing exception or returning null/false. >> >> So I have modified the webrev to throw exception. >> >> Also in write() I have modified the catch block to just throw the >> caught exception without adding message since it will create >> confusion between the case where we are not able to create cache and >> when >> createImageOutputStream() returns null. >> >> Regarding catch block of createImageOutputStream() only when we >> usecache is true we use FileCacheImageOutputStream() and it throws >> IOException so I think there is no need to add extra check before >> throwing IOException. >> >> Please find updated webrev for review : >> >> http://cr.openjdk.java.net/~jdv/8044289/webrev.04/ >> >> >> Thanks, >> >> Jay >> >> *From:*Jayathirth D V >> *Sent:* Thursday, March 24, 2016 3:52 PM >> *To:* Philip Race >> *Cc:* Sergey Bylokhov; 2d-dev at openjdk.java.net >> *Subject:* RE: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >> ImageIO.read() and write() NPE is not handled properly for stream >> >> Hi Phil, >> >> We can change the code to something like : >> >> 1522 * @return false if no appropriate writer is >> found or >> 1523 * when needed stream is null. >> >> 1545 try { >> 1546 output.delete(); >> 1547 stream = createImageOutputStream(output); >> 1548 } catch (IOException e) { >> 1549 *throw e;* >> 1550 } >> >> In this case we will be throwing IOException when we are not able to >> create cache file and stream is null. >> >> And return null/false when createImageXXXStream returns null. Also we >> can add check before throwing IIOException from createImageXXXStream >> for usecache. >> >> 350 >> 351 boolean usecache = getUseCache() && hasCachePermission(); >> 352 >> 353 while (iter.hasNext()) { >> 354 ImageInputStreamSpi spi = iter.next(); >> 355 if (spi.getInputClass().isInstance(input)) { >> 356 try { >> 357 return spi.createInputStreamInstance(input, >> 358 usecache, >> 359 >> getCacheDirectory()); >> 360 } catch (IOException e) { >> 361 *if (usecache)* >> 362 throw new IIOException("Can't create cache >> file!", e); >> 363 } >> 364 } >> 365 } >> >> This will be one of the approach. >> >> Or we can throw IOException in all the cases with additional check in >> createImageXXXStream for usecache. This will be like throwing >> IOException when createImageXXXStream returns null/false or it throws >> IIOException when it cant create cache file. This will be another >> approach. Please let us know your inputs. >> >> Thanks, >> >> Jay >> >> *From:*Philip Race >> *Sent:* Thursday, March 24, 2016 5:10 AM >> *To:* Jayathirth D V >> *Cc:* Sergey Bylokhov; 2d-dev at openjdk.java.net >> >> *Subject:* Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >> ImageIO.read() and write() NPE is not handled properly for stream >> >> I don't think this is ready and we need to discuss whether to rework it. >> >> In general I think I prefer IIO rather than null when we have a stream problem. >> >> >> For one thing you have this change :- >> >> 1522 * @return false if no appropriate writer is >> found or >> 1523 * not able to create required ImageOutputStream. >> yet the implementation says :- >> 1545 try { >> 1546 output.delete(); >> 1547 stream = createImageOutputStream(output); >> 1548 } catch (IOException e) { >> 1549 throw new IIOException("Can't create output stream!", e); >> 1550 } >> So whilst "null" would mean we cannot find an IOS SPI it isn't the >> only reason we fail to create the IOS A null return seems to get >> passed through to doWrite() which probably throws IIOE And I think >> that the implementation is actually right here where it throws an >> exception. >> The ability to create an image input or output stream could be >> because of some kind of problem opening the file, or with the IIS or >> IOS implementations - like they were de-registered. I think in many >> if not all of these cases IOE - or IIOE is what we want. >> Also since we call createImageInputStream() - which is public - we >> need to look at that, and what it does, which is also something to consider. >> If it returns null, that seems to mean that no suitable SPI is >> registered which can only happen if they are de-registered. For the >> methods where we use createImageInputStream() I think it is fair to >> turn that into IIOE BTW I note that the code there says :- >> 350 >> 351 boolean usecache = getUseCache() && hasCachePermission(); >> 352 >> 353 while (iter.hasNext()) { >> 354 ImageInputStreamSpi spi = iter.next(); >> 355 if (spi.getInputClass().isInstance(input)) { >> 356 try { >> 357 return spi.createInputStreamInstance(input, >> 358 usecache, >> 359 getCacheDirectory()); >> 360 } catch (IOException e) { >> 361 throw new IIOException("Can't create cache file!", e); >> 362 } >> 363 } >> 364 } >> So far I can see that means it will claim any Exception that is >> generated is because it could not create the cache file without any proof of that and even if "useCache" is false. >> It seems to imply to me that the author was not considering things >> like someone passing a closed InputStream .. probably we ought to be >> more vague in this case or look more deeply at what we can tell from whether it is IIOE or IOE. >> -phil. >> >> On 3/22/16, 10:49 AM, Jayathirth D V wrote: >> >> Thanks for the review Sergey. >> >> Can I get +1 for this please? >> >> -Jay >> >> -----Original Message----- >> >> From: Sergey Bylokhov >> >> Sent: Tuesday, March 22, 2016 9:52 PM >> >> To: Jayathirth D V; Philip Race >> >> Cc:2d-dev at openjdk.java.net >> >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 : In >> ImageIO.read() and write() NPE is not handled properly for stream >> >> This fix looks fine to me. >> >> At least it made all code work in a similar way. But probably someone will have other opinion? >> >> On 22.03.16 12:34, Jayathirth D V wrote: >> >> Hi Sergey, >> >> I have unified changes related to ImageIO.read() and ImageIO.write(). >> >> In case of read() we will be returning null when createImageInputStream() returns null. >> >> In case of write() we will be returning false when createImageOutputStream() returns null. >> >> Please find updated webrev for review: >> >> http://cr.openjdk.java.net/~jdv/8044289/webrev.03/ >> >> >> Thanks, >> >> Jay >> >> -----Original Message----- >> >> From: Sergey Bylokhov >> >> Sent: Tuesday, March 22, 2016 7:39 AM >> >> To: Jayathirth D V; Philip Race >> >> Cc:2d-dev at openjdk.java.net >> >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8044289 >> : In >> >> ImageIO.read() and write() NPE is not handled properly for >> stream >> >> Hi, Jay. >> >> Since we decided to update the specification we get an additional flexibility in the fix, because we can update the "@exception IOException" part of javadoc and describe that it can be thrown if ImageXXXStream cannot be created. >> >> I don't see a big differences of both approaches in case of write() methods, but in case of read(which has the similar issue but was skipped in the fix) there is a difference. >> >> Note that the read(File) unlike other methods throws the >> unspecified >> >> IIOException exception if ImageXXXStream cannot be created. >> We can >> >> think about unification of read/write methods in ImageIO. Hmm >> but even >> >> then >> >> read() in some cases will return null and in some cases throw an exception.... >> >> and createImageInputStream/createImageOutputStream() will look alien as they always return null not an exception. >> >> Another possible unification is to update javadoc for all >> methods, >> >> that they will return null if related providers are not >> found(in this >> >> case "throw new IIOException("Can't create an ImageInputStream!"))" >> >> should be removed from read(File); >> >> On 21.03.16 10:26, Jayathirth D V wrote: >> >> Hi Sergey, >> >> For the second approach I have created webrev for review. >> >> Please review updated webrev : >> >> http://cr.openjdk.java.net/~jdv/8044289/webrev.02/ >> >> >> Thanks, >> >> Jay >> >> -----Original Message----- >> >> From: Jayathirth D V >> >> Sent: Friday, March 18, 2016 2:23 PM >> >> To: Sergey Bylokhov >> >> Cc:2d-dev at openjdk.java.net >> ; Philip Race >> >> Subject: RE: [OpenJDK 2D-Dev] Review Request for >> JDK-8044289 : In >> >> ImageIO.read() and write() NPE is not handled properly >> for stream >> >> Hi Sergey, >> >> Thanks for your inputs. >> >> Indeed all the null values returned by createImageInputStream() and createImageInputStream() are valid only. >> >> I went through the code more and found that there is no need for fix in ImageIO.read() methods as null stream is handled in read(ImageInputStream stream) which is called by all the remaining read() API's through IAE. So i can remove the changes made in ImageIO.read() functions. Also istream is closed in finally block of read(url). >> >> For ImageIO.write(File) & ImageIO.write(OutputStream) NPE we have two approaches for fix: >> >> 1) Keep the present changes of throwing IOException when stream is null and change the throw clause of write() spec mentioning: >> >> "IOException - if an error occurs during writing or not able to create required ImageOutputStream" >> >> 2) Remove the present changes and handle null in doWrite() method by returning false when stream is null & add code in finally block to close the stream only when stream is not null. Along with this we can also change Returns clause of spec to mention that write() might return false when we are not able to create ImageOutputStream. >> >> >> >> private static boolean doWrite(RenderedImage >> im, ImageWriter writer, >> >> >> ImageOutputStream output) throws IOException { >> >> if (writer == null) { >> >> return false; >> >> } >> >> + if (output == null) { >> >> + return false; >> >> + } >> >> >> >> try { >> >> return doWrite(im, >> writer, stream); >> >> } finally { >> >> + if (stream != null) >> >> stream.close(); >> >> } >> >> >> >> Returns : >> >> false if no appropriate writer is found or not able to create required ImageOutputStream. >> >> Please let me know your inputs. >> >> Thanks, >> >> Jay >> >> -----Original Message----- >> >> From: Sergey Bylokhov >> >> Sent: Friday, March 18, 2016 12:24 AM >> >> To: Jayathirth D V >> >> Cc:2d-dev at openjdk.java.net >> ; Philip Race >> >> Subject: Re: [OpenJDK 2D-Dev] Review Request for >> JDK-8044289 : In >> >> ImageIO.read() and write() NPE is not handled properly >> for stream >> >> On 17.03.16 21:14, Jayathirth D V wrote: >> >> There are many places in createImageInputStream() and createImageOutputStream() where it will return null for stream. >> >> But when why you change the write/read methods? They should take null into account and work according to specification. If some bogus null returns from createImageInputStream/createImageOutputStream then it should be fixed in these methods. >> >> So for NPE described in bug to occur there can be multiple paths: >> >> 1) One of the path described in bug is when theRegistry.getServiceProviders() throws IAE and we return null. >> >> This is the case when we have no installed spi and should return null/false. >> >> 2) When we pass non-existent file path to ImageIO (as described inhttp://stackoverflow.com/questions/11153200/with-imageio-write-api-call-i-get-nullpointerexception ). Here we catch FileNotFoundException but still we return stream as null at the end which will cause NPE further. >> >> This is same thing described in the bug(about stream.close()). The write method call createImageOutputStream() and got FileNotFoundException. >> >> This exception should be propagated to the user, but it is replaced in the finally block, because we try to close the stream=null. So the fix for this particular case is to check the stream to null in finally, No? >> >> 3) When we don't support the provider and theRegistry.getServiceProviders() return iterator with size zero. >> >> This means that our providers do not support this case, and we should return null/false. >> >> For us to follow first scenario we need access to categoryMap of IIORegistry and delete the ImageInputStreamSpi/ ImageOutputStreamSpi but I was not able to find a way to tamper it from test case. If we follow second case FileNotFoundException will be thrown by default eventhough we handle NPE. >> >> But you change the code and we now contradicts the specification, in your case the test should expect false/null from write()/read(). >> >> In the test case we are trying to following third scenario to get stream as null to verify the code changes. >> >> To catch the bogus null we should try to use another approach, or change the spec. But it seems all null values above are correct, we should be ready for them. >> >> As part of collective fix we are throwing IOException which will indicate that we are not able to create required stream. >> >> Thanks, >> >> Jay >> >> -----Original Message----- >> >> From: Sergey Bylokhov >> >> Sent: Thursday, March 17, 2016 7:27 PM >> >> To: Phil Race >> >> Cc: Jayathirth D V;2d-dev at openjdk.java.net >> >> >> Subject: Re: [OpenJDK 2D-Dev] Review Request for >> JDK-8044289 : In >> >> ImageIO.read() and write() NPE is not handled >> properly for stream >> >> On 17.03.16 0:36, Phil Race wrote: >> >> I don't think that is the actual reason here >> >> But the test doing exactly this thing -> deregister >> all spi => in >> >> this case according to specification all related >> >> methods(read/write/creatImageInputStream/creatImageOutputStream) should return null or false. >> >> - it seems likely that there >> >> was some kind of internal error or bad SPI causing this. >> >> So throwing an exception seems more appropriate. >> >> the problem was in some of our methods which do not expect null in some places(like stream.close() from the bug description). >> >> And also the bug was originally solely about write(..). >> >> -phil. >> >> On 03/16/2016 01:35 PM, Sergey Bylokhov wrote: >> >> As far as I understand the >> createImageInputStream() returns null >> >> is this stream is unsupported by current >> plugins via spi. Probably >> >> the >> >> read() method should return null too? >> >> /** >> >> * Returns a {@code BufferedImage} as >> the result of decoding >> >> * a supplied {@code InputStream} >> with an {@code ImageReader} >> >> * chosen automatically from among those currently registered. >> >> * The {@code InputStream} is wrapped >> in an >> >> * {@code ImageInputStream}. If no >> registered >> >> * {@code ImageReader} claims to be >> able to read the >> >> * resulting stream, {@code null} is returned. >> >> * >> >> ....... >> >> * @return a {@code BufferedImage} >> containing the decoded >> >> * contents of the input, or {@code null}. >> >> */ >> >> public static BufferedImage >> read(InputStream input) throws >> >> IOException >> >> On 16.03.16 20:29, Philip Race wrote: >> >> The test writes out into "test.src". >> >> I believe that you should treat that as a "read-only" location. >> >> Write to a tempfile (File.createTempFile()) or TESTCLASSES. >> >> -phil. >> >> On 3/15/16, 10:50 PM, Jayathirth D V wrote: >> >> Hi Phil,All >> >> _Please review the following fix in >> JDK9:_ >> >> __ >> >> Bug >> :https://bugs.openjdk.java.net/browse/JDK-8044289 >> >> Webrev :http://cr.openjdk.java.net/~jdv/8044289/webrev.00/ >> >> >> >> >> >> >> >> Issue : When createImageInputStream() >> or createImageOutputStream >> >> returns null in ImageIO.read() or >> ImageIO.write() we are seeing >> >> NPE as it stream is used further without null check. >> >> Root cause : "stream" is used without >> checking whether it is >> >> null or not. >> >> Solution : Handle null pointer of stream and throw IIOException. >> >> Test case contains all possible >> scenarios where >> >> createImageInputStream() or createImageOutputStream can return null. >> >> Thanks, >> >> Jay >> >> -- >> >> Best regards, Sergey. >> >> -- >> >> Best regards, Sergey. >> >> -- >> >> Best regards, Sergey. >> >> -- >> >> Best regards, Sergey. >> -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Wed Mar 30 07:03:41 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Wed, 30 Mar 2016 12:33:41 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8042713, , [macosx] Print dialog does not update attribute set with page range In-Reply-To: <56FACCEE.3010207@oracle.com> References: <56EBC421.7050109@oracle.com> <56EC5524.8040601@oracle.com> <56F12B9E.9000804@oracle.com> <56FACCEE.3010207@oracle.com> Message-ID: <56FB7A4D.6020902@oracle.com> Hi Phil, Yes, the combination of this fix plus 8061258 works with both the testcase I have along with the fix(es). Jay, can you please review and give your +1 on this? Regards Prasanta On 3/30/2016 12:13 AM, Phil Race wrote: > Like the related fix passing down page ranges to the dialog this looks > reasonable > but I have not had time to apply the patch and test it. > You should test the combination of this fix + that for 8061258 before > pushing .. > > -phil. > > > On 03/22/2016 04:25 AM, prasanta sadhukhan wrote: >> Hi Phil, >> >> I have modified the webrev as per your review comment regarding >> 0-based page indices that osx native supports. >> http://cr.openjdk.java.net/~psadhukhan/8042713/webrev.01/ >> I have tested with copies and pageranges set with my testcase and >> also test/java/awt/print/PrinterJob/PageRanges.java >> >> Also, I found one issue with the previous change in that if we select >> PageRange and then print and then we select ALL, then also previous >> page ranges was getting printed and not "All" pages. >> This was because osx CPrinterJob.setAttributes() checks for >> SunPageSelection.class but nowhere SunPageSelection.RANGE/ALL is >> getting added to attribute in osx >> so attributes.get(SunPageSelection.class) was returning null and >> setPageRange() was getting set with wrong values. >> I added SunPageSelection.RANGE/ALL to attribute and also made sure if >> SunPageSelection.ALL is selected, then setPageRange(-1, -1) is set >> similar to windows. >> >> Regards >> Prasanta >> On 3/19/2016 12:51 AM, Phil Race wrote: >>> The bug report seems to be lacking a proper (any) evaluation. >>> >>> It is probably not accurate to say it did not call the "correct" >>> methods since >>> the problem is actually that there was no method that did this and >>> you needed >>> to add them and make sure they also did what they in turn called >>> what native >>> had been calling after setting the attribute. >>> >>> >>> The change itself seems to be mimicing what happens in Windows >>> printing code, >>> ie WPrinterJob.setRangeCopiesAttribute(..) ? >>> >>> Is this intentional ? If so that would have been useful to point out >>> so I did not >>> need to hunt it down. Looking at that code I see that is does a >>> couple of >>> other things (1) has a way of indicating an explicitly set number of >>> copies >>> vs default copies, (2) accepts a boolean indicating if in the dialog >>> a range >>> was actually requested. It looks like in the OSX code we only make >>> the upcall >>> in that case, but I need you to verify that all this works as it is >>> supposed to. >>> >>> Also native used to use a zero-based index and you have changed that >>> without >>> commenting on it. First it is still zero-based in the initialisation >>> and may not >>> always be changed. Secondly if you want 1-based then you seem to have >>> a problem as the new Java method calls >>> >>> setPageRange(from, to); >>> >>> with the 1-based values and that seems to be the method which >>> accepted the zero-based values. >>> This seems very fishy. >>> >>> >>> -phil. >>> >>> >>> On 03/18/2016 02:02 AM, prasanta sadhukhan wrote: >>>> Hi Phil, >>>> >>>> Please review a fix for >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8042713 >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8042713/webrev.00/ >>>> >>>> The OS X platform print dialog has an option to set the page ranges. >>>> If this is done it ought to be reported back in the AttributeSet. >>>> but it was found that the page range attribute is not reported back . >>>> >>>> This is because nsPrintInfoToJavaPrinterJob() does not call correct >>>> Java setxxxAttributes methods to set the attributes. >>>> >>>> I added the corresponding setPageRangeAttribute method along with >>>> setCopiesAttribute method to report back the "page range" and >>>> "copies" in AttributeSet. >>>> >>>> Regards >>>> Prasanta >>> >> > From jayathirth.d.v at oracle.com Wed Mar 30 10:20:47 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 30 Mar 2016 03:20:47 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8061258, , [macosx] PrinterJob's native Print Dialog does not reflect specified Copies or Page Ranges In-Reply-To: <56FB768F.8060605@oracle.com> References: <56F277CB.40207@oracle.com> <56F3220F.1020304@oracle.com> <56F38D77.4060207@oracle.com> <56FABFAE.5080008@oracle.com> <56FB768F.8060605@oracle.com> Message-ID: Hi Prasanta, ? Changes are fine and test logic works fine. In test case, There are some trailing white spaces, lines with more than 80 character, and typo?s in println please modify them before check-in. Also bug mentions that that both no.of copies and from/to page are not getting set. As we discussed it looks like only PageRanges is not working. You can update the bug regarding the same with Fix version as 9. ? Thanks, Jay ? From: prasanta sadhukhan Sent: Wednesday, March 30, 2016 12:18 PM To: Phil Race; Jayathirth D V Cc: 2d-dev at openjdk.java.net Subject: Re: [9] RFR: JDK-8061258,,[macosx] PrinterJob's native Print Dialog does not reflect specified Copies or Page Ranges ? Hi Phil, I have updated the webrev with your proposed change. http://cr.openjdk.java.net/~psadhukhan/8061258/webrev.02/ Jay, can you please review and give your +1 on this? Regards Prasanta On 3/29/2016 11:17 PM, Phil Race wrote: Hi, ? You are calling these unconditionally : 387???? jint minPage = JNFCallIntMethod(env, srcPrinterJob, jm_getMinPage); 388???? jint maxPage = JNFCallIntMethod(env, srcPrinterJob, jm_getMaxPage); But it seems they are only used/needed in the else {..} Other than that it looks reasonable but I have not had time to apply the patch and verify it .. -phil. On 03/23/2016 11:47 PM, prasanta sadhukhan wrote: Hi Phil, On 3/24/2016 4:39 AM, Philip Race wrote: On 3/23/16, 4:02 AM, prasanta sadhukhan wrote: Hi Phil, Please review a fix for jdk9 Bug: https://bugs.openjdk.java.net/browse/JDK-8061258 Gosh, it appears I submitted that bug 18 months ago although I don't remember how I came across the problem. I need to understand the fix better and it doesn't help that I don't understand this line :- } else if (selectID == 3) { Yes, this is wrong. I was thinking selectID ==3 was for PD_SELECTION but it was not. Anyways, I have rectified this and updated the webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/8061258/webrev.01/"http://cr.openjdk.java.net/~psadhukhan/8061258/webrev.01/ where the else part handles both PD_SELECTION or PD_NOSELECTION ? I tested with JobAttributes.setDefaultSelection(ALL/RANGE/SELECTION) and also without defaultselection and all are working fine. Regards Prasanta ? SelectID is set from a single flag bit .. so it will never be 3, at least not anywhere I can find. What case is that supposed to be covering ? ? -phil. webrev :HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/8061258/webrev.00/"http://cr.openjdk.java.net/~psadhukhan/8061258/webrev.00/ When user attempts to pre-populate the native dialog with copies and page ranges by calling ?PrintRequestAttributeSet aset = new HashPrintRequestAttributeSet(); ??????? aset.add(new Copies(2)); ??????? aset.add(new PageRanges(3,4)); the print dialog does not reflect the user-defined setting. This is because osx native code was calling getNumberOfPages() from OpenBook.java which was returning UNKNOWN_NUMBER_OF_PAGES (-1). Since getNumberOfPages() returned -1, osx always selected NSPrintAllPages or All Radio button. I fixed it by removing this call to getNumberOfPages() and rely on getMinPage/getMaxPage() as was done in windows (awt_PrintControl.cpp:AwtPrintControl::InitPrintDialog) to select which radio button to be selected. If fromPage > minPage or toPage < maxPage, it means user has selected page ranges so PageRange radio button is to be selected else "All" radio button to be selected. Regards Prasanta ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Wed Mar 30 10:58:57 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 30 Mar 2016 03:58:57 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8042713, , [macosx] Print dialog does not update attribute set with page range In-Reply-To: <56FB7A4D.6020902@oracle.com> References: <56EBC421.7050109@oracle.com> <56EC5524.8040601@oracle.com> <56F12B9E.9000804@oracle.com> <56FACCEE.3010207@oracle.com> <56FB7A4D.6020902@oracle.com> Message-ID: <66454446-8cc9-410c-b2e4-ccb81eef6b5b@default> Hi Prasanta, Changes are working fine along with 8061258 changes and test case is working fine. In test case there are some trailing white spaces, unused imports and lines extending 80 character length. Please modify them before pushing. Thanks, Jay -----Original Message----- From: prasanta sadhukhan Sent: Wednesday, March 30, 2016 12:34 PM To: Phil Race; Jayathirth D V Cc: 2d-dev at openjdk.java.net Subject: Re: [9] RFR JDK-8042713,,[macosx] Print dialog does not update attribute set with page range Hi Phil, Yes, the combination of this fix plus 8061258 works with both the testcase I have along with the fix(es). Jay, can you please review and give your +1 on this? Regards Prasanta On 3/30/2016 12:13 AM, Phil Race wrote: > Like the related fix passing down page ranges to the dialog this looks > reasonable but I have not had time to apply the patch and test it. > You should test the combination of this fix + that for 8061258 before > pushing .. > > -phil. > > > On 03/22/2016 04:25 AM, prasanta sadhukhan wrote: >> Hi Phil, >> >> I have modified the webrev as per your review comment regarding >> 0-based page indices that osx native supports. >> http://cr.openjdk.java.net/~psadhukhan/8042713/webrev.01/ >> I have tested with copies and pageranges set with my testcase and >> also test/java/awt/print/PrinterJob/PageRanges.java >> >> Also, I found one issue with the previous change in that if we select >> PageRange and then print and then we select ALL, then also previous >> page ranges was getting printed and not "All" pages. >> This was because osx CPrinterJob.setAttributes() checks for >> SunPageSelection.class but nowhere SunPageSelection.RANGE/ALL is >> getting added to attribute in osx so >> attributes.get(SunPageSelection.class) was returning null and >> setPageRange() was getting set with wrong values. >> I added SunPageSelection.RANGE/ALL to attribute and also made sure if >> SunPageSelection.ALL is selected, then setPageRange(-1, -1) is set >> similar to windows. >> >> Regards >> Prasanta >> On 3/19/2016 12:51 AM, Phil Race wrote: >>> The bug report seems to be lacking a proper (any) evaluation. >>> >>> It is probably not accurate to say it did not call the "correct" >>> methods since >>> the problem is actually that there was no method that did this and >>> you needed to add them and make sure they also did what they in turn >>> called what native had been calling after setting the attribute. >>> >>> >>> The change itself seems to be mimicing what happens in Windows >>> printing code, ie WPrinterJob.setRangeCopiesAttribute(..) ? >>> >>> Is this intentional ? If so that would have been useful to point out >>> so I did not need to hunt it down. Looking at that code I see that >>> is does a couple of other things (1) has a way of indicating an >>> explicitly set number of copies vs default copies, (2) accepts a >>> boolean indicating if in the dialog a range was actually requested. >>> It looks like in the OSX code we only make the upcall in that case, >>> but I need you to verify that all this works as it is supposed to. >>> >>> Also native used to use a zero-based index and you have changed that >>> without commenting on it. First it is still zero-based in the >>> initialisation and may not always be changed. Secondly if you want >>> 1-based then you seem to have a problem as the new Java method calls >>> >>> setPageRange(from, to); >>> >>> with the 1-based values and that seems to be the method which >>> accepted the zero-based values. >>> This seems very fishy. >>> >>> >>> -phil. >>> >>> >>> On 03/18/2016 02:02 AM, prasanta sadhukhan wrote: >>>> Hi Phil, >>>> >>>> Please review a fix for >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8042713 >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8042713/webrev.00/ >>>> >>>> The OS X platform print dialog has an option to set the page ranges. >>>> If this is done it ought to be reported back in the AttributeSet. >>>> but it was found that the page range attribute is not reported back . >>>> >>>> This is because nsPrintInfoToJavaPrinterJob() does not call correct >>>> Java setxxxAttributes methods to set the attributes. >>>> >>>> I added the corresponding setPageRangeAttribute method along with >>>> setCopiesAttribute method to report back the "page range" and >>>> "copies" in AttributeSet. >>>> >>>> Regards >>>> Prasanta >>> >> > From prahalad.kumar.narayanan at oracle.com Wed Mar 30 11:27:52 2016 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Wed, 30 Mar 2016 04:27:52 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: Antialiased text on translucent backgrounds gets bright artifacts In-Reply-To: <56FAF088.70300@oracle.com> References: <63d69ba8-d5cf-4697-bb5c-f51aaaa8c427@default> <56EB4DBB.9080802@oracle.com> <56F3505B.2070101@oracle.com> <215e497a-db82-4f6f-99e9-bd44f25d5999@default> <56FAF088.70300@oracle.com> Message-ID: <6b400fd0-a335-46a5-9fed-abb06c3fd6a0@default> Hello Jim and Everyone on Java2D Group Good day to you. A quick follow-up to Review Request on bug: Bug : JDK-8015070 Bug Link : https://bugs.openjdk.java.net/browse/JDK-8015070 Thank you Jim for the detailed feedback. It takes a lot of time not only in performing the review, but also in getting the feedback with clear words. In each review, the solution definitely gets better & better. I 'm happy about it...! :) Quick Inferences from previous feedback: Incorporating the fast path into current logic: 1. I agree with you on this point and I noticed this when we modelled the solution as per the mask fill. 2. I ignored it initially for two reasons, a. The statement - if (resA != MaxValFor4ByteArgb)... follows srcColor pre-multiplication step and this will ensure to skip most of the blending calculations pertaining to destination. b. Any addition / tweaks to current logic, might deviate from the SRCOVER_MASKFILL reference model. Many a time, managing code with similar logic across implementation helps a lot. 3. As you said, including the fast path will avoid few multiplications and if checks too. The changes are available in the current webrev. Link: http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.03/ Profiling method, and Metrics: 1. The profiling method that was done yesterday was mere execution of the regression test (available in the webrev) and time measured with System.currentTimeMillis API Since only one iteration was run, the time soared into milli seconds. This could be due to internal glyph caching mechanism. 2. Today, I evolved the regression test, into a benchmark that does the following: a. Select Font style : {Plain, Bold, Italic, Bold Italic} b. Select Font size : {20, 40, 60, 80} c. Trigger drawstring once before benchmark is run. This is to ensure, the font subsystem is done with glyph caching internally. d. Use famous string that has all characters-" The quick brown fox jumps over the lazy dog. 0123456789. " e. For every style-size combination - run the test for 20 iterations and take the average. (Note: Font is fixed to 'verdana' ) f. Modify the precision from System.currentTimeMillis to System.nanoTime() and reduce elapsedTime to micro seconds. 3. With the above setup in code, my observation on windows is as follows: a. In many cases, The optimized logic is either equal-to (or) better in performance than the un-optimized logic. The difference is very minimal - few tens to few hundreds of micro-seconds. b. The optimized algorithm improves performance for Pre-multiplied alpha based destination buffer. c. There are occasional huge deviations where optimized logic seems to take longer time. These could be due to external factors like- stalls for memory, bus io etc., Since, the deviation is in micro seconds, I believe, it may not be a concern. d. The complete list of time measurement taken up on windows x86_64 release build is as-follows- I 'm not sure, how the data appears in the final webrev-email. Kindly excuse, if the data is un-readable. Platform : Windows x86_64 Release Build Algorithm : Unoptimized. webrev.00 `````````````````````````````````````````````````````````````````````````` Executing Bench For Image Type: IntArgb -Font Style: Plain /Font Size: 20 /Time consumed (us): 84.742 -Font Style: Plain /Font Size: 40 /Time consumed (us): 318.395 -Font Style: Plain /Font Size: 60 /Time consumed (us): 657.474 -Font Style: Plain /Font Size: 80 /Time consumed (us): 813.079 -Font Style: Bold /Font Size: 20 /Time consumed (us): 386.380 -Font Style: Bold /Font Size: 40 /Time consumed (us): 339.301 -Font Style: Bold /Font Size: 60 /Time consumed (us): 492.631 -Font Style: Bold /Font Size: 80 /Time consumed (us): 625.812 -Font Style: Italic /Font Size: 20 /Time consumed (us): 235.059 -Font Style: Italic /Font Size: 40 /Time consumed (us): 320.180 -Font Style: Italic /Font Size: 60 /Time consumed (us): 474.558 -Font Style: Italic /Font Size: 80 /Time consumed (us): 1188.169 -Font Style: Bold-Italic /Font Size: 20 /Time consumed (us): 426.988 -Font Style: Bold-Italic /Font Size: 40 /Time consumed (us): 374.064 -Font Style: Bold-Italic /Font Size: 60 /Time consumed (us): 732.375 -Font Style: Bold-Italic /Font Size: 80 /Time consumed (us): 864.68 Executing Bench For Image Type: IntArgb_Pre -Font Style: Plain /Font Size: 20 /Time consumed (us): 129.768 -Font Style: Plain /Font Size: 40 /Time consumed (us): 206.299 -Font Style: Plain /Font Size: 60 /Time consumed (us): 249.941 -Font Style: Plain /Font Size: 80 /Time consumed (us): 362.372 -Font Style: Bold /Font Size: 20 /Time consumed (us): 145.096 -Font Style: Bold /Font Size: 40 /Time consumed (us): 151.589 -Font Style: Bold /Font Size: 60 /Time consumed (us): 240.972 -Font Style: Bold /Font Size: 80 /Time consumed (us): 331.894 -Font Style: Italic /Font Size: 20 /Time consumed (us): 95.028 -Font Style: Italic /Font Size: 40 /Time consumed (us): 245.300 -Font Style: Italic /Font Size: 60 /Time consumed (us): 270.379 -Font Style: Italic /Font Size: 80 /Time consumed (us): 398.139 -Font Style: Bold-Italic /Font Size: 20 /Time consumed (us): 93.243 -Font Style: Bold-Italic /Font Size: 40 /Time consumed (us): 475.406 -Font Style: Bold-Italic /Font Size: 60 /Time consumed (us): 280.085 -Font Style: Bold-Italic /Font Size: 80 /Time consumed (us): 357.486 Platform : Windows x86_64 Release Build Algorithm : Optimized. webrev.03 `````````````````````````````````````````````````````````````````````````` Executing Bench For Image Type: IntArgb -Font Style: Plain /Font Size: 20 /Time consumed (us): 120.954 -Font Style: Plain /Font Size: 40 /Time consumed (us): 364.871 -Font Style: Plain /Font Size: 60 /Time consumed (us): 561.799 -Font Style: Plain /Font Size: 80 /Time consumed (us): 653.390 -Font Style: Bold /Font Size: 20 /Time consumed (us): 261.566 -Font Style: Bold /Font Size: 40 /Time consumed (us): 311.054 -Font Style: Bold /Font Size: 60 /Time consumed (us): 490.735 -Font Style: Bold /Font Size: 80 /Time consumed (us): 656.559 -Font Style: Italic /Font Size: 20 /Time consumed (us): 314.289 -Font Style: Italic /Font Size: 40 /Time consumed (us): 378.750 -Font Style: Italic /Font Size: 60 /Time consumed (us): 491.181 -Font Style: Italic /Font Size: 80 /Time consumed (us): 770.172 -Font Style: Bold-Italic /Font Size: 20 /Time consumed (us): 375.336 -Font Style: Bold-Italic /Font Size: 40 /Time consumed (us): 571.371 -Font Style: Bold-Italic /Font Size: 60 /Time consumed (us): 548.300 -Font Style: Bold-Italic /Font Size: 80 /Time consumed (us): 714.526 Executing Bench For Image Type: IntArgb_Pre -Font Style: Plain /Font Size: 20 /Time consumed (us): 45.026 -Font Style: Plain /Font Size: 40 /Time consumed (us): 219.016 -Font Style: Plain /Font Size: 60 /Time consumed (us): 279.617 -Font Style: Plain /Font Size: 80 /Time consumed (us): 282.829 -Font Style: Bold /Font Size: 20 /Time consumed (us): 51.809 -Font Style: Bold /Font Size: 40 /Time consumed (us): 117.563 -Font Style: Bold /Font Size: 60 /Time consumed (us): 508.049 -Font Style: Bold /Font Size: 80 /Time consumed (us): 402.802 -Font Style: Italic /Font Size: 20 /Time consumed (us): 79.320 -Font Style: Italic /Font Size: 40 /Time consumed (us): 227.473 -Font Style: Italic /Font Size: 60 /Time consumed (us): 330.488 -Font Style: Italic /Font Size: 80 /Time consumed (us): 353.782 -Font Style: Bold-Italic /Font Size: 20 /Time consumed (us): 54.687 -Font Style: Bold-Italic /Font Size: 40 /Time consumed (us): 235.505 -Font Style: Bold-Italic /Font Size: 60 /Time consumed (us): 227.205 -Font Style: Bold-Italic /Font Size: 80 /Time consumed (us): 324.308 Updated webrev with changes for the fast-path : http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.03/ Kindly review and provide your suggestions. Thank you once again for detailed review and feedback Have a good day Prahalad N. -----Original Message----- From: Jim Graham Sent: Wednesday, March 30, 2016 2:46 AM To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: Antialiased text on translucent backgrounds gets bright artifacts Hi Prahalad, This latest version looks like it should produce correct answers. I'd like to see benchmark results on more platforms, particularly Windows since the different compilers may optimize these things differently. Also, you didn't mention what data set you used for benchmarking. I'd like to see benchmark results for small, medium and large font sizes, and possibly bold and italic fonts as well. The reason is that the relative ratios of "empty glyph pixels" to "partial glyph pixels" to "fully covered glyph pixels" changes depending on the font type and size so if you made one of those faster and another slower then the results may be seen as a gain in one type of test if you only test one font type and size and it happens to match the part of the code that is more streamlined. Also, for small font sizes the per-glyph overhead might hide per-pixel issues. Please share which fonts and sizes you used for testing and consider using some different sizes, including something very large like 36 or 48 points (something with large areas of opaque pixels) as well as more normal sizes that appear in GUIs. Also, bold fonts can have a higher percentage of opaque pixels. In particular... This latest version is missing the "fast path" from the existing code for the case of srcA == 255 and glyphA == 255 where it just stores the FG_PIXEL values directly. For large fonts/glyphs that case may be as important as detecting empty glyph pixels. On the other hand, an additional "if" may cause the compiler to generate less efficient code as per Sergey's concern. Since this "if" eliminates some multiplies and possibly some divides, I'd hope it would be a win-win. You could add the fast path back inside the case where mixValSrc is 255 and just test srcA for 255 and do the Store ## DST ## PixelData() macro that used to be at the end of the block in the existing code, and then use "break;" to escape out of the do/while surrounding the whole macro so it moves on to the next pixel. (Arguably, we might want to consider teaching our SRCOVER_MASKFILL to do the same thing. I think that was one of the added values of having a separate GLYPH loop, but really both should be optimizing that case...) I can see now that the macro switch to use the same macro set as SRCOVER_MASKFILL required you to compute the pixel address, as you noted in your summary. It makes the new macro more cumbersome and makes it look like it's doing a bit more work per-pixel, but in reality I think the overall operations end up being the same as long as the compiler optimizes the deliberate multiplications the same way it did for implicit multiplications in the "pRas[foo]" and "pRas[foo*4]" code that was being generated previously. Benchmarks will tell us if we're good there... ...jim On 3/28/16 5:33 AM, Prahalad Kumar Narayanan wrote: > Hello Everyone on Java2D Group > > Good day to you. > > This is a follow-up to Review Request on bug: > Bug : JDK-8015070 > Bug Link : https://bugs.openjdk.java.net/browse/JDK-8015070 > > First, Thanks to Jim and Sergey for their feedback on the changes so far. > > Inferences from Jim 's Feedback on Loading destination colors: > 1. The API or Macro that I had earlier used to Load DST colors, indeed, adjusted destination color components with divide-by-alpha if destination was already pre-multiplied. > My apologies.. I should have spotted this error at the first iteration itself. > 2. Due to the divide-by-alpha adjustment, the remaining logic would become incorrect. ( Especially, the multiplication with dstF based on pre-mulitplication status ) > 3. Correct API is being used now, and the dstColor components are loaded directly without any divide-by-alpha adjustment. > > Inferences from Sergey's Feedback on Performance. > 1. To set the context for everyone, the logic present in the current webrev.02 is modelled as per SRCOVER_MASKFILL. > There are multiple if (...) conditions that remove un-necessary blending calculations. Ideally this should improve performance. > However, since some data are not readily available (as present in SRCOVER_MASKFILL), few additional calculations have been added. > They are: pre-multiplying srcColor with alpha and assigning to res. > Finding the correct address of Pixel using DST_PTR and PixelStride. > Henceforth, as Sergey suggests, Observation on performance will be beneficial. > 2. The performance of the new logic was measured with linux-x86_64-normal-server-release config and compared with the logic used in un-optimized code in webrev.00 > 3. Result: The newer logic provides a fractional gain (about 15 - 20 ms) over the older logic. > > Other Subtle Changes: > 1. The test file has been renamed from AADrawStringArtifact.java to more meaningful - AntialiasedTextArtifact.java > 2. The test file tests for both TYPE_INT_ARGB and TYPE_INT_ARGB_PRE BufferedImage formats. > The code has been well commented to explain the logic used in every function. > > Kindly take your time to review the changes in the webrev link mentioned below and provide your suggestions. > Webrev Link: > http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.02/ > > > Thank you for your time in review > Have a good day > > Prahalad N. > > > -----Original Message----- > From: Jim Graham > Sent: Thursday, March 24, 2016 7:57 AM > To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: > Antialiased text on translucent backgrounds gets bright artifacts > > Hi Prahalad, > > (On a side note - ouch! I came up with these macros in the first > place, but 20 years later I'm now realizing just how hard they are to > navigate and review. My apologies...) > > The macro you are still using to load the destination data is one that loads it to non-premultiplied components, which means it will divide out the alpha if the destination is PRE. The rest of the logic assumes that the components were loaded without any adjustment of their premultiplication so not only is that division an unnecessary operation, it makes the following math wrong. > > The SRCOVER_MASKFILL macro seems to use "Postload ## STRATEGY ## From ## TYPE" which seems to load them into separate components without any adjustment of their pre-multiplication status. This is paired with "LoadAlphaFrom ## TYPE ## For ## STRATEGY" to load just the destination alpha for computing dstF... > > ...jim > > On 3/22/16 4:35 AM, Prahalad Kumar Narayanan wrote: >> Hello Everyone on Java2D Group >> >> Good day to you. >> >> This is a Follow-up to Review Request on the bug: >> Bug : JDK-8015070 Anti-aliased Text on Translucent background gets bright artifacts >> Bug Link : https://bugs.openjdk.java.net/browse/JDK-8015070 >> >> First, Sincere thanks to Jim for his valuable feedback. >> 1. As Jim correctly mentioned, SRCOVER_MASKFILL has a similar logic to blend two Translucent colors based on an Alpha mask. >> 2. The calculations are exactly the same as the changes in previous webrev. >> However the logic of SRCOVER_MASKFILL is 'Optimized' to reduce the number of computations. >> 3. This optimization is definitely required because, the logic is executed for every single pixel in a glyph. >> Example: If a string is made up of 5 English characters with each character having 32 x 32 pixels, >> The anti-aliasing logic will be executed for 5 x 32 x 32 iterations. >> Reducing computation per pixel will imply a huge benefit for complete drawString operation. >> >> Observation from SRCOVER_MASKFILL >> 1. The mask fill reduces computations by through multiple if(...) conditions. >> Each if condition affirms whether the next set of computations are required. >> 2. Optimization 1: If mask value is 0- skip entire logic. >> 3. Optimization 2: If mask value is maximum, say 255, take srcA directly without multiplying with maskAlpha ( Reason: 1 * srcAlpha = srcAlpha ) >> 4. Optimization 3: Compute pre-multiplied resColor in two steps. First with srcColor and then with dstColor. >> If the resAlpha from 1st step (i.e., srcColor) is fully opaque, avoid blending dstColor altogether. >> >> Changes in Current Webrev.01 >> 1. The fix for the current bug is modelled based on SRCOVER_MASKFILL. >> 2. The changes have been verified to work on windows, linux and mac operating systems. >> 3. The automated Test file- AADrawStringArtifact.java runs as expected >> Identifies artifact & throws exception when run on JDK 7 and 8. >> With JDK9, the test file returns without error. >> 3. JPRT build has been run to ensure, changes build on all supported platforms. >> JPRT job link : >> http://scaaa637.us.oracle.com//archive/2016/03/2016-03-22-070604.prah >> n >> ara-linux.client >> >> Kindly review the changes in the below mentioned link and provide your views >> Webrev Link : >> http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.01/ >> >> >> Thank you for your time in review >> Have a good day >> >> Prahalad N. >> >> >> -----Original Message----- >> From: Jim Graham >> Sent: Friday, March 18, 2016 6:07 AM >> To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: >> Antialiased text on translucent backgrounds gets bright artifacts >> >> Hi Prahalad, >> >> This basically boils down to "alpha blending math needs to be performed in premultiplied form" and the existing code was not doing that. >> >> Your changes do add a pre-multiplication step to the math in two >> places >> - when you mix the src alpha and the glyph alpha at the top of the macro, and again when you do the Multiply(dst, dstA, dst) step in the middle. In that sense, the new math is correct. >> >> However, it is not the optimal way to implement this. In particular, >> the macro used here to load the data from the destination is the one >> that loads it into 4 ARGB non-premultiplied values. If the >> destination is non-PRE, then your added multiply step is exactly what >> is needed, but it could be combined with the multiply that will >> happen later in the blending equation, so it is an added step rather >> than a fixed fraction in the existing MultMultAdd parameters. >> Additionally, if the destination is already PRE, then the macro being >> used to load the dst pixel data there will have done a divide step to >> divide out the alpha from the destination, only to have you reverse >> that math with your new >> Multiply() step. That's a lot of math to end up with a NOP. >> >> The MUL8 you added for the srcA and glyph value is needed, that change is good. Since it is common for glyph pixels to have zero alpha, you might want to test the glyph alpha for 0 and skip the pixel before you do the multiply, though. This would add one more if, but it would be a common case. >> >> The trickier part is to load the destination components without un-premultiplying them. Unfortunately there is no "Load...ToArgbPre" >> macro to parallel the Load macro used in the function. Perhaps there should be, but you'd still end up with an extra multiply step as I mentioned above because you can fold the premultiplication of the dst data into the MultMultAdd by carefully choosing the parameters you use in the math there. >> >> The good news is that the way that the SRCOVER_MASKFILL uses the various type-specific macros works around this a bit and minimizes the number of multiplies that happen. You could check out DEFINE_SRCOVER_MASKFILL and see how it works in the case where pMask is not null (pMask is an alpha mask with values very similar to the glyphAA data). Modeling this code on that code would correct the math and minimize it as well... >> >> ...jim >> >> On 3/17/16 3:00 AM, Prahalad Kumar Narayanan wrote: >>> Hello Everyone on Java2D Group >>> >>> Good day to you. >>> >>> Herewith, I 'm sharing the webrev for two identical Java2D Bugs. >>> >>> Bug ID : JDK-8015070 >>> >>> Title : Antialiased text on translucent backgrounds gets >>> bright artifacts >>> >>> Link : https://bugs.openjdk.java.net/browse/JDK-8015070 >>> >>> Bug ID : JDK-8013564 ( currently closed as duplicate ) >>> >>> Title : Font rendering anti-aliasing in translucent >>> BufferedImages broken >>> >>> Link : https://bugs.openjdk.java.net/browse/JDK-8013564 >>> >>> Webrev Link : >>> http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.00/ >>> >>> Quick Summary on Bugs : >>> >>> ```````````````````````````````````````````````` >>> >>> 1. Artifacts appear on Edges of text characters when anti-aliased >>> text is drawn on Translucent background >>> >>> 2. The issue is reproducible on all platforms - windows, linux and mac os. >>> >>> 3. Besides, the issue is reproduced with the commonly used pixel >>> format- 4ByteArgb. >>> >>> Root Cause & Solution : >>> >>> ```````````````````````````````````````````````` >>> >>> 1. The Macro: GlyphListAABlend4ByteArgb in File: LoopMacros.h uses >>> the standard blending algorithm >>> >>> dstColor = [ srcColor * glyphAlpha + dstColor * (1 - >>> glyphAlpha) ] / dstAlpha >>> >>> 2. The above equation works only when the srcColor and dstColor are Opaque. >>> >>> 3. When srcColor and dstColor are Translucent, their alphaComponent >>> will influence the visibility of the color, and visibility of the >>> color below. >>> >>> 4. The new set of calculations for blending Translucent source and >>> destination colors is given as >>> >>> resAlpha = 1 - ((1 - srcAlpha) * (1 - dstAlpha)) >>> >>> resColor = [ srcColor * srcAlpha + dstColor * dstAlpha * >>> (1 >>> - >>> srcAlpha) ] / resAlpha >>> >>> 5. Reference text for the equation: >>> https://en.wikipedia.org/wiki/Alpha_compositing >>> >>> 6. With the above modification to the blending logic, the artifacts >>> do not appear and issues are fixed. >>> >>> Jtreg & Jprt Results : >>> >>> ```````````````````````````````````````````````` >>> >>> 1. A simple test-file: AADrawStringArtifact.java has been created >>> to be a part of jtreg test cases. >>> >>> The test file is well commented to explain - nature of >>> artifact and how the test tries to identify them. >>> >>> As required, the test case fails with Jdk 7, Jdk 8 and >>> succeeds with Jdk 9-internal (built with changes for the bug fix) >>> >>> 2. The changes to blending logic lies within >>> java.desktop/src/share/native/... >>> >>> Henceforth, JPRT was used to ensure successful build >>> across all supported platforms >>> >>> Jprt Job Link : >>> http://scaaa637.us.oracle.com//archive/2016/03/2016-03-17-072001.pra >>> h >>> n >>> ara-linux.client >>> >>> The build succeeds on all platforms. >>> >>> Kindly review the webrev link and provide your views and suggestions. >>> >>> Webrev Link : >>> http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.00/ >>> >>> If the changes look good, we could take up the changes for source checkin. >>> >>> Thank you for your time in review >>> >>> Have a good day >>> >>> Prahalad N. >>> From ajit.ghaisas at oracle.com Wed Mar 30 12:12:19 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Wed, 30 Mar 2016 05:12:19 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception In-Reply-To: <56FAF58E.5060208@oracle.com> References: <3969befd-57cd-48ee-bed5-173a28e7bd08@default> <56DFFC9F.4020403@oracle.com> <70f247c0-6f3e-472a-b7b0-b02814010e30@default> <56E16D0A.3060807@oracle.com> <56E1E2A5.1020008@oracle.com> <56F1C6F2.6000305@oracle.com> <56F1D0DB.9000508@oracle.com> <56F33180.8060408@oracle.com> <56F334D3.5060106@oracle.com> <56FAF58E.5060208@oracle.com> Message-ID: <737019e7-94af-43d8-830b-fd676f6a98e1@default> Hi, Thanks Sergey and Phil for answering some of Jim's concerns regarding this fix. I have answered rest of them below: Raster.java, line 742: This branch of the switch statement instantiates a SWR which doesn't have a specific buffer type. It could be replaced with just "break;" and let the code after the switch create the raster (it can't be deleted from the switch statement because the default would throw an exception, but it could just "break;" on that dataType). At a minimum, though, it didn't need the instanceof or cast that was added since it will just fall through to exactly the same code anyway. >>> [Ajit] : Good catch. As suggested, I have replaced this with just a 'break' statement. It's much cleaner now. Thanks. Raster.java, line 894: Why was the test for dataType removed from this if statement? >>> [Ajit] : It was an extra check. It was removed after Phil's review comment. The check for 'dataType' is removed as it is populated from 'dataBuffer' (and not from SampleModel as in other methods). The newly added check (dataBuffer instanceof DataBufferByte) that uses 'dataBuffer' is sufficient to decide whether to create BytePackedRaster or SunWritableRaster. Raster.java: line 980: Something to file as a potential bug for future work. The test for getSampleSize(0) in this method is much more permissive than the test for bitsPerPixel in createPackedRaster just above this method. Both determine whether to return a BytePackedRaster so they should probably agree. >>> [Ajit] : I agree. The code here can be made in line with test for bitsPerPixel as in createPackedRaster method. I will create a bug for this. Raster.java, line 986: Something to file as a potential bug for future work since the fix would have to be verified that it doesn't disrupt the other parts of this method, but... The set of if statements in this method never checked for a BandedSampleModel to try to create a BandedRaster as in createBandedRaster. On the other hand, no developer has complained so far (that I know of, but maybe we have an old bug filed on it that I'm not aware of). >>>[Ajit] : Without my fix, it was easier to get RasterFormatException as explained in Bug Description. This fix enhances the code by making type specific Raster class constructors type-safe. Now, the bigger question is: Whether methods in Raster.java support all possible combinations of Raster creations? What I can say is - this fix does not break anything than what is already present in Raster.java. If there is specific user complaint or any existing bug - we can look into it separately. Raster.java: the same comments for createRaster above apply for createWritableRaster at line 1033. The following 2 comments are identical for all of the raster types { ByteBandedRaster.java, line 76: This code will throw a ClassCastException now instead of the RasterFormatException that used to be thrown. Do we care? It would be easy enough to add a test to just this method (and the similar versions in other files). >>> [Ajit] : Since we have decided to make the type specific Raster class constructors type safe, yes, it is possible to get ClassCastException. But, as the usage of these classes is guarded now with "instanceof" checks, it would be rare. ByteBandedRaster.java, line 668: Extra credit: This cast could be avoided if we make SunWritableRaster employ generics for a strongly typed DataBuffer. >>> [Ajit] : the casted member ' dataBuffer' on this line is a member of Raster class. The class hierarchy of ByteBandedRaster is ( added on single line for convenience) -------- ByteBandedRaster extends SunWritableRaster extends WritableRaster extends Raster. I am not quite clear on how we can avoid cast on this line. Can you please elaborate? } ShortInterleavedRaster - I think the import of DataBuffer can be eliminated now? >>> [Ajit] Good catch - I have eliminated the extra import now. Thanks. Here is the updated webrev: http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.05/ Request you to review it. Thanks, Ajit On 3/28/16 3:18 AM, Ajit Ghaisas wrote: > Hi, > > Thanks Jim for thorough review. > > Here is the updated webrev : > http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.04/ > > In this update : > 1) I have corrected missing space after casting > 2) I have modified code to adapt suggested indentation for blocks having conditionals & method declaration split on multiple lines. > > Please note that, I have done indentation change only if it is related to the code changes done as part of this fix. > The files in this review already have indentation issues and fixing all of them will result in multiple changes masking the actual code changes that fixes the reported issue. > > Request you to review the updated webrev. > > Regards, > Ajit > > -----Original Message----- > From: Jim Graham > Sent: Thursday, March 24, 2016 5:59 AM > To: Phil Race > Cc: 2d-dev > Subject: Re: [OpenJDK 2D-Dev] [9] Review-request for 6353518: Creation > of a WritableRaster with a custom DataBuffer causes erroneous > Exception > > I should point out that this form I demonstrate below is only used when there are continuation lines on the prefix to the code block (conditionals, method declarations, loop controls, etc.), so: > > if (some simple condition) { > ... > } > > and: > > if (some complex condition && > some additional condition) > { > ... > } > > but, not: > > if (some single line condition) > { > // blech > ... > } > > The reason for this is that the standard indentation would recommend: > > if (some complex condition && > some additional condition) { > // code block > } > or > void foomethod(int sx, int sy, > int dx, int dy) { > // code block > } > > which may be more compact, but the lack of a breaking line means you have to vary the indentation of the declarations/conditionals and as a result they don't line up nicely which makes them harder to scan if they are all related (and frequently in graphics code you end up with a series of very similar arguments or conditionals that are more readable if they line up nicely), and the only indication of when the multiple lines of continued declaration/conditionals end and the body of the method begins is the number of spaces - noting that frequently the indentation on lines in practice is just wrong so this form makes it hard to distinguish between "that line is a continuation line" and "someone indented that line wrong"... > > ...jim > > On 3/23/16 5:14 PM, Jim Graham wrote: >> For the record, in many places in the 2D code we also adopt a slight >> extension of the indentation rules such that the below might be written as: >> >> public ByteBandedRaster(SampleModel sampleModel, >> DataBufferByte dataBuffer, >> Point origin) >> { >> // body lines of the method... >> } >> >> with the open curly brace on the following line so that it more >> visually points out the beginning of the body block of the method and >> it's easy to find the start/end of the block by sighting down the >> left margin. The official policy is for the "{" to be at the end of >> the previous line after "Point origin) {" and as more new engineers >> work on the code and follow the official rules, the above form >> becomes less common. (Sad face since I particularly like the above >> form...) >> >> ...jim >> >> On 3/22/16 4:10 PM, Phil Race wrote: >>> Ajit, >>> >>> There is also some odd indentation in ByteBandedRaster.java which is >>> not yours but >>> >>> 98 public ByteBandedRaster(SampleModel sampleModel, >>> 99 DataBufferByte dataBuffer, >>> 100 Point origin) { >>> >>> >>> This appears to be the result of someone using tabs a long time ago. >>> >>> Since you are touching the method signature lines anyway may be >>> better fixed so we have these aligned >>> >>> public ByteBandedRaster(SampleModel sampleModel, >>> DataBufferByte dataBuffer, >>> Point origin) { >>> >>> [not sure if that will make it through mail as intended]. >>> >>> Here in Raster.java, the first condition now seems to be redundant .. >>> 890 if (dataType == DataBuffer.TYPE_BYTE && >>> 891 dataBuffer instanceof DataBufferByte && >>> >>> >>> >>> -phil. >>> >>> >>> On 03/22/2016 03:28 PM, Jim Graham wrote: >>>> Hi Ajit, >>>> >>>> Most of your if statements are spaced wrong. There should be a >>>> space between "if" and the parentheses. I'll review more later, >>>> but I noticed that issue in the first couple of files I looked at... >>>> >>>> ...jim >>>> >>>> On 3/15/16 7:05 AM, Ajit Ghaisas wrote: >>>>> Hi, >>>>> >>>>> Thanks Sergey and Jim for suggestions. >>>>> >>>>> I have made the data specific Raster constructors type safe >>>>> now. Also, I have modified all Raster creations in Raster.java to >>>>> support custom DataBuffer classes. >>>>> >>>>> Please review the changes present in updated webrev : >>>>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.02/ >>>>> >>>>> Regards, >>>>> Ajit >>>>> >>>>> -----Original Message----- >>>>> From: Jim Graham >>>>> Sent: Friday, March 11, 2016 2:40 AM >>>>> To: Sergey Bylokhov; Ajit Ghaisas; 2d-dev >>>>> Subject: Re: [OpenJDK 2D-Dev] [9] Review-request for 6353518: >>>>> Creation of a WritableRaster with a custom DataBuffer causes >>>>> erroneous Exception >>>>> >>>>> Yes, those constructors should be type-safe. Perhaps that was >>>>> done to save code in the caller, but that is a small price to pay >>>>> to avoid errors in the future, and it makes sure there is a backup >>>>> plan for different kinds of buffers... >>>>> >>>>> ...jim >>>>> >>>>> On 3/10/16 4:48 AM, Sergey Bylokhov wrote: >>>>>> Hi, Ajit. >>>>>> What about other cases in Raster.java, where the DataBuffer is >>>>>> passed as a parameter? Probably we can simplify the code and find >>>>>> all such issues if we changes the ByteInterleavedRaster/etc. For example: >>>>>> >>>>>> ByteInterleavedRaster(SampleModel sampleModel,DataBuffer >>>>>> dataBuffer,...) to >>>>>> >>>>>> ByteInterleavedRaster(SampleModel sampleModel,DataBufferByte >>>>>> dataBuffer,...) >>>>>> >>>>>> Because we throw an exception in such cases anyway: >>>>>> >>>>>> if (!(dataBuffer instanceof DataBufferByte)) { >>>>>> throw new RasterFormatException("ByteInterleavedRasters >>>>>> must have " >>>>>> + "byte DataBuffers"); >>>>>> } >>>>>> >>>>>> And the compiler will help us, what everybody think about it? >>>>>> >>>>>> On 09.03.16 17:38, Ajit Ghaisas wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Modified the test and added check for >>>>>>> MultiPixelPackedSampleModel condition. >>>>>>> >>>>>>> Please review updated webrev : >>>>>>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.01/ >>>>>>> >>>>>>> Regards, >>>>>>> Ajit >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Sergey Bylokhov >>>>>>> Sent: Wednesday, March 09, 2016 4:06 PM >>>>>>> To: Ajit Ghaisas; awt-dev at openjdk.java.net; Semyon Sadetsky; >>>>>>> Ambarish Rapte; 2d-dev >>>>>>> Subject: Re: [9] Review-request for 6353518: Creation of a >>>>>>> WritableRaster with a custom DataBuffer causes erroneous >>>>>>> Exception >>>>>>> >>>>>>> Changes for 2d area.(cc) >>>>>>> >>>>>>> >>>>>>> On 07.03.16 11:20, Ajit Ghaisas wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-6353518 >>>>>>>> >>>>>>>> Issue : (Text from bug description) >>>>>>>> >>>>>>>> An attempt to create a WritableRaster via >>>>>>>> Raster.createWritableRaster(SampleModel sm, DataBuffer db, >>>>>>>> Point >>>>>>>> location) using a custom DataBuffer causes an erroneous >>>>>>>> RasterFormatException. >>>>>>>> Apparently the reason for this bug is that >>>>>>>> IntegerComponentRaster insists on being passed an instance of >>>>>>>> DataBufferInt rather than just a DataBuffer with a DataType of TYPE_INT. >>>>>>>> This is quite annoying since DataBufferInt is declared final >>>>>>>> and thus cannot be extended. >>>>>>>> >>>>>>>> Fix : >>>>>>>> >>>>>>>> The last line of Raster.createWritableRaster() method already >>>>>>>> has a way to handle generic case if the input does not match >>>>>>>> any of the cases in switch statements in that method. >>>>>>>> >>>>>>>> The fact that " *InterleavedRaster() constructors throw >>>>>>>> exception if DataBuffer passed to them does not match the >>>>>>>> expected type" was ignored earlier. >>>>>>>> >>>>>>>> This fix adds a check of "DataBuffer type" before creating >>>>>>>> respective >>>>>>>> *InterleavedRaster() objects. >>>>>>>> >>>>>>>> It constructs the SunWritableRaster in case DataBuffer type >>>>>>>> does not match any data specific DataBuffer classes >>>>>>>> (DataBufferByte, DataBufferUShort, DataBufferInt) >>>>>>>> >>>>>>>> Request to review webrev containing this fix : >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.00/ >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Ajit >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, Sergey. >>>>>>> >>>>>> >>>>>> >>> From james.graham at oracle.com Wed Mar 30 20:15:50 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 30 Mar 2016 13:15:50 -0700 Subject: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: Antialiased text on translucent backgrounds gets bright artifacts In-Reply-To: <6b400fd0-a335-46a5-9fed-abb06c3fd6a0@default> References: <63d69ba8-d5cf-4697-bb5c-f51aaaa8c427@default> <56EB4DBB.9080802@oracle.com> <56F3505B.2070101@oracle.com> <215e497a-db82-4f6f-99e9-bd44f25d5999@default> <56FAF088.70300@oracle.com> <6b400fd0-a335-46a5-9fed-abb06c3fd6a0@default> Message-ID: <56FC33F6.1060108@oracle.com> Hi Prahalad, Benchmarks must run for a significant period of time to be valid. Measuring with nanoTime() is fine, but the run times should exceed at least a couple of seconds, not a few nanoseconds. You might want to use Java2DBench instead (in src/demo/share/java2d in the java.desktop repo), which calibrates test times, does multiple runs, and includes an analyzer to compare results from multiple test runs... ...jim On 3/30/2016 4:27 AM, Prahalad Kumar Narayanan wrote: > Hello Jim and Everyone on Java2D Group > > Good day to you. > > A quick follow-up to Review Request on bug: > Bug : JDK-8015070 > Bug Link : https://bugs.openjdk.java.net/browse/JDK-8015070 > > Thank you Jim for the detailed feedback. > > It takes a lot of time not only in performing the review, but also in getting the feedback with clear words. > In each review, the solution definitely gets better & better. I 'm happy about it...! :) > > Quick Inferences from previous feedback: > > Incorporating the fast path into current logic: > 1. I agree with you on this point and I noticed this when we modelled the solution as per the mask fill. > 2. I ignored it initially for two reasons, > a. The statement - if (resA != MaxValFor4ByteArgb)... follows srcColor pre-multiplication step and this will ensure to skip most of the blending calculations pertaining to destination. > b. Any addition / tweaks to current logic, might deviate from the SRCOVER_MASKFILL reference model. > Many a time, managing code with similar logic across implementation helps a lot. > 3. As you said, including the fast path will avoid few multiplications and if checks too. > The changes are available in the current webrev. > Link: http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.03/ > > Profiling method, and Metrics: > 1. The profiling method that was done yesterday was mere execution of the regression test (available in the webrev) and time measured with System.currentTimeMillis API > Since only one iteration was run, the time soared into milli seconds. This could be due to internal glyph caching mechanism. > 2. Today, I evolved the regression test, into a benchmark that does the following: > a. Select Font style : {Plain, Bold, Italic, Bold Italic} > b. Select Font size : {20, 40, 60, 80} > c. Trigger drawstring once before benchmark is run. This is to ensure, the font subsystem is done with glyph caching internally. > d. Use famous string that has all characters-" The quick brown fox jumps over the lazy dog. 0123456789. " > e. For every style-size combination - run the test for 20 iterations and take the average. (Note: Font is fixed to 'verdana' ) > f. Modify the precision from System.currentTimeMillis to System.nanoTime() and reduce elapsedTime to micro seconds. > > 3. With the above setup in code, my observation on windows is as follows: > a. In many cases, The optimized logic is either equal-to (or) better in performance than the un-optimized logic. > The difference is very minimal - few tens to few hundreds of micro-seconds. > b. The optimized algorithm improves performance for Pre-multiplied alpha based destination buffer. > c. There are occasional huge deviations where optimized logic seems to take longer time. > These could be due to external factors like- stalls for memory, bus io etc., > Since, the deviation is in micro seconds, I believe, it may not be a concern. > d. The complete list of time measurement taken up on windows x86_64 release build is as-follows- > I 'm not sure, how the data appears in the final webrev-email. > Kindly excuse, if the data is un-readable. > > Platform : Windows x86_64 Release Build > Algorithm : Unoptimized. webrev.00 > `````````````````````````````````````````````````````````````````````````` > Executing Bench For Image Type: IntArgb > -Font Style: Plain /Font Size: 20 /Time consumed (us): 84.742 > -Font Style: Plain /Font Size: 40 /Time consumed (us): 318.395 > -Font Style: Plain /Font Size: 60 /Time consumed (us): 657.474 > -Font Style: Plain /Font Size: 80 /Time consumed (us): 813.079 > -Font Style: Bold /Font Size: 20 /Time consumed (us): 386.380 > -Font Style: Bold /Font Size: 40 /Time consumed (us): 339.301 > -Font Style: Bold /Font Size: 60 /Time consumed (us): 492.631 > -Font Style: Bold /Font Size: 80 /Time consumed (us): 625.812 > -Font Style: Italic /Font Size: 20 /Time consumed (us): 235.059 > -Font Style: Italic /Font Size: 40 /Time consumed (us): 320.180 > -Font Style: Italic /Font Size: 60 /Time consumed (us): 474.558 > -Font Style: Italic /Font Size: 80 /Time consumed (us): 1188.169 > -Font Style: Bold-Italic /Font Size: 20 /Time consumed (us): 426.988 > -Font Style: Bold-Italic /Font Size: 40 /Time consumed (us): 374.064 > -Font Style: Bold-Italic /Font Size: 60 /Time consumed (us): 732.375 > -Font Style: Bold-Italic /Font Size: 80 /Time consumed (us): 864.68 > > Executing Bench For Image Type: IntArgb_Pre > -Font Style: Plain /Font Size: 20 /Time consumed (us): 129.768 > -Font Style: Plain /Font Size: 40 /Time consumed (us): 206.299 > -Font Style: Plain /Font Size: 60 /Time consumed (us): 249.941 > -Font Style: Plain /Font Size: 80 /Time consumed (us): 362.372 > -Font Style: Bold /Font Size: 20 /Time consumed (us): 145.096 > -Font Style: Bold /Font Size: 40 /Time consumed (us): 151.589 > -Font Style: Bold /Font Size: 60 /Time consumed (us): 240.972 > -Font Style: Bold /Font Size: 80 /Time consumed (us): 331.894 > -Font Style: Italic /Font Size: 20 /Time consumed (us): 95.028 > -Font Style: Italic /Font Size: 40 /Time consumed (us): 245.300 > -Font Style: Italic /Font Size: 60 /Time consumed (us): 270.379 > -Font Style: Italic /Font Size: 80 /Time consumed (us): 398.139 > -Font Style: Bold-Italic /Font Size: 20 /Time consumed (us): 93.243 > -Font Style: Bold-Italic /Font Size: 40 /Time consumed (us): 475.406 > -Font Style: Bold-Italic /Font Size: 60 /Time consumed (us): 280.085 > -Font Style: Bold-Italic /Font Size: 80 /Time consumed (us): 357.486 > > Platform : Windows x86_64 Release Build > Algorithm : Optimized. webrev.03 > `````````````````````````````````````````````````````````````````````````` > Executing Bench For Image Type: IntArgb > -Font Style: Plain /Font Size: 20 /Time consumed (us): 120.954 > -Font Style: Plain /Font Size: 40 /Time consumed (us): 364.871 > -Font Style: Plain /Font Size: 60 /Time consumed (us): 561.799 > -Font Style: Plain /Font Size: 80 /Time consumed (us): 653.390 > -Font Style: Bold /Font Size: 20 /Time consumed (us): 261.566 > -Font Style: Bold /Font Size: 40 /Time consumed (us): 311.054 > -Font Style: Bold /Font Size: 60 /Time consumed (us): 490.735 > -Font Style: Bold /Font Size: 80 /Time consumed (us): 656.559 > -Font Style: Italic /Font Size: 20 /Time consumed (us): 314.289 > -Font Style: Italic /Font Size: 40 /Time consumed (us): 378.750 > -Font Style: Italic /Font Size: 60 /Time consumed (us): 491.181 > -Font Style: Italic /Font Size: 80 /Time consumed (us): 770.172 > -Font Style: Bold-Italic /Font Size: 20 /Time consumed (us): 375.336 > -Font Style: Bold-Italic /Font Size: 40 /Time consumed (us): 571.371 > -Font Style: Bold-Italic /Font Size: 60 /Time consumed (us): 548.300 > -Font Style: Bold-Italic /Font Size: 80 /Time consumed (us): 714.526 > > Executing Bench For Image Type: IntArgb_Pre > -Font Style: Plain /Font Size: 20 /Time consumed (us): 45.026 > -Font Style: Plain /Font Size: 40 /Time consumed (us): 219.016 > -Font Style: Plain /Font Size: 60 /Time consumed (us): 279.617 > -Font Style: Plain /Font Size: 80 /Time consumed (us): 282.829 > -Font Style: Bold /Font Size: 20 /Time consumed (us): 51.809 > -Font Style: Bold /Font Size: 40 /Time consumed (us): 117.563 > -Font Style: Bold /Font Size: 60 /Time consumed (us): 508.049 > -Font Style: Bold /Font Size: 80 /Time consumed (us): 402.802 > -Font Style: Italic /Font Size: 20 /Time consumed (us): 79.320 > -Font Style: Italic /Font Size: 40 /Time consumed (us): 227.473 > -Font Style: Italic /Font Size: 60 /Time consumed (us): 330.488 > -Font Style: Italic /Font Size: 80 /Time consumed (us): 353.782 > -Font Style: Bold-Italic /Font Size: 20 /Time consumed (us): 54.687 > -Font Style: Bold-Italic /Font Size: 40 /Time consumed (us): 235.505 > -Font Style: Bold-Italic /Font Size: 60 /Time consumed (us): 227.205 > -Font Style: Bold-Italic /Font Size: 80 /Time consumed (us): 324.308 > > Updated webrev with changes for the fast-path : http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.03/ > Kindly review and provide your suggestions. > > Thank you once again for detailed review and feedback > Have a good day > > Prahalad N. > > > > -----Original Message----- > From: Jim Graham > Sent: Wednesday, March 30, 2016 2:46 AM > To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net; Sergey Bylokhov > Subject: Re: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: Antialiased text on translucent backgrounds gets bright artifacts > > Hi Prahalad, > > This latest version looks like it should produce correct answers. > > I'd like to see benchmark results on more platforms, particularly Windows since the different compilers may optimize these things differently. > > Also, you didn't mention what data set you used for benchmarking. I'd like to see benchmark results for small, medium and large font sizes, and possibly bold and italic fonts as well. The reason is that the relative ratios of "empty glyph pixels" to "partial glyph pixels" to "fully covered glyph pixels" changes depending on the font type and size so if you made one of those faster and another slower then the results may be seen as a gain in one type of test if you only test one font type and size and it happens to match the part of the code that is more streamlined. Also, for small font sizes the per-glyph overhead might hide per-pixel issues. Please share which fonts and sizes you used for testing and consider using some different sizes, including something very large like 36 or 48 points (something with large areas of opaque > pixels) as well as more normal sizes that appear in GUIs. Also, bold fonts can have a higher percentage of opaque pixels. > > In particular... > > This latest version is missing the "fast path" from the existing code for the case of srcA == 255 and glyphA == 255 where it just stores the FG_PIXEL values directly. For large fonts/glyphs that case may be as important as detecting empty glyph pixels. > > On the other hand, an additional "if" may cause the compiler to generate less efficient code as per Sergey's concern. Since this "if" eliminates some multiplies and possibly some divides, I'd hope it would be a win-win. > > You could add the fast path back inside the case where mixValSrc is 255 and just test srcA for 255 and do the Store ## DST ## PixelData() macro that used to be at the end of the block in the existing code, and then use "break;" to escape out of the do/while surrounding the whole macro so it moves on to the next pixel. > > (Arguably, we might want to consider teaching our SRCOVER_MASKFILL to do the same thing. I think that was one of the added values of having a separate GLYPH loop, but really both should be optimizing that case...) > > I can see now that the macro switch to use the same macro set as SRCOVER_MASKFILL required you to compute the pixel address, as you noted in your summary. It makes the new macro more cumbersome and makes it look like it's doing a bit more work per-pixel, but in reality I think the overall operations end up being the same as long as the compiler optimizes the deliberate multiplications the same way it did for implicit multiplications in the "pRas[foo]" and "pRas[foo*4]" code that was being generated previously. Benchmarks will tell us if we're good there... > > ...jim > > > On 3/28/16 5:33 AM, Prahalad Kumar Narayanan wrote: >> Hello Everyone on Java2D Group >> >> Good day to you. >> >> This is a follow-up to Review Request on bug: >> Bug : JDK-8015070 >> Bug Link : https://bugs.openjdk.java.net/browse/JDK-8015070 >> >> First, Thanks to Jim and Sergey for their feedback on the changes so far. >> >> Inferences from Jim 's Feedback on Loading destination colors: >> 1. The API or Macro that I had earlier used to Load DST colors, indeed, adjusted destination color components with divide-by-alpha if destination was already pre-multiplied. >> My apologies.. I should have spotted this error at the first iteration itself. >> 2. Due to the divide-by-alpha adjustment, the remaining logic would become incorrect. ( Especially, the multiplication with dstF based on pre-mulitplication status ) >> 3. Correct API is being used now, and the dstColor components are loaded directly without any divide-by-alpha adjustment. >> >> Inferences from Sergey's Feedback on Performance. >> 1. To set the context for everyone, the logic present in the current webrev.02 is modelled as per SRCOVER_MASKFILL. >> There are multiple if (...) conditions that remove un-necessary blending calculations. Ideally this should improve performance. >> However, since some data are not readily available (as present in SRCOVER_MASKFILL), few additional calculations have been added. >> They are: pre-multiplying srcColor with alpha and assigning to res. >> Finding the correct address of Pixel using DST_PTR and PixelStride. >> Henceforth, as Sergey suggests, Observation on performance will be beneficial. >> 2. The performance of the new logic was measured with linux-x86_64-normal-server-release config and compared with the logic used in un-optimized code in webrev.00 >> 3. Result: The newer logic provides a fractional gain (about 15 - 20 ms) over the older logic. >> >> Other Subtle Changes: >> 1. The test file has been renamed from AADrawStringArtifact.java to more meaningful - AntialiasedTextArtifact.java >> 2. The test file tests for both TYPE_INT_ARGB and TYPE_INT_ARGB_PRE BufferedImage formats. >> The code has been well commented to explain the logic used in every function. >> >> Kindly take your time to review the changes in the webrev link mentioned below and provide your suggestions. >> Webrev Link: >> http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.02/ >> >> >> Thank you for your time in review >> Have a good day >> >> Prahalad N. >> >> >> -----Original Message----- >> From: Jim Graham >> Sent: Thursday, March 24, 2016 7:57 AM >> To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: >> Antialiased text on translucent backgrounds gets bright artifacts >> >> Hi Prahalad, >> >> (On a side note - ouch! I came up with these macros in the first >> place, but 20 years later I'm now realizing just how hard they are to >> navigate and review. My apologies...) >> >> The macro you are still using to load the destination data is one that loads it to non-premultiplied components, which means it will divide out the alpha if the destination is PRE. The rest of the logic assumes that the components were loaded without any adjustment of their premultiplication so not only is that division an unnecessary operation, it makes the following math wrong. >> >> The SRCOVER_MASKFILL macro seems to use "Postload ## STRATEGY ## From ## TYPE" which seems to load them into separate components without any adjustment of their pre-multiplication status. This is paired with "LoadAlphaFrom ## TYPE ## For ## STRATEGY" to load just the destination alpha for computing dstF... >> >> ...jim >> >> On 3/22/16 4:35 AM, Prahalad Kumar Narayanan wrote: >>> Hello Everyone on Java2D Group >>> >>> Good day to you. >>> >>> This is a Follow-up to Review Request on the bug: >>> Bug : JDK-8015070 Anti-aliased Text on Translucent background gets bright artifacts >>> Bug Link : https://bugs.openjdk.java.net/browse/JDK-8015070 >>> >>> First, Sincere thanks to Jim for his valuable feedback. >>> 1. As Jim correctly mentioned, SRCOVER_MASKFILL has a similar logic to blend two Translucent colors based on an Alpha mask. >>> 2. The calculations are exactly the same as the changes in previous webrev. >>> However the logic of SRCOVER_MASKFILL is 'Optimized' to reduce the number of computations. >>> 3. This optimization is definitely required because, the logic is executed for every single pixel in a glyph. >>> Example: If a string is made up of 5 English characters with each character having 32 x 32 pixels, >>> The anti-aliasing logic will be executed for 5 x 32 x 32 iterations. >>> Reducing computation per pixel will imply a huge benefit for complete drawString operation. >>> >>> Observation from SRCOVER_MASKFILL >>> 1. The mask fill reduces computations by through multiple if(...) conditions. >>> Each if condition affirms whether the next set of computations are required. >>> 2. Optimization 1: If mask value is 0- skip entire logic. >>> 3. Optimization 2: If mask value is maximum, say 255, take srcA directly without multiplying with maskAlpha ( Reason: 1 * srcAlpha = srcAlpha ) >>> 4. Optimization 3: Compute pre-multiplied resColor in two steps. First with srcColor and then with dstColor. >>> If the resAlpha from 1st step (i.e., srcColor) is fully opaque, avoid blending dstColor altogether. >>> >>> Changes in Current Webrev.01 >>> 1. The fix for the current bug is modelled based on SRCOVER_MASKFILL. >>> 2. The changes have been verified to work on windows, linux and mac operating systems. >>> 3. The automated Test file- AADrawStringArtifact.java runs as expected >>> Identifies artifact & throws exception when run on JDK 7 and 8. >>> With JDK9, the test file returns without error. >>> 3. JPRT build has been run to ensure, changes build on all supported platforms. >>> JPRT job link : >>> http://scaaa637.us.oracle.com//archive/2016/03/2016-03-22-070604.prah >>> n >>> ara-linux.client >>> >>> Kindly review the changes in the below mentioned link and provide your views >>> Webrev Link : >>> http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.01/ >>> >>> >>> Thank you for your time in review >>> Have a good day >>> >>> Prahalad N. >>> >>> >>> -----Original Message----- >>> From: Jim Graham >>> Sent: Friday, March 18, 2016 6:07 AM >>> To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net >>> Subject: Re: [OpenJDK 2D-Dev] [2D-Dev] Review Request: JDK-8015070: >>> Antialiased text on translucent backgrounds gets bright artifacts >>> >>> Hi Prahalad, >>> >>> This basically boils down to "alpha blending math needs to be performed in premultiplied form" and the existing code was not doing that. >>> >>> Your changes do add a pre-multiplication step to the math in two >>> places >>> - when you mix the src alpha and the glyph alpha at the top of the macro, and again when you do the Multiply(dst, dstA, dst) step in the middle. In that sense, the new math is correct. >>> >>> However, it is not the optimal way to implement this. In particular, >>> the macro used here to load the data from the destination is the one >>> that loads it into 4 ARGB non-premultiplied values. If the >>> destination is non-PRE, then your added multiply step is exactly what >>> is needed, but it could be combined with the multiply that will >>> happen later in the blending equation, so it is an added step rather >>> than a fixed fraction in the existing MultMultAdd parameters. >>> Additionally, if the destination is already PRE, then the macro being >>> used to load the dst pixel data there will have done a divide step to >>> divide out the alpha from the destination, only to have you reverse >>> that math with your new >>> Multiply() step. That's a lot of math to end up with a NOP. >>> >>> The MUL8 you added for the srcA and glyph value is needed, that change is good. Since it is common for glyph pixels to have zero alpha, you might want to test the glyph alpha for 0 and skip the pixel before you do the multiply, though. This would add one more if, but it would be a common case. >>> >>> The trickier part is to load the destination components without un-premultiplying them. Unfortunately there is no "Load...ToArgbPre" >>> macro to parallel the Load macro used in the function. Perhaps there should be, but you'd still end up with an extra multiply step as I mentioned above because you can fold the premultiplication of the dst data into the MultMultAdd by carefully choosing the parameters you use in the math there. >>> >>> The good news is that the way that the SRCOVER_MASKFILL uses the various type-specific macros works around this a bit and minimizes the number of multiplies that happen. You could check out DEFINE_SRCOVER_MASKFILL and see how it works in the case where pMask is not null (pMask is an alpha mask with values very similar to the glyphAA data). Modeling this code on that code would correct the math and minimize it as well... >>> >>> ...jim >>> >>> On 3/17/16 3:00 AM, Prahalad Kumar Narayanan wrote: >>>> Hello Everyone on Java2D Group >>>> >>>> Good day to you. >>>> >>>> Herewith, I 'm sharing the webrev for two identical Java2D Bugs. >>>> >>>> Bug ID : JDK-8015070 >>>> >>>> Title : Antialiased text on translucent backgrounds gets >>>> bright artifacts >>>> >>>> Link : https://bugs.openjdk.java.net/browse/JDK-8015070 >>>> >>>> Bug ID : JDK-8013564 ( currently closed as duplicate ) >>>> >>>> Title : Font rendering anti-aliasing in translucent >>>> BufferedImages broken >>>> >>>> Link : https://bugs.openjdk.java.net/browse/JDK-8013564 >>>> >>>> Webrev Link : >>>> http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.00/ >>>> >>>> Quick Summary on Bugs : >>>> >>>> ```````````````````````````````````````````````` >>>> >>>> 1. Artifacts appear on Edges of text characters when anti-aliased >>>> text is drawn on Translucent background >>>> >>>> 2. The issue is reproducible on all platforms - windows, linux and mac os. >>>> >>>> 3. Besides, the issue is reproduced with the commonly used pixel >>>> format- 4ByteArgb. >>>> >>>> Root Cause & Solution : >>>> >>>> ```````````````````````````````````````````````` >>>> >>>> 1. The Macro: GlyphListAABlend4ByteArgb in File: LoopMacros.h uses >>>> the standard blending algorithm >>>> >>>> dstColor = [ srcColor * glyphAlpha + dstColor * (1 - >>>> glyphAlpha) ] / dstAlpha >>>> >>>> 2. The above equation works only when the srcColor and dstColor are Opaque. >>>> >>>> 3. When srcColor and dstColor are Translucent, their alphaComponent >>>> will influence the visibility of the color, and visibility of the >>>> color below. >>>> >>>> 4. The new set of calculations for blending Translucent source and >>>> destination colors is given as >>>> >>>> resAlpha = 1 - ((1 - srcAlpha) * (1 - dstAlpha)) >>>> >>>> resColor = [ srcColor * srcAlpha + dstColor * dstAlpha * >>>> (1 >>>> - >>>> srcAlpha) ] / resAlpha >>>> >>>> 5. Reference text for the equation: >>>> https://en.wikipedia.org/wiki/Alpha_compositing >>>> >>>> 6. With the above modification to the blending logic, the artifacts >>>> do not appear and issues are fixed. >>>> >>>> Jtreg & Jprt Results : >>>> >>>> ```````````````````````````````````````````````` >>>> >>>> 1. A simple test-file: AADrawStringArtifact.java has been created >>>> to be a part of jtreg test cases. >>>> >>>> The test file is well commented to explain - nature of >>>> artifact and how the test tries to identify them. >>>> >>>> As required, the test case fails with Jdk 7, Jdk 8 and >>>> succeeds with Jdk 9-internal (built with changes for the bug fix) >>>> >>>> 2. The changes to blending logic lies within >>>> java.desktop/src/share/native/... >>>> >>>> Henceforth, JPRT was used to ensure successful build >>>> across all supported platforms >>>> >>>> Jprt Job Link : >>>> http://scaaa637.us.oracle.com//archive/2016/03/2016-03-17-072001.pra >>>> h >>>> n >>>> ara-linux.client >>>> >>>> The build succeeds on all platforms. >>>> >>>> Kindly review the webrev link and provide your views and suggestions. >>>> >>>> Webrev Link : >>>> http://cr.openjdk.java.net/~psadhukhan/prahlad/8015070/webrev.00/ >>>> >>>> If the changes look good, we could take up the changes for source checkin. >>>> >>>> Thank you for your time in review >>>> >>>> Have a good day >>>> >>>> Prahalad N. >>>> From james.graham at oracle.com Wed Mar 30 20:29:35 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 30 Mar 2016 13:29:35 -0700 Subject: [OpenJDK 2D-Dev] [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception In-Reply-To: <56FB4F17.90109@oracle.com> References: <3969befd-57cd-48ee-bed5-173a28e7bd08@default> <56DFFC9F.4020403@oracle.com> <70f247c0-6f3e-472a-b7b0-b02814010e30@default> <56E16D0A.3060807@oracle.com> <56E1E2A5.1020008@oracle.com> <56F1C6F2.6000305@oracle.com> <56F1D0DB.9000508@oracle.com> <56F33180.8060408@oracle.com> <56F334D3.5060106@oracle.com> <56FAF58E.5060208@oracle.com> <56FB022B.7050609@oracle.com> <56FB3732.8090306@oracle.com> <56FB4F17.90109@oracle.com> Message-ID: <56FC372F.3000208@oracle.com> Actually, it was sufficient to make that apparent, but I again fell under the spell of "all these methods are the same, so the same logic should apply in each of them". Apologies again for the non-sequitur. If it's a DBB, then the type must be TYPE_BYTE... ...jim On 3/29/2016 8:59 PM, Philip Race wrote: > > One comes from the SampleModel, the other comes from the DataBuffer. > > In the other methods that is true but not in this one. > This method creates the SampleModel using the type of the DataBuffer. > The webrev diff is insufficient to make this apparent. > > -phil. > > On 3/29/16, 7:17 PM, Jim Graham wrote: >> One comes from the SampleModel, the other comes from the DataBuffer. >> The reason to check them both is to make sure they agree. There is no >> "it must be DataBuffer.TYPE_BYTE" here, there is only "it *should* be >> DataBuffer.TYPE_BYTE" and that warrants a test and a fallback to the >> generic SunWritableRaster if they ever send in the wrong type. >> >> Otherwise why do we bother to switch on the dataType in the other >> sections of the code before we check instanceof? For the same reason >> as we need both checks here. If we expanded out this final else >> clause in parallel to match the way that the other blocks are written, >> then we would have: >> >> } else if (sm instanceof MPPSM) { >> switch (dataType) { >> case DataBuffer.TYPE_BYTE: >> if (dataBuffer instanceof DataBufferByte) { >> if (sm.getSampleSize(0) < 8) { >> return new BPP(...); >> } >> } >> break; >> } >> } >> >> The tests in the prior version were a perfect compaction of all of the >> above constructs into a single if statement. The new one omits the >> switch test that all of the other blocks have... >> >> ...jim >> >> On 3/29/16 3:31 PM, Phil Race wrote: >>> On 03/29/2016 02:37 PM, Jim Graham wrote: >>>> Raster.java, line 894: Why was the test for dataType removed from this >>>> if statement? >>> >>> In a previous version .. >>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.02/src/java.desktop/share/classes/java/awt/image/Raster.java.sdiff.html >>> >>> >>> >>> Ajit had added a condition : >>> >>> 890 if (dataType == DataBuffer.TYPE_BYTE && >>> 891 dataBuffer instanceof DataBufferByte && >>> >>> >>> But we don't need both of these. >>> DataBufferByte should always be DataBuffer.TYPE_BYTE and we do the cast >>> so it had better be DataBufferByte. >>> >>> -phil. >>> From james.graham at oracle.com Wed Mar 30 20:59:38 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 30 Mar 2016 13:59:38 -0700 Subject: [OpenJDK 2D-Dev] [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception In-Reply-To: <56FB4F17.90109@oracle.com> References: <3969befd-57cd-48ee-bed5-173a28e7bd08@default> <56DFFC9F.4020403@oracle.com> <70f247c0-6f3e-472a-b7b0-b02814010e30@default> <56E16D0A.3060807@oracle.com> <56E1E2A5.1020008@oracle.com> <56F1C6F2.6000305@oracle.com> <56F1D0DB.9000508@oracle.com> <56F33180.8060408@oracle.com> <56F334D3.5060106@oracle.com> <56FAF58E.5060208@oracle.com> <56FB022B.7050609@oracle.com> <56FB3732.8090306@oracle.com> <56FB4F17.90109@oracle.com> Message-ID: <56FC3E3A.5080406@oracle.com> Actually, there are other methods (well at least one that I spotted - createPackedRaster) that get the data type from the DB itself, but also switch on it. I suppose in that case the switch means we only have to do a single instanceof check instead of 3 nested instanceof checks so it is a performance mechanism in those cases... ...jim On 3/29/2016 8:59 PM, Philip Race wrote: > > One comes from the SampleModel, the other comes from the DataBuffer. > > In the other methods that is true but not in this one. > This method creates the SampleModel using the type of the DataBuffer. > The webrev diff is insufficient to make this apparent. > > -phil. > > On 3/29/16, 7:17 PM, Jim Graham wrote: >> One comes from the SampleModel, the other comes from the DataBuffer. >> The reason to check them both is to make sure they agree. There is no >> "it must be DataBuffer.TYPE_BYTE" here, there is only "it *should* be >> DataBuffer.TYPE_BYTE" and that warrants a test and a fallback to the >> generic SunWritableRaster if they ever send in the wrong type. >> >> Otherwise why do we bother to switch on the dataType in the other >> sections of the code before we check instanceof? For the same reason >> as we need both checks here. If we expanded out this final else >> clause in parallel to match the way that the other blocks are written, >> then we would have: >> >> } else if (sm instanceof MPPSM) { >> switch (dataType) { >> case DataBuffer.TYPE_BYTE: >> if (dataBuffer instanceof DataBufferByte) { >> if (sm.getSampleSize(0) < 8) { >> return new BPP(...); >> } >> } >> break; >> } >> } >> >> The tests in the prior version were a perfect compaction of all of the >> above constructs into a single if statement. The new one omits the >> switch test that all of the other blocks have... >> >> ...jim >> >> On 3/29/16 3:31 PM, Phil Race wrote: >>> On 03/29/2016 02:37 PM, Jim Graham wrote: >>>> Raster.java, line 894: Why was the test for dataType removed from this >>>> if statement? >>> >>> In a previous version .. >>> http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.02/src/java.desktop/share/classes/java/awt/image/Raster.java.sdiff.html >>> >>> >>> >>> Ajit had added a condition : >>> >>> 890 if (dataType == DataBuffer.TYPE_BYTE && >>> 891 dataBuffer instanceof DataBufferByte && >>> >>> >>> But we don't need both of these. >>> DataBufferByte should always be DataBuffer.TYPE_BYTE and we do the cast >>> so it had better be DataBufferByte. >>> >>> -phil. >>> From james.graham at oracle.com Wed Mar 30 21:07:20 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 30 Mar 2016 14:07:20 -0700 Subject: [OpenJDK 2D-Dev] [9] Review-request for 6353518: Creation of a WritableRaster with a custom DataBuffer causes erroneous Exception In-Reply-To: <737019e7-94af-43d8-830b-fd676f6a98e1@default> References: <3969befd-57cd-48ee-bed5-173a28e7bd08@default> <56DFFC9F.4020403@oracle.com> <70f247c0-6f3e-472a-b7b0-b02814010e30@default> <56E16D0A.3060807@oracle.com> <56E1E2A5.1020008@oracle.com> <56F1C6F2.6000305@oracle.com> <56F1D0DB.9000508@oracle.com> <56F33180.8060408@oracle.com> <56F334D3.5060106@oracle.com> <56FAF58E.5060208@oracle.com> <737019e7-94af-43d8-830b-fd676f6a98e1@default> Message-ID: <56FC4008.2090406@oracle.com> Hi Ajit, On 3/30/2016 5:12 AM, Ajit Ghaisas wrote: > Raster.java, line 986: Something to file as a potential bug for future work since the fix would have to be verified that it doesn't disrupt the other parts of this method, but... The set of if statements in this method never checked for a BandedSampleModel to try to create a BandedRaster as in createBandedRaster. On the other hand, no developer has complained so far (that I know of, but maybe we have an old bug filed on it that I'm not aware of). > >>>> [Ajit] : Without my fix, it was easier to get RasterFormatException as explained in Bug Description. This fix enhances the code by making type specific Raster class constructors type-safe. > Now, the bigger question is: Whether methods in Raster.java support all possible combinations of Raster creations? > What I can say is - this fix does not break anything than what is already present in Raster.java. > If there is specific user complaint or any existing bug - we can look into it separately. I agree that this creates no new failure modes, which is why I suggested it as something to file for future work. (an enhancement) > The following 2 comments are identical for all of the raster types { > ByteBandedRaster.java, line 76: This code will throw a ClassCastException > now instead of the RasterFormatException that used to be thrown. > Do we care? It would be easy enough to add a test to just this > method (and the similar versions in other files). >>>> [Ajit] : Since we have decided to make the type specific Raster class constructors type safe, yes, it is possible to get ClassCastException. But, as the usage of these classes is guarded now with "instanceof" checks, it would be rare. In other cases, where the caller supplies the data buffer, we have protected them all with instance checks, but in this case the method is relying on the sample model to create the correct type of data buffer. If this method were called from a random place then we'd have no guarantees, but as far as I can see, it is only called from within ByteBandedRaster itself and it is called on the same sample model that it was originally created with. The typical case will probably not be an issue, but it's not immediately clear if there is any way that someone can end up with a custom sample model in a ByteBandedRaster that produces some other kind of data buffer? Possibly this would be more likely if there were any other callers to that method, but a search of java.desktop didn't turn up any. It would be difficult at best to engineer a test case that would discover the difference here and that test case would have previously thrown an exception anyway so I suppose I'm not going to be concerned if the type of the exception has changed here... > ByteBandedRaster.java, line 668: Extra credit: This cast could be avoided > if we make SunWritableRaster employ generics for a strongly typed DataBuffer. > >>>> [Ajit] : the casted member ' dataBuffer' on this line is a member of Raster class. > The class hierarchy of ByteBandedRaster is ( added on single line for convenience) > -------- ByteBandedRaster extends SunWritableRaster extends WritableRaster extends Raster. > > I am not quite clear on how we can avoid cast on this line. Can you please elaborate? > > } The object being cast here is the contents of the dataBuffer field of the raster, which is known to be a DataBufferByte for the case of ByteBandedRaster because all of its constructors enforce that type, especially so now that the constructors are all type-specific. If all of the super-classes were generified for the kind of DataBuffer that they held then we wouldn't need a cast here. But, that would be a public API change since the field is stored in the public java.awt.image.Raster class, so the generification would have to extend all the way up to that class. Something to consider for the future, but definitely outside the scope of this fix. And if we do that, then we should also consider other use of generics within all of the java.awt.image classes and that would be a much larger effort. > Here is the updated webrev: > http://cr.openjdk.java.net/~arapte/ajit/6353518/webrev.05/ If you only changed those things you mentioned above then it looks good to go. If there is something else that was changed, let me know and I'll do a more thorough review... ...jim From prasanta.sadhukhan at oracle.com Thu Mar 31 05:22:38 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Thu, 31 Mar 2016 10:52:38 +0530 Subject: [OpenJDK 2D-Dev] [9]: RFR JDK-6357905, , java.awt.JobAttributes.getFromPage() and getToPage() always returns "1". In-Reply-To: <56F9D724.3060104@oracle.com> References: <56F8ED8F.6030007@oracle.com> <56F9D724.3060104@oracle.com> Message-ID: <56FCB41E.4000505@oracle.com> Hi Phil, I found out we do not need to change minPage. Changing toPage before frompage should be enough. Please find the modified webrev: http://cr.openjdk.java.net/~psadhukhan/6357905/webrev.01/ Regards Prasanta On 3/29/2016 6:45 AM, Philip Race wrote: > Please add an evaluation to the bug report. > > As to the fix I am under the impression that min&max page are > meant to constrain what the user can enter in the dialog so > if min page & max page are set to "1" then the problem > may be with those settings ? > > i.e the application can set those values and expect the user > can't change them so updating our code to circumvent that > seems wrong. > > -phil. > > On 3/28/16, 1:38 AM, prasanta sadhukhan wrote: >> Hi All, >> >> Please review a print job attribute fix for jdk9. >> Bug: https://bugs.openjdk.java.net/browse/JDK-6357905 >> webrev: http://cr.openjdk.java.net/~psadhukhan/6357905/webrev.00/ >> >> The issue was in the Print-dialog, when some pages are specified >> using "Pages" within "Page range", >> java.awt.JobAttributes.getFromPage() and getToPage() always returns "1" >> and not the values as updated by the user. >> The fix was to get the pageranges attribute as set by the user and >> obtain the from and to Page range and update the JobAttribute's from >> and to Page. >> >> Regards >> Prasanta From philip.race at oracle.com Thu Mar 31 15:44:37 2016 From: philip.race at oracle.com (Philip Race) Date: Thu, 31 Mar 2016 08:44:37 -0700 Subject: [OpenJDK 2D-Dev] [9]: RFR JDK-6357905, , java.awt.JobAttributes.getFromPage() and getToPage() always returns "1". In-Reply-To: <56FCB41E.4000505@oracle.com> References: <56F8ED8F.6030007@oracle.com> <56F9D724.3060104@oracle.com> <56FCB41E.4000505@oracle.com> Message-ID: <56FD45E5.4020208@oracle.com> On 3/30/16, 10:22 PM, prasanta sadhukhan wrote: > Hi Phil, > > I found out we do not need to change minPage. That makes more sense now. > Changing toPage before frompage should be enough. > Please find the modified webrev: > http://cr.openjdk.java.net/~psadhukhan/6357905/webrev.01/ Don't you need to check ? setToPage also checks that to > from Supposing we start with from=3,to=4 and you want to change it so that from=1,to=2 when you try to change the to page (in the first step) to 3,2 you will also get an IAE. So you need to examine the existing values to decide which order to do the update. A bad API design IMO, it should have been setPageRange(int from, int to) but it is too late for that. BTW I notice it really is a requirement that from < to and to > from eg : I see (toPage != 0 && fromPage > toPage) || I would have expected >= .. .. in fact the docs for setFromPage say : * @param fromPage an integer greater than zero and less than or equal to * toPage So the implementation looks wrong to me for that and setToPage. -phil. > > Regards > Prasanta > On 3/29/2016 6:45 AM, Philip Race wrote: >> Please add an evaluation to the bug report. >> >> As to the fix I am under the impression that min&max page are >> meant to constrain what the user can enter in the dialog so >> if min page & max page are set to "1" then the problem >> may be with those settings ? >> >> i.e the application can set those values and expect the user >> can't change them so updating our code to circumvent that >> seems wrong. >> >> -phil. >> >> On 3/28/16, 1:38 AM, prasanta sadhukhan wrote: >>> Hi All, >>> >>> Please review a print job attribute fix for jdk9. >>> Bug: https://bugs.openjdk.java.net/browse/JDK-6357905 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/6357905/webrev.00/ >>> >>> The issue was in the Print-dialog, when some pages are specified >>> using "Pages" within "Page range", >>> java.awt.JobAttributes.getFromPage() and getToPage() always returns "1" >>> and not the values as updated by the user. >>> The fix was to get the pageranges attribute as set by the user and >>> obtain the from and to Page range and update the JobAttribute's from >>> and to Page. >>> >>> Regards >>> Prasanta > From philip.race at oracle.com Thu Mar 31 15:49:08 2016 From: philip.race at oracle.com (Philip Race) Date: Thu, 31 Mar 2016 08:49:08 -0700 Subject: [OpenJDK 2D-Dev] [9]: RFR JDK-6357905, , java.awt.JobAttributes.getFromPage() and getToPage() always returns "1". In-Reply-To: <56FD45E5.4020208@oracle.com> References: <56F8ED8F.6030007@oracle.com> <56F9D724.3060104@oracle.com> <56FCB41E.4000505@oracle.com> <56FD45E5.4020208@oracle.com> Message-ID: <56FD46F4.8040704@oracle.com> Actually never mind about the > or >= difference that code is fine since it is the condition under which the exception is thrown not the condition that the setting is accepted ! But you do still need to check the existing values to see which order to do the update. -phil On 3/31/16, 8:44 AM, Philip Race wrote: > > > On 3/30/16, 10:22 PM, prasanta sadhukhan wrote: >> Hi Phil, >> >> I found out we do not need to change minPage. > That makes more sense now. > >> Changing toPage before frompage should be enough. >> Please find the modified webrev: >> http://cr.openjdk.java.net/~psadhukhan/6357905/webrev.01/ > > Don't you need to check ? setToPage also checks that to > from > > Supposing we start with from=3,to=4 > and you want to change it so that from=1,to=2 > when you try to change the to page (in the first step) to 3,2 > you will also get an IAE. > > So you need to examine the existing values to decide which order to do > the update. > > A bad API design IMO, it should have been setPageRange(int from, int to) > but it is too late for that. > > BTW I notice it really is a requirement that from < to and to > from > > eg : I see > (toPage != 0 && fromPage > toPage) || > > I would have expected >= .. > > .. in fact the docs for setFromPage say : > * @param fromPage an integer greater than zero and less than or > equal to > * toPage > > So the implementation looks wrong to me for that and setToPage. > > -phil. >> >> Regards >> Prasanta >> On 3/29/2016 6:45 AM, Philip Race wrote: >>> Please add an evaluation to the bug report. >>> >>> As to the fix I am under the impression that min&max page are >>> meant to constrain what the user can enter in the dialog so >>> if min page & max page are set to "1" then the problem >>> may be with those settings ? >>> >>> i.e the application can set those values and expect the user >>> can't change them so updating our code to circumvent that >>> seems wrong. >>> >>> -phil. >>> >>> On 3/28/16, 1:38 AM, prasanta sadhukhan wrote: >>>> Hi All, >>>> >>>> Please review a print job attribute fix for jdk9. >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6357905 >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6357905/webrev.00/ >>>> >>>> The issue was in the Print-dialog, when some pages are specified >>>> using "Pages" within "Page range", >>>> java.awt.JobAttributes.getFromPage() and getToPage() always returns >>>> "1" >>>> and not the values as updated by the user. >>>> The fix was to get the pageranges attribute as set by the user and >>>> obtain the from and to Page range and update the JobAttribute's >>>> from and to Page. >>>> >>>> Regards >>>> Prasanta >> From alexander.v.stepanov at oracle.com Thu Mar 31 15:52:25 2016 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Thu, 31 Mar 2016 18:52:25 +0300 Subject: [OpenJDK 2D-Dev] RFR 8149028: [TEST] add test for TIFFDirectory In-Reply-To: <56FAB9B3.6050209@oracle.com> References: <56F55D56.4090408@oracle.com> <56FAB9B3.6050209@oracle.com> Message-ID: <56FD47B9.6010008@oracle.com> Please see http://cr.openjdk.java.net/~avstepan/8149028/webrev.02/ (one more test covering TIFFImageReadParam was added). Thanks, Alexander On 3/29/2016 8:21 PM, Alexander Stepanov wrote: > Please see the updated webrev: > http://cr.openjdk.java.net/~avstepan/8149028/webrev.01/ > (one more test was added). > > Thanks, > Alexander > > On 3/25/2016 6:46 PM, Alexander Stepanov wrote: >> Hello, >> >> Could you please review the following fix >> http://cr.openjdk.java.net/~avstepan/8149028/webrev.00/ >> for >> https://bugs.openjdk.java.net/browse/JDK-8149028 >> >> Just a single test added. >> >> Thanks, >> Alexander >> > From semyon.sadetsky at oracle.com Thu Mar 31 17:10:47 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 31 Mar 2016 20:10:47 +0300 Subject: [OpenJDK 2D-Dev] RFR 8149028: [TEST] add test for TIFFDirectory In-Reply-To: <56FD47B9.6010008@oracle.com> References: <56F55D56.4090408@oracle.com> <56FAB9B3.6050209@oracle.com> <56FD47B9.6010008@oracle.com> Message-ID: <56FD5A17.6010101@oracle.com> Looks good. --Semyon On 3/31/2016 6:52 PM, Alexander Stepanov wrote: > Please see > http://cr.openjdk.java.net/~avstepan/8149028/webrev.02/ > (one more test covering TIFFImageReadParam was added). > > Thanks, > Alexander > > On 3/29/2016 8:21 PM, Alexander Stepanov wrote: >> Please see the updated webrev: >> http://cr.openjdk.java.net/~avstepan/8149028/webrev.01/ >> (one more test was added). >> >> Thanks, >> Alexander >> >> On 3/25/2016 6:46 PM, Alexander Stepanov wrote: >>> Hello, >>> >>> Could you please review the following fix >>> http://cr.openjdk.java.net/~avstepan/8149028/webrev.00/ >>> for >>> https://bugs.openjdk.java.net/browse/JDK-8149028 >>> >>> Just a single test added. >>> >>> Thanks, >>> Alexander >>> >> >