From jayathirth.d.v at oracle.com Wed Jun 1 07:02:20 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 1 Jun 2016 00:02:20 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods In-Reply-To: <574E13BD.9060701@oracle.com> References: <6f83b633-3910-47fa-b872-e042fe4c24d3@default> <24ca2994-aa27-4a70-8cf9-0bda35664f3f@default> <574809B2.5040901@oracle.com> <9f641938-f979-4021-9e94-bde47e1d3c67@default> <57489033.7020901@oracle.com> <77d5b327-066b-4d86-a44d-8e681aeb71f8@default> <574DE3F9.40709@oracle.com> <574E0717.5060405@oracle.com> <574E0DF9.20508@oracle.com> <574E10B0.4070003@oracle.com> <574E13BD.9060701@oracle.com> Message-ID: <9a87056b-2646-4d5f-bfec-d50bea489381@default> Hi Phil & Jim, Collating all the changes needed: 1) I have removed both equals() & hashCode() in CCM but forgot to add the file while creating webrev. I will include changes in CCM in updated webrev. 2) Caching of hashCode value in IndexColorModel & PackedColorModel : We can cache hashCode value when constructor is called or when hashCode() is called for first time. What approach we have to follow? 3) Comment section of equals() method, I will update it to : 1449 * the target object must be the same class (and not a subclass) as this 4) I will use .equals() to compare colorSpace values in CM.equals() so it will be like we are not intending ColorSpace class to never override equals() method. Please let me know your inputs. Thanks, Jay -----Original Message----- From: Jim Graham Sent: Wednesday, June 01, 2016 4:14 AM To: Phil Race Cc: Jayathirth D V; 2d-dev at openjdk.java.net Subject: Re: Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods I think we should use .equals() here, otherwise it looks like a recommendation that the intent is for those classes to never implement it... ...jim On 05/31/2016 03:31 PM, Phil Race wrote: > I don't know of any design intent, so yes, I meant more as a practical > matter. > Unless they subclass then using equals() which I thought unlikely it > makes no difference here. > But it would be proof against that to use equals, unlikely to matter > as it might be .. > > -phil. > > On 05/31/2016 03:19 PM, Jim Graham wrote: >> >> >> On 05/31/2016 02:50 PM, Phil Race wrote: >>> On 05/31/2016 12:20 PM, Jim Graham wrote: >>>> Hi Jay, >>>> >>>> You were going to remove hashCode/equals from CCM, but instead you >>>> simply removed it from the patch. You still need to edit it to >>>> remove the existing methods. >>> >>> Oh yeah ! CCM is gone from the latest webrev. I expect that was not >>> intentional. >>> >>>> >>>> Also, I'm not sure == is a good way to compare ColorSpace instances >>>> - Phil? >>> >>> Neither ColorSpace nor ICC_ColorSpace over-ride equals or hashCode >>> and all the predefined ones are constructed as singletons so it >>> seems unlikely to cause problems >> >> Should it use .equals() on principle, though? Otherwise we are >> baking in the assumption that it doesn't implement equals() into our >> implementation of the CM.equals() method. Might it some day >> implement equals (perhaps it isn't a practical issue today, but it >> might be in the future when we forget that it was omitted in this >> usage we create today). >> >> I guess what I'm asking is if it is a design feature that different >> objects are considered non-equal (such as an object that, for >> instance, has only predetermined instances that are shared by >> reference and reused). I think color spaces are sort of in-between >> in that we define a few constants that simply get used by reference >> in 99% of cases, but that isn't a design feature, more like a >> practical issue... >> >> ...jim > From prasanta.sadhukhan at oracle.com Wed Jun 1 07:03:22 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Wed, 1 Jun 2016 12:33:22 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6842011: StackOverflowError printing landscape with scale and transform In-Reply-To: <574DCD00.9010005@oracle.com> References: <5739A1D8.90703@oracle.com> <4ac584a5-b1a6-a707-bd80-3d7717901c46@oracle.com> <0bfb90de-f26b-45f9-6e08-ae1d1818ffcb@oracle.com> <811d7b2a-4cf6-90d3-254e-f54e05a88837@oracle.com> <57438156.2000007@oracle.com> <994ea332-c40f-e97c-8780-4015193946c2@oracle.com> <57438AED.9070009@oracle.com> <5745D569.4090709@oracle.com> <66c5075a-d5f1-fd38-c230-1b61a9c26778@oracle.com> <574DCD00.9010005@oracle.com> Message-ID: <1cb02649-3738-73e8-9452-68fd9e427131@oracle.com> HI Phil, Jim, I have modified webrev to address Jim's doc change. Please review http://cr.openjdk.java.net/~psadhukhan/6842011/webrev.02/ I will send the ccc link separately to you for approval. On 5/31/2016 11:12 PM, Phil Race wrote: > On 05/26/2016 03:49 AM, prasanta sadhukhan wrote: >> >> Hi Phil, >> >> >> On 5/25/2016 10:10 PM, Philip Race wrote: >>> I am OK with committing the clarifying javadoc as part of this fix >>> and filing a new RFE for the new method - to be fixed at some later >>> date. >>> >>> However before this fix can be committed you need to make sure >>> we have consistent behaviour across platforms and we do not have >>> that yet >> In mac, unlike RasterPrinterJob which does the transform using the >> following code >> / pathGraphics.transform(scaleTransform);// >> // // user (0,0) should be origin of page, not >> imageable area// >> //pathGraphics.translate(-getPhysicalPrintableX(paper) / xScale,// >> //-getPhysicalPrintableY(paper) / yScale);// >> // pathGraphics.transform(new >> AffineTransform(page.getMatrix()));// >> /CPrinterJob does not do this transforms, it straightway goes to >> native printloop code >> so when scalex = g2d.getTransform().getScaleX(); is called the >> transform returned is identity transform (as was the case in linux >> too before the above transform code is executed) > > I am not sure I know what you mean by that part in parentheses. What I meant was SunGraphics2D.transform was an identity transform in linux and osx to begin with, but in linux RasterPrinterJob calls the above code snippet which modifies SunGraphics2D.transfrom from identity transform to [m00=0, m01=4.16, m02=0][m10=-4.16, m11=0, m12=3507.873] but it remains as identity transform in osx. > Our printing pipelines have always reflected the device transform. > > If in fact OS X printing does not do that, then this is a bigger > inconsistency .. > But not one we will try to address today, nor in JDK 9.. > Verify that is the case and then file a P4 bug on that too in order to > track it. > RasterPrinterJob#print() calls printPage() which does this device transformation but in osx CPrinterJob#print calls printloop() in osx native which does not do this. I have created JDK-8158339 to address this. Regards Prasanta > And this fix is then approved .. > > -phil. > > >> so getScaleX/Y returns 1 as m00,m11=1 . >> So, since the transform is not invalid unlike linux, mac prints ok. >> >> Regards >> Prasanta >>> >>> -phil. >>> >>> On 5/23/16, 3:57 PM, Phil Race wrote: >>>> On 05/23/2016 03:33 PM, Jim Graham wrote: >>>>> Though, they are likely to think this API is doing that. We have >>>>> a visibility problem here to make sure that any work going forward >>>>> is more likely to see the new method and ignore this one. I don't >>>>> think we'll win there on naming alone, but we can make the >>>>> javadocs look very intimidating so if they are using completion >>>>> they may get scared and hopefully see the other method before they >>>>> just accept the completion. Perhaps we can try to make the >>>>> alphabetic sorting have the new methods appear first in the list? >>>> >>>> getScaleFactorX() should sort ahead of getScaleX() >>>> >>>> -phil. >>>> >>>>> >>>>> In FX we were smart and went with very dry "getMxy()" style names >>>>> that won't attract attention... >>>>> >>>>> ...jim >>>>> >>>>> On 5/23/2016 3:16 PM, Phil Race wrote: >>>>>> What we have here might happen when developer A writes some UI code >>>>>> without any conception that a 90 degree rotation may be in effect >>>>>> and >>>>>> then developer B >>>>>> comes along and adds printing support .. and the implementation >>>>>> rotates it. >>>>>> So an out-of-the-box advertised API that does what dev A really >>>>>> meant >>>>>> would be helpful. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 05/23/2016 11:52 AM, Jim Graham wrote: >>>>>>> I think we need to go a bit further and change the way we describe >>>>>>> them. If we perhaps get very technical about how it is >>>>>>> returning one >>>>>>> element of the scaling equations/matrix then they will be >>>>>>> discouraged >>>>>>> from finding a simple use for it. I'll try to come up with some >>>>>>> wording today or tomorrow and it would be good to apply it to >>>>>>> all 6 of >>>>>>> the getters uniformly. Something like: >>>>>>> >>>>>>> Returns element M## of the transformation matrix which controls how >>>>>>> the output XY coordinates are affected by the input XY coordinates. >>>>>>> >>>>>>> Then on the getScaleXY methods add a "Note, this method will not >>>>>>> return the amount by which input XY coordinates will be >>>>>>> stretched or >>>>>>> contracted since a 90 degree rotation will cause all of its >>>>>>> contribution to be redirected into the other axis. Properly >>>>>>> determining the full scale of the matrix involves analyzing both >>>>>>> this >>>>>>> factor and the ...". >>>>>>> >>>>>>> There is where it would be good to have the new methods ready to >>>>>>> go so >>>>>>> we can then immediately say ", such as in the getScalingFactorXY() >>>>>>> method" or have an @see to send them where they need to go. That >>>>>>> doesn't mean we can't do this documentation refresh now, but we >>>>>>> might >>>>>>> want to make those new methods a high priority to get done >>>>>>> soon. (I'm >>>>>>> guessing/hoping we can add small "fixup" APIs like that after FC >>>>>>> since >>>>>>> it doesn't really represent a "feature"...?) >>>>>>> >>>>>>> ...jim >>>>>>> >>>>>>> On 5/22/16 11:53 PM, prasanta sadhukhan wrote: >>>>>>>> Hi Jim, >>>>>>>> >>>>>>>> >>>>>>>> On 5/21/2016 3:20 AM, Jim Graham wrote: >>>>>>>>> We should acknowledge that the test case is buggy anyway. It >>>>>>>>> is not >>>>>>>>> computing the scale of a transform correctly, >>>>>>>>> though that is likely due to the unfortunate naming we chose >>>>>>>>> for our >>>>>>>>> methods. >>>>>>>>> >>>>>>>>> If you are looking for "the amount by which an X coordinate is >>>>>>>>> stretched or contracted", you have to compute a >>>>>>>>> distance formula on all of the elements of the X transform >>>>>>>>> equation. We don't have a method to do that for the >>>>>>>>> caller. If we did, we might call it something very similar to >>>>>>>>> "getScaleX()". >>>>>>>>> >>>>>>>>> Unfortunately, we have a method named "getScaleX()" which one >>>>>>>>> might >>>>>>>>> think does that, but it doesn't. >>>>>>>>> >>>>>>>>> While I think we should prevent a stack overflow here, it's >>>>>>>>> really >>>>>>>>> more of "making sure a program bug is caught early >>>>>>>>> and with a more sane response", than "fixing a valid test case". >>>>>>>>> >>>>>>>>> Also, we should consider adding a method to do the right >>>>>>>>> calculation, and document the existing getScaleX() to point >>>>>>>>> out that it cannot be used to determine "the stretchiness of X >>>>>>>>> coordinates" or something more appropriately worded... >>>>>>>>> >>>>>>>> I have documented the anomalies in getScaleX()/getScaley(). >>>>>>>> http://cr.openjdk.java.net/~psadhukhan/6842011/webrev.01/ >>>>>>>> I will create a bug to address this scaling calculation of a >>>>>>>> transform in affinetransform (as it is in geom package and >>>>>>>> not a printing issue par se). Will that be ok? >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>>>> ...jim >>>>>>>>> >>>>>>>>> On 5/20/16 4:27 AM, prasanta sadhukhan wrote: >>>>>>>>>> Hi Phil, >>>>>>>>>> >>>>>>>>>> When we call print() it calls RasterPrinterJob#printPage() which >>>>>>>>>> sets peekGraphics.transform([4.16,0,0][0,4.16,0]) as >>>>>>>>>> obtained from xscale=4.16 [getXRes()=300 / 72.0] ,yscale=4.16 >>>>>>>>>> It calls SunGraphics2D.transform which was identity transform >>>>>>>>>> [1.0, >>>>>>>>>> 0.0, 0.0] [0.0, 1.0, 0.0] calls >>>>>>>>>> transform.concatenate(peekgraphicsTx) and stores as >>>>>>>>>> ([4.16,0,0][0,4.16,0]) >>>>>>>>>> >>>>>>>>>> Then RasterPrinterJob#printPage() again calls >>>>>>>>>> peekGraphics.transform(new AffineTransform(page.getMatrix())); >>>>>>>>>> where page.getMatrix() returns 0.0, -1.0, 1.0, 0.0, 0.0, >>>>>>>>>> 841.88 and >>>>>>>>>> peekGraphics transform now becomes [0.0, 1.0, 0.0] >>>>>>>>>> [-1.0, 0.0, 841.88] >>>>>>>>>> which calls SunGraphics2D#transform() where it again does >>>>>>>>>> transform.concatenate(peekgraphicsTx) >>>>>>>>>> >>>>>>>>>> so the transform becomes [m00=0, m01=4.16, m02=0][m10=-4.16, >>>>>>>>>> m11=0, >>>>>>>>>> m12=3507.873] >>>>>>>>>> Now scaleX obtains value from g2d.getTransform().getScaleX() >>>>>>>>>> which >>>>>>>>>> returns SunGraphics2D stored transform.m00 which is 0 >>>>>>>>>> and scaleY is m11=0 so scaleX,scaleY becomes 0. >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Prasanta >>>>>>>>>> On 5/19/2016 4:03 AM, Phil Race wrote: >>>>>>>>>>> It sounds like scalex & scaley are 0 and are then used in >>>>>>>>>>> calculations which >>>>>>>>>>> results in the NaN ? So why are they zero to begin with ? >>>>>>>>>>> >>>>>>>>>>> -phil. >>>>>>>>>>> >>>>>>>>>>> On 5/16/2016 3:32 AM, prasanta sadhukhan wrote: >>>>>>>>>>>> Hi All, >>>>>>>>>>>> >>>>>>>>>>>> Please review a fix for jdk9 whereby it is seen that >>>>>>>>>>>> A StackOverflowError occurs when printing in landscape >>>>>>>>>>>> orientation with a scaled and transformed graphics object. >>>>>>>>>>>> at sun.print.PSPrinterJob.prepDrawing(PSPrinterJob.java:1610) >>>>>>>>>>>> at >>>>>>>>>>>> sun.print.PSPrinterJob.beginPath(PSPrinterJob.java:1319) >>>>>>>>>>>> at >>>>>>>>>>>> sun.print.PSPrinterJob.convertToPSPath(PSPrinterJob.java:1793) >>>>>>>>>>>> at >>>>>>>>>>>> sun.print.PSPrinterJob$GState.emitPSClip(PSPrinterJob.java:1718) >>>>>>>>>>>> >>>>>>>>>>>> at >>>>>>>>>>>> sun.print.PSPrinterJob.prepDrawing(PSPrinterJob.java:1625) >>>>>>>>>>>> >>>>>>>>>>>> at sun.print.PSPrinterJob.beginPath(PSPrinterJob.java:1319) >>>>>>>>>>>> at >>>>>>>>>>>> sun.print.PSPrinterJob.convertToPSPath(PSPrinterJob.java:1793) >>>>>>>>>>>> at >>>>>>>>>>>> sun.print.PSPrinterJob$GState.emitPSClip(PSPrinterJob.java:1718) >>>>>>>>>>>> >>>>>>>>>>>> at >>>>>>>>>>>> sun.print.PSPrinterJob.prepDrawing(PSPrinterJob.java:1625) >>>>>>>>>>>> >>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6842011 >>>>>>>>>>>> webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/6842011/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> StackOverflowError is occuring because the scalex, scaley for >>>>>>>>>>>> landscape orientation was 0 so when the testcase tries >>>>>>>>>>>> to scale with these scale factors >>>>>>>>>>>> using g2d.scale( 1 / scalex, 1 / scaley ); >>>>>>>>>>>> it creates a AffineTransform of NaN transformation. Now, In >>>>>>>>>>>> linux, when the PS print drawing information is being >>>>>>>>>>>> prepared, it calls prepDrawing() where it checks >>>>>>>>>>>> getGState().mTransform.equals(mLastTransform) and since NaN >>>>>>>>>>>> values cannot be compared it results in "false", causing >>>>>>>>>>>> erroneous "grestore" postscript command to be issued and >>>>>>>>>>>> remove a >>>>>>>>>>>> GState from the stack so isOuterGState() becomes >>>>>>>>>>>> true which causes emitPSClip() to be called which calls >>>>>>>>>>>> prepDrawing() again via convertToPSPath() , beginPath() and >>>>>>>>>>>> since >>>>>>>>>>>> isOuterState() returns true due to transform not >>>>>>>>>>>> being equal it again calls emitPSClip() causing a recursion. >>>>>>>>>>>> >>>>>>>>>>>> The fix was to check if transform is NaN and do not fill the >>>>>>>>>>>> devicePath if it is so, so that erroeous drawing is not >>>>>>>>>>>> done. >>>>>>>>>>>> So, it will print out a blank page. >>>>>>>>>>>> >>>>>>>>>>>> In windows, the testcase prints out a blank page. In mac, the >>>>>>>>>>>> testcase prints a 2x2 rectangle. >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> Prasanta >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Wed Jun 1 07:18:18 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 1 Jun 2016 00:18:18 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : Exception getting thumbnail size for JPEG with embedded thumbnail Message-ID: <4cedc972-c8c2-42ed-80cf-e0fb276fc26d@default> Hi, Please review the following fix in JDK9: Bug : https://bugs.openjdk.java.net/browse/JDK-8152672 Webrev : http://cr.openjdk.java.net/~jdv/8152672/webrev.00/ Issue : When we are trying to get properties related to second image in JPEG file we are getting IIOException mentioning that it is not a JPEG file. Root cause : When we are skipping first image to reach second image header, we are just trying to find next available EOI marker. But if first image has embedded thumbnail in APP1 marker, we will reach to EOI of this thumbnail and not EOI of first image. So after we reach EOI of embedded thumbnail we try to access second image SOI marker which will fail. Solution : We have to change the logic of how we skip to consecutive images in JPEG file. We know that application markers, comments or other markers can contain data same as SOI & EOI. Instead of just checking for EOI marker serially, we should read length of these markers and skip them. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Wed Jun 1 08:06:58 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 1 Jun 2016 01:06:58 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail Message-ID: <89531a21-64b2-4e00-8f15-aa78650cf7b2@default> Updated bug title in JBS as it was misleading. From: Jayathirth D V Sent: Wednesday, June 01, 2016 12:48 PM To: Philip Race; Jim Graham Cc: 2d-dev at openjdk.java.net Subject: Review Request for JDK-8152672 : Exception getting thumbnail size for JPEG with embedded thumbnail Hi, Please review the following fix in JDK9: Bug : https://bugs.openjdk.java.net/browse/JDK-8152672 Webrev : http://cr.openjdk.java.net/~jdv/8152672/webrev.00/ Issue : When we are trying to get properties related to second image in JPEG file we are getting IIOException mentioning that it is not a JPEG file. Root cause : When we are skipping first image to reach second image header, we are just trying to find next available EOI marker. But if first image has embedded thumbnail in APP1 marker, we will reach to EOI of this thumbnail and not EOI of first image. So after we reach EOI of embedded thumbnail we try to access second image SOI marker which will fail. Solution : We have to change the logic of how we skip to consecutive images in JPEG file. We know that application markers, comments or other markers can contain data same as SOI & EOI. Instead of just checking for EOI marker serially, we should read length of these markers and skip them. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ivanov at oracle.com Wed Jun 1 10:21:35 2016 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 1 Jun 2016 13:21:35 +0300 Subject: [OpenJDK 2D-Dev] [9] request for review: 8078382: Wrong glyph is displayed for a derived font In-Reply-To: <574DFD01.2040307@oracle.com> References: <55A64031.3060205@oracle.com> <55A68982.9090906@oracle.com> <55A7ACBD.9040403@oracle.com> <55A7FA20.7000105@oracle.com> <55AFC5DA.1030408@oracle.com> <5718E59E.6060804@oracle.com> <574DBC27.80807@oracle.com> <574DFD01.2040307@oracle.com> Message-ID: Hi Phil, On 01.06.2016 0:07, Phil Race wrote: > getClosestStyle() is something of a last resort. > Historically I think it was called only when you > had only a font *with* a style like bold and someone asked for > plain/regular. > ie for the subtractive case rather than the additive case. > So it would not apply to the case in this bug. > > However OS X does not natively support synthetic styling so we may > be entering that method for the additive case on OS X. > > So will not have this same bug since it just does not happen. > > In which case the reamaining question is, when you only have BOLD and > ITALIC > and someone asks for BOLDITALIC and you can't synthesise at all, which > do you give them ? So it needs additional testing. However, I think GDI still returns Bold in this case: this way it would look consistent. > > I'd still lean towards ITALIC - assuming I have ITALIC, so we do not > need to update that method. > If it can be shown otherwise we can make the change. Do you think we should push the fix as is, and leave FontFamily.getClosestStyle() as it is now? Then test how native systems behave and update this method if necessary. Thanks, Alexey > > > -phil. > > On 05/31/2016 09:43 AM, Sergey Bylokhov wrote: >> On 31.05.16 19:30, Phil Race wrote: >>>> The patch changes the order of font selection: bold will be used, if >>>> possible, as the base for bold-italic instead of italic which is the >>>> current default. It also fixes the issue where italic is returned >>>> instead of bold. >>> >>> OK. +1 >> >> I am not sure but should FontFamily.getClosestStyle() be updated also?: >> case Font.BOLD|Font.ITALIC: >> if (italic != null) { >> return italic; >> } else if (bold != null) { >> return bold; >> } else { >> return plain; >> } >> } >> >>> >>> -phil. >>> >>>> >>>> >>>> Thank you in advance, >>>> Alexey >>>> >>>> On 22.07.2015 19:33, Alexey Ivanov wrote: >>>>> Hi Phil, >>>>> >>>>> On 16.07.2015 21:38, Phil Race wrote: >>>>>> On 07/16/2015 06:08 AM, Andrew Brygin wrote: >>>>>>> Hi Phil, >>>>>>> >>>>>>> another option to avoid the problem is to be a bit more specific >>>>>>> regarding the >>>>>>> required font when we obtaining lcd glyph from GDI. >>>>>>> If we specify a particular name of the font which we used to >>>>>>> construct the >>>>>>> glyph vector, then we will get glyphs exactly for desired >>>>>>> characters: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~bae/8078382/9/webrev.01/ >>>>>>> >>>>>>> This change affects only the case of lcd glyphs on windows, >>>>>>> it reduces the scope of required testing. >>>>>> >>>>>> This is heading in the direction I was thinking of but since GDI is >>>>>> excepting a face name >>>>>> (what we call a family name), I am not sure if this will always work >>>>>> as is. >>>>>> There are possible issues with using a localized name and the length >>>>>> of the full name exceeding what Windows allows here. >>>>>> And there may be unintended consequences that are not immediately >>>>>> obvious. >>>>>> I would like to try limit this to the case where we can positively >>>>>> identify that the >>>>>> font is not the one we expected. And do it cheaply too. >>>>>> I do not have a quick answer here but roughly the algorithm might be >>>>>> - specify family, check (somehow) if GDI selects the same base font >>>>>> - if not, try the facename approach (if the name fits). Did we >>>>>> succeed and get the same base font ? >>>>>> - if not, bail on GDI for this case and do the rasterisation >>>>>> ourselves. >>>>>> >>>>>> "cheaply" might depend on caching a success value on the first >>>>>> attempt, so >>>>>> that we only do it once, ever, for a font. Then the problem becomes >>>>>> how to >>>>>> do the verification. One approach might be to call GetFontData() >>>>>> which >>>>>> will give us some chunk of the font file and we can see if the name >>>>>> (or something >>>>>> else we can quickly and reliably parse) is exactly that we expect .. >>>>> >>>>> It looks there's no easy way to detect whether GDI selected the same >>>>> base font or not. GetTextFace function doesn't help it: it always >>>>> returns the face name passed in LOGFONT except in the cases where >>>>> there's no such font. >>>>> >>>>> I haven't found any other API which could tell us what font GDI >>>>> selected. So the only alternative is to use GetFontData and parse the >>>>> font file itself. Yet I can't find any example how to use this >>>>> function. I'll keep searching in that direction. >>>>> >>>>> >>>>> Regards, >>>>> Alexey >>>>> >>>>>> >>>>>> Leaving aside the 'wrong glyph' case, I have to suppose it is >>>>>> possible that >>>>>> there are other un-noticed cases where we use a different base font >>>>>> than >>>>>> that selected by GDI. The algorithms are not defined anywhere I can >>>>>> locate. >>>>>> >>>>>>> >>>>>>> However, there seems to be a copy&paste error in FontFamily.java: >>>>>>> on lines 340 - 341 we check that bold font fits our needs but use >>>>>>> italic >>>>>>> anyway. Was it done by purpose, or this is really an error? >>>>>> >>>>>> That is a copy/paste mistake. It should be fixed. >>>>>> >>>>>> -phil. >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Andrew >>>>>>> >>>>>>> On 7/15/2015 7:25 PM, Phil Race wrote: >>>>>>>> This probably needs more examination and perhaps a more complex >>>>>>>> fix. >>>>>>>> The observation that GDI bases bold-italic on the bold version not >>>>>>>> the >>>>>>>> italic version is an implementation choice just as we had done the >>>>>>>> opposite. It is possible some other time it does the opposite >>>>>>>> or some >>>>>>>> other platform does the opposite. I have supposed it is harder to >>>>>>>> synthesise italic than to do 'over-strike'. And this GDI usage >>>>>>>> applies only to LCD glyphs. >>>>>>>> >>>>>>>> Maybe what we need to do is see if we can detect the cases when >>>>>>>> GDI and JDK disagree on the actual font and remap the glyph id. >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> On 7/15/15 4:12 AM, Andrew Brygin wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> could you please review a fix for 8078382? >>>>>>>>> >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8078382 >>>>>>>>> webrev: http://cr.openjdk.java.net/~bae/8078382/9/webrev.00/ >>>>>>>>> >>>>>>>>> The problem is caused by following peculiarity of the Code New >>>>>>>>> Roman font: this font provides plain, italic and bold variants. >>>>>>>>> In bold and italic variants of the font, different glyphs >>>>>>>>> correspond to the apostrophe character (0039): >>>>>>>>> bold: 0039 -> 0x250 (592) >>>>>>>>> italic: 0039 -> 0x256 (598) >>>>>>>>> >>>>>>>>> So, we translate character to glyphs using italic variant >>>>>>>>> of the font, and then request glyph images from GDI. >>>>>>>>> However, GDI uses the bold variant of the font in order >>>>>>>>> to compose glyph images for artificial bold-italic variant, >>>>>>>>> and we have got a glyph image for ? instead of apostrophe. >>>>>>>>> >>>>>>>>> Suggested fix is to select bold variant (if possible) as a >>>>>>>>> base for artificial bold-italic. >>>>>>>>> >>>>>>>>> There is no regression test because it requires a specific font >>>>>>>>> to be installed on a test system. The font can be found here: >>>>>>>>> http://www.dafont.com/code-new-roman.font >>>>>>>>> >>>>>>>>> Please take a look. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Andrew >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> > From alexey.ivanov at oracle.com Wed Jun 1 10:22:56 2016 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 1 Jun 2016 13:22:56 +0300 Subject: [OpenJDK 2D-Dev] [9] request for review: 8078382: Wrong glyph is displayed for a derived font In-Reply-To: References: <55A64031.3060205@oracle.com> <55A68982.9090906@oracle.com> <55A7ACBD.9040403@oracle.com> <55A7FA20.7000105@oracle.com> <55AFC5DA.1030408@oracle.com> <5718E59E.6060804@oracle.com> <574DBC27.80807@oracle.com> Message-ID: Hi Sergey, On 31.05.2016 19:43, Sergey Bylokhov wrote: > On 31.05.16 19:30, Phil Race wrote: >>> The patch changes the order of font selection: bold will be used, if >>> possible, as the base for bold-italic instead of italic which is the >>> current default. It also fixes the issue where italic is returned >>> instead of bold. >> >> OK. +1 > > I am not sure but should FontFamily.getClosestStyle() be updated also?: > case Font.BOLD|Font.ITALIC: > if (italic != null) { > return italic; > } else if (bold != null) { > return bold; > } else { > return plain; > } > } > Good catch! The discussion is in progress? Regards, Alexey >> >> -phil. >> >>> >>> >>> Thank you in advance, >>> Alexey >>> >>> On 22.07.2015 19:33, Alexey Ivanov wrote: >>>> Hi Phil, >>>> >>>> On 16.07.2015 21:38, Phil Race wrote: >>>>> On 07/16/2015 06:08 AM, Andrew Brygin wrote: >>>>>> Hi Phil, >>>>>> >>>>>> another option to avoid the problem is to be a bit more specific >>>>>> regarding the >>>>>> required font when we obtaining lcd glyph from GDI. >>>>>> If we specify a particular name of the font which we used to >>>>>> construct the >>>>>> glyph vector, then we will get glyphs exactly for desired >>>>>> characters: >>>>>> >>>>>> http://cr.openjdk.java.net/~bae/8078382/9/webrev.01/ >>>>>> >>>>>> This change affects only the case of lcd glyphs on windows, >>>>>> it reduces the scope of required testing. >>>>> >>>>> This is heading in the direction I was thinking of but since GDI is >>>>> excepting a face name >>>>> (what we call a family name), I am not sure if this will always work >>>>> as is. >>>>> There are possible issues with using a localized name and the length >>>>> of the full name exceeding what Windows allows here. >>>>> And there may be unintended consequences that are not immediately >>>>> obvious. >>>>> I would like to try limit this to the case where we can positively >>>>> identify that the >>>>> font is not the one we expected. And do it cheaply too. >>>>> I do not have a quick answer here but roughly the algorithm might be >>>>> - specify family, check (somehow) if GDI selects the same base font >>>>> - if not, try the facename approach (if the name fits). Did we >>>>> succeed and get the same base font ? >>>>> - if not, bail on GDI for this case and do the rasterisation >>>>> ourselves. >>>>> >>>>> "cheaply" might depend on caching a success value on the first >>>>> attempt, so >>>>> that we only do it once, ever, for a font. Then the problem becomes >>>>> how to >>>>> do the verification. One approach might be to call GetFontData() >>>>> which >>>>> will give us some chunk of the font file and we can see if the name >>>>> (or something >>>>> else we can quickly and reliably parse) is exactly that we expect .. >>>> >>>> It looks there's no easy way to detect whether GDI selected the same >>>> base font or not. GetTextFace function doesn't help it: it always >>>> returns the face name passed in LOGFONT except in the cases where >>>> there's no such font. >>>> >>>> I haven't found any other API which could tell us what font GDI >>>> selected. So the only alternative is to use GetFontData and parse the >>>> font file itself. Yet I can't find any example how to use this >>>> function. I'll keep searching in that direction. >>>> >>>> >>>> Regards, >>>> Alexey >>>> >>>>> >>>>> Leaving aside the 'wrong glyph' case, I have to suppose it is >>>>> possible that >>>>> there are other un-noticed cases where we use a different base font >>>>> than >>>>> that selected by GDI. The algorithms are not defined anywhere I can >>>>> locate. >>>>> >>>>>> >>>>>> However, there seems to be a copy&paste error in FontFamily.java: >>>>>> on lines 340 - 341 we check that bold font fits our needs but use >>>>>> italic >>>>>> anyway. Was it done by purpose, or this is really an error? >>>>> >>>>> That is a copy/paste mistake. It should be fixed. >>>>> >>>>> -phil. >>>>> >>>>>> >>>>>> Thanks, >>>>>> Andrew >>>>>> >>>>>> On 7/15/2015 7:25 PM, Phil Race wrote: >>>>>>> This probably needs more examination and perhaps a more complex >>>>>>> fix. >>>>>>> The observation that GDI bases bold-italic on the bold version not >>>>>>> the >>>>>>> italic version is an implementation choice just as we had done the >>>>>>> opposite. It is possible some other time it does the opposite or >>>>>>> some >>>>>>> other platform does the opposite. I have supposed it is harder to >>>>>>> synthesise italic than to do 'over-strike'. And this GDI usage >>>>>>> applies only to LCD glyphs. >>>>>>> >>>>>>> Maybe what we need to do is see if we can detect the cases when >>>>>>> GDI and JDK disagree on the actual font and remap the glyph id. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 7/15/15 4:12 AM, Andrew Brygin wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> could you please review a fix for 8078382? >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8078382 >>>>>>>> webrev: http://cr.openjdk.java.net/~bae/8078382/9/webrev.00/ >>>>>>>> >>>>>>>> The problem is caused by following peculiarity of the Code New >>>>>>>> Roman font: this font provides plain, italic and bold variants. >>>>>>>> In bold and italic variants of the font, different glyphs >>>>>>>> correspond to the apostrophe character (0039): >>>>>>>> bold: 0039 -> 0x250 (592) >>>>>>>> italic: 0039 -> 0x256 (598) >>>>>>>> >>>>>>>> So, we translate character to glyphs using italic variant >>>>>>>> of the font, and then request glyph images from GDI. >>>>>>>> However, GDI uses the bold variant of the font in order >>>>>>>> to compose glyph images for artificial bold-italic variant, >>>>>>>> and we have got a glyph image for ? instead of apostrophe. >>>>>>>> >>>>>>>> Suggested fix is to select bold variant (if possible) as a >>>>>>>> base for artificial bold-italic. >>>>>>>> >>>>>>>> There is no regression test because it requires a specific font >>>>>>>> to be installed on a test system. The font can be found here: >>>>>>>> http://www.dafont.com/code-new-roman.font >>>>>>>> >>>>>>>> Please take a look. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Andrew >>>>>>> >>>>>> >>>>> >>>> >>> >> > > From ajit.ghaisas at oracle.com Wed Jun 1 10:28:03 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Wed, 1 Jun 2016 03:28:03 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Fix for JDK-8139192 : Custom ImageFilters return blank images in Java 8(.45) while working in 7 In-Reply-To: <74c0b159-895e-c6c4-67ae-e470d7055251@oracle.com> References: <480a1ef0-30e5-e1ed-8def-e28f383949ac@oracle.com> <958c83a7-1a72-a5cf-0b3b-8479efee5974@oracle.com> <6d79d18b-3854-402c-9981-38ed2e0f161a@default> <2d10a7cc-51e5-50dc-1a66-33f94679e067@oracle.com> <4f6cae95-0552-4507-942a-e0f2e9beb3be@default> <574DCB17.3070306@oracle.com> <574DE61F.30607@oracle.com> <74c0b159-895e-c6c4-67ae-e470d7055251@oracle.com> Message-ID: <544e09c0-79d9-4606-973e-d03259b68362@default> Thanks Jim and Phil for valuable feedback and suggestions. The detailed discussion helped me to understand why catching RuntimeException is a better option for a call to imageComplete(STATICIMAGEDONE). I have modified the code on line 192 accordingly. I have not modified the code catching NullPointerException (on line 196) as doing so would mask a wider variety of legitimate exceptions. So, line 196 remains unchanged. I have also modified the test to throw NullPointerException instead of calling intValue() on a null. Please review updated webrev : http://cr.openjdk.java.net/~aghaisas/8139192/webrev.03/ Regards, Ajit -----Original Message----- From: Phil Race Sent: Wednesday, June 01, 2016 1:41 AM To: Jim Graham; Ajit Ghaisas Cc: Sergey Bylokhov; 2d-dev Subject: Re: [OpenJDK 2D-Dev] Fix for JDK-8139192 : Custom ImageFilters return blank images in Java 8(.45) while working in 7 I agree with the suggestion of RuntimeException as likely sufficient but not too much ... -phil. On 5/31/2016 12:29 PM, Jim Graham wrote: > I agree with this. It would be nice if we didn't spit out print > statements by default, but I'm not sure what a good flag would be to > use to diagnose this that balances how likely developers will think to > use it. > > The point about catching a wider variety of exceptions is not that it > is good practice in general, but we've added a new call to a > long-standing algorithm which has decades (really? plural? pretty > much, I think) of past code that isn't expecting the new call, and > that call is basically "informative" not something that they really > need to successfully handle, so just as someone might accidentally > process a null pointer in a case like that, someone else might run off > the end of an array (AIOOB) or any other "I wasn't expecting that" > sort of issue. > > Throwable might be a bit much, though. Phil? I was thinking > Exception because those tend to focus on "your code made a mistake" > whereas Error is something like "you are mix/matching incompatible > code that was compiled to contain conflicting information" (kind of > like calling a method that doesn't exist in this release, etc.). It's > hard to say what the proper level of forgiveness should be here. > Another thought is "RuntimeException", since any other exception would > need to be declared to be thrown and we don't declare it for that > method, so their implementation shouldn't be allowed to declare it > either... > > ...jim > > On 05/31/2016 10:34 AM, Phil Race wrote: >> Based on what Ajit wrote in the bug report, he at least found a jar >> file that contains this code, but I have so far failed to locate the >> source code as all the versions I find on the net use the Java 2D >> JDK 1.2 BufferedImageOp APIs so I suspect this bug is in a very old >> version and it may not be open source. >> Therefore I am not sure how much e.printStackTrace() will help them >> if they don't own that source except to encourage them to upgrade. >> I'd be inclined to stick it behind a debugging property if we have >> one that we could re-use except that in such a case they probably >> won't know enough to set the property. >> So on balance it is probably best to do as it has been presented here >> except that catch (Throwable t) probably makes sense as we don't want >> to revisit this for a different exception. >> >> Minor nit about the test: instead of calling intValue() on a null >> Integer, why not just "throw new NullPointerException("reason ..") ? >> >> >> -phil. >> >> >> >> >> >> On 05/30/2016 01:22 AM, Ajit Ghaisas wrote: >>> I did contemplate catching 'Exception' instead of >>> 'NullPointerException' while raising the webrev, but decided not to do >>> it as- >>> 1. Complaint in current image filter was due to NPE only >>> 2. Catching & consuming generic exception does not seem quite correct >>> here as we are just printing stack trace and not taking any concrete >>> action. >>> 3. There is no reported issue of any other type of Exception out of >>> this method. >>> >>> Regards, >>> Ajit >>> >>> >>> -----Original Message----- >>> From: Jim Graham >>> Sent: Saturday, May 28, 2016 4:41 AM >>> To: Ajit Ghaisas; Sergey Bylokhov; 2d-dev; Philip Race >>> Subject: Re: [OpenJDK 2D-Dev] Fix for JDK-8139192 : Custom >>> ImageFilters return blank images in Java 8(.45) while working in 7 >>> >>> That looks good, but I wonder if it should catch all exceptions >>> instead of just NPE. Historically we were only catching NPE before we >>> added the call to STATICIMAGEDONE, and the current filter in question >>> turns out to throw an NPE, but if a filter that was commonly used with >>> offscreen images was not expecting the STATICIMAGEDONE as was this >>> WaterFilter, then they could potentially throw a wider variety of >>> exceptions. >>> >>> I'm good with NPE since that is the only case we've seen, but I'd also >>> be good with changing line 192 to catch all exceptions. Phil? >>> >>> ...jim >>> >>> On 5/27/16 1:32 AM, Ajit Ghaisas wrote: >>>> Hi Jim, >>>> >>>> Thanks for in-depth analysis and detailed review. >>>> I appreciate your concern for filtered image being blank in Java >>>> 8, while it used to work in Java 7. >>>> >>>> Yes. I totally agree with your suggestion to do both - >>>> 1. Not send IMAGEERROR if there is exception from ImageFilter >>>> while processing STATICIMAGE done >>>> 2. At the same time, as we are consuming the exception, show the >>>> exception stacktrace. >>>> >>>> With this fix the functionality of com.jhlabs.image.WaterFilter >>>> is restored. It does not return blank images anymore. >>>> Also, as additional information, exception details are shown as >>>> a stacktrace. >>>> >>>> Please review the updated webrev : >>>> http://cr.openjdk.java.net/~aghaisas/8139192/webrev.02/ >>>> >>>> Regards, >>>> Ajit >>>> >>>> >>>> -----Original Message----- >>>> From: Jim Graham >>>> Sent: Thursday, May 26, 2016 4:57 AM >>>> To: Sergey Bylokhov; Ajit Ghaisas; 2d-dev; Philip Race >>>> Subject: Re: [OpenJDK 2D-Dev] Fix for JDK-8139192 : Custom >>>> ImageFilters return blank images in Java 8(.45) while working in 7 >>>> >>>> Their complaint is that the resulting image is empty - most likely >>>> because the error gets passed through and clears the image buffer. >>>> It appears that the sequence of events is: >>>> >>>> We send SINGLEFRAMEDONE. >>>> - the image is displayable >>>> We send STATICIMAGEDONE. >>>> - filter throws NPE >>>> - image is probably still displayable >>>> We send ERROR >>>> - if it gets passed through to the toolkit image consumer then we'll >>>> clear the image buffer >>>> - image is no longer displayable >>>> >>>> It's hard to say for sure without having an instance of their filter >>>> in-house for testing, but previously we weren't sending the >>>> STATICDONE notice and the program was working just fine. Since the >>>> NPE comes from their code when we send it, it shouldn't have affected >>>> any down-stream consumers, so we should be OK with just continuing on >>>> and the image should still be displayable just as if we hadn't sent >>>> the STATICDONE notice in the first place. >>>> >>>> Now, *during debugging*, they were thwarted by the fact that we ate >>>> the exception, true, but the original issue is that the image wasn't >>>> displayable at all. We might want to do both: >>>> >>>> - not send ERROR for STATICDONE when we used to not send STATICDONE at >>>> all >>>> - show the exception so that someone realizes that there is a >>>> problem, even though we've made it not hurt their functionality. >>>> >>>> Does that make sense? >>>> >>>> ...jim >>>> >>>> On 5/25/2016 1:36 PM, Sergey Bylokhov wrote: >>>>> On 25.05.16 23:33, Jim Graham wrote: >>>>>> How about option 3 - >>>>>> >>>>>> NPE before imageComplete sends an ERROR as it does now. >>>>>> >>>>>> NPE during imageComplete is ignored, both for backwards >>>>>> compatibility and because it is more of a "hint" than an operation >>>>>> that requires action from the consumer. >>>>> I guess the case is that when we ignore this NPE(w/o any >>>>> notification) the users complains that the bug is in jdk. >>>>> >>>>>> ...jim >>>>>> >>>>>> On 5/25/2016 1:31 AM, Ajit Ghaisas wrote: >>>>>>> Hi >>>>>>> >>>>>>> >>>>>>> >>>>>>> Bug : >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8139192 >>>>>>> >>>>>>> Custom ImageFilters return blank images in Java 8(.45) while >>>>>>> working in 7 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Root cause : >>>>>>> >>>>>>> private method produce() in OffScreenImageSource.java consumes a >>>>>>> NullPointerException that originates from a custom ImageConsumer (a >>>>>>> 3^rd party image library class - com.jhlabs.image.WaterFilter) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Analysis: >>>>>>> >>>>>>> 1. How the behavior changed between JDK7 and JK8 : >>>>>>> >>>>>>> A call to imageComplete(ImageConsumer.SINGLEFRAMEDONE) was added in >>>>>>> addition to imageComplete(ImageConsumer. STATICIMAGEDONE) as a fix >>>>>>> for JDK-7143612. >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2. What debugging revealed: >>>>>>> >>>>>>> A NullPointerException is being thrown from the library during the >>>>>>> call to imageComplete(ImageConsumer.STATICIMAGEDONE) >>>>>>> >>>>>>> >>>>>>> >>>>>>> 3. It looks like the fix of JDK-7143612 is valid and successive >>>>>>> calls to >>>>>>> imageComplete() are allowed. >>>>>>> >>>>>>> >>>>>>> >>>>>>> 4. The 3rd party library behavior appears incorrect (if it can not >>>>>>> handle subsequent calls to imageComplete(), it should de-register >>>>>>> itself). >>>>>>> >>>>>>> The 3rd-party library code should be fixed. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Possible modifications in JDK : >>>>>>> >>>>>>> >>>>>>> >>>>>>> Currently, OffScreenImageSource::produce() consumes the >>>>>>> NullPointerException - this is incorrect and results in silent >>>>>>> failure of this particular image filter. >>>>>>> >>>>>>> We need to let the image filter library know that exception has >>>>>>> occurred in its code and not in JDK. We have two options - >>>>>>> >>>>>>> >>>>>>> >>>>>>> Option 1 : Rethrow the NullPointerException --- It is the >>>>>>> clearest way >>>>>>> to let 3^rd party library know that their code is erroneous with >>>>>>> latest JDK. This will change the 3^rd party image filter behavior >>>>>>> that generates blank image. >>>>>>> >>>>>>> Option 2 : Add a stack trace where the exception is being consumed >>>>>>> --- Adding stack trace provides more information regarding failure >>>>>>> of 3^rd party image filter with retaining the current behavior that >>>>>>> generates blank image. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I have implemented both the options: >>>>>>> >>>>>>> Option 1: http://cr.openjdk.java.net/~aghaisas/8139192/webrev.00/ >>>>>>> >>>>>>> Option 2: http://cr.openjdk.java.net/~aghaisas/8139192/webrev.01/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> Request you to review both the webrevs and provide your preference. >>>>>>> >>>>>>> I will add a test to the selected webrev. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Ajit >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >> From prasanta.sadhukhan at oracle.com Wed Jun 1 10:37:05 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Wed, 1 Jun 2016 16:07:05 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6601097:Margins are not reset to hardware margins when width/height is 0 or -ve alongwith x, y In-Reply-To: <574DBF01.5080101@oracle.com> References: <5745D4BB.5040900@oracle.com> <574DBF01.5080101@oracle.com> Message-ID: <8af2832a-77c7-41e7-bf4c-ebc743185747@oracle.com> Hi Phil, Actually, the test program does 3 subtests 1. negative y we get ix=12, iy=12, iw=571, ih=817 in Margins.java#print() where we do System.out.println("ix="+ix+" iy="+iy+" iw="+iw+" ih="+ih); which is correctly getting hardware margin and not Java default 1" margin 2. printable height more than paper height we get ix=12, iy=12, iw=571, ih=817 which is correctly getting hardware margin and not Java default 1" margin 3. negative width we get ix=72, iy=72, iw=451, ih=697 which is not correct as we get 1" margin and not hardware margin With webrev.01, I am getting ix=12, iy=12, iw=571, ih=817 ie, correct hardware margin same as the other 2 subtests . *Is it not correct?* I guess your suggested change wants me to do the below but I am not sure how to get hardware margin? Can you please suggest how to constrain iw/ih with ix/iy? 686 if (ix < 0) ix = 0f; if (iy < 0) iy = 0f; 687 float left = (ix > 0) ? ix : 1.0f; // take valid ix or 1" ??? how will I get hardware margin?? 688 float top = (iy > 0 ) ? iy : 1.0f; // take valid iy or 1" 689 if (iw <= 0) iw = (float)(page.getPaper().getWidth()/DPI) - (left*2.0f); 690 if (ih <= 0) ih = (float)(page.getPaper().getHeight()/DPI) - (top*2.0f); Regards Prasanta On 5/31/2016 10:12 PM, Phil Race wrote: > Well ... few printers can print on the entire paper. Photo printers are > the ones that can do this. So Paper dimension minus the "hardware > margins" > are the maximum imageable width. > And then supposing imageable x/y is some perfectly reasonable value > like 1" each > then you've set iw/ih such that even a printer with zero hardware > margins has > an imageable area that goes off the bottom and right off the paper. > > More reasonable would be to constrain iw/ih such that they work with the > requested ix/iy - assuming they are also valid. > > If all else fails then just using the "default" set of values as if > the application > had not set any values would be better. > > -phil. > > On 05/26/2016 03:26 AM, prasanta sadhukhan wrote: >> Hi Phil, >> >> I got it rectified. >> >> Please find the modified webrev >> >> http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.01/ >> >> Regarding using entire width/height pf paper, I thought since >> imageable width/height is invalid we should make the entire paper as >> the imageable area.For invalid x,y we were making it to paper's >> top/left. >> Else what option do we have, should we calculate >> width[height]=abs(image[width][height]) instead? >> >> Regards >> Prasanta >> On 5/25/2016 10:07 PM, Philip Race wrote: >>> It seems to me that you are using the wrong units. >>> You have not divided by DPI to get inches. >>> >>> Also I am not sure that the *entire* width/height of the paper is >>> what you want here >>> but that is secondary to the first issue >>> >>> -phil >>> >>> On 5/19/16, 2:59 AM, prasanta sadhukhan wrote: >>>> Hi All, >>>> >>>> Please review a fix for jdk9 which is a continuation of the fix of >>>> JDK-6543815. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6601097 >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.00/ >>>> >>>> 6543815 fix resets the x,y to 0 if they are negative before >>>> creating a MediaPrintableArea and the platform replaces it with >>>> hardware margins when printing. >>>> This works only if x/y is negative. >>>> But, If either width/height is negative alongwith x or y, then the >>>> margin is set to the java def 1 inch margin and not hardware margins. >>>> >>>> This is because width/height -ve results in IAE in >>>> MediaPrintableArea constructor and so values are ignored. >>>> Added a check for -ve width/height to make sure width/height are >>>> set to minimum paper width/height. >>>> >>>> Regards >>>> Prasanta >>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Wed Jun 1 10:47:56 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Wed, 1 Jun 2016 16:17:56 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR 6212751: DOC: ServiceUI.printDialog() need to enhance the description for X, Y coordinates In-Reply-To: <574DD94F.1090900@oracle.com> References: <52b96c89-0774-f473-a311-b9ea04448720@oracle.com> <574DD94F.1090900@oracle.com> Message-ID: <4b9ca6c3-f4c2-b4dc-44a2-d34b560ddf51@oracle.com> Hi Phil, Ok. So, it seems we do not need to make change to gc definition. I just modified x,y to specify it is relative to gc. http://cr.openjdk.java.net/~psadhukhan/6212751/webrev.01/ Do you think it's ok? or do you think our explanation in the javadocs is good enough and we can close this bug as "not an issue"? Regards Prasanta On 6/1/2016 12:04 AM, Phil Race wrote: > Before I forget this one looks as if it may need a CCC - if it goes > that far. > Remember to revisit that before it is done. > > Yet I am not sure I accept what is written in the bug report as being > the basis > for updating these docs. > > The existing javadoc on ServiceUI appears consistent with what is > written here : > https://docs.oracle.com/javase/8/docs/api/java/awt/GraphicsConfiguration.html > > The specified "GC" - best written out as "GraphicsConfiguration" in > the docs - > targets a specific physical monitor/screen regardless of whether the > screens > are separate or there is one virtual screen spanning them. > The x/y are then relative to the origin of that monitor/screen. > > >this value depicts the GC ofthe active window. > > All references to "active window" fall flat if there is no such window > so I don't think you should (or can) bake such an assumption into the > javadoc. > Remember this dialog could be the *only* window that is ever displayed > by the app. > > But even more importantly this is simply wrong. > I can specify *any* GC I want. Nothing should be forcing me to display it > only on the same screen as the active window - if there is one. > It might be what you usually want to do but that is a choice .. > > If I was to speculate, I might say that the comments written in 6212751 > were a result of confusion due to the issues described in 8138749 (and > its original report under 5109347). > > -phil. > > On 05/27/2016 04:54 AM, prasanta sadhukhan wrote: >> >> Hi All, >> >> Please review a doc fix for jdk9. >> Bug: https://bugs.openjdk.java.net/browse/JDK-6212751 >> webrev: http://cr.openjdk.java.net/~psadhukhan/6212751/webrev.00/ >> >> After JDK-8138749 >> multimonitor support fix, the doc needs some change. It was also >> misleading in the first place as the bugdescription pointed out >> which is API doc for ServiceUI.printDialog() specifies that X,Y are >> location of the dialog in screen coordinates, but for multmonitor >> setup, it should be w.r.t to secondary screen >> because >> . If the sec monitor starts at 1025, 0 and If I specify 1025 as the X >> coordinate, the calculated X value would be 1025 + 1025 = 2050 which >> actually exceeds the bounds of virtual screen. >> >> Updated the documentation . >> >> Regards >> Prasanta > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Jun 1 16:32:23 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 01 Jun 2016 09:32:23 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6842011: StackOverflowError printing landscape with scale and transform In-Reply-To: <1cb02649-3738-73e8-9452-68fd9e427131@oracle.com> References: <5739A1D8.90703@oracle.com> <4ac584a5-b1a6-a707-bd80-3d7717901c46@oracle.com> <0bfb90de-f26b-45f9-6e08-ae1d1818ffcb@oracle.com> <811d7b2a-4cf6-90d3-254e-f54e05a88837@oracle.com> <57438156.2000007@oracle.com> <994ea332-c40f-e97c-8780-4015193946c2@oracle.com> <57438AED.9070009@oracle.com> <5745D569.4090709@oracle.com> <66c5075a-d5f1-fd38-c230-1b61a9c26778@oracle.com> <574DCD00.9010005@oracle.com> <1cb02649-3738-73e8-9452-68fd9e427131@oracle.com> Message-ID: <574F0E17.2040008@oracle.com> +1 -phil. On 6/1/16, 12:03 AM, prasanta sadhukhan wrote: > > HI Phil, Jim, > > I have modified webrev to address Jim's doc change. Please review > http://cr.openjdk.java.net/~psadhukhan/6842011/webrev.02/ > > I will send the ccc link separately to you for approval. > > On 5/31/2016 11:12 PM, Phil Race wrote: >> On 05/26/2016 03:49 AM, prasanta sadhukhan wrote: >>> >>> Hi Phil, >>> >>> >>> On 5/25/2016 10:10 PM, Philip Race wrote: >>>> I am OK with committing the clarifying javadoc as part of this fix >>>> and filing a new RFE for the new method - to be fixed at some later >>>> date. >>>> >>>> However before this fix can be committed you need to make sure >>>> we have consistent behaviour across platforms and we do not have >>>> that yet >>> In mac, unlike RasterPrinterJob which does the transform using the >>> following code >>> / pathGraphics.transform(scaleTransform);// >>> // // user (0,0) should be origin of page, not >>> imageable area// >>> // >>> pathGraphics.translate(-getPhysicalPrintableX(paper) / xScale,// >>> // >>> -getPhysicalPrintableY(paper) / yScale);// >>> // pathGraphics.transform(new >>> AffineTransform(page.getMatrix()));// >>> /CPrinterJob does not do this transforms, it straightway goes to >>> native printloop code >>> so when scalex = g2d.getTransform().getScaleX(); is called the >>> transform returned is identity transform (as was the case in linux >>> too before the above transform code is executed) >> >> I am not sure I know what you mean by that part in parentheses. > What I meant was SunGraphics2D.transform was an identity transform in > linux and osx to begin with, but in linux RasterPrinterJob calls the > above code snippet which modifies SunGraphics2D.transfrom from > identity transform to > [m00=0, m01=4.16, m02=0][m10=-4.16, m11=0, m12=3507.873] but it > remains as identity transform in osx. >> Our printing pipelines have always reflected the device transform. >> >> If in fact OS X printing does not do that, then this is a bigger >> inconsistency .. >> But not one we will try to address today, nor in JDK 9.. >> Verify that is the case and then file a P4 bug on that too in order >> to track it. >> > RasterPrinterJob#print() calls printPage() which does this device > transformation but in osx CPrinterJob#print calls printloop() in osx > native which does not do this. I have created JDK-8158339 to address this. > > Regards > Prasanta >> And this fix is then approved .. >> >> -phil. >> >> >>> so getScaleX/Y returns 1 as m00,m11=1 . >>> So, since the transform is not invalid unlike linux, mac prints ok. >>> >>> Regards >>> Prasanta >>>> >>>> -phil. >>>> >>>> On 5/23/16, 3:57 PM, Phil Race wrote: >>>>> On 05/23/2016 03:33 PM, Jim Graham wrote: >>>>>> Though, they are likely to think this API is doing that. We have >>>>>> a visibility problem here to make sure that any work going >>>>>> forward is more likely to see the new method and ignore this >>>>>> one. I don't think we'll win there on naming alone, but we can >>>>>> make the javadocs look very intimidating so if they are using >>>>>> completion they may get scared and hopefully see the other method >>>>>> before they just accept the completion. Perhaps we can try to >>>>>> make the alphabetic sorting have the new methods appear first in >>>>>> the list? >>>>> >>>>> getScaleFactorX() should sort ahead of getScaleX() >>>>> >>>>> -phil. >>>>> >>>>>> >>>>>> In FX we were smart and went with very dry "getMxy()" style names >>>>>> that won't attract attention... >>>>>> >>>>>> ...jim >>>>>> >>>>>> On 5/23/2016 3:16 PM, Phil Race wrote: >>>>>>> What we have here might happen when developer A writes some UI code >>>>>>> without any conception that a 90 degree rotation may be in >>>>>>> effect and >>>>>>> then developer B >>>>>>> comes along and adds printing support .. and the implementation >>>>>>> rotates it. >>>>>>> So an out-of-the-box advertised API that does what dev A really >>>>>>> meant >>>>>>> would be helpful. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 05/23/2016 11:52 AM, Jim Graham wrote: >>>>>>>> I think we need to go a bit further and change the way we describe >>>>>>>> them. If we perhaps get very technical about how it is >>>>>>>> returning one >>>>>>>> element of the scaling equations/matrix then they will be >>>>>>>> discouraged >>>>>>>> from finding a simple use for it. I'll try to come up with some >>>>>>>> wording today or tomorrow and it would be good to apply it to >>>>>>>> all 6 of >>>>>>>> the getters uniformly. Something like: >>>>>>>> >>>>>>>> Returns element M## of the transformation matrix which controls >>>>>>>> how >>>>>>>> the output XY coordinates are affected by the input XY >>>>>>>> coordinates. >>>>>>>> >>>>>>>> Then on the getScaleXY methods add a "Note, this method will not >>>>>>>> return the amount by which input XY coordinates will be >>>>>>>> stretched or >>>>>>>> contracted since a 90 degree rotation will cause all of its >>>>>>>> contribution to be redirected into the other axis. Properly >>>>>>>> determining the full scale of the matrix involves analyzing >>>>>>>> both this >>>>>>>> factor and the ...". >>>>>>>> >>>>>>>> There is where it would be good to have the new methods ready >>>>>>>> to go so >>>>>>>> we can then immediately say ", such as in the getScalingFactorXY() >>>>>>>> method" or have an @see to send them where they need to go. That >>>>>>>> doesn't mean we can't do this documentation refresh now, but we >>>>>>>> might >>>>>>>> want to make those new methods a high priority to get done >>>>>>>> soon. (I'm >>>>>>>> guessing/hoping we can add small "fixup" APIs like that after >>>>>>>> FC since >>>>>>>> it doesn't really represent a "feature"...?) >>>>>>>> >>>>>>>> ...jim >>>>>>>> >>>>>>>> On 5/22/16 11:53 PM, prasanta sadhukhan wrote: >>>>>>>>> Hi Jim, >>>>>>>>> >>>>>>>>> >>>>>>>>> On 5/21/2016 3:20 AM, Jim Graham wrote: >>>>>>>>>> We should acknowledge that the test case is buggy anyway. It >>>>>>>>>> is not >>>>>>>>>> computing the scale of a transform correctly, >>>>>>>>>> though that is likely due to the unfortunate naming we chose >>>>>>>>>> for our >>>>>>>>>> methods. >>>>>>>>>> >>>>>>>>>> If you are looking for "the amount by which an X coordinate is >>>>>>>>>> stretched or contracted", you have to compute a >>>>>>>>>> distance formula on all of the elements of the X transform >>>>>>>>>> equation. We don't have a method to do that for the >>>>>>>>>> caller. If we did, we might call it something very similar to >>>>>>>>>> "getScaleX()". >>>>>>>>>> >>>>>>>>>> Unfortunately, we have a method named "getScaleX()" which one >>>>>>>>>> might >>>>>>>>>> think does that, but it doesn't. >>>>>>>>>> >>>>>>>>>> While I think we should prevent a stack overflow here, it's >>>>>>>>>> really >>>>>>>>>> more of "making sure a program bug is caught early >>>>>>>>>> and with a more sane response", than "fixing a valid test case". >>>>>>>>>> >>>>>>>>>> Also, we should consider adding a method to do the right >>>>>>>>>> calculation, and document the existing getScaleX() to point >>>>>>>>>> out that it cannot be used to determine "the stretchiness of X >>>>>>>>>> coordinates" or something more appropriately worded... >>>>>>>>>> >>>>>>>>> I have documented the anomalies in getScaleX()/getScaley(). >>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/6842011/webrev.01/ >>>>>>>>> I will create a bug to address this scaling calculation of a >>>>>>>>> transform in affinetransform (as it is in geom package and >>>>>>>>> not a printing issue par se). Will that be ok? >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Prasanta >>>>>>>>>> ...jim >>>>>>>>>> >>>>>>>>>> On 5/20/16 4:27 AM, prasanta sadhukhan wrote: >>>>>>>>>>> Hi Phil, >>>>>>>>>>> >>>>>>>>>>> When we call print() it calls RasterPrinterJob#printPage() >>>>>>>>>>> which >>>>>>>>>>> sets peekGraphics.transform([4.16,0,0][0,4.16,0]) as >>>>>>>>>>> obtained from xscale=4.16 [getXRes()=300 / 72.0] ,yscale=4.16 >>>>>>>>>>> It calls SunGraphics2D.transform which was identity >>>>>>>>>>> transform [1.0, >>>>>>>>>>> 0.0, 0.0] [0.0, 1.0, 0.0] calls >>>>>>>>>>> transform.concatenate(peekgraphicsTx) and stores as >>>>>>>>>>> ([4.16,0,0][0,4.16,0]) >>>>>>>>>>> >>>>>>>>>>> Then RasterPrinterJob#printPage() again calls >>>>>>>>>>> peekGraphics.transform(new AffineTransform(page.getMatrix())); >>>>>>>>>>> where page.getMatrix() returns 0.0, -1.0, 1.0, 0.0, 0.0, >>>>>>>>>>> 841.88 and >>>>>>>>>>> peekGraphics transform now becomes [0.0, 1.0, 0.0] >>>>>>>>>>> [-1.0, 0.0, 841.88] >>>>>>>>>>> which calls SunGraphics2D#transform() where it again does >>>>>>>>>>> transform.concatenate(peekgraphicsTx) >>>>>>>>>>> >>>>>>>>>>> so the transform becomes [m00=0, m01=4.16, m02=0][m10=-4.16, >>>>>>>>>>> m11=0, >>>>>>>>>>> m12=3507.873] >>>>>>>>>>> Now scaleX obtains value from g2d.getTransform().getScaleX() >>>>>>>>>>> which >>>>>>>>>>> returns SunGraphics2D stored transform.m00 which is 0 >>>>>>>>>>> and scaleY is m11=0 so scaleX,scaleY becomes 0. >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> Prasanta >>>>>>>>>>> On 5/19/2016 4:03 AM, Phil Race wrote: >>>>>>>>>>>> It sounds like scalex & scaley are 0 and are then used in >>>>>>>>>>>> calculations which >>>>>>>>>>>> results in the NaN ? So why are they zero to begin with ? >>>>>>>>>>>> >>>>>>>>>>>> -phil. >>>>>>>>>>>> >>>>>>>>>>>> On 5/16/2016 3:32 AM, prasanta sadhukhan wrote: >>>>>>>>>>>>> Hi All, >>>>>>>>>>>>> >>>>>>>>>>>>> Please review a fix for jdk9 whereby it is seen that >>>>>>>>>>>>> A StackOverflowError occurs when printing in landscape >>>>>>>>>>>>> orientation with a scaled and transformed graphics object. >>>>>>>>>>>>> at >>>>>>>>>>>>> sun.print.PSPrinterJob.prepDrawing(PSPrinterJob.java:1610) >>>>>>>>>>>>> at >>>>>>>>>>>>> sun.print.PSPrinterJob.beginPath(PSPrinterJob.java:1319) >>>>>>>>>>>>> at >>>>>>>>>>>>> sun.print.PSPrinterJob.convertToPSPath(PSPrinterJob.java:1793) >>>>>>>>>>>>> >>>>>>>>>>>>> at >>>>>>>>>>>>> sun.print.PSPrinterJob$GState.emitPSClip(PSPrinterJob.java:1718) >>>>>>>>>>>>> >>>>>>>>>>>>> at >>>>>>>>>>>>> sun.print.PSPrinterJob.prepDrawing(PSPrinterJob.java:1625) >>>>>>>>>>>>> >>>>>>>>>>>>> at sun.print.PSPrinterJob.beginPath(PSPrinterJob.java:1319) >>>>>>>>>>>>> at >>>>>>>>>>>>> sun.print.PSPrinterJob.convertToPSPath(PSPrinterJob.java:1793) >>>>>>>>>>>>> >>>>>>>>>>>>> at >>>>>>>>>>>>> sun.print.PSPrinterJob$GState.emitPSClip(PSPrinterJob.java:1718) >>>>>>>>>>>>> >>>>>>>>>>>>> at >>>>>>>>>>>>> sun.print.PSPrinterJob.prepDrawing(PSPrinterJob.java:1625) >>>>>>>>>>>>> >>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6842011 >>>>>>>>>>>>> webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/6842011/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> StackOverflowError is occuring because the scalex, scaley for >>>>>>>>>>>>> landscape orientation was 0 so when the testcase tries >>>>>>>>>>>>> to scale with these scale factors >>>>>>>>>>>>> using g2d.scale( 1 / scalex, 1 / scaley ); >>>>>>>>>>>>> it creates a AffineTransform of NaN transformation. Now, In >>>>>>>>>>>>> linux, when the PS print drawing information is being >>>>>>>>>>>>> prepared, it calls prepDrawing() where it checks >>>>>>>>>>>>> getGState().mTransform.equals(mLastTransform) and since NaN >>>>>>>>>>>>> values cannot be compared it results in "false", causing >>>>>>>>>>>>> erroneous "grestore" postscript command to be issued and >>>>>>>>>>>>> remove a >>>>>>>>>>>>> GState from the stack so isOuterGState() becomes >>>>>>>>>>>>> true which causes emitPSClip() to be called which calls >>>>>>>>>>>>> prepDrawing() again via convertToPSPath() , beginPath() >>>>>>>>>>>>> and since >>>>>>>>>>>>> isOuterState() returns true due to transform not >>>>>>>>>>>>> being equal it again calls emitPSClip() causing a recursion. >>>>>>>>>>>>> >>>>>>>>>>>>> The fix was to check if transform is NaN and do not fill the >>>>>>>>>>>>> devicePath if it is so, so that erroeous drawing is not >>>>>>>>>>>>> done. >>>>>>>>>>>>> So, it will print out a blank page. >>>>>>>>>>>>> >>>>>>>>>>>>> In windows, the testcase prints out a blank page. In mac, the >>>>>>>>>>>>> testcase prints a 2x2 rectangle. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards >>>>>>>>>>>>> Prasanta >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Jun 1 16:34:35 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 01 Jun 2016 09:34:35 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR 6212751: DOC: ServiceUI.printDialog() need to enhance the description for X, Y coordinates In-Reply-To: <4b9ca6c3-f4c2-b4dc-44a2-d34b560ddf51@oracle.com> References: <52b96c89-0774-f473-a311-b9ea04448720@oracle.com> <574DD94F.1090900@oracle.com> <4b9ca6c3-f4c2-b4dc-44a2-d34b560ddf51@oracle.com> Message-ID: <574F0E9B.8090001@oracle.com> I think those few words you added are good and sufficient .. -phil. On 6/1/16, 3:47 AM, prasanta sadhukhan wrote: > > Hi Phil, > > Ok. So, it seems we do not need to make change to gc definition. > I just modified x,y to specify it is relative to gc. > > http://cr.openjdk.java.net/~psadhukhan/6212751/webrev.01/ > > Do you think it's ok? or do you think our explanation in the javadocs > is good enough and we can close this bug as "not an issue"? > > Regards > Prasanta > On 6/1/2016 12:04 AM, Phil Race wrote: >> Before I forget this one looks as if it may need a CCC - if it goes >> that far. >> Remember to revisit that before it is done. >> >> Yet I am not sure I accept what is written in the bug report as being >> the basis >> for updating these docs. >> >> The existing javadoc on ServiceUI appears consistent with what is >> written here : >> https://docs.oracle.com/javase/8/docs/api/java/awt/GraphicsConfiguration.html >> >> The specified "GC" - best written out as "GraphicsConfiguration" in >> the docs - >> targets a specific physical monitor/screen regardless of whether the >> screens >> are separate or there is one virtual screen spanning them. >> The x/y are then relative to the origin of that monitor/screen. >> >> >this value depicts the GC ofthe active window. >> >> All references to "active window" fall flat if there is no such window >> so I don't think you should (or can) bake such an assumption into the >> javadoc. >> Remember this dialog could be the *only* window that is ever >> displayed by the app. >> >> But even more importantly this is simply wrong. >> I can specify *any* GC I want. Nothing should be forcing me to display it >> only on the same screen as the active window - if there is one. >> It might be what you usually want to do but that is a choice .. >> >> If I was to speculate, I might say that the comments written in 6212751 >> were a result of confusion due to the issues described in 8138749 (and >> its original report under 5109347). >> >> -phil. >> >> On 05/27/2016 04:54 AM, prasanta sadhukhan wrote: >>> >>> Hi All, >>> >>> Please review a doc fix for jdk9. >>> Bug: https://bugs.openjdk.java.net/browse/JDK-6212751 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/6212751/webrev.00/ >>> >>> After JDK-8138749 >>> multimonitor support fix, the doc needs some change. It was also >>> misleading in the first place as the bugdescription pointed out >>> which is API doc for ServiceUI.printDialog() specifies that X,Y are >>> location of the dialog in screen coordinates, but for multmonitor >>> setup, it should be w.r.t to secondary screen >>> because >>> . If the sec monitor starts at 1025, 0 and If I specify 1025 as the >>> X coordinate, the calculated X value would be 1025 + 1025 = 2050 >>> which actually exceeds the bounds of virtual screen. >>> >>> Updated the documentation . >>> >>> Regards >>> Prasanta >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Jun 1 16:36:14 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 01 Jun 2016 09:36:14 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods In-Reply-To: <9a87056b-2646-4d5f-bfec-d50bea489381@default> References: <6f83b633-3910-47fa-b872-e042fe4c24d3@default> <24ca2994-aa27-4a70-8cf9-0bda35664f3f@default> <574809B2.5040901@oracle.com> <9f641938-f979-4021-9e94-bde47e1d3c67@default> <57489033.7020901@oracle.com> <77d5b327-066b-4d86-a44d-8e681aeb71f8@default> <574DE3F9.40709@oracle.com> <574E0717.5060405@oracle.com> <574E0DF9.20508@oracle.com> <574E10B0.4070003@oracle.com> <574E13BD.9060701@oracle.com> <9a87056b-2646-4d5f-bfec-d50bea489381@default> Message-ID: <574F0EFE.2070300@oracle.com> Please post the updated webrev. -phil. On 6/1/16, 12:02 AM, Jayathirth D V wrote: > Hi Phil& Jim, > > Collating all the changes needed: > 1) I have removed both equals()& hashCode() in CCM but forgot to add the file while creating webrev. I will include changes in CCM in updated webrev. > 2) Caching of hashCode value in IndexColorModel& PackedColorModel : > We can cache hashCode value when constructor is called or when hashCode() is called for first time. What approach we have to follow? > 3) Comment section of equals() method, I will update it to : > 1449 * the target object must be the same class (and not a subclass) as this > 4) I will use .equals() to compare colorSpace values in CM.equals() so it will be like we are not intending ColorSpace class to never override equals() method. > > Please let me know your inputs. > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Wednesday, June 01, 2016 4:14 AM > To: Phil Race > Cc: Jayathirth D V; 2d-dev at openjdk.java.net > Subject: Re: Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods > > I think we should use .equals() here, otherwise it looks like a recommendation that the intent is for those classes to never implement it... > > ...jim > > On 05/31/2016 03:31 PM, Phil Race wrote: >> I don't know of any design intent, so yes, I meant more as a practical >> matter. >> Unless they subclass then using equals() which I thought unlikely it >> makes no difference here. >> But it would be proof against that to use equals, unlikely to matter >> as it might be .. >> >> -phil. >> >> On 05/31/2016 03:19 PM, Jim Graham wrote: >>> >>> On 05/31/2016 02:50 PM, Phil Race wrote: >>>> On 05/31/2016 12:20 PM, Jim Graham wrote: >>>>> Hi Jay, >>>>> >>>>> You were going to remove hashCode/equals from CCM, but instead you >>>>> simply removed it from the patch. You still need to edit it to >>>>> remove the existing methods. >>>> Oh yeah ! CCM is gone from the latest webrev. I expect that was not >>>> intentional. >>>> >>>>> Also, I'm not sure == is a good way to compare ColorSpace instances >>>>> - Phil? >>>> Neither ColorSpace nor ICC_ColorSpace over-ride equals or hashCode >>>> and all the predefined ones are constructed as singletons so it >>>> seems unlikely to cause problems >>> Should it use .equals() on principle, though? Otherwise we are >>> baking in the assumption that it doesn't implement equals() into our >>> implementation of the CM.equals() method. Might it some day >>> implement equals (perhaps it isn't a practical issue today, but it >>> might be in the future when we forget that it was omitted in this >>> usage we create today). >>> >>> I guess what I'm asking is if it is a design feature that different >>> objects are considered non-equal (such as an object that, for >>> instance, has only predetermined instances that are shared by >>> reference and reused). I think color spaces are sort of in-between >>> in that we define a few constants that simply get used by reference >>> in 99% of cases, but that isn't a design feature, more like a >>> practical issue... >>> >>> ...jim From philip.race at oracle.com Wed Jun 1 16:58:54 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 01 Jun 2016 09:58:54 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8158408: Font2DTest demo needs to use FontPanel resolution matching the screen Message-ID: <574F144E.40606@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8158408 Webrev: http://cr.openjdk.java.net/~prr/8158408/ At 125% scaling on JDK 9 Font2DTest looks horrid since its BufferedImage is scaled to the screen. Fix is to not use a BufferedImage, just use the Swing back buffer. -phil. From alexey.ivanov at oracle.com Wed Jun 1 17:25:41 2016 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 1 Jun 2016 20:25:41 +0300 Subject: [OpenJDK 2D-Dev] [9] request for review: 8078382: Wrong glyph is displayed for a derived font In-Reply-To: References: <55A64031.3060205@oracle.com> <55A68982.9090906@oracle.com> <55A7ACBD.9040403@oracle.com> <55A7FA20.7000105@oracle.com> <55AFC5DA.1030408@oracle.com> <5718E59E.6060804@oracle.com> <574DBC27.80807@oracle.com> <574DFD01.2040307@oracle.com> Message-ID: Hi Phil, Sergey, Thank you for reviewing! I suggest pushing the current version of the fix: http://cr.openjdk.java.net/~bae/8078382/9/webrev.00/ It's Andrew's fix, and I'll push it under his name, giving him the credit. As for FontFamily.getClosestStyle(), I'll submit a new bug to investigate the behavior. We will update getClosestStyle() if necessary. Thanks, Alexey On 01.06.2016 13:21, Alexey Ivanov wrote: > Hi Phil, > > On 01.06.2016 0:07, Phil Race wrote: >> getClosestStyle() is something of a last resort. >> Historically I think it was called only when you >> had only a font *with* a style like bold and someone asked for >> plain/regular. >> ie for the subtractive case rather than the additive case. >> So it would not apply to the case in this bug. >> >> However OS X does not natively support synthetic styling so we may >> be entering that method for the additive case on OS X. >> >> So will not have this same bug since it just does not happen. >> >> In which case the reamaining question is, when you only have BOLD and >> ITALIC >> and someone asks for BOLDITALIC and you can't synthesise at all, >> which do you give them ? > > So it needs additional testing. However, I think GDI still returns > Bold in this case: this way it would look consistent. > >> >> I'd still lean towards ITALIC - assuming I have ITALIC, so we do not >> need to update that method. >> If it can be shown otherwise we can make the change. > > Do you think we should push the fix as is, and leave > FontFamily.getClosestStyle() as it is now? > > Then test how native systems behave and update this method if necessary. > > > Thanks, > Alexey > >> >> >> -phil. >> >> On 05/31/2016 09:43 AM, Sergey Bylokhov wrote: >>> On 31.05.16 19:30, Phil Race wrote: >>>>> The patch changes the order of font selection: bold will be used, if >>>>> possible, as the base for bold-italic instead of italic which is the >>>>> current default. It also fixes the issue where italic is returned >>>>> instead of bold. >>>> >>>> OK. +1 >>> >>> I am not sure but should FontFamily.getClosestStyle() be updated also?: >>> case Font.BOLD|Font.ITALIC: >>> if (italic != null) { >>> return italic; >>> } else if (bold != null) { >>> return bold; >>> } else { >>> return plain; >>> } >>> } >>> >>>> >>>> -phil. >>>> >>>>> >>>>> >>>>> Thank you in advance, >>>>> Alexey >>>>> >>>>> On 22.07.2015 19:33, Alexey Ivanov wrote: >>>>>> Hi Phil, >>>>>> >>>>>> On 16.07.2015 21:38, Phil Race wrote: >>>>>>> On 07/16/2015 06:08 AM, Andrew Brygin wrote: >>>>>>>> Hi Phil, >>>>>>>> >>>>>>>> another option to avoid the problem is to be a bit more specific >>>>>>>> regarding the >>>>>>>> required font when we obtaining lcd glyph from GDI. >>>>>>>> If we specify a particular name of the font which we used to >>>>>>>> construct the >>>>>>>> glyph vector, then we will get glyphs exactly for desired >>>>>>>> characters: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~bae/8078382/9/webrev.01/ >>>>>>>> >>>>>>>> This change affects only the case of lcd glyphs on windows, >>>>>>>> it reduces the scope of required testing. >>>>>>> >>>>>>> This is heading in the direction I was thinking of but since GDI is >>>>>>> excepting a face name >>>>>>> (what we call a family name), I am not sure if this will always >>>>>>> work >>>>>>> as is. >>>>>>> There are possible issues with using a localized name and the >>>>>>> length >>>>>>> of the full name exceeding what Windows allows here. >>>>>>> And there may be unintended consequences that are not immediately >>>>>>> obvious. >>>>>>> I would like to try limit this to the case where we can positively >>>>>>> identify that the >>>>>>> font is not the one we expected. And do it cheaply too. >>>>>>> I do not have a quick answer here but roughly the algorithm >>>>>>> might be >>>>>>> - specify family, check (somehow) if GDI selects the same base font >>>>>>> - if not, try the facename approach (if the name fits). Did we >>>>>>> succeed and get the same base font ? >>>>>>> - if not, bail on GDI for this case and do the rasterisation >>>>>>> ourselves. >>>>>>> >>>>>>> "cheaply" might depend on caching a success value on the first >>>>>>> attempt, so >>>>>>> that we only do it once, ever, for a font. Then the problem becomes >>>>>>> how to >>>>>>> do the verification. One approach might be to call GetFontData() >>>>>>> which >>>>>>> will give us some chunk of the font file and we can see if the name >>>>>>> (or something >>>>>>> else we can quickly and reliably parse) is exactly that we >>>>>>> expect .. >>>>>> >>>>>> It looks there's no easy way to detect whether GDI selected the same >>>>>> base font or not. GetTextFace function doesn't help it: it always >>>>>> returns the face name passed in LOGFONT except in the cases where >>>>>> there's no such font. >>>>>> >>>>>> I haven't found any other API which could tell us what font GDI >>>>>> selected. So the only alternative is to use GetFontData and parse >>>>>> the >>>>>> font file itself. Yet I can't find any example how to use this >>>>>> function. I'll keep searching in that direction. >>>>>> >>>>>> >>>>>> Regards, >>>>>> Alexey >>>>>> >>>>>>> >>>>>>> Leaving aside the 'wrong glyph' case, I have to suppose it is >>>>>>> possible that >>>>>>> there are other un-noticed cases where we use a different base font >>>>>>> than >>>>>>> that selected by GDI. The algorithms are not defined anywhere I can >>>>>>> locate. >>>>>>> >>>>>>>> >>>>>>>> However, there seems to be a copy&paste error in FontFamily.java: >>>>>>>> on lines 340 - 341 we check that bold font fits our needs but use >>>>>>>> italic >>>>>>>> anyway. Was it done by purpose, or this is really an error? >>>>>>> >>>>>>> That is a copy/paste mistake. It should be fixed. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Andrew >>>>>>>> >>>>>>>> On 7/15/2015 7:25 PM, Phil Race wrote: >>>>>>>>> This probably needs more examination and perhaps a more >>>>>>>>> complex fix. >>>>>>>>> The observation that GDI bases bold-italic on the bold version >>>>>>>>> not >>>>>>>>> the >>>>>>>>> italic version is an implementation choice just as we had done >>>>>>>>> the >>>>>>>>> opposite. It is possible some other time it does the opposite >>>>>>>>> or some >>>>>>>>> other platform does the opposite. I have supposed it is harder to >>>>>>>>> synthesise italic than to do 'over-strike'. And this GDI usage >>>>>>>>> applies only to LCD glyphs. >>>>>>>>> >>>>>>>>> Maybe what we need to do is see if we can detect the cases when >>>>>>>>> GDI and JDK disagree on the actual font and remap the glyph id. >>>>>>>>> >>>>>>>>> -phil. >>>>>>>>> >>>>>>>>> On 7/15/15 4:12 AM, Andrew Brygin wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> could you please review a fix for 8078382? >>>>>>>>>> >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8078382 >>>>>>>>>> webrev: http://cr.openjdk.java.net/~bae/8078382/9/webrev.00/ >>>>>>>>>> >>>>>>>>>> The problem is caused by following peculiarity of the Code New >>>>>>>>>> Roman font: this font provides plain, italic and bold variants. >>>>>>>>>> In bold and italic variants of the font, different glyphs >>>>>>>>>> correspond to the apostrophe character (0039): >>>>>>>>>> bold: 0039 -> 0x250 (592) >>>>>>>>>> italic: 0039 -> 0x256 (598) >>>>>>>>>> >>>>>>>>>> So, we translate character to glyphs using italic variant >>>>>>>>>> of the font, and then request glyph images from GDI. >>>>>>>>>> However, GDI uses the bold variant of the font in order >>>>>>>>>> to compose glyph images for artificial bold-italic variant, >>>>>>>>>> and we have got a glyph image for ? instead of apostrophe. >>>>>>>>>> >>>>>>>>>> Suggested fix is to select bold variant (if possible) as a >>>>>>>>>> base for artificial bold-italic. >>>>>>>>>> >>>>>>>>>> There is no regression test because it requires a specific font >>>>>>>>>> to be installed on a test system. The font can be found here: >>>>>>>>>> http://www.dafont.com/code-new-roman.font >>>>>>>>>> >>>>>>>>>> Please take a look. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Andrew >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> >> > From semyon.sadetsky at oracle.com Wed Jun 1 18:05:37 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 1 Jun 2016 21:05:37 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8158408: Font2DTest demo needs to use FontPanel resolution matching the screen In-Reply-To: <574F144E.40606@oracle.com> References: <574F144E.40606@oracle.com> Message-ID: you call super.paintComponent(g); twice in lines 956 and 964. Is it expected behavior? --Semyon On 6/1/2016 7:58 PM, Philip Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8158408 > Webrev: http://cr.openjdk.java.net/~prr/8158408/ > > At 125% scaling on JDK 9 Font2DTest looks horrid since its > BufferedImage is scaled to the screen. > Fix is to not use a BufferedImage, just use the Swing back buffer. > > -phil. From philip.race at oracle.com Wed Jun 1 18:44:31 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 01 Jun 2016 11:44:31 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8158408: Font2DTest demo needs to use FontPanel resolution matching the screen In-Reply-To: References: <574F144E.40606@oracle.com> Message-ID: <574F2D0F.9020404@oracle.com> On 06/01/2016 11:05 AM, Semyon Sadetsky wrote: > you call super.paintComponent(g); twice in lines 956 and 964. Is it > expected behavior? Yes, if "CannotDrawException" is caught we want to repaint using super else, we will may have a partially panel. -phil. > > --Semyon > > > On 6/1/2016 7:58 PM, Philip Race wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8158408 >> Webrev: http://cr.openjdk.java.net/~prr/8158408/ >> >> At 125% scaling on JDK 9 Font2DTest looks horrid since its >> BufferedImage is scaled to the screen. >> Fix is to not use a BufferedImage, just use the Swing back buffer. >> >> -phil. > From philip.race at oracle.com Wed Jun 1 18:51:34 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 01 Jun 2016 11:51:34 -0700 Subject: [OpenJDK 2D-Dev] Fix for JDK-8139192 : Custom ImageFilters return blank images in Java 8(.45) while working in 7 In-Reply-To: <544e09c0-79d9-4606-973e-d03259b68362@default> References: <480a1ef0-30e5-e1ed-8def-e28f383949ac@oracle.com> <958c83a7-1a72-a5cf-0b3b-8479efee5974@oracle.com> <6d79d18b-3854-402c-9981-38ed2e0f161a@default> <2d10a7cc-51e5-50dc-1a66-33f94679e067@oracle.com> <4f6cae95-0552-4507-942a-e0f2e9beb3be@default> <574DCB17.3070306@oracle.com> <574DE61F.30607@oracle.com> <74c0b159-895e-c6c4-67ae-e470d7055251@oracle.com> <544e09c0-79d9-4606-973e-d03259b68362@default> Message-ID: <574F2EB6.9000405@oracle.com> +1 from me .. -phil On 06/01/2016 03:28 AM, Ajit Ghaisas wrote: > Thanks Jim and Phil for valuable feedback and suggestions. > > The detailed discussion helped me to understand why catching RuntimeException is a better option for a call to imageComplete(STATICIMAGEDONE). > I have modified the code on line 192 accordingly. > > I have not modified the code catching NullPointerException (on line 196) as doing so would mask a wider variety of legitimate exceptions. So, line 196 remains unchanged. > > I have also modified the test to throw NullPointerException instead of calling intValue() on a null. > > Please review updated webrev : > http://cr.openjdk.java.net/~aghaisas/8139192/webrev.03/ > > Regards, > Ajit > > -----Original Message----- > From: Phil Race > Sent: Wednesday, June 01, 2016 1:41 AM > To: Jim Graham; Ajit Ghaisas > Cc: Sergey Bylokhov; 2d-dev > Subject: Re: [OpenJDK 2D-Dev] Fix for JDK-8139192 : Custom ImageFilters return blank images in Java 8(.45) while working in 7 > > I agree with the suggestion of RuntimeException as likely sufficient but not too much ... > > -phil. > > > On 5/31/2016 12:29 PM, Jim Graham wrote: >> I agree with this. It would be nice if we didn't spit out print >> statements by default, but I'm not sure what a good flag would be to >> use to diagnose this that balances how likely developers will think to >> use it. >> >> The point about catching a wider variety of exceptions is not that it >> is good practice in general, but we've added a new call to a >> long-standing algorithm which has decades (really? plural? pretty >> much, I think) of past code that isn't expecting the new call, and >> that call is basically "informative" not something that they really >> need to successfully handle, so just as someone might accidentally >> process a null pointer in a case like that, someone else might run off >> the end of an array (AIOOB) or any other "I wasn't expecting that" >> sort of issue. >> >> Throwable might be a bit much, though. Phil? I was thinking >> Exception because those tend to focus on "your code made a mistake" >> whereas Error is something like "you are mix/matching incompatible >> code that was compiled to contain conflicting information" (kind of >> like calling a method that doesn't exist in this release, etc.). It's >> hard to say what the proper level of forgiveness should be here. >> Another thought is "RuntimeException", since any other exception would >> need to be declared to be thrown and we don't declare it for that >> method, so their implementation shouldn't be allowed to declare it >> either... >> >> ...jim >> >> On 05/31/2016 10:34 AM, Phil Race wrote: >>> Based on what Ajit wrote in the bug report, he at least found a jar >>> file that contains this code, but I have so far failed to locate the >>> source code as all the versions I find on the net use the Java 2D >>> JDK 1.2 BufferedImageOp APIs so I suspect this bug is in a very old >>> version and it may not be open source. >>> Therefore I am not sure how much e.printStackTrace() will help them >>> if they don't own that source except to encourage them to upgrade. >>> I'd be inclined to stick it behind a debugging property if we have >>> one that we could re-use except that in such a case they probably >>> won't know enough to set the property. >>> So on balance it is probably best to do as it has been presented here >>> except that catch (Throwable t) probably makes sense as we don't want >>> to revisit this for a different exception. >>> >>> Minor nit about the test: instead of calling intValue() on a null >>> Integer, why not just "throw new NullPointerException("reason ..") ? >>> >>> >>> -phil. >>> >>> >>> >>> >>> >>> On 05/30/2016 01:22 AM, Ajit Ghaisas wrote: >>>> I did contemplate catching 'Exception' instead of >>>> 'NullPointerException' while raising the webrev, but decided not to do >>>> it as- >>>> 1. Complaint in current image filter was due to NPE only >>>> 2. Catching & consuming generic exception does not seem quite correct >>>> here as we are just printing stack trace and not taking any concrete >>>> action. >>>> 3. There is no reported issue of any other type of Exception out of >>>> this method. >>>> >>>> Regards, >>>> Ajit >>>> >>>> >>>> -----Original Message----- >>>> From: Jim Graham >>>> Sent: Saturday, May 28, 2016 4:41 AM >>>> To: Ajit Ghaisas; Sergey Bylokhov; 2d-dev; Philip Race >>>> Subject: Re: [OpenJDK 2D-Dev] Fix for JDK-8139192 : Custom >>>> ImageFilters return blank images in Java 8(.45) while working in 7 >>>> >>>> That looks good, but I wonder if it should catch all exceptions >>>> instead of just NPE. Historically we were only catching NPE before we >>>> added the call to STATICIMAGEDONE, and the current filter in question >>>> turns out to throw an NPE, but if a filter that was commonly used with >>>> offscreen images was not expecting the STATICIMAGEDONE as was this >>>> WaterFilter, then they could potentially throw a wider variety of >>>> exceptions. >>>> >>>> I'm good with NPE since that is the only case we've seen, but I'd also >>>> be good with changing line 192 to catch all exceptions. Phil? >>>> >>>> ...jim >>>> >>>> On 5/27/16 1:32 AM, Ajit Ghaisas wrote: >>>>> Hi Jim, >>>>> >>>>> Thanks for in-depth analysis and detailed review. >>>>> I appreciate your concern for filtered image being blank in Java >>>>> 8, while it used to work in Java 7. >>>>> >>>>> Yes. I totally agree with your suggestion to do both - >>>>> 1. Not send IMAGEERROR if there is exception from ImageFilter >>>>> while processing STATICIMAGE done >>>>> 2. At the same time, as we are consuming the exception, show the >>>>> exception stacktrace. >>>>> >>>>> With this fix the functionality of com.jhlabs.image.WaterFilter >>>>> is restored. It does not return blank images anymore. >>>>> Also, as additional information, exception details are shown as >>>>> a stacktrace. >>>>> >>>>> Please review the updated webrev : >>>>> http://cr.openjdk.java.net/~aghaisas/8139192/webrev.02/ >>>>> >>>>> Regards, >>>>> Ajit >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Jim Graham >>>>> Sent: Thursday, May 26, 2016 4:57 AM >>>>> To: Sergey Bylokhov; Ajit Ghaisas; 2d-dev; Philip Race >>>>> Subject: Re: [OpenJDK 2D-Dev] Fix for JDK-8139192 : Custom >>>>> ImageFilters return blank images in Java 8(.45) while working in 7 >>>>> >>>>> Their complaint is that the resulting image is empty - most likely >>>>> because the error gets passed through and clears the image buffer. >>>>> It appears that the sequence of events is: >>>>> >>>>> We send SINGLEFRAMEDONE. >>>>> - the image is displayable >>>>> We send STATICIMAGEDONE. >>>>> - filter throws NPE >>>>> - image is probably still displayable >>>>> We send ERROR >>>>> - if it gets passed through to the toolkit image consumer then we'll >>>>> clear the image buffer >>>>> - image is no longer displayable >>>>> >>>>> It's hard to say for sure without having an instance of their filter >>>>> in-house for testing, but previously we weren't sending the >>>>> STATICDONE notice and the program was working just fine. Since the >>>>> NPE comes from their code when we send it, it shouldn't have affected >>>>> any down-stream consumers, so we should be OK with just continuing on >>>>> and the image should still be displayable just as if we hadn't sent >>>>> the STATICDONE notice in the first place. >>>>> >>>>> Now, *during debugging*, they were thwarted by the fact that we ate >>>>> the exception, true, but the original issue is that the image wasn't >>>>> displayable at all. We might want to do both: >>>>> >>>>> - not send ERROR for STATICDONE when we used to not send STATICDONE at >>>>> all >>>>> - show the exception so that someone realizes that there is a >>>>> problem, even though we've made it not hurt their functionality. >>>>> >>>>> Does that make sense? >>>>> >>>>> ...jim >>>>> >>>>> On 5/25/2016 1:36 PM, Sergey Bylokhov wrote: >>>>>> On 25.05.16 23:33, Jim Graham wrote: >>>>>>> How about option 3 - >>>>>>> >>>>>>> NPE before imageComplete sends an ERROR as it does now. >>>>>>> >>>>>>> NPE during imageComplete is ignored, both for backwards >>>>>>> compatibility and because it is more of a "hint" than an operation >>>>>>> that requires action from the consumer. >>>>>> I guess the case is that when we ignore this NPE(w/o any >>>>>> notification) the users complains that the bug is in jdk. >>>>>> >>>>>>> ...jim >>>>>>> >>>>>>> On 5/25/2016 1:31 AM, Ajit Ghaisas wrote: >>>>>>>> Hi >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Bug : >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8139192 >>>>>>>> >>>>>>>> Custom ImageFilters return blank images in Java 8(.45) while >>>>>>>> working in 7 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Root cause : >>>>>>>> >>>>>>>> private method produce() in OffScreenImageSource.java consumes a >>>>>>>> NullPointerException that originates from a custom ImageConsumer (a >>>>>>>> 3^rd party image library class - com.jhlabs.image.WaterFilter) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Analysis: >>>>>>>> >>>>>>>> 1. How the behavior changed between JDK7 and JK8 : >>>>>>>> >>>>>>>> A call to imageComplete(ImageConsumer.SINGLEFRAMEDONE) was added in >>>>>>>> addition to imageComplete(ImageConsumer. STATICIMAGEDONE) as a fix >>>>>>>> for JDK-7143612. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2. What debugging revealed: >>>>>>>> >>>>>>>> A NullPointerException is being thrown from the library during the >>>>>>>> call to imageComplete(ImageConsumer.STATICIMAGEDONE) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 3. It looks like the fix of JDK-7143612 is valid and successive >>>>>>>> calls to >>>>>>>> imageComplete() are allowed. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 4. The 3rd party library behavior appears incorrect (if it can not >>>>>>>> handle subsequent calls to imageComplete(), it should de-register >>>>>>>> itself). >>>>>>>> >>>>>>>> The 3rd-party library code should be fixed. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Possible modifications in JDK : >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Currently, OffScreenImageSource::produce() consumes the >>>>>>>> NullPointerException - this is incorrect and results in silent >>>>>>>> failure of this particular image filter. >>>>>>>> >>>>>>>> We need to let the image filter library know that exception has >>>>>>>> occurred in its code and not in JDK. We have two options - >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Option 1 : Rethrow the NullPointerException --- It is the >>>>>>>> clearest way >>>>>>>> to let 3^rd party library know that their code is erroneous with >>>>>>>> latest JDK. This will change the 3^rd party image filter behavior >>>>>>>> that generates blank image. >>>>>>>> >>>>>>>> Option 2 : Add a stack trace where the exception is being consumed >>>>>>>> --- Adding stack trace provides more information regarding failure >>>>>>>> of 3^rd party image filter with retaining the current behavior that >>>>>>>> generates blank image. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I have implemented both the options: >>>>>>>> >>>>>>>> Option 1: http://cr.openjdk.java.net/~aghaisas/8139192/webrev.00/ >>>>>>>> >>>>>>>> Option 2: http://cr.openjdk.java.net/~aghaisas/8139192/webrev.01/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Request you to review both the webrevs and provide your preference. >>>>>>>> >>>>>>>> I will add a test to the selected webrev. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Ajit >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> From semyon.sadetsky at oracle.com Wed Jun 1 19:06:14 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 1 Jun 2016 22:06:14 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8158408: Font2DTest demo needs to use FontPanel resolution matching the screen In-Reply-To: <574F2D0F.9020404@oracle.com> References: <574F144E.40606@oracle.com> <574F2D0F.9020404@oracle.com> Message-ID: <0b8a5c2e-f04b-67bf-349a-3367c670ba97@oracle.com> Looks good to me. --Semyon On 6/1/2016 9:44 PM, Phil Race wrote: > On 06/01/2016 11:05 AM, Semyon Sadetsky wrote: >> you call super.paintComponent(g); twice in lines 956 and 964. Is it >> expected behavior? > > Yes, if "CannotDrawException" is caught we want to repaint using super > else, we will > may have a partially panel. > > -phil. > >> >> --Semyon >> >> >> On 6/1/2016 7:58 PM, Philip Race wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8158408 >>> Webrev: http://cr.openjdk.java.net/~prr/8158408/ >>> >>> At 125% scaling on JDK 9 Font2DTest looks horrid since its >>> BufferedImage is scaled to the screen. >>> Fix is to not use a BufferedImage, just use the Swing back buffer. >>> >>> -phil. >> > From james.graham at oracle.com Wed Jun 1 20:37:32 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 1 Jun 2016 13:37:32 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : Exception getting thumbnail size for JPEG with embedded thumbnail In-Reply-To: <4cedc972-c8c2-42ed-80cf-e0fb276fc26d@default> References: <4cedc972-c8c2-42ed-80cf-e0fb276fc26d@default> Message-ID: <81493db0-3791-5877-e776-d906985e6704@oracle.com> I'm a little disturbed that we are just doing a basic "look for these byte value" type of search rather than parsing the file until we find an SOI. Are there cases where we are skipping arbitrary untagged data, or was this just lazy programming in the first place. Everything in a JPEG file should be tagged and the size of any arbitrary data should be known or included in the file so that we should basically be looking at the next 2 bytes, determining what kind of data follows, skipping that data, and then looking at the next tag and no amount of "we don't know what that byte was, so we'll just look at the next byte" should ever be occuring. Am I missing something about the practical nature of the JPEG file that requires a brute force search? ...jim On 6/1/16 12:18 AM, Jayathirth D V wrote: > Hi, > > > > _Please review the following fix in JDK9:_ > > _ _ > > Bug : https://bugs.openjdk.java.net/browse/JDK-8152672 > > > > Webrev : http://cr.openjdk.java.net/~jdv/8152672/webrev.00/ > > > > Issue : When we are trying to get properties related to second image in JPEG file we are getting IIOException mentioning > that it is not a JPEG file. > > > > Root cause : When we are skipping first image to reach second image header, we are just trying to find next available > EOI marker. But if first image has embedded thumbnail in APP1 marker, we will reach to EOI of this thumbnail and not EOI > of first image. So after we reach EOI of embedded thumbnail we try to access second image SOI marker which will fail. > > Solution : We have to change the logic of how we skip to consecutive images in JPEG file. We know that application > markers, comments or other markers can contain data same as SOI & EOI. Instead of just checking for EOI marker serially, > we should read length of these markers and skip them. > > > > Thanks, > > Jay > > > From james.graham at oracle.com Wed Jun 1 21:19:14 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 1 Jun 2016 14:19:14 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6842011: StackOverflowError printing landscape with scale and transform In-Reply-To: <1cb02649-3738-73e8-9452-68fd9e427131@oracle.com> References: <5739A1D8.90703@oracle.com> <4ac584a5-b1a6-a707-bd80-3d7717901c46@oracle.com> <0bfb90de-f26b-45f9-6e08-ae1d1818ffcb@oracle.com> <811d7b2a-4cf6-90d3-254e-f54e05a88837@oracle.com> <57438156.2000007@oracle.com> <994ea332-c40f-e97c-8780-4015193946c2@oracle.com> <57438AED.9070009@oracle.com> <5745D569.4090709@oracle.com> <66c5075a-d5f1-fd38-c230-1b61a9c26778@oracle.com> <574DCD00.9010005@oracle.com> <1cb02649-3738-73e8-9452-68fd9e427131@oracle.com> Message-ID: <9c031c7c-3f7a-bca0-4d4b-4457e354e3e9@oracle.com> Looks good. +1 ...jim On 6/1/16 12:03 AM, prasanta sadhukhan wrote: > HI Phil, Jim, > > I have modified webrev to address Jim's doc change. Please review > http://cr.openjdk.java.net/~psadhukhan/6842011/webrev.02/ > > I will send the ccc link separately to you for approval. > > On 5/31/2016 11:12 PM, Phil Race wrote: >> On 05/26/2016 03:49 AM, prasanta sadhukhan wrote: >>> >>> Hi Phil, >>> >>> >>> On 5/25/2016 10:10 PM, Philip Race wrote: >>>> I am OK with committing the clarifying javadoc as part of this fix >>>> and filing a new RFE for the new method - to be fixed at some later date. >>>> >>>> However before this fix can be committed you need to make sure >>>> we have consistent behaviour across platforms and we do not have that yet >>> In mac, unlike RasterPrinterJob which does the transform using the following code >>> / pathGraphics.transform(scaleTransform);// >>> // // user (0,0) should be origin of page, not imageable area// >>> // pathGraphics.translate(-getPhysicalPrintableX(paper) / xScale,// >>> // -getPhysicalPrintableY(paper) / yScale);// >>> // pathGraphics.transform(new AffineTransform(page.getMatrix()));// >>> /CPrinterJob does not do this transforms, it straightway goes to native printloop code >>> so when scalex = g2d.getTransform().getScaleX(); is called the transform returned is identity transform (as was the >>> case in linux too before the above transform code is executed) >> >> I am not sure I know what you mean by that part in parentheses. > What I meant was SunGraphics2D.transform was an identity transform in linux and osx to begin with, but in linux > RasterPrinterJob calls the above code snippet which modifies SunGraphics2D.transfrom from identity transform to > [m00=0, m01=4.16, m02=0][m10=-4.16, m11=0, m12=3507.873] but it remains as identity transform in osx. >> Our printing pipelines have always reflected the device transform. >> >> If in fact OS X printing does not do that, then this is a bigger inconsistency .. >> But not one we will try to address today, nor in JDK 9.. >> Verify that is the case and then file a P4 bug on that too in order to track it. >> > RasterPrinterJob#print() calls printPage() which does this device transformation but in osx CPrinterJob#print calls > printloop() in osx native which does not do this. I have created JDK-8158339 to address this. > > Regards > Prasanta >> And this fix is then approved .. >> >> -phil. >> >> >>> so getScaleX/Y returns 1 as m00,m11=1 . >>> So, since the transform is not invalid unlike linux, mac prints ok. >>> >>> Regards >>> Prasanta >>>> >>>> -phil. >>>> >>>> On 5/23/16, 3:57 PM, Phil Race wrote: >>>>> On 05/23/2016 03:33 PM, Jim Graham wrote: >>>>>> Though, they are likely to think this API is doing that. We have a visibility problem here to make sure that any >>>>>> work going forward is more likely to see the new method and ignore this one. I don't think we'll win there on >>>>>> naming alone, but we can make the javadocs look very intimidating so if they are using completion they may get >>>>>> scared and hopefully see the other method before they just accept the completion. Perhaps we can try to make the >>>>>> alphabetic sorting have the new methods appear first in the list? >>>>> >>>>> getScaleFactorX() should sort ahead of getScaleX() >>>>> >>>>> -phil. >>>>> >>>>>> >>>>>> In FX we were smart and went with very dry "getMxy()" style names that won't attract attention... >>>>>> >>>>>> ...jim >>>>>> >>>>>> On 5/23/2016 3:16 PM, Phil Race wrote: >>>>>>> What we have here might happen when developer A writes some UI code >>>>>>> without any conception that a 90 degree rotation may be in effect and >>>>>>> then developer B >>>>>>> comes along and adds printing support .. and the implementation rotates it. >>>>>>> So an out-of-the-box advertised API that does what dev A really meant >>>>>>> would be helpful. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 05/23/2016 11:52 AM, Jim Graham wrote: >>>>>>>> I think we need to go a bit further and change the way we describe >>>>>>>> them. If we perhaps get very technical about how it is returning one >>>>>>>> element of the scaling equations/matrix then they will be discouraged >>>>>>>> from finding a simple use for it. I'll try to come up with some >>>>>>>> wording today or tomorrow and it would be good to apply it to all 6 of >>>>>>>> the getters uniformly. Something like: >>>>>>>> >>>>>>>> Returns element M## of the transformation matrix which controls how >>>>>>>> the output XY coordinates are affected by the input XY coordinates. >>>>>>>> >>>>>>>> Then on the getScaleXY methods add a "Note, this method will not >>>>>>>> return the amount by which input XY coordinates will be stretched or >>>>>>>> contracted since a 90 degree rotation will cause all of its >>>>>>>> contribution to be redirected into the other axis. Properly >>>>>>>> determining the full scale of the matrix involves analyzing both this >>>>>>>> factor and the ...". >>>>>>>> >>>>>>>> There is where it would be good to have the new methods ready to go so >>>>>>>> we can then immediately say ", such as in the getScalingFactorXY() >>>>>>>> method" or have an @see to send them where they need to go. That >>>>>>>> doesn't mean we can't do this documentation refresh now, but we might >>>>>>>> want to make those new methods a high priority to get done soon. (I'm >>>>>>>> guessing/hoping we can add small "fixup" APIs like that after FC since >>>>>>>> it doesn't really represent a "feature"...?) >>>>>>>> >>>>>>>> ...jim >>>>>>>> >>>>>>>> On 5/22/16 11:53 PM, prasanta sadhukhan wrote: >>>>>>>>> Hi Jim, >>>>>>>>> >>>>>>>>> >>>>>>>>> On 5/21/2016 3:20 AM, Jim Graham wrote: >>>>>>>>>> We should acknowledge that the test case is buggy anyway. It is not >>>>>>>>>> computing the scale of a transform correctly, >>>>>>>>>> though that is likely due to the unfortunate naming we chose for our >>>>>>>>>> methods. >>>>>>>>>> >>>>>>>>>> If you are looking for "the amount by which an X coordinate is >>>>>>>>>> stretched or contracted", you have to compute a >>>>>>>>>> distance formula on all of the elements of the X transform >>>>>>>>>> equation. We don't have a method to do that for the >>>>>>>>>> caller. If we did, we might call it something very similar to >>>>>>>>>> "getScaleX()". >>>>>>>>>> >>>>>>>>>> Unfortunately, we have a method named "getScaleX()" which one might >>>>>>>>>> think does that, but it doesn't. >>>>>>>>>> >>>>>>>>>> While I think we should prevent a stack overflow here, it's really >>>>>>>>>> more of "making sure a program bug is caught early >>>>>>>>>> and with a more sane response", than "fixing a valid test case". >>>>>>>>>> >>>>>>>>>> Also, we should consider adding a method to do the right >>>>>>>>>> calculation, and document the existing getScaleX() to point >>>>>>>>>> out that it cannot be used to determine "the stretchiness of X >>>>>>>>>> coordinates" or something more appropriately worded... >>>>>>>>>> >>>>>>>>> I have documented the anomalies in getScaleX()/getScaley(). >>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/6842011/webrev.01/ >>>>>>>>> I will create a bug to address this scaling calculation of a >>>>>>>>> transform in affinetransform (as it is in geom package and >>>>>>>>> not a printing issue par se). Will that be ok? >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Prasanta >>>>>>>>>> ...jim >>>>>>>>>> >>>>>>>>>> On 5/20/16 4:27 AM, prasanta sadhukhan wrote: >>>>>>>>>>> Hi Phil, >>>>>>>>>>> >>>>>>>>>>> When we call print() it calls RasterPrinterJob#printPage() which >>>>>>>>>>> sets peekGraphics.transform([4.16,0,0][0,4.16,0]) as >>>>>>>>>>> obtained from xscale=4.16 [getXRes()=300 / 72.0] ,yscale=4.16 >>>>>>>>>>> It calls SunGraphics2D.transform which was identity transform [1.0, >>>>>>>>>>> 0.0, 0.0] [0.0, 1.0, 0.0] calls >>>>>>>>>>> transform.concatenate(peekgraphicsTx) and stores as >>>>>>>>>>> ([4.16,0,0][0,4.16,0]) >>>>>>>>>>> >>>>>>>>>>> Then RasterPrinterJob#printPage() again calls >>>>>>>>>>> peekGraphics.transform(new AffineTransform(page.getMatrix())); >>>>>>>>>>> where page.getMatrix() returns 0.0, -1.0, 1.0, 0.0, 0.0, 841.88 and >>>>>>>>>>> peekGraphics transform now becomes [0.0, 1.0, 0.0] >>>>>>>>>>> [-1.0, 0.0, 841.88] >>>>>>>>>>> which calls SunGraphics2D#transform() where it again does >>>>>>>>>>> transform.concatenate(peekgraphicsTx) >>>>>>>>>>> >>>>>>>>>>> so the transform becomes [m00=0, m01=4.16, m02=0][m10=-4.16, m11=0, >>>>>>>>>>> m12=3507.873] >>>>>>>>>>> Now scaleX obtains value from g2d.getTransform().getScaleX() which >>>>>>>>>>> returns SunGraphics2D stored transform.m00 which is 0 >>>>>>>>>>> and scaleY is m11=0 so scaleX,scaleY becomes 0. >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> Prasanta >>>>>>>>>>> On 5/19/2016 4:03 AM, Phil Race wrote: >>>>>>>>>>>> It sounds like scalex & scaley are 0 and are then used in >>>>>>>>>>>> calculations which >>>>>>>>>>>> results in the NaN ? So why are they zero to begin with ? >>>>>>>>>>>> >>>>>>>>>>>> -phil. >>>>>>>>>>>> >>>>>>>>>>>> On 5/16/2016 3:32 AM, prasanta sadhukhan wrote: >>>>>>>>>>>>> Hi All, >>>>>>>>>>>>> >>>>>>>>>>>>> Please review a fix for jdk9 whereby it is seen that >>>>>>>>>>>>> A StackOverflowError occurs when printing in landscape >>>>>>>>>>>>> orientation with a scaled and transformed graphics object. >>>>>>>>>>>>> at sun.print.PSPrinterJob.prepDrawing(PSPrinterJob.java:1610) >>>>>>>>>>>>> at sun.print.PSPrinterJob.beginPath(PSPrinterJob.java:1319) >>>>>>>>>>>>> at >>>>>>>>>>>>> sun.print.PSPrinterJob.convertToPSPath(PSPrinterJob.java:1793) >>>>>>>>>>>>> at >>>>>>>>>>>>> sun.print.PSPrinterJob$GState.emitPSClip(PSPrinterJob.java:1718) >>>>>>>>>>>>> at sun.print.PSPrinterJob.prepDrawing(PSPrinterJob.java:1625) >>>>>>>>>>>>> >>>>>>>>>>>>> at sun.print.PSPrinterJob.beginPath(PSPrinterJob.java:1319) >>>>>>>>>>>>> at >>>>>>>>>>>>> sun.print.PSPrinterJob.convertToPSPath(PSPrinterJob.java:1793) >>>>>>>>>>>>> at >>>>>>>>>>>>> sun.print.PSPrinterJob$GState.emitPSClip(PSPrinterJob.java:1718) >>>>>>>>>>>>> at sun.print.PSPrinterJob.prepDrawing(PSPrinterJob.java:1625) >>>>>>>>>>>>> >>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6842011 >>>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6842011/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> StackOverflowError is occuring because the scalex, scaley for >>>>>>>>>>>>> landscape orientation was 0 so when the testcase tries >>>>>>>>>>>>> to scale with these scale factors >>>>>>>>>>>>> using g2d.scale( 1 / scalex, 1 / scaley ); >>>>>>>>>>>>> it creates a AffineTransform of NaN transformation. Now, In >>>>>>>>>>>>> linux, when the PS print drawing information is being >>>>>>>>>>>>> prepared, it calls prepDrawing() where it checks >>>>>>>>>>>>> getGState().mTransform.equals(mLastTransform) and since NaN >>>>>>>>>>>>> values cannot be compared it results in "false", causing >>>>>>>>>>>>> erroneous "grestore" postscript command to be issued and remove a >>>>>>>>>>>>> GState from the stack so isOuterGState() becomes >>>>>>>>>>>>> true which causes emitPSClip() to be called which calls >>>>>>>>>>>>> prepDrawing() again via convertToPSPath() , beginPath() and since >>>>>>>>>>>>> isOuterState() returns true due to transform not >>>>>>>>>>>>> being equal it again calls emitPSClip() causing a recursion. >>>>>>>>>>>>> >>>>>>>>>>>>> The fix was to check if transform is NaN and do not fill the >>>>>>>>>>>>> devicePath if it is so, so that erroeous drawing is not >>>>>>>>>>>>> done. >>>>>>>>>>>>> So, it will print out a blank page. >>>>>>>>>>>>> >>>>>>>>>>>>> In windows, the testcase prints out a blank page. In mac, the >>>>>>>>>>>>> testcase prints a 2x2 rectangle. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards >>>>>>>>>>>>> Prasanta >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> >> > From james.graham at oracle.com Wed Jun 1 21:23:50 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 1 Jun 2016 14:23:50 -0700 Subject: [OpenJDK 2D-Dev] Fix for JDK-8139192 : Custom ImageFilters return blank images in Java 8(.45) while working in 7 In-Reply-To: <544e09c0-79d9-4606-973e-d03259b68362@default> References: <480a1ef0-30e5-e1ed-8def-e28f383949ac@oracle.com> <958c83a7-1a72-a5cf-0b3b-8479efee5974@oracle.com> <6d79d18b-3854-402c-9981-38ed2e0f161a@default> <2d10a7cc-51e5-50dc-1a66-33f94679e067@oracle.com> <4f6cae95-0552-4507-942a-e0f2e9beb3be@default> <574DCB17.3070306@oracle.com> <574DE61F.30607@oracle.com> <74c0b159-895e-c6c4-67ae-e470d7055251@oracle.com> <544e09c0-79d9-4606-973e-d03259b68362@default> Message-ID: <0849286c-0b7e-964e-85ef-41de34e5a60a@oracle.com> +1. If you wanted to add a comment on the new catch, you could say: } catch (RuntimeException e) { // We did not previously call this method here and some filters // were not prepared for it to be called at this time so we // allow them to have runtime issues for this one call only // without triggering the ERROR condition below. ... (printstack) } Your call, I don't need to approve a webrev for that comment addition... ...jim On 6/1/16 3:28 AM, Ajit Ghaisas wrote: > Thanks Jim and Phil for valuable feedback and suggestions. > > The detailed discussion helped me to understand why catching RuntimeException is a better option for a call to imageComplete(STATICIMAGEDONE). > I have modified the code on line 192 accordingly. > > I have not modified the code catching NullPointerException (on line 196) as doing so would mask a wider variety of legitimate exceptions. So, line 196 remains unchanged. > > I have also modified the test to throw NullPointerException instead of calling intValue() on a null. > > Please review updated webrev : > http://cr.openjdk.java.net/~aghaisas/8139192/webrev.03/ > > Regards, > Ajit > > -----Original Message----- > From: Phil Race > Sent: Wednesday, June 01, 2016 1:41 AM > To: Jim Graham; Ajit Ghaisas > Cc: Sergey Bylokhov; 2d-dev > Subject: Re: [OpenJDK 2D-Dev] Fix for JDK-8139192 : Custom ImageFilters return blank images in Java 8(.45) while working in 7 > > I agree with the suggestion of RuntimeException as likely sufficient but not too much ... > > -phil. > > > On 5/31/2016 12:29 PM, Jim Graham wrote: >> I agree with this. It would be nice if we didn't spit out print >> statements by default, but I'm not sure what a good flag would be to >> use to diagnose this that balances how likely developers will think to >> use it. >> >> The point about catching a wider variety of exceptions is not that it >> is good practice in general, but we've added a new call to a >> long-standing algorithm which has decades (really? plural? pretty >> much, I think) of past code that isn't expecting the new call, and >> that call is basically "informative" not something that they really >> need to successfully handle, so just as someone might accidentally >> process a null pointer in a case like that, someone else might run off >> the end of an array (AIOOB) or any other "I wasn't expecting that" >> sort of issue. >> >> Throwable might be a bit much, though. Phil? I was thinking >> Exception because those tend to focus on "your code made a mistake" >> whereas Error is something like "you are mix/matching incompatible >> code that was compiled to contain conflicting information" (kind of >> like calling a method that doesn't exist in this release, etc.). It's >> hard to say what the proper level of forgiveness should be here. >> Another thought is "RuntimeException", since any other exception would >> need to be declared to be thrown and we don't declare it for that >> method, so their implementation shouldn't be allowed to declare it >> either... >> >> ...jim >> >> On 05/31/2016 10:34 AM, Phil Race wrote: >>> Based on what Ajit wrote in the bug report, he at least found a jar >>> file that contains this code, but I have so far failed to locate the >>> source code as all the versions I find on the net use the Java 2D >>> JDK 1.2 BufferedImageOp APIs so I suspect this bug is in a very old >>> version and it may not be open source. >>> Therefore I am not sure how much e.printStackTrace() will help them >>> if they don't own that source except to encourage them to upgrade. >>> I'd be inclined to stick it behind a debugging property if we have >>> one that we could re-use except that in such a case they probably >>> won't know enough to set the property. >>> So on balance it is probably best to do as it has been presented here >>> except that catch (Throwable t) probably makes sense as we don't want >>> to revisit this for a different exception. >>> >>> Minor nit about the test: instead of calling intValue() on a null >>> Integer, why not just "throw new NullPointerException("reason ..") ? >>> >>> >>> -phil. >>> >>> >>> >>> >>> >>> On 05/30/2016 01:22 AM, Ajit Ghaisas wrote: >>>> I did contemplate catching 'Exception' instead of >>>> 'NullPointerException' while raising the webrev, but decided not to do >>>> it as- >>>> 1. Complaint in current image filter was due to NPE only >>>> 2. Catching & consuming generic exception does not seem quite correct >>>> here as we are just printing stack trace and not taking any concrete >>>> action. >>>> 3. There is no reported issue of any other type of Exception out of >>>> this method. >>>> >>>> Regards, >>>> Ajit >>>> >>>> >>>> -----Original Message----- >>>> From: Jim Graham >>>> Sent: Saturday, May 28, 2016 4:41 AM >>>> To: Ajit Ghaisas; Sergey Bylokhov; 2d-dev; Philip Race >>>> Subject: Re: [OpenJDK 2D-Dev] Fix for JDK-8139192 : Custom >>>> ImageFilters return blank images in Java 8(.45) while working in 7 >>>> >>>> That looks good, but I wonder if it should catch all exceptions >>>> instead of just NPE. Historically we were only catching NPE before we >>>> added the call to STATICIMAGEDONE, and the current filter in question >>>> turns out to throw an NPE, but if a filter that was commonly used with >>>> offscreen images was not expecting the STATICIMAGEDONE as was this >>>> WaterFilter, then they could potentially throw a wider variety of >>>> exceptions. >>>> >>>> I'm good with NPE since that is the only case we've seen, but I'd also >>>> be good with changing line 192 to catch all exceptions. Phil? >>>> >>>> ...jim >>>> >>>> On 5/27/16 1:32 AM, Ajit Ghaisas wrote: >>>>> Hi Jim, >>>>> >>>>> Thanks for in-depth analysis and detailed review. >>>>> I appreciate your concern for filtered image being blank in Java >>>>> 8, while it used to work in Java 7. >>>>> >>>>> Yes. I totally agree with your suggestion to do both - >>>>> 1. Not send IMAGEERROR if there is exception from ImageFilter >>>>> while processing STATICIMAGE done >>>>> 2. At the same time, as we are consuming the exception, show the >>>>> exception stacktrace. >>>>> >>>>> With this fix the functionality of com.jhlabs.image.WaterFilter >>>>> is restored. It does not return blank images anymore. >>>>> Also, as additional information, exception details are shown as >>>>> a stacktrace. >>>>> >>>>> Please review the updated webrev : >>>>> http://cr.openjdk.java.net/~aghaisas/8139192/webrev.02/ >>>>> >>>>> Regards, >>>>> Ajit >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Jim Graham >>>>> Sent: Thursday, May 26, 2016 4:57 AM >>>>> To: Sergey Bylokhov; Ajit Ghaisas; 2d-dev; Philip Race >>>>> Subject: Re: [OpenJDK 2D-Dev] Fix for JDK-8139192 : Custom >>>>> ImageFilters return blank images in Java 8(.45) while working in 7 >>>>> >>>>> Their complaint is that the resulting image is empty - most likely >>>>> because the error gets passed through and clears the image buffer. >>>>> It appears that the sequence of events is: >>>>> >>>>> We send SINGLEFRAMEDONE. >>>>> - the image is displayable >>>>> We send STATICIMAGEDONE. >>>>> - filter throws NPE >>>>> - image is probably still displayable >>>>> We send ERROR >>>>> - if it gets passed through to the toolkit image consumer then we'll >>>>> clear the image buffer >>>>> - image is no longer displayable >>>>> >>>>> It's hard to say for sure without having an instance of their filter >>>>> in-house for testing, but previously we weren't sending the >>>>> STATICDONE notice and the program was working just fine. Since the >>>>> NPE comes from their code when we send it, it shouldn't have affected >>>>> any down-stream consumers, so we should be OK with just continuing on >>>>> and the image should still be displayable just as if we hadn't sent >>>>> the STATICDONE notice in the first place. >>>>> >>>>> Now, *during debugging*, they were thwarted by the fact that we ate >>>>> the exception, true, but the original issue is that the image wasn't >>>>> displayable at all. We might want to do both: >>>>> >>>>> - not send ERROR for STATICDONE when we used to not send STATICDONE at >>>>> all >>>>> - show the exception so that someone realizes that there is a >>>>> problem, even though we've made it not hurt their functionality. >>>>> >>>>> Does that make sense? >>>>> >>>>> ...jim >>>>> >>>>> On 5/25/2016 1:36 PM, Sergey Bylokhov wrote: >>>>>> On 25.05.16 23:33, Jim Graham wrote: >>>>>>> How about option 3 - >>>>>>> >>>>>>> NPE before imageComplete sends an ERROR as it does now. >>>>>>> >>>>>>> NPE during imageComplete is ignored, both for backwards >>>>>>> compatibility and because it is more of a "hint" than an operation >>>>>>> that requires action from the consumer. >>>>>> I guess the case is that when we ignore this NPE(w/o any >>>>>> notification) the users complains that the bug is in jdk. >>>>>> >>>>>>> ...jim >>>>>>> >>>>>>> On 5/25/2016 1:31 AM, Ajit Ghaisas wrote: >>>>>>>> Hi >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Bug : >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8139192 >>>>>>>> >>>>>>>> Custom ImageFilters return blank images in Java 8(.45) while >>>>>>>> working in 7 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Root cause : >>>>>>>> >>>>>>>> private method produce() in OffScreenImageSource.java consumes a >>>>>>>> NullPointerException that originates from a custom ImageConsumer (a >>>>>>>> 3^rd party image library class - com.jhlabs.image.WaterFilter) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Analysis: >>>>>>>> >>>>>>>> 1. How the behavior changed between JDK7 and JK8 : >>>>>>>> >>>>>>>> A call to imageComplete(ImageConsumer.SINGLEFRAMEDONE) was added in >>>>>>>> addition to imageComplete(ImageConsumer. STATICIMAGEDONE) as a fix >>>>>>>> for JDK-7143612. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2. What debugging revealed: >>>>>>>> >>>>>>>> A NullPointerException is being thrown from the library during the >>>>>>>> call to imageComplete(ImageConsumer.STATICIMAGEDONE) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 3. It looks like the fix of JDK-7143612 is valid and successive >>>>>>>> calls to >>>>>>>> imageComplete() are allowed. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 4. The 3rd party library behavior appears incorrect (if it can not >>>>>>>> handle subsequent calls to imageComplete(), it should de-register >>>>>>>> itself). >>>>>>>> >>>>>>>> The 3rd-party library code should be fixed. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Possible modifications in JDK : >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Currently, OffScreenImageSource::produce() consumes the >>>>>>>> NullPointerException - this is incorrect and results in silent >>>>>>>> failure of this particular image filter. >>>>>>>> >>>>>>>> We need to let the image filter library know that exception has >>>>>>>> occurred in its code and not in JDK. We have two options - >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Option 1 : Rethrow the NullPointerException --- It is the >>>>>>>> clearest way >>>>>>>> to let 3^rd party library know that their code is erroneous with >>>>>>>> latest JDK. This will change the 3^rd party image filter behavior >>>>>>>> that generates blank image. >>>>>>>> >>>>>>>> Option 2 : Add a stack trace where the exception is being consumed >>>>>>>> --- Adding stack trace provides more information regarding failure >>>>>>>> of 3^rd party image filter with retaining the current behavior that >>>>>>>> generates blank image. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I have implemented both the options: >>>>>>>> >>>>>>>> Option 1: http://cr.openjdk.java.net/~aghaisas/8139192/webrev.00/ >>>>>>>> >>>>>>>> Option 2: http://cr.openjdk.java.net/~aghaisas/8139192/webrev.01/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Request you to review both the webrevs and provide your preference. >>>>>>>> >>>>>>>> I will add a test to the selected webrev. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Ajit >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>> > From philip.race at oracle.com Wed Jun 1 22:34:34 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 01 Jun 2016 15:34:34 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail In-Reply-To: <89531a21-64b2-4e00-8f15-aa78650cf7b2@default> References: <89531a21-64b2-4e00-8f15-aa78650cf7b2@default> Message-ID: <574F62FA.50900@oracle.com> I am bit doubtful about this. Are you sure we are correct in reporting two images to begin with ? Thumbnails should not get counted .. -phil. On 06/01/2016 01:06 AM, Jayathirth D V wrote: > > Updated bug title in JBS as it was misleading. > > *From:* Jayathirth D V > *Sent:* Wednesday, June 01, 2016 12:48 PM > *To:* Philip Race; Jim Graham > *Cc:* 2d-dev at openjdk.java.net > *Subject:* Review Request for JDK-8152672 : Exception getting > thumbnail size for JPEG with embedded thumbnail > > Hi, > > _Please review the following fix in JDK9:_ > > __ > > Bug : https://bugs.openjdk.java.net/browse/JDK-8152672 > > Webrev : http://cr.openjdk.java.net/~jdv/8152672/webrev.00/ > > > Issue : When we are trying to get properties related to second image > in JPEG file we are getting IIOException mentioning that it is not a > JPEG file. > > Root cause : When we are skipping first image to reach second image > header, we are just trying to find next available EOI marker. But if > first image has embedded thumbnail in APP1 marker, we will reach to > EOI of this thumbnail and not EOI of first image. So after we reach > EOI of embedded thumbnail we try to access second image SOI marker > which will fail. > > Solution : We have to change the logic of how we skip to consecutive > images in JPEG file. We know that application markers, comments or > other markers can contain data same as SOI & EOI. Instead of just > checking for EOI marker serially, we should read length of these > markers and skip them. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Jun 2 09:37:52 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 2 Jun 2016 12:37:52 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8158408: Font2DTest demo needs to use FontPanel resolution matching the screen In-Reply-To: <574F2D0F.9020404@oracle.com> References: <574F144E.40606@oracle.com> <574F2D0F.9020404@oracle.com> Message-ID: On 01.06.16 21:44, Phil Race wrote: > On 06/01/2016 11:05 AM, Semyon Sadetsky wrote: >> you call super.paintComponent(g); twice in lines 956 and 964. Is it >> expected behavior? Why the writePNG() produce the low resolution image? probably it should take into account the GC scale? > > Yes, if "CannotDrawException" is caught we want to repaint using super > else, we will > may have a partially panel. > > -phil. > >> >> --Semyon >> >> >> On 6/1/2016 7:58 PM, Philip Race wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8158408 >>> Webrev: http://cr.openjdk.java.net/~prr/8158408/ >>> >>> At 125% scaling on JDK 9 Font2DTest looks horrid since its >>> BufferedImage is scaled to the screen. >>> Fix is to not use a BufferedImage, just use the Swing back buffer. >>> >>> -phil. >> > -- Best regards, Sergey. From ajit.ghaisas at oracle.com Thu Jun 2 09:51:09 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Thu, 2 Jun 2016 02:51:09 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Fix for JDK-8139192 : Custom ImageFilters return blank images in Java 8(.45) while working in 7 In-Reply-To: <0849286c-0b7e-964e-85ef-41de34e5a60a@oracle.com> References: <480a1ef0-30e5-e1ed-8def-e28f383949ac@oracle.com> <958c83a7-1a72-a5cf-0b3b-8479efee5974@oracle.com> <6d79d18b-3854-402c-9981-38ed2e0f161a@default> <2d10a7cc-51e5-50dc-1a66-33f94679e067@oracle.com> <4f6cae95-0552-4507-942a-e0f2e9beb3be@default> <574DCB17.3070306@oracle.com> <574DE61F.30607@oracle.com> <74c0b159-895e-c6c4-67ae-e470d7055251@oracle.com> <544e09c0-79d9-4606-973e-d03259b68362@default> <0849286c-0b7e-964e-85ef-41de34e5a60a@oracle.com> Message-ID: <4942199a-5642-47c2-98fc-5f085ba079b3@default> Thanks Jim and Phil for reviewing this. Adding a comment is a good suggestion. I have added it and requested a push of following webrev- http://cr.openjdk.java.net/~aghaisas/8139192/webrev.04/ (Sent here for a reference) Regards, Ajit -----Original Message----- From: Jim Graham Sent: Thursday, June 02, 2016 2:54 AM To: Ajit Ghaisas; Philip Race; Sergey Bylokhov; 2d-dev Subject: Re: [OpenJDK 2D-Dev] Fix for JDK-8139192 : Custom ImageFilters return blank images in Java 8(.45) while working in 7 +1. If you wanted to add a comment on the new catch, you could say: } catch (RuntimeException e) { // We did not previously call this method here and some filters // were not prepared for it to be called at this time so we // allow them to have runtime issues for this one call only // without triggering the ERROR condition below. ... (printstack) } Your call, I don't need to approve a webrev for that comment addition... ...jim On 6/1/16 3:28 AM, Ajit Ghaisas wrote: > Thanks Jim and Phil for valuable feedback and suggestions. > > The detailed discussion helped me to understand why catching RuntimeException is a better option for a call to imageComplete(STATICIMAGEDONE). > I have modified the code on line 192 accordingly. > > I have not modified the code catching NullPointerException (on line 196) as doing so would mask a wider variety of legitimate exceptions. So, line 196 remains unchanged. > > I have also modified the test to throw NullPointerException instead of calling intValue() on a null. > > Please review updated webrev : > http://cr.openjdk.java.net/~aghaisas/8139192/webrev.03/ > > Regards, > Ajit > > -----Original Message----- > From: Phil Race > Sent: Wednesday, June 01, 2016 1:41 AM > To: Jim Graham; Ajit Ghaisas > Cc: Sergey Bylokhov; 2d-dev > Subject: Re: [OpenJDK 2D-Dev] Fix for JDK-8139192 : Custom > ImageFilters return blank images in Java 8(.45) while working in 7 > > I agree with the suggestion of RuntimeException as likely sufficient but not too much ... > > -phil. > > > On 5/31/2016 12:29 PM, Jim Graham wrote: >> I agree with this. It would be nice if we didn't spit out print >> statements by default, but I'm not sure what a good flag would be to >> use to diagnose this that balances how likely developers will think >> to use it. >> >> The point about catching a wider variety of exceptions is not that it >> is good practice in general, but we've added a new call to a >> long-standing algorithm which has decades (really? plural? pretty >> much, I think) of past code that isn't expecting the new call, and >> that call is basically "informative" not something that they really >> need to successfully handle, so just as someone might accidentally >> process a null pointer in a case like that, someone else might run >> off the end of an array (AIOOB) or any other "I wasn't expecting that" >> sort of issue. >> >> Throwable might be a bit much, though. Phil? I was thinking >> Exception because those tend to focus on "your code made a mistake" >> whereas Error is something like "you are mix/matching incompatible >> code that was compiled to contain conflicting information" (kind of >> like calling a method that doesn't exist in this release, etc.). >> It's hard to say what the proper level of forgiveness should be here. >> Another thought is "RuntimeException", since any other exception >> would need to be declared to be thrown and we don't declare it for >> that method, so their implementation shouldn't be allowed to declare >> it either... >> >> ...jim >> >> On 05/31/2016 10:34 AM, Phil Race wrote: >>> Based on what Ajit wrote in the bug report, he at least found a jar >>> file that contains this code, but I have so far failed to locate the >>> source code as all the versions I find on the net use the Java 2D >>> JDK 1.2 BufferedImageOp APIs so I suspect this bug is in a very old >>> version and it may not be open source. >>> Therefore I am not sure how much e.printStackTrace() will help them >>> if they don't own that source except to encourage them to upgrade. >>> I'd be inclined to stick it behind a debugging property if we have >>> one that we could re-use except that in such a case they probably >>> won't know enough to set the property. >>> So on balance it is probably best to do as it has been presented >>> here except that catch (Throwable t) probably makes sense as we >>> don't want to revisit this for a different exception. >>> >>> Minor nit about the test: instead of calling intValue() on a null >>> Integer, why not just "throw new NullPointerException("reason ..") ? >>> >>> >>> -phil. >>> >>> >>> >>> >>> >>> On 05/30/2016 01:22 AM, Ajit Ghaisas wrote: >>>> I did contemplate catching 'Exception' instead of >>>> 'NullPointerException' while raising the webrev, but decided not to >>>> do it as- 1. Complaint in current image filter was due to NPE only >>>> 2. Catching & consuming generic exception does not seem quite >>>> correct here as we are just printing stack trace and not taking any >>>> concrete action. >>>> 3. There is no reported issue of any other type of Exception out of >>>> this method. >>>> >>>> Regards, >>>> Ajit >>>> >>>> >>>> -----Original Message----- >>>> From: Jim Graham >>>> Sent: Saturday, May 28, 2016 4:41 AM >>>> To: Ajit Ghaisas; Sergey Bylokhov; 2d-dev; Philip Race >>>> Subject: Re: [OpenJDK 2D-Dev] Fix for JDK-8139192 : Custom >>>> ImageFilters return blank images in Java 8(.45) while working in 7 >>>> >>>> That looks good, but I wonder if it should catch all exceptions >>>> instead of just NPE. Historically we were only catching NPE before >>>> we added the call to STATICIMAGEDONE, and the current filter in >>>> question turns out to throw an NPE, but if a filter that was >>>> commonly used with offscreen images was not expecting the >>>> STATICIMAGEDONE as was this WaterFilter, then they could >>>> potentially throw a wider variety of exceptions. >>>> >>>> I'm good with NPE since that is the only case we've seen, but I'd >>>> also be good with changing line 192 to catch all exceptions. Phil? >>>> >>>> ...jim >>>> >>>> On 5/27/16 1:32 AM, Ajit Ghaisas wrote: >>>>> Hi Jim, >>>>> >>>>> Thanks for in-depth analysis and detailed review. >>>>> I appreciate your concern for filtered image being blank in >>>>> Java 8, while it used to work in Java 7. >>>>> >>>>> Yes. I totally agree with your suggestion to do both - >>>>> 1. Not send IMAGEERROR if there is exception from ImageFilter >>>>> while processing STATICIMAGE done >>>>> 2. At the same time, as we are consuming the exception, show >>>>> the exception stacktrace. >>>>> >>>>> With this fix the functionality of >>>>> com.jhlabs.image.WaterFilter is restored. It does not return blank images anymore. >>>>> Also, as additional information, exception details are shown >>>>> as a stacktrace. >>>>> >>>>> Please review the updated webrev : >>>>> http://cr.openjdk.java.net/~aghaisas/8139192/webrev.02/ >>>>> >>>>> Regards, >>>>> Ajit >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Jim Graham >>>>> Sent: Thursday, May 26, 2016 4:57 AM >>>>> To: Sergey Bylokhov; Ajit Ghaisas; 2d-dev; Philip Race >>>>> Subject: Re: [OpenJDK 2D-Dev] Fix for JDK-8139192 : Custom >>>>> ImageFilters return blank images in Java 8(.45) while working in 7 >>>>> >>>>> Their complaint is that the resulting image is empty - most likely >>>>> because the error gets passed through and clears the image buffer. >>>>> It appears that the sequence of events is: >>>>> >>>>> We send SINGLEFRAMEDONE. >>>>> - the image is displayable >>>>> We send STATICIMAGEDONE. >>>>> - filter throws NPE >>>>> - image is probably still displayable We send ERROR >>>>> - if it gets passed through to the toolkit image consumer then >>>>> we'll clear the image buffer >>>>> - image is no longer displayable >>>>> >>>>> It's hard to say for sure without having an instance of their >>>>> filter in-house for testing, but previously we weren't sending the >>>>> STATICDONE notice and the program was working just fine. Since the >>>>> NPE comes from their code when we send it, it shouldn't have >>>>> affected any down-stream consumers, so we should be OK with just >>>>> continuing on and the image should still be displayable just as if >>>>> we hadn't sent the STATICDONE notice in the first place. >>>>> >>>>> Now, *during debugging*, they were thwarted by the fact that we >>>>> ate the exception, true, but the original issue is that the image >>>>> wasn't displayable at all. We might want to do both: >>>>> >>>>> - not send ERROR for STATICDONE when we used to not send >>>>> STATICDONE at all >>>>> - show the exception so that someone realizes that there is a >>>>> problem, even though we've made it not hurt their functionality. >>>>> >>>>> Does that make sense? >>>>> >>>>> ...jim >>>>> >>>>> On 5/25/2016 1:36 PM, Sergey Bylokhov wrote: >>>>>> On 25.05.16 23:33, Jim Graham wrote: >>>>>>> How about option 3 - >>>>>>> >>>>>>> NPE before imageComplete sends an ERROR as it does now. >>>>>>> >>>>>>> NPE during imageComplete is ignored, both for backwards >>>>>>> compatibility and because it is more of a "hint" than an >>>>>>> operation that requires action from the consumer. >>>>>> I guess the case is that when we ignore this NPE(w/o any >>>>>> notification) the users complains that the bug is in jdk. >>>>>> >>>>>>> ...jim >>>>>>> >>>>>>> On 5/25/2016 1:31 AM, Ajit Ghaisas wrote: >>>>>>>> Hi >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Bug : >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8139192 >>>>>>>> >>>>>>>> Custom ImageFilters return blank images in Java 8(.45) while >>>>>>>> working in 7 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Root cause : >>>>>>>> >>>>>>>> private method produce() in OffScreenImageSource.java consumes >>>>>>>> a NullPointerException that originates from a custom >>>>>>>> ImageConsumer (a 3^rd party image library class - >>>>>>>> com.jhlabs.image.WaterFilter) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Analysis: >>>>>>>> >>>>>>>> 1. How the behavior changed between JDK7 and JK8 : >>>>>>>> >>>>>>>> A call to imageComplete(ImageConsumer.SINGLEFRAMEDONE) was >>>>>>>> added in addition to imageComplete(ImageConsumer. >>>>>>>> STATICIMAGEDONE) as a fix for JDK-7143612. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2. What debugging revealed: >>>>>>>> >>>>>>>> A NullPointerException is being thrown from the library during >>>>>>>> the call to imageComplete(ImageConsumer.STATICIMAGEDONE) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 3. It looks like the fix of JDK-7143612 is valid and successive >>>>>>>> calls to >>>>>>>> imageComplete() are allowed. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 4. The 3rd party library behavior appears incorrect (if it can >>>>>>>> not handle subsequent calls to imageComplete(), it should >>>>>>>> de-register itself). >>>>>>>> >>>>>>>> The 3rd-party library code should be fixed. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Possible modifications in JDK : >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Currently, OffScreenImageSource::produce() consumes the >>>>>>>> NullPointerException - this is incorrect and results in silent >>>>>>>> failure of this particular image filter. >>>>>>>> >>>>>>>> We need to let the image filter library know that exception has >>>>>>>> occurred in its code and not in JDK. We have two options - >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Option 1 : Rethrow the NullPointerException --- It is the >>>>>>>> clearest way >>>>>>>> to let 3^rd party library know that their code is erroneous >>>>>>>> with latest JDK. This will change the 3^rd party image filter >>>>>>>> behavior that generates blank image. >>>>>>>> >>>>>>>> Option 2 : Add a stack trace where the exception is being >>>>>>>> consumed >>>>>>>> --- Adding stack trace provides more information regarding >>>>>>>> failure of 3^rd party image filter with retaining the current >>>>>>>> behavior that generates blank image. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I have implemented both the options: >>>>>>>> >>>>>>>> Option 1: >>>>>>>> http://cr.openjdk.java.net/~aghaisas/8139192/webrev.00/ >>>>>>>> >>>>>>>> Option 2: >>>>>>>> http://cr.openjdk.java.net/~aghaisas/8139192/webrev.01/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Request you to review both the webrevs and provide your preference. >>>>>>>> >>>>>>>> I will add a test to the selected webrev. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Ajit >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>> > From jayathirth.d.v at oracle.com Thu Jun 2 11:37:38 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 2 Jun 2016 04:37:38 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail In-Reply-To: <574F62FA.50900@oracle.com> References: <89531a21-64b2-4e00-8f15-aa78650cf7b2@default> <574F62FA.50900@oracle.com> Message-ID: Hi Phil, We have to kind of images with which we are able to reproduce the issue: 1) sample.jpg present in JBS bug(We can't use this image because it is licensed ). 2) JpegEmbedThumbnail.jpg taken using Prasanta's camera and used in webrev. sample.jpg : If we do getNumImages() it will return 2. getNumImages() follows the same logic of skipping markers with length and registering SOI to get number of images. sample.jpg has markers as follows : SOI -> APP1 - > SOI -> EOI -> APP1 End -> EOI -> SOI -> EOI I have dumped first image its SOI is first one in the above list and for second image it is third one in the list. getNumImages() counts first and third SOI for number of images. But in case of skipImage() we are getting inside APP1 marker and considering its SOI. JpegEmbedThumbnail.jpg : If we do getNumImages() it will return 1. JpegEmbedThumbnail.jpg has markers as follows : SOI -> APP1 -> SOI -> EOI -> APP1 End -> APP2 -> SOI -> APP2 End -> APP2 -> EOI -> APP2 End -> EOI getNumImages() counts only first SOI for number of images. But in case of skipImage() we will are getting inside APP1 and APP2 markers also. Thanks, Jay From: Phil Race Sent: Thursday, June 02, 2016 4:05 AM To: Jayathirth D V Cc: Jim Graham; 2d-dev at openjdk.java.net Subject: Re: Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail I am bit doubtful about this. Are you sure we are correct in reporting two images to begin with ? Thumbnails should not get counted .. -phil. On 06/01/2016 01:06 AM, Jayathirth D V wrote: Updated bug title in JBS as it was misleading. From: Jayathirth D V Sent: Wednesday, June 01, 2016 12:48 PM To: Philip Race; Jim Graham Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Review Request for JDK-8152672 : Exception getting thumbnail size for JPEG with embedded thumbnail Hi, Please review the following fix in JDK9: Bug : https://bugs.openjdk.java.net/browse/JDK-8152672 Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8152672/webrev.00/"http://cr.openjdk.java.net/~jdv/8152672/webrev.00/ Issue : When we are trying to get properties related to second image in JPEG file we are getting IIOException mentioning that it is not a JPEG file. Root cause : When we are skipping first image to reach second image header, we are just trying to find next available EOI marker. But if first image has embedded thumbnail in APP1 marker, we will reach to EOI of this thumbnail and not EOI of first image. So after we reach EOI of embedded thumbnail we try to access second image SOI marker which will fail. Solution : We have to change the logic of how we skip to consecutive images in JPEG file. We know that application markers, comments or other markers can contain data same as SOI & EOI. Instead of just checking for EOI marker serially, we should read length of these markers and skip them. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Thu Jun 2 12:10:26 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 2 Jun 2016 05:10:26 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail In-Reply-To: References: <89531a21-64b2-4e00-8f15-aa78650cf7b2@default> <574F62FA.50900@oracle.com> Message-ID: Fixed typo. From: Jayathirth D V Sent: Thursday, June 02, 2016 5:08 PM To: Philip Race Cc: Jim Graham; 2d-dev at openjdk.java.net Subject: RE: Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail Hi Phil, We have two kind of images with which we are able to reproduce the issue: 1) sample.jpg present in JBS bug(We can't use this image because it is licensed ). 2) JpegEmbedThumbnail.jpg taken using Prasanta's camera and used in webrev. sample.jpg : If we do getNumImages() it will return 2. getNumImages() follows the same logic of skipping markers with length and registering SOI to get number of images. sample.jpg has markers as follows : SOI -> APP1 - > SOI -> EOI -> APP1 End -> EOI -> SOI -> EOI I have dumped first image its SOI is first one in the above list and for second image it is third one in the list. getNumImages() counts first and third SOI for number of images. But in case of skipImage() we are getting inside APP1 marker and considering its SOI. JpegEmbedThumbnail.jpg : If we do getNumImages() it will return 1. JpegEmbedThumbnail.jpg has markers as follows : SOI -> APP1 -> SOI -> EOI -> APP1 End -> APP2 -> SOI -> APP2 End -> APP2 -> EOI -> APP2 End -> EOI getNumImages() counts only first SOI for number of images. But in case of skipImage() we will are getting inside APP1 and APP2 markers also. Thanks, Jay From: Phil Race Sent: Thursday, June 02, 2016 4:05 AM To: Jayathirth D V Cc: Jim Graham; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail I am bit doubtful about this. Are you sure we are correct in reporting two images to begin with ? Thumbnails should not get counted .. -phil. On 06/01/2016 01:06 AM, Jayathirth D V wrote: Updated bug title in JBS as it was misleading. From: Jayathirth D V Sent: Wednesday, June 01, 2016 12:48 PM To: Philip Race; Jim Graham Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Review Request for JDK-8152672 : Exception getting thumbnail size for JPEG with embedded thumbnail Hi, Please review the following fix in JDK9: Bug : https://bugs.openjdk.java.net/browse/JDK-8152672 Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8152672/webrev.00/"http://cr.openjdk.java.net/~jdv/8152672/webrev.00/ Issue : When we are trying to get properties related to second image in JPEG file we are getting IIOException mentioning that it is not a JPEG file. Root cause : When we are skipping first image to reach second image header, we are just trying to find next available EOI marker. But if first image has embedded thumbnail in APP1 marker, we will reach to EOI of this thumbnail and not EOI of first image. So after we reach EOI of embedded thumbnail we try to access second image SOI marker which will fail. Solution : We have to change the logic of how we skip to consecutive images in JPEG file. We know that application markers, comments or other markers can contain data same as SOI & EOI. Instead of just checking for EOI marker serially, we should read length of these markers and skip them. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Thu Jun 2 14:07:12 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 2 Jun 2016 07:07:12 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods In-Reply-To: <574F0EFE.2070300@oracle.com> References: <6f83b633-3910-47fa-b872-e042fe4c24d3@default> <24ca2994-aa27-4a70-8cf9-0bda35664f3f@default> <574809B2.5040901@oracle.com> <9f641938-f979-4021-9e94-bde47e1d3c67@default> <57489033.7020901@oracle.com> <77d5b327-066b-4d86-a44d-8e681aeb71f8@default> <574DE3F9.40709@oracle.com> <574E0717.5060405@oracle.com> <574E0DF9.20508@oracle.com> <574E10B0.4070003@oracle.com> <574E13BD.9060701@oracle.com> <9a87056b-2646-4d5f-bfec-d50bea489381@default> <574F0EFE.2070300@oracle.com> Message-ID: <2e485b6b-3df0-41db-ba40-a96528883e95@default> Hi Phil, I have updated the code with all the changes I mentioned previously. I am caching hashCode when first time hashCode() is called. Please find the updated webrev for review: http://cr.openjdk.java.net/~jdv/7107905/webrev.09/ Thanks, Jay -----Original Message----- From: Philip Race Sent: Wednesday, June 01, 2016 10:06 PM To: Jayathirth D V Cc: Jim Graham; 2d-dev at openjdk.java.net Subject: Re: Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods Please post the updated webrev. -phil. On 6/1/16, 12:02 AM, Jayathirth D V wrote: > Hi Phil& Jim, > > Collating all the changes needed: > 1) I have removed both equals()& hashCode() in CCM but forgot to add the file while creating webrev. I will include changes in CCM in updated webrev. > 2) Caching of hashCode value in IndexColorModel& PackedColorModel : > We can cache hashCode value when constructor is called or when hashCode() is called for first time. What approach we have to follow? > 3) Comment section of equals() method, I will update it to : > 1449 * the target object must be the same class (and not a subclass) as this > 4) I will use .equals() to compare colorSpace values in CM.equals() so it will be like we are not intending ColorSpace class to never override equals() method. > > Please let me know your inputs. > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Wednesday, June 01, 2016 4:14 AM > To: Phil Race > Cc: Jayathirth D V; 2d-dev at openjdk.java.net > Subject: Re: Review Request for JDK-7107905: ColorModel subclasses are > missing hashCode() or equals() or both methods > > I think we should use .equals() here, otherwise it looks like a recommendation that the intent is for those classes to never implement it... > > ...jim > > On 05/31/2016 03:31 PM, Phil Race wrote: >> I don't know of any design intent, so yes, I meant more as a >> practical matter. >> Unless they subclass then using equals() which I thought unlikely it >> makes no difference here. >> But it would be proof against that to use equals, unlikely to matter >> as it might be .. >> >> -phil. >> >> On 05/31/2016 03:19 PM, Jim Graham wrote: >>> >>> On 05/31/2016 02:50 PM, Phil Race wrote: >>>> On 05/31/2016 12:20 PM, Jim Graham wrote: >>>>> Hi Jay, >>>>> >>>>> You were going to remove hashCode/equals from CCM, but instead you >>>>> simply removed it from the patch. You still need to edit it to >>>>> remove the existing methods. >>>> Oh yeah ! CCM is gone from the latest webrev. I expect that was not >>>> intentional. >>>> >>>>> Also, I'm not sure == is a good way to compare ColorSpace >>>>> instances >>>>> - Phil? >>>> Neither ColorSpace nor ICC_ColorSpace over-ride equals or hashCode >>>> and all the predefined ones are constructed as singletons so it >>>> seems unlikely to cause problems >>> Should it use .equals() on principle, though? Otherwise we are >>> baking in the assumption that it doesn't implement equals() into our >>> implementation of the CM.equals() method. Might it some day >>> implement equals (perhaps it isn't a practical issue today, but it >>> might be in the future when we forget that it was omitted in this >>> usage we create today). >>> >>> I guess what I'm asking is if it is a design feature that different >>> objects are considered non-equal (such as an object that, for >>> instance, has only predetermined instances that are shared by >>> reference and reused). I think color spaces are sort of in-between >>> in that we define a few constants that simply get used by reference >>> in 99% of cases, but that isn't a design feature, more like a >>> practical issue... >>> >>> ...jim From alexey.ushakov at jetbrains.com Thu Jun 2 15:07:43 2016 From: alexey.ushakov at jetbrains.com (Alexey Ushakov) Date: Thu, 2 Jun 2016 18:07:43 +0300 Subject: [OpenJDK 2D-Dev] Review request for: JDK-8158495 CCE: sun.java2d.NullSurfaceData cannot be cast to sun.java2d.opengl.OGLSurfaceData Message-ID: <0F380F61-7EC2-43F0-B0AA-2D79D4C9E9CD@jetbrains.com> Hello Phil and Sergey, Here is one more fix of the ClassCastException for invalid surface that we?ve recently got in our products. I?ve updated Sergey?s test so it goes through the problematic code. Unfortunately, I was unable to reproduce the problem by myself (The actual issue was reported only by our customers) Bug: https://bugs.openjdk.java.net/browse/JDK-8158495 Webrev: http://cr.openjdk.java.net/~avu/JDK-8158495/webrev.00 Best Regards, Alexey From ajit.ghaisas at oracle.com Thu Jun 2 16:10:48 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Thu, 2 Jun 2016 09:10:48 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Fix for JDK-8074829 : Resolve disabled warnings for libawt_headless In-Reply-To: <574DBD23.7060608@oracle.com> References: <5717D829.8070704@oracle.com> <5717E448.7000003@oracle.com> <48002ede-2af9-4bf2-bb32-f38114ea438b@default> <57193461.1090904@oracle.com> <574DBD23.7060608@oracle.com> Message-ID: <24342d75-e133-46ff-959f-9d3e2a6b3a8c@default> Hi, I faced merge issues while getting the webrev.00 committed. I have taken the latest code and merged webrev.00 changes on top of it to generate webrev.01. Here is the updated webrev. http://cr.openjdk.java.net/~aghaisas/8074829/webrev.01/ The changes are exactly the same between webrev.00 & webrev.01. Request you to kindly review and approve again. Regards, Ajit -----Original Message----- From: Phil Race Sent: Tuesday, May 31, 2016 10:05 PM To: Ajit Ghaisas Cc: Sergey Bylokhov; 2d-dev; build-dev at openjdk.java.net Subject: Re: Fix for JDK-8074829 : Resolve disabled warnings for libawt_headless +1 given your off-list confirmation that JPRT built all combinations of platforms it can .. -phil. On 04/28/2016 05:44 AM, Ajit Ghaisas wrote: > Hi, > > I tried excluding files under directory : jdk/src/java.desktop/share/native/common/java2d/opengl from libawt_headless. > It resulted in compilation errors - as the headers in this directory (and under sub-directory J2D_GL) are used in other places. > > To Phil's question on - why I mentioned only OGLBlitLoops.c file? - this is the file where warning is reported and build stopped. > > Hence, I propose not to remove the suppression of warning E_EMPTY_TRANSLATION_UNIT in make file for Solaris. > There is no change in original webrev : http://cr.openjdk.java.net/~aghaisas/8074829/webrev.00/ > > Based on Erik's suggestion, I have built it for arm and arm64 with no errors. > > Regards, > Ajit > > -----Original Message----- > From: Phil Race > Sent: Friday, April 22, 2016 1:43 AM > To: Ajit Ghaisas > Cc: Sergey Bylokhov; 2d-dev; build-dev at openjdk.java.net > Subject: Re: Fix for JDK-8074829 : Resolve disabled warnings for libawt_headless > > > Another solution is to exclude this file from HEADLESS compilation. > > I am not sure how to achieve it. Any suggestion? > > I suppose that is possible and I expect we can do that See in the make file, where I think you just need to add entries to > LIBAWT_HEADLESS_EXCLUDES := medialib > > although I have not tried it. > Hmm .. I wonder why medialib needs to be explicitly excluded from headless ? .. but that is for another day. > > I have another question: why do you mention only OGLBlitLoops.c ? > I've flicked through a number of the C files in the same location and all look to have the same issue. > > -phil. > > On 04/21/2016 06:33 AM, Ajit Ghaisas wrote: >>>> On 04/20/2016 12:27 PM, Sergey Bylokhov wrote: >>>> 2d-dev added. >>> In fact all these are 2D. No AWT warnings here. >>>> I am not sure but why "declaration in the code" is a bad thing and >>>> we should fix it? >>>> - DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE >>>> >>>> I cannot find the documentation in solaris studio for this warning. >>> I don't mind fixing it if it is still an issue but does the current compiler actually complain about it ? >>> The SS11 -> SS12 upgrade might have got a more modern C compiler .. >> [Ajit ] Yes. The Solaris compiler still complains about this declaration in code. Hence, I have fixed the reported warnings after removing the suppression from makefile. >> >>>> On 20.04.16 11:57, Ajit Ghaisas wrote: >>>>> Hi, >>>>> >>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8074829 >>>>> This bug is to remove warning suppressions from makefile and >>>>> fix the warnings for libawt_headless library. >>>>> >>>>> I have removed following warning suppressions & fixed the >>>>> warnings for libawt_headless library. >>>>> DISABLED_WARNINGS_gcc := maybe-uninitialized >>>>> int-to-pointer-cast >>> What made that one go away ?? >> [Ajit] : I fixed warnings reported for 'maybe-uninitialized' and 'E_DECLARATION_IN_CODE' warning types in two .c files in webrev. >> There was no warning after removal of 'int-to-pointer-cast' suppression from makefile. No code change was made for this type of warning. >> >> >>>>> DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE >>>>> >>>>> Warning suppression that cannot be removed : >>>>> DISABLED_WARNINGS_solstudio := E_EMPTY_TRANSLATION_UNIT >>>>> This is due to the fact that - >>>>> jdk/src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops >>>>> .c file becomes empty file in case of HEADLESS mode compilation. >>> Sigh .. there ought to be "informational" warnings as well as "risky practice" warnings and this should be in the former category. >>> You could move something like the jni.h and jlong.h imports outside to see if that shuts it up. >>> Not saying that is what we want to do but it would be interesting to check. >> [Ajit] : Nope. Moving jni.h or jlong.h inclusions outside #ifndef HEADLESS did not help. We still get E_EMPTY_TRANSLATION_UNIT warning. >> To get rid of this warning, there are suggestions to make a typedef - and not use it anywhere - but, I would rather keep the suppression in makefile than defining a typedef without actual usage. >> Another solution is to exclude this file from HEADLESS compilation. I am not sure how to achieve it. Any suggestion? >> >> >>> -phil. >>>>> Request you to review following webrev : >>>>> http://cr.openjdk.java.net/~aghaisas/8074829/webrev.00/ >>>>> >>>>> Regards, >>>>> Ajit From erik.joelsson at oracle.com Thu Jun 2 16:27:11 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 2 Jun 2016 18:27:11 +0200 Subject: [OpenJDK 2D-Dev] Fix for JDK-8074829 : Resolve disabled warnings for libawt_headless In-Reply-To: <24342d75-e133-46ff-959f-9d3e2a6b3a8c@default> References: <5717D829.8070704@oracle.com> <5717E448.7000003@oracle.com> <48002ede-2af9-4bf2-bb32-f38114ea438b@default> <57193461.1090904@oracle.com> <574DBD23.7060608@oracle.com> <24342d75-e133-46ff-959f-9d3e2a6b3a8c@default> Message-ID: <57505E5F.9020008@oracle.com> Makefile changes are still good. /Erik On 2016-06-02 18:10, Ajit Ghaisas wrote: > Hi, > > I faced merge issues while getting the webrev.00 committed. > > I have taken the latest code and merged webrev.00 changes on top of it to generate webrev.01. > > Here is the updated webrev. > http://cr.openjdk.java.net/~aghaisas/8074829/webrev.01/ > > The changes are exactly the same between webrev.00 & webrev.01. > Request you to kindly review and approve again. > > Regards, > Ajit > > -----Original Message----- > From: Phil Race > Sent: Tuesday, May 31, 2016 10:05 PM > To: Ajit Ghaisas > Cc: Sergey Bylokhov; 2d-dev; build-dev at openjdk.java.net > Subject: Re: Fix for JDK-8074829 : Resolve disabled warnings for libawt_headless > > +1 given your off-list confirmation that JPRT built all combinations of > platforms it can .. > > -phil. > > On 04/28/2016 05:44 AM, Ajit Ghaisas wrote: >> Hi, >> >> I tried excluding files under directory : jdk/src/java.desktop/share/native/common/java2d/opengl from libawt_headless. >> It resulted in compilation errors - as the headers in this directory (and under sub-directory J2D_GL) are used in other places. >> >> To Phil's question on - why I mentioned only OGLBlitLoops.c file? - this is the file where warning is reported and build stopped. >> >> Hence, I propose not to remove the suppression of warning E_EMPTY_TRANSLATION_UNIT in make file for Solaris. >> There is no change in original webrev : http://cr.openjdk.java.net/~aghaisas/8074829/webrev.00/ >> >> Based on Erik's suggestion, I have built it for arm and arm64 with no errors. >> >> Regards, >> Ajit >> >> -----Original Message----- >> From: Phil Race >> Sent: Friday, April 22, 2016 1:43 AM >> To: Ajit Ghaisas >> Cc: Sergey Bylokhov; 2d-dev; build-dev at openjdk.java.net >> Subject: Re: Fix for JDK-8074829 : Resolve disabled warnings for libawt_headless >> >> > Another solution is to exclude this file from HEADLESS compilation. >> > I am not sure how to achieve it. Any suggestion? >> >> I suppose that is possible and I expect we can do that See in the make file, where I think you just need to add entries to >> LIBAWT_HEADLESS_EXCLUDES := medialib >> >> although I have not tried it. >> Hmm .. I wonder why medialib needs to be explicitly excluded from headless ? .. but that is for another day. >> >> I have another question: why do you mention only OGLBlitLoops.c ? >> I've flicked through a number of the C files in the same location and all look to have the same issue. >> >> -phil. >> >> On 04/21/2016 06:33 AM, Ajit Ghaisas wrote: >>>>> On 04/20/2016 12:27 PM, Sergey Bylokhov wrote: >>>>> 2d-dev added. >>>> In fact all these are 2D. No AWT warnings here. >>>>> I am not sure but why "declaration in the code" is a bad thing and >>>>> we should fix it? >>>>> - DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE >>>>> >>>>> I cannot find the documentation in solaris studio for this warning. >>>> I don't mind fixing it if it is still an issue but does the current compiler actually complain about it ? >>>> The SS11 -> SS12 upgrade might have got a more modern C compiler .. >>> [Ajit ] Yes. The Solaris compiler still complains about this declaration in code. Hence, I have fixed the reported warnings after removing the suppression from makefile. >>> >>>>> On 20.04.16 11:57, Ajit Ghaisas wrote: >>>>>> Hi, >>>>>> >>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8074829 >>>>>> This bug is to remove warning suppressions from makefile and >>>>>> fix the warnings for libawt_headless library. >>>>>> >>>>>> I have removed following warning suppressions & fixed the >>>>>> warnings for libawt_headless library. >>>>>> DISABLED_WARNINGS_gcc := maybe-uninitialized >>>>>> int-to-pointer-cast >>>> What made that one go away ?? >>> [Ajit] : I fixed warnings reported for 'maybe-uninitialized' and 'E_DECLARATION_IN_CODE' warning types in two .c files in webrev. >>> There was no warning after removal of 'int-to-pointer-cast' suppression from makefile. No code change was made for this type of warning. >>> >>> >>>>>> DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE >>>>>> >>>>>> Warning suppression that cannot be removed : >>>>>> DISABLED_WARNINGS_solstudio := E_EMPTY_TRANSLATION_UNIT >>>>>> This is due to the fact that - >>>>>> jdk/src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops >>>>>> .c file becomes empty file in case of HEADLESS mode compilation. >>>> Sigh .. there ought to be "informational" warnings as well as "risky practice" warnings and this should be in the former category. >>>> You could move something like the jni.h and jlong.h imports outside to see if that shuts it up. >>>> Not saying that is what we want to do but it would be interesting to check. >>> [Ajit] : Nope. Moving jni.h or jlong.h inclusions outside #ifndef HEADLESS did not help. We still get E_EMPTY_TRANSLATION_UNIT warning. >>> To get rid of this warning, there are suggestions to make a typedef - and not use it anywhere - but, I would rather keep the suppression in makefile than defining a typedef without actual usage. >>> Another solution is to exclude this file from HEADLESS compilation. I am not sure how to achieve it. Any suggestion? >>> >>> >>>> -phil. >>>>>> Request you to review following webrev : >>>>>> http://cr.openjdk.java.net/~aghaisas/8074829/webrev.00/ >>>>>> >>>>>> Regards, >>>>>> Ajit From philip.race at oracle.com Thu Jun 2 17:20:11 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 02 Jun 2016 10:20:11 -0700 Subject: [OpenJDK 2D-Dev] Fix for JDK-8074829 : Resolve disabled warnings for libawt_headless In-Reply-To: <24342d75-e133-46ff-959f-9d3e2a6b3a8c@default> References: <5717D829.8070704@oracle.com> <5717E448.7000003@oracle.com> <48002ede-2af9-4bf2-bb32-f38114ea438b@default> <57193461.1090904@oracle.com> <574DBD23.7060608@oracle.com> <24342d75-e133-46ff-959f-9d3e2a6b3a8c@default> Message-ID: <57506ACB.2050106@oracle.com> +1 -phil. On 06/02/2016 09:10 AM, Ajit Ghaisas wrote: > Hi, > > I faced merge issues while getting the webrev.00 committed. > > I have taken the latest code and merged webrev.00 changes on top of it to generate webrev.01. > > Here is the updated webrev. > http://cr.openjdk.java.net/~aghaisas/8074829/webrev.01/ > > The changes are exactly the same between webrev.00 & webrev.01. > Request you to kindly review and approve again. > > Regards, > Ajit > > -----Original Message----- > From: Phil Race > Sent: Tuesday, May 31, 2016 10:05 PM > To: Ajit Ghaisas > Cc: Sergey Bylokhov; 2d-dev; build-dev at openjdk.java.net > Subject: Re: Fix for JDK-8074829 : Resolve disabled warnings for libawt_headless > > +1 given your off-list confirmation that JPRT built all combinations of > platforms it can .. > > -phil. > > On 04/28/2016 05:44 AM, Ajit Ghaisas wrote: >> Hi, >> >> I tried excluding files under directory : jdk/src/java.desktop/share/native/common/java2d/opengl from libawt_headless. >> It resulted in compilation errors - as the headers in this directory (and under sub-directory J2D_GL) are used in other places. >> >> To Phil's question on - why I mentioned only OGLBlitLoops.c file? - this is the file where warning is reported and build stopped. >> >> Hence, I propose not to remove the suppression of warning E_EMPTY_TRANSLATION_UNIT in make file for Solaris. >> There is no change in original webrev : http://cr.openjdk.java.net/~aghaisas/8074829/webrev.00/ >> >> Based on Erik's suggestion, I have built it for arm and arm64 with no errors. >> >> Regards, >> Ajit >> >> -----Original Message----- >> From: Phil Race >> Sent: Friday, April 22, 2016 1:43 AM >> To: Ajit Ghaisas >> Cc: Sergey Bylokhov; 2d-dev; build-dev at openjdk.java.net >> Subject: Re: Fix for JDK-8074829 : Resolve disabled warnings for libawt_headless >> >> > Another solution is to exclude this file from HEADLESS compilation. >> > I am not sure how to achieve it. Any suggestion? >> >> I suppose that is possible and I expect we can do that See in the make file, where I think you just need to add entries to >> LIBAWT_HEADLESS_EXCLUDES := medialib >> >> although I have not tried it. >> Hmm .. I wonder why medialib needs to be explicitly excluded from headless ? .. but that is for another day. >> >> I have another question: why do you mention only OGLBlitLoops.c ? >> I've flicked through a number of the C files in the same location and all look to have the same issue. >> >> -phil. >> >> On 04/21/2016 06:33 AM, Ajit Ghaisas wrote: >>>>> On 04/20/2016 12:27 PM, Sergey Bylokhov wrote: >>>>> 2d-dev added. >>>> In fact all these are 2D. No AWT warnings here. >>>>> I am not sure but why "declaration in the code" is a bad thing and >>>>> we should fix it? >>>>> - DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE >>>>> >>>>> I cannot find the documentation in solaris studio for this warning. >>>> I don't mind fixing it if it is still an issue but does the current compiler actually complain about it ? >>>> The SS11 -> SS12 upgrade might have got a more modern C compiler .. >>> [Ajit ] Yes. The Solaris compiler still complains about this declaration in code. Hence, I have fixed the reported warnings after removing the suppression from makefile. >>> >>>>> On 20.04.16 11:57, Ajit Ghaisas wrote: >>>>>> Hi, >>>>>> >>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8074829 >>>>>> This bug is to remove warning suppressions from makefile and >>>>>> fix the warnings for libawt_headless library. >>>>>> >>>>>> I have removed following warning suppressions & fixed the >>>>>> warnings for libawt_headless library. >>>>>> DISABLED_WARNINGS_gcc := maybe-uninitialized >>>>>> int-to-pointer-cast >>>> What made that one go away ?? >>> [Ajit] : I fixed warnings reported for 'maybe-uninitialized' and 'E_DECLARATION_IN_CODE' warning types in two .c files in webrev. >>> There was no warning after removal of 'int-to-pointer-cast' suppression from makefile. No code change was made for this type of warning. >>> >>> >>>>>> DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE >>>>>> >>>>>> Warning suppression that cannot be removed : >>>>>> DISABLED_WARNINGS_solstudio := E_EMPTY_TRANSLATION_UNIT >>>>>> This is due to the fact that - >>>>>> jdk/src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops >>>>>> .c file becomes empty file in case of HEADLESS mode compilation. >>>> Sigh .. there ought to be "informational" warnings as well as "risky practice" warnings and this should be in the former category. >>>> You could move something like the jni.h and jlong.h imports outside to see if that shuts it up. >>>> Not saying that is what we want to do but it would be interesting to check. >>> [Ajit] : Nope. Moving jni.h or jlong.h inclusions outside #ifndef HEADLESS did not help. We still get E_EMPTY_TRANSLATION_UNIT warning. >>> To get rid of this warning, there are suggestions to make a typedef - and not use it anywhere - but, I would rather keep the suppression in makefile than defining a typedef without actual usage. >>> Another solution is to exclude this file from HEADLESS compilation. I am not sure how to achieve it. Any suggestion? >>> >>> >>>> -phil. >>>>>> Request you to review following webrev : >>>>>> http://cr.openjdk.java.net/~aghaisas/8074829/webrev.00/ >>>>>> >>>>>> Regards, >>>>>> Ajit From philip.race at oracle.com Thu Jun 2 17:28:08 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 02 Jun 2016 10:28:08 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods In-Reply-To: <2e485b6b-3df0-41db-ba40-a96528883e95@default> References: <6f83b633-3910-47fa-b872-e042fe4c24d3@default> <24ca2994-aa27-4a70-8cf9-0bda35664f3f@default> <574809B2.5040901@oracle.com> <9f641938-f979-4021-9e94-bde47e1d3c67@default> <57489033.7020901@oracle.com> <77d5b327-066b-4d86-a44d-8e681aeb71f8@default> <574DE3F9.40709@oracle.com> <574E0717.5060405@oracle.com> <574E0DF9.20508@oracle.com> <574E10B0.4070003@oracle.com> <574E13BD.9060701@oracle.com> <9a87056b-2646-4d5f-bfec-d50bea489381@default> <574F0EFE.2070300@oracle.com> <2e485b6b-3df0-41db-ba40-a96528883e95@default> Message-ID: <57506CA8.3040608@oracle.com> +1 -phil. On 06/02/2016 07:07 AM, Jayathirth D V wrote: > Hi Phil, > > I have updated the code with all the changes I mentioned previously. I am caching hashCode when first time hashCode() is called. > Please find the updated webrev for review: > http://cr.openjdk.java.net/~jdv/7107905/webrev.09/ > > Thanks, > Jay > > -----Original Message----- > From: Philip Race > Sent: Wednesday, June 01, 2016 10:06 PM > To: Jayathirth D V > Cc: Jim Graham; 2d-dev at openjdk.java.net > Subject: Re: Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods > > Please post the updated webrev. > > -phil. > > On 6/1/16, 12:02 AM, Jayathirth D V wrote: >> Hi Phil& Jim, >> >> Collating all the changes needed: >> 1) I have removed both equals()& hashCode() in CCM but forgot to add the file while creating webrev. I will include changes in CCM in updated webrev. >> 2) Caching of hashCode value in IndexColorModel& PackedColorModel : >> We can cache hashCode value when constructor is called or when hashCode() is called for first time. What approach we have to follow? >> 3) Comment section of equals() method, I will update it to : >> 1449 * the target object must be the same class (and not a subclass) as this >> 4) I will use .equals() to compare colorSpace values in CM.equals() so it will be like we are not intending ColorSpace class to never override equals() method. >> >> Please let me know your inputs. >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Wednesday, June 01, 2016 4:14 AM >> To: Phil Race >> Cc: Jayathirth D V; 2d-dev at openjdk.java.net >> Subject: Re: Review Request for JDK-7107905: ColorModel subclasses are >> missing hashCode() or equals() or both methods >> >> I think we should use .equals() here, otherwise it looks like a recommendation that the intent is for those classes to never implement it... >> >> ...jim >> >> On 05/31/2016 03:31 PM, Phil Race wrote: >>> I don't know of any design intent, so yes, I meant more as a >>> practical matter. >>> Unless they subclass then using equals() which I thought unlikely it >>> makes no difference here. >>> But it would be proof against that to use equals, unlikely to matter >>> as it might be .. >>> >>> -phil. >>> >>> On 05/31/2016 03:19 PM, Jim Graham wrote: >>>> On 05/31/2016 02:50 PM, Phil Race wrote: >>>>> On 05/31/2016 12:20 PM, Jim Graham wrote: >>>>>> Hi Jay, >>>>>> >>>>>> You were going to remove hashCode/equals from CCM, but instead you >>>>>> simply removed it from the patch. You still need to edit it to >>>>>> remove the existing methods. >>>>> Oh yeah ! CCM is gone from the latest webrev. I expect that was not >>>>> intentional. >>>>> >>>>>> Also, I'm not sure == is a good way to compare ColorSpace >>>>>> instances >>>>>> - Phil? >>>>> Neither ColorSpace nor ICC_ColorSpace over-ride equals or hashCode >>>>> and all the predefined ones are constructed as singletons so it >>>>> seems unlikely to cause problems >>>> Should it use .equals() on principle, though? Otherwise we are >>>> baking in the assumption that it doesn't implement equals() into our >>>> implementation of the CM.equals() method. Might it some day >>>> implement equals (perhaps it isn't a practical issue today, but it >>>> might be in the future when we forget that it was omitted in this >>>> usage we create today). >>>> >>>> I guess what I'm asking is if it is a design feature that different >>>> objects are considered non-equal (such as an object that, for >>>> instance, has only predetermined instances that are shared by >>>> reference and reused). I think color spaces are sort of in-between >>>> in that we define a few constants that simply get used by reference >>>> in 99% of cases, but that isn't a design feature, more like a >>>> practical issue... >>>> >>>> ...jim From Sergey.Bylokhov at oracle.com Thu Jun 2 17:36:50 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 2 Jun 2016 20:36:50 +0300 Subject: [OpenJDK 2D-Dev] Fix for JDK-8074829 : Resolve disabled warnings for libawt_headless In-Reply-To: <57506ACB.2050106@oracle.com> References: <5717D829.8070704@oracle.com> <5717E448.7000003@oracle.com> <48002ede-2af9-4bf2-bb32-f38114ea438b@default> <57193461.1090904@oracle.com> <574DBD23.7060608@oracle.com> <24342d75-e133-46ff-959f-9d3e2a6b3a8c@default> <57506ACB.2050106@oracle.com> Message-ID: <172bb3b8-734b-ba2e-bb92-24c5351ea9b9@oracle.com> +1 On 02.06.16 20:20, Phil Race wrote: > +1 > > -phil. > > On 06/02/2016 09:10 AM, Ajit Ghaisas wrote: >> Hi, >> >> I faced merge issues while getting the webrev.00 committed. >> I have taken the latest code and merged webrev.00 changes on >> top of it to generate webrev.01. >> >> Here is the updated webrev. >> http://cr.openjdk.java.net/~aghaisas/8074829/webrev.01/ >> >> The changes are exactly the same between webrev.00 & webrev.01. >> Request you to kindly review and approve again. >> >> Regards, >> Ajit >> >> -----Original Message----- >> From: Phil Race >> Sent: Tuesday, May 31, 2016 10:05 PM >> To: Ajit Ghaisas >> Cc: Sergey Bylokhov; 2d-dev; build-dev at openjdk.java.net >> Subject: Re: Fix for JDK-8074829 : Resolve disabled warnings >> for libawt_headless >> >> +1 given your off-list confirmation that JPRT built all combinations of >> platforms it can .. >> >> -phil. >> >> On 04/28/2016 05:44 AM, Ajit Ghaisas wrote: >>> Hi, >>> >>> I tried excluding files under directory : >>> jdk/src/java.desktop/share/native/common/java2d/opengl from >>> libawt_headless. >>> It resulted in compilation errors - as the headers in this >>> directory (and under sub-directory J2D_GL) are used in other places. >>> To Phil's question on - why I mentioned only >>> OGLBlitLoops.c file? - this is the file where warning is reported and >>> build stopped. >>> Hence, I propose not to remove the suppression of >>> warning E_EMPTY_TRANSLATION_UNIT in make file for Solaris. >>> There is no change in original webrev : >>> http://cr.openjdk.java.net/~aghaisas/8074829/webrev.00/ >>> >>> Based on Erik's suggestion, I have built it for arm and arm64 >>> with no errors. >>> >>> Regards, >>> Ajit >>> >>> -----Original Message----- >>> From: Phil Race >>> Sent: Friday, April 22, 2016 1:43 AM >>> To: Ajit Ghaisas >>> Cc: Sergey Bylokhov; 2d-dev; build-dev at openjdk.java.net >>> Subject: Re: Fix for JDK-8074829 : Resolve disabled >>> warnings for libawt_headless >>> >>> > Another solution is to exclude this file from HEADLESS >>> compilation. >>> > I am not sure how to achieve it. Any suggestion? >>> >>> I suppose that is possible and I expect we can do that See in the >>> make file, where I think you just need to add entries to >>> LIBAWT_HEADLESS_EXCLUDES := medialib >>> >>> although I have not tried it. >>> Hmm .. I wonder why medialib needs to be explicitly excluded from >>> headless ? .. but that is for another day. >>> >>> I have another question: why do you mention only OGLBlitLoops.c ? >>> I've flicked through a number of the C files in the same location and >>> all look to have the same issue. >>> >>> -phil. >>> >>> On 04/21/2016 06:33 AM, Ajit Ghaisas wrote: >>>>>> On 04/20/2016 12:27 PM, Sergey Bylokhov wrote: >>>>>> 2d-dev added. >>>>> In fact all these are 2D. No AWT warnings here. >>>>>> I am not sure but why "declaration in the code" is a bad thing and >>>>>> we should fix it? >>>>>> - DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE >>>>>> >>>>>> I cannot find the documentation in solaris studio for this warning. >>>>> I don't mind fixing it if it is still an issue but does the current >>>>> compiler actually complain about it ? >>>>> The SS11 -> SS12 upgrade might have got a more modern C compiler .. >>>> [Ajit ] Yes. The Solaris compiler still complains about this >>>> declaration in code. Hence, I have fixed the reported warnings after >>>> removing the suppression from makefile. >>>> >>>>>> On 20.04.16 11:57, Ajit Ghaisas wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8074829 >>>>>>> This bug is to remove warning suppressions from makefile and >>>>>>> fix the warnings for libawt_headless library. >>>>>>> >>>>>>> I have removed following warning suppressions & fixed the >>>>>>> warnings for libawt_headless library. >>>>>>> DISABLED_WARNINGS_gcc := maybe-uninitialized >>>>>>> int-to-pointer-cast >>>>> What made that one go away ?? >>>> [Ajit] : I fixed warnings reported for 'maybe-uninitialized' and >>>> 'E_DECLARATION_IN_CODE' warning types in two .c files in webrev. >>>> There was no warning after removal of 'int-to-pointer-cast' >>>> suppression from makefile. No code change was made for this type of >>>> warning. >>>> >>>> >>>>>>> DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE >>>>>>> >>>>>>> Warning suppression that cannot be removed : >>>>>>> DISABLED_WARNINGS_solstudio := E_EMPTY_TRANSLATION_UNIT >>>>>>> This is due to the fact that - >>>>>>> jdk/src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops >>>>>>> .c file becomes empty file in case of HEADLESS mode compilation. >>>>> Sigh .. there ought to be "informational" warnings as well as >>>>> "risky practice" warnings and this should be in the former category. >>>>> You could move something like the jni.h and jlong.h imports outside >>>>> to see if that shuts it up. >>>>> Not saying that is what we want to do but it would be interesting >>>>> to check. >>>> [Ajit] : Nope. Moving jni.h or jlong.h inclusions outside #ifndef >>>> HEADLESS did not help. We still get E_EMPTY_TRANSLATION_UNIT warning. >>>> To get rid of this warning, there are suggestions to make a typedef >>>> - and not use it anywhere - but, I would rather keep the suppression >>>> in makefile than defining a typedef without actual usage. >>>> Another solution is to exclude this file from HEADLESS compilation. >>>> I am not sure how to achieve it. Any suggestion? >>>> >>>> >>>>> -phil. >>>>>>> Request you to review following webrev : >>>>>>> http://cr.openjdk.java.net/~aghaisas/8074829/webrev.00/ >>>>>>> >>>>>>> Regards, >>>>>>> Ajit > -- Best regards, Sergey. From philip.race at oracle.com Thu Jun 2 17:41:32 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 02 Jun 2016 10:41:32 -0700 Subject: [OpenJDK 2D-Dev] Review request for: JDK-8158495 CCE: sun.java2d.NullSurfaceData cannot be cast to sun.java2d.opengl.OGLSurfaceData In-Reply-To: <0F380F61-7EC2-43F0-B0AA-2D79D4C9E9CD@jetbrains.com> References: <0F380F61-7EC2-43F0-B0AA-2D79D4C9E9CD@jetbrains.com> Message-ID: <57506FCC.4090402@oracle.com> +1 -phil. On 06/02/2016 08:07 AM, Alexey Ushakov wrote: > Hello Phil and Sergey, > > Here is one more fix of the > ClassCastException for invalid surface that we?ve recently got in our products. I?ve updated Sergey?s test so it goes through the problematic code. Unfortunately, I was unable to reproduce the problem by myself (The actual issue was reported only by our customers) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8158495 > Webrev: http://cr.openjdk.java.net/~avu/JDK-8158495/webrev.00 > > Best Regards, > Alexey From Sergey.Bylokhov at oracle.com Thu Jun 2 18:42:25 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 2 Jun 2016 21:42:25 +0300 Subject: [OpenJDK 2D-Dev] Review request for: JDK-8158495 CCE: sun.java2d.NullSurfaceData cannot be cast to sun.java2d.opengl.OGLSurfaceData In-Reply-To: <0F380F61-7EC2-43F0-B0AA-2D79D4C9E9CD@jetbrains.com> References: <0F380F61-7EC2-43F0-B0AA-2D79D4C9E9CD@jetbrains.com> Message-ID: <07ee68ba-eddf-1905-a6b8-f3f08f4040e2@oracle.com> Hi, Alexey. The code in OGLMaskFill.java is mirrored in D3DMaskFill for d3d, I think it should be updated also. It seems these files follow the rule: "80 chars per line", it will be good to do the same in the fix. On 02.06.16 18:07, Alexey Ushakov wrote: > Hello Phil and Sergey, > > Here is one more fix of the > ClassCastException for invalid surface that we?ve recently got in our products. I?ve updated Sergey?s test so it goes through the problematic code. Unfortunately, I was unable to reproduce the problem by myself (The actual issue was reported only by our customers) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8158495 > Webrev: http://cr.openjdk.java.net/~avu/JDK-8158495/webrev.00 > > Best Regards, > Alexey > -- Best regards, Sergey. From james.graham at oracle.com Thu Jun 2 20:54:54 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 2 Jun 2016 13:54:54 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods In-Reply-To: <2e485b6b-3df0-41db-ba40-a96528883e95@default> References: <6f83b633-3910-47fa-b872-e042fe4c24d3@default> <24ca2994-aa27-4a70-8cf9-0bda35664f3f@default> <574809B2.5040901@oracle.com> <9f641938-f979-4021-9e94-bde47e1d3c67@default> <57489033.7020901@oracle.com> <77d5b327-066b-4d86-a44d-8e681aeb71f8@default> <574DE3F9.40709@oracle.com> <574E0717.5060405@oracle.com> <574E0DF9.20508@oracle.com> <574E10B0.4070003@oracle.com> <574E13BD.9060701@oracle.com> <9a87056b-2646-4d5f-bfec-d50bea489381@default> <574F0EFE.2070300@oracle.com> <2e485b6b-3df0-41db-ba40-a96528883e95@default> Message-ID: <20a4c021-6814-9423-2891-c45c1ab94396@oracle.com> I just noticed a hashCode/equals violation that we created a few revisions ago. We compute the hash of the validBits in ICM, but we only compare validBits up to the number of colors in the colormap. One could construct two ICMs that have different validBits that are identical in the first N bits (N = number of colors), but have different bits beyond that, and those 2 ICMs would evaluate as equals(), but their hashcodes would be different. Possible solutions: - Truncate validBits when it is accepted in the constructor (validBits.and(...)) - Manually compute the hash of the first N bits of validBits - Not use validBits in the hash code since it is allowed to omit significant data from the hash (Note that everything in hashcode must participate in equals(), but not vice versa) The same is true of nBits in ColorModel. (nBits can be copied and truncated with Arrays.copyOf) The same is *not* true of maskBits in PCM since the constructor creates an array of the precise length it needs... ...jim On 6/2/16 7:07 AM, Jayathirth D V wrote: > Hi Phil, > > I have updated the code with all the changes I mentioned previously. I am caching hashCode when first time hashCode() is called. > Please find the updated webrev for review: > http://cr.openjdk.java.net/~jdv/7107905/webrev.09/ > > Thanks, > Jay > > -----Original Message----- > From: Philip Race > Sent: Wednesday, June 01, 2016 10:06 PM > To: Jayathirth D V > Cc: Jim Graham; 2d-dev at openjdk.java.net > Subject: Re: Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods > > Please post the updated webrev. > > -phil. > > On 6/1/16, 12:02 AM, Jayathirth D V wrote: >> Hi Phil& Jim, >> >> Collating all the changes needed: >> 1) I have removed both equals()& hashCode() in CCM but forgot to add the file while creating webrev. I will include changes in CCM in updated webrev. >> 2) Caching of hashCode value in IndexColorModel& PackedColorModel : >> We can cache hashCode value when constructor is called or when hashCode() is called for first time. What approach we have to follow? >> 3) Comment section of equals() method, I will update it to : >> 1449 * the target object must be the same class (and not a subclass) as this >> 4) I will use .equals() to compare colorSpace values in CM.equals() so it will be like we are not intending ColorSpace class to never override equals() method. >> >> Please let me know your inputs. >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Wednesday, June 01, 2016 4:14 AM >> To: Phil Race >> Cc: Jayathirth D V; 2d-dev at openjdk.java.net >> Subject: Re: Review Request for JDK-7107905: ColorModel subclasses are >> missing hashCode() or equals() or both methods >> >> I think we should use .equals() here, otherwise it looks like a recommendation that the intent is for those classes to never implement it... >> >> ...jim >> >> On 05/31/2016 03:31 PM, Phil Race wrote: >>> I don't know of any design intent, so yes, I meant more as a >>> practical matter. >>> Unless they subclass then using equals() which I thought unlikely it >>> makes no difference here. >>> But it would be proof against that to use equals, unlikely to matter >>> as it might be .. >>> >>> -phil. >>> >>> On 05/31/2016 03:19 PM, Jim Graham wrote: >>>> >>>> On 05/31/2016 02:50 PM, Phil Race wrote: >>>>> On 05/31/2016 12:20 PM, Jim Graham wrote: >>>>>> Hi Jay, >>>>>> >>>>>> You were going to remove hashCode/equals from CCM, but instead you >>>>>> simply removed it from the patch. You still need to edit it to >>>>>> remove the existing methods. >>>>> Oh yeah ! CCM is gone from the latest webrev. I expect that was not >>>>> intentional. >>>>> >>>>>> Also, I'm not sure == is a good way to compare ColorSpace >>>>>> instances >>>>>> - Phil? >>>>> Neither ColorSpace nor ICC_ColorSpace over-ride equals or hashCode >>>>> and all the predefined ones are constructed as singletons so it >>>>> seems unlikely to cause problems >>>> Should it use .equals() on principle, though? Otherwise we are >>>> baking in the assumption that it doesn't implement equals() into our >>>> implementation of the CM.equals() method. Might it some day >>>> implement equals (perhaps it isn't a practical issue today, but it >>>> might be in the future when we forget that it was omitted in this >>>> usage we create today). >>>> >>>> I guess what I'm asking is if it is a design feature that different >>>> objects are considered non-equal (such as an object that, for >>>> instance, has only predetermined instances that are shared by >>>> reference and reused). I think color spaces are sort of in-between >>>> in that we define a few constants that simply get used by reference >>>> in 99% of cases, but that isn't a design feature, more like a >>>> practical issue... >>>> >>>> ...jim From james.graham at oracle.com Thu Jun 2 21:17:45 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 2 Jun 2016 14:17:45 -0700 Subject: [OpenJDK 2D-Dev] Fix for JDK-8139192 : Custom ImageFilters return blank images in Java 8(.45) while working in 7 In-Reply-To: <4942199a-5642-47c2-98fc-5f085ba079b3@default> References: <480a1ef0-30e5-e1ed-8def-e28f383949ac@oracle.com> <958c83a7-1a72-a5cf-0b3b-8479efee5974@oracle.com> <6d79d18b-3854-402c-9981-38ed2e0f161a@default> <2d10a7cc-51e5-50dc-1a66-33f94679e067@oracle.com> <4f6cae95-0552-4507-942a-e0f2e9beb3be@default> <574DCB17.3070306@oracle.com> <574DE61F.30607@oracle.com> <74c0b159-895e-c6c4-67ae-e470d7055251@oracle.com> <544e09c0-79d9-4606-973e-d03259b68362@default> <0849286c-0b7e-964e-85ef-41de34e5a60a@oracle.com> <4942199a-5642-47c2-98fc-5f085ba079b3@default> Message-ID: Looks good! ...jim On 6/2/16 2:51 AM, Ajit Ghaisas wrote: > Thanks Jim and Phil for reviewing this. > > Adding a comment is a good suggestion. I have added it and requested a push of following webrev- > http://cr.openjdk.java.net/~aghaisas/8139192/webrev.04/ > (Sent here for a reference) > > Regards, > Ajit > > > > -----Original Message----- > From: Jim Graham > Sent: Thursday, June 02, 2016 2:54 AM > To: Ajit Ghaisas; Philip Race; Sergey Bylokhov; 2d-dev > Subject: Re: [OpenJDK 2D-Dev] Fix for JDK-8139192 : Custom ImageFilters return blank images in Java 8(.45) while working in 7 > > +1. > > If you wanted to add a comment on the new catch, you could say: > > } catch (RuntimeException e) { > // We did not previously call this method here and some filters > // were not prepared for it to be called at this time so we > // allow them to have runtime issues for this one call only > // without triggering the ERROR condition below. > ... (printstack) > } > > Your call, I don't need to approve a webrev for that comment addition... > > ...jim > > On 6/1/16 3:28 AM, Ajit Ghaisas wrote: >> Thanks Jim and Phil for valuable feedback and suggestions. >> >> The detailed discussion helped me to understand why catching RuntimeException is a better option for a call to imageComplete(STATICIMAGEDONE). >> I have modified the code on line 192 accordingly. >> >> I have not modified the code catching NullPointerException (on line 196) as doing so would mask a wider variety of legitimate exceptions. So, line 196 remains unchanged. >> >> I have also modified the test to throw NullPointerException instead of calling intValue() on a null. >> >> Please review updated webrev : >> http://cr.openjdk.java.net/~aghaisas/8139192/webrev.03/ >> >> Regards, >> Ajit >> >> -----Original Message----- >> From: Phil Race >> Sent: Wednesday, June 01, 2016 1:41 AM >> To: Jim Graham; Ajit Ghaisas >> Cc: Sergey Bylokhov; 2d-dev >> Subject: Re: [OpenJDK 2D-Dev] Fix for JDK-8139192 : Custom >> ImageFilters return blank images in Java 8(.45) while working in 7 >> >> I agree with the suggestion of RuntimeException as likely sufficient but not too much ... >> >> -phil. >> >> >> On 5/31/2016 12:29 PM, Jim Graham wrote: >>> I agree with this. It would be nice if we didn't spit out print >>> statements by default, but I'm not sure what a good flag would be to >>> use to diagnose this that balances how likely developers will think >>> to use it. >>> >>> The point about catching a wider variety of exceptions is not that it >>> is good practice in general, but we've added a new call to a >>> long-standing algorithm which has decades (really? plural? pretty >>> much, I think) of past code that isn't expecting the new call, and >>> that call is basically "informative" not something that they really >>> need to successfully handle, so just as someone might accidentally >>> process a null pointer in a case like that, someone else might run >>> off the end of an array (AIOOB) or any other "I wasn't expecting that" >>> sort of issue. >>> >>> Throwable might be a bit much, though. Phil? I was thinking >>> Exception because those tend to focus on "your code made a mistake" >>> whereas Error is something like "you are mix/matching incompatible >>> code that was compiled to contain conflicting information" (kind of >>> like calling a method that doesn't exist in this release, etc.). >>> It's hard to say what the proper level of forgiveness should be here. >>> Another thought is "RuntimeException", since any other exception >>> would need to be declared to be thrown and we don't declare it for >>> that method, so their implementation shouldn't be allowed to declare >>> it either... >>> >>> ...jim >>> >>> On 05/31/2016 10:34 AM, Phil Race wrote: >>>> Based on what Ajit wrote in the bug report, he at least found a jar >>>> file that contains this code, but I have so far failed to locate the >>>> source code as all the versions I find on the net use the Java 2D >>>> JDK 1.2 BufferedImageOp APIs so I suspect this bug is in a very old >>>> version and it may not be open source. >>>> Therefore I am not sure how much e.printStackTrace() will help them >>>> if they don't own that source except to encourage them to upgrade. >>>> I'd be inclined to stick it behind a debugging property if we have >>>> one that we could re-use except that in such a case they probably >>>> won't know enough to set the property. >>>> So on balance it is probably best to do as it has been presented >>>> here except that catch (Throwable t) probably makes sense as we >>>> don't want to revisit this for a different exception. >>>> >>>> Minor nit about the test: instead of calling intValue() on a null >>>> Integer, why not just "throw new NullPointerException("reason ..") ? >>>> >>>> >>>> -phil. >>>> >>>> >>>> >>>> >>>> >>>> On 05/30/2016 01:22 AM, Ajit Ghaisas wrote: >>>>> I did contemplate catching 'Exception' instead of >>>>> 'NullPointerException' while raising the webrev, but decided not to >>>>> do it as- 1. Complaint in current image filter was due to NPE only >>>>> 2. Catching & consuming generic exception does not seem quite >>>>> correct here as we are just printing stack trace and not taking any >>>>> concrete action. >>>>> 3. There is no reported issue of any other type of Exception out of >>>>> this method. >>>>> >>>>> Regards, >>>>> Ajit >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Jim Graham >>>>> Sent: Saturday, May 28, 2016 4:41 AM >>>>> To: Ajit Ghaisas; Sergey Bylokhov; 2d-dev; Philip Race >>>>> Subject: Re: [OpenJDK 2D-Dev] Fix for JDK-8139192 : Custom >>>>> ImageFilters return blank images in Java 8(.45) while working in 7 >>>>> >>>>> That looks good, but I wonder if it should catch all exceptions >>>>> instead of just NPE. Historically we were only catching NPE before >>>>> we added the call to STATICIMAGEDONE, and the current filter in >>>>> question turns out to throw an NPE, but if a filter that was >>>>> commonly used with offscreen images was not expecting the >>>>> STATICIMAGEDONE as was this WaterFilter, then they could >>>>> potentially throw a wider variety of exceptions. >>>>> >>>>> I'm good with NPE since that is the only case we've seen, but I'd >>>>> also be good with changing line 192 to catch all exceptions. Phil? >>>>> >>>>> ...jim >>>>> >>>>> On 5/27/16 1:32 AM, Ajit Ghaisas wrote: >>>>>> Hi Jim, >>>>>> >>>>>> Thanks for in-depth analysis and detailed review. >>>>>> I appreciate your concern for filtered image being blank in >>>>>> Java 8, while it used to work in Java 7. >>>>>> >>>>>> Yes. I totally agree with your suggestion to do both - >>>>>> 1. Not send IMAGEERROR if there is exception from ImageFilter >>>>>> while processing STATICIMAGE done >>>>>> 2. At the same time, as we are consuming the exception, show >>>>>> the exception stacktrace. >>>>>> >>>>>> With this fix the functionality of >>>>>> com.jhlabs.image.WaterFilter is restored. It does not return blank images anymore. >>>>>> Also, as additional information, exception details are shown >>>>>> as a stacktrace. >>>>>> >>>>>> Please review the updated webrev : >>>>>> http://cr.openjdk.java.net/~aghaisas/8139192/webrev.02/ >>>>>> >>>>>> Regards, >>>>>> Ajit >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Jim Graham >>>>>> Sent: Thursday, May 26, 2016 4:57 AM >>>>>> To: Sergey Bylokhov; Ajit Ghaisas; 2d-dev; Philip Race >>>>>> Subject: Re: [OpenJDK 2D-Dev] Fix for JDK-8139192 : Custom >>>>>> ImageFilters return blank images in Java 8(.45) while working in 7 >>>>>> >>>>>> Their complaint is that the resulting image is empty - most likely >>>>>> because the error gets passed through and clears the image buffer. >>>>>> It appears that the sequence of events is: >>>>>> >>>>>> We send SINGLEFRAMEDONE. >>>>>> - the image is displayable >>>>>> We send STATICIMAGEDONE. >>>>>> - filter throws NPE >>>>>> - image is probably still displayable We send ERROR >>>>>> - if it gets passed through to the toolkit image consumer then >>>>>> we'll clear the image buffer >>>>>> - image is no longer displayable >>>>>> >>>>>> It's hard to say for sure without having an instance of their >>>>>> filter in-house for testing, but previously we weren't sending the >>>>>> STATICDONE notice and the program was working just fine. Since the >>>>>> NPE comes from their code when we send it, it shouldn't have >>>>>> affected any down-stream consumers, so we should be OK with just >>>>>> continuing on and the image should still be displayable just as if >>>>>> we hadn't sent the STATICDONE notice in the first place. >>>>>> >>>>>> Now, *during debugging*, they were thwarted by the fact that we >>>>>> ate the exception, true, but the original issue is that the image >>>>>> wasn't displayable at all. We might want to do both: >>>>>> >>>>>> - not send ERROR for STATICDONE when we used to not send >>>>>> STATICDONE at all >>>>>> - show the exception so that someone realizes that there is a >>>>>> problem, even though we've made it not hurt their functionality. >>>>>> >>>>>> Does that make sense? >>>>>> >>>>>> ...jim >>>>>> >>>>>> On 5/25/2016 1:36 PM, Sergey Bylokhov wrote: >>>>>>> On 25.05.16 23:33, Jim Graham wrote: >>>>>>>> How about option 3 - >>>>>>>> >>>>>>>> NPE before imageComplete sends an ERROR as it does now. >>>>>>>> >>>>>>>> NPE during imageComplete is ignored, both for backwards >>>>>>>> compatibility and because it is more of a "hint" than an >>>>>>>> operation that requires action from the consumer. >>>>>>> I guess the case is that when we ignore this NPE(w/o any >>>>>>> notification) the users complains that the bug is in jdk. >>>>>>> >>>>>>>> ...jim >>>>>>>> >>>>>>>> On 5/25/2016 1:31 AM, Ajit Ghaisas wrote: >>>>>>>>> Hi >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Bug : >>>>>>>>> >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8139192 >>>>>>>>> >>>>>>>>> Custom ImageFilters return blank images in Java 8(.45) while >>>>>>>>> working in 7 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Root cause : >>>>>>>>> >>>>>>>>> private method produce() in OffScreenImageSource.java consumes >>>>>>>>> a NullPointerException that originates from a custom >>>>>>>>> ImageConsumer (a 3^rd party image library class - >>>>>>>>> com.jhlabs.image.WaterFilter) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Analysis: >>>>>>>>> >>>>>>>>> 1. How the behavior changed between JDK7 and JK8 : >>>>>>>>> >>>>>>>>> A call to imageComplete(ImageConsumer.SINGLEFRAMEDONE) was >>>>>>>>> added in addition to imageComplete(ImageConsumer. >>>>>>>>> STATICIMAGEDONE) as a fix for JDK-7143612. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2. What debugging revealed: >>>>>>>>> >>>>>>>>> A NullPointerException is being thrown from the library during >>>>>>>>> the call to imageComplete(ImageConsumer.STATICIMAGEDONE) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 3. It looks like the fix of JDK-7143612 is valid and successive >>>>>>>>> calls to >>>>>>>>> imageComplete() are allowed. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 4. The 3rd party library behavior appears incorrect (if it can >>>>>>>>> not handle subsequent calls to imageComplete(), it should >>>>>>>>> de-register itself). >>>>>>>>> >>>>>>>>> The 3rd-party library code should be fixed. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Possible modifications in JDK : >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Currently, OffScreenImageSource::produce() consumes the >>>>>>>>> NullPointerException - this is incorrect and results in silent >>>>>>>>> failure of this particular image filter. >>>>>>>>> >>>>>>>>> We need to let the image filter library know that exception has >>>>>>>>> occurred in its code and not in JDK. We have two options - >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Option 1 : Rethrow the NullPointerException --- It is the >>>>>>>>> clearest way >>>>>>>>> to let 3^rd party library know that their code is erroneous >>>>>>>>> with latest JDK. This will change the 3^rd party image filter >>>>>>>>> behavior that generates blank image. >>>>>>>>> >>>>>>>>> Option 2 : Add a stack trace where the exception is being >>>>>>>>> consumed >>>>>>>>> --- Adding stack trace provides more information regarding >>>>>>>>> failure of 3^rd party image filter with retaining the current >>>>>>>>> behavior that generates blank image. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I have implemented both the options: >>>>>>>>> >>>>>>>>> Option 1: >>>>>>>>> http://cr.openjdk.java.net/~aghaisas/8139192/webrev.00/ >>>>>>>>> >>>>>>>>> Option 2: >>>>>>>>> http://cr.openjdk.java.net/~aghaisas/8139192/webrev.01/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Request you to review both the webrevs and provide your preference. >>>>>>>>> >>>>>>>>> I will add a test to the selected webrev. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Ajit >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>> >> From jayathirth.d.v at oracle.com Fri Jun 3 09:49:30 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Fri, 3 Jun 2016 02:49:30 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods In-Reply-To: <20a4c021-6814-9423-2891-c45c1ab94396@oracle.com> References: <6f83b633-3910-47fa-b872-e042fe4c24d3@default> <24ca2994-aa27-4a70-8cf9-0bda35664f3f@default> <574809B2.5040901@oracle.com> <9f641938-f979-4021-9e94-bde47e1d3c67@default> <57489033.7020901@oracle.com> <77d5b327-066b-4d86-a44d-8e681aeb71f8@default> <574DE3F9.40709@oracle.com> <574E0717.5060405@oracle.com> <574E0DF9.20508@oracle.com> <574E10B0.4070003@oracle.com> <574E13BD.9060701@oracle.com> <9a87056b-2646-4d5f-bfec-d50bea489381@default> <574F0EFE.2070300@oracle.com> <2e485b6b-3df0-41db-ba40-a96528883e95@default> <20a4c021-6814-9423-2891-c45c1ab94396@oracle.com> Message-ID: <0042f492-5fc4-481c-8b2d-35a242a5af93@default> Hi Jim, Oh that's an important change. Thanks for your review. I have updated ColorModel constructor to copy nBIts only of numOfComponents length and I have removed validBits check in hashCode() of ICM. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/7107905/webrev.10/ Thanks, Jay -----Original Message----- From: Jim Graham Sent: Friday, June 03, 2016 2:25 AM To: Jayathirth D V; Philip Race Cc: 2d-dev at openjdk.java.net Subject: Re: Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods I just noticed a hashCode/equals violation that we created a few revisions ago. We compute the hash of the validBits in ICM, but we only compare validBits up to the number of colors in the colormap. One could construct two ICMs that have different validBits that are identical in the first N bits (N = number of colors), but have different bits beyond that, and those 2 ICMs would evaluate as equals(), but their hashcodes would be different. Possible solutions: - Truncate validBits when it is accepted in the constructor (validBits.and(...)) - Manually compute the hash of the first N bits of validBits - Not use validBits in the hash code since it is allowed to omit significant data from the hash (Note that everything in hashcode must participate in equals(), but not vice versa) The same is true of nBits in ColorModel. (nBits can be copied and truncated with Arrays.copyOf) The same is *not* true of maskBits in PCM since the constructor creates an array of the precise length it needs... ...jim On 6/2/16 7:07 AM, Jayathirth D V wrote: > Hi Phil, > > I have updated the code with all the changes I mentioned previously. I am caching hashCode when first time hashCode() is called. > Please find the updated webrev for review: > http://cr.openjdk.java.net/~jdv/7107905/webrev.09/ > > Thanks, > Jay > > -----Original Message----- > From: Philip Race > Sent: Wednesday, June 01, 2016 10:06 PM > To: Jayathirth D V > Cc: Jim Graham; 2d-dev at openjdk.java.net > Subject: Re: Review Request for JDK-7107905: ColorModel subclasses are > missing hashCode() or equals() or both methods > > Please post the updated webrev. > > -phil. > > On 6/1/16, 12:02 AM, Jayathirth D V wrote: >> Hi Phil& Jim, >> >> Collating all the changes needed: >> 1) I have removed both equals()& hashCode() in CCM but forgot to add the file while creating webrev. I will include changes in CCM in updated webrev. >> 2) Caching of hashCode value in IndexColorModel& PackedColorModel : >> We can cache hashCode value when constructor is called or when hashCode() is called for first time. What approach we have to follow? >> 3) Comment section of equals() method, I will update it to : >> 1449 * the target object must be the same class (and not a subclass) as this >> 4) I will use .equals() to compare colorSpace values in CM.equals() so it will be like we are not intending ColorSpace class to never override equals() method. >> >> Please let me know your inputs. >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Wednesday, June 01, 2016 4:14 AM >> To: Phil Race >> Cc: Jayathirth D V; 2d-dev at openjdk.java.net >> Subject: Re: Review Request for JDK-7107905: ColorModel subclasses >> are missing hashCode() or equals() or both methods >> >> I think we should use .equals() here, otherwise it looks like a recommendation that the intent is for those classes to never implement it... >> >> ...jim >> >> On 05/31/2016 03:31 PM, Phil Race wrote: >>> I don't know of any design intent, so yes, I meant more as a >>> practical matter. >>> Unless they subclass then using equals() which I thought unlikely it >>> makes no difference here. >>> But it would be proof against that to use equals, unlikely to matter >>> as it might be .. >>> >>> -phil. >>> >>> On 05/31/2016 03:19 PM, Jim Graham wrote: >>>> >>>> On 05/31/2016 02:50 PM, Phil Race wrote: >>>>> On 05/31/2016 12:20 PM, Jim Graham wrote: >>>>>> Hi Jay, >>>>>> >>>>>> You were going to remove hashCode/equals from CCM, but instead >>>>>> you simply removed it from the patch. You still need to edit it >>>>>> to remove the existing methods. >>>>> Oh yeah ! CCM is gone from the latest webrev. I expect that was >>>>> not intentional. >>>>> >>>>>> Also, I'm not sure == is a good way to compare ColorSpace >>>>>> instances >>>>>> - Phil? >>>>> Neither ColorSpace nor ICC_ColorSpace over-ride equals or hashCode >>>>> and all the predefined ones are constructed as singletons so it >>>>> seems unlikely to cause problems >>>> Should it use .equals() on principle, though? Otherwise we are >>>> baking in the assumption that it doesn't implement equals() into >>>> our implementation of the CM.equals() method. Might it some day >>>> implement equals (perhaps it isn't a practical issue today, but it >>>> might be in the future when we forget that it was omitted in this >>>> usage we create today). >>>> >>>> I guess what I'm asking is if it is a design feature that different >>>> objects are considered non-equal (such as an object that, for >>>> instance, has only predetermined instances that are shared by >>>> reference and reused). I think color spaces are sort of in-between >>>> in that we define a few constants that simply get used by reference >>>> in 99% of cases, but that isn't a design feature, more like a >>>> practical issue... >>>> >>>> ...jim From prasanta.sadhukhan at oracle.com Fri Jun 3 11:46:06 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Fri, 3 Jun 2016 17:16:06 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8158520: [TEST_BUG] java/awt/PrintJob/PrinterException.java fails on timeout Message-ID: <3b534145-9c38-51b4-5f3d-12b9c1898373@oracle.com> Hi All, Please review a test bug which was added for bug 7161283. Toolkit.getPrintJob() threw a NPE if no printer was available. Although the testcase was working ok in failure case by throwing NPE, in pass case it was waiting for manual intervention causing jtreg to fail on timeout. Made the testcase automated to use Robot to press Enter as the focus in the dialog is in the "Print" button. Using Robot to press Enter closes the dialog without the need for manual intervention. Tested on windows, linux and mac. Bug: https://bugs.openjdk.java.net/browse/JDK-8158520 webrev: http://cr.openjdk.java.net/~psadhukhan/8158520/webrev.00/ Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Fri Jun 3 12:01:04 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 3 Jun 2016 15:01:04 +0300 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8158520: [TEST_BUG] java/awt/PrintJob/PrinterException.java fails on timeout In-Reply-To: <3b534145-9c38-51b4-5f3d-12b9c1898373@oracle.com> References: <3b534145-9c38-51b4-5f3d-12b9c1898373@oracle.com> Message-ID: <19787936-25a2-692b-c864-34f3680c20ee@oracle.com> Do we really need try to print something or cancel(ESC) will be enough to reproduce the previous bug? On 03.06.16 14:46, prasanta sadhukhan wrote: > Please review a test bug which was added for bug 7161283. > Toolkit.getPrintJob() threw a NPE if no printer was available. > > Although the testcase was working ok in failure case by throwing NPE, in > pass case it was waiting for manual intervention causing jtreg to fail > on timeout. > > Made the testcase automated to use Robot to press Enter as the focus in > the dialog is in the "Print" button. Using Robot to press Enter closes > the dialog without the need for manual intervention. > > Tested on windows, linux and mac. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8158520 > > webrev: http://cr.openjdk.java.net/~psadhukhan/8158520/webrev.00/ > > > Regards > > Prasanta > -- Best regards, Sergey. From alexey.ushakov at jetbrains.com Fri Jun 3 12:16:32 2016 From: alexey.ushakov at jetbrains.com (Alexey Ushakov) Date: Fri, 3 Jun 2016 15:16:32 +0300 Subject: [OpenJDK 2D-Dev] Review request for: JDK-8158495 CCE: sun.java2d.NullSurfaceData cannot be cast to sun.java2d.opengl.OGLSurfaceData In-Reply-To: <07ee68ba-eddf-1905-a6b8-f3f08f4040e2@oracle.com> References: <0F380F61-7EC2-43F0-B0AA-2D79D4C9E9CD@jetbrains.com> <07ee68ba-eddf-1905-a6b8-f3f08f4040e2@oracle.com> Message-ID: <7BEE58D1-0D4A-4F81-A04C-EB1FDE5DADAD@jetbrains.com> Hi Sergey, Thanks for the comments. Here is updated webrev: http://cr.openjdk.java.net/~avu/JDK-8158495/webrev.01 BTW, could you integrate this fix into jdk8 and jdk9 as well. Best Regards, Alexey > On 02 Jun 2016, at 21:42, Sergey Bylokhov wrote: > > Hi, Alexey. > The code in OGLMaskFill.java is mirrored in D3DMaskFill for d3d, I think it should be updated also. It seems these files follow the rule: "80 chars per line", it will be good to do the same in the fix. > > On 02.06.16 18:07, Alexey Ushakov wrote: >> Hello Phil and Sergey, >> >> Here is one more fix of the >> ClassCastException for invalid surface that we?ve recently got in our products. I?ve updated Sergey?s test so it goes through the problematic code. Unfortunately, I was unable to reproduce the problem by myself (The actual issue was reported only by our customers) >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8158495 >> Webrev: http://cr.openjdk.java.net/~avu/JDK-8158495/webrev.00 >> >> Best Regards, >> Alexey >> > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ivanov at oracle.com Fri Jun 3 12:18:59 2016 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 3 Jun 2016 15:18:59 +0300 Subject: [OpenJDK 2D-Dev] [9] request for review: 8078382: Wrong glyph is displayed for a derived font In-Reply-To: References: <55A64031.3060205@oracle.com> <55A68982.9090906@oracle.com> <55A7ACBD.9040403@oracle.com> <55A7FA20.7000105@oracle.com> <55AFC5DA.1030408@oracle.com> <5718E59E.6060804@oracle.com> <574DBC27.80807@oracle.com> <574DFD01.2040307@oracle.com> Message-ID: <504c3601-92b4-74a7-93ee-db60e80f790e@oracle.com> Hi Phil, Sergey, I pushed the fix and submitted a new bug https://bugs.openjdk.java.net/browse/JDK-8158637 Regards, Alexey On 01.06.2016 20:25, Alexey Ivanov wrote: > Hi Phil, Sergey, > > Thank you for reviewing! > > I suggest pushing the current version of the fix: > http://cr.openjdk.java.net/~bae/8078382/9/webrev.00/ > > It's Andrew's fix, and I'll push it under his name, giving him the > credit. > > > As for FontFamily.getClosestStyle(), I'll submit a new bug to > investigate the behavior. We will update getClosestStyle() if necessary. > > > Thanks, > Alexey > > On 01.06.2016 13:21, Alexey Ivanov wrote: >> Hi Phil, >> >> On 01.06.2016 0:07, Phil Race wrote: >>> getClosestStyle() is something of a last resort. >>> Historically I think it was called only when you >>> had only a font *with* a style like bold and someone asked for >>> plain/regular. >>> ie for the subtractive case rather than the additive case. >>> So it would not apply to the case in this bug. >>> >>> However OS X does not natively support synthetic styling so we may >>> be entering that method for the additive case on OS X. >>> >>> So will not have this same bug since it just does not happen. >>> >>> In which case the reamaining question is, when you only have BOLD >>> and ITALIC >>> and someone asks for BOLDITALIC and you can't synthesise at all, >>> which do you give them ? >> >> So it needs additional testing. However, I think GDI still returns >> Bold in this case: this way it would look consistent. >> >>> >>> I'd still lean towards ITALIC - assuming I have ITALIC, so we do not >>> need to update that method. >>> If it can be shown otherwise we can make the change. >> >> Do you think we should push the fix as is, and leave >> FontFamily.getClosestStyle() as it is now? >> >> Then test how native systems behave and update this method if necessary. >> >> >> Thanks, >> Alexey >> >>> >>> >>> -phil. >>> >>> On 05/31/2016 09:43 AM, Sergey Bylokhov wrote: >>>> On 31.05.16 19:30, Phil Race wrote: >>>>>> The patch changes the order of font selection: bold will be used, if >>>>>> possible, as the base for bold-italic instead of italic which is the >>>>>> current default. It also fixes the issue where italic is returned >>>>>> instead of bold. >>>>> >>>>> OK. +1 >>>> >>>> I am not sure but should FontFamily.getClosestStyle() be updated >>>> also?: >>>> case Font.BOLD|Font.ITALIC: >>>> if (italic != null) { >>>> return italic; >>>> } else if (bold != null) { >>>> return bold; >>>> } else { >>>> return plain; >>>> } >>>> } >>>> >>>>> >>>>> -phil. >>>>> >>>>>> >>>>>> >>>>>> Thank you in advance, >>>>>> Alexey >>>>>> >>>>>> On 22.07.2015 19:33, Alexey Ivanov wrote: >>>>>>> Hi Phil, >>>>>>> >>>>>>> On 16.07.2015 21:38, Phil Race wrote: >>>>>>>> On 07/16/2015 06:08 AM, Andrew Brygin wrote: >>>>>>>>> Hi Phil, >>>>>>>>> >>>>>>>>> another option to avoid the problem is to be a bit more specific >>>>>>>>> regarding the >>>>>>>>> required font when we obtaining lcd glyph from GDI. >>>>>>>>> If we specify a particular name of the font which we used to >>>>>>>>> construct the >>>>>>>>> glyph vector, then we will get glyphs exactly for desired >>>>>>>>> characters: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~bae/8078382/9/webrev.01/ >>>>>>>>> >>>>>>>>> This change affects only the case of lcd glyphs on windows, >>>>>>>>> it reduces the scope of required testing. >>>>>>>> >>>>>>>> This is heading in the direction I was thinking of but since >>>>>>>> GDI is >>>>>>>> excepting a face name >>>>>>>> (what we call a family name), I am not sure if this will always >>>>>>>> work >>>>>>>> as is. >>>>>>>> There are possible issues with using a localized name and the >>>>>>>> length >>>>>>>> of the full name exceeding what Windows allows here. >>>>>>>> And there may be unintended consequences that are not immediately >>>>>>>> obvious. >>>>>>>> I would like to try limit this to the case where we can positively >>>>>>>> identify that the >>>>>>>> font is not the one we expected. And do it cheaply too. >>>>>>>> I do not have a quick answer here but roughly the algorithm >>>>>>>> might be >>>>>>>> - specify family, check (somehow) if GDI selects the same base >>>>>>>> font >>>>>>>> - if not, try the facename approach (if the name fits). Did we >>>>>>>> succeed and get the same base font ? >>>>>>>> - if not, bail on GDI for this case and do the rasterisation >>>>>>>> ourselves. >>>>>>>> >>>>>>>> "cheaply" might depend on caching a success value on the first >>>>>>>> attempt, so >>>>>>>> that we only do it once, ever, for a font. Then the problem >>>>>>>> becomes >>>>>>>> how to >>>>>>>> do the verification. One approach might be to call >>>>>>>> GetFontData() which >>>>>>>> will give us some chunk of the font file and we can see if the >>>>>>>> name >>>>>>>> (or something >>>>>>>> else we can quickly and reliably parse) is exactly that we >>>>>>>> expect .. >>>>>>> >>>>>>> It looks there's no easy way to detect whether GDI selected the >>>>>>> same >>>>>>> base font or not. GetTextFace function doesn't help it: it always >>>>>>> returns the face name passed in LOGFONT except in the cases where >>>>>>> there's no such font. >>>>>>> >>>>>>> I haven't found any other API which could tell us what font GDI >>>>>>> selected. So the only alternative is to use GetFontData and >>>>>>> parse the >>>>>>> font file itself. Yet I can't find any example how to use this >>>>>>> function. I'll keep searching in that direction. >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Alexey >>>>>>> >>>>>>>> >>>>>>>> Leaving aside the 'wrong glyph' case, I have to suppose it is >>>>>>>> possible that >>>>>>>> there are other un-noticed cases where we use a different base >>>>>>>> font >>>>>>>> than >>>>>>>> that selected by GDI. The algorithms are not defined anywhere I >>>>>>>> can >>>>>>>> locate. >>>>>>>> >>>>>>>>> >>>>>>>>> However, there seems to be a copy&paste error in >>>>>>>>> FontFamily.java: >>>>>>>>> on lines 340 - 341 we check that bold font fits our needs but >>>>>>>>> use >>>>>>>>> italic >>>>>>>>> anyway. Was it done by purpose, or this is really an error? >>>>>>>> >>>>>>>> That is a copy/paste mistake. It should be fixed. >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Andrew >>>>>>>>> >>>>>>>>> On 7/15/2015 7:25 PM, Phil Race wrote: >>>>>>>>>> This probably needs more examination and perhaps a more >>>>>>>>>> complex fix. >>>>>>>>>> The observation that GDI bases bold-italic on the bold >>>>>>>>>> version not >>>>>>>>>> the >>>>>>>>>> italic version is an implementation choice just as we had >>>>>>>>>> done the >>>>>>>>>> opposite. It is possible some other time it does the opposite >>>>>>>>>> or some >>>>>>>>>> other platform does the opposite. I have supposed it is >>>>>>>>>> harder to >>>>>>>>>> synthesise italic than to do 'over-strike'. And this GDI usage >>>>>>>>>> applies only to LCD glyphs. >>>>>>>>>> >>>>>>>>>> Maybe what we need to do is see if we can detect the cases when >>>>>>>>>> GDI and JDK disagree on the actual font and remap the glyph id. >>>>>>>>>> >>>>>>>>>> -phil. >>>>>>>>>> >>>>>>>>>> On 7/15/15 4:12 AM, Andrew Brygin wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> could you please review a fix for 8078382? >>>>>>>>>>> >>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8078382 >>>>>>>>>>> webrev: http://cr.openjdk.java.net/~bae/8078382/9/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> The problem is caused by following peculiarity of the Code New >>>>>>>>>>> Roman font: this font provides plain, italic and bold >>>>>>>>>>> variants. >>>>>>>>>>> In bold and italic variants of the font, different glyphs >>>>>>>>>>> correspond to the apostrophe character (0039): >>>>>>>>>>> bold: 0039 -> 0x250 (592) >>>>>>>>>>> italic: 0039 -> 0x256 (598) >>>>>>>>>>> >>>>>>>>>>> So, we translate character to glyphs using italic variant >>>>>>>>>>> of the font, and then request glyph images from GDI. >>>>>>>>>>> However, GDI uses the bold variant of the font in order >>>>>>>>>>> to compose glyph images for artificial bold-italic variant, >>>>>>>>>>> and we have got a glyph image for ? instead of apostrophe. >>>>>>>>>>> >>>>>>>>>>> Suggested fix is to select bold variant (if possible) as a >>>>>>>>>>> base for artificial bold-italic. >>>>>>>>>>> >>>>>>>>>>> There is no regression test because it requires a specific >>>>>>>>>>> font >>>>>>>>>>> to be installed on a test system. The font can be found here: >>>>>>>>>>> http://www.dafont.com/code-new-roman.font >>>>>>>>>>> >>>>>>>>>>> Please take a look. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Andrew >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> > From prasanta.sadhukhan at oracle.com Fri Jun 3 14:07:48 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Fri, 3 Jun 2016 19:37:48 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8158520: [TEST_BUG] java/awt/PrintJob/PrinterException.java fails on timeout In-Reply-To: <19787936-25a2-692b-c864-34f3680c20ee@oracle.com> References: <3b534145-9c38-51b4-5f3d-12b9c1898373@oracle.com> <19787936-25a2-692b-c864-34f3680c20ee@oracle.com> Message-ID: No, we do not really need to print anything but we need to show the printdialog to reproduce the previous bug. But to avoid human interaction ,we need to close the dialog so that jtreg should not fail in timeout. I am not sure how to select "Cancel" in the print dialog automatically but Print or Cancel does not change the behaviour, so we are just pressing "Enter". In windows and linux, the "focus" is on print and in osx, the "focus" is on cancel. Regards Prasanta On 6/3/2016 5:31 PM, Sergey Bylokhov wrote: > Do we really need try to print something or cancel(ESC) will be enough > to reproduce the previous bug? > > On 03.06.16 14:46, prasanta sadhukhan wrote: >> Please review a test bug which was added for bug 7161283. >> Toolkit.getPrintJob() threw a NPE if no printer was available. >> >> Although the testcase was working ok in failure case by throwing NPE, in >> pass case it was waiting for manual intervention causing jtreg to fail >> on timeout. >> >> Made the testcase automated to use Robot to press Enter as the focus in >> the dialog is in the "Print" button. Using Robot to press Enter closes >> the dialog without the need for manual intervention. >> >> Tested on windows, linux and mac. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8158520 >> >> webrev: http://cr.openjdk.java.net/~psadhukhan/8158520/webrev.00/ >> >> >> Regards >> >> Prasanta >> > > From prasanta.sadhukhan at oracle.com Fri Jun 3 14:16:37 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Fri, 3 Jun 2016 19:46:37 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8158520: [TEST_BUG] java/awt/PrintJob/PrinterException.java fails on timeout In-Reply-To: References: <3b534145-9c38-51b4-5f3d-12b9c1898373@oracle.com> <19787936-25a2-692b-c864-34f3680c20ee@oracle.com> Message-ID: Ok. we can pass VK_ESCAPE instead of VK_ENTER and it works ok. Regards Prasanta On 6/3/2016 7:37 PM, prasanta sadhukhan wrote: > No, we do not really need to print anything but we need to show the > printdialog to reproduce the previous bug. But to avoid human > interaction ,we need to close the dialog so that jtreg should not fail > in timeout. > > I am not sure how to select "Cancel" in the print dialog automatically > but Print or Cancel does not change the behaviour, so we are just > pressing "Enter". In windows and linux, the "focus" is on print and in > osx, the "focus" is on cancel. > > Regards > Prasanta > On 6/3/2016 5:31 PM, Sergey Bylokhov wrote: >> Do we really need try to print something or cancel(ESC) will be >> enough to reproduce the previous bug? >> >> On 03.06.16 14:46, prasanta sadhukhan wrote: >>> Please review a test bug which was added for bug 7161283. >>> Toolkit.getPrintJob() threw a NPE if no printer was available. >>> >>> Although the testcase was working ok in failure case by throwing >>> NPE, in >>> pass case it was waiting for manual intervention causing jtreg to fail >>> on timeout. >>> >>> Made the testcase automated to use Robot to press Enter as the focus in >>> the dialog is in the "Print" button. Using Robot to press Enter closes >>> the dialog without the need for manual intervention. >>> >>> Tested on windows, linux and mac. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8158520 >>> >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8158520/webrev.00/ >>> >>> >>> Regards >>> >>> Prasanta >>> >> >> > From Sergey.Bylokhov at oracle.com Fri Jun 3 17:00:12 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 3 Jun 2016 20:00:12 +0300 Subject: [OpenJDK 2D-Dev] Review request for: JDK-8158495 CCE: sun.java2d.NullSurfaceData cannot be cast to sun.java2d.opengl.OGLSurfaceData In-Reply-To: <7BEE58D1-0D4A-4F81-A04C-EB1FDE5DADAD@jetbrains.com> References: <0F380F61-7EC2-43F0-B0AA-2D79D4C9E9CD@jetbrains.com> <07ee68ba-eddf-1905-a6b8-f3f08f4040e2@oracle.com> <7BEE58D1-0D4A-4F81-A04C-EB1FDE5DADAD@jetbrains.com> Message-ID: <327ed49a-2e03-83ea-6824-84ed0da96a86@oracle.com> Thanks. Looks fine. > BTW, could you integrate this fix into jdk8 and jdk9 as well. I'll push it. > > Best Regards, > Alexey > >> On 02 Jun 2016, at 21:42, Sergey Bylokhov > > wrote: >> >> Hi, Alexey. >> The code in OGLMaskFill.java is mirrored in D3DMaskFill for d3d, I >> think it should be updated also. It seems these files follow the rule: >> "80 chars per line", it will be good to do the same in the fix. >> >> On 02.06.16 18:07, Alexey Ushakov wrote: >>> Hello Phil and Sergey, >>> >>> Here is one more fix of the >>> ClassCastException for invalid surface that we?ve recently got in our >>> products. I?ve updated Sergey?s test so it goes through the >>> problematic code. Unfortunately, I was unable to reproduce the >>> problem by myself (The actual issue was reported only by our customers) >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8158495 >>> Webrev: http://cr.openjdk.java.net/~avu/JDK-8158495/webrev.00 >>> >>> Best Regards, >>> Alexey >>> >> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. From james.graham at oracle.com Fri Jun 3 23:21:53 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 3 Jun 2016 16:21:53 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods In-Reply-To: <0042f492-5fc4-481c-8b2d-35a242a5af93@default> References: <6f83b633-3910-47fa-b872-e042fe4c24d3@default> <24ca2994-aa27-4a70-8cf9-0bda35664f3f@default> <574809B2.5040901@oracle.com> <9f641938-f979-4021-9e94-bde47e1d3c67@default> <57489033.7020901@oracle.com> <77d5b327-066b-4d86-a44d-8e681aeb71f8@default> <574DE3F9.40709@oracle.com> <574E0717.5060405@oracle.com> <574E0DF9.20508@oracle.com> <574E10B0.4070003@oracle.com> <574E13BD.9060701@oracle.com> <9a87056b-2646-4d5f-bfec-d50bea489381@default> <574F0EFE.2070300@oracle.com> <2e485b6b-3df0-41db-ba40-a96528883e95@default> <20a4c021-6814-9423-2891-c45c1ab94396@oracle.com> <0042f492-5fc4-481c-8b2d-35a242a5af93@default> Message-ID: <6341d4b6-f281-3f58-efc3-32d1ed0ecc42@oracle.com> That looks good to me. Has the CCC cleared yet? ...jim On 6/3/16 2:49 AM, Jayathirth D V wrote: > Hi Jim, > > Oh that's an important change. > Thanks for your review. > > I have updated ColorModel constructor to copy nBIts only of numOfComponents length and I have removed validBits check in hashCode() of ICM. > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/7107905/webrev.10/ > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Friday, June 03, 2016 2:25 AM > To: Jayathirth D V; Philip Race > Cc: 2d-dev at openjdk.java.net > Subject: Re: Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods > > I just noticed a hashCode/equals violation that we created a few revisions ago. We compute the hash of the validBits in ICM, but we only compare validBits up to the number of colors in the colormap. One could construct two ICMs that have different validBits that are identical in the first N bits (N = number of colors), but have different bits beyond that, and those 2 ICMs would evaluate as equals(), but their hashcodes would be different. > > Possible solutions: > > - Truncate validBits when it is accepted in the constructor (validBits.and(...)) > - Manually compute the hash of the first N bits of validBits > - Not use validBits in the hash code since it is allowed to omit significant data from the hash > > (Note that everything in hashcode must participate in equals(), but not vice versa) > > The same is true of nBits in ColorModel. (nBits can be copied and truncated with Arrays.copyOf) > > The same is *not* true of maskBits in PCM since the constructor creates an array of the precise length it needs... > > ...jim > > On 6/2/16 7:07 AM, Jayathirth D V wrote: >> Hi Phil, >> >> I have updated the code with all the changes I mentioned previously. I am caching hashCode when first time hashCode() is called. >> Please find the updated webrev for review: >> http://cr.openjdk.java.net/~jdv/7107905/webrev.09/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Philip Race >> Sent: Wednesday, June 01, 2016 10:06 PM >> To: Jayathirth D V >> Cc: Jim Graham; 2d-dev at openjdk.java.net >> Subject: Re: Review Request for JDK-7107905: ColorModel subclasses are >> missing hashCode() or equals() or both methods >> >> Please post the updated webrev. >> >> -phil. >> >> On 6/1/16, 12:02 AM, Jayathirth D V wrote: >>> Hi Phil& Jim, >>> >>> Collating all the changes needed: >>> 1) I have removed both equals()& hashCode() in CCM but forgot to add the file while creating webrev. I will include changes in CCM in updated webrev. >>> 2) Caching of hashCode value in IndexColorModel& PackedColorModel : >>> We can cache hashCode value when constructor is called or when hashCode() is called for first time. What approach we have to follow? >>> 3) Comment section of equals() method, I will update it to : >>> 1449 * the target object must be the same class (and not a subclass) as this >>> 4) I will use .equals() to compare colorSpace values in CM.equals() so it will be like we are not intending ColorSpace class to never override equals() method. >>> >>> Please let me know your inputs. >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Jim Graham >>> Sent: Wednesday, June 01, 2016 4:14 AM >>> To: Phil Race >>> Cc: Jayathirth D V; 2d-dev at openjdk.java.net >>> Subject: Re: Review Request for JDK-7107905: ColorModel subclasses >>> are missing hashCode() or equals() or both methods >>> >>> I think we should use .equals() here, otherwise it looks like a recommendation that the intent is for those classes to never implement it... >>> >>> ...jim >>> >>> On 05/31/2016 03:31 PM, Phil Race wrote: >>>> I don't know of any design intent, so yes, I meant more as a >>>> practical matter. >>>> Unless they subclass then using equals() which I thought unlikely it >>>> makes no difference here. >>>> But it would be proof against that to use equals, unlikely to matter >>>> as it might be .. >>>> >>>> -phil. >>>> >>>> On 05/31/2016 03:19 PM, Jim Graham wrote: >>>>> >>>>> On 05/31/2016 02:50 PM, Phil Race wrote: >>>>>> On 05/31/2016 12:20 PM, Jim Graham wrote: >>>>>>> Hi Jay, >>>>>>> >>>>>>> You were going to remove hashCode/equals from CCM, but instead >>>>>>> you simply removed it from the patch. You still need to edit it >>>>>>> to remove the existing methods. >>>>>> Oh yeah ! CCM is gone from the latest webrev. I expect that was >>>>>> not intentional. >>>>>> >>>>>>> Also, I'm not sure == is a good way to compare ColorSpace >>>>>>> instances >>>>>>> - Phil? >>>>>> Neither ColorSpace nor ICC_ColorSpace over-ride equals or hashCode >>>>>> and all the predefined ones are constructed as singletons so it >>>>>> seems unlikely to cause problems >>>>> Should it use .equals() on principle, though? Otherwise we are >>>>> baking in the assumption that it doesn't implement equals() into >>>>> our implementation of the CM.equals() method. Might it some day >>>>> implement equals (perhaps it isn't a practical issue today, but it >>>>> might be in the future when we forget that it was omitted in this >>>>> usage we create today). >>>>> >>>>> I guess what I'm asking is if it is a design feature that different >>>>> objects are considered non-equal (such as an object that, for >>>>> instance, has only predetermined instances that are shared by >>>>> reference and reused). I think color spaces are sort of in-between >>>>> in that we define a few constants that simply get used by reference >>>>> in 99% of cases, but that isn't a design feature, more like a >>>>> practical issue... >>>>> >>>>> ...jim From jayathirth.d.v at oracle.com Mon Jun 6 06:07:04 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Sun, 5 Jun 2016 23:07:04 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : Exception getting thumbnail size for JPEG with embedded thumbnail In-Reply-To: <81493db0-3791-5877-e776-d906985e6704@oracle.com> References: <4cedc972-c8c2-42ed-80cf-e0fb276fc26d@default> <81493db0-3791-5877-e776-d906985e6704@oracle.com> Message-ID: <56b2c630-e9a8-4ff7-bbe4-0e28e2a5fc1b@default> Hi Jim, When I verified by adding logs we are actually checking for EOI markers serially. I have sent detailed mail regarding the same in 2D-dev list. I don't think that we need brute force check of EOI/SOI markers continuously without parsing the header in this case of skipImage(). Thanks, Jay -----Original Message----- From: Jim Graham Sent: Thursday, June 02, 2016 2:08 AM To: Jayathirth D V; Philip Race Cc: 2d-dev at openjdk.java.net Subject: Re: Review Request for JDK-8152672 : Exception getting thumbnail size for JPEG with embedded thumbnail I'm a little disturbed that we are just doing a basic "look for these byte value" type of search rather than parsing the file until we find an SOI. Are there cases where we are skipping arbitrary untagged data, or was this just lazy programming in the first place. Everything in a JPEG file should be tagged and the size of any arbitrary data should be known or included in the file so that we should basically be looking at the next 2 bytes, determining what kind of data follows, skipping that data, and then looking at the next tag and no amount of "we don't know what that byte was, so we'll just look at the next byte" should ever be occuring. Am I missing something about the practical nature of the JPEG file that requires a brute force search? ...jim On 6/1/16 12:18 AM, Jayathirth D V wrote: > Hi, > > > > _Please review the following fix in JDK9:_ > > _ _ > > Bug : https://bugs.openjdk.java.net/browse/JDK-8152672 > > > > Webrev : http://cr.openjdk.java.net/~jdv/8152672/webrev.00/ > > > > Issue : When we are trying to get properties related to second image > in JPEG file we are getting IIOException mentioning that it is not a JPEG file. > > > > Root cause : When we are skipping first image to reach second image > header, we are just trying to find next available EOI marker. But if > first image has embedded thumbnail in APP1 marker, we will reach to EOI of this thumbnail and not EOI of first image. So after we reach EOI of embedded thumbnail we try to access second image SOI marker which will fail. > > Solution : We have to change the logic of how we skip to consecutive > images in JPEG file. We know that application markers, comments or > other markers can contain data same as SOI & EOI. Instead of just checking for EOI marker serially, we should read length of these markers and skip them. > > > > Thanks, > > Jay > > > From prasanta.sadhukhan at oracle.com Mon Jun 6 07:02:08 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Mon, 6 Jun 2016 12:32:08 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8158520: [TEST_BUG] java/awt/PrintJob/PrinterException.java fails on timeout In-Reply-To: References: <3b534145-9c38-51b4-5f3d-12b9c1898373@oracle.com> <19787936-25a2-692b-c864-34f3680c20ee@oracle.com> Message-ID: Hi Sergey, Please find the modified webrev with ESC. The previous bug can also be reproduced with this without the 7161283 fix. http://cr.openjdk.java.net/~psadhukhan/8158520/webrev.01/ Regards Prasanta On 6/3/2016 7:46 PM, prasanta sadhukhan wrote: > > Ok. we can pass VK_ESCAPE instead of VK_ENTER and it works ok. > > Regards > Prasanta > On 6/3/2016 7:37 PM, prasanta sadhukhan wrote: >> No, we do not really need to print anything but we need to show the >> printdialog to reproduce the previous bug. But to avoid human >> interaction ,we need to close the dialog so that jtreg should not >> fail in timeout. >> >> I am not sure how to select "Cancel" in the print dialog >> automatically but Print or Cancel does not change the behaviour, so >> we are just pressing "Enter". In windows and linux, the "focus" is on >> print and in osx, the "focus" is on cancel. >> >> Regards >> Prasanta >> On 6/3/2016 5:31 PM, Sergey Bylokhov wrote: >>> Do we really need try to print something or cancel(ESC) will be >>> enough to reproduce the previous bug? >>> >>> On 03.06.16 14:46, prasanta sadhukhan wrote: >>>> Please review a test bug which was added for bug 7161283. >>>> Toolkit.getPrintJob() threw a NPE if no printer was available. >>>> >>>> Although the testcase was working ok in failure case by throwing >>>> NPE, in >>>> pass case it was waiting for manual intervention causing jtreg to fail >>>> on timeout. >>>> >>>> Made the testcase automated to use Robot to press Enter as the >>>> focus in >>>> the dialog is in the "Print" button. Using Robot to press Enter closes >>>> the dialog without the need for manual intervention. >>>> >>>> Tested on windows, linux and mac. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8158520 >>>> >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8158520/webrev.00/ >>>> >>>> >>>> Regards >>>> >>>> Prasanta >>>> >>> >>> >> > From Sergey.Bylokhov at oracle.com Mon Jun 6 14:49:13 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 6 Jun 2016 17:49:13 +0300 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8158520: [TEST_BUG] java/awt/PrintJob/PrinterException.java fails on timeout In-Reply-To: References: <3b534145-9c38-51b4-5f3d-12b9c1898373@oracle.com> <19787936-25a2-692b-c864-34f3680c20ee@oracle.com> Message-ID: <1708025e-f5ea-ccae-2935-4ba012c46f8e@oracle.com> Looks fine. On 06.06.16 10:02, prasanta sadhukhan wrote: > Hi Sergey, > > Please find the modified webrev with ESC. The previous bug can also be > reproduced with this without the 7161283 fix. > http://cr.openjdk.java.net/~psadhukhan/8158520/webrev.01/ > > Regards > Prasanta > On 6/3/2016 7:46 PM, prasanta sadhukhan wrote: >> >> Ok. we can pass VK_ESCAPE instead of VK_ENTER and it works ok. >> >> Regards >> Prasanta >> On 6/3/2016 7:37 PM, prasanta sadhukhan wrote: >>> No, we do not really need to print anything but we need to show the >>> printdialog to reproduce the previous bug. But to avoid human >>> interaction ,we need to close the dialog so that jtreg should not >>> fail in timeout. >>> >>> I am not sure how to select "Cancel" in the print dialog >>> automatically but Print or Cancel does not change the behaviour, so >>> we are just pressing "Enter". In windows and linux, the "focus" is on >>> print and in osx, the "focus" is on cancel. >>> >>> Regards >>> Prasanta >>> On 6/3/2016 5:31 PM, Sergey Bylokhov wrote: >>>> Do we really need try to print something or cancel(ESC) will be >>>> enough to reproduce the previous bug? >>>> >>>> On 03.06.16 14:46, prasanta sadhukhan wrote: >>>>> Please review a test bug which was added for bug 7161283. >>>>> Toolkit.getPrintJob() threw a NPE if no printer was available. >>>>> >>>>> Although the testcase was working ok in failure case by throwing >>>>> NPE, in >>>>> pass case it was waiting for manual intervention causing jtreg to fail >>>>> on timeout. >>>>> >>>>> Made the testcase automated to use Robot to press Enter as the >>>>> focus in >>>>> the dialog is in the "Print" button. Using Robot to press Enter closes >>>>> the dialog without the need for manual intervention. >>>>> >>>>> Tested on windows, linux and mac. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8158520 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8158520/webrev.00/ >>>>> >>>>> >>>>> Regards >>>>> >>>>> Prasanta >>>>> >>>> >>>> >>> >> > -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Tue Jun 7 09:11:10 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Tue, 7 Jun 2016 14:41:10 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8158758: [TEST_BUG] test/java/awt/print/PrinterJob/LandscapeStackOverflow.java fails on timeout Message-ID: Hi All, Please review a testbug fix for jdk9 where it was seen that jtreg times out if print dialog ok/cancel button is not pressed. Bug: https://bugs.openjdk.java.net/browse/JDK-8158758 webrev: http://cr.openjdk.java.net/~psadhukhan/8158758/webrev.00/ Fix is not to show print dialog as 6842011bug can be reproduced without showing print dialog. Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From prahalad.kumar.narayanan at oracle.com Tue Jun 7 10:12:06 2016 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Tue, 7 Jun 2016 03:12:06 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request: JDK-6457721: Stroke width incorrect while printing Message-ID: Hello Everyone on Java2D Good day to you. Please find herewith: Webrev changes for the bug Bug ID : JDK-6457721 Bug Link : https://bugs.openjdk.java.net/browse/JDK-6457721 As per the Bug: 1. With rotation angle set to Graphics2D object, the printed Lines, Rectangles or Shapes have incorrect stroke width 2. The behavior is typically noticed at a rotation of 45' 3. The issue is reproducible on JDK 9 and is applicable for windows platform. Quick Description on Changes 1. Thanks to Phil for adding his detailed comments on JBS. They were really helpful. a. Root Cause: The formula for stroke width calculation was incorrect in the WPathGraphics.java code. 2. Following changes have been incorporated- a. Correction to the stroke width calculation. i. As Phil suggested in his JBS comments, the logic has been modified to use distance formula after being rotated by theta. ii. Since many other places also use the same logic, correction has been taken up wherever necessary b. Fallback path for Lines and Rectangles when Custom stroke implementation is set. i. It was observed that when lines or rectangles are drawn with custom stroke object, the code does not print any of these shapes. ii. A fallback logic is now provided that prints the lines and rectangles as 'Shapes'. iii. The same fallback logic is being taken up in other sections of code, when GDI fails to instantiate a pen with required Attributes. Hence the introduced fallback will be consistent with existing code. c. Manual Test Case to detect the bug and verify the fix i. A manual jtreg test case has been provided for users to run, print and verify the fix. Detailed comments have been added for changes in the code. Kindly review the changes at your convenience and provide your suggestions. Webrev Link: http://cr.openjdk.java.net/~pnarayanan/6457721/webrev.00/ Thank you for your time in review Have a good day Prahalad N. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Tue Jun 7 11:32:14 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Tue, 7 Jun 2016 17:02:14 +0530 Subject: [OpenJDK 2D-Dev] Review Request: JDK-6457721: Stroke width incorrect while printing In-Reply-To: References: Message-ID: Fix looks good to me. But, do we not need to do the same for 209 minLineWidth = Math.max(Math.abs(minPenSize.x) 210 Math.abs(minPenSize.y)); For the test the instruction textarea is editable which needs to be made read-only. Also, if the user does not do any manual intervention, the test passes. The test should have provision of failing if there is no user interaction. I guess there is no need of using Robot class in a manual test, you can use sleep if it is just meant to delay main() closing. The test has some wildcard imports which can be changed to specific imports. Regards Prasanta On 6/7/2016 3:42 PM, Prahalad Kumar Narayanan wrote: > > Hello Everyone on Java2D > > Good day to you. > > Please find herewith: Webrev changes for the bug > > Bug ID : JDK-6457721 > > Bug Link : https://bugs.openjdk.java.net/browse/JDK-6457721 > > As per the Bug: > > 1.With rotation angle set to Graphics2D object, the printed Lines, > Rectangles or Shapes have incorrect stroke width > > 2.The behavior is typically noticed at a rotation of 45? > > 3.The issue is reproducible on JDK 9 and is applicable for windows > platform. > > Quick Description on Changes > > 1.Thanks to Phil for adding his detailed comments on JBS. They were > really helpful. > > a.Root Cause: The formula for stroke width calculation was incorrect > in the WPathGraphics.java code. > > 2.Following changes have been incorporated- > > a.Correction to the stroke width calculation. > > i.As Phil suggested in his JBS comments, the logic has been modified > to use distance formula after being rotated by theta. > > ii.Since many other places also use the same logic, correction has > been taken up wherever necessary > > b.Fallback path for Lines and Rectangles when Custom stroke > implementation is set. > > i.It was observed that when lines or rectangles are drawn with custom > stroke object, the code does not print any of these shapes. > > ii.A fallback logic is now provided that prints the lines and > rectangles as ?Shapes?. > > iii.The same fallback logic is being taken up in other sections of > code, when GDI fails to instantiate a pen with required Attributes. > > Hence the introduced fallback will be consistent with existing code. > > c.Manual Test Case to detect the bug and verify the fix > > i.A manual jtreg test case has been provided for users to run, print > and verify the fix. > > Detailed comments have been added for changes in the code. > > Kindly review the changes at your convenience and provide your > suggestions. > > Webrev Link: > http://cr.openjdk.java.net/~pnarayanan/6457721/webrev.00/ > > > Thank you for your time in review > > Have a good day > > Prahalad N. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Tue Jun 7 21:50:28 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 7 Jun 2016 14:50:28 -0700 Subject: [OpenJDK 2D-Dev] Review Request: JDK-6457721: Stroke width incorrect while printing In-Reply-To: References: Message-ID: <70f0e7ac-2960-3247-9bac-5249a0da3976@oracle.com> The calculations are still not correct. Consider a transform that zooms Y coordinates and shrinks X coordinates, you will think that the resulting line width is large, and it will be for horizontal lines. But vertical lines will experience a smaller line width. The only real calculation to see if the point size needs to be adjusted is one of: - if the direction is known, use an N-length vector perpendicular to the direction of the path. This might work for drawLine(), but not for drawPolygon() and draw(Shape). - if the direction is not known, or varies as in a polygon or path, then you need to use computations to compute the size of the minor axis of the ellipse produced by transforming the unit circle, which is not an easy problem (you can look at the code in the Marlin renderer to see how it handles this, I don't recall how it does it off-hand). Also, you fixed the computations of "is the line width too thin", but there are also computations for "if it is too thin, then what is the correct minimum line width?" that still use the old computations, but in reverse... ...jim On 6/7/2016 4:32 AM, prasanta sadhukhan wrote: > Fix looks good to me. But, do we not need to do the same for > > 209 minLineWidth = Math.max(Math.abs(minPenSize.x) > 210 Math.abs(minPenSize.y)); > > For the test the instruction textarea is editable which needs to be made > read-only. > Also, if the user does not do any manual intervention, the test passes. > The test should have provision of failing if there is no user > interaction. I guess there is no need of using Robot class in a manual > test, you can use sleep if it is just meant to delay main() closing. > The test has some wildcard imports which can be changed to specific imports. > > Regards > Prasanta > On 6/7/2016 3:42 PM, Prahalad Kumar Narayanan wrote: >> >> Hello Everyone on Java2D >> >> >> >> Good day to you. >> >> >> >> Please find herewith: Webrev changes for the bug >> >> Bug ID : JDK-6457721 >> >> Bug Link : https://bugs.openjdk.java.net/browse/JDK-6457721 >> >> >> >> As per the Bug: >> >> 1. With rotation angle set to Graphics2D object, the printed >> Lines, Rectangles or Shapes have incorrect stroke width >> >> 2. The behavior is typically noticed at a rotation of 45? >> >> 3. The issue is reproducible on JDK 9 and is applicable for >> windows platform. >> >> >> >> Quick Description on Changes >> >> 1. Thanks to Phil for adding his detailed comments on JBS. They >> were really helpful. >> >> a. Root Cause: The formula for stroke width calculation was >> incorrect in the WPathGraphics.java code. >> >> >> >> 2. Following changes have been incorporated- >> >> a. Correction to the stroke width calculation. >> >> i. >> As Phil suggested in his JBS comments, the logic has been modified to >> use distance formula after being rotated by theta. >> >> ii. >> Since many other places also use the same logic, correction has been >> taken up wherever necessary >> >> >> >> b. Fallback path for Lines and Rectangles when Custom stroke >> implementation is set. >> >> i. >> It was observed that when lines or rectangles are drawn with custom >> stroke object, the code does not print any of these shapes. >> >> ii. >> A fallback logic is now provided that prints the lines and rectangles >> as ?Shapes?. >> >> iii. >> The same fallback logic is being taken up in other sections of code, >> when GDI fails to instantiate a pen with required Attributes. >> >> Hence the introduced fallback will be consistent with >> existing code. >> >> >> >> c. Manual Test Case to detect the bug and verify the fix >> >> i. >> A manual jtreg test case has been provided for users to run, print and >> verify the fix. >> >> >> >> Detailed comments have been added for changes in the code. >> >> Kindly review the changes at your convenience and provide your >> suggestions. >> >> Webrev Link: >> http://cr.openjdk.java.net/~pnarayanan/6457721/webrev.00/ >> >> >> >> Thank you for your time in review >> >> Have a good day >> >> >> >> Prahalad N. >> >> >> >> >> >> >> > From prasanta.sadhukhan at oracle.com Wed Jun 8 11:42:15 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Wed, 8 Jun 2016 17:12:15 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6601097:Margins are not reset to hardware margins when width/height is 0 or -ve alongwith x, y In-Reply-To: <574DBF01.5080101@oracle.com> References: <5745D4BB.5040900@oracle.com> <574DBF01.5080101@oracle.com> Message-ID: <0703d17a-9e36-94a2-93f8-80c56d0250f3@oracle.com> Hi Phil, As discussed offline, regarding mpa modification in both setAttributes() and updateAttributesWithPageFormat, I found that updateAttributesWithPageFormat() will be called during pageDialog() and setPrintable() whereas setAttributes() will be called during print() and setAttributes() called validatePaper() to validate imageable values, so in that regard, setAttributes() has final say in validating and updating invalid mpa values. Regarding bug, I found that if we have -ve width/height, MediaPrintable constructor throws IAE if width/height is -ve so mpa values set by user will not be added to pageAttributes (even if there was valid x,y mpa values) therefore we fallback to Java default paper size and so we will get mpa values as ix=72 iy=72 iw=451 ih=697 in validatePaper() so to avoid IAE and to use user-set valid values, I have modified the code to constrain iw/ih with requested ix/iy as you suggested. Please find the modified webrev: http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.02/ Regards Prasanta On 5/31/2016 10:12 PM, Phil Race wrote: > Well ... few printers can print on the entire paper. Photo printers are > the ones that can do this. So Paper dimension minus the "hardware > margins" > are the maximum imageable width. > And then supposing imageable x/y is some perfectly reasonable value > like 1" each > then you've set iw/ih such that even a printer with zero hardware > margins has > an imageable area that goes off the bottom and right off the paper. > > More reasonable would be to constrain iw/ih such that they work with the > requested ix/iy - assuming they are also valid. > > If all else fails then just using the "default" set of values as if > the application > had not set any values would be better. > > -phil. > > On 05/26/2016 03:26 AM, prasanta sadhukhan wrote: >> Hi Phil, >> >> I got it rectified. >> >> Please find the modified webrev >> >> http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.01/ >> >> Regarding using entire width/height pf paper, I thought since >> imageable width/height is invalid we should make the entire paper as >> the imageable area.For invalid x,y we were making it to paper's >> top/left. >> Else what option do we have, should we calculate >> width[height]=abs(image[width][height]) instead? >> >> Regards >> Prasanta >> On 5/25/2016 10:07 PM, Philip Race wrote: >>> It seems to me that you are using the wrong units. >>> You have not divided by DPI to get inches. >>> >>> Also I am not sure that the *entire* width/height of the paper is >>> what you want here >>> but that is secondary to the first issue >>> >>> -phil >>> >>> On 5/19/16, 2:59 AM, prasanta sadhukhan wrote: >>>> Hi All, >>>> >>>> Please review a fix for jdk9 which is a continuation of the fix of >>>> JDK-6543815. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6601097 >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.00/ >>>> >>>> 6543815 fix resets the x,y to 0 if they are negative before >>>> creating a MediaPrintableArea and the platform replaces it with >>>> hardware margins when printing. >>>> This works only if x/y is negative. >>>> But, If either width/height is negative alongwith x or y, then the >>>> margin is set to the java def 1 inch margin and not hardware margins. >>>> >>>> This is because width/height -ve results in IAE in >>>> MediaPrintableArea constructor and so values are ignored. >>>> Added a check for -ve width/height to make sure width/height are >>>> set to minimum paper width/height. >>>> >>>> Regards >>>> Prasanta >>>> >>>> >> > From bourges.laurent at gmail.com Wed Jun 8 21:31:41 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 8 Jun 2016 23:31:41 +0200 Subject: [OpenJDK 2D-Dev] RFR 8159093: Fix coding conventions in Marlin renderer Message-ID: Hi, Please review this bug fix for the Marlin renderer to fix coding conventions: bug: https://bugs.openjdk.java.net/browse/JDK-8159093 webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8159093.0/ Changes: - Use capital letters for all constants (static fields) - Use rdrCtx.stats instead of RendererContext.stats (static to field) - removed useless imports PS: this patch is an intermediate step before next Marlin patch Regards, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From yuri.nesterenko at oracle.com Thu Jun 9 09:12:59 2016 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Thu, 9 Jun 2016 12:12:59 +0300 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8158758: [TEST_BUG] test/java/awt/print/PrinterJob/LandscapeStackOverflow.java fails on timeout In-Reply-To: References: Message-ID: <5759331B.2090500@oracle.com> Fine with me! -yan PS: this test will still timeout on a system with i.e. PDF printer (a default setup for Windows 10) but that's not an issue. On 06/07/2016 12:11 PM, prasanta sadhukhan wrote: > Hi All, > > Please review a testbug fix for jdk9 where it was seen that jtreg times > out if print dialog ok/cancel button is not pressed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8158758 > > webrev: http://cr.openjdk.java.net/~psadhukhan/8158758/webrev.00/ > > Fix is not to show print dialog as 6842011bug can be reproduced without > showing print dialog. > > Regards > > Prasanta > From prasanta.sadhukhan at oracle.com Thu Jun 9 11:35:52 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Thu, 9 Jun 2016 17:05:52 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6966350:Empty pages when printing on Lexmark E352dn PS3 with "1200 IQ" setting Message-ID: <4a57f40d-9462-5236-7b2d-df69f97aa8e4@oracle.com> Hi All, Bug: https://bugs.openjdk.java.net/browse/JDK-6966350 The issue was if we select 1200IQ Normal (default) setting in Lexmark E352dn PS3 or Dell 5310n printer, it does not print the output and we get empty pages. It was because DEVMODE windows structure returns 600 for "dmPrintQuality" and 2 for "dmYResolution". For 2400IQ, it returns 600 dmPrintQuality and 4 as dmYResolution so awt_printControl.cpp#AwtPrintControl::UpdateAttributes() calls WPrinterJob#setResolutionDPI(xres=600, yres=2) and RasterPrinterJob#print() gets 0.027 as yscale(=getYRes()/72 and yres = 2) so devicetransform for normal 1200IQ dpi becomes [8.33, 0.0, -108.0][0.0, 0.027, -108.0] so WPathGraphics#drawString() gets devPos x= 725.33, *y = -105.22**. *so nothing gets printed. I tried finding the significance of 1200IQ setting which just says it enhances the images sent to the printer. From http://www.smallbusinesscomputing.com/testdrive/article.php/1585581/Lexmark-T420d-Printer-Review-Both-Sides-Now.htm (although it's not the same printer) says /"//To be fair, the LaserJet offers sharper resolution ? 1,200 by 1,200 dpi, while the T420d is a 600 by 600 dpi printer with what Lexmark calls "1,200 Image Quality" dot placement for photos" /I modified the code to set yres to xres value if yres is less than 10 . Although it seems to be a workaround, it prints the output. webrev: http://cr.openjdk.java.net/~psadhukhan/6966350/webrev.00/ Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Thu Jun 9 23:48:36 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 9 Jun 2016 16:48:36 -0700 Subject: [OpenJDK 2D-Dev] RFR 8159093: Fix coding conventions in Marlin renderer In-Reply-To: References: Message-ID: Hi Laurent, Just a few details I noticed... In RendererStats, lines 276,277 - is it better to convert to an array (which is an inherently risky situation for a concurrent collection due to the potential for the size changing between the array allocation and the toArray), or to iterate the concurrent collection directly? I realize that the toArray() method protects against a short array, but is it any better than just directly iterating which would deal with the concurrency automatically anyway without having to allocate an array. One thing to note, if you convert to an array and there is a concurrency issue then the array may have a null entry to indicate "this is the end of the list", but you don't look for that null entry. A simple "if rdrCtx==null break;" statement would be enough to deal with that case. MarlinConst.java - you added DO_FLUSH_STATS, but I don't see it getting used anywhere...? MarlinRenderingEngine.java - it looks like you eliminated all uses of mon_npi_currentSegment, but it is still created in RendererStats...? Histogram.java - 2016 copyright ...jim On 6/8/2016 2:31 PM, Laurent Bourg?s wrote: > Hi, > > Please review this bug fix for the Marlin renderer to fix coding > conventions: > bug: https://bugs.openjdk.java.net/browse/JDK-8159093 > webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8159093.0/ > > Changes: > - Use capital letters for all constants (static fields) > - Use rdrCtx.stats instead of RendererContext.stats (static to field) > - removed useless imports > > PS: this patch is an intermediate step before next Marlin patch > > Regards, > Laurent From james.graham at oracle.com Thu Jun 9 23:58:07 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 9 Jun 2016 16:58:07 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail In-Reply-To: References: <89531a21-64b2-4e00-8f15-aa78650cf7b2@default> <574F62FA.50900@oracle.com> Message-ID: <1309b2bb-c189-d623-cfc5-105223718e12@oracle.com> It looks like JPEG files have protection for scanning for an FF and assuming it is a marker by making sure that all FF bytes that appear in data are followed by a harmless byte, so a brute force search is probably fine. But it still seems wasteful when we know we are at a tag and we know the sizes of all of the tags, we should be able to skip around the file looking for the SOI directly... ...jim On 6/2/2016 5:10 AM, Jayathirth D V wrote: > Fixed typo. > > > > *From:*Jayathirth D V > *Sent:* Thursday, June 02, 2016 5:08 PM > *To:* Philip Race > *Cc:* Jim Graham; 2d-dev at openjdk.java.net > *Subject:* RE: Review Request for JDK-8152672 : Exception while getting > second image properties for JPEG with embedded thumbnail > > > > Hi Phil, > > > > We have two kind of images with which we are able to reproduce the issue: > > 1) sample.jpg present in JBS bug(We can?t use this image because it > is licensed ). > > 2) JpegEmbedThumbnail.jpg taken using Prasanta?s camera and used in > webrev. > > > > _ _ > > _sample.jpg : _ > > _ _ > > If we do getNumImages() it will return 2. getNumImages() follows the > same logic of skipping markers with length and registering SOI to get > number of images. > > sample.jpg has markers as follows : > > SOI -> APP1 - > SOI -> EOI -> APP1 End -> EOI -> SOI -> EOI > > > > I have dumped first image its SOI is first one in the above list and for > second image it is third one in the list. getNumImages() counts first > and third SOI for number of images. But in case of skipImage() we are > getting inside APP1 marker and considering its SOI. > > > > _JpegEmbedThumbnail.jpg :_ > > _ _ > > If we do getNumImages() it will return 1. > > JpegEmbedThumbnail.jpg has markers as follows : > > SOI -> APP1 -> SOI -> EOI -> APP1 End -> APP2 -> SOI -> APP2 End -> APP2 > -> EOI -> APP2 End -> EOI > > > > getNumImages() counts only first SOI for number of images. But in case > of skipImage() we will are getting inside APP1 and APP2 markers also. > > > > Thanks, > > Jay > > *From:*Phil Race > *Sent:* Thursday, June 02, 2016 4:05 AM > *To:* Jayathirth D V > *Cc:* Jim Graham; 2d-dev at openjdk.java.net > *Subject:* Re: Review Request for JDK-8152672 : Exception while getting > second image properties for JPEG with embedded thumbnail > > > > I am bit doubtful about this. Are you sure we are correct in reporting > two images to begin with ? > Thumbnails should not get counted .. > > > -phil. > > On 06/01/2016 01:06 AM, Jayathirth D V wrote: > > Updated bug title in JBS as it was misleading. > > > > *From:* Jayathirth D V > *Sent:* Wednesday, June 01, 2016 12:48 PM > *To:* Philip Race; Jim Graham > *Cc:* 2d-dev at openjdk.java.net > *Subject:* Review Request for JDK-8152672 : Exception getting > thumbnail size for JPEG with embedded thumbnail > > > > Hi, > > > > _Please review the following fix in JDK9:_ > > > > Bug : https://bugs.openjdk.java.net/browse/JDK-8152672 > > > > Webrev : http://cr.openjdk.java.net/~jdv/8152672/webrev.00/ > > > > > Issue : When we are trying to get properties related to second image > in JPEG file we are getting IIOException mentioning that it is not a > JPEG file. > > > > Root cause : When we are skipping first image to reach second image > header, we are just trying to find next available EOI marker. But if > first image has embedded thumbnail in APP1 marker, we will reach to > EOI of this thumbnail and not EOI of first image. So after we reach > EOI of embedded thumbnail we try to access second image SOI marker > which will fail. > > > > Solution : We have to change the logic of how we skip to consecutive > images in JPEG file. We know that application markers, comments or > other markers can contain data same as SOI & EOI. Instead of just > checking for EOI marker serially, we should read length of these > markers and skip them. > > > > Thanks, > > Jay > > > > > From prasanta.sadhukhan at oracle.com Fri Jun 10 04:38:01 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Fri, 10 Jun 2016 10:08:01 +0530 Subject: [OpenJDK 2D-Dev] [9]: RFR JDK-8159134: [PIT][TEST_BUG] failed to run java/awt/print/PrinterJob/PrintDlgSelectionAttribTest.java Message-ID: Hi All, Increased the timeout of this manual test so that user can read and verify the instructions within timelimit to avoid timeout. Bug:https://bugs.openjdk.java.net/browse/JDK-8159134 webrev: http://cr.openjdk.java.net/~psadhukhan/8159134/webrev.00/ Regards Prasanta From jayathirth.d.v at oracle.com Fri Jun 10 06:21:48 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 9 Jun 2016 23:21:48 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail In-Reply-To: <1309b2bb-c189-d623-cfc5-105223718e12@oracle.com> References: <89531a21-64b2-4e00-8f15-aa78650cf7b2@default> <574F62FA.50900@oracle.com> <1309b2bb-c189-d623-cfc5-105223718e12@oracle.com> Message-ID: <70565f43-7547-4047-bca3-f95ae709427e@default> Hi Jim, I think the harmless byte that you are referring to will be applied only for image data(Between SOS(Start of Scan) marker and EOI). For example, any "FF" data present in Jpeg image will be represented as "FF 00". But I think application headers or comments section can contain data which will be similar to EOI,SOI or other markers(FF XX). Thanks, Jay -----Original Message----- From: Jim Graham Sent: Friday, June 10, 2016 5:28 AM To: Jayathirth D V; Philip Race Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail It looks like JPEG files have protection for scanning for an FF and assuming it is a marker by making sure that all FF bytes that appear in data are followed by a harmless byte, so a brute force search is probably fine. But it still seems wasteful when we know we are at a tag and we know the sizes of all of the tags, we should be able to skip around the file looking for the SOI directly... ...jim On 6/2/2016 5:10 AM, Jayathirth D V wrote: > Fixed typo. > > > > *From:*Jayathirth D V > *Sent:* Thursday, June 02, 2016 5:08 PM > *To:* Philip Race > *Cc:* Jim Graham; 2d-dev at openjdk.java.net > *Subject:* RE: Review Request for JDK-8152672 : Exception while > getting second image properties for JPEG with embedded thumbnail > > > > Hi Phil, > > > > We have two kind of images with which we are able to reproduce the issue: > > 1) sample.jpg present in JBS bug(We can't use this image because it > is licensed ). > > 2) JpegEmbedThumbnail.jpg taken using Prasanta's camera and used in > webrev. > > > > _ _ > > _sample.jpg : _ > > _ _ > > If we do getNumImages() it will return 2. getNumImages() follows the > same logic of skipping markers with length and registering SOI to get > number of images. > > sample.jpg has markers as follows : > > SOI -> APP1 - > SOI -> EOI -> APP1 End -> EOI -> SOI -> EOI > > > > I have dumped first image its SOI is first one in the above list and > for second image it is third one in the list. getNumImages() counts > first and third SOI for number of images. But in case of skipImage() > we are getting inside APP1 marker and considering its SOI. > > > > _JpegEmbedThumbnail.jpg :_ > > _ _ > > If we do getNumImages() it will return 1. > > JpegEmbedThumbnail.jpg has markers as follows : > > SOI -> APP1 -> SOI -> EOI -> APP1 End -> APP2 -> SOI -> APP2 End -> > APP2 > -> EOI -> APP2 End -> EOI > > > > getNumImages() counts only first SOI for number of images. But in case > of skipImage() we will are getting inside APP1 and APP2 markers also. > > > > Thanks, > > Jay > > *From:*Phil Race > *Sent:* Thursday, June 02, 2016 4:05 AM > *To:* Jayathirth D V > *Cc:* Jim Graham; 2d-dev at openjdk.java.net > > *Subject:* Re: Review Request for JDK-8152672 : Exception while > getting second image properties for JPEG with embedded thumbnail > > > > I am bit doubtful about this. Are you sure we are correct in reporting > two images to begin with ? > Thumbnails should not get counted .. > > > -phil. > > On 06/01/2016 01:06 AM, Jayathirth D V wrote: > > Updated bug title in JBS as it was misleading. > > > > *From:* Jayathirth D V > *Sent:* Wednesday, June 01, 2016 12:48 PM > *To:* Philip Race; Jim Graham > *Cc:* 2d-dev at openjdk.java.net > *Subject:* Review Request for JDK-8152672 : Exception getting > thumbnail size for JPEG with embedded thumbnail > > > > Hi, > > > > _Please review the following fix in JDK9:_ > > > > Bug : https://bugs.openjdk.java.net/browse/JDK-8152672 > > > > Webrev : http://cr.openjdk.java.net/~jdv/8152672/webrev.00/ > > > > > Issue : When we are trying to get properties related to second image > in JPEG file we are getting IIOException mentioning that it is not a > JPEG file. > > > > Root cause : When we are skipping first image to reach second image > header, we are just trying to find next available EOI marker. But if > first image has embedded thumbnail in APP1 marker, we will reach to > EOI of this thumbnail and not EOI of first image. So after we reach > EOI of embedded thumbnail we try to access second image SOI marker > which will fail. > > > > Solution : We have to change the logic of how we skip to consecutive > images in JPEG file. We know that application markers, comments or > other markers can contain data same as SOI & EOI. Instead of just > checking for EOI marker serially, we should read length of these > markers and skip them. > > > > Thanks, > > Jay > > > > > From yuri.nesterenko at oracle.com Fri Jun 10 10:01:40 2016 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Fri, 10 Jun 2016 13:01:40 +0300 Subject: [OpenJDK 2D-Dev] [9]: RFR JDK-8159134: [PIT][TEST_BUG] failed to run java/awt/print/PrinterJob/PrintDlgSelectionAttribTest.java In-Reply-To: References: Message-ID: <575A9004.4020502@oracle.com> +1 Thank you! -yan On 06/10/2016 07:38 AM, prasanta sadhukhan wrote: > Hi All, > > Increased the timeout of this manual test so that user can read and > verify the instructions within timelimit to avoid timeout. > > Bug:https://bugs.openjdk.java.net/browse/JDK-8159134 > > webrev: http://cr.openjdk.java.net/~psadhukhan/8159134/webrev.00/ > > Regards > > Prasanta > From bourges.laurent at gmail.com Fri Jun 10 11:59:48 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Fri, 10 Jun 2016 13:59:48 +0200 Subject: [OpenJDK 2D-Dev] RFR 8159093: Fix coding conventions in Marlin renderer In-Reply-To: References: Message-ID: Jim, I fixed the issues you mentioned, see below. Here is the new webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8159093.1/ I also fixed the bracket position (int val[] => int[] val) in Helpers, MarlinRenderingEngine, MarlinTileGenerator classes. My comments: 2016-06-10 1:48 GMT+02:00 Jim Graham : > > In RendererStats, lines 276,277 - is it better to convert to an array > (which is an inherently risky situation for a concurrent collection due to > the potential for the size changing between the array allocation and the > toArray), or to iterate the concurrent collection directly? I realize that > the toArray() method protects against a short array, but is it any better > than just directly iterating which would deal with the concurrency > automatically anyway without having to allocate an array. One thing to > note, if you convert to an array and there is a concurrency issue then the > array may have a null entry to indicate "this is the end of the list", but > you don't look for that null entry. A simple "if rdrCtx==null break;" > statement would be enough to deal with that case. > I agree and adopted the simplest solution: iterate directly on the concurrent queue. > MarlinConst.java - you added DO_FLUSH_STATS, but I don't see it getting > used anywhere...? > Exact; I removed it as it will be only used in the next patch. > MarlinRenderingEngine.java - it looks like you eliminated all uses of > mon_npi_currentSegment, but it is still created in RendererStats...? > mon_npi_currentSegment removed in RendererStats. > Histogram.java - 2016 copyright > Fixed. Regards, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.markov at oracle.com Fri Jun 10 12:07:06 2016 From: dmitry.markov at oracle.com (dmitry markov) Date: Fri, 10 Jun 2016 15:07:06 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8144703: ClassCastException: sun.font.CompositeFont cannot be cast to PhysicalFont Message-ID: <575AAD6A.5040903@oracle.com> Hello, Could you review a fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8144703 webrev: http://cr.openjdk.java.net/~dmarkov/8144703/webrev.00/ Problem description: If an incorrect font file is used, we unable to initialize the font during CompositeFont.doDeferredInitialisation() invocation and assign default physical font to the corresponding components entry. Later at the same method, (i.e. doDeferredInitialisation()) we try to update this entry one more time, since the name retrieved from the entry and the name provide by componentNames array are different. The method SunFontManager.findFont2D() may return a composite font for such case. As a result we get ClassCastException trying to assign CompositeFont object to the instance of PhysicalFont. Fix: Surround invocation of SunFontManager.findFont2D() inside CompositeFont.doDeferredInitialisation() with 'try-catch' to avoid propagation of ClassCastException. Thanks, Dmitry From james.graham at oracle.com Fri Jun 10 21:36:33 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 10 Jun 2016 14:36:33 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail In-Reply-To: <70565f43-7547-4047-bca3-f95ae709427e@default> References: <89531a21-64b2-4e00-8f15-aa78650cf7b2@default> <574F62FA.50900@oracle.com> <1309b2bb-c189-d623-cfc5-105223718e12@oracle.com> <70565f43-7547-4047-bca3-f95ae709427e@default> Message-ID: <7b22a1ca-5e6a-c705-90bc-510aa2073c90@oracle.com> Thanks for the response Jay, I think I was misreading some of the code as now that I look back at it, it's mostly written as I was suggesting with respect to skipping over data sections, however it is still doing some scanning to find the initial 0xFF. Some thoughts: - If we can be sure that we are located at where a tag should be, then shouldn't we just read a byte and assert that it is 0xFF and report the file as invalid if it isn't? The current code will just ignore the byte and continue reading until it finds a 0xFF, but the fact that the first byte we read isn't 0xFF means we have wandered into data that isn't following the file format (or, possibly, that this was called from a case where we hadn't completely read a section of data, but that should be fixed as we could be in the middle of a section that isn't entropy encoded and our search for 0xFF might have invalid assumptions). - The bytes read in the default section to get the length and the tag for the next block aren't tested for EOF (-1). This may even get us into an infinite loop if we hit EOF at the right time (just after a sized block tag) as the size bytes will read and combine into a -1 size, back up three bytes, and then reread the same tag and try to compute a length again which will send us back 3 bytes, etc. - default assumes that all other markers that are created will be sized, but can we assert that? Shouldn't we specifically list all known sized markers and have the default case reject the file as not being of a format that we recognize? ...jim On 6/9/2016 11:21 PM, Jayathirth D V wrote: > Hi Jim, > > I think the harmless byte that you are referring to will be applied only for image data(Between SOS(Start of Scan) marker and EOI). For example, any "FF" data present in Jpeg image will be represented as "FF 00". But I think application headers or comments section can contain data which will be similar to EOI,SOI or other markers(FF XX). > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Friday, June 10, 2016 5:28 AM > To: Jayathirth D V; Philip Race > Cc: 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail > > It looks like JPEG files have protection for scanning for an FF and assuming it is a marker by making sure that all FF bytes that appear in data are followed by a harmless byte, so a brute force search is probably fine. But it still seems wasteful when we know we are at a tag and we know the sizes of all of the tags, we should be able to skip around the file looking for the SOI directly... > > ...jim > > On 6/2/2016 5:10 AM, Jayathirth D V wrote: >> Fixed typo. >> >> >> >> *From:*Jayathirth D V >> *Sent:* Thursday, June 02, 2016 5:08 PM >> *To:* Philip Race >> *Cc:* Jim Graham; 2d-dev at openjdk.java.net >> *Subject:* RE: Review Request for JDK-8152672 : Exception while >> getting second image properties for JPEG with embedded thumbnail >> >> >> >> Hi Phil, >> >> >> >> We have two kind of images with which we are able to reproduce the issue: >> >> 1) sample.jpg present in JBS bug(We can't use this image because it >> is licensed ). >> >> 2) JpegEmbedThumbnail.jpg taken using Prasanta's camera and used in >> webrev. >> >> >> >> _ _ >> >> _sample.jpg : _ >> >> _ _ >> >> If we do getNumImages() it will return 2. getNumImages() follows the >> same logic of skipping markers with length and registering SOI to get >> number of images. >> >> sample.jpg has markers as follows : >> >> SOI -> APP1 - > SOI -> EOI -> APP1 End -> EOI -> SOI -> EOI >> >> >> >> I have dumped first image its SOI is first one in the above list and >> for second image it is third one in the list. getNumImages() counts >> first and third SOI for number of images. But in case of skipImage() >> we are getting inside APP1 marker and considering its SOI. >> >> >> >> _JpegEmbedThumbnail.jpg :_ >> >> _ _ >> >> If we do getNumImages() it will return 1. >> >> JpegEmbedThumbnail.jpg has markers as follows : >> >> SOI -> APP1 -> SOI -> EOI -> APP1 End -> APP2 -> SOI -> APP2 End -> >> APP2 >> -> EOI -> APP2 End -> EOI >> >> >> >> getNumImages() counts only first SOI for number of images. But in case >> of skipImage() we will are getting inside APP1 and APP2 markers also. >> >> >> >> Thanks, >> >> Jay >> >> *From:*Phil Race >> *Sent:* Thursday, June 02, 2016 4:05 AM >> *To:* Jayathirth D V >> *Cc:* Jim Graham; 2d-dev at openjdk.java.net >> >> *Subject:* Re: Review Request for JDK-8152672 : Exception while >> getting second image properties for JPEG with embedded thumbnail >> >> >> >> I am bit doubtful about this. Are you sure we are correct in reporting >> two images to begin with ? >> Thumbnails should not get counted .. >> >> >> -phil. >> >> On 06/01/2016 01:06 AM, Jayathirth D V wrote: >> >> Updated bug title in JBS as it was misleading. >> >> >> >> *From:* Jayathirth D V >> *Sent:* Wednesday, June 01, 2016 12:48 PM >> *To:* Philip Race; Jim Graham >> *Cc:* 2d-dev at openjdk.java.net >> *Subject:* Review Request for JDK-8152672 : Exception getting >> thumbnail size for JPEG with embedded thumbnail >> >> >> >> Hi, >> >> >> >> _Please review the following fix in JDK9:_ >> >> >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8152672 >> >> >> >> Webrev : http://cr.openjdk.java.net/~jdv/8152672/webrev.00/ >> >> >> >> >> Issue : When we are trying to get properties related to second image >> in JPEG file we are getting IIOException mentioning that it is not a >> JPEG file. >> >> >> >> Root cause : When we are skipping first image to reach second image >> header, we are just trying to find next available EOI marker. But if >> first image has embedded thumbnail in APP1 marker, we will reach to >> EOI of this thumbnail and not EOI of first image. So after we reach >> EOI of embedded thumbnail we try to access second image SOI marker >> which will fail. >> >> >> >> Solution : We have to change the logic of how we skip to consecutive >> images in JPEG file. We know that application markers, comments or >> other markers can contain data same as SOI & EOI. Instead of just >> checking for EOI marker serially, we should read length of these >> markers and skip them. >> >> >> >> Thanks, >> >> Jay >> >> >> >> >> From james.graham at oracle.com Fri Jun 10 21:54:02 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 10 Jun 2016 14:54:02 -0700 Subject: [OpenJDK 2D-Dev] RFR 8159093: Fix coding conventions in Marlin renderer In-Reply-To: References: Message-ID: <1970cc79-31ce-7231-2681-d49ce283323e@oracle.com> Thanks Laurent, Eeek, I hate the type[] syntax for declaring arrays, but I guess I have to grow with the times. One last thing I just noticed, RendererState.getInstance doesn't protect against MT access if multiple threads encounter the null instance case and all decide to make their own... ...jim On 6/10/2016 4:59 AM, Laurent Bourg?s wrote: > Jim, > > I fixed the issues you mentioned, see below. > > Here is the new webrev: > http://cr.openjdk.java.net/~lbourges/marlin/marlin-8159093.1/ > > I also fixed the bracket position (int val[] => int[] val) in Helpers, > MarlinRenderingEngine, MarlinTileGenerator classes. > > My comments: > > 2016-06-10 1:48 GMT+02:00 Jim Graham >: > > > In RendererStats, lines 276,277 - is it better to convert to an > array (which is an inherently risky situation for a concurrent > collection due to the potential for the size changing between the > array allocation and the toArray), or to iterate the concurrent > collection directly? I realize that the toArray() method protects > against a short array, but is it any better than just directly > iterating which would deal with the concurrency automatically anyway > without having to allocate an array. One thing to note, if you > convert to an array and there is a concurrency issue then the array > may have a null entry to indicate "this is the end of the list", but > you don't look for that null entry. A simple "if rdrCtx==null > break;" statement would be enough to deal with that case. > > > I agree and adopted the simplest solution: iterate directly on the > concurrent queue. > > > MarlinConst.java - you added DO_FLUSH_STATS, but I don't see it > getting used anywhere...? > > > Exact; I removed it as it will be only used in the next patch. > > > MarlinRenderingEngine.java - it looks like you eliminated all uses > of mon_npi_currentSegment, but it is still created in RendererStats...? > > > mon_npi_currentSegment removed in RendererStats. > > > Histogram.java - 2016 copyright > > > Fixed. > > Regards, > Laurent From james.graham at oracle.com Fri Jun 10 23:59:13 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 10 Jun 2016 16:59:13 -0700 Subject: [OpenJDK 2D-Dev] RFR 8159093: Fix coding conventions in Marlin renderer In-Reply-To: <1970cc79-31ce-7231-2681-d49ce283323e@oracle.com> References: <1970cc79-31ce-7231-2681-d49ce283323e@oracle.com> Message-ID: <92b7df47-380e-3247-3ccd-e3b9fda9a43f@oracle.com> The getInstance MT issue could be filed as a separate follow-on bug if you want, in which case webrev.1 is good to go... ...jim On 6/10/2016 2:54 PM, Jim Graham wrote: > Thanks Laurent, > > Eeek, I hate the type[] syntax for declaring arrays, but I guess I have > to grow with the times. > > One last thing I just noticed, RendererState.getInstance doesn't protect > against MT access if multiple threads encounter the null instance case > and all decide to make their own... > > ...jim > > On 6/10/2016 4:59 AM, Laurent Bourg?s wrote: >> Jim, >> >> I fixed the issues you mentioned, see below. >> >> Here is the new webrev: >> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8159093.1/ >> >> I also fixed the bracket position (int val[] => int[] val) in Helpers, >> MarlinRenderingEngine, MarlinTileGenerator classes. >> >> My comments: >> >> 2016-06-10 1:48 GMT+02:00 Jim Graham > >: >> >> >> In RendererStats, lines 276,277 - is it better to convert to an >> array (which is an inherently risky situation for a concurrent >> collection due to the potential for the size changing between the >> array allocation and the toArray), or to iterate the concurrent >> collection directly? I realize that the toArray() method protects >> against a short array, but is it any better than just directly >> iterating which would deal with the concurrency automatically anyway >> without having to allocate an array. One thing to note, if you >> convert to an array and there is a concurrency issue then the array >> may have a null entry to indicate "this is the end of the list", but >> you don't look for that null entry. A simple "if rdrCtx==null >> break;" statement would be enough to deal with that case. >> >> >> I agree and adopted the simplest solution: iterate directly on the >> concurrent queue. >> >> >> MarlinConst.java - you added DO_FLUSH_STATS, but I don't see it >> getting used anywhere...? >> >> >> Exact; I removed it as it will be only used in the next patch. >> >> >> MarlinRenderingEngine.java - it looks like you eliminated all uses >> of mon_npi_currentSegment, but it is still created in >> RendererStats...? >> >> >> mon_npi_currentSegment removed in RendererStats. >> >> >> Histogram.java - 2016 copyright >> >> >> Fixed. >> >> Regards, >> Laurent From bourges.laurent at gmail.com Mon Jun 13 11:31:35 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Mon, 13 Jun 2016 13:31:35 +0200 Subject: [OpenJDK 2D-Dev] RFR 8159093: Fix coding conventions in Marlin renderer In-Reply-To: <92b7df47-380e-3247-3ccd-e3b9fda9a43f@oracle.com> References: <1970cc79-31ce-7231-2681-d49ce283323e@oracle.com> <92b7df47-380e-3247-3ccd-e3b9fda9a43f@oracle.com> Message-ID: Jim, This MT issue concerns only statistics collection so I deliberately did not ensure thread safety to avoid a synchronized block as the code is still "safe". Anyway I can fix it in the next patch that will improve array cache and stats per rendering context. Laurent Le 11 juin 2016 01:59, "Jim Graham" a ?crit : > > The getInstance MT issue could be filed as a separate follow-on bug if you want, in which case webrev.1 is good to go... > > ...jim > > > On 6/10/2016 2:54 PM, Jim Graham wrote: >> >> Thanks Laurent, >> >> Eeek, I hate the type[] syntax for declaring arrays, but I guess I have >> to grow with the times. >> >> One last thing I just noticed, RendererState.getInstance doesn't protect >> against MT access if multiple threads encounter the null instance case >> and all decide to make their own... >> >> ...jim >> >> On 6/10/2016 4:59 AM, Laurent Bourg?s wrote: >>> >>> Jim, >>> >>> I fixed the issues you mentioned, see below. >>> >>> Here is the new webrev: >>> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8159093.1/ >>> >>> I also fixed the bracket position (int val[] => int[] val) in Helpers, >>> MarlinRenderingEngine, MarlinTileGenerator classes. >>> >>> My comments: >>> >>> 2016-06-10 1:48 GMT+02:00 Jim Graham >> >: >>> >>> >>> In RendererStats, lines 276,277 - is it better to convert to an >>> array (which is an inherently risky situation for a concurrent >>> collection due to the potential for the size changing between the >>> array allocation and the toArray), or to iterate the concurrent >>> collection directly? I realize that the toArray() method protects >>> against a short array, but is it any better than just directly >>> iterating which would deal with the concurrency automatically anyway >>> without having to allocate an array. One thing to note, if you >>> convert to an array and there is a concurrency issue then the array >>> may have a null entry to indicate "this is the end of the list", but >>> you don't look for that null entry. A simple "if rdrCtx==null >>> break;" statement would be enough to deal with that case. >>> >>> >>> I agree and adopted the simplest solution: iterate directly on the >>> concurrent queue. >>> >>> >>> MarlinConst.java - you added DO_FLUSH_STATS, but I don't see it >>> getting used anywhere...? >>> >>> >>> Exact; I removed it as it will be only used in the next patch. >>> >>> >>> MarlinRenderingEngine.java - it looks like you eliminated all uses >>> of mon_npi_currentSegment, but it is still created in >>> RendererStats...? >>> >>> >>> mon_npi_currentSegment removed in RendererStats. >>> >>> >>> Histogram.java - 2016 copyright >>> >>> >>> Fixed. >>> >>> Regards, >>> Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Mon Jun 13 14:00:41 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 13 Jun 2016 07:00:41 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-6386906 : Faulty rounding code in BMPImageReader.decodeRLE4() Message-ID: <0d4c6456-598b-4279-8899-1547743362ed@default> Hi, Please review the following fix in JDK9: Bug : https://bugs.openjdk.java.net/browse/JDK-6386906 Webrev : http://cr.openjdk.java.net/~jdv/6386906/webrev.00/ Issue : We are dividing an integer with another integer and trying to perform ceil() on resultant value which will be an integer. Resultant value will not have fractional part and ceil() operation is invalid. Solution : Update the code to divide the integer with floating point variable so that ceil() operation becomes valid. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Mon Jun 13 17:00:07 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 13 Jun 2016 10:00:07 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail In-Reply-To: <7b22a1ca-5e6a-c705-90bc-510aa2073c90@oracle.com> References: <89531a21-64b2-4e00-8f15-aa78650cf7b2@default> <574F62FA.50900@oracle.com> <1309b2bb-c189-d623-cfc5-105223718e12@oracle.com> <70565f43-7547-4047-bca3-f95ae709427e@default> <7b22a1ca-5e6a-c705-90bc-510aa2073c90@oracle.com> Message-ID: <1b962d5d-ae52-4281-8ca8-d6d5558e3fe5@default> Hi Jim, Thanks for your valuable inputs. I have updated the code with your inputs: 1) We should check for complete SOI marker and not just "FF" at start of skipImage(). 2) There is no need of iis.read() which was happening in default case. iis.read() present in for loop check will take care of checking EOF. 3) I have added case condition for all the markers having length and added default case where we get invalid marker starting with FF. Apart from above changes, after going more through https://www.w3.org/Graphics/JPEG/itu-t81.pdf got to know following things: 1) TEM is also one more marker without length so added case for that. 2) Since we have all unique conditions checked, we should not find any SOI marker after the initial SOI marker before we find EOI. Made changes to throw IOException in this case. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/8152672/webrev.01/ Thanks, Jay -----Original Message----- From: Jim Graham Sent: Saturday, June 11, 2016 3:07 AM To: Jayathirth D V; Philip Race Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail Thanks for the response Jay, I think I was misreading some of the code as now that I look back at it, it's mostly written as I was suggesting with respect to skipping over data sections, however it is still doing some scanning to find the initial 0xFF. Some thoughts: - If we can be sure that we are located at where a tag should be, then shouldn't we just read a byte and assert that it is 0xFF and report the file as invalid if it isn't? The current code will just ignore the byte and continue reading until it finds a 0xFF, but the fact that the first byte we read isn't 0xFF means we have wandered into data that isn't following the file format (or, possibly, that this was called from a case where we hadn't completely read a section of data, but that should be fixed as we could be in the middle of a section that isn't entropy encoded and our search for 0xFF might have invalid assumptions). - The bytes read in the default section to get the length and the tag for the next block aren't tested for EOF (-1). This may even get us into an infinite loop if we hit EOF at the right time (just after a sized block tag) as the size bytes will read and combine into a -1 size, back up three bytes, and then reread the same tag and try to compute a length again which will send us back 3 bytes, etc. - default assumes that all other markers that are created will be sized, but can we assert that? Shouldn't we specifically list all known sized markers and have the default case reject the file as not being of a format that we recognize? ...jim On 6/9/2016 11:21 PM, Jayathirth D V wrote: > Hi Jim, > > I think the harmless byte that you are referring to will be applied only for image data(Between SOS(Start of Scan) marker and EOI). For example, any "FF" data present in Jpeg image will be represented as "FF 00". But I think application headers or comments section can contain data which will be similar to EOI,SOI or other markers(FF XX). > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Friday, June 10, 2016 5:28 AM > To: Jayathirth D V; Philip Race > Cc: 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : > Exception while getting second image properties for JPEG with embedded > thumbnail > > It looks like JPEG files have protection for scanning for an FF and assuming it is a marker by making sure that all FF bytes that appear in data are followed by a harmless byte, so a brute force search is probably fine. But it still seems wasteful when we know we are at a tag and we know the sizes of all of the tags, we should be able to skip around the file looking for the SOI directly... > > ...jim > > On 6/2/2016 5:10 AM, Jayathirth D V wrote: >> Fixed typo. >> >> >> >> *From:*Jayathirth D V >> *Sent:* Thursday, June 02, 2016 5:08 PM >> *To:* Philip Race >> *Cc:* Jim Graham; 2d-dev at openjdk.java.net >> *Subject:* RE: Review Request for JDK-8152672 : Exception while >> getting second image properties for JPEG with embedded thumbnail >> >> >> >> Hi Phil, >> >> >> >> We have two kind of images with which we are able to reproduce the issue: >> >> 1) sample.jpg present in JBS bug(We can't use this image because it >> is licensed ). >> >> 2) JpegEmbedThumbnail.jpg taken using Prasanta's camera and used in >> webrev. >> >> >> >> _ _ >> >> _sample.jpg : _ >> >> _ _ >> >> If we do getNumImages() it will return 2. getNumImages() follows the >> same logic of skipping markers with length and registering SOI to get >> number of images. >> >> sample.jpg has markers as follows : >> >> SOI -> APP1 - > SOI -> EOI -> APP1 End -> EOI -> SOI -> EOI >> >> >> >> I have dumped first image its SOI is first one in the above list and >> for second image it is third one in the list. getNumImages() counts >> first and third SOI for number of images. But in case of skipImage() >> we are getting inside APP1 marker and considering its SOI. >> >> >> >> _JpegEmbedThumbnail.jpg :_ >> >> _ _ >> >> If we do getNumImages() it will return 1. >> >> JpegEmbedThumbnail.jpg has markers as follows : >> >> SOI -> APP1 -> SOI -> EOI -> APP1 End -> APP2 -> SOI -> APP2 End -> >> APP2 >> -> EOI -> APP2 End -> EOI >> >> >> >> getNumImages() counts only first SOI for number of images. But in >> case of skipImage() we will are getting inside APP1 and APP2 markers also. >> >> >> >> Thanks, >> >> Jay >> >> *From:*Phil Race >> *Sent:* Thursday, June 02, 2016 4:05 AM >> *To:* Jayathirth D V >> *Cc:* Jim Graham; 2d-dev at openjdk.java.net >> >> *Subject:* Re: Review Request for JDK-8152672 : Exception while >> getting second image properties for JPEG with embedded thumbnail >> >> >> >> I am bit doubtful about this. Are you sure we are correct in >> reporting two images to begin with ? >> Thumbnails should not get counted .. >> >> >> -phil. >> >> On 06/01/2016 01:06 AM, Jayathirth D V wrote: >> >> Updated bug title in JBS as it was misleading. >> >> >> >> *From:* Jayathirth D V >> *Sent:* Wednesday, June 01, 2016 12:48 PM >> *To:* Philip Race; Jim Graham >> *Cc:* 2d-dev at openjdk.java.net >> *Subject:* Review Request for JDK-8152672 : Exception getting >> thumbnail size for JPEG with embedded thumbnail >> >> >> >> Hi, >> >> >> >> _Please review the following fix in JDK9:_ >> >> >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8152672 >> >> >> >> Webrev : http://cr.openjdk.java.net/~jdv/8152672/webrev.00/ >> >> >> >> >> Issue : When we are trying to get properties related to second image >> in JPEG file we are getting IIOException mentioning that it is not a >> JPEG file. >> >> >> >> Root cause : When we are skipping first image to reach second image >> header, we are just trying to find next available EOI marker. But if >> first image has embedded thumbnail in APP1 marker, we will reach to >> EOI of this thumbnail and not EOI of first image. So after we reach >> EOI of embedded thumbnail we try to access second image SOI marker >> which will fail. >> >> >> >> Solution : We have to change the logic of how we skip to consecutive >> images in JPEG file. We know that application markers, comments or >> other markers can contain data same as SOI & EOI. Instead of just >> checking for EOI marker serially, we should read length of these >> markers and skip them. >> >> >> >> Thanks, >> >> Jay >> >> >> >> >> From james.graham at oracle.com Mon Jun 13 19:03:33 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 13 Jun 2016 12:03:33 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-6386906 : Faulty rounding code in BMPImageReader.decodeRLE4() In-Reply-To: <0d4c6456-598b-4279-8899-1547743362ed@default> References: <0d4c6456-598b-4279-8899-1547743362ed@default> Message-ID: Why use ceil() at all? If you want Math.ceil(intval/2.0f), use "((intval + 1) / 2)"... ...jim On 6/13/2016 7:00 AM, Jayathirth D V wrote: > Hi, > > > > _Please review the following fix in JDK9:_ > > _ _ > > Bug : https://bugs.openjdk.java.net/browse/JDK-6386906 > > > > Webrev : http://cr.openjdk.java.net/~jdv/6386906/webrev.00/ > > > > Issue : We are dividing an integer with another integer and trying to > perform ceil() on resultant value which will be an integer. Resultant > value will not have fractional part and ceil() operation is invalid. > > > > Solution : Update the code to divide the integer with floating point > variable so that ceil() operation becomes valid. > > > > Thanks, > > Jay > > > From james.graham at oracle.com Mon Jun 13 19:14:09 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 13 Jun 2016 12:14:09 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail In-Reply-To: <1b962d5d-ae52-4281-8ca8-d6d5558e3fe5@default> References: <89531a21-64b2-4e00-8f15-aa78650cf7b2@default> <574F62FA.50900@oracle.com> <1309b2bb-c189-d623-cfc5-105223718e12@oracle.com> <70565f43-7547-4047-bca3-f95ae709427e@default> <7b22a1ca-5e6a-c705-90bc-510aa2073c90@oracle.com> <1b962d5d-ae52-4281-8ca8-d6d5558e3fe5@default> Message-ID: Hi Jay, You still don't check the read() calls in the length case to see if you reached EOF (-1). The potential for an infinite loop is still there. Also, you still search for an FF, even if you require the function to start at an SOI marker - all subsequent markers are still subject to a search rather than a deterministic requirement that we encounter markers with no gaps between them. Why do we have the foundFF variable in the first place? If we just saw an SOI marker then the next byte *must be* a 0xff (shouldn't it? Am I missing something?). We shouldn't read a byte and check if it is a 0xff and then try again, we should expect a single 0xff byte followed by a marker type byte, as in: while (true) { int byteval == iis.read(); // if (byteval < 0) then what? if (byteval != 0xff) { exception } byteval = iis.read(); switch (byteval) { } } The only question is if we get a -1 on the first read if we treat that as an implicit EOI as we do now, or if we treat it as an exception. Note that if we get a -1 in the second read, then we have a half-formed tag and that should fall into the default and be declared a bad file. ...jim On 6/13/2016 10:00 AM, Jayathirth D V wrote: > Hi Jim, > > Thanks for your valuable inputs. > I have updated the code with your inputs: > 1) We should check for complete SOI marker and not just "FF" at start of skipImage(). > 2) There is no need of iis.read() which was happening in default case. iis.read() present in for loop check will take care of checking EOF. > 3) I have added case condition for all the markers having length and added default case where we get invalid marker starting with FF. > > Apart from above changes, after going more through https://www.w3.org/Graphics/JPEG/itu-t81.pdf got to know following things: > > 1) TEM is also one more marker without length so added case for that. > 2) Since we have all unique conditions checked, we should not find any SOI marker after the initial SOI marker before we find EOI. Made changes to throw IOException in this case. > > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/8152672/webrev.01/ > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Saturday, June 11, 2016 3:07 AM > To: Jayathirth D V; Philip Race > Cc: 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail > > Thanks for the response Jay, I think I was misreading some of the code as now that I look back at it, it's mostly written as I was suggesting with respect to skipping over data sections, however it is still doing some scanning to find the initial 0xFF. Some thoughts: > > - If we can be sure that we are located at where a tag should be, then shouldn't we just read a byte and assert that it is 0xFF and report the file as invalid if it isn't? The current code will just ignore the byte and continue reading until it finds a 0xFF, but the fact that the first byte we read isn't 0xFF means we have wandered into data that isn't following the file format (or, possibly, that this was called from a case where we hadn't completely read a section of data, but that should be fixed as we could be in the middle of a section that isn't entropy encoded and our search for 0xFF might have invalid assumptions). > > - The bytes read in the default section to get the length and the tag for the next block aren't tested for EOF (-1). This may even get us into an infinite loop if we hit EOF at the right time (just after a sized block tag) as the size bytes will read and combine into a -1 size, back up three bytes, and then reread the same tag and try to compute a length again which will send us back 3 bytes, etc. > > - default assumes that all other markers that are created will be sized, but can we assert that? Shouldn't we specifically list all known sized markers and have the default case reject the file as not being of a format that we recognize? > > ...jim > > On 6/9/2016 11:21 PM, Jayathirth D V wrote: >> Hi Jim, >> >> I think the harmless byte that you are referring to will be applied only for image data(Between SOS(Start of Scan) marker and EOI). For example, any "FF" data present in Jpeg image will be represented as "FF 00". But I think application headers or comments section can contain data which will be similar to EOI,SOI or other markers(FF XX). >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Friday, June 10, 2016 5:28 AM >> To: Jayathirth D V; Philip Race >> Cc: 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : >> Exception while getting second image properties for JPEG with embedded >> thumbnail >> >> It looks like JPEG files have protection for scanning for an FF and assuming it is a marker by making sure that all FF bytes that appear in data are followed by a harmless byte, so a brute force search is probably fine. But it still seems wasteful when we know we are at a tag and we know the sizes of all of the tags, we should be able to skip around the file looking for the SOI directly... >> >> ...jim >> >> On 6/2/2016 5:10 AM, Jayathirth D V wrote: >>> Fixed typo. >>> >>> >>> >>> *From:*Jayathirth D V >>> *Sent:* Thursday, June 02, 2016 5:08 PM >>> *To:* Philip Race >>> *Cc:* Jim Graham; 2d-dev at openjdk.java.net >>> *Subject:* RE: Review Request for JDK-8152672 : Exception while >>> getting second image properties for JPEG with embedded thumbnail >>> >>> >>> >>> Hi Phil, >>> >>> >>> >>> We have two kind of images with which we are able to reproduce the issue: >>> >>> 1) sample.jpg present in JBS bug(We can't use this image because it >>> is licensed ). >>> >>> 2) JpegEmbedThumbnail.jpg taken using Prasanta's camera and used in >>> webrev. >>> >>> >>> >>> _ _ >>> >>> _sample.jpg : _ >>> >>> _ _ >>> >>> If we do getNumImages() it will return 2. getNumImages() follows the >>> same logic of skipping markers with length and registering SOI to get >>> number of images. >>> >>> sample.jpg has markers as follows : >>> >>> SOI -> APP1 - > SOI -> EOI -> APP1 End -> EOI -> SOI -> EOI >>> >>> >>> >>> I have dumped first image its SOI is first one in the above list and >>> for second image it is third one in the list. getNumImages() counts >>> first and third SOI for number of images. But in case of skipImage() >>> we are getting inside APP1 marker and considering its SOI. >>> >>> >>> >>> _JpegEmbedThumbnail.jpg :_ >>> >>> _ _ >>> >>> If we do getNumImages() it will return 1. >>> >>> JpegEmbedThumbnail.jpg has markers as follows : >>> >>> SOI -> APP1 -> SOI -> EOI -> APP1 End -> APP2 -> SOI -> APP2 End -> >>> APP2 >>> -> EOI -> APP2 End -> EOI >>> >>> >>> >>> getNumImages() counts only first SOI for number of images. But in >>> case of skipImage() we will are getting inside APP1 and APP2 markers also. >>> >>> >>> >>> Thanks, >>> >>> Jay >>> >>> *From:*Phil Race >>> *Sent:* Thursday, June 02, 2016 4:05 AM >>> *To:* Jayathirth D V >>> *Cc:* Jim Graham; 2d-dev at openjdk.java.net >>> >>> *Subject:* Re: Review Request for JDK-8152672 : Exception while >>> getting second image properties for JPEG with embedded thumbnail >>> >>> >>> >>> I am bit doubtful about this. Are you sure we are correct in >>> reporting two images to begin with ? >>> Thumbnails should not get counted .. >>> >>> >>> -phil. >>> >>> On 06/01/2016 01:06 AM, Jayathirth D V wrote: >>> >>> Updated bug title in JBS as it was misleading. >>> >>> >>> >>> *From:* Jayathirth D V >>> *Sent:* Wednesday, June 01, 2016 12:48 PM >>> *To:* Philip Race; Jim Graham >>> *Cc:* 2d-dev at openjdk.java.net >>> *Subject:* Review Request for JDK-8152672 : Exception getting >>> thumbnail size for JPEG with embedded thumbnail >>> >>> >>> >>> Hi, >>> >>> >>> >>> _Please review the following fix in JDK9:_ >>> >>> >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8152672 >>> >>> >>> >>> Webrev : http://cr.openjdk.java.net/~jdv/8152672/webrev.00/ >>> >>> >>> >>> >>> Issue : When we are trying to get properties related to second image >>> in JPEG file we are getting IIOException mentioning that it is not a >>> JPEG file. >>> >>> >>> >>> Root cause : When we are skipping first image to reach second image >>> header, we are just trying to find next available EOI marker. But if >>> first image has embedded thumbnail in APP1 marker, we will reach to >>> EOI of this thumbnail and not EOI of first image. So after we reach >>> EOI of embedded thumbnail we try to access second image SOI marker >>> which will fail. >>> >>> >>> >>> Solution : We have to change the logic of how we skip to consecutive >>> images in JPEG file. We know that application markers, comments or >>> other markers can contain data same as SOI & EOI. Instead of just >>> checking for EOI marker serially, we should read length of these >>> markers and skip them. >>> >>> >>> >>> Thanks, >>> >>> Jay >>> >>> >>> >>> >>> From jayathirth.d.v at oracle.com Tue Jun 14 16:36:04 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 14 Jun 2016 09:36:04 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail In-Reply-To: References: <89531a21-64b2-4e00-8f15-aa78650cf7b2@default> <574F62FA.50900@oracle.com> <1309b2bb-c189-d623-cfc5-105223718e12@oracle.com> <70565f43-7547-4047-bca3-f95ae709427e@default> <7b22a1ca-5e6a-c705-90bc-510aa2073c90@oracle.com> <1b962d5d-ae52-4281-8ca8-d6d5558e3fe5@default> Message-ID: <9c521f0e-1f76-420b-bf51-3495c5779b83@default> Hi Jim, I have updated the code to add check for EOF even in case of reading length. Also I have updated the code such that in all the cases where we find EOF before EOI we are throwing IndexOutOfBoundsException and in other failed cases we are throwing IOException. More analysis : All the length markers that we are checking in our case have valid length data except SOS marker in which always the length value will be 12 and it is the value only for the length of Scan header. After Scan header(SOS) we have compressed data for which we have no parameter which gives the length so that we can skip it completely. Once we get to the initial SOS header it can take 3 paths based on how the data follows: a) If we don't have Restart enabled and if we scan continuously through compressed data we will find EOI otherwise we will find RST markers and then EOI marker. b) If we have multiple scan headers(Multi-scan scenario) we have to follow point 'a' in loop with each scan header separated by DNL and other miscellaneous tables. c) If we have multiple frame headers(Multi-frame scenario) we have to follow point 'b' in loop with different markers coming in between. Above information is taken from page 52 of https://www.w3.org/Graphics/JPEG/itu-t81.pdf Since we can't rely on length specified in SOS header and there is possibility of having multiple SOS headers, we need to search for FF(foundFF). It means even if we jump for the length specified is SOS header the next byte is not promised to be '0xff'. For all the remaining markers we will get proper information related to the length and we will skip all data part(which might contain data similar to EOI/SOI/or any other marker). While propagating through the 'for' loop we are following the same approach. Please find updated webrev for review : http://cr.openjdk.java.net/~jdv/8152672/webrev.02/ Thanks, Jay -----Original Message----- From: Jim Graham Sent: Tuesday, June 14, 2016 12:44 AM To: Jayathirth D V Cc: 2d-dev at openjdk.java.net; Philip Race Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail Hi Jay, You still don't check the read() calls in the length case to see if you reached EOF (-1). The potential for an infinite loop is still there. Also, you still search for an FF, even if you require the function to start at an SOI marker - all subsequent markers are still subject to a search rather than a deterministic requirement that we encounter markers with no gaps between them. Why do we have the foundFF variable in the first place? If we just saw an SOI marker then the next byte *must be* a 0xff (shouldn't it? Am I missing something?). We shouldn't read a byte and check if it is a 0xff and then try again, we should expect a single 0xff byte followed by a marker type byte, as in: while (true) { int byteval == iis.read(); // if (byteval < 0) then what? if (byteval != 0xff) { exception } byteval = iis.read(); switch (byteval) { } } The only question is if we get a -1 on the first read if we treat that as an implicit EOI as we do now, or if we treat it as an exception. Note that if we get a -1 in the second read, then we have a half-formed tag and that should fall into the default and be declared a bad file. ...jim On 6/13/2016 10:00 AM, Jayathirth D V wrote: > Hi Jim, > > Thanks for your valuable inputs. > I have updated the code with your inputs: > 1) We should check for complete SOI marker and not just "FF" at start of skipImage(). > 2) There is no need of iis.read() which was happening in default case. iis.read() present in for loop check will take care of checking EOF. > 3) I have added case condition for all the markers having length and added default case where we get invalid marker starting with FF. > > Apart from above changes, after going more through https://www.w3.org/Graphics/JPEG/itu-t81.pdf got to know following things: > > 1) TEM is also one more marker without length so added case for that. > 2) Since we have all unique conditions checked, we should not find any SOI marker after the initial SOI marker before we find EOI. Made changes to throw IOException in this case. > > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/8152672/webrev.01/ > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Saturday, June 11, 2016 3:07 AM > To: Jayathirth D V; Philip Race > Cc: 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : > Exception while getting second image properties for JPEG with embedded > thumbnail > > Thanks for the response Jay, I think I was misreading some of the code as now that I look back at it, it's mostly written as I was suggesting with respect to skipping over data sections, however it is still doing some scanning to find the initial 0xFF. Some thoughts: > > - If we can be sure that we are located at where a tag should be, then shouldn't we just read a byte and assert that it is 0xFF and report the file as invalid if it isn't? The current code will just ignore the byte and continue reading until it finds a 0xFF, but the fact that the first byte we read isn't 0xFF means we have wandered into data that isn't following the file format (or, possibly, that this was called from a case where we hadn't completely read a section of data, but that should be fixed as we could be in the middle of a section that isn't entropy encoded and our search for 0xFF might have invalid assumptions). > > - The bytes read in the default section to get the length and the tag for the next block aren't tested for EOF (-1). This may even get us into an infinite loop if we hit EOF at the right time (just after a sized block tag) as the size bytes will read and combine into a -1 size, back up three bytes, and then reread the same tag and try to compute a length again which will send us back 3 bytes, etc. > > - default assumes that all other markers that are created will be sized, but can we assert that? Shouldn't we specifically list all known sized markers and have the default case reject the file as not being of a format that we recognize? > > ...jim > > On 6/9/2016 11:21 PM, Jayathirth D V wrote: >> Hi Jim, >> >> I think the harmless byte that you are referring to will be applied only for image data(Between SOS(Start of Scan) marker and EOI). For example, any "FF" data present in Jpeg image will be represented as "FF 00". But I think application headers or comments section can contain data which will be similar to EOI,SOI or other markers(FF XX). >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Friday, June 10, 2016 5:28 AM >> To: Jayathirth D V; Philip Race >> Cc: 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : >> Exception while getting second image properties for JPEG with >> embedded thumbnail >> >> It looks like JPEG files have protection for scanning for an FF and assuming it is a marker by making sure that all FF bytes that appear in data are followed by a harmless byte, so a brute force search is probably fine. But it still seems wasteful when we know we are at a tag and we know the sizes of all of the tags, we should be able to skip around the file looking for the SOI directly... >> >> ...jim >> >> On 6/2/2016 5:10 AM, Jayathirth D V wrote: >>> Fixed typo. >>> >>> >>> >>> *From:*Jayathirth D V >>> *Sent:* Thursday, June 02, 2016 5:08 PM >>> *To:* Philip Race >>> *Cc:* Jim Graham; 2d-dev at openjdk.java.net >>> *Subject:* RE: Review Request for JDK-8152672 : Exception while >>> getting second image properties for JPEG with embedded thumbnail >>> >>> >>> >>> Hi Phil, >>> >>> >>> >>> We have two kind of images with which we are able to reproduce the issue: >>> >>> 1) sample.jpg present in JBS bug(We can't use this image because it >>> is licensed ). >>> >>> 2) JpegEmbedThumbnail.jpg taken using Prasanta's camera and used in >>> webrev. >>> >>> >>> >>> _ _ >>> >>> _sample.jpg : _ >>> >>> _ _ >>> >>> If we do getNumImages() it will return 2. getNumImages() follows the >>> same logic of skipping markers with length and registering SOI to >>> get number of images. >>> >>> sample.jpg has markers as follows : >>> >>> SOI -> APP1 - > SOI -> EOI -> APP1 End -> EOI -> SOI -> EOI >>> >>> >>> >>> I have dumped first image its SOI is first one in the above list and >>> for second image it is third one in the list. getNumImages() counts >>> first and third SOI for number of images. But in case of skipImage() >>> we are getting inside APP1 marker and considering its SOI. >>> >>> >>> >>> _JpegEmbedThumbnail.jpg :_ >>> >>> _ _ >>> >>> If we do getNumImages() it will return 1. >>> >>> JpegEmbedThumbnail.jpg has markers as follows : >>> >>> SOI -> APP1 -> SOI -> EOI -> APP1 End -> APP2 -> SOI -> APP2 End -> >>> APP2 >>> -> EOI -> APP2 End -> EOI >>> >>> >>> >>> getNumImages() counts only first SOI for number of images. But in >>> case of skipImage() we will are getting inside APP1 and APP2 markers also. >>> >>> >>> >>> Thanks, >>> >>> Jay >>> >>> *From:*Phil Race >>> *Sent:* Thursday, June 02, 2016 4:05 AM >>> *To:* Jayathirth D V >>> *Cc:* Jim Graham; 2d-dev at openjdk.java.net >>> >>> *Subject:* Re: Review Request for JDK-8152672 : Exception while >>> getting second image properties for JPEG with embedded thumbnail >>> >>> >>> >>> I am bit doubtful about this. Are you sure we are correct in >>> reporting two images to begin with ? >>> Thumbnails should not get counted .. >>> >>> >>> -phil. >>> >>> On 06/01/2016 01:06 AM, Jayathirth D V wrote: >>> >>> Updated bug title in JBS as it was misleading. >>> >>> >>> >>> *From:* Jayathirth D V >>> *Sent:* Wednesday, June 01, 2016 12:48 PM >>> *To:* Philip Race; Jim Graham >>> *Cc:* 2d-dev at openjdk.java.net >>> *Subject:* Review Request for JDK-8152672 : Exception getting >>> thumbnail size for JPEG with embedded thumbnail >>> >>> >>> >>> Hi, >>> >>> >>> >>> _Please review the following fix in JDK9:_ >>> >>> >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8152672 >>> >>> >>> >>> Webrev : http://cr.openjdk.java.net/~jdv/8152672/webrev.00/ >>> >>> >>> >>> >>> Issue : When we are trying to get properties related to second image >>> in JPEG file we are getting IIOException mentioning that it is not a >>> JPEG file. >>> >>> >>> >>> Root cause : When we are skipping first image to reach second image >>> header, we are just trying to find next available EOI marker. But if >>> first image has embedded thumbnail in APP1 marker, we will reach to >>> EOI of this thumbnail and not EOI of first image. So after we reach >>> EOI of embedded thumbnail we try to access second image SOI marker >>> which will fail. >>> >>> >>> >>> Solution : We have to change the logic of how we skip to consecutive >>> images in JPEG file. We know that application markers, comments or >>> other markers can contain data same as SOI & EOI. Instead of just >>> checking for EOI marker serially, we should read length of these >>> markers and skip them. >>> >>> >>> >>> Thanks, >>> >>> Jay >>> >>> >>> >>> >>> From jayathirth.d.v at oracle.com Tue Jun 14 18:37:00 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 14 Jun 2016 11:37:00 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-6386906 : Faulty rounding code in BMPImageReader.decodeRLE4() In-Reply-To: References: <0d4c6456-598b-4279-8899-1547743362ed@default> Message-ID: Hi Jim, Thanks for your review. I have updated the changes mentioned by you. Please find the updated webrev for review: http://cr.openjdk.java.net/~jdv/6386906/webrev.01/ Thanks, Jay -----Original Message----- From: Jim Graham Sent: Tuesday, June 14, 2016 12:34 AM To: Jayathirth D V; 2d-dev at openjdk.java.net; Philip Race Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-6386906 : Faulty rounding code in BMPImageReader.decodeRLE4() Why use ceil() at all? If you want Math.ceil(intval/2.0f), use "((intval + 1) / 2)"... ...jim On 6/13/2016 7:00 AM, Jayathirth D V wrote: > Hi, > > > > _Please review the following fix in JDK9:_ > > _ _ > > Bug : https://bugs.openjdk.java.net/browse/JDK-6386906 > > > > Webrev : http://cr.openjdk.java.net/~jdv/6386906/webrev.00/ > > > > Issue : We are dividing an integer with another integer and trying to > perform ceil() on resultant value which will be an integer. Resultant > value will not have fractional part and ceil() operation is invalid. > > > > Solution : Update the code to divide the integer with floating point > variable so that ceil() operation becomes valid. > > > > Thanks, > > Jay > > > From philip.race at oracle.com Tue Jun 14 18:51:36 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 14 Jun 2016 11:51:36 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6966350:Empty pages when printing on Lexmark E352dn PS3 with "1200 IQ" setting In-Reply-To: <4a57f40d-9462-5236-7b2d-df69f97aa8e4@oracle.com> References: <4a57f40d-9462-5236-7b2d-df69f97aa8e4@oracle.com> Message-ID: <57605238.3090707@oracle.com> This sound fishy. "2" does not sound like a valid value per the Microsoft spec but this driver is apparently considering it as something like a multiplier although presumably not to the actual resolution. I see that we are checking that the DM_YRESOLUTION bit of the dmFields member is set : 1002 int xRes = devmode->dmPrintQuality; 1003 int yRes = (devmode->dmFields & DM_YRESOLUTION) ? 1004 devmode->dmYResolution : devmode->dmPrintQuality; 1005 1006 // For some printers, printer quality can specify 1200IQ 1007 // In this case, dmPrintQuality comes out 600 and 1008 // dmYResolution comes out 2 which is not a valid resolution 1009 // so for IQ setting, we specify yresolution same as xRes 1010 if (yRes < 10) yRes = xRes; .. so really they ought to return a DPI value as the spec says. I can't find anything that grants the apparent latitude being taken here. Note that your change here looks like it may break "quality" - where the pre-defined values are negative - as you will overwrite "-1" (for example) with 10. Actual breakage depends on whether we bother to read yRes in the case that xRes is negative but it still should not be over-written. At a minimum you need to fix the code to look like :- int yRes = (devmode->dmFields & DM_YRESOLUTION) && (devmode->dmYResolution < 10) ? devmode->dmYResolution : devmode->dmPrintQuality; But I find it a little unsatisfactory to have to make this kind of workaround and wonder what we are missing ... -phil. On 06/09/2016 04:35 AM, prasanta sadhukhan wrote: > > Hi All, > > Bug: https://bugs.openjdk.java.net/browse/JDK-6966350 > > The issue was if we select 1200IQ Normal (default) setting in Lexmark > E352dn PS3 or Dell 5310n printer, it does not print the output and we > get empty pages. > > It was because DEVMODE windows structure returns 600 for > "dmPrintQuality" and 2 for "dmYResolution". For 2400IQ, it returns 600 > dmPrintQuality and 4 as dmYResolution > so awt_printControl.cpp#AwtPrintControl::UpdateAttributes() calls > WPrinterJob#setResolutionDPI(xres=600, yres=2) and > RasterPrinterJob#print() gets 0.027 as yscale(=getYRes()/72 and yres = 2) > so devicetransform for normal 1200IQ dpi becomes [8.33, 0.0, > -108.0][0.0, 0.027, -108.0] so WPathGraphics#drawString() gets devPos > x= 725.33, *y = -105.22**. > *so nothing gets printed. > > I tried finding the significance of 1200IQ setting which just says it > enhances the images sent to the printer. > From > http://www.smallbusinesscomputing.com/testdrive/article.php/1585581/Lexmark-T420d-Printer-Review-Both-Sides-Now.htm > (although it's not the same printer) > says /"//To be fair, the LaserJet offers sharper resolution ? 1,200 by > 1,200 dpi, while the T420d is a 600 by 600 dpi printer with what > Lexmark calls "1,200 Image Quality" dot placement for photos" > > /I modified the code to set yres to xres value if yres is less than 10 > . Although it seems to be a workaround, it prints the output. > > webrev: http://cr.openjdk.java.net/~psadhukhan/6966350/webrev.00/ > > Regards > Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Tue Jun 14 22:44:40 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 14 Jun 2016 15:44:40 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-6386906 : Faulty rounding code in BMPImageReader.decodeRLE4() In-Reply-To: References: <0d4c6456-598b-4279-8899-1547743362ed@default> Message-ID: Hi Jay, That looks fine. There is an extra space before the end parenthesis, but that doesn't require a review cycle to fix... ...jim On 6/14/16 11:37 AM, Jayathirth D V wrote: > Hi Jim, > > Thanks for your review. I have updated the changes mentioned by you. > Please find the updated webrev for review: > http://cr.openjdk.java.net/~jdv/6386906/webrev.01/ > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Tuesday, June 14, 2016 12:34 AM > To: Jayathirth D V; 2d-dev at openjdk.java.net; Philip Race > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-6386906 : Faulty rounding code in BMPImageReader.decodeRLE4() > > Why use ceil() at all? If you want Math.ceil(intval/2.0f), use "((intval + 1) / 2)"... > > ...jim > > On 6/13/2016 7:00 AM, Jayathirth D V wrote: >> Hi, >> >> >> >> _Please review the following fix in JDK9:_ >> >> _ _ >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-6386906 >> >> >> >> Webrev : http://cr.openjdk.java.net/~jdv/6386906/webrev.00/ >> >> >> >> Issue : We are dividing an integer with another integer and trying to >> perform ceil() on resultant value which will be an integer. Resultant >> value will not have fractional part and ceil() operation is invalid. >> >> >> >> Solution : Update the code to divide the integer with floating point >> variable so that ceil() operation becomes valid. >> >> >> >> Thanks, >> >> Jay >> >> >> From james.graham at oracle.com Wed Jun 15 04:30:48 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 14 Jun 2016 21:30:48 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail In-Reply-To: <9c521f0e-1f76-420b-bf51-3495c5779b83@default> References: <89531a21-64b2-4e00-8f15-aa78650cf7b2@default> <574F62FA.50900@oracle.com> <1309b2bb-c189-d623-cfc5-105223718e12@oracle.com> <70565f43-7547-4047-bca3-f95ae709427e@default> <7b22a1ca-5e6a-c705-90bc-510aa2073c90@oracle.com> <1b962d5d-ae52-4281-8ca8-d6d5558e3fe5@default> <9c521f0e-1f76-420b-bf51-3495c5779b83@default> Message-ID: Hi Jay, Thanks for explaining all of the details. It seems that constantly being in scan mode simplifies things because we have to be in scan mode for entropy data anyway, but it still allows errant bytes outside of the entropy data to be accepted by this parser. I'm not sure if that is a problem in the long run, but it is not a new issue (since the existing code already was doing that) so we can live with it for purposes of fixing this particular bug. One simplification of what you say below, it appears that among all of those cases none of them really impact the fact that un-sized entropy encoded data only appears inside the SOS marker and the only markers found inside the entropy data itself are the RSTn markers. Ideally we could limit our scanning to just the data following the SOS marker and its sized header and only allow RSTn markers to appear inside that manual scan, reverting to a non-scanning mode when we reach another marker (DNL it looks like). But, that would be the subject of a different bug fix. It looks OK to me as long as Phil is OK with the types of exceptions that you are throwing in the various new exceptional cases, and with the change to now assume that skipImage always being called at an SOI marker. Phil? ...jim On 6/14/16 9:36 AM, Jayathirth D V wrote: > Hi Jim, > > I have updated the code to add check for EOF even in case of reading length. Also I have updated the code such that in all the cases where we find EOF before EOI we are throwing IndexOutOfBoundsException and in other failed cases we are throwing IOException. > > More analysis : > All the length markers that we are checking in our case have valid length data except SOS marker in which always the length value will be 12 and it is the value only for the length of Scan header. > After Scan header(SOS) we have compressed data for which we have no parameter which gives the length so that we can skip it completely. > Once we get to the initial SOS header it can take 3 paths based on how the data follows: > a) If we don't have Restart enabled and if we scan continuously through compressed data we will find EOI otherwise we will find RST markers and then EOI marker. > b) If we have multiple scan headers(Multi-scan scenario) we have to follow point 'a' in loop with each scan header separated by DNL and other miscellaneous tables. > c) If we have multiple frame headers(Multi-frame scenario) we have to follow point 'b' in loop with different markers coming in between. > Above information is taken from page 52 of https://www.w3.org/Graphics/JPEG/itu-t81.pdf > > Since we can't rely on length specified in SOS header and there is possibility of having multiple SOS headers, we need to search for FF(foundFF). It means even if we jump for the length specified is SOS header the next byte is not promised to be '0xff'. > For all the remaining markers we will get proper information related to the length and we will skip all data part(which might contain data similar to EOI/SOI/or any other marker). While propagating through the 'for' loop we are following the same approach. > > Please find updated webrev for review : > http://cr.openjdk.java.net/~jdv/8152672/webrev.02/ > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Tuesday, June 14, 2016 12:44 AM > To: Jayathirth D V > Cc: 2d-dev at openjdk.java.net; Philip Race > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail > > Hi Jay, > > You still don't check the read() calls in the length case to see if you reached EOF (-1). The potential for an infinite loop is still there. > > Also, you still search for an FF, even if you require the function to start at an SOI marker - all subsequent markers are still subject to a search rather than a deterministic requirement that we encounter markers with no gaps between them. > > Why do we have the foundFF variable in the first place? If we just saw an SOI marker then the next byte *must be* a 0xff (shouldn't it? Am I missing something?). We shouldn't read a byte and check if it is a 0xff and then try again, we should expect a single 0xff byte followed by a marker type byte, as in: > > while (true) { > int byteval == iis.read(); > // if (byteval < 0) then what? > if (byteval != 0xff) { exception } > byteval = iis.read(); > switch (byteval) { > } > } > > The only question is if we get a -1 on the first read if we treat that as an implicit EOI as we do now, or if we treat it as an exception. > Note that if we get a -1 in the second read, then we have a half-formed tag and that should fall into the default and be declared a bad file. > > ...jim > > On 6/13/2016 10:00 AM, Jayathirth D V wrote: >> Hi Jim, >> >> Thanks for your valuable inputs. >> I have updated the code with your inputs: >> 1) We should check for complete SOI marker and not just "FF" at start of skipImage(). >> 2) There is no need of iis.read() which was happening in default case. iis.read() present in for loop check will take care of checking EOF. >> 3) I have added case condition for all the markers having length and added default case where we get invalid marker starting with FF. >> >> Apart from above changes, after going more through https://www.w3.org/Graphics/JPEG/itu-t81.pdf got to know following things: >> >> 1) TEM is also one more marker without length so added case for that. >> 2) Since we have all unique conditions checked, we should not find any SOI marker after the initial SOI marker before we find EOI. Made changes to throw IOException in this case. >> >> Please find updated webrev for review: >> http://cr.openjdk.java.net/~jdv/8152672/webrev.01/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Saturday, June 11, 2016 3:07 AM >> To: Jayathirth D V; Philip Race >> Cc: 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : >> Exception while getting second image properties for JPEG with embedded >> thumbnail >> >> Thanks for the response Jay, I think I was misreading some of the code as now that I look back at it, it's mostly written as I was suggesting with respect to skipping over data sections, however it is still doing some scanning to find the initial 0xFF. Some thoughts: >> >> - If we can be sure that we are located at where a tag should be, then shouldn't we just read a byte and assert that it is 0xFF and report the file as invalid if it isn't? The current code will just ignore the byte and continue reading until it finds a 0xFF, but the fact that the first byte we read isn't 0xFF means we have wandered into data that isn't following the file format (or, possibly, that this was called from a case where we hadn't completely read a section of data, but that should be fixed as we could be in the middle of a section that isn't entropy encoded and our search for 0xFF might have invalid assumptions). >> >> - The bytes read in the default section to get the length and the tag for the next block aren't tested for EOF (-1). This may even get us into an infinite loop if we hit EOF at the right time (just after a sized block tag) as the size bytes will read and combine into a -1 size, back up three bytes, and then reread the same tag and try to compute a length again which will send us back 3 bytes, etc. >> >> - default assumes that all other markers that are created will be sized, but can we assert that? Shouldn't we specifically list all known sized markers and have the default case reject the file as not being of a format that we recognize? >> >> ...jim >> >> On 6/9/2016 11:21 PM, Jayathirth D V wrote: >>> Hi Jim, >>> >>> I think the harmless byte that you are referring to will be applied only for image data(Between SOS(Start of Scan) marker and EOI). For example, any "FF" data present in Jpeg image will be represented as "FF 00". But I think application headers or comments section can contain data which will be similar to EOI,SOI or other markers(FF XX). >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Jim Graham >>> Sent: Friday, June 10, 2016 5:28 AM >>> To: Jayathirth D V; Philip Race >>> Cc: 2d-dev at openjdk.java.net >>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : >>> Exception while getting second image properties for JPEG with >>> embedded thumbnail >>> >>> It looks like JPEG files have protection for scanning for an FF and assuming it is a marker by making sure that all FF bytes that appear in data are followed by a harmless byte, so a brute force search is probably fine. But it still seems wasteful when we know we are at a tag and we know the sizes of all of the tags, we should be able to skip around the file looking for the SOI directly... >>> >>> ...jim >>> >>> On 6/2/2016 5:10 AM, Jayathirth D V wrote: >>>> Fixed typo. >>>> >>>> >>>> >>>> *From:*Jayathirth D V >>>> *Sent:* Thursday, June 02, 2016 5:08 PM >>>> *To:* Philip Race >>>> *Cc:* Jim Graham; 2d-dev at openjdk.java.net >>>> *Subject:* RE: Review Request for JDK-8152672 : Exception while >>>> getting second image properties for JPEG with embedded thumbnail >>>> >>>> >>>> >>>> Hi Phil, >>>> >>>> >>>> >>>> We have two kind of images with which we are able to reproduce the issue: >>>> >>>> 1) sample.jpg present in JBS bug(We can't use this image because it >>>> is licensed ). >>>> >>>> 2) JpegEmbedThumbnail.jpg taken using Prasanta's camera and used in >>>> webrev. >>>> >>>> >>>> >>>> _ _ >>>> >>>> _sample.jpg : _ >>>> >>>> _ _ >>>> >>>> If we do getNumImages() it will return 2. getNumImages() follows the >>>> same logic of skipping markers with length and registering SOI to >>>> get number of images. >>>> >>>> sample.jpg has markers as follows : >>>> >>>> SOI -> APP1 - > SOI -> EOI -> APP1 End -> EOI -> SOI -> EOI >>>> >>>> >>>> >>>> I have dumped first image its SOI is first one in the above list and >>>> for second image it is third one in the list. getNumImages() counts >>>> first and third SOI for number of images. But in case of skipImage() >>>> we are getting inside APP1 marker and considering its SOI. >>>> >>>> >>>> >>>> _JpegEmbedThumbnail.jpg :_ >>>> >>>> _ _ >>>> >>>> If we do getNumImages() it will return 1. >>>> >>>> JpegEmbedThumbnail.jpg has markers as follows : >>>> >>>> SOI -> APP1 -> SOI -> EOI -> APP1 End -> APP2 -> SOI -> APP2 End -> >>>> APP2 >>>> -> EOI -> APP2 End -> EOI >>>> >>>> >>>> >>>> getNumImages() counts only first SOI for number of images. But in >>>> case of skipImage() we will are getting inside APP1 and APP2 markers also. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Jay >>>> >>>> *From:*Phil Race >>>> *Sent:* Thursday, June 02, 2016 4:05 AM >>>> *To:* Jayathirth D V >>>> *Cc:* Jim Graham; 2d-dev at openjdk.java.net >>>> >>>> *Subject:* Re: Review Request for JDK-8152672 : Exception while >>>> getting second image properties for JPEG with embedded thumbnail >>>> >>>> >>>> >>>> I am bit doubtful about this. Are you sure we are correct in >>>> reporting two images to begin with ? >>>> Thumbnails should not get counted .. >>>> >>>> >>>> -phil. >>>> >>>> On 06/01/2016 01:06 AM, Jayathirth D V wrote: >>>> >>>> Updated bug title in JBS as it was misleading. >>>> >>>> >>>> >>>> *From:* Jayathirth D V >>>> *Sent:* Wednesday, June 01, 2016 12:48 PM >>>> *To:* Philip Race; Jim Graham >>>> *Cc:* 2d-dev at openjdk.java.net >>>> *Subject:* Review Request for JDK-8152672 : Exception getting >>>> thumbnail size for JPEG with embedded thumbnail >>>> >>>> >>>> >>>> Hi, >>>> >>>> >>>> >>>> _Please review the following fix in JDK9:_ >>>> >>>> >>>> >>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8152672 >>>> >>>> >>>> >>>> Webrev : http://cr.openjdk.java.net/~jdv/8152672/webrev.00/ >>>> >>>> >>>> >>>> >>>> Issue : When we are trying to get properties related to second image >>>> in JPEG file we are getting IIOException mentioning that it is not a >>>> JPEG file. >>>> >>>> >>>> >>>> Root cause : When we are skipping first image to reach second image >>>> header, we are just trying to find next available EOI marker. But if >>>> first image has embedded thumbnail in APP1 marker, we will reach to >>>> EOI of this thumbnail and not EOI of first image. So after we reach >>>> EOI of embedded thumbnail we try to access second image SOI marker >>>> which will fail. >>>> >>>> >>>> >>>> Solution : We have to change the logic of how we skip to consecutive >>>> images in JPEG file. We know that application markers, comments or >>>> other markers can contain data same as SOI & EOI. Instead of just >>>> checking for EOI marker serially, we should read length of these >>>> markers and skip them. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Jay >>>> >>>> >>>> >>>> >>>> From prasanta.sadhukhan at oracle.com Wed Jun 15 05:09:17 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Wed, 15 Jun 2016 10:39:17 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6966350:Empty pages when printing on Lexmark E352dn PS3 with "1200 IQ" setting In-Reply-To: <57605238.3090707@oracle.com> References: <4a57f40d-9462-5236-7b2d-df69f97aa8e4@oracle.com> <57605238.3090707@oracle.com> Message-ID: <7e9a0d87-93fe-0ae8-e0e4-447610aa31e6@oracle.com> Hi Phil, On 6/15/2016 12:21 AM, Phil Race wrote: > This sound fishy. "2" does not sound like a valid value per the Microsoft spec > but this driver is apparently considering it as something like a multiplier although > presumably not to the actual resolution. > > I see that we are checking that the DM_YRESOLUTION bit of the dmFields member is set : > > 1002 int xRes = devmode->dmPrintQuality; > 1003 int yRes = (devmode->dmFields & DM_YRESOLUTION) ? > 1004 devmode->dmYResolution : devmode->dmPrintQuality; > 1005 > 1006 // For some printers, printer quality can specify 1200IQ > 1007 // In this case, dmPrintQuality comes out 600 and > 1008 // dmYResolution comes out 2 which is not a valid resolution > 1009 // so for IQ setting, we specify yresolution same as xRes > 1010 if (yRes < 10) yRes = xRes; > > .. so really they ought to return a DPI value as the spec says. I can't > find anything that grants the apparent latitude being taken here. > > Note that your change here looks like it may break "quality" - where > the pre-defined values are negative - as you will overwrite "-1" (for > example) with 10. > Actual breakage depends on whether we bother to read yRes in the case that > xRes is negative but it still should not be over-written. > If "quality" or dmPrintQuality is pre-defined negative value (like**DMRES_HIGH, DMRES_MEDIUM, DMRES_LOW, DMRES_DRAFT) then it will be handled in the "if" block and my modification is in "else" . > At a minimum you need to fix the code to look like :- > > int yRes = (devmode->dmFields & DM_YRESOLUTION) && (devmode->dmYResolution < 10) > ? devmode->dmYResolution : devmode->dmPrintQuality; I guess you mean devmode->dmYResolution > 10 Anyways, I have updated webrev to accomodate your comment. http://cr.openjdk.java.net/~psadhukhan/6966350/webrev.01/ > But I find it a little unsatisfactory to have to make this kind of > workaround and wonder what we are missing ... I could not find anything but this will help in getting printing to be working in those printers. If we find anything in near future, we will update this code . Regards Prasanta > -phil. > > On 06/09/2016 04:35 AM, prasanta sadhukhan wrote: >> >> Hi All, >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-6966350 >> >> The issue was if we select 1200IQ Normal (default) setting in Lexmark >> E352dn PS3 or Dell 5310n printer, it does not print the output and we >> get empty pages. >> >> It was because DEVMODE windows structure returns 600 for >> "dmPrintQuality" and 2 for "dmYResolution". For 2400IQ, it returns >> 600 dmPrintQuality and 4 as dmYResolution >> so awt_printControl.cpp#AwtPrintControl::UpdateAttributes() calls >> WPrinterJob#setResolutionDPI(xres=600, yres=2) and >> RasterPrinterJob#print() gets 0.027 as yscale(=getYRes()/72 and yres = 2) >> so devicetransform for normal 1200IQ dpi becomes [8.33, 0.0, >> -108.0][0.0, 0.027, -108.0] so WPathGraphics#drawString() gets devPos >> x= 725.33, *y = -105.22**. >> *so nothing gets printed. >> >> I tried finding the significance of 1200IQ setting which just says it >> enhances the images sent to the printer. >> From >> http://www.smallbusinesscomputing.com/testdrive/article.php/1585581/Lexmark-T420d-Printer-Review-Both-Sides-Now.htm >> (although it's not the same printer) >> says /"//To be fair, the LaserJet offers sharper resolution ? 1,200 >> by 1,200 dpi, while the T420d is a 600 by 600 dpi printer with what >> Lexmark calls "1,200 Image Quality" dot placement for photos" >> >> /I modified the code to set yres to xres value if yres is less than >> 10 . Although it seems to be a workaround, it prints the output. >> >> webrev: http://cr.openjdk.java.net/~psadhukhan/6966350/webrev.00/ >> >> Regards >> Prasanta > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Wed Jun 15 06:53:37 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 14 Jun 2016 23:53:37 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-6386906 : Faulty rounding code in BMPImageReader.decodeRLE4() In-Reply-To: References: <0d4c6456-598b-4279-8899-1547743362ed@default> Message-ID: Hi Jim, Thanks for the review. I have updated the webrev for reference: http://cr.openjdk.java.net/~jdv/6386906/webrev.02/ Thanks, Jay -----Original Message----- From: Jim Graham Sent: Wednesday, June 15, 2016 4:15 AM To: Jayathirth D V; 2d-dev at openjdk.java.net; Philip Race Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-6386906 : Faulty rounding code in BMPImageReader.decodeRLE4() Hi Jay, That looks fine. There is an extra space before the end parenthesis, but that doesn't require a review cycle to fix... ...jim On 6/14/16 11:37 AM, Jayathirth D V wrote: > Hi Jim, > > Thanks for your review. I have updated the changes mentioned by you. > Please find the updated webrev for review: > http://cr.openjdk.java.net/~jdv/6386906/webrev.01/ > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Tuesday, June 14, 2016 12:34 AM > To: Jayathirth D V; 2d-dev at openjdk.java.net; Philip Race > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-6386906 : Faulty > rounding code in BMPImageReader.decodeRLE4() > > Why use ceil() at all? If you want Math.ceil(intval/2.0f), use "((intval + 1) / 2)"... > > ...jim > > On 6/13/2016 7:00 AM, Jayathirth D V wrote: >> Hi, >> >> >> >> _Please review the following fix in JDK9:_ >> >> _ _ >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-6386906 >> >> >> >> Webrev : http://cr.openjdk.java.net/~jdv/6386906/webrev.00/ >> >> >> >> Issue : We are dividing an integer with another integer and trying to >> perform ceil() on resultant value which will be an integer. Resultant >> value will not have fractional part and ceil() operation is invalid. >> >> >> >> Solution : Update the code to divide the integer with floating point >> variable so that ceil() operation becomes valid. >> >> >> >> Thanks, >> >> Jay >> >> >> From prasanta.sadhukhan at oracle.com Wed Jun 15 07:56:57 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Wed, 15 Jun 2016 13:26:57 +0530 Subject: [OpenJDK 2D-Dev] Review Request for JDK-6386906 : Faulty rounding code in BMPImageReader.decodeRLE4() In-Reply-To: References: <0d4c6456-598b-4279-8899-1547743362ed@default> Message-ID: +1 Regards Prasanta On 6/15/2016 12:23 PM, Jayathirth D V wrote: > Hi Jim, > > Thanks for the review. I have updated the webrev for reference: > http://cr.openjdk.java.net/~jdv/6386906/webrev.02/ > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Wednesday, June 15, 2016 4:15 AM > To: Jayathirth D V; 2d-dev at openjdk.java.net; Philip Race > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-6386906 : Faulty rounding code in BMPImageReader.decodeRLE4() > > Hi Jay, > > That looks fine. There is an extra space before the end parenthesis, but that doesn't require a review cycle to fix... > > ...jim > > On 6/14/16 11:37 AM, Jayathirth D V wrote: >> Hi Jim, >> >> Thanks for your review. I have updated the changes mentioned by you. >> Please find the updated webrev for review: >> http://cr.openjdk.java.net/~jdv/6386906/webrev.01/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Tuesday, June 14, 2016 12:34 AM >> To: Jayathirth D V; 2d-dev at openjdk.java.net; Philip Race >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-6386906 : Faulty >> rounding code in BMPImageReader.decodeRLE4() >> >> Why use ceil() at all? If you want Math.ceil(intval/2.0f), use "((intval + 1) / 2)"... >> >> ...jim >> >> On 6/13/2016 7:00 AM, Jayathirth D V wrote: >>> Hi, >>> >>> >>> >>> _Please review the following fix in JDK9:_ >>> >>> _ _ >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-6386906 >>> >>> >>> >>> Webrev : http://cr.openjdk.java.net/~jdv/6386906/webrev.00/ >>> >>> >>> >>> Issue : We are dividing an integer with another integer and trying to >>> perform ceil() on resultant value which will be an integer. Resultant >>> value will not have fractional part and ceil() operation is invalid. >>> >>> >>> >>> Solution : Update the code to divide the integer with floating point >>> variable so that ceil() operation becomes valid. >>> >>> >>> >>> Thanks, >>> >>> Jay >>> >>> >>> From prasanta.sadhukhan at oracle.com Wed Jun 15 10:25:10 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Wed, 15 Jun 2016 15:55:10 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6218397:Printing to file does not throw a PrinterException if the file cannot be created Message-ID: Hi All, Bug: https://bugs.openjdk.java.net/browse/JDK-6218397 The issue was if the linux disk is full and we are trying to "print to file" then PrinterException is not thrown and a 0 byte file is created. Although I am not able to reproduce this behaviour, because when I make my disk full and try to run "java", I get /Java HotSpot(TM) Server VM warning: Insufficient space for shared memory file:// // 13783// //Try using the -Djava.io.tmpdir= option to select an alternate temp location./ but on investigating this, I see that we are calling f.createNewFile() in RasterPrinterJob#validateDestination() which creates a new, empty file but if there is any exception in PSPrinterJob#startDoc this file is not deleted. Modified the code to make sure if there is any exception, delete the file. http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.00/ Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Jun 15 16:22:44 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 15 Jun 2016 09:22:44 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6218397:Printing to file does not throw a PrinterException if the file cannot be created In-Reply-To: References: Message-ID: <576180D4.9040502@oracle.com> If this is executed on Windows (shared Postscript stream printer could do this) then since the output stream is still open I expect the delete will fail. Attempt to close the open stream first (in a try .. catch I suppose). -phil. On 6/15/16, 3:25 AM, prasanta sadhukhan wrote: > > Hi All, > > Bug: https://bugs.openjdk.java.net/browse/JDK-6218397 > > The issue was if the linux disk is full and we are trying to "print to > file" then PrinterException is not thrown and a 0 byte file is created. > > Although I am not able to reproduce this behaviour, because when I > make my disk full and try to run "java", I get > > /Java HotSpot(TM) Server VM warning: Insufficient space for shared > memory file:// > // 13783// > //Try using the -Djava.io.tmpdir= option to select an alternate temp > location./ > > but on investigating this, I see that we are calling f.createNewFile() > in RasterPrinterJob#validateDestination() which creates a new, empty file > > but if there is any exception in PSPrinterJob#startDoc this file is > not deleted. > > Modified the code to make sure if there is any exception, delete the file. > > http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.00/ > > Regards > Prasanta > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prahalad.kumar.narayanan at oracle.com Wed Jun 15 17:17:04 2016 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Wed, 15 Jun 2016 10:17:04 -0700 (PDT) Subject: [OpenJDK 2D-Dev] (Review request) JDK-8152971: -Xcheck:jni warning Message-ID: Hello Everyone on Java2D group Good day to you. Please find herewith, webrev with changes to fix the following issue: Bug ID / Title : JDK-8152971 -Xcheck:jni - WARNING in native method Bug Link : https://bugs.openjdk.java.net/browse/JDK-8152971 Description on Bug : . Submitter has provided a test code with the bug. . When the test code is run (with -Xcheck:jni in JVM options), JNI warnings are thrown. . The warnings mention that JNI functions invoke Java methods without checking for exceptions. Description on Changes : . The bug did not appear in Jdk 8 b132 or earlier but is reproducible with 8u91 and 9 versions. I believe, strict check for conformance has been added recently in JVM that has caused this issue. . In the proposed fix, I 've added JNIEnv->ExceptionCheck and ExceptionClear functions at required places. Webrev Link: http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.00/ Kindly review the changes at your available time and provide your feedback. Thanks for your time in review Have a good day Prahalad N From philip.race at oracle.com Wed Jun 15 18:01:02 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 15 Jun 2016 11:01:02 -0700 Subject: [OpenJDK 2D-Dev] RFR 8159093: Fix coding conventions in Marlin renderer In-Reply-To: References: <1970cc79-31ce-7231-2681-d49ce283323e@oracle.com> <92b7df47-380e-3247-3ccd-e3b9fda9a43f@oracle.com> Message-ID: <576197DE.5010203@oracle.com> +1 -phil. On 06/13/2016 04:31 AM, Laurent Bourg?s wrote: > > Jim, > > This MT issue concerns only statistics collection so I deliberately > did not ensure thread safety to avoid a synchronized block as the code > is still "safe". > > Anyway I can fix it in the next patch that will improve array cache > and stats per rendering context. > > Laurent > > Le 11 juin 2016 01:59, "Jim Graham" > a ?crit : > > > > The getInstance MT issue could be filed as a separate follow-on bug > if you want, in which case webrev.1 is good to go... > > > > ...jim > > > > > > On 6/10/2016 2:54 PM, Jim Graham wrote: > >> > >> Thanks Laurent, > >> > >> Eeek, I hate the type[] syntax for declaring arrays, but I guess I have > >> to grow with the times. > >> > >> One last thing I just noticed, RendererState.getInstance doesn't > protect > >> against MT access if multiple threads encounter the null instance case > >> and all decide to make their own... > >> > >> ...jim > >> > >> On 6/10/2016 4:59 AM, Laurent Bourg?s wrote: > >>> > >>> Jim, > >>> > >>> I fixed the issues you mentioned, see below. > >>> > >>> Here is the new webrev: > >>> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8159093.1/ > > >>> > >>> I also fixed the bracket position (int val[] => int[] val) in Helpers, > >>> MarlinRenderingEngine, MarlinTileGenerator classes. > >>> > >>> My comments: > >>> > >>> 2016-06-10 1:48 GMT+02:00 Jim Graham > >>> >>: > >>> > >>> > >>> In RendererStats, lines 276,277 - is it better to convert to an > >>> array (which is an inherently risky situation for a concurrent > >>> collection due to the potential for the size changing between the > >>> array allocation and the toArray), or to iterate the concurrent > >>> collection directly? I realize that the toArray() method protects > >>> against a short array, but is it any better than just directly > >>> iterating which would deal with the concurrency automatically > anyway > >>> without having to allocate an array. One thing to note, if you > >>> convert to an array and there is a concurrency issue then the > array > >>> may have a null entry to indicate "this is the end of the > list", but > >>> you don't look for that null entry. A simple "if rdrCtx==null > >>> break;" statement would be enough to deal with that case. > >>> > >>> > >>> I agree and adopted the simplest solution: iterate directly on the > >>> concurrent queue. > >>> > >>> > >>> MarlinConst.java - you added DO_FLUSH_STATS, but I don't see it > >>> getting used anywhere...? > >>> > >>> > >>> Exact; I removed it as it will be only used in the next patch. > >>> > >>> > >>> MarlinRenderingEngine.java - it looks like you eliminated all uses > >>> of mon_npi_currentSegment, but it is still created in > >>> RendererStats...? > >>> > >>> > >>> mon_npi_currentSegment removed in RendererStats. > >>> > >>> > >>> Histogram.java - 2016 copyright > >>> > >>> > >>> Fixed. > >>> > >>> Regards, > >>> Laurent > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bourges.laurent at gmail.com Wed Jun 15 21:10:06 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 15 Jun 2016 23:10:06 +0200 Subject: [OpenJDK 2D-Dev] RFR 8159638: Improve array caches and renderer stats in Marlin renderer Message-ID: Hi, Please review this bug fix for the Marlin renderer to improve the array caches, its usages but also the renderer stats: bug: https://bugs.openjdk.java.net/browse/JDK-8159638 webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8159638.0/ This patch also reduces slightly the memory footprint: 1 RendererContext represents now ~ 450K (310K on-heap / 140K off-heap). Changes: - Byte/Int/Float ArrayCache removed - replaced by Clean[Byte/Int/Float]ArrayCache (zero-filled arrays) and Dirty[Byte/Int/Float]ArrayCache classes (dirty arrays). These new classes provides a Reference class that wraps the initial array and acts as a proxy to the related array cache instance (get/widen//put Array) - ArrayCache: increased bucket to 8 (larger retained memory but weakly referenced) + added CacheStats (and BucketStats) - MarlinProperties: added setiings for initial edge capacity and align array sizes to 64 (power of 2) - RendererContext: large cleanup + use a weak reference for the recycled Path2D instance - RendererStats: big refactoring to create one RendererStats instance per created RendererContext instance (thread stats) and the new RendererStatsHolder class gathers all RendererStats instances to dump them at shutdown (very small retained memory instead of keeping all RendererContext instances) Tested with current jtreg tests (+ my MapBench tests) Regards, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Jun 15 23:34:34 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 15 Jun 2016 16:34:34 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6966350:Empty pages when printing on Lexmark E352dn PS3 with "1200 IQ" setting In-Reply-To: <7e9a0d87-93fe-0ae8-e0e4-447610aa31e6@oracle.com> References: <4a57f40d-9462-5236-7b2d-df69f97aa8e4@oracle.com> <57605238.3090707@oracle.com> <7e9a0d87-93fe-0ae8-e0e4-447610aa31e6@oracle.com> Message-ID: <5761E60A.5080308@oracle.com> On 6/14/16, 10:09 PM, prasanta sadhukhan wrote: > > Hi Phil, > > > On 6/15/2016 12:21 AM, Phil Race wrote: >> This sound fishy. "2" does not sound like a valid value per the Microsoft spec >> but this driver is apparently considering it as something like a multiplier although >> presumably not to the actual resolution. >> >> I see that we are checking that the DM_YRESOLUTION bit of the dmFields member is set : >> >> 1002 int xRes = devmode->dmPrintQuality; >> 1003 int yRes = (devmode->dmFields& DM_YRESOLUTION) ? >> 1004 devmode->dmYResolution : devmode->dmPrintQuality; >> 1005 >> 1006 // For some printers, printer quality can specify 1200IQ >> 1007 // In this case, dmPrintQuality comes out 600 and >> 1008 // dmYResolution comes out 2 which is not a valid resolution >> 1009 // so for IQ setting, we specify yresolution same as xRes >> 1010 if (yRes< 10) yRes = xRes; >> >> .. so really they ought to return a DPI value as the spec says. I can't >> find anything that grants the apparent latitude being taken here. >> >> Note that your change here looks like it may break "quality" - where >> the pre-defined values are negative - as you will overwrite "-1" (for >> example) with 10. >> Actual breakage depends on whether we bother to read yRes in the case >> that >> xRes is negative but it still should not be over-written. >> > If "quality" or dmPrintQuality is pre-defined negative value > (like**DMRES_HIGH, DMRES_MEDIUM, DMRES_LOW, DMRES_DRAFT) > then it will be handled in the "if" block > and my modification is in "else" . Not following that but in any case ... >> At a minimum you need to fix the code to look like :- >> >> int yRes = (devmode->dmFields& DM_YRESOLUTION)&& (devmode->dmYResolution< 10) >> ? devmode->dmYResolution : devmode->dmPrintQuality; > I guess you mean > devmode->dmYResolution> 10 .. yes > > Anyways, I have updated webrev to accomodate your comment. > http://cr.openjdk.java.net/~psadhukhan/6966350/webrev.01/ approved since we have a comment explaining the "logic" but still puzzled. -phil. >> >> But I find it a little unsatisfactory to have to make this kind of workaround >> and wonder what we are missing ... > I could not find anything but this will help in getting printing to be > working in those printers. If we find anything in near future, we will > update this code . > > Regards > Prasanta >> >> -phil. >> >> On 06/09/2016 04:35 AM, prasanta sadhukhan wrote: >>> >>> Hi All, >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-6966350 >>> >>> The issue was if we select 1200IQ Normal (default) setting in >>> Lexmark E352dn PS3 or Dell 5310n printer, it does not print the >>> output and we get empty pages. >>> >>> It was because DEVMODE windows structure returns 600 for >>> "dmPrintQuality" and 2 for "dmYResolution". For 2400IQ, it returns >>> 600 dmPrintQuality and 4 as dmYResolution >>> so awt_printControl.cpp#AwtPrintControl::UpdateAttributes() calls >>> WPrinterJob#setResolutionDPI(xres=600, yres=2) and >>> RasterPrinterJob#print() gets 0.027 as yscale(=getYRes()/72 and yres >>> = 2) >>> so devicetransform for normal 1200IQ dpi becomes [8.33, 0.0, >>> -108.0][0.0, 0.027, -108.0] so WPathGraphics#drawString() gets >>> devPos x= 725.33, *y = -105.22**. >>> *so nothing gets printed. >>> >>> I tried finding the significance of 1200IQ setting which just says >>> it enhances the images sent to the printer. >>> From >>> http://www.smallbusinesscomputing.com/testdrive/article.php/1585581/Lexmark-T420d-Printer-Review-Both-Sides-Now.htm >>> (although it's not the same printer) >>> says /"//To be fair, the LaserJet offers sharper resolution ? 1,200 >>> by 1,200 dpi, while the T420d is a 600 by 600 dpi printer with what >>> Lexmark calls "1,200 Image Quality" dot placement for photos" >>> >>> /I modified the code to set yres to xres value if yres is less than >>> 10 . Although it seems to be a workaround, it prints the output. >>> >>> webrev: http://cr.openjdk.java.net/~psadhukhan/6966350/webrev.00/ >>> >>> Regards >>> Prasanta >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Jun 15 23:41:29 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 15 Jun 2016 16:41:29 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6601097:Margins are not reset to hardware margins when width/height is 0 or -ve alongwith x, y In-Reply-To: <0703d17a-9e36-94a2-93f8-80c56d0250f3@oracle.com> References: <5745D4BB.5040900@oracle.com> <574DBF01.5080101@oracle.com> <0703d17a-9e36-94a2-93f8-80c56d0250f3@oracle.com> Message-ID: <5761E7A9.1010805@oracle.com> I did say so long as the "ix/iy" are also valid. Which means not just positive but that they are not too large. Consider if (iw<= 0) iw = (float)(page.getPaper().getWidth()/DPI) - (ix*2); if we have ix = 500 and iw = -20 for a paper with width 800 this will result in iw = 800 - (500*2) = -200 .. -phil. On 6/8/16, 4:42 AM, prasanta sadhukhan wrote: > Hi Phil, > > As discussed offline, regarding mpa modification in both > setAttributes() and updateAttributesWithPageFormat, I found that > updateAttributesWithPageFormat() will be called during pageDialog() > and setPrintable() > whereas setAttributes() will be called during print() and > setAttributes() called validatePaper() to validate imageable values, > so in that regard, setAttributes() has final say in validating and > updating invalid mpa values. > > Regarding bug, I found that if we have -ve width/height, > MediaPrintable constructor throws IAE if width/height is -ve so mpa > values set by user will not be added to pageAttributes (even if there > was valid x,y mpa values) > therefore we fallback to Java default paper size and so we will get > mpa values as ix=72 iy=72 iw=451 ih=697 in validatePaper() > so to avoid IAE and to use user-set valid values, I have modified the > code to constrain iw/ih with requested ix/iy as you suggested. > > Please find the modified webrev: > http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.02/ > > Regards > Prasanta > On 5/31/2016 10:12 PM, Phil Race wrote: >> Well ... few printers can print on the entire paper. Photo printers are >> the ones that can do this. So Paper dimension minus the "hardware >> margins" >> are the maximum imageable width. >> And then supposing imageable x/y is some perfectly reasonable value >> like 1" each >> then you've set iw/ih such that even a printer with zero hardware >> margins has >> an imageable area that goes off the bottom and right off the paper. >> >> More reasonable would be to constrain iw/ih such that they work with the >> requested ix/iy - assuming they are also valid. >> >> If all else fails then just using the "default" set of values as if >> the application >> had not set any values would be better. >> >> -phil. >> >> On 05/26/2016 03:26 AM, prasanta sadhukhan wrote: >>> Hi Phil, >>> >>> I got it rectified. >>> >>> Please find the modified webrev >>> >>> http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.01/ >>> >>> Regarding using entire width/height pf paper, I thought since >>> imageable width/height is invalid we should make the entire paper as >>> the imageable area.For invalid x,y we were making it to paper's >>> top/left. >>> Else what option do we have, should we calculate >>> width[height]=abs(image[width][height]) instead? >>> >>> Regards >>> Prasanta >>> On 5/25/2016 10:07 PM, Philip Race wrote: >>>> It seems to me that you are using the wrong units. >>>> You have not divided by DPI to get inches. >>>> >>>> Also I am not sure that the *entire* width/height of the paper is >>>> what you want here >>>> but that is secondary to the first issue >>>> >>>> -phil >>>> >>>> On 5/19/16, 2:59 AM, prasanta sadhukhan wrote: >>>>> Hi All, >>>>> >>>>> Please review a fix for jdk9 which is a continuation of the fix of >>>>> JDK-6543815. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6601097 >>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.00/ >>>>> >>>>> 6543815 fix resets the x,y to 0 if they are negative before >>>>> creating a MediaPrintableArea and the platform replaces it with >>>>> hardware margins when printing. >>>>> This works only if x/y is negative. >>>>> But, If either width/height is negative alongwith x or y, then the >>>>> margin is set to the java def 1 inch margin and not hardware margins. >>>>> >>>>> This is because width/height -ve results in IAE in >>>>> MediaPrintableArea constructor and so values are ignored. >>>>> Added a check for -ve width/height to make sure width/height are >>>>> set to minimum paper width/height. >>>>> >>>>> Regards >>>>> Prasanta >>>>> >>>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Thu Jun 16 06:55:54 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Thu, 16 Jun 2016 12:25:54 +0530 Subject: [OpenJDK 2D-Dev] (Review request) JDK-8152971: -Xcheck:jni warning In-Reply-To: References: Message-ID: <99726247-e65b-eaef-9811-155cd3e841f9@oracle.com> Please mention for which jdk release you are asking this review for like [9] for jdk9 !! awt_Component.cpp: Should we continue if there is any exception? You are just clearing the exception here, should we also not return as the "obj" values are going to be used later on which again will show up other problems!! fontpath.c. 177, 286 this return 1 is not needed I guess you need to also put noreg-sqe or so in JBS label as it does not have testcase and you are using existing JNICheck script. Regards Prasanta On 6/15/2016 10:47 PM, Prahalad Kumar Narayanan wrote: > Hello Everyone on Java2D group > > Good day to you. > > Please find herewith, webrev with changes to fix the following issue: > Bug ID / Title : JDK-8152971 -Xcheck:jni - WARNING in native method > Bug Link : https://bugs.openjdk.java.net/browse/JDK-8152971 > > Description on Bug : > . Submitter has provided a test code with the bug. > . When the test code is run (with -Xcheck:jni in JVM options), JNI warnings are thrown. > . The warnings mention that JNI functions invoke Java methods without checking for exceptions. > > Description on Changes : > . The bug did not appear in Jdk 8 b132 or earlier but is reproducible with 8u91 and 9 versions. > I believe, strict check for conformance has been added recently in JVM that has caused this issue. > . In the proposed fix, I 've added JNIEnv->ExceptionCheck and ExceptionClear functions at required places. > > Webrev Link: > http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.00/ > > Kindly review the changes at your available time and provide your feedback. > > Thanks for your time in review > Have a good day > > Prahalad N > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Thu Jun 16 08:10:11 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Thu, 16 Jun 2016 13:40:11 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6218397:Printing to file does not throw a PrinterException if the file cannot be created In-Reply-To: <576180D4.9040502@oracle.com> References: <576180D4.9040502@oracle.com> Message-ID: <1209f6f2-36df-6655-c542-d3836b11ff71@oracle.com> Modified webrev to close output stream. http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.01/ Regards Prasanta On 6/15/2016 9:52 PM, Philip Race wrote: > If this is executed on Windows (shared Postscript stream printer could > do this) > then since the output stream is still open I expect the delete will fail. > Attempt to close the open stream first (in a try .. catch I suppose). > > -phil. > > On 6/15/16, 3:25 AM, prasanta sadhukhan wrote: >> >> Hi All, >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-6218397 >> >> The issue was if the linux disk is full and we are trying to "print >> to file" then PrinterException is not thrown and a 0 byte file is >> created. >> >> Although I am not able to reproduce this behaviour, because when I >> make my disk full and try to run "java", I get >> >> /Java HotSpot(TM) Server VM warning: Insufficient space for shared >> memory file:// >> // 13783// >> //Try using the -Djava.io.tmpdir= option to select an alternate temp >> location./ >> >> but on investigating this, I see that we are calling >> f.createNewFile() in RasterPrinterJob#validateDestination() which >> creates a new, empty file >> >> but if there is any exception in PSPrinterJob#startDoc this file is >> not deleted. >> >> Modified the code to make sure if there is any exception, delete the >> file. >> >> http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.00/ >> >> Regards >> Prasanta >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Fri Jun 17 06:32:30 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Fri, 17 Jun 2016 12:02:30 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6601097:Margins are not reset to hardware margins when width/height is 0 or -ve alongwith x, y In-Reply-To: <5761E7A9.1010805@oracle.com> References: <5745D4BB.5040900@oracle.com> <574DBF01.5080101@oracle.com> <0703d17a-9e36-94a2-93f8-80c56d0250f3@oracle.com> <5761E7A9.1010805@oracle.com> Message-ID: <48d2a342-851a-0a79-1443-c7bf82958f7b@oracle.com> Hi Phil, Ok. I have added a check for this case in which it will fall back to default values since if ix/iy is too large then we probably will not get anything to print inside printable area if we have to leave same margin on the right/bottom of the paper. validatePaper() does not check for ix/iy too large case. Modified webrev http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.03/ Regards Prasanta On 6/16/2016 5:11 AM, Philip Race wrote: > I did say so long as the "ix/iy" are also valid. Which means not just > positive but that they > are not too large. Consider > if (iw <= 0) iw = (float)(page.getPaper().getWidth()/DPI) - (ix*2); > > if we have ix = 500 and iw = -20 for a paper with width 800 this will > result > in iw = 800 - (500*2) = -200 .. > > -phil. > > On 6/8/16, 4:42 AM, prasanta sadhukhan wrote: >> Hi Phil, >> >> As discussed offline, regarding mpa modification in both >> setAttributes() and updateAttributesWithPageFormat, I found that >> updateAttributesWithPageFormat() will be called during pageDialog() >> and setPrintable() >> whereas setAttributes() will be called during print() and >> setAttributes() called validatePaper() to validate imageable values, >> so in that regard, setAttributes() has final say in validating and >> updating invalid mpa values. >> >> Regarding bug, I found that if we have -ve width/height, >> MediaPrintable constructor throws IAE if width/height is -ve so mpa >> values set by user will not be added to pageAttributes (even if there >> was valid x,y mpa values) >> therefore we fallback to Java default paper size and so we will get >> mpa values as ix=72 iy=72 iw=451 ih=697 in validatePaper() >> so to avoid IAE and to use user-set valid values, I have modified the >> code to constrain iw/ih with requested ix/iy as you suggested. >> >> Please find the modified webrev: >> http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.02/ >> >> Regards >> Prasanta >> On 5/31/2016 10:12 PM, Phil Race wrote: >>> Well ... few printers can print on the entire paper. Photo printers are >>> the ones that can do this. So Paper dimension minus the "hardware >>> margins" >>> are the maximum imageable width. >>> And then supposing imageable x/y is some perfectly reasonable value >>> like 1" each >>> then you've set iw/ih such that even a printer with zero hardware >>> margins has >>> an imageable area that goes off the bottom and right off the paper. >>> >>> More reasonable would be to constrain iw/ih such that they work with >>> the >>> requested ix/iy - assuming they are also valid. >>> >>> If all else fails then just using the "default" set of values as if >>> the application >>> had not set any values would be better. >>> >>> -phil. >>> >>> On 05/26/2016 03:26 AM, prasanta sadhukhan wrote: >>>> Hi Phil, >>>> >>>> I got it rectified. >>>> >>>> Please find the modified webrev >>>> >>>> http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.01/ >>>> >>>> Regarding using entire width/height pf paper, I thought since >>>> imageable width/height is invalid we should make the entire paper >>>> as the imageable area.For invalid x,y we were making it to paper's >>>> top/left. >>>> Else what option do we have, should we calculate >>>> width[height]=abs(image[width][height]) instead? >>>> >>>> Regards >>>> Prasanta >>>> On 5/25/2016 10:07 PM, Philip Race wrote: >>>>> It seems to me that you are using the wrong units. >>>>> You have not divided by DPI to get inches. >>>>> >>>>> Also I am not sure that the *entire* width/height of the paper is >>>>> what you want here >>>>> but that is secondary to the first issue >>>>> >>>>> -phil >>>>> >>>>> On 5/19/16, 2:59 AM, prasanta sadhukhan wrote: >>>>>> Hi All, >>>>>> >>>>>> Please review a fix for jdk9 which is a continuation of the fix >>>>>> of JDK-6543815. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6601097 >>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.00/ >>>>>> >>>>>> 6543815 fix resets the x,y to 0 if they are negative before >>>>>> creating a MediaPrintableArea and the platform replaces it with >>>>>> hardware margins when printing. >>>>>> This works only if x/y is negative. >>>>>> But, If either width/height is negative alongwith x or y, then >>>>>> the margin is set to the java def 1 inch margin and not hardware >>>>>> margins. >>>>>> >>>>>> This is because width/height -ve results in IAE in >>>>>> MediaPrintableArea constructor and so values are ignored. >>>>>> Added a check for -ve width/height to make sure width/height are >>>>>> set to minimum paper width/height. >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> >>>>>> >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Fri Jun 17 09:14:47 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Fri, 17 Jun 2016 02:14:47 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6966350:Empty pages when printing on Lexmark E352dn PS3 with "1200 IQ" setting In-Reply-To: <5761E60A.5080308@oracle.com> References: <4a57f40d-9462-5236-7b2d-df69f97aa8e4@oracle.com> <57605238.3090707@oracle.com> <7e9a0d87-93fe-0ae8-e0e4-447610aa31e6@oracle.com> <5761E60A.5080308@oracle.com> Message-ID: <6a79c5c4-d21d-470d-9bf4-0ece3e3b920d@default> Hi Prasanta, ? I tried to run the test but it looks like you are not creating object for proper class in test case : 88???????? pj.setPrintable(new PrintableDemo(), pf); ? ? I think it should be test class name : 88???????? pj.setPrintable(new PrintTestLexmarkIQ(), pf); ? After we change it to test class name it is working fine. ? In the description of test JTextArea, I found Print quality setting under Properties -> Advanced -> Graphic -> Print Quality. Please verify the same. Also please increase timeout for test case as I was looking for Print Quality setting and it came out. In test case jtreg multiline comment are not indented properly. ? Regarding code change, if we can be sure that in future image quality setting will not increase more than 6000IQ then changes are fine. Also in comments related to code change we can make it multiline comment instead of multiple single line comments. ? Thanks, Jay ? ? From: Philip Race Sent: Thursday, June 16, 2016 5:05 AM To: prasanta sadhukhan Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9] RFR: JDK-6966350:Empty pages when printing on Lexmark E352dn PS3 with "1200 IQ" setting ? On 6/14/16, 10:09 PM, prasanta sadhukhan wrote: Hi Phil, ? On 6/15/2016 12:21 AM, Phil Race wrote: This sound fishy. "2" does not sound like a valid value per the Microsoft spec but this driver is apparently considering it as something like a multiplier although presumably not to the actual resolution. ? I see that we are checking that the DM_YRESOLUTION bit of the dmFields member is set : ? 1002???????????? ????int xRes = devmode->dmPrintQuality; 1003???????????????? int yRes = (devmode->dmFields & DM_YRESOLUTION) ? 1004?????????????????? devmode->dmYResolution : devmode->dmPrintQuality; 1005???????????????? 1006???????????????? // For some printers, printer quality can specify 1200IQ 1007???????????????? // In this case, dmPrintQuality comes out 600 and 1008???????????????? // dmYResolution comes out 2 which is not a valid resolution 1009???????????????? // so for IQ setting, we specify yresolution same as xRes 1010???????????????? if (yRes < 10) yRes = xRes; .. so really they ought to return a DPI value as the spec says. I can't find anything that grants the apparent latitude being taken here. Note that your change here looks like it may break "quality" - where the pre-defined values are negative - as you will overwrite "-1" (for example) with 10. Actual breakage depends on whether we bother to read yRes in the case that xRes is negative but it still should not be over-written. If "quality" or dmPrintQuality is pre-defined negative value (like DMRES_HIGH, DMRES_MEDIUM, DMRES_LOW, DMRES_DRAFT) then it will be handled in the "if" block and my modification is in "else" . Not following that but in any case ... At a minimum you need to fix the code to look like :- int yRes = (devmode->dmFields & DM_YRESOLUTION) && (devmode->dmYResolution < 10) ??????????????? ? devmode->dmYResolution : devmode->dmPrintQuality; I guess you mean devmode->dmYResolution > 10 .. yes ? ? Anyways, I have updated webrev to accomodate your comment. HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/6966350/webrev.01/"http://cr.openjdk.java.net/~psadhukhan/6966350/webrev.01/ approved since we have a comment explaining the "logic" but still puzzled. -phil. ? ? But I find it a little unsatisfactory to have to make this kind of workaround and wonder what we are missing ... I could not find anything but this will help in getting printing to be working in those printers. If we find anything in near future, we will update this code . Regards Prasanta ? -phil. On 06/09/2016 04:35 AM, prasanta sadhukhan wrote: Hi All, Bug: https://bugs.openjdk.java.net/browse/JDK-6966350 The issue was if we select 1200IQ Normal (default) setting in Lexmark E352dn PS3 or Dell 5310n printer, it does not print the output and we get empty pages. It was because DEVMODE windows structure returns 600 for "dmPrintQuality" and 2 for "dmYResolution". For 2400IQ, it returns 600 dmPrintQuality and 4 as dmYResolution so awt_printControl.cpp#AwtPrintControl::UpdateAttributes() calls WPrinterJob#setResolutionDPI(xres=600, yres=2) and RasterPrinterJob#print() gets 0.027 as yscale(=getYRes()/72 and yres = 2) so devicetransform for normal 1200IQ dpi becomes [8.33, 0.0, -108.0][0.0, 0.027, -108.0] so WPathGraphics#drawString() gets devPos x= 725.33, y = -105.22. so nothing gets printed. I tried finding the significance of 1200IQ setting which just says it enhances the images sent to the printer. >From http://www.smallbusinesscomputing.com/testdrive/article.php/1585581/Lexmark-T420d-Printer-Review-Both-Sides-Now.htm (although it's not the same printer) says "To be fair, the LaserJet offers sharper resolution ? 1,200 by 1,200 dpi, while the T420d is a 600 by 600 dpi printer with what Lexmark calls "1,200 Image Quality" dot placement for photos" I modified the code to set yres to xres value if yres is less than 10 . Although it seems to be a workaround, it prints the output. webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/6966350/webrev.00/"http://cr.openjdk.java.net/~psadhukhan/6966350/webrev.00/ Regards Prasanta ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Fri Jun 17 09:17:29 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Fri, 17 Jun 2016 02:17:29 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6966350:Empty pages when printing on Lexmark E352dn PS3 with "1200 IQ" setting In-Reply-To: <6a79c5c4-d21d-470d-9bf4-0ece3e3b920d@default> References: <4a57f40d-9462-5236-7b2d-df69f97aa8e4@oracle.com> <57605238.3090707@oracle.com> <7e9a0d87-93fe-0ae8-e0e4-447610aa31e6@oracle.com> <5761E60A.5080308@oracle.com> <6a79c5c4-d21d-470d-9bf4-0ece3e3b920d@default> Message-ID: <1fa919d4-0edd-4532-8e94-8e8705ec5e02@default> Hi Prasanta, ? One more thing I missed, there are many unneeded imports in test case. Please remove them also. ? Thanks, Jay ? From: Jayathirth D V Sent: Friday, June 17, 2016 2:45 PM To: Prasanta Sadhukhan Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9] RFR: JDK-6966350:Empty pages when printing on Lexmark E352dn PS3 with "1200 IQ" setting ? Hi Prasanta, ? I tried to run the test but it looks like you are not creating object for proper class in test case : 88???????? pj.setPrintable(new PrintableDemo(), pf); ? ? I think it should be test class name : 88???????? pj.setPrintable(new PrintTestLexmarkIQ(), pf); ? After we change it to test class name it is working fine. ? In the description of test JTextArea, I found Print quality setting under Properties -> Advanced -> Graphic -> Print Quality. Please verify the same. Also please increase timeout for test case as I was looking for Print Quality setting and it came out. In test case jtreg multiline comment are not indented properly. ? Regarding code change, if we can be sure that in future image quality setting will not increase more than 6000IQ then changes are fine. Also in comments related to code change we can make it multiline comment instead of multiple single line comments. ? Thanks, Jay ? ? From: Philip Race Sent: Thursday, June 16, 2016 5:05 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-6966350:Empty pages when printing on Lexmark E352dn PS3 with "1200 IQ" setting ? On 6/14/16, 10:09 PM, prasanta sadhukhan wrote: Hi Phil, ? On 6/15/2016 12:21 AM, Phil Race wrote: This sound fishy. "2" does not sound like a valid value per the Microsoft spec but this driver is apparently considering it as something like a multiplier although presumably not to the actual resolution. ? I see that we are checking that the DM_YRESOLUTION bit of the dmFields member is set : ? 1002???????????? ????int xRes = devmode->dmPrintQuality; 1003???????????????? int yRes = (devmode->dmFields & DM_YRESOLUTION) ? 1004?????????????????? devmode->dmYResolution : devmode->dmPrintQuality; 1005???????????????? 1006???????????????? // For some printers, printer quality can specify 1200IQ 1007???????????????? // In this case, dmPrintQuality comes out 600 and 1008???????????????? // dmYResolution comes out 2 which is not a valid resolution 1009???????????????? // so for IQ setting, we specify yresolution same as xRes 1010???????????????? if (yRes < 10) yRes = xRes; .. so really they ought to return a DPI value as the spec says. I can't find anything that grants the apparent latitude being taken here. Note that your change here looks like it may break "quality" - where the pre-defined values are negative - as you will overwrite "-1" (for example) with 10. Actual breakage depends on whether we bother to read yRes in the case that xRes is negative but it still should not be over-written. If "quality" or dmPrintQuality is pre-defined negative value (like DMRES_HIGH, DMRES_MEDIUM, DMRES_LOW, DMRES_DRAFT) then it will be handled in the "if" block and my modification is in "else" . Not following that but in any case ... At a minimum you need to fix the code to look like :- int yRes = (devmode->dmFields & DM_YRESOLUTION) && (devmode->dmYResolution < 10) ??????????????? ? devmode->dmYResolution : devmode->dmPrintQuality; I guess you mean devmode->dmYResolution > 10 .. yes ? ? Anyways, I have updated webrev to accomodate your comment. HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/6966350/webrev.01/"http://cr.openjdk.java.net/~psadhukhan/6966350/webrev.01/ approved since we have a comment explaining the "logic" but still puzzled. -phil. ? ? But I find it a little unsatisfactory to have to make this kind of workaround and wonder what we are missing ... I could not find anything but this will help in getting printing to be working in those printers. If we find anything in near future, we will update this code . Regards Prasanta ? -phil. On 06/09/2016 04:35 AM, prasanta sadhukhan wrote: Hi All, Bug: https://bugs.openjdk.java.net/browse/JDK-6966350 The issue was if we select 1200IQ Normal (default) setting in Lexmark E352dn PS3 or Dell 5310n printer, it does not print the output and we get empty pages. It was because DEVMODE windows structure returns 600 for "dmPrintQuality" and 2 for "dmYResolution". For 2400IQ, it returns 600 dmPrintQuality and 4 as dmYResolution so awt_printControl.cpp#AwtPrintControl::UpdateAttributes() calls WPrinterJob#setResolutionDPI(xres=600, yres=2) and RasterPrinterJob#print() gets 0.027 as yscale(=getYRes()/72 and yres = 2) so devicetransform for normal 1200IQ dpi becomes [8.33, 0.0, -108.0][0.0, 0.027, -108.0] so WPathGraphics#drawString() gets devPos x= 725.33, y = -105.22. so nothing gets printed. I tried finding the significance of 1200IQ setting which just says it enhances the images sent to the printer. >From http://www.smallbusinesscomputing.com/testdrive/article.php/1585581/Lexmark-T420d-Printer-Review-Both-Sides-Now.htm (although it's not the same printer) says "To be fair, the LaserJet offers sharper resolution ? 1,200 by 1,200 dpi, while the T420d is a 600 by 600 dpi printer with what Lexmark calls "1,200 Image Quality" dot placement for photos" I modified the code to set yres to xres value if yres is less than 10 . Although it seems to be a workaround, it prints the output. webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/6966350/webrev.00/"http://cr.openjdk.java.net/~psadhukhan/6966350/webrev.00/ Regards Prasanta ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Fri Jun 17 10:07:26 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Fri, 17 Jun 2016 15:37:26 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6966350:Empty pages when printing on Lexmark E352dn PS3 with "1200 IQ" setting In-Reply-To: <1fa919d4-0edd-4532-8e94-8e8705ec5e02@default> References: <4a57f40d-9462-5236-7b2d-df69f97aa8e4@oracle.com> <57605238.3090707@oracle.com> <7e9a0d87-93fe-0ae8-e0e4-447610aa31e6@oracle.com> <5761E60A.5080308@oracle.com> <6a79c5c4-d21d-470d-9bf4-0ece3e3b920d@default> <1fa919d4-0edd-4532-8e94-8e8705ec5e02@default> Message-ID: Hi Jay, I have modified the testcase to select the proper printable, description (it seems for dell 5310 it is Properties->Print Quality whereas for lexmark it is as you mentioned) is changed to include both printers, increased timeout, removed unused imports and rectified indents. http://cr.openjdk.java.net/~psadhukhan/6966350/webrev.02/ Regards Prasanta On 6/17/2016 2:47 PM, Jayathirth D V wrote: > > Hi Prasanta, > > One more thing I missed, there are many unneeded imports in test case. > Please remove them also. > > Thanks, > > Jay > > *From:*Jayathirth D V > *Sent:* Friday, June 17, 2016 2:45 PM > *To:* Prasanta Sadhukhan > *Cc:* 2d-dev at openjdk.java.net > *Subject:* Re: [OpenJDK 2D-Dev] [9] RFR: JDK-6966350:Empty pages when > printing on Lexmark E352dn PS3 with "1200 IQ" setting > > Hi Prasanta, > > I tried to run the test but it looks like you are not creating object > for proper class in test case : > > 88 pj.setPrintable(new PrintableDemo(), pf); > > I think it should be test class name : > > 88 pj.setPrintable(new PrintTestLexmarkIQ(), pf); > > After we change it to test class name it is working fine. > > In the description of test JTextArea, I found Print quality setting > under Properties -> Advanced -> Graphic -> Print Quality. Please > verify the same. > > Also please increase timeout for test case as I was looking for Print > Quality setting and it came out. > > In test case jtreg multiline comment are not indented properly. > > Regarding code change, if we can be sure that in future image quality > setting will not increase more than 6000IQ then changes are fine. Also > in comments related to code change we can make it multiline comment > instead of multiple single line comments. > > Thanks, > > Jay > > *From:*Philip Race > *Sent:* Thursday, June 16, 2016 5:05 AM > *To:* prasanta sadhukhan > *Cc:* 2d-dev at openjdk.java.net > *Subject:* Re: [OpenJDK 2D-Dev] [9] RFR: JDK-6966350:Empty pages when > printing on Lexmark E352dn PS3 with "1200 IQ" setting > > > > On 6/14/16, 10:09 PM, prasanta sadhukhan wrote: > > Hi Phil, > > On 6/15/2016 12:21 AM, Phil Race wrote: > > This sound fishy. "2" does not sound like a valid value per the Microsoft spec > > but this driver is apparently considering it as something like a multiplier although > > presumably not to the actual resolution. > > I see that we are checking that the DM_YRESOLUTION bit of the dmFields member is set : > > 1002 int xRes = devmode->dmPrintQuality; > > 1003 int yRes = (devmode->dmFields & DM_YRESOLUTION) ? > > 1004 devmode->dmYResolution : devmode->dmPrintQuality; > > 1005 > > 1006 // For some printers, printer quality can > specify 1200IQ > > 1007 // In this case, dmPrintQuality comes out > 600 and > > 1008 // dmYResolution comes out 2 which is not > a valid resolution > > 1009 // so for IQ setting, we specify > yresolution same as xRes > > 1010 if (yRes < 10) yRes = xRes; > > > .. so really they ought to return a DPI value as the spec > says. I can't > find anything that grants the apparent latitude being taken here. > > Note that your change here looks like it may break "quality" - > where > the pre-defined values are negative - as you will overwrite > "-1" (for example) with 10. > Actual breakage depends on whether we bother to read yRes in > the case that > xRes is negative but it still should not be over-written. > > If "quality" or dmPrintQuality is pre-defined negative value > (like**DMRES_HIGH, DMRES_MEDIUM, DMRES_LOW, DMRES_DRAFT) > then it will be handled in the "if" block > and my modification is in "else" . > > > Not following that but in any case ... > > At a minimum you need to fix the code to look like :- > > int yRes = (devmode->dmFields & DM_YRESOLUTION) && (devmode->dmYResolution < 10) > > ? devmode->dmYResolution : devmode->dmPrintQuality; > > I guess you mean > > devmode->dmYResolution > 10 > > > .. yes > > Anyways, I have updated webrev to accomodate your comment. > > http://cr.openjdk.java.net/~psadhukhan/6966350/webrev.01/ > > > > approved since we have a comment explaining the "logic" but still puzzled. > > -phil. > > But I find it a little unsatisfactory to have to make this > kind of workaround > > and wonder what we are missing ... > > I could not find anything but this will help in getting printing > to be working in those printers. If we find anything in near > future, we will update this code . > > Regards > Prasanta > > -phil. > > On 06/09/2016 04:35 AM, prasanta sadhukhan wrote: > > Hi All, > > Bug: https://bugs.openjdk.java.net/browse/JDK-6966350 > > The issue was if we select 1200IQ Normal (default) setting > in Lexmark E352dn PS3 or Dell 5310n printer, it does not > print the output and we get empty pages. > > It was because DEVMODE windows structure returns 600 for > "dmPrintQuality" and 2 for "dmYResolution". For 2400IQ, it > returns 600 dmPrintQuality and 4 as dmYResolution > so > awt_printControl.cpp#AwtPrintControl::UpdateAttributes() > calls WPrinterJob#setResolutionDPI(xres=600, yres=2) and > RasterPrinterJob#print() gets 0.027 as > yscale(=getYRes()/72 and yres = 2) > so devicetransform for normal 1200IQ dpi becomes [8.33, > 0.0, -108.0][0.0, 0.027, -108.0] so > WPathGraphics#drawString() gets devPos x= 725.33, *y = > -105.22. > *so nothing gets printed. > > I tried finding the significance of 1200IQ setting which > just says it enhances the images sent to the printer. > From > http://www.smallbusinesscomputing.com/testdrive/article.php/1585581/Lexmark-T420d-Printer-Review-Both-Sides-Now.htm > (although it's not the same printer) > says /"To be fair, the LaserJet offers sharper resolution > ? 1,200 by 1,200 dpi, while the T420d is a 600 by 600 dpi > printer with what Lexmark calls "1,200 Image Quality" dot > placement for photos" > > /I modified the code to set yres to xres value if yres is > less than 10 . Although it seems to be a workaround, it > prints the output. > > webrev: > http://cr.openjdk.java.net/~psadhukhan/6966350/webrev.00/ > > > Regards > Prasanta > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.markov at oracle.com Fri Jun 17 10:47:39 2016 From: dmitry.markov at oracle.com (dmitry markov) Date: Fri, 17 Jun 2016 13:47:39 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8144703: ClassCastException: sun.font.CompositeFont cannot be cast to PhysicalFont In-Reply-To: <575AAD6A.5040903@oracle.com> References: <575AAD6A.5040903@oracle.com> Message-ID: <5763D54B.1030405@oracle.com> Reminder. Could you review the fix, please? Thanks in advance, Dmitry On 10/06/2016 15:07, dmitry markov wrote: > Hello, > > Could you review a fix for jdk9, please? > > bug: https://bugs.openjdk.java.net/browse/JDK-8144703 > webrev: http://cr.openjdk.java.net/~dmarkov/8144703/webrev.00/ > > Problem description: > If an incorrect font file is used, we unable to initialize the font > during CompositeFont.doDeferredInitialisation() invocation and assign > default physical font to the corresponding components entry. Later at > the same method, (i.e. doDeferredInitialisation()) we try to update > this entry one more time, since the name retrieved from the entry and > the name provide by componentNames array are different. The method > SunFontManager.findFont2D() may return a composite font for such case. > As a result we get ClassCastException trying to assign CompositeFont > object to the instance of PhysicalFont. > > Fix: > Surround invocation of SunFontManager.findFont2D() inside > CompositeFont.doDeferredInitialisation() with 'try-catch' to avoid > propagation of ClassCastException. > > Thanks, > Dmitry From jayathirth.d.v at oracle.com Fri Jun 17 11:02:36 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Fri, 17 Jun 2016 04:02:36 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-6966350:Empty pages when printing on Lexmark E352dn PS3 with "1200 IQ" setting In-Reply-To: References: <4a57f40d-9462-5236-7b2d-df69f97aa8e4@oracle.com> <57605238.3090707@oracle.com> <7e9a0d87-93fe-0ae8-e0e4-447610aa31e6@oracle.com> <5761E60A.5080308@oracle.com> <6a79c5c4-d21d-470d-9bf4-0ece3e3b920d@default> <1fa919d4-0edd-4532-8e94-8e8705ec5e02@default> Message-ID: Hi Prasanta, ? Changes are fine. ? Thanks, Jay ? From: prasanta sadhukhan Sent: Friday, June 17, 2016 3:37 PM To: Jayathirth D V Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9] RFR: JDK-6966350:Empty pages when printing on Lexmark E352dn PS3 with "1200 IQ" setting ? Hi Jay, I have modified the testcase to select the proper printable, description (it seems for dell 5310 it is Properties->Print Quality whereas for lexmark it is as you mentioned) is changed to include both printers, increased timeout, removed unused imports and rectified indents. http://cr.openjdk.java.net/~psadhukhan/6966350/webrev.02/ Regards Prasanta On 6/17/2016 2:47 PM, Jayathirth D V wrote: Hi Prasanta, ? One more thing I missed, there are many unneeded imports in test case. Please remove them also. ? Thanks, Jay ? From: Jayathirth D V Sent: Friday, June 17, 2016 2:45 PM 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-6966350:Empty pages when printing on Lexmark E352dn PS3 with "1200 IQ" setting ? Hi Prasanta, ? I tried to run the test but it looks like you are not creating object for proper class in test case : 88???????? pj.setPrintable(new PrintableDemo(), pf); ? ? I think it should be test class name : 88???????? pj.setPrintable(new PrintTestLexmarkIQ(), pf); ? After we change it to test class name it is working fine. ? In the description of test JTextArea, I found Print quality setting under Properties -> Advanced -> Graphic -> Print Quality. Please verify the same. Also please increase timeout for test case as I was looking for Print Quality setting and it came out. In test case jtreg multiline comment are not indented properly. ? Regarding code change, if we can be sure that in future image quality setting will not increase more than 6000IQ then changes are fine. Also in comments related to code change we can make it multiline comment instead of multiple single line comments. ? Thanks, Jay ? ? From: Philip Race Sent: Thursday, June 16, 2016 5:05 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-6966350:Empty pages when printing on Lexmark E352dn PS3 with "1200 IQ" setting ? On 6/14/16, 10:09 PM, prasanta sadhukhan wrote: Hi Phil, ? On 6/15/2016 12:21 AM, Phil Race wrote: This sound fishy. "2" does not sound like a valid value per the Microsoft spec but this driver is apparently considering it as something like a multiplier although presumably not to the actual resolution. ? I see that we are checking that the DM_YRESOLUTION bit of the dmFields member is set : ? 1002???????????? ????int xRes = devmode->dmPrintQuality; 1003???????????????? int yRes = (devmode->dmFields & DM_YRESOLUTION) ? 1004?????????????????? devmode->dmYResolution : devmode->dmPrintQuality; 1005???????????????? 1006???????????????? // For some printers, printer quality can specify 1200IQ 1007???????????????? // In this case, dmPrintQuality comes out 600 and 1008???????????????? // dmYResolution comes out 2 which is not a valid resolution 1009???????????????? // so for IQ setting, we specify yresolution same as xRes 1010???????????????? if (yRes < 10) yRes = xRes; .. so really they ought to return a DPI value as the spec says. I can't find anything that grants the apparent latitude being taken here. Note that your change here looks like it may break "quality" - where the pre-defined values are negative - as you will overwrite "-1" (for example) with 10. Actual breakage depends on whether we bother to read yRes in the case that xRes is negative but it still should not be over-written. If "quality" or dmPrintQuality is pre-defined negative value (like DMRES_HIGH, DMRES_MEDIUM, DMRES_LOW, DMRES_DRAFT) then it will be handled in the "if" block and my modification is in "else" . Not following that but in any case ... At a minimum you need to fix the code to look like :- int yRes = (devmode->dmFields & DM_YRESOLUTION) && (devmode->dmYResolution < 10) ??????????????? ? devmode->dmYResolution : devmode->dmPrintQuality; I guess you mean devmode->dmYResolution > 10 .. yes ? ? Anyways, I have updated webrev to accomodate your comment. HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/6966350/webrev.01/"http://cr.openjdk.java.net/~psadhukhan/6966350/webrev.01/ approved since we have a comment explaining the "logic" but still puzzled. -phil. ? ? But I find it a little unsatisfactory to have to make this kind of workaround and wonder what we are missing ... I could not find anything but this will help in getting printing to be working in those printers. If we find anything in near future, we will update this code . Regards Prasanta ? -phil. On 06/09/2016 04:35 AM, prasanta sadhukhan wrote: Hi All, Bug: https://bugs.openjdk.java.net/browse/JDK-6966350 The issue was if we select 1200IQ Normal (default) setting in Lexmark E352dn PS3 or Dell 5310n printer, it does not print the output and we get empty pages. It was because DEVMODE windows structure returns 600 for "dmPrintQuality" and 2 for "dmYResolution". For 2400IQ, it returns 600 dmPrintQuality and 4 as dmYResolution so awt_printControl.cpp#AwtPrintControl::UpdateAttributes() calls WPrinterJob#setResolutionDPI(xres=600, yres=2) and RasterPrinterJob#print() gets 0.027 as yscale(=getYRes()/72 and yres = 2) so devicetransform for normal 1200IQ dpi becomes [8.33, 0.0, -108.0][0.0, 0.027, -108.0] so WPathGraphics#drawString() gets devPos x= 725.33, y = -105.22. so nothing gets printed. I tried finding the significance of 1200IQ setting which just says it enhances the images sent to the printer. >From http://www.smallbusinesscomputing.com/testdrive/article.php/1585581/Lexmark-T420d-Printer-Review-Both-Sides-Now.htm (although it's not the same printer) says "To be fair, the LaserJet offers sharper resolution ? 1,200 by 1,200 dpi, while the T420d is a 600 by 600 dpi printer with what Lexmark calls "1,200 Image Quality" dot placement for photos" I modified the code to set yres to xres value if yres is less than 10 . Although it seems to be a workaround, it prints the output. webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/6966350/webrev.00/"http://cr.openjdk.java.net/~psadhukhan/6966350/webrev.00/ Regards Prasanta ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Fri Jun 17 14:20:53 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 17 Jun 2016 17:20:53 +0300 Subject: [OpenJDK 2D-Dev] RFR(L): 8159690: [TESTBUG] Mark headful tests with @key headful. In-Reply-To: <0682a62cf09045b5a394dbcf70cd2ebc@DEWDFE13DE09.global.corp.sap> References: <906afad52c284df2bc8a509e00007912@DEWDFE13DE09.global.corp.sap> <791258f1-0e1a-9b09-7021-816137e1146b@oracle.com> <67f94b06-23fb-a280-f706-20808cab000e@oracle.com> <503e07b1c4c5469d8a0ed516cb5bb01c@DEWDFE13DE09.global.corp.sap> <32a8ced1-f5f5-d3e1-4834-254bcb106165@oracle.com> <726f6bd0-6463-0515-9a81-328785694b5d@oracle.com> <0682a62cf09045b5a394dbcf70cd2ebc@DEWDFE13DE09.global.corp.sap> Message-ID: <4e4dca16-76e4-d9fc-12f2-fad347f9e13a@oracle.com> I guess that 2d team should review it as well (cc) On 17.06.16 17:17, Lindenmaier, Goetz wrote: > Hi Alexandr, > > Thanks for reviewing! > > Best regards, > Goetz. > >> -----Original Message----- >> From: Alexandr Scherbatiy [mailto:alexandr.scherbatiy at oracle.com] >> Sent: Freitag, 17. Juni 2016 16:04 >> To: Volker Simonis >> Cc: Lindenmaier, Goetz ; swing- >> dev at openjdk.java.net; awt-dev at openjdk.java.net >> Subject: Re: RFR(L): 8159690: [TESTBUG] Mark >> headful tests with @key headful. >> >> >> The change looks good to me. >> >> Thanks, >> Alexandr. >> >> On 6/17/2016 4:54 PM, Volker Simonis wrote: >>> On Fri, Jun 17, 2016 at 3:40 PM, Alexandr Scherbatiy >>> wrote: >>>> On 6/17/2016 4:17 PM, Lindenmaier, Goetz wrote: >>>>> Hi Alexandr, >>>>> >>>>> yes, you are right, the test you mention is missing in this change. >>>>> There are others, too, and we still have lots of failures for other >>>>> reasons. >>>>> >>>>> We are currently working on getting all the tests green in >>>>> our test environment where we test linuxppc64, linuxppc64le >>>>> and aixppc64 (and, for reference, the Oracle platforms). >>>>> So I will address all the remaining issues at some point. >>>>> >>>>> If you basically agree on this change, I would appreciate if we >>>>> could push this one and I make a follow up change. Handling >>>>> changes with this many files is a pain point. But I can also >>>>> extend this change so that we get all of them at once. >>>> >>>> As I see there are areas like jdk_beans or jdk_imageio which usually >> does >>>> not require headful environment and jdk_awt or jdk_swing which usually >>>> requires it. It seems that ordinary AWT/Swing tests require the "headful" >>>> keyword. >>>> >>>> May be it is more appropriate to have "headful" keyword for areas like >>>> jdk_beans and "headless" keyword for areas like jdk_awt and jdk_swing? >> This >>>> will allow to mark only small part of tests with necessary keyword for each >>>> area. >>>> >>> While this approach sounds desirable, I'm not aware of functionality >>> in jtreg which allows marking all the tests in a test group (e.g. >>> jdk_awt) with a special default keyword which can be override in the >>> test itself. >>> >>> After all, the author of a test should know best if his test requires >>> a headful environment or not. I think after we've gone trough the >>> initial pain of marking all headful test, the future development >>> should then be straightforward and simple. >>> >>>> In other way almost all AWT/Swing tests should be marked by "headful" >>>> keyword. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Alexandr Scherbatiy [mailto:alexandr.scherbatiy at oracle.com] >>>>>> Sent: Freitag, 17. Juni 2016 14:53 >>>>>> To: Volker Simonis >>>>>> Cc: Lindenmaier, Goetz ; swing- >>>>>> dev at openjdk.java.net; awt-dev at openjdk.java.net >>>>>> Subject: Re: RFR(L): 8159690: [TESTBUG] >> Mark >>>>>> headful tests with @key headful. >>>>>> >>>>>> On 6/17/2016 11:36 AM, Volker Simonis wrote: >>>>>>> On Thu, Jun 16, 2016 at 5:55 PM, Alexandr Scherbatiy >>>>>>> wrote: >>>>>>>> On 6/16/2016 5:40 PM, Lindenmaier, Goetz wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> we have test machines without X server. On these many of the jdk >>>>>>>> >>>>>>>> jtreg tests fail with a headless exception. >>>>>>>> >>>>>>>> We grepped for this exception in the test output and identified >>>>>>>> >>>>>>>> about 450 tests. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> In these tests, we added with another script "@key headful". >>>>>>>> >>>>>>>> What is a number of tests which passe in headless mode? >>>>>>>> >>>>>>>> I would expect that an ordinary client test which use Frame and >>>>>>>> fails in >>>>>>>> headless mode does not require a special key by default. >>>>>>>> >>>>>>> Hi Alexandr, >>>>>>> >>>>>>> I don't quite understand your concerns, but the purpose of this >> change >>>>>>> is to make it possible to simply exclude all tests which require a >>>>>>> "headful" environment from a jtreg run. >>>>>>> >>>>>>> There are AWT/Swing tests which can be run even without X server. >> For >>>>>> example: >>>>>>> java/awt/image/DrawImage/DrawImageCoordsTest.java >>>>>>> >>>>>>> Others, like for example: >>>>>>> >>>>>>> java/awt/image/DrawImage/EABlitTest.jtr >>>>>>> >>>>>>> will throw a Headless exception and fail: >>>>>>> >>>>>>> java.awt.HeadlessException: >>>>>>> No X11 DISPLAY variable was set, but this program performed an >>>>>>> operation which requires it. >>>>>>> >>>>>>> With Goetz's change we can simply exclude all the test which require >> a >>>>>>> headful environment by specifying "-keywords:\!headful" to jtreg. >>>>>>> After all, I think that's the purpose why the "headful" keyword has >>>>>>> been introduced. >>>>>>> >>>>>>> If there's any other simple way of excluding all tests which require a >>>>>>> headful environment, please let us now. >>>>>> For example, the test >>>>>> jdk/test/javax/swing/AbstractButton/6711682/bug6711682.java when >> it is >>>>>> run with -Djava.awt.headless=true option fails with exception >>>>>> "java.awt.AWTException: headless environment". >>>>>> >>>>>> The test is not listed in the proposed patch. Is it correct that this >>>>>> test requires the "headful" environment and should be marked with >> the >>>>>> "headful" keyword? >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>>> Regards, >>>>>>> Volker >>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>> >>>>>>>> So that the script generates better output, I adapted the >>>>>>>> >>>>>>>> formatting of some of the test descriptions. >>>>>>>> >>>>>>>> see also the text in the webrev, where I posted some incremental >> diffs >>>>>>>> >>>>>>>> of the changes I more or less edited by hand. I hope this eases >>>>>>>> >>>>>>>> reviewing :) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Last, I updated the Copyrights with the script by Coleen. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Please review this change. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8159690- >> headful/webrev.01/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Goetz. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> > -- Best regards, Sergey. From goetz.lindenmaier at sap.com Fri Jun 17 14:23:36 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 17 Jun 2016 14:23:36 +0000 Subject: [OpenJDK 2D-Dev] RFR(L): 8159690: [TESTBUG] Mark headful tests with @key headful. In-Reply-To: <4e4dca16-76e4-d9fc-12f2-fad347f9e13a@oracle.com> References: <906afad52c284df2bc8a509e00007912@DEWDFE13DE09.global.corp.sap> <791258f1-0e1a-9b09-7021-816137e1146b@oracle.com> <67f94b06-23fb-a280-f706-20808cab000e@oracle.com> <503e07b1c4c5469d8a0ed516cb5bb01c@DEWDFE13DE09.global.corp.sap> <32a8ced1-f5f5-d3e1-4834-254bcb106165@oracle.com> <726f6bd0-6463-0515-9a81-328785694b5d@oracle.com> <0682a62cf09045b5a394dbcf70cd2ebc@DEWDFE13DE09.global.corp.sap> <4e4dca16-76e4-d9fc-12f2-fad347f9e13a@oracle.com> Message-ID: <9cefe7d5e8c947a997d8dd4ac2286382@DEWDFE13DE09.global.corp.sap> Hi Sergey, Sorry, I pushed it just now! If you (or anybody else) has any objections I can revert this or do a follow-up to correct it. Please let me know. Best regards, Goetz. > -----Original Message----- > From: Sergey Bylokhov [mailto:Sergey.Bylokhov at oracle.com] > Sent: Freitag, 17. Juni 2016 16:21 > To: Lindenmaier, Goetz ; Alexandr Scherbatiy > ; Volker Simonis > > Cc: awt-dev at openjdk.java.net; swing-dev at openjdk.java.net; 2d-dev <2d- > dev at openjdk.java.net> > Subject: Re: RFR(L): 8159690: [TESTBUG] Mark > headful tests with @key headful. > > I guess that 2d team should review it as well (cc) > > On 17.06.16 17:17, Lindenmaier, Goetz wrote: > > Hi Alexandr, > > > > Thanks for reviewing! > > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: Alexandr Scherbatiy [mailto:alexandr.scherbatiy at oracle.com] > >> Sent: Freitag, 17. Juni 2016 16:04 > >> To: Volker Simonis > >> Cc: Lindenmaier, Goetz ; swing- > >> dev at openjdk.java.net; awt-dev at openjdk.java.net > >> Subject: Re: RFR(L): 8159690: [TESTBUG] Mark > >> headful tests with @key headful. > >> > >> > >> The change looks good to me. > >> > >> Thanks, > >> Alexandr. > >> > >> On 6/17/2016 4:54 PM, Volker Simonis wrote: > >>> On Fri, Jun 17, 2016 at 3:40 PM, Alexandr Scherbatiy > >>> wrote: > >>>> On 6/17/2016 4:17 PM, Lindenmaier, Goetz wrote: > >>>>> Hi Alexandr, > >>>>> > >>>>> yes, you are right, the test you mention is missing in this change. > >>>>> There are others, too, and we still have lots of failures for other > >>>>> reasons. > >>>>> > >>>>> We are currently working on getting all the tests green in > >>>>> our test environment where we test linuxppc64, linuxppc64le > >>>>> and aixppc64 (and, for reference, the Oracle platforms). > >>>>> So I will address all the remaining issues at some point. > >>>>> > >>>>> If you basically agree on this change, I would appreciate if we > >>>>> could push this one and I make a follow up change. Handling > >>>>> changes with this many files is a pain point. But I can also > >>>>> extend this change so that we get all of them at once. > >>>> > >>>> As I see there are areas like jdk_beans or jdk_imageio which usually > >> does > >>>> not require headful environment and jdk_awt or jdk_swing which > usually > >>>> requires it. It seems that ordinary AWT/Swing tests require the > "headful" > >>>> keyword. > >>>> > >>>> May be it is more appropriate to have "headful" keyword for areas > like > >>>> jdk_beans and "headless" keyword for areas like jdk_awt and > jdk_swing? > >> This > >>>> will allow to mark only small part of tests with necessary keyword for > each > >>>> area. > >>>> > >>> While this approach sounds desirable, I'm not aware of functionality > >>> in jtreg which allows marking all the tests in a test group (e.g. > >>> jdk_awt) with a special default keyword which can be override in the > >>> test itself. > >>> > >>> After all, the author of a test should know best if his test requires > >>> a headful environment or not. I think after we've gone trough the > >>> initial pain of marking all headful test, the future development > >>> should then be straightforward and simple. > >>> > >>>> In other way almost all AWT/Swing tests should be marked by > "headful" > >>>> keyword. > >>>> > >>>> Thanks, > >>>> Alexandr. > >>>> > >>>> > >>>>> Best regards, > >>>>> Goetz. > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Alexandr Scherbatiy [mailto:alexandr.scherbatiy at oracle.com] > >>>>>> Sent: Freitag, 17. Juni 2016 14:53 > >>>>>> To: Volker Simonis > >>>>>> Cc: Lindenmaier, Goetz ; swing- > >>>>>> dev at openjdk.java.net; awt-dev at openjdk.java.net > >>>>>> Subject: Re: RFR(L): 8159690: [TESTBUG] > >> Mark > >>>>>> headful tests with @key headful. > >>>>>> > >>>>>> On 6/17/2016 11:36 AM, Volker Simonis wrote: > >>>>>>> On Thu, Jun 16, 2016 at 5:55 PM, Alexandr Scherbatiy > >>>>>>> wrote: > >>>>>>>> On 6/16/2016 5:40 PM, Lindenmaier, Goetz wrote: > >>>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> we have test machines without X server. On these many of the > jdk > >>>>>>>> > >>>>>>>> jtreg tests fail with a headless exception. > >>>>>>>> > >>>>>>>> We grepped for this exception in the test output and identified > >>>>>>>> > >>>>>>>> about 450 tests. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> In these tests, we added with another script "@key headful". > >>>>>>>> > >>>>>>>> What is a number of tests which passe in headless mode? > >>>>>>>> > >>>>>>>> I would expect that an ordinary client test which use Frame and > >>>>>>>> fails in > >>>>>>>> headless mode does not require a special key by default. > >>>>>>>> > >>>>>>> Hi Alexandr, > >>>>>>> > >>>>>>> I don't quite understand your concerns, but the purpose of this > >> change > >>>>>>> is to make it possible to simply exclude all tests which require a > >>>>>>> "headful" environment from a jtreg run. > >>>>>>> > >>>>>>> There are AWT/Swing tests which can be run even without X > server. > >> For > >>>>>> example: > >>>>>>> java/awt/image/DrawImage/DrawImageCoordsTest.java > >>>>>>> > >>>>>>> Others, like for example: > >>>>>>> > >>>>>>> java/awt/image/DrawImage/EABlitTest.jtr > >>>>>>> > >>>>>>> will throw a Headless exception and fail: > >>>>>>> > >>>>>>> java.awt.HeadlessException: > >>>>>>> No X11 DISPLAY variable was set, but this program performed an > >>>>>>> operation which requires it. > >>>>>>> > >>>>>>> With Goetz's change we can simply exclude all the test which > require > >> a > >>>>>>> headful environment by specifying "-keywords:\!headful" to jtreg. > >>>>>>> After all, I think that's the purpose why the "headful" keyword has > >>>>>>> been introduced. > >>>>>>> > >>>>>>> If there's any other simple way of excluding all tests which require a > >>>>>>> headful environment, please let us now. > >>>>>> For example, the test > >>>>>> jdk/test/javax/swing/AbstractButton/6711682/bug6711682.java > when > >> it is > >>>>>> run with -Djava.awt.headless=true option fails with exception > >>>>>> "java.awt.AWTException: headless environment". > >>>>>> > >>>>>> The test is not listed in the proposed patch. Is it correct that this > >>>>>> test requires the "headful" environment and should be marked with > >> the > >>>>>> "headful" keyword? > >>>>>> > >>>>>> Thanks, > >>>>>> Alexandr. > >>>>>> > >>>>>>> Regards, > >>>>>>> Volker > >>>>>>> > >>>>>>>> Thanks, > >>>>>>>> Alexandr. > >>>>>>>> > >>>>>>>> > >>>>>>>> So that the script generates better output, I adapted the > >>>>>>>> > >>>>>>>> formatting of some of the test descriptions. > >>>>>>>> > >>>>>>>> see also the text in the webrev, where I posted some incremental > >> diffs > >>>>>>>> > >>>>>>>> of the changes I more or less edited by hand. I hope this eases > >>>>>>>> > >>>>>>>> reviewing :) > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Last, I updated the Copyrights with the script by Coleen. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Please review this change. > >>>>>>>> > >>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8159690- > >> headful/webrev.01/ > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Best regards, > >>>>>>>> > >>>>>>>> Goetz. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > > > > > -- > Best regards, Sergey. From philip.race at oracle.com Sat Jun 18 23:16:22 2016 From: philip.race at oracle.com (Philip Race) Date: Sat, 18 Jun 2016 16:16:22 -0700 Subject: [OpenJDK 2D-Dev] RFR: 4497648: TextLayout equals method is not implemented Message-ID: <5765D646.5070708@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-4497648 Webrev : http://cr.openjdk.java.net/~prr/4497648/ TextLayout is a final class that derives directly from Object. It defines boolean equals(TextLayout) and over-rides boolean equals(Object) int hashCode(); The hashCode() delegates to the implementation class TextLine(). TextLine is also a final class that directly derives from Object It does over-ride Object.hashCode() but *does not* over-ride Object.equals(Object). Aside from this breaking the rule that you should over-ride neither or both - migitated only by the fact that this is a non-API class - the equals(..) methods on TextLayout() delegate to this class. The result of all this is that TextLayout.equals(..) is really Object.equals(), whilst TextLayout.hashCode() is not Object.hashCode(). Further the javadoc on TextLayout.equals(TextLayout) says that the compared instances are equal if they contain the same glyph vectors. Note that whilst there is this and other commentary on the class mentioning glyph vectors, the GlyphVector class is not exposed anywhere in the API of TextLayout and we can take this only to infer that it is implying that the laid out text is equivalent. But as already noted there is no implementation to support comparing the internal state. Since this state of affairs goes back to 1.2 and it is neither easy, nor obviously valuable to be able to make such comparisons, we should make the spec. match the long standing implementation. So this fix removes the over-rides that add no value, and removes the wording about equal glyph vectors in favour of text that cannot be used to interpret that there is anything other than the minimal equivalence of equals. It would have been better if equals(TextLayout) had not been added at all but that ship has sailed. FYI .. I have already discussed this proposal off-line with the JCK team and they are happy so long as the spec. matches the implementation. CCC will be filed once this is reviewed - and I also had an off-line conversation with Joe Darcy. -phil. From prasanta.sadhukhan at oracle.com Mon Jun 20 06:31:38 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Mon, 20 Jun 2016 12:01:38 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6218397:Printing to file does not throw a PrinterException if the file cannot be created In-Reply-To: <1209f6f2-36df-6655-c542-d3836b11ff71@oracle.com> References: <576180D4.9040502@oracle.com> <1209f6f2-36df-6655-c542-d3836b11ff71@oracle.com> Message-ID: <7461a8f1-5263-a7b8-3dab-a4bd0733890b@oracle.com> Hi Phil,All, Added file delete in another case where we throw PrinterException. http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.02/ Regards Prasanta On 6/16/2016 1:40 PM, prasanta sadhukhan wrote: > > Modified webrev to close output stream. > > http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.01/ > > Regards > Prasanta > On 6/15/2016 9:52 PM, Philip Race wrote: >> If this is executed on Windows (shared Postscript stream printer >> could do this) >> then since the output stream is still open I expect the delete will fail. >> Attempt to close the open stream first (in a try .. catch I suppose). >> >> -phil. >> >> On 6/15/16, 3:25 AM, prasanta sadhukhan wrote: >>> >>> Hi All, >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-6218397 >>> >>> The issue was if the linux disk is full and we are trying to "print >>> to file" then PrinterException is not thrown and a 0 byte file is >>> created. >>> >>> Although I am not able to reproduce this behaviour, because when I >>> make my disk full and try to run "java", I get >>> >>> /Java HotSpot(TM) Server VM warning: Insufficient space for shared >>> memory file:// >>> // 13783// >>> //Try using the -Djava.io.tmpdir= option to select an alternate temp >>> location./ >>> >>> but on investigating this, I see that we are calling >>> f.createNewFile() in RasterPrinterJob#validateDestination() which >>> creates a new, empty file >>> >>> but if there is any exception in PSPrinterJob#startDoc this file is >>> not deleted. >>> >>> Modified the code to make sure if there is any exception, delete the >>> file. >>> >>> http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.00/ >>> >>> Regards >>> Prasanta >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Mon Jun 20 12:11:18 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 20 Jun 2016 17:41:18 +0530 Subject: [OpenJDK 2D-Dev] RFR: 4497648: TextLayout equals method is not implemented In-Reply-To: <5765D646.5070708@oracle.com> References: <5765D646.5070708@oracle.com> Message-ID: <5767DD66.2030200@oracle.com> Looks ok to me. Regards Prasanta On 6/19/2016 4:46 AM, Philip Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-4497648 > Webrev : http://cr.openjdk.java.net/~prr/4497648/ > > TextLayout is a final class that derives directly from Object. > It defines > boolean equals(TextLayout) > and over-rides > boolean equals(Object) > int hashCode(); > > The hashCode() delegates to the implementation class TextLine(). > TextLine is also a final class that directly derives from Object > It does over-ride Object.hashCode() but *does not* over-ride > Object.equals(Object). > > Aside from this breaking the rule that you should over-ride neither or > both - > migitated only by the fact that this is a non-API class - > the equals(..) methods on TextLayout() delegate to this class. > > The result of all this is that TextLayout.equals(..) is really > Object.equals(), > whilst TextLayout.hashCode() is not Object.hashCode(). > > Further the javadoc on TextLayout.equals(TextLayout) says that the > compared instances are equal if they contain the same glyph vectors. > Note that whilst there is this and other commentary on the class > mentioning glyph vectors, the GlyphVector class is not exposed > anywhere in the API of TextLayout and we can take this only to > infer that it is implying that the laid out text is equivalent. > But as already noted there is no implementation to support > comparing the internal state. > > Since this state of affairs goes back to 1.2 and it is neither easy, > nor obviously valuable to be able to make such comparisons, we > should make the spec. match the long standing implementation. > > So this fix removes the over-rides that add no value, and removes > the wording about equal glyph vectors in favour of text that cannot > be used to interpret that there is anything other than the minimal > equivalence of equals. It would have been better if equals(TextLayout) > had not been added at all but that ship has sailed. > > FYI .. I have already discussed this proposal off-line with the JCK team > and they are happy so long as the spec. matches the implementation. > CCC will be filed once this is reviewed - and I also had an off-line > conversation with Joe Darcy. > > -phil. > From Sergey.Bylokhov at oracle.com Mon Jun 20 12:22:34 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 20 Jun 2016 15:22:34 +0300 Subject: [OpenJDK 2D-Dev] RFR: 4497648: TextLayout equals method is not implemented In-Reply-To: <5767DD66.2030200@oracle.com> References: <5765D646.5070708@oracle.com> <5767DD66.2030200@oracle.com> Message-ID: <0e05f729-f807-c560-415d-b0e46bbbae79@oracle.com> Looks fine. On 20.06.16 15:11, Prasanta Sadhukhan wrote: > Looks ok to me. > > Regards > Prasanta > On 6/19/2016 4:46 AM, Philip Race wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-4497648 >> Webrev : http://cr.openjdk.java.net/~prr/4497648/ >> >> TextLayout is a final class that derives directly from Object. >> It defines >> boolean equals(TextLayout) >> and over-rides >> boolean equals(Object) >> int hashCode(); >> >> The hashCode() delegates to the implementation class TextLine(). >> TextLine is also a final class that directly derives from Object >> It does over-ride Object.hashCode() but *does not* over-ride >> Object.equals(Object). >> >> Aside from this breaking the rule that you should over-ride neither or >> both - >> migitated only by the fact that this is a non-API class - >> the equals(..) methods on TextLayout() delegate to this class. >> >> The result of all this is that TextLayout.equals(..) is really >> Object.equals(), >> whilst TextLayout.hashCode() is not Object.hashCode(). >> >> Further the javadoc on TextLayout.equals(TextLayout) says that the >> compared instances are equal if they contain the same glyph vectors. >> Note that whilst there is this and other commentary on the class >> mentioning glyph vectors, the GlyphVector class is not exposed >> anywhere in the API of TextLayout and we can take this only to >> infer that it is implying that the laid out text is equivalent. >> But as already noted there is no implementation to support >> comparing the internal state. >> >> Since this state of affairs goes back to 1.2 and it is neither easy, >> nor obviously valuable to be able to make such comparisons, we >> should make the spec. match the long standing implementation. >> >> So this fix removes the over-rides that add no value, and removes >> the wording about equal glyph vectors in favour of text that cannot >> be used to interpret that there is anything other than the minimal >> equivalence of equals. It would have been better if equals(TextLayout) >> had not been added at all but that ship has sailed. >> >> FYI .. I have already discussed this proposal off-line with the JCK team >> and they are happy so long as the spec. matches the implementation. >> CCC will be filed once this is reviewed - and I also had an off-line >> conversation with Joe Darcy. >> >> -phil. >> > -- Best regards, Sergey. From philip.race at oracle.com Mon Jun 20 20:18:00 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 20 Jun 2016 13:18:00 -0700 Subject: [OpenJDK 2D-Dev] RFR(L): 8159690: [TESTBUG] Mark headful tests with @key headful. In-Reply-To: <9cefe7d5e8c947a997d8dd4ac2286382@DEWDFE13DE09.global.corp.sap> References: <906afad52c284df2bc8a509e00007912@DEWDFE13DE09.global.corp.sap> <791258f1-0e1a-9b09-7021-816137e1146b@oracle.com> <67f94b06-23fb-a280-f706-20808cab000e@oracle.com> <503e07b1c4c5469d8a0ed516cb5bb01c@DEWDFE13DE09.global.corp.sap> <32a8ced1-f5f5-d3e1-4834-254bcb106165@oracle.com> <726f6bd0-6463-0515-9a81-328785694b5d@oracle.com> <0682a62cf09045b5a394dbcf70cd2ebc@DEWDFE13DE09.global.corp.sap> <4e4dca16-76e4-d9fc-12f2-fad347f9e13a@oracle.com> <9cefe7d5e8c947a997d8dd4ac2286382@DEWDFE13DE09.global.corp.sap> Message-ID: <57684F78.3070302@oracle.com> It should have been reviewed on 2d as well - I only just saw this. But how I noticed is that as I am syncing jdk9/dev into jdk9/client I saw hundreds (!) of client tests had been updated in the wrong forest. Client test changes and other client changes go into 9/client unless there is a very good reason otherwise - and it is approved by a client group lead. -phil. On 06/17/2016 07:23 AM, Lindenmaier, Goetz wrote: > Hi Sergey, > > Sorry, I pushed it just now! If you (or anybody else) has any objections > I can revert this or do a follow-up to correct it. Please let me know. > > Best regards, > Goetz. > > > >> -----Original Message----- >> From: Sergey Bylokhov [mailto:Sergey.Bylokhov at oracle.com] >> Sent: Freitag, 17. Juni 2016 16:21 >> To: Lindenmaier, Goetz ; Alexandr Scherbatiy >> ; Volker Simonis >> >> Cc: awt-dev at openjdk.java.net; swing-dev at openjdk.java.net; 2d-dev <2d- >> dev at openjdk.java.net> >> Subject: Re: RFR(L): 8159690: [TESTBUG] Mark >> headful tests with @key headful. >> >> I guess that 2d team should review it as well (cc) >> >> On 17.06.16 17:17, Lindenmaier, Goetz wrote: >>> Hi Alexandr, >>> >>> Thanks for reviewing! >>> >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: Alexandr Scherbatiy [mailto:alexandr.scherbatiy at oracle.com] >>>> Sent: Freitag, 17. Juni 2016 16:04 >>>> To: Volker Simonis >>>> Cc: Lindenmaier, Goetz ; swing- >>>> dev at openjdk.java.net; awt-dev at openjdk.java.net >>>> Subject: Re: RFR(L): 8159690: [TESTBUG] Mark >>>> headful tests with @key headful. >>>> >>>> >>>> The change looks good to me. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 6/17/2016 4:54 PM, Volker Simonis wrote: >>>>> On Fri, Jun 17, 2016 at 3:40 PM, Alexandr Scherbatiy >>>>> wrote: >>>>>> On 6/17/2016 4:17 PM, Lindenmaier, Goetz wrote: >>>>>>> Hi Alexandr, >>>>>>> >>>>>>> yes, you are right, the test you mention is missing in this change. >>>>>>> There are others, too, and we still have lots of failures for other >>>>>>> reasons. >>>>>>> >>>>>>> We are currently working on getting all the tests green in >>>>>>> our test environment where we test linuxppc64, linuxppc64le >>>>>>> and aixppc64 (and, for reference, the Oracle platforms). >>>>>>> So I will address all the remaining issues at some point. >>>>>>> >>>>>>> If you basically agree on this change, I would appreciate if we >>>>>>> could push this one and I make a follow up change. Handling >>>>>>> changes with this many files is a pain point. But I can also >>>>>>> extend this change so that we get all of them at once. >>>>>> As I see there are areas like jdk_beans or jdk_imageio which usually >>>> does >>>>>> not require headful environment and jdk_awt or jdk_swing which >> usually >>>>>> requires it. It seems that ordinary AWT/Swing tests require the >> "headful" >>>>>> keyword. >>>>>> >>>>>> May be it is more appropriate to have "headful" keyword for areas >> like >>>>>> jdk_beans and "headless" keyword for areas like jdk_awt and >> jdk_swing? >>>> This >>>>>> will allow to mark only small part of tests with necessary keyword for >> each >>>>>> area. >>>>>> >>>>> While this approach sounds desirable, I'm not aware of functionality >>>>> in jtreg which allows marking all the tests in a test group (e.g. >>>>> jdk_awt) with a special default keyword which can be override in the >>>>> test itself. >>>>> >>>>> After all, the author of a test should know best if his test requires >>>>> a headful environment or not. I think after we've gone trough the >>>>> initial pain of marking all headful test, the future development >>>>> should then be straightforward and simple. >>>>> >>>>>> In other way almost all AWT/Swing tests should be marked by >> "headful" >>>>>> keyword. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Alexandr Scherbatiy [mailto:alexandr.scherbatiy at oracle.com] >>>>>>>> Sent: Freitag, 17. Juni 2016 14:53 >>>>>>>> To: Volker Simonis >>>>>>>> Cc: Lindenmaier, Goetz ; swing- >>>>>>>> dev at openjdk.java.net; awt-dev at openjdk.java.net >>>>>>>> Subject: Re: RFR(L): 8159690: [TESTBUG] >>>> Mark >>>>>>>> headful tests with @key headful. >>>>>>>> >>>>>>>> On 6/17/2016 11:36 AM, Volker Simonis wrote: >>>>>>>>> On Thu, Jun 16, 2016 at 5:55 PM, Alexandr Scherbatiy >>>>>>>>> wrote: >>>>>>>>>> On 6/16/2016 5:40 PM, Lindenmaier, Goetz wrote: >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> we have test machines without X server. On these many of the >> jdk >>>>>>>>>> jtreg tests fail with a headless exception. >>>>>>>>>> >>>>>>>>>> We grepped for this exception in the test output and identified >>>>>>>>>> >>>>>>>>>> about 450 tests. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> In these tests, we added with another script "@key headful". >>>>>>>>>> >>>>>>>>>> What is a number of tests which passe in headless mode? >>>>>>>>>> >>>>>>>>>> I would expect that an ordinary client test which use Frame and >>>>>>>>>> fails in >>>>>>>>>> headless mode does not require a special key by default. >>>>>>>>>> >>>>>>>>> Hi Alexandr, >>>>>>>>> >>>>>>>>> I don't quite understand your concerns, but the purpose of this >>>> change >>>>>>>>> is to make it possible to simply exclude all tests which require a >>>>>>>>> "headful" environment from a jtreg run. >>>>>>>>> >>>>>>>>> There are AWT/Swing tests which can be run even without X >> server. >>>> For >>>>>>>> example: >>>>>>>>> java/awt/image/DrawImage/DrawImageCoordsTest.java >>>>>>>>> >>>>>>>>> Others, like for example: >>>>>>>>> >>>>>>>>> java/awt/image/DrawImage/EABlitTest.jtr >>>>>>>>> >>>>>>>>> will throw a Headless exception and fail: >>>>>>>>> >>>>>>>>> java.awt.HeadlessException: >>>>>>>>> No X11 DISPLAY variable was set, but this program performed an >>>>>>>>> operation which requires it. >>>>>>>>> >>>>>>>>> With Goetz's change we can simply exclude all the test which >> require >>>> a >>>>>>>>> headful environment by specifying "-keywords:\!headful" to jtreg. >>>>>>>>> After all, I think that's the purpose why the "headful" keyword has >>>>>>>>> been introduced. >>>>>>>>> >>>>>>>>> If there's any other simple way of excluding all tests which require a >>>>>>>>> headful environment, please let us now. >>>>>>>> For example, the test >>>>>>>> jdk/test/javax/swing/AbstractButton/6711682/bug6711682.java >> when >>>> it is >>>>>>>> run with -Djava.awt.headless=true option fails with exception >>>>>>>> "java.awt.AWTException: headless environment". >>>>>>>> >>>>>>>> The test is not listed in the proposed patch. Is it correct that this >>>>>>>> test requires the "headful" environment and should be marked with >>>> the >>>>>>>> "headful" keyword? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Volker >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> So that the script generates better output, I adapted the >>>>>>>>>> >>>>>>>>>> formatting of some of the test descriptions. >>>>>>>>>> >>>>>>>>>> see also the text in the webrev, where I posted some incremental >>>> diffs >>>>>>>>>> of the changes I more or less edited by hand. I hope this eases >>>>>>>>>> >>>>>>>>>> reviewing :) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Last, I updated the Copyrights with the script by Coleen. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Please review this change. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8159690- >>>> headful/webrev.01/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >> >> -- >> Best regards, Sergey. From jayathirth.d.v at oracle.com Tue Jun 21 05:43:38 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 20 Jun 2016 22:43:38 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail In-Reply-To: References: <89531a21-64b2-4e00-8f15-aa78650cf7b2@default> <574F62FA.50900@oracle.com> <1309b2bb-c189-d623-cfc5-105223718e12@oracle.com> <70565f43-7547-4047-bca3-f95ae709427e@default> <7b22a1ca-5e6a-c705-90bc-510aa2073c90@oracle.com> <1b962d5d-ae52-4281-8ca8-d6d5558e3fe5@default> <9c521f0e-1f76-420b-bf51-3495c5779b83@default> Message-ID: Hi Phil, Gentle remainder for review. Thanks, Jay -----Original Message----- From: Jim Graham Sent: Wednesday, June 15, 2016 10:01 AM To: Jayathirth D V; Phil Race Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail Hi Jay, Thanks for explaining all of the details. It seems that constantly being in scan mode simplifies things because we have to be in scan mode for entropy data anyway, but it still allows errant bytes outside of the entropy data to be accepted by this parser. I'm not sure if that is a problem in the long run, but it is not a new issue (since the existing code already was doing that) so we can live with it for purposes of fixing this particular bug. One simplification of what you say below, it appears that among all of those cases none of them really impact the fact that un-sized entropy encoded data only appears inside the SOS marker and the only markers found inside the entropy data itself are the RSTn markers. Ideally we could limit our scanning to just the data following the SOS marker and its sized header and only allow RSTn markers to appear inside that manual scan, reverting to a non-scanning mode when we reach another marker (DNL it looks like). But, that would be the subject of a different bug fix. It looks OK to me as long as Phil is OK with the types of exceptions that you are throwing in the various new exceptional cases, and with the change to now assume that skipImage always being called at an SOI marker. Phil? ...jim On 6/14/16 9:36 AM, Jayathirth D V wrote: > Hi Jim, > > I have updated the code to add check for EOF even in case of reading length. Also I have updated the code such that in all the cases where we find EOF before EOI we are throwing IndexOutOfBoundsException and in other failed cases we are throwing IOException. > > More analysis : > All the length markers that we are checking in our case have valid length data except SOS marker in which always the length value will be 12 and it is the value only for the length of Scan header. > After Scan header(SOS) we have compressed data for which we have no parameter which gives the length so that we can skip it completely. > Once we get to the initial SOS header it can take 3 paths based on how the data follows: > a) If we don't have Restart enabled and if we scan continuously through compressed data we will find EOI otherwise we will find RST markers and then EOI marker. > b) If we have multiple scan headers(Multi-scan scenario) we have to follow point 'a' in loop with each scan header separated by DNL and other miscellaneous tables. > c) If we have multiple frame headers(Multi-frame scenario) we have to follow point 'b' in loop with different markers coming in between. > Above information is taken from page 52 of > https://www.w3.org/Graphics/JPEG/itu-t81.pdf > > Since we can't rely on length specified in SOS header and there is possibility of having multiple SOS headers, we need to search for FF(foundFF). It means even if we jump for the length specified is SOS header the next byte is not promised to be '0xff'. > For all the remaining markers we will get proper information related to the length and we will skip all data part(which might contain data similar to EOI/SOI/or any other marker). While propagating through the 'for' loop we are following the same approach. > > Please find updated webrev for review : > http://cr.openjdk.java.net/~jdv/8152672/webrev.02/ > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Tuesday, June 14, 2016 12:44 AM > To: Jayathirth D V > Cc: 2d-dev at openjdk.java.net; Philip Race > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : > Exception while getting second image properties for JPEG with embedded > thumbnail > > Hi Jay, > > You still don't check the read() calls in the length case to see if you reached EOF (-1). The potential for an infinite loop is still there. > > Also, you still search for an FF, even if you require the function to start at an SOI marker - all subsequent markers are still subject to a search rather than a deterministic requirement that we encounter markers with no gaps between them. > > Why do we have the foundFF variable in the first place? If we just saw an SOI marker then the next byte *must be* a 0xff (shouldn't it? Am I missing something?). We shouldn't read a byte and check if it is a 0xff and then try again, we should expect a single 0xff byte followed by a marker type byte, as in: > > while (true) { > int byteval == iis.read(); > // if (byteval < 0) then what? > if (byteval != 0xff) { exception } > byteval = iis.read(); > switch (byteval) { > } > } > > The only question is if we get a -1 on the first read if we treat that as an implicit EOI as we do now, or if we treat it as an exception. > Note that if we get a -1 in the second read, then we have a half-formed tag and that should fall into the default and be declared a bad file. > > ...jim > > On 6/13/2016 10:00 AM, Jayathirth D V wrote: >> Hi Jim, >> >> Thanks for your valuable inputs. >> I have updated the code with your inputs: >> 1) We should check for complete SOI marker and not just "FF" at start of skipImage(). >> 2) There is no need of iis.read() which was happening in default case. iis.read() present in for loop check will take care of checking EOF. >> 3) I have added case condition for all the markers having length and added default case where we get invalid marker starting with FF. >> >> Apart from above changes, after going more through https://www.w3.org/Graphics/JPEG/itu-t81.pdf got to know following things: >> >> 1) TEM is also one more marker without length so added case for that. >> 2) Since we have all unique conditions checked, we should not find any SOI marker after the initial SOI marker before we find EOI. Made changes to throw IOException in this case. >> >> Please find updated webrev for review: >> http://cr.openjdk.java.net/~jdv/8152672/webrev.01/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Saturday, June 11, 2016 3:07 AM >> To: Jayathirth D V; Philip Race >> Cc: 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : >> Exception while getting second image properties for JPEG with >> embedded thumbnail >> >> Thanks for the response Jay, I think I was misreading some of the code as now that I look back at it, it's mostly written as I was suggesting with respect to skipping over data sections, however it is still doing some scanning to find the initial 0xFF. Some thoughts: >> >> - If we can be sure that we are located at where a tag should be, then shouldn't we just read a byte and assert that it is 0xFF and report the file as invalid if it isn't? The current code will just ignore the byte and continue reading until it finds a 0xFF, but the fact that the first byte we read isn't 0xFF means we have wandered into data that isn't following the file format (or, possibly, that this was called from a case where we hadn't completely read a section of data, but that should be fixed as we could be in the middle of a section that isn't entropy encoded and our search for 0xFF might have invalid assumptions). >> >> - The bytes read in the default section to get the length and the tag for the next block aren't tested for EOF (-1). This may even get us into an infinite loop if we hit EOF at the right time (just after a sized block tag) as the size bytes will read and combine into a -1 size, back up three bytes, and then reread the same tag and try to compute a length again which will send us back 3 bytes, etc. >> >> - default assumes that all other markers that are created will be sized, but can we assert that? Shouldn't we specifically list all known sized markers and have the default case reject the file as not being of a format that we recognize? >> >> ...jim >> >> On 6/9/2016 11:21 PM, Jayathirth D V wrote: >>> Hi Jim, >>> >>> I think the harmless byte that you are referring to will be applied only for image data(Between SOS(Start of Scan) marker and EOI). For example, any "FF" data present in Jpeg image will be represented as "FF 00". But I think application headers or comments section can contain data which will be similar to EOI,SOI or other markers(FF XX). >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Jim Graham >>> Sent: Friday, June 10, 2016 5:28 AM >>> To: Jayathirth D V; Philip Race >>> Cc: 2d-dev at openjdk.java.net >>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : >>> Exception while getting second image properties for JPEG with >>> embedded thumbnail >>> >>> It looks like JPEG files have protection for scanning for an FF and assuming it is a marker by making sure that all FF bytes that appear in data are followed by a harmless byte, so a brute force search is probably fine. But it still seems wasteful when we know we are at a tag and we know the sizes of all of the tags, we should be able to skip around the file looking for the SOI directly... >>> >>> ...jim >>> >>> On 6/2/2016 5:10 AM, Jayathirth D V wrote: >>>> Fixed typo. >>>> >>>> >>>> >>>> *From:*Jayathirth D V >>>> *Sent:* Thursday, June 02, 2016 5:08 PM >>>> *To:* Philip Race >>>> *Cc:* Jim Graham; 2d-dev at openjdk.java.net >>>> *Subject:* RE: Review Request for JDK-8152672 : Exception while >>>> getting second image properties for JPEG with embedded thumbnail >>>> >>>> >>>> >>>> Hi Phil, >>>> >>>> >>>> >>>> We have two kind of images with which we are able to reproduce the issue: >>>> >>>> 1) sample.jpg present in JBS bug(We can't use this image because it >>>> is licensed ). >>>> >>>> 2) JpegEmbedThumbnail.jpg taken using Prasanta's camera and used in >>>> webrev. >>>> >>>> >>>> >>>> _ _ >>>> >>>> _sample.jpg : _ >>>> >>>> _ _ >>>> >>>> If we do getNumImages() it will return 2. getNumImages() follows >>>> the same logic of skipping markers with length and registering SOI >>>> to get number of images. >>>> >>>> sample.jpg has markers as follows : >>>> >>>> SOI -> APP1 - > SOI -> EOI -> APP1 End -> EOI -> SOI -> EOI >>>> >>>> >>>> >>>> I have dumped first image its SOI is first one in the above list >>>> and for second image it is third one in the list. getNumImages() >>>> counts first and third SOI for number of images. But in case of >>>> skipImage() we are getting inside APP1 marker and considering its SOI. >>>> >>>> >>>> >>>> _JpegEmbedThumbnail.jpg :_ >>>> >>>> _ _ >>>> >>>> If we do getNumImages() it will return 1. >>>> >>>> JpegEmbedThumbnail.jpg has markers as follows : >>>> >>>> SOI -> APP1 -> SOI -> EOI -> APP1 End -> APP2 -> SOI -> APP2 End -> >>>> APP2 >>>> -> EOI -> APP2 End -> EOI >>>> >>>> >>>> >>>> getNumImages() counts only first SOI for number of images. But in >>>> case of skipImage() we will are getting inside APP1 and APP2 markers also. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Jay >>>> >>>> *From:*Phil Race >>>> *Sent:* Thursday, June 02, 2016 4:05 AM >>>> *To:* Jayathirth D V >>>> *Cc:* Jim Graham; 2d-dev at openjdk.java.net >>>> >>>> *Subject:* Re: Review Request for JDK-8152672 : Exception while >>>> getting second image properties for JPEG with embedded thumbnail >>>> >>>> >>>> >>>> I am bit doubtful about this. Are you sure we are correct in >>>> reporting two images to begin with ? >>>> Thumbnails should not get counted .. >>>> >>>> >>>> -phil. >>>> >>>> On 06/01/2016 01:06 AM, Jayathirth D V wrote: >>>> >>>> Updated bug title in JBS as it was misleading. >>>> >>>> >>>> >>>> *From:* Jayathirth D V >>>> *Sent:* Wednesday, June 01, 2016 12:48 PM >>>> *To:* Philip Race; Jim Graham >>>> *Cc:* 2d-dev at openjdk.java.net >>>> *Subject:* Review Request for JDK-8152672 : Exception getting >>>> thumbnail size for JPEG with embedded thumbnail >>>> >>>> >>>> >>>> Hi, >>>> >>>> >>>> >>>> _Please review the following fix in JDK9:_ >>>> >>>> >>>> >>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8152672 >>>> >>>> >>>> >>>> Webrev : http://cr.openjdk.java.net/~jdv/8152672/webrev.00/ >>>> >>>> >>>> >>>> >>>> Issue : When we are trying to get properties related to second image >>>> in JPEG file we are getting IIOException mentioning that it is not a >>>> JPEG file. >>>> >>>> >>>> >>>> Root cause : When we are skipping first image to reach second image >>>> header, we are just trying to find next available EOI marker. But if >>>> first image has embedded thumbnail in APP1 marker, we will reach to >>>> EOI of this thumbnail and not EOI of first image. So after we reach >>>> EOI of embedded thumbnail we try to access second image SOI marker >>>> which will fail. >>>> >>>> >>>> >>>> Solution : We have to change the logic of how we skip to consecutive >>>> images in JPEG file. We know that application markers, comments or >>>> other markers can contain data same as SOI & EOI. Instead of just >>>> checking for EOI marker serially, we should read length of these >>>> markers and skip them. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Jay >>>> >>>> >>>> >>>> >>>> From jayathirth.d.v at oracle.com Tue Jun 21 06:24:55 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 20 Jun 2016 23:24:55 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail In-Reply-To: References: <89531a21-64b2-4e00-8f15-aa78650cf7b2@default> <574F62FA.50900@oracle.com> <1309b2bb-c189-d623-cfc5-105223718e12@oracle.com> <70565f43-7547-4047-bca3-f95ae709427e@default> <7b22a1ca-5e6a-c705-90bc-510aa2073c90@oracle.com> <1b962d5d-ae52-4281-8ca8-d6d5558e3fe5@default> <9c521f0e-1f76-420b-bf51-3495c5779b83@default> Message-ID: <700d1da9-809e-4614-8d0f-47960c4b372f@default> Hi Phil, Gentle reminder for review. Thanks, Jay -----Original Message----- From: Jim Graham Sent: Wednesday, June 15, 2016 10:01 AM To: Jayathirth D V; Phil Race Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail Hi Jay, Thanks for explaining all of the details. It seems that constantly being in scan mode simplifies things because we have to be in scan mode for entropy data anyway, but it still allows errant bytes outside of the entropy data to be accepted by this parser. I'm not sure if that is a problem in the long run, but it is not a new issue (since the existing code already was doing that) so we can live with it for purposes of fixing this particular bug. One simplification of what you say below, it appears that among all of those cases none of them really impact the fact that un-sized entropy encoded data only appears inside the SOS marker and the only markers found inside the entropy data itself are the RSTn markers. Ideally we could limit our scanning to just the data following the SOS marker and its sized header and only allow RSTn markers to appear inside that manual scan, reverting to a non-scanning mode when we reach another marker (DNL it looks like). But, that would be the subject of a different bug fix. It looks OK to me as long as Phil is OK with the types of exceptions that you are throwing in the various new exceptional cases, and with the change to now assume that skipImage always being called at an SOI marker. Phil? ...jim On 6/14/16 9:36 AM, Jayathirth D V wrote: > Hi Jim, > > I have updated the code to add check for EOF even in case of reading length. Also I have updated the code such that in all the cases where we find EOF before EOI we are throwing IndexOutOfBoundsException and in other failed cases we are throwing IOException. > > More analysis : > All the length markers that we are checking in our case have valid length data except SOS marker in which always the length value will be 12 and it is the value only for the length of Scan header. > After Scan header(SOS) we have compressed data for which we have no parameter which gives the length so that we can skip it completely. > Once we get to the initial SOS header it can take 3 paths based on how the data follows: > a) If we don't have Restart enabled and if we scan continuously through compressed data we will find EOI otherwise we will find RST markers and then EOI marker. > b) If we have multiple scan headers(Multi-scan scenario) we have to follow point 'a' in loop with each scan header separated by DNL and other miscellaneous tables. > c) If we have multiple frame headers(Multi-frame scenario) we have to follow point 'b' in loop with different markers coming in between. > Above information is taken from page 52 of > https://www.w3.org/Graphics/JPEG/itu-t81.pdf > > Since we can't rely on length specified in SOS header and there is possibility of having multiple SOS headers, we need to search for FF(foundFF). It means even if we jump for the length specified is SOS header the next byte is not promised to be '0xff'. > For all the remaining markers we will get proper information related to the length and we will skip all data part(which might contain data similar to EOI/SOI/or any other marker). While propagating through the 'for' loop we are following the same approach. > > Please find updated webrev for review : > http://cr.openjdk.java.net/~jdv/8152672/webrev.02/ > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Tuesday, June 14, 2016 12:44 AM > To: Jayathirth D V > Cc: 2d-dev at openjdk.java.net; Philip Race > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : > Exception while getting second image properties for JPEG with embedded > thumbnail > > Hi Jay, > > You still don't check the read() calls in the length case to see if you reached EOF (-1). The potential for an infinite loop is still there. > > Also, you still search for an FF, even if you require the function to start at an SOI marker - all subsequent markers are still subject to a search rather than a deterministic requirement that we encounter markers with no gaps between them. > > Why do we have the foundFF variable in the first place? If we just saw an SOI marker then the next byte *must be* a 0xff (shouldn't it? Am I missing something?). We shouldn't read a byte and check if it is a 0xff and then try again, we should expect a single 0xff byte followed by a marker type byte, as in: > > while (true) { > int byteval == iis.read(); > // if (byteval < 0) then what? > if (byteval != 0xff) { exception } > byteval = iis.read(); > switch (byteval) { > } > } > > The only question is if we get a -1 on the first read if we treat that as an implicit EOI as we do now, or if we treat it as an exception. > Note that if we get a -1 in the second read, then we have a half-formed tag and that should fall into the default and be declared a bad file. > > ...jim > > On 6/13/2016 10:00 AM, Jayathirth D V wrote: >> Hi Jim, >> >> Thanks for your valuable inputs. >> I have updated the code with your inputs: >> 1) We should check for complete SOI marker and not just "FF" at start of skipImage(). >> 2) There is no need of iis.read() which was happening in default case. iis.read() present in for loop check will take care of checking EOF. >> 3) I have added case condition for all the markers having length and added default case where we get invalid marker starting with FF. >> >> Apart from above changes, after going more through https://www.w3.org/Graphics/JPEG/itu-t81.pdf got to know following things: >> >> 1) TEM is also one more marker without length so added case for that. >> 2) Since we have all unique conditions checked, we should not find any SOI marker after the initial SOI marker before we find EOI. Made changes to throw IOException in this case. >> >> Please find updated webrev for review: >> http://cr.openjdk.java.net/~jdv/8152672/webrev.01/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Saturday, June 11, 2016 3:07 AM >> To: Jayathirth D V; Philip Race >> Cc: 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : >> Exception while getting second image properties for JPEG with >> embedded thumbnail >> >> Thanks for the response Jay, I think I was misreading some of the code as now that I look back at it, it's mostly written as I was suggesting with respect to skipping over data sections, however it is still doing some scanning to find the initial 0xFF. Some thoughts: >> >> - If we can be sure that we are located at where a tag should be, then shouldn't we just read a byte and assert that it is 0xFF and report the file as invalid if it isn't? The current code will just ignore the byte and continue reading until it finds a 0xFF, but the fact that the first byte we read isn't 0xFF means we have wandered into data that isn't following the file format (or, possibly, that this was called from a case where we hadn't completely read a section of data, but that should be fixed as we could be in the middle of a section that isn't entropy encoded and our search for 0xFF might have invalid assumptions). >> >> - The bytes read in the default section to get the length and the tag for the next block aren't tested for EOF (-1). This may even get us into an infinite loop if we hit EOF at the right time (just after a sized block tag) as the size bytes will read and combine into a -1 size, back up three bytes, and then reread the same tag and try to compute a length again which will send us back 3 bytes, etc. >> >> - default assumes that all other markers that are created will be sized, but can we assert that? Shouldn't we specifically list all known sized markers and have the default case reject the file as not being of a format that we recognize? >> >> ...jim >> >> On 6/9/2016 11:21 PM, Jayathirth D V wrote: >>> Hi Jim, >>> >>> I think the harmless byte that you are referring to will be applied only for image data(Between SOS(Start of Scan) marker and EOI). For example, any "FF" data present in Jpeg image will be represented as "FF 00". But I think application headers or comments section can contain data which will be similar to EOI,SOI or other markers(FF XX). >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Jim Graham >>> Sent: Friday, June 10, 2016 5:28 AM >>> To: Jayathirth D V; Philip Race >>> Cc: 2d-dev at openjdk.java.net >>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : >>> Exception while getting second image properties for JPEG with >>> embedded thumbnail >>> >>> It looks like JPEG files have protection for scanning for an FF and assuming it is a marker by making sure that all FF bytes that appear in data are followed by a harmless byte, so a brute force search is probably fine. But it still seems wasteful when we know we are at a tag and we know the sizes of all of the tags, we should be able to skip around the file looking for the SOI directly... >>> >>> ...jim >>> >>> On 6/2/2016 5:10 AM, Jayathirth D V wrote: >>>> Fixed typo. >>>> >>>> >>>> >>>> *From:*Jayathirth D V >>>> *Sent:* Thursday, June 02, 2016 5:08 PM >>>> *To:* Philip Race >>>> *Cc:* Jim Graham; 2d-dev at openjdk.java.net >>>> *Subject:* RE: Review Request for JDK-8152672 : Exception while >>>> getting second image properties for JPEG with embedded thumbnail >>>> >>>> >>>> >>>> Hi Phil, >>>> >>>> >>>> >>>> We have two kind of images with which we are able to reproduce the issue: >>>> >>>> 1) sample.jpg present in JBS bug(We can't use this image because it >>>> is licensed ). >>>> >>>> 2) JpegEmbedThumbnail.jpg taken using Prasanta's camera and used in >>>> webrev. >>>> >>>> >>>> >>>> _ _ >>>> >>>> _sample.jpg : _ >>>> >>>> _ _ >>>> >>>> If we do getNumImages() it will return 2. getNumImages() follows >>>> the same logic of skipping markers with length and registering SOI >>>> to get number of images. >>>> >>>> sample.jpg has markers as follows : >>>> >>>> SOI -> APP1 - > SOI -> EOI -> APP1 End -> EOI -> SOI -> EOI >>>> >>>> >>>> >>>> I have dumped first image its SOI is first one in the above list >>>> and for second image it is third one in the list. getNumImages() >>>> counts first and third SOI for number of images. But in case of >>>> skipImage() we are getting inside APP1 marker and considering its SOI. >>>> >>>> >>>> >>>> _JpegEmbedThumbnail.jpg :_ >>>> >>>> _ _ >>>> >>>> If we do getNumImages() it will return 1. >>>> >>>> JpegEmbedThumbnail.jpg has markers as follows : >>>> >>>> SOI -> APP1 -> SOI -> EOI -> APP1 End -> APP2 -> SOI -> APP2 End -> >>>> APP2 >>>> -> EOI -> APP2 End -> EOI >>>> >>>> >>>> >>>> getNumImages() counts only first SOI for number of images. But in >>>> case of skipImage() we will are getting inside APP1 and APP2 markers also. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Jay >>>> >>>> *From:*Phil Race >>>> *Sent:* Thursday, June 02, 2016 4:05 AM >>>> *To:* Jayathirth D V >>>> *Cc:* Jim Graham; 2d-dev at openjdk.java.net >>>> >>>> *Subject:* Re: Review Request for JDK-8152672 : Exception while >>>> getting second image properties for JPEG with embedded thumbnail >>>> >>>> >>>> >>>> I am bit doubtful about this. Are you sure we are correct in >>>> reporting two images to begin with ? >>>> Thumbnails should not get counted .. >>>> >>>> >>>> -phil. >>>> >>>> On 06/01/2016 01:06 AM, Jayathirth D V wrote: >>>> >>>> Updated bug title in JBS as it was misleading. >>>> >>>> >>>> >>>> *From:* Jayathirth D V >>>> *Sent:* Wednesday, June 01, 2016 12:48 PM >>>> *To:* Philip Race; Jim Graham >>>> *Cc:* 2d-dev at openjdk.java.net >>>> *Subject:* Review Request for JDK-8152672 : Exception getting >>>> thumbnail size for JPEG with embedded thumbnail >>>> >>>> >>>> >>>> Hi, >>>> >>>> >>>> >>>> _Please review the following fix in JDK9:_ >>>> >>>> >>>> >>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8152672 >>>> >>>> >>>> >>>> Webrev : http://cr.openjdk.java.net/~jdv/8152672/webrev.00/ >>>> >>>> >>>> >>>> >>>> Issue : When we are trying to get properties related to second image >>>> in JPEG file we are getting IIOException mentioning that it is not a >>>> JPEG file. >>>> >>>> >>>> >>>> Root cause : When we are skipping first image to reach second image >>>> header, we are just trying to find next available EOI marker. But if >>>> first image has embedded thumbnail in APP1 marker, we will reach to >>>> EOI of this thumbnail and not EOI of first image. So after we reach >>>> EOI of embedded thumbnail we try to access second image SOI marker >>>> which will fail. >>>> >>>> >>>> >>>> Solution : We have to change the logic of how we skip to consecutive >>>> images in JPEG file. We know that application markers, comments or >>>> other markers can contain data same as SOI & EOI. Instead of just >>>> checking for EOI marker serially, we should read length of these >>>> markers and skip them. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Jay >>>> >>>> >>>> >>>> >>>> From goetz.lindenmaier at sap.com Tue Jun 21 06:57:52 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 21 Jun 2016 06:57:52 +0000 Subject: [OpenJDK 2D-Dev] RFR(L): 8159690: [TESTBUG] Mark headful tests with @key headful. In-Reply-To: <57684F78.3070302@oracle.com> References: <906afad52c284df2bc8a509e00007912@DEWDFE13DE09.global.corp.sap> <791258f1-0e1a-9b09-7021-816137e1146b@oracle.com> <67f94b06-23fb-a280-f706-20808cab000e@oracle.com> <503e07b1c4c5469d8a0ed516cb5bb01c@DEWDFE13DE09.global.corp.sap> <32a8ced1-f5f5-d3e1-4834-254bcb106165@oracle.com> <726f6bd0-6463-0515-9a81-328785694b5d@oracle.com> <0682a62cf09045b5a394dbcf70cd2ebc@DEWDFE13DE09.global.corp.sap> <4e4dca16-76e4-d9fc-12f2-fad347f9e13a@oracle.com> <9cefe7d5e8c947a997d8dd4ac2286382@DEWDFE13DE09.global.corp.sap> <57684F78.3070302@oracle.com> Message-ID: Hi Phil, I'm sorry I got this wrong. I'm not that familiar with the list/repo organization on the jdk side. I'll try to do better next time. Besides the wrong processing of the change, do you have any objections to its content? I'll do a follow-up if so to get it straightened out. Best regards, Goetz. > -----Original Message----- > From: Phil Race [mailto:philip.race at oracle.com] > Sent: Montag, 20. Juni 2016 22:18 > To: Lindenmaier, Goetz > Cc: Sergey Bylokhov ; Alexandr Scherbatiy > ; Volker Simonis > ; awt-dev at openjdk.java.net; 2d-dev <2d- > dev at openjdk.java.net>; swing-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] RFR(L): 8159690: > [TESTBUG] Mark headful tests with @key headful. > > It should have been reviewed on 2d as well - I only just saw this. > But how I noticed is that as I am syncing jdk9/dev into jdk9/client > I saw hundreds (!) of client tests had been updated in the wrong forest. > Client test changes and other client changes go into 9/client unless > there is a very good reason otherwise - and it is approved by a client > group lead. > > -phil. > > On 06/17/2016 07:23 AM, Lindenmaier, Goetz wrote: > > Hi Sergey, > > > > Sorry, I pushed it just now! If you (or anybody else) has any objections > > I can revert this or do a follow-up to correct it. Please let me know. > > > > Best regards, > > Goetz. > > > > > > > >> -----Original Message----- > >> From: Sergey Bylokhov [mailto:Sergey.Bylokhov at oracle.com] > >> Sent: Freitag, 17. Juni 2016 16:21 > >> To: Lindenmaier, Goetz ; Alexandr > Scherbatiy > >> ; Volker Simonis > >> > >> Cc: awt-dev at openjdk.java.net; swing-dev at openjdk.java.net; 2d-dev > <2d- > >> dev at openjdk.java.net> > >> Subject: Re: RFR(L): 8159690: [TESTBUG] Mark > >> headful tests with @key headful. > >> > >> I guess that 2d team should review it as well (cc) > >> > >> On 17.06.16 17:17, Lindenmaier, Goetz wrote: > >>> Hi Alexandr, > >>> > >>> Thanks for reviewing! > >>> > >>> Best regards, > >>> Goetz. > >>> > >>>> -----Original Message----- > >>>> From: Alexandr Scherbatiy [mailto:alexandr.scherbatiy at oracle.com] > >>>> Sent: Freitag, 17. Juni 2016 16:04 > >>>> To: Volker Simonis > >>>> Cc: Lindenmaier, Goetz ; swing- > >>>> dev at openjdk.java.net; awt-dev at openjdk.java.net > >>>> Subject: Re: RFR(L): 8159690: [TESTBUG] > Mark > >>>> headful tests with @key headful. > >>>> > >>>> > >>>> The change looks good to me. > >>>> > >>>> Thanks, > >>>> Alexandr. > >>>> > >>>> On 6/17/2016 4:54 PM, Volker Simonis wrote: > >>>>> On Fri, Jun 17, 2016 at 3:40 PM, Alexandr Scherbatiy > >>>>> wrote: > >>>>>> On 6/17/2016 4:17 PM, Lindenmaier, Goetz wrote: > >>>>>>> Hi Alexandr, > >>>>>>> > >>>>>>> yes, you are right, the test you mention is missing in this change. > >>>>>>> There are others, too, and we still have lots of failures for other > >>>>>>> reasons. > >>>>>>> > >>>>>>> We are currently working on getting all the tests green in > >>>>>>> our test environment where we test linuxppc64, linuxppc64le > >>>>>>> and aixppc64 (and, for reference, the Oracle platforms). > >>>>>>> So I will address all the remaining issues at some point. > >>>>>>> > >>>>>>> If you basically agree on this change, I would appreciate if we > >>>>>>> could push this one and I make a follow up change. Handling > >>>>>>> changes with this many files is a pain point. But I can also > >>>>>>> extend this change so that we get all of them at once. > >>>>>> As I see there are areas like jdk_beans or jdk_imageio which > usually > >>>> does > >>>>>> not require headful environment and jdk_awt or jdk_swing which > >> usually > >>>>>> requires it. It seems that ordinary AWT/Swing tests require the > >> "headful" > >>>>>> keyword. > >>>>>> > >>>>>> May be it is more appropriate to have "headful" keyword for areas > >> like > >>>>>> jdk_beans and "headless" keyword for areas like jdk_awt and > >> jdk_swing? > >>>> This > >>>>>> will allow to mark only small part of tests with necessary keyword for > >> each > >>>>>> area. > >>>>>> > >>>>> While this approach sounds desirable, I'm not aware of functionality > >>>>> in jtreg which allows marking all the tests in a test group (e.g. > >>>>> jdk_awt) with a special default keyword which can be override in the > >>>>> test itself. > >>>>> > >>>>> After all, the author of a test should know best if his test requires > >>>>> a headful environment or not. I think after we've gone trough the > >>>>> initial pain of marking all headful test, the future development > >>>>> should then be straightforward and simple. > >>>>> > >>>>>> In other way almost all AWT/Swing tests should be marked by > >> "headful" > >>>>>> keyword. > >>>>>> > >>>>>> Thanks, > >>>>>> Alexandr. > >>>>>> > >>>>>> > >>>>>>> Best regards, > >>>>>>> Goetz. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Alexandr Scherbatiy > [mailto:alexandr.scherbatiy at oracle.com] > >>>>>>>> Sent: Freitag, 17. Juni 2016 14:53 > >>>>>>>> To: Volker Simonis > >>>>>>>> Cc: Lindenmaier, Goetz ; swing- > >>>>>>>> dev at openjdk.java.net; awt-dev at openjdk.java.net > >>>>>>>> Subject: Re: RFR(L): 8159690: [TESTBUG] > >>>> Mark > >>>>>>>> headful tests with @key headful. > >>>>>>>> > >>>>>>>> On 6/17/2016 11:36 AM, Volker Simonis wrote: > >>>>>>>>> On Thu, Jun 16, 2016 at 5:55 PM, Alexandr Scherbatiy > >>>>>>>>> wrote: > >>>>>>>>>> On 6/16/2016 5:40 PM, Lindenmaier, Goetz wrote: > >>>>>>>>>> > >>>>>>>>>> Hi, > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> we have test machines without X server. On these many of the > >> jdk > >>>>>>>>>> jtreg tests fail with a headless exception. > >>>>>>>>>> > >>>>>>>>>> We grepped for this exception in the test output and identified > >>>>>>>>>> > >>>>>>>>>> about 450 tests. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> In these tests, we added with another script "@key headful". > >>>>>>>>>> > >>>>>>>>>> What is a number of tests which passe in headless mode? > >>>>>>>>>> > >>>>>>>>>> I would expect that an ordinary client test which use Frame > and > >>>>>>>>>> fails in > >>>>>>>>>> headless mode does not require a special key by default. > >>>>>>>>>> > >>>>>>>>> Hi Alexandr, > >>>>>>>>> > >>>>>>>>> I don't quite understand your concerns, but the purpose of this > >>>> change > >>>>>>>>> is to make it possible to simply exclude all tests which require a > >>>>>>>>> "headful" environment from a jtreg run. > >>>>>>>>> > >>>>>>>>> There are AWT/Swing tests which can be run even without X > >> server. > >>>> For > >>>>>>>> example: > >>>>>>>>> java/awt/image/DrawImage/DrawImageCoordsTest.java > >>>>>>>>> > >>>>>>>>> Others, like for example: > >>>>>>>>> > >>>>>>>>> java/awt/image/DrawImage/EABlitTest.jtr > >>>>>>>>> > >>>>>>>>> will throw a Headless exception and fail: > >>>>>>>>> > >>>>>>>>> java.awt.HeadlessException: > >>>>>>>>> No X11 DISPLAY variable was set, but this program performed an > >>>>>>>>> operation which requires it. > >>>>>>>>> > >>>>>>>>> With Goetz's change we can simply exclude all the test which > >> require > >>>> a > >>>>>>>>> headful environment by specifying "-keywords:\!headful" to > jtreg. > >>>>>>>>> After all, I think that's the purpose why the "headful" keyword > has > >>>>>>>>> been introduced. > >>>>>>>>> > >>>>>>>>> If there's any other simple way of excluding all tests which > require a > >>>>>>>>> headful environment, please let us now. > >>>>>>>> For example, the test > >>>>>>>> jdk/test/javax/swing/AbstractButton/6711682/bug6711682.java > >> when > >>>> it is > >>>>>>>> run with -Djava.awt.headless=true option fails with exception > >>>>>>>> "java.awt.AWTException: headless environment". > >>>>>>>> > >>>>>>>> The test is not listed in the proposed patch. Is it correct that > this > >>>>>>>> test requires the "headful" environment and should be marked > with > >>>> the > >>>>>>>> "headful" keyword? > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> Alexandr. > >>>>>>>> > >>>>>>>>> Regards, > >>>>>>>>> Volker > >>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> Alexandr. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> So that the script generates better output, I adapted the > >>>>>>>>>> > >>>>>>>>>> formatting of some of the test descriptions. > >>>>>>>>>> > >>>>>>>>>> see also the text in the webrev, where I posted some > incremental > >>>> diffs > >>>>>>>>>> of the changes I more or less edited by hand. I hope this eases > >>>>>>>>>> > >>>>>>>>>> reviewing :) > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Last, I updated the Copyrights with the script by Coleen. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Please review this change. > >>>>>>>>>> > >>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8159690- > >>>> headful/webrev.01/ > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Best regards, > >>>>>>>>>> > >>>>>>>>>> Goetz. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >> > >> -- > >> Best regards, Sergey. From bourges.laurent at gmail.com Tue Jun 21 17:45:32 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 21 Jun 2016 19:45:32 +0200 Subject: [OpenJDK 2D-Dev] RFR 8159638: Improve array caches and renderer stats in Marlin renderer In-Reply-To: References: Message-ID: Gentle reminder ... Jim, could you have a first look soon ? I am busy and will attend a conference next week, so maybe we could postpone the review in july. Laurent Le 15 juin 2016 11:10 PM, "Laurent Bourg?s" a ?crit : Hi, Please review this bug fix for the Marlin renderer to improve the array caches, its usages but also the renderer stats: bug: https://bugs.openjdk.java.net/browse/JDK-8159638 webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8159638.0/ This patch also reduces slightly the memory footprint: 1 RendererContext represents now ~ 450K (310K on-heap / 140K off-heap). Changes: - Byte/Int/Float ArrayCache removed - replaced by Clean[Byte/Int/Float]ArrayCache (zero-filled arrays) and Dirty[Byte/Int/Float]ArrayCache classes (dirty arrays). These new classes provides a Reference class that wraps the initial array and acts as a proxy to the related array cache instance (get/widen//put Array) - ArrayCache: increased bucket to 8 (larger retained memory but weakly referenced) + added CacheStats (and BucketStats) - MarlinProperties: added setiings for initial edge capacity and align array sizes to 64 (power of 2) - RendererContext: large cleanup + use a weak reference for the recycled Path2D instance - RendererStats: big refactoring to create one RendererStats instance per created RendererContext instance (thread stats) and the new RendererStatsHolder class gathers all RendererStats instances to dump them at shutdown (very small retained memory instead of keeping all RendererContext instances) Tested with current jtreg tests (+ my MapBench tests) Regards, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Tue Jun 21 20:50:22 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 21 Jun 2016 13:50:22 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail In-Reply-To: References: <89531a21-64b2-4e00-8f15-aa78650cf7b2@default> <574F62FA.50900@oracle.com> <1309b2bb-c189-d623-cfc5-105223718e12@oracle.com> <70565f43-7547-4047-bca3-f95ae709427e@default> <7b22a1ca-5e6a-c705-90bc-510aa2073c90@oracle.com> <1b962d5d-ae52-4281-8ca8-d6d5558e3fe5@default> <9c521f0e-1f76-420b-bf51-3495c5779b83@default> Message-ID: <5769A88E.9000603@oracle.com> No issues with the exceptions as such. Whilst this does make things better I still have some reservations about the result of the fix since remember the bug says "JPEG with embedded thumbnail". If I apply your patch and use the original file I get two images but neither reports any thumbnails .. using either metadata or ImageReader.getNumThumbnails(int) One image is 3968x2976, the other is 640x480 (vga resolution). This seems a little big for a thumbnail but still a lot smaller than the original and a nice size for say using on a camera display. So my suspicion is the latter is an EXIF embedded thumbnail - since it is JPEG compressed and that ideally what we should return here is one image with one thumbnail. But since we aren't properly parsing the EXIF APP1 data .. we just find it as another image using the 'brute force' method of looking for the marker sequence. I am a bit surprised though that this hasn't been a more common complaint. We now have the TIFF code so if this really is the case then a fuller fix would return this as a thumbnail. If it really is a follow-on second image in the stream then the fix would seem OK. I just want to know which we have here Then we get to the image you used in the test. Yes, this throws an exception with 8ux .. but it is a different complaint. With the original file :- Exception in thread "main" javax.imageio.IIOException: Not a JPEG file: starts with 0xff 0xff With the test file :- Exception in thread "main" javax.imageio.IIOException: Not a JPEG file: starts with 0xff 0xe2 That's an APP2 marker .. which may mean an embedded ICC Profile. The code is supposed to be able to handle that https://docs.oracle.com/javase/8/docs/api/javax/imageio/metadata/doc-files/jpeg_metadata.html#color .. so perhaps its something else but it would be nice to know this is being handled properly. Also - back to thumbnails - this one reports zero thumbnails too ! So with the test and the fix being all about embedded thumbnails it is weird that there aren't any :-) I think we need to break down the exact contents/structure of these files to be sure what we have here. -phil. On 06/14/2016 09:30 PM, Jim Graham wrote: > Hi Jay, > > Thanks for explaining all of the details. It seems that constantly > being in scan mode simplifies things because we have to be in scan > mode for entropy data anyway, but it still allows errant bytes outside > of the entropy data to be accepted by this parser. I'm not sure if > that is a problem in the long run, but it is not a new issue (since > the existing code already was doing that) so we can live with it for > purposes of fixing this particular bug. > > One simplification of what you say below, it appears that among all of > those cases none of them really impact the fact that un-sized entropy > encoded data only appears inside the SOS marker and the only markers > found inside the entropy data itself are the RSTn markers. Ideally we > could limit our scanning to just the data following the SOS marker and > its sized header and only allow RSTn markers to appear inside that > manual scan, reverting to a non-scanning mode when we reach another > marker (DNL it looks like). But, that would be the subject of a > different bug fix. > > It looks OK to me as long as Phil is OK with the types of exceptions > that you are throwing in the various new exceptional cases, and with > the change to now assume that skipImage always being called at an SOI > marker. Phil? > > ...jim > > On 6/14/16 9:36 AM, Jayathirth D V wrote: >> Hi Jim, >> >> I have updated the code to add check for EOF even in case of reading >> length. Also I have updated the code such that in all the cases where >> we find EOF before EOI we are throwing IndexOutOfBoundsException and >> in other failed cases we are throwing IOException. >> >> More analysis : >> All the length markers that we are checking in our case have >> valid length data except SOS marker in which always the length value >> will be 12 and it is the value only for the length of Scan header. >> After Scan header(SOS) we have compressed data for which we have >> no parameter which gives the length so that we can skip it completely. >> Once we get to the initial SOS header it can take 3 paths based >> on how the data follows: >> a) If we don't have Restart enabled and if we scan >> continuously through compressed data we will find EOI otherwise we >> will find RST markers and then EOI marker. >> b) If we have multiple scan headers(Multi-scan scenario) we >> have to follow point 'a' in loop with each scan header separated by >> DNL and other miscellaneous tables. >> c) If we have multiple frame headers(Multi-frame scenario) we >> have to follow point 'b' in loop with different markers coming in >> between. >> Above information is taken from page 52 of >> https://www.w3.org/Graphics/JPEG/itu-t81.pdf >> >> Since we can't rely on length specified in SOS header and there is >> possibility of having multiple SOS headers, we need to search for >> FF(foundFF). It means even if we jump for the length specified is SOS >> header the next byte is not promised to be '0xff'. >> For all the remaining markers we will get proper information related >> to the length and we will skip all data part(which might contain data >> similar to EOI/SOI/or any other marker). While propagating through >> the 'for' loop we are following the same approach. >> >> Please find updated webrev for review : >> http://cr.openjdk.java.net/~jdv/8152672/webrev.02/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Tuesday, June 14, 2016 12:44 AM >> To: Jayathirth D V >> Cc: 2d-dev at openjdk.java.net; Philip Race >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : >> Exception while getting second image properties for JPEG with >> embedded thumbnail >> >> Hi Jay, >> >> You still don't check the read() calls in the length case to see if >> you reached EOF (-1). The potential for an infinite loop is still >> there. >> >> Also, you still search for an FF, even if you require the function to >> start at an SOI marker - all subsequent markers are still subject to >> a search rather than a deterministic requirement that we encounter >> markers with no gaps between them. >> >> Why do we have the foundFF variable in the first place? If we just >> saw an SOI marker then the next byte *must be* a 0xff (shouldn't it? >> Am I missing something?). We shouldn't read a byte and check if it >> is a 0xff and then try again, we should expect a single 0xff byte >> followed by a marker type byte, as in: >> >> while (true) { >> int byteval == iis.read(); >> // if (byteval < 0) then what? >> if (byteval != 0xff) { exception } >> byteval = iis.read(); >> switch (byteval) { >> } >> } >> >> The only question is if we get a -1 on the first read if we treat >> that as an implicit EOI as we do now, or if we treat it as an exception. >> Note that if we get a -1 in the second read, then we have a >> half-formed tag and that should fall into the default and be declared >> a bad file. >> >> ...jim >> >> On 6/13/2016 10:00 AM, Jayathirth D V wrote: >>> Hi Jim, >>> >>> Thanks for your valuable inputs. >>> I have updated the code with your inputs: >>> 1) We should check for complete SOI marker and not just "FF" at >>> start of skipImage(). >>> 2) There is no need of iis.read() which was happening in default >>> case. iis.read() present in for loop check will take care of >>> checking EOF. >>> 3) I have added case condition for all the markers having length >>> and added default case where we get invalid marker starting with FF. >>> >>> Apart from above changes, after going more through >>> https://www.w3.org/Graphics/JPEG/itu-t81.pdf got to know following >>> things: >>> >>> 1) TEM is also one more marker without length so added case for >>> that. >>> 2) Since we have all unique conditions checked, we should not >>> find any SOI marker after the initial SOI marker before we find EOI. >>> Made changes to throw IOException in this case. >>> >>> Please find updated webrev for review: >>> http://cr.openjdk.java.net/~jdv/8152672/webrev.01/ >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Jim Graham >>> Sent: Saturday, June 11, 2016 3:07 AM >>> To: Jayathirth D V; Philip Race >>> Cc: 2d-dev at openjdk.java.net >>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : >>> Exception while getting second image properties for JPEG with embedded >>> thumbnail >>> >>> Thanks for the response Jay, I think I was misreading some of the >>> code as now that I look back at it, it's mostly written as I was >>> suggesting with respect to skipping over data sections, however it >>> is still doing some scanning to find the initial 0xFF. Some thoughts: >>> >>> - If we can be sure that we are located at where a tag should be, >>> then shouldn't we just read a byte and assert that it is 0xFF and >>> report the file as invalid if it isn't? The current code will just >>> ignore the byte and continue reading until it finds a 0xFF, but the >>> fact that the first byte we read isn't 0xFF means we have wandered >>> into data that isn't following the file format (or, possibly, that >>> this was called from a case where we hadn't completely read a >>> section of data, but that should be fixed as we could be in the >>> middle of a section that isn't entropy encoded and our search for >>> 0xFF might have invalid assumptions). >>> >>> - The bytes read in the default section to get the length and the >>> tag for the next block aren't tested for EOF (-1). This may even >>> get us into an infinite loop if we hit EOF at the right time (just >>> after a sized block tag) as the size bytes will read and combine >>> into a -1 size, back up three bytes, and then reread the same tag >>> and try to compute a length again which will send us back 3 bytes, etc. >>> >>> - default assumes that all other markers that are created will be >>> sized, but can we assert that? Shouldn't we specifically list all >>> known sized markers and have the default case reject the file as not >>> being of a format that we recognize? >>> >>> ...jim >>> >>> On 6/9/2016 11:21 PM, Jayathirth D V wrote: >>>> Hi Jim, >>>> >>>> I think the harmless byte that you are referring to will be applied >>>> only for image data(Between SOS(Start of Scan) marker and EOI). For >>>> example, any "FF" data present in Jpeg image will be represented as >>>> "FF 00". But I think application headers or comments section can >>>> contain data which will be similar to EOI,SOI or other markers(FF XX). >>>> >>>> Thanks, >>>> Jay >>>> >>>> -----Original Message----- >>>> From: Jim Graham >>>> Sent: Friday, June 10, 2016 5:28 AM >>>> To: Jayathirth D V; Philip Race >>>> Cc: 2d-dev at openjdk.java.net >>>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : >>>> Exception while getting second image properties for JPEG with >>>> embedded thumbnail >>>> >>>> It looks like JPEG files have protection for scanning for an FF and >>>> assuming it is a marker by making sure that all FF bytes that >>>> appear in data are followed by a harmless byte, so a brute force >>>> search is probably fine. But it still seems wasteful when we know >>>> we are at a tag and we know the sizes of all of the tags, we should >>>> be able to skip around the file looking for the SOI directly... >>>> >>>> ...jim >>>> >>>> On 6/2/2016 5:10 AM, Jayathirth D V wrote: >>>>> Fixed typo. >>>>> >>>>> >>>>> >>>>> *From:*Jayathirth D V >>>>> *Sent:* Thursday, June 02, 2016 5:08 PM >>>>> *To:* Philip Race >>>>> *Cc:* Jim Graham; 2d-dev at openjdk.java.net >>>>> *Subject:* RE: Review Request for JDK-8152672 : Exception while >>>>> getting second image properties for JPEG with embedded thumbnail >>>>> >>>>> >>>>> >>>>> Hi Phil, >>>>> >>>>> >>>>> >>>>> We have two kind of images with which we are able to reproduce the >>>>> issue: >>>>> >>>>> 1) sample.jpg present in JBS bug(We can't use this image >>>>> because it >>>>> is licensed ). >>>>> >>>>> 2) JpegEmbedThumbnail.jpg taken using Prasanta's camera and >>>>> used in >>>>> webrev. >>>>> >>>>> >>>>> >>>>> _ _ >>>>> >>>>> _sample.jpg : _ >>>>> >>>>> _ _ >>>>> >>>>> If we do getNumImages() it will return 2. getNumImages() follows the >>>>> same logic of skipping markers with length and registering SOI to >>>>> get number of images. >>>>> >>>>> sample.jpg has markers as follows : >>>>> >>>>> SOI -> APP1 - > SOI -> EOI -> APP1 End -> EOI -> SOI -> EOI >>>>> >>>>> >>>>> >>>>> I have dumped first image its SOI is first one in the above list and >>>>> for second image it is third one in the list. getNumImages() counts >>>>> first and third SOI for number of images. But in case of skipImage() >>>>> we are getting inside APP1 marker and considering its SOI. >>>>> >>>>> >>>>> >>>>> _JpegEmbedThumbnail.jpg :_ >>>>> >>>>> _ _ >>>>> >>>>> If we do getNumImages() it will return 1. >>>>> >>>>> JpegEmbedThumbnail.jpg has markers as follows : >>>>> >>>>> SOI -> APP1 -> SOI -> EOI -> APP1 End -> APP2 -> SOI -> APP2 End -> >>>>> APP2 >>>>> -> EOI -> APP2 End -> EOI >>>>> >>>>> >>>>> >>>>> getNumImages() counts only first SOI for number of images. But in >>>>> case of skipImage() we will are getting inside APP1 and APP2 >>>>> markers also. >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Jay >>>>> >>>>> *From:*Phil Race >>>>> *Sent:* Thursday, June 02, 2016 4:05 AM >>>>> *To:* Jayathirth D V >>>>> *Cc:* Jim Graham; 2d-dev at openjdk.java.net >>>>> >>>>> *Subject:* Re: Review Request for JDK-8152672 : Exception while >>>>> getting second image properties for JPEG with embedded thumbnail >>>>> >>>>> >>>>> >>>>> I am bit doubtful about this. Are you sure we are correct in >>>>> reporting two images to begin with ? >>>>> Thumbnails should not get counted .. >>>>> >>>>> >>>>> -phil. >>>>> >>>>> On 06/01/2016 01:06 AM, Jayathirth D V wrote: >>>>> >>>>> Updated bug title in JBS as it was misleading. >>>>> >>>>> >>>>> >>>>> *From:* Jayathirth D V >>>>> *Sent:* Wednesday, June 01, 2016 12:48 PM >>>>> *To:* Philip Race; Jim Graham >>>>> *Cc:* 2d-dev at openjdk.java.net >>>>> *Subject:* Review Request for JDK-8152672 : Exception getting >>>>> thumbnail size for JPEG with embedded thumbnail >>>>> >>>>> >>>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> _Please review the following fix in JDK9:_ >>>>> >>>>> >>>>> >>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8152672 >>>>> >>>>> >>>>> >>>>> Webrev : http://cr.openjdk.java.net/~jdv/8152672/webrev.00/ >>>>> >>>>> >>>>> >>>>> >>>>> Issue : When we are trying to get properties related to second >>>>> image >>>>> in JPEG file we are getting IIOException mentioning that it is >>>>> not a >>>>> JPEG file. >>>>> >>>>> >>>>> >>>>> Root cause : When we are skipping first image to reach second >>>>> image >>>>> header, we are just trying to find next available EOI marker. >>>>> But if >>>>> first image has embedded thumbnail in APP1 marker, we will >>>>> reach to >>>>> EOI of this thumbnail and not EOI of first image. So after we >>>>> reach >>>>> EOI of embedded thumbnail we try to access second image SOI >>>>> marker >>>>> which will fail. >>>>> >>>>> >>>>> >>>>> Solution : We have to change the logic of how we skip to >>>>> consecutive >>>>> images in JPEG file. We know that application markers, >>>>> comments or >>>>> other markers can contain data same as SOI & EOI. Instead of just >>>>> checking for EOI marker serially, we should read length of these >>>>> markers and skip them. >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Jay >>>>> >>>>> >>>>> >>>>> >>>>> From philip.race at oracle.com Tue Jun 21 23:32:18 2016 From: philip.race at oracle.com (Philip Race) Date: Tue, 21 Jun 2016 16:32:18 -0700 Subject: [OpenJDK 2D-Dev] Review Request: JDK-6457721: Stroke width incorrect while printing In-Reply-To: <70f0e7ac-2960-3247-9bac-5249a0da3976@oracle.com> References: <70f0e7ac-2960-3247-9bac-5249a0da3976@oracle.com> Message-ID: <5769CE82.3090005@oracle.com> For a different situation, PathGraphics does this :- if ((getTransform().getType() & ~( AffineTransform.TYPE_UNIFORM_SCALE | AffineTransform.TYPE_TRANSLATION | AffineTransform.TYPE_QUADRANT_ROTATION )) != 0) { return false; } The methods here could all be updated to apply a similar check and then I think you'd be OK for these cases - but some testing is needed to make sure GDI co-operates. Hmm .. I applied it and it helped some cases but not all when I applied a non-uniform scale. Either I did something wrong or the code we are delegating (upwards) to has a problem as well. The test needs to be expanded to handle all the cases and also the custom stroke path. Also it would be very helpful if the test displayed to the screen as well. One thing you can do to test the printed output is -Dsun.java2d.print.pipeline=raster This makes it use "on screen" loops to generate the print out as one big image. It can be a quick way to verify the printing pipelines are handling it right. -phil. On 06/07/2016 02:50 PM, Jim Graham wrote: > The calculations are still not correct. Consider a transform that > zooms Y coordinates and shrinks X coordinates, you will think that the > resulting line width is large, and it will be for horizontal lines. > But vertical lines will experience a smaller line width. > > The only real calculation to see if the point size needs to be > adjusted is one of: > > - if the direction is known, use an N-length vector perpendicular to > the direction of the path. This might work for drawLine(), but not > for drawPolygon() and draw(Shape). > > - if the direction is not known, or varies as in a polygon or path, > then you need to use computations to compute the size of the minor > axis of the ellipse produced by transforming the unit circle, which is > not an easy problem (you can look at the code in the Marlin renderer > to see how it handles this, I don't recall how it does it off-hand). > > Also, you fixed the computations of "is the line width too thin", but > there are also computations for "if it is too thin, then what is the > correct minimum line width?" that still use the old computations, but > in reverse... > > ...jim > > On 6/7/2016 4:32 AM, prasanta sadhukhan wrote: >> Fix looks good to me. But, do we not need to do the same for >> >> 209 minLineWidth = Math.max(Math.abs(minPenSize.x) >> 210 >> Math.abs(minPenSize.y)); >> >> For the test the instruction textarea is editable which needs to be made >> read-only. >> Also, if the user does not do any manual intervention, the test passes. >> The test should have provision of failing if there is no user >> interaction. I guess there is no need of using Robot class in a manual >> test, you can use sleep if it is just meant to delay main() closing. >> The test has some wildcard imports which can be changed to specific >> imports. >> >> Regards >> Prasanta >> On 6/7/2016 3:42 PM, Prahalad Kumar Narayanan wrote: >>> >>> Hello Everyone on Java2D >>> >>> >>> >>> Good day to you. >>> >>> >>> >>> Please find herewith: Webrev changes for the bug >>> >>> Bug ID : JDK-6457721 >>> >>> Bug Link : https://bugs.openjdk.java.net/browse/JDK-6457721 >>> >>> >>> >>> As per the Bug: >>> >>> 1. With rotation angle set to Graphics2D object, the printed >>> Lines, Rectangles or Shapes have incorrect stroke width >>> >>> 2. The behavior is typically noticed at a rotation of 45? >>> >>> 3. The issue is reproducible on JDK 9 and is applicable for >>> windows platform. >>> >>> >>> >>> Quick Description on Changes >>> >>> 1. Thanks to Phil for adding his detailed comments on JBS. They >>> were really helpful. >>> >>> a. Root Cause: The formula for stroke width calculation was >>> incorrect in the WPathGraphics.java code. >>> >>> >>> >>> 2. Following changes have been incorporated- >>> >>> a. Correction to the stroke width calculation. >>> >>> i. >>> As Phil suggested in his JBS comments, the logic has been modified to >>> use distance formula after being rotated by theta. >>> >>> ii. >>> Since many other places also use the same logic, correction has been >>> taken up wherever necessary >>> >>> >>> >>> b. Fallback path for Lines and Rectangles when Custom stroke >>> implementation is set. >>> >>> i. >>> It was observed that when lines or rectangles are drawn with custom >>> stroke object, the code does not print any of these shapes. >>> >>> ii. >>> A fallback logic is now provided that prints the lines and rectangles >>> as ?Shapes?. >>> >>> iii. >>> The same fallback logic is being taken up in other sections of code, >>> when GDI fails to instantiate a pen with required Attributes. >>> >>> Hence the introduced fallback will be consistent with >>> existing code. >>> >>> >>> >>> c. Manual Test Case to detect the bug and verify the fix >>> >>> i. >>> A manual jtreg test case has been provided for users to run, print and >>> verify the fix. >>> >>> >>> >>> Detailed comments have been added for changes in the code. >>> >>> Kindly review the changes at your convenience and provide your >>> suggestions. >>> >>> Webrev Link: >>> http://cr.openjdk.java.net/~pnarayanan/6457721/webrev.00/ >>> >>> >>> >>> >>> Thank you for your time in review >>> >>> Have a good day >>> >>> >>> >>> Prahalad N. >>> >>> >>> >>> >>> >>> >>> >> From prahalad.kumar.narayanan at oracle.com Wed Jun 22 06:47:00 2016 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Tue, 21 Jun 2016 23:47:00 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request: JDK-6457721: Stroke width incorrect while printing In-Reply-To: <5769CE82.3090005@oracle.com> References: <70f0e7ac-2960-3247-9bac-5249a0da3976@oracle.com> <5769CE82.3090005@oracle.com> Message-ID: Hello Phil, Jim and Prasanta Thanks for each of your time in review feedback. I will continue my inspection and revert once I 've a concrete solution. Thank you Have a good day Prahalad N. -----Original Message----- From: Philip Race Sent: Wednesday, June 22, 2016 5:02 AM To: Jim Graham Cc: prasanta sadhukhan; Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request: JDK-6457721: Stroke width incorrect while printing For a different situation, PathGraphics does this :- if ((getTransform().getType() & ~( AffineTransform.TYPE_UNIFORM_SCALE | AffineTransform.TYPE_TRANSLATION | AffineTransform.TYPE_QUADRANT_ROTATION )) != 0) { return false; } The methods here could all be updated to apply a similar check and then I think you'd be OK for these cases - but some testing is needed to make sure GDI co-operates. Hmm .. I applied it and it helped some cases but not all when I applied a non-uniform scale. Either I did something wrong or the code we are delegating (upwards) to has a problem as well. The test needs to be expanded to handle all the cases and also the custom stroke path. Also it would be very helpful if the test displayed to the screen as well. One thing you can do to test the printed output is -Dsun.java2d.print.pipeline=raster This makes it use "on screen" loops to generate the print out as one big image. It can be a quick way to verify the printing pipelines are handling it right. -phil. On 06/07/2016 02:50 PM, Jim Graham wrote: > The calculations are still not correct. Consider a transform that > zooms Y coordinates and shrinks X coordinates, you will think that the > resulting line width is large, and it will be for horizontal lines. > But vertical lines will experience a smaller line width. > > The only real calculation to see if the point size needs to be > adjusted is one of: > > - if the direction is known, use an N-length vector perpendicular to > the direction of the path. This might work for drawLine(), but not > for drawPolygon() and draw(Shape). > > - if the direction is not known, or varies as in a polygon or path, > then you need to use computations to compute the size of the minor > axis of the ellipse produced by transforming the unit circle, which is > not an easy problem (you can look at the code in the Marlin renderer > to see how it handles this, I don't recall how it does it off-hand). > > Also, you fixed the computations of "is the line width too thin", but > there are also computations for "if it is too thin, then what is the > correct minimum line width?" that still use the old computations, but > in reverse... > > ...jim > > On 6/7/2016 4:32 AM, prasanta sadhukhan wrote: >> Fix looks good to me. But, do we not need to do the same for >> >> 209 minLineWidth = Math.max(Math.abs(minPenSize.x) >> 210 >> Math.abs(minPenSize.y)); >> >> For the test the instruction textarea is editable which needs to be >> made read-only. >> Also, if the user does not do any manual intervention, the test passes. >> The test should have provision of failing if there is no user >> interaction. I guess there is no need of using Robot class in a >> manual test, you can use sleep if it is just meant to delay main() closing. >> The test has some wildcard imports which can be changed to specific >> imports. >> >> Regards >> Prasanta >> On 6/7/2016 3:42 PM, Prahalad Kumar Narayanan wrote: >>> >>> Hello Everyone on Java2D >>> >>> >>> >>> Good day to you. >>> >>> >>> >>> Please find herewith: Webrev changes for the bug >>> >>> Bug ID : JDK-6457721 >>> >>> Bug Link : https://bugs.openjdk.java.net/browse/JDK-6457721 >>> >>> >>> >>> As per the Bug: >>> >>> 1. With rotation angle set to Graphics2D object, the printed >>> Lines, Rectangles or Shapes have incorrect stroke width >>> >>> 2. The behavior is typically noticed at a rotation of 45' >>> >>> 3. The issue is reproducible on JDK 9 and is applicable for >>> windows platform. >>> >>> >>> >>> Quick Description on Changes >>> >>> 1. Thanks to Phil for adding his detailed comments on JBS. They >>> were really helpful. >>> >>> a. Root Cause: The formula for stroke width calculation was >>> incorrect in the WPathGraphics.java code. >>> >>> >>> >>> 2. Following changes have been incorporated- >>> >>> a. Correction to the stroke width calculation. >>> >>> i. >>> As Phil suggested in his JBS comments, the logic has been modified >>> to use distance formula after being rotated by theta. >>> >>> ii. >>> Since many other places also use the same logic, correction has been >>> taken up wherever necessary >>> >>> >>> >>> b. Fallback path for Lines and Rectangles when Custom stroke >>> implementation is set. >>> >>> i. >>> It was observed that when lines or rectangles are drawn with custom >>> stroke object, the code does not print any of these shapes. >>> >>> ii. >>> A fallback logic is now provided that prints the lines and >>> rectangles as 'Shapes'. >>> >>> iii. >>> The same fallback logic is being taken up in other sections of code, >>> when GDI fails to instantiate a pen with required Attributes. >>> >>> Hence the introduced fallback will be consistent with >>> existing code. >>> >>> >>> >>> c. Manual Test Case to detect the bug and verify the fix >>> >>> i. >>> A manual jtreg test case has been provided for users to run, print >>> and verify the fix. >>> >>> >>> >>> Detailed comments have been added for changes in the code. >>> >>> Kindly review the changes at your convenience and provide your >>> suggestions. >>> >>> Webrev Link: >>> http:// >>> cr.openjdk.java.net/~pnarayanan/6457721/webrev.00/ >>> >>> >>> >>> >>> Thank you for your time in review >>> >>> Have a good day >>> >>> >>> >>> Prahalad N. >>> >>> >>> >>> >>> >>> >>> >> From prahalad.kumar.narayanan at oracle.com Wed Jun 22 09:50:16 2016 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Wed, 22 Jun 2016 02:50:16 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni Message-ID: Hello Everyone, on Java2D Group Good day to you. Please find herewith, webrev changes to fix the bug- Bug ID : JDK-8152971 / -Xcheck:jni - warning in native method Bug Link : https://bugs.openjdk.java.net/browse/JDK-8152971?filter=-1 Webrev : http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.00/ Description on Bug: 1. Too many JNI warnings are reported in the native functions when test-code is run with VM Option: -Xcheck:jni 2. The warnings can be classified into 2 categories a. JNI warnings that are thrown due to the missing exception checks after an Up call ( JNI function invoking Java method ) b. JNI warnings that are thrown due to increased usage of Local Reference objects. Description on the Fix: 1. File : FontPath.c Added JNIEnv->ExceptionCheck() and ExceptionClear() where Up call is invoked. The checks are added only to the valid Up calls as per JNI spec. Added JNIEnv->DeleteLocalRef where the native functions created Java side objects but did not delete their local reference after usage. A few of the native functions get invoked as Callbacks to Windows APIs following the font enumeration. Therefore at each callback, the count of active local references would increase. Over time, the active local references would exceed the planned number of local references set by JVM. 2. File : awt_Component.cpp Added JNIEnv->ExceptionCheck() and ExceptionClear() where an Up call displayed a JNI warning while running the Jtreg test script. Information on Jtreg test script is given below. 3. File : LoadFontsJNICheck.sh The shell script is already a part of JTreg test case & invokes LoadFontsJNICheck with -Xcheck:jni VM option However, the script was configured to run only on Mac OS. Now, the script is modified to run on windows, linux and mac systems. This way, the code changes can be checked for proper execution with test-case. Kindly review the changes at your convenience and share your feedback. Thank you for your time in review Have a good day Prahalad N. From philip.race at oracle.com Wed Jun 22 15:37:33 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 22 Jun 2016 08:37:33 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6601097:Margins are not reset to hardware margins when width/height is 0 or -ve alongwith x, y In-Reply-To: <48d2a342-851a-0a79-1443-c7bf82958f7b@oracle.com> References: <5745D4BB.5040900@oracle.com> <574DBF01.5080101@oracle.com> <0703d17a-9e36-94a2-93f8-80c56d0250f3@oracle.com> <5761E7A9.1010805@oracle.com> <48d2a342-851a-0a79-1443-c7bf82958f7b@oracle.com> Message-ID: <576AB0BD.7050506@oracle.com> +1 .. they won't get any output with a zero-width imageable area but this is last ditch fix up of excessively bad values. -phil. On 6/16/16, 11:32 PM, prasanta sadhukhan wrote: > > Hi Phil, > > Ok. I have added a check for this case in which it will fall back to > default values since > if ix/iy is too large then we probably will not get anything to print > inside printable area if we have to leave same margin on the > right/bottom of the paper. > validatePaper() does not check for ix/iy too large case. > > Modified webrev > http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.03/ > > Regards > Prasanta > On 6/16/2016 5:11 AM, Philip Race wrote: >> I did say so long as the "ix/iy" are also valid. Which means not just >> positive but that they >> are not too large. Consider >> if (iw<= 0) iw = (float)(page.getPaper().getWidth()/DPI) - (ix*2); >> >> if we have ix = 500 and iw = -20 for a paper with width 800 this will >> result >> in iw = 800 - (500*2) = -200 .. >> >> -phil. >> >> On 6/8/16, 4:42 AM, prasanta sadhukhan wrote: >>> Hi Phil, >>> >>> As discussed offline, regarding mpa modification in both >>> setAttributes() and updateAttributesWithPageFormat, I found that >>> updateAttributesWithPageFormat() will be called during pageDialog() >>> and setPrintable() >>> whereas setAttributes() will be called during print() and >>> setAttributes() called validatePaper() to validate imageable values, >>> so in that regard, setAttributes() has final say in validating and >>> updating invalid mpa values. >>> >>> Regarding bug, I found that if we have -ve width/height, >>> MediaPrintable constructor throws IAE if width/height is -ve so mpa >>> values set by user will not be added to pageAttributes (even if >>> there was valid x,y mpa values) >>> therefore we fallback to Java default paper size and so we will get >>> mpa values as ix=72 iy=72 iw=451 ih=697 in validatePaper() >>> so to avoid IAE and to use user-set valid values, I have modified >>> the code to constrain iw/ih with requested ix/iy as you suggested. >>> >>> Please find the modified webrev: >>> http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.02/ >>> >>> Regards >>> Prasanta >>> On 5/31/2016 10:12 PM, Phil Race wrote: >>>> Well ... few printers can print on the entire paper. Photo printers >>>> are >>>> the ones that can do this. So Paper dimension minus the "hardware >>>> margins" >>>> are the maximum imageable width. >>>> And then supposing imageable x/y is some perfectly reasonable value >>>> like 1" each >>>> then you've set iw/ih such that even a printer with zero hardware >>>> margins has >>>> an imageable area that goes off the bottom and right off the paper. >>>> >>>> More reasonable would be to constrain iw/ih such that they work >>>> with the >>>> requested ix/iy - assuming they are also valid. >>>> >>>> If all else fails then just using the "default" set of values as if >>>> the application >>>> had not set any values would be better. >>>> >>>> -phil. >>>> >>>> On 05/26/2016 03:26 AM, prasanta sadhukhan wrote: >>>>> Hi Phil, >>>>> >>>>> I got it rectified. >>>>> >>>>> Please find the modified webrev >>>>> >>>>> http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.01/ >>>>> >>>>> Regarding using entire width/height pf paper, I thought since >>>>> imageable width/height is invalid we should make the entire paper >>>>> as the imageable area.For invalid x,y we were making it to paper's >>>>> top/left. >>>>> Else what option do we have, should we calculate >>>>> width[height]=abs(image[width][height]) instead? >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 5/25/2016 10:07 PM, Philip Race wrote: >>>>>> It seems to me that you are using the wrong units. >>>>>> You have not divided by DPI to get inches. >>>>>> >>>>>> Also I am not sure that the *entire* width/height of the paper is >>>>>> what you want here >>>>>> but that is secondary to the first issue >>>>>> >>>>>> -phil >>>>>> >>>>>> On 5/19/16, 2:59 AM, prasanta sadhukhan wrote: >>>>>>> Hi All, >>>>>>> >>>>>>> Please review a fix for jdk9 which is a continuation of the fix >>>>>>> of JDK-6543815. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6601097 >>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.00/ >>>>>>> >>>>>>> 6543815 fix resets the x,y to 0 if they are negative before >>>>>>> creating a MediaPrintableArea and the platform replaces it with >>>>>>> hardware margins when printing. >>>>>>> This works only if x/y is negative. >>>>>>> But, If either width/height is negative alongwith x or y, then >>>>>>> the margin is set to the java def 1 inch margin and not hardware >>>>>>> margins. >>>>>>> >>>>>>> This is because width/height -ve results in IAE in >>>>>>> MediaPrintableArea constructor and so values are ignored. >>>>>>> Added a check for -ve width/height to make sure width/height are >>>>>>> set to minimum paper width/height. >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>> >>>>>>> >>>>> >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajit.ghaisas at oracle.com Thu Jun 23 07:09:43 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Thu, 23 Jun 2016 00:09:43 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] Fix for JDK-8074824: Resolve disabled warnings for libawt_xawt In-Reply-To: <53656bf6-bce8-4444-8c4f-67d7cc93a522@default> References: <53656bf6-bce8-4444-8c4f-67d7cc93a522@default> Message-ID: <58fd8ac4-4520-4776-8229-a7c510eba6d6@default> Hi, Bug : https://bugs.openjdk.java.net/browse/JDK-8074824 (Resolve disabled warnings for libawt_xawt) As part of fixing this bug, I have - 1. Fixed warnings in source code after removing blanket warning suppressions from makefile. 2. In case the warning fix is not possible, converted blanket warning suppression for this library to suppression of warnings for individual files. 3. Added comments in makefile for the warning suppression that cannot be fixed. One type of gcc warning 'deprecated-declarations' will be fixed separately (as part of JDK-8160146) I have built the changes successfully on all supported platforms. Webrev : http://cr.openjdk.java.net/~aghaisas/8074824/webrev.00/ Request you to review. Regards, Ajit From prasanta.sadhukhan at oracle.com Thu Jun 23 10:40:40 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 23 Jun 2016 16:10:40 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6218397:Printing to file does not throw a PrinterException if the file cannot be created In-Reply-To: <7461a8f1-5263-a7b8-3dab-a4bd0733890b@oracle.com> References: <576180D4.9040502@oracle.com> <1209f6f2-36df-6655-c542-d3836b11ff71@oracle.com> <7461a8f1-5263-a7b8-3dab-a4bd0733890b@oracle.com> Message-ID: <576BBCA8.2080800@oracle.com> Hi Phil, All, Based on the offline discussion, I added the case when disk gets filled while writing to the file. Since PrintStream does not throw IOException, I added check for checkError() to do the corresponding error handling. I added it after flush() as that is where the stream will be written to the file. http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.03/ Regards Prasanta On 6/20/2016 12:01 PM, prasanta sadhukhan wrote: > > Hi Phil,All, > > Added file delete in another case where we throw PrinterException. > http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.02/ > > Regards > Prasanta > On 6/16/2016 1:40 PM, prasanta sadhukhan wrote: >> >> Modified webrev to close output stream. >> >> http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.01/ >> >> Regards >> Prasanta >> On 6/15/2016 9:52 PM, Philip Race wrote: >>> If this is executed on Windows (shared Postscript stream printer >>> could do this) >>> then since the output stream is still open I expect the delete will >>> fail. >>> Attempt to close the open stream first (in a try .. catch I suppose). >>> >>> -phil. >>> >>> On 6/15/16, 3:25 AM, prasanta sadhukhan wrote: >>>> >>>> Hi All, >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6218397 >>>> >>>> The issue was if the linux disk is full and we are trying to "print >>>> to file" then PrinterException is not thrown and a 0 byte file is >>>> created. >>>> >>>> Although I am not able to reproduce this behaviour, because when I >>>> make my disk full and try to run "java", I get >>>> >>>> /Java HotSpot(TM) Server VM warning: Insufficient space for shared >>>> memory file:// >>>> // 13783// >>>> //Try using the -Djava.io.tmpdir= option to select an alternate >>>> temp location./ >>>> >>>> but on investigating this, I see that we are calling >>>> f.createNewFile() in RasterPrinterJob#validateDestination() which >>>> creates a new, empty file >>>> >>>> but if there is any exception in PSPrinterJob#startDoc this file is >>>> not deleted. >>>> >>>> Modified the code to make sure if there is any exception, delete >>>> the file. >>>> >>>> http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.00/ >>>> >>>> Regards >>>> Prasanta >>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Thu Jun 23 11:04:33 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 23 Jun 2016 04:04:33 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6601097:Margins are not reset to hardware margins when width/height is 0 or -ve alongwith x, y In-Reply-To: <576AB0BD.7050506@oracle.com> References: <5745D4BB.5040900@oracle.com> <574DBF01.5080101@oracle.com> <0703d17a-9e36-94a2-93f8-80c56d0250f3@oracle.com> <5761E7A9.1010805@oracle.com> <48d2a342-851a-0a79-1443-c7bf82958f7b@oracle.com> <576AB0BD.7050506@oracle.com> Message-ID: <0864dc39-d107-468e-b24e-cceac4e38bdf@default> Hi Prasanta, ? Changes are working fine. Please convert multiple single line comments to multi-line comments both in code change in test case. In test case there are some places where lines are ending with more than 80 characters. No need for review. Please change it before check-in. ? Thanks, Jay ? From: Philip Race Sent: Wednesday, June 22, 2016 9:08 PM To: prasanta sadhukhan Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-6601097:Margins are not reset to hardware margins when width/height is 0 or -ve alongwith x, y ? +1 .. they won't get any output with a zero-width imageable area but this is last ditch fix up of excessively bad values. -phil. On 6/16/16, 11:32 PM, prasanta sadhukhan wrote: Hi Phil, Ok. I have added a check for this case in which it will fall back to default values since if ix/iy is too large then we probably will not get anything to print inside printable area if we have to leave same margin on the right/bottom of the paper. validatePaper() does not check for ix/iy too large case. Modified webrev HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/6601097/webrev.03/"http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.03/ Regards Prasanta On 6/16/2016 5:11 AM, Philip Race wrote: I did say so long as the "ix/iy" are also valid. Which means not just positive but that they are not too large. Consider if (iw <= 0) iw = (float)(page.getPaper().getWidth()/DPI) - (ix*2); if we have ix = 500 and iw = -20 for a paper with width 800 this will result in iw = 800 - (500*2) = -200 .. -phil. On 6/8/16, 4:42 AM, prasanta sadhukhan wrote: Hi Phil, As discussed offline, regarding mpa modification in both setAttributes() and updateAttributesWithPageFormat, I found that updateAttributesWithPageFormat() will be called during pageDialog() and setPrintable() whereas setAttributes() will be called during print() and setAttributes() called validatePaper() to validate imageable values, so in that regard, setAttributes() has final say in validating and updating invalid mpa values. Regarding bug, I found that if we have -ve width/height, MediaPrintable constructor throws IAE if width/height is -ve so mpa values set by user will not be added to pageAttributes (even if there was valid x,y mpa values) therefore we fallback to Java default paper size and so we will get mpa values as ix=72 iy=72 iw=451 ih=697 in validatePaper() so to avoid IAE and to use user-set valid values, I have modified the code to constrain iw/ih with requested ix/iy as you suggested. Please find the modified webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/6601097/webrev.02/"http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.02/ Regards Prasanta On 5/31/2016 10:12 PM, Phil Race wrote: Well ... few printers can print on the entire paper. Photo printers are the ones that can do this. So Paper dimension minus the "hardware margins" are the maximum imageable width. And then supposing imageable x/y is some perfectly reasonable value like 1" each then you've set iw/ih such that even a printer with zero hardware margins has an imageable area that goes off the bottom and right off the paper. More reasonable would be to constrain iw/ih such that they work with the requested ix/iy - assuming they are also valid. If all else fails then just using the "default" set of values as if the application had not set any values would be better. -phil. On 05/26/2016 03:26 AM, prasanta sadhukhan wrote: Hi Phil, I got it rectified. Please find the modified webrev HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/6601097/webrev.01/"http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.01/ Regarding using entire width/height pf paper, I thought since imageable width/height is invalid we should make the entire paper as the imageable area.For invalid x,y we were making it to paper's top/left. Else what option do we have, should we calculate width[height]=abs(image[width][height]) instead? Regards Prasanta On 5/25/2016 10:07 PM, Philip Race wrote: It seems to me that you are using the wrong units. You have not divided by DPI to get inches. Also I am not sure that the *entire* width/height of the paper is what you want here but that is secondary to the first issue -phil On 5/19/16, 2:59 AM, prasanta sadhukhan wrote: Hi All, Please review a fix for jdk9 which is a continuation of the fix of JDK-6543815. Bug: https://bugs.openjdk.java.net/browse/JDK-6601097 webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/6601097/webrev.00/"http://cr.openjdk.java.net/~psadhukhan/6601097/webrev.00/ 6543815 fix resets the x,y to 0 if they are negative before creating a MediaPrintableArea and the platform replaces it with hardware margins when printing. This works only if x/y is negative. But, If either width/height is negative alongwith x or y, then the margin is set to the java def 1 inch margin and not hardware margins. This is because width/height -ve results in IAE in MediaPrintableArea constructor and so values are ignored. Added a check for -ve width/height to make sure width/height are set to minimum paper width/height. Regards Prasanta ? ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Thu Jun 23 12:04:19 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 23 Jun 2016 15:04:19 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8160124 SunGraphics2D.hitClip() can give wrong result for floating point scale Message-ID: <7de7d230-3f62-272e-437a-ea42bd739e88@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8160124 webrev: http://cr.openjdk.java.net/~alexsch/8160124/webrev.00 Let's set the clip [x=5, y=5, width=5, height=5] to a graphics and call the hitClip() with the passed rectangle [x=0, y=0, width=5, height=5]. The result is false for the graphics with scale 1 and true if the scale is floating point 1.5. This is because the transformed clip which has floating point bounds [7.5, 7.5, 7.5, 7.5] for the scale 1.5 has bounds with rounded down upper-left and rounded up lower-right corners [7, 7, 8, 8] which now intersects with the transformed rectangle [0, 0, 7.5, 7.5]. The proposed fix adds additional check for the user clip and the user rectangle intersection if the intersection with the region clip passes. Thanks, Alexandr. From omajid at redhat.com Thu Jun 23 16:59:14 2016 From: omajid at redhat.com (Omair Majid) Date: Thu, 23 Jun 2016 12:59:14 -0400 Subject: [OpenJDK 2D-Dev] Fix integer overflow warnings in icu layout code In-Reply-To: <20160217154544.GB3900@redhat.com> References: <20160121175243.GB12309@redhat.com> <56A12DA2.7020906@oracle.com> <20160121215030.GC12309@redhat.com> <56A1612F.3010403@oracle.com> <20160127203515.GE3789@redhat.com> <20160217154544.GB3900@redhat.com> Message-ID: <20160623165913.GC3519@redhat.com> * Omair Majid [2016-02-17 10:45]: > * Omair Majid [2016-01-27 15:35]: > > Hi, > > > > * Phil Race [2016-01-21 17:55]: > > > On 01/21/2016 01:50 PM, Omair Majid wrote: > > > >That said, do you think some sort of add-and-check-for-overflow test > > > >would be suitable here? I can take a shot at implementing it, if you > > > >like. > > > > > > Sure ! (to the code change option). > > > > The following webrev implements that: > > http://cr.openjdk.java.net/~omajid/webrevs/le-signed-overflow-warnings/00/ > > > > It uses comparisons with INT32_MAX and INT32_MIN instead of performing > > an addition or subtraction on the variable itself to avoid an overflow. > > With this, I no longer get any overflow warnings. > > > > On the other hand, if you think these checks are redundant, then I would > > be happy to remove these too. > > Ping. Anyone have any comments? Just wondering if there's any interest in this or if I should throw it away. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From philip.race at oracle.com Thu Jun 23 17:46:45 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 23 Jun 2016 10:46:45 -0700 Subject: [OpenJDK 2D-Dev] [9] Review request for 8160124 SunGraphics2D.hitClip() can give wrong result for floating point scale In-Reply-To: <7de7d230-3f62-272e-437a-ea42bd739e88@oracle.com> References: <7de7d230-3f62-272e-437a-ea42bd739e88@oracle.com> Message-ID: <576C2085.6080601@oracle.com> On 06/23/2016 05:04 AM, Alexandr Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8160124 > webrev: http://cr.openjdk.java.net/~alexsch/8160124/webrev.00 > > Let's set the clip [x=5, y=5, width=5, height=5] to a graphics and > call the hitClip() with the passed rectangle [x=0, y=0, width=5, > height=5]. > > The result is false for the graphics with scale 1 and true if the > scale is floating point 1.5. > > This is because the transformed clip which has floating point bounds > [7.5, 7.5, 7.5, 7.5] You must mean the latter two as width and height of the bounding rectangle, not x2, y2. bounds would be [7.5, 7.5, 15.0, 15.0] - > for the scale 1.5 has bounds with rounded down upper-left and rounded > up lower-right corners [7, 7, 8, 8] similarly you mean the width/height would be rounded up to 8 - not the corner location. anyway .. +1 from me but this is one Jim should look at too. -phil. > which now intersects with the transformed rectangle [0, 0, 7.5, 7.5]. > > The proposed fix adds additional check for the user clip and the > user rectangle intersection if the intersection with the region clip > passes. > > Thanks, > Alexandr. > > From jayathirth.d.v at oracle.com Thu Jun 23 12:10:25 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 23 Jun 2016 05:10:25 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail In-Reply-To: <5769A88E.9000603@oracle.com> References: <89531a21-64b2-4e00-8f15-aa78650cf7b2@default> <574F62FA.50900@oracle.com> <1309b2bb-c189-d623-cfc5-105223718e12@oracle.com> <70565f43-7547-4047-bca3-f95ae709427e@default> <7b22a1ca-5e6a-c705-90bc-510aa2073c90@oracle.com> <1b962d5d-ae52-4281-8ca8-d6d5558e3fe5@default> <9c521f0e-1f76-420b-bf51-3495c5779b83@default> <5769A88E.9000603@oracle.com> Message-ID: <1b4983f1-6286-4394-8f52-788a1e6bb23b@default> Hi Phil, We have two images with which we can reproduce the issue: 1) sample.jpg - Image attached in JBS 2) JpegEmbedThumbnail.jpg - Image present in webrev. I have attached image for difference in markers if we skipbytes for length and without skipping and parsing serially for both the images. It also mentions all the markers present in both the images. Also I have attached metadata information extracted for both the images using http://www.sno.phy.queensu.ca/~phil/exiftool/ . Regarding the thumbnails : In both the images we have thumbnail inside APP1(EXIF) marker, I have extracted the thumbnails using exiftool . The information that we have of thumbnail present APP1 markers match the thumbnail information present in exiftool metadata. In JPEGMetadata.java constructor we are not parsing APP1 marker and storing it as a marker segment. That is why in both the cases we are seeing thumbnails as 0. This looks like separate issue of not considering thumbnail data present in APP1 markers. In sample.jpg the 640*480 image present after 3968*2976 image is preview image. It is stored for showing preview in Camera display and it is not EXIF embedded thumbnail. We have thumbnail data present in APP1 marker and it is of dimensions 160*120, we can extract the same using exiftool. In JpegEmbedThumbnail.jpg both main image and thumbnail are of same size 64*48(I have kept main image size to be as small as possible since it will be checked in). Regarding embedded ICC profile: JpegEmbedThumbnail.jpg has one image with embedded thumbnail in APP1 marker. It has many APP2 markers and we are parsing it for given ImageIndex using gotoImage() and readNativeHeader(). Please let me know your inputs. Thanks, Jay -----Original Message----- From: Phil Race Sent: Wednesday, June 22, 2016 2:20 AM To: Jim Graham Cc: Jayathirth D V; 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail No issues with the exceptions as such. Whilst this does make things better I still have some reservations about the result of the fix since remember the bug says "JPEG with embedded thumbnail". If I apply your patch and use the original file I get two images but neither reports any thumbnails .. using either metadata or ImageReader.getNumThumbnails(int) One image is 3968x2976, the other is 640x480 (vga resolution). This seems a little big for a thumbnail but still a lot smaller than the original and a nice size for say using on a camera display. So my suspicion is the latter is an EXIF embedded thumbnail - since it is JPEG compressed and that ideally what we should return here is one image with one thumbnail. But since we aren't properly parsing the EXIF APP1 data .. we just find it as another image using the 'brute force' method of looking for the marker sequence. I am a bit surprised though that this hasn't been a more common complaint. We now have the TIFF code so if this really is the case then a fuller fix would return this as a thumbnail. If it really is a follow-on second image in the stream then the fix would seem OK. I just want to know which we have here Then we get to the image you used in the test. Yes, this throws an exception with 8ux .. but it is a different complaint. With the original file :- Exception in thread "main" javax.imageio.IIOException: Not a JPEG file: starts with 0xff 0xff With the test file :- Exception in thread "main" javax.imageio.IIOException: Not a JPEG file: starts with 0xff 0xe2 That's an APP2 marker .. which may mean an embedded ICC Profile. The code is supposed to be able to handle that https://docs.oracle.com/javase/8/docs/api/javax/imageio/metadata/doc-files/jpeg_metadata.html#color .. so perhaps its something else but it would be nice to know this is being handled properly. Also - back to thumbnails - this one reports zero thumbnails too ! So with the test and the fix being all about embedded thumbnails it is weird that there aren't any :-) I think we need to break down the exact contents/structure of these files to be sure what we have here. -phil. On 06/14/2016 09:30 PM, Jim Graham wrote: > Hi Jay, > > Thanks for explaining all of the details. It seems that constantly > being in scan mode simplifies things because we have to be in scan > mode for entropy data anyway, but it still allows errant bytes outside > of the entropy data to be accepted by this parser. I'm not sure if > that is a problem in the long run, but it is not a new issue (since > the existing code already was doing that) so we can live with it for > purposes of fixing this particular bug. > > One simplification of what you say below, it appears that among all of > those cases none of them really impact the fact that un-sized entropy > encoded data only appears inside the SOS marker and the only markers > found inside the entropy data itself are the RSTn markers. Ideally we > could limit our scanning to just the data following the SOS marker and > its sized header and only allow RSTn markers to appear inside that > manual scan, reverting to a non-scanning mode when we reach another > marker (DNL it looks like). But, that would be the subject of a > different bug fix. > > It looks OK to me as long as Phil is OK with the types of exceptions > that you are throwing in the various new exceptional cases, and with > the change to now assume that skipImage always being called at an SOI > marker. Phil? > > ...jim > > On 6/14/16 9:36 AM, Jayathirth D V wrote: >> Hi Jim, >> >> I have updated the code to add check for EOF even in case of reading >> length. Also I have updated the code such that in all the cases where >> we find EOF before EOI we are throwing IndexOutOfBoundsException and >> in other failed cases we are throwing IOException. >> >> More analysis : >> All the length markers that we are checking in our case have >> valid length data except SOS marker in which always the length value >> will be 12 and it is the value only for the length of Scan header. >> After Scan header(SOS) we have compressed data for which we have >> no parameter which gives the length so that we can skip it completely. >> Once we get to the initial SOS header it can take 3 paths based >> on how the data follows: >> a) If we don't have Restart enabled and if we scan >> continuously through compressed data we will find EOI otherwise we >> will find RST markers and then EOI marker. >> b) If we have multiple scan headers(Multi-scan scenario) we >> have to follow point 'a' in loop with each scan header separated by >> DNL and other miscellaneous tables. >> c) If we have multiple frame headers(Multi-frame scenario) we >> have to follow point 'b' in loop with different markers coming in >> between. >> Above information is taken from page 52 of >> https://www.w3.org/Graphics/JPEG/itu-t81.pdf >> >> Since we can't rely on length specified in SOS header and there is >> possibility of having multiple SOS headers, we need to search for >> FF(foundFF). It means even if we jump for the length specified is SOS >> header the next byte is not promised to be '0xff'. >> For all the remaining markers we will get proper information related >> to the length and we will skip all data part(which might contain data >> similar to EOI/SOI/or any other marker). While propagating through >> the 'for' loop we are following the same approach. >> >> Please find updated webrev for review : >> http://cr.openjdk.java.net/~jdv/8152672/webrev.02/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Tuesday, June 14, 2016 12:44 AM >> To: Jayathirth D V >> Cc: 2d-dev at openjdk.java.net; Philip Race >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : >> Exception while getting second image properties for JPEG with >> embedded thumbnail >> >> Hi Jay, >> >> You still don't check the read() calls in the length case to see if >> you reached EOF (-1). The potential for an infinite loop is still >> there. >> >> Also, you still search for an FF, even if you require the function to >> start at an SOI marker - all subsequent markers are still subject to >> a search rather than a deterministic requirement that we encounter >> markers with no gaps between them. >> >> Why do we have the foundFF variable in the first place? If we just >> saw an SOI marker then the next byte *must be* a 0xff (shouldn't it? >> Am I missing something?). We shouldn't read a byte and check if it >> is a 0xff and then try again, we should expect a single 0xff byte >> followed by a marker type byte, as in: >> >> while (true) { >> int byteval == iis.read(); >> // if (byteval < 0) then what? >> if (byteval != 0xff) { exception } >> byteval = iis.read(); >> switch (byteval) { >> } >> } >> >> The only question is if we get a -1 on the first read if we treat >> that as an implicit EOI as we do now, or if we treat it as an exception. >> Note that if we get a -1 in the second read, then we have a >> half-formed tag and that should fall into the default and be declared >> a bad file. >> >> ...jim >> >> On 6/13/2016 10:00 AM, Jayathirth D V wrote: >>> Hi Jim, >>> >>> Thanks for your valuable inputs. >>> I have updated the code with your inputs: >>> 1) We should check for complete SOI marker and not just "FF" at >>> start of skipImage(). >>> 2) There is no need of iis.read() which was happening in default >>> case. iis.read() present in for loop check will take care of >>> checking EOF. >>> 3) I have added case condition for all the markers having length >>> and added default case where we get invalid marker starting with FF. >>> >>> Apart from above changes, after going more through >>> https://www.w3.org/Graphics/JPEG/itu-t81.pdf got to know following >>> things: >>> >>> 1) TEM is also one more marker without length so added case for >>> that. >>> 2) Since we have all unique conditions checked, we should not >>> find any SOI marker after the initial SOI marker before we find EOI. >>> Made changes to throw IOException in this case. >>> >>> Please find updated webrev for review: >>> http://cr.openjdk.java.net/~jdv/8152672/webrev.01/ >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Jim Graham >>> Sent: Saturday, June 11, 2016 3:07 AM >>> To: Jayathirth D V; Philip Race >>> Cc: 2d-dev at openjdk.java.net >>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : >>> Exception while getting second image properties for JPEG with >>> embedded thumbnail >>> >>> Thanks for the response Jay, I think I was misreading some of the >>> code as now that I look back at it, it's mostly written as I was >>> suggesting with respect to skipping over data sections, however it >>> is still doing some scanning to find the initial 0xFF. Some thoughts: >>> >>> - If we can be sure that we are located at where a tag should be, >>> then shouldn't we just read a byte and assert that it is 0xFF and >>> report the file as invalid if it isn't? The current code will just >>> ignore the byte and continue reading until it finds a 0xFF, but the >>> fact that the first byte we read isn't 0xFF means we have wandered >>> into data that isn't following the file format (or, possibly, that >>> this was called from a case where we hadn't completely read a >>> section of data, but that should be fixed as we could be in the >>> middle of a section that isn't entropy encoded and our search for >>> 0xFF might have invalid assumptions). >>> >>> - The bytes read in the default section to get the length and the >>> tag for the next block aren't tested for EOF (-1). This may even >>> get us into an infinite loop if we hit EOF at the right time (just >>> after a sized block tag) as the size bytes will read and combine >>> into a -1 size, back up three bytes, and then reread the same tag >>> and try to compute a length again which will send us back 3 bytes, etc. >>> >>> - default assumes that all other markers that are created will be >>> sized, but can we assert that? Shouldn't we specifically list all >>> known sized markers and have the default case reject the file as not >>> being of a format that we recognize? >>> >>> ...jim >>> >>> On 6/9/2016 11:21 PM, Jayathirth D V wrote: >>>> Hi Jim, >>>> >>>> I think the harmless byte that you are referring to will be applied >>>> only for image data(Between SOS(Start of Scan) marker and EOI). For >>>> example, any "FF" data present in Jpeg image will be represented as >>>> "FF 00". But I think application headers or comments section can >>>> contain data which will be similar to EOI,SOI or other markers(FF XX). >>>> >>>> Thanks, >>>> Jay >>>> >>>> -----Original Message----- >>>> From: Jim Graham >>>> Sent: Friday, June 10, 2016 5:28 AM >>>> To: Jayathirth D V; Philip Race >>>> Cc: 2d-dev at openjdk.java.net >>>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : >>>> Exception while getting second image properties for JPEG with >>>> embedded thumbnail >>>> >>>> It looks like JPEG files have protection for scanning for an FF and >>>> assuming it is a marker by making sure that all FF bytes that >>>> appear in data are followed by a harmless byte, so a brute force >>>> search is probably fine. But it still seems wasteful when we know >>>> we are at a tag and we know the sizes of all of the tags, we should >>>> be able to skip around the file looking for the SOI directly... >>>> >>>> ...jim >>>> >>>> On 6/2/2016 5:10 AM, Jayathirth D V wrote: >>>>> Fixed typo. >>>>> >>>>> >>>>> >>>>> *From:*Jayathirth D V >>>>> *Sent:* Thursday, June 02, 2016 5:08 PM >>>>> *To:* Philip Race >>>>> *Cc:* Jim Graham; 2d-dev at openjdk.java.net >>>>> *Subject:* RE: Review Request for JDK-8152672 : Exception while >>>>> getting second image properties for JPEG with embedded thumbnail >>>>> >>>>> >>>>> >>>>> Hi Phil, >>>>> >>>>> >>>>> >>>>> We have two kind of images with which we are able to reproduce the >>>>> issue: >>>>> >>>>> 1) sample.jpg present in JBS bug(We can't use this image >>>>> because it >>>>> is licensed ). >>>>> >>>>> 2) JpegEmbedThumbnail.jpg taken using Prasanta's camera and >>>>> used in >>>>> webrev. >>>>> >>>>> >>>>> >>>>> _ _ >>>>> >>>>> _sample.jpg : _ >>>>> >>>>> _ _ >>>>> >>>>> If we do getNumImages() it will return 2. getNumImages() follows >>>>> the same logic of skipping markers with length and registering SOI >>>>> to get number of images. >>>>> >>>>> sample.jpg has markers as follows : >>>>> >>>>> SOI -> APP1 - > SOI -> EOI -> APP1 End -> EOI -> SOI -> EOI >>>>> >>>>> >>>>> >>>>> I have dumped first image its SOI is first one in the above list >>>>> and for second image it is third one in the list. getNumImages() >>>>> counts first and third SOI for number of images. But in case of >>>>> skipImage() we are getting inside APP1 marker and considering its SOI. >>>>> >>>>> >>>>> >>>>> _JpegEmbedThumbnail.jpg :_ >>>>> >>>>> _ _ >>>>> >>>>> If we do getNumImages() it will return 1. >>>>> >>>>> JpegEmbedThumbnail.jpg has markers as follows : >>>>> >>>>> SOI -> APP1 -> SOI -> EOI -> APP1 End -> APP2 -> SOI -> APP2 End >>>>> -> >>>>> APP2 >>>>> -> EOI -> APP2 End -> EOI >>>>> >>>>> >>>>> >>>>> getNumImages() counts only first SOI for number of images. But in >>>>> case of skipImage() we will are getting inside APP1 and APP2 >>>>> markers also. >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Jay >>>>> >>>>> *From:*Phil Race >>>>> *Sent:* Thursday, June 02, 2016 4:05 AM >>>>> *To:* Jayathirth D V >>>>> *Cc:* Jim Graham; 2d-dev at openjdk.java.net >>>>> >>>>> *Subject:* Re: Review Request for JDK-8152672 : Exception while >>>>> getting second image properties for JPEG with embedded thumbnail >>>>> >>>>> >>>>> >>>>> I am bit doubtful about this. Are you sure we are correct in >>>>> reporting two images to begin with ? >>>>> Thumbnails should not get counted .. >>>>> >>>>> >>>>> -phil. >>>>> >>>>> On 06/01/2016 01:06 AM, Jayathirth D V wrote: >>>>> >>>>> Updated bug title in JBS as it was misleading. >>>>> >>>>> >>>>> >>>>> *From:* Jayathirth D V >>>>> *Sent:* Wednesday, June 01, 2016 12:48 PM >>>>> *To:* Philip Race; Jim Graham >>>>> *Cc:* 2d-dev at openjdk.java.net >>>>> *Subject:* Review Request for JDK-8152672 : Exception getting >>>>> thumbnail size for JPEG with embedded thumbnail >>>>> >>>>> >>>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> _Please review the following fix in JDK9:_ >>>>> >>>>> >>>>> >>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8152672 >>>>> >>>>> >>>>> >>>>> Webrev : http://cr.openjdk.java.net/~jdv/8152672/webrev.00/ >>>>> >>>>> >>>>> >>>>> >>>>> Issue : When we are trying to get properties related to second >>>>> image >>>>> in JPEG file we are getting IIOException mentioning that it is >>>>> not a >>>>> JPEG file. >>>>> >>>>> >>>>> >>>>> Root cause : When we are skipping first image to reach second >>>>> image >>>>> header, we are just trying to find next available EOI marker. >>>>> But if >>>>> first image has embedded thumbnail in APP1 marker, we will >>>>> reach to >>>>> EOI of this thumbnail and not EOI of first image. So after we >>>>> reach >>>>> EOI of embedded thumbnail we try to access second image SOI >>>>> marker >>>>> which will fail. >>>>> >>>>> >>>>> >>>>> Solution : We have to change the logic of how we skip to >>>>> consecutive >>>>> images in JPEG file. We know that application markers, >>>>> comments or >>>>> other markers can contain data same as SOI & EOI. Instead of just >>>>> checking for EOI marker serially, we should read length of these >>>>> markers and skip them. >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Jay >>>>> >>>>> >>>>> >>>>> >>>>> -------------- next part -------------- A non-text attachment was scrubbed... Name: sample_Diff.JPG Type: image/jpeg Size: 151081 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: JpegEmbedThumbnail_Diff.JPG Type: image/jpeg Size: 240646 bytes Desc: not available URL: -------------- next part -------------- ExifTool Version Number : 10.05 File Name : JpegEmbedThumbnailSmall.jpg Directory : . File Size : 129 kB File Modification Date/Time : 2016:05:31 20:38:41+05:30 File Access Date/Time : 2016:06:23 14:20:01+05:30 File Creation Date/Time : 2016:06:23 14:20:01+05:30 File Permissions : rw-rw-rw- File Type : JPEG File Type Extension : jpg MIME Type : image/jpeg JFIF Version : 1.01 Exif Byte Order : Big-endian (Motorola, MM) Make : EASTMAN KODAK COMPANY Camera Model Name : KODAK EASYSHARE V803 ZOOM DIGITAL CAMERA Orientation : Horizontal (normal) X Resolution : 480 Y Resolution : 480 Resolution Unit : inches Y Cb Cr Positioning : Co-sited Exposure Time : 1/60 F Number : 2.8 Exposure Program : Program AE ISO : 80 Exif Version : 0221 Date/Time Original : 2016:05:31 17:22:47 Create Date : 2016:05:31 17:22:47 Components Configuration : Y, Cb, Cr, - Shutter Speed Value : 1/64 Aperture Value : 2.8 Exposure Compensation : 0 Max Aperture Value : 2.8 Metering Mode : Multi-segment Light Source : Unknown Flash : On, Fired Focal Length : 7.5 mm Serial Number : KCTGR71350581 Warning : Invalid EXIF text encoding for UserComment User Comment : ?.?.?.?.?.........).3.=.G.Q.[.e.o.y.?.?.?.?.?.?.?.?.?.?.?.??.?..??.?..?.??.9?.$?..?..?.%?.?B..?.?!.}l.??.>?.F?..g.?..??.?y.z6.??.e?..?.??.c?.??..?.?~.?|.?{.@?.??.??.}?.??.j..?..:?..O.??.?).??.Z?.^?..?.?..?Q.??..?.?7.?...?..?.l?.??.|?.3?.??.`?.I?.??..?.)?.??.XZ.? .+?.?0.??.??.??.?f..?.??.?G..?.??.?d.?4.L..??.??..?.??.??.N?.??..?.C?..?.??.70.?c.??.?C.??.%..?E.XA....??..B.??.?e.?..F?.??.??.??.??.F?.??.7?..?.??.??.??.??.T..??....??.x?.?f. ?.?f. ?. ?.??.??.??.??.L?.,?.?l.d..??.?Q.?*.|..??.0?.l?.0?.0?.??.l?.N????..Q0.?a.^?.??.2?..~.Sd.?F.:'.????4?????????.?Q?.???m??? ???.??????..uC.?k.-?.??.??.??.?y.BW.?-.m..G?.?.???.?????????.???????.?,??..QF.j?.v?..%.?T. w.?}.?n..H.?..G?.?~.JF.7..??????v???????.?:???.?{???????$??..?8.?F.?=.?..?...???.???w???q???@?????????????????.?T?\?.???...,..B8.?D.&:.t..??-?`?????.????????}?z3x?y?xqx.z?|[?P?.???.?O..?..?%.?D.FU..H.?%.??F???????.?A?????`?.}?{?}????q?.???.???...W".m#.?G.??.??.D?.??.?C.?..x?????n???r?????K?n?????.???3?s?V?s?&>.?v..?.??.??.??.??.\?.?K.?..??n?m?n???????:?h?v?0???????.?(?.??...e..?.j?.3..E&.?$.??..?.?s.h<.|..????????????????O???????H???????.%.$n.&?.??.(..?H.JY.?B.??..?.?w.?-.???????????r?D?????7?-?v?^??????..?].??.??.C?.?1.@@.\%.N?.9?.?l.?).J?N???x?y?g?p?#?A?}?K?T?????.?H?l..?T.Ir.??.??.?..N..{?.6?.E?.Rc.R-.????C???y???.?=?????>???>?????????V?<...>.?V.._.?[.#K.h).?..??&?.?U?????K??.?|?x?y.{m|?|'{?|?}??4???...h%.?E.?V..\.?K.?0./..x?????'???[?t?.???`?.??..?.?.????}B??????).i\.?{.??.{?.z.?X.?2.t...?.???K???????r???P?,?"? ???.?.? Flashpix Version : 0100 Color Space : sRGB Exif Image Width : 1280 Exif Image Height : 960 Interoperability Index : R98 - DCF basic file (sRGB) Interoperability Version : 0100 Exposure Index : 80 Sensing Method : One-chip color area File Source : Digital Camera Scene Type : Directly photographed Custom Rendered : Normal Exposure Mode : Auto White Balance : Auto Digital Zoom Ratio : 1 Focal Length In 35mm Format : 36 mm Scene Capture Type : Standard Gain Control : None Contrast : Normal Saturation : Normal Sharpness : Hard Subject Distance Range : Unknown Offset Schema : 12 Compression : JPEG (old-style) Thumbnail Offset : 24534 Thumbnail Length : 872 Code Page : Unicode UTF-16, little endian Used Extension Numbers : 1 Extension Name : Screen nail Extension Class ID : 10000230-6FC0-11D0-BD01-00609719A180 Extension Persistence : Invalidated By Modification Extension Create Date : 2003:03:29 17:47:50 Extension Modify Date : 2003:03:29 17:47:50 Creating Application : Picoss Extension Description : Presized image for LCD Display Storage-Stream Pathname : /.Screen Nail_bd0100609719a180 Screen Nail : (Binary data 84404 bytes, use -b option to extract) Image Width : 64 Image Height : 48 Encoding Process : Baseline DCT, Huffman coding Bits Per Sample : 8 Color Components : 3 Y Cb Cr Sub Sampling : YCbCr4:2:0 (2 2) Aperture : 2.8 Image Size : 64x48 Megapixels : 0.003 Preview Image : (Binary data 84264 bytes, use -b option to extract) Scale Factor To 35 mm Equivalent: 4.8 Shutter Speed : 1/60 Thumbnail Image : (Binary data 872 bytes, use -b option to extract) Circle Of Confusion : 0.006 mm Field Of View : 53.1 deg Focal Length : 7.5 mm (35 mm equivalent: 36.0 mm) Hyperfocal Distance : 3.21 m Light Value : 9.2 -------------- next part -------------- ExifTool Version Number : 10.05 File Name : sample.jpg Directory : . File Size : 2.7 MB File Modification Date/Time : 2016:05:31 15:16:33+05:30 File Access Date/Time : 2016:06:23 14:20:01+05:30 File Creation Date/Time : 2016:06:23 14:20:01+05:30 File Permissions : rw-rw-rw- File Type : JPEG File Type Extension : jpg MIME Type : image/jpeg Exif Byte Order : Little-endian (Intel, II) Image Description : OLYMPUS DIGITAL CAMERA Make : OLYMPUS IMAGING CORP. Camera Model Name : FE3010,X895 Orientation : Horizontal (normal) X Resolution : 314 Y Resolution : 314 Resolution Unit : inches Software : Version 1.0 Modify Date : 2009:07:14 00:45:06 Y Cb Cr Positioning : Co-sited Exposure Time : 1/80 F Number : 3.5 Exposure Program : Creative (Slow speed) ISO : 100 Exif Version : 0221 Date/Time Original : 2009:07:14 00:45:06 Create Date : 2009:07:14 00:45:06 Components Configuration : Y, Cb, Cr, - Exposure Compensation : 0 Max Aperture Value : 3.1 Metering Mode : Center-weighted average Light Source : Unknown Flash : Auto, Did not fire Focal Length : 7.4 mm Special Mode : Normal, Sequence: 0, Panorama: (none) Camera ID : OLYMPUS DIGITAL CAMERA Equipment Version : 0100 Camera Type 2 : FE3010,X895 Focal Plane Diagonal : 7.56 mm Camera Settings Version : 0100 Preview Image Valid : Yes Preview Image Start : 2827914 Preview Image Length : 43959 Macro Mode : Off Flash Mode : Off White Balance 2 : Auto White Balance Bracket : 0 0 Scene Mode : Auto Drive Mode : Single Shot Panorama Mode : Off Image Processing Version : 0100 Distortion Correction 2 : Off Body Firmware Version : 1.001 User Comment : Flashpix Version : 0100 Color Space : sRGB Exif Image Width : 3968 Exif Image Height : 2976 Interoperability Index : R98 - DCF basic file (sRGB) Interoperability Version : 0100 File Source : Digital Camera Custom Rendered : Normal Exposure Mode : Auto White Balance : Auto Digital Zoom Ratio : 0 Focal Length In 35mm Format : 42 mm Scene Capture Type : Standard Gain Control : None Contrast : Normal Saturation : Normal Sharpness : Normal PrintIM Version : 0300 Compression : JPEG (old-style) Thumbnail Offset : 4592 Thumbnail Length : 8784 Image Width : 3968 Image Height : 2976 Encoding Process : Baseline DCT, Huffman coding Bits Per Sample : 8 Color Components : 3 Y Cb Cr Sub Sampling : YCbCr4:2:2 (2 1) Aperture : 3.5 Image Size : 3968x2976 Megapixels : 11.8 Preview Image : (Binary data 43959 bytes, use -b option to extract) Scale Factor To 35 mm Equivalent: 5.7 Shutter Speed : 1/80 Thumbnail Image : (Binary data 8784 bytes, use -b option to extract) Circle Of Confusion : 0.005 mm Field Of View : 46.4 deg Focal Length : 7.4 mm (35 mm equivalent: 42.0 mm) Hyperfocal Distance : 2.96 m Light Value : 9.9 From alexandr.scherbatiy at oracle.com Thu Jun 23 20:04:42 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 23 Jun 2016 23:04:42 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8158370 Text drawn with floating pointing scale can be shifted to one pixel Message-ID: <1b76b6da-674c-ab62-c253-182ae12aa869@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8158370 webrev: http://cr.openjdk.java.net/~alexsch/8158370/webrev.00 Char advance in user space is calculated with float precision. That leads that summed up char advances in user space can have small rounding error. To draw a substring of a text as selected it needs to draw the selected text from the string location plus the preceding text width. The selected text location is close to an integer value for an integer scale: (textX + sum(charAdvanceInDevSpave/scale) + transformTranslate) * scale // both textX and transformTranslate have integer value The situation is different for floating point scales. Now (textX + transformTranslate) * scale can be a floating point value like N.5 where N is some integer value. The sum(charAdvanceInDevSpave/scale) * scale is close to an integer. Sum of these values can be M.499.. which is rounded to M or M.500.. which is rounded to M+1. Because of this a selected text can be shifted to one pixel left from the required position. The proposed fix rounds the text coordinates to the closest half integer value if it is necessary in dev space. Thanks, Alexandr. From james.graham at oracle.com Thu Jun 23 22:00:04 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 23 Jun 2016 15:00:04 -0700 Subject: [OpenJDK 2D-Dev] [9] Review request for 8160124 SunGraphics2D.hitClip() can give wrong result for floating point scale In-Reply-To: <7de7d230-3f62-272e-437a-ea42bd739e88@oracle.com> References: <7de7d230-3f62-272e-437a-ea42bd739e88@oracle.com> Message-ID: Since "return true" would be a compliant implementation of Graphics.hitClip(), this is not a bug... Read the documentation, it is allowed to use fast math that can return true when technically the answer is false... ...jim On 6/23/16 5:04 AM, Alexandr Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8160124 > webrev: http://cr.openjdk.java.net/~alexsch/8160124/webrev.00 > > Let's set the clip [x=5, y=5, width=5, height=5] to a graphics and call the hitClip() with the passed rectangle [x=0, > y=0, width=5, height=5]. > > The result is false for the graphics with scale 1 and true if the scale is floating point 1.5. > > This is because the transformed clip which has floating point bounds [7.5, 7.5, 7.5, 7.5] for the scale 1.5 has bounds > with rounded down upper-left and rounded up lower-right corners [7, 7, 8, 8] which now intersects with the transformed > rectangle [0, 0, 7.5, 7.5]. > > The proposed fix adds additional check for the user clip and the user rectangle intersection if the intersection with > the region clip passes. > > Thanks, > Alexandr. > > From philip.race at oracle.com Thu Jun 23 22:14:34 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 23 Jun 2016 15:14:34 -0700 Subject: [OpenJDK 2D-Dev] [9] Review request for 8160124 SunGraphics2D.hitClip() can give wrong result for floating point scale In-Reply-To: References: <7de7d230-3f62-272e-437a-ea42bd739e88@oracle.com> Message-ID: So .. question to Alexandr : JComponent.paintChildren() is the only place in the JDK that consumes this API. Is this causing a particular problem with Swing hi-dpi - other than repainting in cases that maybe didn't need it ? -phil. On 6/23/2016 3:00 PM, Jim Graham wrote: > Since "return true" would be a compliant implementation of > Graphics.hitClip(), this is not a bug... > > Read the documentation, it is allowed to use fast math that can return > true when technically the answer is false... > > ...jim > > On 6/23/16 5:04 AM, Alexandr Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8160124 >> webrev: http://cr.openjdk.java.net/~alexsch/8160124/webrev.00 >> >> Let's set the clip [x=5, y=5, width=5, height=5] to a graphics and >> call the hitClip() with the passed rectangle [x=0, >> y=0, width=5, height=5]. >> >> The result is false for the graphics with scale 1 and true if the >> scale is floating point 1.5. >> >> This is because the transformed clip which has floating point >> bounds [7.5, 7.5, 7.5, 7.5] for the scale 1.5 has bounds >> with rounded down upper-left and rounded up lower-right corners [7, >> 7, 8, 8] which now intersects with the transformed >> rectangle [0, 0, 7.5, 7.5]. >> >> The proposed fix adds additional check for the user clip and the >> user rectangle intersection if the intersection with >> the region clip passes. >> >> Thanks, >> Alexandr. >> >> From james.graham at oracle.com Thu Jun 23 22:14:54 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 23 Jun 2016 15:14:54 -0700 Subject: [OpenJDK 2D-Dev] [9] Review request for 8160124 SunGraphics2D.hitClip() can give wrong result for floating point scale In-Reply-To: References: <7de7d230-3f62-272e-437a-ea42bd739e88@oracle.com> Message-ID: <5e4a062a-a552-85c2-d6af-9c21b3616278@oracle.com> Think of this method as asking: I don't want you to waste a lot of time, but tell me if it is silly for me to even consider rendering something with these bounds. And the answer is either "Oh, yeah, it is inconceivable that those bounds would be rendered", or "Not sure, maybe, just render it and see". There may be some cases where it knows "I know for sure that lots of stuff will render through the clip", but that is not where the divining line is here in terms of when the answer becomes true - it becomes true when there is a chance that it might render something. Arguably, the user-space comparison against the user-space clip that you added here can never be accurate even if you allow for "false positives". The clip is rasterized and whole pixels are chosen based on various criteria that affect clip rasterization. Thus, while the theoretical clip is at N.5, our rasterization choice has us render anything that hits pixel N, even if the contribution of the rendered primitive is only for the first half of N. That pixel might be rendered if anything hits any part of it, depending on what rendering operation is being done. So, your "fix" actually breaks the functionality because it is quite possible that something with a bounding box that stops before N.5 might affect pixel N and cause it to be rendered even though your new answer suggested that it wouldn't happen. Your code might actually cause a bug, not fix one. (There are also some potential theoretical failures related to how AA and STROKE_CONTROL might perturb our rendering, effects which are ignore by the current implementation of hitClip(), however I believe that all of those effects fit within the current implementation - it's just that I don't think anyone has ever proven this, or written an exhaustive test suite to verify that none of our rendering hints can perturb rendering by enough to create some surprises here...) ...jim On 6/23/16 3:00 PM, Jim Graham wrote: > Since "return true" would be a compliant implementation of Graphics.hitClip(), this is not a bug... > > Read the documentation, it is allowed to use fast math that can return true when technically the answer is false... > > ...jim > > On 6/23/16 5:04 AM, Alexandr Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8160124 >> webrev: http://cr.openjdk.java.net/~alexsch/8160124/webrev.00 >> >> Let's set the clip [x=5, y=5, width=5, height=5] to a graphics and call the hitClip() with the passed rectangle [x=0, >> y=0, width=5, height=5]. >> >> The result is false for the graphics with scale 1 and true if the scale is floating point 1.5. >> >> This is because the transformed clip which has floating point bounds [7.5, 7.5, 7.5, 7.5] for the scale 1.5 has bounds >> with rounded down upper-left and rounded up lower-right corners [7, 7, 8, 8] which now intersects with the transformed >> rectangle [0, 0, 7.5, 7.5]. >> >> The proposed fix adds additional check for the user clip and the user rectangle intersection if the intersection with >> the region clip passes. >> >> Thanks, >> Alexandr. >> >> From james.graham at oracle.com Thu Jun 23 22:32:35 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 23 Jun 2016 15:32:35 -0700 Subject: [OpenJDK 2D-Dev] [9] Review request for 8160124 SunGraphics2D.hitClip() can give wrong result for floating point scale In-Reply-To: References: <7de7d230-3f62-272e-437a-ea42bd739e88@oracle.com> Message-ID: I suspect the answer is that as long as Swing/AWT use APIs that have integer coordinates, there will be cases where this hit testing might be able to know the answer in floating point coordinates, but lose the ability to answer accurately when everything is turned into integers - which often involves ceil/floor operations that expand bounding boxes. In the case of 150% rendering for Windows, sometimes you can't accurately describe the pixels you will be rendering with enough precision in integer coordinates... ...jim On 6/23/16 3:14 PM, Phil Race wrote: > So .. question to Alexandr : > JComponent.paintChildren() is the only place in the JDK that consumes this API. > Is this causing a particular problem with Swing hi-dpi - other than repainting in cases that maybe didn't need it ? > > -phil. > > > > On 6/23/2016 3:00 PM, Jim Graham wrote: >> Since "return true" would be a compliant implementation of Graphics.hitClip(), this is not a bug... >> >> Read the documentation, it is allowed to use fast math that can return true when technically the answer is false... >> >> ...jim >> >> On 6/23/16 5:04 AM, Alexandr Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the fix: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8160124 >>> webrev: http://cr.openjdk.java.net/~alexsch/8160124/webrev.00 >>> >>> Let's set the clip [x=5, y=5, width=5, height=5] to a graphics and call the hitClip() with the passed rectangle [x=0, >>> y=0, width=5, height=5]. >>> >>> The result is false for the graphics with scale 1 and true if the scale is floating point 1.5. >>> >>> This is because the transformed clip which has floating point bounds [7.5, 7.5, 7.5, 7.5] for the scale 1.5 has bounds >>> with rounded down upper-left and rounded up lower-right corners [7, 7, 8, 8] which now intersects with the transformed >>> rectangle [0, 0, 7.5, 7.5]. >>> >>> The proposed fix adds additional check for the user clip and the user rectangle intersection if the intersection with >>> the region clip passes. >>> >>> Thanks, >>> Alexandr. >>> >>> > From alexandr.scherbatiy at oracle.com Fri Jun 24 09:01:03 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Fri, 24 Jun 2016 12:01:03 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8160124 SunGraphics2D.hitClip() can give wrong result for floating point scale In-Reply-To: References: <7de7d230-3f62-272e-437a-ea42bd739e88@oracle.com> Message-ID: On 6/24/2016 1:14 AM, Phil Race wrote: > So .. question to Alexandr : > JComponent.paintChildren() is the only place in the JDK that consumes > this API. > Is this causing a particular problem with Swing hi-dpi - other than > repainting in cases that maybe didn't need it ? This is used, for example, for internal frames dragging. An internal frame is just copied as a whole image so only small areas near the internal frame should be repainted. The current case where hit hitClip() fails for scale 1.5 causes whole internal frame repainting on Windows with 150% scale. Swing can implement its own clip intersection algorithm for this special case. I can close the JDK-8160124 as not an issue. Thanks, Alexandr. > > -phil. > > > > On 6/23/2016 3:00 PM, Jim Graham wrote: >> Since "return true" would be a compliant implementation of >> Graphics.hitClip(), this is not a bug... >> >> Read the documentation, it is allowed to use fast math that can >> return true when technically the answer is false... >> >> ...jim >> >> On 6/23/16 5:04 AM, Alexandr Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the fix: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8160124 >>> webrev: http://cr.openjdk.java.net/~alexsch/8160124/webrev.00 >>> >>> Let's set the clip [x=5, y=5, width=5, height=5] to a graphics and >>> call the hitClip() with the passed rectangle [x=0, >>> y=0, width=5, height=5]. >>> >>> The result is false for the graphics with scale 1 and true if the >>> scale is floating point 1.5. >>> >>> This is because the transformed clip which has floating point >>> bounds [7.5, 7.5, 7.5, 7.5] for the scale 1.5 has bounds >>> with rounded down upper-left and rounded up lower-right corners [7, >>> 7, 8, 8] which now intersects with the transformed >>> rectangle [0, 0, 7.5, 7.5]. >>> >>> The proposed fix adds additional check for the user clip and the >>> user rectangle intersection if the intersection with >>> the region clip passes. >>> >>> Thanks, >>> Alexandr. >>> >>> > From prahalad.kumar.narayanan at oracle.com Fri Jun 24 14:04:16 2016 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Fri, 24 Jun 2016 07:04:16 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni In-Reply-To: References: Message-ID: <2c20f37e-7eae-499c-9a70-bb3dd06da636@default> Hello Everyone on Java2D Forum Good day to you. A Quick follow-up on webrev to fix the following issue Bug ID : JDK-8152971 / -Xcheck:jni - warning in native method Bug Link : https://bugs.openjdk.java.net/browse/JDK-8152971?filter=-1 Updated webrev link: http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.01/ Description on Changes . The previous webrev contained changes to additional files which are not related to the current bug in concern. . Henceforth, the updated webrev limits the changes to only fontpath.c and a Jtreg test script to verify the change. Regarding Build & Test . Though the changes pertain to windows specific code, internal build system was triggered to ensure safe build on all supported platforms. . In addition, no new Jtreg failures were found with the proposed changes. Kindly review the changes at your convenience & provide your feedback. Thank you for your time in review Have a good day Prahalad N. -----Original Message----- From: Prahalad Kumar Narayanan Sent: Wednesday, June 22, 2016 3:20 PM To: 2d-dev at openjdk.java.net Cc: Philip Race; Prasanta Sadhukhan; Jayathirth D V; Praveen Srivastava Subject: [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni Hello Everyone, on Java2D Group Good day to you. Please find herewith, webrev changes to fix the bug- Bug ID : JDK-8152971 / -Xcheck:jni - warning in native method Bug Link : https://bugs.openjdk.java.net/browse/JDK-8152971?filter=-1 Webrev : http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.00/ Description on Bug: 1. Too many JNI warnings are reported in the native functions when test-code is run with VM Option: -Xcheck:jni 2. The warnings can be classified into 2 categories a. JNI warnings that are thrown due to the missing exception checks after an Up call ( JNI function invoking Java method ) b. JNI warnings that are thrown due to increased usage of Local Reference objects. Description on the Fix: 1. File : FontPath.c Added JNIEnv->ExceptionCheck() and ExceptionClear() where Up call is invoked. The checks are added only to the valid Up calls as per JNI spec. Added JNIEnv->DeleteLocalRef where the native functions created Java side objects but did not delete their local reference after usage. A few of the native functions get invoked as Callbacks to Windows APIs following the font enumeration. Therefore at each callback, the count of active local references would increase. Over time, the active local references would exceed the planned number of local references set by JVM. 2. File : awt_Component.cpp Added JNIEnv->ExceptionCheck() and ExceptionClear() where an Up call displayed a JNI warning while running the Jtreg test script. Information on Jtreg test script is given below. 3. File : LoadFontsJNICheck.sh The shell script is already a part of JTreg test case & invokes LoadFontsJNICheck with -Xcheck:jni VM option However, the script was configured to run only on Mac OS. Now, the script is modified to run on windows, linux and mac systems. This way, the code changes can be checked for proper execution with test-case. Kindly review the changes at your convenience and share your feedback. Thank you for your time in review Have a good day Prahalad N. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Fri Jun 24 17:34:13 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Fri, 24 Jun 2016 10:34:13 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8153943 : In PixelInterLeavedSampleModel and BandedSampleModel we dont need hashCode() method Message-ID: Hi, Please find following changes for review in JDK9 : Bug : https://bugs.openjdk.java.net/browse/JDK-8153943 Webrev : http://cr.openjdk.java.net/~jdv/8153943/webrev.03/ Issue : We have hashCode() method in PixelInterleavedSampleModel and BandedSampleModel, but we don't have corresponding equals() method. Solution : In PixelInterleavedSampleModel and BandedSampleModel we don't have unique properties that are specific to these subclasses and we have proper equals() & hashCode() method in parent class ComponentSampleModel. So removed hashCode() method present in PixelInterleavedSampleModel and BandedSampleModel. Thanks, Jay -----Original Message----- From: Jim Graham Sent: Wednesday, May 04, 2016 2:44 AM To: Phil Race Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8153943 : In java.awt.image package some of the classes are missing hashCode() or equals() method Yes, the equals/hashcode chapter in Effective Java includes rules about ignoring fields that can be calculated from other fields (which applies to most internal fields). Basically, only things in the constructors tend to be good candidates for equals/hashcode... ...jim On 5/3/2016 2:00 PM, Phil Race wrote: > On 04/26/2016 04:10 PM, Jim Graham wrote: >> The ComponentColorModel implementation is a meaningless wrapper >> around super.equals/hashCode(). Why does it not test CCM-specific fields? > > It should although this looks like it is more than just running > through all the fields and testing them for equality. > eg it looks like "initScale()" should be called if necessary before > determining equality and the field "needScaleInit" is not one that has > to be directly included in the equality comparison. > > -phil. > > > >> >> The ComponentSampleModel.hashCode() method should be upgraded based >> on the recommendations in Effective Java like the other methods here. >> >> PixelInterleavedSampleModel and BandedSampleModel also have a >> meaningless override of super.equals/hashCode(). >> >> And all of these classes suffer from casting to the specific type >> before verifying its class as I mentioned in the ICM.equals() review... >> >> ...jim >> >> On 4/25/16 2:31 AM, Jayathirth D V wrote: >>> Hi Jim, >>> >>> I have made changes to include check for class equality in base >>> class and use super.equals() from subclasses. >>> Please find updated webrev for review : >>> http://cr.openjdk.java.net/~jdv/8153943/webrev.02/ >>> >>> Change related to ColorModel is present in JDK-7107905 review. >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Jim Graham >>> Sent: Saturday, April 23, 2016 7:30 AM >>> To: Phil Race; Jayathirth D V >>> Cc: 2d-dev at openjdk.java.net >>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8153943 : In >>> java.awt.image package some of the classes are missing hashCode() or >>> equals() method >>> >>> This is actually a pretty nasty issue that Joe Darcy also brought up >>> in the CCC review. >>> >>> In order to have symmetric testing of .equals(), we pretty much have >>> to enforce this test at all levels, including in the original >>> ColorModels.equals() method. If we don't enforce this in >>> CM.equals(), then we could run ccm.equals(othercm) and it would >>> return false because the class is wrong, but turning it around and >>> testing >>> othercm.equals(ccm) would succeed because it doesn't enforce the >>> class equality. >>> >>> So, I'd recommend that CM.equals() tests getClass() == getClass() at >>> the base level and then all others will use super.equals() and get >>> the same protection. It means you can't have a subclass of CCM be >>> "equals" to a different subclass of CCM, but that's an unfortunate >>> issue with equals needing to honor symmetry... :( >>> >>> ...jim >>> >>> On 4/20/2016 10:17 AM, Phil Race wrote: >>>> Hi, You removed the following test in CCM.java : 2941 if >>>> (obj.getClass() != getClass()) { >>>> 2942 return false; >>>> >>>> 2943 } >>>> >>>> What this means is that before your change an instance of a >>>> subclass of CCM would never be equals() to any direct >>>> instantiatation of CCM but after your change it can be. I suspect >>>> the condition was there on purpose. >>>> >>>> -phil. >>>> >>>> On 04/20/2016 05:45 AM, Jayathirth D V wrote: >>>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> _Please review the following fix in JDK9:_ >>>>> >>>>> >>>>> >>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8153943 >>>>> >>>>> >>>>> >>>>> This is subtask of >>>>> https://bugs.openjdk.java.net/browse/JDK-6588409 >>>>> >>>>> >>>>> >>>>> Webrev : http://cr.openjdk.java.net/~jdv/8153943/webrev.00/ >>>>> >>>>> >>>>> >>>>> >>>>> Issue : Some of the java.awt.image classes are missing either >>>>> equals() or hashCode() method. >>>>> >>>>> >>>>> >>>>> Solution : Add missing equals() or hashCode() methods. >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Jay >>>>> >>>>> >>>>> >>>> > From yasuenag at gmail.com Sat Jun 25 13:40:56 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 25 Jun 2016 22:40:56 +0900 Subject: [OpenJDK 2D-Dev] RFR: JDK-8160294: Some client libraries cannot be bult with GCC 6 Message-ID: Hi all, This review request relates to [1]. Some client libraries could not be built with misleading-indentation and shift-negative-value warning (error) on GCC 6.1.1 . So I think we have to fix new warnings. However, some libraries (LCMS, JPEG library) are imported from another open source project. So we should avoid compile error with suppressing them. I uploaded a webrev. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8160294/webrev.00/ Thanks, Yasumasa [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004494.html From philip.race at oracle.com Sat Jun 25 15:40:30 2016 From: philip.race at oracle.com (Philip Race) Date: Sat, 25 Jun 2016 08:40:30 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8160294: Some client libraries cannot be bult with GCC 6 In-Reply-To: References: Message-ID: <576EA5EE.3020209@oracle.com> Could you share all warning messages that you received ? Adding them to the bug report is probably best. I feel much better reviewing these kinds of changes when I can see for myself what the issue is. -phil. On 6/25/16, 6:40 AM, Yasumasa Suenaga wrote: > Hi all, > > This review request relates to [1]. > > Some client libraries could not be built with misleading-indentation > and shift-negative-value warning (error) on GCC 6.1.1 . > > So I think we have to fix new warnings. > > However, some libraries (LCMS, JPEG library) are imported from another > open source project. So we should avoid compile error with suppressing > them. > > I uploaded a webrev. > Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8160294/webrev.00/ > > > Thanks, > > Yasumasa > > > [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004494.html From philip.race at oracle.com Sat Jun 25 16:57:31 2016 From: philip.race at oracle.com (Philip Race) Date: Sat, 25 Jun 2016 09:57:31 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail In-Reply-To: <1b4983f1-6286-4394-8f52-788a1e6bb23b@default> References: <89531a21-64b2-4e00-8f15-aa78650cf7b2@default> <574F62FA.50900@oracle.com> <1309b2bb-c189-d623-cfc5-105223718e12@oracle.com> <70565f43-7547-4047-bca3-f95ae709427e@default> <7b22a1ca-5e6a-c705-90bc-510aa2073c90@oracle.com> <1b962d5d-ae52-4281-8ca8-d6d5558e3fe5@default> <9c521f0e-1f76-420b-bf51-3495c5779b83@default> <5769A88E.9000603@oracle.com> <1b4983f1-6286-4394-8f52-788a1e6bb23b@default> Message-ID: <576EB7FB.8060600@oracle.com> Hi, So my conclusion is as follows : - in both these images, there is a thumbnail but it is inside the APP1 marker and we never even see it. So the synopsis reference to "for JPEG with embedded thumbnail" is completely misleading .. wrong even. We should just delete that part from the synopsis and update the test names and description to eliminate reference to that. After that the fix should be good to go. - A follow-on bug should be filed that we do not locate thumbnails inside EXIF APP1 markers. We do not need to parse everything inside the APP1 marker to do this so it should be a moderate but not massive amount of work. - The APP2 markers appear to be FlashPix data since these follow EXIF/APP1 data and I understand they may use multiple APP2s because the marker segment has a size limit of 64K (the size is a two byte quantity). So we can ignore this. -phil. On 6/23/16, 5:10 AM, Jayathirth D V wrote: > Hi Phil, > > We have two images with which we can reproduce the issue: > 1) sample.jpg - Image attached in JBS > 2) JpegEmbedThumbnail.jpg - Image present in webrev. > > I have attached image for difference in markers if we skipbytes for length and without skipping and parsing serially for both the images. It also mentions all the markers present in both the images. > Also I have attached metadata information extracted for both the images using http://www.sno.phy.queensu.ca/~phil/exiftool/ . > > Regarding the thumbnails : > In both the images we have thumbnail inside APP1(EXIF) marker, I have extracted the thumbnails using exiftool . The information that we have of thumbnail present APP1 markers match the thumbnail information present in exiftool metadata. > > In JPEGMetadata.java constructor we are not parsing APP1 marker and storing it as a marker segment. That is why in both the cases we are seeing thumbnails as 0. This looks like separate issue of not considering thumbnail data present in APP1 markers. > > In sample.jpg the 640*480 image present after 3968*2976 image is preview image. It is stored for showing preview in Camera display and it is not EXIF embedded thumbnail. We have thumbnail data present in APP1 marker and it is of dimensions 160*120, we can extract the same using exiftool. In JpegEmbedThumbnail.jpg both main image and thumbnail are of same size 64*48(I have kept main image size to be as small as possible since it will be checked in). > > Regarding embedded ICC profile: > JpegEmbedThumbnail.jpg has one image with embedded thumbnail in APP1 marker. It has many APP2 markers and we are parsing it for given ImageIndex using gotoImage() and readNativeHeader(). > > Please let me know your inputs. > > Thanks, > Jay > > -----Original Message----- > From: Phil Race > Sent: Wednesday, June 22, 2016 2:20 AM > To: Jim Graham > Cc: Jayathirth D V; 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail > > No issues with the exceptions as such. > > Whilst this does make things better I still have some reservations about the result of the fix since remember the bug says "JPEG with embedded thumbnail". > > If I apply your patch and use the original file I get two images but neither reports any thumbnails .. using either metadata or > ImageReader.getNumThumbnails(int) > > One image is 3968x2976, the other is 640x480 (vga resolution). > This seems a little big for a thumbnail but still a lot smaller than the original and a nice size for say using on a camera display. > So my suspicion is the latter is an EXIF embedded thumbnail - since it is JPEG compressed and that ideally what we should return here is one image with one thumbnail. > > But since we aren't properly parsing the EXIF APP1 data .. we just find it as another image using the 'brute force' method of looking for the marker sequence. > I am a bit surprised though that this hasn't been a more common complaint. > > We now have the TIFF code so if this really is the case then a fuller fix would return this as a thumbnail. If it really is a follow-on second image in the stream then the fix would seem OK. I just want to know which we have here > > Then we get to the image you used in the test. Yes, this throws an exception with 8ux .. but it is a different complaint. > > With the original file :- > Exception in thread "main" javax.imageio.IIOException: Not a JPEG file: > starts with 0xff 0xff > > > With the test file :- > Exception in thread "main" javax.imageio.IIOException: Not a JPEG file: > starts with 0xff 0xe2 > > That's an APP2 marker .. which may mean an embedded ICC Profile. > The code is supposed to be able to handle that https://docs.oracle.com/javase/8/docs/api/javax/imageio/metadata/doc-files/jpeg_metadata.html#color > .. so perhaps its something else but it would be nice to know this is being handled properly. > > Also - back to thumbnails - this one reports zero thumbnails too ! > > So with the test and the fix being all about embedded thumbnails it is weird that there aren't any :-) > > I think we need to break down the exact contents/structure of these files to be sure what we have here. > > -phil. > > On 06/14/2016 09:30 PM, Jim Graham wrote: >> Hi Jay, >> >> Thanks for explaining all of the details. It seems that constantly >> being in scan mode simplifies things because we have to be in scan >> mode for entropy data anyway, but it still allows errant bytes outside >> of the entropy data to be accepted by this parser. I'm not sure if >> that is a problem in the long run, but it is not a new issue (since >> the existing code already was doing that) so we can live with it for >> purposes of fixing this particular bug. >> >> One simplification of what you say below, it appears that among all of >> those cases none of them really impact the fact that un-sized entropy >> encoded data only appears inside the SOS marker and the only markers >> found inside the entropy data itself are the RSTn markers. Ideally we >> could limit our scanning to just the data following the SOS marker and >> its sized header and only allow RSTn markers to appear inside that >> manual scan, reverting to a non-scanning mode when we reach another >> marker (DNL it looks like). But, that would be the subject of a >> different bug fix. >> >> It looks OK to me as long as Phil is OK with the types of exceptions >> that you are throwing in the various new exceptional cases, and with >> the change to now assume that skipImage always being called at an SOI >> marker. Phil? >> >> ...jim >> >> On 6/14/16 9:36 AM, Jayathirth D V wrote: >>> Hi Jim, >>> >>> I have updated the code to add check for EOF even in case of reading >>> length. Also I have updated the code such that in all the cases where >>> we find EOF before EOI we are throwing IndexOutOfBoundsException and >>> in other failed cases we are throwing IOException. >>> >>> More analysis : >>> All the length markers that we are checking in our case have >>> valid length data except SOS marker in which always the length value >>> will be 12 and it is the value only for the length of Scan header. >>> After Scan header(SOS) we have compressed data for which we have >>> no parameter which gives the length so that we can skip it completely. >>> Once we get to the initial SOS header it can take 3 paths based >>> on how the data follows: >>> a) If we don't have Restart enabled and if we scan >>> continuously through compressed data we will find EOI otherwise we >>> will find RST markers and then EOI marker. >>> b) If we have multiple scan headers(Multi-scan scenario) we >>> have to follow point 'a' in loop with each scan header separated by >>> DNL and other miscellaneous tables. >>> c) If we have multiple frame headers(Multi-frame scenario) we >>> have to follow point 'b' in loop with different markers coming in >>> between. >>> Above information is taken from page 52 of >>> https://www.w3.org/Graphics/JPEG/itu-t81.pdf >>> >>> Since we can't rely on length specified in SOS header and there is >>> possibility of having multiple SOS headers, we need to search for >>> FF(foundFF). It means even if we jump for the length specified is SOS >>> header the next byte is not promised to be '0xff'. >>> For all the remaining markers we will get proper information related >>> to the length and we will skip all data part(which might contain data >>> similar to EOI/SOI/or any other marker). While propagating through >>> the 'for' loop we are following the same approach. >>> >>> Please find updated webrev for review : >>> http://cr.openjdk.java.net/~jdv/8152672/webrev.02/ >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Jim Graham >>> Sent: Tuesday, June 14, 2016 12:44 AM >>> To: Jayathirth D V >>> Cc: 2d-dev at openjdk.java.net; Philip Race >>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : >>> Exception while getting second image properties for JPEG with >>> embedded thumbnail >>> >>> Hi Jay, >>> >>> You still don't check the read() calls in the length case to see if >>> you reached EOF (-1). The potential for an infinite loop is still >>> there. >>> >>> Also, you still search for an FF, even if you require the function to >>> start at an SOI marker - all subsequent markers are still subject to >>> a search rather than a deterministic requirement that we encounter >>> markers with no gaps between them. >>> >>> Why do we have the foundFF variable in the first place? If we just >>> saw an SOI marker then the next byte *must be* a 0xff (shouldn't it? >>> Am I missing something?). We shouldn't read a byte and check if it >>> is a 0xff and then try again, we should expect a single 0xff byte >>> followed by a marker type byte, as in: >>> >>> while (true) { >>> int byteval == iis.read(); >>> // if (byteval< 0) then what? >>> if (byteval != 0xff) { exception } >>> byteval = iis.read(); >>> switch (byteval) { >>> } >>> } >>> >>> The only question is if we get a -1 on the first read if we treat >>> that as an implicit EOI as we do now, or if we treat it as an exception. >>> Note that if we get a -1 in the second read, then we have a >>> half-formed tag and that should fall into the default and be declared >>> a bad file. >>> >>> ...jim >>> >>> On 6/13/2016 10:00 AM, Jayathirth D V wrote: >>>> Hi Jim, >>>> >>>> Thanks for your valuable inputs. >>>> I have updated the code with your inputs: >>>> 1) We should check for complete SOI marker and not just "FF" at >>>> start of skipImage(). >>>> 2) There is no need of iis.read() which was happening in default >>>> case. iis.read() present in for loop check will take care of >>>> checking EOF. >>>> 3) I have added case condition for all the markers having length >>>> and added default case where we get invalid marker starting with FF. >>>> >>>> Apart from above changes, after going more through >>>> https://www.w3.org/Graphics/JPEG/itu-t81.pdf got to know following >>>> things: >>>> >>>> 1) TEM is also one more marker without length so added case for >>>> that. >>>> 2) Since we have all unique conditions checked, we should not >>>> find any SOI marker after the initial SOI marker before we find EOI. >>>> Made changes to throw IOException in this case. >>>> >>>> Please find updated webrev for review: >>>> http://cr.openjdk.java.net/~jdv/8152672/webrev.01/ >>>> >>>> Thanks, >>>> Jay >>>> >>>> -----Original Message----- >>>> From: Jim Graham >>>> Sent: Saturday, June 11, 2016 3:07 AM >>>> To: Jayathirth D V; Philip Race >>>> Cc: 2d-dev at openjdk.java.net >>>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : >>>> Exception while getting second image properties for JPEG with >>>> embedded thumbnail >>>> >>>> Thanks for the response Jay, I think I was misreading some of the >>>> code as now that I look back at it, it's mostly written as I was >>>> suggesting with respect to skipping over data sections, however it >>>> is still doing some scanning to find the initial 0xFF. Some thoughts: >>>> >>>> - If we can be sure that we are located at where a tag should be, >>>> then shouldn't we just read a byte and assert that it is 0xFF and >>>> report the file as invalid if it isn't? The current code will just >>>> ignore the byte and continue reading until it finds a 0xFF, but the >>>> fact that the first byte we read isn't 0xFF means we have wandered >>>> into data that isn't following the file format (or, possibly, that >>>> this was called from a case where we hadn't completely read a >>>> section of data, but that should be fixed as we could be in the >>>> middle of a section that isn't entropy encoded and our search for >>>> 0xFF might have invalid assumptions). >>>> >>>> - The bytes read in the default section to get the length and the >>>> tag for the next block aren't tested for EOF (-1). This may even >>>> get us into an infinite loop if we hit EOF at the right time (just >>>> after a sized block tag) as the size bytes will read and combine >>>> into a -1 size, back up three bytes, and then reread the same tag >>>> and try to compute a length again which will send us back 3 bytes, etc. >>>> >>>> - default assumes that all other markers that are created will be >>>> sized, but can we assert that? Shouldn't we specifically list all >>>> known sized markers and have the default case reject the file as not >>>> being of a format that we recognize? >>>> >>>> ...jim >>>> >>>> On 6/9/2016 11:21 PM, Jayathirth D V wrote: >>>>> Hi Jim, >>>>> >>>>> I think the harmless byte that you are referring to will be applied >>>>> only for image data(Between SOS(Start of Scan) marker and EOI). For >>>>> example, any "FF" data present in Jpeg image will be represented as >>>>> "FF 00". But I think application headers or comments section can >>>>> contain data which will be similar to EOI,SOI or other markers(FF XX). >>>>> >>>>> Thanks, >>>>> Jay >>>>> >>>>> -----Original Message----- >>>>> From: Jim Graham >>>>> Sent: Friday, June 10, 2016 5:28 AM >>>>> To: Jayathirth D V; Philip Race >>>>> Cc: 2d-dev at openjdk.java.net >>>>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : >>>>> Exception while getting second image properties for JPEG with >>>>> embedded thumbnail >>>>> >>>>> It looks like JPEG files have protection for scanning for an FF and >>>>> assuming it is a marker by making sure that all FF bytes that >>>>> appear in data are followed by a harmless byte, so a brute force >>>>> search is probably fine. But it still seems wasteful when we know >>>>> we are at a tag and we know the sizes of all of the tags, we should >>>>> be able to skip around the file looking for the SOI directly... >>>>> >>>>> ...jim >>>>> >>>>> On 6/2/2016 5:10 AM, Jayathirth D V wrote: >>>>>> Fixed typo. >>>>>> >>>>>> >>>>>> >>>>>> *From:*Jayathirth D V >>>>>> *Sent:* Thursday, June 02, 2016 5:08 PM >>>>>> *To:* Philip Race >>>>>> *Cc:* Jim Graham; 2d-dev at openjdk.java.net >>>>>> *Subject:* RE: Review Request for JDK-8152672 : Exception while >>>>>> getting second image properties for JPEG with embedded thumbnail >>>>>> >>>>>> >>>>>> >>>>>> Hi Phil, >>>>>> >>>>>> >>>>>> >>>>>> We have two kind of images with which we are able to reproduce the >>>>>> issue: >>>>>> >>>>>> 1) sample.jpg present in JBS bug(We can't use this image >>>>>> because it >>>>>> is licensed ). >>>>>> >>>>>> 2) JpegEmbedThumbnail.jpg taken using Prasanta's camera and >>>>>> used in >>>>>> webrev. >>>>>> >>>>>> >>>>>> >>>>>> _ _ >>>>>> >>>>>> _sample.jpg : _ >>>>>> >>>>>> _ _ >>>>>> >>>>>> If we do getNumImages() it will return 2. getNumImages() follows >>>>>> the same logic of skipping markers with length and registering SOI >>>>>> to get number of images. >>>>>> >>>>>> sample.jpg has markers as follows : >>>>>> >>>>>> SOI -> APP1 -> SOI -> EOI -> APP1 End -> EOI -> SOI -> EOI >>>>>> >>>>>> >>>>>> >>>>>> I have dumped first image its SOI is first one in the above list >>>>>> and for second image it is third one in the list. getNumImages() >>>>>> counts first and third SOI for number of images. But in case of >>>>>> skipImage() we are getting inside APP1 marker and considering its SOI. >>>>>> >>>>>> >>>>>> >>>>>> _JpegEmbedThumbnail.jpg :_ >>>>>> >>>>>> _ _ >>>>>> >>>>>> If we do getNumImages() it will return 1. >>>>>> >>>>>> JpegEmbedThumbnail.jpg has markers as follows : >>>>>> >>>>>> SOI -> APP1 -> SOI -> EOI -> APP1 End -> APP2 -> SOI -> APP2 End >>>>>> -> >>>>>> APP2 >>>>>> -> EOI -> APP2 End -> EOI >>>>>> >>>>>> >>>>>> >>>>>> getNumImages() counts only first SOI for number of images. But in >>>>>> case of skipImage() we will are getting inside APP1 and APP2 >>>>>> markers also. >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jay >>>>>> >>>>>> *From:*Phil Race >>>>>> *Sent:* Thursday, June 02, 2016 4:05 AM >>>>>> *To:* Jayathirth D V >>>>>> *Cc:* Jim Graham; 2d-dev at openjdk.java.net >>>>>> >>>>>> *Subject:* Re: Review Request for JDK-8152672 : Exception while >>>>>> getting second image properties for JPEG with embedded thumbnail >>>>>> >>>>>> >>>>>> >>>>>> I am bit doubtful about this. Are you sure we are correct in >>>>>> reporting two images to begin with ? >>>>>> Thumbnails should not get counted .. >>>>>> >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 06/01/2016 01:06 AM, Jayathirth D V wrote: >>>>>> >>>>>> Updated bug title in JBS as it was misleading. >>>>>> >>>>>> >>>>>> >>>>>> *From:* Jayathirth D V >>>>>> *Sent:* Wednesday, June 01, 2016 12:48 PM >>>>>> *To:* Philip Race; Jim Graham >>>>>> *Cc:* 2d-dev at openjdk.java.net >>>>>> *Subject:* Review Request for JDK-8152672 : Exception getting >>>>>> thumbnail size for JPEG with embedded thumbnail >>>>>> >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> >>>>>> _Please review the following fix in JDK9:_ >>>>>> >>>>>> >>>>>> >>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8152672 >>>>>> >>>>>> >>>>>> >>>>>> Webrev : http://cr.openjdk.java.net/~jdv/8152672/webrev.00/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Issue : When we are trying to get properties related to second >>>>>> image >>>>>> in JPEG file we are getting IIOException mentioning that it is >>>>>> not a >>>>>> JPEG file. >>>>>> >>>>>> >>>>>> >>>>>> Root cause : When we are skipping first image to reach second >>>>>> image >>>>>> header, we are just trying to find next available EOI marker. >>>>>> But if >>>>>> first image has embedded thumbnail in APP1 marker, we will >>>>>> reach to >>>>>> EOI of this thumbnail and not EOI of first image. So after we >>>>>> reach >>>>>> EOI of embedded thumbnail we try to access second image SOI >>>>>> marker >>>>>> which will fail. >>>>>> >>>>>> >>>>>> >>>>>> Solution : We have to change the logic of how we skip to >>>>>> consecutive >>>>>> images in JPEG file. We know that application markers, >>>>>> comments or >>>>>> other markers can contain data same as SOI& EOI. Instead of just >>>>>> checking for EOI marker serially, we should read length of these >>>>>> markers and skip them. >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jay >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Sun Jun 26 02:14:43 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sun, 26 Jun 2016 11:14:43 +0900 Subject: [OpenJDK 2D-Dev] RFR: JDK-8160294: Some client libraries cannot be bult with GCC 6 In-Reply-To: <576EA5EE.3020209@oracle.com> References: <576EA5EE.3020209@oracle.com> Message-ID: <549987ed-d80d-3ab0-ad2d-b135331eb80b@gmail.com> Hi Phil, I've added all warning (error) messages to JIRA. Could you review them? https://bugs.openjdk.java.net/browse/JDK-8160294 Thanks, Yasumasa On 2016/06/26 0:40, Philip Race wrote: > > Could you share all warning messages that you received ? > Adding them to the bug report is probably best. > I feel much better reviewing these kinds of changes when > I can see for myself what the issue is. > > -phil. > > On 6/25/16, 6:40 AM, Yasumasa Suenaga wrote: >> Hi all, >> >> This review request relates to [1]. >> >> Some client libraries could not be built with misleading-indentation >> and shift-negative-value warning (error) on GCC 6.1.1 . >> >> So I think we have to fix new warnings. >> >> However, some libraries (LCMS, JPEG library) are imported from another >> open source project. So we should avoid compile error with suppressing >> them. >> >> I uploaded a webrev. >> Could you review it? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8160294/webrev.00/ >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004494.html From prasanta.sadhukhan at oracle.com Mon Jun 27 06:20:36 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 27 Jun 2016 11:50:36 +0530 Subject: [OpenJDK 2D-Dev] [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni In-Reply-To: <2c20f37e-7eae-499c-9a70-bb3dd06da636@default> References: <2c20f37e-7eae-499c-9a70-bb3dd06da636@default> Message-ID: <5770C5B4.9090600@oracle.com> I guess this method(s) should take "fontStrLC" instead of "fontStr" 650 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, 651 fontStr, fileStr); 692 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, 693 fontStr, fileStr); 762 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, 763 fontStr, fileStr); 805 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, 806 fontStr, fileStr); It seems this line is not needed as we have not populated fmi structure yet. 882 releaseGdiFontMapReferences(env, &fmi); Why aren't we deleting fmi->env,fmi.arrayListCtr,fmi.addMID,fmi.putMID in releaseGdiFontMapReferences()? Also, it seems earlier the testscript was supposed to execute only on Mac but now you are extending the execution platform to windows and linux as well excluding only solaris. Is there any particular need to restrict solaris too? Regards Prasanta On 6/24/2016 7:34 PM, Prahalad Kumar Narayanan wrote: > RE: [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni > > Hello Everyoneon Java2D Forum > > Good day to you. > > A Quick follow-up on webrev to fix the following issue > > Bug ID : JDK-8152971 / -Xcheck:jni - warning in native method > > Bug Link : > https://bugs.openjdk.java.net/browse/JDK-8152971?filter=-1 > > Updated webrev > link:_http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.01/_ > > Description on Changes > > .The previous webrevcontained changes > toadditionalfileswhicharenot related to the current bug in concern. > > . Henceforth, the updated webrev limits the changes to only > fontpath.c and a Jtreg test script to verify the change. > > RegardingBuild & Test > > .Though the changes pertain to windows specific code,internal > buildsystemwastriggeredto ensure safe build on all supportedplatforms. > > .In addition,no new Jtreg failureswere found withthe proposed > changes. > > Kindly review the changes at your convenience & provide your feedback. > > Thank you for your time in review > > Have a good day > > Prahalad N. > > -----Original Message----- > From: Prahalad Kumar Narayanan > Sent: Wednesday, June 22, 2016 3:20 PM > To: 2d-dev at openjdk.java.net > Cc: Philip Race; Prasanta Sadhukhan; Jayathirth D V; Praveen Srivastava > Subject: [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni > > Hello Everyone, on Java2D Group > > Good day to you. > > Please find herewith, webrev changes to fix the bug- > > Bug ID : JDK-8152971 / -Xcheck:jni - warning in native method > > Bug Link :https://bugs.openjdk.java.net/browse/JDK-8152971?filter=-1 > > Webrev > :http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.00/ > > Description on Bug: > > 1. Too many JNI warnings are reported in the native functions > when test-code is run with VM Option: -Xcheck:jni > > 2. The warnings can be classified into 2 categories > > a. JNI warnings that are thrown due to the missing exception checks > after an Up call ( JNI function invoking Java method ) > > b. JNI warnings that are thrown due to increased usage of Local > Reference objects. > > Description on the Fix: > > 1. File : FontPath.c > > Added JNIEnv->ExceptionCheck() and ExceptionClear() where Up call is > invoked. > > The checks are added only to the valid Up calls as per JNI spec. > > Added JNIEnv->DeleteLocalRef where the native functions created Java > side objects but did not delete their local reference after usage. > > A few of the native functions get invoked as Callbacks to Windows APIs > following the font enumeration. > > Therefore at each callback, the count of active local references would > increase. > > Over time, the active local references would exceed the planned number > of local references set by JVM. > > 2. File : awt_Component.cpp > > Added JNIEnv->ExceptionCheck() and ExceptionClear() where an Up call > displayed a JNI warning while running the Jtreg test script. > > Information on Jtreg test script is given below. > > 3. File : LoadFontsJNICheck.sh > > The shell script is already a part of JTreg test case & invokes > LoadFontsJNICheck with -Xcheck:jni VM option > > However, the script was configured to run only on Mac OS. Now, the > script is modified to run on windows, linux and mac systems. > > This way, the code changes can be checked for proper execution with > test-case. > > Kindly review the changes at your convenience and share your feedback. > > Thank you for your time in review > > Have a good day > > Prahalad N. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Mon Jun 27 07:38:13 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 27 Jun 2016 00:38:13 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : IIOException while getting second image properties for JPEG Message-ID: <07359798-1d65-44ad-9d94-044564564828@default> Hi Phil, Thanks for your review. I have removed all the references to "for JPEG with embedded thumbnail" and updated the information in test case, description and file names. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/8152672/webrev.03/ I have created new bug to support thumbnails present in APP1 marker : https://bugs.openjdk.java.net/browse/JDK-8160327 I was also wondering that APP2 markers can contain FlashPix data, thanks for the clarification. Regards, Jay From: Philip Race Sent: Saturday, June 25, 2016 10:28 PM To: Jayathirth D V Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail Hi, So my conclusion is as follows : - in both these images, there is a thumbnail but it is inside the APP1 marker and we never even see it. So the synopsis reference to "for JPEG with embedded thumbnail" is completely misleading .. wrong even. We should just delete that part from the synopsis and update the test names and description to eliminate reference to that. After that the fix should be good to go. - A follow-on bug should be filed that we do not locate thumbnails inside EXIF APP1 markers. We do not need to parse everything inside the APP1 marker to do this so it should be a moderate but not massive amount of work. - The APP2 markers appear to be FlashPix data since these follow EXIF/APP1 data and I understand they may use multiple APP2s because the marker segment has a size limit of 64K (the size is a two byte quantity). So we can ignore this. -phil. On 6/23/16, 5:10 AM, Jayathirth D V wrote: Hi Phil, We have two images with which we can reproduce the issue: 1) sample.jpg - Image attached in JBS 2) JpegEmbedThumbnail.jpg - Image present in webrev. I have attached image for difference in markers if we skipbytes for length and without skipping and parsing serially for both the images. It also mentions all the markers present in both the images. Also I have attached metadata information extracted for both the images using http://www.sno.phy.queensu.ca/~phil/exiftool/ . Regarding the thumbnails : In both the images we have thumbnail inside APP1(EXIF) marker, I have extracted the thumbnails using exiftool . The information that we have of thumbnail present APP1 markers match the thumbnail information present in exiftool metadata. In JPEGMetadata.java constructor we are not parsing APP1 marker and storing it as a marker segment. That is why in both the cases we are seeing thumbnails as 0. This looks like separate issue of not considering thumbnail data present in APP1 markers. In sample.jpg the 640*480 image present after 3968*2976 image is preview image. It is stored for showing preview in Camera display and it is not EXIF embedded thumbnail. We have thumbnail data present in APP1 marker and it is of dimensions 160*120, we can extract the same using exiftool. In JpegEmbedThumbnail.jpg both main image and thumbnail are of same size 64*48(I have kept main image size to be as small as possible since it will be checked in). Regarding embedded ICC profile: JpegEmbedThumbnail.jpg has one image with embedded thumbnail in APP1 marker. It has many APP2 markers and we are parsing it for given ImageIndex using gotoImage() and readNativeHeader(). Please let me know your inputs. Thanks, Jay -----Original Message----- From: Phil Race Sent: Wednesday, June 22, 2016 2:20 AM To: Jim Graham 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-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail No issues with the exceptions as such. Whilst this does make things better I still have some reservations about the result of the fix since remember the bug says "JPEG with embedded thumbnail". If I apply your patch and use the original file I get two images but neither reports any thumbnails .. using either metadata or ImageReader.getNumThumbnails(int) One image is 3968x2976, the other is 640x480 (vga resolution). This seems a little big for a thumbnail but still a lot smaller than the original and a nice size for say using on a camera display. So my suspicion is the latter is an EXIF embedded thumbnail - since it is JPEG compressed and that ideally what we should return here is one image with one thumbnail. But since we aren't properly parsing the EXIF APP1 data .. we just find it as another image using the 'brute force' method of looking for the marker sequence. I am a bit surprised though that this hasn't been a more common complaint. We now have the TIFF code so if this really is the case then a fuller fix would return this as a thumbnail. If it really is a follow-on second image in the stream then the fix would seem OK. I just want to know which we have here Then we get to the image you used in the test. Yes, this throws an exception with 8ux .. but it is a different complaint. With the original file :- Exception in thread "main" javax.imageio.IIOException: Not a JPEG file: starts with 0xff 0xff With the test file :- Exception in thread "main" javax.imageio.IIOException: Not a JPEG file: starts with 0xff 0xe2 That's an APP2 marker .. which may mean an embedded ICC Profile. The code is supposed to be able to handle that https://docs.oracle.com/javase/8/docs/api/javax/imageio/metadata/doc-files/jpeg_metadata.html#color .. so perhaps its something else but it would be nice to know this is being handled properly. Also - back to thumbnails - this one reports zero thumbnails too ! So with the test and the fix being all about embedded thumbnails it is weird that there aren't any :-) I think we need to break down the exact contents/structure of these files to be sure what we have here. -phil. On 06/14/2016 09:30 PM, Jim Graham wrote: Hi Jay, Thanks for explaining all of the details. It seems that constantly being in scan mode simplifies things because we have to be in scan mode for entropy data anyway, but it still allows errant bytes outside of the entropy data to be accepted by this parser. I'm not sure if that is a problem in the long run, but it is not a new issue (since the existing code already was doing that) so we can live with it for purposes of fixing this particular bug. One simplification of what you say below, it appears that among all of those cases none of them really impact the fact that un-sized entropy encoded data only appears inside the SOS marker and the only markers found inside the entropy data itself are the RSTn markers. Ideally we could limit our scanning to just the data following the SOS marker and its sized header and only allow RSTn markers to appear inside that manual scan, reverting to a non-scanning mode when we reach another marker (DNL it looks like). But, that would be the subject of a different bug fix. It looks OK to me as long as Phil is OK with the types of exceptions that you are throwing in the various new exceptional cases, and with the change to now assume that skipImage always being called at an SOI marker. Phil? ...jim On 6/14/16 9:36 AM, Jayathirth D V wrote: Hi Jim, I have updated the code to add check for EOF even in case of reading length. Also I have updated the code such that in all the cases where we find EOF before EOI we are throwing IndexOutOfBoundsException and in other failed cases we are throwing IOException. More analysis : All the length markers that we are checking in our case have valid length data except SOS marker in which always the length value will be 12 and it is the value only for the length of Scan header. After Scan header(SOS) we have compressed data for which we have no parameter which gives the length so that we can skip it completely. Once we get to the initial SOS header it can take 3 paths based on how the data follows: a) If we don't have Restart enabled and if we scan continuously through compressed data we will find EOI otherwise we will find RST markers and then EOI marker. b) If we have multiple scan headers(Multi-scan scenario) we have to follow point 'a' in loop with each scan header separated by DNL and other miscellaneous tables. c) If we have multiple frame headers(Multi-frame scenario) we have to follow point 'b' in loop with different markers coming in between. Above information is taken from page 52 of https://www.w3.org/Graphics/JPEG/itu-t81.pdf Since we can't rely on length specified in SOS header and there is possibility of having multiple SOS headers, we need to search for FF(foundFF). It means even if we jump for the length specified is SOS header the next byte is not promised to be '0xff'. For all the remaining markers we will get proper information related to the length and we will skip all data part(which might contain data similar to EOI/SOI/or any other marker). While propagating through the 'for' loop we are following the same approach. Please find updated webrev for review : http://cr.openjdk.java.net/~jdv/8152672/webrev.02/ Thanks, Jay -----Original Message----- From: Jim Graham Sent: Tuesday, June 14, 2016 12:44 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-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail Hi Jay, You still don't check the read() calls in the length case to see if you reached EOF (-1). The potential for an infinite loop is still there. Also, you still search for an FF, even if you require the function to start at an SOI marker - all subsequent markers are still subject to a search rather than a deterministic requirement that we encounter markers with no gaps between them. Why do we have the foundFF variable in the first place? If we just saw an SOI marker then the next byte *must be* a 0xff (shouldn't it? Am I missing something?). We shouldn't read a byte and check if it is a 0xff and then try again, we should expect a single 0xff byte followed by a marker type byte, as in: while (true) { int byteval == iis.read(); // if (byteval < 0) then what? if (byteval != 0xff) { exception } byteval = iis.read(); switch (byteval) { } } The only question is if we get a -1 on the first read if we treat that as an implicit EOI as we do now, or if we treat it as an exception. Note that if we get a -1 in the second read, then we have a half-formed tag and that should fall into the default and be declared a bad file. ...jim On 6/13/2016 10:00 AM, Jayathirth D V wrote: Hi Jim, Thanks for your valuable inputs. I have updated the code with your inputs: 1) We should check for complete SOI marker and not just "FF" at start of skipImage(). 2) There is no need of iis.read() which was happening in default case. iis.read() present in for loop check will take care of checking EOF. 3) I have added case condition for all the markers having length and added default case where we get invalid marker starting with FF. Apart from above changes, after going more through https://www.w3.org/Graphics/JPEG/itu-t81.pdf got to know following things: 1) TEM is also one more marker without length so added case for that. 2) Since we have all unique conditions checked, we should not find any SOI marker after the initial SOI marker before we find EOI. Made changes to throw IOException in this case. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/8152672/webrev.01/ Thanks, Jay -----Original Message----- From: Jim Graham Sent: Saturday, June 11, 2016 3:07 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-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail Thanks for the response Jay, I think I was misreading some of the code as now that I look back at it, it's mostly written as I was suggesting with respect to skipping over data sections, however it is still doing some scanning to find the initial 0xFF. Some thoughts: - If we can be sure that we are located at where a tag should be, then shouldn't we just read a byte and assert that it is 0xFF and report the file as invalid if it isn't? The current code will just ignore the byte and continue reading until it finds a 0xFF, but the fact that the first byte we read isn't 0xFF means we have wandered into data that isn't following the file format (or, possibly, that this was called from a case where we hadn't completely read a section of data, but that should be fixed as we could be in the middle of a section that isn't entropy encoded and our search for 0xFF might have invalid assumptions). - The bytes read in the default section to get the length and the tag for the next block aren't tested for EOF (-1). This may even get us into an infinite loop if we hit EOF at the right time (just after a sized block tag) as the size bytes will read and combine into a -1 size, back up three bytes, and then reread the same tag and try to compute a length again which will send us back 3 bytes, etc. - default assumes that all other markers that are created will be sized, but can we assert that? Shouldn't we specifically list all known sized markers and have the default case reject the file as not being of a format that we recognize? ...jim On 6/9/2016 11:21 PM, Jayathirth D V wrote: Hi Jim, I think the harmless byte that you are referring to will be applied only for image data(Between SOS(Start of Scan) marker and EOI). For example, any "FF" data present in Jpeg image will be represented as "FF 00". But I think application headers or comments section can contain data which will be similar to EOI,SOI or other markers(FF XX). Thanks, Jay -----Original Message----- From: Jim Graham Sent: Friday, June 10, 2016 5:28 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-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail It looks like JPEG files have protection for scanning for an FF and assuming it is a marker by making sure that all FF bytes that appear in data are followed by a harmless byte, so a brute force search is probably fine. But it still seems wasteful when we know we are at a tag and we know the sizes of all of the tags, we should be able to skip around the file looking for the SOI directly... ...jim On 6/2/2016 5:10 AM, Jayathirth D V wrote: Fixed typo. *From:*Jayathirth D V *Sent:* Thursday, June 02, 2016 5:08 PM *To:* Philip Race *Cc:* Jim Graham; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net *Subject:* RE: Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail Hi Phil, We have two kind of images with which we are able to reproduce the issue: 1) sample.jpg present in JBS bug(We can't use this image because it is licensed ). 2) JpegEmbedThumbnail.jpg taken using Prasanta's camera and used in webrev. _ _ _sample.jpg : _ _ _ If we do getNumImages() it will return 2. getNumImages() follows the same logic of skipping markers with length and registering SOI to get number of images. sample.jpg has markers as follows : SOI -> APP1 - > SOI -> EOI -> APP1 End -> EOI -> SOI -> EOI I have dumped first image its SOI is first one in the above list and for second image it is third one in the list. getNumImages() counts first and third SOI for number of images. But in case of skipImage() we are getting inside APP1 marker and considering its SOI. _JpegEmbedThumbnail.jpg :_ _ _ If we do getNumImages() it will return 1. JpegEmbedThumbnail.jpg has markers as follows : SOI -> APP1 -> SOI -> EOI -> APP1 End -> APP2 -> SOI -> APP2 End -> APP2 -> EOI -> APP2 End -> EOI getNumImages() counts only first SOI for number of images. But in case of skipImage() we will are getting inside APP1 and APP2 markers also. Thanks, Jay *From:*Phil Race *Sent:* Thursday, June 02, 2016 4:05 AM *To:* Jayathirth D V *Cc:* Jim Graham; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net HYPERLINK "mailto:2d-dev at openjdk.java.net" *Subject:* Re: Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail I am bit doubtful about this. Are you sure we are correct in reporting two images to begin with ? Thumbnails should not get counted .. -phil. On 06/01/2016 01:06 AM, Jayathirth D V wrote: Updated bug title in JBS as it was misleading. *From:* Jayathirth D V *Sent:* Wednesday, June 01, 2016 12:48 PM *To:* Philip Race; Jim Graham *Cc:* HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net HYPERLINK "mailto:2d-dev at openjdk.java.net" *Subject:* Review Request for JDK-8152672 : Exception getting thumbnail size for JPEG with embedded thumbnail Hi, _Please review the following fix in JDK9:_ Bug : https://bugs.openjdk.java.net/browse/JDK-8152672 Webrev : http://cr.openjdk.java.net/~jdv/8152672/webrev.00/ HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8152672/webrev.00/" Issue : When we are trying to get properties related to second image in JPEG file we are getting IIOException mentioning that it is not a JPEG file. Root cause : When we are skipping first image to reach second image header, we are just trying to find next available EOI marker. But if first image has embedded thumbnail in APP1 marker, we will reach to EOI of this thumbnail and not EOI of first image. So after we reach EOI of embedded thumbnail we try to access second image SOI marker which will fail. Solution : We have to change the logic of how we skip to consecutive images in JPEG file. We know that application markers, comments or other markers can contain data same as SOI & EOI. Instead of just checking for EOI marker serially, we should read length of these markers and skip them. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Mon Jun 27 08:15:01 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 27 Jun 2016 10:15:01 +0200 Subject: [OpenJDK 2D-Dev] [9] Fix for JDK-8074824: Resolve disabled warnings for libawt_xawt In-Reply-To: <58fd8ac4-4520-4776-8229-a7c510eba6d6@default> References: <53656bf6-bce8-4444-8c4f-67d7cc93a522@default> <58fd8ac4-4520-4776-8229-a7c510eba6d6@default> Message-ID: <5770E085.3040109@oracle.com> Hello, I'm happy with the makefile changes, unless anyone else could come up with a solution for any of the remaining warnings. /Erik On 2016-06-23 09:09, Ajit Ghaisas wrote: > Hi, > > Bug : > https://bugs.openjdk.java.net/browse/JDK-8074824 > (Resolve disabled warnings for libawt_xawt) > > As part of fixing this bug, I have - > > 1. Fixed warnings in source code after removing blanket warning suppressions from makefile. > > 2. In case the warning fix is not possible, converted blanket warning suppression for this library to suppression of warnings for individual files. > > 3. Added comments in makefile for the warning suppression that cannot be fixed. > > One type of gcc warning 'deprecated-declarations' will be fixed separately (as part of JDK-8160146) > > > I have built the changes successfully on all supported platforms. > > > Webrev : > http://cr.openjdk.java.net/~aghaisas/8074824/webrev.00/ > > Request you to review. > > Regards, > Ajit From prahalad.kumar.narayanan at oracle.com Mon Jun 27 10:47:46 2016 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Mon, 27 Jun 2016 03:47:46 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni In-Reply-To: <5770C5B4.9090600@oracle.com> References: <2c20f37e-7eae-499c-9a70-bb3dd06da636@default> <5770C5B4.9090600@oracle.com> Message-ID: <29611571-bc4e-4180-9aa7-0b055bcf0a8b@default> Hello Everyone Good day to you. Quick follow up to fix for the Bug Bug ID : JDK-8152971 Bug Link : https://bugs.openjdk.java.net/browse/JDK-8152971 First, Thanks to Prasanta for his review & suggestions. I 've incorporated some of the review suggestions & updated the webrev. Webrev Link : http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.02/ Overview on changes from previous webrev: 1. Code Changes: As Prasanta mentioned, The variable fontStrLC should be used in place of fontStr - The correction has been taken up. And releaseGdiFontMapReferences call is not required when GdiFontMapInfo object isn't initialized - The particular invocation has been removed. 2. With regard to deleting references held within GdiFontMapInfo struture JNI creates local references only for objects that are created at the Java side - jobject, jstring and jclass The other FMI variables - method IDs are not references to objects. Hence invoking deleteLocalRef.. is not valid (may not compile too). 3. The Jtreg shell script - LoadFontsJNICheck.sh was initially written to run only on MacOS. Since it addresses the bug at hand (which is on windows), I tested the script 's execution on Win and Linux. The Jtreg script passes on linux and fails on windows with warnings in java.lang codebase. As I understand, there is a JBS bug filed already pertaining to JNI warnings in java.lang package. Hence enabling the script on windows, doesn't introduce new bug. The only OS that the script doesn't run - Solaris. Presently, we don't have a Solaris environment at our facility to test the script. Hence the original functionality on Solaris is retained. Kindly take a look at the changes at your convenience & provide the suggestions. Thank you for your review Have a good day Prahalad N. From: Prasanta Sadhukhan Sent: Monday, June 27, 2016 11:51 AM To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net Cc: Philip Race; Jayathirth D V; Praveen Srivastava Subject: Re: [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni I guess this method(s) should take "fontStrLC" instead of "fontStr" 650 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, 651 fontStr, fileStr); 692 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, 693 fontStr, fileStr); 762 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, 763 fontStr, fileStr); 805 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, 806 fontStr, fileStr); It seems this line is not needed as we have not populated fmi structure yet. 882 releaseGdiFontMapReferences(env, &fmi); Why aren't we deleting fmi->env,fmi.arrayListCtr,fmi.addMID,fmi.putMID in releaseGdiFontMapReferences()? Also, it seems earlier the testscript was supposed to execute only on Mac but now you are extending the execution platform to windows and linux as well excluding only solaris. Is there any particular need to restrict solaris too? Regards Prasanta On 6/24/2016 7:34 PM, Prahalad Kumar Narayanan wrote: Hello Everyone on Java2D Forum Good day to you. A Quick follow-up on webrev to fix the following issue ????? Bug ID???? : JDK-8152971? / -Xcheck:jni - warning in native method ????? Bug Link : https://bugs.openjdk.java.net/browse/JDK-8152971?filter=-1 Updated webrev link:? http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.01/ Description on Changes ????? . The previous webrev contained changes to additional files which are not related to the current bug in concern. ????? . Henceforth, the updated webrev limits the changes to only fontpath.c and a Jtreg test script to verify the change. Regarding Build & Test ????? . Though the changes pertain to windows specific code, internal build system was triggered to ensure safe build on all supported platforms. ????? . In addition, no new Jtreg failures were found with the proposed changes. Kindly review the changes at your convenience & provide your feedback. Thank you for your time in review Have a good day Prahalad N. -----Original Message----- From: Prahalad Kumar Narayanan Sent: Wednesday, June 22, 2016 3:20 PM To: 2d-dev at openjdk.java.net Cc: Philip Race; Prasanta Sadhukhan; Jayathirth D V; Praveen Srivastava Subject: [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni Hello Everyone, on Java2D Group Good day to you. Please find herewith, webrev changes to fix the bug- ????? Bug ID???? : JDK-8152971? / -Xcheck:jni - warning in native method ????? Bug Link : https://bugs.openjdk.java.net/browse/JDK-8152971?filter=-1 ????? Webrev : http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.00/ Description on Bug: ???? 1.? Too many JNI warnings are reported in the native functions when test-code is run with VM Option:? -Xcheck:jni ???? 2.? The warnings can be classified into 2 categories ???????????????? a.? JNI warnings that are thrown due to the missing exception checks after an Up call ( JNI function invoking Java method ) ???????????????? b.? JNI warnings that are thrown due to increased usage of Local Reference objects. Description on the Fix: ???? 1.? File : FontPath.c ?????????????????? Added JNIEnv->ExceptionCheck() and ExceptionClear() where Up call is invoked. ?????????????????????????? The checks are added only to the valid Up calls as per JNI spec. ?????????????????? Added JNIEnv->DeleteLocalRef where the native functions created Java side objects but did not delete their local reference after usage. ?????????????????????????? A few of the native functions get invoked as Callbacks to Windows APIs following the font enumeration. ?????????????????????????? Therefore at each callback, the count of active local references would increase. ??????????????????????????????????? Over time, the active local references would exceed the planned number of local references set by JVM. ???? 2.? File : awt_Component.cpp ?????????????????? Added JNIEnv->ExceptionCheck() and ExceptionClear() where an Up call displayed a JNI warning while running the Jtreg test script. ?????????????????? Information on Jtreg test script is given below. ???? 3.? File : LoadFontsJNICheck.sh ?????????????????? The shell script is already a part of JTreg test case & invokes LoadFontsJNICheck with -Xcheck:jni VM option ?????????????????? However, the script was configured to run only on Mac OS. Now, the script is modified to run on windows, linux and mac systems. ??????????????????????????????? This way, the code changes can be checked for proper execution with test-case. Kindly review the changes at your convenience and share your feedback. Thank you for your time in review Have a good day Prahalad N. From prasanta.sadhukhan at oracle.com Mon Jun 27 11:27:18 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 27 Jun 2016 16:57:18 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6789262: getPageFormat doesn't apply PrintRequestAttributeSet specified Message-ID: <57710D96.8010808@oracle.com> Hi All, Please review a fix for an issue where it was found that setting left margin of 2" is ignored and when we query PrinterJob.job.getPageFormat(PrintRequestAttributeSet) we get the default paper mediapritable area of x=1" instead of the set 2". Bug: https://bugs.openjdk.java.net/browse/JDK-6789262 webrev: http://cr.openjdk.java.net/~psadhukhan/6789262/webrev.00/ This is because it was found that getPageFormat() calls Win32PrintService#isAttributeValueSupported() where we call isSupportedMediaPrintableArea() to check if the mediaprintable area is matching with the media size that has been cached. It gets the paperID by calling findPaperID() and stores the mpa of that paper in MediaPrintableArea[] I see that my printer supports 43 mediasize names (like iso_a4, iso_a5, na_letter etc) and none of the 43 mediaPrintables equals the mpa value of (50.4, 25.4, 133.8, 246.2)mm ---------------isSupportedMediaPrintableArea()--------- if (mediaPrintables != null) { for (int i=0; i From yasuenag at gmail.com Mon Jun 27 13:55:11 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 27 Jun 2016 22:55:11 +0900 Subject: [OpenJDK 2D-Dev] RFR: JDK-8160294: Some client libraries cannot be bult with GCC 6 In-Reply-To: <549987ed-d80d-3ab0-ad2d-b135331eb80b@gmail.com> References: <576EA5EE.3020209@oracle.com> <549987ed-d80d-3ab0-ad2d-b135331eb80b@gmail.com> Message-ID: <387752d6-69d8-c484-bd26-9459cf4ff008@gmail.com> Hi, Erik commented that the changes in Awt2dLibraries.gmk should use DISABLED_WARNINGS_gcc parameter. So I use it in new webrev. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8160294/webrev.01/ Thanks, Yasumasa On 2016/06/26 11:14, Yasumasa Suenaga wrote: > Hi Phil, > > I've added all warning (error) messages to JIRA. > Could you review them? > > https://bugs.openjdk.java.net/browse/JDK-8160294 > > > Thanks, > > Yasumasa > > > On 2016/06/26 0:40, Philip Race wrote: >> >> Could you share all warning messages that you received ? >> Adding them to the bug report is probably best. >> I feel much better reviewing these kinds of changes when >> I can see for myself what the issue is. >> >> -phil. >> >> On 6/25/16, 6:40 AM, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> This review request relates to [1]. >>> >>> Some client libraries could not be built with misleading-indentation >>> and shift-negative-value warning (error) on GCC 6.1.1 . >>> >>> So I think we have to fix new warnings. >>> >>> However, some libraries (LCMS, JPEG library) are imported from another >>> open source project. So we should avoid compile error with suppressing >>> them. >>> >>> I uploaded a webrev. >>> Could you review it? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8160294/webrev.00/ >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004494.html From Sergey.Bylokhov at oracle.com Mon Jun 27 14:54:43 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 27 Jun 2016 17:54:43 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8144703: ClassCastException: sun.font.CompositeFont cannot be cast to PhysicalFont In-Reply-To: <5763D54B.1030405@oracle.com> References: <575AAD6A.5040903@oracle.com> <5763D54B.1030405@oracle.com> Message-ID: Looks fine. On 17.06.16 13:47, dmitry markov wrote: > Reminder. > > Could you review the fix, please? > > Thanks in advance, > Dmitry > On 10/06/2016 15:07, dmitry markov wrote: >> Hello, >> >> Could you review a fix for jdk9, please? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8144703 >> webrev: http://cr.openjdk.java.net/~dmarkov/8144703/webrev.00/ >> >> Problem description: >> If an incorrect font file is used, we unable to initialize the font >> during CompositeFont.doDeferredInitialisation() invocation and assign >> default physical font to the corresponding components entry. Later at >> the same method, (i.e. doDeferredInitialisation()) we try to update >> this entry one more time, since the name retrieved from the entry and >> the name provide by componentNames array are different. The method >> SunFontManager.findFont2D() may return a composite font for such case. >> As a result we get ClassCastException trying to assign CompositeFont >> object to the instance of PhysicalFont. >> >> Fix: >> Surround invocation of SunFontManager.findFont2D() inside >> CompositeFont.doDeferredInitialisation() with 'try-catch' to avoid >> propagation of ClassCastException. >> >> Thanks, >> Dmitry > -- Best regards, Sergey. From erik.joelsson at oracle.com Mon Jun 27 15:59:26 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 27 Jun 2016 17:59:26 +0200 Subject: [OpenJDK 2D-Dev] RFR: JDK-8160294: Some client libraries cannot be bult with GCC 6 In-Reply-To: <387752d6-69d8-c484-bd26-9459cf4ff008@gmail.com> References: <576EA5EE.3020209@oracle.com> <549987ed-d80d-3ab0-ad2d-b135331eb80b@gmail.com> <387752d6-69d8-c484-bd26-9459cf4ff008@gmail.com> Message-ID: <57714D5E.60400@oracle.com> Build changes look ok. /Erik On 2016-06-27 15:55, Yasumasa Suenaga wrote: > Hi, > > Erik commented that the changes in Awt2dLibraries.gmk should use > DISABLED_WARNINGS_gcc > parameter. > > So I use it in new webrev. > Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8160294/webrev.01/ > > > Thanks, > > Yasumasa > > > On 2016/06/26 11:14, Yasumasa Suenaga wrote: >> Hi Phil, >> >> I've added all warning (error) messages to JIRA. >> Could you review them? >> >> https://bugs.openjdk.java.net/browse/JDK-8160294 >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/06/26 0:40, Philip Race wrote: >>> >>> Could you share all warning messages that you received ? >>> Adding them to the bug report is probably best. >>> I feel much better reviewing these kinds of changes when >>> I can see for myself what the issue is. >>> >>> -phil. >>> >>> On 6/25/16, 6:40 AM, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> This review request relates to [1]. >>>> >>>> Some client libraries could not be built with misleading-indentation >>>> and shift-negative-value warning (error) on GCC 6.1.1 . >>>> >>>> So I think we have to fix new warnings. >>>> >>>> However, some libraries (LCMS, JPEG library) are imported from another >>>> open source project. So we should avoid compile error with suppressing >>>> them. >>>> >>>> I uploaded a webrev. >>>> Could you review it? >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8160294/webrev.00/ >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004494.html From alexandr.scherbatiy at oracle.com Mon Jun 27 18:17:44 2016 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 27 Jun 2016 22:17:44 +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: <0f87bf94-13c3-160b-d1f6-c95b959299bb@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> <56F03E0B.1080703@oracle.com> <5734B8AB.7070908@oracle.com> <0f87bf94-13c3-160b-d1f6-c95b959299bb@oracle.com> Message-ID: Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8151303/webrev.02 The fix does not use a new public API to apply filters to multi-resolution images. Thanks, Alexandr. On 14/05/16 02:54, Jim Graham wrote: > Another reason to avoid new API is that we don't have to involve the > CCC to get this "bug fix" in... > > ...jim > > On 5/13/16 3:50 PM, Jim Graham wrote: >> That looks very tight. The only issue I'd have is that it would be >> better if this could be done with non-public API for >> now - the map() methods could live on one of the sun.awt.image >> classes or even in a Swing implementation utility class >> and still work just fine. When we have more time to figure out how >> we're going to handle filtering of MRIs in general >> we can decide if this API should live on the base MRI interface. >> >> The only thing we'd lose is BaseMRI having an optimized >> implementation of the map() method, but I don't think it's >> implementation represents enough of an optimization to matter when we >> are creating and loading dozens of images... >> >> ...jim >> >> On 5/12/16 10:08 AM, Alexander Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8151303/webrev.01 >>> >>> There was a suggestion to postpone the fix for the issue 8152309 >>> Seamless way of using image filters with >>> multi-resolution images >>> and continue with the current one: >>> http://mail.openjdk.java.net/pipermail/2d-dev/2016-April/006766.html >>> >>> The new version of the fix introduces a mapper method which allows >>> to map all resolution variants of one >>> multi-resolution image to another: >>> ------------ >>> Image image = // original image >>> Image filteredImage = MultiResolutionImage.map(image, (img) -> >>> /* return filtered image */); >>> ------------ >>> >>> Thanks, >>> Alexandr. >>> >>> On 21/03/16 22:31, Jim Graham wrote: >>>> 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 brian.burkhalter at oracle.com Mon Jun 27 19:10:37 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 27 Jun 2016 12:10:37 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail In-Reply-To: <576EB7FB.8060600@oracle.com> References: <89531a21-64b2-4e00-8f15-aa78650cf7b2@default> <574F62FA.50900@oracle.com> <1309b2bb-c189-d623-cfc5-105223718e12@oracle.com> <70565f43-7547-4047-bca3-f95ae709427e@default> <7b22a1ca-5e6a-c705-90bc-510aa2073c90@oracle.com> <1b962d5d-ae52-4281-8ca8-d6d5558e3fe5@default> <9c521f0e-1f76-420b-bf51-3495c5779b83@default> <5769A88E.9000603@oracle.com> <1b4983f1-6286-4394-8f52-788a1e6bb23b@default> <576EB7FB.8060600@oracle.com> Message-ID: <99E63493-8533-4CDF-810F-8CD7AEDAF69A@oracle.com> The procedure for this is straightforward: Inside the APP1 Exif marker segment locate the 8-byte TIFF header. From the last four bytes of the TIFF header obtain the offset to the 0th Image File Descriptor (IFD). Skip all the entries in the 0th IFD. Obtain from the last four bytes of the 0th IFD the offset to the 1st IFD. If the offset to the 1st IFD is zero, there is no thumbnail; otherwise seek to the offset of the 1st IFD. Within the 1st IFD locate and obtain the values of the two entries with tags JPEGInterchangeFormat and JPEGInterchangeFormatLength. These provide respectively the offset to the SOI marker segment of the Exif thumbnail and the length of the Exif thumbnail data. If both of these entries are missing, then the file is aberrant and no thumbnail can be read. If only the JPEGInterchangeFormat entry is present, the thumbnail is likely still readable assuming it has the proper JPEG structure including a terminating EOI marker segment. Seek to the value of the JPEGInterchangeFormat entry and decode the thumbnail. (It might not be a bad safeguard if possible to check that the two bytes at offset JPEGInterchangeFormat + JPEGInterchangeFormatLength - 2 are actually an EOI marker.) It might not be a bad idea to add the above as a comment in the issue to be filed. Brian On Jun 25, 2016, at 9:57 AM, Philip Race wrote: > - A follow-on bug should be filed that we do not locate thumbnails > inside EXIF APP1 markers. We do not need to parse everything inside > the APP1 marker to do this so it should be a moderate but not > massive amount of work. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Jun 27 22:44:23 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 27 Jun 2016 15:44:23 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8160294: Some client libraries cannot be bult with GCC 6 In-Reply-To: <57714D5E.60400@oracle.com> References: <576EA5EE.3020209@oracle.com> <549987ed-d80d-3ab0-ad2d-b135331eb80b@gmail.com> <387752d6-69d8-c484-bd26-9459cf4ff008@gmail.com> <57714D5E.60400@oracle.com> Message-ID: <5771AC47.8000406@oracle.com> I think these are all OK. Regarding the AlphaMath change, I get that we may have the use of signed int means the undefined result would be for that .. but it doesn't seem to impact the loop conditions so I don't understand why that causes a problem for loop optimisation. Still, the change is fine. -phil. On 06/27/2016 08:59 AM, Erik Joelsson wrote: > Build changes look ok. > > /Erik > > On 2016-06-27 15:55, Yasumasa Suenaga wrote: >> Hi, >> >> Erik commented that the changes in Awt2dLibraries.gmk should use >> DISABLED_WARNINGS_gcc >> parameter. >> >> So I use it in new webrev. >> Could you review it? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8160294/webrev.01/ >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/06/26 11:14, Yasumasa Suenaga wrote: >>> Hi Phil, >>> >>> I've added all warning (error) messages to JIRA. >>> Could you review them? >>> >>> https://bugs.openjdk.java.net/browse/JDK-8160294 >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/06/26 0:40, Philip Race wrote: >>>> >>>> Could you share all warning messages that you received ? >>>> Adding them to the bug report is probably best. >>>> I feel much better reviewing these kinds of changes when >>>> I can see for myself what the issue is. >>>> >>>> -phil. >>>> >>>> On 6/25/16, 6:40 AM, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> This review request relates to [1]. >>>>> >>>>> Some client libraries could not be built with misleading-indentation >>>>> and shift-negative-value warning (error) on GCC 6.1.1 . >>>>> >>>>> So I think we have to fix new warnings. >>>>> >>>>> However, some libraries (LCMS, JPEG library) are imported from >>>>> another >>>>> open source project. So we should avoid compile error with >>>>> suppressing >>>>> them. >>>>> >>>>> I uploaded a webrev. >>>>> Could you review it? >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8160294/webrev.00/ >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> [1] >>>>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004494.html > From james.graham at oracle.com Mon Jun 27 23:05:50 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 27 Jun 2016 16:05:50 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8153943 : In PixelInterLeavedSampleModel and BandedSampleModel we dont need hashCode() method In-Reply-To: References: Message-ID: This is odd that two completely different classes have identical "equals()" methods. After looking into it in more detail it looks as if ComponentSM is implemented as a general case that can encompass either PixelInterleaved or Banded pixel layouts - which means the subclasses are mostly just cosmetic (offering the constructors that make most sense if the pixels are laid out in the different ways) and only Banded offers a different implementation of getDataElements which is only different from the super implementation by virtue of eliminating a "multiply by a number which we know to be 1". There are also some restrictions in the constructors that enforce limits on the various values that CSM allows in its general implementation, so it isn't possible to use the PixelInterleaved constructor to create an arbitrarily-valued CSM nor to use the Banded constructors for the same purpose. The overlap in the type of CSM you can create from each of their constructors is very tiny to non-existant. The end result is that it ends up being infeasible to define a PixelInterleaved and a Banded SM that are equals() (not impossible, but you'd have to have a very degenerate case like a 1x1 image to make it through the various restrictions in the constructors and the offsets and the scanline strides and pixel strides, etc.). It's really odd in theory, and while not a problem in practice it still feels as if it violates an expectation. The primary restrictions I see getting in the way of different classed objects being equals() is that Banded forces a pixel stride of 1 and PixelInterleaved enforces that all band offsets are smaller than the scan stride. So, technically, I don't see any issue with just removing the hash method as the webrev proposes, but I'd like to see Phil's reaction to the situation we are in here with respect to intent vs. theory vs. practice vs. developer expectation... ...jim On 6/24/16 10:34 AM, Jayathirth D V wrote: > Hi, > > Please find following changes for review in JDK9 : > > Bug : https://bugs.openjdk.java.net/browse/JDK-8153943 > > Webrev : http://cr.openjdk.java.net/~jdv/8153943/webrev.03/ > > Issue : We have hashCode() method in PixelInterleavedSampleModel and BandedSampleModel, but we don't have corresponding equals() method. > > Solution : In PixelInterleavedSampleModel and BandedSampleModel we don't have unique properties that are specific to these subclasses and we have proper equals() & hashCode() method in parent class ComponentSampleModel. So removed hashCode() method present in PixelInterleavedSampleModel and BandedSampleModel. > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Wednesday, May 04, 2016 2:44 AM > To: Phil Race > Cc: 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8153943 : In java.awt.image package some of the classes are missing hashCode() or equals() method > > Yes, the equals/hashcode chapter in Effective Java includes rules about ignoring fields that can be calculated from other fields (which applies to most internal fields). Basically, only things in the constructors tend to be good candidates for equals/hashcode... > > ...jim > > On 5/3/2016 2:00 PM, Phil Race wrote: >> On 04/26/2016 04:10 PM, Jim Graham wrote: >>> The ComponentColorModel implementation is a meaningless wrapper >>> around super.equals/hashCode(). Why does it not test CCM-specific fields? >> >> It should although this looks like it is more than just running >> through all the fields and testing them for equality. >> eg it looks like "initScale()" should be called if necessary before >> determining equality and the field "needScaleInit" is not one that has >> to be directly included in the equality comparison. >> >> -phil. >> >> >> >>> >>> The ComponentSampleModel.hashCode() method should be upgraded based >>> on the recommendations in Effective Java like the other methods here. >>> >>> PixelInterleavedSampleModel and BandedSampleModel also have a >>> meaningless override of super.equals/hashCode(). >>> >>> And all of these classes suffer from casting to the specific type >>> before verifying its class as I mentioned in the ICM.equals() review... >>> >>> ...jim >>> >>> On 4/25/16 2:31 AM, Jayathirth D V wrote: >>>> Hi Jim, >>>> >>>> I have made changes to include check for class equality in base >>>> class and use super.equals() from subclasses. >>>> Please find updated webrev for review : >>>> http://cr.openjdk.java.net/~jdv/8153943/webrev.02/ >>>> >>>> Change related to ColorModel is present in JDK-7107905 review. >>>> >>>> Thanks, >>>> Jay >>>> >>>> -----Original Message----- >>>> From: Jim Graham >>>> Sent: Saturday, April 23, 2016 7:30 AM >>>> To: Phil Race; Jayathirth D V >>>> Cc: 2d-dev at openjdk.java.net >>>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8153943 : In >>>> java.awt.image package some of the classes are missing hashCode() or >>>> equals() method >>>> >>>> This is actually a pretty nasty issue that Joe Darcy also brought up >>>> in the CCC review. >>>> >>>> In order to have symmetric testing of .equals(), we pretty much have >>>> to enforce this test at all levels, including in the original >>>> ColorModels.equals() method. If we don't enforce this in >>>> CM.equals(), then we could run ccm.equals(othercm) and it would >>>> return false because the class is wrong, but turning it around and >>>> testing >>>> othercm.equals(ccm) would succeed because it doesn't enforce the >>>> class equality. >>>> >>>> So, I'd recommend that CM.equals() tests getClass() == getClass() at >>>> the base level and then all others will use super.equals() and get >>>> the same protection. It means you can't have a subclass of CCM be >>>> "equals" to a different subclass of CCM, but that's an unfortunate >>>> issue with equals needing to honor symmetry... :( >>>> >>>> ...jim >>>> >>>> On 4/20/2016 10:17 AM, Phil Race wrote: >>>>> Hi, You removed the following test in CCM.java : 2941 if >>>>> (obj.getClass() != getClass()) { >>>>> 2942 return false; >>>>> >>>>> 2943 } >>>>> >>>>> What this means is that before your change an instance of a >>>>> subclass of CCM would never be equals() to any direct >>>>> instantiatation of CCM but after your change it can be. I suspect >>>>> the condition was there on purpose. >>>>> >>>>> -phil. >>>>> >>>>> On 04/20/2016 05:45 AM, Jayathirth D V wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> >>>>>> _Please review the following fix in JDK9:_ >>>>>> >>>>>> >>>>>> >>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8153943 >>>>>> >>>>>> >>>>>> >>>>>> This is subtask of >>>>>> https://bugs.openjdk.java.net/browse/JDK-6588409 >>>>>> >>>>>> >>>>>> >>>>>> Webrev : http://cr.openjdk.java.net/~jdv/8153943/webrev.00/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Issue : Some of the java.awt.image classes are missing either >>>>>> equals() or hashCode() method. >>>>>> >>>>>> >>>>>> >>>>>> Solution : Add missing equals() or hashCode() methods. >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jay >>>>>> >>>>>> >>>>>> >>>>> >> From james.graham at oracle.com Mon Jun 27 23:16:09 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 27 Jun 2016 16:16:09 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8160294: Some client libraries cannot be bult with GCC 6 In-Reply-To: <5771AC47.8000406@oracle.com> References: <576EA5EE.3020209@oracle.com> <549987ed-d80d-3ab0-ad2d-b135331eb80b@gmail.com> <387752d6-69d8-c484-bd26-9459cf4ff008@gmail.com> <57714D5E.60400@oracle.com> <5771AC47.8000406@oracle.com> Message-ID: <1a4345df-eca0-0d3a-9e05-05da95707c76@oracle.com> I agree, it looks more like an overflow error, but the new code is technically more correct so this is more of a comment on their error reporting than on the resulting fix. If you ignore the "Werror=" part of the comment, it is true that val overflows a signed int on the 127th iteration, which means they've done some sort of deep dive on analyzing the activity of the loop. Perhaps "aggressive-loop-optimizion" is more of a comment on the fact that they aggressively computed what the loop was doing in all 256 iterations when they discovered the overflow? In any case, the AlphaMath fix looks fine... ...jim On 6/27/16 3:44 PM, Phil Race wrote: > I think these are all OK. > Regarding the AlphaMath change, I get that we may have > the use of signed int means the undefined result would > be for that .. but it doesn't seem to impact the loop > conditions so I don't understand why that causes a problem > for loop optimisation. Still, the change is fine. > > -phil. > > On 06/27/2016 08:59 AM, Erik Joelsson wrote: >> Build changes look ok. >> >> /Erik >> >> On 2016-06-27 15:55, Yasumasa Suenaga wrote: >>> Hi, >>> >>> Erik commented that the changes in Awt2dLibraries.gmk should use DISABLED_WARNINGS_gcc >>> parameter. >>> >>> So I use it in new webrev. >>> Could you review it? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8160294/webrev.01/ >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/06/26 11:14, Yasumasa Suenaga wrote: >>>> Hi Phil, >>>> >>>> I've added all warning (error) messages to JIRA. >>>> Could you review them? >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8160294 >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/06/26 0:40, Philip Race wrote: >>>>> >>>>> Could you share all warning messages that you received ? >>>>> Adding them to the bug report is probably best. >>>>> I feel much better reviewing these kinds of changes when >>>>> I can see for myself what the issue is. >>>>> >>>>> -phil. >>>>> >>>>> On 6/25/16, 6:40 AM, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> This review request relates to [1]. >>>>>> >>>>>> Some client libraries could not be built with misleading-indentation >>>>>> and shift-negative-value warning (error) on GCC 6.1.1 . >>>>>> >>>>>> So I think we have to fix new warnings. >>>>>> >>>>>> However, some libraries (LCMS, JPEG library) are imported from another >>>>>> open source project. So we should avoid compile error with suppressing >>>>>> them. >>>>>> >>>>>> I uploaded a webrev. >>>>>> Could you review it? >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8160294/webrev.00/ >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004494.html >> > From yasuenag at gmail.com Tue Jun 28 03:50:33 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 28 Jun 2016 12:50:33 +0900 Subject: [OpenJDK 2D-Dev] JDK 9 build with GCC 6.1.1 In-Reply-To: <57F3A28D-6FFD-45D6-B85C-1B5638CE29F4@oracle.com> References: <57F3A28D-6FFD-45D6-B85C-1B5638CE29F4@oracle.com> Message-ID: Hi Kim, The newest changes for jdk repos is [1]. Erik points we should use DISABLED_WARNINGS_gcc to handle unknown warning tags. [2] [1] is implemented with it. This change is already reviewed by 2d folks. So I want to merge it ASAP. Do you have any objection? Thanks, Yasumasa [1] http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007090.html [2] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004499.html On 2016/06/28 8:37, Kim Barrett wrote: >> On Jun 25, 2016, at 9:57 AM, Yasumasa Suenaga wrote: >> >> Hi all, >> >> This review request relates to [1]. >> >> I've tried to build OpenJDK 9 at Fedora 24 x64. >> Fedora 24 has GCC 6.1.1, and OpenJDK 9 build was failed. >> >> I fixed build error and several issues (VM crash and internal error) as below: >> >> http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot/ >> >> Does someone work for it? >> If no one works for it, I will file it to JBS and will send review request. >> >> For jdk repos, I've sent review request [2]. >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004494.html >> [2] http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007081.html > > Having gone through these, I think all of them are arising due to > build system problems, where we seem to have lost the compiler > configuration to use explicit selection of the language standard and > some additional options. > > For now I think we should fix the build system problems, and file > additional bugs or update existing ones as needed to fix the root > causes of the problems encountered. I think many of the proposed > changes do not address the root causes, and should not be made. See > my comments for the specific bugs. > > I'm not on the mailing list where the jdk RFR was submitted. I took a > look at them though, and > > ------------------------------------------------------------------------------ > make/lib/Awt2dLibraries.gmk > 407 # Avoid warning for GCC 6 > 408 ifeq ($(TOOLCHAIN_TYPE), gcc) > 409 LCMS_CFLAGS += -Wno-misleading-indentation > 410 endif > > 926 # Avoid warning for GCC 6 > 927 ifeq ($(TOOLCHAIN_TYPE), gcc) > 928 BUILD_LIBSPLASHSCREEN_jdhuff.c_CFLAGS += -Wno-shift-negative-value > 929 BUILD_LIBSPLASHSCREEN_jdphuff.c_CFLAGS += -Wno-shift-negative-value > 930 endif > > The -Wmisleading-indentation and -Wshift-negative-value options are > new in gcc 6. gcc has for some time (starting with gcc 4.4) silently > ignored unrecognized -Wno-XXX options. But some folks (like SAP) are > still using older versions. So these will need to be conditionalized > on the gcc version. > > ------------------------------------------------------------------------------ > src/java.desktop/share/native/libfontmanager/layout/SunLayoutEngine.cpp > 154 if (min < 0) min = 0; > 155 if (max < min) max = min; /* defensive coding */ > > [splitting the line] > > Seems like this would be suppressed by -Wno-misleading-indentation, > especially since the reported warning is for that. Why change both > the code and the build configuration? > > ------------------------------------------------------------------------------ > > The changes in AlphaMath.c and splashscreen_jpeg.c look ok. > From prasanta.sadhukhan at oracle.com Tue Jun 28 05:24:00 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 28 Jun 2016 10:54:00 +0530 Subject: [OpenJDK 2D-Dev] [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni In-Reply-To: <29611571-bc4e-4180-9aa7-0b055bcf0a8b@default> References: <2c20f37e-7eae-499c-9a70-bb3dd06da636@default> <5770C5B4.9090600@oracle.com> <29611571-bc4e-4180-9aa7-0b055bcf0a8b@default> Message-ID: <577209F0.9080309@oracle.com> Looks good to me. Only thing is in test script, you need to add copyright 2015, 2016 as the script is originally written in 2015 and you cannot omit the created year from the copyright. Regards Prasanta On 6/27/2016 4:17 PM, Prahalad Kumar Narayanan wrote: > Hello Everyone > > Good day to you. > > Quick follow up to fix for the Bug > Bug ID : JDK-8152971 > Bug Link : https://bugs.openjdk.java.net/browse/JDK-8152971 > > First, Thanks to Prasanta for his review & suggestions. > > I 've incorporated some of the review suggestions & updated the webrev. > Webrev Link : http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.02/ > > Overview on changes from previous webrev: > > 1. Code Changes: As Prasanta mentioned, > The variable fontStrLC should be used in place of fontStr - The correction has been taken up. > And releaseGdiFontMapReferences call is not required when GdiFontMapInfo object isn't initialized - The particular invocation has been removed. > > 2. With regard to deleting references held within GdiFontMapInfo struture > JNI creates local references only for objects that are created at the Java side - jobject, jstring and jclass > The other FMI variables - method IDs are not references to objects. Hence invoking deleteLocalRef.. is not valid (may not compile too). > > 3. The Jtreg shell script - LoadFontsJNICheck.sh was initially written to run only on MacOS. > Since it addresses the bug at hand (which is on windows), I tested the script 's execution on Win and Linux. > The Jtreg script passes on linux and fails on windows with warnings in java.lang codebase. > As I understand, there is a JBS bug filed already pertaining to JNI warnings in java.lang package. > Hence enabling the script on windows, doesn't introduce new bug. > The only OS that the script doesn't run - Solaris. > Presently, we don't have a Solaris environment at our facility to test the script. > Hence the original functionality on Solaris is retained. > > Kindly take a look at the changes at your convenience & provide the suggestions. > > Thank you for your review > Have a good day > > Prahalad N. > > > > From: Prasanta Sadhukhan > Sent: Monday, June 27, 2016 11:51 AM > To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net > Cc: Philip Race; Jayathirth D V; Praveen Srivastava > Subject: Re: [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni > > I guess this method(s) should take "fontStrLC" instead of "fontStr" > 650 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, > 651 fontStr, fileStr); > > 692 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, > 693 fontStr, fileStr); > > 762 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, > 763 fontStr, fileStr); > > 805 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, > 806 fontStr, fileStr); > It seems this line is not needed as we have not populated fmi structure yet. > 882 releaseGdiFontMapReferences(env, &fmi); > > Why aren't we deleting fmi->env,fmi.arrayListCtr,fmi.addMID,fmi.putMID in releaseGdiFontMapReferences()? > > Also, it seems earlier the testscript was supposed to execute only on Mac but now you are extending the execution platform to windows and linux as well excluding only solaris. > Is there any particular need to restrict solaris too? > > Regards > Prasanta > > > On 6/24/2016 7:34 PM, Prahalad Kumar Narayanan wrote: > Hello Everyone on Java2D Forum > Good day to you. > A Quick follow-up on webrev to fix the following issue > Bug ID : JDK-8152971 / -Xcheck:jni - warning in native method > Bug Link : https://bugs.openjdk.java.net/browse/JDK-8152971?filter=-1 > Updated webrev link: http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.01/ > Description on Changes > . The previous webrev contained changes to additional files which are not related to the current bug in concern. > . Henceforth, the updated webrev limits the changes to only fontpath.c and a Jtreg test script to verify the change. > Regarding Build & Test > . Though the changes pertain to windows specific code, internal build system was triggered to ensure safe build on all supported platforms. > . In addition, no new Jtreg failures were found with the proposed changes. > Kindly review the changes at your convenience & provide your feedback. > Thank you for your time in review > Have a good day > Prahalad N. > -----Original Message----- > From: Prahalad Kumar Narayanan > Sent: Wednesday, June 22, 2016 3:20 PM > To: 2d-dev at openjdk.java.net > Cc: Philip Race; Prasanta Sadhukhan; Jayathirth D V; Praveen Srivastava > Subject: [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni > Hello Everyone, on Java2D Group > Good day to you. > Please find herewith, webrev changes to fix the bug- > Bug ID : JDK-8152971 / -Xcheck:jni - warning in native method > Bug Link : https://bugs.openjdk.java.net/browse/JDK-8152971?filter=-1 > Webrev : http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.00/ > Description on Bug: > 1. Too many JNI warnings are reported in the native functions when test-code is run with VM Option: -Xcheck:jni > 2. The warnings can be classified into 2 categories > a. JNI warnings that are thrown due to the missing exception checks after an Up call ( JNI function invoking Java method ) > b. JNI warnings that are thrown due to increased usage of Local Reference objects. > Description on the Fix: > 1. File : FontPath.c > Added JNIEnv->ExceptionCheck() and ExceptionClear() where Up call is invoked. > The checks are added only to the valid Up calls as per JNI spec. > Added JNIEnv->DeleteLocalRef where the native functions created Java side objects but did not delete their local reference after usage. > A few of the native functions get invoked as Callbacks to Windows APIs following the font enumeration. > Therefore at each callback, the count of active local references would increase. > Over time, the active local references would exceed the planned number of local references set by JVM. > 2. File : awt_Component.cpp > Added JNIEnv->ExceptionCheck() and ExceptionClear() where an Up call displayed a JNI warning while running the Jtreg test script. > Information on Jtreg test script is given below. > 3. File : LoadFontsJNICheck.sh > The shell script is already a part of JTreg test case & invokes LoadFontsJNICheck with -Xcheck:jni VM option > However, the script was configured to run only on Mac OS. Now, the script is modified to run on windows, linux and mac systems. > This way, the code changes can be checked for proper execution with test-case. > Kindly review the changes at your convenience and share your feedback. > Thank you for your time in review > Have a good day > Prahalad N. From jayathirth.d.v at oracle.com Tue Jun 28 05:45:09 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 27 Jun 2016 22:45:09 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail In-Reply-To: <99E63493-8533-4CDF-810F-8CD7AEDAF69A@oracle.com> References: <89531a21-64b2-4e00-8f15-aa78650cf7b2@default> <574F62FA.50900@oracle.com> <1309b2bb-c189-d623-cfc5-105223718e12@oracle.com> <70565f43-7547-4047-bca3-f95ae709427e@default> <7b22a1ca-5e6a-c705-90bc-510aa2073c90@oracle.com> <1b962d5d-ae52-4281-8ca8-d6d5558e3fe5@default> <9c521f0e-1f76-420b-bf51-3495c5779b83@default> <5769A88E.9000603@oracle.com> <1b4983f1-6286-4394-8f52-788a1e6bb23b@default> <576EB7FB.8060600@oracle.com> <99E63493-8533-4CDF-810F-8CD7AEDAF69A@oracle.com> Message-ID: <0e7ee984-2e82-4d36-8577-6fd45240331c@default> Hi Brian, Thanks for your inputs. I have updated the new bug https://bugs.openjdk.java.net/browse/JDK-8160327 with same comment. Thanks, Jay From: Brian Burkhalter Sent: Tuesday, June 28, 2016 12:41 AM To: Philip Race Cc: Jayathirth D V; 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail The procedure for this is straightforward: Inside the APP1 Exif marker segment locate the 8-byte TIFF header. >From the last four bytes of the TIFF header obtain the offset to the 0th Image File Descriptor (IFD). Skip all the entries in the 0th IFD. Obtain from the last four bytes of the 0th IFD the offset to the 1st IFD. If the offset to the 1st IFD is zero, there is no thumbnail; otherwise seek to the offset of the 1st IFD. Within the 1st IFD locate and obtain the values of the two entries with tags JPEGInterchangeFormat and JPEGInterchangeFormatLength. These provide respectively the offset to the SOI marker segment of the Exif thumbnail and the length of the Exif thumbnail data. If both of these entries are missing, then the file is aberrant and no thumbnail can be read. If only the JPEGInterchangeFormat entry is present, the thumbnail is likely still readable assuming it has the proper JPEG structure including a terminating EOI marker segment. Seek to the value of the JPEGInterchangeFormat entry and decode the thumbnail. (It might not be a bad safeguard if possible to check that the two bytes at offset JPEGInterchangeFormat + JPEGInterchangeFormatLength - 2 are actually an EOI marker.) It might not be a bad idea to add the above as a comment in the issue to be filed. Brian On Jun 25, 2016, at 9:57 AM, Philip Race wrote: - A follow-on bug should be filed that we do not locate thumbnails inside EXIF APP1 markers. We do not need to parse everything inside the APP1 marker to do this so it should be a moderate but not massive amount of work. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Tue Jun 28 10:04:36 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 28 Jun 2016 15:34:36 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-5049012: PrintToFile option is not disabled for flavors that do not support destination Message-ID: <57724BB4.40602@oracle.com> Hi All, Please review a fix for an issue where it is seen that "Print-To-File" option is enabled even for flavors that do not support Destination attribute even though isAttributeValueSupported for that flavor returns false. Bug: https://bugs.openjdk.java.net/browse/JDK-5049012 webrev: http://cr.openjdk.java.net/~psadhukhan/5049012/webrev.00/ The reason for this behaviour is in Print Dialog code, the validation is done against isAttributeCategorySupported() which still returns true because Pageable and Printable supports it and therefore the "Print-to-File" option gets enabled. But print dialog is shown specific to a doc flavor and a print service (selected one) and hence must validate the attribute against the chosen doc flavor. So, the proposed fix checks the attributevalue is supported or not for that flavor to determine if we need to enable "Print-to-File" option in print dialog. Regards Prasanta From alexander.potochkin at oracle.com Tue Jun 28 13:06:04 2016 From: alexander.potochkin at oracle.com (Alexander Potochkin) Date: Tue, 28 Jun 2016 16:06:04 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8144703: ClassCastException: sun.font.CompositeFont cannot be cast to PhysicalFont In-Reply-To: <5763D54B.1030405@oracle.com> References: <575AAD6A.5040903@oracle.com> <5763D54B.1030405@oracle.com> Message-ID: <56a4d3b3-f10c-b6ed-c117-b793bc24a056@oracle.com> Hello Dmitry Looks good to me! Thanks alexp On 6/17/2016 13:47, dmitry markov wrote: > Reminder. > > Could you review the fix, please? > > Thanks in advance, > Dmitry > On 10/06/2016 15:07, dmitry markov wrote: >> Hello, >> >> Could you review a fix for jdk9, please? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8144703 >> webrev: http://cr.openjdk.java.net/~dmarkov/8144703/webrev.00/ >> >> Problem description: >> If an incorrect font file is used, we unable to initialize the font >> during CompositeFont.doDeferredInitialisation() invocation and assign >> default physical font to the corresponding components entry. Later at >> the same method, (i.e. doDeferredInitialisation()) we try to update >> this entry one more time, since the name retrieved from the entry and >> the name provide by componentNames array are different. The method >> SunFontManager.findFont2D() may return a composite font for such >> case. As a result we get ClassCastException trying to assign >> CompositeFont object to the instance of PhysicalFont. >> >> Fix: >> Surround invocation of SunFontManager.findFont2D() inside >> CompositeFont.doDeferredInitialisation() with 'try-catch' to avoid >> propagation of ClassCastException. >> >> Thanks, >> Dmitry > From philip.race at oracle.com Tue Jun 28 17:38:38 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 28 Jun 2016 10:38:38 -0700 Subject: [OpenJDK 2D-Dev] JDK 9 build with GCC 6.1.1 In-Reply-To: References: <57F3A28D-6FFD-45D6-B85C-1B5638CE29F4@oracle.com> Message-ID: <5772B61E.7060606@oracle.com> On 06/27/2016 08:50 PM, Yasumasa Suenaga wrote: > Hi Kim, > > The newest changes for jdk repos is [1]. > Erik points we should use DISABLED_WARNINGS_gcc to handle unknown > warning tags. [2] > [1] is implemented with it. > > This change is already reviewed by 2d folks. > So I want to merge it ASAP. > > Do you have any objection? > > > Thanks, > > Yasumasa > > > [1] http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007090.html > [2] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004499.html > > > On 2016/06/28 8:37, Kim Barrett wrote: >>> On Jun 25, 2016, at 9:57 AM, Yasumasa Suenaga >>> wrote: >>> >>> Hi all, >>> >>> This review request relates to [1]. >>> >>> I've tried to build OpenJDK 9 at Fedora 24 x64. >>> Fedora 24 has GCC 6.1.1, and OpenJDK 9 build was failed. >>> >>> I fixed build error and several issues (VM crash and internal error) >>> as below: >>> >>> http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot/ >>> >>> Does someone work for it? >>> If no one works for it, I will file it to JBS and will send review >>> request. >>> >>> For jdk repos, I've sent review request [2]. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004494.html >>> [2] http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007081.html >> >> Having gone through these, I think all of them are arising due to >> build system problems, where we seem to have lost the compiler >> configuration to use explicit selection of the language standard and >> some additional options. Do tell more about what this means. Where would this previously have been seen ? Different versions of Visual Studio / CLANG / GCC all emit different warnings and it is not always monotonically increasing with compiler version, and I can imagine someone might want to have different sets of flags in general depending on compiler version in use, but I have not seen a pattern of this being applied to the warnings on any of the platforms. in the makefile here there is just one special case of this .. 474 # Suppress gcc warnings like "variable might be clobbered by 'longjmp' 475 # or 'vfork'": this warning indicates that some variable is placed to 476 # a register by optimized compiler and it's value might be lost on longjmp(). 477 # Recommended way to avoid such warning is to declare the variable as 478 # volatile to prevent the optimization. However, this approach does not 479 # work because we have to declare all variables as volatile in result. 480 #ifndef CROSS_COMPILE_ARCH 481 # CC_43_OR_NEWER := \ 482 # $(shell $(EXPR) $(CC_MAJORVER) \> 4 \| \ 483 # \( $(CC_MAJORVER) = 4 \& $(CC_MINORVER) \>= 3 \) ) 484 # ifeq ($(CC_43_OR_NEWER), 1) 485 # BUILD_LIBJAVAJPEG_CFLAGS_linux += -Wno-clobbered 486 # endif 487 #endif >> >> For now I think we should fix the build system problems, and file >> additional bugs or update existing ones as needed to fix the root >> causes of the problems encountered. I think many of the proposed >> changes do not address the root causes, and should not be made. See >> my comments for the specific bugs. >> >> I'm not on the mailing list where the jdk RFR was submitted. I took a >> look at them though, and >> >> ------------------------------------------------------------------------------ >> >> make/lib/Awt2dLibraries.gmk >> 407 # Avoid warning for GCC 6 >> 408 ifeq ($(TOOLCHAIN_TYPE), gcc) >> 409 LCMS_CFLAGS += -Wno-misleading-indentation >> 410 endif >> >> 926 # Avoid warning for GCC 6 >> 927 ifeq ($(TOOLCHAIN_TYPE), gcc) >> 928 BUILD_LIBSPLASHSCREEN_jdhuff.c_CFLAGS += >> -Wno-shift-negative-value >> 929 BUILD_LIBSPLASHSCREEN_jdphuff.c_CFLAGS += >> -Wno-shift-negative-value >> 930 endif >> >> The -Wmisleading-indentation and -Wshift-negative-value options are >> new in gcc 6. gcc has for some time (starting with gcc 4.4) silently >> ignored unrecognized -Wno-XXX options. But some folks (like SAP) are >> still using older versions. So these will need to be conditionalized >> on the gcc version. >> >> ------------------------------------------------------------------------------ >> >> src/java.desktop/share/native/libfontmanager/layout/SunLayoutEngine.cpp >> 154 if (min < 0) min = 0; >> 155 if (max < min) max = min; /* defensive coding */ >> >> [splitting the line] >> >> Seems like this would be suppressed by -Wno-misleading-indentation, >> especially since the reported warning is for that. Why change both >> the code and the build configuration? Was that something seen in the original fix ? It is not in the version I reviewed. The current version of the fix does not update the makefile to add this .. except for LCMS - which is a different library. -phil. >> >> ------------------------------------------------------------------------------ >> >> >> The changes in AlphaMath.c and splashscreen_jpeg.c look ok. >> From james.graham at oracle.com Tue Jun 28 20:40:36 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 28 Jun 2016 13:40:36 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8153943 : In PixelInterLeavedSampleModel and BandedSampleModel we dont need hashCode() method In-Reply-To: References: Message-ID: <9fae0981-42a0-1af5-0de0-45f131b8555b@oracle.com> Still hoping to hear an opinion from Phil on this... The alternative is to add equals() overrides in the subclasses that just do "obj instanceof && super.equals()" which would only matter in some specific somewhat degenerate cases. The intent would be that even though the layout and pixel fetching behavior for a specific configuration of PISM and BSM are identical, they are philosophically not the same and so should not evaluate as equals()... ...Or, should they? ...jim On 6/27/16 4:05 PM, Jim Graham wrote: > This is odd that two completely different classes have identical "equals()" methods. After looking into it in more > detail it looks as if ComponentSM is implemented as a general case that can encompass either PixelInterleaved or Banded > pixel layouts - which means the subclasses are mostly just cosmetic (offering the constructors that make most sense if > the pixels are laid out in the different ways) and only Banded offers a different implementation of getDataElements > which is only different from the super implementation by virtue of eliminating a "multiply by a number which we know to > be 1". > > There are also some restrictions in the constructors that enforce limits on the various values that CSM allows in its > general implementation, so it isn't possible to use the PixelInterleaved constructor to create an arbitrarily-valued CSM > nor to use the Banded constructors for the same purpose. The overlap in the type of CSM you can create from each of > their constructors is very tiny to non-existant. > > The end result is that it ends up being infeasible to define a PixelInterleaved and a Banded SM that are equals() (not > impossible, but you'd have to have a very degenerate case like a 1x1 image to make it through the various restrictions > in the constructors and the offsets and the scanline strides and pixel strides, etc.). It's really odd in theory, and > while not a problem in practice it still feels as if it violates an expectation. The primary restrictions I see getting > in the way of different classed objects being equals() is that Banded forces a pixel stride of 1 and PixelInterleaved > enforces that all band offsets are smaller than the scan stride. > > So, technically, I don't see any issue with just removing the hash method as the webrev proposes, but I'd like to see > Phil's reaction to the situation we are in here with respect to intent vs. theory vs. practice vs. developer expectation... > > ...jim > > On 6/24/16 10:34 AM, Jayathirth D V wrote: >> Hi, >> >> Please find following changes for review in JDK9 : >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8153943 >> >> Webrev : http://cr.openjdk.java.net/~jdv/8153943/webrev.03/ >> >> Issue : We have hashCode() method in PixelInterleavedSampleModel and BandedSampleModel, but we don't have >> corresponding equals() method. >> >> Solution : In PixelInterleavedSampleModel and BandedSampleModel we don't have unique properties that are specific to >> these subclasses and we have proper equals() & hashCode() method in parent class ComponentSampleModel. So removed >> hashCode() method present in PixelInterleavedSampleModel and BandedSampleModel. >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Wednesday, May 04, 2016 2:44 AM >> To: Phil Race >> Cc: 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8153943 : In java.awt.image package some of the classes are >> missing hashCode() or equals() method >> >> Yes, the equals/hashcode chapter in Effective Java includes rules about ignoring fields that can be calculated from >> other fields (which applies to most internal fields). Basically, only things in the constructors tend to be good >> candidates for equals/hashcode... >> >> ...jim >> >> On 5/3/2016 2:00 PM, Phil Race wrote: >>> On 04/26/2016 04:10 PM, Jim Graham wrote: >>>> The ComponentColorModel implementation is a meaningless wrapper >>>> around super.equals/hashCode(). Why does it not test CCM-specific fields? >>> >>> It should although this looks like it is more than just running >>> through all the fields and testing them for equality. >>> eg it looks like "initScale()" should be called if necessary before >>> determining equality and the field "needScaleInit" is not one that has >>> to be directly included in the equality comparison. >>> >>> -phil. >>> >>> >>> >>>> >>>> The ComponentSampleModel.hashCode() method should be upgraded based >>>> on the recommendations in Effective Java like the other methods here. >>>> >>>> PixelInterleavedSampleModel and BandedSampleModel also have a >>>> meaningless override of super.equals/hashCode(). >>>> >>>> And all of these classes suffer from casting to the specific type >>>> before verifying its class as I mentioned in the ICM.equals() review... >>>> >>>> ...jim >>>> >>>> On 4/25/16 2:31 AM, Jayathirth D V wrote: >>>>> Hi Jim, >>>>> >>>>> I have made changes to include check for class equality in base >>>>> class and use super.equals() from subclasses. >>>>> Please find updated webrev for review : >>>>> http://cr.openjdk.java.net/~jdv/8153943/webrev.02/ >>>>> >>>>> Change related to ColorModel is present in JDK-7107905 review. >>>>> >>>>> Thanks, >>>>> Jay >>>>> >>>>> -----Original Message----- >>>>> From: Jim Graham >>>>> Sent: Saturday, April 23, 2016 7:30 AM >>>>> To: Phil Race; Jayathirth D V >>>>> Cc: 2d-dev at openjdk.java.net >>>>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8153943 : In >>>>> java.awt.image package some of the classes are missing hashCode() or >>>>> equals() method >>>>> >>>>> This is actually a pretty nasty issue that Joe Darcy also brought up >>>>> in the CCC review. >>>>> >>>>> In order to have symmetric testing of .equals(), we pretty much have >>>>> to enforce this test at all levels, including in the original >>>>> ColorModels.equals() method. If we don't enforce this in >>>>> CM.equals(), then we could run ccm.equals(othercm) and it would >>>>> return false because the class is wrong, but turning it around and >>>>> testing >>>>> othercm.equals(ccm) would succeed because it doesn't enforce the >>>>> class equality. >>>>> >>>>> So, I'd recommend that CM.equals() tests getClass() == getClass() at >>>>> the base level and then all others will use super.equals() and get >>>>> the same protection. It means you can't have a subclass of CCM be >>>>> "equals" to a different subclass of CCM, but that's an unfortunate >>>>> issue with equals needing to honor symmetry... :( >>>>> >>>>> ...jim >>>>> >>>>> On 4/20/2016 10:17 AM, Phil Race wrote: >>>>>> Hi, You removed the following test in CCM.java : 2941 if >>>>>> (obj.getClass() != getClass()) { >>>>>> 2942 return false; >>>>>> >>>>>> 2943 } >>>>>> >>>>>> What this means is that before your change an instance of a >>>>>> subclass of CCM would never be equals() to any direct >>>>>> instantiatation of CCM but after your change it can be. I suspect >>>>>> the condition was there on purpose. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 04/20/2016 05:45 AM, Jayathirth D V wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>> >>>>>>> _Please review the following fix in JDK9:_ >>>>>>> >>>>>>> >>>>>>> >>>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8153943 >>>>>>> >>>>>>> >>>>>>> >>>>>>> This is subtask of >>>>>>> https://bugs.openjdk.java.net/browse/JDK-6588409 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Webrev : http://cr.openjdk.java.net/~jdv/8153943/webrev.00/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Issue : Some of the java.awt.image classes are missing either >>>>>>> equals() or hashCode() method. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Solution : Add missing equals() or hashCode() methods. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Jay >>>>>>> >>>>>>> >>>>>>> >>>>>> >>> From jayathirth.d.v at oracle.com Wed Jun 29 11:13:26 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 29 Jun 2016 04:13:26 -0700 (PDT) Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods In-Reply-To: <6341d4b6-f281-3f58-efc3-32d1ed0ecc42@oracle.com> References: <6f83b633-3910-47fa-b872-e042fe4c24d3@default> <24ca2994-aa27-4a70-8cf9-0bda35664f3f@default> <574809B2.5040901@oracle.com> <9f641938-f979-4021-9e94-bde47e1d3c67@default> <57489033.7020901@oracle.com> <77d5b327-066b-4d86-a44d-8e681aeb71f8@default> <574DE3F9.40709@oracle.com> <574E0717.5060405@oracle.com> <574E0DF9.20508@oracle.com> <574E10B0.4070003@oracle.com> <574E13BD.9060701@oracle.com> <9a87056b-2646-4d5f-bfec-d50bea489381@default> <574F0EFE.2070300@oracle.com> <2e485b6b-3df0-41db-ba40-a96528883e95@default> <20a4c021-6814-9423-2891-c45c1ab94396@oracle.com> <0042f492-5fc4-481c-8b2d-35a242a5af93@default> <6341d4b6-f281-3f58-efc3-32d1ed0ecc42@oracle.com> Message-ID: Hi, Since Joe mentioned to add information related to what fields we are using to calculate equals() method in ColorModel and its subclasses I have updated the spec for the same. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/7107905/webrev.11/ Thanks, Jay -----Original Message----- From: Jim Graham Sent: Saturday, June 04, 2016 4:52 AM To: Jayathirth D V; Philip Race Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods That looks good to me. Has the CCC cleared yet? ...jim On 6/3/16 2:49 AM, Jayathirth D V wrote: > Hi Jim, > > Oh that's an important change. > Thanks for your review. > > I have updated ColorModel constructor to copy nBIts only of numOfComponents length and I have removed validBits check in hashCode() of ICM. > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/7107905/webrev.10/ > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Friday, June 03, 2016 2:25 AM > To: Jayathirth D V; Philip Race > Cc: 2d-dev at openjdk.java.net > Subject: Re: Review Request for JDK-7107905: ColorModel subclasses are > missing hashCode() or equals() or both methods > > I just noticed a hashCode/equals violation that we created a few revisions ago. We compute the hash of the validBits in ICM, but we only compare validBits up to the number of colors in the colormap. One could construct two ICMs that have different validBits that are identical in the first N bits (N = number of colors), but have different bits beyond that, and those 2 ICMs would evaluate as equals(), but their hashcodes would be different. > > Possible solutions: > > - Truncate validBits when it is accepted in the constructor > (validBits.and(...)) > - Manually compute the hash of the first N bits of validBits > - Not use validBits in the hash code since it is allowed to omit > significant data from the hash > > (Note that everything in hashcode must participate in equals(), but > not vice versa) > > The same is true of nBits in ColorModel. (nBits can be copied and > truncated with Arrays.copyOf) > > The same is *not* true of maskBits in PCM since the constructor creates an array of the precise length it needs... > > ...jim > > On 6/2/16 7:07 AM, Jayathirth D V wrote: >> Hi Phil, >> >> I have updated the code with all the changes I mentioned previously. I am caching hashCode when first time hashCode() is called. >> Please find the updated webrev for review: >> http://cr.openjdk.java.net/~jdv/7107905/webrev.09/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Philip Race >> Sent: Wednesday, June 01, 2016 10:06 PM >> To: Jayathirth D V >> Cc: Jim Graham; 2d-dev at openjdk.java.net >> Subject: Re: Review Request for JDK-7107905: ColorModel subclasses >> are missing hashCode() or equals() or both methods >> >> Please post the updated webrev. >> >> -phil. >> >> On 6/1/16, 12:02 AM, Jayathirth D V wrote: >>> Hi Phil& Jim, >>> >>> Collating all the changes needed: >>> 1) I have removed both equals()& hashCode() in CCM but forgot to add the file while creating webrev. I will include changes in CCM in updated webrev. >>> 2) Caching of hashCode value in IndexColorModel& PackedColorModel : >>> We can cache hashCode value when constructor is called or when hashCode() is called for first time. What approach we have to follow? >>> 3) Comment section of equals() method, I will update it to : >>> 1449 * the target object must be the same class (and not a subclass) as this >>> 4) I will use .equals() to compare colorSpace values in CM.equals() so it will be like we are not intending ColorSpace class to never override equals() method. >>> >>> Please let me know your inputs. >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Jim Graham >>> Sent: Wednesday, June 01, 2016 4:14 AM >>> To: Phil Race >>> Cc: Jayathirth D V; 2d-dev at openjdk.java.net >>> Subject: Re: Review Request for JDK-7107905: ColorModel subclasses >>> are missing hashCode() or equals() or both methods >>> >>> I think we should use .equals() here, otherwise it looks like a recommendation that the intent is for those classes to never implement it... >>> >>> ...jim >>> >>> On 05/31/2016 03:31 PM, Phil Race wrote: >>>> I don't know of any design intent, so yes, I meant more as a >>>> practical matter. >>>> Unless they subclass then using equals() which I thought unlikely >>>> it makes no difference here. >>>> But it would be proof against that to use equals, unlikely to >>>> matter as it might be .. >>>> >>>> -phil. >>>> >>>> On 05/31/2016 03:19 PM, Jim Graham wrote: >>>>> >>>>> On 05/31/2016 02:50 PM, Phil Race wrote: >>>>>> On 05/31/2016 12:20 PM, Jim Graham wrote: >>>>>>> Hi Jay, >>>>>>> >>>>>>> You were going to remove hashCode/equals from CCM, but instead >>>>>>> you simply removed it from the patch. You still need to edit it >>>>>>> to remove the existing methods. >>>>>> Oh yeah ! CCM is gone from the latest webrev. I expect that was >>>>>> not intentional. >>>>>> >>>>>>> Also, I'm not sure == is a good way to compare ColorSpace >>>>>>> instances >>>>>>> - Phil? >>>>>> Neither ColorSpace nor ICC_ColorSpace over-ride equals or >>>>>> hashCode and all the predefined ones are constructed as >>>>>> singletons so it seems unlikely to cause problems >>>>> Should it use .equals() on principle, though? Otherwise we are >>>>> baking in the assumption that it doesn't implement equals() into >>>>> our implementation of the CM.equals() method. Might it some day >>>>> implement equals (perhaps it isn't a practical issue today, but it >>>>> might be in the future when we forget that it was omitted in this >>>>> usage we create today). >>>>> >>>>> I guess what I'm asking is if it is a design feature that >>>>> different objects are considered non-equal (such as an object >>>>> that, for instance, has only predetermined instances that are >>>>> shared by reference and reused). I think color spaces are sort of >>>>> in-between in that we define a few constants that simply get used >>>>> by reference in 99% of cases, but that isn't a design feature, >>>>> more like a practical issue... >>>>> >>>>> ...jim From philip.race at oracle.com Wed Jun 29 17:17:59 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 29 Jun 2016 10:17:59 -0700 Subject: [OpenJDK 2D-Dev] [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni In-Reply-To: <577209F0.9080309@oracle.com> References: <2c20f37e-7eae-499c-9a70-bb3dd06da636@default> <5770C5B4.9090600@oracle.com> <29611571-bc4e-4180-9aa7-0b055bcf0a8b@default> <577209F0.9080309@oracle.com> Message-ID: <577402C7.6040505@oracle.com> https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/design.html#exception_handling lists DeleteLocalRef as safe to call with a pending exception. So here ... 74 fullnameLC = (*env)->CallObjectMethod(env, fullname, 175 fmi->toLowerCaseMID, fmi->locale); 176 if ((*env)->ExceptionCheck(env)) { 177 (*env)->ExceptionClear(env); 178 /* Delete the created references */ 179 DeleteLocalReference(env, fullname); 180 return 1; 181 } ... perhaps what we should do is not clear the exception and with the goal that after returning from this function we can check in the caller for a pending exception and return from JNI to Java *without clearing it* - so that Java code gets that exception propagated. I suggest this because I think we would have a correctness issue which should be reported - not swallowed - if there ever really was one. I think this means that the GDI callbacks need to check for a pending exception on entry and bail since once we hand off to windows it may be called repeatedly. But also we should stop enumeration if we detect an error hence we should return 0 in this case, not 1 per the docs forEnumFontFamExProc --- https://msdn.microsoft.com/en-us/library/windows/desktop/dd162618(v=vs.85).aspx Return value The return value must be a nonzero value to continue enumeration; to stop enumeration, the return value must be zero. --- Also the "A" functions are now obsolete. No win 98 support any more :-) We should just delete them instead of updating them. And I'd prefer the test be verified on Solaris rather than excluding it -phil On 6/27/16, 10:24 PM, Prasanta Sadhukhan wrote: > Looks good to me. Only thing is in test script, you need to add > copyright 2015, 2016 as the script is originally written in 2015 and > you cannot omit the created year from the copyright. > > Regards > Prasanta > On 6/27/2016 4:17 PM, Prahalad Kumar Narayanan wrote: >> Hello Everyone >> >> Good day to you. >> >> Quick follow up to fix for the Bug >> Bug ID : JDK-8152971 >> Bug Link : https://bugs.openjdk.java.net/browse/JDK-8152971 >> >> First, Thanks to Prasanta for his review & suggestions. >> >> I 've incorporated some of the review suggestions & updated the webrev. >> Webrev Link : >> http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.02/ >> >> Overview on changes from previous webrev: >> >> 1. Code Changes: As Prasanta mentioned, >> The variable fontStrLC should be used in place of fontStr >> - The correction has been taken up. >> And releaseGdiFontMapReferences call is not required when >> GdiFontMapInfo object isn't initialized - The particular invocation >> has been removed. >> >> 2. With regard to deleting references held within GdiFontMapInfo >> struture >> JNI creates local references only for objects that are >> created at the Java side - jobject, jstring and jclass >> The other FMI variables - method IDs are not references to >> objects. Hence invoking deleteLocalRef.. is not valid (may not >> compile too). >> >> 3. The Jtreg shell script - LoadFontsJNICheck.sh was initially >> written to run only on MacOS. >> Since it addresses the bug at hand (which is on windows), I >> tested the script 's execution on Win and Linux. >> The Jtreg script passes on linux and fails on windows >> with warnings in java.lang codebase. >> As I understand, there is a JBS bug filed already >> pertaining to JNI warnings in java.lang package. >> Hence enabling the script on windows, doesn't >> introduce new bug. >> The only OS that the script doesn't run - Solaris. >> Presently, we don't have a Solaris environment at our >> facility to test the script. >> Hence the original functionality on Solaris is retained. >> >> Kindly take a look at the changes at your convenience & provide the >> suggestions. >> >> Thank you for your review >> Have a good day >> >> Prahalad N. >> >> >> >> From: Prasanta Sadhukhan >> Sent: Monday, June 27, 2016 11:51 AM >> To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net >> Cc: Philip Race; Jayathirth D V; Praveen Srivastava >> Subject: Re: [9] Review Request- JDK-8152971- JNI Warning with >> -Xcheck:jni >> >> I guess this method(s) should take "fontStrLC" instead of "fontStr" >> 650 (*env)->CallObjectMethod(env, fontToFileMap, >> fmi->putMID, >> 651 fontStr, fileStr); >> >> 692 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, >> 693 fontStr, fileStr); >> >> 762 (*env)->CallObjectMethod(env, fontToFileMap, >> fmi->putMID, >> 763 fontStr, fileStr); >> >> 805 (*env)->CallObjectMethod(env, fontToFileMap, fmi->putMID, >> 806 fontStr, fileStr); >> It seems this line is not needed as we have not populated fmi >> structure yet. >> 882 releaseGdiFontMapReferences(env, &fmi); >> >> Why aren't we deleting >> fmi->env,fmi.arrayListCtr,fmi.addMID,fmi.putMID in >> releaseGdiFontMapReferences()? >> >> Also, it seems earlier the testscript was supposed to execute only on >> Mac but now you are extending the execution platform to windows and >> linux as well excluding only solaris. >> Is there any particular need to restrict solaris too? >> >> Regards >> Prasanta >> >> >> On 6/24/2016 7:34 PM, Prahalad Kumar Narayanan wrote: >> Hello Everyone on Java2D Forum >> Good day to you. >> A Quick follow-up on webrev to fix the following issue >> Bug ID : JDK-8152971 / -Xcheck:jni - warning in native >> method >> Bug Link : >> https://bugs.openjdk.java.net/browse/JDK-8152971?filter=-1 >> Updated webrev link: >> http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.01/ >> Description on Changes >> . The previous webrev contained changes to additional files >> which are not related to the current bug in concern. >> . Henceforth, the updated webrev limits the changes to only >> fontpath.c and a Jtreg test script to verify the change. >> Regarding Build & Test >> . Though the changes pertain to windows specific code, >> internal build system was triggered to ensure safe build on all >> supported platforms. >> . In addition, no new Jtreg failures were found with the >> proposed changes. >> Kindly review the changes at your convenience & provide your feedback. >> Thank you for your time in review >> Have a good day >> Prahalad N. >> -----Original Message----- >> From: Prahalad Kumar Narayanan >> Sent: Wednesday, June 22, 2016 3:20 PM >> To: 2d-dev at openjdk.java.net >> Cc: Philip Race; Prasanta Sadhukhan; Jayathirth D V; Praveen Srivastava >> Subject: [9] Review Request- JDK-8152971- JNI Warning with -Xcheck:jni >> Hello Everyone, on Java2D Group >> Good day to you. >> Please find herewith, webrev changes to fix the bug- >> Bug ID : JDK-8152971 / -Xcheck:jni - warning in native >> method >> Bug Link : >> https://bugs.openjdk.java.net/browse/JDK-8152971?filter=-1 >> Webrev : >> http://cr.openjdk.java.net/~pnarayanan/8152971/webrev.00/ >> Description on Bug: >> 1. Too many JNI warnings are reported in the native functions >> when test-code is run with VM Option: -Xcheck:jni >> 2. The warnings can be classified into 2 categories >> a. JNI warnings that are thrown due to the missing >> exception checks after an Up call ( JNI function invoking Java method ) >> b. JNI warnings that are thrown due to increased >> usage of Local Reference objects. >> Description on the Fix: >> 1. File : FontPath.c >> Added JNIEnv->ExceptionCheck() and >> ExceptionClear() where Up call is invoked. >> The checks are added only to the valid Up >> calls as per JNI spec. >> Added JNIEnv->DeleteLocalRef where the native >> functions created Java side objects but did not delete their local >> reference after usage. >> A few of the native functions get invoked >> as Callbacks to Windows APIs following the font enumeration. >> Therefore at each callback, the count of >> active local references would increase. >> Over time, the active local >> references would exceed the planned number of local references set by >> JVM. >> 2. File : awt_Component.cpp >> Added JNIEnv->ExceptionCheck() and >> ExceptionClear() where an Up call displayed a JNI warning while >> running the Jtreg test script. >> Information on Jtreg test script is given below. >> 3. File : LoadFontsJNICheck.sh >> The shell script is already a part of JTreg test >> case & invokes LoadFontsJNICheck with -Xcheck:jni VM option >> However, the script was configured to run only on >> Mac OS. Now, the script is modified to run on windows, linux and mac >> systems. >> This way, the code changes can be >> checked for proper execution with test-case. >> Kindly review the changes at your convenience and share your feedback. >> Thank you for your time in review >> Have a good day >> Prahalad N. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Jun 29 17:31:56 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 29 Jun 2016 10:31:56 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6218397:Printing to file does not throw a PrinterException if the file cannot be created In-Reply-To: <576BBCA8.2080800@oracle.com> References: <576180D4.9040502@oracle.com> <1209f6f2-36df-6655-c542-d3836b11ff71@oracle.com> <7461a8f1-5263-a7b8-3dab-a4bd0733890b@oracle.com> <576BBCA8.2080800@oracle.com> Message-ID: <5774060C.3010205@oracle.com> if (f.exists()) f.delete(); should use { ... } for the body - 2 cases of this one in each of the modified files. Other than that OK. I don't need to see an updated webrev so long as you make those syntactic changes. -phil On 6/23/16, 3:40 AM, Prasanta Sadhukhan wrote: > Hi Phil, All, > > Based on the offline discussion, I added the case when disk gets > filled while writing to the file. > Since PrintStream does not throw IOException, I added check for > checkError() to do the corresponding error handling. I added it after > flush() as that is where the stream will be written to the file. > http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.03/ > > Regards > Prasanta > On 6/20/2016 12:01 PM, prasanta sadhukhan wrote: >> >> Hi Phil,All, >> >> Added file delete in another case where we throw PrinterException. >> http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.02/ >> >> Regards >> Prasanta >> On 6/16/2016 1:40 PM, prasanta sadhukhan wrote: >>> >>> Modified webrev to close output stream. >>> >>> http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.01/ >>> >>> Regards >>> Prasanta >>> On 6/15/2016 9:52 PM, Philip Race wrote: >>>> If this is executed on Windows (shared Postscript stream printer >>>> could do this) >>>> then since the output stream is still open I expect the delete will >>>> fail. >>>> Attempt to close the open stream first (in a try .. catch I suppose). >>>> >>>> -phil. >>>> >>>> On 6/15/16, 3:25 AM, prasanta sadhukhan wrote: >>>>> >>>>> Hi All, >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6218397 >>>>> >>>>> The issue was if the linux disk is full and we are trying to >>>>> "print to file" then PrinterException is not thrown and a 0 byte >>>>> file is created. >>>>> >>>>> Although I am not able to reproduce this behaviour, because when I >>>>> make my disk full and try to run "java", I get >>>>> >>>>> /Java HotSpot(TM) Server VM warning: Insufficient space for shared >>>>> memory file:// >>>>> // 13783// >>>>> //Try using the -Djava.io.tmpdir= option to select an alternate >>>>> temp location./ >>>>> >>>>> but on investigating this, I see that we are calling >>>>> f.createNewFile() in RasterPrinterJob#validateDestination() which >>>>> creates a new, empty file >>>>> >>>>> but if there is any exception in PSPrinterJob#startDoc this file >>>>> is not deleted. >>>>> >>>>> Modified the code to make sure if there is any exception, delete >>>>> the file. >>>>> >>>>> http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.00/ >>>>> >>>>> Regards >>>>> Prasanta >>>>> >>>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Jun 29 17:59:39 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 29 Jun 2016 10:59:39 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6789262: getPageFormat doesn't apply PrintRequestAttributeSet specified In-Reply-To: <57710D96.8010808@oracle.com> References: <57710D96.8010808@oracle.com> Message-ID: <57740C8B.10609@oracle.com> This is actually a little subtle. The check you are deleting has been there since 2000 .. and it can't just be removed. But it need adjusting. This is the subtlety. Most of the attribute checks are yes/no. I think for this one we need to look at the actual dimensions and return true if it is "fits" So isSupportedMediaPrintableArea needs to do more than "equals" I am not 100% sure that won't surprise some other code but as far as I can think right now it seems the right thing to do. -phil. On 6/27/16, 4:27 AM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix for an issue where it was found that setting left > margin of 2" is ignored and when we query > PrinterJob.job.getPageFormat(PrintRequestAttributeSet) > we get the default paper mediapritable area of x=1" instead of the set 2". > > Bug: https://bugs.openjdk.java.net/browse/JDK-6789262 > webrev: http://cr.openjdk.java.net/~psadhukhan/6789262/webrev.00/ > > This is because > it was found that getPageFormat() calls > Win32PrintService#isAttributeValueSupported() where we call > isSupportedMediaPrintableArea() > to check if the mediaprintable area is matching with the media size > that has been cached. It gets the paperID by calling findPaperID() and > stores the mpa of that paper in MediaPrintableArea[] > I see that my printer supports 43 mediasize names (like iso_a4, > iso_a5, na_letter etc) and none of the 43 mediaPrintables equals the > mpa value of (50.4, 25.4, 133.8, 246.2)mm > > ---------------isSupportedMediaPrintableArea()--------- > if (mediaPrintables != null) { > for (int i=0; i if (mpa.equals(mediaPrintables[i])) { > return true; > } > } > } > ---------------------- > So, it seems this check isSupportedMediaPrintableArea() is preventing > valid mpa values to be propagated to RasterPrinterJob to be used for > printing. > > I see in linux and mac, *IPPPrintService*#isAttributeValueSupported() > is called which does not have this isSupportedMediaPrintableArea() > check and there this left margin of 2" is not ignored and stored properly. > > So, the proposed fix do away with this isSupportedMediaPrintableArea() > call from Win32PrintService#isAttributeValueSupported. > > Regards > Prasanta > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Jun 29 18:26:00 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 29 Jun 2016 11:26:00 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : IIOException while getting second image properties for JPEG In-Reply-To: <07359798-1d65-44ad-9d94-044564564828@default> References: <07359798-1d65-44ad-9d94-044564564828@default> Message-ID: <577412B8.8030006@oracle.com> On 6/27/16, 12:38 AM, Jayathirth D V wrote: > > Hi Phil, > > Thanks for your review. > > I have removed all the references to ?for JPEG with embedded > thumbnail? and updated the information in test case, description and > file names. > > Please find updated webrev for review: > > http://cr.openjdk.java.net/~jdv/8152672/webrev.03/ > > Approved. -phil. > > I have created new bug to support thumbnails present in APP1 marker : > https://bugs.openjdk.java.net/browse/JDK-8160327 > > I was also wondering that APP2 markers can contain FlashPix data, > thanks for the clarification. > > Regards, > > Jay > > *From:*Philip Race > *Sent:* Saturday, June 25, 2016 10:28 PM > *To:* Jayathirth D V > *Cc:* 2d-dev at openjdk.java.net > *Subject:* Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : > Exception while getting second image properties for JPEG with embedded > thumbnail > > Hi, > > So my conclusion is as follows : > > - in both these images, there is a thumbnail but it is inside the APP1 > marker and we never even see it. So the synopsis reference to > "for JPEG with embedded thumbnail" is completely misleading .. wrong even. > > We should just delete that part from the synopsis and update the > test names and description to eliminate reference to that. > After that the fix should be good to go. > > - A follow-on bug should be filed that we do not locate thumbnails > inside EXIF APP1 markers. We do not need to parse everything inside > the APP1 marker to do this so it should be a moderate but not > massive amount of work. > > - The APP2 markers appear to be FlashPix data since these > follow EXIF/APP1 data and I understand they may use > multiple APP2s because the marker segment has a size limit of 64K > (the size is a two byte quantity). So we can ignore this. > > -phil. > > > On 6/23/16, 5:10 AM, Jayathirth D V wrote: > > Hi Phil, > > > > We have two images with which we can reproduce the issue: > > 1) sample.jpg - Image attached in JBS > > 2) JpegEmbedThumbnail.jpg - Image present in webrev. > > > > I have attached image for difference in markers if we skipbytes for length and without skipping and parsing serially for both the images. It also mentions all the markers present in both the images. > > Also I have attached metadata information extracted for both the images usinghttp://www.sno.phy.queensu.ca/~phil/exiftool/ . > > > > Regarding the thumbnails : > > In both the images we have thumbnail inside APP1(EXIF) marker, I have extracted the thumbnails using exiftool . The information that we have of thumbnail present APP1 markers match the thumbnail information present in exiftool metadata. > > > > In JPEGMetadata.java constructor we are not parsing APP1 marker and storing it as a marker segment. That is why in both the cases we are seeing thumbnails as 0. This looks like separate issue of not considering thumbnail data present in APP1 markers. > > > > In sample.jpg the 640*480 image present after 3968*2976 image is preview image. It is stored for showing preview in Camera display and it is not EXIF embedded thumbnail. We have thumbnail data present in APP1 marker and it is of dimensions 160*120, we can extract the same using exiftool. In JpegEmbedThumbnail.jpg both main image and thumbnail are of same size 64*48(I have kept main image size to be as small as possible since it will be checked in). > > > > Regarding embedded ICC profile: > > JpegEmbedThumbnail.jpg has one image with embedded thumbnail in APP1 marker. It has many APP2 markers and we are parsing it for given ImageIndex using gotoImage() and readNativeHeader(). > > > > Please let me know your inputs. > > > > Thanks, > > Jay > > > > -----Original Message----- > > From: Phil Race > > Sent: Wednesday, June 22, 2016 2:20 AM > > To: Jim Graham > > Cc: Jayathirth D V;2d-dev at openjdk.java.net > > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : Exception while getting second image properties for JPEG with embedded thumbnail > > > > No issues with the exceptions as such. > > > > Whilst this does make things better I still have some reservations about the result of the fix since remember the bug says "JPEG with embedded thumbnail". > > > > If I apply your patch and use the original file I get two images but neither reports any thumbnails .. using either metadata or > > ImageReader.getNumThumbnails(int) > > > > One image is 3968x2976, the other is 640x480 (vga resolution). > > This seems a little big for a thumbnail but still a lot smaller than the original and a nice size for say using on a camera display. > > So my suspicion is the latter is an EXIF embedded thumbnail - since it is JPEG compressed and that ideally what we should return here is one image with one thumbnail. > > > > But since we aren't properly parsing the EXIF APP1 data .. we just find it as another image using the 'brute force' method of looking for the marker sequence. > > I am a bit surprised though that this hasn't been a more common complaint. > > > > We now have the TIFF code so if this really is the case then a fuller fix would return this as a thumbnail. If it really is a follow-on second image in the stream then the fix would seem OK. I just want to know which we have here > > > > Then we get to the image you used in the test. Yes, this throws an exception with 8ux .. but it is a different complaint. > > > > With the original file :- > > Exception in thread "main" javax.imageio.IIOException: Not a JPEG file: > > starts with 0xff 0xff > > > > > > With the test file :- > > Exception in thread "main" javax.imageio.IIOException: Not a JPEG file: > > starts with 0xff 0xe2 > > > > That's an APP2 marker .. which may mean an embedded ICC Profile. > > The code is supposed to be able to handle thathttps://docs.oracle.com/javase/8/docs/api/javax/imageio/metadata/doc-files/jpeg_metadata.html#color > > .. so perhaps its something else but it would be nice to know this is being handled properly. > > > > Also - back to thumbnails - this one reports zero thumbnails too ! > > > > So with the test and the fix being all about embedded thumbnails it is weird that there aren't any :-) > > > > I think we need to break down the exact contents/structure of these files to be sure what we have here. > > > > -phil. > > > > On 06/14/2016 09:30 PM, Jim Graham wrote: > > Hi Jay, > > > > Thanks for explaining all of the details. It seems that constantly > > being in scan mode simplifies things because we have to be in scan > > mode for entropy data anyway, but it still allows errant bytes outside > > of the entropy data to be accepted by this parser. I'm not sure if > > that is a problem in the long run, but it is not a new issue (since > > the existing code already was doing that) so we can live with it for > > purposes of fixing this particular bug. > > > > One simplification of what you say below, it appears that among all of > > those cases none of them really impact the fact that un-sized entropy > > encoded data only appears inside the SOS marker and the only markers > > found inside the entropy data itself are the RSTn markers. Ideally we > > could limit our scanning to just the data following the SOS marker and > > its sized header and only allow RSTn markers to appear inside that > > manual scan, reverting to a non-scanning mode when we reach another > > marker (DNL it looks like). But, that would be the subject of a > > different bug fix. > > > > It looks OK to me as long as Phil is OK with the types of exceptions > > that you are throwing in the various new exceptional cases, and with > > the change to now assume that skipImage always being called at an SOI > > marker. Phil? > > > > ...jim > > > > On 6/14/16 9:36 AM, Jayathirth D V wrote: > > Hi Jim, > > > > I have updated the code to add check for EOF even in case of reading > > length. Also I have updated the code such that in all the cases where > > we find EOF before EOI we are throwing IndexOutOfBoundsException and > > in other failed cases we are throwing IOException. > > > > More analysis : > > All the length markers that we are checking in our case have > > valid length data except SOS marker in which always the length value > > will be 12 and it is the value only for the length of Scan header. > > After Scan header(SOS) we have compressed data for which we have > > no parameter which gives the length so that we can skip it completely. > > Once we get to the initial SOS header it can take 3 paths based > > on how the data follows: > > a) If we don't have Restart enabled and if we scan > > continuously through compressed data we will find EOI otherwise we > > will find RST markers and then EOI marker. > > b) If we have multiple scan headers(Multi-scan scenario) we > > have to follow point 'a' in loop with each scan header separated by > > DNL and other miscellaneous tables. > > c) If we have multiple frame headers(Multi-frame scenario) we > > have to follow point 'b' in loop with different markers coming in > > between. > > Above information is taken from page 52 of > > https://www.w3.org/Graphics/JPEG/itu-t81.pdf > > > > Since we can't rely on length specified in SOS header and there is > > possibility of having multiple SOS headers, we need to search for > > FF(foundFF). It means even if we jump for the length specified is SOS > > header the next byte is not promised to be '0xff'. > > For all the remaining markers we will get proper information related > > to the length and we will skip all data part(which might contain data > > similar to EOI/SOI/or any other marker). While propagating through > > the 'for' loop we are following the same approach. > > > > Please find updated webrev for review : > > http://cr.openjdk.java.net/~jdv/8152672/webrev.02/ > > > > Thanks, > > Jay > > > > -----Original Message----- > > From: Jim Graham > > Sent: Tuesday, June 14, 2016 12:44 AM > > To: Jayathirth D V > > Cc:2d-dev at openjdk.java.net ; Philip Race > > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : > > Exception while getting second image properties for JPEG with > > embedded thumbnail > > > > Hi Jay, > > > > You still don't check the read() calls in the length case to see if > > you reached EOF (-1). The potential for an infinite loop is still > > there. > > > > Also, you still search for an FF, even if you require the function to > > start at an SOI marker - all subsequent markers are still subject to > > a search rather than a deterministic requirement that we encounter > > markers with no gaps between them. > > > > Why do we have the foundFF variable in the first place? If we just > > saw an SOI marker then the next byte *must be* a 0xff (shouldn't it? > > Am I missing something?). We shouldn't read a byte and check if it > > is a 0xff and then try again, we should expect a single 0xff byte > > followed by a marker type byte, as in: > > > > while (true) { > > int byteval == iis.read(); > > // if (byteval< 0) then what? > > if (byteval != 0xff) { exception } > > byteval = iis.read(); > > switch (byteval) { > > } > > } > > > > The only question is if we get a -1 on the first read if we treat > > that as an implicit EOI as we do now, or if we treat it as an exception. > > Note that if we get a -1 in the second read, then we have a > > half-formed tag and that should fall into the default and be declared > > a bad file. > > > > ...jim > > > > On 6/13/2016 10:00 AM, Jayathirth D V wrote: > > Hi Jim, > > > > Thanks for your valuable inputs. > > I have updated the code with your inputs: > > 1) We should check for complete SOI marker and not just "FF" at > > start of skipImage(). > > 2) There is no need of iis.read() which was happening in default > > case. iis.read() present in for loop check will take care of > > checking EOF. > > 3) I have added case condition for all the markers having length > > and added default case where we get invalid marker starting with FF. > > > > Apart from above changes, after going more through > > https://www.w3.org/Graphics/JPEG/itu-t81.pdf got to know following > > things: > > > > 1) TEM is also one more marker without length so added case for > > that. > > 2) Since we have all unique conditions checked, we should not > > find any SOI marker after the initial SOI marker before we find EOI. > > Made changes to throw IOException in this case. > > > > Please find updated webrev for review: > > http://cr.openjdk.java.net/~jdv/8152672/webrev.01/ > > > > Thanks, > > Jay > > > > -----Original Message----- > > From: Jim Graham > > Sent: Saturday, June 11, 2016 3:07 AM > > To: Jayathirth D V; Philip Race > > Cc:2d-dev at openjdk.java.net > > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : > > Exception while getting second image properties for JPEG with > > embedded thumbnail > > > > Thanks for the response Jay, I think I was misreading some of the > > code as now that I look back at it, it's mostly written as I was > > suggesting with respect to skipping over data sections, however it > > is still doing some scanning to find the initial 0xFF. Some thoughts: > > > > - If we can be sure that we are located at where a tag should be, > > then shouldn't we just read a byte and assert that it is 0xFF and > > report the file as invalid if it isn't? The current code will just > > ignore the byte and continue reading until it finds a 0xFF, but the > > fact that the first byte we read isn't 0xFF means we have wandered > > into data that isn't following the file format (or, possibly, that > > this was called from a case where we hadn't completely read a > > section of data, but that should be fixed as we could be in the > > middle of a section that isn't entropy encoded and our search for > > 0xFF might have invalid assumptions). > > > > - The bytes read in the default section to get the length and the > > tag for the next block aren't tested for EOF (-1). This may even > > get us into an infinite loop if we hit EOF at the right time (just > > after a sized block tag) as the size bytes will read and combine > > into a -1 size, back up three bytes, and then reread the same tag > > and try to compute a length again which will send us back 3 bytes, etc. > > > > - default assumes that all other markers that are created will be > > sized, but can we assert that? Shouldn't we specifically list all > > known sized markers and have the default case reject the file as not > > being of a format that we recognize? > > > > ...jim > > > > On 6/9/2016 11:21 PM, Jayathirth D V wrote: > > Hi Jim, > > > > I think the harmless byte that you are referring to will be applied > > only for image data(Between SOS(Start of Scan) marker and EOI). For > > example, any "FF" data present in Jpeg image will be represented as > > "FF 00". But I think application headers or comments section can > > contain data which will be similar to EOI,SOI or other markers(FF XX). > > > > Thanks, > > Jay > > > > -----Original Message----- > > From: Jim Graham > > Sent: Friday, June 10, 2016 5:28 AM > > To: Jayathirth D V; Philip Race > > Cc:2d-dev at openjdk.java.net > > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8152672 : > > Exception while getting second image properties for JPEG with > > embedded thumbnail > > > > It looks like JPEG files have protection for scanning for an FF and > > assuming it is a marker by making sure that all FF bytes that > > appear in data are followed by a harmless byte, so a brute force > > search is probably fine. But it still seems wasteful when we know > > we are at a tag and we know the sizes of all of the tags, we should > > be able to skip around the file looking for the SOI directly... > > > > ...jim > > > > On 6/2/2016 5:10 AM, Jayathirth D V wrote: > > Fixed typo. > > > > > > > > *From:*Jayathirth D V > > *Sent:* Thursday, June 02, 2016 5:08 PM > > *To:* Philip Race > > *Cc:* Jim Graham;2d-dev at openjdk.java.net > > *Subject:* RE: Review Request for JDK-8152672 : Exception while > > getting second image properties for JPEG with embedded thumbnail > > > > > > > > Hi Phil, > > > > > > > > We have two kind of images with which we are able to reproduce the > > issue: > > > > 1) sample.jpg present in JBS bug(We can't use this image > > because it > > is licensed ). > > > > 2) JpegEmbedThumbnail.jpg taken using Prasanta's camera and > > used in > > webrev. > > > > > > > > _ _ > > > > _sample.jpg : _ > > > > _ _ > > > > If we do getNumImages() it will return 2. getNumImages() follows > > the same logic of skipping markers with length and registering SOI > > to get number of images. > > > > sample.jpg has markers as follows : > > > > SOI -> APP1 -> SOI -> EOI -> APP1 End -> EOI -> SOI -> EOI > > > > > > > > I have dumped first image its SOI is first one in the above list > > and for second image it is third one in the list. getNumImages() > > counts first and third SOI for number of images. But in case of > > skipImage() we are getting inside APP1 marker and considering its SOI. > > > > > > > > _JpegEmbedThumbnail.jpg :_ > > > > _ _ > > > > If we do getNumImages() it will return 1. > > > > JpegEmbedThumbnail.jpg has markers as follows : > > > > SOI -> APP1 -> SOI -> EOI -> APP1 End -> APP2 -> SOI -> APP2 End > > -> > > APP2 > > -> EOI -> APP2 End -> EOI > > > > > > > > getNumImages() counts only first SOI for number of images. But in > > case of skipImage() we will are getting inside APP1 and APP2 > > markers also. > > > > > > > > Thanks, > > > > Jay > > > > *From:*Phil Race > > *Sent:* Thursday, June 02, 2016 4:05 AM > > *To:* Jayathirth D V > > *Cc:* Jim Graham;2d-dev at openjdk.java.net > > > > *Subject:* Re: Review Request for JDK-8152672 : Exception while > > getting second image properties for JPEG with embedded thumbnail > > > > > > > > I am bit doubtful about this. Are you sure we are correct in > > reporting two images to begin with ? > > Thumbnails should not get counted .. > > > > > > -phil. > > > > On 06/01/2016 01:06 AM, Jayathirth D V wrote: > > > > Updated bug title in JBS as it was misleading. > > > > > > > > *From:* Jayathirth D V > > *Sent:* Wednesday, June 01, 2016 12:48 PM > > *To:* Philip Race; Jim Graham > > *Cc:*2d-dev at openjdk.java.net > > *Subject:* Review Request for JDK-8152672 : Exception getting > > thumbnail size for JPEG with embedded thumbnail > > > > > > > > Hi, > > > > > > > > _Please review the following fix in JDK9:_ > > > > > > > > Bug :https://bugs.openjdk.java.net/browse/JDK-8152672 > > > > > > > > Webrev :http://cr.openjdk.java.net/~jdv/8152672/webrev.00/ > > > > > > > > > > Issue : When we are trying to get properties related to second > > image > > in JPEG file we are getting IIOException mentioning that it is > > not a > > JPEG file. > > > > > > > > Root cause : When we are skipping first image to reach second > > image > > header, we are just trying to find next available EOI marker. > > But if > > first image has embedded thumbnail in APP1 marker, we will > > reach to > > EOI of this thumbnail and not EOI of first image. So after we > > reach > > EOI of embedded thumbnail we try to access second image SOI > > marker > > which will fail. > > > > > > > > Solution : We have to change the logic of how we skip to > > consecutive > > images in JPEG file. We know that application markers, > > comments or > > other markers can contain data same as SOI& EOI. Instead of just > > checking for EOI marker serially, we should read length of these > > markers and skip them. > > > > > > > > Thanks, > > > > Jay > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Jun 29 18:29:18 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 29 Jun 2016 11:29:18 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-5049012: PrintToFile option is not disabled for flavors that do not support destination In-Reply-To: <57724BB4.40602@oracle.com> References: <57724BB4.40602@oracle.com> Message-ID: <5774137E.6090304@oracle.com> --- https://docs.oracle.com/javase/8/docs/api/javax/print/PrintService.html#isAttributeValueSupported-javax.print.attribute.Attribute-javax.print.DocFlavor-javax.print.attribute.AttributeSet- Throws: NullPointerException - (unchecked exception) if attrval is null. -- So why did you remove the check for null ? -phil. On 6/28/16, 3:04 AM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix for an issue where it is seen that "Print-To-File" > option is enabled even for flavors that do not support Destination > attribute > even though isAttributeValueSupported for that flavor returns false. > > Bug: https://bugs.openjdk.java.net/browse/JDK-5049012 > webrev: http://cr.openjdk.java.net/~psadhukhan/5049012/webrev.00/ > > The reason for this behaviour is in Print Dialog code, the validation > is done against isAttributeCategorySupported() which still returns > true because Pageable and Printable supports it > and therefore the "Print-to-File" option gets enabled. > > But print dialog is shown specific to a doc flavor and a print service > (selected one) and hence must validate the attribute against the > chosen doc flavor. > So, the proposed fix checks the attributevalue is supported or not for > that flavor to determine if we need to enable "Print-to-File" option > in print dialog. > > Regards > Prasanta From philip.race at oracle.com Wed Jun 29 21:29:38 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 29 Jun 2016 14:29:38 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8153943 : In PixelInterLeavedSampleModel and BandedSampleModel we dont need hashCode() method In-Reply-To: <9fae0981-42a0-1af5-0de0-45f131b8555b@oracle.com> References: <9fae0981-42a0-1af5-0de0-45f131b8555b@oracle.com> Message-ID: <57743DC2.7040001@oracle.com> To remind myself and others .. this review started out with changes to the ColorModel classes mixed in. Those were separated out making it easier to review just the SampleModel hierachy here. Jim observed (see some way below for the context) :- > PixelInterleavedSampleModel and BandedSampleModel also have a > meaningless override of super.equals/hashCode(). I think that comment is from when the webrev for those files looked like this :- http://cr.openjdk.java.net/~jdv/8153943/webrev.02/src/java.desktop/share/classes/java/awt/image/BandedSampleModel.java.sdiff.html http://cr.openjdk.java.net/~jdv/8153943/webrev.02/src/java.desktop/share/classes/java/awt/image/PixelInterleavedSampleModel.java.sdiff.html So Jim, are you suggesting a preferred option is to go back to that proposal - at least for the equals methods ? [Caveat : the proposed equals method there should test instanceof before doing a cast but I actually don't know why it needs the cast anyway] The hashCode() could be left alone in that case. But if the equals methods are not added as there, then I think we do need to remove the hashCode() since it could be different even if (albeit only in a degenerate case), whilst instances (of the different classes) could compare as equal. But in either case we need to look to the super-class which is lacking any documentation of its own describing what makes two instances equal. We could try to explain there what might otherwise be surprising. -phil. On 06/28/2016 01:40 PM, Jim Graham wrote: > Still hoping to hear an opinion from Phil on this... > > The alternative is to add equals() overrides in the subclasses that > just do "obj instanceof && super.equals()" which would only > matter in some specific somewhat degenerate cases. > > The intent would be that even though the layout and pixel fetching > behavior for a specific configuration of PISM and BSM are identical, > they are philosophically not the same and so should not evaluate as > equals()... > > ...Or, should they? > > ...jim > > On 6/27/16 4:05 PM, Jim Graham wrote: >> This is odd that two completely different classes have identical >> "equals()" methods. After looking into it in more >> detail it looks as if ComponentSM is implemented as a general case >> that can encompass either PixelInterleaved or Banded >> pixel layouts - which means the subclasses are mostly just cosmetic >> (offering the constructors that make most sense if >> the pixels are laid out in the different ways) and only Banded offers >> a different implementation of getDataElements >> which is only different from the super implementation by virtue of >> eliminating a "multiply by a number which we know to >> be 1". >> >> There are also some restrictions in the constructors that enforce >> limits on the various values that CSM allows in its >> general implementation, so it isn't possible to use the >> PixelInterleaved constructor to create an arbitrarily-valued CSM >> nor to use the Banded constructors for the same purpose. The overlap >> in the type of CSM you can create from each of >> their constructors is very tiny to non-existant. >> >> The end result is that it ends up being infeasible to define a >> PixelInterleaved and a Banded SM that are equals() (not >> impossible, but you'd have to have a very degenerate case like a 1x1 >> image to make it through the various restrictions >> in the constructors and the offsets and the scanline strides and >> pixel strides, etc.). It's really odd in theory, and >> while not a problem in practice it still feels as if it violates an >> expectation. The primary restrictions I see getting >> in the way of different classed objects being equals() is that Banded >> forces a pixel stride of 1 and PixelInterleaved >> enforces that all band offsets are smaller than the scan stride. >> >> So, technically, I don't see any issue with just removing the hash >> method as the webrev proposes, but I'd like to see >> Phil's reaction to the situation we are in here with respect to >> intent vs. theory vs. practice vs. developer expectation... >> >> ...jim >> >> On 6/24/16 10:34 AM, Jayathirth D V wrote: >>> Hi, >>> >>> Please find following changes for review in JDK9 : >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8153943 >>> >>> Webrev : http://cr.openjdk.java.net/~jdv/8153943/webrev.03/ >>> >>> Issue : We have hashCode() method in PixelInterleavedSampleModel and >>> BandedSampleModel, but we don't have >>> corresponding equals() method. >>> >>> Solution : In PixelInterleavedSampleModel and BandedSampleModel we >>> don't have unique properties that are specific to >>> these subclasses and we have proper equals() & hashCode() method in >>> parent class ComponentSampleModel. So removed >>> hashCode() method present in PixelInterleavedSampleModel and >>> BandedSampleModel. >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Jim Graham >>> Sent: Wednesday, May 04, 2016 2:44 AM >>> To: Phil Race >>> Cc: 2d-dev at openjdk.java.net >>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8153943 : In >>> java.awt.image package some of the classes are >>> missing hashCode() or equals() method >>> >>> Yes, the equals/hashcode chapter in Effective Java includes rules >>> about ignoring fields that can be calculated from >>> other fields (which applies to most internal fields). Basically, >>> only things in the constructors tend to be good >>> candidates for equals/hashcode... >>> >>> ...jim >>> >>> On 5/3/2016 2:00 PM, Phil Race wrote: >>>> On 04/26/2016 04:10 PM, Jim Graham wrote: >>>>> The ComponentColorModel implementation is a meaningless wrapper >>>>> around super.equals/hashCode(). Why does it not test CCM-specific >>>>> fields? >>>> >>>> It should although this looks like it is more than just running >>>> through all the fields and testing them for equality. >>>> eg it looks like "initScale()" should be called if necessary before >>>> determining equality and the field "needScaleInit" is not one that has >>>> to be directly included in the equality comparison. >>>> >>>> -phil. >>>> >>>> >>>> >>>>> >>>>> The ComponentSampleModel.hashCode() method should be upgraded based >>>>> on the recommendations in Effective Java like the other methods here. >>>>> >>>>> PixelInterleavedSampleModel and BandedSampleModel also have a >>>>> meaningless override of super.equals/hashCode(). >>>>> >>>>> And all of these classes suffer from casting to the specific type >>>>> before verifying its class as I mentioned in the ICM.equals() >>>>> review... >>>>> >>>>> ...jim >>>>> >>>>> On 4/25/16 2:31 AM, Jayathirth D V wrote: >>>>>> Hi Jim, >>>>>> >>>>>> I have made changes to include check for class equality in base >>>>>> class and use super.equals() from subclasses. >>>>>> Please find updated webrev for review : >>>>>> http://cr.openjdk.java.net/~jdv/8153943/webrev.02/ >>>>>> >>>>>> Change related to ColorModel is present in JDK-7107905 review. >>>>>> >>>>>> Thanks, >>>>>> Jay >>>>>> >>>>>> -----Original Message----- >>>>>> From: Jim Graham >>>>>> Sent: Saturday, April 23, 2016 7:30 AM >>>>>> To: Phil Race; Jayathirth D V >>>>>> Cc: 2d-dev at openjdk.java.net >>>>>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8153943 : In >>>>>> java.awt.image package some of the classes are missing hashCode() or >>>>>> equals() method >>>>>> >>>>>> This is actually a pretty nasty issue that Joe Darcy also brought up >>>>>> in the CCC review. >>>>>> >>>>>> In order to have symmetric testing of .equals(), we pretty much have >>>>>> to enforce this test at all levels, including in the original >>>>>> ColorModels.equals() method. If we don't enforce this in >>>>>> CM.equals(), then we could run ccm.equals(othercm) and it would >>>>>> return false because the class is wrong, but turning it around and >>>>>> testing >>>>>> othercm.equals(ccm) would succeed because it doesn't enforce the >>>>>> class equality. >>>>>> >>>>>> So, I'd recommend that CM.equals() tests getClass() == getClass() at >>>>>> the base level and then all others will use super.equals() and get >>>>>> the same protection. It means you can't have a subclass of CCM be >>>>>> "equals" to a different subclass of CCM, but that's an unfortunate >>>>>> issue with equals needing to honor symmetry... :( >>>>>> >>>>>> ...jim >>>>>> >>>>>> On 4/20/2016 10:17 AM, Phil Race wrote: >>>>>>> Hi, You removed the following test in CCM.java : 2941 if >>>>>>> (obj.getClass() != getClass()) { >>>>>>> 2942 return false; >>>>>>> >>>>>>> 2943 } >>>>>>> >>>>>>> What this means is that before your change an instance of a >>>>>>> subclass of CCM would never be equals() to any direct >>>>>>> instantiatation of CCM but after your change it can be. I suspect >>>>>>> the condition was there on purpose. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 04/20/2016 05:45 AM, Jayathirth D V wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _Please review the following fix in JDK9:_ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8153943 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This is subtask of >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6588409 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Webrev : http://cr.openjdk.java.net/~jdv/8153943/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Issue : Some of the java.awt.image classes are missing either >>>>>>>> equals() or hashCode() method. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Solution : Add missing equals() or hashCode() methods. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Jay >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>> From james.graham at oracle.com Wed Jun 29 22:34:53 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 29 Jun 2016 15:34:53 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods In-Reply-To: References: <6f83b633-3910-47fa-b872-e042fe4c24d3@default> <24ca2994-aa27-4a70-8cf9-0bda35664f3f@default> <574809B2.5040901@oracle.com> <9f641938-f979-4021-9e94-bde47e1d3c67@default> <57489033.7020901@oracle.com> <77d5b327-066b-4d86-a44d-8e681aeb71f8@default> <574DE3F9.40709@oracle.com> <574E0717.5060405@oracle.com> <574E0DF9.20508@oracle.com> <574E10B0.4070003@oracle.com> <574E13BD.9060701@oracle.com> <9a87056b-2646-4d5f-bfec-d50bea489381@default> <574F0EFE.2070300@oracle.com> <2e485b6b-3df0-41db-ba40-a96528883e95@default> <20a4c021-6814-9423-2891-c45c1ab94396@oracle.com> <0042f492-5fc4-481c-8b2d-35a242a5af93@default> <6341d4b6-f281-3f58-efc3-32d1ed0ecc42@oracle.com> Message-ID: <57744D0D.9080809@oracle.com> Hi Jay, We need to reference the properties from the base class in the subclasses. We don't need to list them every time, but we could introduce the "additional properties" using something like: "... we check all of the properties checked by the {equals} method of {ColorModel}, and the following additional properties:" Arguably, we could omit the class comparison text from the subclasses as well by using a reference like that, but I think that the class equivalence test is enough out of the ordinary that it does bear reiterating it in every subclass as you already do now even though we only reference the specific other properties tested by a reference. A few grammar fixes: In all of the classes, insert a space before any parentheses in comment text as in "the same class (and not a subclass)". (That wouldn't apply if the text in the comment is referring to code - then space it as you would actual code.) In CM, insert the word "the" as in "also check the following ..." In ICM I would refer to the "Valid bits of" instead as "The list of valid pixel indices in". In PCM I would change "check maskArray of ..." to "check the masks of the ..." and pluralize the word "samples". ...jim On 06/29/2016 04:13 AM, Jayathirth D V wrote: > Hi, > > Since Joe mentioned to add information related to what fields we are using to calculate equals() method in ColorModel and its subclasses I have updated the spec for the same. > > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/7107905/webrev.11/ > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Saturday, June 04, 2016 4:52 AM > To: Jayathirth D V; Philip Race > Cc: 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods > > That looks good to me. Has the CCC cleared yet? > > ...jim > > On 6/3/16 2:49 AM, Jayathirth D V wrote: >> Hi Jim, >> >> Oh that's an important change. >> Thanks for your review. >> >> I have updated ColorModel constructor to copy nBIts only of numOfComponents length and I have removed validBits check in hashCode() of ICM. >> Please find updated webrev for review: >> http://cr.openjdk.java.net/~jdv/7107905/webrev.10/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Friday, June 03, 2016 2:25 AM >> To: Jayathirth D V; Philip Race >> Cc: 2d-dev at openjdk.java.net >> Subject: Re: Review Request for JDK-7107905: ColorModel subclasses are >> missing hashCode() or equals() or both methods >> >> I just noticed a hashCode/equals violation that we created a few revisions ago. We compute the hash of the validBits in ICM, but we only compare validBits up to the number of colors in the colormap. One could construct two ICMs that have different validBits that are identical in the first N bits (N = number of colors), but have different bits beyond that, and those 2 ICMs would evaluate as equals(), but their hashcodes would be different. >> >> Possible solutions: >> >> - Truncate validBits when it is accepted in the constructor >> (validBits.and(...)) >> - Manually compute the hash of the first N bits of validBits >> - Not use validBits in the hash code since it is allowed to omit >> significant data from the hash >> >> (Note that everything in hashcode must participate in equals(), but >> not vice versa) >> >> The same is true of nBits in ColorModel. (nBits can be copied and >> truncated with Arrays.copyOf) >> >> The same is *not* true of maskBits in PCM since the constructor creates an array of the precise length it needs... >> >> ...jim >> >> On 6/2/16 7:07 AM, Jayathirth D V wrote: >>> Hi Phil, >>> >>> I have updated the code with all the changes I mentioned previously. I am caching hashCode when first time hashCode() is called. >>> Please find the updated webrev for review: >>> http://cr.openjdk.java.net/~jdv/7107905/webrev.09/ >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Philip Race >>> Sent: Wednesday, June 01, 2016 10:06 PM >>> To: Jayathirth D V >>> Cc: Jim Graham; 2d-dev at openjdk.java.net >>> Subject: Re: Review Request for JDK-7107905: ColorModel subclasses >>> are missing hashCode() or equals() or both methods >>> >>> Please post the updated webrev. >>> >>> -phil. >>> >>> On 6/1/16, 12:02 AM, Jayathirth D V wrote: >>>> Hi Phil& Jim, >>>> >>>> Collating all the changes needed: >>>> 1) I have removed both equals()& hashCode() in CCM but forgot to add the file while creating webrev. I will include changes in CCM in updated webrev. >>>> 2) Caching of hashCode value in IndexColorModel& PackedColorModel : >>>> We can cache hashCode value when constructor is called or when hashCode() is called for first time. What approach we have to follow? >>>> 3) Comment section of equals() method, I will update it to : >>>> 1449 * the target object must be the same class (and not a subclass) as this >>>> 4) I will use .equals() to compare colorSpace values in CM.equals() so it will be like we are not intending ColorSpace class to never override equals() method. >>>> >>>> Please let me know your inputs. >>>> >>>> Thanks, >>>> Jay >>>> >>>> -----Original Message----- >>>> From: Jim Graham >>>> Sent: Wednesday, June 01, 2016 4:14 AM >>>> To: Phil Race >>>> Cc: Jayathirth D V; 2d-dev at openjdk.java.net >>>> Subject: Re: Review Request for JDK-7107905: ColorModel subclasses >>>> are missing hashCode() or equals() or both methods >>>> >>>> I think we should use .equals() here, otherwise it looks like a recommendation that the intent is for those classes to never implement it... >>>> >>>> ...jim >>>> >>>> On 05/31/2016 03:31 PM, Phil Race wrote: >>>>> I don't know of any design intent, so yes, I meant more as a >>>>> practical matter. >>>>> Unless they subclass then using equals() which I thought unlikely >>>>> it makes no difference here. >>>>> But it would be proof against that to use equals, unlikely to >>>>> matter as it might be .. >>>>> >>>>> -phil. >>>>> >>>>> On 05/31/2016 03:19 PM, Jim Graham wrote: >>>>>> >>>>>> On 05/31/2016 02:50 PM, Phil Race wrote: >>>>>>> On 05/31/2016 12:20 PM, Jim Graham wrote: >>>>>>>> Hi Jay, >>>>>>>> >>>>>>>> You were going to remove hashCode/equals from CCM, but instead >>>>>>>> you simply removed it from the patch. You still need to edit it >>>>>>>> to remove the existing methods. >>>>>>> Oh yeah ! CCM is gone from the latest webrev. I expect that was >>>>>>> not intentional. >>>>>>> >>>>>>>> Also, I'm not sure == is a good way to compare ColorSpace >>>>>>>> instances >>>>>>>> - Phil? >>>>>>> Neither ColorSpace nor ICC_ColorSpace over-ride equals or >>>>>>> hashCode and all the predefined ones are constructed as >>>>>>> singletons so it seems unlikely to cause problems >>>>>> Should it use .equals() on principle, though? Otherwise we are >>>>>> baking in the assumption that it doesn't implement equals() into >>>>>> our implementation of the CM.equals() method. Might it some day >>>>>> implement equals (perhaps it isn't a practical issue today, but it >>>>>> might be in the future when we forget that it was omitted in this >>>>>> usage we create today). >>>>>> >>>>>> I guess what I'm asking is if it is a design feature that >>>>>> different objects are considered non-equal (such as an object >>>>>> that, for instance, has only predetermined instances that are >>>>>> shared by reference and reused). I think color spaces are sort of >>>>>> in-between in that we define a few constants that simply get used >>>>>> by reference in 99% of cases, but that isn't a design feature, >>>>>> more like a practical issue... >>>>>> >>>>>> ...jim From james.graham at oracle.com Wed Jun 29 22:51:57 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 29 Jun 2016 15:51:57 -0700 Subject: [OpenJDK 2D-Dev] Review Request for JDK-8153943 : In PixelInterLeavedSampleModel and BandedSampleModel we dont need hashCode() method In-Reply-To: <57743DC2.7040001@oracle.com> References: <9fae0981-42a0-1af5-0de0-45f131b8555b@oracle.com> <57743DC2.7040001@oracle.com> Message-ID: <5774510D.1020307@oracle.com> Hi Phil, The following 2 statements are factually correct ignoring what we plan to do about these classes: - If they don't override equals() then they shouldn't override hash - Their raw casts were wrong (and the fact that nobody ever noticed that is a good indication that these methods have probably not been used in the wild). What I'm waffling on is that while the equals() methods appeared functionally useless, in practice they can either block or allow disparate class objects from being equal to each other and I'm thinking that one could argue that it makes strategic sense to enforce the correct class type (using instanceof) to match the behavioral expectations of a developer. Since I sent that out I also checked a similar case in the Number subclasses and an Integer and a Long will not evaluate to equals even if they hold the same cardinal value. Arguably that's even a stronger case of when 2 disparate objects might want to be seen as equals(), but we don't allow it there. Arguably, the override of hash is still unnecessary since it would be fine to allow disparate classes to have the same hash value from the super class - that doesn't violate any contracts. You can't allow it to inherit from Object.hashCode() since that hash value is very strict, but it would be OK to override the somewhat "property oriented" hash code from their immediate superclass. I would lean towards leaving it in if we decide to override equals() just to avoid the argument. Given the fact that these equals() methods have obviously not been used much, I don't have a strong opinion between "saving code by just not overriding them" and "making the different subclasses have unique identities by overriding and preventing them from being equal to each other". In the end, if we do fix the equals() for these classes, we should document why they are overriding equals() even if it appears to do not really value added testing compared to the super class... ...jim On 06/29/2016 02:29 PM, Phil Race wrote: > > To remind myself and others .. this review started out with changes to > the ColorModel classes mixed in. > Those were separated out making it easier to review just the SampleModel > hierachy here. > > Jim observed (see some way below for the context) :- > > > PixelInterleavedSampleModel and BandedSampleModel also have a > > meaningless override of super.equals/hashCode(). > > I think that comment is from when the webrev for those files looked like > this :- > > http://cr.openjdk.java.net/~jdv/8153943/webrev.02/src/java.desktop/share/classes/java/awt/image/BandedSampleModel.java.sdiff.html > > http://cr.openjdk.java.net/~jdv/8153943/webrev.02/src/java.desktop/share/classes/java/awt/image/PixelInterleavedSampleModel.java.sdiff.html > > > So Jim, are you suggesting a preferred option is to go back to that > proposal - at least for the equals methods ? > [Caveat : the proposed equals method there should test instanceof before > doing a cast but I actually don't > know why it needs the cast anyway] > > The hashCode() could be left alone in that case. > > But if the equals methods are not added as there, then I think we do > need to remove the > hashCode() since it could be different even if (albeit only in a > degenerate case), whilst > instances (of the different classes) could compare as equal. > > But in either case we need to look to the super-class which is lacking > any documentation of its > own describing what makes two instances equal. > We could try to explain there what might otherwise be surprising. > > -phil. > > > On 06/28/2016 01:40 PM, Jim Graham wrote: >> Still hoping to hear an opinion from Phil on this... >> >> The alternative is to add equals() overrides in the subclasses that >> just do "obj instanceof && super.equals()" which would only >> matter in some specific somewhat degenerate cases. >> >> The intent would be that even though the layout and pixel fetching >> behavior for a specific configuration of PISM and BSM are identical, >> they are philosophically not the same and so should not evaluate as >> equals()... >> >> ...Or, should they? >> >> ...jim >> >> On 6/27/16 4:05 PM, Jim Graham wrote: >>> This is odd that two completely different classes have identical >>> "equals()" methods. After looking into it in more >>> detail it looks as if ComponentSM is implemented as a general case >>> that can encompass either PixelInterleaved or Banded >>> pixel layouts - which means the subclasses are mostly just cosmetic >>> (offering the constructors that make most sense if >>> the pixels are laid out in the different ways) and only Banded offers >>> a different implementation of getDataElements >>> which is only different from the super implementation by virtue of >>> eliminating a "multiply by a number which we know to >>> be 1". >>> >>> There are also some restrictions in the constructors that enforce >>> limits on the various values that CSM allows in its >>> general implementation, so it isn't possible to use the >>> PixelInterleaved constructor to create an arbitrarily-valued CSM >>> nor to use the Banded constructors for the same purpose. The overlap >>> in the type of CSM you can create from each of >>> their constructors is very tiny to non-existant. >>> >>> The end result is that it ends up being infeasible to define a >>> PixelInterleaved and a Banded SM that are equals() (not >>> impossible, but you'd have to have a very degenerate case like a 1x1 >>> image to make it through the various restrictions >>> in the constructors and the offsets and the scanline strides and >>> pixel strides, etc.). It's really odd in theory, and >>> while not a problem in practice it still feels as if it violates an >>> expectation. The primary restrictions I see getting >>> in the way of different classed objects being equals() is that Banded >>> forces a pixel stride of 1 and PixelInterleaved >>> enforces that all band offsets are smaller than the scan stride. >>> >>> So, technically, I don't see any issue with just removing the hash >>> method as the webrev proposes, but I'd like to see >>> Phil's reaction to the situation we are in here with respect to >>> intent vs. theory vs. practice vs. developer expectation... >>> >>> ...jim >>> >>> On 6/24/16 10:34 AM, Jayathirth D V wrote: >>>> Hi, >>>> >>>> Please find following changes for review in JDK9 : >>>> >>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8153943 >>>> >>>> Webrev : http://cr.openjdk.java.net/~jdv/8153943/webrev.03/ >>>> >>>> Issue : We have hashCode() method in PixelInterleavedSampleModel and >>>> BandedSampleModel, but we don't have >>>> corresponding equals() method. >>>> >>>> Solution : In PixelInterleavedSampleModel and BandedSampleModel we >>>> don't have unique properties that are specific to >>>> these subclasses and we have proper equals() & hashCode() method in >>>> parent class ComponentSampleModel. So removed >>>> hashCode() method present in PixelInterleavedSampleModel and >>>> BandedSampleModel. >>>> >>>> Thanks, >>>> Jay >>>> >>>> -----Original Message----- >>>> From: Jim Graham >>>> Sent: Wednesday, May 04, 2016 2:44 AM >>>> To: Phil Race >>>> Cc: 2d-dev at openjdk.java.net >>>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8153943 : In >>>> java.awt.image package some of the classes are >>>> missing hashCode() or equals() method >>>> >>>> Yes, the equals/hashcode chapter in Effective Java includes rules >>>> about ignoring fields that can be calculated from >>>> other fields (which applies to most internal fields). Basically, >>>> only things in the constructors tend to be good >>>> candidates for equals/hashcode... >>>> >>>> ...jim >>>> >>>> On 5/3/2016 2:00 PM, Phil Race wrote: >>>>> On 04/26/2016 04:10 PM, Jim Graham wrote: >>>>>> The ComponentColorModel implementation is a meaningless wrapper >>>>>> around super.equals/hashCode(). Why does it not test CCM-specific >>>>>> fields? >>>>> >>>>> It should although this looks like it is more than just running >>>>> through all the fields and testing them for equality. >>>>> eg it looks like "initScale()" should be called if necessary before >>>>> determining equality and the field "needScaleInit" is not one that has >>>>> to be directly included in the equality comparison. >>>>> >>>>> -phil. >>>>> >>>>> >>>>> >>>>>> >>>>>> The ComponentSampleModel.hashCode() method should be upgraded based >>>>>> on the recommendations in Effective Java like the other methods here. >>>>>> >>>>>> PixelInterleavedSampleModel and BandedSampleModel also have a >>>>>> meaningless override of super.equals/hashCode(). >>>>>> >>>>>> And all of these classes suffer from casting to the specific type >>>>>> before verifying its class as I mentioned in the ICM.equals() >>>>>> review... >>>>>> >>>>>> ...jim >>>>>> >>>>>> On 4/25/16 2:31 AM, Jayathirth D V wrote: >>>>>>> Hi Jim, >>>>>>> >>>>>>> I have made changes to include check for class equality in base >>>>>>> class and use super.equals() from subclasses. >>>>>>> Please find updated webrev for review : >>>>>>> http://cr.openjdk.java.net/~jdv/8153943/webrev.02/ >>>>>>> >>>>>>> Change related to ColorModel is present in JDK-7107905 review. >>>>>>> >>>>>>> Thanks, >>>>>>> Jay >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Jim Graham >>>>>>> Sent: Saturday, April 23, 2016 7:30 AM >>>>>>> To: Phil Race; Jayathirth D V >>>>>>> Cc: 2d-dev at openjdk.java.net >>>>>>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-8153943 : In >>>>>>> java.awt.image package some of the classes are missing hashCode() or >>>>>>> equals() method >>>>>>> >>>>>>> This is actually a pretty nasty issue that Joe Darcy also brought up >>>>>>> in the CCC review. >>>>>>> >>>>>>> In order to have symmetric testing of .equals(), we pretty much have >>>>>>> to enforce this test at all levels, including in the original >>>>>>> ColorModels.equals() method. If we don't enforce this in >>>>>>> CM.equals(), then we could run ccm.equals(othercm) and it would >>>>>>> return false because the class is wrong, but turning it around and >>>>>>> testing >>>>>>> othercm.equals(ccm) would succeed because it doesn't enforce the >>>>>>> class equality. >>>>>>> >>>>>>> So, I'd recommend that CM.equals() tests getClass() == getClass() at >>>>>>> the base level and then all others will use super.equals() and get >>>>>>> the same protection. It means you can't have a subclass of CCM be >>>>>>> "equals" to a different subclass of CCM, but that's an unfortunate >>>>>>> issue with equals needing to honor symmetry... :( >>>>>>> >>>>>>> ...jim >>>>>>> >>>>>>> On 4/20/2016 10:17 AM, Phil Race wrote: >>>>>>>> Hi, You removed the following test in CCM.java : 2941 if >>>>>>>> (obj.getClass() != getClass()) { >>>>>>>> 2942 return false; >>>>>>>> >>>>>>>> 2943 } >>>>>>>> >>>>>>>> What this means is that before your change an instance of a >>>>>>>> subclass of CCM would never be equals() to any direct >>>>>>>> instantiatation of CCM but after your change it can be. I suspect >>>>>>>> the condition was there on purpose. >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> On 04/20/2016 05:45 AM, Jayathirth D V wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _Please review the following fix in JDK9:_ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8153943 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> This is subtask of >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6588409 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Webrev : http://cr.openjdk.java.net/~jdv/8153943/webrev.00/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Issue : Some of the java.awt.image classes are missing either >>>>>>>>> equals() or hashCode() method. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Solution : Add missing equals() or hashCode() methods. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Jay >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>> > From yasuenag at gmail.com Wed Jun 29 23:30:33 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 30 Jun 2016 08:30:33 +0900 Subject: [OpenJDK 2D-Dev] JDK 9 build with GCC 6.1.1 In-Reply-To: <5772B61E.7060606@oracle.com> References: <57F3A28D-6FFD-45D6-B85C-1B5638CE29F4@oracle.com> <5772B61E.7060606@oracle.com> Message-ID: <67542003-65a5-4791-dc27-e02f129a4d97@gmail.com> Hi Kim, Phil, Can I push this patch? It has been reviewed. http://cr.openjdk.java.net/~ysuenaga/JDK-8160294/webrev.01/ Thanks, Yasumasa On 2016/06/29 2:38, Phil Race wrote: > On 06/27/2016 08:50 PM, Yasumasa Suenaga wrote: >> Hi Kim, >> >> The newest changes for jdk repos is [1]. >> Erik points we should use DISABLED_WARNINGS_gcc to handle unknown warning tags. [2] >> [1] is implemented with it. >> >> This change is already reviewed by 2d folks. >> So I want to merge it ASAP. >> >> Do you have any objection? >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007090.html >> [2] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004499.html >> >> >> On 2016/06/28 8:37, Kim Barrett wrote: >>>> On Jun 25, 2016, at 9:57 AM, Yasumasa Suenaga wrote: >>>> >>>> Hi all, >>>> >>>> This review request relates to [1]. >>>> >>>> I've tried to build OpenJDK 9 at Fedora 24 x64. >>>> Fedora 24 has GCC 6.1.1, and OpenJDK 9 build was failed. >>>> >>>> I fixed build error and several issues (VM crash and internal error) as below: >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot/ >>>> >>>> Does someone work for it? >>>> If no one works for it, I will file it to JBS and will send review request. >>>> >>>> For jdk repos, I've sent review request [2]. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004494.html >>>> [2] http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007081.html >>> >>> Having gone through these, I think all of them are arising due to >>> build system problems, where we seem to have lost the compiler >>> configuration to use explicit selection of the language standard and >>> some additional options. > > Do tell more about what this means. Where would this previously have been seen ? > Different versions of Visual Studio / CLANG / GCC all emit different warnings > and it is not always monotonically increasing with compiler version, and I > can imagine someone might want to have different sets of flags in general > depending on compiler version in use, but I have not seen a pattern of this > being applied to the warnings on any of the platforms. > > in the makefile here there is just one special case of this .. > > 474 # Suppress gcc warnings like "variable might be clobbered by 'longjmp' > 475 # or 'vfork'": this warning indicates that some variable is placed to > 476 # a register by optimized compiler and it's value might be lost on longjmp(). > 477 # Recommended way to avoid such warning is to declare the variable as > 478 # volatile to prevent the optimization. However, this approach does not > 479 # work because we have to declare all variables as volatile in result. > 480 #ifndef CROSS_COMPILE_ARCH > 481 # CC_43_OR_NEWER := \ > 482 # $(shell $(EXPR) $(CC_MAJORVER) \> 4 \| \ > 483 # \( $(CC_MAJORVER) = 4 \& $(CC_MINORVER) \>= 3 \) ) > 484 # ifeq ($(CC_43_OR_NEWER), 1) > 485 # BUILD_LIBJAVAJPEG_CFLAGS_linux += -Wno-clobbered > 486 # endif > 487 #endif > > >>> >>> For now I think we should fix the build system problems, and file >>> additional bugs or update existing ones as needed to fix the root >>> causes of the problems encountered. I think many of the proposed >>> changes do not address the root causes, and should not be made. See >>> my comments for the specific bugs. >>> >>> I'm not on the mailing list where the jdk RFR was submitted. I took a >>> look at them though, and >>> >>> ------------------------------------------------------------------------------ >>> make/lib/Awt2dLibraries.gmk >>> 407 # Avoid warning for GCC 6 >>> 408 ifeq ($(TOOLCHAIN_TYPE), gcc) >>> 409 LCMS_CFLAGS += -Wno-misleading-indentation >>> 410 endif >>> >>> 926 # Avoid warning for GCC 6 >>> 927 ifeq ($(TOOLCHAIN_TYPE), gcc) >>> 928 BUILD_LIBSPLASHSCREEN_jdhuff.c_CFLAGS += -Wno-shift-negative-value >>> 929 BUILD_LIBSPLASHSCREEN_jdphuff.c_CFLAGS += -Wno-shift-negative-value >>> 930 endif >>> >>> The -Wmisleading-indentation and -Wshift-negative-value options are >>> new in gcc 6. gcc has for some time (starting with gcc 4.4) silently >>> ignored unrecognized -Wno-XXX options. But some folks (like SAP) are >>> still using older versions. So these will need to be conditionalized >>> on the gcc version. >>> >>> ------------------------------------------------------------------------------ >>> src/java.desktop/share/native/libfontmanager/layout/SunLayoutEngine.cpp >>> 154 if (min < 0) min = 0; >>> 155 if (max < min) max = min; /* defensive coding */ >>> >>> [splitting the line] >>> >>> Seems like this would be suppressed by -Wno-misleading-indentation, >>> especially since the reported warning is for that. Why change both >>> the code and the build configuration? > > Was that something seen in the original fix ? It is not in the version I reviewed. > The current version of the fix does not update the makefile to add this > .. except for LCMS - which is a different library. > > > -phil. > >>> >>> ------------------------------------------------------------------------------ >>> >>> The changes in AlphaMath.c and splashscreen_jpeg.c look ok. >>> > From philip.race at oracle.com Thu Jun 30 00:44:29 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 29 Jun 2016 17:44:29 -0700 Subject: [OpenJDK 2D-Dev] JDK 9 build with GCC 6.1.1 In-Reply-To: <67542003-65a5-4791-dc27-e02f129a4d97@gmail.com> References: <57F3A28D-6FFD-45D6-B85C-1B5638CE29F4@oracle.com> <5772B61E.7060606@oracle.com> <67542003-65a5-4791-dc27-e02f129a4d97@gmail.com> Message-ID: <57746B6D.5030405@oracle.com> Hi, Not just yet. Whilst I am OK with it ... 1) We like 2 (two) reviewers to approve. 2) I would like Kim to reply to the questions so I understand his concerns first. -phil. On 6/29/16, 4:30 PM, Yasumasa Suenaga wrote: > Hi Kim, Phil, > > Can I push this patch? > It has been reviewed. > > http://cr.openjdk.java.net/~ysuenaga/JDK-8160294/webrev.01/ > > > Thanks, > > Yasumasa > > > On 2016/06/29 2:38, Phil Race wrote: >> On 06/27/2016 08:50 PM, Yasumasa Suenaga wrote: >>> Hi Kim, >>> >>> The newest changes for jdk repos is [1]. >>> Erik points we should use DISABLED_WARNINGS_gcc to handle unknown >>> warning tags. [2] >>> [1] is implemented with it. >>> >>> This change is already reviewed by 2d folks. >>> So I want to merge it ASAP. >>> >>> Do you have any objection? >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007090.html >>> [2] >>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004499.html >>> >>> >>> On 2016/06/28 8:37, Kim Barrett wrote: >>>>> On Jun 25, 2016, at 9:57 AM, Yasumasa Suenaga >>>>> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> This review request relates to [1]. >>>>> >>>>> I've tried to build OpenJDK 9 at Fedora 24 x64. >>>>> Fedora 24 has GCC 6.1.1, and OpenJDK 9 build was failed. >>>>> >>>>> I fixed build error and several issues (VM crash and internal >>>>> error) as below: >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot/ >>>>> >>>>> Does someone work for it? >>>>> If no one works for it, I will file it to JBS and will send review >>>>> request. >>>>> >>>>> For jdk repos, I've sent review request [2]. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> [1] >>>>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004494.html >>>>> [2] >>>>> http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007081.html >>>> >>>> Having gone through these, I think all of them are arising due to >>>> build system problems, where we seem to have lost the compiler >>>> configuration to use explicit selection of the language standard and >>>> some additional options. >> >> Do tell more about what this means. Where would this previously have >> been seen ? >> Different versions of Visual Studio / CLANG / GCC all emit different >> warnings >> and it is not always monotonically increasing with compiler version, >> and I >> can imagine someone might want to have different sets of flags in >> general >> depending on compiler version in use, but I have not seen a pattern >> of this >> being applied to the warnings on any of the platforms. >> >> in the makefile here there is just one special case of this .. >> >> 474 # Suppress gcc warnings like "variable might be clobbered by >> 'longjmp' >> 475 # or 'vfork'": this warning indicates that some variable is >> placed to >> 476 # a register by optimized compiler and it's value might be lost >> on longjmp(). >> 477 # Recommended way to avoid such warning is to declare the >> variable as >> 478 # volatile to prevent the optimization. However, this approach >> does not >> 479 # work because we have to declare all variables as volatile in >> result. >> 480 #ifndef CROSS_COMPILE_ARCH >> 481 # CC_43_OR_NEWER := \ >> 482 # $(shell $(EXPR) $(CC_MAJORVER) \> 4 \| \ >> 483 # \( $(CC_MAJORVER) = 4 \& $(CC_MINORVER) \>= 3 \) ) >> 484 # ifeq ($(CC_43_OR_NEWER), 1) >> 485 # BUILD_LIBJAVAJPEG_CFLAGS_linux += -Wno-clobbered >> 486 # endif >> 487 #endif >> >> >>>> >>>> For now I think we should fix the build system problems, and file >>>> additional bugs or update existing ones as needed to fix the root >>>> causes of the problems encountered. I think many of the proposed >>>> changes do not address the root causes, and should not be made. See >>>> my comments for the specific bugs. >>>> >>>> I'm not on the mailing list where the jdk RFR was submitted. I took a >>>> look at them though, and >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> make/lib/Awt2dLibraries.gmk >>>> 407 # Avoid warning for GCC 6 >>>> 408 ifeq ($(TOOLCHAIN_TYPE), gcc) >>>> 409 LCMS_CFLAGS += -Wno-misleading-indentation >>>> 410 endif >>>> >>>> 926 # Avoid warning for GCC 6 >>>> 927 ifeq ($(TOOLCHAIN_TYPE), gcc) >>>> 928 BUILD_LIBSPLASHSCREEN_jdhuff.c_CFLAGS += >>>> -Wno-shift-negative-value >>>> 929 BUILD_LIBSPLASHSCREEN_jdphuff.c_CFLAGS += >>>> -Wno-shift-negative-value >>>> 930 endif >>>> >>>> The -Wmisleading-indentation and -Wshift-negative-value options are >>>> new in gcc 6. gcc has for some time (starting with gcc 4.4) silently >>>> ignored unrecognized -Wno-XXX options. But some folks (like SAP) are >>>> still using older versions. So these will need to be conditionalized >>>> on the gcc version. >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> src/java.desktop/share/native/libfontmanager/layout/SunLayoutEngine.cpp >>>> >>>> 154 if (min < 0) min = 0; >>>> 155 if (max < min) max = min; /* defensive coding */ >>>> >>>> [splitting the line] >>>> >>>> Seems like this would be suppressed by -Wno-misleading-indentation, >>>> especially since the reported warning is for that. Why change both >>>> the code and the build configuration? >> >> Was that something seen in the original fix ? It is not in the >> version I reviewed. >> The current version of the fix does not update the makefile to add this >> .. except for LCMS - which is a different library. >> >> >> -phil. >> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> The changes in AlphaMath.c and splashscreen_jpeg.c look ok. >>>> >> From prasanta.sadhukhan at oracle.com Thu Jun 30 05:05:07 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 30 Jun 2016 10:35:07 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6218397:Printing to file does not throw a PrinterException if the file cannot be created In-Reply-To: <5774060C.3010205@oracle.com> References: <576180D4.9040502@oracle.com> <1209f6f2-36df-6655-c542-d3836b11ff71@oracle.com> <7461a8f1-5263-a7b8-3dab-a4bd0733890b@oracle.com> <576BBCA8.2080800@oracle.com> <5774060C.3010205@oracle.com> Message-ID: <5774A883.1010602@oracle.com> Thanks Phil. @Jay, can you please review this updated webrev http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.04/ that takes care of this syntactic changes? Regards Prasanta On 6/29/2016 11:01 PM, Philip Race wrote: > if (f.exists()) f.delete(); should use { ... } for the body - 2 cases > of this one in each of the modified files. Other than that OK. I don't > need to see an updated webrev so long as you make those syntactic > changes. -phil > > > On 6/23/16, 3:40 AM, Prasanta Sadhukhan wrote: >> Hi Phil, All, >> >> Based on the offline discussion, I added the case when disk gets >> filled while writing to the file. >> Since PrintStream does not throw IOException, I added check for >> checkError() to do the corresponding error handling. I added it after >> flush() as that is where the stream will be written to the file. >> http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.03/ >> >> Regards >> Prasanta >> On 6/20/2016 12:01 PM, prasanta sadhukhan wrote: >>> >>> Hi Phil,All, >>> >>> Added file delete in another case where we throw PrinterException. >>> http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.02/ >>> >>> Regards >>> Prasanta >>> On 6/16/2016 1:40 PM, prasanta sadhukhan wrote: >>>> >>>> Modified webrev to close output stream. >>>> >>>> http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.01/ >>>> >>>> Regards >>>> Prasanta >>>> On 6/15/2016 9:52 PM, Philip Race wrote: >>>>> If this is executed on Windows (shared Postscript stream printer >>>>> could do this) >>>>> then since the output stream is still open I expect the delete >>>>> will fail. >>>>> Attempt to close the open stream first (in a try .. catch I suppose). >>>>> >>>>> -phil. >>>>> >>>>> On 6/15/16, 3:25 AM, prasanta sadhukhan wrote: >>>>>> >>>>>> Hi All, >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6218397 >>>>>> >>>>>> The issue was if the linux disk is full and we are trying to >>>>>> "print to file" then PrinterException is not thrown and a 0 byte >>>>>> file is created. >>>>>> >>>>>> Although I am not able to reproduce this behaviour, because when >>>>>> I make my disk full and try to run "java", I get >>>>>> >>>>>> /Java HotSpot(TM) Server VM warning: Insufficient space for >>>>>> shared memory file:// >>>>>> // 13783// >>>>>> //Try using the -Djava.io.tmpdir= option to select an alternate >>>>>> temp location./ >>>>>> >>>>>> but on investigating this, I see that we are calling >>>>>> f.createNewFile() in RasterPrinterJob#validateDestination() which >>>>>> creates a new, empty file >>>>>> >>>>>> but if there is any exception in PSPrinterJob#startDoc this file >>>>>> is not deleted. >>>>>> >>>>>> Modified the code to make sure if there is any exception, delete >>>>>> the file. >>>>>> >>>>>> http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.00/ >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> >>>>>> >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Thu Jun 30 07:45:27 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 30 Jun 2016 13:15:27 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-5049012: PrintToFile option is not disabled for flavors that do not support destination In-Reply-To: <5774137E.6090304@oracle.com> References: <57724BB4.40602@oracle.com> <5774137E.6090304@oracle.com> Message-ID: <5774CE17.2090209@oracle.com> Hi Phil, NPE will be thrown ---------- public boolean isAttributeValueSupported(Attribute attr, DocFlavor flavor, AttributeSet attributes) { if (attr == null) { throw new NullPointerException("null attribute"); } --------- before updateInfo() will be called so I guess null check is redundant there. Anyways, I have added the check back just to be safe http://cr.openjdk.java.net/~psadhukhan/5049012/webrev.01/ Regards Prasanta On 6/29/2016 11:59 PM, Philip Race wrote: > --- > https://docs.oracle.com/javase/8/docs/api/javax/print/PrintService.html#isAttributeValueSupported-javax.print.attribute.Attribute-javax.print.DocFlavor-javax.print.attribute.AttributeSet- > > > Throws: > NullPointerException - (unchecked exception) if attrval is null. > > -- > > So why did you remove the check for null ? > > > -phil. > > On 6/28/16, 3:04 AM, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a fix for an issue where it is seen that >> "Print-To-File" option is enabled even for flavors that do not >> support Destination attribute >> even though isAttributeValueSupported for that flavor returns false. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-5049012 >> webrev: http://cr.openjdk.java.net/~psadhukhan/5049012/webrev.00/ >> >> The reason for this behaviour is in Print Dialog code, the validation >> is done against isAttributeCategorySupported() which still returns >> true because Pageable and Printable supports it >> and therefore the "Print-to-File" option gets enabled. >> >> But print dialog is shown specific to a doc flavor and a print >> service (selected one) and hence must validate the attribute against >> the chosen doc flavor. >> So, the proposed fix checks the attributevalue is supported or not >> for that flavor to determine if we need to enable "Print-to-File" >> option in print dialog. >> >> Regards >> Prasanta From prasanta.sadhukhan at oracle.com Thu Jun 30 08:10:27 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 30 Jun 2016 13:40:27 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-5049012: PrintToFile option is not disabled for flavors that do not support destination In-Reply-To: <5774CE17.2090209@oracle.com> References: <57724BB4.40602@oracle.com> <5774137E.6090304@oracle.com> <5774CE17.2090209@oracle.com> Message-ID: <5774D3F3.1030407@oracle.com> On 6/30/2016 1:15 PM, Prasanta Sadhukhan wrote: > Hi Phil, > > NPE will be thrown > ---------- > public boolean isAttributeValueSupported(Attribute attr, > DocFlavor flavor, > AttributeSet attributes) { > if (attr == null) { > throw new NullPointerException("null attribute"); > } > --------- > before updateInfo() will be called so I guess null check is redundant > there. Anyways, I have added the check back just to be safe > http://cr.openjdk.java.net/~psadhukhan/5049012/webrev.01/ > ok sorry, I was thinking from testcase perspective where isAttributeSupported() was called before printDialog() where updateInfo() is called. I got your point but webrev.01 still stands Thanks Prasanta > Regards > Prasanta > On 6/29/2016 11:59 PM, Philip Race wrote: >> --- >> https://docs.oracle.com/javase/8/docs/api/javax/print/PrintService.html#isAttributeValueSupported-javax.print.attribute.Attribute-javax.print.DocFlavor-javax.print.attribute.AttributeSet- >> >> >> Throws: >> NullPointerException - (unchecked exception) if attrval is null. >> >> -- >> >> So why did you remove the check for null ? >> >> >> -phil. >> >> On 6/28/16, 3:04 AM, Prasanta Sadhukhan wrote: >>> Hi All, >>> >>> Please review a fix for an issue where it is seen that >>> "Print-To-File" option is enabled even for flavors that do not >>> support Destination attribute >>> even though isAttributeValueSupported for that flavor returns false. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-5049012 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/5049012/webrev.00/ >>> >>> The reason for this behaviour is in Print Dialog code, the >>> validation is done against isAttributeCategorySupported() which >>> still returns true because Pageable and Printable supports it >>> and therefore the "Print-to-File" option gets enabled. >>> >>> But print dialog is shown specific to a doc flavor and a print >>> service (selected one) and hence must validate the attribute against >>> the chosen doc flavor. >>> So, the proposed fix checks the attributevalue is supported or not >>> for that flavor to determine if we need to enable "Print-to-File" >>> option in print dialog. >>> >>> Regards >>> Prasanta > From jayathirth.d.v at oracle.com Thu Jun 30 09:39:17 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 30 Jun 2016 02:39:17 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6218397:Printing to file does not throw a PrinterException if the file cannot be created In-Reply-To: <5774A883.1010602@oracle.com> References: <576180D4.9040502@oracle.com> <1209f6f2-36df-6655-c542-d3836b11ff71@oracle.com> <7461a8f1-5263-a7b8-3dab-a4bd0733890b@oracle.com> <576BBCA8.2080800@oracle.com> <5774060C.3010205@oracle.com> <5774A883.1010602@oracle.com> Message-ID: <77c6c894-91ee-423a-a541-92a064fbecc1@default> Hi Prasanta, ? I think we can use same abortDoc() functionality in ?endDoc() -> mPSStream.checkError()? case as it is used in startDoc(). In abortDoc() we are closing mPSStream and deleting the spoolfile. Otherwise it will be a redundant code. ? Like : if (mPSStream.checkError()) { ??????????????? abortDoc(); throw new PrinterException("Error while writing to file"); } ? Thanks, Jay From: Prasanta Sadhukhan Sent: Thursday, June 30, 2016 10:35 AM To: Philip Race; Jayathirth D V Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-6218397:Printing to file does not throw a PrinterException if the file cannot be created ? Thanks Phil. @Jay, can you please review this updated webrev http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.04/ that takes care of this syntactic changes? Regards Prasanta On 6/29/2016 11:01 PM, Philip Race wrote: if (f.exists()) f.delete(); should use { ... } for the body - 2 cases of this one in each of the modified files. ? Other than that OK. I don't need to see an updated webrev so long as you make those syntactic changes. ? ? -phil On 6/23/16, 3:40 AM, Prasanta Sadhukhan wrote: Hi Phil, All, Based on the offline discussion, I added the case when disk gets filled while writing to the file. Since PrintStream does not throw IOException, I added check for checkError() to do the corresponding error handling. I added it after flush() as that is where the stream will be written to the file. HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/6218397/webrev.03/"http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.03/ Regards Prasanta On 6/20/2016 12:01 PM, prasanta sadhukhan wrote: Hi Phil,All, Added file delete in another case where we throw PrinterException. HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/6218397/webrev.02/"http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.02/ Regards Prasanta On 6/16/2016 1:40 PM, prasanta sadhukhan wrote: Modified webrev to close output stream. HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/6218397/webrev.01/"http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.01/ Regards Prasanta On 6/15/2016 9:52 PM, Philip Race wrote: If this is executed on Windows (shared Postscript stream printer could do this) then since the output stream is still open I expect the delete will fail. Attempt to close the open stream first (in a try .. catch I suppose). -phil. On 6/15/16, 3:25 AM, prasanta sadhukhan wrote: Hi All, Bug: https://bugs.openjdk.java.net/browse/JDK-6218397 The issue was if the linux disk is full and we are trying to "print to file" then PrinterException is not thrown and a 0 byte file is created. Although I am not able to reproduce this behaviour, because when I make my disk full and try to run "java", I get Java HotSpot(TM) Server VM warning: Insufficient space for shared memory file: ?? 13783 Try using the -Djava.io.tmpdir= option to select an alternate temp location. but on investigating this, I see that we are calling f.createNewFile() in RasterPrinterJob#validateDestination() which creates a new, empty file but if there is any exception in PSPrinterJob#startDoc this file is not deleted. Modified the code to make sure if there is any exception, delete the file. HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/6218397/webrev.00/"http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.00/ Regards Prasanta ? ? ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Thu Jun 30 09:45:16 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 30 Jun 2016 02:45:16 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6218397:Printing to file does not throw a PrinterException if the file cannot be created In-Reply-To: <77c6c894-91ee-423a-a541-92a064fbecc1@default> References: <576180D4.9040502@oracle.com> <1209f6f2-36df-6655-c542-d3836b11ff71@oracle.com> <7461a8f1-5263-a7b8-3dab-a4bd0733890b@oracle.com> <576BBCA8.2080800@oracle.com> <5774060C.3010205@oracle.com> <5774A883.1010602@oracle.com> <77c6c894-91ee-423a-a541-92a064fbecc1@default> Message-ID: <7fa6576a-1c18-4b12-9722-bfd576a711e3@default> Hi Prasanta, ? Forgot to mention. Please add evaluation in Bug and change fix version to 9 as we know it will cause problems while pushing the changes to repo. ? Thanks, Jay ? From: Jayathirth D V Sent: Thursday, June 30, 2016 3:09 PM To: Prasanta Sadhukhan; Philip Race Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-6218397:Printing to file does not throw a PrinterException if the file cannot be created ? Hi Prasanta, ? I think we can use same abortDoc() functionality in ?endDoc() -> mPSStream.checkError()? case as it is used in startDoc(). In abortDoc() we are closing mPSStream and deleting the spoolfile. Otherwise it will be a redundant code. ? Like : if (mPSStream.checkError()) { ??????????????? abortDoc(); throw new PrinterException("Error while writing to file"); } ? Thanks, Jay From: Prasanta Sadhukhan Sent: Thursday, June 30, 2016 10:35 AM To: Philip Race; Jayathirth D V Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-6218397:Printing to file does not throw a PrinterException if the file cannot be created ? Thanks Phil. @Jay, can you please review this updated webrev http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.04/ that takes care of this syntactic changes? Regards Prasanta On 6/29/2016 11:01 PM, Philip Race wrote: if (f.exists()) f.delete(); should use { ... } for the body - 2 cases of this one in each of the modified files. ? Other than that OK. I don't need to see an updated webrev so long as you make those syntactic changes. ? ? -phil On 6/23/16, 3:40 AM, Prasanta Sadhukhan wrote: Hi Phil, All, Based on the offline discussion, I added the case when disk gets filled while writing to the file. Since PrintStream does not throw IOException, I added check for checkError() to do the corresponding error handling. I added it after flush() as that is where the stream will be written to the file. HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/6218397/webrev.03/"http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.03/ Regards Prasanta On 6/20/2016 12:01 PM, prasanta sadhukhan wrote: Hi Phil,All, Added file delete in another case where we throw PrinterException. HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/6218397/webrev.02/"http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.02/ Regards Prasanta On 6/16/2016 1:40 PM, prasanta sadhukhan wrote: Modified webrev to close output stream. HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/6218397/webrev.01/"http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.01/ Regards Prasanta On 6/15/2016 9:52 PM, Philip Race wrote: If this is executed on Windows (shared Postscript stream printer could do this) then since the output stream is still open I expect the delete will fail. Attempt to close the open stream first (in a try .. catch I suppose). -phil. On 6/15/16, 3:25 AM, prasanta sadhukhan wrote: Hi All, Bug: https://bugs.openjdk.java.net/browse/JDK-6218397 The issue was if the linux disk is full and we are trying to "print to file" then PrinterException is not thrown and a 0 byte file is created. Although I am not able to reproduce this behaviour, because when I make my disk full and try to run "java", I get Java HotSpot(TM) Server VM warning: Insufficient space for shared memory file: ?? 13783 Try using the -Djava.io.tmpdir= option to select an alternate temp location. but on investigating this, I see that we are calling f.createNewFile() in RasterPrinterJob#validateDestination() which creates a new, empty file but if there is any exception in PSPrinterJob#startDoc this file is not deleted. Modified the code to make sure if there is any exception, delete the file. HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/6218397/webrev.00/"http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.00/ Regards Prasanta ? ? ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Thu Jun 30 09:49:26 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 30 Jun 2016 15:19:26 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6218397:Printing to file does not throw a PrinterException if the file cannot be created In-Reply-To: <77c6c894-91ee-423a-a541-92a064fbecc1@default> References: <576180D4.9040502@oracle.com> <1209f6f2-36df-6655-c542-d3836b11ff71@oracle.com> <7461a8f1-5263-a7b8-3dab-a4bd0733890b@oracle.com> <576BBCA8.2080800@oracle.com> <5774060C.3010205@oracle.com> <5774A883.1010602@oracle.com> <77c6c894-91ee-423a-a541-92a064fbecc1@default> Message-ID: <5774EB26.1040201@oracle.com> Hi Jay, Yes, we can do that. Updated webrev: http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.05/ Regards Prasanta On 6/30/2016 3:09 PM, Jayathirth D V wrote: > > Hi Prasanta, > > I think we can use same abortDoc() functionality in ?endDoc() -> > mPSStream.checkError()? case as it is used in startDoc(). > > In abortDoc() we are closing mPSStream and deleting the spoolfile. > Otherwise it will be a redundant code. > > Like : > > if (mPSStream.checkError()) { > > abortDoc(); > > throw new PrinterException("Error while writing to file"); > > } > > Thanks, > > Jay > > *From:*Prasanta Sadhukhan > *Sent:* Thursday, June 30, 2016 10:35 AM > *To:* Philip Race; Jayathirth D V > *Cc:* 2d-dev at openjdk.java.net > *Subject:* Re: [OpenJDK 2D-Dev] [9] RFR JDK-6218397:Printing to file > does not throw a PrinterException if the file cannot be created > > Thanks Phil. > @Jay, can you please review this updated webrev > http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.04/ > > that takes care of this syntactic changes? > > Regards > Prasanta > > On 6/29/2016 11:01 PM, Philip Race wrote: > > if (f.exists()) f.delete(); > > should use { ... } for the body - 2 cases of this one in each > > of the modified files. > > Other than that OK. I don't need to see an updated webrev > > so long as you make those syntactic changes. > > -phil > > > > On 6/23/16, 3:40 AM, Prasanta Sadhukhan wrote: > > Hi Phil, All, > > Based on the offline discussion, I added the case when disk > gets filled while writing to the file. > Since PrintStream does not throw IOException, I added check > for checkError() to do the corresponding error handling. I > added it after flush() as that is where the stream will be > written to the file. > http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.03/ > > > Regards > Prasanta > > On 6/20/2016 12:01 PM, prasanta sadhukhan wrote: > > Hi Phil,All, > > Added file delete in another case where we throw > PrinterException. > http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.02/ > > > Regards > Prasanta > > On 6/16/2016 1:40 PM, prasanta sadhukhan wrote: > > Modified webrev to close output stream. > > http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.01/ > > > Regards > Prasanta > > On 6/15/2016 9:52 PM, Philip Race wrote: > > If this is executed on Windows (shared Postscript > stream printer could do this) > then since the output stream is still open I > expect the delete will fail. > Attempt to close the open stream first (in a try > .. catch I suppose). > > -phil. > > On 6/15/16, 3:25 AM, prasanta sadhukhan wrote: > > Hi All, > > Bug: > https://bugs.openjdk.java.net/browse/JDK-6218397 > > The issue was if the linux disk is full and we > are trying to "print to file" then > PrinterException is not thrown and a 0 byte > file is created. > > Although I am not able to reproduce this > behaviour, because when I make my disk full > and try to run "java", I get > > /Java HotSpot(TM) Server VM warning: > Insufficient space for shared memory file: > 13783 > Try using the -Djava.io.tmpdir= option to > select an alternate temp location./ > > but on investigating this, I see that we are > calling f.createNewFile() in > RasterPrinterJob#validateDestination() which > creates a new, empty file > > but if there is any exception in > PSPrinterJob#startDoc this file is not deleted. > > Modified the code to make sure if there is any > exception, delete the file. > > http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.00/ > > > Regards > Prasanta > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Thu Jun 30 10:16:28 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 30 Jun 2016 03:16:28 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6218397:Printing to file does not throw a PrinterException if the file cannot be created In-Reply-To: <5774EB26.1040201@oracle.com> References: <576180D4.9040502@oracle.com> <1209f6f2-36df-6655-c542-d3836b11ff71@oracle.com> <7461a8f1-5263-a7b8-3dab-a4bd0733890b@oracle.com> <576BBCA8.2080800@oracle.com> <5774060C.3010205@oracle.com> <5774A883.1010602@oracle.com> <77c6c894-91ee-423a-a541-92a064fbecc1@default> <5774EB26.1040201@oracle.com> Message-ID: <16e22c79-d151-4522-9b2c-502ed6b7c268@default> Hi Prasanta, ? Changes are fine. ? Thanks, Jay ? From: Prasanta Sadhukhan Sent: Thursday, June 30, 2016 3:19 PM To: Jayathirth D V; Philip Race Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-6218397:Printing to file does not throw a PrinterException if the file cannot be created ? Hi Jay, Yes, we can do that. Updated webrev: http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.05/ Regards Prasanta On 6/30/2016 3:09 PM, Jayathirth D V wrote: Hi Prasanta, ? I think we can use same abortDoc() functionality in ?endDoc() -> mPSStream.checkError()? case as it is used in startDoc(). In abortDoc() we are closing mPSStream and deleting the spoolfile. Otherwise it will be a redundant code. ? Like : if (mPSStream.checkError()) { ??????????????? abortDoc(); throw new PrinterException("Error while writing to file"); } ? Thanks, Jay From: Prasanta Sadhukhan Sent: Thursday, June 30, 2016 10:35 AM To: Philip Race; Jayathirth D V Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-6218397:Printing to file does not throw a PrinterException if the file cannot be created ? Thanks Phil. @Jay, can you please review this updated webrev http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.04/ that takes care of this syntactic changes? Regards Prasanta On 6/29/2016 11:01 PM, Philip Race wrote: if (f.exists()) f.delete(); should use { ... } for the body - 2 cases of this one in each of the modified files. ? Other than that OK. I don't need to see an updated webrev so long as you make those syntactic changes. ? ? -phil On 6/23/16, 3:40 AM, Prasanta Sadhukhan wrote: Hi Phil, All, Based on the offline discussion, I added the case when disk gets filled while writing to the file. Since PrintStream does not throw IOException, I added check for checkError() to do the corresponding error handling. I added it after flush() as that is where the stream will be written to the file. HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/6218397/webrev.03/"http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.03/ Regards Prasanta On 6/20/2016 12:01 PM, prasanta sadhukhan wrote: Hi Phil,All, Added file delete in another case where we throw PrinterException. HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/6218397/webrev.02/"http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.02/ Regards Prasanta On 6/16/2016 1:40 PM, prasanta sadhukhan wrote: Modified webrev to close output stream. HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/6218397/webrev.01/"http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.01/ Regards Prasanta On 6/15/2016 9:52 PM, Philip Race wrote: If this is executed on Windows (shared Postscript stream printer could do this) then since the output stream is still open I expect the delete will fail. Attempt to close the open stream first (in a try .. catch I suppose). -phil. On 6/15/16, 3:25 AM, prasanta sadhukhan wrote: Hi All, Bug: https://bugs.openjdk.java.net/browse/JDK-6218397 The issue was if the linux disk is full and we are trying to "print to file" then PrinterException is not thrown and a 0 byte file is created. Although I am not able to reproduce this behaviour, because when I make my disk full and try to run "java", I get Java HotSpot(TM) Server VM warning: Insufficient space for shared memory file: ?? 13783 Try using the -Djava.io.tmpdir= option to select an alternate temp location. but on investigating this, I see that we are calling f.createNewFile() in RasterPrinterJob#validateDestination() which creates a new, empty file but if there is any exception in PSPrinterJob#startDoc this file is not deleted. Modified the code to make sure if there is any exception, delete the file. HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/6218397/webrev.00/"http://cr.openjdk.java.net/~psadhukhan/6218397/webrev.00/ Regards Prasanta ? ? ? ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Thu Jun 30 10:31:07 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 30 Jun 2016 16:01:07 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6789262: getPageFormat doesn't apply PrintRequestAttributeSet specified In-Reply-To: <57740C8B.10609@oracle.com> References: <57710D96.8010808@oracle.com> <57740C8B.10609@oracle.com> Message-ID: <5774F4EB.7050806@oracle.com> Hi Phil, I modified the method to check for "fit" rather than perfect match as you suggested. Please find the modified webrev http://cr.openjdk.java.net/~psadhukhan/6789262/webrev.01/ Regards Prasanta On 6/29/2016 11:29 PM, Philip Race wrote: > This is actually a little subtle. > > The check you are deleting has been there since 2000 .. > and it can't just be removed. But it need adjusting. > This is the subtlety. Most of the attribute checks > are yes/no. I think for this one we need to look at > the actual dimensions and return true if it is "fits" > So isSupportedMediaPrintableArea needs to do more than "equals" > I am not 100% sure that won't surprise some other code but > as far as I can think right now it seems the right thing to do. > > -phil. > > On 6/27/16, 4:27 AM, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a fix for an issue where it was found that setting left >> margin of 2" is ignored and when we query >> PrinterJob.job.getPageFormat(PrintRequestAttributeSet) >> we get the default paper mediapritable area of x=1" instead of the >> set 2". >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-6789262 >> webrev: http://cr.openjdk.java.net/~psadhukhan/6789262/webrev.00/ >> >> This is because >> it was found that getPageFormat() calls >> Win32PrintService#isAttributeValueSupported() where we call >> isSupportedMediaPrintableArea() >> to check if the mediaprintable area is matching with the media size >> that has been cached. It gets the paperID by calling findPaperID() >> and stores the mpa of that paper in MediaPrintableArea[] >> I see that my printer supports 43 mediasize names (like iso_a4, >> iso_a5, na_letter etc) and none of the 43 mediaPrintables equals the >> mpa value of (50.4, 25.4, 133.8, 246.2)mm >> >> ---------------isSupportedMediaPrintableArea()--------- >> if (mediaPrintables != null) { >> for (int i=0; i> if (mpa.equals(mediaPrintables[i])) { >> return true; >> } >> } >> } >> ---------------------- >> So, it seems this check isSupportedMediaPrintableArea() is preventing >> valid mpa values to be propagated to RasterPrinterJob to be used for >> printing. >> >> I see in linux and mac, *IPPPrintService*#isAttributeValueSupported() >> is called which does not have this isSupportedMediaPrintableArea() >> check and there this left margin of 2" is not ignored and stored >> properly. >> >> So, the proposed fix do away with this >> isSupportedMediaPrintableArea() call from >> Win32PrintService#isAttributeValueSupported. >> >> Regards >> Prasanta >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajit.ghaisas at oracle.com Thu Jun 30 13:41:07 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Thu, 30 Jun 2016 06:41:07 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] Fix for JDK-8160421 : Regression: JDK-8139192 causes NPE in java.awt.Toolkit.createCustomCursor() Message-ID: Hi, Bug : This is regarding a NPE getting printed as stacktrace in java.awt.Toolkit.createCustomCursor() method. The bug is described at : https://bugs.openjdk.java.net/browse/JDK-8160421 Root Cause : Fix of bug JDK-8139192 : Custom ImageFilters return blank images in Java 8(.45) while working in 7. The above fix added a RuntimeException catch & log mechanism to support a ImageFilter which was broken due to the second imageComplete() call in OffScreenImageSource.produce() method. Analysis: Without the fix of JDK-8139192, java.awt.Toolkit.createCustomCursor() call results in NullPointerException when imageComplete(ImageConsumer.STATICIMAGEDONE) call is made - but, it gets consumed silently. Cathing RuntimeException() out of imageComplete(ImageConsumer.STATICIMAGEDONE) was added to fix JDK-8160421. This started catching & logging the exception in case 'theConsumer' has unregistered itself as a result of call theConsumer.imageComplete(ImageConsumer.SINGLEFRAMEDONE); This log is undesirable as this mechanism is used in java.awt.Toolkit.createCustomCursor() and may be in other places. Fix : Make the call to imageComplete(ImageConsumer.STATICIMAGEDONE) only if 'theConsumer' has not been unregistered. Webrev: http://cr.openjdk.java.net/~aghaisas/8160421/webrev.00/ Request you to review. Regards, Ajit From philip.race at oracle.com Thu Jun 30 14:20:44 2016 From: philip.race at oracle.com (Philip Race) Date: Thu, 30 Jun 2016 07:20:44 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-5049012: PrintToFile option is not disabled for flavors that do not support destination In-Reply-To: <5774CE17.2090209@oracle.com> References: <57724BB4.40602@oracle.com> <5774137E.6090304@oracle.com> <5774CE17.2090209@oracle.com> Message-ID: <57752ABC.4020406@oracle.com> Eh ? Before your change the code was calling isAttributeCategorySupported(), notisAttributeValueSupported() So there was not previously a possibility of that NPE, and my point was now you have changed that call you need that !=null check even more .. But I think there is still a problem. Now dstSupported is set only if the *specific* destination is supported. A malformed file: URL would not be valid but should not disable (grey out) the print to file checkbox which is what it looks like here .. can you verify this ? -phil On 6/30/16, 12:45 AM, Prasanta Sadhukhan wrote: > Hi Phil, > > NPE will be thrown > ---------- > public boolean isAttributeValueSupported(Attribute attr, > DocFlavor flavor, > AttributeSet attributes) { > if (attr == null) { > throw new NullPointerException("null attribute"); > } > --------- > before updateInfo() will be called so I guess null check is redundant > there. Anyways, I have added the check back just to be safe > http://cr.openjdk.java.net/~psadhukhan/5049012/webrev.01/ > > Regards > Prasanta > On 6/29/2016 11:59 PM, Philip Race wrote: >> --- >> https://docs.oracle.com/javase/8/docs/api/javax/print/PrintService.html#isAttributeValueSupported-javax.print.attribute.Attribute-javax.print.DocFlavor-javax.print.attribute.AttributeSet- >> >> >> Throws: >> NullPointerException - (unchecked exception) if attrval is null. >> >> -- >> >> So why did you remove the check for null ? >> >> >> -phil. >> >> On 6/28/16, 3:04 AM, Prasanta Sadhukhan wrote: >>> Hi All, >>> >>> Please review a fix for an issue where it is seen that >>> "Print-To-File" option is enabled even for flavors that do not >>> support Destination attribute >>> even though isAttributeValueSupported for that flavor returns false. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-5049012 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/5049012/webrev.00/ >>> >>> The reason for this behaviour is in Print Dialog code, the >>> validation is done against isAttributeCategorySupported() which >>> still returns true because Pageable and Printable supports it >>> and therefore the "Print-to-File" option gets enabled. >>> >>> But print dialog is shown specific to a doc flavor and a print >>> service (selected one) and hence must validate the attribute against >>> the chosen doc flavor. >>> So, the proposed fix checks the attributevalue is supported or not >>> for that flavor to determine if we need to enable "Print-to-File" >>> option in print dialog. >>> >>> Regards >>> Prasanta > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Jun 30 17:02:11 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 30 Jun 2016 20:02:11 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8160124 SunGraphics2D.hitClip() can give wrong result for floating point scale In-Reply-To: <5e4a062a-a552-85c2-d6af-9c21b3616278@oracle.com> References: <7de7d230-3f62-272e-437a-ea42bd739e88@oracle.com> <5e4a062a-a552-85c2-d6af-9c21b3616278@oracle.com> Message-ID: <57c555af-061f-8b6c-fe13-d9b294d9aa99@oracle.com> It looks strange that the empty clip became "non-empty"(at least hitClip reports this) when we apply transform to it, no? I guess that at the beginning of hitClip() we should check that the clip.isEmpty(), and we should return "false" in this case(I think this is not strictly related to this bug)? On 24.06.16 1:14, Jim Graham wrote: > Think of this method as asking: > > I don't want you to waste a lot of time, but tell me if it is silly for > me to even consider rendering something with these bounds. > > And the answer is either "Oh, yeah, it is inconceivable that those > bounds would be rendered", or "Not sure, maybe, just render it and > see". There may be some cases where it knows "I know for sure that lots > of stuff will render through the clip", but that is not where the > divining line is here in terms of when the answer becomes true - it > becomes true when there is a chance that it might render something. > > Arguably, the user-space comparison against the user-space clip that you > added here can never be accurate even if you allow for "false > positives". The clip is rasterized and whole pixels are chosen based on > various criteria that affect clip rasterization. Thus, while the > theoretical clip is at N.5, our rasterization choice has us render > anything that hits pixel N, even if the contribution of the rendered > primitive is only for the first half of N. That pixel might be rendered > if anything hits any part of it, depending on what rendering operation > is being done. > > So, your "fix" actually breaks the functionality because it is quite > possible that something with a bounding box that stops before N.5 might > affect pixel N and cause it to be rendered even though your new answer > suggested that it wouldn't happen. Your code might actually cause a > bug, not fix one. > > (There are also some potential theoretical failures related to how AA > and STROKE_CONTROL might perturb our rendering, effects which are ignore > by the current implementation of hitClip(), however I believe that all > of those effects fit within the current implementation - it's just that > I don't think anyone has ever proven this, or written an exhaustive test > suite to verify that none of our rendering hints can perturb rendering > by enough to create some surprises here...) > > ...jim > > On 6/23/16 3:00 PM, Jim Graham wrote: >> Since "return true" would be a compliant implementation of >> Graphics.hitClip(), this is not a bug... >> >> Read the documentation, it is allowed to use fast math that can return >> true when technically the answer is false... >> >> ...jim >> >> On 6/23/16 5:04 AM, Alexandr Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the fix: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8160124 >>> webrev: http://cr.openjdk.java.net/~alexsch/8160124/webrev.00 >>> >>> Let's set the clip [x=5, y=5, width=5, height=5] to a graphics and >>> call the hitClip() with the passed rectangle [x=0, >>> y=0, width=5, height=5]. >>> >>> The result is false for the graphics with scale 1 and true if the >>> scale is floating point 1.5. >>> >>> This is because the transformed clip which has floating point >>> bounds [7.5, 7.5, 7.5, 7.5] for the scale 1.5 has bounds >>> with rounded down upper-left and rounded up lower-right corners [7, >>> 7, 8, 8] which now intersects with the transformed >>> rectangle [0, 0, 7.5, 7.5]. >>> >>> The proposed fix adds additional check for the user clip and the >>> user rectangle intersection if the intersection with >>> the region clip passes. >>> >>> Thanks, >>> Alexandr. >>> >>> -- Best regards, Sergey. From philip.race at oracle.com Thu Jun 30 21:59:03 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 30 Jun 2016 14:59:03 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6789262: getPageFormat doesn't apply PrintRequestAttributeSet specified In-Reply-To: <5774F4EB.7050806@oracle.com> References: <57710D96.8010808@oracle.com> <57740C8B.10609@oracle.com> <5774F4EB.7050806@oracle.com> Message-ID: <57759627.5010203@oracle.com> Shouldn't these all be >= and <= ? Else (eg) for X==1 in both cases you would return false when it should be true .. f ((mpa.getX(units) > mediaPrintables[i].getX(units)) && -phil. On 06/30/2016 03:31 AM, Prasanta Sadhukhan wrote: > Hi Phil, > > I modified the method to check for "fit" rather than perfect match as > you suggested. > Please find the modified webrev > http://cr.openjdk.java.net/~psadhukhan/6789262/webrev.01/ > > Regards > Prasanta > On 6/29/2016 11:29 PM, Philip Race wrote: >> This is actually a little subtle. >> >> The check you are deleting has been there since 2000 .. >> and it can't just be removed. But it need adjusting. >> This is the subtlety. Most of the attribute checks >> are yes/no. I think for this one we need to look at >> the actual dimensions and return true if it is "fits" >> So isSupportedMediaPrintableArea needs to do more than "equals" >> I am not 100% sure that won't surprise some other code but >> as far as I can think right now it seems the right thing to do. >> >> -phil. >> >> On 6/27/16, 4:27 AM, Prasanta Sadhukhan wrote: >>> Hi All, >>> >>> Please review a fix for an issue where it was found that setting >>> left margin of 2" is ignored and when we query >>> PrinterJob.job.getPageFormat(PrintRequestAttributeSet) >>> we get the default paper mediapritable area of x=1" instead of the >>> set 2". >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-6789262 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/6789262/webrev.00/ >>> >>> This is because >>> it was found that getPageFormat() calls >>> Win32PrintService#isAttributeValueSupported() where we call >>> isSupportedMediaPrintableArea() >>> to check if the mediaprintable area is matching with the media size >>> that has been cached. It gets the paperID by calling findPaperID() >>> and stores the mpa of that paper in MediaPrintableArea[] >>> I see that my printer supports 43 mediasize names (like iso_a4, >>> iso_a5, na_letter etc) and none of the 43 mediaPrintables equals the >>> mpa value of (50.4, 25.4, 133.8, 246.2)mm >>> >>> ---------------isSupportedMediaPrintableArea()--------- >>> if (mediaPrintables != null) { >>> for (int i=0; i>> if (mpa.equals(mediaPrintables[i])) { >>> return true; >>> } >>> } >>> } >>> ---------------------- >>> So, it seems this check isSupportedMediaPrintableArea() is >>> preventing valid mpa values to be propagated to RasterPrinterJob to >>> be used for printing. >>> >>> I see in linux and mac, >>> *IPPPrintService*#isAttributeValueSupported() is called which does >>> not have this isSupportedMediaPrintableArea() check and there this >>> left margin of 2" is not ignored and stored properly. >>> >>> So, the proposed fix do away with this >>> isSupportedMediaPrintableArea() call from >>> Win32PrintService#isAttributeValueSupported. >>> >>> Regards >>> Prasanta >>> >>> >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Jun 30 22:25:27 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 30 Jun 2016 15:25:27 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8160693: ScriptRunData.java uses bitwise AND instead of logical AND Message-ID: <57759C57.2080700@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8160693 Fix :- hg diff src/java.desktop/share/classes/sun/font/ScriptRunData.java diff --git a/src/java.desktop/share/classes/sun/font/ScriptRunData.java b/src/java.desktop/share/classes/sun/font/ScriptRunData.java --- a/src/java.desktop/share/classes/sun/font/ScriptRunData.java +++ b/src/java.desktop/share/classes/sun/font/ScriptRunData.java @@ -44,7 +44,7 @@ if (cp >= data[cache] && cp < data[cache+2]) { return data[cache+1]; } - if (cp >= CHAR_START & cp < CHAR_LIMIT) { + if ((cp >= CHAR_START) && (cp < CHAR_LIMIT)) { int probe = dataPower; int index = 0; -phil. From philip.race at oracle.com Thu Jun 30 23:09:55 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 30 Jun 2016 16:09:55 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8160695 : getHBScriptCode script code validation Message-ID: <5775A6C3.6080209@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8160695 A simple fix to ensure we check an array index is positive. In fact the value is always positive anyway, so this is just for "extra" safety. diff --git a/src/java.desktop/share/native/libfontmanager/scriptMapping.c b/src/java.desktop/share/native/libfontmanager/scriptMapping.c --- a/src/java.desktop/share/native/libfontmanager/scriptMapping.c +++ b/src/java.desktop/share/native/libfontmanager/scriptMapping.c @@ -85,7 +85,7 @@ int MAX_ICU_SCRIPTCODE = 45; hb_script_t getHBScriptCode(int code) { - if (code > MAX_ICU_SCRIPTCODE) { + if ((code < 0) || (code > MAX_ICU_SCRIPTCODE)) { return HB_SCRIPT_INVALID; } return ICU_to_Harfbuzz_ScriptCode[code]; -phil. From brian.burkhalter at oracle.com Thu Jun 30 23:38:16 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 30 Jun 2016 16:38:16 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8160695 : getHBScriptCode script code validation In-Reply-To: <5775A6C3.6080209@oracle.com> References: <5775A6C3.6080209@oracle.com> Message-ID: +1 Brian On Jun 30, 2016, at 4:09 PM, Phil Race wrote: > https://bugs.openjdk.java.net/browse/JDK-8160695 > > A simple fix to ensure we check an array index is positive. > In fact the value is always positive anyway, so this is just for "extra" safety. > > diff --git a/src/java.desktop/share/native/libfontmanager/scriptMapping.c b/src/java.desktop/share/native/libfontmanager/scriptMapping.c > --- a/src/java.desktop/share/native/libfontmanager/scriptMapping.c > +++ b/src/java.desktop/share/native/libfontmanager/scriptMapping.c > @@ -85,7 +85,7 @@ > int MAX_ICU_SCRIPTCODE = 45; > > hb_script_t getHBScriptCode(int code) { > - if (code > MAX_ICU_SCRIPTCODE) { > + if ((code < 0) || (code > MAX_ICU_SCRIPTCODE)) { > return HB_SCRIPT_INVALID; > } > return ICU_to_Harfbuzz_ScriptCode[code]; > > > -phil. > From james.graham at oracle.com Thu Jun 30 23:43:17 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 30 Jun 2016 16:43:17 -0700 Subject: [OpenJDK 2D-Dev] [9] Fix for JDK-8160421 : Regression: JDK-8139192 causes NPE in java.awt.Toolkit.createCustomCursor() In-Reply-To: References: Message-ID: <5775AE95.5070302@oracle.com> The solution looks fine to me. I didn't run the test case, but about the only issue I can see with it is whether it should have a flag to run it in its own VM because of its interaction with System.err. Phil? ...jim On 06/30/2016 06:41 AM, Ajit Ghaisas wrote: > Hi, > > Bug : > This is regarding a NPE getting printed as stacktrace in java.awt.Toolkit.createCustomCursor() method. > The bug is described at : https://bugs.openjdk.java.net/browse/JDK-8160421 > > Root Cause : > Fix of bug JDK-8139192 : Custom ImageFilters return blank images in Java 8(.45) while working in 7. > The above fix added a RuntimeException catch & log mechanism to support a ImageFilter which was broken due to the second imageComplete() call in OffScreenImageSource.produce() method. > > Analysis: > Without the fix of JDK-8139192, java.awt.Toolkit.createCustomCursor() call results in > NullPointerException when imageComplete(ImageConsumer.STATICIMAGEDONE) call is made - but, it gets consumed silently. > Cathing RuntimeException() out of imageComplete(ImageConsumer.STATICIMAGEDONE) was added to fix JDK-8160421. > This started catching & logging the exception in case 'theConsumer' has unregistered itself as a result of call > theConsumer.imageComplete(ImageConsumer.SINGLEFRAMEDONE); > This log is undesirable as this mechanism is used in java.awt.Toolkit.createCustomCursor() and may be in other places. > > Fix : > Make the call to imageComplete(ImageConsumer.STATICIMAGEDONE) only if 'theConsumer' has not been unregistered. > > Webrev: > http://cr.openjdk.java.net/~aghaisas/8160421/webrev.00/ > > Request you to review. > > Regards, > Ajit > From james.graham at oracle.com Thu Jun 30 23:49:12 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 30 Jun 2016 16:49:12 -0700 Subject: [OpenJDK 2D-Dev] [9] Review request for 8160124 SunGraphics2D.hitClip() can give wrong result for floating point scale In-Reply-To: <57c555af-061f-8b6c-fe13-d9b294d9aa99@oracle.com> References: <7de7d230-3f62-272e-437a-ea42bd739e88@oracle.com> <5e4a062a-a552-85c2-d6af-9c21b3616278@oracle.com> <57c555af-061f-8b6c-fe13-d9b294d9aa99@oracle.com> Message-ID: <5775AFF8.5060006@oracle.com> How is it returning true? If the clip really is empty, then intersectsQuickCheck() should never return true. Or are you saying that an empty clip shape produces a non-empty composite clip region? ...jim On 06/30/2016 10:02 AM, Sergey Bylokhov wrote: > It looks strange that the empty clip became "non-empty"(at least hitClip > reports this) when we apply transform to it, no? I guess that at the > beginning of hitClip() we should check that the clip.isEmpty(), and we > should return "false" in this case(I think this is not strictly related > to this bug)? > > On 24.06.16 1:14, Jim Graham wrote: >> Think of this method as asking: >> >> I don't want you to waste a lot of time, but tell me if it is silly for >> me to even consider rendering something with these bounds. >> >> And the answer is either "Oh, yeah, it is inconceivable that those >> bounds would be rendered", or "Not sure, maybe, just render it and >> see". There may be some cases where it knows "I know for sure that lots >> of stuff will render through the clip", but that is not where the >> divining line is here in terms of when the answer becomes true - it >> becomes true when there is a chance that it might render something. >> >> Arguably, the user-space comparison against the user-space clip that you >> added here can never be accurate even if you allow for "false >> positives". The clip is rasterized and whole pixels are chosen based on >> various criteria that affect clip rasterization. Thus, while the >> theoretical clip is at N.5, our rasterization choice has us render >> anything that hits pixel N, even if the contribution of the rendered >> primitive is only for the first half of N. That pixel might be rendered >> if anything hits any part of it, depending on what rendering operation >> is being done. >> >> So, your "fix" actually breaks the functionality because it is quite >> possible that something with a bounding box that stops before N.5 might >> affect pixel N and cause it to be rendered even though your new answer >> suggested that it wouldn't happen. Your code might actually cause a >> bug, not fix one. >> >> (There are also some potential theoretical failures related to how AA >> and STROKE_CONTROL might perturb our rendering, effects which are ignore >> by the current implementation of hitClip(), however I believe that all >> of those effects fit within the current implementation - it's just that >> I don't think anyone has ever proven this, or written an exhaustive test >> suite to verify that none of our rendering hints can perturb rendering >> by enough to create some surprises here...) >> >> ...jim >> >> On 6/23/16 3:00 PM, Jim Graham wrote: >>> Since "return true" would be a compliant implementation of >>> Graphics.hitClip(), this is not a bug... >>> >>> Read the documentation, it is allowed to use fast math that can return >>> true when technically the answer is false... >>> >>> ...jim >>> >>> On 6/23/16 5:04 AM, Alexandr Scherbatiy wrote: >>>> >>>> Hello, >>>> >>>> Could you review the fix: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160124 >>>> webrev: http://cr.openjdk.java.net/~alexsch/8160124/webrev.00 >>>> >>>> Let's set the clip [x=5, y=5, width=5, height=5] to a graphics and >>>> call the hitClip() with the passed rectangle [x=0, >>>> y=0, width=5, height=5]. >>>> >>>> The result is false for the graphics with scale 1 and true if the >>>> scale is floating point 1.5. >>>> >>>> This is because the transformed clip which has floating point >>>> bounds [7.5, 7.5, 7.5, 7.5] for the scale 1.5 has bounds >>>> with rounded down upper-left and rounded up lower-right corners [7, >>>> 7, 8, 8] which now intersects with the transformed >>>> rectangle [0, 0, 7.5, 7.5]. >>>> >>>> The proposed fix adds additional check for the user clip and the >>>> user rectangle intersection if the intersection with >>>> the region clip passes. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> > > From james.graham at oracle.com Thu Jun 30 23:51:16 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 30 Jun 2016 16:51:16 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8160693: ScriptRunData.java uses bitwise AND instead of logical AND In-Reply-To: <57759C57.2080700@oracle.com> References: <57759C57.2080700@oracle.com> Message-ID: <5775B074.5000906@oracle.com> I don't see the need for the extra parentheses in this particular case, but the change/fix looks good... ...jim On 06/30/2016 03:25 PM, Phil Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8160693 > > Fix :- > hg diff src/java.desktop/share/classes/sun/font/ScriptRunData.java > diff --git a/src/java.desktop/share/classes/sun/font/ScriptRunData.java > b/src/java.desktop/share/classes/sun/font/ScriptRunData.java > --- a/src/java.desktop/share/classes/sun/font/ScriptRunData.java > +++ b/src/java.desktop/share/classes/sun/font/ScriptRunData.java > @@ -44,7 +44,7 @@ > if (cp >= data[cache] && cp < data[cache+2]) { > return data[cache+1]; > } > - if (cp >= CHAR_START & cp < CHAR_LIMIT) { > + if ((cp >= CHAR_START) && (cp < CHAR_LIMIT)) { > int probe = dataPower; > int index = 0; > > > -phil. >