From jayathirth.d.v at oracle.com Mon Feb 1 09:04:07 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 1 Feb 2016 01:04:07 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review request for JDK-8147413 : api/java_awt/Image/MultiResolutionImage/index.html\#MultiResolutionRenderingHints[test_VALUE_RESOLUTION_VARIANT_BASE] started to fail In-Reply-To: <56A213E7.8090903@oracle.com> References: <569FF4C4.4030102@oracle.com> <56A140EB.90402@oracle.com> <56A213E7.8090903@oracle.com> Message-ID: Hi Alex, Since two separate bugs are created for the suggestions given by Jim. And you are okay with the fix provided for the bug https://bugs.openjdk.java.net/browse/JDK-8147413 under webrev http://cr.openjdk.java.net/~jdv/8147413/webrev.00/ Can we push the fix into JDK9 after one more approval? Thanks, Jay -----Original Message----- From: Alexander Scherbatiy Sent: Friday, January 22, 2016 5:05 PM To: Jim Graham; Phil Race; Jayathirth D V Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review request for JDK-8147413 : api/java_awt/Image/MultiResolutionImage/index.html\#MultiResolutionRenderingHints[test_VALUE_RESOLUTION_VARIANT_BASE] started to fail I have created two separated issues on it: 8148045 Handle null resolution variant in SunGraphics2D https://bugs.openjdk.java.net/browse/JDK-8148045 8148046 Investigate the case where MRI.getResolutionVariant() returns MultiResolutionImage https://bugs.openjdk.java.net/browse/JDK-8148046 Thanks, Alexandr. On 22/01/16 00:34, Jim Graham wrote: > BASE essentially just means to draw the 1:1 image. The problem is > that returning null is not the way to achieve that. Returning null > means "MRI doesn't apply here, just use the original image", but in > the case of BASE we have to make sure it isn't an MRI first otherwise > the caller will get an exception. > > The change does achieve that since BASE handling is built in to the > helper getResolutionVariant() method in SG2D and so it should ask for > the 1:1 image, but if the getRV() helper method returns null then we > still return null from the drawHiDPIImage() method and that causes the > caller to use the original MRI in a normal-image pipeline. There > should perhaps be an else clause for the "if (rV != img && rV != null) > { } else { ???; }". What that "???" is depends on why the helper > method returned the original image and/or a null, but it should not be > "return null;". (Also, there is no check if it returned another > different MRI. That should probably not be allowed, but we never state > that in the interface description...) > > The remaining question is why the helper method would return either > the original image or null. > > I don't think the helper method ever returns the original MRI > knowingly, but the MRI itself might do that. That would then fall > under the "what to do if the MRI returns any sort of non-standard > image" case, and perhaps the exception is appropriate there? We > should probably detect that, though, and throw a more obvious > exception (or recurse?). Recursion can get ugly, so perhaps a very > explicit error with a reasonable description would be better than > letting the DrawImage pipeline fail in various ways. > > The helper function can return null if the operation is a NOP (sxy1 == > sxy2 - i.e. an empty subimage rectangle), but that case should be > handled here and end up with returning ?true? which matches what many > of the drawImage() variants return when they detect a trivial NOP case. > > The helper function can also return null if the srcWidth/Height are > negative which would imply an uninitialized image. I'm not sure what > to do there because normally an uninitialized image is tracked by the > DrawImage pipe and the observer is notified as the image data is > loaded, but we have no mechanism to do that with an MRI. This case > may require more work, or something explicit in the MRI spec (what > happens when someone lazily loads an image with an @x2 variant now?). > > It also returns null if the return value from the MRI is a > ToolkitImage with an error - but I think that is wrong, it should just > return the ToolkitImage and let the caller send it to the DrawImage > pipeline to detect the error and respond in the appropriate manner. > Or perhaps it should cause the drawHiDPIImage() method to return > whatever boolean is appropriate for an error to save time, but there > is no way to orchestrate that from the helper method since it can only > return a (non-MRI) image. It's probably best to just return the > errored TKImage in that case...? > > The last way it can return null is if the MRI returned null from its > getRV() method, but the interface doesn't discuss what that means. I > suppose it might mean that all of the resolution variants are being > loaded asynchronously and none of them are available yet, but we are > then missing a mechanism to inform the observer of when the variants > are loaded. (Is there a bugid for that? I seem to recall having a > discussion about that missing mechanism in the past...?) > > So, I think the change made here is along the right track, but we have > a couple more holes to plug before we can consider this fixed... > > ...jim > > On 1/20/2016 12:57 PM, Phil Race wrote: >> It seems like the expectation was that BASE could be drawn by the old >> imaging path. >> which would be lower overhead. >> I think we should ask Alexandr what the intention was here and >> whether the code that handles the base image needs to be taught how >> to extract data from a MultiResolutionImage. >> >> -phil. >> >> On 01/20/2016 08:20 AM, Jayathirth D V wrote: >>> >>> Hi, >>> >>> __ >>> >>> _Please review the following fix in JDK9:_ >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8147413 >>> >>> Webrev : http://cr.openjdk.java.net/~jdv/8147413/webrev.00/ >>> >>> >>> Issue : JCK testcase >>> api/java_awt/Image/MultiResolutionImage/index.html\#MultiResolutionR >>> enderingHints[test_VALUE_RESOLUTION_VARIANT_BASE] >>> >>> is failing from b96 JDK9 build. >>> >>> Root cause : In getManager API of SurfaceManager.java we are trying >>> to typecast BaseMultiResolutionImage to BufferedImage and it is >>> causing ClassCastException and in turn IllegalArgumentException seen >>> in result of test case. It is happening because of change made in >>> JDK-8073320 in >>> SunGraphics2D.java. In case of VALUE_RESOLUTION_VARIANT_BASE type we >>> are not trying to convert MultiResolutionImage to BufferedImage. >>> >>> Solution : Modify the condition present in drawHiDPIImage API to >>> convert all MultiResolutionImage to BufferedImage irrespective of >>> KEY_RESOLUTION_VARIANT type. >>> >>> Thanks, >>> >>> Jay >>> >> From semyon.sadetsky at oracle.com Mon Feb 1 09:23:30 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 1 Feb 2016 12:23:30 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8146042 Offscreen rendering is different from onscreen one In-Reply-To: <56A0E584.3050204@oracle.com> References: <5697E44B.2040100@oracle.com> <5697E7B1.2080207@oracle.com> <569898C4.1030404@oracle.com> <5698F46A.5020809@oracle.com> <5699025C.7030904@oracle.com> <5699143A.4070408@oracle.com> <56992111.9000501@oracle.com> <5699603C.6000200@oracle.com> <569E1E4E.9080309@oracle.com> <56A0E584.3050204@oracle.com> Message-ID: <56AF2412.3040905@oracle.com> On 1/21/2016 5:04 PM, Sergey Bylokhov wrote: > On 19/01/16 14:30, Semyon Sadetsky wrote: >> We are getting error because of incorrect fudge factor added to the "to" >> line coordinates (for line from - to). >> See the updated version of the fix in which test should work on OS X: >> http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.02/ >> Test fails on my mac book-pro with integrated i7 GPU - rectangle is >> drawn at wrong position. > > It will fail on any hdpi systems(including osx+retina), The reason is > that: when you create a VolatileImage it will take into account > default transform of the GraphicsConfiguration(on hdpi systems it will > be x2). When you draw a line to this VI and then take s spapshot then > you convert the big VI image to the small BI. you need to take into > account this scale and draw VI to BI 1-2-1, something like this: > BufferedImage capture = new BufferedImage(12x2, 12x2, > BufferedImage.TYPE_4BYTE_ABGR_PRE); > capture.createGraphics().drawImage(vi,0,0,12x2,12x2,null); > > Note that even in this case the line locations check is incorrect and > should be adjusted. I tried what you've proposed. The position of the up-scaled image is wrong as well 1-21 instead of 2-22. I think test may be remained the same. > > >>>>> >>>>>>> >>>>>>>> >>>>>>>> --Semyon >>>>>>>> >>>>>>>> On 1/14/2016 9:23 PM, Phil Race wrote: >>>>>>>>> This fudge factor was last adjusted in >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6597822 >>>>>>>>> way back before the D3D pipeline was released and the comments >>>>>>>>> seem to >>>>>>>>> indicate that >>>>>>>>> there was a fair amount of testing on different hardware. >>>>>>>>> >>>>>>>>> I don't know why this seems to be in un-specified >>>>>>>>> hardware-dependent >>>>>>>>> territory but >>>>>>>>> it seems quite possible that this could just as easily >>>>>>>>> introduce a >>>>>>>>> different artifact >>>>>>>>> on some other hardware. >>>>>>>>> >>>>>>>>> What exactly are you testing on ? And I think it needs to >>>>>>>>> include at >>>>>>>>> least one Nvidia >>>>>>>>> and one AMD/ATI card. >>>>>>>>> >>>>>>>>> -phil. >>>>>>>>> >>>>>>>>> On 1/14/2016 10:09 AM, Semyon Sadetsky wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Please review the fix for jdk9. >>>>>>>>>> >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8146042 >>>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.00/ >>>>>>>>>> >>>>>>>>>> The root cause is incorrect coordinate rounding in D3D >>>>>>>>>> renderer. To >>>>>>>>>> fix the issue one of fudge factors was adjusted. >>>>>>>>>> >>>>>>>>>> Another issue mentioning in the JIRA ticket is taken out as a >>>>>>>>>> separate bug. >>>>>>>>>> >>>>>>>>>> --Semyon >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From prasanta.sadhukhan at oracle.com Mon Feb 1 11:42:37 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Mon, 1 Feb 2016 17:12:37 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8138749, , Revisited: PrinterJob.printDialog() does not support multi-mon, always displayed on primary In-Reply-To: <56AB323C.7090706@oracle.com> References: <569F6AC2.7060103@oracle.com> <569FFC46.8040700@oracle.com> <56A0A8BD.306@oracle.com> <56A169C3.2010903@oracle.com> <56A1D85B.3020804@oracle.com> <56AA2B15.90900@oracle.com> <56AB323C.7090706@oracle.com> Message-ID: <56AF44AD.5050406@oracle.com> Hi Phil, On 1/29/2016 3:04 PM, prasanta sadhukhan wrote: > Hi Phil, > > On 1/28/2016 8:22 PM, Philip Race wrote: >> "in consistent" >> >> On 1/21/16, 11:20 PM, prasanta sadhukhan wrote: >>> Hi Phil, >>> >>> I checked with NATIVE print dialog and with other app print dialog, >>> they are positioning the dialog a little ahead of top-left corner >>> (not at 1/3rd of the window as we are doing now) >>> so I did the same and positioned the dialog in consistent with our >>> NATIVE print dialog. >> >> You mean consistently. in consistent means the opposite >> Please adjust that in the code comment. >> >> 50,50 is probably OK so long as you verified this is approximately >> what happens on most platforms, not just windows 8 or similar. >> I don't think you will find complete consistency because apps may >> control it and use different dialogs even on the same platform. >> On hidpi screens this may be closer to the top-left than you intend >> but I expect it is fine. >> > Tested on windows, linux and it works ok. We showed the dialog at > x+50,y+50 where x,y is the coordinate of the active window. > Do not have local mac system to test multimonitor setup. Tested on mac too on multi-monitor setup. There is not complete consistency as you suspected as the dialog is closed to top compared to linux where it is more closer to left but all 3 platforms have the dialog near to top-left corner. Regards Prasanta >> The one main thing that you should verify is what happens in the case >> a native app top-level window is smaller than the print dialog and is >> positioned >> at the bottom right (of the right-most display). Does the native app >> ensure >> that the dialog is wholly on-screen ? I don't think your code will do >> that. >> And Safari on Mac at least seems to do that. I guess that most apps try >> their best to keep the dialog wholly on-screen. >> > Tested this case where window bounds is smaller than print dialog > but because of this check in ServiceUI.java > > // if portion of dialog is not within the gc boundary > if (!gcBounds.contains(dlgBounds)) { > // put in the center relative to parent frame/dialog > dialog.setLocationRelativeTo(owner); > } > > the dialog is shown in the primary window. > I saw we did not have this check for pageDialog(attr) where the dialog > is shown in secondary monitor despite gcBounds smaller than print dialog. > Therefore, I removed this check from ServiceUI. > > Please find the updated webrev: > http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.03/ > > Regards > Prasanta >> -phil. >> >> >>> Please find the updated webrev >>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.02/ >>> >>> Regards >>> Prasanta >>> On 1/22/2016 4:59 AM, Phil Race wrote: >>>> That is definitely better .. although I wonder if it would be even >>>> better >>>> if you found when there is an 'active' window that you tried to >>>> position the dialog such that it is near the upper-left corner of >>>> that window ? >>>> Please experiment and see how that looks compared to what other >>>> apps are doing. >>>> >>>> -phil. >>>> >>>> On 01/21/2016 01:45 AM, prasanta sadhukhan wrote: >>>>> Hi Phil, >>>>> >>>>> Please find the updated webrev >>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.01/ >>>>> which do away with the change in ServiceUI. >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 1/21/2016 2:59 AM, Phil Race wrote: >>>>>> The changes in ServiceUI seem like they can cause the spec. to be >>>>>> contradicted. >>>>>> It says >>>>>> >>>>>> * @param gc used to select screen. null means primary or >>>>>> default screen. >>>>>> >>>>>> but you update the code such that it will use the active window. >>>>>> If that is on a secondary screen but null was passed in. >>>>>> >>>>>> I am not entirely sure why ServiceUI needs to be changed at all. >>>>>> It is just the caller of ServiceUI .. >>>>>> >>>>>> -phil. >>>>>> >>>>>> >>>>>> On 01/20/2016 03:08 AM, prasanta sadhukhan wrote: >>>>>>> Hi All, >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8138749 >>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.00/ >>>>>>> >>>>>>> Please review a fix for a long standing issue whereby it is seen >>>>>>> that >>>>>>> PrinterJob.printDialog(attr set) does not support multi-monitor >>>>>>> setup. When this API is invoked, the print dialog is always >>>>>>> displayed on the default screen device regardless of where the >>>>>>> application is running. >>>>>>> This is because this method >>>>>>> uses ServiceDialog class for creating the dialog and that indeed >>>>>>> supports passing a GC in which we would like to have the dialog. >>>>>>> But printer job always uses the GraphicsConfig of the default >>>>>>> screen device >>>>>>> resulting in print dialog to be shown on primary device/monitor. >>>>>>> >>>>>>> I have not considered pageDialog() for this fix. Will create a >>>>>>> separate bugid and send a patch for that as well once this fix >>>>>>> is approved. >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>> >>>>>> >>>>> >>>> >>> > From alexandr.scherbatiy at oracle.com Mon Feb 1 12:17:40 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Mon, 1 Feb 2016 04:17:40 -0800 Subject: [OpenJDK 2D-Dev] Review request for JDK-8147413 : api/java_awt/Image/MultiResolutionImage/index.html\#MultiResolutionRenderingHints[test_VALUE_RESOLUTION_VARIANT_BASE] started to fail In-Reply-To: References: <569FF4C4.4030102@oracle.com> <56A140EB.90402@oracle.com> <56A213E7.8090903@oracle.com> Message-ID: <56AF4CE4.503@oracle.com> On 2/1/2016 1:04 AM, Jayathirth D V wrote: > Hi Alex, > > Since two separate bugs are created for the suggestions given by Jim. > And you are okay with the fix provided for the bug https://bugs.openjdk.java.net/browse/JDK-8147413 under webrev http://cr.openjdk.java.net/~jdv/8147413/webrev.00/ > > Can we push the fix into JDK9 after one more approval? Two approvals are usually enough for the fix pushing. Thanks, Alexandr. > > Thanks, > Jay > > -----Original Message----- > From: Alexander Scherbatiy > Sent: Friday, January 22, 2016 5:05 PM > To: Jim Graham; Phil Race; Jayathirth D V > Cc: 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review request for JDK-8147413 : api/java_awt/Image/MultiResolutionImage/index.html\#MultiResolutionRenderingHints[test_VALUE_RESOLUTION_VARIANT_BASE] started to fail > > > I have created two separated issues on it: > 8148045 Handle null resolution variant in SunGraphics2D > https://bugs.openjdk.java.net/browse/JDK-8148045 > > 8148046 Investigate the case where MRI.getResolutionVariant() returns MultiResolutionImage > https://bugs.openjdk.java.net/browse/JDK-8148046 > > Thanks, > Alexandr. > > On 22/01/16 00:34, Jim Graham wrote: >> BASE essentially just means to draw the 1:1 image. The problem is >> that returning null is not the way to achieve that. Returning null >> means "MRI doesn't apply here, just use the original image", but in >> the case of BASE we have to make sure it isn't an MRI first otherwise >> the caller will get an exception. >> >> The change does achieve that since BASE handling is built in to the >> helper getResolutionVariant() method in SG2D and so it should ask for >> the 1:1 image, but if the getRV() helper method returns null then we >> still return null from the drawHiDPIImage() method and that causes the >> caller to use the original MRI in a normal-image pipeline. There >> should perhaps be an else clause for the "if (rV != img && rV != null) >> { } else { ???; }". What that "???" is depends on why the helper >> method returned the original image and/or a null, but it should not be >> "return null;". (Also, there is no check if it returned another >> different MRI. That should probably not be allowed, but we never state >> that in the interface description...) >> >> The remaining question is why the helper method would return either >> the original image or null. >> >> I don't think the helper method ever returns the original MRI >> knowingly, but the MRI itself might do that. That would then fall >> under the "what to do if the MRI returns any sort of non-standard >> image" case, and perhaps the exception is appropriate there? We >> should probably detect that, though, and throw a more obvious >> exception (or recurse?). Recursion can get ugly, so perhaps a very >> explicit error with a reasonable description would be better than >> letting the DrawImage pipeline fail in various ways. >> >> The helper function can return null if the operation is a NOP (sxy1 == >> sxy2 - i.e. an empty subimage rectangle), but that case should be >> handled here and end up with returning ?true? which matches what many >> of the drawImage() variants return when they detect a trivial NOP case. >> >> The helper function can also return null if the srcWidth/Height are >> negative which would imply an uninitialized image. I'm not sure what >> to do there because normally an uninitialized image is tracked by the >> DrawImage pipe and the observer is notified as the image data is >> loaded, but we have no mechanism to do that with an MRI. This case >> may require more work, or something explicit in the MRI spec (what >> happens when someone lazily loads an image with an @x2 variant now?). >> >> It also returns null if the return value from the MRI is a >> ToolkitImage with an error - but I think that is wrong, it should just >> return the ToolkitImage and let the caller send it to the DrawImage >> pipeline to detect the error and respond in the appropriate manner. >> Or perhaps it should cause the drawHiDPIImage() method to return >> whatever boolean is appropriate for an error to save time, but there >> is no way to orchestrate that from the helper method since it can only >> return a (non-MRI) image. It's probably best to just return the >> errored TKImage in that case...? >> >> The last way it can return null is if the MRI returned null from its >> getRV() method, but the interface doesn't discuss what that means. I >> suppose it might mean that all of the resolution variants are being >> loaded asynchronously and none of them are available yet, but we are >> then missing a mechanism to inform the observer of when the variants >> are loaded. (Is there a bugid for that? I seem to recall having a >> discussion about that missing mechanism in the past...?) >> >> So, I think the change made here is along the right track, but we have >> a couple more holes to plug before we can consider this fixed... >> >> ...jim >> >> On 1/20/2016 12:57 PM, Phil Race wrote: >>> It seems like the expectation was that BASE could be drawn by the old >>> imaging path. >>> which would be lower overhead. >>> I think we should ask Alexandr what the intention was here and >>> whether the code that handles the base image needs to be taught how >>> to extract data from a MultiResolutionImage. >>> >>> -phil. >>> >>> On 01/20/2016 08:20 AM, Jayathirth D V wrote: >>>> Hi, >>>> >>>> __ >>>> >>>> _Please review the following fix in JDK9:_ >>>> >>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8147413 >>>> >>>> Webrev : http://cr.openjdk.java.net/~jdv/8147413/webrev.00/ >>>> >>>> >>>> Issue : JCK testcase >>>> api/java_awt/Image/MultiResolutionImage/index.html\#MultiResolutionR >>>> enderingHints[test_VALUE_RESOLUTION_VARIANT_BASE] >>>> >>>> is failing from b96 JDK9 build. >>>> >>>> Root cause : In getManager API of SurfaceManager.java we are trying >>>> to typecast BaseMultiResolutionImage to BufferedImage and it is >>>> causing ClassCastException and in turn IllegalArgumentException seen >>>> in result of test case. It is happening because of change made in >>>> JDK-8073320 in >>>> SunGraphics2D.java. In case of VALUE_RESOLUTION_VARIANT_BASE type we >>>> are not trying to convert MultiResolutionImage to BufferedImage. >>>> >>>> Solution : Modify the condition present in drawHiDPIImage API to >>>> convert all MultiResolutionImage to BufferedImage irrespective of >>>> KEY_RESOLUTION_VARIANT type. >>>> >>>> Thanks, >>>> >>>> Jay >>>> From alexandr.scherbatiy at oracle.com Mon Feb 1 12:27:56 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Mon, 1 Feb 2016 04:27:56 -0800 Subject: [OpenJDK 2D-Dev] [9] Review request for 8076545 Text size is twice bigger under Windows L&F on Win 8.1 with HiDPI display In-Reply-To: <56ABD6B2.10302@oracle.com> References: <5596C117.1040806@oracle.com> <559DB2FB.5000208@oracle.com> <55A902D4.1050603@oracle.com> <563208A9.50702@oracle.com> <56328355.1010608@oracle.com> <5633C7C8.2030804@oracle.com> <5649E312.2010606@oracle.com> <564A41D3.5010202@oracle.com> <564A4DE9.1040102@oracle.com> <56ABB269.6030808@oracle.com> <56ABD6B2.10302@oracle.com> Message-ID: <56AF4F4C.4030504@oracle.com> Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8076545/webrev.04/ - both LOGPIXELSX and Y are used for the theme size scaling. - LOGPIXELSY is used for text metrics height rescaling Thanks, Alexandr. On 1/29/2016 1:16 PM, Jim Graham wrote: > Hi Alexandr, > > Thanks for investigating the behaviors. > > With respect to using LOGPIXELSX or Y, these methods are used to scale > both horizontal and vertical measurements so we really should have 2 > scale values and rescale methods, one for horizontal use and one for > vertical... > > ...jim > > On 1/29/2016 10:41 AM, Alexandr Scherbatiy wrote: >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8076545/webrev.03 >> >> - LOGPIXELSX is changed to LOGPIXELSY >> >> On 11/16/2015 1:43 PM, Jim Graham wrote: >>> Note that LOGPIXELSY is global and static between reboots so it >>> doesn't really matter which monitor is used to get the value. >>> >>> Also, the issue is that the measurements are in pixels, so if we >>> convert them into a resolution independent measurement then the rest >>> of the scaling in the AWT/2D will be correct regardless of any given >>> monitor's resolution. We just have to make sure the "de-pixelization" >>> of the measurement is an apples-to-apples calculation. >>> >>> The question in my mind is whether the values they get from >>> GetTheme*() and SPI_GETNONCLIENTMETRICS are relative to LOGPIXELSY, or >>> the more recent Per-Monitor aware DPI APIs, or ...? It would be >>> interesting to see what happens to those values when you change the >>> DPI settings on Windows 8.1 and not reboot. If they stay constant >>> until you reboot then LOGPIXELSY on the main screen would be the value >>> to use to de-scale them... >> >> I tried to use the "Change the size of all items" slider on Windows >> 8.1 without rebooting. >> GetDpiForMonitor() returns the updated DPI values: 192, 144, 96 >> LOGPIXELSY returns unchanged values: 192, 192, 192 >> SystemParametersInfo(SPI_GETNONCLIENTMETRICS,...) returns unchanged >> NONCLIENTMETRICS >> GetThemePartSize() returns unchanged theme part sizes >> >> It seems that theme part sizes behave in the same way as the >> LOGPIXELSY in this case. >> >> Thanks, >> Alexandr. >> >>> >>> ...jim >>> >>> On 11/16/2015 12:51 PM, Phil Race wrote: >>>> That seems better. But one more question to get a point clarified. >>>> You are using getDesktopWindow() which is for the primary monitor. >>>> I assume that the 'inversion' results in the value being used to be >>>> independent >>>> of the monitor in a multi-mon situation and so when we move to a 2nd >>>> monitor >>>> that inverted size remains valid ? >>>> >>>> If so looks good to me. >>>> >>>> -phil. >>>> >>>> On 11/16/2015 06:07 AM, Alexander Scherbatiy wrote: >>>>> >>>>> Hello, >>>>> >>>>> Could you review the updated fix: >>>>> http://cr.openjdk.java.net/~alexsch/8076545/webrev.02 >>>>> >>>>> - round is used instead of ceil >>>>> - inverted scales are used >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> >>>>> On 10/30/2015 10:40 PM, Jim Graham wrote: >>>>>> In this case round may be better. ceil() is more for cases where you >>>>>> needed "at least X amount of room", but I don't think a font size is >>>>>> an "at least this much" kind of case. >>>>>> >>>>>> Also, I've been toying with the idea that use of ceil() and floor() >>>>>> in any DPI-adjustment equations should really be "ceil(val - >>>>>> epsilon)" or "floor(ceil + epsilon)" for some small value of epsilon >>>>>> chosen just large enough to prevent various round-off errors from >>>>>> affecting the outcome. One idea is for 1/256 as the value of >>>>>> epsilon >>>>>> since that could equate to the smallest measurable difference in >>>>>> terms of alpha or interpolation results (or 1/512 for "half the >>>>>> smallest quantum")... >>>>>> >>>>>> ...jim >>>>>> >>>>>> On 10/29/15 1:36 PM, Phil Race wrote: >>>>>>> size->cx = (int)ceil(size->cx / scale); >>>>>>> >>>>>>> >>>>>>> So if size->cx / scale works out to be 12.0001 you will round it up >>>>>>> to 13? >>>>>>> >>>>>>> Can you check what pixel size windows gives you in such a case ? >>>>>>> I'd be a little surprised if they did that rather than round. >>>>>>> >>>>>>> Is the SetFontProperty that does not accept a scale parameter still >>>>>>> used >>>>>>> somewhere ? >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 10/29/2015 04:53 AM, Sergey Bylokhov wrote: >>>>>>>> On 17.07.15 16:27, Alexander Scherbatiy wrote: >>>>>>>>>> >>>>>>>>>> - Sergey's point about multi-mon should be checked out. >>>>>>>>> Windows 8.1 has option "Let me choose one scaling level for >>>>>>>>> all my >>>>>>>>> displays". >>>>>>>>> If I unset it I am able to change the size of all items. >>>>>>>>> However, >>>>>>>>> the DPI which returns GetDPIForMonitor is still 2 on HiDPI >>>>>>>>> displays. >>>>>>>> >>>>>>>> This version looks fine, but I am sure it can be double checked on >>>>>>>> windows 10 at some moment as well. >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >> From brian.burkhalter at oracle.com Mon Feb 1 23:06:13 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 1 Feb 2016 15:06:13 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8148628: TIFFDirectory(getAsMetaData) created with one TIFFField having a IFD pointer tag throws ClassCastException & other naming differences (JEP 262) Message-ID: Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8148628 Patch: http://cr.openjdk.java.net/~bpb/8148628/webrev.00/ Summary: 1) Needed to fix some problems in TIFFDirectory and TIFFFieldNode with respect to the fact that a TIFFDirectory contained in a TIFFField may be either the ?dir? field or the ?data? field. 2) Trivial changes to names in Exif and GeoTIFF tags to better align with the respective specifications. Thanks, Brian From james.graham at oracle.com Tue Feb 2 01:38:30 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 1 Feb 2016 17:38:30 -0800 Subject: [OpenJDK 2D-Dev] Review request for 8069348 SunGraphics2D.copyArea() does not properly work for scaled graphics in D3D In-Reply-To: <56AA4EE3.5020507@oracle.com> References: <564F08B6.7010009@oracle.com> <564F3E8C.3040400@oracle.com> <564F4360.3070609@oracle.com> <5654610C.2090302@oracle.com> <5654D6F0.3090702@oracle.com> <56582B0E.20405@oracle.com> <5658DC90.2010801@oracle.com> <566B2D68.10201@oracle.com> <566F6588.3080909@oracle.com> <5670686A.8040904@oracle.com> <56AA4EE3.5020507@oracle.com> Message-ID: <56B00896.2090107@oracle.com> Hi Alexandr, This looks great. It's good to go, but you might want to fix one indenting issue before you push: X11SD and XRSD both had the same edit, but you made a different decision on whether to get rid of some extra parentheses or not and XRSD was left with the indentation off by 1. It would probably make sense to get rid of the extra parens in X11SD and then make sure the resulting indentation is correct in both. But, that won't affect the correctness of the fix. I don't feel the need to do a review for these indentation changes if you make them... ...jim On 1/28/16 9:24 AM, Alexandr Scherbatiy wrote: > > Hello, > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8069348/webrev.04/ > > - TRANSFORM_TRANSLATESCALE check is restored in the > OSXOffScreenSurfaceData > - TRANSFORM_TRANSLATESCALE check is removed from X11SurfaceData and > GDIWindowSurfaceData > > Thanks, > Alexandr. > > On 12/15/2015 11:22 AM, Jim Graham wrote: >> Also, X11SD and GDISD still reject TRANSLATESCALE. >> >> I think it may make sense for OSXOffscreen to return false for >> TRANSLATESCALE and punt back to the general implementation? But, X11 >> and GDI should be able to allow that condition... >> >> ...jim >> >> On 12/14/15 4:57 PM, Jim Graham wrote: >>> Will OSXOffScreenSurfaceData.copyArea work with a scaled context? It >>> calls the drawImage on the original sg2d, but it is using transformed >>> coordinates already. On the other hand, I installed the patch and built >>> on my retina MBP and didn't see any errors in SwingSet2 - is that >>> because I was using a different SurfaceData by default (CGL?)? >>> >>> The rest looks fine... >>> >>> ...jim >>> >>> On 12/11/15 12:09 PM, Alexander Scherbatiy wrote: >>>> >>>> Hello, >>>> >>>> Could you review the updated fix: >>>> http://cr.openjdk.java.net/~alexsch/8069348/webrev.03 >>>> >>>> On 28/11/15 02:43, Jim Graham wrote: >>>>> Hi Alexandr, >>>>> >>>>> On 11/27/15 2:06 AM, Alexander Scherbatiy wrote: >>>>>>> OSXOffscreenSD.java (and all *SD.java), line 481 - should we just >>>>>>> make >>>>>>> this part of the SD.copyArea contract, that the coordinates are in >>>>>>> device space and the SD method should not concern itself with the >>>>>>> SG2D >>>>>>> transform? >>>>>> I updated the SurfaceData.copyArea() x,y,width, and height >>>>>> description. >>>>> >>>>> And yet most of the implementations still check the transformState. >>>>> Why do they do that if they are no longer concerned with transforming >>>>> the inputs? >>>> Updated. >>>> >>>> XRSurfaceData didn't handled translate scale transform state. I >>>> removed it and checked that on Linux scaled internal frames are >>>> properly >>>> moved and scroll works correctly. >>>> GDIWindowSurfaceData handles only translate state. For scale state >>>> support it is necessary also to scale destination coordinates. It is >>>> also requires some additional testing. I left it unchanged. >>>>> >>>>>>> CopyAreaTest.java, line 61 - rounding is not the same operation that >>>>>>> SG2D uses, but it works anyway? >>>>> >>>>> The rounding still isn't the same as SG2D. Floor() != ceil(v - 0.5). >>>>> >>>>> On second thought, it's probably best not to worry about the exact >>>>> rounding in the test case, but just test 1 pixel inset from the >>>>> coordinates that are needed. In other words, check: >>>>> >>>>> scale(X + (N+1) * DX) + 1 >>>>> scale(Y + (N+1) * DY) + 1, >>>>> scale(W) - 2 >>>>> scale(H) - 2 >>>>> >>>>> and go back to just rounding... >>>> Updated. >>>>> >>>>>>> CopyAreaTest.java, lines 143,144 - why subtract 2DX and 2DY here? >>>>>>> Ah, >>>>>>> this may mask the error in line 94 above...? >>>>> >>>>> I notice that it used to check the rectangle at X+(N+1)*DX, >>>>> Y+(N+1)*DY, but now it only checks X+N*DX,Y+N*DY. Why not continue to >>>>> check the N+1 copy? That should be the location of the destination of >>>>> the last copy, right? >>>> I believe my initial assumption was incorrect. >>>> For example, let's take N = 1. The loops below has only one >>>> iteration: >>>> ----------- >>>> for (int i = 0; i < N; i++) { >>>> g.copyArea(X + i * DX, Y + i * DY, W, H, DX, DY); >>>> } >>>> ----------- >>>> >>>> Which is just g.copyArea(X, Y, W, H, DX, DY). So the destination >>>> rectangle is (X+DX, Y+DY, W, H) >>>> which corresponds to the N = 1. >>>> >>>> I also updated the test to check different scaleX and scaleY. >>>> >>>> Thanks, >>>> Alexandr. >>>>> >>>>> ...jim >>>> > From james.graham at oracle.com Tue Feb 2 01:46:02 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 1 Feb 2016 17:46:02 -0800 Subject: [OpenJDK 2D-Dev] Review request for JDK-8147413 : api/java_awt/Image/MultiResolutionImage/index.html\#MultiResolutionRenderingHints[test_VALUE_RESOLUTION_VARIANT_BASE] started to fail In-Reply-To: References: <569FF4C4.4030102@oracle.com> <56A140EB.90402@oracle.com> <56A213E7.8090903@oracle.com> Message-ID: <56B00A5A.2030506@oracle.com> I'm OK with the additional issues being addressed in follow-on fixes if that is what you are asking. The original fix in webrev.00 adds no additional harm and fixes a common case that is already breaking some code... ...jim On 2/1/16 1:04 AM, Jayathirth D V wrote: > Hi Alex, > > Since two separate bugs are created for the suggestions given by Jim. > And you are okay with the fix provided for the bug https://bugs.openjdk.java.net/browse/JDK-8147413 under webrev http://cr.openjdk.java.net/~jdv/8147413/webrev.00/ > > Can we push the fix into JDK9 after one more approval? > > Thanks, > Jay > > -----Original Message----- > From: Alexander Scherbatiy > Sent: Friday, January 22, 2016 5:05 PM > To: Jim Graham; Phil Race; Jayathirth D V > Cc: 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review request for JDK-8147413 : api/java_awt/Image/MultiResolutionImage/index.html\#MultiResolutionRenderingHints[test_VALUE_RESOLUTION_VARIANT_BASE] started to fail > > > I have created two separated issues on it: > 8148045 Handle null resolution variant in SunGraphics2D > https://bugs.openjdk.java.net/browse/JDK-8148045 > > 8148046 Investigate the case where MRI.getResolutionVariant() returns MultiResolutionImage > https://bugs.openjdk.java.net/browse/JDK-8148046 > > Thanks, > Alexandr. > > On 22/01/16 00:34, Jim Graham wrote: >> BASE essentially just means to draw the 1:1 image. The problem is >> that returning null is not the way to achieve that. Returning null >> means "MRI doesn't apply here, just use the original image", but in >> the case of BASE we have to make sure it isn't an MRI first otherwise >> the caller will get an exception. >> >> The change does achieve that since BASE handling is built in to the >> helper getResolutionVariant() method in SG2D and so it should ask for >> the 1:1 image, but if the getRV() helper method returns null then we >> still return null from the drawHiDPIImage() method and that causes the >> caller to use the original MRI in a normal-image pipeline. There >> should perhaps be an else clause for the "if (rV != img && rV != null) >> { } else { ???; }". What that "???" is depends on why the helper >> method returned the original image and/or a null, but it should not be >> "return null;". (Also, there is no check if it returned another >> different MRI. That should probably not be allowed, but we never state >> that in the interface description...) >> >> The remaining question is why the helper method would return either >> the original image or null. >> >> I don't think the helper method ever returns the original MRI >> knowingly, but the MRI itself might do that. That would then fall >> under the "what to do if the MRI returns any sort of non-standard >> image" case, and perhaps the exception is appropriate there? We >> should probably detect that, though, and throw a more obvious >> exception (or recurse?). Recursion can get ugly, so perhaps a very >> explicit error with a reasonable description would be better than >> letting the DrawImage pipeline fail in various ways. >> >> The helper function can return null if the operation is a NOP (sxy1 == >> sxy2 - i.e. an empty subimage rectangle), but that case should be >> handled here and end up with returning ?true? which matches what many >> of the drawImage() variants return when they detect a trivial NOP case. >> >> The helper function can also return null if the srcWidth/Height are >> negative which would imply an uninitialized image. I'm not sure what >> to do there because normally an uninitialized image is tracked by the >> DrawImage pipe and the observer is notified as the image data is >> loaded, but we have no mechanism to do that with an MRI. This case >> may require more work, or something explicit in the MRI spec (what >> happens when someone lazily loads an image with an @x2 variant now?). >> >> It also returns null if the return value from the MRI is a >> ToolkitImage with an error - but I think that is wrong, it should just >> return the ToolkitImage and let the caller send it to the DrawImage >> pipeline to detect the error and respond in the appropriate manner. >> Or perhaps it should cause the drawHiDPIImage() method to return >> whatever boolean is appropriate for an error to save time, but there >> is no way to orchestrate that from the helper method since it can only >> return a (non-MRI) image. It's probably best to just return the >> errored TKImage in that case...? >> >> The last way it can return null is if the MRI returned null from its >> getRV() method, but the interface doesn't discuss what that means. I >> suppose it might mean that all of the resolution variants are being >> loaded asynchronously and none of them are available yet, but we are >> then missing a mechanism to inform the observer of when the variants >> are loaded. (Is there a bugid for that? I seem to recall having a >> discussion about that missing mechanism in the past...?) >> >> So, I think the change made here is along the right track, but we have >> a couple more holes to plug before we can consider this fixed... >> >> ...jim >> >> On 1/20/2016 12:57 PM, Phil Race wrote: >>> It seems like the expectation was that BASE could be drawn by the old >>> imaging path. >>> which would be lower overhead. >>> I think we should ask Alexandr what the intention was here and >>> whether the code that handles the base image needs to be taught how >>> to extract data from a MultiResolutionImage. >>> >>> -phil. >>> >>> On 01/20/2016 08:20 AM, Jayathirth D V wrote: >>>> >>>> Hi, >>>> >>>> __ >>>> >>>> _Please review the following fix in JDK9:_ >>>> >>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8147413 >>>> >>>> Webrev : http://cr.openjdk.java.net/~jdv/8147413/webrev.00/ >>>> >>>> >>>> Issue : JCK testcase >>>> api/java_awt/Image/MultiResolutionImage/index.html\#MultiResolutionR >>>> enderingHints[test_VALUE_RESOLUTION_VARIANT_BASE] >>>> >>>> is failing from b96 JDK9 build. >>>> >>>> Root cause : In getManager API of SurfaceManager.java we are trying >>>> to typecast BaseMultiResolutionImage to BufferedImage and it is >>>> causing ClassCastException and in turn IllegalArgumentException seen >>>> in result of test case. It is happening because of change made in >>>> JDK-8073320 in >>>> SunGraphics2D.java. In case of VALUE_RESOLUTION_VARIANT_BASE type we >>>> are not trying to convert MultiResolutionImage to BufferedImage. >>>> >>>> Solution : Modify the condition present in drawHiDPIImage API to >>>> convert all MultiResolutionImage to BufferedImage irrespective of >>>> KEY_RESOLUTION_VARIANT type. >>>> >>>> Thanks, >>>> >>>> Jay >>>> >>> > From james.graham at oracle.com Tue Feb 2 01:51:07 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 1 Feb 2016 17:51:07 -0800 Subject: [OpenJDK 2D-Dev] [9] Review request for 8076545 Text size is twice bigger under Windows L&F on Win 8.1 with HiDPI display In-Reply-To: <56AF4F4C.4030504@oracle.com> References: <5596C117.1040806@oracle.com> <559DB2FB.5000208@oracle.com> <55A902D4.1050603@oracle.com> <563208A9.50702@oracle.com> <56328355.1010608@oracle.com> <5633C7C8.2030804@oracle.com> <5649E312.2010606@oracle.com> <564A41D3.5010202@oracle.com> <564A4DE9.1040102@oracle.com> <56ABB269.6030808@oracle.com> <56ABD6B2.10302@oracle.com> <56AF4F4C.4030504@oracle.com> Message-ID: <56B00B8B.9040102@oracle.com> Hi Alexandr, In awt_DesktopProperties.cpp you are using the Y scaling factor to scale widths still - see lines 287 (and others in that same function) and then 322 in another function. It looks like you'll need getInvScaleX() and getInvScaleY(). I'll leave it to Phil to comment on the unit test... ...jim On 2/1/16 4:27 AM, Alexandr Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8076545/webrev.04/ > > - both LOGPIXELSX and Y are used for the theme size scaling. > - LOGPIXELSY is used for text metrics height rescaling > > Thanks, > Alexandr. > > On 1/29/2016 1:16 PM, Jim Graham wrote: >> Hi Alexandr, >> >> Thanks for investigating the behaviors. >> >> With respect to using LOGPIXELSX or Y, these methods are used to scale >> both horizontal and vertical measurements so we really should have 2 >> scale values and rescale methods, one for horizontal use and one for >> vertical... >> >> ...jim >> >> On 1/29/2016 10:41 AM, Alexandr Scherbatiy wrote: >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8076545/webrev.03 >>> >>> - LOGPIXELSX is changed to LOGPIXELSY >>> >>> On 11/16/2015 1:43 PM, Jim Graham wrote: >>>> Note that LOGPIXELSY is global and static between reboots so it >>>> doesn't really matter which monitor is used to get the value. >>>> >>>> Also, the issue is that the measurements are in pixels, so if we >>>> convert them into a resolution independent measurement then the rest >>>> of the scaling in the AWT/2D will be correct regardless of any given >>>> monitor's resolution. We just have to make sure the "de-pixelization" >>>> of the measurement is an apples-to-apples calculation. >>>> >>>> The question in my mind is whether the values they get from >>>> GetTheme*() and SPI_GETNONCLIENTMETRICS are relative to LOGPIXELSY, or >>>> the more recent Per-Monitor aware DPI APIs, or ...? It would be >>>> interesting to see what happens to those values when you change the >>>> DPI settings on Windows 8.1 and not reboot. If they stay constant >>>> until you reboot then LOGPIXELSY on the main screen would be the value >>>> to use to de-scale them... >>> >>> I tried to use the "Change the size of all items" slider on Windows >>> 8.1 without rebooting. >>> GetDpiForMonitor() returns the updated DPI values: 192, 144, 96 >>> LOGPIXELSY returns unchanged values: 192, 192, 192 >>> SystemParametersInfo(SPI_GETNONCLIENTMETRICS,...) returns unchanged >>> NONCLIENTMETRICS >>> GetThemePartSize() returns unchanged theme part sizes >>> >>> It seems that theme part sizes behave in the same way as the >>> LOGPIXELSY in this case. >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> ...jim >>>> >>>> On 11/16/2015 12:51 PM, Phil Race wrote: >>>>> That seems better. But one more question to get a point clarified. >>>>> You are using getDesktopWindow() which is for the primary monitor. >>>>> I assume that the 'inversion' results in the value being used to be >>>>> independent >>>>> of the monitor in a multi-mon situation and so when we move to a 2nd >>>>> monitor >>>>> that inverted size remains valid ? >>>>> >>>>> If so looks good to me. >>>>> >>>>> -phil. >>>>> >>>>> On 11/16/2015 06:07 AM, Alexander Scherbatiy wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Could you review the updated fix: >>>>>> http://cr.openjdk.java.net/~alexsch/8076545/webrev.02 >>>>>> >>>>>> - round is used instead of ceil >>>>>> - inverted scales are used >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> >>>>>> On 10/30/2015 10:40 PM, Jim Graham wrote: >>>>>>> In this case round may be better. ceil() is more for cases where you >>>>>>> needed "at least X amount of room", but I don't think a font size is >>>>>>> an "at least this much" kind of case. >>>>>>> >>>>>>> Also, I've been toying with the idea that use of ceil() and floor() >>>>>>> in any DPI-adjustment equations should really be "ceil(val - >>>>>>> epsilon)" or "floor(ceil + epsilon)" for some small value of epsilon >>>>>>> chosen just large enough to prevent various round-off errors from >>>>>>> affecting the outcome. One idea is for 1/256 as the value of >>>>>>> epsilon >>>>>>> since that could equate to the smallest measurable difference in >>>>>>> terms of alpha or interpolation results (or 1/512 for "half the >>>>>>> smallest quantum")... >>>>>>> >>>>>>> ...jim >>>>>>> >>>>>>> On 10/29/15 1:36 PM, Phil Race wrote: >>>>>>>> size->cx = (int)ceil(size->cx / scale); >>>>>>>> >>>>>>>> >>>>>>>> So if size->cx / scale works out to be 12.0001 you will round it up >>>>>>>> to 13? >>>>>>>> >>>>>>>> Can you check what pixel size windows gives you in such a case ? >>>>>>>> I'd be a little surprised if they did that rather than round. >>>>>>>> >>>>>>>> Is the SetFontProperty that does not accept a scale parameter still >>>>>>>> used >>>>>>>> somewhere ? >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> On 10/29/2015 04:53 AM, Sergey Bylokhov wrote: >>>>>>>>> On 17.07.15 16:27, Alexander Scherbatiy wrote: >>>>>>>>>>> >>>>>>>>>>> - Sergey's point about multi-mon should be checked out. >>>>>>>>>> Windows 8.1 has option "Let me choose one scaling level for >>>>>>>>>> all my >>>>>>>>>> displays". >>>>>>>>>> If I unset it I am able to change the size of all items. >>>>>>>>>> However, >>>>>>>>>> the DPI which returns GetDPIForMonitor is still 2 on HiDPI >>>>>>>>>> displays. >>>>>>>>> >>>>>>>>> This version looks fine, but I am sure it can be double checked on >>>>>>>>> windows 10 at some moment as well. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>> > From philip.race at oracle.com Wed Feb 3 00:35:03 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 02 Feb 2016 16:35:03 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8138749, , Revisited: PrinterJob.printDialog() does not support multi-mon, always displayed on primary In-Reply-To: <56AB323C.7090706@oracle.com> References: <569F6AC2.7060103@oracle.com> <569FFC46.8040700@oracle.com> <56A0A8BD.306@oracle.com> <56A169C3.2010903@oracle.com> <56A1D85B.3020804@oracle.com> <56AA2B15.90900@oracle.com> <56AB323C.7090706@oracle.com> Message-ID: <56B14B37.6010706@oracle.com> The RasterPrinterJob changes are now OK however - I am not sure I understand how removing the check in ServiceUI will address the issue about the dialog needing to be entirely on-screen. It reads to me as if now you allow that in preference to having it centred. But I am not sure the old code would have worked in all cases either since centering on a very small owner window in the corner of the screen would result in the same problem. Probably what is needed is some code that moves it just enough to fit. ie downwards if it is off the top, left if it is off the right and so forth ? - The two tests do not share the same bug ID. I expected they should now do so .. and I was further supposing you would merge the two tests into one. -phil. On 01/29/2016 01:34 AM, prasanta sadhukhan wrote: > Hi Phil, > > On 1/28/2016 8:22 PM, Philip Race wrote: >> "in consistent" >> >> On 1/21/16, 11:20 PM, prasanta sadhukhan wrote: >>> Hi Phil, >>> >>> I checked with NATIVE print dialog and with other app print dialog, >>> they are positioning the dialog a little ahead of top-left corner >>> (not at 1/3rd of the window as we are doing now) >>> so I did the same and positioned the dialog in consistent with our >>> NATIVE print dialog. >> >> You mean consistently. in consistent means the opposite >> Please adjust that in the code comment. >> >> 50,50 is probably OK so long as you verified this is approximately >> what happens on most platforms, not just windows 8 or similar. >> I don't think you will find complete consistency because apps may >> control it and use different dialogs even on the same platform. >> On hidpi screens this may be closer to the top-left than you intend >> but I expect it is fine. >> > Tested on windows, linux and it works ok. We showed the dialog at > x+50,y+50 where x,y is the coordinate of the active window. > Do not have local mac system to test multimonitor setup. >> The one main thing that you should verify is what happens in the case >> a native app top-level window is smaller than the print dialog and is >> positioned >> at the bottom right (of the right-most display). Does the native app >> ensure >> that the dialog is wholly on-screen ? I don't think your code will do >> that. >> And Safari on Mac at least seems to do that. I guess that most apps try >> their best to keep the dialog wholly on-screen. >> > Tested this case where window bounds is smaller than print dialog > but because of this check in ServiceUI.java > > // if portion of dialog is not within the gc boundary > if (!gcBounds.contains(dlgBounds)) { > // put in the center relative to parent frame/dialog > dialog.setLocationRelativeTo(owner); > } > > the dialog is shown in the primary window. > I saw we did not have this check for pageDialog(attr) where the dialog > is shown in secondary monitor despite gcBounds smaller than print dialog. > Therefore, I removed this check from ServiceUI. > > Please find the updated webrev: > http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.03/ > > Regards > Prasanta >> -phil. >> >> >>> Please find the updated webrev >>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.02/ >>> >>> Regards >>> Prasanta >>> On 1/22/2016 4:59 AM, Phil Race wrote: >>>> That is definitely better .. although I wonder if it would be even >>>> better >>>> if you found when there is an 'active' window that you tried to >>>> position the dialog such that it is near the upper-left corner of >>>> that window ? >>>> Please experiment and see how that looks compared to what other >>>> apps are doing. >>>> >>>> -phil. >>>> >>>> On 01/21/2016 01:45 AM, prasanta sadhukhan wrote: >>>>> Hi Phil, >>>>> >>>>> Please find the updated webrev >>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.01/ >>>>> which do away with the change in ServiceUI. >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 1/21/2016 2:59 AM, Phil Race wrote: >>>>>> The changes in ServiceUI seem like they can cause the spec. to be >>>>>> contradicted. >>>>>> It says >>>>>> >>>>>> * @param gc used to select screen. null means primary or >>>>>> default screen. >>>>>> >>>>>> but you update the code such that it will use the active window. >>>>>> If that is on a secondary screen but null was passed in. >>>>>> >>>>>> I am not entirely sure why ServiceUI needs to be changed at all. >>>>>> It is just the caller of ServiceUI .. >>>>>> >>>>>> -phil. >>>>>> >>>>>> >>>>>> On 01/20/2016 03:08 AM, prasanta sadhukhan wrote: >>>>>>> Hi All, >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8138749 >>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.00/ >>>>>>> >>>>>>> Please review a fix for a long standing issue whereby it is seen >>>>>>> that >>>>>>> PrinterJob.printDialog(attr set) does not support multi-monitor >>>>>>> setup. When this API is invoked, the print dialog is always >>>>>>> displayed on the default screen device regardless of where the >>>>>>> application is running. >>>>>>> This is because this method >>>>>>> uses ServiceDialog class for creating the dialog and that indeed >>>>>>> supports passing a GC in which we would like to have the dialog. >>>>>>> But printer job always uses the GraphicsConfig of the default >>>>>>> screen device >>>>>>> resulting in print dialog to be shown on primary device/monitor. >>>>>>> >>>>>>> I have not considered pageDialog() for this fix. Will create a >>>>>>> separate bugid and send a patch for that as well once this fix >>>>>>> is approved. >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>> >>>>>> >>>>> >>>> >>> > From prasanta.sadhukhan at oracle.com Wed Feb 3 05:34:56 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Wed, 3 Feb 2016 11:04:56 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8138749, , Revisited: PrinterJob.printDialog() does not support multi-mon, always displayed on primary In-Reply-To: <56B14B37.6010706@oracle.com> References: <569F6AC2.7060103@oracle.com> <569FFC46.8040700@oracle.com> <56A0A8BD.306@oracle.com> <56A169C3.2010903@oracle.com> <56A1D85B.3020804@oracle.com> <56AA2B15.90900@oracle.com> <56AB323C.7090706@oracle.com> <56B14B37.6010706@oracle.com> Message-ID: <56B19180.70207@oracle.com> Hi Phil, On 2/3/2016 6:05 AM, Phil Race wrote: > The RasterPrinterJob changes are now OK however > > - I am not sure I understand how removing the check in ServiceUI > will address the issue about the dialog needing to be entirely on-screen. > It reads to me as if now you allow that in preference to having it > centred. > But I am not sure the old code would have worked in all cases either > since centering on a very small owner window in the corner of the screen > would result in the same problem. Since this issue was about showing the dialog on primary vs secondary, can we address this issue of showing the dialog entirely on-screen in separate bug id (since this issue is present in primary screen too if dialog is bigger than top-level window)? The present change in ServiceUI address the issue of showing the dialog on secondary monitor if dialog is bigger than top-level. > Probably what is needed is some code that moves it just enough to fit. > ie downwards if it is off the top, left if it is off the right and so > forth ? > > - The two tests do not share the same bug ID. I expected they > should now do so .. and I was further supposing you would merge > the two tests into one. I will change the bug id of 2nd test. Is it ok if I keep these 2 tests separate to make it easier? Regards Prasanta > > -phil. > > On 01/29/2016 01:34 AM, prasanta sadhukhan wrote: >> Hi Phil, >> >> On 1/28/2016 8:22 PM, Philip Race wrote: >>> "in consistent" >>> >>> On 1/21/16, 11:20 PM, prasanta sadhukhan wrote: >>>> Hi Phil, >>>> >>>> I checked with NATIVE print dialog and with other app print dialog, >>>> they are positioning the dialog a little ahead of top-left corner >>>> (not at 1/3rd of the window as we are doing now) >>>> so I did the same and positioned the dialog in consistent with our >>>> NATIVE print dialog. >>> >>> You mean consistently. in consistent means the opposite >>> Please adjust that in the code comment. >>> >>> 50,50 is probably OK so long as you verified this is approximately >>> what happens on most platforms, not just windows 8 or similar. >>> I don't think you will find complete consistency because apps may >>> control it and use different dialogs even on the same platform. >>> On hidpi screens this may be closer to the top-left than you intend >>> but I expect it is fine. >>> >> Tested on windows, linux and it works ok. We showed the dialog at >> x+50,y+50 where x,y is the coordinate of the active window. >> Do not have local mac system to test multimonitor setup. >>> The one main thing that you should verify is what happens in the case >>> a native app top-level window is smaller than the print dialog and >>> is positioned >>> at the bottom right (of the right-most display). Does the native app >>> ensure >>> that the dialog is wholly on-screen ? I don't think your code will >>> do that. >>> And Safari on Mac at least seems to do that. I guess that most apps try >>> their best to keep the dialog wholly on-screen. >>> >> Tested this case where window bounds is smaller than print dialog >> but because of this check in ServiceUI.java >> >> // if portion of dialog is not within the gc boundary >> if (!gcBounds.contains(dlgBounds)) { >> // put in the center relative to parent frame/dialog >> dialog.setLocationRelativeTo(owner); >> } >> >> the dialog is shown in the primary window. >> I saw we did not have this check for pageDialog(attr) where the >> dialog is shown in secondary monitor despite gcBounds smaller than >> print dialog. >> Therefore, I removed this check from ServiceUI. >> >> Please find the updated webrev: >> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.03/ >> >> Regards >> Prasanta >>> -phil. >>> >>> >>>> Please find the updated webrev >>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.02/ >>>> >>>> Regards >>>> Prasanta >>>> On 1/22/2016 4:59 AM, Phil Race wrote: >>>>> That is definitely better .. although I wonder if it would be even >>>>> better >>>>> if you found when there is an 'active' window that you tried to >>>>> position the dialog such that it is near the upper-left corner of >>>>> that window ? >>>>> Please experiment and see how that looks compared to what other >>>>> apps are doing. >>>>> >>>>> -phil. >>>>> >>>>> On 01/21/2016 01:45 AM, prasanta sadhukhan wrote: >>>>>> Hi Phil, >>>>>> >>>>>> Please find the updated webrev >>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.01/ >>>>>> which do away with the change in ServiceUI. >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> On 1/21/2016 2:59 AM, Phil Race wrote: >>>>>>> The changes in ServiceUI seem like they can cause the spec. to >>>>>>> be contradicted. >>>>>>> It says >>>>>>> >>>>>>> * @param gc used to select screen. null means primary or >>>>>>> default screen. >>>>>>> >>>>>>> but you update the code such that it will use the active window. >>>>>>> If that is on a secondary screen but null was passed in. >>>>>>> >>>>>>> I am not entirely sure why ServiceUI needs to be changed at all. >>>>>>> It is just the caller of ServiceUI .. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> >>>>>>> On 01/20/2016 03:08 AM, prasanta sadhukhan wrote: >>>>>>>> Hi All, >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8138749 >>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.00/ >>>>>>>> >>>>>>>> Please review a fix for a long standing issue whereby it is >>>>>>>> seen that >>>>>>>> PrinterJob.printDialog(attr set) does not support multi-monitor >>>>>>>> setup. When this API is invoked, the print dialog is always >>>>>>>> displayed on the default screen device regardless of where the >>>>>>>> application is running. >>>>>>>> This is because this method >>>>>>>> uses ServiceDialog class for creating the dialog and that >>>>>>>> indeed supports passing a GC in which we would like to have the >>>>>>>> dialog. But printer job always uses the GraphicsConfig of the >>>>>>>> default screen device >>>>>>>> resulting in print dialog to be shown on primary device/monitor. >>>>>>>> >>>>>>>> I have not considered pageDialog() for this fix. Will create a >>>>>>>> separate bugid and send a patch for that as well once this fix >>>>>>>> is approved. >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> > From alexander.v.stepanov at oracle.com Wed Feb 3 13:46:39 2016 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Wed, 3 Feb 2016 16:46:39 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8145780: create a simple test for TIFF tag sets Message-ID: <56B204BF.2020702@oracle.com> Hello, Could you please review the following fix http://cr.openjdk.java.net/~avstepan/8145780/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8145780 Just a single test added. Thanks, Alexander From philip.race at oracle.com Wed Feb 3 18:19:22 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 03 Feb 2016 10:19:22 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8138749, , Revisited: PrinterJob.printDialog() does not support multi-mon, always displayed on primary In-Reply-To: <56B19180.70207@oracle.com> References: <569F6AC2.7060103@oracle.com> <569FFC46.8040700@oracle.com> <56A0A8BD.306@oracle.com> <56A169C3.2010903@oracle.com> <56A1D85B.3020804@oracle.com> <56AA2B15.90900@oracle.com> <56AB323C.7090706@oracle.com> <56B14B37.6010706@oracle.com> <56B19180.70207@oracle.com> Message-ID: <56B244AA.8060707@oracle.com> Hi, I think it is worth addressing all this at once and I think it can be done entirely in RPJ, leaving ServiceUI alone. Ie fix it just for the case where RPJ displays the dialog(s). When an application calls ServiceUI directly, it can decide where it would like the dialog subject to the existing constraint. The test really should be one test so that the behaviours can be tested as one with lower overhead. -phil. On 02/02/2016 09:34 PM, prasanta sadhukhan wrote: > Hi Phil, > > On 2/3/2016 6:05 AM, Phil Race wrote: >> The RasterPrinterJob changes are now OK however >> >> - I am not sure I understand how removing the check in ServiceUI >> will address the issue about the dialog needing to be entirely >> on-screen. >> It reads to me as if now you allow that in preference to having it >> centred. >> But I am not sure the old code would have worked in all cases either >> since centering on a very small owner window in the corner of the screen >> would result in the same problem. > Since this issue was about showing the dialog on primary vs secondary, > can we address this issue of showing the dialog entirely on-screen in > separate bug id (since this issue is present in primary screen too if > dialog is bigger than top-level window)? > The present change in ServiceUI address the issue of showing the > dialog on secondary monitor if dialog is bigger than top-level. >> Probably what is needed is some code that moves it just enough to fit. >> ie downwards if it is off the top, left if it is off the right and so >> forth ? >> >> - The two tests do not share the same bug ID. I expected they >> should now do so .. and I was further supposing you would merge >> the two tests into one. > I will change the bug id of 2nd test. Is it ok if I keep these 2 tests > separate to make it easier? > > Regards > Prasanta >> >> -phil. >> >> On 01/29/2016 01:34 AM, prasanta sadhukhan wrote: >>> Hi Phil, >>> >>> On 1/28/2016 8:22 PM, Philip Race wrote: >>>> "in consistent" >>>> >>>> On 1/21/16, 11:20 PM, prasanta sadhukhan wrote: >>>>> Hi Phil, >>>>> >>>>> I checked with NATIVE print dialog and with other app print >>>>> dialog, they are positioning the dialog a little ahead of top-left >>>>> corner (not at 1/3rd of the window as we are doing now) >>>>> so I did the same and positioned the dialog in consistent with our >>>>> NATIVE print dialog. >>>> >>>> You mean consistently. in consistent means the opposite >>>> Please adjust that in the code comment. >>>> >>>> 50,50 is probably OK so long as you verified this is approximately >>>> what happens on most platforms, not just windows 8 or similar. >>>> I don't think you will find complete consistency because apps may >>>> control it and use different dialogs even on the same platform. >>>> On hidpi screens this may be closer to the top-left than you intend >>>> but I expect it is fine. >>>> >>> Tested on windows, linux and it works ok. We showed the dialog at >>> x+50,y+50 where x,y is the coordinate of the active window. >>> Do not have local mac system to test multimonitor setup. >>>> The one main thing that you should verify is what happens in the case >>>> a native app top-level window is smaller than the print dialog and >>>> is positioned >>>> at the bottom right (of the right-most display). Does the native >>>> app ensure >>>> that the dialog is wholly on-screen ? I don't think your code will >>>> do that. >>>> And Safari on Mac at least seems to do that. I guess that most apps >>>> try >>>> their best to keep the dialog wholly on-screen. >>>> >>> Tested this case where window bounds is smaller than print dialog >>> but because of this check in ServiceUI.java >>> >>> // if portion of dialog is not within the gc boundary >>> if (!gcBounds.contains(dlgBounds)) { >>> // put in the center relative to parent frame/dialog >>> dialog.setLocationRelativeTo(owner); >>> } >>> >>> the dialog is shown in the primary window. >>> I saw we did not have this check for pageDialog(attr) where the >>> dialog is shown in secondary monitor despite gcBounds smaller than >>> print dialog. >>> Therefore, I removed this check from ServiceUI. >>> >>> Please find the updated webrev: >>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.03/ >>> >>> Regards >>> Prasanta >>>> -phil. >>>> >>>> >>>>> Please find the updated webrev >>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.02/ >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 1/22/2016 4:59 AM, Phil Race wrote: >>>>>> That is definitely better .. although I wonder if it would be >>>>>> even better >>>>>> if you found when there is an 'active' window that you tried to >>>>>> position the dialog such that it is near the upper-left corner of >>>>>> that window ? >>>>>> Please experiment and see how that looks compared to what other >>>>>> apps are doing. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 01/21/2016 01:45 AM, prasanta sadhukhan wrote: >>>>>>> Hi Phil, >>>>>>> >>>>>>> Please find the updated webrev >>>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.01/ >>>>>>> which do away with the change in ServiceUI. >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>> On 1/21/2016 2:59 AM, Phil Race wrote: >>>>>>>> The changes in ServiceUI seem like they can cause the spec. to >>>>>>>> be contradicted. >>>>>>>> It says >>>>>>>> >>>>>>>> * @param gc used to select screen. null means primary or >>>>>>>> default screen. >>>>>>>> >>>>>>>> but you update the code such that it will use the active window. >>>>>>>> If that is on a secondary screen but null was passed in. >>>>>>>> >>>>>>>> I am not entirely sure why ServiceUI needs to be changed at all. >>>>>>>> It is just the caller of ServiceUI .. >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> >>>>>>>> On 01/20/2016 03:08 AM, prasanta sadhukhan wrote: >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8138749 >>>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.00/ >>>>>>>>> >>>>>>>>> Please review a fix for a long standing issue whereby it is >>>>>>>>> seen that >>>>>>>>> PrinterJob.printDialog(attr set) does not support >>>>>>>>> multi-monitor setup. When this API is invoked, the print >>>>>>>>> dialog is always displayed on the default screen device >>>>>>>>> regardless of where the application is running. >>>>>>>>> This is because this method >>>>>>>>> uses ServiceDialog class for creating the dialog and that >>>>>>>>> indeed supports passing a GC in which we would like to have >>>>>>>>> the dialog. But printer job always uses the GraphicsConfig of >>>>>>>>> the default screen device >>>>>>>>> resulting in print dialog to be shown on primary device/monitor. >>>>>>>>> >>>>>>>>> I have not considered pageDialog() for this fix. Will create a >>>>>>>>> separate bugid and send a patch for that as well once this fix >>>>>>>>> is approved. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Prasanta >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >> > From brian.burkhalter at oracle.com Wed Feb 3 22:46:15 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 3 Feb 2016 14:46:15 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8145780: create a simple test for TIFF tag sets In-Reply-To: <56B204BF.2020702@oracle.com> References: <56B204BF.2020702@oracle.com> Message-ID: Hello, Alexander, Looks reasonable to me! Regards, Brian On Feb 3, 2016, at 5:46 AM, Alexander Stepanov wrote: > Hello, > > Could you please review the following fix > http://cr.openjdk.java.net/~avstepan/8145780/webrev.00/ > for > https://bugs.openjdk.java.net/browse/JDK-8145780 > > Just a single test added. > > Thanks, > Alexander From philip.race at oracle.com Wed Feb 3 23:54:03 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 03 Feb 2016 15:54:03 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8148628: TIFFDirectory(getAsMetaData) created with one TIFFField having a IFD pointer tag throws ClassCastException & other naming differences (JEP 262) In-Reply-To: References: Message-ID: <56B2931B.4080409@oracle.com> +1. -phil. On 02/01/2016 03:06 PM, Brian Burkhalter wrote: > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8148628 > Patch: http://cr.openjdk.java.net/~bpb/8148628/webrev.00/ > > Summary: > 1) Needed to fix some problems in TIFFDirectory and TIFFFieldNode with respect to the fact that a TIFFDirectory contained in a TIFFField may be either the ?dir? field or the ?data? field. > 2) Trivial changes to names in Exif and GeoTIFF tags to better align with the respective specifications. > > Thanks, > > Brian From prasanta.sadhukhan at oracle.com Thu Feb 4 05:31:15 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Thu, 4 Feb 2016 11:01:15 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8138749, , Revisited: PrinterJob.printDialog() does not support multi-mon, always displayed on primary In-Reply-To: <56B244AA.8060707@oracle.com> References: <569F6AC2.7060103@oracle.com> <569FFC46.8040700@oracle.com> <56A0A8BD.306@oracle.com> <56A169C3.2010903@oracle.com> <56A1D85B.3020804@oracle.com> <56AA2B15.90900@oracle.com> <56AB323C.7090706@oracle.com> <56B14B37.6010706@oracle.com> <56B19180.70207@oracle.com> <56B244AA.8060707@oracle.com> Message-ID: <56B2E223.1050400@oracle.com> Hi Phil, On 2/3/2016 11:49 PM, Phil Race wrote: > Hi, > > I think it is worth addressing all this at once and I think it can be > done > entirely in RPJ, leaving ServiceUI alone. Ie fix it just for the case > where > RPJ displays the dialog(s). RPJ display the dialog only for pageDialog http://hg.openjdk.java.net/jdk9/client/jdk/file/b9a92b2a8b37/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java#l820 whereas ServiceUI display the printDialog http://hg.openjdk.java.net/jdk9/client/jdk/file/b9a92b2a8b37/src/java.desktop/share/classes/javax/print/ServiceUI.java#l227 So, are you saying we fix it only for pageDialog and leave out printDialog()? Regards Prasanta > When an application calls ServiceUI directly, it > can decide where it would like the dialog subject to the existing > constraint. > > The test really should be one test so that the behaviours can be > tested as one with lower overhead. > > -phil. > > On 02/02/2016 09:34 PM, prasanta sadhukhan wrote: >> Hi Phil, >> >> On 2/3/2016 6:05 AM, Phil Race wrote: >>> The RasterPrinterJob changes are now OK however >>> >>> - I am not sure I understand how removing the check in ServiceUI >>> will address the issue about the dialog needing to be entirely >>> on-screen. >>> It reads to me as if now you allow that in preference to having it >>> centred. >>> But I am not sure the old code would have worked in all cases either >>> since centering on a very small owner window in the corner of the >>> screen >>> would result in the same problem. >> Since this issue was about showing the dialog on primary vs >> secondary, can we address this issue of showing the dialog entirely >> on-screen in separate bug id (since this issue is present in primary >> screen too if dialog is bigger than top-level window)? >> The present change in ServiceUI address the issue of showing the >> dialog on secondary monitor if dialog is bigger than top-level. >>> Probably what is needed is some code that moves it just enough to fit. >>> ie downwards if it is off the top, left if it is off the right and >>> so forth ? >>> >>> - The two tests do not share the same bug ID. I expected they >>> should now do so .. and I was further supposing you would merge >>> the two tests into one. >> I will change the bug id of 2nd test. Is it ok if I keep these 2 >> tests separate to make it easier? >> >> Regards >> Prasanta >>> >>> -phil. >>> >>> On 01/29/2016 01:34 AM, prasanta sadhukhan wrote: >>>> Hi Phil, >>>> >>>> On 1/28/2016 8:22 PM, Philip Race wrote: >>>>> "in consistent" >>>>> >>>>> On 1/21/16, 11:20 PM, prasanta sadhukhan wrote: >>>>>> Hi Phil, >>>>>> >>>>>> I checked with NATIVE print dialog and with other app print >>>>>> dialog, they are positioning the dialog a little ahead of >>>>>> top-left corner (not at 1/3rd of the window as we are doing now) >>>>>> so I did the same and positioned the dialog in consistent with >>>>>> our NATIVE print dialog. >>>>> >>>>> You mean consistently. in consistent means the opposite >>>>> Please adjust that in the code comment. >>>>> >>>>> 50,50 is probably OK so long as you verified this is approximately >>>>> what happens on most platforms, not just windows 8 or similar. >>>>> I don't think you will find complete consistency because apps may >>>>> control it and use different dialogs even on the same platform. >>>>> On hidpi screens this may be closer to the top-left than you intend >>>>> but I expect it is fine. >>>>> >>>> Tested on windows, linux and it works ok. We showed the dialog at >>>> x+50,y+50 where x,y is the coordinate of the active window. >>>> Do not have local mac system to test multimonitor setup. >>>>> The one main thing that you should verify is what happens in the case >>>>> a native app top-level window is smaller than the print dialog and >>>>> is positioned >>>>> at the bottom right (of the right-most display). Does the native >>>>> app ensure >>>>> that the dialog is wholly on-screen ? I don't think your code will >>>>> do that. >>>>> And Safari on Mac at least seems to do that. I guess that most >>>>> apps try >>>>> their best to keep the dialog wholly on-screen. >>>>> >>>> Tested this case where window bounds is smaller than print dialog >>>> but because of this check in ServiceUI.java >>>> >>>> // if portion of dialog is not within the gc boundary >>>> if (!gcBounds.contains(dlgBounds)) { >>>> // put in the center relative to parent frame/dialog >>>> dialog.setLocationRelativeTo(owner); >>>> } >>>> >>>> the dialog is shown in the primary window. >>>> I saw we did not have this check for pageDialog(attr) where the >>>> dialog is shown in secondary monitor despite gcBounds smaller than >>>> print dialog. >>>> Therefore, I removed this check from ServiceUI. >>>> >>>> Please find the updated webrev: >>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.03/ >>>> >>>> Regards >>>> Prasanta >>>>> -phil. >>>>> >>>>> >>>>>> Please find the updated webrev >>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.02/ >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> On 1/22/2016 4:59 AM, Phil Race wrote: >>>>>>> That is definitely better .. although I wonder if it would be >>>>>>> even better >>>>>>> if you found when there is an 'active' window that you tried to >>>>>>> position the dialog such that it is near the upper-left corner >>>>>>> of that window ? >>>>>>> Please experiment and see how that looks compared to what other >>>>>>> apps are doing. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 01/21/2016 01:45 AM, prasanta sadhukhan wrote: >>>>>>>> Hi Phil, >>>>>>>> >>>>>>>> Please find the updated webrev >>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.01/ >>>>>>>> which do away with the change in ServiceUI. >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>>> On 1/21/2016 2:59 AM, Phil Race wrote: >>>>>>>>> The changes in ServiceUI seem like they can cause the spec. to >>>>>>>>> be contradicted. >>>>>>>>> It says >>>>>>>>> >>>>>>>>> * @param gc used to select screen. null means primary or >>>>>>>>> default screen. >>>>>>>>> >>>>>>>>> but you update the code such that it will use the active window. >>>>>>>>> If that is on a secondary screen but null was passed in. >>>>>>>>> >>>>>>>>> I am not entirely sure why ServiceUI needs to be changed at all. >>>>>>>>> It is just the caller of ServiceUI .. >>>>>>>>> >>>>>>>>> -phil. >>>>>>>>> >>>>>>>>> >>>>>>>>> On 01/20/2016 03:08 AM, prasanta sadhukhan wrote: >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8138749 >>>>>>>>>> webrev: >>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.00/ >>>>>>>>>> >>>>>>>>>> Please review a fix for a long standing issue whereby it is >>>>>>>>>> seen that >>>>>>>>>> PrinterJob.printDialog(attr set) does not support >>>>>>>>>> multi-monitor setup. When this API is invoked, the print >>>>>>>>>> dialog is always displayed on the default screen device >>>>>>>>>> regardless of where the application is running. >>>>>>>>>> This is because this method >>>>>>>>>> uses ServiceDialog class for creating the dialog and that >>>>>>>>>> indeed supports passing a GC in which we would like to have >>>>>>>>>> the dialog. But printer job always uses the GraphicsConfig of >>>>>>>>>> the default screen device >>>>>>>>>> resulting in print dialog to be shown on primary device/monitor. >>>>>>>>>> >>>>>>>>>> I have not considered pageDialog() for this fix. Will create >>>>>>>>>> a separate bugid and send a patch for that as well once this >>>>>>>>>> fix is approved. >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Prasanta >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>> >> > From alexander.v.stepanov at oracle.com Thu Feb 4 10:16:31 2016 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Thu, 4 Feb 2016 13:16:31 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8145780: create a simple test for TIFF tag sets In-Reply-To: References: <56B204BF.2020702@oracle.com> Message-ID: <56B324FF.2040504@oracle.com> Hello, Brian, Thanks! Regards, Alexander On 2/4/2016 1:46 AM, Brian Burkhalter wrote: > Hello, Alexander, > > Looks reasonable to me! > > Regards, > > Brian > > On Feb 3, 2016, at 5:46 AM, Alexander Stepanov wrote: > >> Hello, >> >> Could you please review the following fix >> http://cr.openjdk.java.net/~avstepan/8145780/webrev.00/ >> for >> https://bugs.openjdk.java.net/browse/JDK-8145780 >> >> Just a single test added. >> >> Thanks, >> Alexander From yuri.nesterenko at oracle.com Thu Feb 4 11:14:09 2016 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Thu, 4 Feb 2016 14:14:09 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8145780: create a simple test for TIFF tag sets In-Reply-To: <56B204BF.2020702@oracle.com> References: <56B204BF.2020702@oracle.com> Message-ID: <56B33281.1010206@oracle.com> OK with me! -yan On 02/03/2016 04:46 PM, Alexander Stepanov wrote: > Hello, > > Could you please review the following fix > http://cr.openjdk.java.net/~avstepan/8145780/webrev.00/ > for > https://bugs.openjdk.java.net/browse/JDK-8145780 > > Just a single test added. > > Thanks, > Alexander From alexander.v.stepanov at oracle.com Thu Feb 4 11:19:40 2016 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Thu, 4 Feb 2016 14:19:40 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8145780: create a simple test for TIFF tag sets In-Reply-To: <56B33281.1010206@oracle.com> References: <56B204BF.2020702@oracle.com> <56B33281.1010206@oracle.com> Message-ID: <56B333CC.4010503@oracle.com> Thanks! On 2/4/2016 2:14 PM, Yuri Nesterenko wrote: > OK with me! > > -yan > > On 02/03/2016 04:46 PM, Alexander Stepanov wrote: >> Hello, >> >> Could you please review the following fix >> http://cr.openjdk.java.net/~avstepan/8145780/webrev.00/ >> for >> https://bugs.openjdk.java.net/browse/JDK-8145780 >> >> Just a single test added. >> >> Thanks, >> Alexander > From bourges.laurent at gmail.com Thu Feb 4 22:21:19 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 4 Feb 2016 23:21:19 +0100 Subject: [OpenJDK 2D-Dev] RFR 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering Message-ID: Please review the webrev fixing SEGFAULT (P2) in the Marlin Renderer when using thread-local storage with custom Paint (reentrance): bug: https://bugs.openjdk.java.net/browse/JDK-8148886 webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8148886.0/ Changes: - detect reentrance in MarlinRenderingEngine using flag RendererContext.usedTL (true/false) and use another context from CLQ - added few more details in array checks (XXXArrayCache) - fixed AAShapePipe to support reentrancy: added defensive copy of int[] abox in local variables + TODO to discuss - updated Version to 0.7.3.2 - fixed copyright headers Best regards, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Fri Feb 5 01:10:39 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 4 Feb 2016 17:10:39 -0800 Subject: [OpenJDK 2D-Dev] RFR 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering In-Reply-To: References: Message-ID: <56B3F68F.3070204@oracle.com> Hi Laurent, In AAShapePipe you load the values from abox[] into variables named xywh, but these are not xywh values, they are min/max values. We typically use any of the following naming conventions for these types of values: - x0, y0, x1, y1 - x1, y1, x2, y2 - minX, minY, maxX, maxY Other than that naming inconsistency the changes look great... ...jim On 2/4/2016 2:21 PM, Laurent Bourg?s wrote: > Please review the webrev fixing SEGFAULT (P2) in the Marlin Renderer > when using thread-local storage with custom Paint (reentrance): > bug: https://bugs.openjdk.java.net/browse/JDK-8148886 > webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8148886.0/ > > Changes: > - detect reentrance in MarlinRenderingEngine using flag > RendererContext.usedTL (true/false) and use another context from CLQ > - added few more details in array checks (XXXArrayCache) > - fixed AAShapePipe to support reentrancy: added defensive copy of int[] > abox in local variables + TODO to discuss > - updated Version to 0.7.3.2 > - fixed copyright headers > > Best regards, > Laurent From james.graham at oracle.com Fri Feb 5 01:20:03 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 4 Feb 2016 17:20:03 -0800 Subject: [OpenJDK 2D-Dev] RFR 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering In-Reply-To: <56B3F68F.3070204@oracle.com> References: <56B3F68F.3070204@oracle.com> Message-ID: <56B3F8C3.7040609@oracle.com> Ah, at least one error spotted here after my initial review... The abox values could be changed by the code in lines 157-160 so you can't cache their values until after that. Also, as you pointed out in another thread in the grdev group, we should probably do the same treatment for the TileState in case we have reentrance for the AAShapePipe code... ...jim On 2/4/2016 5:10 PM, Jim Graham wrote: > Hi Laurent, > > In AAShapePipe you load the values from abox[] into variables named > xywh, but these are not xywh values, they are min/max values. We > typically use any of the following naming conventions for these types of > values: > > - x0, y0, x1, y1 > - x1, y1, x2, y2 > - minX, minY, maxX, maxY > > Other than that naming inconsistency the changes look great... > > ...jim > > On 2/4/2016 2:21 PM, Laurent Bourg?s wrote: >> Please review the webrev fixing SEGFAULT (P2) in the Marlin Renderer >> when using thread-local storage with custom Paint (reentrance): >> bug: https://bugs.openjdk.java.net/browse/JDK-8148886 >> webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8148886.0/ >> >> Changes: >> - detect reentrance in MarlinRenderingEngine using flag >> RendererContext.usedTL (true/false) and use another context from CLQ >> - added few more details in array checks (XXXArrayCache) >> - fixed AAShapePipe to support reentrancy: added defensive copy of int[] >> abox in local variables + TODO to discuss >> - updated Version to 0.7.3.2 >> - fixed copyright headers >> >> Best regards, >> Laurent From prasanta.sadhukhan at oracle.com Fri Feb 5 08:57:32 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Fri, 5 Feb 2016 14:27:32 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8138749, , Revisited: PrinterJob.printDialog() does not support multi-mon, always displayed on primary In-Reply-To: <56B2E223.1050400@oracle.com> References: <569F6AC2.7060103@oracle.com> <569FFC46.8040700@oracle.com> <56A0A8BD.306@oracle.com> <56A169C3.2010903@oracle.com> <56A1D85B.3020804@oracle.com> <56AA2B15.90900@oracle.com> <56AB323C.7090706@oracle.com> <56B14B37.6010706@oracle.com> <56B19180.70207@oracle.com> <56B244AA.8060707@oracle.com> <56B2E223.1050400@oracle.com> Message-ID: <56B463FC.9070702@oracle.com> On 2/4/2016 11:01 AM, prasanta sadhukhan wrote: > Hi Phil, > > On 2/3/2016 11:49 PM, Phil Race wrote: >> Hi, >> >> I think it is worth addressing all this at once and I think it can be >> done >> entirely in RPJ, leaving ServiceUI alone. Ie fix it just for the case >> where >> RPJ displays the dialog(s). > RPJ display the dialog only for pageDialog > http://hg.openjdk.java.net/jdk9/client/jdk/file/b9a92b2a8b37/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java#l820 > > whereas ServiceUI display the printDialog > http://hg.openjdk.java.net/jdk9/client/jdk/file/b9a92b2a8b37/src/java.desktop/share/classes/javax/print/ServiceUI.java#l227 > > > So, are you saying we fix it only for pageDialog and leave out > printDialog()? > Please find updated webrev http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.04/ where both RPJ and ServiceUI is modified to show the dialog entirely on-screen. I could not leave ServiceUI without modification as // if portion of dialog is not within the gc boundary if (!gcBounds.contains(dlgBounds)) { // put in the center relative to parent frame/dialog dialog.setLocationRelativeTo(owner); } this code was drawing the dialog in primary so I have to delete the code to make sure dialog is displayed on secondary to fix the bug. And since anyway, I was modifying ServiceUI, I thought of adding the check to draw the printDialog on screen in ServiceUI same as pageDialog. Regards Prasanta > Regards > Prasanta >> When an application calls ServiceUI directly, it >> can decide where it would like the dialog subject to the existing >> constraint. >> >> The test really should be one test so that the behaviours can be >> tested as one with lower overhead. >> >> -phil. >> >> On 02/02/2016 09:34 PM, prasanta sadhukhan wrote: >>> Hi Phil, >>> >>> On 2/3/2016 6:05 AM, Phil Race wrote: >>>> The RasterPrinterJob changes are now OK however >>>> >>>> - I am not sure I understand how removing the check in ServiceUI >>>> will address the issue about the dialog needing to be entirely >>>> on-screen. >>>> It reads to me as if now you allow that in preference to having it >>>> centred. >>>> But I am not sure the old code would have worked in all cases either >>>> since centering on a very small owner window in the corner of the >>>> screen >>>> would result in the same problem. >>> Since this issue was about showing the dialog on primary vs >>> secondary, can we address this issue of showing the dialog entirely >>> on-screen in separate bug id (since this issue is present in primary >>> screen too if dialog is bigger than top-level window)? >>> The present change in ServiceUI address the issue of showing the >>> dialog on secondary monitor if dialog is bigger than top-level. >>>> Probably what is needed is some code that moves it just enough to fit. >>>> ie downwards if it is off the top, left if it is off the right and >>>> so forth ? >>>> >>>> - The two tests do not share the same bug ID. I expected they >>>> should now do so .. and I was further supposing you would merge >>>> the two tests into one. >>> I will change the bug id of 2nd test. Is it ok if I keep these 2 >>> tests separate to make it easier? >>> >>> Regards >>> Prasanta >>>> >>>> -phil. >>>> >>>> On 01/29/2016 01:34 AM, prasanta sadhukhan wrote: >>>>> Hi Phil, >>>>> >>>>> On 1/28/2016 8:22 PM, Philip Race wrote: >>>>>> "in consistent" >>>>>> >>>>>> On 1/21/16, 11:20 PM, prasanta sadhukhan wrote: >>>>>>> Hi Phil, >>>>>>> >>>>>>> I checked with NATIVE print dialog and with other app print >>>>>>> dialog, they are positioning the dialog a little ahead of >>>>>>> top-left corner (not at 1/3rd of the window as we are doing now) >>>>>>> so I did the same and positioned the dialog in consistent with >>>>>>> our NATIVE print dialog. >>>>>> >>>>>> You mean consistently. in consistent means the opposite >>>>>> Please adjust that in the code comment. >>>>>> >>>>>> 50,50 is probably OK so long as you verified this is approximately >>>>>> what happens on most platforms, not just windows 8 or similar. >>>>>> I don't think you will find complete consistency because apps may >>>>>> control it and use different dialogs even on the same platform. >>>>>> On hidpi screens this may be closer to the top-left than you intend >>>>>> but I expect it is fine. >>>>>> >>>>> Tested on windows, linux and it works ok. We showed the dialog at >>>>> x+50,y+50 where x,y is the coordinate of the active window. >>>>> Do not have local mac system to test multimonitor setup. >>>>>> The one main thing that you should verify is what happens in the >>>>>> case >>>>>> a native app top-level window is smaller than the print dialog >>>>>> and is positioned >>>>>> at the bottom right (of the right-most display). Does the native >>>>>> app ensure >>>>>> that the dialog is wholly on-screen ? I don't think your code >>>>>> will do that. >>>>>> And Safari on Mac at least seems to do that. I guess that most >>>>>> apps try >>>>>> their best to keep the dialog wholly on-screen. >>>>>> >>>>> Tested this case where window bounds is smaller than print dialog >>>>> but because of this check in ServiceUI.java >>>>> >>>>> // if portion of dialog is not within the gc boundary >>>>> if (!gcBounds.contains(dlgBounds)) { >>>>> // put in the center relative to parent frame/dialog >>>>> dialog.setLocationRelativeTo(owner); >>>>> } >>>>> >>>>> the dialog is shown in the primary window. >>>>> I saw we did not have this check for pageDialog(attr) where the >>>>> dialog is shown in secondary monitor despite gcBounds smaller than >>>>> print dialog. >>>>> Therefore, I removed this check from ServiceUI. >>>>> >>>>> Please find the updated webrev: >>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.03/ >>>>> >>>>> Regards >>>>> Prasanta >>>>>> -phil. >>>>>> >>>>>> >>>>>>> Please find the updated webrev >>>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.02/ >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>> On 1/22/2016 4:59 AM, Phil Race wrote: >>>>>>>> That is definitely better .. although I wonder if it would be >>>>>>>> even better >>>>>>>> if you found when there is an 'active' window that you tried to >>>>>>>> position the dialog such that it is near the upper-left corner >>>>>>>> of that window ? >>>>>>>> Please experiment and see how that looks compared to what other >>>>>>>> apps are doing. >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> On 01/21/2016 01:45 AM, prasanta sadhukhan wrote: >>>>>>>>> Hi Phil, >>>>>>>>> >>>>>>>>> Please find the updated webrev >>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.01/ >>>>>>>>> which do away with the change in ServiceUI. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Prasanta >>>>>>>>> On 1/21/2016 2:59 AM, Phil Race wrote: >>>>>>>>>> The changes in ServiceUI seem like they can cause the spec. >>>>>>>>>> to be contradicted. >>>>>>>>>> It says >>>>>>>>>> >>>>>>>>>> * @param gc used to select screen. null means primary or >>>>>>>>>> default screen. >>>>>>>>>> >>>>>>>>>> but you update the code such that it will use the active window. >>>>>>>>>> If that is on a secondary screen but null was passed in. >>>>>>>>>> >>>>>>>>>> I am not entirely sure why ServiceUI needs to be changed at all. >>>>>>>>>> It is just the caller of ServiceUI .. >>>>>>>>>> >>>>>>>>>> -phil. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 01/20/2016 03:08 AM, prasanta sadhukhan wrote: >>>>>>>>>>> Hi All, >>>>>>>>>>> >>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8138749 >>>>>>>>>>> webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Please review a fix for a long standing issue whereby it is >>>>>>>>>>> seen that >>>>>>>>>>> PrinterJob.printDialog(attr set) does not support >>>>>>>>>>> multi-monitor setup. When this API is invoked, the print >>>>>>>>>>> dialog is always displayed on the default screen device >>>>>>>>>>> regardless of where the application is running. >>>>>>>>>>> This is because this method >>>>>>>>>>> uses ServiceDialog class for creating the dialog and that >>>>>>>>>>> indeed supports passing a GC in which we would like to have >>>>>>>>>>> the dialog. But printer job always uses the GraphicsConfig >>>>>>>>>>> of the default screen device >>>>>>>>>>> resulting in print dialog to be shown on primary >>>>>>>>>>> device/monitor. >>>>>>>>>>> >>>>>>>>>>> I have not considered pageDialog() for this fix. Will create >>>>>>>>>>> a separate bugid and send a patch for that as well once this >>>>>>>>>>> fix is approved. >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> Prasanta >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >>> >> > From alexandr.scherbatiy at oracle.com Fri Feb 5 10:12:09 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Fri, 5 Feb 2016 02:12:09 -0800 Subject: [OpenJDK 2D-Dev] [9] Review request for 8076545 Text size is twice bigger under Windows L&F on Win 8.1 with HiDPI display In-Reply-To: <56B00B8B.9040102@oracle.com> References: <5596C117.1040806@oracle.com> <559DB2FB.5000208@oracle.com> <55A902D4.1050603@oracle.com> <563208A9.50702@oracle.com> <56328355.1010608@oracle.com> <5633C7C8.2030804@oracle.com> <5649E312.2010606@oracle.com> <564A41D3.5010202@oracle.com> <564A4DE9.1040102@oracle.com> <56ABB269.6030808@oracle.com> <56ABD6B2.10302@oracle.com> <56AF4F4C.4030504@oracle.com> <56B00B8B.9040102@oracle.com> Message-ID: <56B47579.3090309@oracle.com> Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8076545/webrev.05 - The awt_DesktopProperties.cpp file is updated to use scaleX for width rescaling and scaleY for height rescaling Thanks, Alexandr. On 2/1/2016 5:51 PM, Jim Graham wrote: > Hi Alexandr, > > In awt_DesktopProperties.cpp you are using the Y scaling factor to > scale widths still - see lines 287 (and others in that same function) > and then 322 in another function. It looks like you'll need > getInvScaleX() and getInvScaleY(). > > I'll leave it to Phil to comment on the unit test... > > ...jim > > On 2/1/16 4:27 AM, Alexandr Scherbatiy wrote: >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8076545/webrev.04/ >> >> - both LOGPIXELSX and Y are used for the theme size scaling. >> - LOGPIXELSY is used for text metrics height rescaling >> >> Thanks, >> Alexandr. >> >> On 1/29/2016 1:16 PM, Jim Graham wrote: >>> Hi Alexandr, >>> >>> Thanks for investigating the behaviors. >>> >>> With respect to using LOGPIXELSX or Y, these methods are used to scale >>> both horizontal and vertical measurements so we really should have 2 >>> scale values and rescale methods, one for horizontal use and one for >>> vertical... >>> >>> ...jim >>> >>> On 1/29/2016 10:41 AM, Alexandr Scherbatiy wrote: >>>> Could you review the updated fix: >>>> http://cr.openjdk.java.net/~alexsch/8076545/webrev.03 >>>> >>>> - LOGPIXELSX is changed to LOGPIXELSY >>>> >>>> On 11/16/2015 1:43 PM, Jim Graham wrote: >>>>> Note that LOGPIXELSY is global and static between reboots so it >>>>> doesn't really matter which monitor is used to get the value. >>>>> >>>>> Also, the issue is that the measurements are in pixels, so if we >>>>> convert them into a resolution independent measurement then the rest >>>>> of the scaling in the AWT/2D will be correct regardless of any given >>>>> monitor's resolution. We just have to make sure the >>>>> "de-pixelization" >>>>> of the measurement is an apples-to-apples calculation. >>>>> >>>>> The question in my mind is whether the values they get from >>>>> GetTheme*() and SPI_GETNONCLIENTMETRICS are relative to >>>>> LOGPIXELSY, or >>>>> the more recent Per-Monitor aware DPI APIs, or ...? It would be >>>>> interesting to see what happens to those values when you change the >>>>> DPI settings on Windows 8.1 and not reboot. If they stay constant >>>>> until you reboot then LOGPIXELSY on the main screen would be the >>>>> value >>>>> to use to de-scale them... >>>> >>>> I tried to use the "Change the size of all items" slider on >>>> Windows >>>> 8.1 without rebooting. >>>> GetDpiForMonitor() returns the updated DPI values: 192, 144, 96 >>>> LOGPIXELSY returns unchanged values: 192, 192, 192 >>>> SystemParametersInfo(SPI_GETNONCLIENTMETRICS,...) returns >>>> unchanged >>>> NONCLIENTMETRICS >>>> GetThemePartSize() returns unchanged theme part sizes >>>> >>>> It seems that theme part sizes behave in the same way as the >>>> LOGPIXELSY in this case. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>> >>>>> ...jim >>>>> >>>>> On 11/16/2015 12:51 PM, Phil Race wrote: >>>>>> That seems better. But one more question to get a point clarified. >>>>>> You are using getDesktopWindow() which is for the primary monitor. >>>>>> I assume that the 'inversion' results in the value being used to be >>>>>> independent >>>>>> of the monitor in a multi-mon situation and so when we move to a 2nd >>>>>> monitor >>>>>> that inverted size remains valid ? >>>>>> >>>>>> If so looks good to me. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 11/16/2015 06:07 AM, Alexander Scherbatiy wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Could you review the updated fix: >>>>>>> http://cr.openjdk.java.net/~alexsch/8076545/webrev.02 >>>>>>> >>>>>>> - round is used instead of ceil >>>>>>> - inverted scales are used >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> >>>>>>> On 10/30/2015 10:40 PM, Jim Graham wrote: >>>>>>>> In this case round may be better. ceil() is more for cases >>>>>>>> where you >>>>>>>> needed "at least X amount of room", but I don't think a font >>>>>>>> size is >>>>>>>> an "at least this much" kind of case. >>>>>>>> >>>>>>>> Also, I've been toying with the idea that use of ceil() and >>>>>>>> floor() >>>>>>>> in any DPI-adjustment equations should really be "ceil(val - >>>>>>>> epsilon)" or "floor(ceil + epsilon)" for some small value of >>>>>>>> epsilon >>>>>>>> chosen just large enough to prevent various round-off errors from >>>>>>>> affecting the outcome. One idea is for 1/256 as the value of >>>>>>>> epsilon >>>>>>>> since that could equate to the smallest measurable difference in >>>>>>>> terms of alpha or interpolation results (or 1/512 for "half the >>>>>>>> smallest quantum")... >>>>>>>> >>>>>>>> ...jim >>>>>>>> >>>>>>>> On 10/29/15 1:36 PM, Phil Race wrote: >>>>>>>>> size->cx = (int)ceil(size->cx / scale); >>>>>>>>> >>>>>>>>> >>>>>>>>> So if size->cx / scale works out to be 12.0001 you will round >>>>>>>>> it up >>>>>>>>> to 13? >>>>>>>>> >>>>>>>>> Can you check what pixel size windows gives you in such a case ? >>>>>>>>> I'd be a little surprised if they did that rather than round. >>>>>>>>> >>>>>>>>> Is the SetFontProperty that does not accept a scale parameter >>>>>>>>> still >>>>>>>>> used >>>>>>>>> somewhere ? >>>>>>>>> >>>>>>>>> -phil. >>>>>>>>> >>>>>>>>> On 10/29/2015 04:53 AM, Sergey Bylokhov wrote: >>>>>>>>>> On 17.07.15 16:27, Alexander Scherbatiy wrote: >>>>>>>>>>>> >>>>>>>>>>>> - Sergey's point about multi-mon should be checked out. >>>>>>>>>>> Windows 8.1 has option "Let me choose one scaling level >>>>>>>>>>> for >>>>>>>>>>> all my >>>>>>>>>>> displays". >>>>>>>>>>> If I unset it I am able to change the size of all items. >>>>>>>>>>> However, >>>>>>>>>>> the DPI which returns GetDPIForMonitor is still 2 on HiDPI >>>>>>>>>>> displays. >>>>>>>>>> >>>>>>>>>> This version looks fine, but I am sure it can be double >>>>>>>>>> checked on >>>>>>>>>> windows 10 at some moment as well. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>> >> From dmitry.markov at oracle.com Fri Feb 5 11:51:28 2016 From: dmitry.markov at oracle.com (dmitry markov) Date: Fri, 05 Feb 2016 14:51:28 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8073400: Some Monospaced logical fonts have a different width In-Reply-To: <569F54A4.9010800@oracle.com> References: <56977953.10604@oracle.com> <569F54A4.9010800@oracle.com> Message-ID: <56B48CC0.2030406@oracle.com> Reminder. Could anyone review the fix, please? Thanks in advance, Dmitry On 20/01/2016 12:34, dmitry markov wrote: > Hello, > > Any volunteers to review the fix? > > Thanks, > Dmitry > On 14/01/2016 13:32, dmitry markov wrote: >> Hello, >> >> Could you review the fix for jdk9, please? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8073400 >> webrev: http://cr.openjdk.java.net/~dmarkov/8073400/jdk9/webrev.00/ >> >> Problem description: >> On Windows some characters (in particular, left and right double >> quotation marks) have width differing from other characters' widths, >> when Monospaced logical font is used. >> The default monospaced font for windows platform is Courier New. It >> contains the desired characters, (i.e. '\u201c' and '\u201d'). >> However the characters are in 'exclusion ranges' for this font due to >> settings in windows.fontconfig.properties. So when we try to obtain >> glyphs for these characters and calculate their bounds, we fallback >> to another font (Lucida) and use its glyphs. >> >> Fix: >> Remove the following set of characters u2018 - u201F from the >> exclusion ranges. >> >> Thanks, >> Dmitry > From james.graham at oracle.com Fri Feb 5 19:37:46 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 5 Feb 2016 11:37:46 -0800 Subject: [OpenJDK 2D-Dev] [9] Review request for 8076545 Text size is twice bigger under Windows L&F on Win 8.1 with HiDPI display In-Reply-To: <56B47579.3090309@oracle.com> References: <5596C117.1040806@oracle.com> <559DB2FB.5000208@oracle.com> <55A902D4.1050603@oracle.com> <563208A9.50702@oracle.com> <56328355.1010608@oracle.com> <5633C7C8.2030804@oracle.com> <5649E312.2010606@oracle.com> <564A41D3.5010202@oracle.com> <564A4DE9.1040102@oracle.com> <56ABB269.6030808@oracle.com> <56ABD6B2.10302@oracle.com> <56AF4F4C.4030504@oracle.com> <56B00B8B.9040102@oracle.com> <56B47579.3090309@oracle.com> Message-ID: <56B4FA0A.3080505@oracle.com> Hi Alexandr, awt_DesktopProperties.cpp, line 300 - is the "1.0f /" a typo? Also, is there a still a need for the setFontProperty() variants that don't have a scale as the last parameter? ...jim On 2/5/2016 2:12 AM, Alexandr Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8076545/webrev.05 > > - The awt_DesktopProperties.cpp file is updated to use scaleX for > width rescaling and scaleY for height rescaling > > Thanks, > Alexandr. > > On 2/1/2016 5:51 PM, Jim Graham wrote: >> Hi Alexandr, >> >> In awt_DesktopProperties.cpp you are using the Y scaling factor to >> scale widths still - see lines 287 (and others in that same function) >> and then 322 in another function. It looks like you'll need >> getInvScaleX() and getInvScaleY(). >> >> I'll leave it to Phil to comment on the unit test... >> >> ...jim >> >> On 2/1/16 4:27 AM, Alexandr Scherbatiy wrote: >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8076545/webrev.04/ >>> >>> - both LOGPIXELSX and Y are used for the theme size scaling. >>> - LOGPIXELSY is used for text metrics height rescaling >>> >>> Thanks, >>> Alexandr. >>> >>> On 1/29/2016 1:16 PM, Jim Graham wrote: >>>> Hi Alexandr, >>>> >>>> Thanks for investigating the behaviors. >>>> >>>> With respect to using LOGPIXELSX or Y, these methods are used to scale >>>> both horizontal and vertical measurements so we really should have 2 >>>> scale values and rescale methods, one for horizontal use and one for >>>> vertical... >>>> >>>> ...jim >>>> >>>> On 1/29/2016 10:41 AM, Alexandr Scherbatiy wrote: >>>>> Could you review the updated fix: >>>>> http://cr.openjdk.java.net/~alexsch/8076545/webrev.03 >>>>> >>>>> - LOGPIXELSX is changed to LOGPIXELSY >>>>> >>>>> On 11/16/2015 1:43 PM, Jim Graham wrote: >>>>>> Note that LOGPIXELSY is global and static between reboots so it >>>>>> doesn't really matter which monitor is used to get the value. >>>>>> >>>>>> Also, the issue is that the measurements are in pixels, so if we >>>>>> convert them into a resolution independent measurement then the rest >>>>>> of the scaling in the AWT/2D will be correct regardless of any given >>>>>> monitor's resolution. We just have to make sure the >>>>>> "de-pixelization" >>>>>> of the measurement is an apples-to-apples calculation. >>>>>> >>>>>> The question in my mind is whether the values they get from >>>>>> GetTheme*() and SPI_GETNONCLIENTMETRICS are relative to >>>>>> LOGPIXELSY, or >>>>>> the more recent Per-Monitor aware DPI APIs, or ...? It would be >>>>>> interesting to see what happens to those values when you change the >>>>>> DPI settings on Windows 8.1 and not reboot. If they stay constant >>>>>> until you reboot then LOGPIXELSY on the main screen would be the >>>>>> value >>>>>> to use to de-scale them... >>>>> >>>>> I tried to use the "Change the size of all items" slider on >>>>> Windows >>>>> 8.1 without rebooting. >>>>> GetDpiForMonitor() returns the updated DPI values: 192, 144, 96 >>>>> LOGPIXELSY returns unchanged values: 192, 192, 192 >>>>> SystemParametersInfo(SPI_GETNONCLIENTMETRICS,...) returns >>>>> unchanged >>>>> NONCLIENTMETRICS >>>>> GetThemePartSize() returns unchanged theme part sizes >>>>> >>>>> It seems that theme part sizes behave in the same way as the >>>>> LOGPIXELSY in this case. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>>> >>>>>> ...jim >>>>>> >>>>>> On 11/16/2015 12:51 PM, Phil Race wrote: >>>>>>> That seems better. But one more question to get a point clarified. >>>>>>> You are using getDesktopWindow() which is for the primary monitor. >>>>>>> I assume that the 'inversion' results in the value being used to be >>>>>>> independent >>>>>>> of the monitor in a multi-mon situation and so when we move to a 2nd >>>>>>> monitor >>>>>>> that inverted size remains valid ? >>>>>>> >>>>>>> If so looks good to me. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 11/16/2015 06:07 AM, Alexander Scherbatiy wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> Could you review the updated fix: >>>>>>>> http://cr.openjdk.java.net/~alexsch/8076545/webrev.02 >>>>>>>> >>>>>>>> - round is used instead of ceil >>>>>>>> - inverted scales are used >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>> >>>>>>>> On 10/30/2015 10:40 PM, Jim Graham wrote: >>>>>>>>> In this case round may be better. ceil() is more for cases >>>>>>>>> where you >>>>>>>>> needed "at least X amount of room", but I don't think a font >>>>>>>>> size is >>>>>>>>> an "at least this much" kind of case. >>>>>>>>> >>>>>>>>> Also, I've been toying with the idea that use of ceil() and >>>>>>>>> floor() >>>>>>>>> in any DPI-adjustment equations should really be "ceil(val - >>>>>>>>> epsilon)" or "floor(ceil + epsilon)" for some small value of >>>>>>>>> epsilon >>>>>>>>> chosen just large enough to prevent various round-off errors from >>>>>>>>> affecting the outcome. One idea is for 1/256 as the value of >>>>>>>>> epsilon >>>>>>>>> since that could equate to the smallest measurable difference in >>>>>>>>> terms of alpha or interpolation results (or 1/512 for "half the >>>>>>>>> smallest quantum")... >>>>>>>>> >>>>>>>>> ...jim >>>>>>>>> >>>>>>>>> On 10/29/15 1:36 PM, Phil Race wrote: >>>>>>>>>> size->cx = (int)ceil(size->cx / scale); >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> So if size->cx / scale works out to be 12.0001 you will round >>>>>>>>>> it up >>>>>>>>>> to 13? >>>>>>>>>> >>>>>>>>>> Can you check what pixel size windows gives you in such a case ? >>>>>>>>>> I'd be a little surprised if they did that rather than round. >>>>>>>>>> >>>>>>>>>> Is the SetFontProperty that does not accept a scale parameter >>>>>>>>>> still >>>>>>>>>> used >>>>>>>>>> somewhere ? >>>>>>>>>> >>>>>>>>>> -phil. >>>>>>>>>> >>>>>>>>>> On 10/29/2015 04:53 AM, Sergey Bylokhov wrote: >>>>>>>>>>> On 17.07.15 16:27, Alexander Scherbatiy wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> - Sergey's point about multi-mon should be checked out. >>>>>>>>>>>> Windows 8.1 has option "Let me choose one scaling level >>>>>>>>>>>> for >>>>>>>>>>>> all my >>>>>>>>>>>> displays". >>>>>>>>>>>> If I unset it I am able to change the size of all items. >>>>>>>>>>>> However, >>>>>>>>>>>> the DPI which returns GetDPIForMonitor is still 2 on HiDPI >>>>>>>>>>>> displays. >>>>>>>>>>> >>>>>>>>>>> This version looks fine, but I am sure it can be double >>>>>>>>>>> checked on >>>>>>>>>>> windows 10 at some moment as well. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> > From philip.race at oracle.com Fri Feb 5 19:39:21 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 05 Feb 2016 11:39:21 -0800 Subject: [OpenJDK 2D-Dev] [9] Review request for 8142966 Wrong cursor position in text components on HiDPI display In-Reply-To: <56A935F0.5060504@oracle.com> References: <56A935F0.5060504@oracle.com> Message-ID: <56B4FA69.9000604@oracle.com> Two things strike me when I read this 1) Initial surprise at how deep into the font code it goes. Perhaps there are alternatives. 2) That it changes to using the linear metrics for measuring advance. Regardless of (1) I do not think (2) is correct. I am fairly sure this will lead to changes in text advance. It seems like it must throw away adjusted metrics as a result of glyph hinting. I don't know what the fix should be, since I have not looked at the problem top-down, I am just seeing the bottom-up proposed solution. So all I can say for now is that it needs to be at least somewhat different. -phil. On 01/27/2016 01:26 PM, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8142966 > webrev: http://cr.openjdk.java.net/~alexsch/8142966/webev.00/ > > The proposed fix rounds a glyph advance first and then scales it if > UI scales do not equal to one. > > Thanks, > Alexandr. > From bourges.laurent at gmail.com Fri Feb 5 23:21:58 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Sat, 6 Feb 2016 00:21:58 +0100 Subject: [OpenJDK 2D-Dev] RFR 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering In-Reply-To: <56B3F8C3.7040609@oracle.com> References: <56B3F68F.3070204@oracle.com> <56B3F8C3.7040609@oracle.com> Message-ID: Jim & Phil, Here is an updated webrev according to jim's comments: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8148886.1/ Changes: - AAShapePipe rewritten to use a new ReentrantThreadLocal class (generalization) that use TL + CLQ (like Marlin) to use other (cached) TileState instances in case of reentrancy; such class may be useful for other use cases (replacing synchronized / static refs); it do not use WeakReference as TileState instances are very small (to be improved later ?) - Improved CrashPaintTest to check few pixel values to ensure rendering is correct PS: I noticed that AlphaPaintPipe has a constant int TILE_SIZE = 32 that seems useless as the method has a tilesize argument; maybe it should be cleaned up ? Regards, Laurent 2016-02-05 2:20 GMT+01:00 Jim Graham : > Ah, at least one error spotted here after my initial review... > > The abox values could be changed by the code in lines 157-160 so you can't > cache their values until after that. > > Also, as you pointed out in another thread in the grdev group, we should > probably do the same treatment for the TileState in case we have reentrance > for the AAShapePipe code... > > ...jim > > > On 2/4/2016 5:10 PM, Jim Graham wrote: > >> Hi Laurent, >> >> In AAShapePipe you load the values from abox[] into variables named >> xywh, but these are not xywh values, they are min/max values. We >> typically use any of the following naming conventions for these types of >> values: >> >> - x0, y0, x1, y1 >> - x1, y1, x2, y2 >> - minX, minY, maxX, maxY >> >> Other than that naming inconsistency the changes look great... >> >> ...jim >> >> On 2/4/2016 2:21 PM, Laurent Bourg?s wrote: >> >>> Please review the webrev fixing SEGFAULT (P2) in the Marlin Renderer >>> when using thread-local storage with custom Paint (reentrance): >>> bug: https://bugs.openjdk.java.net/browse/JDK-8148886 >>> webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8148886.0/ >>> >>> Changes: >>> - detect reentrance in MarlinRenderingEngine using flag >>> RendererContext.usedTL (true/false) and use another context from CLQ >>> - added few more details in array checks (XXXArrayCache) >>> - fixed AAShapePipe to support reentrancy: added defensive copy of int[] >>> abox in local variables + TODO to discuss >>> - updated Version to 0.7.3.2 >>> - fixed copyright headers >>> >>> Best regards, >>> Laurent >>> >> -- -- Laurent Bourg?s -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Sat Feb 6 15:19:00 2016 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Sat, 6 Feb 2016 19:19:00 +0400 Subject: [OpenJDK 2D-Dev] [9] Review request for 8076545 Text size is twice bigger under Windows L&F on Win 8.1 with HiDPI display In-Reply-To: <56B4FA0A.3080505@oracle.com> References: <5596C117.1040806@oracle.com> <559DB2FB.5000208@oracle.com> <55A902D4.1050603@oracle.com> <563208A9.50702@oracle.com> <56328355.1010608@oracle.com> <5633C7C8.2030804@oracle.com> <5649E312.2010606@oracle.com> <564A41D3.5010202@oracle.com> <564A4DE9.1040102@oracle.com> <56ABB269.6030808@oracle.com> <56ABD6B2.10302@oracle.com> <56AF4F4C.4030504@oracle.com> <56B00B8B.9040102@oracle.com> <56B47579.3090309@oracle.com> <56B4FA0A.3080505@oracle.com> Message-ID: <56B60EE4.2070501@oracle.com> On 2/5/2016 11:37 AM, Jim Graham wrote: > Hi Alexandr, > > awt_DesktopProperties.cpp, line 300 - is the "1.0f /" a typo? Sorry. Here is the updated fix without the typo: http://cr.openjdk.java.net/~alexsch/8076545/webrev.06/ > > Also, is there a still a need for the setFontProperty() variants that > don't have a scale as the last parameter? There are fonts like win.ansiFixed.font, win.ansiVar.font, and win.deviceDefault.font which size is the same for any display DPI. And there are fonts like win.oemFixed.font, win.system.font, and win.systemFixed.font which have one size for DPI 96 and another size for all other DPI. For example win.oemFixed.font: DPI 96, size: 12 DPI 144, size: 18 DPI 192, size: 18 DPI 240, size: 18 I left them unscaled but may be it is better to have one precalculated scale for this fonts which is used when DPI is not 96. I updated the setFontProperty() method without scale parameter usage to call with scale 1.0f. Thanks, Alexandr. > > ...jim > > On 2/5/2016 2:12 AM, Alexandr Scherbatiy wrote: >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8076545/webrev.05 >> >> - The awt_DesktopProperties.cpp file is updated to use scaleX for >> width rescaling and scaleY for height rescaling >> >> Thanks, >> Alexandr. >> >> On 2/1/2016 5:51 PM, Jim Graham wrote: >>> Hi Alexandr, >>> >>> In awt_DesktopProperties.cpp you are using the Y scaling factor to >>> scale widths still - see lines 287 (and others in that same function) >>> and then 322 in another function. It looks like you'll need >>> getInvScaleX() and getInvScaleY(). >>> >>> I'll leave it to Phil to comment on the unit test... >>> >>> ...jim >>> >>> On 2/1/16 4:27 AM, Alexandr Scherbatiy wrote: >>>> >>>> Could you review the updated fix: >>>> http://cr.openjdk.java.net/~alexsch/8076545/webrev.04/ >>>> >>>> - both LOGPIXELSX and Y are used for the theme size scaling. >>>> - LOGPIXELSY is used for text metrics height rescaling >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 1/29/2016 1:16 PM, Jim Graham wrote: >>>>> Hi Alexandr, >>>>> >>>>> Thanks for investigating the behaviors. >>>>> >>>>> With respect to using LOGPIXELSX or Y, these methods are used to >>>>> scale >>>>> both horizontal and vertical measurements so we really should have 2 >>>>> scale values and rescale methods, one for horizontal use and one for >>>>> vertical... >>>>> >>>>> ...jim >>>>> >>>>> On 1/29/2016 10:41 AM, Alexandr Scherbatiy wrote: >>>>>> Could you review the updated fix: >>>>>> http://cr.openjdk.java.net/~alexsch/8076545/webrev.03 >>>>>> >>>>>> - LOGPIXELSX is changed to LOGPIXELSY >>>>>> >>>>>> On 11/16/2015 1:43 PM, Jim Graham wrote: >>>>>>> Note that LOGPIXELSY is global and static between reboots so it >>>>>>> doesn't really matter which monitor is used to get the value. >>>>>>> >>>>>>> Also, the issue is that the measurements are in pixels, so if we >>>>>>> convert them into a resolution independent measurement then the >>>>>>> rest >>>>>>> of the scaling in the AWT/2D will be correct regardless of any >>>>>>> given >>>>>>> monitor's resolution. We just have to make sure the >>>>>>> "de-pixelization" >>>>>>> of the measurement is an apples-to-apples calculation. >>>>>>> >>>>>>> The question in my mind is whether the values they get from >>>>>>> GetTheme*() and SPI_GETNONCLIENTMETRICS are relative to >>>>>>> LOGPIXELSY, or >>>>>>> the more recent Per-Monitor aware DPI APIs, or ...? It would be >>>>>>> interesting to see what happens to those values when you change the >>>>>>> DPI settings on Windows 8.1 and not reboot. If they stay constant >>>>>>> until you reboot then LOGPIXELSY on the main screen would be the >>>>>>> value >>>>>>> to use to de-scale them... >>>>>> >>>>>> I tried to use the "Change the size of all items" slider on >>>>>> Windows >>>>>> 8.1 without rebooting. >>>>>> GetDpiForMonitor() returns the updated DPI values: 192, 144, 96 >>>>>> LOGPIXELSY returns unchanged values: 192, 192, 192 >>>>>> SystemParametersInfo(SPI_GETNONCLIENTMETRICS,...) returns >>>>>> unchanged >>>>>> NONCLIENTMETRICS >>>>>> GetThemePartSize() returns unchanged theme part sizes >>>>>> >>>>>> It seems that theme part sizes behave in the same way as the >>>>>> LOGPIXELSY in this case. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>>> >>>>>>> ...jim >>>>>>> >>>>>>> On 11/16/2015 12:51 PM, Phil Race wrote: >>>>>>>> That seems better. But one more question to get a point clarified. >>>>>>>> You are using getDesktopWindow() which is for the primary monitor. >>>>>>>> I assume that the 'inversion' results in the value being used >>>>>>>> to be >>>>>>>> independent >>>>>>>> of the monitor in a multi-mon situation and so when we move to >>>>>>>> a 2nd >>>>>>>> monitor >>>>>>>> that inverted size remains valid ? >>>>>>>> >>>>>>>> If so looks good to me. >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> On 11/16/2015 06:07 AM, Alexander Scherbatiy wrote: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Could you review the updated fix: >>>>>>>>> http://cr.openjdk.java.net/~alexsch/8076545/webrev.02 >>>>>>>>> >>>>>>>>> - round is used instead of ceil >>>>>>>>> - inverted scales are used >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/30/2015 10:40 PM, Jim Graham wrote: >>>>>>>>>> In this case round may be better. ceil() is more for cases >>>>>>>>>> where you >>>>>>>>>> needed "at least X amount of room", but I don't think a font >>>>>>>>>> size is >>>>>>>>>> an "at least this much" kind of case. >>>>>>>>>> >>>>>>>>>> Also, I've been toying with the idea that use of ceil() and >>>>>>>>>> floor() >>>>>>>>>> in any DPI-adjustment equations should really be "ceil(val - >>>>>>>>>> epsilon)" or "floor(ceil + epsilon)" for some small value of >>>>>>>>>> epsilon >>>>>>>>>> chosen just large enough to prevent various round-off errors >>>>>>>>>> from >>>>>>>>>> affecting the outcome. One idea is for 1/256 as the value of >>>>>>>>>> epsilon >>>>>>>>>> since that could equate to the smallest measurable difference in >>>>>>>>>> terms of alpha or interpolation results (or 1/512 for "half the >>>>>>>>>> smallest quantum")... >>>>>>>>>> >>>>>>>>>> ...jim >>>>>>>>>> >>>>>>>>>> On 10/29/15 1:36 PM, Phil Race wrote: >>>>>>>>>>> size->cx = (int)ceil(size->cx / scale); >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> So if size->cx / scale works out to be 12.0001 you will round >>>>>>>>>>> it up >>>>>>>>>>> to 13? >>>>>>>>>>> >>>>>>>>>>> Can you check what pixel size windows gives you in such a >>>>>>>>>>> case ? >>>>>>>>>>> I'd be a little surprised if they did that rather than round. >>>>>>>>>>> >>>>>>>>>>> Is the SetFontProperty that does not accept a scale parameter >>>>>>>>>>> still >>>>>>>>>>> used >>>>>>>>>>> somewhere ? >>>>>>>>>>> >>>>>>>>>>> -phil. >>>>>>>>>>> >>>>>>>>>>> On 10/29/2015 04:53 AM, Sergey Bylokhov wrote: >>>>>>>>>>>> On 17.07.15 16:27, Alexander Scherbatiy wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> - Sergey's point about multi-mon should be checked out. >>>>>>>>>>>>> Windows 8.1 has option "Let me choose one scaling level >>>>>>>>>>>>> for >>>>>>>>>>>>> all my >>>>>>>>>>>>> displays". >>>>>>>>>>>>> If I unset it I am able to change the size of all items. >>>>>>>>>>>>> However, >>>>>>>>>>>>> the DPI which returns GetDPIForMonitor is still 2 on HiDPI >>>>>>>>>>>>> displays. >>>>>>>>>>>> >>>>>>>>>>>> This version looks fine, but I am sure it can be double >>>>>>>>>>>> checked on >>>>>>>>>>>> windows 10 at some moment as well. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>> >> From alexandr.scherbatiy at oracle.com Sat Feb 6 15:28:47 2016 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Sat, 6 Feb 2016 19:28:47 +0400 Subject: [OpenJDK 2D-Dev] [9] Review request for 8142966 Wrong cursor position in text components on HiDPI display In-Reply-To: <56B4FA69.9000604@oracle.com> References: <56A935F0.5060504@oracle.com> <56B4FA69.9000604@oracle.com> Message-ID: <56B6112F.1050708@oracle.com> On 05/02/16 23:39, Phil Race wrote: > Two things strike me when I read this > > 1) Initial surprise at how deep into the font code it goes. > Perhaps there are alternatives. > > 2) That it changes to using the linear metrics for measuring advance. > Regardless of (1) I do not think (2) is correct. I am fairly sure this > will lead to changes in text advance. It seems like it must throw > away adjusted metrics as a result of glyph hinting. > > I don't know what the fix should be, since I have not looked at the > problem top-down, I am just seeing the bottom-up proposed solution. > So all I can say for now is that it needs to be at least somewhat > different. There was the same issue on Mac OS X which has been fixed in the similar way: 8013569 [macosx] JLabel preferred size incorrect on retina displays with non-default font size https://bugs.openjdk.java.net/browse/JDK-8013569 http://cr.openjdk.java.net/~serb/7190349/webrev.04/ The problem is that in many case for UI scale 2 we return to a user an unscaled value. But a value for transformed glyph advance, rounded and descaled can differ from just rounded glyph advance. For example, font[dialog, plain, 12] char 'a': transform: 12, advance: 7.35, rounded advance: 8 transform: 24, advance: 14.70 round advance: 14 and 8 does not equal 14 / 2. The solution for Mac OS X was to get the glyph advance using only font transform, round it and then apply the dev transform: CGGlyphImages.m: 481 advance = CGSizeApplyAffineTransform(advance, strike->fFontTx); 482 if (!JRSFontStyleUsesFractionalMetrics(strike->fStyle)) { 483 advance.width = round(advance.width); 484 advance.height = round(advance.height); 485 } 486 advance = CGSizeApplyAffineTransform(advance, strike->fDevTx); Thanks, Alexandr. > > -phil. > > On 01/27/2016 01:26 PM, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8142966 >> webrev: http://cr.openjdk.java.net/~alexsch/8142966/webev.00/ >> >> The proposed fix rounds a glyph advance first and then scales it if >> UI scales do not equal to one. >> >> Thanks, >> Alexandr. >> > From Sergey.Bylokhov at oracle.com Sun Feb 7 20:37:34 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sun, 7 Feb 2016 23:37:34 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8146042 Offscreen rendering is different from onscreen one In-Reply-To: <56AF2412.3040905@oracle.com> References: <5697E44B.2040100@oracle.com> <5697E7B1.2080207@oracle.com> <569898C4.1030404@oracle.com> <5698F46A.5020809@oracle.com> <5699025C.7030904@oracle.com> <5699143A.4070408@oracle.com> <56992111.9000501@oracle.com> <5699603C.6000200@oracle.com> <569E1E4E.9080309@oracle.com> <56A0E584.3050204@oracle.com> <56AF2412.3040905@oracle.com> Message-ID: <56B7AB0E.9000705@oracle.com> On 01.02.16 12:23, Semyon Sadetsky wrote: > > > On 1/21/2016 5:04 PM, Sergey Bylokhov wrote: >> On 19/01/16 14:30, Semyon Sadetsky wrote: >>> We are getting error because of incorrect fudge factor added to the "to" >>> line coordinates (for line from - to). >>> See the updated version of the fix in which test should work on OS X: >>> http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.02/ >>> Test fails on my mac book-pro with integrated i7 GPU - rectangle is >>> drawn at wrong position. >> >> It will fail on any hdpi systems(including osx+retina), The reason is >> that: when you create a VolatileImage it will take into account >> default transform of the GraphicsConfiguration(on hdpi systems it will >> be x2). When you draw a line to this VI and then take s spapshot then >> you convert the big VI image to the small BI. you need to take into >> account this scale and draw VI to BI 1-2-1, something like this: >> BufferedImage capture = new BufferedImage(12x2, 12x2, >> BufferedImage.TYPE_4BYTE_ABGR_PRE); >> capture.createGraphics().drawImage(vi,0,0,12x2,12x2,null); >> >> Note that even in this case the line locations check is incorrect and >> should be adjusted. > I tried what you've proposed. The position of the up-scaled image is > wrong as well 1-21 instead of 2-22. Why wrong? this is correct result, the simple BufferedImage will produce the same: BufferedImage bi = new BufferedImage(12*2, 12*2, BufferedImage.TYPE_INT_ARGB_PRE); Graphics2D g1 = bi.createGraphics(); g1.scale(2,2); g1.setColor(Color.black); g1.drawRect(1, 1, 9, 9); g1.dispose(); ImageIO.write(bi,"png",new File("gold.png")); When you draw a line you set the middle point of the line, not the left point. So the x=1px when scaled will cover the pixels 1 and 2, not the 2 and 3. > I think test may be remained the same. >> >> >>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> --Semyon >>>>>>>>> >>>>>>>>> On 1/14/2016 9:23 PM, Phil Race wrote: >>>>>>>>>> This fudge factor was last adjusted in >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6597822 >>>>>>>>>> way back before the D3D pipeline was released and the comments >>>>>>>>>> seem to >>>>>>>>>> indicate that >>>>>>>>>> there was a fair amount of testing on different hardware. >>>>>>>>>> >>>>>>>>>> I don't know why this seems to be in un-specified >>>>>>>>>> hardware-dependent >>>>>>>>>> territory but >>>>>>>>>> it seems quite possible that this could just as easily >>>>>>>>>> introduce a >>>>>>>>>> different artifact >>>>>>>>>> on some other hardware. >>>>>>>>>> >>>>>>>>>> What exactly are you testing on ? And I think it needs to >>>>>>>>>> include at >>>>>>>>>> least one Nvidia >>>>>>>>>> and one AMD/ATI card. >>>>>>>>>> >>>>>>>>>> -phil. >>>>>>>>>> >>>>>>>>>> On 1/14/2016 10:09 AM, Semyon Sadetsky wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> Please review the fix for jdk9. >>>>>>>>>>> >>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8146042 >>>>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> The root cause is incorrect coordinate rounding in D3D >>>>>>>>>>> renderer. To >>>>>>>>>>> fix the issue one of fudge factors was adjusted. >>>>>>>>>>> >>>>>>>>>>> Another issue mentioning in the JIRA ticket is taken out as a >>>>>>>>>>> separate bug. >>>>>>>>>>> >>>>>>>>>>> --Semyon >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > -- Best regards, Sergey. From semyon.sadetsky at oracle.com Mon Feb 8 07:56:27 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 8 Feb 2016 10:56:27 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8146042 Offscreen rendering is different from onscreen one In-Reply-To: <56B7AB0E.9000705@oracle.com> References: <5697E44B.2040100@oracle.com> <5697E7B1.2080207@oracle.com> <569898C4.1030404@oracle.com> <5698F46A.5020809@oracle.com> <5699025C.7030904@oracle.com> <5699143A.4070408@oracle.com> <56992111.9000501@oracle.com> <5699603C.6000200@oracle.com> <569E1E4E.9080309@oracle.com> <56A0E584.3050204@oracle.com> <56AF2412.3040905@oracle.com> <56B7AB0E.9000705@oracle.com> Message-ID: <56B84A2B.9030102@oracle.com> On 2/7/2016 11:37 PM, Sergey Bylokhov wrote: > On 01.02.16 12:23, Semyon Sadetsky wrote: >> >> >> On 1/21/2016 5:04 PM, Sergey Bylokhov wrote: >>> On 19/01/16 14:30, Semyon Sadetsky wrote: >>>> We are getting error because of incorrect fudge factor added to the >>>> "to" >>>> line coordinates (for line from - to). >>>> See the updated version of the fix in which test should work on OS X: >>>> http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.02/ >>>> Test fails on my mac book-pro with integrated i7 GPU - rectangle is >>>> drawn at wrong position. >>> >>> It will fail on any hdpi systems(including osx+retina), The reason is >>> that: when you create a VolatileImage it will take into account >>> default transform of the GraphicsConfiguration(on hdpi systems it will >>> be x2). When you draw a line to this VI and then take s spapshot then >>> you convert the big VI image to the small BI. you need to take into >>> account this scale and draw VI to BI 1-2-1, something like this: >>> BufferedImage capture = new BufferedImage(12x2, 12x2, >>> BufferedImage.TYPE_4BYTE_ABGR_PRE); >>> capture.createGraphics().drawImage(vi,0,0,12x2,12x2,null); >>> >>> Note that even in this case the line locations check is incorrect and >>> should be adjusted. >> I tried what you've proposed. The position of the up-scaled image is >> wrong as well 1-21 instead of 2-22. > > Why wrong? this is correct result, the simple BufferedImage will > produce the same: > BufferedImage bi = new BufferedImage(12*2, 12*2, > BufferedImage.TYPE_INT_ARGB_PRE); > Graphics2D g1 = bi.createGraphics(); > g1.scale(2,2); > g1.setColor(Color.black); > g1.drawRect(1, 1, 9, 9); > g1.dispose(); > ImageIO.write(bi,"png",new File("gold.png")); > > When you draw a line you set the middle point of the line, not the > left point. So the x=1px when scaled will cover the pixels 1 and 2, > not the 2 and 3. No, the correct will be 2 and 3. In the small image 0 is white and 1 is black. In its 2x-upscaled variant 0 and 1 are white and 2 and 3 are black. The resulting rectangle should be centered in the image but it is shifted to left top corner by 1px. > >> I think test may be remained the same. >>> >>> >>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> --Semyon >>>>>>>>>> >>>>>>>>>> On 1/14/2016 9:23 PM, Phil Race wrote: >>>>>>>>>>> This fudge factor was last adjusted in >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6597822 >>>>>>>>>>> way back before the D3D pipeline was released and the comments >>>>>>>>>>> seem to >>>>>>>>>>> indicate that >>>>>>>>>>> there was a fair amount of testing on different hardware. >>>>>>>>>>> >>>>>>>>>>> I don't know why this seems to be in un-specified >>>>>>>>>>> hardware-dependent >>>>>>>>>>> territory but >>>>>>>>>>> it seems quite possible that this could just as easily >>>>>>>>>>> introduce a >>>>>>>>>>> different artifact >>>>>>>>>>> on some other hardware. >>>>>>>>>>> >>>>>>>>>>> What exactly are you testing on ? And I think it needs to >>>>>>>>>>> include at >>>>>>>>>>> least one Nvidia >>>>>>>>>>> and one AMD/ATI card. >>>>>>>>>>> >>>>>>>>>>> -phil. >>>>>>>>>>> >>>>>>>>>>> On 1/14/2016 10:09 AM, Semyon Sadetsky wrote: >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> Please review the fix for jdk9. >>>>>>>>>>>> >>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8146042 >>>>>>>>>>>> webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> The root cause is incorrect coordinate rounding in D3D >>>>>>>>>>>> renderer. To >>>>>>>>>>>> fix the issue one of fudge factors was adjusted. >>>>>>>>>>>> >>>>>>>>>>>> Another issue mentioning in the JIRA ticket is taken out as a >>>>>>>>>>>> separate bug. >>>>>>>>>>>> >>>>>>>>>>>> --Semyon >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From james.graham at oracle.com Mon Feb 8 19:14:56 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 8 Feb 2016 11:14:56 -0800 Subject: [OpenJDK 2D-Dev] [9] Review request for 8142966 Wrong cursor position in text components on HiDPI display In-Reply-To: <56B6112F.1050708@oracle.com> References: <56A935F0.5060504@oracle.com> <56B4FA69.9000604@oracle.com> <56B6112F.1050708@oracle.com> Message-ID: <56B8E930.9000405@oracle.com> Isn't the problem there that we are returning an integer as the advance? Why aren't we returning 7.35 as a value instead of 8? Also, shouldn't 7.35 round to 7 and 14.7 round to 15? ...jim On 2/6/2016 7:28 AM, Alexander Scherbatiy wrote: > On 05/02/16 23:39, Phil Race wrote: >> Two things strike me when I read this >> >> 1) Initial surprise at how deep into the font code it goes. >> Perhaps there are alternatives. >> >> 2) That it changes to using the linear metrics for measuring advance. >> Regardless of (1) I do not think (2) is correct. I am fairly sure this >> will lead to changes in text advance. It seems like it must throw >> away adjusted metrics as a result of glyph hinting. >> >> I don't know what the fix should be, since I have not looked at the >> problem top-down, I am just seeing the bottom-up proposed solution. >> So all I can say for now is that it needs to be at least somewhat >> different. > > There was the same issue on Mac OS X which has been fixed in the > similar way: > 8013569 [macosx] JLabel preferred size incorrect on retina displays > with non-default font size > https://bugs.openjdk.java.net/browse/JDK-8013569 > http://cr.openjdk.java.net/~serb/7190349/webrev.04/ > > The problem is that in many case for UI scale 2 we return to a user > an unscaled value. > But a value for transformed glyph advance, rounded and descaled can > differ from just rounded glyph advance. > > For example, font[dialog, plain, 12] char 'a': > transform: 12, advance: 7.35, rounded advance: 8 > transform: 24, advance: 14.70 round advance: 14 > > and 8 does not equal 14 / 2. > > The solution for Mac OS X was to get the glyph advance using only > font transform, round it and then apply the dev transform: > > CGGlyphImages.m: > 481 advance = CGSizeApplyAffineTransform(advance, strike->fFontTx); > 482 if (!JRSFontStyleUsesFractionalMetrics(strike->fStyle)) { > 483 advance.width = round(advance.width); > 484 advance.height = round(advance.height); > 485 } > 486 advance = CGSizeApplyAffineTransform(advance, strike->fDevTx); > > Thanks, > Alexandr. >> >> -phil. >> >> On 01/27/2016 01:26 PM, Alexander Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the fix: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8142966 >>> webrev: http://cr.openjdk.java.net/~alexsch/8142966/webev.00/ >>> >>> The proposed fix rounds a glyph advance first and then scales it if >>> UI scales do not equal to one. >>> >>> Thanks, >>> Alexandr. >>> >> > From philip.race at oracle.com Mon Feb 8 20:40:01 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 08 Feb 2016 12:40:01 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8051519 Message-ID: <56B8FD21.9070907@oracle.com> Bug : https://bugs.openjdk.java.net/browse/JDK-8051519 This internal AP being deprecated in preparation for removal in JDK 10. Ordinarily we would remove it directly but it is known to be used by non-JDK code, hence the deprecation. CCC approval is already obtained diff in-line below diff --git a/src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java b/src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java --- a/src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java +++ b/src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java @@ -208,8 +208,7 @@ * to use Mincho instead of Gothic for dialoginput in JA locales * on windows. Not needed on other platforms. * - * DO NOT MOVE OR RENAME OR OTHERWISE ALTER THIS METHOD. - * ITS USED BY SOME NON-JRE INTERNAL CODE. + * @deprecated as of JDK9. To be removed in a future release. */ public static void useAlternateFontforJALocales() { getFontManagerForSGE().useAlternateFontforJALocales(); -phil. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Feb 8 20:44:38 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 08 Feb 2016 12:44:38 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8051519: Deprecate sun.java2d.SunGraphicsEnvironment.useAlternateFontforJALocales In-Reply-To: <56B8FD21.9070907@oracle.com> References: <56B8FD21.9070907@oracle.com> Message-ID: <56B8FE36.60204@oracle.com> Adding missing bug synopsis to the subject line. -phil. On 02/08/2016 12:40 PM, Phil Race wrote: > Bug : https://bugs.openjdk.java.net/browse/JDK-8051519 > This internal AP being deprecated in preparation for removal in JDK 10. > Ordinarily we would remove it directly but it is known to be used by > non-JDK code, hence the deprecation. CCC approval is already obtained > > diff in-line below > > diff --git > a/src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java b/src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java > --- > a/src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java > +++ > b/src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java > @@ -208,8 +208,7 @@ > * to use Mincho instead of Gothic for dialoginput in JA locales > * on windows. Not needed on other platforms. > * > - * DO NOT MOVE OR RENAME OR OTHERWISE ALTER THIS METHOD. > - * ITS USED BY SOME NON-JRE INTERNAL CODE. > + * @deprecated as of JDK9. To be removed in a future release. > */ > public static void useAlternateFontforJALocales() { > getFontManagerForSGE().useAlternateFontforJALocales(); > > -phil. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bourges.laurent at gmail.com Mon Feb 8 20:58:35 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Mon, 8 Feb 2016 21:58:35 +0100 Subject: [OpenJDK 2D-Dev] RFR 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering In-Reply-To: References: <56B3F68F.3070204@oracle.com> <56B3F8C3.7040609@oracle.com> Message-ID: Jim & Phil, I updated my previous webrev to have MarlinRenderingEngine TL/CLQ more close to the new proposed approach in AAShapePipe (and looks simpler): http://cr.openjdk.java.net/~lbourges/marlin/marlin-8148886.2/ Please give me your comments on my previous email. Cheers, Laurent 2016-02-06 0:21 GMT+01:00 Laurent Bourg?s : > Jim & Phil, > > Here is an updated webrev according to jim's comments: > http://cr.openjdk.java.net/~lbourges/marlin/marlin-8148886.1/ > > Changes: > - AAShapePipe rewritten to use a new ReentrantThreadLocal class > (generalization) that use TL + CLQ (like Marlin) to use other (cached) > TileState instances in case of reentrancy; such class may be useful for > other use cases (replacing synchronized / static refs); it do not use > WeakReference as TileState instances are very small (to be improved later ?) > - Improved CrashPaintTest to check few pixel values to ensure rendering is > correct > > PS: I noticed that AlphaPaintPipe has a constant int TILE_SIZE = 32 that > seems useless as the method has a tilesize argument; maybe it should be > cleaned up ? > > Regards, > Laurent > > 2016-02-05 2:20 GMT+01:00 Jim Graham : > >> Ah, at least one error spotted here after my initial review... >> >> The abox values could be changed by the code in lines 157-160 so you >> can't cache their values until after that. >> >> Also, as you pointed out in another thread in the grdev group, we should >> probably do the same treatment for the TileState in case we have reentrance >> for the AAShapePipe code... >> >> ...jim >> >> >> On 2/4/2016 5:10 PM, Jim Graham wrote: >> >>> Hi Laurent, >>> >>> In AAShapePipe you load the values from abox[] into variables named >>> xywh, but these are not xywh values, they are min/max values. We >>> typically use any of the following naming conventions for these types of >>> values: >>> >>> - x0, y0, x1, y1 >>> - x1, y1, x2, y2 >>> - minX, minY, maxX, maxY >>> >>> Other than that naming inconsistency the changes look great... >>> >>> ...jim >>> >>> On 2/4/2016 2:21 PM, Laurent Bourg?s wrote: >>> >>>> Please review the webrev fixing SEGFAULT (P2) in the Marlin Renderer >>>> when using thread-local storage with custom Paint (reentrance): >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8148886 >>>> webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8148886.0/ >>>> >>>> Changes: >>>> - detect reentrance in MarlinRenderingEngine using flag >>>> RendererContext.usedTL (true/false) and use another context from CLQ >>>> - added few more details in array checks (XXXArrayCache) >>>> - fixed AAShapePipe to support reentrancy: added defensive copy of int[] >>>> abox in local variables + TODO to discuss >>>> - updated Version to 0.7.3.2 >>>> - fixed copyright headers >>>> >>>> Best regards, >>>> Laurent >>>> >>> > > > -- > -- > Laurent Bourg?s > -- -- Laurent Bourg?s -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Mon Feb 8 21:15:15 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 8 Feb 2016 13:15:15 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8051519 In-Reply-To: <56B8FD21.9070907@oracle.com> References: <56B8FD21.9070907@oracle.com> Message-ID: > On Feb 8, 2016, at 12:40 PM, Phil Race wrote: > > Bug : https://bugs.openjdk.java.net/browse/JDK-8051519 > This internal AP being deprecated in preparation for removal in JDK 10. > Ordinarily we would remove it directly but it is known to be used by > non-JDK code, hence the deprecation. CCC approval is already obtained > > diff in-line below > > diff --git a/src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java b/src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java > --- a/src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java > +++ b/src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java > @@ -208,8 +208,7 @@ > * to use Mincho instead of Gothic for dialoginput in JA locales > * on windows. Not needed on other platforms. > * > - * DO NOT MOVE OR RENAME OR OTHERWISE ALTER THIS METHOD. > - * ITS USED BY SOME NON-JRE INTERNAL CODE. > + * @deprecated as of JDK9. To be removed in a future release. > */ > public static void useAlternateFontforJALocales() { > getFontManagerForSGE().useAlternateFontforJALocales(); > Do you want to annotate the method with @Deprecated to make it clear and also users of this internal API will get compiler warning? FWIW. When compiled with javac with module system integrated, they will get compilation error anyway. Since the javadoc has @deprecated, annotating with @Deprecated makes it clear. Mandy From bourges.laurent at gmail.com Mon Feb 8 21:22:45 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Mon, 8 Feb 2016 22:22:45 +0100 Subject: [OpenJDK 2D-Dev] RFR 8149338: JVM Crash caused by Marlin renderer not handling NaN coordinates Message-ID: Phil & Jim, Please review a simple fix for a SEGV in Marlin renderer due to NaN coordinates: bug: https://bugs.openjdk.java.net/browse/JDK-8149338 webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8149338.0/ Changes: - addLine: use first / last Y crossings to compute edge min/max Y that ensures consistency with edgeBuckets / edgeBucketCounts arrays in case of NaN values: it is used in dispose() to reset these critical arrays (pointer-like) => robust and consistent zero-fill - minor cleanup in closePath() to avoid upscaling coordinates - added crash test Cheers, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Mon Feb 8 22:33:48 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 8 Feb 2016 14:33:48 -0800 Subject: [OpenJDK 2D-Dev] RFR 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering In-Reply-To: References: <56B3F68F.3070204@oracle.com> <56B3F8C3.7040609@oracle.com> Message-ID: <56B917CC.5090806@oracle.com> You might want to separate the new ReentrantTL class into a separate file in sun.java2d so it can be used in other places. What are the hurdles for using it in Marlin instead of rolling its own? If it is going to be reused it might be better to represent the ReentrantContext class as an interface so that objects with pre-determined super-class hierarchies can still participate. TILE_SIZE is probably mostly obsolete now, but that's fodder for some other work. Also, 32 may not be the best choice to use when we aren't using Ductus, but currently D3D can only accept 32 so there is work to be done before that is really configurable. MarlinRenderingEngine line 182 - testing useThreadLocal is redundant/irrelevant here, checking the queue variable should be enough. ReentrantThreadLocal - depth is a poor name for that field. Perhaps usage? With "*_TL_INACTIVE", "*_TL_IN_USE", and "*_CLQ" being the variants? AAShapePipe line 297 - should it double check that the level is DEPTH_CLQ? Otherwise someone can submit an undefined TL object for restore() and it will end up in the queue... ...jim On 2/5/16 3:21 PM, Laurent Bourg?s wrote: > Jim & Phil, > > Here is an updated webrev according to jim's comments: > http://cr.openjdk.java.net/~lbourges/marlin/marlin-8148886.1/ > > Changes: > - AAShapePipe rewritten to use a new ReentrantThreadLocal class > (generalization) that use TL + CLQ (like Marlin) to use other (cached) > TileState instances in case of reentrancy; such class may be useful for > other use cases (replacing synchronized / static refs); it do not use > WeakReference as TileState instances are very small (to be improved later ?) > - Improved CrashPaintTest to check few pixel values to ensure rendering > is correct > > PS: I noticed that AlphaPaintPipe has a constant int TILE_SIZE = 32 that > seems useless as the method has a tilesize argument; maybe it should be > cleaned up ? > > Regards, > Laurent > > 2016-02-05 2:20 GMT+01:00 Jim Graham >: > > Ah, at least one error spotted here after my initial review... > > The abox values could be changed by the code in lines 157-160 so you > can't cache their values until after that. > > Also, as you pointed out in another thread in the grdev group, we > should probably do the same treatment for the TileState in case we > have reentrance for the AAShapePipe code... > > ...jim > > > On 2/4/2016 5:10 PM, Jim Graham wrote: > > Hi Laurent, > > In AAShapePipe you load the values from abox[] into variables named > xywh, but these are not xywh values, they are min/max values. We > typically use any of the following naming conventions for these > types of > values: > > - x0, y0, x1, y1 > - x1, y1, x2, y2 > - minX, minY, maxX, maxY > > Other than that naming inconsistency the changes look great... > > ...jim > > On 2/4/2016 2:21 PM, Laurent Bourg?s wrote: > > Please review the webrev fixing SEGFAULT (P2) in the Marlin > Renderer > when using thread-local storage with custom Paint (reentrance): > bug: https://bugs.openjdk.java.net/browse/JDK-8148886 > webrev: > http://cr.openjdk.java.net/~lbourges/marlin/marlin-8148886.0/ > > Changes: > - detect reentrance in MarlinRenderingEngine using flag > RendererContext.usedTL (true/false) and use another context > from CLQ > - added few more details in array checks (XXXArrayCache) > - fixed AAShapePipe to support reentrancy: added defensive > copy of int[] > abox in local variables + TODO to discuss > - updated Version to 0.7.3.2 > - fixed copyright headers > > Best regards, > Laurent > > > > > -- > -- > Laurent Bourg?s From james.graham at oracle.com Mon Feb 8 22:35:53 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 8 Feb 2016 14:35:53 -0800 Subject: [OpenJDK 2D-Dev] RFR 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering In-Reply-To: References: <56B3F68F.3070204@oracle.com> <56B3F8C3.7040609@oracle.com> Message-ID: <56B91849.4090509@oracle.com> These changes look fine, but my previous comments remain... ...jim On 2/8/16 12:58 PM, Laurent Bourg?s wrote: > Jim & Phil, > > I updated my previous webrev to have MarlinRenderingEngine TL/CLQ more > close to the new proposed approach in AAShapePipe (and looks simpler): > http://cr.openjdk.java.net/~lbourges/marlin/marlin-8148886.2/ > > Please give me your comments on my previous email. > > Cheers, > Laurent > > > 2016-02-06 0:21 GMT+01:00 Laurent Bourg?s >: > > Jim & Phil, > > Here is an updated webrev according to jim's comments: > http://cr.openjdk.java.net/~lbourges/marlin/marlin-8148886.1/ > > Changes: > - AAShapePipe rewritten to use a new ReentrantThreadLocal class > (generalization) that use TL + CLQ (like Marlin) to use other > (cached) TileState instances in case of reentrancy; such class may > be useful for other use cases (replacing synchronized / static > refs); it do not use WeakReference as TileState instances are very > small (to be improved later ?) > - Improved CrashPaintTest to check few pixel values to ensure > rendering is correct > > PS: I noticed that AlphaPaintPipe has a constant int TILE_SIZE = 32 > that seems useless as the method has a tilesize argument; maybe it > should be cleaned up ? > > Regards, > Laurent > > 2016-02-05 2:20 GMT+01:00 Jim Graham >: > > Ah, at least one error spotted here after my initial review... > > The abox values could be changed by the code in lines 157-160 so > you can't cache their values until after that. > > Also, as you pointed out in another thread in the grdev group, > we should probably do the same treatment for the TileState in > case we have reentrance for the AAShapePipe code... > > ...jim > > > On 2/4/2016 5:10 PM, Jim Graham wrote: > > Hi Laurent, > > In AAShapePipe you load the values from abox[] into > variables named > xywh, but these are not xywh values, they are min/max > values. We > typically use any of the following naming conventions for > these types of > values: > > - x0, y0, x1, y1 > - x1, y1, x2, y2 > - minX, minY, maxX, maxY > > Other than that naming inconsistency the changes look great... > > ...jim > > On 2/4/2016 2:21 PM, Laurent Bourg?s wrote: > > Please review the webrev fixing SEGFAULT (P2) in the > Marlin Renderer > when using thread-local storage with custom Paint > (reentrance): > bug: https://bugs.openjdk.java.net/browse/JDK-8148886 > webrev: > http://cr.openjdk.java.net/~lbourges/marlin/marlin-8148886.0/ > > Changes: > - detect reentrance in MarlinRenderingEngine using flag > RendererContext.usedTL (true/false) and use another > context from CLQ > - added few more details in array checks (XXXArrayCache) > - fixed AAShapePipe to support reentrancy: added > defensive copy of int[] > abox in local variables + TODO to discuss > - updated Version to 0.7.3.2 > - fixed copyright headers > > Best regards, > Laurent > > > > > -- > -- > Laurent Bourg?s > > > > > -- > -- > Laurent Bourg?s From james.graham at oracle.com Mon Feb 8 23:04:50 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 8 Feb 2016 15:04:50 -0800 Subject: [OpenJDK 2D-Dev] [9] Review request for 8076545 Text size is twice bigger under Windows L&F on Win 8.1 with HiDPI display In-Reply-To: <56B60EE4.2070501@oracle.com> References: <5596C117.1040806@oracle.com> <559DB2FB.5000208@oracle.com> <55A902D4.1050603@oracle.com> <563208A9.50702@oracle.com> <56328355.1010608@oracle.com> <5633C7C8.2030804@oracle.com> <5649E312.2010606@oracle.com> <564A41D3.5010202@oracle.com> <564A4DE9.1040102@oracle.com> <56ABB269.6030808@oracle.com> <56ABD6B2.10302@oracle.com> <56AF4F4C.4030504@oracle.com> <56B00B8B.9040102@oracle.com> <56B47579.3090309@oracle.com> <56B4FA0A.3080505@oracle.com> <56B60EE4.2070501@oracle.com> Message-ID: <56B91F12.9070909@oracle.com> I don't understand the issue with the fonts that you are saying have different sizes for different DPIs. Those are pixel sizes, aren't they? They still need to be turned into user-space units for our applications to know what to do with them. Or, are you saying that they are not representing pixel sizes as the rest of the font units do and so they are already in DPI-relative "user space" units? AT 192 DPI, oemFixed.font is 18, but are they saying 18 pixels? Which would be a 9-point font in our automatically scaled coordinate systems, wouldn't it? ...jim On 2/6/16 7:19 AM, Alexander Scherbatiy wrote: > On 2/5/2016 11:37 AM, Jim Graham wrote: >> Hi Alexandr, >> >> awt_DesktopProperties.cpp, line 300 - is the "1.0f /" a typo? > Sorry. Here is the updated fix without the typo: > http://cr.openjdk.java.net/~alexsch/8076545/webrev.06/ >> >> Also, is there a still a need for the setFontProperty() variants that >> don't have a scale as the last parameter? > There are fonts like win.ansiFixed.font, win.ansiVar.font, and > win.deviceDefault.font which size is the same for any display DPI. > > And there are fonts like win.oemFixed.font, win.system.font, and > win.systemFixed.font which have one size for DPI 96 and another size for > all other DPI. > For example win.oemFixed.font: > DPI 96, size: 12 > DPI 144, size: 18 > DPI 192, size: 18 > DPI 240, size: 18 > > I left them unscaled but may be it is better to have one > precalculated scale for this fonts which is used when DPI is not 96. > > I updated the setFontProperty() method without scale parameter usage > to call with scale 1.0f. > > Thanks, > Alexandr. > >> >> ...jim >> >> On 2/5/2016 2:12 AM, Alexandr Scherbatiy wrote: >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8076545/webrev.05 >>> >>> - The awt_DesktopProperties.cpp file is updated to use scaleX for >>> width rescaling and scaleY for height rescaling >>> >>> Thanks, >>> Alexandr. >>> >>> On 2/1/2016 5:51 PM, Jim Graham wrote: >>>> Hi Alexandr, >>>> >>>> In awt_DesktopProperties.cpp you are using the Y scaling factor to >>>> scale widths still - see lines 287 (and others in that same function) >>>> and then 322 in another function. It looks like you'll need >>>> getInvScaleX() and getInvScaleY(). >>>> >>>> I'll leave it to Phil to comment on the unit test... >>>> >>>> ...jim >>>> >>>> On 2/1/16 4:27 AM, Alexandr Scherbatiy wrote: >>>>> >>>>> Could you review the updated fix: >>>>> http://cr.openjdk.java.net/~alexsch/8076545/webrev.04/ >>>>> >>>>> - both LOGPIXELSX and Y are used for the theme size scaling. >>>>> - LOGPIXELSY is used for text metrics height rescaling >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 1/29/2016 1:16 PM, Jim Graham wrote: >>>>>> Hi Alexandr, >>>>>> >>>>>> Thanks for investigating the behaviors. >>>>>> >>>>>> With respect to using LOGPIXELSX or Y, these methods are used to >>>>>> scale >>>>>> both horizontal and vertical measurements so we really should have 2 >>>>>> scale values and rescale methods, one for horizontal use and one for >>>>>> vertical... >>>>>> >>>>>> ...jim >>>>>> >>>>>> On 1/29/2016 10:41 AM, Alexandr Scherbatiy wrote: >>>>>>> Could you review the updated fix: >>>>>>> http://cr.openjdk.java.net/~alexsch/8076545/webrev.03 >>>>>>> >>>>>>> - LOGPIXELSX is changed to LOGPIXELSY >>>>>>> >>>>>>> On 11/16/2015 1:43 PM, Jim Graham wrote: >>>>>>>> Note that LOGPIXELSY is global and static between reboots so it >>>>>>>> doesn't really matter which monitor is used to get the value. >>>>>>>> >>>>>>>> Also, the issue is that the measurements are in pixels, so if we >>>>>>>> convert them into a resolution independent measurement then the >>>>>>>> rest >>>>>>>> of the scaling in the AWT/2D will be correct regardless of any >>>>>>>> given >>>>>>>> monitor's resolution. We just have to make sure the >>>>>>>> "de-pixelization" >>>>>>>> of the measurement is an apples-to-apples calculation. >>>>>>>> >>>>>>>> The question in my mind is whether the values they get from >>>>>>>> GetTheme*() and SPI_GETNONCLIENTMETRICS are relative to >>>>>>>> LOGPIXELSY, or >>>>>>>> the more recent Per-Monitor aware DPI APIs, or ...? It would be >>>>>>>> interesting to see what happens to those values when you change the >>>>>>>> DPI settings on Windows 8.1 and not reboot. If they stay constant >>>>>>>> until you reboot then LOGPIXELSY on the main screen would be the >>>>>>>> value >>>>>>>> to use to de-scale them... >>>>>>> >>>>>>> I tried to use the "Change the size of all items" slider on >>>>>>> Windows >>>>>>> 8.1 without rebooting. >>>>>>> GetDpiForMonitor() returns the updated DPI values: 192, 144, 96 >>>>>>> LOGPIXELSY returns unchanged values: 192, 192, 192 >>>>>>> SystemParametersInfo(SPI_GETNONCLIENTMETRICS,...) returns >>>>>>> unchanged >>>>>>> NONCLIENTMETRICS >>>>>>> GetThemePartSize() returns unchanged theme part sizes >>>>>>> >>>>>>> It seems that theme part sizes behave in the same way as the >>>>>>> LOGPIXELSY in this case. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>>> >>>>>>>> ...jim >>>>>>>> >>>>>>>> On 11/16/2015 12:51 PM, Phil Race wrote: >>>>>>>>> That seems better. But one more question to get a point clarified. >>>>>>>>> You are using getDesktopWindow() which is for the primary monitor. >>>>>>>>> I assume that the 'inversion' results in the value being used >>>>>>>>> to be >>>>>>>>> independent >>>>>>>>> of the monitor in a multi-mon situation and so when we move to >>>>>>>>> a 2nd >>>>>>>>> monitor >>>>>>>>> that inverted size remains valid ? >>>>>>>>> >>>>>>>>> If so looks good to me. >>>>>>>>> >>>>>>>>> -phil. >>>>>>>>> >>>>>>>>> On 11/16/2015 06:07 AM, Alexander Scherbatiy wrote: >>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Could you review the updated fix: >>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8076545/webrev.02 >>>>>>>>>> >>>>>>>>>> - round is used instead of ceil >>>>>>>>>> - inverted scales are used >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 10/30/2015 10:40 PM, Jim Graham wrote: >>>>>>>>>>> In this case round may be better. ceil() is more for cases >>>>>>>>>>> where you >>>>>>>>>>> needed "at least X amount of room", but I don't think a font >>>>>>>>>>> size is >>>>>>>>>>> an "at least this much" kind of case. >>>>>>>>>>> >>>>>>>>>>> Also, I've been toying with the idea that use of ceil() and >>>>>>>>>>> floor() >>>>>>>>>>> in any DPI-adjustment equations should really be "ceil(val - >>>>>>>>>>> epsilon)" or "floor(ceil + epsilon)" for some small value of >>>>>>>>>>> epsilon >>>>>>>>>>> chosen just large enough to prevent various round-off errors >>>>>>>>>>> from >>>>>>>>>>> affecting the outcome. One idea is for 1/256 as the value of >>>>>>>>>>> epsilon >>>>>>>>>>> since that could equate to the smallest measurable difference in >>>>>>>>>>> terms of alpha or interpolation results (or 1/512 for "half the >>>>>>>>>>> smallest quantum")... >>>>>>>>>>> >>>>>>>>>>> ...jim >>>>>>>>>>> >>>>>>>>>>> On 10/29/15 1:36 PM, Phil Race wrote: >>>>>>>>>>>> size->cx = (int)ceil(size->cx / scale); >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> So if size->cx / scale works out to be 12.0001 you will round >>>>>>>>>>>> it up >>>>>>>>>>>> to 13? >>>>>>>>>>>> >>>>>>>>>>>> Can you check what pixel size windows gives you in such a >>>>>>>>>>>> case ? >>>>>>>>>>>> I'd be a little surprised if they did that rather than round. >>>>>>>>>>>> >>>>>>>>>>>> Is the SetFontProperty that does not accept a scale parameter >>>>>>>>>>>> still >>>>>>>>>>>> used >>>>>>>>>>>> somewhere ? >>>>>>>>>>>> >>>>>>>>>>>> -phil. >>>>>>>>>>>> >>>>>>>>>>>> On 10/29/2015 04:53 AM, Sergey Bylokhov wrote: >>>>>>>>>>>>> On 17.07.15 16:27, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - Sergey's point about multi-mon should be checked out. >>>>>>>>>>>>>> Windows 8.1 has option "Let me choose one scaling level >>>>>>>>>>>>>> for >>>>>>>>>>>>>> all my >>>>>>>>>>>>>> displays". >>>>>>>>>>>>>> If I unset it I am able to change the size of all items. >>>>>>>>>>>>>> However, >>>>>>>>>>>>>> the DPI which returns GetDPIForMonitor is still 2 on HiDPI >>>>>>>>>>>>>> displays. >>>>>>>>>>>>> >>>>>>>>>>>>> This version looks fine, but I am sure it can be double >>>>>>>>>>>>> checked on >>>>>>>>>>>>> windows 10 at some moment as well. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> > From james.graham at oracle.com Mon Feb 8 23:11:56 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 8 Feb 2016 15:11:56 -0800 Subject: [OpenJDK 2D-Dev] RFR 8149338: JVM Crash caused by Marlin renderer not handling NaN coordinates In-Reply-To: References: Message-ID: <56B920BC.9010407@oracle.com> Is there a reason why you reversed the calculations for the slope at line 374? ...jim On 2/8/16 1:22 PM, Laurent Bourg?s wrote: > Phil & Jim, > > Please review a simple fix for a SEGV in Marlin renderer due to NaN > coordinates: > bug: https://bugs.openjdk.java.net/browse/JDK-8149338 > webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8149338.0/ > > Changes: > - addLine: use first / last Y crossings to compute edge min/max Y that > ensures consistency with edgeBuckets / edgeBucketCounts arrays in case > of NaN values: it is used in dispose() to reset these critical arrays > (pointer-like) => robust and consistent zero-fill > - minor cleanup in closePath() to avoid upscaling coordinates > - added crash test > > Cheers, > Laurent From james.graham at oracle.com Mon Feb 8 23:14:24 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 8 Feb 2016 15:14:24 -0800 Subject: [OpenJDK 2D-Dev] RFR 8149338: JVM Crash caused by Marlin renderer not handling NaN coordinates In-Reply-To: References: Message-ID: <56B92150.8030007@oracle.com> In the test case, why are you using a log handler to check for a particular exception? Shouldn't any exception logged be cause for a test failure? ...jim On 2/8/16 1:22 PM, Laurent Bourg?s wrote: > Phil & Jim, > > Please review a simple fix for a SEGV in Marlin renderer due to NaN > coordinates: > bug: https://bugs.openjdk.java.net/browse/JDK-8149338 > webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8149338.0/ > > Changes: > - addLine: use first / last Y crossings to compute edge min/max Y that > ensures consistency with edgeBuckets / edgeBucketCounts arrays in case > of NaN values: it is used in dispose() to reset these critical arrays > (pointer-like) => robust and consistent zero-fill > - minor cleanup in closePath() to avoid upscaling coordinates > - added crash test > > Cheers, > Laurent From bourges.laurent at gmail.com Tue Feb 9 08:51:52 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 9 Feb 2016 09:51:52 +0100 Subject: [OpenJDK 2D-Dev] RFR 8149338: JVM Crash caused by Marlin renderer not handling NaN coordinates In-Reply-To: <56B92150.8030007@oracle.com> References: <56B92150.8030007@oracle.com> Message-ID: Jim, Here are my answers to your 2 questions: 2016-02-09 0:14 GMT+01:00 Jim Graham : > In the test case, why are you using a log handler to check for a > particular exception? Shouldn't any exception logged be cause for a test > failure? I already used that code in 1 other test: TextClipErrorTest. I agree it can be simpler to report any exception like: public void publish(LogRecord record) { Throwable th = record.getThrown(); // detect any Throwable: if (th != null) { System.out.println("Test failed:\n" + record.getMessage()); th.printStackTrace(System.out); throw new RuntimeException("Test failed: ", th); } } Is there a reason why you reversed the calculations for the slope at line > 374? + final double slope = (x1d - x2) / (y1d - y2); I prefer this syntax as it is more explicit that (x1d - x2) and (y1d - y2) are double values (not implicit promotion). Cheers, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Tue Feb 9 14:47:59 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 9 Feb 2016 17:47:59 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8142966 Wrong cursor position in text components on HiDPI display In-Reply-To: <56B8E930.9000405@oracle.com> References: <56A935F0.5060504@oracle.com> <56B4FA69.9000604@oracle.com> <56B6112F.1050708@oracle.com> <56B8E930.9000405@oracle.com> Message-ID: <56B9FC1F.9090607@oracle.com> Some additional information. The Swing calculates the size of the components and location of the cursor based on the text metrics. And these text metrics based on advance. The Swing do not know to what destination it will be painted, it calculates the size based on the non-scaled(non-retina) destination. The problem occurs when we paint such component to the hidpi screen, because we get small round errors per glyph -> this causes a visible issue? when the text string is long. As a solution on the macosx the round operation was done in the users space instead of dev space. For example before the fix the size 1.4px was rounded to 3 (1.4 * 2 = 2.8 -> 3), but after the fix it will be 2 (1.4-> 1 * 2 = 2). So the Swing will be able to calculate correct size/location without information of the device scale. Note that the 3px(in dev space) is a kind of fractional coordinate in the user space(1.5). And the Swing does not work properly when fractional metrics are used, because it use ints as a coordinates. Note that the fix should be applied only when fractional metrics is off, otherwise we should not use any rounding. I am not sure that the current fix take it into account. On 08.02.16 22:14, Jim Graham wrote: > Isn't the problem there that we are returning an integer as the advance? > Why aren't we returning 7.35 as a value instead of 8? > > Also, shouldn't 7.35 round to 7 and 14.7 round to 15? > > ...jim > > On 2/6/2016 7:28 AM, Alexander Scherbatiy wrote: >> On 05/02/16 23:39, Phil Race wrote: >>> Two things strike me when I read this >>> >>> 1) Initial surprise at how deep into the font code it goes. >>> Perhaps there are alternatives. >>> >>> 2) That it changes to using the linear metrics for measuring advance. >>> Regardless of (1) I do not think (2) is correct. I am fairly sure this >>> will lead to changes in text advance. It seems like it must throw >>> away adjusted metrics as a result of glyph hinting. >>> >>> I don't know what the fix should be, since I have not looked at the >>> problem top-down, I am just seeing the bottom-up proposed solution. >>> So all I can say for now is that it needs to be at least somewhat >>> different. >> >> There was the same issue on Mac OS X which has been fixed in the >> similar way: >> 8013569 [macosx] JLabel preferred size incorrect on retina displays >> with non-default font size >> https://bugs.openjdk.java.net/browse/JDK-8013569 >> http://cr.openjdk.java.net/~serb/7190349/webrev.04/ >> >> The problem is that in many case for UI scale 2 we return to a user >> an unscaled value. >> But a value for transformed glyph advance, rounded and descaled can >> differ from just rounded glyph advance. >> >> For example, font[dialog, plain, 12] char 'a': >> transform: 12, advance: 7.35, rounded advance: 8 >> transform: 24, advance: 14.70 round advance: 14 >> >> and 8 does not equal 14 / 2. >> >> The solution for Mac OS X was to get the glyph advance using only >> font transform, round it and then apply the dev transform: >> >> CGGlyphImages.m: >> 481 advance = CGSizeApplyAffineTransform(advance, strike->fFontTx); >> 482 if (!JRSFontStyleUsesFractionalMetrics(strike->fStyle)) { >> 483 advance.width = round(advance.width); >> 484 advance.height = round(advance.height); >> 485 } >> 486 advance = CGSizeApplyAffineTransform(advance, strike->fDevTx); >> >> Thanks, >> Alexandr. >>> >>> -phil. >>> >>> On 01/27/2016 01:26 PM, Alexander Scherbatiy wrote: >>>> >>>> Hello, >>>> >>>> Could you review the fix: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8142966 >>>> webrev: http://cr.openjdk.java.net/~alexsch/8142966/webev.00/ >>>> >>>> The proposed fix rounds a glyph advance first and then scales it if >>>> UI scales do not equal to one. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>> >> -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Feb 9 14:56:39 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 9 Feb 2016 17:56:39 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8142966 Wrong cursor position in text components on HiDPI display In-Reply-To: <56B9FC1F.9090607@oracle.com> References: <56A935F0.5060504@oracle.com> <56B4FA69.9000604@oracle.com> <56B6112F.1050708@oracle.com> <56B8E930.9000405@oracle.com> <56B9FC1F.9090607@oracle.com> Message-ID: <56B9FE27.4040204@oracle.com> Also probably it will be possible to test this via the public api only(using the mix of the graphics transform + font transform). On 09.02.16 17:47, Sergey Bylokhov wrote: > Some additional information. > The Swing calculates the size of the components and location of the > cursor based on the text metrics. And these text metrics based on > advance. The Swing do not know to what destination it will be painted, > it calculates the size based on the non-scaled(non-retina) destination. > The problem occurs when we paint such component to the hidpi screen, > because we get small round errors per glyph -> this causes a visible > issue? when the text string is long. As a solution on the macosx the > round operation was done in the users space instead of dev space. > > For example before the fix the size 1.4px was rounded to 3 (1.4 * 2 = > 2.8 -> 3), but after the fix it will be 2 (1.4-> 1 * 2 = 2). So the > Swing will be able to calculate correct size/location without > information of the device scale. Note that the 3px(in dev space) is a > kind of fractional coordinate in the user space(1.5). And the Swing does > not work properly when fractional metrics are used, because it use ints > as a coordinates. > > Note that the fix should be applied only when fractional metrics is off, > otherwise we should not use any rounding. I am not sure that the current > fix take it into account. > > > On 08.02.16 22:14, Jim Graham wrote: >> Isn't the problem there that we are returning an integer as the advance? >> Why aren't we returning 7.35 as a value instead of 8? >> >> Also, shouldn't 7.35 round to 7 and 14.7 round to 15? >> >> ...jim >> >> On 2/6/2016 7:28 AM, Alexander Scherbatiy wrote: >>> On 05/02/16 23:39, Phil Race wrote: >>>> Two things strike me when I read this >>>> >>>> 1) Initial surprise at how deep into the font code it goes. >>>> Perhaps there are alternatives. >>>> >>>> 2) That it changes to using the linear metrics for measuring advance. >>>> Regardless of (1) I do not think (2) is correct. I am fairly sure this >>>> will lead to changes in text advance. It seems like it must throw >>>> away adjusted metrics as a result of glyph hinting. >>>> >>>> I don't know what the fix should be, since I have not looked at the >>>> problem top-down, I am just seeing the bottom-up proposed solution. >>>> So all I can say for now is that it needs to be at least somewhat >>>> different. >>> >>> There was the same issue on Mac OS X which has been fixed in the >>> similar way: >>> 8013569 [macosx] JLabel preferred size incorrect on retina displays >>> with non-default font size >>> https://bugs.openjdk.java.net/browse/JDK-8013569 >>> http://cr.openjdk.java.net/~serb/7190349/webrev.04/ >>> >>> The problem is that in many case for UI scale 2 we return to a user >>> an unscaled value. >>> But a value for transformed glyph advance, rounded and descaled can >>> differ from just rounded glyph advance. >>> >>> For example, font[dialog, plain, 12] char 'a': >>> transform: 12, advance: 7.35, rounded advance: 8 >>> transform: 24, advance: 14.70 round advance: 14 >>> >>> and 8 does not equal 14 / 2. >>> >>> The solution for Mac OS X was to get the glyph advance using only >>> font transform, round it and then apply the dev transform: >>> >>> CGGlyphImages.m: >>> 481 advance = CGSizeApplyAffineTransform(advance, >>> strike->fFontTx); >>> 482 if (!JRSFontStyleUsesFractionalMetrics(strike->fStyle)) { >>> 483 advance.width = round(advance.width); >>> 484 advance.height = round(advance.height); >>> 485 } >>> 486 advance = CGSizeApplyAffineTransform(advance, strike->fDevTx); >>> >>> Thanks, >>> Alexandr. >>>> >>>> -phil. >>>> >>>> On 01/27/2016 01:26 PM, Alexander Scherbatiy wrote: >>>>> >>>>> Hello, >>>>> >>>>> Could you review the fix: >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8142966 >>>>> webrev: http://cr.openjdk.java.net/~alexsch/8142966/webev.00/ >>>>> >>>>> The proposed fix rounds a glyph advance first and then scales it if >>>>> UI scales do not equal to one. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>> >>> > > -- Best regards, Sergey. From brian.burkhalter at oracle.com Tue Feb 9 19:35:25 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 9 Feb 2016 11:35:25 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8149120: TIFFField constructor throws ArrayIndexOutOfBoundsException and IllegalArgumentException for scenarios explained in description Message-ID: <98A4B331-7BC1-442A-AD1B-2CFA1F38D8C3@oracle.com> Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8149120 Patch: see below Summary: Clean up parameter checking for TIFFField(TIFFTag,int,int,Object). Thanks, Brian --- a/src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFField.java +++ b/src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFField.java @@ -519,6 +519,11 @@ * @throws IllegalArgumentException if type is an unacceptable * data type for the supplied TIFFTag. * @throws IllegalArgumentException if count < 0. + * @throws IllegalArgumentException if count < 1 + * and type is TIFF_RATIONAL or + * TIFF_SRATIONAL. + * @throws IllegalArgumentException if count ≠ 1 + * and type is TIFF_IFD_POINTER. * @throws NullPointerException if data == null. * @throws IllegalArgumentException if data is an instance of * a class incompatible with the specified type. @@ -534,6 +539,14 @@ + " for " + tag.getName() + " tag"); } else if(count < 0) { throw new IllegalArgumentException("count < 0!"); + } else if((type == TIFFTag.TIFF_RATIONAL + || type == TIFFTag.TIFF_SRATIONAL) + && count < 1) { + throw new IllegalArgumentException + ("Type is TIFF_RATIONAL or TIFF_SRATIONAL and count < 1"); + } else if (type == TIFFTag.TIFF_IFD_POINTER && count != 1) { + throw new IllegalArgumentException + ("Type is TIFF_IFD_POINTER count != 1"); } else if(data == null) { throw new NullPointerException("data == null!"); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From bourges.laurent at gmail.com Tue Feb 9 22:10:41 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 9 Feb 2016 23:10:41 +0100 Subject: [OpenJDK 2D-Dev] RFR 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering In-Reply-To: <56B917CC.5090806@oracle.com> References: <56B3F68F.3070204@oracle.com> <56B3F8C3.7040609@oracle.com> <56B917CC.5090806@oracle.com> Message-ID: Jim, Thanks to your comments, I generalized the TL / CLQ approach in sun.java2d package with new classes: - ReentrantContext: base class for thread contexts with few package-visible fields: usage and reference - ReentrantContextProvider: base provider class that define the abstract methods to be implemented + several reference wrappers (hard, soft, weak) - ReentrantContextProviderCLQ: very simple provider that only use a CLQ for storage - ReentrantContextProviderTL: enhanced Thread Local provider that uses another ReentrantContextProviderCLQ if reentrance detected These 2 last implementations supports any reference wrapper as given in their constructor. Here is the updated webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8148886.3/ Please give me your point of view; is it the good direction ? (javadoc / comments remain to be fixed) Of course, the new classes are used by both AAShapePipe and MarlinRenderingEngine and it works well: performance is still the same but all tests are passing. Few anwsers below: 2016-02-08 23:33 GMT+01:00 Jim Graham : > You might want to separate the new ReentrantTL class into a separate file > in sun.java2d so it can be used in other places. What are the hurdles for > using it in Marlin instead of rolling its own? If it is going to be reused > it might be better to represent the ReentrantContext class as an interface > so that objects with pre-determined super-class hierarchies can still > participate. > Done as proposed; the 'hurdles' were that I want to keep high performance and may prefer sometimes code duplication ... but my first tests seem indicating that the new approach is equivalent as before. > MarlinRenderingEngine line 182 - testing useThreadLocal is > redundant/irrelevant here, checking the queue variable should be enough. > (it was a trick as hotspot optimizes dead code: the condition !useThreadLocal may let hotspot remove a useless block) > ReentrantThreadLocal - depth is a poor name for that field. Perhaps > usage? With "*_TL_INACTIVE", "*_TL_IN_USE", and "*_CLQ" being the variants? > Agreed: I adopted your proposal. > > AAShapePipe line 297 - should it double check that the level is > DEPTH_CLQ? Otherwise someone can submit an undefined TL object for > restore() and it will end up in the queue... > I added the double-check as recommended. Cheers, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Tue Feb 9 23:43:04 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 9 Feb 2016 15:43:04 -0800 Subject: [OpenJDK 2D-Dev] RFR 8149338: JVM Crash caused by Marlin renderer not handling NaN coordinates In-Reply-To: References: <56B92150.8030007@oracle.com> Message-ID: <56BA7988.4040202@oracle.com> On 2/9/16 12:51 AM, Laurent Bourg?s wrote: > + final double slope = (x1d - x2) / (y1d - y2); > > I prefer this syntax as it is more explicit that (x1d - x2) and (y1d - > y2) are double values (not implicit promotion). I see. Arguably both are implicit promotion, though, no? Mathematiconceptually, "x2 as a double minus x1d" and "y2 as a double minus y1d" are the values one would associate with a slope calculation, type promotion semantics aside. But, both are correct so I'm happy with either way that you are comfortable maintaining the code... ...jim From james.graham at oracle.com Tue Feb 9 23:46:49 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 9 Feb 2016 15:46:49 -0800 Subject: [OpenJDK 2D-Dev] RFR 8149338: JVM Crash caused by Marlin renderer not handling NaN coordinates In-Reply-To: References: <56B92150.8030007@oracle.com> Message-ID: <56BA7A69.5050703@oracle.com> Let me know if/when you have an updated webrev. It should be good to go, but it couldn't hurt to publish one for the archives... ...jim On 2/9/16 12:51 AM, Laurent Bourg?s wrote: > Jim, > > Here are my answers to your 2 questions: > > 2016-02-09 0:14 GMT+01:00 Jim Graham >: > > In the test case, why are you using a log handler to check for a > particular exception? Shouldn't any exception logged be cause for a > test failure? > > > I already used that code in 1 other test: TextClipErrorTest. I agree it > can be simpler to report any exception like: > public void publish(LogRecord record) { > Throwable th = record.getThrown(); > // detect any Throwable: > if (th != null) { > System.out.println("Test failed:\n" + > record.getMessage()); > th.printStackTrace(System.out); > > throw new RuntimeException("Test failed: ", th); > } > } > > Is there a reason why you reversed the calculations for the slope at > line 374? > > + final double slope = (x1d - x2) / (y1d - y2); > > I prefer this syntax as it is more explicit that (x1d - x2) and (y1d - > y2) are double values (not implicit promotion). > > Cheers, > Laurent From philip.race at oracle.com Wed Feb 10 00:20:13 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 09 Feb 2016 16:20:13 -0800 Subject: [OpenJDK 2D-Dev] RFR 8149338: JVM Crash caused by Marlin renderer not handling NaN coordinates In-Reply-To: <56BA7A69.5050703@oracle.com> References: <56B92150.8030007@oracle.com> <56BA7A69.5050703@oracle.com> Message-ID: <56BA823D.4010106@oracle.com> Looks ok to me. -phil. On 02/09/2016 03:46 PM, Jim Graham wrote: > Let me know if/when you have an updated webrev. It should be good to > go, but it couldn't hurt to publish one for the archives... > > ...jim > > On 2/9/16 12:51 AM, Laurent Bourg?s wrote: >> Jim, >> >> Here are my answers to your 2 questions: >> >> 2016-02-09 0:14 GMT+01:00 Jim Graham > >: >> >> In the test case, why are you using a log handler to check for a >> particular exception? Shouldn't any exception logged be cause for a >> test failure? >> >> >> I already used that code in 1 other test: TextClipErrorTest. I agree it >> can be simpler to report any exception like: >> public void publish(LogRecord record) { >> Throwable th = record.getThrown(); >> // detect any Throwable: >> if (th != null) { >> System.out.println("Test failed:\n" + >> record.getMessage()); >> th.printStackTrace(System.out); >> >> throw new RuntimeException("Test failed: ", th); >> } >> } >> >> Is there a reason why you reversed the calculations for the slope at >> line 374? >> >> + final double slope = (x1d - x2) / (y1d - y2); >> >> I prefer this syntax as it is more explicit that (x1d - x2) and (y1d - >> y2) are double values (not implicit promotion). >> >> Cheers, >> Laurent From james.graham at oracle.com Wed Feb 10 01:00:47 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 9 Feb 2016 17:00:47 -0800 Subject: [OpenJDK 2D-Dev] RFR 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering In-Reply-To: References: <56B3F68F.3070204@oracle.com> <56B3F8C3.7040609@oracle.com> <56B917CC.5090806@oracle.com> Message-ID: <56BA8BBF.9070609@oracle.com> Hi Laurent, This looks great! The classes you call *Wrapper are really more like factories or accessors. A wrapper would imply that it houses the object in question, but these are more concerned with providing an access pattern and/or a factory for Reference types to wrap the objects in question. I would probably have named them *Factory instead. About the only simplifying suggestion I might have is that if you can subclass Reference and create HardReference extends Reference with an obvious implementation, then you wouldn't have to special case the HARD type and you could get rid of a lot of your use of raw "Object" references and replace them with generified code. Unfortunately Reference is not subclassable outside the java.lang.ref package. I looked online and found a number of people considering subclassing a HardReference variant off of WeakReference - as long as the subclass keeps a hard reference the referent in the super class is not relevant. That mechanism may be a little clunky, but it would mean that you can always assume that the TL.get() and CLQ.poll() are returning a Reference and just call get() on it without having to use a factory/accessor. public class HardReference extends WeakReference { private final T strongRef; public HardReference(T obj) { super(null); this.strongRef = obj; } public T get() { return strongRef; } } Another way to crack that egg would be to simply embed the following code where you call the resolveReference methods: ctx = (obj instanceof Reference) ? ((Reference) obj).get() : ((K) obj); (No need for a null test there because instanceof ensures non-nullness and you don't care about which form of reference it is since they all share the same get() method.) If you made either of those changes then the Wrapper classes would only exist to create the appropriate Reference object and could be left as factories or simply be replaced with a wrap(ctx) method in the parent with a switch statement in it. Since it is only called on construction, the switch statement should have negligible overhead and eliminate 4 inner classes (parent Wrapper and 3 flavors of Wrapper). ...jim On 2/9/16 2:10 PM, Laurent Bourg?s wrote: > Jim, > > Thanks to your comments, I generalized the TL / CLQ approach in > sun.java2d package with new classes: > - ReentrantContext: base class for thread contexts with few > package-visible fields: usage and reference > - ReentrantContextProvider: base provider class that define the abstract > methods to be implemented + several reference wrappers (hard, soft, weak) > - ReentrantContextProviderCLQ: very simple provider that only use a CLQ > for storage > - ReentrantContextProviderTL: enhanced Thread Local provider that uses > another ReentrantContextProviderCLQ if reentrance detected > > These 2 last implementations supports any reference wrapper as given in > their constructor. > > Here is the updated webrev: > http://cr.openjdk.java.net/~lbourges/marlin/marlin-8148886.3/ > > Please give me your point of view; is it the good direction ? > (javadoc / comments remain to be fixed) > > Of course, the new classes are used by both AAShapePipe and > MarlinRenderingEngine and it works well: > performance is still the same but all tests are passing. > > > Few anwsers below: > > 2016-02-08 23:33 GMT+01:00 Jim Graham >: > > You might want to separate the new ReentrantTL class into a separate > file in sun.java2d so it can be used in other places. What are the > hurdles for using it in Marlin instead of rolling its own? If it is > going to be reused it might be better to represent the > ReentrantContext class as an interface so that objects with > pre-determined super-class hierarchies can still participate. > > > Done as proposed; the 'hurdles' were that I want to keep high > performance and may prefer sometimes code duplication ... but my first > tests seem indicating that the new approach is equivalent as before. > > MarlinRenderingEngine line 182 - testing useThreadLocal is > redundant/irrelevant here, checking the queue variable should be enough. > > > (it was a trick as hotspot optimizes dead code: the condition > !useThreadLocal may let hotspot remove a useless block) > > ReentrantThreadLocal - depth is a poor name for that field. Perhaps > usage? With "*_TL_INACTIVE", "*_TL_IN_USE", and "*_CLQ" being the > variants? > > > Agreed: I adopted your proposal. > > > AAShapePipe line 297 - should it double check that the level is > DEPTH_CLQ? Otherwise someone can submit an undefined TL object for > restore() and it will end up in the queue... > > > I added the double-check as recommended. > > Cheers, > Laurent From philip.race at oracle.com Wed Feb 10 19:50:54 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 10 Feb 2016 11:50:54 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8149120: TIFFField constructor throws ArrayIndexOutOfBoundsException and IllegalArgumentException for scenarios explained in description In-Reply-To: <98A4B331-7BC1-442A-AD1B-2CFA1F38D8C3@oracle.com> References: <98A4B331-7BC1-442A-AD1B-2CFA1F38D8C3@oracle.com> Message-ID: <56BB949E.80809@oracle.com> +1 -phil. On 02/09/2016 11:35 AM, Brian Burkhalter wrote: > Please review at your convenience. > > Issue:https://bugs.openjdk.java.net/browse/JDK-8149120 > Patch:see below > > Summary: Clean up parameter checking for > TIFFField(TIFFTag,int,int,Object). > > Thanks, > > Brian > > --- > a/src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFField.java > +++ > b/src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFField.java > @@ -519,6 +519,11 @@ > * @throws IllegalArgumentException if type is an > unacceptable > * data type for the supplied TIFFTag. > * @throws IllegalArgumentException if > count < 0. > *+ * @throws IllegalArgumentException if > count < 1* > *+ * and type is TIFF_RATIONAL or* > *+ * TIFF_SRATIONAL.* > *+ * @throws IllegalArgumentException if > count ≠ 1* > *+ * and type is TIFF_IFD_POINTER.* > * @throws NullPointerException if > data == null. > * @throws IllegalArgumentException if data is an > instance of > * a class incompatible with the specified type. > @@ -534,6 +539,14 @@ > + " for " + tag.getName() + " tag"); > } else if(count < 0) { > throw new IllegalArgumentException("count < 0!"); > *+ } else if((type == TIFFTag.TIFF_RATIONAL* > *+ || type == TIFFTag.TIFF_SRATIONAL)* > *+ && count < 1) {* > *+ throw new IllegalArgumentException* > *+ ("Type is TIFF_RATIONAL or TIFF_SRATIONAL and count < 1");* > *+ } else if (type == TIFFTag.TIFF_IFD_POINTER && count != 1) {* > *+ throw new IllegalArgumentException* > *+ ("Type is TIFF_IFD_POINTER count != 1");* > } else if(data == null) { > throw new NullPointerException("data == null!"); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Feb 10 20:25:16 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 10 Feb 2016 12:25:16 -0800 Subject: [OpenJDK 2D-Dev] [9] Review request for 8073400: Some Monospaced logical fonts have a different width In-Reply-To: <56977953.10604@oracle.com> References: <56977953.10604@oracle.com> Message-ID: <56BB9CAC.3050408@oracle.com> I expect the exclusion range is there for a reason. I think (guess) that the intent was that where there is a sequence like this : sequence.sansserif.x-windows-950=alphabetic,chinese-ms950,dingbats,symbol,chinese-ms950-extb then those code points should come from the chinese font. Perhaps your adjusted exclusion range should apply only to the monospaced fonts which are already putting the locale font first. Unfortunately it doesn't appear that this is possible with the supported syntax https://docs.oracle.com/javase/1.5.0/docs/guide/intl/fontconfig.html#windows i.e it supports selection only by charactersubsetname, not also by logicalfontname. But you should check the code to see if this is in fact the case. There may need to be a non-ideal decision or a revision to that spec. and its supporting code. And why be so narrow ? It seems you have made an even odder situation in having just those two code points 'un'-excluded. The argument that those were the two a customer complained about does not hold up very well. I think you should also run this whole change+discussion by i18n-dev .. -phil. On 01/14/2016 02:32 AM, dmitry markov wrote: > Hello, > > Could you review the fix for jdk9, please? > > bug: https://bugs.openjdk.java.net/browse/JDK-8073400 > webrev: http://cr.openjdk.java.net/~dmarkov/8073400/jdk9/webrev.00/ > > Problem description: > On Windows some characters (in particular, left and right double > quotation marks) have width differing from other characters' widths, > when Monospaced logical font is used. > The default monospaced font for windows platform is Courier New. It > contains the desired characters, (i.e. '\u201c' and '\u201d'). However > the characters are in 'exclusion ranges' for this font due to settings > in windows.fontconfig.properties. So when we try to obtain glyphs for > these characters and calculate their bounds, we fallback to another > font (Lucida) and use its glyphs. > > Fix: > Remove the following set of characters u2018 - u201F from the > exclusion ranges. > > Thanks, > Dmitry From bourges.laurent at gmail.com Wed Feb 10 20:52:12 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 10 Feb 2016 21:52:12 +0100 Subject: [OpenJDK 2D-Dev] RFR 8149338: JVM Crash caused by Marlin renderer not handling NaN coordinates In-Reply-To: <56BA7A69.5050703@oracle.com> References: <56B92150.8030007@oracle.com> <56BA7A69.5050703@oracle.com> Message-ID: Jim & Phil, Here is the updated webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8149338.1/ I just simplified the exception handling code in both TextClipErrorTest and CrashNaNTest Cheers, Laurent 2016-02-10 0:46 GMT+01:00 Jim Graham : > Let me know if/when you have an updated webrev. It should be good to go, > but it couldn't hurt to publish one for the archives... > > ...jim > > On 2/9/16 12:51 AM, Laurent Bourg?s wrote: > >> Jim, >> >> Here are my answers to your 2 questions: >> >> 2016-02-09 0:14 GMT+01:00 Jim Graham > >: >> >> In the test case, why are you using a log handler to check for a >> particular exception? Shouldn't any exception logged be cause for a >> test failure? >> >> >> I already used that code in 1 other test: TextClipErrorTest. I agree it >> can be simpler to report any exception like: >> public void publish(LogRecord record) { >> Throwable th = record.getThrown(); >> // detect any Throwable: >> if (th != null) { >> System.out.println("Test failed:\n" + >> record.getMessage()); >> th.printStackTrace(System.out); >> >> throw new RuntimeException("Test failed: ", th); >> } >> } >> >> Is there a reason why you reversed the calculations for the slope at >> line 374? >> >> + final double slope = (x1d - x2) / (y1d - y2); >> >> I prefer this syntax as it is more explicit that (x1d - x2) and (y1d - >> y2) are double values (not implicit promotion). >> >> Cheers, >> Laurent >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Wed Feb 10 21:27:15 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 10 Feb 2016 13:27:15 -0800 Subject: [OpenJDK 2D-Dev] RFR 8149338: JVM Crash caused by Marlin renderer not handling NaN coordinates In-Reply-To: References: <56B92150.8030007@oracle.com> <56BA7A69.5050703@oracle.com> Message-ID: <56BBAB33.3070104@oracle.com> Looks good... ...jim On 2/10/16 12:52 PM, Laurent Bourg?s wrote: > Jim & Phil, > > Here is the updated webrev: > http://cr.openjdk.java.net/~lbourges/marlin/marlin-8149338.1/ > > I just simplified the exception handling code in both TextClipErrorTest > and CrashNaNTest > > Cheers, > Laurent > > 2016-02-10 0:46 GMT+01:00 Jim Graham >: > > Let me know if/when you have an updated webrev. It should be good > to go, but it couldn't hurt to publish one for the archives... > > ...jim > > On 2/9/16 12:51 AM, Laurent Bourg?s wrote: > > Jim, > > Here are my answers to your 2 questions: > > 2016-02-09 0:14 GMT+01:00 Jim Graham > >>: > > In the test case, why are you using a log handler to check > for a > particular exception? Shouldn't any exception logged be > cause for a > test failure? > > > I already used that code in 1 other test: TextClipErrorTest. I > agree it > can be simpler to report any exception like: > public void publish(LogRecord record) { > Throwable th = record.getThrown(); > // detect any Throwable: > if (th != null) { > System.out.println("Test failed:\n" + > record.getMessage()); > th.printStackTrace(System.out); > > throw new RuntimeException("Test failed: > ", th); > } > } > > Is there a reason why you reversed the calculations for the > slope at > line 374? > > + final double slope = (x1d - x2) / (y1d - y2); > > I prefer this syntax as it is more explicit that (x1d - x2) and > (y1d - > y2) are double values (not implicit promotion). > > Cheers, > Laurent > > From james.graham at oracle.com Wed Feb 10 21:32:02 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 10 Feb 2016 13:32:02 -0800 Subject: [OpenJDK 2D-Dev] RFR 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering In-Reply-To: References: <56B3F68F.3070204@oracle.com> <56B3F8C3.7040609@oracle.com> <56B917CC.5090806@oracle.com> Message-ID: <56BBAC52.8090403@oracle.com> One suggestion on ProviderTL - have a constructor overload that allows separate ref types for the TL and the CLQ references in case there is a situation where you want a hard reference for the primary context and a soft reference for the reentrant ones (which may be situationally rare). The single refType constructor would use the same refType for both cases... ...jim On 2/9/16 2:10 PM, Laurent Bourg?s wrote: > Jim, > > Thanks to your comments, I generalized the TL / CLQ approach in > sun.java2d package with new classes: > - ReentrantContext: base class for thread contexts with few > package-visible fields: usage and reference > - ReentrantContextProvider: base provider class that define the abstract > methods to be implemented + several reference wrappers (hard, soft, weak) > - ReentrantContextProviderCLQ: very simple provider that only use a CLQ > for storage > - ReentrantContextProviderTL: enhanced Thread Local provider that uses > another ReentrantContextProviderCLQ if reentrance detected > > These 2 last implementations supports any reference wrapper as given in > their constructor. > > Here is the updated webrev: > http://cr.openjdk.java.net/~lbourges/marlin/marlin-8148886.3/ > > Please give me your point of view; is it the good direction ? > (javadoc / comments remain to be fixed) > > Of course, the new classes are used by both AAShapePipe and > MarlinRenderingEngine and it works well: > performance is still the same but all tests are passing. > > > Few anwsers below: > > 2016-02-08 23:33 GMT+01:00 Jim Graham >: > > You might want to separate the new ReentrantTL class into a separate > file in sun.java2d so it can be used in other places. What are the > hurdles for using it in Marlin instead of rolling its own? If it is > going to be reused it might be better to represent the > ReentrantContext class as an interface so that objects with > pre-determined super-class hierarchies can still participate. > > > Done as proposed; the 'hurdles' were that I want to keep high > performance and may prefer sometimes code duplication ... but my first > tests seem indicating that the new approach is equivalent as before. > > MarlinRenderingEngine line 182 - testing useThreadLocal is > redundant/irrelevant here, checking the queue variable should be enough. > > > (it was a trick as hotspot optimizes dead code: the condition > !useThreadLocal may let hotspot remove a useless block) > > ReentrantThreadLocal - depth is a poor name for that field. Perhaps > usage? With "*_TL_INACTIVE", "*_TL_IN_USE", and "*_CLQ" being the > variants? > > > Agreed: I adopted your proposal. > > > AAShapePipe line 297 - should it double check that the level is > DEPTH_CLQ? Otherwise someone can submit an undefined TL object for > restore() and it will end up in the queue... > > > I added the double-check as recommended. > > Cheers, > Laurent From bourges.laurent at gmail.com Wed Feb 10 21:36:59 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 10 Feb 2016 22:36:59 +0100 Subject: [OpenJDK 2D-Dev] RFR 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering In-Reply-To: <56BBAC52.8090403@oracle.com> References: <56B3F68F.3070204@oracle.com> <56B3F8C3.7040609@oracle.com> <56B917CC.5090806@oracle.com> <56BBAC52.8090403@oracle.com> Message-ID: Jim 2016-02-10 22:32 GMT+01:00 Jim Graham : > One suggestion on ProviderTL - have a constructor overload that allows > separate ref types for the TL and the CLQ references in case there is a > situation where you want a hard reference for the primary context and a > soft reference for the reentrant ones (which may be situationally rare). > The single refType constructor would use the same refType for both cases... It is a good idea. I am preparing a new webrev and I slightly changed my mind: - TL references are defined using the given ref type (hard, soft or weak) - CLQ references are always weak to reduce the memory footprint I think it is better to have weaker references for the CLQ as it is less important. Do you still need a new constructor with 2 different ref types ? Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Feb 10 21:41:13 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 10 Feb 2016 13:41:13 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8149593: Change foo to {@code foo} in TIFF plugin classes Message-ID: <2033706E-E18F-42C0-8941-B0361D2DF82F@oracle.com> Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8149593 Patch: http://cr.openjdk.java.net/~bpb/8149593/webrev.00/ Summary: Transmogrify ?foo? to ?{@code foo}?. The patch is long but the changes are all the same (quotation marks omitted): ?" changed to ?{@code ?. ?? change to ?}? ?2015,? changed to ?2016," Both the source and the docs builds succeed, the latter with no errors or warning in these affected classes. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Wed Feb 10 21:41:47 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 10 Feb 2016 13:41:47 -0800 Subject: [OpenJDK 2D-Dev] RFR 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering In-Reply-To: References: <56B3F68F.3070204@oracle.com> <56B3F8C3.7040609@oracle.com> <56B917CC.5090806@oracle.com> <56BBAC52.8090403@oracle.com> Message-ID: <56BBAE9B.80404@oracle.com> I was thinking the same thing with respect to the 2 current cases we are looking at, that's why I suggested the 2 types. But, it could be situational. It may be rare to have reentrancy for these objects, but other cases might encounter reentrant cases more often. It couldn't hurt to have the 2 constructors since the single refType constructor would just be a 1-liner: public ProviderTL(refType) { this(refType, refType); } or? public ProviderTL(refType) { this(refType, WEAK); } ? ...jim On 2/10/16 1:36 PM, Laurent Bourg?s wrote: > Jim > > 2016-02-10 22:32 GMT+01:00 Jim Graham >: > > One suggestion on ProviderTL - have a constructor overload that > allows separate ref types for the TL and the CLQ references in case > there is a situation where you want a hard reference for the primary > context and a soft reference for the reentrant ones (which may be > situationally rare). The single refType constructor would use the > same refType for both cases... > > > It is a good idea. I am preparing a new webrev and I slightly changed my > mind: > - TL references are defined using the given ref type (hard, soft or weak) > - CLQ references are always weak to reduce the memory footprint > > I think it is better to have weaker references for the CLQ as it is less > important. > > Do you still need a new constructor with 2 different ref types ? > > Laurent From bourges.laurent at gmail.com Wed Feb 10 22:25:30 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 10 Feb 2016 23:25:30 +0100 Subject: [OpenJDK 2D-Dev] RFR 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering In-Reply-To: <56BA8BBF.9070609@oracle.com> References: <56B3F68F.3070204@oracle.com> <56B3F8C3.7040609@oracle.com> <56B917CC.5090806@oracle.com> <56BA8BBF.9070609@oracle.com> Message-ID: Jim, Here is the updated webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8148886.4/ Changes: - HardReference adopted: it simplified the code as I removed the wrapper / factory classes but also allowed me to apply generic types: Reference instead of Object - ReentrantContextProviderTL: added a constructor with 2 reference types (TL / CLQ), the default one uses weak reference for CLQ - added javadoc in ReentrantContext* classes: please correct my english sentences ! I am not fluent enough to write clearly such documentation and I do not know how much details are needed or not as it is a internal API. About the only simplifying suggestion I might have is that if you can > subclass Reference and create HardReference extends Reference with an > obvious implementation, then you wouldn't have to special case the HARD > type and you could get rid of a lot of your use of raw "Object" references > and replace them with generified code. Unfortunately Reference is not > subclassable outside the java.lang.ref package. I looked online and found > a number of people considering subclassing a HardReference variant off of > WeakReference - as long as the subclass keeps a hard reference the referent > in the super class is not relevant. That mechanism may be a little clunky, > but it would mean that you can always assume that the TL.get() and > CLQ.poll() are returning a Reference and just call get() on it without > having to use a factory/accessor. > That's absolutely what I always needed ! Several times I wondered why no such HardReference exists in the java.lang.reference package: should we tell core-libs that it is really needed to improve homogeneity / consistency ... and simplify such reference-based code ? > public class HardReference extends WeakReference { > private final T strongRef; > public HardReference(T obj) { > super(null); > this.strongRef = obj; > } > public T get() { return strongRef; } > } > I added such class in ReentrantContextProvider but I did not use 'super(null)'. What is the aim ? Does it simplify the reference processing ? Of course such HardReference does not need any reference queue... > Another way to crack that egg would be to simply embed the following code > where you call the resolveReference methods: > ctx = (obj instanceof Reference) ? ((Reference) obj).get() : > ((K) obj); > (No need for a null test there because instanceof ensures non-nullness and > you don't care about which form of reference it is since they all share the > same get() method.) > It was the case before in MarlinRenderingEngine but I wanted to avoid most conditional statements ... . > If you made either of those changes then the Wrapper classes would only > exist to create the appropriate Reference object and could be left as > factories or simply be replaced with a wrap(ctx) method in the parent with > a switch statement in it. Since it is only called on construction, the > switch statement should have negligible overhead and eliminate 4 inner > classes (parent Wrapper and 3 flavors of Wrapper). > Wrapped in ReentrantContextProvider.getOrCreateReference(ctx). Thanks for your suggestions, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Feb 10 22:33:45 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 10 Feb 2016 14:33:45 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8149593: Change foo to {@code foo} in TIFF plugin classes In-Reply-To: <2033706E-E18F-42C0-8941-B0361D2DF82F@oracle.com> References: <2033706E-E18F-42C0-8941-B0361D2DF82F@oracle.com> Message-ID: <56BBBAC9.5030308@oracle.com> Does your transmogrifier work where there is more than one per line ? I expected both to be changed here : - * the JPEGTables. Default value is null. + * the {@code JPEGTables}. Default value is null. -phil. On 02/10/2016 01:41 PM, Brian Burkhalter wrote: > Please review at your convenience. > > Issue:https://bugs.openjdk.java.net/browse/JDK-8149593 > Patch:http://cr.openjdk.java.net/~bpb/8149593/webrev.00/ > > > Summary: Transmogrify ?foo? to ?{@code foo}?. The patch > is long but the changes are all the same (quotation marks omitted): > > 1. ?" changed to ?{@code ?. > 2. ?? change to ?}? > 3. ?2015,? changed to ?2016," > > > Both the source and the docs builds succeed, the latter with no errors > or warning in these affected classes. > > Thanks, > > Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Feb 10 22:47:00 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 10 Feb 2016 14:47:00 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8149593: Change foo to {@code foo} in TIFF plugin classes In-Reply-To: <56BBBAC9.5030308@oracle.com> References: <2033706E-E18F-42C0-8941-B0361D2DF82F@oracle.com> <56BBBAC9.5030308@oracle.com> Message-ID: <8E400C3D-15F5-4606-8975-C9B0DD93F2AE@oracle.com> Apparently not. It?s a decade old script. I?ll check it out. Thanks for the catch. Perhaps I could just run it N times instead? Brian On Feb 10, 2016, at 2:33 PM, Phil Race wrote: > Does your transmogrifier work where there is more than one per line ? > > I expected both to be changed here : > - * the JPEGTables. Default value is null. > + * the {@code JPEGTables}. Default value is null. > > -phil. > > On 02/10/2016 01:41 PM, Brian Burkhalter wrote: >> Please review at your convenience. >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8149593 >> Patch: >> http://cr.openjdk.java.net/~bpb/8149593/webrev.00/ >> >> Summary: Transmogrify ?foo? to ?{@code foo}?. The patch is long but the changes are all the same (quotation marks omitted): >> >> ?" changed to ?{@code ?. >> ?? change to ?}? >> ?2015,? changed to ?2016," >> >> Both the source and the docs builds succeed, the latter with no errors or warning in these affected classes. >> >> Thanks, >> >> Brian > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Feb 10 22:57:27 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 10 Feb 2016 14:57:27 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8149593: Change foo to {@code foo} in TIFF plugin classes In-Reply-To: <8E400C3D-15F5-4606-8975-C9B0DD93F2AE@oracle.com> References: <2033706E-E18F-42C0-8941-B0361D2DF82F@oracle.com> <56BBBAC9.5030308@oracle.com> <8E400C3D-15F5-4606-8975-C9B0DD93F2AE@oracle.com> Message-ID: <3833682F-20D0-4166-958D-2C3CC4ADDFC0@oracle.com> I re-ran the script on the .00 version of the patch and it seems to have fixed the problem: http://cr.openjdk.java.net/~bpb/8149593/webrev.01/ Please let me know should I have botched anything else. ;-) Thanks, Brian On Feb 10, 2016, at 2:47 PM, Brian Burkhalter wrote: > Apparently not. It?s a decade old script. I?ll check it out. Thanks for the catch. Perhaps I could just run it N times instead? > > Brian > > On Feb 10, 2016, at 2:33 PM, Phil Race wrote: > >> Does your transmogrifier work where there is more than one per line ? >> >> I expected both to be changed here : >> - * the JPEGTables. Default value is null. >> + * the {@code JPEGTables}. Default value is null. >> >> -phil. >> >> On 02/10/2016 01:41 PM, Brian Burkhalter wrote: >>> Please review at your convenience. >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8149593 >>> Patch: >>> http://cr.openjdk.java.net/~bpb/8149593/webrev.00/ >>> >>> Summary: Transmogrify ?foo? to ?{@code foo}?. The patch is long but the changes are all the same (quotation marks omitted): >>> >>> ?" changed to ?{@code ?. >>> ?? change to ?}? >>> ?2015,? changed to ?2016," >>> >>> Both the source and the docs builds succeed, the latter with no errors or warning in these affected classes. >>> >>> Thanks, >>> >>> Brian >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Feb 10 22:59:35 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 10 Feb 2016 14:59:35 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8138749, , Revisited: PrinterJob.printDialog() does not support multi-mon, always displayed on primary In-Reply-To: <56B463FC.9070702@oracle.com> References: <569F6AC2.7060103@oracle.com> <569FFC46.8040700@oracle.com> <56A0A8BD.306@oracle.com> <56A169C3.2010903@oracle.com> <56A1D85B.3020804@oracle.com> <56AA2B15.90900@oracle.com> <56AB323C.7090706@oracle.com> <56B14B37.6010706@oracle.com> <56B19180.70207@oracle.com> <56B244AA.8060707@oracle.com> <56B2E223.1050400@oracle.com> <56B463FC.9070702@oracle.com> Message-ID: <56BBC0D7.9080401@oracle.com> if (dlgBounds.x + dlgBounds.width > bounds.x + bounds.width) { 836 x = bounds.x; Line 836 should be x = (bounds.x + bounds.width) - dlgBound.width Same logic for y. 841 pageDialog.setBounds(x, y, bounds.width, bounds.height); That looks wrong. It is setting the width/height of the dialog to be the width/height of the screen. Should be dlgBounds.width + height. -phil. On 02/05/2016 12:57 AM, prasanta sadhukhan wrote: > > > On 2/4/2016 11:01 AM, prasanta sadhukhan wrote: >> Hi Phil, >> >> On 2/3/2016 11:49 PM, Phil Race wrote: >>> Hi, >>> >>> I think it is worth addressing all this at once and I think it can >>> be done >>> entirely in RPJ, leaving ServiceUI alone. Ie fix it just for the >>> case where >>> RPJ displays the dialog(s). >> RPJ display the dialog only for pageDialog >> http://hg.openjdk.java.net/jdk9/client/jdk/file/b9a92b2a8b37/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java#l820 >> >> whereas ServiceUI display the printDialog >> http://hg.openjdk.java.net/jdk9/client/jdk/file/b9a92b2a8b37/src/java.desktop/share/classes/javax/print/ServiceUI.java#l227 >> >> >> So, are you saying we fix it only for pageDialog and leave out >> printDialog()? >> > Please find updated webrev > http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.04/ > > where both RPJ and ServiceUI is modified to show the dialog entirely > on-screen. > I could not leave ServiceUI without modification as > // if portion of dialog is not within the gc boundary > if (!gcBounds.contains(dlgBounds)) { > // put in the center relative to parent frame/dialog > dialog.setLocationRelativeTo(owner); > } > this code was drawing the dialog in primary so I have to delete the > code to make sure dialog is displayed on secondary to fix the bug. And > since anyway, I was modifying ServiceUI, I thought of adding the > check to draw the printDialog on screen in ServiceUI same as pageDialog. > > Regards > Prasanta >> Regards >> Prasanta >>> When an application calls ServiceUI directly, it >>> can decide where it would like the dialog subject to the existing >>> constraint. >>> >>> The test really should be one test so that the behaviours can be >>> tested as one with lower overhead. >>> >>> -phil. >>> >>> On 02/02/2016 09:34 PM, prasanta sadhukhan wrote: >>>> Hi Phil, >>>> >>>> On 2/3/2016 6:05 AM, Phil Race wrote: >>>>> The RasterPrinterJob changes are now OK however >>>>> >>>>> - I am not sure I understand how removing the check in ServiceUI >>>>> will address the issue about the dialog needing to be entirely >>>>> on-screen. >>>>> It reads to me as if now you allow that in preference to having it >>>>> centred. >>>>> But I am not sure the old code would have worked in all cases either >>>>> since centering on a very small owner window in the corner of the >>>>> screen >>>>> would result in the same problem. >>>> Since this issue was about showing the dialog on primary vs >>>> secondary, can we address this issue of showing the dialog entirely >>>> on-screen in separate bug id (since this issue is present in >>>> primary screen too if dialog is bigger than top-level window)? >>>> The present change in ServiceUI address the issue of showing the >>>> dialog on secondary monitor if dialog is bigger than top-level. >>>>> Probably what is needed is some code that moves it just enough to >>>>> fit. >>>>> ie downwards if it is off the top, left if it is off the right and >>>>> so forth ? >>>>> >>>>> - The two tests do not share the same bug ID. I expected they >>>>> should now do so .. and I was further supposing you would merge >>>>> the two tests into one. >>>> I will change the bug id of 2nd test. Is it ok if I keep these 2 >>>> tests separate to make it easier? >>>> >>>> Regards >>>> Prasanta >>>>> >>>>> -phil. >>>>> >>>>> On 01/29/2016 01:34 AM, prasanta sadhukhan wrote: >>>>>> Hi Phil, >>>>>> >>>>>> On 1/28/2016 8:22 PM, Philip Race wrote: >>>>>>> "in consistent" >>>>>>> >>>>>>> On 1/21/16, 11:20 PM, prasanta sadhukhan wrote: >>>>>>>> Hi Phil, >>>>>>>> >>>>>>>> I checked with NATIVE print dialog and with other app print >>>>>>>> dialog, they are positioning the dialog a little ahead of >>>>>>>> top-left corner (not at 1/3rd of the window as we are doing now) >>>>>>>> so I did the same and positioned the dialog in consistent with >>>>>>>> our NATIVE print dialog. >>>>>>> >>>>>>> You mean consistently. in consistent means the opposite >>>>>>> Please adjust that in the code comment. >>>>>>> >>>>>>> 50,50 is probably OK so long as you verified this is approximately >>>>>>> what happens on most platforms, not just windows 8 or similar. >>>>>>> I don't think you will find complete consistency because apps may >>>>>>> control it and use different dialogs even on the same platform. >>>>>>> On hidpi screens this may be closer to the top-left than you intend >>>>>>> but I expect it is fine. >>>>>>> >>>>>> Tested on windows, linux and it works ok. We showed the dialog at >>>>>> x+50,y+50 where x,y is the coordinate of the active window. >>>>>> Do not have local mac system to test multimonitor setup. >>>>>>> The one main thing that you should verify is what happens in the >>>>>>> case >>>>>>> a native app top-level window is smaller than the print dialog >>>>>>> and is positioned >>>>>>> at the bottom right (of the right-most display). Does the native >>>>>>> app ensure >>>>>>> that the dialog is wholly on-screen ? I don't think your code >>>>>>> will do that. >>>>>>> And Safari on Mac at least seems to do that. I guess that most >>>>>>> apps try >>>>>>> their best to keep the dialog wholly on-screen. >>>>>>> >>>>>> Tested this case where window bounds is smaller than print dialog >>>>>> but because of this check in ServiceUI.java >>>>>> >>>>>> // if portion of dialog is not within the gc boundary >>>>>> if (!gcBounds.contains(dlgBounds)) { >>>>>> // put in the center relative to parent frame/dialog >>>>>> dialog.setLocationRelativeTo(owner); >>>>>> } >>>>>> >>>>>> the dialog is shown in the primary window. >>>>>> I saw we did not have this check for pageDialog(attr) where the >>>>>> dialog is shown in secondary monitor despite gcBounds smaller >>>>>> than print dialog. >>>>>> Therefore, I removed this check from ServiceUI. >>>>>> >>>>>> Please find the updated webrev: >>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.03/ >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>>> -phil. >>>>>>> >>>>>>> >>>>>>>> Please find the updated webrev >>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.02/ >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>>> On 1/22/2016 4:59 AM, Phil Race wrote: >>>>>>>>> That is definitely better .. although I wonder if it would be >>>>>>>>> even better >>>>>>>>> if you found when there is an 'active' window that you tried to >>>>>>>>> position the dialog such that it is near the upper-left corner >>>>>>>>> of that window ? >>>>>>>>> Please experiment and see how that looks compared to what >>>>>>>>> other apps are doing. >>>>>>>>> >>>>>>>>> -phil. >>>>>>>>> >>>>>>>>> On 01/21/2016 01:45 AM, prasanta sadhukhan wrote: >>>>>>>>>> Hi Phil, >>>>>>>>>> >>>>>>>>>> Please find the updated webrev >>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.01/ >>>>>>>>>> which do away with the change in ServiceUI. >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Prasanta >>>>>>>>>> On 1/21/2016 2:59 AM, Phil Race wrote: >>>>>>>>>>> The changes in ServiceUI seem like they can cause the spec. >>>>>>>>>>> to be contradicted. >>>>>>>>>>> It says >>>>>>>>>>> >>>>>>>>>>> * @param gc used to select screen. null means primary or >>>>>>>>>>> default screen. >>>>>>>>>>> >>>>>>>>>>> but you update the code such that it will use the active >>>>>>>>>>> window. >>>>>>>>>>> If that is on a secondary screen but null was passed in. >>>>>>>>>>> >>>>>>>>>>> I am not entirely sure why ServiceUI needs to be changed at >>>>>>>>>>> all. >>>>>>>>>>> It is just the caller of ServiceUI .. >>>>>>>>>>> >>>>>>>>>>> -phil. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 01/20/2016 03:08 AM, prasanta sadhukhan wrote: >>>>>>>>>>>> Hi All, >>>>>>>>>>>> >>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8138749 >>>>>>>>>>>> webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> Please review a fix for a long standing issue whereby it is >>>>>>>>>>>> seen that >>>>>>>>>>>> PrinterJob.printDialog(attr set) does not support >>>>>>>>>>>> multi-monitor setup. When this API is invoked, the print >>>>>>>>>>>> dialog is always displayed on the default screen device >>>>>>>>>>>> regardless of where the application is running. >>>>>>>>>>>> This is because this method >>>>>>>>>>>> uses ServiceDialog class for creating the dialog and that >>>>>>>>>>>> indeed supports passing a GC in which we would like to have >>>>>>>>>>>> the dialog. But printer job always uses the GraphicsConfig >>>>>>>>>>>> of the default screen device >>>>>>>>>>>> resulting in print dialog to be shown on primary >>>>>>>>>>>> device/monitor. >>>>>>>>>>>> >>>>>>>>>>>> I have not considered pageDialog() for this fix. Will >>>>>>>>>>>> create a separate bugid and send a patch for that as well >>>>>>>>>>>> once this fix is approved. >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> Prasanta >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> > From philip.race at oracle.com Thu Feb 11 01:35:57 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 10 Feb 2016 17:35:57 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8149593: Change foo to {@code foo} in TIFF plugin classes In-Reply-To: <3833682F-20D0-4166-958D-2C3CC4ADDFC0@oracle.com> References: <2033706E-E18F-42C0-8941-B0361D2DF82F@oracle.com> <56BBBAC9.5030308@oracle.com> <8E400C3D-15F5-4606-8975-C9B0DD93F2AE@oracle.com> <3833682F-20D0-4166-958D-2C3CC4ADDFC0@oracle.com> Message-ID: <56BBE57D.3000603@oracle.com> +1 My eyes were glazing over but since it seems to have correctly handled tricky changes like this one below it seems probable to all be good. - *

The default implementation callsdecodeRaw(byte[] b, - * ...) and copies the resulting data intos. + *

The default implementation calls {@code decodeRaw(byte[] b, + * ...)} and copies the resulting data into {@code s}. -phil. On 2/10/16, 2:57 PM, Brian Burkhalter wrote: > I re-ran the script on the .00 version of the patch and it seems to > have fixed the problem: > > http://cr.openjdk.java.net/~bpb/8149593/webrev.01/ > > > Please let me know should I have botched anything else. ;-) > > Thanks, > > Brian > > On Feb 10, 2016, at 2:47 PM, Brian Burkhalter > > wrote: > >> Apparently not. It?s a decade old script. I?ll check it out. Thanks >> for the catch. Perhaps I could just run it N times instead? >> >> Brian >> >> On Feb 10, 2016, at 2:33 PM, Phil Race > > wrote: >> >>> Does your transmogrifier work where there is more than one per line ? >>> >>> I expected both to be changed here : >>> - * theJPEGTables. Default value isnull. >>> + * the {@code JPEGTables}. Default value isnull. >>> >>> -phil. >>> >>> On 02/10/2016 01:41 PM, Brian Burkhalter wrote: >>>> Please review at your convenience. >>>> >>>> Issue:https://bugs.openjdk.java.net/browse/JDK-8149593 >>>> Patch:http://cr.openjdk.java.net/~bpb/8149593/webrev.00/ >>>> >>>> >>>> Summary: Transmogrify ?foo? to ?{@code foo}?. The >>>> patch is long but the changes are all the same (quotation marks >>>> omitted): >>>> >>>> 1. ?" changed to ?{@code ?. >>>> 2. ?? change to ?}? >>>> 3. ?2015,? changed to ?2016," >>>> >>>> >>>> Both the source and the docs builds succeed, the latter with no >>>> errors or warning in these affected classes. >>>> >>>> Thanks, >>>> >>>> Brian >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Feb 11 03:12:47 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 10 Feb 2016 19:12:47 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8149593: Change foo to {@code foo} in TIFF plugin classes In-Reply-To: <56BBE57D.3000603@oracle.com> References: <2033706E-E18F-42C0-8941-B0361D2DF82F@oracle.com> <56BBBAC9.5030308@oracle.com> <8E400C3D-15F5-4606-8975-C9B0DD93F2AE@oracle.com> <3833682F-20D0-4166-958D-2C3CC4ADDFC0@oracle.com> <56BBE57D.3000603@oracle.com> Message-ID: <9AAF6EF0-25D0-4CB8-8112-AE448EC22878@oracle.com> I don?t think that there was any problem with the script, just operator error. I?ll double check it and push it tomorrow morning PT. Thanks, Brian On Feb 10, 2016, at 5:35 PM, Philip Race wrote: > +1 > > My eyes were glazing over but since it seems to have correctly > handled tricky changes like this one below it seems probable to all be good. > > - *

The default implementation calls decodeRaw(byte[] b, > - * ...) and copies the resulting data into s. > + *

The default implementation calls {@code decodeRaw(byte[] b, > + * ...)} and copies the resulting data into {@code s}. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bourges.laurent at gmail.com Thu Feb 11 08:12:25 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 11 Feb 2016 09:12:25 +0100 Subject: [OpenJDK 2D-Dev] RFR 8149338: JVM Crash caused by Marlin renderer not handling NaN coordinates In-Reply-To: <56BBAB33.3070104@oracle.com> References: <56B92150.8030007@oracle.com> <56BA7A69.5050703@oracle.com> <56BBAB33.3070104@oracle.com> Message-ID: Pushed: http://hg.openjdk.java.net/jdk9/client/jdk/rev/3eda6cd3f504 Thanks for your reviews ! Laurent 2016-02-10 22:27 GMT+01:00 Jim Graham : > Looks good... > > ...jim > > On 2/10/16 12:52 PM, Laurent Bourg?s wrote: > >> Jim & Phil, >> >> Here is the updated webrev: >> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8149338.1/ >> >> I just simplified the exception handling code in both TextClipErrorTest >> and CrashNaNTest >> >> Cheers, >> Laurent >> >> 2016-02-10 0:46 GMT+01:00 Jim Graham > >: >> >> Let me know if/when you have an updated webrev. It should be good >> to go, but it couldn't hurt to publish one for the archives... >> >> ...jim >> >> On 2/9/16 12:51 AM, Laurent Bourg?s wrote: >> >> Jim, >> >> Here are my answers to your 2 questions: >> >> 2016-02-09 0:14 GMT+01:00 Jim Graham > >> > >>>: >> >> >> In the test case, why are you using a log handler to check >> for a >> particular exception? Shouldn't any exception logged be >> cause for a >> test failure? >> >> >> I already used that code in 1 other test: TextClipErrorTest. I >> agree it >> can be simpler to report any exception like: >> public void publish(LogRecord record) { >> Throwable th = record.getThrown(); >> // detect any Throwable: >> if (th != null) { >> System.out.println("Test failed:\n" + >> record.getMessage()); >> th.printStackTrace(System.out); >> >> throw new RuntimeException("Test failed: >> ", th); >> } >> } >> >> Is there a reason why you reversed the calculations for the >> slope at >> line 374? >> >> + final double slope = (x1d - x2) / (y1d - y2); >> >> I prefer this syntax as it is more explicit that (x1d - x2) and >> (y1d - >> y2) are double values (not implicit promotion). >> >> Cheers, >> Laurent >> >> >> -- -- Laurent Bourg?s -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ivanov at oracle.com Thu Feb 11 14:19:12 2016 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Thu, 11 Feb 2016 17:19:12 +0300 Subject: [OpenJDK 2D-Dev] [8u-dev] Request for review and approval for bug 8147807: crash in libkcms.so on linux-sparc Message-ID: <56BC9860.7050006@oracle.com> Hello, Could you please review the fix for JDK-8147807 and approve push to 8u-dev? JBS: https://bugs.openjdk.java.net/browse/JDK-8147807 Webrev: http://cr.openjdk.java.net/~aivanov/8147807/jdk8/webrev.00/ The issue is not relevant to jdk 9. The fix just removes kcms service leaving lcms as the only option which is the default in jdk8. Thanks in advance, Alexey From jayathirth.d.v at oracle.com Thu Feb 11 14:37:56 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 11 Feb 2016 06:37:56 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED Message-ID: <2c9221dc-ed76-481a-8bee-a694d313448e@default> Hi, Please review the following fix in JDK9: Bug : https://bugs.openjdk.java.net/browse/JDK-7116979 Webrev : http://cr.openjdk.java.net/~jdv/7116979/webrev.00/ Issue : When Image containing black pixels are converted from any format to Byte Indexed format some of the pixels are not black. They are following pattern similar to dithering. Root cause : When we convert any format type to ByteIndexed we are adding Error delta values to R,G,B components using dithering indices. This is causing some pixels values to not point to proper index in color table. Solution : There is no need to add error delta for primary colors containing basic values in R,G,B components. Exclude such pixels from delta addition. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Thu Feb 11 22:20:50 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 11 Feb 2016 14:20:50 -0800 Subject: [OpenJDK 2D-Dev] RFR 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering In-Reply-To: References: <56B3F68F.3070204@oracle.com> <56B3F8C3.7040609@oracle.com> <56B917CC.5090806@oracle.com> <56BA8BBF.9070609@oracle.com> Message-ID: <56BD0942.1060007@oracle.com> It all looks great. The comments are fine for internal documentation, but here is a suggestion for the initial comment on a couple of the Provider classes. I don't need to review the changes to comments. (NOTE: Watch out for trailing white space on these if you cut and past them back as the process of cutting and pasting the original comments from your webrev into my email buffer may have added trailing spaces...) /** * This abstract ReentrantContextProvider helper class manages the creation, * storage, and retrieval of concrete ReentrantContext instances which can be * subclassed to hold cached contextual data. * * It supports reentrancy as every call to acquire() provides a new unique context * instance that must later be returned for reuse by a call to release(ctx) * (typically in a try/finally block). * * It has a couple of abstract implementations which store references in a queue * and/or thread-local storage. * The Providers can be configured to hold ReentrantContext instances in memory * using hard, soft or weak references. * * The acquire() and release() methods are used to retrieve and return the contexts. * * The {@code newContext()} method remains abstract in all implementations and * must be provided by the module to create a new subclass of ReentrantContext * with the appropriate contextual data in it. * * Sample Usage: ... (And probably add a back pointer to the context class at the end of that comment:) * @see ReentrantContext */ Some suggestions on RCPTL: /** * This ReentrantContextProvider implementation uses a ThreadLocal to hold * the first ReentrantContext per thread and a ReentrantContextProviderCLQ to * store child ReentrantContext instances needed during recursion. * * Note: this implementation may keep up to one context in memory per thread. * Child contexts for recursive uses are stored in the queue using a WEAK * reference by default unless specified in the 2 argument constructor. * * @param ReentrantContext subclass */ ...jim On 2/10/16 2:25 PM, Laurent Bourg?s wrote: > Jim, > > Here is the updated webrev: > http://cr.openjdk.java.net/~lbourges/marlin/marlin-8148886.4/ > > Changes: > - HardReference adopted: it simplified the code as I removed the wrapper > / factory classes but also allowed me to apply generic types: > Reference instead of Object > - ReentrantContextProviderTL: added a constructor with 2 reference types > (TL / CLQ), the default one uses weak reference for CLQ > - added javadoc in ReentrantContext* classes: please correct my english > sentences ! > I am not fluent enough to write clearly such documentation and I do not > know how much details are needed or not as it is a internal API. > > About the only simplifying suggestion I might have is that if you > can subclass Reference and create HardReference extends > Reference with an obvious implementation, then you wouldn't have > to special case the HARD type and you could get rid of a lot of your > use of raw "Object" references and replace them with generified > code. Unfortunately Reference is not subclassable outside the > java.lang.ref package. I looked online and found a number of people > considering subclassing a HardReference variant off of WeakReference > - as long as the subclass keeps a hard reference the referent in the > super class is not relevant. That mechanism may be a little clunky, > but it would mean that you can always assume that the TL.get() and > CLQ.poll() are returning a Reference and just call get() on it > without having to use a factory/accessor. > > > That's absolutely what I always needed ! > Several times I wondered why no such HardReference exists in the > java.lang.reference package: > should we tell core-libs that it is really needed to improve homogeneity > / consistency ... and simplify such reference-based code ? > > public class HardReference extends WeakReference { > private final T strongRef; > public HardReference(T obj) { > super(null); > this.strongRef = obj; > } > public T get() { return strongRef; } > } > > > I added such class in ReentrantContextProvider but I did not use > 'super(null)'. What is the aim ? > Does it simplify the reference processing ? Of course such HardReference > does not need any reference queue... > > Another way to crack that egg would be to simply embed the following > code where you call the resolveReference methods: > ctx = (obj instanceof Reference) ? ((Reference) > obj).get() : ((K) obj); > (No need for a null test there because instanceof ensures > non-nullness and you don't care about which form of reference it is > since they all share the same get() method.) > > > It was the case before in MarlinRenderingEngine but I wanted to avoid > most conditional statements ... . > > If you made either of those changes then the Wrapper classes would > only exist to create the appropriate Reference object and could be > left as factories or simply be replaced with a wrap(ctx) method in > the parent with a switch statement in it. Since it is only called > on construction, the switch statement should have negligible > overhead and eliminate 4 inner classes (parent Wrapper and 3 flavors > of Wrapper). > > > Wrapped in ReentrantContextProvider.getOrCreateReference(ctx). > > Thanks for your suggestions, > Laurent > From james.graham at oracle.com Thu Feb 11 22:35:23 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 11 Feb 2016 14:35:23 -0800 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED In-Reply-To: <2c9221dc-ed76-481a-8bee-a694d313448e@default> References: <2c9221dc-ed76-481a-8bee-a694d313448e@default> Message-ID: <56BD0CAB.6080704@oracle.com> Hi Jayathirth, Did you do any performance analysis of this change? You are adding 6 tests and multiple branches to per-pixel code. The effectiveness of this technique depends on the colormap that we have set up. For the BufferedImage.TYPE_INDEXED constructor we produce a fairly nice colormap, but if someone creates a custom colormap then the colors could be anything. We create a decent inversion for just about any colormap, but that doesn't mean that using only "the best match for solid red" will produce a better result for a dithered approximation for red. It is true that if there is a really good match for red then we should just use that, but if there are no direct matches for red then we may choose to paint a red region with solid orange even though there is another color in the colormap that when mixed with orange approximates a red tone better. For example, if a colormap contains no pure red, but contains: 240, 20, 0 240, 0, 20 (I'm not sure if 20 is within our current error deltas that we use for dithering, but this is an example not a test case.) Then using one of these alone might skew the color towards orange or purple. Using both together in a dither pattern might keep the overall hue impression as red, but with a small amount of noise in its saturation. What types of colormaps was this tested with? ...jim On 2/11/16 6:37 AM, Jayathirth D V wrote: > Hi, > > _Please review the following fix in JDK9:_ > > __ > > Bug : https://bugs.openjdk.java.net/browse/JDK-7116979 > > Webrev : http://cr.openjdk.java.net/~jdv/7116979/webrev.00/ > > Issue : When Image containing black pixels are converted from any format > to Byte Indexed format some of the pixels are not black. They are > following pattern similar to dithering. > > Root cause : When we convert any format type to ByteIndexed we are > adding Error delta values to R,G,B components using dithering indices. > This is causing some pixels values to not point to proper index in color > table. > > Solution : There is no need to add error delta for primary colors > containing basic values in R,G,B components. Exclude such pixels from > delta addition. > > Thanks, > > Jay > From brian.burkhalter at oracle.com Thu Feb 11 22:58:59 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 11 Feb 2016 14:58:59 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8149593: Change foo to {@code foo} in TIFF plugin classes In-Reply-To: <9AAF6EF0-25D0-4CB8-8112-AE448EC22878@oracle.com> References: <2033706E-E18F-42C0-8941-B0361D2DF82F@oracle.com> <56BBBAC9.5030308@oracle.com> <8E400C3D-15F5-4606-8975-C9B0DD93F2AE@oracle.com> <3833682F-20D0-4166-958D-2C3CC4ADDFC0@oracle.com> <56BBE57D.3000603@oracle.com> <9AAF6EF0-25D0-4CB8-8112-AE448EC22878@oracle.com> Message-ID: <6B3D4F97-38FF-4378-ADC6-D7BE030500A0@oracle.com> Code pushed. To be certain I fixed the bug in my script, ran it against the same code, and compared the results. As the results were the same, it looked good. Brian On Feb 10, 2016, at 7:12 PM, Brian Burkhalter wrote: > I don?t think that there was any problem with the script, just operator error. > > I?ll double check it and push it tomorrow morning PT. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Fri Feb 12 02:00:49 2016 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 11 Feb 2016 18:00:49 -0800 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8148914: BitDepth.java test fails Message-ID: <56BD3CD1.7080701@oracle.com> Hello, Please review a candidate fix for JDK-8148914: BitDepth.java test fails In brief, OpenJDK supports two fewer buffered image formats for jpg than the closed JDK does. I've modified the BitDepth test to allow for this difference. Patch below; webrev at http://cr.openjdk.java.net/~darcy/8148914.0/ Thanks, -Joe --- a/test/javax/imageio/plugins/shared/BitDepth.java Thu Feb 11 16:24:55 2016 -0800 +++ b/test/javax/imageio/plugins/shared/BitDepth.java Thu Feb 11 17:26:23 2016 -0800 @@ -130,11 +130,7 @@ boolean allOK = true; - for (int i = 0; i < biRGBTypes.length; i++) { - - int type = biRGBTypes[i]; - - + for (int type : biRGBTypes) { // TODO: remove the following 'if' block after the 8147448 fix if ( format.toLowerCase().equals("bmp") && ( (type == BufferedImage.TYPE_INT_ARGB ) || @@ -151,12 +147,23 @@ System.out.println("Testing " + format + " writer for type " + biTypeNames[type]); - File f = testWriteRGB(format, type); - boolean ok = testReadRGB(f); - if (ok) { - f.delete(); + boolean ok = false; + File f = null; + try { + f = testWriteRGB(format, type); + ok = testReadRGB(f); + } catch (javax.imageio.IIOException e) { + // The follow two formats are not supported on OpenJDK + if (format.toLowerCase().equals("jpg") && + (type == BufferedImage.TYPE_4BYTE_ABGR || + type == BufferedImage.TYPE_4BYTE_ABGR_PRE)) + continue; + } finally { + if (ok) { + f.delete(); + } + allOK = allOK && (ok || f == null); } - allOK = allOK && ok; } From alexey.ivanov at oracle.com Fri Feb 12 08:19:02 2016 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 12 Feb 2016 11:19:02 +0300 Subject: [OpenJDK 2D-Dev] [8u-dev] Request for review and approval for bug 8147807: crash in libkcms.so on linux-sparc In-Reply-To: <56BC9860.7050006@oracle.com> References: <56BC9860.7050006@oracle.com> Message-ID: <56BD9576.4090904@oracle.com> I forgot to add jdk8u-dev list... On 11.02.2016 17:19, Alexey Ivanov wrote: > Hello, > > Could you please review the fix for JDK-8147807 and approve push to > 8u-dev? > > JBS: https://bugs.openjdk.java.net/browse/JDK-8147807 > Webrev: http://cr.openjdk.java.net/~aivanov/8147807/jdk8/webrev.00/ > > The issue is not relevant to jdk 9. > > The fix just removes kcms service leaving lcms as the only option > which is the default in jdk8. > > > Thanks in advance, > Alexey From bourges.laurent at gmail.com Fri Feb 12 08:46:48 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Fri, 12 Feb 2016 09:46:48 +0100 Subject: [OpenJDK 2D-Dev] RFR 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering In-Reply-To: <56BD0942.1060007@oracle.com> References: <56B3F68F.3070204@oracle.com> <56B3F8C3.7040609@oracle.com> <56B917CC.5090806@oracle.com> <56BA8BBF.9070609@oracle.com> <56BD0942.1060007@oracle.com> Message-ID: Jim & Phil, 2016-02-11 23:20 GMT+01:00 Jim Graham : > It all looks great. The comments are fine for internal documentation, but > here is a suggestion for the initial comment on a couple of the Provider > classes. I don't need to review the changes to comments. > Thanks Jim for your carefull reviews and your suggestions: I integrated your changes to javadoc with care. FYI I always use the following command to remove redundant white spaces: find . -type f -name '*.java' -exec sed --in-place 's/[[:space:]]\+$//' {} \; To summarize, I can count on jim's review but another one is missing. Phil, do you approve too ? Regards, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Fri Feb 12 09:15:27 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 12 Feb 2016 09:15:27 +0000 Subject: [OpenJDK 2D-Dev] [8u-dev] Request for review and approval for bug 8147807: crash in libkcms.so on linux-sparc In-Reply-To: <56BD9576.4090904@oracle.com> References: <56BC9860.7050006@oracle.com> <56BD9576.4090904@oracle.com> Message-ID: <56BDA2AF.9000209@oracle.com> Approved for jdk8u-dev once you have a peer code review. Regards, Sean. On 12/02/2016 08:19, Alexey Ivanov wrote: > I forgot to add jdk8u-dev list... > > On 11.02.2016 17:19, Alexey Ivanov wrote: >> Hello, >> >> Could you please review the fix for JDK-8147807 and approve push to >> 8u-dev? >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8147807 >> Webrev: http://cr.openjdk.java.net/~aivanov/8147807/jdk8/webrev.00/ >> >> The issue is not relevant to jdk 9. >> >> The fix just removes kcms service leaving lcms as the only option >> which is the default in jdk8. >> >> >> Thanks in advance, >> Alexey > From alexander.v.stepanov at oracle.com Fri Feb 12 10:35:47 2016 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Fri, 12 Feb 2016 13:35:47 +0300 Subject: [OpenJDK 2D-Dev] RFR: add regression test for JDK-8144991 Message-ID: <56BDB583.5020806@oracle.com> Hello, Could you please review the following fix http://cr.openjdk.java.net/~avstepan/8149558/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8149558 Just a single regression test added (still failing), plus minor correction for other test. Thanks, Alexander From magnus.ihse.bursie at oracle.com Fri Feb 12 11:25:19 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 12 Feb 2016 12:25:19 +0100 Subject: [OpenJDK 2D-Dev] [8u-dev] Request for review and approval for bug 8147807: crash in libkcms.so on linux-sparc In-Reply-To: <56BDA2AF.9000209@oracle.com> References: <56BC9860.7050006@oracle.com> <56BD9576.4090904@oracle.com> <56BDA2AF.9000209@oracle.com> Message-ID: <56BDC11F.6000403@oracle.com> On 2016-02-12 10:15, Se?n Coffey wrote: > Approved for jdk8u-dev once you have a peer code review. Makefile change look good. /Magnus > > Regards, > Sean. > > On 12/02/2016 08:19, Alexey Ivanov wrote: >> I forgot to add jdk8u-dev list... >> >> On 11.02.2016 17:19, Alexey Ivanov wrote: >>> Hello, >>> >>> Could you please review the fix for JDK-8147807 and approve push to >>> 8u-dev? >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8147807 >>> Webrev: http://cr.openjdk.java.net/~aivanov/8147807/jdk8/webrev.00/ >>> >>> The issue is not relevant to jdk 9. >>> >>> The fix just removes kcms service leaving lcms as the only option >>> which is the default in jdk8. >>> >>> >>> Thanks in advance, >>> Alexey >> > From alexandr.scherbatiy at oracle.com Fri Feb 12 20:16:02 2016 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Sat, 13 Feb 2016 00:16:02 +0400 Subject: [OpenJDK 2D-Dev] [9] Review request for 8142966 Wrong cursor position in text components on HiDPI display In-Reply-To: <56B9FE27.4040204@oracle.com> References: <56A935F0.5060504@oracle.com> <56B4FA69.9000604@oracle.com> <56B6112F.1050708@oracle.com> <56B8E930.9000405@oracle.com> <56B9FC1F.9090607@oracle.com> <56B9FE27.4040204@oracle.com> Message-ID: <56BE3D82.5010506@oracle.com> On 09/02/16 18:56, Sergey Bylokhov wrote: > Also probably it will be possible to test this via the public api > only(using the mix of the graphics transform + font transform). > > On 09.02.16 17:47, Sergey Bylokhov wrote: >> Some additional information. >> The Swing calculates the size of the components and location of the >> cursor based on the text metrics. And these text metrics based on >> advance. The Swing do not know to what destination it will be painted, >> it calculates the size based on the non-scaled(non-retina) destination. >> The problem occurs when we paint such component to the hidpi screen, >> because we get small round errors per glyph -> this causes a visible >> issue? when the text string is long. As a solution on the macosx the >> round operation was done in the users space instead of dev space. >> >> For example before the fix the size 1.4px was rounded to 3 (1.4 * 2 = >> 2.8 -> 3), but after the fix it will be 2 (1.4-> 1 * 2 = 2). So the >> Swing will be able to calculate correct size/location without >> information of the device scale. Note that the 3px(in dev space) is a >> kind of fractional coordinate in the user space(1.5). And the Swing does >> not work properly when fractional metrics are used, because it use ints >> as a coordinates. >> >> Note that the fix should be applied only when fractional metrics is off, >> otherwise we should not use any rounding. I am not sure that the current >> fix take it into account. The proposed fix is applied only when the fractional metrics are off. >> >> >> On 08.02.16 22:14, Jim Graham wrote: >>> Isn't the problem there that we are returning an integer as the >>> advance? >>> Why aren't we returning 7.35 as a value instead of 8? 7.35 is returned when fractional metrics are on. >>> >>> Also, shouldn't 7.35 round to 7 and 14.7 round to 15? This happens because when fractional metrics are on the glyph linearAdvance value is returned (for current case ftglyph->linearHoriAdvance = 7.35). But when fractional metrics are off the glyph advance is returned (ftglyph->advance.x = 8). This calculation is done by freetype library. Thanks, Alexandr. >>> >>> ...jim >>> >>> On 2/6/2016 7:28 AM, Alexander Scherbatiy wrote: >>>> On 05/02/16 23:39, Phil Race wrote: >>>>> Two things strike me when I read this >>>>> >>>>> 1) Initial surprise at how deep into the font code it goes. >>>>> Perhaps there are alternatives. >>>>> >>>>> 2) That it changes to using the linear metrics for measuring advance. >>>>> Regardless of (1) I do not think (2) is correct. I am fairly sure >>>>> this >>>>> will lead to changes in text advance. It seems like it must throw >>>>> away adjusted metrics as a result of glyph hinting. >>>>> >>>>> I don't know what the fix should be, since I have not looked at the >>>>> problem top-down, I am just seeing the bottom-up proposed solution. >>>>> So all I can say for now is that it needs to be at least somewhat >>>>> different. >>>> >>>> There was the same issue on Mac OS X which has been fixed in the >>>> similar way: >>>> 8013569 [macosx] JLabel preferred size incorrect on retina displays >>>> with non-default font size >>>> https://bugs.openjdk.java.net/browse/JDK-8013569 >>>> http://cr.openjdk.java.net/~serb/7190349/webrev.04/ >>>> >>>> The problem is that in many case for UI scale 2 we return to a user >>>> an unscaled value. >>>> But a value for transformed glyph advance, rounded and descaled can >>>> differ from just rounded glyph advance. >>>> >>>> For example, font[dialog, plain, 12] char 'a': >>>> transform: 12, advance: 7.35, rounded advance: 8 >>>> transform: 24, advance: 14.70 round advance: 14 >>>> >>>> and 8 does not equal 14 / 2. >>>> >>>> The solution for Mac OS X was to get the glyph advance using only >>>> font transform, round it and then apply the dev transform: >>>> >>>> CGGlyphImages.m: >>>> 481 advance = CGSizeApplyAffineTransform(advance, >>>> strike->fFontTx); >>>> 482 if (!JRSFontStyleUsesFractionalMetrics(strike->fStyle)) { >>>> 483 advance.width = round(advance.width); >>>> 484 advance.height = round(advance.height); >>>> 485 } >>>> 486 advance = CGSizeApplyAffineTransform(advance, >>>> strike->fDevTx); >>>> >>>> Thanks, >>>> Alexandr. >>>>> >>>>> -phil. >>>>> >>>>> On 01/27/2016 01:26 PM, Alexander Scherbatiy wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Could you review the fix: >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8142966 >>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8142966/webev.00/ >>>>>> >>>>>> The proposed fix rounds a glyph advance first and then scales it if >>>>>> UI scales do not equal to one. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>> >>>> >> >> > > From alexandr.scherbatiy at oracle.com Fri Feb 12 20:54:18 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Fri, 12 Feb 2016 12:54:18 -0800 Subject: [OpenJDK 2D-Dev] [9] Review request for 8076545 Text size is twice bigger under Windows L&F on Win 8.1 with HiDPI display In-Reply-To: <56B91F12.9070909@oracle.com> References: <5596C117.1040806@oracle.com> <559DB2FB.5000208@oracle.com> <55A902D4.1050603@oracle.com> <563208A9.50702@oracle.com> <56328355.1010608@oracle.com> <5633C7C8.2030804@oracle.com> <5649E312.2010606@oracle.com> <564A41D3.5010202@oracle.com> <564A4DE9.1040102@oracle.com> <56ABB269.6030808@oracle.com> <56ABD6B2.10302@oracle.com> <56AF4F4C.4030504@oracle.com> <56B00B8B.9040102@oracle.com> <56B47579.3090309@oracle.com> <56B4FA0A.3080505@oracle.com> <56B60EE4.2070501@oracle.com> <56B91F12.9070909@oracle.com> Message-ID: <56BE467A.8060403@oracle.com> On 2/8/2016 3:04 PM, Jim Graham wrote: > I don't understand the issue with the fonts that you are saying have > different sizes for different DPIs. Those are pixel sizes, aren't > they? They still need to be turned into user-space units for our > applications to know what to do with them. Or, are you saying that > they are not representing pixel sizes as the rest of the font units do > and so they are already in DPI-relative "user space" units? > > AT 192 DPI, oemFixed.font is 18, but are they saying 18 pixels? Which > would be a 9-point font in our automatically scaled coordinate > systems, wouldn't it? The font size in the AwtDesktopProperties is calculated as (tmHeight - tmInternalLeading) values from TEXTMETRIC: jint pointSize = metrics.tmHeight - metrics.tmInternalLeading; According to MSDN "All sizes are specified in logical units; that is, they depend on the current mapping mode of the display context." The calculated size value is proportional to the scale factor for the fonts like win.frame.captionFont : DPI 96 (scale 100%), size: 15 DPI 144 (scale 150%), size: 23 DPI 192 (scale 200%), size: 30 That means that for each DPI it is possible to scale down the font size to its base value just using the formula: baseFontSize = fontSize / scaleFactor However, for win.ansiFixed.font the TEXTMETRIC returns the same values for each display DPI: DPI 96 (scale 100%), size: 13 DPI 144 (scale 150%), size: 13 DPI 192 (scale 200%), size: 13 Now scaling the size down for DPI 192 ( 13/ 2) it does not give the font size for the DPI 96. That is why the scale factor 1.0 is used in this case in the fix. Thanks, Alexandr. > > ...jim > > On 2/6/16 7:19 AM, Alexander Scherbatiy wrote: >> On 2/5/2016 11:37 AM, Jim Graham wrote: >>> Hi Alexandr, >>> >>> awt_DesktopProperties.cpp, line 300 - is the "1.0f /" a typo? >> Sorry. Here is the updated fix without the typo: >> http://cr.openjdk.java.net/~alexsch/8076545/webrev.06/ >>> >>> Also, is there a still a need for the setFontProperty() variants that >>> don't have a scale as the last parameter? >> There are fonts like win.ansiFixed.font, win.ansiVar.font, and >> win.deviceDefault.font which size is the same for any display DPI. >> >> And there are fonts like win.oemFixed.font, win.system.font, and >> win.systemFixed.font which have one size for DPI 96 and another size for >> all other DPI. >> For example win.oemFixed.font: >> DPI 96, size: 12 >> DPI 144, size: 18 >> DPI 192, size: 18 >> DPI 240, size: 18 >> >> I left them unscaled but may be it is better to have one >> precalculated scale for this fonts which is used when DPI is not 96. >> >> I updated the setFontProperty() method without scale parameter usage >> to call with scale 1.0f. >> >> Thanks, >> Alexandr. >> >>> >>> ...jim >>> >>> On 2/5/2016 2:12 AM, Alexandr Scherbatiy wrote: >>>> >>>> Could you review the updated fix: >>>> http://cr.openjdk.java.net/~alexsch/8076545/webrev.05 >>>> >>>> - The awt_DesktopProperties.cpp file is updated to use scaleX for >>>> width rescaling and scaleY for height rescaling >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 2/1/2016 5:51 PM, Jim Graham wrote: >>>>> Hi Alexandr, >>>>> >>>>> In awt_DesktopProperties.cpp you are using the Y scaling factor to >>>>> scale widths still - see lines 287 (and others in that same function) >>>>> and then 322 in another function. It looks like you'll need >>>>> getInvScaleX() and getInvScaleY(). >>>>> >>>>> I'll leave it to Phil to comment on the unit test... >>>>> >>>>> ...jim >>>>> >>>>> On 2/1/16 4:27 AM, Alexandr Scherbatiy wrote: >>>>>> >>>>>> Could you review the updated fix: >>>>>> http://cr.openjdk.java.net/~alexsch/8076545/webrev.04/ >>>>>> >>>>>> - both LOGPIXELSX and Y are used for the theme size scaling. >>>>>> - LOGPIXELSY is used for text metrics height rescaling >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> On 1/29/2016 1:16 PM, Jim Graham wrote: >>>>>>> Hi Alexandr, >>>>>>> >>>>>>> Thanks for investigating the behaviors. >>>>>>> >>>>>>> With respect to using LOGPIXELSX or Y, these methods are used to >>>>>>> scale >>>>>>> both horizontal and vertical measurements so we really should >>>>>>> have 2 >>>>>>> scale values and rescale methods, one for horizontal use and one >>>>>>> for >>>>>>> vertical... >>>>>>> >>>>>>> ...jim >>>>>>> >>>>>>> On 1/29/2016 10:41 AM, Alexandr Scherbatiy wrote: >>>>>>>> Could you review the updated fix: >>>>>>>> http://cr.openjdk.java.net/~alexsch/8076545/webrev.03 >>>>>>>> >>>>>>>> - LOGPIXELSX is changed to LOGPIXELSY >>>>>>>> >>>>>>>> On 11/16/2015 1:43 PM, Jim Graham wrote: >>>>>>>>> Note that LOGPIXELSY is global and static between reboots so it >>>>>>>>> doesn't really matter which monitor is used to get the value. >>>>>>>>> >>>>>>>>> Also, the issue is that the measurements are in pixels, so if we >>>>>>>>> convert them into a resolution independent measurement then the >>>>>>>>> rest >>>>>>>>> of the scaling in the AWT/2D will be correct regardless of any >>>>>>>>> given >>>>>>>>> monitor's resolution. We just have to make sure the >>>>>>>>> "de-pixelization" >>>>>>>>> of the measurement is an apples-to-apples calculation. >>>>>>>>> >>>>>>>>> The question in my mind is whether the values they get from >>>>>>>>> GetTheme*() and SPI_GETNONCLIENTMETRICS are relative to >>>>>>>>> LOGPIXELSY, or >>>>>>>>> the more recent Per-Monitor aware DPI APIs, or ...? It would be >>>>>>>>> interesting to see what happens to those values when you >>>>>>>>> change the >>>>>>>>> DPI settings on Windows 8.1 and not reboot. If they stay constant >>>>>>>>> until you reboot then LOGPIXELSY on the main screen would be the >>>>>>>>> value >>>>>>>>> to use to de-scale them... >>>>>>>> >>>>>>>> I tried to use the "Change the size of all items" slider on >>>>>>>> Windows >>>>>>>> 8.1 without rebooting. >>>>>>>> GetDpiForMonitor() returns the updated DPI values: 192, >>>>>>>> 144, 96 >>>>>>>> LOGPIXELSY returns unchanged values: 192, 192, 192 >>>>>>>> SystemParametersInfo(SPI_GETNONCLIENTMETRICS,...) returns >>>>>>>> unchanged >>>>>>>> NONCLIENTMETRICS >>>>>>>> GetThemePartSize() returns unchanged theme part sizes >>>>>>>> >>>>>>>> It seems that theme part sizes behave in the same way as the >>>>>>>> LOGPIXELSY in this case. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>>> >>>>>>>>> ...jim >>>>>>>>> >>>>>>>>> On 11/16/2015 12:51 PM, Phil Race wrote: >>>>>>>>>> That seems better. But one more question to get a point >>>>>>>>>> clarified. >>>>>>>>>> You are using getDesktopWindow() which is for the primary >>>>>>>>>> monitor. >>>>>>>>>> I assume that the 'inversion' results in the value being used >>>>>>>>>> to be >>>>>>>>>> independent >>>>>>>>>> of the monitor in a multi-mon situation and so when we move to >>>>>>>>>> a 2nd >>>>>>>>>> monitor >>>>>>>>>> that inverted size remains valid ? >>>>>>>>>> >>>>>>>>>> If so looks good to me. >>>>>>>>>> >>>>>>>>>> -phil. >>>>>>>>>> >>>>>>>>>> On 11/16/2015 06:07 AM, Alexander Scherbatiy wrote: >>>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> Could you review the updated fix: >>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8076545/webrev.02 >>>>>>>>>>> >>>>>>>>>>> - round is used instead of ceil >>>>>>>>>>> - inverted scales are used >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 10/30/2015 10:40 PM, Jim Graham wrote: >>>>>>>>>>>> In this case round may be better. ceil() is more for cases >>>>>>>>>>>> where you >>>>>>>>>>>> needed "at least X amount of room", but I don't think a font >>>>>>>>>>>> size is >>>>>>>>>>>> an "at least this much" kind of case. >>>>>>>>>>>> >>>>>>>>>>>> Also, I've been toying with the idea that use of ceil() and >>>>>>>>>>>> floor() >>>>>>>>>>>> in any DPI-adjustment equations should really be "ceil(val - >>>>>>>>>>>> epsilon)" or "floor(ceil + epsilon)" for some small value of >>>>>>>>>>>> epsilon >>>>>>>>>>>> chosen just large enough to prevent various round-off errors >>>>>>>>>>>> from >>>>>>>>>>>> affecting the outcome. One idea is for 1/256 as the value of >>>>>>>>>>>> epsilon >>>>>>>>>>>> since that could equate to the smallest measurable >>>>>>>>>>>> difference in >>>>>>>>>>>> terms of alpha or interpolation results (or 1/512 for "half >>>>>>>>>>>> the >>>>>>>>>>>> smallest quantum")... >>>>>>>>>>>> >>>>>>>>>>>> ...jim >>>>>>>>>>>> >>>>>>>>>>>> On 10/29/15 1:36 PM, Phil Race wrote: >>>>>>>>>>>>> size->cx = (int)ceil(size->cx / scale); >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> So if size->cx / scale works out to be 12.0001 you will round >>>>>>>>>>>>> it up >>>>>>>>>>>>> to 13? >>>>>>>>>>>>> >>>>>>>>>>>>> Can you check what pixel size windows gives you in such a >>>>>>>>>>>>> case ? >>>>>>>>>>>>> I'd be a little surprised if they did that rather than round. >>>>>>>>>>>>> >>>>>>>>>>>>> Is the SetFontProperty that does not accept a scale parameter >>>>>>>>>>>>> still >>>>>>>>>>>>> used >>>>>>>>>>>>> somewhere ? >>>>>>>>>>>>> >>>>>>>>>>>>> -phil. >>>>>>>>>>>>> >>>>>>>>>>>>> On 10/29/2015 04:53 AM, Sergey Bylokhov wrote: >>>>>>>>>>>>>> On 17.07.15 16:27, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - Sergey's point about multi-mon should be checked out. >>>>>>>>>>>>>>> Windows 8.1 has option "Let me choose one scaling >>>>>>>>>>>>>>> level >>>>>>>>>>>>>>> for >>>>>>>>>>>>>>> all my >>>>>>>>>>>>>>> displays". >>>>>>>>>>>>>>> If I unset it I am able to change the size of all >>>>>>>>>>>>>>> items. >>>>>>>>>>>>>>> However, >>>>>>>>>>>>>>> the DPI which returns GetDPIForMonitor is still 2 on HiDPI >>>>>>>>>>>>>>> displays. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This version looks fine, but I am sure it can be double >>>>>>>>>>>>>> checked on >>>>>>>>>>>>>> windows 10 at some moment as well. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >> From bourges.laurent at gmail.com Sat Feb 13 13:31:14 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Sat, 13 Feb 2016 14:31:14 +0100 Subject: [OpenJDK 2D-Dev] RFR 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering In-Reply-To: References: <56B3F68F.3070204@oracle.com> <56B3F8C3.7040609@oracle.com> <56B917CC.5090806@oracle.com> <56BA8BBF.9070609@oracle.com> <56BD0942.1060007@oracle.com> Message-ID: One more review, please ! I would like pushing this patch asap: it fixes a SEGFAULT. PS: the new generic ReentrantContext providers may benefit to other java2d cached data... Regards, Laurent Le 12 f?vr. 2016 09:46, "Laurent Bourg?s" a ?crit : > Jim & Phil, > > > 2016-02-11 23:20 GMT+01:00 Jim Graham : > >> It all looks great. The comments are fine for internal documentation, >> but here is a suggestion for the initial comment on a couple of the >> Provider classes. I don't need to review the changes to comments. >> > > Thanks Jim for your carefull reviews and your suggestions: I integrated > your changes to javadoc with care. > > FYI I always use the following command to remove redundant white spaces: > find . -type f -name '*.java' -exec sed --in-place 's/[[:space:]]\+$//' {} > \; > > To summarize, I can count on jim's review but another one is missing. > > Phil, do you approve too ? > > Regards, > Laurent > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Mon Feb 15 09:02:23 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 15 Feb 2016 10:02:23 +0100 Subject: [OpenJDK 2D-Dev] [8u-dev] Request for review and approval for bug 8147807: crash in libkcms.so on linux-sparc In-Reply-To: <56BDA2AF.9000209@oracle.com> References: <56BC9860.7050006@oracle.com> <56BD9576.4090904@oracle.com> <56BDA2AF.9000209@oracle.com> Message-ID: <56C1941F.3040900@oracle.com> Looks good. /Erik On 2016-02-12 10:15, Se?n Coffey wrote: > Approved for jdk8u-dev once you have a peer code review. > > Regards, > Sean. > > On 12/02/2016 08:19, Alexey Ivanov wrote: >> I forgot to add jdk8u-dev list... >> >> On 11.02.2016 17:19, Alexey Ivanov wrote: >>> Hello, >>> >>> Could you please review the fix for JDK-8147807 and approve push to >>> 8u-dev? >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8147807 >>> Webrev: http://cr.openjdk.java.net/~aivanov/8147807/jdk8/webrev.00/ >>> >>> The issue is not relevant to jdk 9. >>> >>> The fix just removes kcms service leaving lcms as the only option >>> which is the default in jdk8. >>> >>> >>> Thanks in advance, >>> Alexey >> > From prasanta.sadhukhan at oracle.com Mon Feb 15 11:39:05 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Mon, 15 Feb 2016 17:09:05 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8138749, , Revisited: PrinterJob.printDialog() does not support multi-mon, always displayed on primary In-Reply-To: <56BBC0D7.9080401@oracle.com> References: <569F6AC2.7060103@oracle.com> <569FFC46.8040700@oracle.com> <56A0A8BD.306@oracle.com> <56A169C3.2010903@oracle.com> <56A1D85B.3020804@oracle.com> <56AA2B15.90900@oracle.com> <56AB323C.7090706@oracle.com> <56B14B37.6010706@oracle.com> <56B19180.70207@oracle.com> <56B244AA.8060707@oracle.com> <56B2E223.1050400@oracle.com> <56B463FC.9070702@oracle.com> <56BBC0D7.9080401@oracle.com> Message-ID: <56C1B8D9.7030805@oracle.com> Hi Phil, >> Line 836 should be >> x = (bounds.x + bounds.width) - dlgBound.width can be wrong if (bounds.x + bounds.width) - dlgBound.width comes out to be negative (or less than window top-left x,y coordiantes) For example, if window bounds for secondary monitor is (x=1600, y=0, width=489, height =361) and dialog bounds is (x=1650, y=50, width=460, height=353) then above calc will set x to (1629, 8) [ x=1600+489-460=1629 , y = 0+361-353=8] which is ok but if we have dialog bounds (x=1650, y=50, width=554, height = 390) then x becomes 1600+489-554=1535 and y becomes 0+361-390= -29 so it will go beyond the top-left corner of window. so for those cases, I am setting x and y to bounds.x, bounds.y so that atmost it can go to top-left and not beyond that and also setting the dialog width /height to window width/height (as if we keep the same dialog width,height it will become 1600,0,554,390 which is again going beyond window bounds 1600,0,489,361) Please find the updated webrev http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.05/ Regards Prasanta On 2/11/2016 4:29 AM, Phil Race wrote: > if (dlgBounds.x + dlgBounds.width > bounds.x + bounds.width) { > 836 x = bounds.x; > > > Line 836 should be > x = (bounds.x + bounds.width) - dlgBound.width > > Same logic for y. > > 841 pageDialog.setBounds(x, y, bounds.width, bounds.height); > > That looks wrong. It is setting the width/height of the dialog to > be the width/height of the screen. Should be dlgBounds.width + height. > > > -phil. > > > On 02/05/2016 12:57 AM, prasanta sadhukhan wrote: >> >> >> On 2/4/2016 11:01 AM, prasanta sadhukhan wrote: >>> Hi Phil, >>> >>> On 2/3/2016 11:49 PM, Phil Race wrote: >>>> Hi, >>>> >>>> I think it is worth addressing all this at once and I think it can >>>> be done >>>> entirely in RPJ, leaving ServiceUI alone. Ie fix it just for the >>>> case where >>>> RPJ displays the dialog(s). >>> RPJ display the dialog only for pageDialog >>> http://hg.openjdk.java.net/jdk9/client/jdk/file/b9a92b2a8b37/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java#l820 >>> >>> whereas ServiceUI display the printDialog >>> http://hg.openjdk.java.net/jdk9/client/jdk/file/b9a92b2a8b37/src/java.desktop/share/classes/javax/print/ServiceUI.java#l227 >>> >>> >>> So, are you saying we fix it only for pageDialog and leave out >>> printDialog()? >>> >> Please find updated webrev >> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.04/ >> >> where both RPJ and ServiceUI is modified to show the dialog entirely >> on-screen. >> I could not leave ServiceUI without modification as >> // if portion of dialog is not within the gc boundary >> if (!gcBounds.contains(dlgBounds)) { >> // put in the center relative to parent frame/dialog >> dialog.setLocationRelativeTo(owner); >> } >> this code was drawing the dialog in primary so I have to delete the >> code to make sure dialog is displayed on secondary to fix the bug. >> And since anyway, I was modifying ServiceUI, I thought of adding the >> check to draw the printDialog on screen in ServiceUI same as pageDialog. >> >> Regards >> Prasanta >>> Regards >>> Prasanta >>>> When an application calls ServiceUI directly, it >>>> can decide where it would like the dialog subject to the existing >>>> constraint. >>>> >>>> The test really should be one test so that the behaviours can be >>>> tested as one with lower overhead. >>>> >>>> -phil. >>>> >>>> On 02/02/2016 09:34 PM, prasanta sadhukhan wrote: >>>>> Hi Phil, >>>>> >>>>> On 2/3/2016 6:05 AM, Phil Race wrote: >>>>>> The RasterPrinterJob changes are now OK however >>>>>> >>>>>> - I am not sure I understand how removing the check in ServiceUI >>>>>> will address the issue about the dialog needing to be entirely >>>>>> on-screen. >>>>>> It reads to me as if now you allow that in preference to having >>>>>> it centred. >>>>>> But I am not sure the old code would have worked in all cases either >>>>>> since centering on a very small owner window in the corner of the >>>>>> screen >>>>>> would result in the same problem. >>>>> Since this issue was about showing the dialog on primary vs >>>>> secondary, can we address this issue of showing the dialog >>>>> entirely on-screen in separate bug id (since this issue is present >>>>> in primary screen too if dialog is bigger than top-level window)? >>>>> The present change in ServiceUI address the issue of showing the >>>>> dialog on secondary monitor if dialog is bigger than top-level. >>>>>> Probably what is needed is some code that moves it just enough to >>>>>> fit. >>>>>> ie downwards if it is off the top, left if it is off the right >>>>>> and so forth ? >>>>>> >>>>>> - The two tests do not share the same bug ID. I expected they >>>>>> should now do so .. and I was further supposing you would merge >>>>>> the two tests into one. >>>>> I will change the bug id of 2nd test. Is it ok if I keep these 2 >>>>> tests separate to make it easier? >>>>> >>>>> Regards >>>>> Prasanta >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 01/29/2016 01:34 AM, prasanta sadhukhan wrote: >>>>>>> Hi Phil, >>>>>>> >>>>>>> On 1/28/2016 8:22 PM, Philip Race wrote: >>>>>>>> "in consistent" >>>>>>>> >>>>>>>> On 1/21/16, 11:20 PM, prasanta sadhukhan wrote: >>>>>>>>> Hi Phil, >>>>>>>>> >>>>>>>>> I checked with NATIVE print dialog and with other app print >>>>>>>>> dialog, they are positioning the dialog a little ahead of >>>>>>>>> top-left corner (not at 1/3rd of the window as we are doing now) >>>>>>>>> so I did the same and positioned the dialog in consistent with >>>>>>>>> our NATIVE print dialog. >>>>>>>> >>>>>>>> You mean consistently. in consistent means the opposite >>>>>>>> Please adjust that in the code comment. >>>>>>>> >>>>>>>> 50,50 is probably OK so long as you verified this is approximately >>>>>>>> what happens on most platforms, not just windows 8 or similar. >>>>>>>> I don't think you will find complete consistency because apps may >>>>>>>> control it and use different dialogs even on the same platform. >>>>>>>> On hidpi screens this may be closer to the top-left than you >>>>>>>> intend >>>>>>>> but I expect it is fine. >>>>>>>> >>>>>>> Tested on windows, linux and it works ok. We showed the dialog >>>>>>> at x+50,y+50 where x,y is the coordinate of the active window. >>>>>>> Do not have local mac system to test multimonitor setup. >>>>>>>> The one main thing that you should verify is what happens in >>>>>>>> the case >>>>>>>> a native app top-level window is smaller than the print dialog >>>>>>>> and is positioned >>>>>>>> at the bottom right (of the right-most display). Does the >>>>>>>> native app ensure >>>>>>>> that the dialog is wholly on-screen ? I don't think your code >>>>>>>> will do that. >>>>>>>> And Safari on Mac at least seems to do that. I guess that most >>>>>>>> apps try >>>>>>>> their best to keep the dialog wholly on-screen. >>>>>>>> >>>>>>> Tested this case where window bounds is smaller than print dialog >>>>>>> but because of this check in ServiceUI.java >>>>>>> >>>>>>> // if portion of dialog is not within the gc boundary >>>>>>> if (!gcBounds.contains(dlgBounds)) { >>>>>>> // put in the center relative to parent frame/dialog >>>>>>> dialog.setLocationRelativeTo(owner); >>>>>>> } >>>>>>> >>>>>>> the dialog is shown in the primary window. >>>>>>> I saw we did not have this check for pageDialog(attr) where the >>>>>>> dialog is shown in secondary monitor despite gcBounds smaller >>>>>>> than print dialog. >>>>>>> Therefore, I removed this check from ServiceUI. >>>>>>> >>>>>>> Please find the updated webrev: >>>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.03/ >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>>> -phil. >>>>>>>> >>>>>>>> >>>>>>>>> Please find the updated webrev >>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.02/ >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Prasanta >>>>>>>>> On 1/22/2016 4:59 AM, Phil Race wrote: >>>>>>>>>> That is definitely better .. although I wonder if it would be >>>>>>>>>> even better >>>>>>>>>> if you found when there is an 'active' window that you tried to >>>>>>>>>> position the dialog such that it is near the upper-left >>>>>>>>>> corner of that window ? >>>>>>>>>> Please experiment and see how that looks compared to what >>>>>>>>>> other apps are doing. >>>>>>>>>> >>>>>>>>>> -phil. >>>>>>>>>> >>>>>>>>>> On 01/21/2016 01:45 AM, prasanta sadhukhan wrote: >>>>>>>>>>> Hi Phil, >>>>>>>>>>> >>>>>>>>>>> Please find the updated webrev >>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.01/ >>>>>>>>>>> which do away with the change in ServiceUI. >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> Prasanta >>>>>>>>>>> On 1/21/2016 2:59 AM, Phil Race wrote: >>>>>>>>>>>> The changes in ServiceUI seem like they can cause the spec. >>>>>>>>>>>> to be contradicted. >>>>>>>>>>>> It says >>>>>>>>>>>> >>>>>>>>>>>> * @param gc used to select screen. null means primary or >>>>>>>>>>>> default screen. >>>>>>>>>>>> >>>>>>>>>>>> but you update the code such that it will use the active >>>>>>>>>>>> window. >>>>>>>>>>>> If that is on a secondary screen but null was passed in. >>>>>>>>>>>> >>>>>>>>>>>> I am not entirely sure why ServiceUI needs to be changed at >>>>>>>>>>>> all. >>>>>>>>>>>> It is just the caller of ServiceUI .. >>>>>>>>>>>> >>>>>>>>>>>> -phil. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 01/20/2016 03:08 AM, prasanta sadhukhan wrote: >>>>>>>>>>>>> Hi All, >>>>>>>>>>>>> >>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8138749 >>>>>>>>>>>>> webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> Please review a fix for a long standing issue whereby it >>>>>>>>>>>>> is seen that >>>>>>>>>>>>> PrinterJob.printDialog(attr set) does not support >>>>>>>>>>>>> multi-monitor setup. When this API is invoked, the print >>>>>>>>>>>>> dialog is always displayed on the default screen device >>>>>>>>>>>>> regardless of where the application is running. >>>>>>>>>>>>> This is because this method >>>>>>>>>>>>> uses ServiceDialog class for creating the dialog and that >>>>>>>>>>>>> indeed supports passing a GC in which we would like to >>>>>>>>>>>>> have the dialog. But printer job always uses the >>>>>>>>>>>>> GraphicsConfig of the default screen device >>>>>>>>>>>>> resulting in print dialog to be shown on primary >>>>>>>>>>>>> device/monitor. >>>>>>>>>>>>> >>>>>>>>>>>>> I have not considered pageDialog() for this fix. Will >>>>>>>>>>>>> create a separate bugid and send a patch for that as well >>>>>>>>>>>>> once this fix is approved. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards >>>>>>>>>>>>> Prasanta >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From jayathirth.d.v at oracle.com Mon Feb 15 11:39:40 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 15 Feb 2016 03:39:40 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED In-Reply-To: <56BD0CAB.6080704@oracle.com> References: <2c9221dc-ed76-481a-8bee-a694d313448e@default> <56BD0CAB.6080704@oracle.com> Message-ID: <90de7741-c175-4803-9c3e-30b1039b2774@default> Hi Jim, I performed performance analysis with white image so that all conditions are checked in the new branch added. There is no major difference in time taken before and after change. For each input I have tested time taken for drawImage() API to convert from every format to Byte indexed type. For every unique conversion test is run for 100 times. Please find the details: Input type Min before change (ns) Min after change (ns) Max before change (ns) Max after change (ns) Average before change (ns) Average after change (ns) INT_RGB 523437 481491 1230724 1270440 789452 666144 INT_ARGB 500232 493986 12406307 1308816 793384 654015 INT_ARGB_PRE 500233 492201 1037057 981277 710250 699214 INT_BGR 537716 562706 1446703 2046001 862377 863256 3BYTE_BGR 483275 481045 1181638 1384676 651427 580961 4BYTE_ABGR 544410 499786 1292305 968783 690106 683881 4BYTE_ABGR_PRE 504249 505588 1680086 1216445 756101 687750 USHORT_565_RGB 507818 505588 978153 1346746 652908 655782 USHORT_555_RGB 510496 509604 952272 1162004 650418 670811 BYTE_GRAY 481491 478367 1140585 1799231 691160 583250 USHORT_GRAY 506927 507373 1375751 1255267 728202 646902 BYTE_BINARY 541733 496217 1083466 959411 730527 728461 The changes are tested with plain images having primary colors like RED, GREEN, BLUE, BLACK and WHITE. Thanks, Jay -----Original Message----- From: Jim Graham Sent: Friday, February 12, 2016 4:05 AM To: Jayathirth D V; 2d-dev at openjdk.java.net; Philip Race; Prasanta Sadhukhan Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED Hi Jayathirth, Did you do any performance analysis of this change? You are adding 6 tests and multiple branches to per-pixel code. The effectiveness of this technique depends on the colormap that we have set up. For the BufferedImage.TYPE_INDEXED constructor we produce a fairly nice colormap, but if someone creates a custom colormap then the colors could be anything. We create a decent inversion for just about any colormap, but that doesn't mean that using only "the best match for solid red" will produce a better result for a dithered approximation for red. It is true that if there is a really good match for red then we should just use that, but if there are no direct matches for red then we may choose to paint a red region with solid orange even though there is another color in the colormap that when mixed with orange approximates a red tone better. For example, if a colormap contains no pure red, but contains: 240, 20, 0 240, 0, 20 (I'm not sure if 20 is within our current error deltas that we use for dithering, but this is an example not a test case.) Then using one of these alone might skew the color towards orange or purple. Using both together in a dither pattern might keep the overall hue impression as red, but with a small amount of noise in its saturation. What types of colormaps was this tested with? ...jim On 2/11/16 6:37 AM, Jayathirth D V wrote: > Hi, > > _Please review the following fix in JDK9:_ > > __ > > Bug : https://bugs.openjdk.java.net/browse/JDK-7116979 > > Webrev : http://cr.openjdk.java.net/~jdv/7116979/webrev.00/ > > Issue : When Image containing black pixels are converted from any > format to Byte Indexed format some of the pixels are not black. They > are following pattern similar to dithering. > > Root cause : When we convert any format type to ByteIndexed we are > adding Error delta values to R,G,B components using dithering indices. > This is causing some pixels values to not point to proper index in > color table. > > Solution : There is no need to add error delta for primary colors > containing basic values in R,G,B components. Exclude such pixels from > delta addition. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Mon Feb 15 17:35:56 2016 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 15 Feb 2016 09:35:56 -0800 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8148914: BitDepth.java test fails In-Reply-To: <56BD3CD1.7080701@oracle.com> References: <56BD3CD1.7080701@oracle.com> Message-ID: <56C20C7C.2070402@oracle.com> Any comments on this? Thanks, -Joe On 2/11/2016 6:00 PM, joe darcy wrote: > Hello, > > Please review a candidate fix for > > JDK-8148914: BitDepth.java test fails > > In brief, OpenJDK supports two fewer buffered image formats for jpg > than the closed JDK does. I've modified the BitDepth test to allow for > this difference. Patch below; webrev at > > http://cr.openjdk.java.net/~darcy/8148914.0/ > > Thanks, > > -Joe > > --- a/test/javax/imageio/plugins/shared/BitDepth.java Thu Feb 11 > 16:24:55 2016 -0800 > +++ b/test/javax/imageio/plugins/shared/BitDepth.java Thu Feb 11 > 17:26:23 2016 -0800 > @@ -130,11 +130,7 @@ > > boolean allOK = true; > > - for (int i = 0; i < biRGBTypes.length; i++) { > - > - int type = biRGBTypes[i]; > - > - > + for (int type : biRGBTypes) { > // TODO: remove the following 'if' block after the > 8147448 fix > if ( format.toLowerCase().equals("bmp") && ( > (type == BufferedImage.TYPE_INT_ARGB ) || > @@ -151,12 +147,23 @@ > > System.out.println("Testing " + format + > " writer for type " + biTypeNames[type]); > - File f = testWriteRGB(format, type); > - boolean ok = testReadRGB(f); > - if (ok) { > - f.delete(); > + boolean ok = false; > + File f = null; > + try { > + f = testWriteRGB(format, type); > + ok = testReadRGB(f); > + } catch (javax.imageio.IIOException e) { > + // The follow two formats are not supported on OpenJDK > + if (format.toLowerCase().equals("jpg") && > + (type == BufferedImage.TYPE_4BYTE_ABGR || > + type == BufferedImage.TYPE_4BYTE_ABGR_PRE)) > + continue; > + } finally { > + if (ok) { > + f.delete(); > + } > + allOK = allOK && (ok || f == null); > } > - allOK = allOK && ok; > } > > From brian.burkhalter at oracle.com Mon Feb 15 19:14:01 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 15 Feb 2016 11:14:01 -0800 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED In-Reply-To: <90de7741-c175-4803-9c3e-30b1039b2774@default> References: <2c9221dc-ed76-481a-8bee-a694d313448e@default> <56BD0CAB.6080704@oracle.com> <90de7741-c175-4803-9c3e-30b1039b2774@default> Message-ID: <74C62899-59BC-4972-8A26-00CCA276756C@oracle.com> How do create the palette? Brian On Feb 15, 2016, at 3:39 AM, Jayathirth D V wrote: > Hi Jim, > > I performed performance analysis with white image so that all conditions are checked in the new branch added. There is no major difference in time taken before and after change. For each input I have tested time taken for drawImage() API to convert from every format to Byte indexed type. For every unique conversion test is run for 100 times. Please find the details: > > > Input > type > Min > before change > (ns) > Min > after change > (ns) > Max > before change > (ns) > Max > after change > (ns) > Average > before change > (ns) > Average > after > change > (ns) > INT_RGB > 523437 > 481491 > 1230724 > 1270440 > 789452 > 666144 > INT_ARGB > 500232 > 493986 > 12406307 > 1308816 > 793384 > 654015 > INT_ARGB_PRE > 500233 > 492201 > 1037057 > 981277 > 710250 > 699214 > INT_BGR > 537716 > 562706 > 1446703 > 2046001 > 862377 > 863256 > 3BYTE_BGR > 483275 > 481045 > 1181638 > 1384676 > 651427 > 580961 > 4BYTE_ABGR > 544410 > 499786 > 1292305 > 968783 > 690106 > 683881 > 4BYTE_ABGR_PRE > 504249 > 505588 > 1680086 > 1216445 > 756101 > 687750 > USHORT_565_RGB > 507818 > 505588 > 978153 > 1346746 > 652908 > 655782 > USHORT_555_RGB > 510496 > 509604 > 952272 > 1162004 > 650418 > 670811 > BYTE_GRAY > 481491 > 478367 > 1140585 > 1799231 > 691160 > 583250 > USHORT_GRAY > 506927 > 507373 > 1375751 > 1255267 > 728202 > 646902 > BYTE_BINARY > 541733 > 496217 > 1083466 > 959411 > 730527 > 728461 > > > The changes are tested with plain images having primary colors like RED, GREEN, BLUE, BLACK and WHITE. > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Friday, February 12, 2016 4:05 AM > To: Jayathirth D V; 2d-dev at openjdk.java.net; Philip Race; Prasanta Sadhukhan > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED > > Hi Jayathirth, > > Did you do any performance analysis of this change? You are adding 6 tests and multiple branches to per-pixel code. > > The effectiveness of this technique depends on the colormap that we have set up. For the BufferedImage.TYPE_INDEXED constructor we produce a fairly nice colormap, but if someone creates a custom colormap then the colors could be anything. We create a decent inversion for just about any colormap, but that doesn't mean that using only "the best match for solid red" will produce a better result for a dithered approximation for red. It is true that if there is a really good match for red then we should just use that, but if there are no direct matches for red then we may choose to paint a red region with solid orange even though there is another color in the colormap that when mixed with orange approximates a red tone better. For example, if a colormap contains no pure red, but > contains: > > 240, 20, 0 > 240, 0, 20 > > (I'm not sure if 20 is within our current error deltas that we use for dithering, but this is an example not a test case.) > > Then using one of these alone might skew the color towards orange or purple. Using both together in a dither pattern might keep the overall hue impression as red, but with a small amount of noise in its saturation. > > What types of colormaps was this tested with? > > ...jim > > On 2/11/16 6:37 AM, Jayathirth D V wrote: > > Hi, > > > > _Please review the following fix in JDK9:_ > > > > __ > > > > Bug : https://bugs.openjdk.java.net/browse/JDK-7116979 > > > > Webrev : http://cr.openjdk.java.net/~jdv/7116979/webrev.00/ > > > > Issue : When Image containing black pixels are converted from any > > format to Byte Indexed format some of the pixels are not black. They > > are following pattern similar to dithering. > > > > Root cause : When we convert any format type to ByteIndexed we are > > adding Error delta values to R,G,B components using dithering indices. > > This is causing some pixels values to not point to proper index in > > color table. > > > > Solution : There is no need to add error delta for primary colors > > containing basic values in R,G,B components. Exclude such pixels from > > delta addition. > > > > Thanks, > > > > Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Mon Feb 15 19:24:04 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 15 Feb 2016 11:24:04 -0800 Subject: [OpenJDK 2D-Dev] [9] Review request for 8076545 Text size is twice bigger under Windows L&F on Win 8.1 with HiDPI display In-Reply-To: <56BE467A.8060403@oracle.com> References: <5596C117.1040806@oracle.com> <559DB2FB.5000208@oracle.com> <55A902D4.1050603@oracle.com> <563208A9.50702@oracle.com> <56328355.1010608@oracle.com> <5633C7C8.2030804@oracle.com> <5649E312.2010606@oracle.com> <564A41D3.5010202@oracle.com> <564A4DE9.1040102@oracle.com> <56ABB269.6030808@oracle.com> <56ABD6B2.10302@oracle.com> <56AF4F4C.4030504@oracle.com> <56B00B8B.9040102@oracle.com> <56B47579.3090309@oracle.com> <56B4FA0A.3080505@oracle.com> <56B60EE4.2070501@oracle.com> <56B91F12.9070909@oracle.com> <56BE467A.8060403@oracle.com> Message-ID: <56C225D4.4030909@oracle.com> Thanks Alexandr, The AWT changes all look good. I'll leave it to others as to whether the test case represents the best way to test this. I have no idea how those two font values in those two L&F's in a Swing button should compare - maybe a difference of 8 is ordinary under some circumstances? Also, the test will only be conclusive when run on a HiDPI display larger than a certain scale factor so it may not even be testing anything in most test environments. In either case, the AWT code changes look fine... ...jim On 2/12/16 12:54 PM, Alexandr Scherbatiy wrote: > On 2/8/2016 3:04 PM, Jim Graham wrote: >> I don't understand the issue with the fonts that you are saying have >> different sizes for different DPIs. Those are pixel sizes, aren't >> they? They still need to be turned into user-space units for our >> applications to know what to do with them. Or, are you saying that >> they are not representing pixel sizes as the rest of the font units do >> and so they are already in DPI-relative "user space" units? >> >> AT 192 DPI, oemFixed.font is 18, but are they saying 18 pixels? Which >> would be a 9-point font in our automatically scaled coordinate >> systems, wouldn't it? > > The font size in the AwtDesktopProperties is calculated as (tmHeight > - tmInternalLeading) values from TEXTMETRIC: > jint pointSize = metrics.tmHeight - metrics.tmInternalLeading; > According to MSDN "All sizes are specified in logical units; that is, > they depend on the current mapping mode of the display context." > > The calculated size value is proportional to the scale factor for the > fonts like win.frame.captionFont : > DPI 96 (scale 100%), size: 15 > DPI 144 (scale 150%), size: 23 > DPI 192 (scale 200%), size: 30 > > That means that for each DPI it is possible to scale down the font > size to its base value just using the formula: > baseFontSize = fontSize / scaleFactor > > However, for win.ansiFixed.font the TEXTMETRIC returns the same values > for each display DPI: > DPI 96 (scale 100%), size: 13 > DPI 144 (scale 150%), size: 13 > DPI 192 (scale 200%), size: 13 > > Now scaling the size down for DPI 192 ( 13/ 2) it does not give the > font size for the DPI 96. > That is why the scale factor 1.0 is used in this case in the fix. > > Thanks, > Alexandr. > >> >> ...jim >> >> On 2/6/16 7:19 AM, Alexander Scherbatiy wrote: >>> On 2/5/2016 11:37 AM, Jim Graham wrote: >>>> Hi Alexandr, >>>> >>>> awt_DesktopProperties.cpp, line 300 - is the "1.0f /" a typo? >>> Sorry. Here is the updated fix without the typo: >>> http://cr.openjdk.java.net/~alexsch/8076545/webrev.06/ >>>> >>>> Also, is there a still a need for the setFontProperty() variants that >>>> don't have a scale as the last parameter? >>> There are fonts like win.ansiFixed.font, win.ansiVar.font, and >>> win.deviceDefault.font which size is the same for any display DPI. >>> >>> And there are fonts like win.oemFixed.font, win.system.font, and >>> win.systemFixed.font which have one size for DPI 96 and another size for >>> all other DPI. >>> For example win.oemFixed.font: >>> DPI 96, size: 12 >>> DPI 144, size: 18 >>> DPI 192, size: 18 >>> DPI 240, size: 18 >>> >>> I left them unscaled but may be it is better to have one >>> precalculated scale for this fonts which is used when DPI is not 96. >>> >>> I updated the setFontProperty() method without scale parameter usage >>> to call with scale 1.0f. >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> ...jim >>>> >>>> On 2/5/2016 2:12 AM, Alexandr Scherbatiy wrote: >>>>> >>>>> Could you review the updated fix: >>>>> http://cr.openjdk.java.net/~alexsch/8076545/webrev.05 >>>>> >>>>> - The awt_DesktopProperties.cpp file is updated to use scaleX for >>>>> width rescaling and scaleY for height rescaling >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 2/1/2016 5:51 PM, Jim Graham wrote: >>>>>> Hi Alexandr, >>>>>> >>>>>> In awt_DesktopProperties.cpp you are using the Y scaling factor to >>>>>> scale widths still - see lines 287 (and others in that same function) >>>>>> and then 322 in another function. It looks like you'll need >>>>>> getInvScaleX() and getInvScaleY(). >>>>>> >>>>>> I'll leave it to Phil to comment on the unit test... >>>>>> >>>>>> ...jim >>>>>> >>>>>> On 2/1/16 4:27 AM, Alexandr Scherbatiy wrote: >>>>>>> >>>>>>> Could you review the updated fix: >>>>>>> http://cr.openjdk.java.net/~alexsch/8076545/webrev.04/ >>>>>>> >>>>>>> - both LOGPIXELSX and Y are used for the theme size scaling. >>>>>>> - LOGPIXELSY is used for text metrics height rescaling >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> On 1/29/2016 1:16 PM, Jim Graham wrote: >>>>>>>> Hi Alexandr, >>>>>>>> >>>>>>>> Thanks for investigating the behaviors. >>>>>>>> >>>>>>>> With respect to using LOGPIXELSX or Y, these methods are used to >>>>>>>> scale >>>>>>>> both horizontal and vertical measurements so we really should >>>>>>>> have 2 >>>>>>>> scale values and rescale methods, one for horizontal use and one >>>>>>>> for >>>>>>>> vertical... >>>>>>>> >>>>>>>> ...jim >>>>>>>> >>>>>>>> On 1/29/2016 10:41 AM, Alexandr Scherbatiy wrote: >>>>>>>>> Could you review the updated fix: >>>>>>>>> http://cr.openjdk.java.net/~alexsch/8076545/webrev.03 >>>>>>>>> >>>>>>>>> - LOGPIXELSX is changed to LOGPIXELSY >>>>>>>>> >>>>>>>>> On 11/16/2015 1:43 PM, Jim Graham wrote: >>>>>>>>>> Note that LOGPIXELSY is global and static between reboots so it >>>>>>>>>> doesn't really matter which monitor is used to get the value. >>>>>>>>>> >>>>>>>>>> Also, the issue is that the measurements are in pixels, so if we >>>>>>>>>> convert them into a resolution independent measurement then the >>>>>>>>>> rest >>>>>>>>>> of the scaling in the AWT/2D will be correct regardless of any >>>>>>>>>> given >>>>>>>>>> monitor's resolution. We just have to make sure the >>>>>>>>>> "de-pixelization" >>>>>>>>>> of the measurement is an apples-to-apples calculation. >>>>>>>>>> >>>>>>>>>> The question in my mind is whether the values they get from >>>>>>>>>> GetTheme*() and SPI_GETNONCLIENTMETRICS are relative to >>>>>>>>>> LOGPIXELSY, or >>>>>>>>>> the more recent Per-Monitor aware DPI APIs, or ...? It would be >>>>>>>>>> interesting to see what happens to those values when you >>>>>>>>>> change the >>>>>>>>>> DPI settings on Windows 8.1 and not reboot. If they stay constant >>>>>>>>>> until you reboot then LOGPIXELSY on the main screen would be the >>>>>>>>>> value >>>>>>>>>> to use to de-scale them... >>>>>>>>> >>>>>>>>> I tried to use the "Change the size of all items" slider on >>>>>>>>> Windows >>>>>>>>> 8.1 without rebooting. >>>>>>>>> GetDpiForMonitor() returns the updated DPI values: 192, >>>>>>>>> 144, 96 >>>>>>>>> LOGPIXELSY returns unchanged values: 192, 192, 192 >>>>>>>>> SystemParametersInfo(SPI_GETNONCLIENTMETRICS,...) returns >>>>>>>>> unchanged >>>>>>>>> NONCLIENTMETRICS >>>>>>>>> GetThemePartSize() returns unchanged theme part sizes >>>>>>>>> >>>>>>>>> It seems that theme part sizes behave in the same way as the >>>>>>>>> LOGPIXELSY in this case. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> ...jim >>>>>>>>>> >>>>>>>>>> On 11/16/2015 12:51 PM, Phil Race wrote: >>>>>>>>>>> That seems better. But one more question to get a point >>>>>>>>>>> clarified. >>>>>>>>>>> You are using getDesktopWindow() which is for the primary >>>>>>>>>>> monitor. >>>>>>>>>>> I assume that the 'inversion' results in the value being used >>>>>>>>>>> to be >>>>>>>>>>> independent >>>>>>>>>>> of the monitor in a multi-mon situation and so when we move to >>>>>>>>>>> a 2nd >>>>>>>>>>> monitor >>>>>>>>>>> that inverted size remains valid ? >>>>>>>>>>> >>>>>>>>>>> If so looks good to me. >>>>>>>>>>> >>>>>>>>>>> -phil. >>>>>>>>>>> >>>>>>>>>>> On 11/16/2015 06:07 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> Could you review the updated fix: >>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8076545/webrev.02 >>>>>>>>>>>> >>>>>>>>>>>> - round is used instead of ceil >>>>>>>>>>>> - inverted scales are used >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/30/2015 10:40 PM, Jim Graham wrote: >>>>>>>>>>>>> In this case round may be better. ceil() is more for cases >>>>>>>>>>>>> where you >>>>>>>>>>>>> needed "at least X amount of room", but I don't think a font >>>>>>>>>>>>> size is >>>>>>>>>>>>> an "at least this much" kind of case. >>>>>>>>>>>>> >>>>>>>>>>>>> Also, I've been toying with the idea that use of ceil() and >>>>>>>>>>>>> floor() >>>>>>>>>>>>> in any DPI-adjustment equations should really be "ceil(val - >>>>>>>>>>>>> epsilon)" or "floor(ceil + epsilon)" for some small value of >>>>>>>>>>>>> epsilon >>>>>>>>>>>>> chosen just large enough to prevent various round-off errors >>>>>>>>>>>>> from >>>>>>>>>>>>> affecting the outcome. One idea is for 1/256 as the value of >>>>>>>>>>>>> epsilon >>>>>>>>>>>>> since that could equate to the smallest measurable >>>>>>>>>>>>> difference in >>>>>>>>>>>>> terms of alpha or interpolation results (or 1/512 for "half >>>>>>>>>>>>> the >>>>>>>>>>>>> smallest quantum")... >>>>>>>>>>>>> >>>>>>>>>>>>> ...jim >>>>>>>>>>>>> >>>>>>>>>>>>> On 10/29/15 1:36 PM, Phil Race wrote: >>>>>>>>>>>>>> size->cx = (int)ceil(size->cx / scale); >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> So if size->cx / scale works out to be 12.0001 you will round >>>>>>>>>>>>>> it up >>>>>>>>>>>>>> to 13? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Can you check what pixel size windows gives you in such a >>>>>>>>>>>>>> case ? >>>>>>>>>>>>>> I'd be a little surprised if they did that rather than round. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is the SetFontProperty that does not accept a scale parameter >>>>>>>>>>>>>> still >>>>>>>>>>>>>> used >>>>>>>>>>>>>> somewhere ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> -phil. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 10/29/2015 04:53 AM, Sergey Bylokhov wrote: >>>>>>>>>>>>>>> On 17.07.15 16:27, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - Sergey's point about multi-mon should be checked out. >>>>>>>>>>>>>>>> Windows 8.1 has option "Let me choose one scaling >>>>>>>>>>>>>>>> level >>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>> all my >>>>>>>>>>>>>>>> displays". >>>>>>>>>>>>>>>> If I unset it I am able to change the size of all >>>>>>>>>>>>>>>> items. >>>>>>>>>>>>>>>> However, >>>>>>>>>>>>>>>> the DPI which returns GetDPIForMonitor is still 2 on HiDPI >>>>>>>>>>>>>>>> displays. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This version looks fine, but I am sure it can be double >>>>>>>>>>>>>>> checked on >>>>>>>>>>>>>>> windows 10 at some moment as well. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> > From james.graham at oracle.com Mon Feb 15 19:32:33 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 15 Feb 2016 11:32:33 -0800 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED In-Reply-To: <90de7741-c175-4803-9c3e-30b1039b2774@default> References: <2c9221dc-ed76-481a-8bee-a694d313448e@default> <56BD0CAB.6080704@oracle.com> <90de7741-c175-4803-9c3e-30b1039b2774@default> Message-ID: <56C227D1.1030600@oracle.com> Hi Jayathirth, The issue with testing performance with white images is that the tests allow the code to eliminate 3 indexed fetches which take time. Primary colors end up being the one obscure case where the new code might be faster. But, non-primary colors would be slower by a fair amount, so performance testing with converting a randomized or non-primary-color image are the more telling case. An image filled with 255,255,128 would be the worst case because it would involve all of the tests and still have to do all of the lookups. My question about how this works with custom colormaps was not really addressed by your response. A simple test to make sure the colormap has accurate (or very close) conversions for the primary colors may be enough to validate the colormap for the indicated tests. If the colormap contains no pure conversions for some of the primary colors then they may need to be dithered anyway... ...jim On 2/15/16 3:39 AM, Jayathirth D V wrote: > Hi Jim, > > I performed performance analysis with white image so that all conditions > are checked in the new branch added. There is no major difference in > time taken before and after change. For each input I have tested time > taken for drawImage() API to convert from every format to Byte indexed > type. For every unique conversion test is run for 100 times. Please find > the details: > > Input > > type > > > > Min > > before change > > (ns) > > > > Min > > after change > > (ns) > > > > Max > > before change > > (ns) > > > > Max > > after change > > (ns) > > > > Average > > before change > > (ns) > > > > Average > > after > > change > > (ns) > > INT_RGB > > > > 523437 > > > > 481491 > > > > 1230724 > > > > 1270440 > > > > 789452 > > > > 666144 > > INT_ARGB > > > > 500232 > > > > 493986 > > > > 12406307 > > > > 1308816 > > > > 793384 > > > > 654015 > > INT_ARGB_PRE > > > > 500233 > > > > 492201 > > > > 1037057 > > > > 981277 > > > > 710250 > > > > 699214 > > INT_BGR > > > > 537716 > > > > 562706 > > > > 1446703 > > > > 2046001 > > > > 862377 > > > > 863256 > > 3BYTE_BGR > > > > 483275 > > > > 481045 > > > > 1181638 > > > > 1384676 > > > > 651427 > > > > 580961 > > 4BYTE_ABGR > > > > 544410 > > > > 499786 > > > > 1292305 > > > > 968783 > > > > 690106 > > > > 683881 > > 4BYTE_ABGR_PRE > > > > 504249 > > > > 505588 > > > > 1680086 > > > > 1216445 > > > > 756101 > > > > 687750 > > USHORT_565_RGB > > > > 507818 > > > > 505588 > > > > 978153 > > > > 1346746 > > > > 652908 > > > > 655782 > > USHORT_555_RGB > > > > 510496 > > > > 509604 > > > > 952272 > > > > 1162004 > > > > 650418 > > > > 670811 > > BYTE_GRAY > > > > 481491 > > > > 478367 > > > > 1140585 > > > > 1799231 > > > > 691160 > > > > 583250 > > USHORT_GRAY > > > > 506927 > > > > 507373 > > > > 1375751 > > > > 1255267 > > > > 728202 > > > > 646902 > > BYTE_BINARY > > > > 541733 > > > > 496217 > > > > 1083466 > > > > 959411 > > > > 730527 > > > > 728461 > > The changes are tested with plain images having primary colors like RED, > GREEN, BLUE, BLACK and WHITE. > > Thanks, > > Jay > > -----Original Message----- > From: Jim Graham > Sent: Friday, February 12, 2016 4:05 AM > To: Jayathirth D V; 2d-dev at openjdk.java.net; Philip Race; Prasanta Sadhukhan > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : > Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED > > Hi Jayathirth, > > Did you do any performance analysis of this change? You are adding 6 > tests and multiple branches to per-pixel code. > > The effectiveness of this technique depends on the colormap that we have > set up. For the BufferedImage.TYPE_INDEXED constructor we produce a > fairly nice colormap, but if someone creates a custom colormap then the > colors could be anything. We create a decent inversion for just about > any colormap, but that doesn't mean that using only "the best match for > solid red" will produce a better result for a dithered approximation for > red. It is true that if there is a really good match for red then we > should just use that, but if there are no direct matches for red then we > may choose to paint a red region with solid orange even though there is > another color in the colormap that when mixed with orange approximates a > red tone better. For example, if a colormap contains no pure red, but > > contains: > > 240, 20, 0 > > 240, 0, 20 > > (I'm not sure if 20 is within our current error deltas that we use for > dithering, but this is an example not a test case.) > > Then using one of these alone might skew the color towards orange or > purple. Using both together in a dither pattern might keep the overall > hue impression as red, but with a small amount of noise in its saturation. > > What types of colormaps was this tested with? > > ...jim > > On 2/11/16 6:37 AM, Jayathirth D V wrote: > >> Hi, > >> > >> _Please review the following fix in JDK9:_ > >> > >> __ > >> > >> Bug :https://bugs.openjdk.java.net/browse/JDK-7116979 > >> > >> Webrev :http://cr.openjdk.java.net/~jdv/7116979/webrev.00/ > >> > >> Issue : When Image containing black pixels are converted from any > >> format to Byte Indexed format some of the pixels are not black. They > >> are following pattern similar to dithering. > >> > >> Root cause : When we convert any format type to ByteIndexed we are > >> adding Error delta values to R,G,B components using dithering indices. > >> This is causing some pixels values to not point to proper index in > >> color table. > >> > >> Solution : There is no need to add error delta for primary colors > >> containing basic values in R,G,B components. Exclude such pixels from > >> delta addition. > >> > >> Thanks, > >> > >> Jay > >> > From brian.burkhalter at oracle.com Mon Feb 15 19:39:15 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 15 Feb 2016 11:39:15 -0800 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8148914: BitDepth.java test fails In-Reply-To: <56C20C7C.2070402@oracle.com> References: <56BD3CD1.7080701@oracle.com> <56C20C7C.2070402@oracle.com> Message-ID: Hi Joe, Might it not be better to modify testWriteRGB() to do something like this (code neither compiled nor tested): ImageTypeSpecifier spec = new ImageTypeSpecifier(bi); Iterator writers = ImageIO.getImageWriters(spec, format).next(); File file = new File("BitDepth_" + biTypeNames[type] + "." + format); if (!writers.hasNext()) { System.out.println(?No writers available for type ? + biTypeNames[type] + " BufferedImage!"); } else { ImageWriter writer = writers.next(); try (ImageOutputStream out = ImageIO.createImageOutputStream(file)) { writer.setOutput(out); writer.write(bi); } catch (Exception e) { System.out.println("Can't write a type ? + biTypeNames[type] + " BufferedImage!"); } } return file; Thanks, Brian On Feb 15, 2016, at 9:35 AM, joe darcy wrote: > Any comments on this? > > Thanks, > > -Joe > > On 2/11/2016 6:00 PM, joe darcy wrote: >> Hello, >> >> Please review a candidate fix for >> >> JDK-8148914: BitDepth.java test fails >> >> In brief, OpenJDK supports two fewer buffered image formats for jpg than the closed JDK does. I've modified the BitDepth test to allow for this difference. Patch below; webrev at >> >> http://cr.openjdk.java.net/~darcy/8148914.0/ >> >> Thanks, >> >> -Joe >> >> --- a/test/javax/imageio/plugins/shared/BitDepth.java Thu Feb 11 16:24:55 2016 -0800 >> +++ b/test/javax/imageio/plugins/shared/BitDepth.java Thu Feb 11 17:26:23 2016 -0800 >> @@ -130,11 +130,7 @@ >> >> boolean allOK = true; >> >> - for (int i = 0; i < biRGBTypes.length; i++) { >> - >> - int type = biRGBTypes[i]; >> - >> - >> + for (int type : biRGBTypes) { >> // TODO: remove the following 'if' block after the 8147448 fix >> if ( format.toLowerCase().equals("bmp") && ( >> (type == BufferedImage.TYPE_INT_ARGB ) || >> @@ -151,12 +147,23 @@ >> >> System.out.println("Testing " + format + >> " writer for type " + biTypeNames[type]); >> - File f = testWriteRGB(format, type); >> - boolean ok = testReadRGB(f); >> - if (ok) { >> - f.delete(); >> + boolean ok = false; >> + File f = null; >> + try { >> + f = testWriteRGB(format, type); >> + ok = testReadRGB(f); >> + } catch (javax.imageio.IIOException e) { >> + // The follow two formats are not supported on OpenJDK >> + if (format.toLowerCase().equals("jpg") && >> + (type == BufferedImage.TYPE_4BYTE_ABGR || >> + type == BufferedImage.TYPE_4BYTE_ABGR_PRE)) >> + continue; >> + } finally { >> + if (ok) { >> + f.delete(); >> + } >> + allOK = allOK && (ok || f == null); >> } >> - allOK = allOK && ok; >> } >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Feb 15 21:58:49 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 15 Feb 2016 13:58:49 -0800 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8148914: BitDepth.java test fails In-Reply-To: References: <56BD3CD1.7080701@oracle.com> <56C20C7C.2070402@oracle.com> Message-ID: <56C24A19.1080903@oracle.com> Assuming it works, this approach seems better. -phil. On 02/15/2016 11:39 AM, Brian Burkhalter wrote: > Hi Joe, > > Might it not be better to modify testWriteRGB() to do something like > this (code neither compiled nor tested): > > ImageTypeSpecifier spec = new ImageTypeSpecifier(bi); > Iterator writers = ImageIO.getImageWriters(spec, > format).next(); > File file = new File("BitDepth_" + biTypeNames[type] + "." + format); > if (!writers.hasNext()) { > System.out.println(?No writers available for type ? + > biTypeNames[type] > + " BufferedImage!"); > } else { > ImageWriter writer = writers.next(); > try (ImageOutputStream out = ImageIO.createImageOutputStream(file)) { > writer.setOutput(out); > writer.write(bi); > } catch (Exception e) { > System.out.println("Can't write a type ? + biTypeNames[type] > + " BufferedImage!"); > } > } > > return file; > > Thanks, > > Brian > > On Feb 15, 2016, at 9:35 AM, joe darcy > wrote: > >> Any comments on this? >> >> Thanks, >> >> -Joe >> >> On 2/11/2016 6:00 PM, joe darcy wrote: >>> Hello, >>> >>> Please review a candidate fix for >>> >>> JDK-8148914: BitDepth.java test fails >>> >>> In brief, OpenJDK supports two fewer buffered image formats for jpg >>> than the closed JDK does. I've modified the BitDepth test to allow >>> for this difference. Patch below; webrev at >>> >>> http://cr.openjdk.java.net/~darcy/8148914.0/ >>> >>> >>> Thanks, >>> >>> -Joe >>> >>> --- a/test/javax/imageio/plugins/shared/BitDepth.java Thu Feb 11 >>> 16:24:55 2016 -0800 >>> +++ b/test/javax/imageio/plugins/shared/BitDepth.java Thu Feb 11 >>> 17:26:23 2016 -0800 >>> @@ -130,11 +130,7 @@ >>> >>> boolean allOK = true; >>> >>> - for (int i = 0; i < biRGBTypes.length; i++) { >>> - >>> - int type = biRGBTypes[i]; >>> - >>> - >>> + for (int type : biRGBTypes) { >>> // TODO: remove the following 'if' block after the >>> 8147448 fix >>> if ( format.toLowerCase().equals("bmp") && ( >>> (type == BufferedImage.TYPE_INT_ARGB ) || >>> @@ -151,12 +147,23 @@ >>> >>> System.out.println("Testing " + format + >>> " writer for type " + biTypeNames[type]); >>> - File f = testWriteRGB(format, type); >>> - boolean ok = testReadRGB(f); >>> - if (ok) { >>> - f.delete(); >>> + boolean ok = false; >>> + File f = null; >>> + try { >>> + f = testWriteRGB(format, type); >>> + ok = testReadRGB(f); >>> + } catch (javax.imageio.IIOException e) { >>> + // The follow two formats are not supported on OpenJDK >>> + if (format.toLowerCase().equals("jpg") && >>> + (type == BufferedImage.TYPE_4BYTE_ABGR || >>> + type == BufferedImage.TYPE_4BYTE_ABGR_PRE)) >>> + continue; >>> + } finally { >>> + if (ok) { >>> + f.delete(); >>> + } >>> + allOK = allOK && (ok || f == null); >>> } >>> - allOK = allOK && ok; >>> } >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Tue Feb 16 06:23:19 2016 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 15 Feb 2016 22:23:19 -0800 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8149896: Remove unnecessary values in FloatConsts and DoubleConsts Message-ID: <56C2C057.4090000@oracle.com> Hello, The the FloatConsts and DoubleConsts classes, while moved to an internal package recently (JDK-8145990), contain constants now available via the public API. All such uses of the redundant values should be removed as well as the redundant constants themselves. A quick note on the 2d changes, several constants (and a copy from a package-private method from java.lang) were used to initialize a double value POWER_2_TO_32; this can be accomplished more directly using a hexadecimal floating-point literal. Please review the webrev http://cr.openjdk.java.net/~darcy/8149896.0/ Thanks, -Joe From joe.darcy at oracle.com Tue Feb 16 07:15:42 2016 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 15 Feb 2016 23:15:42 -0800 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8148914: BitDepth.java test fails In-Reply-To: <56C24A19.1080903@oracle.com> References: <56BD3CD1.7080701@oracle.com> <56C20C7C.2070402@oracle.com> <56C24A19.1080903@oracle.com> Message-ID: <56C2CC9E.5060300@oracle.com> On 2/15/2016 1:58 PM, Phil Race wrote: > Assuming it works, this approach seems better. A slightly modified version of Brian's change does the trick. Patch below and updated webrev at http://cr.openjdk.java.net/~darcy/8148914.1/ Thanks, -Joe diff -r 10e298cb4ef1 test/javax/imageio/plugins/shared/BitDepth.java --- a/test/javax/imageio/plugins/shared/BitDepth.java Mon Feb 15 18:41:23 2016 -0800 +++ b/test/javax/imageio/plugins/shared/BitDepth.java Mon Feb 15 23:13:43 2016 -0800 @@ -35,7 +35,11 @@ import java.awt.image.BufferedImage; import java.io.File; import java.io.IOException; +import java.util.Iterator; import javax.imageio.ImageIO; +import javax.imageio.ImageTypeSpecifier; +import javax.imageio.ImageWriter; +import javax.imageio.stream.ImageOutputStream; public class BitDepth { @@ -114,15 +118,15 @@ private int width = 80; private int height = 80; - private String[] format = { "png", "jpeg", "tif", "bmp", "gif" }; + private String[] formats = { "png", "jpeg", "tif", "bmp", "gif" }; public BitDepth(String[] args) throws IOException { if (args.length > 0) { - format = args; + formats = args; } - for (int i = 0; i < format.length; i++) { - testFormat(format[i]); + for (String format : formats) { + testFormat(format); } } @@ -130,11 +134,7 @@ boolean allOK = true; - for (int i = 0; i < biRGBTypes.length; i++) { - - int type = biRGBTypes[i]; - - + for (int type : biRGBTypes) { // TODO: remove the following 'if' block after the 8147448 fix if ( format.toLowerCase().equals("bmp") && ( (type == BufferedImage.TYPE_INT_ARGB ) || @@ -148,10 +148,12 @@ continue; } - System.out.println("Testing " + format + " writer for type " + biTypeNames[type]); File f = testWriteRGB(format, type); + if (f == null) + continue; + boolean ok = testReadRGB(f); if (ok) { f.delete(); @@ -159,8 +161,6 @@ allOK = allOK && ok; } - - if (format.equals("png")) { System.out.println("Testing png writer for black stripe"); boolean ok = testPNGByteBinary(); @@ -191,13 +191,22 @@ g.setColor(blue); g.fillRect(50, 50, 20, 20); + ImageTypeSpecifier spec = new ImageTypeSpecifier(bi); + Iterator writers = ImageIO.getImageWriters(spec, format); File file = new File("BitDepth_" + biTypeNames[type] + "." + format); - try { - ImageIO.write(bi, format, file); - } catch (RuntimeException re) { - System.out.println("Can't write a type " - + biTypeNames[type] + - " BufferedImage!"); + if (!writers.hasNext()) { + System.out.println("\tNo writers available for type " + biTypeNames[type] + + " BufferedImage!"); + } else { + ImageWriter writer = writers.next(); + try (ImageOutputStream out = ImageIO.createImageOutputStream(file)) { + writer.setOutput(out); + writer.write(bi); + } catch (Exception e) { + System.out.println("\tCan't write a type " + biTypeNames[type] + + " BufferedImage!"); + return null; + } } return file; > > -phil. > > On 02/15/2016 11:39 AM, Brian Burkhalter wrote: >> Hi Joe, >> >> Might it not be better to modify testWriteRGB() to do something like >> this (code neither compiled nor tested): >> >> ImageTypeSpecifier spec = new ImageTypeSpecifier(bi); >> Iterator writers = ImageIO.getImageWriters(spec, >> format).next(); >> File file = new File("BitDepth_" + biTypeNames[type] + "." + format); >> if (!writers.hasNext()) { >> System.out.println(?No writers available for type ? + >> biTypeNames[type] >> + " BufferedImage!"); >> } else { >> ImageWriter writer = writers.next(); >> try (ImageOutputStream out = ImageIO.createImageOutputStream(file)) { >> writer.setOutput(out); >> writer.write(bi); >> } catch (Exception e) { >> System.out.println("Can't write a type ? + biTypeNames[type] >> + " BufferedImage!"); >> } >> } >> >> return file; >> >> Thanks, >> >> Brian >> >> On Feb 15, 2016, at 9:35 AM, joe darcy > > wrote: >> >>> Any comments on this? >>> >>> Thanks, >>> >>> -Joe >>> >>> On 2/11/2016 6:00 PM, joe darcy wrote: >>>> Hello, >>>> >>>> Please review a candidate fix for >>>> >>>> JDK-8148914: BitDepth.java test fails >>>> >>>> In brief, OpenJDK supports two fewer buffered image formats for jpg >>>> than the closed JDK does. I've modified the BitDepth test to allow >>>> for this difference. Patch below; webrev at >>>> >>>> http://cr.openjdk.java.net/~darcy/8148914.0/ >>>> >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>> --- a/test/javax/imageio/plugins/shared/BitDepth.java Thu Feb 11 >>>> 16:24:55 2016 -0800 >>>> +++ b/test/javax/imageio/plugins/shared/BitDepth.java Thu Feb 11 >>>> 17:26:23 2016 -0800 >>>> @@ -130,11 +130,7 @@ >>>> >>>> boolean allOK = true; >>>> >>>> - for (int i = 0; i < biRGBTypes.length; i++) { >>>> - >>>> - int type = biRGBTypes[i]; >>>> - >>>> - >>>> + for (int type : biRGBTypes) { >>>> // TODO: remove the following 'if' block after the >>>> 8147448 fix >>>> if ( format.toLowerCase().equals("bmp") && ( >>>> (type == BufferedImage.TYPE_INT_ARGB ) || >>>> @@ -151,12 +147,23 @@ >>>> >>>> System.out.println("Testing " + format + >>>> " writer for type " + >>>> biTypeNames[type]); >>>> - File f = testWriteRGB(format, type); >>>> - boolean ok = testReadRGB(f); >>>> - if (ok) { >>>> - f.delete(); >>>> + boolean ok = false; >>>> + File f = null; >>>> + try { >>>> + f = testWriteRGB(format, type); >>>> + ok = testReadRGB(f); >>>> + } catch (javax.imageio.IIOException e) { >>>> + // The follow two formats are not supported on OpenJDK >>>> + if (format.toLowerCase().equals("jpg") && >>>> + (type == BufferedImage.TYPE_4BYTE_ABGR || >>>> + type == BufferedImage.TYPE_4BYTE_ABGR_PRE)) >>>> + continue; >>>> + } finally { >>>> + if (ok) { >>>> + f.delete(); >>>> + } >>>> + allOK = allOK && (ok || f == null); >>>> } >>>> - allOK = allOK && ok; >>>> } >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.sandoz at oracle.com Tue Feb 16 09:05:04 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 16 Feb 2016 10:05:04 +0100 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8149896: Remove unnecessary values in FloatConsts and DoubleConsts In-Reply-To: <56C2C057.4090000@oracle.com> References: <56C2C057.4090000@oracle.com> Message-ID: <85D3D7D7-2D23-4A10-947A-05D4872B117E@oracle.com> > On 16 Feb 2016, at 07:23, joe darcy wrote: > > Hello, > > The the FloatConsts and DoubleConsts classes, while moved to an internal package recently (JDK-8145990), contain constants now available via the public API. All such uses of the redundant values should be removed as well as the redundant constants themselves. > > A quick note on the 2d changes, several constants (and a copy from a package-private method from java.lang) were used to initialize a double value POWER_2_TO_32; this can be accomplished more directly using a hexadecimal floating-point literal. > > Please review the webrev > > http://cr.openjdk.java.net/~darcy/8149896.0/ > +1 My favourite change is this one: - private static final double POWER_2_TO_32 = FloatMath.powerOfTwoD(32); + private static final double POWER_2_TO_32 = 0x1.0p32; and the removal of the method on FloatMath. Paul. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From bourges.laurent at gmail.com Tue Feb 16 10:08:53 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 16 Feb 2016 11:08:53 +0100 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8149896: Remove unnecessary values in FloatConsts and DoubleConsts In-Reply-To: <85D3D7D7-2D23-4A10-947A-05D4872B117E@oracle.com> References: <56C2C057.4090000@oracle.com> <85D3D7D7-2D23-4A10-947A-05D4872B117E@oracle.com> Message-ID: Hello, Joe, I tested your changes in the Marlin renderer as it works well ! > A quick note on the 2d changes, several constants (and a copy from a > package-private method from java.lang) were used to initialize a double > value POWER_2_TO_32; this can be accomplished more directly using a > hexadecimal floating-point literal. > > > > Please review the webrev > > > > http://cr.openjdk.java.net/~darcy/8149896.0/ > ... > My favourite change is this one: > > - private static final double POWER_2_TO_32 = FloatMath.powerOfTwoD(32); > + private static final double POWER_2_TO_32 = 0x1.0p32; > > and the removal of the method on FloatMath. > I agree it is simpler and exactly what I needed; I wasn't aware of such literals: https://blogs.oracle.com/darcy/entry/hexadecimal_floating_point_literals (I am not a reviewer) Thanks for the fix, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Tue Feb 16 16:32:30 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 16 Feb 2016 08:32:30 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED In-Reply-To: <56C227D1.1030600@oracle.com> References: <2c9221dc-ed76-481a-8bee-a694d313448e@default> <56BD0CAB.6080704@oracle.com> <90de7741-c175-4803-9c3e-30b1039b2774@default> <56C227D1.1030600@oracle.com> Message-ID: <46329edf-4cbe-48d4-a519-c908b09844a6@default> Hi Jim, Thanks for letting me know about the importance of custom color maps. I was not able to understand what you mentioned previously since I am new to this terminology. Regarding performance I checked with image having complete 255,255,128 pixels and ran it for 100 times. I am running on Windows 7 Professional SP1 with Intel i5-5300U CPU. Overall I don't see much difference in time taken for drawImage() API before and after change. Details for INT_RGB image as input: Before change : Minimum time 536827ns Maximum time 1560947ns Average time 871167ns After change : Minimum time 536380ns Maximum time 1468130ns Average time 830778ns There is +/- 10% delta both for before and after change time but there is no major gap. Even for image with other input type it holds the same. Regarding custom color maps, previously I ran on default color map generated in TYPE_BYTE_INDEXED constructor. Now I tested with modified color map so that it doesn't contain any of the primary color values. Instead of using 0-255 values with value 51 increments in R,G,B components I used color map with 20-245 values with value 45 as increment. For this color map before and after change all the pixels are referring to same index in color map irrespective of removal of error delta addition in case of primary colors. I have attached log for Red and Green primary colors before and after change(Was not able to attach for more since it exceeded 120KB mailing list limit). Please search for "Final index value =" in the logs. Please let me know your inputs. Thanks, Jay -----Original Message----- From: Jim Graham Sent: Tuesday, February 16, 2016 1:03 AM To: Jayathirth D V Cc: 2d-dev at openjdk.java.net; Philip Race; Prasanta Sadhukhan Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED Hi Jayathirth, The issue with testing performance with white images is that the tests allow the code to eliminate 3 indexed fetches which take time. Primary colors end up being the one obscure case where the new code might be faster. But, non-primary colors would be slower by a fair amount, so performance testing with converting a randomized or non-primary-color image are the more telling case. An image filled with 255,255,128 would be the worst case because it would involve all of the tests and still have to do all of the lookups. My question about how this works with custom colormaps was not really addressed by your response. A simple test to make sure the colormap has accurate (or very close) conversions for the primary colors may be enough to validate the colormap for the indicated tests. If the colormap contains no pure conversions for some of the primary colors then they may need to be dithered anyway... ...jim On 2/15/16 3:39 AM, Jayathirth D V wrote: > Hi Jim, > > I performed performance analysis with white image so that all > conditions are checked in the new branch added. There is no major > difference in time taken before and after change. For each input I > have tested time taken for drawImage() API to convert from every > format to Byte indexed type. For every unique conversion test is run > for 100 times. Please find the details: > > Input > > type > > > > Min > > before change > > (ns) > > > > Min > > after change > > (ns) > > > > Max > > before change > > (ns) > > > > Max > > after change > > (ns) > > > > Average > > before change > > (ns) > > > > Average > > after > > change > > (ns) > > INT_RGB > > > > 523437 > > > > 481491 > > > > 1230724 > > > > 1270440 > > > > 789452 > > > > 666144 > > INT_ARGB > > > > 500232 > > > > 493986 > > > > 12406307 > > > > 1308816 > > > > 793384 > > > > 654015 > > INT_ARGB_PRE > > > > 500233 > > > > 492201 > > > > 1037057 > > > > 981277 > > > > 710250 > > > > 699214 > > INT_BGR > > > > 537716 > > > > 562706 > > > > 1446703 > > > > 2046001 > > > > 862377 > > > > 863256 > > 3BYTE_BGR > > > > 483275 > > > > 481045 > > > > 1181638 > > > > 1384676 > > > > 651427 > > > > 580961 > > 4BYTE_ABGR > > > > 544410 > > > > 499786 > > > > 1292305 > > > > 968783 > > > > 690106 > > > > 683881 > > 4BYTE_ABGR_PRE > > > > 504249 > > > > 505588 > > > > 1680086 > > > > 1216445 > > > > 756101 > > > > 687750 > > USHORT_565_RGB > > > > 507818 > > > > 505588 > > > > 978153 > > > > 1346746 > > > > 652908 > > > > 655782 > > USHORT_555_RGB > > > > 510496 > > > > 509604 > > > > 952272 > > > > 1162004 > > > > 650418 > > > > 670811 > > BYTE_GRAY > > > > 481491 > > > > 478367 > > > > 1140585 > > > > 1799231 > > > > 691160 > > > > 583250 > > USHORT_GRAY > > > > 506927 > > > > 507373 > > > > 1375751 > > > > 1255267 > > > > 728202 > > > > 646902 > > BYTE_BINARY > > > > 541733 > > > > 496217 > > > > 1083466 > > > > 959411 > > > > 730527 > > > > 728461 > > The changes are tested with plain images having primary colors like > RED, GREEN, BLUE, BLACK and WHITE. > > Thanks, > > Jay > > -----Original Message----- > From: Jim Graham > Sent: Friday, February 12, 2016 4:05 AM > To: Jayathirth D V; 2d-dev at openjdk.java.net; Philip Race; Prasanta > Sadhukhan > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : > Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED > > Hi Jayathirth, > > Did you do any performance analysis of this change? You are adding 6 > tests and multiple branches to per-pixel code. > > The effectiveness of this technique depends on the colormap that we > have set up. For the BufferedImage.TYPE_INDEXED constructor we > produce a fairly nice colormap, but if someone creates a custom > colormap then the colors could be anything. We create a decent > inversion for just about any colormap, but that doesn't mean that > using only "the best match for solid red" will produce a better result > for a dithered approximation for red. It is true that if there is a > really good match for red then we should just use that, but if there > are no direct matches for red then we may choose to paint a red region > with solid orange even though there is another color in the colormap > that when mixed with orange approximates a red tone better. For > example, if a colormap contains no pure red, but > > contains: > > 240, 20, 0 > > 240, 0, 20 > > (I'm not sure if 20 is within our current error deltas that we use for > dithering, but this is an example not a test case.) > > Then using one of these alone might skew the color towards orange or > purple. Using both together in a dither pattern might keep the > overall hue impression as red, but with a small amount of noise in its saturation. > > What types of colormaps was this tested with? > > ...jim > > On 2/11/16 6:37 AM, Jayathirth D V wrote: > >> Hi, > >> > >> _Please review the following fix in JDK9:_ > >> > >> __ > >> > >> Bug :https://bugs.openjdk.java.net/browse/JDK-7116979 > >> > >> Webrev :http://cr.openjdk.java.net/~jdv/7116979/webrev.00/ > >> > >> Issue : When Image containing black pixels are converted from any > >> format to Byte Indexed format some of the pixels are not black. They > >> are following pattern similar to dithering. > >> > >> Root cause : When we convert any format type to ByteIndexed we are > >> adding Error delta values to R,G,B components using dithering indices. > >> This is causing some pixels values to not point to proper index in > >> color table. > >> > >> Solution : There is no need to add error delta for primary colors > >> containing basic values in R,G,B components. Exclude such pixels from > >> delta addition. > >> > >> Thanks, > >> > >> Jay > >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: AfterChange.7z Type: application/octet-stream Size: 22327 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: BeforeChange.7z Type: application/octet-stream Size: 40906 bytes Desc: not available URL: From joe.darcy at oracle.com Tue Feb 16 16:59:17 2016 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 16 Feb 2016 08:59:17 -0800 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8149896: Remove unnecessary values in FloatConsts and DoubleConsts In-Reply-To: References: <56C2C057.4090000@oracle.com> <85D3D7D7-2D23-4A10-947A-05D4872B117E@oracle.com> Message-ID: <56C35565.2050605@oracle.com> Hi Laurent, On 2/16/2016 2:08 AM, Laurent Bourg?s wrote: > Hello, > > Joe, I tested your changes in the Marlin renderer as it works well ! > > > > A quick note on the 2d changes, several constants (and a copy > from a package-private method from java.lang) were used to > initialize a double value POWER_2_TO_32; this can be accomplished > more directly using a hexadecimal floating-point literal. > > > > Please review the webrev > > > > http://cr.openjdk.java.net/~darcy/8149896.0/ > > ... > My favourite change is this one: > > - private static final double POWER_2_TO_32 = > FloatMath.powerOfTwoD(32); > + private static final double POWER_2_TO_32 = 0x1.0p32; > > and the removal of the method on FloatMath. > > > I agree it is simpler and exactly what I needed; I wasn't aware of > such literals: > https://blogs.oracle.com/darcy/entry/hexadecimal_floating_point_literals > > Most people don't have cause to use hexadecimal floating-point literals very often, but when you need them, they are exactly what you need :-) Thanks for the review, -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Tue Feb 16 17:36:06 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 16 Feb 2016 09:36:06 -0800 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8148914: BitDepth.java test fails In-Reply-To: <56C2CC9E.5060300@oracle.com> References: <56BD3CD1.7080701@oracle.com> <56C20C7C.2070402@oracle.com> <56C24A19.1080903@oracle.com> <56C2CC9E.5060300@oracle.com> Message-ID: Hi Joe, On Feb 15, 2016, at 11:15 PM, joe darcy wrote: > On 2/15/2016 1:58 PM, Phil Race wrote: >> Assuming it works, this approach seems better. > > A slightly modified version of Brian's change does the trick. > > Patch below and updated webrev at > > http://cr.openjdk.java.net/~darcy/8148914.1/ Picayune remarks (line numbers refer to new version): 1. Line 121: Would prefer ?tiff? to ?tif? as the former is the format acronym and consistent with the other array elements. 2. Line 155: So a write failure appends to a log of failures on System.out as opposed to an actual test failure, or am I mistaken? Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksey.shipilev at oracle.com Tue Feb 16 08:59:28 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 16 Feb 2016 11:59:28 +0300 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8149896: Remove unnecessary values in FloatConsts and DoubleConsts In-Reply-To: <56C2C057.4090000@oracle.com> References: <56C2C057.4090000@oracle.com> Message-ID: <56C2E4F0.5030700@oracle.com> On 02/16/2016 09:23 AM, joe darcy wrote: > Please review the webrev > > http://cr.openjdk.java.net/~darcy/8149896.0/ +1, nice cleanup. -Aleksey (not a Reviewer) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From james.graham at oracle.com Tue Feb 16 22:28:27 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 16 Feb 2016 14:28:27 -0800 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8149896: Remove unnecessary values in FloatConsts and DoubleConsts In-Reply-To: References: <56C2C057.4090000@oracle.com> <85D3D7D7-2D23-4A10-947A-05D4872B117E@oracle.com> Message-ID: <56C3A28B.7070100@oracle.com> Laurent may not technically be a reviewer, but he pretty much owns that code so if he's happy then I'm happy (but I didn't look at any of the other code outside of Marlin if you are keeping count of "full reviewers"...). ...jim On 2/16/2016 2:08 AM, Laurent Bourg?s wrote: > Hello, > > Joe, I tested your changes in the Marlin renderer as it works well ! > > > > A quick note on the 2d changes, several constants (and a copy from a package-private method from java.lang) were used to initialize a double value POWER_2_TO_32; this can be accomplished more directly using a hexadecimal floating-point literal. > > > > Please review the webrev > > > >http://cr.openjdk.java.net/~darcy/8149896.0/ > ... > My favourite change is this one: > > - private static final double POWER_2_TO_32 = > FloatMath.powerOfTwoD(32); > + private static final double POWER_2_TO_32 = 0x1.0p32; > > and the removal of the method on FloatMath. > > > I agree it is simpler and exactly what I needed; I wasn't aware of such > literals: > https://blogs.oracle.com/darcy/entry/hexadecimal_floating_point_literals > > (I am not a reviewer) > > Thanks for the fix, > Laurent From joe.darcy at oracle.com Wed Feb 17 02:42:42 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 16 Feb 2016 18:42:42 -0800 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8148914: BitDepth.java test fails In-Reply-To: References: <56BD3CD1.7080701@oracle.com> <56C20C7C.2070402@oracle.com> <56C24A19.1080903@oracle.com> <56C2CC9E.5060300@oracle.com> Message-ID: <56C3DE22.20502@oracle.com> Hi Brian, On 2/16/2016 9:36 AM, Brian Burkhalter wrote: > Hi Joe, > > On Feb 15, 2016, at 11:15 PM, joe darcy > wrote: > >> On 2/15/2016 1:58 PM, Phil Race wrote: >>> Assuming it works, this approach seems better. >> >> A slightly modified version of Brian's change does the trick. >> >> Patch below and updated webrev at >> >> http://cr.openjdk.java.net/~darcy/8148914.1/ > > Picayune remarks (line numbers refer to new version): > > 1. Line 121: Would prefer ?tiff? to ?tif? as the former is the format > acronym and consistent with the other array elements. I'm happy to change "tif" to "tiff" here; I verified the test passes under an open-only build as a full Oracle build using "tiff". > 2. Line 155: So a write failure appends to a log of failures on > System.out as opposed to an actual test failure, or am I mistaken? > Those are the combinations that need to be accommodated to allow open-only Linux build to pass the tests. The relevant messages written out in this case are: .... Testing jpeg writer for type INT_RGB Testing jpeg writer for type INT_BGR Testing jpeg writer for type 3BYTE_BGR Testing jpeg writer for type USHORT_565_RGB Testing jpeg writer for type USHORT_555_RGB Testing jpeg writer for type INT_ARGB Can't write a type INT_ARGB BufferedImage! Testing jpeg writer for type INT_ARGB_PRE Can't write a type INT_ARGB_PRE BufferedImage! Testing jpeg writer for type 4BYTE_ABGR Can't write a type 4BYTE_ABGR BufferedImage! Testing jpeg writer for type 4BYTE_ABGR_PRE Can't write a type 4BYTE_ABGR_PRE BufferedImage! ... Phil, any additional comments? I'd like to get some form of this pushed to get the test back to green. HTH and thanks, -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.markov at oracle.com Wed Feb 17 13:01:41 2016 From: dmitry.markov at oracle.com (dmitry markov) Date: Wed, 17 Feb 2016 16:01:41 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8073400: Some Monospaced logical fonts have a different width In-Reply-To: <56BB9CAC.3050408@oracle.com> References: <56977953.10604@oracle.com> <56BB9CAC.3050408@oracle.com> Message-ID: <56C46F35.6030107@oracle.com> Hello Phil, Thank you for the review. According to unicode table the characters u201c and u201d are in General Punctuation block, see http://unicode-table.com/en/blocks/general-punctuation/ Many characters from this block are not supported by Courier New. So I do not think we need to remove the whole block from the exclusion range, since it will not have any effect except few characters like u201c and u201d. That's why I removed such small characters set (u2018 - u201F) from the exclusion range, but I can change this if it is necessary. At the same time the characters set (u2018 - u201F) is supported by Arial and Times New Roman which are mapped to other logical fonts. The adjusted exclusion range seems 'quite safe' from this point of view. So I do not think we need to modify any code such as FontConfiguration class and so on to apply these changes only to monospaced fonts. Please correct me if I am wrong. Adding i18n-dev. Internationalization team, Could you review a small change in windows.fontconfig.properties, please? bug: https://bugs.openjdk.java.net/browse/JDK-8073400 webrev: http://cr.openjdk.java.net/~dmarkov/8073400/jdk9/webrev.00/ Problem description: On Windows some characters (in particular, left and right double quotation marks) have width differing from other characters' widths, when Monospaced logical font is used. The default monospaced font for windows platform is Courier New. It contains the desired characters, (i.e. '\u201c' and '\u201d'). However the characters are in 'exclusion ranges' for this font due to settings in windows.fontconfig.properties. So when we try to obtain glyphs for these characters and calculate their bounds, we fallback to another font (Lucida) and use its glyphs. Fix: Remove the following set of characters u2018 - u201F from the exclusion ranges. Thank you in advance, Dmitry On 10/02/2016 23:25, Phil Race wrote: > I expect the exclusion range is there for a reason. > I think (guess) that the intent was that where there is a sequence > like this : > > sequence.sansserif.x-windows-950=alphabetic,chinese-ms950,dingbats,symbol,chinese-ms950-extb > > > then those code points should come from the chinese font. > > Perhaps your adjusted exclusion range should apply only to the > monospaced fonts > which are already putting the locale font first. > > Unfortunately it doesn't appear that this is possible with the > supported syntax > https://docs.oracle.com/javase/1.5.0/docs/guide/intl/fontconfig.html#windows > > > i.e it supports selection only by charactersubsetname, not also by > logicalfontname. > But you should check the code to see if this is in fact the case. > There may need to be a non-ideal decision or a revision to that spec. > and its > supporting code. > > And why be so narrow ? It seems you have made an even odder situation > in having just those two code points 'un'-excluded. > The argument that those were the two a customer complained about does not > hold up very well. > > I think you should also run this whole change+discussion by i18n-dev .. > > > -phil. > > On 01/14/2016 02:32 AM, dmitry markov wrote: >> Hello, >> >> Could you review the fix for jdk9, please? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8073400 >> webrev: http://cr.openjdk.java.net/~dmarkov/8073400/jdk9/webrev.00/ >> >> Problem description: >> On Windows some characters (in particular, left and right double >> quotation marks) have width differing from other characters' widths, >> when Monospaced logical font is used. >> The default monospaced font for windows platform is Courier New. It >> contains the desired characters, (i.e. '\u201c' and '\u201d'). >> However the characters are in 'exclusion ranges' for this font due to >> settings in windows.fontconfig.properties. So when we try to obtain >> glyphs for these characters and calculate their bounds, we fallback >> to another font (Lucida) and use its glyphs. >> >> Fix: >> Remove the following set of characters u2018 - u201F from the >> exclusion ranges. >> >> Thanks, >> Dmitry > From brian.burkhalter at oracle.com Wed Feb 17 14:36:12 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 17 Feb 2016 06:36:12 -0800 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8148914: BitDepth.java test fails In-Reply-To: <56C3DE22.20502@oracle.com> References: <56BD3CD1.7080701@oracle.com> <56C20C7C.2070402@oracle.com> <56C24A19.1080903@oracle.com> <56C2CC9E.5060300@oracle.com> <56C3DE22.20502@oracle.com> Message-ID: <2659F7D0-B56B-41AD-88A4-059343DA5FD0@oracle.com> On Feb 16, 2016, at 6:42 PM, Joseph D. Darcy wrote: >> 1. Line 121: Would prefer ?tiff? to ?tif? as the former is the format acronym and consistent with the other array elements. > > I'm happy to change "tif" to "tiff" here; I verified the test passes under an open-only build as a full Oracle build using "tiff?. Good - thanks. >> 2. Line 155: So a write failure appends to a log of failures on System.out as opposed to an actual test failure, or am I mistaken? >> > > Those are the combinations that need to be accommodated to allow open-only Linux build to pass the tests. The relevant messages written out in this case are: > > .... > Testing jpeg writer for type INT_RGB > Testing jpeg writer for type INT_BGR > Testing jpeg writer for type 3BYTE_BGR > Testing jpeg writer for type USHORT_565_RGB > Testing jpeg writer for type USHORT_555_RGB > Testing jpeg writer for type INT_ARGB > Can't write a type INT_ARGB BufferedImage! > Testing jpeg writer for type INT_ARGB_PRE > Can't write a type INT_ARGB_PRE BufferedImage! > Testing jpeg writer for type 4BYTE_ABGR > Can't write a type 4BYTE_ABGR BufferedImage! > Testing jpeg writer for type 4BYTE_ABGR_PRE > Can't write a type 4BYTE_ABGR_PRE BufferedImage! Alpha is not generally supported for JPEG so that looks OK. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From omajid at redhat.com Wed Feb 17 15:45:44 2016 From: omajid at redhat.com (Omair Majid) Date: Wed, 17 Feb 2016 10:45:44 -0500 Subject: [OpenJDK 2D-Dev] Fix integer overflow warnings in icu layout code In-Reply-To: <20160127203515.GE3789@redhat.com> References: <20160121175243.GB12309@redhat.com> <56A12DA2.7020906@oracle.com> <20160121215030.GC12309@redhat.com> <56A1612F.3010403@oracle.com> <20160127203515.GE3789@redhat.com> Message-ID: <20160217154544.GB3900@redhat.com> * 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? 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 Wed Feb 17 19:54:44 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 17 Feb 2016 11:54:44 -0800 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8148914: BitDepth.java test fails In-Reply-To: <2659F7D0-B56B-41AD-88A4-059343DA5FD0@oracle.com> References: <56BD3CD1.7080701@oracle.com> <56C20C7C.2070402@oracle.com> <56C24A19.1080903@oracle.com> <56C2CC9E.5060300@oracle.com> <56C3DE22.20502@oracle.com> <2659F7D0-B56B-41AD-88A4-059343DA5FD0@oracle.com> Message-ID: <56C4D004.5060104@oracle.com> +1 -phil. On 02/17/2016 06:36 AM, Brian Burkhalter wrote: > > On Feb 16, 2016, at 6:42 PM, Joseph D. Darcy > wrote: > >>> 1. Line 121: Would prefer ?tiff? to ?tif? as the former is the >>> format acronym and consistent with the other array elements. >> >> I'm happy to change "tif" to "tiff" here; I verified the test passes >> under an open-only build as a full Oracle build using "tiff?. > > Good - thanks. > >>> 2. Line 155: So a write failure appends to a log of failures on >>> System.out as opposed to an actual test failure, or am I mistaken? >>> >> >> Those are the combinations that need to be accommodated to allow >> open-only Linux build to pass the tests. The relevant messages >> written out in this case are: >> >> .... >> Testing jpeg writer for type INT_RGB >> Testing jpeg writer for type INT_BGR >> Testing jpeg writer for type 3BYTE_BGR >> Testing jpeg writer for type USHORT_565_RGB >> Testing jpeg writer for type USHORT_555_RGB >> Testing jpeg writer for type INT_ARGB >> Can't write a type INT_ARGB BufferedImage! >> Testing jpeg writer for type INT_ARGB_PRE >> Can't write a type INT_ARGB_PRE BufferedImage! >> Testing jpeg writer for type 4BYTE_ABGR >> Can't write a type 4BYTE_ABGR BufferedImage! >> Testing jpeg writer for type 4BYTE_ABGR_PRE >> Can't write a type 4BYTE_ABGR_PRE BufferedImage! > > Alpha is not generally supported for JPEG so that looks OK. > > Thanks, > > Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Feb 18 00:23:09 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 17 Feb 2016 16:23:09 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8138749, , Revisited: PrinterJob.printDialog() does not support multi-mon, always displayed on primary In-Reply-To: <56C1B8D9.7030805@oracle.com> References: <569F6AC2.7060103@oracle.com> <569FFC46.8040700@oracle.com> <56A0A8BD.306@oracle.com> <56A169C3.2010903@oracle.com> <56A1D85B.3020804@oracle.com> <56AA2B15.90900@oracle.com> <56AB323C.7090706@oracle.com> <56B14B37.6010706@oracle.com> <56B19180.70207@oracle.com> <56B244AA.8060707@oracle.com> <56B2E223.1050400@oracle.com> <56B463FC.9070702@oracle.com> <56BBC0D7.9080401@oracle.com> <56C1B8D9.7030805@oracle.com> Message-ID: <56C50EED.2020609@oracle.com> I don't think we should be adjusting the width of the dialog so that part of the change should be removed which will simplify the logic. Of course anyone calling the ServiceUI public API does not have any insight into the size of the dialog since it is not explicitly returned so they could inadvertently position it so that it is partly off the bottom or right side of the screen. Perhaps in a multi-monitor environment with two side by side screens they want the dialog centred such that it spans the two Perhaps they want these behaviours but I suspect not so it is probably worth 'fixing up' some of these cases. So our 'tweaking' of the position should be limited so that it positions the dialog such that its moved the minimum amount to that the bottom right is on (the specified) screen. If - and only if - that would cause it to be partially off the top-left - possible only if the screen is smaller than the dialog, should we adjust the dialog position in a way that allows the bottom or right to be off-screen. I think we are mostly there and it is not important enough to add new API to ServiceUI at this time to give us hints about how to handle such cases - although I have given it some consideration. There are lot of things we *could* do here - expose the pageDialog (now commented out) - provide a way to pass in the owner Dialog or Frame and stop ignoring it in ServiceDialog. That would be useful for modality. - provide those hints I mentioned I think #1 and #2 on that list might be the most useful to some people but don't invalidate this fix even if it might need to be revised if we ever do them .. -phil. On 2/15/16, 3:39 AM, prasanta sadhukhan wrote: > Hi Phil, > > >> Line 836 should be > >> x = (bounds.x + bounds.width) - dlgBound.width > > can be wrong if (bounds.x + bounds.width) - dlgBound.width comes out > to be negative (or less than window top-left x,y coordiantes) > For example, if window bounds for secondary monitor is (x=1600, y=0, > width=489, height =361) > and dialog bounds is (x=1650, y=50, width=460, height=353) then above > calc will set x to (1629, 8) [ x=1600+489-460=1629 , y = 0+361-353=8] > which is ok > > but if we have dialog bounds (x=1650, y=50, width=554, height = 390) > then x becomes 1600+489-554=1535 and y becomes 0+361-390= -29 so it > will go beyond the top-left corner of window. > > so for those cases, I am > setting x and y to bounds.x, bounds.y so that atmost it can go to > top-left and not beyond that and > also setting the dialog width /height to window width/height (as if we > keep the same dialog width,height it will become 1600,0,554,390 which > is again going beyond window bounds 1600,0,489,361) > > Please find the updated webrev > http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.05/ > > Regards > Prasanta > On 2/11/2016 4:29 AM, Phil Race wrote: >> if (dlgBounds.x + dlgBounds.width > bounds.x + bounds.width) { >> 836 x = bounds.x; >> >> >> Line 836 should be >> x = (bounds.x + bounds.width) - dlgBound.width >> >> Same logic for y. >> >> 841 pageDialog.setBounds(x, y, bounds.width, bounds.height); >> >> That looks wrong. It is setting the width/height of the dialog to >> be the width/height of the screen. Should be dlgBounds.width + height. >> >> >> -phil. >> >> >> On 02/05/2016 12:57 AM, prasanta sadhukhan wrote: >>> >>> >>> On 2/4/2016 11:01 AM, prasanta sadhukhan wrote: >>>> Hi Phil, >>>> >>>> On 2/3/2016 11:49 PM, Phil Race wrote: >>>>> Hi, >>>>> >>>>> I think it is worth addressing all this at once and I think it can >>>>> be done >>>>> entirely in RPJ, leaving ServiceUI alone. Ie fix it just for the >>>>> case where >>>>> RPJ displays the dialog(s). >>>> RPJ display the dialog only for pageDialog >>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/b9a92b2a8b37/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java#l820 >>>> >>>> whereas ServiceUI display the printDialog >>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/b9a92b2a8b37/src/java.desktop/share/classes/javax/print/ServiceUI.java#l227 >>>> >>>> >>>> So, are you saying we fix it only for pageDialog and leave out >>>> printDialog()? >>>> >>> Please find updated webrev >>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.04/ >>> >>> where both RPJ and ServiceUI is modified to show the dialog entirely >>> on-screen. >>> I could not leave ServiceUI without modification as >>> // if portion of dialog is not within the gc boundary >>> if (!gcBounds.contains(dlgBounds)) { >>> // put in the center relative to parent frame/dialog >>> dialog.setLocationRelativeTo(owner); >>> } >>> this code was drawing the dialog in primary so I have to delete the >>> code to make sure dialog is displayed on secondary to fix the bug. >>> And since anyway, I was modifying ServiceUI, I thought of adding the >>> check to draw the printDialog on screen in ServiceUI same as >>> pageDialog. >>> >>> Regards >>> Prasanta >>>> Regards >>>> Prasanta >>>>> When an application calls ServiceUI directly, it >>>>> can decide where it would like the dialog subject to the existing >>>>> constraint. >>>>> >>>>> The test really should be one test so that the behaviours can be >>>>> tested as one with lower overhead. >>>>> >>>>> -phil. >>>>> >>>>> On 02/02/2016 09:34 PM, prasanta sadhukhan wrote: >>>>>> Hi Phil, >>>>>> >>>>>> On 2/3/2016 6:05 AM, Phil Race wrote: >>>>>>> The RasterPrinterJob changes are now OK however >>>>>>> >>>>>>> - I am not sure I understand how removing the check in ServiceUI >>>>>>> will address the issue about the dialog needing to be entirely >>>>>>> on-screen. >>>>>>> It reads to me as if now you allow that in preference to having >>>>>>> it centred. >>>>>>> But I am not sure the old code would have worked in all cases >>>>>>> either >>>>>>> since centering on a very small owner window in the corner of >>>>>>> the screen >>>>>>> would result in the same problem. >>>>>> Since this issue was about showing the dialog on primary vs >>>>>> secondary, can we address this issue of showing the dialog >>>>>> entirely on-screen in separate bug id (since this issue is >>>>>> present in primary screen too if dialog is bigger than top-level >>>>>> window)? >>>>>> The present change in ServiceUI address the issue of showing the >>>>>> dialog on secondary monitor if dialog is bigger than top-level. >>>>>>> Probably what is needed is some code that moves it just enough >>>>>>> to fit. >>>>>>> ie downwards if it is off the top, left if it is off the right >>>>>>> and so forth ? >>>>>>> >>>>>>> - The two tests do not share the same bug ID. I expected they >>>>>>> should now do so .. and I was further supposing you would merge >>>>>>> the two tests into one. >>>>>> I will change the bug id of 2nd test. Is it ok if I keep these 2 >>>>>> tests separate to make it easier? >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 01/29/2016 01:34 AM, prasanta sadhukhan wrote: >>>>>>>> Hi Phil, >>>>>>>> >>>>>>>> On 1/28/2016 8:22 PM, Philip Race wrote: >>>>>>>>> "in consistent" >>>>>>>>> >>>>>>>>> On 1/21/16, 11:20 PM, prasanta sadhukhan wrote: >>>>>>>>>> Hi Phil, >>>>>>>>>> >>>>>>>>>> I checked with NATIVE print dialog and with other app print >>>>>>>>>> dialog, they are positioning the dialog a little ahead of >>>>>>>>>> top-left corner (not at 1/3rd of the window as we are doing now) >>>>>>>>>> so I did the same and positioned the dialog in consistent >>>>>>>>>> with our NATIVE print dialog. >>>>>>>>> >>>>>>>>> You mean consistently. in consistent means the opposite >>>>>>>>> Please adjust that in the code comment. >>>>>>>>> >>>>>>>>> 50,50 is probably OK so long as you verified this is >>>>>>>>> approximately >>>>>>>>> what happens on most platforms, not just windows 8 or similar. >>>>>>>>> I don't think you will find complete consistency because apps may >>>>>>>>> control it and use different dialogs even on the same platform. >>>>>>>>> On hidpi screens this may be closer to the top-left than you >>>>>>>>> intend >>>>>>>>> but I expect it is fine. >>>>>>>>> >>>>>>>> Tested on windows, linux and it works ok. We showed the dialog >>>>>>>> at x+50,y+50 where x,y is the coordinate of the active window. >>>>>>>> Do not have local mac system to test multimonitor setup. >>>>>>>>> The one main thing that you should verify is what happens in >>>>>>>>> the case >>>>>>>>> a native app top-level window is smaller than the print dialog >>>>>>>>> and is positioned >>>>>>>>> at the bottom right (of the right-most display). Does the >>>>>>>>> native app ensure >>>>>>>>> that the dialog is wholly on-screen ? I don't think your code >>>>>>>>> will do that. >>>>>>>>> And Safari on Mac at least seems to do that. I guess that most >>>>>>>>> apps try >>>>>>>>> their best to keep the dialog wholly on-screen. >>>>>>>>> >>>>>>>> Tested this case where window bounds is smaller than print dialog >>>>>>>> but because of this check in ServiceUI.java >>>>>>>> >>>>>>>> // if portion of dialog is not within the gc boundary >>>>>>>> if (!gcBounds.contains(dlgBounds)) { >>>>>>>> // put in the center relative to parent frame/dialog >>>>>>>> dialog.setLocationRelativeTo(owner); >>>>>>>> } >>>>>>>> >>>>>>>> the dialog is shown in the primary window. >>>>>>>> I saw we did not have this check for pageDialog(attr) where the >>>>>>>> dialog is shown in secondary monitor despite gcBounds smaller >>>>>>>> than print dialog. >>>>>>>> Therefore, I removed this check from ServiceUI. >>>>>>>> >>>>>>>> Please find the updated webrev: >>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.03/ >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>>>> -phil. >>>>>>>>> >>>>>>>>> >>>>>>>>>> Please find the updated webrev >>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.02/ >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Prasanta >>>>>>>>>> On 1/22/2016 4:59 AM, Phil Race wrote: >>>>>>>>>>> That is definitely better .. although I wonder if it would >>>>>>>>>>> be even better >>>>>>>>>>> if you found when there is an 'active' window that you tried to >>>>>>>>>>> position the dialog such that it is near the upper-left >>>>>>>>>>> corner of that window ? >>>>>>>>>>> Please experiment and see how that looks compared to what >>>>>>>>>>> other apps are doing. >>>>>>>>>>> >>>>>>>>>>> -phil. >>>>>>>>>>> >>>>>>>>>>> On 01/21/2016 01:45 AM, prasanta sadhukhan wrote: >>>>>>>>>>>> Hi Phil, >>>>>>>>>>>> >>>>>>>>>>>> Please find the updated webrev >>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.01/ >>>>>>>>>>>> which do away with the change in ServiceUI. >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> Prasanta >>>>>>>>>>>> On 1/21/2016 2:59 AM, Phil Race wrote: >>>>>>>>>>>>> The changes in ServiceUI seem like they can cause the >>>>>>>>>>>>> spec. to be contradicted. >>>>>>>>>>>>> It says >>>>>>>>>>>>> >>>>>>>>>>>>> * @param gc used to select screen. null means primary >>>>>>>>>>>>> or default screen. >>>>>>>>>>>>> >>>>>>>>>>>>> but you update the code such that it will use the active >>>>>>>>>>>>> window. >>>>>>>>>>>>> If that is on a secondary screen but null was passed in. >>>>>>>>>>>>> >>>>>>>>>>>>> I am not entirely sure why ServiceUI needs to be changed >>>>>>>>>>>>> at all. >>>>>>>>>>>>> It is just the caller of ServiceUI .. >>>>>>>>>>>>> >>>>>>>>>>>>> -phil. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 01/20/2016 03:08 AM, prasanta sadhukhan wrote: >>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8138749 >>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review a fix for a long standing issue whereby it >>>>>>>>>>>>>> is seen that >>>>>>>>>>>>>> PrinterJob.printDialog(attr set) does not support >>>>>>>>>>>>>> multi-monitor setup. When this API is invoked, the print >>>>>>>>>>>>>> dialog is always displayed on the default screen device >>>>>>>>>>>>>> regardless of where the application is running. >>>>>>>>>>>>>> This is because this method >>>>>>>>>>>>>> uses ServiceDialog class for creating the dialog and that >>>>>>>>>>>>>> indeed supports passing a GC in which we would like to >>>>>>>>>>>>>> have the dialog. But printer job always uses the >>>>>>>>>>>>>> GraphicsConfig of the default screen device >>>>>>>>>>>>>> resulting in print dialog to be shown on primary >>>>>>>>>>>>>> device/monitor. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have not considered pageDialog() for this fix. Will >>>>>>>>>>>>>> create a separate bugid and send a patch for that as well >>>>>>>>>>>>>> once this fix is approved. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards >>>>>>>>>>>>>> Prasanta >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From prasanta.sadhukhan at oracle.com Thu Feb 18 05:56:11 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Thu, 18 Feb 2016 11:26:11 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8138749, , Revisited: PrinterJob.printDialog() does not support multi-mon, always displayed on primary In-Reply-To: <56C50EED.2020609@oracle.com> References: <569F6AC2.7060103@oracle.com> <569FFC46.8040700@oracle.com> <56A0A8BD.306@oracle.com> <56A169C3.2010903@oracle.com> <56A1D85B.3020804@oracle.com> <56AA2B15.90900@oracle.com> <56AB323C.7090706@oracle.com> <56B14B37.6010706@oracle.com> <56B19180.70207@oracle.com> <56B244AA.8060707@oracle.com> <56B2E223.1050400@oracle.com> <56B463FC.9070702@oracle.com> <56BBC0D7.9080401@oracle.com> <56C1B8D9.7030805@oracle.com> <56C50EED.2020609@oracle.com> Message-ID: <56C55CFB.50707@oracle.com> Hi Phil, On 2/18/2016 5:53 AM, Philip Race wrote: > I don't think we should be adjusting the width of the dialog so that > part of the change > should be removed which will simplify the logic. > > Of course anyone calling the ServiceUI public API does not have any > insight into the size of the dialog since it is not explicitly > returned so they > could inadvertently position it so that it is partly off the bottom or > right side of the screen. > Perhaps in a multi-monitor environment with two side by side screens > they want > the dialog centred such that it spans the two > Perhaps they want these behaviours but I suspect not so it is probably > worth > 'fixing up' some of these cases. > > So our 'tweaking' of the position should be limited so that it > positions the dialog > such that its moved the minimum amount to that the bottom right is on > (the specified) screen. > If - and only if - that would cause it to be partially off the > top-left - possible only > if the screen is smaller than the dialog, should we adjust the dialog > position in > a way that allows the bottom or right to be off-screen. > Please find the updated webrev that takes care of your review comments http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.06/ As for the below proposal, I guess we could handle it as part of future enhancements, can we? Regards Prasanta > I think we are mostly there and it is not important enough to add new > API to > ServiceUI at this time to give us hints about how to handle such cases > - although > I have given it some consideration. > > There are lot of things we *could* do here > - expose the pageDialog (now commented out) > - provide a way to pass in the owner Dialog or Frame and stop ignoring > it in ServiceDialog. > That would be useful for modality. > - provide those hints I mentioned > > I think #1 and #2 on that list might be the most useful to some people > but > don't invalidate this fix even if it might need to be revised if we > ever do them .. > > > -phil. > > On 2/15/16, 3:39 AM, prasanta sadhukhan wrote: >> Hi Phil, >> >> >> Line 836 should be >> >> x = (bounds.x + bounds.width) - dlgBound.width >> >> can be wrong if (bounds.x + bounds.width) - dlgBound.width comes out >> to be negative (or less than window top-left x,y coordiantes) >> For example, if window bounds for secondary monitor is (x=1600, y=0, >> width=489, height =361) >> and dialog bounds is (x=1650, y=50, width=460, height=353) then above >> calc will set x to (1629, 8) [ x=1600+489-460=1629 , y = 0+361-353=8] >> which is ok >> >> but if we have dialog bounds (x=1650, y=50, width=554, height = 390) >> then x becomes 1600+489-554=1535 and y becomes 0+361-390= -29 so it >> will go beyond the top-left corner of window. >> >> so for those cases, I am >> setting x and y to bounds.x, bounds.y so that atmost it can go to >> top-left and not beyond that and >> also setting the dialog width /height to window width/height (as if >> we keep the same dialog width,height it will become 1600,0,554,390 >> which is again going beyond window bounds 1600,0,489,361) >> >> Please find the updated webrev >> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.05/ >> >> Regards >> Prasanta >> On 2/11/2016 4:29 AM, Phil Race wrote: >>> if (dlgBounds.x + dlgBounds.width > bounds.x + bounds.width) { >>> 836 x = bounds.x; >>> >>> >>> Line 836 should be >>> x = (bounds.x + bounds.width) - dlgBound.width >>> >>> Same logic for y. >>> >>> 841 pageDialog.setBounds(x, y, bounds.width, >>> bounds.height); >>> >>> That looks wrong. It is setting the width/height of the dialog to >>> be the width/height of the screen. Should be dlgBounds.width + height. >>> >>> >>> -phil. >>> >>> >>> On 02/05/2016 12:57 AM, prasanta sadhukhan wrote: >>>> >>>> >>>> On 2/4/2016 11:01 AM, prasanta sadhukhan wrote: >>>>> Hi Phil, >>>>> >>>>> On 2/3/2016 11:49 PM, Phil Race wrote: >>>>>> Hi, >>>>>> >>>>>> I think it is worth addressing all this at once and I think it >>>>>> can be done >>>>>> entirely in RPJ, leaving ServiceUI alone. Ie fix it just for the >>>>>> case where >>>>>> RPJ displays the dialog(s). >>>>> RPJ display the dialog only for pageDialog >>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/b9a92b2a8b37/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java#l820 >>>>> >>>>> whereas ServiceUI display the printDialog >>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/b9a92b2a8b37/src/java.desktop/share/classes/javax/print/ServiceUI.java#l227 >>>>> >>>>> >>>>> So, are you saying we fix it only for pageDialog and leave out >>>>> printDialog()? >>>>> >>>> Please find updated webrev >>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.04/ >>>> >>>> where both RPJ and ServiceUI is modified to show the dialog >>>> entirely on-screen. >>>> I could not leave ServiceUI without modification as >>>> // if portion of dialog is not within the gc boundary >>>> if (!gcBounds.contains(dlgBounds)) { >>>> // put in the center relative to parent frame/dialog >>>> dialog.setLocationRelativeTo(owner); >>>> } >>>> this code was drawing the dialog in primary so I have to delete the >>>> code to make sure dialog is displayed on secondary to fix the bug. >>>> And since anyway, I was modifying ServiceUI, I thought of adding the >>>> check to draw the printDialog on screen in ServiceUI same as >>>> pageDialog. >>>> >>>> Regards >>>> Prasanta >>>>> Regards >>>>> Prasanta >>>>>> When an application calls ServiceUI directly, it >>>>>> can decide where it would like the dialog subject to the existing >>>>>> constraint. >>>>>> >>>>>> The test really should be one test so that the behaviours can be >>>>>> tested as one with lower overhead. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 02/02/2016 09:34 PM, prasanta sadhukhan wrote: >>>>>>> Hi Phil, >>>>>>> >>>>>>> On 2/3/2016 6:05 AM, Phil Race wrote: >>>>>>>> The RasterPrinterJob changes are now OK however >>>>>>>> >>>>>>>> - I am not sure I understand how removing the check in ServiceUI >>>>>>>> will address the issue about the dialog needing to be entirely >>>>>>>> on-screen. >>>>>>>> It reads to me as if now you allow that in preference to having >>>>>>>> it centred. >>>>>>>> But I am not sure the old code would have worked in all cases >>>>>>>> either >>>>>>>> since centering on a very small owner window in the corner of >>>>>>>> the screen >>>>>>>> would result in the same problem. >>>>>>> Since this issue was about showing the dialog on primary vs >>>>>>> secondary, can we address this issue of showing the dialog >>>>>>> entirely on-screen in separate bug id (since this issue is >>>>>>> present in primary screen too if dialog is bigger than top-level >>>>>>> window)? >>>>>>> The present change in ServiceUI address the issue of showing the >>>>>>> dialog on secondary monitor if dialog is bigger than top-level. >>>>>>>> Probably what is needed is some code that moves it just enough >>>>>>>> to fit. >>>>>>>> ie downwards if it is off the top, left if it is off the right >>>>>>>> and so forth ? >>>>>>>> >>>>>>>> - The two tests do not share the same bug ID. I expected they >>>>>>>> should now do so .. and I was further supposing you would merge >>>>>>>> the two tests into one. >>>>>>> I will change the bug id of 2nd test. Is it ok if I keep these 2 >>>>>>> tests separate to make it easier? >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> On 01/29/2016 01:34 AM, prasanta sadhukhan wrote: >>>>>>>>> Hi Phil, >>>>>>>>> >>>>>>>>> On 1/28/2016 8:22 PM, Philip Race wrote: >>>>>>>>>> "in consistent" >>>>>>>>>> >>>>>>>>>> On 1/21/16, 11:20 PM, prasanta sadhukhan wrote: >>>>>>>>>>> Hi Phil, >>>>>>>>>>> >>>>>>>>>>> I checked with NATIVE print dialog and with other app print >>>>>>>>>>> dialog, they are positioning the dialog a little ahead of >>>>>>>>>>> top-left corner (not at 1/3rd of the window as we are doing >>>>>>>>>>> now) >>>>>>>>>>> so I did the same and positioned the dialog in consistent >>>>>>>>>>> with our NATIVE print dialog. >>>>>>>>>> >>>>>>>>>> You mean consistently. in consistent means the opposite >>>>>>>>>> Please adjust that in the code comment. >>>>>>>>>> >>>>>>>>>> 50,50 is probably OK so long as you verified this is >>>>>>>>>> approximately >>>>>>>>>> what happens on most platforms, not just windows 8 or similar. >>>>>>>>>> I don't think you will find complete consistency because apps >>>>>>>>>> may >>>>>>>>>> control it and use different dialogs even on the same platform. >>>>>>>>>> On hidpi screens this may be closer to the top-left than you >>>>>>>>>> intend >>>>>>>>>> but I expect it is fine. >>>>>>>>>> >>>>>>>>> Tested on windows, linux and it works ok. We showed the dialog >>>>>>>>> at x+50,y+50 where x,y is the coordinate of the active window. >>>>>>>>> Do not have local mac system to test multimonitor setup. >>>>>>>>>> The one main thing that you should verify is what happens in >>>>>>>>>> the case >>>>>>>>>> a native app top-level window is smaller than the print >>>>>>>>>> dialog and is positioned >>>>>>>>>> at the bottom right (of the right-most display). Does the >>>>>>>>>> native app ensure >>>>>>>>>> that the dialog is wholly on-screen ? I don't think your code >>>>>>>>>> will do that. >>>>>>>>>> And Safari on Mac at least seems to do that. I guess that >>>>>>>>>> most apps try >>>>>>>>>> their best to keep the dialog wholly on-screen. >>>>>>>>>> >>>>>>>>> Tested this case where window bounds is smaller than print dialog >>>>>>>>> but because of this check in ServiceUI.java >>>>>>>>> >>>>>>>>> // if portion of dialog is not within the gc boundary >>>>>>>>> if (!gcBounds.contains(dlgBounds)) { >>>>>>>>> // put in the center relative to parent frame/dialog >>>>>>>>> dialog.setLocationRelativeTo(owner); >>>>>>>>> } >>>>>>>>> >>>>>>>>> the dialog is shown in the primary window. >>>>>>>>> I saw we did not have this check for pageDialog(attr) where >>>>>>>>> the dialog is shown in secondary monitor despite gcBounds >>>>>>>>> smaller than print dialog. >>>>>>>>> Therefore, I removed this check from ServiceUI. >>>>>>>>> >>>>>>>>> Please find the updated webrev: >>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.03/ >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Prasanta >>>>>>>>>> -phil. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Please find the updated webrev >>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.02/ >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> Prasanta >>>>>>>>>>> On 1/22/2016 4:59 AM, Phil Race wrote: >>>>>>>>>>>> That is definitely better .. although I wonder if it would >>>>>>>>>>>> be even better >>>>>>>>>>>> if you found when there is an 'active' window that you >>>>>>>>>>>> tried to >>>>>>>>>>>> position the dialog such that it is near the upper-left >>>>>>>>>>>> corner of that window ? >>>>>>>>>>>> Please experiment and see how that looks compared to what >>>>>>>>>>>> other apps are doing. >>>>>>>>>>>> >>>>>>>>>>>> -phil. >>>>>>>>>>>> >>>>>>>>>>>> On 01/21/2016 01:45 AM, prasanta sadhukhan wrote: >>>>>>>>>>>>> Hi Phil, >>>>>>>>>>>>> >>>>>>>>>>>>> Please find the updated webrev >>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.01/ >>>>>>>>>>>>> which do away with the change in ServiceUI. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards >>>>>>>>>>>>> Prasanta >>>>>>>>>>>>> On 1/21/2016 2:59 AM, Phil Race wrote: >>>>>>>>>>>>>> The changes in ServiceUI seem like they can cause the >>>>>>>>>>>>>> spec. to be contradicted. >>>>>>>>>>>>>> It says >>>>>>>>>>>>>> >>>>>>>>>>>>>> * @param gc used to select screen. null means primary >>>>>>>>>>>>>> or default screen. >>>>>>>>>>>>>> >>>>>>>>>>>>>> but you update the code such that it will use the active >>>>>>>>>>>>>> window. >>>>>>>>>>>>>> If that is on a secondary screen but null was passed in. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I am not entirely sure why ServiceUI needs to be changed >>>>>>>>>>>>>> at all. >>>>>>>>>>>>>> It is just the caller of ServiceUI .. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -phil. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 01/20/2016 03:08 AM, prasanta sadhukhan wrote: >>>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8138749 >>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.00/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please review a fix for a long standing issue whereby it >>>>>>>>>>>>>>> is seen that >>>>>>>>>>>>>>> PrinterJob.printDialog(attr set) does not support >>>>>>>>>>>>>>> multi-monitor setup. When this API is invoked, the print >>>>>>>>>>>>>>> dialog is always displayed on the default screen device >>>>>>>>>>>>>>> regardless of where the application is running. >>>>>>>>>>>>>>> This is because this method >>>>>>>>>>>>>>> uses ServiceDialog class for creating the dialog and >>>>>>>>>>>>>>> that indeed supports passing a GC in which we would like >>>>>>>>>>>>>>> to have the dialog. But printer job always uses the >>>>>>>>>>>>>>> GraphicsConfig of the default screen device >>>>>>>>>>>>>>> resulting in print dialog to be shown on primary >>>>>>>>>>>>>>> device/monitor. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I have not considered pageDialog() for this fix. Will >>>>>>>>>>>>>>> create a separate bugid and send a patch for that as >>>>>>>>>>>>>>> well once this fix is approved. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>> Prasanta >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> From bourges.laurent at gmail.com Thu Feb 18 08:41:31 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 18 Feb 2016 09:41:31 +0100 Subject: [OpenJDK 2D-Dev] RFR 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering In-Reply-To: References: <56B3F68F.3070204@oracle.com> <56B3F8C3.7040609@oracle.com> <56B917CC.5090806@oracle.com> <56BA8BBF.9070609@oracle.com> <56BD0942.1060007@oracle.com> Message-ID: Phil & Jim, Here is an updated webrev including jim's changes to comments: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8148886.5/ Hope it is ready to push, Regards, Laurent 2016-02-12 9:46 GMT+01:00 Laurent Bourg?s : > Jim & Phil, > > 2016-02-11 23:20 GMT+01:00 Jim Graham : > >> It all looks great. The comments are fine for internal documentation, >> but here is a suggestion for the initial comment on a couple of the >> Provider classes. I don't need to review the changes to comments. >> > > Thanks Jim for your carefull reviews and your suggestions: I integrated > your changes to javadoc with care. > > FYI I always use the following command to remove redundant white spaces: > find . -type f -name '*.java' -exec sed --in-place 's/[[:space:]]\+$//' {} > \; > > To summarize, I can count on jim's review but another one is missing. > > Phil, do you approve too ? > > Regards, > Laurent > -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Thu Feb 18 10:41:05 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 18 Feb 2016 13:41:05 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8146042 Offscreen rendering is different from onscreen one In-Reply-To: <56B7AB0E.9000705@oracle.com> References: <5697E44B.2040100@oracle.com> <5697E7B1.2080207@oracle.com> <569898C4.1030404@oracle.com> <5698F46A.5020809@oracle.com> <5699025C.7030904@oracle.com> <5699143A.4070408@oracle.com> <56992111.9000501@oracle.com> <5699603C.6000200@oracle.com> <569E1E4E.9080309@oracle.com> <56A0E584.3050204@oracle.com> <56AF2412.3040905@oracle.com> <56B7AB0E.9000705@oracle.com> Message-ID: <56C59FC1.7070504@oracle.com> Please see the updated webrev http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.03/. The test is changed to execute per-pixel compare of on-screen and off-screen images in case of HiDPI device since the shape positioning depends on the scale factor. --Semyon On 2/7/2016 11:37 PM, Sergey Bylokhov wrote: > On 01.02.16 12:23, Semyon Sadetsky wrote: >> >> >> On 1/21/2016 5:04 PM, Sergey Bylokhov wrote: >>> On 19/01/16 14:30, Semyon Sadetsky wrote: >>>> We are getting error because of incorrect fudge factor added to the >>>> "to" >>>> line coordinates (for line from - to). >>>> See the updated version of the fix in which test should work on OS X: >>>> http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.02/ >>>> Test fails on my mac book-pro with integrated i7 GPU - rectangle is >>>> drawn at wrong position. >>> >>> It will fail on any hdpi systems(including osx+retina), The reason is >>> that: when you create a VolatileImage it will take into account >>> default transform of the GraphicsConfiguration(on hdpi systems it will >>> be x2). When you draw a line to this VI and then take s spapshot then >>> you convert the big VI image to the small BI. you need to take into >>> account this scale and draw VI to BI 1-2-1, something like this: >>> BufferedImage capture = new BufferedImage(12x2, 12x2, >>> BufferedImage.TYPE_4BYTE_ABGR_PRE); >>> capture.createGraphics().drawImage(vi,0,0,12x2,12x2,null); >>> >>> Note that even in this case the line locations check is incorrect and >>> should be adjusted. >> I tried what you've proposed. The position of the up-scaled image is >> wrong as well 1-21 instead of 2-22. > > Why wrong? this is correct result, the simple BufferedImage will > produce the same: > BufferedImage bi = new BufferedImage(12*2, 12*2, > BufferedImage.TYPE_INT_ARGB_PRE); > Graphics2D g1 = bi.createGraphics(); > g1.scale(2,2); > g1.setColor(Color.black); > g1.drawRect(1, 1, 9, 9); > g1.dispose(); > ImageIO.write(bi,"png",new File("gold.png")); > > When you draw a line you set the middle point of the line, not the > left point. So the x=1px when scaled will cover the pixels 1 and 2, > not the 2 and 3. > >> I think test may be remained the same. >>> >>> >>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> --Semyon >>>>>>>>>> >>>>>>>>>> On 1/14/2016 9:23 PM, Phil Race wrote: >>>>>>>>>>> This fudge factor was last adjusted in >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6597822 >>>>>>>>>>> way back before the D3D pipeline was released and the comments >>>>>>>>>>> seem to >>>>>>>>>>> indicate that >>>>>>>>>>> there was a fair amount of testing on different hardware. >>>>>>>>>>> >>>>>>>>>>> I don't know why this seems to be in un-specified >>>>>>>>>>> hardware-dependent >>>>>>>>>>> territory but >>>>>>>>>>> it seems quite possible that this could just as easily >>>>>>>>>>> introduce a >>>>>>>>>>> different artifact >>>>>>>>>>> on some other hardware. >>>>>>>>>>> >>>>>>>>>>> What exactly are you testing on ? And I think it needs to >>>>>>>>>>> include at >>>>>>>>>>> least one Nvidia >>>>>>>>>>> and one AMD/ATI card. >>>>>>>>>>> >>>>>>>>>>> -phil. >>>>>>>>>>> >>>>>>>>>>> On 1/14/2016 10:09 AM, Semyon Sadetsky wrote: >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> Please review the fix for jdk9. >>>>>>>>>>>> >>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8146042 >>>>>>>>>>>> webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> The root cause is incorrect coordinate rounding in D3D >>>>>>>>>>>> renderer. To >>>>>>>>>>>> fix the issue one of fudge factors was adjusted. >>>>>>>>>>>> >>>>>>>>>>>> Another issue mentioning in the JIRA ticket is taken out as a >>>>>>>>>>>> separate bug. >>>>>>>>>>>> >>>>>>>>>>>> --Semyon >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From james.graham at oracle.com Thu Feb 18 22:40:20 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 18 Feb 2016 14:40:20 -0800 Subject: [OpenJDK 2D-Dev] RFR 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering In-Reply-To: References: <56B3F68F.3070204@oracle.com> <56B3F8C3.7040609@oracle.com> <56B917CC.5090806@oracle.com> <56BA8BBF.9070609@oracle.com> <56BD0942.1060007@oracle.com> Message-ID: <56C64854.5040600@oracle.com> Hi Laurent, I swear I thought I remember asking this before and getting an answer, but I can't find it. RenderContext line 49 - should that be "!= HARD" so that you keep a hard reference for SOFT as well? Also, I just noticed a typo in the sample code in ReentrantContextProvider, shouldn't the constructor in the newContext() method be "new ReentrantContextImpl()"? (TileState probably came from cutting and pasting from AAShapePipe.) ...jim On 2/18/2016 12:41 AM, Laurent Bourg?s wrote: > Phil & Jim, > > Here is an updated webrev including jim's changes to comments: > http://cr.openjdk.java.net/~lbourges/marlin/marlin-8148886.5/ > > Hope it is ready to push, > > Regards, > Laurent > > 2016-02-12 9:46 GMT+01:00 Laurent Bourg?s >: > > Jim & Phil, > > 2016-02-11 23:20 GMT+01:00 Jim Graham >: > > It all looks great. The comments are fine for internal > documentation, but here is a suggestion for the initial comment > on a couple of the Provider classes. I don't need to review the > changes to comments. > > > Thanks Jim for your carefull reviews and your suggestions: I > integrated your changes to javadoc with care. > > FYI I always use the following command to remove redundant white spaces: > find . -type f -name '*.java' -exec sed --in-place > 's/[[:space:]]\+$//' {} \; > > To summarize, I can count on jim's review but another one is missing. > > Phil, do you approve too ? > > Regards, > Laurent > > From jayathirth.d.v at oracle.com Fri Feb 19 06:05:12 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 18 Feb 2016 22:05:12 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED In-Reply-To: <46329edf-4cbe-48d4-a519-c908b09844a6@default> References: <2c9221dc-ed76-481a-8bee-a694d313448e@default> <56BD0CAB.6080704@oracle.com> <90de7741-c175-4803-9c3e-30b1039b2774@default> <56C227D1.1030600@oracle.com> <46329edf-4cbe-48d4-a519-c908b09844a6@default> Message-ID: Hi Jim, Gentle reminder. Please let me your inputs after testing. Thanks, Jay -----Original Message----- From: Jayathirth D V Sent: Tuesday, February 16, 2016 10:03 PM To: Jim Graham Cc: 2d-dev at openjdk.java.net; Philip Race; Prasanta Sadhukhan Subject: RE: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED Hi Jim, Thanks for letting me know about the importance of custom color maps. I was not able to understand what you mentioned previously since I am new to this terminology. Regarding performance I checked with image having complete 255,255,128 pixels and ran it for 100 times. I am running on Windows 7 Professional SP1 with Intel i5-5300U CPU. Overall I don't see much difference in time taken for drawImage() API before and after change. Details for INT_RGB image as input: Before change : Minimum time 536827ns Maximum time 1560947ns Average time 871167ns After change : Minimum time 536380ns Maximum time 1468130ns Average time 830778ns There is +/- 10% delta both for before and after change time but there is no major gap. Even for image with other input type it holds the same. Regarding custom color maps, previously I ran on default color map generated in TYPE_BYTE_INDEXED constructor. Now I tested with modified color map so that it doesn't contain any of the primary color values. Instead of using 0-255 values with value 51 increments in R,G,B components I used color map with 20-245 values with value 45 as increment. For this color map before and after change all the pixels are referring to same index in color map irrespective of removal of error delta addition in case of primary colors. I have attached log for Red and Green primary colors before and after change(Was not able to attach for more since it exceeded 120KB mailing list limit). Please search for "Final index value =" in the logs. Please let me know your inputs. Thanks, Jay -----Original Message----- From: Jim Graham Sent: Tuesday, February 16, 2016 1:03 AM To: Jayathirth D V Cc: 2d-dev at openjdk.java.net; Philip Race; Prasanta Sadhukhan Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED Hi Jayathirth, The issue with testing performance with white images is that the tests allow the code to eliminate 3 indexed fetches which take time. Primary colors end up being the one obscure case where the new code might be faster. But, non-primary colors would be slower by a fair amount, so performance testing with converting a randomized or non-primary-color image are the more telling case. An image filled with 255,255,128 would be the worst case because it would involve all of the tests and still have to do all of the lookups. My question about how this works with custom colormaps was not really addressed by your response. A simple test to make sure the colormap has accurate (or very close) conversions for the primary colors may be enough to validate the colormap for the indicated tests. If the colormap contains no pure conversions for some of the primary colors then they may need to be dithered anyway... ...jim On 2/15/16 3:39 AM, Jayathirth D V wrote: > Hi Jim, > > I performed performance analysis with white image so that all > conditions are checked in the new branch added. There is no major > difference in time taken before and after change. For each input I > have tested time taken for drawImage() API to convert from every > format to Byte indexed type. For every unique conversion test is run > for 100 times. Please find the details: > > Input > > type > > > > Min > > before change > > (ns) > > > > Min > > after change > > (ns) > > > > Max > > before change > > (ns) > > > > Max > > after change > > (ns) > > > > Average > > before change > > (ns) > > > > Average > > after > > change > > (ns) > > INT_RGB > > > > 523437 > > > > 481491 > > > > 1230724 > > > > 1270440 > > > > 789452 > > > > 666144 > > INT_ARGB > > > > 500232 > > > > 493986 > > > > 12406307 > > > > 1308816 > > > > 793384 > > > > 654015 > > INT_ARGB_PRE > > > > 500233 > > > > 492201 > > > > 1037057 > > > > 981277 > > > > 710250 > > > > 699214 > > INT_BGR > > > > 537716 > > > > 562706 > > > > 1446703 > > > > 2046001 > > > > 862377 > > > > 863256 > > 3BYTE_BGR > > > > 483275 > > > > 481045 > > > > 1181638 > > > > 1384676 > > > > 651427 > > > > 580961 > > 4BYTE_ABGR > > > > 544410 > > > > 499786 > > > > 1292305 > > > > 968783 > > > > 690106 > > > > 683881 > > 4BYTE_ABGR_PRE > > > > 504249 > > > > 505588 > > > > 1680086 > > > > 1216445 > > > > 756101 > > > > 687750 > > USHORT_565_RGB > > > > 507818 > > > > 505588 > > > > 978153 > > > > 1346746 > > > > 652908 > > > > 655782 > > USHORT_555_RGB > > > > 510496 > > > > 509604 > > > > 952272 > > > > 1162004 > > > > 650418 > > > > 670811 > > BYTE_GRAY > > > > 481491 > > > > 478367 > > > > 1140585 > > > > 1799231 > > > > 691160 > > > > 583250 > > USHORT_GRAY > > > > 506927 > > > > 507373 > > > > 1375751 > > > > 1255267 > > > > 728202 > > > > 646902 > > BYTE_BINARY > > > > 541733 > > > > 496217 > > > > 1083466 > > > > 959411 > > > > 730527 > > > > 728461 > > The changes are tested with plain images having primary colors like > RED, GREEN, BLUE, BLACK and WHITE. > > Thanks, > > Jay > > -----Original Message----- > From: Jim Graham > Sent: Friday, February 12, 2016 4:05 AM > To: Jayathirth D V; 2d-dev at openjdk.java.net; Philip Race; Prasanta > Sadhukhan > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : > Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED > > Hi Jayathirth, > > Did you do any performance analysis of this change? You are adding 6 > tests and multiple branches to per-pixel code. > > The effectiveness of this technique depends on the colormap that we > have set up. For the BufferedImage.TYPE_INDEXED constructor we > produce a fairly nice colormap, but if someone creates a custom > colormap then the colors could be anything. We create a decent > inversion for just about any colormap, but that doesn't mean that > using only "the best match for solid red" will produce a better result > for a dithered approximation for red. It is true that if there is a > really good match for red then we should just use that, but if there > are no direct matches for red then we may choose to paint a red region > with solid orange even though there is another color in the colormap > that when mixed with orange approximates a red tone better. For > example, if a colormap contains no pure red, but > > contains: > > 240, 20, 0 > > 240, 0, 20 > > (I'm not sure if 20 is within our current error deltas that we use for > dithering, but this is an example not a test case.) > > Then using one of these alone might skew the color towards orange or > purple. Using both together in a dither pattern might keep the > overall hue impression as red, but with a small amount of noise in its saturation. > > What types of colormaps was this tested with? > > ...jim > > On 2/11/16 6:37 AM, Jayathirth D V wrote: > >> Hi, > >> > >> _Please review the following fix in JDK9:_ > >> > >> __ > >> > >> Bug :https://bugs.openjdk.java.net/browse/JDK-7116979 > >> > >> Webrev :http://cr.openjdk.java.net/~jdv/7116979/webrev.00/ > >> > >> Issue : When Image containing black pixels are converted from any > >> format to Byte Indexed format some of the pixels are not black. They > >> are following pattern similar to dithering. > >> > >> Root cause : When we convert any format type to ByteIndexed we are > >> adding Error delta values to R,G,B components using dithering indices. > >> This is causing some pixels values to not point to proper index in > >> color table. > >> > >> Solution : There is no need to add error delta for primary colors > >> containing basic values in R,G,B components. Exclude such pixels from > >> delta addition. > >> > >> Thanks, > >> > >> Jay > >> > From bourges.laurent at gmail.com Fri Feb 19 08:14:29 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Fri, 19 Feb 2016 09:14:29 +0100 Subject: [OpenJDK 2D-Dev] RFR 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering In-Reply-To: <56C64854.5040600@oracle.com> References: <56B3F68F.3070204@oracle.com> <56B3F8C3.7040609@oracle.com> <56B917CC.5090806@oracle.com> <56BA8BBF.9070609@oracle.com> <56BD0942.1060007@oracle.com> <56C64854.5040600@oracle.com> Message-ID: Dear Jim, Please have a look to this updated webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8148886.6/ I fixed the javadoc in ReentrantContextProvider: see below. 2016-02-18 23:40 GMT+01:00 Jim Graham : > > I swear I thought I remember asking this before and getting an answer, but > I can't find it. > > RenderContext line 49 - should that be "!= HARD" so that you keep a hard > reference for SOFT as well? > This concerns the ArrayCacheHolder that gathers several ArrayCache instances that may consume a lot of memory: for example, it holds large primitive arrays in case of large shapes / images or very complex ones. To minimize the memory footprint, I deliberately use a WeakReference(holder) i.e. such large caches are "short live" (always in GC's young generation or TLAB ?). When the RendererContext is also kept in memory by a WeakReference, then it is redundant to have 2 WeakReferences: in this case, the forementioned statement set the USE_CACHE_HARD_REF to true that makes a strong reference between the RendererContext and its related ArrayCachesHolder. Finally I still plan to rewrite the "ArrayCache" feature as a more generic array cache as we discussed several times ! Probably it is time to do it now or after fixing the bug: https://bugs.openjdk.java.net/browse/JDK-8144938 > Also, I just noticed a typo in the sample code in > ReentrantContextProvider, shouldn't the constructor in the newContext() > method be "new ReentrantContextImpl()"? (TileState probably came from > cutting and pasting from AAShapePipe.) > Good catch: fixed. Besides I added a sample for ReentrantContextImpl: 52 * - create a subclass ReentrantContextImpl to hold the thread state: 53 * 54 * static final class ReentrantContextImpl extends ReentrantContext { 55 * // specific cached data 56 * } 57 * Moreover I checked that the sample code is valid as it compiles properly in a new class. PS: I will be on winter holidays (leaving tomorrow for 1 week), so I would like to push this patch myself asap. If it is not possible, could you please handle the review thread & push it for me ? Cheers, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Fri Feb 19 09:18:41 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Fri, 19 Feb 2016 14:48:41 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8066139, , Null return from PrintJob.getGraphics() running closed/java/awt/PrintJob/HighResTest/HighResTest.java Message-ID: <56C6DDF1.1020009@oracle.com> Hi Phil, All, Bug: https://bugs.openjdk.java.net/browse/JDK-8066139 webrev: http://cr.openjdk.java.net/~psadhukhan/8066139/webrev.00/ It was seen after fix of JDK-8061267 : PrinterJob: Specified Page Ranges not displayed in Windows Native Print Dialog the closed/java/awt/PrintJob/HighResTest/HighResTest.java was failing with NPE when PrinterJob.getGraphics() is called the 2nd time before calling PrinterJob.end(). The above fix caused this regression because it sets the PD_PAGENUMS flag for windows PrintDlg struct which causes *Pages* radio button to be selected in print dialog. However, fromPage and toPage was both set to 1 so after the 1st page is printed, RasterPrinterJob.print(attributes) finishes and graphicsToBeDrawn.closeWhenEmpty() gets called http://hg.openjdk.java.net/jdk9/client/jdk/file/d8def65c6c00/src/java.desktop/share/classes/sun/print/PrintJob2D.java#l1006 which sets the queue to null so when PrinterJob2D#getGraphics() calls graphicsToBeDrawn.pop() it sees queue to be null and sets graphics object to be null so PrinterJob.getGraphics() gets null and g.drawLine in testcase causes NPE since g is null. Fix was done to set the PD_PAGENUMS flag only when toPage is more than fromPage in which case, "All" will be selected in printer dialog and RasterPrinterJob.print() will finish only after printing all the pages. Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Feb 19 18:53:39 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 19 Feb 2016 10:53:39 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8066139, , Null return from PrintJob.getGraphics() running closed/java/awt/PrintJob/HighResTest/HighResTest.java In-Reply-To: <56C6DDF1.1020009@oracle.com> References: <56C6DDF1.1020009@oracle.com> Message-ID: <56C764B3.9020005@oracle.com> I am not sure I can be correctly understanding the fix as the ramification seems to be that if the users wants to print only Page 3 of a 10 page document and so sets from page=3 and to page=3, that this request will be ignored and all pages will be printed .. can you test such a scenario. Additionally, have you tried running the original test case provided with 8061267 against your fix ? Also when I ran the HighResTest on a current build I saw a null graphics on the very first call to getGraphics() which is different than what I interpret you as saying - you see the null *after* the first page is printed. -phil. On 02/19/2016 01:18 AM, prasanta sadhukhan wrote: > Hi Phil, All, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066139 > webrev: http://cr.openjdk.java.net/~psadhukhan/8066139/webrev.00/ > > It was seen after fix of JDK-8061267 > : PrinterJob: > Specified Page Ranges not displayed in Windows Native Print Dialog > the closed/java/awt/PrintJob/HighResTest/HighResTest.java was failing > with NPE when PrinterJob.getGraphics() is called the 2nd time before > calling PrinterJob.end(). > > The above fix caused this regression because it sets the PD_PAGENUMS > flag for windows PrintDlg struct which causes *Pages* radio button to > be selected in print dialog. > However, fromPage and toPage was both set to 1 so after the 1st page > is printed, RasterPrinterJob.print(attributes) finishes and > graphicsToBeDrawn.closeWhenEmpty() gets called > http://hg.openjdk.java.net/jdk9/client/jdk/file/d8def65c6c00/src/java.desktop/share/classes/sun/print/PrintJob2D.java#l1006 > > which sets the queue to null so when PrinterJob2D#getGraphics() calls > graphicsToBeDrawn.pop() it sees queue to be null and sets graphics > object to be null so > PrinterJob.getGraphics() gets null and g.drawLine in testcase causes > NPE since g is null. > > Fix was done to set the PD_PAGENUMS flag only when toPage is more than > fromPage in which case, "All" will be selected in printer dialog and > RasterPrinterJob.print() will finish only after printing all the pages. > > Regards > Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Feb 19 20:25:52 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 19 Feb 2016 12:25:52 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8066139, , Null return from PrintJob.getGraphics() running closed/java/awt/PrintJob/HighResTest/HighResTest.java In-Reply-To: <56C764B3.9020005@oracle.com> References: <56C6DDF1.1020009@oracle.com> <56C764B3.9020005@oracle.com> Message-ID: <56C77A50.7010605@oracle.com> I am having trouble building JDK 9 at the moment so i applied 8061267 to jdk8u-dev and was able to reproduce the regression and have a couple of observations - I am now seeing the NPE after the first page as you did .. puzzling. - I next applied your fix but still see the NPE ! It appears that all your fix did is stop the "PD_PAGENUMS" flag being automatically set. If I manually select it, (ie select that "Pages" radio button) then press print, then voila, the NPE is back! -phil. On 02/19/2016 10:53 AM, Phil Race wrote: > I am not sure I can be correctly understanding the fix as the > ramification seems > to be that if the users wants to print only Page 3 of a 10 page > document and so sets > from page=3 and to page=3, that this request will be ignored and all > pages will > be printed .. can you test such a scenario. > > Additionally, have you tried running the original test case provided > with 8061267 > against your fix ? > > Also when I ran the HighResTest on a current build I saw a null > graphics on > the very first call to getGraphics() which is different than what I > interpret > you as saying - you see the null *after* the first page is printed. > > -phil. > > On 02/19/2016 01:18 AM, prasanta sadhukhan wrote: >> Hi Phil, All, >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8066139 >> webrev: http://cr.openjdk.java.net/~psadhukhan/8066139/webrev.00/ >> >> It was seen after fix of JDK-8061267 >> : PrinterJob: >> Specified Page Ranges not displayed in Windows Native Print Dialog >> the closed/java/awt/PrintJob/HighResTest/HighResTest.java was failing >> with NPE when PrinterJob.getGraphics() is called the 2nd time before >> calling PrinterJob.end(). >> >> The above fix caused this regression because it sets the PD_PAGENUMS >> flag for windows PrintDlg struct which causes *Pages* radio button to >> be selected in print dialog. >> However, fromPage and toPage was both set to 1 so after the 1st page >> is printed, RasterPrinterJob.print(attributes) finishes and >> graphicsToBeDrawn.closeWhenEmpty() gets called >> http://hg.openjdk.java.net/jdk9/client/jdk/file/d8def65c6c00/src/java.desktop/share/classes/sun/print/PrintJob2D.java#l1006 >> >> which sets the queue to null so when PrinterJob2D#getGraphics() calls >> graphicsToBeDrawn.pop() it sees queue to be null and sets graphics >> object to be null so >> PrinterJob.getGraphics() gets null and g.drawLine in testcase causes >> NPE since g is null. >> >> Fix was done to set the PD_PAGENUMS flag only when toPage is more >> than fromPage in which case, "All" will be selected in printer dialog >> and RasterPrinterJob.print() will finish only after printing all the >> pages. >> >> Regards >> Prasanta > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Fri Feb 19 21:32:20 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 19 Feb 2016 13:32:20 -0800 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED In-Reply-To: <46329edf-4cbe-48d4-a519-c908b09844a6@default> References: <2c9221dc-ed76-481a-8bee-a694d313448e@default> <56BD0CAB.6080704@oracle.com> <90de7741-c175-4803-9c3e-30b1039b2774@default> <56C227D1.1030600@oracle.com> <46329edf-4cbe-48d4-a519-c908b09844a6@default> Message-ID: <56C789E4.6000409@oracle.com> Hi Jayathirth, Thank you for attaching the detailed logs, but I don't have a program that can deal with the 7z files. Can you summarize what was learned from them? Also, the colormap you created, while subset, was a perfectly scaled cube. I was referring more to a random colormap where you might have 2 colors close to a primary, but neither is on a line from the primary to the 0.5 gray value so each has a different hue. That's something that can only be evaluated visually. One example of randomized colormaps is when we display via X11 onto an 8-bit display. That probably never happens any more, but we may not be able to allocate colors in the colormap in such a case and if another program has already allocated most of the dynamic colormap then we would not be able to add our own colors. This could be dealt with by simply marking our standard colormap as having primaries, or by scanning any given colormap and marking it if it has primaries, and then only perform this code on colormaps with the primaries. Solving it for our own colormap (or solving it for any colormap that has all primaries) would likely solve it for 99% of the vanishingly small number of developers who might run into this. But, in the end, what would we accomplish by adding this one very targeted fix? I'm also curious where the push for this is coming from. While we aren't perfect here, so much of the world today is focused on lossless image formats that I don't imagine there is much need for really good 8-bit indexed image support any more...? If anything, spatial dithering is considered a very low quality algorithm and error propagation dithering would handle all of the colormaps much better. We used to do error propagation dithering back in the JDK 1.1 days, but we dropped it when we introduced 2D because we added a bunch of ways to render small pieces of an image and only the current spatial dithering algorithm can be started in the middle of an operation. That doesn't mean that you can't still do error propagation since many operations already operate on the full image any way and you can still handle subset image operations by either converting the full image first and then copying or by tracing the errors from the edge of the image to the point of the subimage operation. We never bothered to upgrade our algorithms it just never seemed to be work that made sense to prioritize given that screens were overwhelmingly moving to full-color at the time of "Java 2" (and now to HDR in 2016+). 8-bit indexed isn't used much any more. If we want to make 8-bit destination images work better we'd be better off adopting error propagation dithering again rather than trying to tune this algorithm for black. It looks like the bug was closed briefly in 2014 and then reopened soon thereafter with no justification. It is true that we still have this anomaly, but it isn't clear why this is high enough priority to work on in 2016 when other bit depths would work better for destination imagery and other dithering algorithms would work better for most customers and even this targeted fix isn't perfect... ...jim On 2/16/2016 8:32 AM, Jayathirth D V wrote: > Hi Jim, > > Thanks for letting me know about the importance of custom color maps. I was not able to understand what you mentioned previously since I am new to this terminology. > > Regarding performance I checked with image having complete 255,255,128 pixels and ran it for 100 times. I am running on Windows 7 Professional SP1 with Intel i5-5300U CPU. Overall I don't see much difference in time taken for drawImage() API before and after change. Details for INT_RGB image as input: > > Before change : > Minimum time 536827ns > Maximum time 1560947ns > Average time 871167ns > > After change : > Minimum time 536380ns > Maximum time 1468130ns > Average time 830778ns > > There is +/- 10% delta both for before and after change time but there is no major gap. Even for image with other input type it holds the same. > > > Regarding custom color maps, previously I ran on default color map generated in TYPE_BYTE_INDEXED constructor. Now I tested with modified color map so that it doesn't contain any of the primary color values. Instead of using 0-255 values with value 51 increments in R,G,B components I used color map with 20-245 values with value 45 as increment. For this color map before and after change all the pixels are referring to same index in color map irrespective of removal of error delta addition in case of primary colors. > > I have attached log for Red and Green primary colors before and after change(Was not able to attach for more since it exceeded 120KB mailing list limit). Please search for "Final index value =" in the logs. Please let me know your inputs. > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Tuesday, February 16, 2016 1:03 AM > To: Jayathirth D V > Cc: 2d-dev at openjdk.java.net; Philip Race; Prasanta Sadhukhan > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED > > Hi Jayathirth, > > The issue with testing performance with white images is that the tests allow the code to eliminate 3 indexed fetches which take time. Primary colors end up being the one obscure case where the new code might be faster. But, non-primary colors would be slower by a fair amount, so performance testing with converting a randomized or non-primary-color image are the more telling case. An image filled with 255,255,128 would be the worst case because it would involve all of the tests and still have to do all of the lookups. > > My question about how this works with custom colormaps was not really addressed by your response. A simple test to make sure the colormap has accurate (or very close) conversions for the primary colors may be enough to validate the colormap for the indicated tests. If the colormap contains no pure conversions for some of the primary colors then they may need to be dithered anyway... > > ...jim > > On 2/15/16 3:39 AM, Jayathirth D V wrote: >> Hi Jim, >> >> I performed performance analysis with white image so that all >> conditions are checked in the new branch added. There is no major >> difference in time taken before and after change. For each input I >> have tested time taken for drawImage() API to convert from every >> format to Byte indexed type. For every unique conversion test is run >> for 100 times. Please find the details: >> >> Input >> >> type >> >> >> >> Min >> >> before change >> >> (ns) >> >> >> >> Min >> >> after change >> >> (ns) >> >> >> >> Max >> >> before change >> >> (ns) >> >> >> >> Max >> >> after change >> >> (ns) >> >> >> >> Average >> >> before change >> >> (ns) >> >> >> >> Average >> >> after >> >> change >> >> (ns) >> >> INT_RGB >> >> >> >> 523437 >> >> >> >> 481491 >> >> >> >> 1230724 >> >> >> >> 1270440 >> >> >> >> 789452 >> >> >> >> 666144 >> >> INT_ARGB >> >> >> >> 500232 >> >> >> >> 493986 >> >> >> >> 12406307 >> >> >> >> 1308816 >> >> >> >> 793384 >> >> >> >> 654015 >> >> INT_ARGB_PRE >> >> >> >> 500233 >> >> >> >> 492201 >> >> >> >> 1037057 >> >> >> >> 981277 >> >> >> >> 710250 >> >> >> >> 699214 >> >> INT_BGR >> >> >> >> 537716 >> >> >> >> 562706 >> >> >> >> 1446703 >> >> >> >> 2046001 >> >> >> >> 862377 >> >> >> >> 863256 >> >> 3BYTE_BGR >> >> >> >> 483275 >> >> >> >> 481045 >> >> >> >> 1181638 >> >> >> >> 1384676 >> >> >> >> 651427 >> >> >> >> 580961 >> >> 4BYTE_ABGR >> >> >> >> 544410 >> >> >> >> 499786 >> >> >> >> 1292305 >> >> >> >> 968783 >> >> >> >> 690106 >> >> >> >> 683881 >> >> 4BYTE_ABGR_PRE >> >> >> >> 504249 >> >> >> >> 505588 >> >> >> >> 1680086 >> >> >> >> 1216445 >> >> >> >> 756101 >> >> >> >> 687750 >> >> USHORT_565_RGB >> >> >> >> 507818 >> >> >> >> 505588 >> >> >> >> 978153 >> >> >> >> 1346746 >> >> >> >> 652908 >> >> >> >> 655782 >> >> USHORT_555_RGB >> >> >> >> 510496 >> >> >> >> 509604 >> >> >> >> 952272 >> >> >> >> 1162004 >> >> >> >> 650418 >> >> >> >> 670811 >> >> BYTE_GRAY >> >> >> >> 481491 >> >> >> >> 478367 >> >> >> >> 1140585 >> >> >> >> 1799231 >> >> >> >> 691160 >> >> >> >> 583250 >> >> USHORT_GRAY >> >> >> >> 506927 >> >> >> >> 507373 >> >> >> >> 1375751 >> >> >> >> 1255267 >> >> >> >> 728202 >> >> >> >> 646902 >> >> BYTE_BINARY >> >> >> >> 541733 >> >> >> >> 496217 >> >> >> >> 1083466 >> >> >> >> 959411 >> >> >> >> 730527 >> >> >> >> 728461 >> >> The changes are tested with plain images having primary colors like >> RED, GREEN, BLUE, BLACK and WHITE. >> >> Thanks, >> >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Friday, February 12, 2016 4:05 AM >> To: Jayathirth D V; 2d-dev at openjdk.java.net; Philip Race; Prasanta >> Sadhukhan >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7116979 : >> Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED >> >> Hi Jayathirth, >> >> Did you do any performance analysis of this change? You are adding 6 >> tests and multiple branches to per-pixel code. >> >> The effectiveness of this technique depends on the colormap that we >> have set up. For the BufferedImage.TYPE_INDEXED constructor we >> produce a fairly nice colormap, but if someone creates a custom >> colormap then the colors could be anything. We create a decent >> inversion for just about any colormap, but that doesn't mean that >> using only "the best match for solid red" will produce a better result >> for a dithered approximation for red. It is true that if there is a >> really good match for red then we should just use that, but if there >> are no direct matches for red then we may choose to paint a red region >> with solid orange even though there is another color in the colormap >> that when mixed with orange approximates a red tone better. For >> example, if a colormap contains no pure red, but >> >> contains: >> >> 240, 20, 0 >> >> 240, 0, 20 >> >> (I'm not sure if 20 is within our current error deltas that we use for >> dithering, but this is an example not a test case.) >> >> Then using one of these alone might skew the color towards orange or >> purple. Using both together in a dither pattern might keep the >> overall hue impression as red, but with a small amount of noise in its saturation. >> >> What types of colormaps was this tested with? >> >> ...jim >> >> On 2/11/16 6:37 AM, Jayathirth D V wrote: >> >>> Hi, >> >>> >> >>> _Please review the following fix in JDK9:_ >> >>> >> >>> __ >> >>> >> >>> Bug :https://bugs.openjdk.java.net/browse/JDK-7116979 >> >>> >> >>> Webrev :http://cr.openjdk.java.net/~jdv/7116979/webrev.00/ >> >>> >> >>> Issue : When Image containing black pixels are converted from any >> >>> format to Byte Indexed format some of the pixels are not black. They >> >>> are following pattern similar to dithering. >> >>> >> >>> Root cause : When we convert any format type to ByteIndexed we are >> >>> adding Error delta values to R,G,B components using dithering indices. >> >>> This is causing some pixels values to not point to proper index in >> >>> color table. >> >>> >> >>> Solution : There is no need to add error delta for primary colors >> >>> containing basic values in R,G,B components. Exclude such pixels from >> >>> delta addition. >> >>> >> >>> Thanks, >> >>> >> >>> Jay >> >>> >> From james.graham at oracle.com Fri Feb 19 21:44:11 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 19 Feb 2016 13:44:11 -0800 Subject: [OpenJDK 2D-Dev] RFR 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering In-Reply-To: References: <56B3F68F.3070204@oracle.com> <56B3F8C3.7040609@oracle.com> <56B917CC.5090806@oracle.com> <56BA8BBF.9070609@oracle.com> <56BD0942.1060007@oracle.com> <56C64854.5040600@oracle.com> Message-ID: <56C78CAB.1040104@oracle.com> Hi Laurent, The code comment looks good now. With respect to the ArrachCacheHolder, if the refType is SOFT, then you have a SOFT reference holding a WEAK reference. Isn't that similar to the WEAK/WEAK case that you feel is redundant? Or is there an important value to having a WEAK reference to the caches when the entire RendererContext is held by SOFT? (Perhaps WEAK is much more transient than SOFT?) I'm just verifying that you are intending that the Caches are held by a WEAK reference when the context is held by a SOFT reference. I don't really have a counter-argument other than it didn't make sense to me upon first glance, but if it is intentional than that's good enough for me. If that's true then I'm good with the fix... ...jim On 2/19/2016 12:14 AM, Laurent Bourg?s wrote: > Dear Jim, > > Please have a look to this updated webrev: > http://cr.openjdk.java.net/~lbourges/marlin/marlin-8148886.6/ > > I fixed the javadoc in ReentrantContextProvider: see below. > > > 2016-02-18 23:40 GMT+01:00 Jim Graham >: > > > I swear I thought I remember asking this before and getting an > answer, but I can't find it. > > RenderContext line 49 - should that be "!= HARD" so that you keep a > hard reference for SOFT as well? > > > This concerns the ArrayCacheHolder that gathers several ArrayCache > instances that may consume a lot of memory: for example, it holds large > primitive arrays in case of large shapes / images or very complex ones. > > To minimize the memory footprint, I deliberately use a > WeakReference(holder) i.e. such large caches are > "short live" (always in GC's young generation or TLAB ?). > > When the RendererContext is also kept in memory by a WeakReference, then > it is redundant to have 2 WeakReferences: > in this case, the forementioned statement set the USE_CACHE_HARD_REF to > true that makes a strong reference between the RendererContext and its > related ArrayCachesHolder. > > Finally I still plan to rewrite the "ArrayCache" feature as a more > generic array cache as we discussed several times ! > Probably it is time to do it now or after fixing the bug: > https://bugs.openjdk.java.net/browse/JDK-8144938 > > Also, I just noticed a typo in the sample code in > ReentrantContextProvider, shouldn't the constructor in the > newContext() method be "new ReentrantContextImpl()"? (TileState > probably came from cutting and pasting from AAShapePipe.) > > > Good catch: fixed. > > Besides I added a sample for ReentrantContextImpl: > > 52 * - create a subclass ReentrantContextImpl to hold the thread state: > 53 * > 54 * static final class ReentrantContextImpl extends ReentrantContext { > 55 * // specific cached data > 56 * } > 57 * > > Moreover I checked that the sample code is valid as it compiles properly > in a new class. > > > PS: I will be on winter holidays (leaving tomorrow for 1 week), so I > would like to push this patch myself asap. > If it is not possible, could you please handle the review thread & push > it for me ? > > Cheers, > Laurent From bourges.laurent at gmail.com Fri Feb 19 22:06:13 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Fri, 19 Feb 2016 23:06:13 +0100 Subject: [OpenJDK 2D-Dev] RFR 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering In-Reply-To: <56C78CAB.1040104@oracle.com> References: <56B3F68F.3070204@oracle.com> <56B3F8C3.7040609@oracle.com> <56B917CC.5090806@oracle.com> <56BA8BBF.9070609@oracle.com> <56BD0942.1060007@oracle.com> <56C64854.5040600@oracle.com> <56C78CAB.1040104@oracle.com> Message-ID: Dear Jim, With respect to the ArrayCacheHolder, if the refType is SOFT, then you have > a SOFT reference holding a WEAK reference. Isn't that similar to the > WEAK/WEAK case that you feel is redundant? Or is there an important value > to having a WEAK reference to the caches when the entire RendererContext is > held by SOFT? > In terms of liveness, a SoftReference is living a lot longer than a WeakReference; typically in my benchmarks, SoftReferences are only cleared when they are no more used for a long time (gc time threshold) i.e. after a very long time ! That's why I really want to have a SOFT/WEAK solution to maintain the RendererContext in memory longer (more useful ie higher reuse rate) than the ArrayCacheHolder (less useful). > (Perhaps WEAK is much more transient than SOFT?) > Exactly: weak references are (in practice) cleared at each young gen GC cycle ie their associated memory is very short lived. I'm just verifying that you are intending that the Caches are held by a > WEAK reference when the context is held by a SOFT reference. I don't really > have a counter-argument other than it didn't make sense to me upon first > glance, but if it is intentional than that's good enough for me. If that's > true then I'm good with the fix... > The current behaviour is working as expected i.e. intentional as I want to minimize the memory footprint: - RendererContext are kept in memory by a SoftReference = longer alive (to maximize their reuse) - ArrayCache are kept by a WeakReference = shorter alive (to reduce their footprint) Besides, ArrayCache contain larger primitive arrays that consumes a lot more memory than a RendererContext (larger cache) for large shapes / canvas that should happen less frequently so the reallocation overhead should remain small. Regards, Laurent On 2/19/2016 12:14 AM, Laurent Bourg?s wrote: > >> Dear Jim, >> >> Please have a look to this updated webrev: >> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8148886.6/ >> >> I fixed the javadoc in ReentrantContextProvider: see below. >> >> >> 2016-02-18 23:40 GMT+01:00 Jim Graham > >: >> >> >> >> I swear I thought I remember asking this before and getting an >> answer, but I can't find it. >> >> RenderContext line 49 - should that be "!= HARD" so that you keep a >> hard reference for SOFT as well? >> >> >> This concerns the ArrayCacheHolder that gathers several ArrayCache >> instances that may consume a lot of memory: for example, it holds large >> primitive arrays in case of large shapes / images or very complex ones. >> >> To minimize the memory footprint, I deliberately use a >> WeakReference(holder) i.e. such large caches are >> "short live" (always in GC's young generation or TLAB ?). >> >> When the RendererContext is also kept in memory by a WeakReference, then >> it is redundant to have 2 WeakReferences: >> in this case, the forementioned statement set the USE_CACHE_HARD_REF to >> true that makes a strong reference between the RendererContext and its >> related ArrayCachesHolder. >> >> Finally I still plan to rewrite the "ArrayCache" feature as a more >> generic array cache as we discussed several times ! >> Probably it is time to do it now or after fixing the bug: >> https://bugs.openjdk.java.net/browse/JDK-8144938 >> >> Also, I just noticed a typo in the sample code in >> ReentrantContextProvider, shouldn't the constructor in the >> newContext() method be "new ReentrantContextImpl()"? (TileState >> probably came from cutting and pasting from AAShapePipe.) >> >> >> Good catch: fixed. >> >> Besides I added a sample for ReentrantContextImpl: >> >> 52 * - create a subclass ReentrantContextImpl to hold the thread >> state: >> 53 * >> 54 * static final class ReentrantContextImpl extends ReentrantContext >> { >> 55 * // specific cached data >> 56 * } >> 57 * >> >> Moreover I checked that the sample code is valid as it compiles properly >> in a new class. >> >> >> PS: I will be on winter holidays (leaving tomorrow for 1 week), so I >> would like to push this patch myself asap. >> If it is not possible, could you please handle the review thread & push >> it for me ? >> >> Cheers, >> Laurent >> > -- -- Laurent Bourg?s -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Sat Feb 20 00:02:19 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 19 Feb 2016 16:02:19 -0800 Subject: [OpenJDK 2D-Dev] RFR 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering In-Reply-To: References: <56B3F68F.3070204@oracle.com> <56B3F8C3.7040609@oracle.com> <56B917CC.5090806@oracle.com> <56BA8BBF.9070609@oracle.com> <56BD0942.1060007@oracle.com> <56C64854.5040600@oracle.com> <56C78CAB.1040104@oracle.com> Message-ID: <56C7AD0B.4070108@oracle.com> Sounds good then... ...jim On 2/19/2016 2:06 PM, Laurent Bourg?s wrote: > Dear Jim, > > With respect to the ArrayCacheHolder, if the refType is SOFT, then > you have a SOFT reference holding a WEAK reference. Isn't that > similar to the WEAK/WEAK case that you feel is redundant? Or is > there an important value to having a WEAK reference to the caches > when the entire RendererContext is held by SOFT? > > > In terms of liveness, a SoftReference is living a lot longer than a > WeakReference; typically in my benchmarks, SoftReferences are only > cleared when they are no more used for a long time (gc time threshold) > i.e. after a very long time ! > That's why I really want to have a SOFT/WEAK solution to maintain the > RendererContext in memory longer (more useful ie higher reuse rate) than > the ArrayCacheHolder (less useful). > > (Perhaps WEAK is much more transient than SOFT?) > > > Exactly: weak references are (in practice) cleared at each young gen GC > cycle ie their associated memory is very short lived. > > I'm just verifying that you are intending that the Caches are held > by a WEAK reference when the context is held by a SOFT reference. I > don't really have a counter-argument other than it didn't make sense > to me upon first glance, but if it is intentional than that's good > enough for me. If that's true then I'm good with the fix... > > > The current behaviour is working as expected i.e. intentional as I want > to minimize the memory footprint: > - RendererContext are kept in memory by a SoftReference = longer alive > (to maximize their reuse) > - ArrayCache are kept by a WeakReference = shorter alive (to reduce > their footprint) > > Besides, ArrayCache contain larger primitive arrays that consumes a lot > more memory than a RendererContext (larger cache) for large shapes / > canvas that should happen less frequently so the reallocation overhead > should remain small. > > Regards, > Laurent > > On 2/19/2016 12:14 AM, Laurent Bourg?s wrote: > > Dear Jim, > > Please have a look to this updated webrev: > http://cr.openjdk.java.net/~lbourges/marlin/marlin-8148886.6/ > > I fixed the javadoc in ReentrantContextProvider: see below. > > > 2016-02-18 23:40 GMT+01:00 Jim Graham > >>: > > > > I swear I thought I remember asking this before and getting an > answer, but I can't find it. > > RenderContext line 49 - should that be "!= HARD" so that > you keep a > hard reference for SOFT as well? > > > This concerns the ArrayCacheHolder that gathers several ArrayCache > instances that may consume a lot of memory: for example, it > holds large > primitive arrays in case of large shapes / images or very > complex ones. > > To minimize the memory footprint, I deliberately use a > WeakReference(holder) i.e. such large caches are > "short live" (always in GC's young generation or TLAB ?). > > When the RendererContext is also kept in memory by a > WeakReference, then > it is redundant to have 2 WeakReferences: > in this case, the forementioned statement set the > USE_CACHE_HARD_REF to > true that makes a strong reference between the RendererContext > and its > related ArrayCachesHolder. > > Finally I still plan to rewrite the "ArrayCache" feature as a more > generic array cache as we discussed several times ! > Probably it is time to do it now or after fixing the bug: > https://bugs.openjdk.java.net/browse/JDK-8144938 > > Also, I just noticed a typo in the sample code in > ReentrantContextProvider, shouldn't the constructor in the > newContext() method be "new ReentrantContextImpl()"? > (TileState > probably came from cutting and pasting from AAShapePipe.) > > > Good catch: fixed. > > Besides I added a sample for ReentrantContextImpl: > > 52 * - create a subclass ReentrantContextImpl to hold the > thread state: > 53 * > 54 * static final class ReentrantContextImpl extends > ReentrantContext { > 55 * // specific cached data > 56 * } > 57 * > > Moreover I checked that the sample code is valid as it compiles > properly > in a new class. > > > PS: I will be on winter holidays (leaving tomorrow for 1 week), so I > would like to push this patch myself asap. > If it is not possible, could you please handle the review thread > & push > it for me ? > > Cheers, > Laurent > > > > > -- > -- > Laurent Bourg?s From prasanta.sadhukhan at oracle.com Mon Feb 22 05:37:01 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Mon, 22 Feb 2016 11:07:01 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8150233, , Missing copyright headers in XSurfaceData/ExtendedKeyCodes Message-ID: <56CA9E7D.9040707@oracle.com> Hi Phil, Bug: https://bugs.openjdk.java.net/browse/JDK-8150233 webrev: http://cr.openjdk.java.net/~psadhukhan/8150233/webrev.00/ Missing copyright added to the files. I guess 2nd reviewer is not needed for this change. Regards Prasanta From prasanta.sadhukhan at oracle.com Mon Feb 22 06:29:28 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Mon, 22 Feb 2016 11:59:28 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8066139, , Null return from PrintJob.getGraphics() running closed/java/awt/PrintJob/HighResTest/HighResTest.java In-Reply-To: <56C77A50.7010605@oracle.com> References: <56C6DDF1.1020009@oracle.com> <56C764B3.9020005@oracle.com> <56C77A50.7010605@oracle.com> Message-ID: <56CAAAC8.40009@oracle.com> Hi Phil, >>Additionally, have you tried running the original test case provided with 8061267 >> against your fix ? The 8061267 testcase behaves similarly before and after my fix. >> If I manually select it, (ie select that "Pages" radio button) then press print, >> then voila, the NPE is back! It seems this behaviour is same in linux too for this HighResTest testcase. Regards Prasanta On 2/20/2016 1:55 AM, Phil Race wrote: > I am having trouble building JDK 9 at the moment so i applied 8061267 > to jdk8u-dev > and was able to reproduce the regression and have a couple of observations > > - I am now seeing the NPE after the first page as you did .. puzzling. > - I next applied your fix but still see the NPE ! > > It appears that all your fix did is stop the "PD_PAGENUMS" flag being > automatically > set. If I manually select it, (ie select that "Pages" radio button) > then press print, > then voila, the NPE is back! > > -phil. > > > On 02/19/2016 10:53 AM, Phil Race wrote: >> I am not sure I can be correctly understanding the fix as the >> ramification seems >> to be that if the users wants to print only Page 3 of a 10 page >> document and so sets >> from page=3 and to page=3, that this request will be ignored and all >> pages will >> be printed .. can you test such a scenario. >> >> Additionally, have you tried running the original test case provided >> with 8061267 >> against your fix ? >> >> Also when I ran the HighResTest on a current build I saw a null >> graphics on >> the very first call to getGraphics() which is different than what I >> interpret >> you as saying - you see the null *after* the first page is printed. >> >> -phil. >> >> On 02/19/2016 01:18 AM, prasanta sadhukhan wrote: >>> Hi Phil, All, >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066139 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8066139/webrev.00/ >>> >>> It was seen after fix of JDK-8061267 >>> : PrinterJob: >>> Specified Page Ranges not displayed in Windows Native Print Dialog >>> the closed/java/awt/PrintJob/HighResTest/HighResTest.java was >>> failing with NPE when PrinterJob.getGraphics() is called the 2nd >>> time before calling PrinterJob.end(). >>> >>> The above fix caused this regression because it sets the PD_PAGENUMS >>> flag for windows PrintDlg struct which causes *Pages* radio button >>> to be selected in print dialog. >>> However, fromPage and toPage was both set to 1 so after the 1st page >>> is printed, RasterPrinterJob.print(attributes) finishes and >>> graphicsToBeDrawn.closeWhenEmpty() gets called >>> http://hg.openjdk.java.net/jdk9/client/jdk/file/d8def65c6c00/src/java.desktop/share/classes/sun/print/PrintJob2D.java#l1006 >>> >>> which sets the queue to null so when PrinterJob2D#getGraphics() >>> calls graphicsToBeDrawn.pop() it sees queue to be null and sets >>> graphics object to be null so >>> PrinterJob.getGraphics() gets null and g.drawLine in testcase causes >>> NPE since g is null. >>> >>> Fix was done to set the PD_PAGENUMS flag only when toPage is more >>> than fromPage in which case, "All" will be selected in printer >>> dialog and RasterPrinterJob.print() will finish only after printing >>> all the pages. >>> >>> Regards >>> Prasanta >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Feb 22 08:05:35 2016 From: philip.race at oracle.com (Philip Race) Date: Mon, 22 Feb 2016 13:35:35 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8066139, , Null return from PrintJob.getGraphics() running closed/java/awt/PrintJob/HighResTest/HighResTest.java In-Reply-To: <56CAAAC8.40009@oracle.com> References: <56C6DDF1.1020009@oracle.com> <56C764B3.9020005@oracle.com> <56C77A50.7010605@oracle.com> <56CAAAC8.40009@oracle.com> Message-ID: <56CAC14F.4030602@oracle.com> > It seems this behaviour is same in linux too for this HighResTest testcase. OK that is good information .. so is not really a regression from 8061267 as that is not in any way touching linux .. it is a pre-existing issue in a code path that was not being tested. -phil. On 2/22/16, 11:59 AM, prasanta sadhukhan wrote: > Hi Phil, > > >>Additionally, have you tried running the original test case provided > with 8061267 > >> against your fix ? > The 8061267 testcase behaves similarly before and after my fix. > > >> If I manually select it, (ie select that "Pages" radio button) then > press print, > >> then voila, the NPE is back! > It seems this behaviour is same in linux too for this HighResTest > testcase. > > Regards > Prasanta > On 2/20/2016 1:55 AM, Phil Race wrote: >> I am having trouble building JDK 9 at the moment so i applied 8061267 >> to jdk8u-dev >> and was able to reproduce the regression and have a couple of >> observations >> >> - I am now seeing the NPE after the first page as you did .. puzzling. >> - I next applied your fix but still see the NPE ! >> >> It appears that all your fix did is stop the "PD_PAGENUMS" flag >> being automatically >> set. If I manually select it, (ie select that "Pages" radio button) >> then press print, >> then voila, the NPE is back! >> >> -phil. >> >> >> On 02/19/2016 10:53 AM, Phil Race wrote: >>> I am not sure I can be correctly understanding the fix as the >>> ramification seems >>> to be that if the users wants to print only Page 3 of a 10 page >>> document and so sets >>> from page=3 and to page=3, that this request will be ignored and all >>> pages will >>> be printed .. can you test such a scenario. >>> >>> Additionally, have you tried running the original test case provided >>> with 8061267 >>> against your fix ? >>> >>> Also when I ran the HighResTest on a current build I saw a null >>> graphics on >>> the very first call to getGraphics() which is different than what I >>> interpret >>> you as saying - you see the null *after* the first page is printed. >>> >>> -phil. >>> >>> On 02/19/2016 01:18 AM, prasanta sadhukhan wrote: >>>> Hi Phil, All, >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066139 >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8066139/webrev.00/ >>>> >>>> It was seen after fix of JDK-8061267 >>>> : PrinterJob: >>>> Specified Page Ranges not displayed in Windows Native Print Dialog >>>> the closed/java/awt/PrintJob/HighResTest/HighResTest.java was >>>> failing with NPE when PrinterJob.getGraphics() is called the 2nd >>>> time before calling PrinterJob.end(). >>>> >>>> The above fix caused this regression because it sets the >>>> PD_PAGENUMS flag for windows PrintDlg struct which causes *Pages* >>>> radio button to be selected in print dialog. >>>> However, fromPage and toPage was both set to 1 so after the 1st >>>> page is printed, RasterPrinterJob.print(attributes) finishes and >>>> graphicsToBeDrawn.closeWhenEmpty() gets called >>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/d8def65c6c00/src/java.desktop/share/classes/sun/print/PrintJob2D.java#l1006 >>>> >>>> which sets the queue to null so when PrinterJob2D#getGraphics() >>>> calls graphicsToBeDrawn.pop() it sees queue to be null and sets >>>> graphics object to be null so >>>> PrinterJob.getGraphics() gets null and g.drawLine in testcase >>>> causes NPE since g is null. >>>> >>>> Fix was done to set the PD_PAGENUMS flag only when toPage is more >>>> than fromPage in which case, "All" will be selected in printer >>>> dialog and RasterPrinterJob.print() will finish only after printing >>>> all the pages. >>>> >>>> Regards >>>> Prasanta >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Feb 22 08:18:15 2016 From: philip.race at oracle.com (Philip Race) Date: Mon, 22 Feb 2016 13:48:15 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8150233, , Missing copyright headers in XSurfaceData/ExtendedKeyCodes In-Reply-To: <56CA9E7D.9040707@oracle.com> References: <56CA9E7D.9040707@oracle.com> Message-ID: <56CAC447.8050406@oracle.com> I'm surprised that any files were missing the GPL for so long. I am not sure how you chose 2009 and 2010 as the (C) dates. The date for these files should be a range based on when they first were created to last edited. I suspect these are both old .. And given that typically a script is run to update it to the last date it was edited, you probably should make the end date 2016 since it is going to happen anyway. So something like "2002, 2016" Also add noreg-doc (or something else if you find a better match) -phil. On 2/22/16, 11:07 AM, prasanta sadhukhan wrote: > Hi Phil, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8150233 > webrev: http://cr.openjdk.java.net/~psadhukhan/8150233/webrev.00/ > > Missing copyright added to the files. > I guess 2nd reviewer is not needed for this change. > > Regards > Prasanta From prasanta.sadhukhan at oracle.com Mon Feb 22 08:41:09 2016 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Mon, 22 Feb 2016 14:11:09 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8150233, , Missing copyright headers in XSurfaceData/ExtendedKeyCodes In-Reply-To: <56CAC447.8050406@oracle.com> References: <56CA9E7D.9040707@oracle.com> <56CAC447.8050406@oracle.com> Message-ID: <56CAC9A5.3050906@oracle.com> On 2/22/2016 1:48 PM, Philip Race wrote: > I'm surprised that any files were missing the GPL for so long. > I am not sure how you chose 2009 and 2010 as the (C) dates. I got this from history. XSurfaceData seemed to be pushed as per https://bugs.openjdk.java.net/browse/JDK-6307603 in 2010 and ExtendedKeyCodes seemed to be pushed as per https://bugs.openjdk.java.net/browse/JDK-6680988 in 2009 Added the end date too. http://cr.openjdk.java.net/~psadhukhan/8150233/webrev.01/ Regards Prasanta > The date for these files should be a range based on when they first > were created to last edited. I suspect these are both old .. > And given that typically a script is run to update it to the last date > it was edited, you probably should make the end date 2016 since > it is going to happen anyway. So something like "2002, 2016" > > Also add noreg-doc (or something else if you find a better match) > > -phil. > > On 2/22/16, 11:07 AM, prasanta sadhukhan wrote: >> Hi Phil, >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8150233 >> webrev: http://cr.openjdk.java.net/~psadhukhan/8150233/webrev.00/ >> >> Missing copyright added to the files. >> I guess 2nd reviewer is not needed for this change. >> >> Regards >> Prasanta From prahalad.kumar.narayanan at oracle.com Mon Feb 22 08:57:21 2016 From: prahalad.kumar.narayanan at oracle.com (Prahalad kumar Narayanan) Date: Mon, 22 Feb 2016 14:27:21 +0530 Subject: [OpenJDK 2D-Dev] Review Request: (JDK-8044788) [D3D] clip is ignored during surface->sw blit In-Reply-To: <56CAB11E.7040703@oracle.com> References: <56CAB11E.7040703@oracle.com> Message-ID: <56CACD71.9040006@oracle.com> Hello Everyone, 2D-Dev Group I continued to inspect the bug : JDK-8044788: [D3D] Clip is ignored during Surface > Sw Blit issue. Link : https://bugs.openjdk.java.net/browse/JDK-8044788 Here is a quick brief on root cause, solutions experimented and the webrev link for review. Kindly go through each of these items and provide your review so that we could check-in the bug fix. Root Cause: 1. D3DSurfaceToSw Blit does not pass clip value to the native cpp interface 2. Even if the clip were to be passed through JNI, the native interface ignores the clip because it uses d3d's StretRect API. 3. Henceforth, in the current implementation, clipping in SurfaceToSw usecase will work ' only ' for Rect bounds provided proper src(x, y), dst(x, y), width and height are provided. 4. It can be noted that : the proper src(x, y), dst(x, y) are also not calculated considering the intersection of these rectangles with the clip bounds. Different Solutions & Results 1. Three solutions are feasible to fix this issue: a. Solution 1: Convert the input Surface to Sysmem image, followed by regular Blit. To optimize this further, the conversion can be taken up only for Shape clips. b. Solution 2: Using existing classes in D3DBlitLoops, execute SwToSurface (copy dest to accel Surface), SurfaceToSurface (supports clip), SurfaceToSw (full copy) in order. c. Solution 3: Modify the native side interfaces to accept clip and execute Solution2 's logic in native code. 2. Upon various experiments, Solution 1 has been found to be faster than the rest. a. This can be attributed to fewer draw /or copy iterations compared to the other two solutions. b. In addition to the above fact, the code retains the same approach as used by the OGL pipeline making it easier to understand. Webrev Link: http://cr.openjdk.java.net/~psadhukhan/prahlad/webrev.00/ Sufficient comments have been added so that developers could easily get understanding of the issue and solution checked in. Thank you Have a great day Prahalad N. Subject: Re: [OpenJDK 2D-Dev] Review Request: (JDK-8044788) [D3D] clip is ignored during surface->sw blit Date: Wed, 15 Apr 2015 16:17:37 +0300 From: Sergey Bylokhov To: prasanta sadhukhan , 2d-dev at openjdk.java.net Hi, Prasanta. The same approach was used in OGL pipeline for the reason. Because we use glReadPixels and there is no way to apply the clip. So we read pixels to the temporary buffer and apply the clip later. Can you additionaly investigate is it possible to apply the clip in d3d directly or not? Note that this [1] comment is not correct in d3d, because d3d have only one direct blit D3d surface -> SW which is D3DSurfaceToSwBlit(IntArgb, ST_INT_ARGB), all other blits will be done via temporary buffer in D3DGeneralBlit. [1] > 523 // We can convert argb_pre data from D3d surface in two > places: > 524 // - During D3d surface -> SW blit > 525 // - During SW -> SW blit > 526 // The first one is faster when we use opaque D3d > surface, because in > 527 // this case we simply skip conversion and use color > components as is. > 528 // Because of this we align intermediate buffer type with > type of > 529 // destination not source. On 15.04.15 11:57, prasanta sadhukhan wrote: > Hi, > > I would like a review for a solution of this bug in jdk9. > The clip was ignored during surface->sw blit in d3d pipeline. The fix > is to use the clip parameter to calculate the blit coordinates correctly. > > Bug:https://bugs.openjdk.java.net/browse/JDK-8044788 > webrev:http://cr.openjdk.java.net/~psadhukhan/8044788/webrev.00/ > > Regards > Prasanta -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Feb 22 11:30:21 2016 From: philip.race at oracle.com (Philip Race) Date: Mon, 22 Feb 2016 17:00:21 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8150233, , Missing copyright headers in XSurfaceData/ExtendedKeyCodes In-Reply-To: <56CAC9A5.3050906@oracle.com> References: <56CA9E7D.9040707@oracle.com> <56CAC447.8050406@oracle.com> <56CAC9A5.3050906@oracle.com> Message-ID: <56CAF14D.3020906@oracle.com> This looks fine. -phil. On 2/22/16, 2:11 PM, prasanta sadhukhan wrote: > > > On 2/22/2016 1:48 PM, Philip Race wrote: >> I'm surprised that any files were missing the GPL for so long. >> I am not sure how you chose 2009 and 2010 as the (C) dates. > I got this from history. > XSurfaceData seemed to be pushed as per > https://bugs.openjdk.java.net/browse/JDK-6307603 in 2010 > and > ExtendedKeyCodes seemed to be pushed as per > https://bugs.openjdk.java.net/browse/JDK-6680988 in 2009 > > Added the end date too. > http://cr.openjdk.java.net/~psadhukhan/8150233/webrev.01/ > > Regards > Prasanta >> The date for these files should be a range based on when they first >> were created to last edited. I suspect these are both old .. >> And given that typically a script is run to update it to the last date >> it was edited, you probably should make the end date 2016 since >> it is going to happen anyway. So something like "2002, 2016" >> >> Also add noreg-doc (or something else if you find a better match) >> >> -phil. >> >> On 2/22/16, 11:07 AM, prasanta sadhukhan wrote: >>> Hi Phil, >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150233 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8150233/webrev.00/ >>> >>> Missing copyright added to the files. >>> I guess 2nd reviewer is not needed for this change. >>> >>> Regards >>> Prasanta > From philip.race at oracle.com Tue Feb 23 01:05:01 2016 From: philip.race at oracle.com (Philip Race) Date: Tue, 23 Feb 2016 06:35:01 +0530 Subject: [OpenJDK 2D-Dev] RFR 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering In-Reply-To: References: <56B3F68F.3070204@oracle.com> <56B3F8C3.7040609@oracle.com> <56B917CC.5090806@oracle.com> <56BA8BBF.9070609@oracle.com> <56BD0942.1060007@oracle.com> <56C64854.5040600@oracle.com> <56C78CAB.1040104@oracle.com> Message-ID: <56CBB03D.7040901@oracle.com> This all looks good to me. Sorry it took a long time to get to it. One thing that currently doesn't matter and perhaps never will is HardReference perhapscould also over-ride clear() : public void clear() { super.clear(); strongRef = null; } strongRef must no longer be final in this case. But if anyone ever needs that they can make the change .. So approved. -phil. On 2/20/16, 3:36 AM, Laurent Bourg?s wrote: > Dear Jim, > > With respect to the ArrayCacheHolder, if the refType is SOFT, then > you have a SOFT reference holding a WEAK reference. Isn't that > similar to the WEAK/WEAK case that you feel is redundant? Or is > there an important value to having a WEAK reference to the caches > when the entire RendererContext is held by SOFT? > > > In terms of liveness, a SoftReference is living a lot longer than a > WeakReference; typically in my benchmarks, SoftReferences are only > cleared when they are no more used for a long time (gc time threshold) > i.e. after a very long time ! > That's why I really want to have a SOFT/WEAK solution to maintain the > RendererContext in memory longer (more useful ie higher reuse rate) > than the ArrayCacheHolder (less useful). > > (Perhaps WEAK is much more transient than SOFT?) > > > Exactly: weak references are (in practice) cleared at each young gen > GC cycle ie their associated memory is very short lived. > > I'm just verifying that you are intending that the Caches are held > by a WEAK reference when the context is held by a SOFT reference. > I don't really have a counter-argument other than it didn't make > sense to me upon first glance, but if it is intentional than > that's good enough for me. If that's true then I'm good with the > fix... > > > The current behaviour is working as expected i.e. intentional as I > want to minimize the memory footprint: > - RendererContext are kept in memory by a SoftReference = longer alive > (to maximize their reuse) > - ArrayCache are kept by a WeakReference = shorter alive (to reduce > their footprint) > > Besides, ArrayCache contain larger primitive arrays that consumes a > lot more memory than a RendererContext (larger cache) for large shapes > / canvas that should happen less frequently so the reallocation > overhead should remain small. > > Regards, > Laurent > > On 2/19/2016 12:14 AM, Laurent Bourg?s wrote: > > Dear Jim, > > Please have a look to this updated webrev: > http://cr.openjdk.java.net/~lbourges/marlin/marlin-8148886.6/ > > > I fixed the javadoc in ReentrantContextProvider: see below. > > > 2016-02-18 23:40 GMT+01:00 Jim Graham > >>: > > > > I swear I thought I remember asking this before and getting an > answer, but I can't find it. > > RenderContext line 49 - should that be "!= HARD" so that > you keep a > hard reference for SOFT as well? > > > This concerns the ArrayCacheHolder that gathers several ArrayCache > instances that may consume a lot of memory: for example, it > holds large > primitive arrays in case of large shapes / images or very > complex ones. > > To minimize the memory footprint, I deliberately use a > WeakReference(holder) i.e. such large > caches are > "short live" (always in GC's young generation or TLAB ?). > > When the RendererContext is also kept in memory by a > WeakReference, then > it is redundant to have 2 WeakReferences: > in this case, the forementioned statement set the > USE_CACHE_HARD_REF to > true that makes a strong reference between the RendererContext > and its > related ArrayCachesHolder. > > Finally I still plan to rewrite the "ArrayCache" feature as a more > generic array cache as we discussed several times ! > Probably it is time to do it now or after fixing the bug: > https://bugs.openjdk.java.net/browse/JDK-8144938 > > Also, I just noticed a typo in the sample code in > ReentrantContextProvider, shouldn't the constructor in the > newContext() method be "new ReentrantContextImpl()"? > (TileState > probably came from cutting and pasting from AAShapePipe.) > > > Good catch: fixed. > > Besides I added a sample for ReentrantContextImpl: > > 52 * - create a subclass ReentrantContextImpl to hold the > thread state: > 53 * > 54 * static final class ReentrantContextImpl extends > ReentrantContext { > 55 * // specific cached data > 56 * } > 57 * > > Moreover I checked that the sample code is valid as it > compiles properly > in a new class. > > > PS: I will be on winter holidays (leaving tomorrow for 1 > week), so I > would like to push this patch myself asap. > If it is not possible, could you please handle the review > thread & push > it for me ? > > Cheers, > Laurent > > > > > -- > -- > Laurent Bourg?s -------------- next part -------------- An HTML attachment was scrubbed... URL: From bourges.laurent at gmail.com Tue Feb 23 21:25:36 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 23 Feb 2016 22:25:36 +0100 Subject: [OpenJDK 2D-Dev] RFR 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering In-Reply-To: <56CBB03D.7040901@oracle.com> References: <56B3F68F.3070204@oracle.com> <56B3F8C3.7040609@oracle.com> <56B917CC.5090806@oracle.com> <56BA8BBF.9070609@oracle.com> <56BD0942.1060007@oracle.com> <56C64854.5040600@oracle.com> <56C78CAB.1040104@oracle.com> <56CBB03D.7040901@oracle.com> Message-ID: Phil & Jim, Thanks for your reviews. Changeset pushed: http://hg.openjdk.java.net/jdk9/client/jdk/rev/4f7f1c6d613d 2016-02-23 2:05 GMT+01:00 Philip Race : > This all looks good to me. Sorry it took a long time to get to it. > That's fine. I wanted to push the SEGV fix as fast as possible but your comments & suggestions were interesting and improved definitely the proposed solution. One thing that currently doesn't matter and perhaps never will is > HardReference perhapscould also over-ride clear() : > > public void clear() { > super.clear(); > strongRef = null; > } > > strongRef must no longer be final in this case. > > But if anyone ever needs that they can make the change .. > That looks interesting but I doubt someone would need to clear such HardReference (but who knows ?). (for now I prefer keeping the strongRef field 'final' to let the compiler perform optimizations) > So approved. > > -phil. > Sincerly, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Wed Feb 24 11:45:46 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 24 Feb 2016 14:45:46 +0300 Subject: [OpenJDK 2D-Dev] Review Request: (JDK-8044788) [D3D] clip is ignored during surface->sw blit In-Reply-To: <56CACD71.9040006@oracle.com> References: <56CAB11E.7040703@oracle.com> <56CACD71.9040006@oracle.com> Message-ID: <56CD97EA.9030904@oracle.com> Hi, Prahalad. The fix looks good in general. I have only one question: In the complexClipBlit() you have this code: 552 // Type- indicates the pixel format of Sysmem based BufferedImage. 553 // Native side D3D interface supports copying surface contents to 554 // ST_INT_ARGB, ST_INT_ARGB_PRE and other pixel formats 555 final int type = typeval == D3DSurfaceData.ST_INT_ARGB_PRE ? 556 BufferedImage.TYPE_INT_ARGB_PRE : 557 BufferedImage.TYPE_INT_ARGB; This code was copied from the OGL version of the fix and it have two assumptions: - The type of the native texture can be ST_INT_ARGB_PRE, or can contains "other"(???) value. Please take a look to the OGLBlitLoops.java code. In OGL we register two different blits: OGLSurfaceToSwBlit blitSurfaceToIntArgbPre = new OGLSurfaceToSwBlit(SurfaceType.IntArgbPre,OGLSurfaceData.PF_INT_ARGB_PRE); // surface->sw ops new OGLSurfaceToSwBlit(SurfaceType.IntArgb,OGLSurfaceData.PF_INT_ARGB), blitSurfaceToIntArgbPre, So in OGL when the blit is called the type can be PF_INT_ARGB_PRE or PF_INT_ARGB. This is why we have "if" statement in the complexClipBlit. - The second assumption is that the native code is able to copy the d3d texture to the system memory and do conversion on the fly. The ogl code have such conversion(argb_pre is converted to argb in the OGLBlitLoops.c in the flip() method). Do you know our native d3d part is able to do the same? If yes, then we should register separate blits in D3DBlitLoops to cover different source/destination and change the "if". On 22.02.16 11:57, Prahalad kumar Narayanan wrote: > Hello Everyone, 2D-Dev Group > > I continued to inspect the bug : JDK-8044788: [D3D] Clip is ignored > during Surface > Sw Blit issue. > Link : https://bugs.openjdk.java.net/browse/JDK-8044788 > > Here is a quick brief on root cause, solutions experimented and the > webrev link for review. > Kindly go through each of these items and provide your review so that we > could check-in the bug fix. > > Root Cause: > 1. D3DSurfaceToSw Blit does not pass clip value to the native cpp interface > 2. Even if the clip were to be passed through JNI, the native interface > ignores the clip because it uses d3d's StretRect API. > 3. Henceforth, in the current implementation, clipping in SurfaceToSw > usecase will work ' only ' for Rect bounds provided proper src(x, y), > dst(x, y), width and height are provided. > 4. It can be noted that : the proper src(x, y), dst(x, y) are also not > calculated considering the intersection of these rectangles with the > clip bounds. > > Different Solutions & Results > 1. Three solutions are feasible to fix this issue: > a. Solution 1: Convert the input Surface to Sysmem image, > followed by regular Blit. To optimize this further, the conversion can > be taken up only for Shape clips. > b. Solution 2: Using existing classes in D3DBlitLoops, execute > SwToSurface (copy dest to accel Surface), SurfaceToSurface (supports > clip), SurfaceToSw (full copy) in order. > c. Solution 3: Modify the native side interfaces to accept clip > and execute Solution2 's logic in native code. > 2. Upon various experiments, Solution 1 has been found to be faster than > the rest. > a. This can be attributed to fewer draw /or copy iterations > compared to the other two solutions. > b. In addition to the above fact, the code retains the same > approach as used by the OGL pipeline making it easier to understand. > > Webrev Link: http://cr.openjdk.java.net/~psadhukhan/prahlad/webrev.00/ > Sufficient comments have been added so that developers could easily get > understanding of the issue and solution checked in. > > Thank you > Have a great day > > Prahalad N. > > > > Subject: Re: [OpenJDK 2D-Dev] Review Request: (JDK-8044788) [D3D] clip > is ignored during surface->sw blit > Date: Wed, 15 Apr 2015 16:17:37 +0300 > From: Sergey Bylokhov > To: prasanta sadhukhan , > 2d-dev at openjdk.java.net > > > > Hi, Prasanta. > The same approach was used in OGL pipeline for the reason. Because we > use glReadPixels and there is no way to apply the clip. So we read > pixels to the temporary buffer and apply the clip later. Can you > additionaly investigate is it possible to apply the clip in d3d directly > or not? > > Note that this [1] comment is not correct in d3d, because d3d have only > one direct blit D3d surface -> SW which is D3DSurfaceToSwBlit(IntArgb, > ST_INT_ARGB), all other blits will be done via temporary buffer in > D3DGeneralBlit. > > [1] >> 523 // We can convert argb_pre data from D3d surface in two >> places: >> 524 // - During D3d surface -> SW blit >> 525 // - During SW -> SW blit >> 526 // The first one is faster when we use opaque D3d >> surface, because in >> 527 // this case we simply skip conversion and use color >> components as is. >> 528 // Because of this we align intermediate buffer type with >> type of >> 529 // destination not source. > > > On 15.04.15 11:57, prasanta sadhukhan wrote: >> Hi, >> >> I would like a review for a solution of this bug in jdk9. >> The clip was ignored during surface->sw blit in d3d pipeline. The fix >> is to use the clip parameter to calculate the blit coordinates correctly. >> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8044788 >> webrev:http://cr.openjdk.java.net/~psadhukhan/8044788/webrev.00/ >> >> Regards >> Prasanta > > > -- > Best regards, Sergey. > > > > > > > -- Best regards, Sergey. From alexander.v.stepanov at oracle.com Thu Feb 25 15:17:30 2016 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Thu, 25 Feb 2016 18:17:30 +0300 Subject: [OpenJDK 2D-Dev] RFR 8149558: [TEST] add regression test for JDK-8150154 In-Reply-To: <56BDB583.5020806@oracle.com> References: <56BDB583.5020806@oracle.com> Message-ID: <56CF1B0A.2030603@oracle.com> Sorry, just a reminder. Thanks, Alexander On 2/12/2016 1:35 PM, Alexander Stepanov wrote: > Hello, > > Could you please review the following fix > http://cr.openjdk.java.net/~avstepan/8149558/webrev.00/ > for > https://bugs.openjdk.java.net/browse/JDK-8149558 > > Just a single regression test added (still failing), plus minor > correction for other test. > > Thanks, > Alexander > From Sergey.Bylokhov at oracle.com Fri Feb 26 10:25:31 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 26 Feb 2016 13:25:31 +0300 Subject: [OpenJDK 2D-Dev] Review request for 8069348 SunGraphics2D.copyArea() does not properly work for scaled graphics in D3D In-Reply-To: <56B00896.2090107@oracle.com> References: <564F08B6.7010009@oracle.com> <564F3E8C.3040400@oracle.com> <564F4360.3070609@oracle.com> <5654610C.2090302@oracle.com> <5654D6F0.3090702@oracle.com> <56582B0E.20405@oracle.com> <5658DC90.2010801@oracle.com> <566B2D68.10201@oracle.com> <566F6588.3080909@oracle.com> <5670686A.8040904@oracle.com> <56AA4EE3.5020507@oracle.com> <56B00896.2090107@oracle.com> Message-ID: <56D0281B.2020503@oracle.com> +1 On 02.02.16 4:38, Jim Graham wrote: > Hi Alexandr, > > This looks great. It's good to go, but you might want to fix one > indenting issue before you push: > > X11SD and XRSD both had the same edit, but you made a different decision > on whether to get rid of some extra parentheses or not and XRSD was left > with the indentation off by 1. It would probably make sense to get rid > of the extra parens in X11SD and then make sure the resulting > indentation is correct in both. But, that won't affect the correctness > of the fix. > > I don't feel the need to do a review for these indentation changes if > you make them... > > ...jim > > On 1/28/16 9:24 AM, Alexandr Scherbatiy wrote: >> >> Hello, >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8069348/webrev.04/ >> >> - TRANSFORM_TRANSLATESCALE check is restored in the >> OSXOffScreenSurfaceData >> - TRANSFORM_TRANSLATESCALE check is removed from X11SurfaceData and >> GDIWindowSurfaceData >> >> Thanks, >> Alexandr. >> >> On 12/15/2015 11:22 AM, Jim Graham wrote: >>> Also, X11SD and GDISD still reject TRANSLATESCALE. >>> >>> I think it may make sense for OSXOffscreen to return false for >>> TRANSLATESCALE and punt back to the general implementation? But, X11 >>> and GDI should be able to allow that condition... >>> >>> ...jim >>> >>> On 12/14/15 4:57 PM, Jim Graham wrote: >>>> Will OSXOffScreenSurfaceData.copyArea work with a scaled context? It >>>> calls the drawImage on the original sg2d, but it is using transformed >>>> coordinates already. On the other hand, I installed the patch and >>>> built >>>> on my retina MBP and didn't see any errors in SwingSet2 - is that >>>> because I was using a different SurfaceData by default (CGL?)? >>>> >>>> The rest looks fine... >>>> >>>> ...jim >>>> >>>> On 12/11/15 12:09 PM, Alexander Scherbatiy wrote: >>>>> >>>>> Hello, >>>>> >>>>> Could you review the updated fix: >>>>> http://cr.openjdk.java.net/~alexsch/8069348/webrev.03 >>>>> >>>>> On 28/11/15 02:43, Jim Graham wrote: >>>>>> Hi Alexandr, >>>>>> >>>>>> On 11/27/15 2:06 AM, Alexander Scherbatiy wrote: >>>>>>>> OSXOffscreenSD.java (and all *SD.java), line 481 - should we just >>>>>>>> make >>>>>>>> this part of the SD.copyArea contract, that the coordinates are in >>>>>>>> device space and the SD method should not concern itself with the >>>>>>>> SG2D >>>>>>>> transform? >>>>>>> I updated the SurfaceData.copyArea() x,y,width, and height >>>>>>> description. >>>>>> >>>>>> And yet most of the implementations still check the transformState. >>>>>> Why do they do that if they are no longer concerned with transforming >>>>>> the inputs? >>>>> Updated. >>>>> >>>>> XRSurfaceData didn't handled translate scale transform state. I >>>>> removed it and checked that on Linux scaled internal frames are >>>>> properly >>>>> moved and scroll works correctly. >>>>> GDIWindowSurfaceData handles only translate state. For scale state >>>>> support it is necessary also to scale destination coordinates. It is >>>>> also requires some additional testing. I left it unchanged. >>>>>> >>>>>>>> CopyAreaTest.java, line 61 - rounding is not the same operation >>>>>>>> that >>>>>>>> SG2D uses, but it works anyway? >>>>>> >>>>>> The rounding still isn't the same as SG2D. Floor() != ceil(v - 0.5). >>>>>> >>>>>> On second thought, it's probably best not to worry about the exact >>>>>> rounding in the test case, but just test 1 pixel inset from the >>>>>> coordinates that are needed. In other words, check: >>>>>> >>>>>> scale(X + (N+1) * DX) + 1 >>>>>> scale(Y + (N+1) * DY) + 1, >>>>>> scale(W) - 2 >>>>>> scale(H) - 2 >>>>>> >>>>>> and go back to just rounding... >>>>> Updated. >>>>>> >>>>>>>> CopyAreaTest.java, lines 143,144 - why subtract 2DX and 2DY here? >>>>>>>> Ah, >>>>>>>> this may mask the error in line 94 above...? >>>>>> >>>>>> I notice that it used to check the rectangle at X+(N+1)*DX, >>>>>> Y+(N+1)*DY, but now it only checks X+N*DX,Y+N*DY. Why not continue to >>>>>> check the N+1 copy? That should be the location of the destination of >>>>>> the last copy, right? >>>>> I believe my initial assumption was incorrect. >>>>> For example, let's take N = 1. The loops below has only one >>>>> iteration: >>>>> ----------- >>>>> for (int i = 0; i < N; i++) { >>>>> g.copyArea(X + i * DX, Y + i * DY, W, H, DX, DY); >>>>> } >>>>> ----------- >>>>> >>>>> Which is just g.copyArea(X, Y, W, H, DX, DY). So the destination >>>>> rectangle is (X+DX, Y+DY, W, H) >>>>> which corresponds to the N = 1. >>>>> >>>>> I also updated the test to check different scaleX and scaleY. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>>> >>>>>> ...jim >>>>> >> -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri Feb 26 14:40:36 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 26 Feb 2016 17:40:36 +0300 Subject: [OpenJDK 2D-Dev] RFR 8149558: [TEST] add regression test for JDK-8150154 In-Reply-To: <56CF1B0A.2030603@oracle.com> References: <56BDB583.5020806@oracle.com> <56CF1B0A.2030603@oracle.com> Message-ID: <56D063E4.404@oracle.com> Hi, Alexander. Who will responsible to remove @ignore tag? It seems this information should be added to JDK-8150154? On 25.02.16 18:17, Alexander Stepanov wrote: > Sorry, just a reminder. > > Thanks, > Alexander > > On 2/12/2016 1:35 PM, Alexander Stepanov wrote: >> Hello, >> >> Could you please review the following fix >> http://cr.openjdk.java.net/~avstepan/8149558/webrev.00/ >> for >> https://bugs.openjdk.java.net/browse/JDK-8149558 >> >> Just a single regression test added (still failing), plus minor >> correction for other test. >> >> Thanks, >> Alexander >> > -- Best regards, Sergey. From alexander.v.stepanov at oracle.com Fri Feb 26 14:49:32 2016 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Fri, 26 Feb 2016 17:49:32 +0300 Subject: [OpenJDK 2D-Dev] RFR 8149558: [TEST] add regression test for JDK-8150154 In-Reply-To: <56D063E4.404@oracle.com> References: <56BDB583.5020806@oracle.com> <56CF1B0A.2030603@oracle.com> <56D063E4.404@oracle.com> Message-ID: <56D065FC.7090400@oracle.com> Hello, Sergey, Yes, I'll add the "please remove @ignore" comment to the initial JDK-8150154 in case of this test push. Thanks, Alexander On 2/26/2016 5:40 PM, Sergey Bylokhov wrote: > Hi, Alexander. > Who will responsible to remove @ignore tag? It seems this information > should be added to JDK-8150154? > > On 25.02.16 18:17, Alexander Stepanov wrote: >> Sorry, just a reminder. >> >> Thanks, >> Alexander >> >> On 2/12/2016 1:35 PM, Alexander Stepanov wrote: >>> Hello, >>> >>> Could you please review the following fix >>> http://cr.openjdk.java.net/~avstepan/8149558/webrev.00/ >>> for >>> https://bugs.openjdk.java.net/browse/JDK-8149558 >>> >>> Just a single regression test added (still failing), plus minor >>> correction for other test. >>> >>> Thanks, >>> Alexander >>> >> > > From Sergey.Bylokhov at oracle.com Fri Feb 26 15:06:35 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 26 Feb 2016 18:06:35 +0300 Subject: [OpenJDK 2D-Dev] RFR 8149558: [TEST] add regression test for JDK-8150154 In-Reply-To: <56CF1B0A.2030603@oracle.com> References: <56BDB583.5020806@oracle.com> <56CF1B0A.2030603@oracle.com> Message-ID: <56D069FB.4050503@oracle.com> Should we also test bmp and jpg? You tested a different BI formats, but you do not check that the saved information actually relates to the particular image(all of them have a white color and same size). So you will not notice if the Writer will write the same(first) image in all subsequent calls. On 25.02.16 18:17, Alexander Stepanov wrote: > Sorry, just a reminder. > > Thanks, > Alexander > > On 2/12/2016 1:35 PM, Alexander Stepanov wrote: >> Hello, >> >> Could you please review the following fix >> http://cr.openjdk.java.net/~avstepan/8149558/webrev.00/ >> for >> https://bugs.openjdk.java.net/browse/JDK-8149558 >> >> Just a single regression test added (still failing), plus minor >> correction for other test. >> >> Thanks, >> Alexander >> > -- Best regards, Sergey. From alexander.v.stepanov at oracle.com Fri Feb 26 15:54:46 2016 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Fri, 26 Feb 2016 18:54:46 +0300 Subject: [OpenJDK 2D-Dev] RFR 8149558: [TEST] add regression test for JDK-8150154 In-Reply-To: <56D069FB.4050503@oracle.com> References: <56BDB583.5020806@oracle.com> <56CF1B0A.2030603@oracle.com> <56D069FB.4050503@oracle.com> Message-ID: <56D07546.4010906@oracle.com> > Should we also test bmp and jpg? couldn't use writer for these formats "as is" (simply "writer.write(img)") - this causes IOExceptions. JPEGImageWriteParam or BMPImageWriteParam should be used and another signature for write() method. Extended test logic looks quite bulky with all this additions. > but you do not check that the saved information actually relates to the particular image (all of them have a white color and same size) even in this case we have color check failure for pair (TYPE_USHORT_565_RGB, TYPE_USHORT_555_RGB). but yes, probably it is better to use different images for the 1st and 2nd write attempts. Thanks, Alexander On 2/26/2016 6:06 PM, Sergey Bylokhov wrote: > Should we also test bmp and jpg? You tested a different BI formats, > but you do not check that the saved information actually relates to > the particular image(all of them have a white color and same size). So > you will not notice if the Writer will write the same(first) image in > all subsequent calls. > > On 25.02.16 18:17, Alexander Stepanov wrote: >> Sorry, just a reminder. >> >> Thanks, >> Alexander >> >> On 2/12/2016 1:35 PM, Alexander Stepanov wrote: >>> Hello, >>> >>> Could you please review the following fix >>> http://cr.openjdk.java.net/~avstepan/8149558/webrev.00/ >>> for >>> https://bugs.openjdk.java.net/browse/JDK-8149558 >>> >>> Just a single regression test added (still failing), plus minor >>> correction for other test. >>> >>> Thanks, >>> Alexander >>> >> > >