From peter.brunet at oracle.com Fri Jul 1 03:45:57 2016 From: peter.brunet at oracle.com (Pete Brunet) Date: Thu, 30 Jun 2016 22:45:57 -0500 Subject: RfR JDK-8154069, Jaws reads wrong values from comboboxes when no element is selected In-Reply-To: <3a6a289d-7a0a-93eb-3166-85fb4b73651a@oracle.com> References: <4a055ce6-51cc-5ffa-2bf3-51abde104666@oracle.com> <3a6a289d-7a0a-93eb-3166-85fb4b73651a@oracle.com> Message-ID: I ran all Swing JCK and regression tests and found no failures with the fix applied that do not also occur with the fix not applied. On 6/30/16 11:51 AM, Alexander Scherbatiy wrote: > > The fix looks good to me. > > Please, run the regression and JCK tests to be sure that there are no > possible regressions. > > Thanks, > Alexandr. > > On 30/06/16 18:49, Pete Brunet wrote: >> >> On 6/30/16 8:28 AM, Pete Brunet wrote: >>> Please review the following: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154069 >>> Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8154069/webrev.01/ >>> >>> The scenario is resetting a second combo box via setSelectedIndex(-1) >>> when a first combo box changes. With the fix the selection is now >>> cleared. >>> >>> jtreg for my test case and JCK for JComboBox both ran OK. >>> >>> 3 of 9 JPRT build jobs failed (Mac and both Windows). There is nothing >>> about the patch that should cause a build problem on those three >>> platforms so I assume the failures are due to some other unrelated >>> issue. I'll check to see who might know what's going on with the JPRT >>> builds. >> I've been informed the JPRT build fix is known and in review. >>> TiA, Pete > From semyon.sadetsky at oracle.com Fri Jul 1 06:02:39 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 1 Jul 2016 09:02:39 +0300 Subject: [9] Review request for 8160448: Make GTK3 menus appearence similar to native. In-Reply-To: <506c8f3d-5392-06cb-1e0c-6c8c12771744@oracle.com> References: <506c8f3d-5392-06cb-1e0c-6c8c12771744@oracle.com> Message-ID: On 6/30/2016 11:18 PM, Alexandr Scherbatiy wrote: > On 6/28/2016 7:12 PM, Semyon Sadetsky wrote: >> Hello, >> >> Please review fix for JDK9: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8160448 >> >> webrev: http://cr.openjdk.java.net/~ssadetsky/8160448/webrev.00/ >> >> GTK3 lib uses has several specific features in the menu painting that >> differs from GTK2 approach. The solution implements those features to >> follow the native menu appearance. >> > 219 if (value != null && value instanceof Number) { > > it looks like the check to the null can be omitted in this case. ok. Please review the corrected webrev http://cr.openjdk.java.net/~ssadetsky/8160448/webrev.01/ --Semyon > > Thanks, > Alexandr. >> Test would require native code, so noreg-hard label is used. >> >> --Semyon >> > From semyon.sadetsky at oracle.com Fri Jul 1 06:30:55 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 1 Jul 2016 09:30:55 +0300 Subject: [9] Review Request: 8159899 [TEST_BUG] Timeout in tests when OOM should be generated In-Reply-To: References: <458e16b0-0058-565c-0789-753f73dfffba@oracle.com> <09cd1349-be7c-7508-519e-6a5a5dab4934@oracle.com> <4b5b6e6a-2973-4fe0-e30b-9cccd12e0cc4@oracle.com> Message-ID: <054629f2-267f-4270-8ab9-9cdc90446704@oracle.com> On 6/30/2016 4:31 PM, Sergey Bylokhov wrote: > On 30.06.16 13:42, Semyon Sadetsky wrote: >>> Because it was not intentional behavior, such tests should not fill >>> the whole physical memory, especially so much memory. >> Still unclear why "should not fill" when "it should" according to the >> test spec... > > It should fill the java heap, not the whole physical memory. Don't see a contradiction here. If heap is limited to the physical RAM then they are equivalent. > >> At least, please, add a caution comment to the Util.generateOOME() that >> its usage should be accompanied by the -Xmx flag. >> That helps to decrease probability to meet the same problem in the >> future. > > Webrev is updated: > http://cr.openjdk.java.net/~serb/8159899/webrev.01 The caution could be more noticeable. Thank you for adding it, though. I'm ok with the fix. --Semyon > >>> >>>>>>> >>>>>>>> >>>>>>>> This utility method is used in other tests which are not >>>>>>>> covered by >>>>>>>> the >>>>>>>> fix but may fail due to the same reason. >>>>>>> >>>>>>> Which one? >>>>>> bug6795356.java >>>>> >>>>> Covered by the fix. >>>>> >>>>>> TwentyThousandTest.java >>>>> >>>>> already have -mx option. >>>>> >>>>>> WindowsLeak.java >>>>> >>>>> already have -mx option. >>>>> >>>>>> >>>>>> To find them all you can search for Util.generateOOME() usages >>>>> >>>>> good to know. >>>>> >>>>>> >>>>>> --Semyon >>>>>>> >>>>>>>> On 6/27/2016 6:25 PM, Sergey Bylokhov wrote: >>>>>>>>> Hello. >>>>>>>>> Please review the fix for jdk9. >>>>>>>>> >>>>>>>>> Some of our tests fails with timeout when they tries to generate >>>>>>>>> OOM. >>>>>>>>> This occur on the systems which have huge number of memory. >>>>>>>>> >>>>>>>>> In the fix I added "-xm" option to minimize the available >>>>>>>>> amount of >>>>>>>>> memory. >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8159899 >>>>>>>>> Webrev can be found at: >>>>>>>>> http://cr.openjdk.java.net/~serb/8159899/webrev.00 >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From alexandr.scherbatiy at oracle.com Fri Jul 1 20:54:56 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Fri, 1 Jul 2016 23:54:56 +0300 Subject: [9] Review request for 8160448: Make GTK3 menus appearence similar to native. In-Reply-To: References: <506c8f3d-5392-06cb-1e0c-6c8c12771744@oracle.com> Message-ID: <6ac4923d-1c16-5029-9beb-98f471974216@oracle.com> The fix looks good to me. Thanks, Alexandr. On 7/1/2016 9:02 AM, Semyon Sadetsky wrote: > On 6/30/2016 11:18 PM, Alexandr Scherbatiy wrote: > >> On 6/28/2016 7:12 PM, Semyon Sadetsky wrote: >>> Hello, >>> >>> Please review fix for JDK9: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8160448 >>> >>> webrev: http://cr.openjdk.java.net/~ssadetsky/8160448/webrev.00/ >>> >>> GTK3 lib uses has several specific features in the menu painting >>> that differs from GTK2 approach. The solution implements those >>> features to follow the native menu appearance. >>> >> 219 if (value != null && value instanceof Number) { >> >> it looks like the check to the null can be omitted in this case. > ok. Please review the corrected webrev > http://cr.openjdk.java.net/~ssadetsky/8160448/webrev.01/ > > --Semyon >> >> Thanks, >> Alexandr. >>> Test would require native code, so noreg-hard label is used. >>> >>> --Semyon >>> >> > From alexandr.scherbatiy at oracle.com Fri Jul 1 20:59:40 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Fri, 1 Jul 2016 23:59:40 +0300 Subject: [9] Review Request: 8159899 [TEST_BUG] Timeout in tests when OOM should be generated In-Reply-To: References: <458e16b0-0058-565c-0789-753f73dfffba@oracle.com> <09cd1349-be7c-7508-519e-6a5a5dab4934@oracle.com> <4b5b6e6a-2973-4fe0-e30b-9cccd12e0cc4@oracle.com> Message-ID: <95728198-09b7-eb35-ad09-d8ac1976e465@oracle.com> The fix looks good to me. Thanks, Alexandr. On 6/30/2016 4:31 PM, Sergey Bylokhov wrote: > On 30.06.16 13:42, Semyon Sadetsky wrote: >>> Because it was not intentional behavior, such tests should not fill >>> the whole physical memory, especially so much memory. >> Still unclear why "should not fill" when "it should" according to the >> test spec... > > It should fill the java heap, not the whole physical memory. > >> At least, please, add a caution comment to the Util.generateOOME() that >> its usage should be accompanied by the -Xmx flag. >> That helps to decrease probability to meet the same problem in the >> future. > > Webrev is updated: > http://cr.openjdk.java.net/~serb/8159899/webrev.01 > >>> >>>>>>> >>>>>>>> >>>>>>>> This utility method is used in other tests which are not >>>>>>>> covered by >>>>>>>> the >>>>>>>> fix but may fail due to the same reason. >>>>>>> >>>>>>> Which one? >>>>>> bug6795356.java >>>>> >>>>> Covered by the fix. >>>>> >>>>>> TwentyThousandTest.java >>>>> >>>>> already have -mx option. >>>>> >>>>>> WindowsLeak.java >>>>> >>>>> already have -mx option. >>>>> >>>>>> >>>>>> To find them all you can search for Util.generateOOME() usages >>>>> >>>>> good to know. >>>>> >>>>>> >>>>>> --Semyon >>>>>>> >>>>>>>> On 6/27/2016 6:25 PM, Sergey Bylokhov wrote: >>>>>>>>> Hello. >>>>>>>>> Please review the fix for jdk9. >>>>>>>>> >>>>>>>>> Some of our tests fails with timeout when they tries to generate >>>>>>>>> OOM. >>>>>>>>> This occur on the systems which have huge number of memory. >>>>>>>>> >>>>>>>>> In the fix I added "-xm" option to minimize the available >>>>>>>>> amount of >>>>>>>>> memory. >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8159899 >>>>>>>>> Webrev can be found at: >>>>>>>>> http://cr.openjdk.java.net/~serb/8159899/webrev.00 >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From peter.brunet at oracle.com Fri Jul 1 21:24:24 2016 From: peter.brunet at oracle.com (Pete Brunet) Date: Fri, 1 Jul 2016 16:24:24 -0500 Subject: RfR JDK-8154069, Jaws reads wrong values from comboboxes when no element is selected In-Reply-To: References: <4a055ce6-51cc-5ffa-2bf3-51abde104666@oracle.com> <3a6a289d-7a0a-93eb-3166-85fb4b73651a@oracle.com> Message-ID: <12d0a1b4-a6c2-5179-112a-4c4d675b20bb@oracle.com> JPRT results: Build Stats: 9 pass, 0 fail On 6/30/16 10:45 PM, Pete Brunet wrote: > I ran all Swing JCK and regression tests and found no failures with the > fix applied that do not also occur with the fix not applied. > > On 6/30/16 11:51 AM, Alexander Scherbatiy wrote: >> The fix looks good to me. >> >> Please, run the regression and JCK tests to be sure that there are no >> possible regressions. >> >> Thanks, >> Alexandr. >> >> On 30/06/16 18:49, Pete Brunet wrote: >>> On 6/30/16 8:28 AM, Pete Brunet wrote: >>>> Please review the following: >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154069 >>>> Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8154069/webrev.01/ >>>> >>>> The scenario is resetting a second combo box via setSelectedIndex(-1) >>>> when a first combo box changes. With the fix the selection is now >>>> cleared. >>>> >>>> jtreg for my test case and JCK for JComboBox both ran OK. >>>> >>>> 3 of 9 JPRT build jobs failed (Mac and both Windows). There is nothing >>>> about the patch that should cause a build problem on those three >>>> platforms so I assume the failures are due to some other unrelated >>>> issue. I'll check to see who might know what's going on with the JPRT >>>> builds. >>> I've been informed the JPRT build fix is known and in review. >>>> TiA, Pete From alexandr.scherbatiy at oracle.com Mon Jul 4 09:14:27 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Mon, 4 Jul 2016 12:14:27 +0300 Subject: RfR JDK-8145207 [macosx] JList, VO can't access non-visible list items In-Reply-To: <359e3e73-72be-178e-f08a-6f5e81e4943d@oracle.com> References: <359e3e73-72be-178e-f08a-6f5e81e4943d@oracle.com> Message-ID: On 6/18/2016 5:31 AM, Pete Brunet wrote: > Please review the following patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8145207 > Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8145207/webrev.00/ > > This fixes the following functionality that was not working with the > JList of ListDemo of SwingSet2. > - start VoiceOver > - start SwingSet2 > - start the ListDemo > - press Tab until focus is on the list, should hear VO when changing > selections with up/down arrow > - when interacting with list should hear that there are 30 (total) > items, not 26 (visible) items > - when using control+option+up/downarrow should be able to move to and > select (control+option+spacebar) non-visible items past the 26th visible > item > - should be able to multi-select both visible and invisible items using > control+option+command+return and VO should read the item just added > - should be able to shift extend items with shift up or shift down arrow > and VO should announce the item just added or removed CAccessibility: 639 childrenAndRoles.clear(); 640 childrenAndRoles.addAll(newArray); - Is it possible just to assign the newArray to the childrenAndRoles? Is it necessary that the childrenAndRoles has final keyword? - Please, format the code on lines 630-631 to romevo unnessary spaces in round brackets. CAccessible: - static method getActiveDescendant() is not used in the CAccessible class but only in CAccessibility. Is it possible to move it to the CAccessibility class? - Please, split the long lines. You may use static imports for constants. JavaComponentAccessibility: 716 if (returnValue == -1) { 717 return NSNotFound; 718 } else { 719 return returnValue; 720 } - This can be written shorter: return (returnValue == -1) ? NSNotFound : returnValue; 998 if ([self isSelectable:[ThreadUtilities getJNIEnv]]) { 999 return YES; 1000 } else { 1001 return NO; 1002 } - Is there a macros which can convert jboolean to BOOL? - Could you also split the modified lines where it is possible? Thanks, Alexandr. > > Pete > > From rajeev.chamyal at oracle.com Mon Jul 4 12:09:48 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Mon, 4 Jul 2016 12:09:48 +0000 (UTC) Subject: Review Request JDK-8159168 [hidpi] Window.setShape() works incorrectly on HiDPI Message-ID: <4df2cfca-d6d2-4dcf-b986-713d76f017a4@default> Hello All, Please review the following webrev. Bug: https://bugs.openjdk.java.net/browse/JDK-8159168 Webrev: http://cr.openjdk.java.net/~rchamyal/8159168/webrev.00/ Issue: In HiDPI screen shape set through window::setShape API is not scaled based on system scale. Fix:. Updated the WComponentPeer::applyShape to update shape based on system scale. Regards, Rajeev Chamyal -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Mon Jul 4 12:32:41 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Mon, 4 Jul 2016 15:32:41 +0300 Subject: Review Request JDK-8159168 [hidpi] Window.setShape() works incorrectly on HiDPI In-Reply-To: <4df2cfca-d6d2-4dcf-b986-713d76f017a4@default> References: <4df2cfca-d6d2-4dcf-b986-713d76f017a4@default> Message-ID: <7016c0cd-9ad3-4ffb-b4cb-be109a7a50b5@oracle.com> On 7/4/2016 3:09 PM, Rajeev Chamyal wrote: > > Hello All, > > Please review the following webrev. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8159168 > > Webrev: http://cr.openjdk.java.net/~rchamyal/8159168/webrev.00/ > > > Issue: In HiDPI screen shape set through window::setShape API is not > scaled based on system scale. > > Fix:. Updated the WComponentPeer::applyShape to update shape based on > system scale. > 1131 double scaleX = winGraphicsConfig.getDefaultTransform().getScaleX(); 1132 double scaleY = winGraphicsConfig.getDefaultTransform().getScaleY(); The getDefaultTransform() is called twice which leads that AffineTransform object is created two times 1133 if (scaleX != 1 && scaleY != 1 && scaleX == scaleY) { Is the check scaleX == scaleY really necessary here? Is it possible to make the test automated? Just run it with option "@run main/othervm -Dsun.java2d.uiScale=2 TestName" and check the area where the shape is drawn? Thanks, Alexandr. > > Regards, > > Rajeev Chamyal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajeev.chamyal at oracle.com Tue Jul 5 05:25:52 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Tue, 5 Jul 2016 05:25:52 +0000 (UTC) Subject: Review Request JDK-8159168 [hidpi] Window.setShape() works incorrectly on HiDPI In-Reply-To: <7016c0cd-9ad3-4ffb-b4cb-be109a7a50b5@oracle.com> References: <4df2cfca-d6d2-4dcf-b986-713d76f017a4@default> <7016c0cd-9ad3-4ffb-b4cb-be109a7a50b5@oracle.com> Message-ID: <2344f943-cbca-4df2-bec4-30c0fe766388@default> Hello Alexandr, Thanks for the review. As per windows specification X & Y scale are always equal that's why I have put scaleX == scaleY check. But it may change in future so I have removed this check. http://cr.openjdk.java.net/~rchamyal/8159168/webrev.01/ Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 04 July 2016 18:03 To: Rajeev Chamyal; swing-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request JDK-8159168 [hidpi] Window.setShape() works incorrectly on HiDPI On 7/4/2016 3:09 PM, Rajeev Chamyal wrote: Hello All, Please review the following webrev. Bug: https://bugs.openjdk.java.net/browse/JDK-8159168 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8159168/webrev.00/"http://cr.openjdk.java.net/~rchamyal/8159168/webrev.00/ Issue: In HiDPI screen shape set through window::setShape API is not scaled based on system scale. Fix:. Updated the WComponentPeer::applyShape to update shape based on system scale. 1131 double scaleX = winGraphicsConfig.getDefaultTransform().getScaleX(); 1132 double scaleY = winGraphicsConfig.getDefaultTransform().getScaleY(); The getDefaultTransform() is called twice which leads that AffineTransform object is created two times 1133 if (scaleX != 1 && scaleY != 1 && scaleX == scaleY) { Is the check scaleX == scaleY really necessary here? Is it possible to make the test automated? Just run it with option "@run main/othervm -Dsun.java2d.uiScale=2 TestName" and check the area where the shape is drawn? Thanks, Alexandr. Regards, Rajeev Chamyal -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue Jul 5 06:07:31 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 5 Jul 2016 09:07:31 +0300 Subject: Review Request JDK-8159168 [hidpi] Window.setShape() works incorrectly on HiDPI In-Reply-To: <2344f943-cbca-4df2-bec4-30c0fe766388@default> References: <4df2cfca-d6d2-4dcf-b986-713d76f017a4@default> <7016c0cd-9ad3-4ffb-b4cb-be109a7a50b5@oracle.com> <2344f943-cbca-4df2-bec4-30c0fe766388@default> Message-ID: <6275c579-6947-bd61-c434-65ffa1839902@oracle.com> On 7/5/2016 8:25 AM, Rajeev Chamyal wrote: > > Hello Alexandr, > > Thanks for the review. > > As per windows specification X & Y scale are always equal that?s why I > have put scaleX == scaleY check. > > But it may change in future so I have removed this check. > > http://cr.openjdk.java.net/~rchamyal/8159168/webrev.01/ > > 1135 if (scaleX != 1 && scaleY != 1) { It is better to use 'or' operator because the shape should be scaled when on of the scales is differ from 1. Thanks, Alexandr. > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 04 July 2016 18:03 > *To:* Rajeev Chamyal; swing-dev at openjdk.java.net; Sergey Bylokhov > *Subject:* Re: Review Request JDK-8159168 [hidpi] > Window.setShape() works incorrectly on HiDPI > > On 7/4/2016 3:09 PM, Rajeev Chamyal wrote: > > Hello All, > > Please review the following webrev. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8159168 > > Webrev: http://cr.openjdk.java.net/~rchamyal/8159168/webrev.00/ > > > Issue: In HiDPI screen shape set through window::setShape API is > not scaled based on system scale. > > Fix:. Updated the WComponentPeer::applyShape to update shape based > on system scale. > > 1131 double scaleX = winGraphicsConfig.getDefaultTransform().getScaleX(); > 1132 double scaleY = > winGraphicsConfig.getDefaultTransform().getScaleY(); > > The getDefaultTransform() is called twice which leads that > AffineTransform object is created two times > 1133 if (scaleX != 1 && scaleY != 1 && scaleX == scaleY) { > > Is the check scaleX == scaleY really necessary here? > > Is it possible to make the test automated? Just run it with option > "@run main/othervm -Dsun.java2d.uiScale=2 TestName" and check the area > where the shape is drawn? > > Thanks, > Alexandr. > > Regards, > > Rajeev Chamyal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajeev.chamyal at oracle.com Tue Jul 5 06:16:42 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Mon, 4 Jul 2016 23:16:42 -0700 (PDT) Subject: Review Request JDK-8159168 [hidpi] Window.setShape() works incorrectly on HiDPI In-Reply-To: <6275c579-6947-bd61-c434-65ffa1839902@oracle.com> References: <4df2cfca-d6d2-4dcf-b986-713d76f017a4@default> <7016c0cd-9ad3-4ffb-b4cb-be109a7a50b5@oracle.com> <2344f943-cbca-4df2-bec4-30c0fe766388@default> <6275c579-6947-bd61-c434-65ffa1839902@oracle.com> Message-ID: <177de961-76d1-4fa0-8ca0-1f9445e39b0b@default> Hello Alexandr, Please review updated webrev. http://cr.openjdk.java.net/~rchamyal/8159168/webrev.02/ Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 05 July 2016 11:38 To: Rajeev Chamyal; swing-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request JDK-8159168 [hidpi] Window.setShape() works incorrectly on HiDPI On 7/5/2016 8:25 AM, Rajeev Chamyal wrote: Hello Alexandr, Thanks for the review. As per windows specification X & Y scale are always equal that's why I have put scaleX == scaleY check. But it may change in future so I have removed this check. HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8159168/webrev.01/"http://cr.openjdk.java.net/~rchamyal/8159168/webrev.01/ 1135 if (scaleX != 1 && scaleY != 1) { It is better to use 'or' operator because the shape should be scaled when on of the scales is differ from 1. Thanks, Alexandr. Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 04 July 2016 18:03 To: Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request JDK-8159168 [hidpi] Window.setShape() works incorrectly on HiDPI On 7/4/2016 3:09 PM, Rajeev Chamyal wrote: Hello All, Please review the following webrev. Bug: https://bugs.openjdk.java.net/browse/JDK-8159168 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8159168/webrev.00/"http://cr.openjdk.java.net/~rchamyal/8159168/webrev.00/ Issue: In HiDPI screen shape set through window::setShape API is not scaled based on system scale. Fix:. Updated the WComponentPeer::applyShape to update shape based on system scale. 1131 double scaleX = winGraphicsConfig.getDefaultTransform().getScaleX(); 1132 double scaleY = winGraphicsConfig.getDefaultTransform().getScaleY(); The getDefaultTransform() is called twice which leads that AffineTransform object is created two times 1133 if (scaleX != 1 && scaleY != 1 && scaleX == scaleY) { Is the check scaleX == scaleY really necessary here? Is it possible to make the test automated? Just run it with option "@run main/othervm -Dsun.java2d.uiScale=2 TestName" and check the area where the shape is drawn? Thanks, Alexandr. Regards, Rajeev Chamyal -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue Jul 5 06:42:56 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 5 Jul 2016 09:42:56 +0300 Subject: Review Request JDK-8159168 [hidpi] Window.setShape() works incorrectly on HiDPI In-Reply-To: <177de961-76d1-4fa0-8ca0-1f9445e39b0b@default> References: <4df2cfca-d6d2-4dcf-b986-713d76f017a4@default> <7016c0cd-9ad3-4ffb-b4cb-be109a7a50b5@oracle.com> <2344f943-cbca-4df2-bec4-30c0fe766388@default> <6275c579-6947-bd61-c434-65ffa1839902@oracle.com> <177de961-76d1-4fa0-8ca0-1f9445e39b0b@default> Message-ID: The fix looks good to me. Thanks, Alexandr. On 7/5/2016 9:16 AM, Rajeev Chamyal wrote: > > Hello Alexandr, > > Please review updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8159168/webrev.02/ > > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 05 July 2016 11:38 > *To:* Rajeev Chamyal; swing-dev at openjdk.java.net; Sergey Bylokhov > *Subject:* Re: Review Request JDK-8159168 [hidpi] > Window.setShape() works incorrectly on HiDPI > > On 7/5/2016 8:25 AM, Rajeev Chamyal wrote: > > Hello Alexandr, > > Thanks for the review. > > As per windows specification X & Y scale are always equal that?s > why I have put scaleX == scaleY check. > > But it may change in future so I have removed this check. > > http://cr.openjdk.java.net/~rchamyal/8159168/webrev.01/ > > > > 1135 if (scaleX != 1 && scaleY != 1) { > > It is better to use 'or' operator because the shape should be scaled > when on of the scales is differ from 1. > > Thanks, > Alexandr. > > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 04 July 2016 18:03 > *To:* Rajeev Chamyal; swing-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: Review Request JDK-8159168 [hidpi] > Window.setShape() works incorrectly on HiDPI > > On 7/4/2016 3:09 PM, Rajeev Chamyal wrote: > > > Hello All, > > Please review the following webrev. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8159168 > > Webrev: > http://cr.openjdk.java.net/~rchamyal/8159168/webrev.00/ > > > Issue: In HiDPI screen shape set through window::setShape API > is not scaled based on system scale. > > Fix:. Updated the WComponentPeer::applyShape to update shape > based on system scale. > > 1131 double scaleX = > winGraphicsConfig.getDefaultTransform().getScaleX(); > 1132 double scaleY = > winGraphicsConfig.getDefaultTransform().getScaleY(); > > The getDefaultTransform() is called twice which leads that > AffineTransform object is created two times > 1133 if (scaleX != 1 && scaleY != 1 && scaleX == scaleY) { > > Is the check scaleX == scaleY really necessary here? > > Is it possible to make the test automated? Just run it with > option "@run main/othervm -Dsun.java2d.uiScale=2 TestName" and > check the area where the shape is drawn? > > Thanks, > Alexandr. > > > Regards, > > Rajeev Chamyal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajeev.chamyal at oracle.com Tue Jul 5 07:08:22 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Tue, 5 Jul 2016 07:08:22 +0000 (UTC) Subject: Swing Dev> Review Request JDK-8158205 HiDPI hand cursor broken on Windows Message-ID: <7a94293f-fb5d-4591-abfd-abb605923325@default> Hello All, Please review the following fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8158205 Webrev: http://cr.openjdk.java.net/~rchamyal/8158205/webrev.00/ Issue: Incorrect cursor type is displayed over frame in Hidpi screen. Cause: Windows getCursorPos API is returning scaled screen co-ordinates for mouse as a result the findComponentAt is not able to find the frame below mouse pointer and its returning incorrect cursor type. Fix: Updated awt_Cursor.cpp:: getCursorPos to return scaled down co-ordinates. Regards, Rajeev Chamyal -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue Jul 5 07:59:26 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 5 Jul 2016 10:59:26 +0300 Subject: Swing Dev> Review Request JDK-8158205 HiDPI hand cursor broken on Windows In-Reply-To: <7a94293f-fb5d-4591-abfd-abb605923325@default> References: <7a94293f-fb5d-4591-abfd-abb605923325@default> Message-ID: <2dce7708-cbec-16cd-19ba-1e6a1878e583@oracle.com> On 7/5/2016 10:08 AM, Rajeev Chamyal wrote: > > Hello All, > > Please review the following fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8158205 > > Webrev: http://cr.openjdk.java.net/~rchamyal/8158205/webrev.00/ > > > Issue: Incorrect cursor type is displayed over frame in Hidpi screen. > > Cause: Windows getCursorPos API is returning scaled screen > co-ordinates for mouse > > as a result the findComponentAt is not able to find the frame below > mouse pointer and its returning incorrect cursor type. > > Fix: Updated awt_Cursor.cpp:: getCursorPos to return scaled down > co-ordinates. - The call to JFrame methods should be done on EDT in the test. - It looks like there is no need to use the invokeLater() inside the invokeAndWait() call - In case the test fails the dispose method is never called. Thanks, Alexandr. > Regards, > Rajeev Chamyal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajit.ghaisas at oracle.com Tue Jul 5 11:51:08 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Tue, 5 Jul 2016 04:51:08 -0700 (PDT) Subject: [9] Fix for JDK-6567433 : JComponent.updateUI() may create StackOverflowError Message-ID: <6e84f122-4481-4696-b013-27e8fb291231@default> Hi, Bug : https://bugs.openjdk.java.net/browse/JDK-6567433 Calling updateUI() on JList, JComboBox and JTableHeader can create StackOverflowErrors. For example - JList.updateUI() invokes updateUI() on its Cellrenderer via SwingUtilities.updateComponentTreeUI(). If the cellrenderer is a parent of this JList the method recurses endless causing StackOverflowError. Fix : Added a recursion guard to JComboBox, JList and JTableHeader classes. With this fix, UpdateUI() method in these classes does not result in recursion. Webrev : http://cr.openjdk.java.net/~aghaisas/6567433/webrev.00/ Request you to review. Regards, Ajit -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue Jul 5 12:25:26 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 5 Jul 2016 15:25:26 +0300 Subject: [9] Fix for JDK-6567433 : JComponent.updateUI() may create StackOverflowError In-Reply-To: <6e84f122-4481-4696-b013-27e8fb291231@default> References: <6e84f122-4481-4696-b013-27e8fb291231@default> Message-ID: On 7/5/2016 2:51 PM, Ajit Ghaisas wrote: > > Hi, > > Bug : > > https://bugs.openjdk.java.net/browse/JDK-6567433 > > Calling updateUI() on JList, JComboBox and JTableHeader can create > StackOverflowErrors. > For example - > > JList.updateUI() invokes updateUI() on its Cellrenderer via > SwingUtilities.updateComponentTreeUI(). > If the cellrenderer is a parent of this JList the method recurses > endless causing StackOverflowError. > > Fix : > > Added a recursion guard to JComboBox, JList and JTableHeader classes. > > With this fix, UpdateUI() method in these classes does not result > in recursion. > > Webrev : > > http://cr.openjdk.java.net/~aghaisas/6567433/webrev.00/ > > Could the same issue affect another Swing components which allow to set a cell renderer, like JTree? Thanks, Alexandr. > > Request you to review. > > Regards, > > Ajit > -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Wed Jul 6 13:13:08 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 6 Jul 2016 16:13:08 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled Message-ID: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8058742 webrev: http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.00/ After adding hdpi support to JDK the GTK LnF fonts are scaled twice using the JDK UI scale factor and the native scale factor derived from the screen dpi setting. The fix removes the native scale if it is already taken into account in the JDK UI scale. --Semyon From alexandr.scherbatiy at oracle.com Wed Jul 6 15:03:10 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Wed, 6 Jul 2016 18:03:10 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> Message-ID: <435db7a0-9ae3-0b81-ca94-5c9258d789af@oracle.com> On 7/6/2016 4:13 PM, Semyon Sadetsky wrote: > Hello, > > Please review fix for JDK9: > > bug: https://bugs.openjdk.java.net/browse/JDK-8058742 > > webrev: http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.00/ - PangoFonts class is placed in the shared space and it uses the X11GraphicsDevice from the unix space. Could there be problems with build compilation on platforms differ from Unix? - It is better to rename the scale field to nativeScale just to not mix it with other scale types - Does the test test/java/awt/font/FontScaling/FontScalingTest.java fails without the proposed fix on Linux? Thanks, Alexandr. > > After adding hdpi support to JDK the GTK LnF fonts are scaled twice > using the JDK UI scale factor and the native scale factor derived from > the screen dpi setting. The fix removes the native scale if it is > already taken into account in the JDK UI scale. > > --Semyon > From alexandr.scherbatiy at oracle.com Wed Jul 6 15:40:39 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Wed, 6 Jul 2016 18:40:39 +0300 Subject: [9] Review request for 8156217 Selected text is shifted on HiDPI display In-Reply-To: <73ea24e4-331e-a5b5-3609-28e5ddc6f5b0@oracle.com> References: <574DE8A6.4090908@oracle.com> <5c690460-1915-9362-fbb7-d78f2670c3b9@oracle.com> <7823974c-523d-afea-c6db-4b5e9a6c33cb@oracle.com> <0798A861-8586-4DAA-92E5-08F540B7499F@cbfiddle.com> <73ea24e4-331e-a5b5-3609-28e5ddc6f5b0@oracle.com> Message-ID: <95bf7a70-6cc8-373f-f5d4-7441174a189c@oracle.com> Could you review the fix: http://cr.openjdk.java.net/~alexsch/8156217/webrev.03 This is the same fix, just applied to the latest repository sources where the fix 8132119 "Provide public API for text related methods in SwingUtilities2" has been pushed. - public isUseFloatingPointAPI()/setUseFloatingPointAPI() methods are added to the PlainView and WrappedPlainView classes - some @implSpec descriptions are removed from the new text drawing methods with floating point arguments - Built-in L&Fs are updated to use floating point API in standard Java text components Thanks, Alexandr. On 6/30/2016 6:50 PM, Alexandr Scherbatiy wrote: > On 6/28/2016 8:14 PM, Alan Snyder wrote: >> Suppose an application is only partially fixed to use/override the >> floating point methods. Perhaps it uses a library that has not been >> fixed. >> >> Is there a more fine grained way to detect programmer awareness or >> lack of awareness of the new methods? > > Here is a slightly updated version which adds public > isUseFloatingPointAPI()/setUseFloatingPointAPI() methods to the > PlainView and WrappedPlainView classes: > http://cr.openjdk.java.net/~alexsch/8156217/webrev.02 > > Using the floating point API is disabled by default and enabled for > standard Swing text component classes. This has advantage that > selection will work for text component in users applications on HiDPI > display. > > But it still has the same problem. Applications which use custom > View classes needs to updated them to implement corresponding text > drawing methods with floating point arguments and enable the floating > point API usage. > > Thanks, > Alexandr. > >> >> Alan >> >> >>> On Jun 28, 2016, at 9:59 AM, Alexandr Scherbatiy >>> >> > wrote: >>> >>> >>> Hello, >>> >>> I tried to merge this fix with the 8132119 Provide public API for >>> text related methods in SwingUtilities2 >>> and found a flow in the used algorithm. >>> >>> For each method that uses integer coordinates the fix adds a pair >>> with floating point arguments. >>> The fix 8156217 uses only methods with floating point values to >>> correctly handle a selected text. >>> This leads that overridden method with integer arguments in user >>> code is not called anymore. >>> >>> I think that this can be handled in the following way: >>> - Add a property that enables to use methods with floating point >>> arguments in Swing. >>> By default it is false and all work as before. The issue with >>> selected text is reproduced. >>> An application with enabled property does not have issue with the >>> selected text but a user should override >>> all methods with floating point values if he uses corresponding >>> methods with integer values. >>> >>> Here is a proposed solution where new public system property >>> "javax.swing.floatingPoints.enabled" is added: >>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.01 >>> >>> - Fix the enhancement JDK-8157461 Glyph image rendering for HiDPI >>> displays >>> >>> Thanks, >>> Alexandr. >>> >>> On 6/16/2016 6:07 PM, Alexandr Scherbatiy wrote: >>>> On 6/16/2016 4:47 PM, Alexandr Scherbatiy wrote: >>>>> >>>>> I tried to look deeper in the code and it seems there is a >>>>> rounding issue when float values are summed up. >>>>> >>>>> Suppose a transform with scale 1.5 is used and the 'a' char >>>>> advance is 10 in a dev space. >>>>> The 'a' char has advance 10 / 1.5 = 6.666666666666667 as double >>>>> value and 6.6666665 when it is cast to float in user space. >>>>> The width of a string which consists of 15 'a' chars is 15 * >>>>> 6.6666665 = 100.000000. >>>>> But the same width calculated as sum of each glyph advance in >>>>> StandardGlyphVector.initPositions() method is 99.999992. >>>>> -------------- >>>>> double scale = 1.5; >>>>> float advance = (float) (10 / scale); >>>>> int N = 15; >>>>> System.out.printf("%d * %f = %f\n", N, advance, N * advance); >>>>> float sum = 0; >>>>> for (int i = 0; i < N; i++) { >>>>> sum += advance; >>>>> } >>>>> System.out.printf("sum: %f\n", sum); >>>>> -------------- >>>>> >>>>> Because of this a string drawn from float position 99.999998 is >>>>> shifted one pixel left which affects the text selection code in Swing: >>>>> ------------------------ >>>>> g.scale(1.5, 1.5); >>>>> String TEXT = "aaaaaaaaaaaaaaaa"; >>>>> Rectangle2D rect = font.getStringBounds(TEXT, 0, index, >>>>> g.getFontMetrics().getFontRenderContext()); >>>>> float selectedTextPosition = (float) rect.getWidth(); >>>>> // 99.999992 >>>>> g.drawString(TEXT.substring(0, index), x, y); // >>>>> non-selected text >>>>> g.drawString(TEXT.substring(index, TEXT.length()), x + >>>>> selectedTextPosition, y); // selected text is shifted to one pixel >>>>> left >>>>> ------------------------ >>>> The last step is how coordinates are scaled in >>>> Graphics2D.drawString() method. >>>> If the graphics has scale 1.5 and zero translate the transformed >>>> coordinates are: >>>> (99.999992 + 0) * 1.5 = 149.999985 >>>> (100.000000 + 0) * 1.5 = 150.000000 >>>> >>>> Both of them are rounded to the same value. >>>> >>>> If the translate is set to integer 1 value: >>>> (99.999992 + 1) * 1.5 = 151.499989 // shifted to one pixel left >>>> (100.000000 + 1) * 1.5 = 151.500000 >>>> >>>> A position 99.999992 in user space is rounded to 151 in dev space. >>>> A position 100.000000 in user space is rounded to 152 in dev space. >>>> >>>> And this difference can depend on the translate even it has >>>> integer value in user space because it is multiplied on the >>>> graphics scale. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 6/2/2016 11:41 PM, Alexandr Scherbatiy wrote: >>>>>> On 5/31/2016 10:40 PM, Phil Race wrote: >>>>>>> >>>>>>> I applied this and it is *much* better but there still seem to >>>>>>> be some tiny quirks. >>>>>>> When I drag the mouse to select text down and then up again, as >>>>>>> I pass the >>>>>>> original mouse click point vertically, repaint seem to jiggle >>>>>>> vertically by a pixel. >>>>>>> Perhaps a rounding issue in the repaint code's calculation of >>>>>>> the location of >>>>>>> the target y. I think I may see the same in left/right dragging >>>>>>> along a line too. >>>>>>> So I think this is repaint and not text related. Can you take a >>>>>>> look. >>>>>> >>>>>> I am able to reproduce this only using a floating point scale. >>>>>> It looks like 2d issue. I used a test which draws a text in >>>>>> two pieces. The second piece of the text is shifted from the >>>>>> first piece by the floating point size of the the first piece of >>>>>> the text. >>>>>> ----------- >>>>>> Rectangle2D rect = font.getStringBounds(TEXT, 0, index, >>>>>> g.getFontMetrics().getFontRenderContext()); >>>>>> float selectedTextPosition = (float) rect.getWidth(); >>>>>> g.drawString(TEXT.substring(0, index), x, y); >>>>>> g.drawString(TEXT.substring(index, TEXT.length()), x + >>>>>> selectedTextPosition, y); >>>>>> ----------- >>>>>> >>>>>> The second piece of the text can be shifted in the 2 cases: >>>>>> a) graphics scale is 1.5 and translation is 1. >>>>>> b) graphics scale is 2.25 without applied translation >>>>>> >>>>>> I have filed an issue on it: >>>>>> JDK-8158370 Text drawn from float pointing position and with >>>>>> float pointing scale is shifted >>>>>> https://bugs.openjdk.java.net/browse/JDK-8158370 >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> >>>>>>> On 05/06/2016 12:31 PM, Alexandr Scherbatiy wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Could you review the fix: >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8156217 >>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8156217/webrev.00 >>>>>>>> >>>>>>>> This is the second part of the fix related to the fact that >>>>>>>> char width can be fractional in user space. >>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-May/005814.html >>>>>>>> >>>>>>>> >>>>>>>> The Font.getStringBounds(...) method is used for the >>>>>>>> fractional string width calculation by Swing in user space. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Wed Jul 6 19:03:25 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 6 Jul 2016 22:03:25 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: <435db7a0-9ae3-0b81-ca94-5c9258d789af@oracle.com> References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> <435db7a0-9ae3-0b81-ca94-5c9258d789af@oracle.com> Message-ID: <8984a4ae-38e6-2cbb-878a-b29f2394828c@oracle.com> On 7/6/2016 6:03 PM, Alexandr Scherbatiy wrote: > On 7/6/2016 4:13 PM, Semyon Sadetsky wrote: >> Hello, >> >> Please review fix for JDK9: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8058742 >> >> webrev: http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.00/ > > - PangoFonts class is placed in the shared space and it uses the > X11GraphicsDevice from the unix space. Could there be problems with > build compilation on platforms differ from Unix? no it doesn't cause compilations problems. PangoFonts is used on Linux platform only. > - It is better to rename the scale field to nativeScale just to not > mix it with other scale types ok. webrev is updated: http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.01/ > - Does the test test/java/awt/font/FontScaling/FontScalingTest.java > fails without the proposed fix on Linux? Yes it fails before and passes after the fix. --Semyon > > Thanks, > Alexandr. > >> >> After adding hdpi support to JDK the GTK LnF fonts are scaled twice >> using the JDK UI scale factor and the native scale factor derived >> from the screen dpi setting. The fix removes the native scale if it >> is already taken into account in the JDK UI scale. >> >> --Semyon >> > From alexandr.scherbatiy at oracle.com Thu Jul 7 07:01:27 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 7 Jul 2016 10:01:27 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: <8984a4ae-38e6-2cbb-878a-b29f2394828c@oracle.com> References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> <435db7a0-9ae3-0b81-ca94-5c9258d789af@oracle.com> <8984a4ae-38e6-2cbb-878a-b29f2394828c@oracle.com> Message-ID: <8327e9bc-19f6-8ea0-a5a1-05292921638f@oracle.com> The fix looks good to me. Thanks, Alexandr. On 7/6/2016 10:03 PM, Semyon Sadetsky wrote: > On 7/6/2016 6:03 PM, Alexandr Scherbatiy wrote: > >> On 7/6/2016 4:13 PM, Semyon Sadetsky wrote: >>> Hello, >>> >>> Please review fix for JDK9: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8058742 >>> >>> webrev: http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.00/ >> >> - PangoFonts class is placed in the shared space and it uses the >> X11GraphicsDevice from the unix space. Could there be problems with >> build compilation on platforms differ from Unix? > no it doesn't cause compilations problems. PangoFonts is used on Linux > platform only. >> - It is better to rename the scale field to nativeScale just to not >> mix it with other scale types > ok. webrev is updated: > http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.01/ >> - Does the test >> test/java/awt/font/FontScaling/FontScalingTest.java fails without >> the proposed fix on Linux? > Yes it fails before and passes after the fix. > > --Semyon >> >> Thanks, >> Alexandr. >> >>> >>> After adding hdpi support to JDK the GTK LnF fonts are scaled twice >>> using the JDK UI scale factor and the native scale factor derived >>> from the screen dpi setting. The fix removes the native scale if it >>> is already taken into account in the JDK UI scale. >>> >>> --Semyon >>> >> > From alexandr.scherbatiy at oracle.com Thu Jul 7 09:33:43 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 7 Jul 2016 12:33:43 +0300 Subject: [9] Review request for 8160879 [PIT] CloseOnMouseClickPropertyTest fails with AA hint:Nonantialiased rendering mode exception Message-ID: <2f350663-af0d-9454-bc5d-b25a0d3901a3@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8160879 webrev: http://cr.openjdk.java.net/~alexsch/8160879/webrev.00 VALUE_TEXT_ANTIALIAS_OFF should be used for the null antialiased hint instead of VALUE_ANTIALIAS_OFF. Thanks, Alexandr. From ajit.ghaisas at oracle.com Thu Jul 7 09:44:10 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Thu, 7 Jul 2016 09:44:10 +0000 (UTC) Subject: [9] Fix for JDK-6567433 : JComponent.updateUI() may create StackOverflowError In-Reply-To: References: <6e84f122-4481-4696-b013-27e8fb291231@default> Message-ID: <9422a635-fa1a-46e5-a115-ca77163aaebe@default> Hi, Thanks Alex for pointing out there might be more components showing similar behavior. Two more components are identified which may cause this recursion in UpdateUI() method - JTree and JTable. Now, total 5 components ( JComboBox, JList, JTree, JTable and JTableHeader) are fixed. Please review the updated webrev : http://cr.openjdk.java.net/~aghaisas/6567433/webrev.01/ Regards, Ajit From: Alexandr Scherbatiy Sent: Tuesday, July 05, 2016 5:55 PM To: Ajit Ghaisas; Rajeev Chamyal; swing-dev at openjdk.java.net Subject: Re: [9] Fix for JDK-6567433 : JComponent.updateUI() may create StackOverflowError On 7/5/2016 2:51 PM, Ajit Ghaisas wrote: Hi, Bug : https://bugs.openjdk.java.net/browse/JDK-6567433 Calling updateUI() on JList, JComboBox and JTableHeader can create StackOverflowErrors. For example - JList.updateUI() invokes updateUI() on its Cellrenderer via SwingUtilities.updateComponentTreeUI(). If the cellrenderer is a parent of this JList the method recurses endless causing StackOverflowError. Fix : Added a recursion guard to JComboBox, JList and JTableHeader classes. With this fix, UpdateUI() method in these classes does not result in recursion. Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Eaghaisas/6567433/webrev.00/"http://cr.openjdk.java.net/~aghaisas/6567433/webrev.00/ Could the same issue affect another Swing components which allow to set a cell renderer, like JTree? Thanks, Alexandr. Request you to review. Regards, Ajit -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Thu Jul 7 09:46:50 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 7 Jul 2016 12:46:50 +0300 Subject: [9] Fix for JDK-6567433 : JComponent.updateUI() may create StackOverflowError In-Reply-To: <9422a635-fa1a-46e5-a115-ca77163aaebe@default> References: <6e84f122-4481-4696-b013-27e8fb291231@default> <9422a635-fa1a-46e5-a115-ca77163aaebe@default> Message-ID: The fix looks good to me. Thanks, Alexandr. On 7/7/2016 12:44 PM, Ajit Ghaisas wrote: > > Hi, > > Thanks Alex for pointing out there might be more components > showing similar behavior. > > Two more components are identified which may cause this recursion > in UpdateUI() method ? JTree and JTable. > > Now, total 5 components ( JComboBox, JList, JTree, JTable and > JTableHeader) are fixed. > > Please review the updated webrev : > > http://cr.openjdk.java.net/~aghaisas/6567433/webrev.01/ > > > Regards, > > Ajit > > *From:*Alexandr Scherbatiy > *Sent:* Tuesday, July 05, 2016 5:55 PM > *To:* Ajit Ghaisas; Rajeev Chamyal; swing-dev at openjdk.java.net > *Subject:* Re: [9] Fix for JDK-6567433 : JComponent.updateUI() may > create StackOverflowError > > On 7/5/2016 2:51 PM, Ajit Ghaisas wrote: > > Hi, > > Bug : > > https://bugs.openjdk.java.net/browse/JDK-6567433 > > Calling updateUI() on JList, JComboBox and JTableHeader can > create StackOverflowErrors. > For example - > > JList.updateUI() invokes updateUI() on its Cellrenderer via > SwingUtilities.updateComponentTreeUI(). > If the cellrenderer is a parent of this JList the method > recurses endless causing StackOverflowError. > > Fix : > > Added a recursion guard to JComboBox, JList and JTableHeader > classes. > > With this fix, UpdateUI() method in these classes does not > result in recursion. > > Webrev : > > http://cr.openjdk.java.net/~aghaisas/6567433/webrev.00/ > > > > Could the same issue affect another Swing components which allow to > set a cell renderer, like JTree? > > Thanks, > Alexandr. > > Request you to review. > > Regards, > > Ajit > -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Thu Jul 7 09:51:08 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 7 Jul 2016 12:51:08 +0300 Subject: [9] Review request for 8160879 [PIT] CloseOnMouseClickPropertyTest fails with AA hint:Nonantialiased rendering mode exception In-Reply-To: <2f350663-af0d-9454-bc5d-b25a0d3901a3@oracle.com> References: <2f350663-af0d-9454-bc5d-b25a0d3901a3@oracle.com> Message-ID: <577E260C.6080702@oracle.com> Looks good to me. --Semyon On 07.07.2016 12:33, Alexandr Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8160879 > webrev: http://cr.openjdk.java.net/~alexsch/8160879/webrev.00 > > VALUE_TEXT_ANTIALIAS_OFF should be used for the null antialiased > hint instead of VALUE_ANTIALIAS_OFF. > > Thanks, > Alexandr. > From rajeev.chamyal at oracle.com Thu Jul 7 10:00:07 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Thu, 7 Jul 2016 10:00:07 +0000 (UTC) Subject: [9] Fix for JDK-6567433 : JComponent.updateUI() may create StackOverflowError In-Reply-To: References: <6e84f122-4481-4696-b013-27e8fb291231@default> <9422a635-fa1a-46e5-a115-ca77163aaebe@default> Message-ID: Hello Ajit, The fix looks fine to me. Regarding test: JTable and JTree tests exceed 80 char limit. Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 07 July 2016 15:17 To: Ajit Ghaisas; Rajeev Chamyal; swing-dev at openjdk.java.net Subject: Re: [9] Fix for JDK-6567433 : JComponent.updateUI() may create StackOverflowError The fix looks good to me. Thanks, Alexandr. On 7/7/2016 12:44 PM, Ajit Ghaisas wrote: Hi, Thanks Alex for pointing out there might be more components showing similar behavior. Two more components are identified which may cause this recursion in UpdateUI() method - JTree and JTable. Now, total 5 components ( JComboBox, JList, JTree, JTable and JTableHeader) are fixed. Please review the updated webrev : HYPERLINK "http://cr.openjdk.java.net/%7Eaghaisas/6567433/webrev.01/"http://cr.openjdk.java.net/~aghaisas/6567433/webrev.01/ Regards, Ajit From: Alexandr Scherbatiy Sent: Tuesday, July 05, 2016 5:55 PM To: Ajit Ghaisas; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [9] Fix for JDK-6567433 : JComponent.updateUI() may create StackOverflowError On 7/5/2016 2:51 PM, Ajit Ghaisas wrote: Hi, Bug : https://bugs.openjdk.java.net/browse/JDK-6567433 Calling updateUI() on JList, JComboBox and JTableHeader can create StackOverflowErrors. For example - JList.updateUI() invokes updateUI() on its Cellrenderer via SwingUtilities.updateComponentTreeUI(). If the cellrenderer is a parent of this JList the method recurses endless causing StackOverflowError. Fix : Added a recursion guard to JComboBox, JList and JTableHeader classes. With this fix, UpdateUI() method in these classes does not result in recursion. Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Eaghaisas/6567433/webrev.00/"http://cr.openjdk.java.net/~aghaisas/6567433/webrev.00/ Could the same issue affect another Swing components which allow to set a cell renderer, like JTree? Thanks, Alexandr. Request you to review. Regards, Ajit -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrej.golovnin at gmail.com Thu Jul 7 10:13:41 2016 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Thu, 7 Jul 2016 12:13:41 +0200 Subject: [9] Fix for JDK-6567433 : JComponent.updateUI() may create StackOverflowError In-Reply-To: References: <6e84f122-4481-4696-b013-27e8fb291231@default> <9422a635-fa1a-46e5-a115-ca77163aaebe@default> Message-ID: Hi Ajit, src/java.desktop/share/classes/javax/swing/JList.java In the line 545 there are unnecessary brackets: 545 if ((renderer instanceof Component)) { It should look like this: 545 if (renderer instanceof Component) { Best regards, Andrej Golovnin From ajit.ghaisas at oracle.com Thu Jul 7 10:57:29 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Thu, 7 Jul 2016 10:57:29 +0000 (UTC) Subject: [9] Fix for JDK-6567433 : JComponent.updateUI() may create StackOverflowError In-Reply-To: References: <6e84f122-4481-4696-b013-27e8fb291231@default> <9422a635-fa1a-46e5-a115-ca77163aaebe@default> Message-ID: Hi, Thanks Rajeev and Andrej for the suggestions. I have incorporated them in following webrev. http://cr.openjdk.java.net/~aghaisas/6567433/webrev.02/ Regards, Ajit From: Rajeev Chamyal Sent: Thursday, July 07, 2016 3:30 PM To: Alexander Scherbatiy; Ajit Ghaisas; swing-dev at openjdk.java.net Subject: RE: [9] Fix for JDK-6567433 : JComponent.updateUI() may create StackOverflowError Hello Ajit, The fix looks fine to me. Regarding test: JTable and JTree tests exceed 80 char limit. Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 07 July 2016 15:17 To: Ajit Ghaisas; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [9] Fix for JDK-6567433 : JComponent.updateUI() may create StackOverflowError The fix looks good to me. Thanks, Alexandr. On 7/7/2016 12:44 PM, Ajit Ghaisas wrote: Hi, Thanks Alex for pointing out there might be more components showing similar behavior. Two more components are identified which may cause this recursion in UpdateUI() method - JTree and JTable. Now, total 5 components ( JComboBox, JList, JTree, JTable and JTableHeader) are fixed. Please review the updated webrev : HYPERLINK "http://cr.openjdk.java.net/%7Eaghaisas/6567433/webrev.01/"http://cr.openjdk.java.net/~aghaisas/6567433/webrev.01/ Regards, Ajit From: Alexandr Scherbatiy Sent: Tuesday, July 05, 2016 5:55 PM To: Ajit Ghaisas; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [9] Fix for JDK-6567433 : JComponent.updateUI() may create StackOverflowError On 7/5/2016 2:51 PM, Ajit Ghaisas wrote: Hi, Bug : https://bugs.openjdk.java.net/browse/JDK-6567433 Calling updateUI() on JList, JComboBox and JTableHeader can create StackOverflowErrors. For example - JList.updateUI() invokes updateUI() on its Cellrenderer via SwingUtilities.updateComponentTreeUI(). If the cellrenderer is a parent of this JList the method recurses endless causing StackOverflowError. Fix : Added a recursion guard to JComboBox, JList and JTableHeader classes. With this fix, UpdateUI() method in these classes does not result in recursion. Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Eaghaisas/6567433/webrev.00/"http://cr.openjdk.java.net/~aghaisas/6567433/webrev.00/ Could the same issue affect another Swing components which allow to set a cell renderer, like JTree? Thanks, Alexandr. Request you to review. Regards, Ajit -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrej.golovnin at gmail.com Thu Jul 7 11:13:36 2016 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Thu, 7 Jul 2016 13:13:36 +0200 Subject: [9] Fix for JDK-6567433 : JComponent.updateUI() may create StackOverflowError In-Reply-To: References: <6e84f122-4481-4696-b013-27e8fb291231@default> <9422a635-fa1a-46e5-a115-ca77163aaebe@default> Message-ID: Hi Ajit, one more thing that I have just noticed: /** * Flag to indicate UI update is in progress */ private boolean updateInProgress; I think the field must be transient. In Swing every component is serializable. When updateInProgress is set to true and you serialize/deserialize the component, then the call of the #updateUI()-method on the deserialized instance would never update the UI of the deserialized component because the flag updateInProgress will never change from true to false. Best regards, Andrej Golovnin From alexander.zvegintsev at oracle.com Thu Jul 7 12:03:35 2016 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 7 Jul 2016 15:03:35 +0300 Subject: CFV: New Swing Group Member: Sergey Bylokhov In-Reply-To: <9b3e49bd-7ec0-d1c4-3454-53bd4713e99d@oracle.com> References: <9b3e49bd-7ec0-d1c4-3454-53bd4713e99d@oracle.com> Message-ID: <577E4517.2030706@oracle.com> Vote: yes -- Thanks, Alexander. On 06/23/2016 09:21 AM, Alexandr Scherbatiy wrote: > > I hereby nominate Sergey Bylokhov (OpenJDK user name: serb) to > Membership in the Swing Group. > > Sergey is active member of Swing group and contributed a lot of fixes > which include Aqua L&F, Retina support on Mac OS X and others (see > Sergey?s list OpenJDK changesets [1]). > Sergey also regularly reviews fixes suggested by other members. > > Votes are due by July 08, 2016. > > Only current Members of the Swing Group [2] are eligible > to vote on this nomination. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Alexandr. > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000&rev=author(serb) > [2] http://openjdk.java.net/census#swing > [3] http://openjdk.java.net/groups/#member-vote From alexander.zvegintsev at oracle.com Thu Jul 7 12:06:57 2016 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 7 Jul 2016 15:06:57 +0300 Subject: [9] Review request for 8160879 [PIT] CloseOnMouseClickPropertyTest fails with AA hint:Nonantialiased rendering mode exception In-Reply-To: <577E260C.6080702@oracle.com> References: <2f350663-af0d-9454-bc5d-b25a0d3901a3@oracle.com> <577E260C.6080702@oracle.com> Message-ID: <577E45E1.8060608@oracle.com> +1 -- Thanks, Alexander. On 07/07/2016 12:51 PM, Semyon Sadetsky wrote: > Looks good to me. > > --Semyon > > On 07.07.2016 12:33, Alexandr Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8160879 >> webrev: http://cr.openjdk.java.net/~alexsch/8160879/webrev.00 >> >> VALUE_TEXT_ANTIALIAS_OFF should be used for the null antialiased >> hint instead of VALUE_ANTIALIAS_OFF. >> >> Thanks, >> Alexandr. >> > From avik.niyogi at oracle.com Thu Jul 7 12:11:21 2016 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Thu, 7 Jul 2016 17:41:21 +0530 Subject: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails Message-ID: <9B81739F-3482-4A16-8A12-735ACB060A6E@oracle.com> Hi All, Kindly review the fix for JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8160438 Webrev: http://cr.openjdk.java.net/~aniyogi/8160438/webrev.00/ Issue: test javax/swing/plaf/nimbus/8057791/bug8057791.java consistently fails on OS X 10.10 Cause: Due to bug in detecting color for Non-generic display settings for Mac hardware, test case failed Fix: Positive and negative scenarios was added to check the colour for the Nimbus LAF foreground and background colours. With Regards, Avik Niyogi -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Thu Jul 7 13:00:41 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 7 Jul 2016 16:00:41 +0300 Subject: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails In-Reply-To: <9B81739F-3482-4A16-8A12-735ACB060A6E@oracle.com> References: <9B81739F-3482-4A16-8A12-735ACB060A6E@oracle.com> Message-ID: <577E5279.1020403@oracle.com> Hi Avik, could you clarify what is "Non-generic display settings"? Is it known bug on OS X? And also please be more specific on "negative scenarios" why they are necessary ? Also could you replace labeled break with "return foundMatch; " --Semyon On 07.07.2016 15:11, Avik Niyogi wrote: > Hi All, > > Kindly review the fix for JDK9. > > *Bug: *https://bugs.openjdk.java.net/browse/JDK-8160438 > > *Webrev: *http://cr.openjdk.java.net/~aniyogi/8160438/webrev.00/ > > > *Issue: *test javax/swing/plaf/nimbus/8057791/bug8057791.java > consistently fails on OS X 10.10 > > *Cause: * Due to bug in detecting color for Non-generic display > settings for Mac hardware, test case failed > > *Fix: *Positive and negative scenarios was added to check the colour > for the Nimbus LAF foreground and background colours. > > With Regards, > Avik Niyogi > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From avik.niyogi at oracle.com Thu Jul 7 13:35:47 2016 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Thu, 7 Jul 2016 19:05:47 +0530 Subject: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails In-Reply-To: <577E5279.1020403@oracle.com> References: <9B81739F-3482-4A16-8A12-735ACB060A6E@oracle.com> <577E5279.1020403@oracle.com> Message-ID: Hi Semyon, Thank you for the review comment. In Mac OS X, System Preferences > Displays > Colors > Display Profile section, the default value is Color LCD. This causes a failure in some test cases which uses robot.The colour configuration it expects to use is the Generic RGB Profile. That is what ?Non-generic display settings? means. Regarding ?Negative scenarios?, these include cases where colours are different from the expected background or foreground colors is checked with the robot and BufferedImage respectively to eliminate false positives due to coincidentally finding a match by using robot or BufferedImage. Please find my changes appropriating the inputs provided. I removed the variable foundMatch as I found that it is not required at all and incorporated the suggestion to use return instead of a labelled break. http://cr.openjdk.java.net/~aniyogi/8160438/webrev.01/ > On 07-Jul-2016, at 6:30 pm, Semyon Sadetsky wrote: > > Hi Avik, > > could you clarify what is "Non-generic display settings"? Is it known bug on OS X? > And also please be more specific on "negative scenarios" why they are necessary ? > > Also could you replace labeled break with "return foundMatch; " > > --Semyon > > > On 07.07.2016 15:11, Avik Niyogi wrote: >> Hi All, >> >> Kindly review the fix for JDK9. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8160438 >> >> Webrev: http://cr.openjdk.java.net/~aniyogi/8160438/webrev.00/ >> >> Issue: test javax/swing/plaf/nimbus/8057791/bug8057791.java consistently fails on OS X 10.10 >> >> Cause: Due to bug in detecting color for Non-generic display settings for Mac hardware, test case failed >> >> Fix: Positive and negative scenarios was added to check the colour for the Nimbus LAF foreground and background colours. >> >> With Regards, >> Avik Niyogi >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Thu Jul 7 14:04:02 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 7 Jul 2016 17:04:02 +0300 Subject: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails In-Reply-To: References: <9B81739F-3482-4A16-8A12-735ACB060A6E@oracle.com> <577E5279.1020403@oracle.com> Message-ID: <577E6152.3000903@oracle.com> On 07.07.2016 16:35, Avik Niyogi wrote: > Hi Semyon, > > Thank you for the review comment. > > In Mac OS X, *System Preferences > Displays > Colors > Display > Profile* section, the default value is *Color LCD*. > This causes a failure in some test cases which uses robot.The colour > configuration it expects to use is the *Generic RGB Profile*. > That is what ?Non-generic display settings? means. AFAIK there are instruction that tests should be executed using color profile with no color corrections on OS X. I guess there are many other tests that fail with color correction. If this is a root cause than the bug doesn't need to be fixed. --Semyon > > Regarding ?Negative scenarios?, these include cases where colours are > different from the expected background or foreground colors > is checked with the robot and BufferedImage respectively to *eliminate > false positives due to coincidentally finding a match* by using robot > or BufferedImage. > > Please find my changes appropriating the inputs provided. > I removed the variable foundMatch as I found that it is not required > at all and incorporated the suggestion to use return instead of a > labelled break. > > http://cr.openjdk.java.net/~aniyogi/8160438/webrev.01/ > > > >> On 07-Jul-2016, at 6:30 pm, Semyon Sadetsky >> > wrote: >> >> Hi Avik, >> >> could you clarify what is "Non-generic display settings"? Is it known >> bug on OS X? >> And also please be more specific on "negative scenarios" why they are >> necessary ? >> >> Also could you replace labeled break with "return foundMatch; " >> >> --Semyon >> >> >> On 07.07.2016 15:11, Avik Niyogi wrote: >>> Hi All, >>> >>> Kindly review the fix for JDK9. >>> >>> *Bug: *https://bugs.openjdk.java.net/browse/JDK-8160438 >>> >>> *Webrev: *http://cr.openjdk.java.net/~aniyogi/8160438/webrev.00/ >>> >>> >>> *Issue: *test javax/swing/plaf/nimbus/8057791/bug8057791.java >>> consistently fails on OS X 10.10 >>> >>> *Cause: * Due to bug in detecting color for Non-generic display >>> settings for Mac hardware, test case failed >>> >>> *Fix: *Positive and negative scenarios was added to check the colour >>> for the Nimbus LAF foreground and background colours. >>> >>> With Regards, >>> Avik Niyogi >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yuri.nesterenko at oracle.com Thu Jul 7 14:35:17 2016 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Thu, 7 Jul 2016 17:35:17 +0300 Subject: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails In-Reply-To: <577E6152.3000903@oracle.com> References: <9B81739F-3482-4A16-8A12-735ACB060A6E@oracle.com> <577E5279.1020403@oracle.com> <577E6152.3000903@oracle.com> Message-ID: <577E68A5.80500@oracle.com> On 07/07/2016 05:04 PM, Semyon Sadetsky wrote: > > > On 07.07.2016 16:35, Avik Niyogi wrote: >> Hi Semyon, >> >> Thank you for the review comment. >> >> In Mac OS X, *System Preferences > Displays > Colors > Display >> Profile* section, the default value is *Color LCD*. >> This causes a failure in some test cases which uses robot.The colour >> configuration it expects to use is the *Generic RGB Profile*. >> That is what ?Non-generic display settings? means. > AFAIK there are instruction that tests should be executed using color > profile with no color corrections on OS X. I guess there are many other > tests that fail with color correction. > If this is a root cause than the bug doesn't need to be fixed. Well, I filed this bug and I used Generic RGB on all my test machines. There may be additional precautions in the tests about that but misconfiguration is not the root case here. That said, I feel vary about attempts to guess Apple colors in non-generic profiles. -yan > > --Semyon >> >> Regarding ?Negative scenarios?, these include cases where colours are >> different from the expected background or foreground colors >> is checked with the robot and BufferedImage respectively to *eliminate >> false positives due to coincidentally finding a match* by using robot >> or BufferedImage. >> >> Please find my changes appropriating the inputs provided. >> I removed the variable foundMatch as I found that it is not required >> at all and incorporated the suggestion to use return instead of a >> labelled break. >> >> http://cr.openjdk.java.net/~aniyogi/8160438/webrev.01/ >> >> >> >>> On 07-Jul-2016, at 6:30 pm, Semyon Sadetsky >>> > wrote: >>> >>> Hi Avik, >>> >>> could you clarify what is "Non-generic display settings"? Is it known >>> bug on OS X? >>> And also please be more specific on "negative scenarios" why they are >>> necessary ? >>> >>> Also could you replace labeled break with "return foundMatch; " >>> >>> --Semyon >>> >>> >>> On 07.07.2016 15:11, Avik Niyogi wrote: >>>> Hi All, >>>> >>>> Kindly review the fix for JDK9. >>>> >>>> *Bug: >>>> *https://bugs.openjdk.java.net/browse/JDK-8160438 >>>> >>>> *Webrev: >>>> *http://cr.openjdk.java.net/~aniyogi/8160438/webrev.00/ >>>> >>>> *Issue: *test javax/swing/plaf/nimbus/8057791/bug8057791.java >>>> consistently fails on OS X 10.10 >>>> >>>> *Cause: * Due to bug in detecting color for Non-generic display >>>> settings for Mac hardware, test case failed >>>> >>>> *Fix: *Positive and negative scenarios was added to check the colour >>>> for the Nimbus LAF foreground and background colours. >>>> >>>> With Regards, >>>> Avik Niyogi >>>> >>>> >>>> >>> >> > From yuri.nesterenko at oracle.com Thu Jul 7 14:58:15 2016 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Thu, 7 Jul 2016 17:58:15 +0300 Subject: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails In-Reply-To: <577E68A5.80500@oracle.com> References: <9B81739F-3482-4A16-8A12-735ACB060A6E@oracle.com> <577E5279.1020403@oracle.com> <577E6152.3000903@oracle.com> <577E68A5.80500@oracle.com> Message-ID: <577E6E07.2010302@oracle.com> On 07/07/2016 05:35 PM, Yuri Nesterenko wrote: > On 07/07/2016 05:04 PM, Semyon Sadetsky wrote: >> >> >> On 07.07.2016 16:35, Avik Niyogi wrote: >>> Hi Semyon, >>> >>> Thank you for the review comment. >>> >>> In Mac OS X, *System Preferences > Displays > Colors > Display >>> Profile* section, the default value is *Color LCD*. >>> This causes a failure in some test cases which uses robot.The colour >>> configuration it expects to use is the *Generic RGB Profile*. >>> That is what ?Non-generic display settings? means. >> AFAIK there are instruction that tests should be executed using color >> profile with no color corrections on OS X. I guess there are many other >> tests that fail with color correction. >> If this is a root cause than the bug doesn't need to be fixed. > > Well, I filed this bug and I used Generic RGB on all my > test machines. There may be additional precautions in the tests > about that but misconfiguration is not the root case here. > That said, I feel vary about attempts to guess Apple colors wary I mean > in non-generic profiles. > > -yan > > >> >> --Semyon >>> >>> Regarding ?Negative scenarios?, these include cases where colours are >>> different from the expected background or foreground colors >>> is checked with the robot and BufferedImage respectively to *eliminate >>> false positives due to coincidentally finding a match* by using robot >>> or BufferedImage. >>> >>> Please find my changes appropriating the inputs provided. >>> I removed the variable foundMatch as I found that it is not required >>> at all and incorporated the suggestion to use return instead of a >>> labelled break. >>> >>> http://cr.openjdk.java.net/~aniyogi/8160438/webrev.01/ >>> >>> >>> >>>> On 07-Jul-2016, at 6:30 pm, Semyon Sadetsky >>>> > wrote: >>>> >>>> Hi Avik, >>>> >>>> could you clarify what is "Non-generic display settings"? Is it known >>>> bug on OS X? >>>> And also please be more specific on "negative scenarios" why they are >>>> necessary ? >>>> >>>> Also could you replace labeled break with "return foundMatch; " >>>> >>>> --Semyon >>>> >>>> >>>> On 07.07.2016 15:11, Avik Niyogi wrote: >>>>> Hi All, >>>>> >>>>> Kindly review the fix for JDK9. >>>>> >>>>> *Bug: >>>>> *https://bugs.openjdk.java.net/browse/JDK-8160438 >>>>> >>>>> >>>>> *Webrev: >>>>> *http://cr.openjdk.java.net/~aniyogi/8160438/webrev.00/ >>>>> >>>>> >>>>> *Issue: *test javax/swing/plaf/nimbus/8057791/bug8057791.java >>>>> consistently fails on OS X 10.10 >>>>> >>>>> *Cause: * Due to bug in detecting color for Non-generic display >>>>> settings for Mac hardware, test case failed >>>>> >>>>> *Fix: *Positive and negative scenarios was added to check the colour >>>>> for the Nimbus LAF foreground and background colours. >>>>> >>>>> With Regards, >>>>> Avik Niyogi >>>>> >>>>> >>>>> >>>> >>> >> > From goetz.lindenmaier at sap.com Thu Jul 7 15:01:15 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 7 Jul 2016 15:01:15 +0000 Subject: RFR(L): 8160974: [TESTBUG] Mark more headful tests with @key headful. Message-ID: <87923b42e8c1478d8b4227e136fe69a5@DEWDFE13DE09.global.corp.sap> Hi, This change is 'L' because there are changes to a lot of files, but the changes are all similar, so it's rather easy to review. Similar to 8159690 I added @key headful to another around 600 tests. I used different patterns to grep for the headful exceptions. These are now all I could find with grepping and the like. I have around 80 failing tests remaining, where a row will probably also depend on a display, but I want to look at them more closely, so I don't want to include them here. Please review this change: http://cr.openjdk.java.net/~goetz/wr16/8160974-headful/webrev.01/ Best regards, Goetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Thu Jul 7 15:15:16 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 7 Jul 2016 18:15:16 +0300 Subject: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails In-Reply-To: <577E6E07.2010302@oracle.com> References: <9B81739F-3482-4A16-8A12-735ACB060A6E@oracle.com> <577E5279.1020403@oracle.com> <577E6152.3000903@oracle.com> <577E68A5.80500@oracle.com> <577E6E07.2010302@oracle.com> Message-ID: On 7/7/2016 5:58 PM, Yuri Nesterenko wrote: > On 07/07/2016 05:35 PM, Yuri Nesterenko wrote: >> On 07/07/2016 05:04 PM, Semyon Sadetsky wrote: >>> >>> >>> On 07.07.2016 16:35, Avik Niyogi wrote: >>>> Hi Semyon, >>>> >>>> Thank you for the review comment. >>>> >>>> In Mac OS X, *System Preferences > Displays > Colors > Display >>>> Profile* section, the default value is *Color LCD*. >>>> This causes a failure in some test cases which uses robot.The colour >>>> configuration it expects to use is the *Generic RGB Profile*. >>>> That is what ?Non-generic display settings? means. >>> AFAIK there are instruction that tests should be executed using color >>> profile with no color corrections on OS X. I guess there are many other >>> tests that fail with color correction. >>> If this is a root cause than the bug doesn't need to be fixed. >> >> Well, I filed this bug and I used Generic RGB on all my >> test machines. There may be additional precautions in the tests >> about that but misconfiguration is not the root case here. >> That said, I feel vary about attempts to guess Apple colors > wary I mean >> in non-generic profiles. Yuri. Do you mean that the non-generic is not a root case? --Semyon >> >> -yan >> >> >>> >>> --Semyon >>>> >>>> Regarding ?Negative scenarios?, these include cases where colours are >>>> different from the expected background or foreground colors >>>> is checked with the robot and BufferedImage respectively to *eliminate >>>> false positives due to coincidentally finding a match* by using robot >>>> or BufferedImage. >>>> >>>> Please find my changes appropriating the inputs provided. >>>> I removed the variable foundMatch as I found that it is not required >>>> at all and incorporated the suggestion to use return instead of a >>>> labelled break. >>>> >>>> http://cr.openjdk.java.net/~aniyogi/8160438/webrev.01/ >>>> >>>> >>>> >>>>> On 07-Jul-2016, at 6:30 pm, Semyon Sadetsky >>>>> > >>>>> wrote: >>>>> >>>>> Hi Avik, >>>>> >>>>> could you clarify what is "Non-generic display settings"? Is it known >>>>> bug on OS X? >>>>> And also please be more specific on "negative scenarios" why they are >>>>> necessary ? >>>>> >>>>> Also could you replace labeled break with "return foundMatch; " >>>>> >>>>> --Semyon >>>>> >>>>> >>>>> On 07.07.2016 15:11, Avik Niyogi wrote: >>>>>> Hi All, >>>>>> >>>>>> Kindly review the fix for JDK9. >>>>>> >>>>>> *Bug: >>>>>> *https://bugs.openjdk.java.net/browse/JDK-8160438 >>>>>> >>>>>> >>>>>> >>>>>> *Webrev: >>>>>> *http://cr.openjdk.java.net/~aniyogi/8160438/webrev.00/ >>>>>> >>>>>> >>>>>> >>>>>> *Issue: *test javax/swing/plaf/nimbus/8057791/bug8057791.java >>>>>> consistently fails on OS X 10.10 >>>>>> >>>>>> *Cause: * Due to bug in detecting color for Non-generic display >>>>>> settings for Mac hardware, test case failed >>>>>> >>>>>> *Fix: *Positive and negative scenarios was added to check the colour >>>>>> for the Nimbus LAF foreground and background colours. >>>>>> >>>>>> With Regards, >>>>>> Avik Niyogi >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > From yuri.nesterenko at oracle.com Thu Jul 7 15:30:36 2016 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Thu, 7 Jul 2016 18:30:36 +0300 Subject: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails In-Reply-To: References: <9B81739F-3482-4A16-8A12-735ACB060A6E@oracle.com> <577E5279.1020403@oracle.com> <577E6152.3000903@oracle.com> <577E68A5.80500@oracle.com> <577E6E07.2010302@oracle.com> Message-ID: <577E759C.6040805@oracle.com> On 07/07/2016 06:15 PM, Semyon Sadetsky wrote: > > > On 7/7/2016 5:58 PM, Yuri Nesterenko wrote: >> On 07/07/2016 05:35 PM, Yuri Nesterenko wrote: >>> On 07/07/2016 05:04 PM, Semyon Sadetsky wrote: >>>> >>>> >>>> On 07.07.2016 16:35, Avik Niyogi wrote: >>>>> Hi Semyon, >>>>> >>>>> Thank you for the review comment. >>>>> >>>>> In Mac OS X, *System Preferences > Displays > Colors > Display >>>>> Profile* section, the default value is *Color LCD*. >>>>> This causes a failure in some test cases which uses robot.The colour >>>>> configuration it expects to use is the *Generic RGB Profile*. >>>>> That is what ?Non-generic display settings? means. >>>> AFAIK there are instruction that tests should be executed using color >>>> profile with no color corrections on OS X. I guess there are many other >>>> tests that fail with color correction. >>>> If this is a root cause than the bug doesn't need to be fixed. >>> >>> Well, I filed this bug and I used Generic RGB on all my >>> test machines. There may be additional precautions in the tests >>> about that but misconfiguration is not the root case here. >>> That said, I feel vary about attempts to guess Apple colors >> wary I mean >>> in non-generic profiles. > Yuri. Do you mean that the non-generic is not a root case? No: I had Generic RGB everywhere, and it failed for me. I should say that the new version of the test properly fails with b120 and pass with current PIT. And colors are visibly different in the two builds: so the test works OK now. -yan > > --Semyon >>> >>> -yan >>> >>> >>>> >>>> --Semyon >>>>> >>>>> Regarding ?Negative scenarios?, these include cases where colours are >>>>> different from the expected background or foreground colors >>>>> is checked with the robot and BufferedImage respectively to *eliminate >>>>> false positives due to coincidentally finding a match* by using robot >>>>> or BufferedImage. >>>>> >>>>> Please find my changes appropriating the inputs provided. >>>>> I removed the variable foundMatch as I found that it is not required >>>>> at all and incorporated the suggestion to use return instead of a >>>>> labelled break. >>>>> >>>>> http://cr.openjdk.java.net/~aniyogi/8160438/webrev.01/ >>>>> >>>>> >>>>> >>>>>> On 07-Jul-2016, at 6:30 pm, Semyon Sadetsky >>>>>> > >>>>>> wrote: >>>>>> >>>>>> Hi Avik, >>>>>> >>>>>> could you clarify what is "Non-generic display settings"? Is it known >>>>>> bug on OS X? >>>>>> And also please be more specific on "negative scenarios" why they are >>>>>> necessary ? >>>>>> >>>>>> Also could you replace labeled break with "return foundMatch; " >>>>>> >>>>>> --Semyon >>>>>> >>>>>> >>>>>> On 07.07.2016 15:11, Avik Niyogi wrote: >>>>>>> Hi All, >>>>>>> >>>>>>> Kindly review the fix for JDK9. >>>>>>> >>>>>>> *Bug: >>>>>>> *https://bugs.openjdk.java.net/browse/JDK-8160438 >>>>>>> >>>>>>> >>>>>>> >>>>>>> *Webrev: >>>>>>> *http://cr.openjdk.java.net/~aniyogi/8160438/webrev.00/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> *Issue: *test javax/swing/plaf/nimbus/8057791/bug8057791.java >>>>>>> consistently fails on OS X 10.10 >>>>>>> >>>>>>> *Cause: * Due to bug in detecting color for Non-generic display >>>>>>> settings for Mac hardware, test case failed >>>>>>> >>>>>>> *Fix: *Positive and negative scenarios was added to check the colour >>>>>>> for the Nimbus LAF foreground and background colours. >>>>>>> >>>>>>> With Regards, >>>>>>> Avik Niyogi >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From semyon.sadetsky at oracle.com Thu Jul 7 16:21:16 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 7 Jul 2016 19:21:16 +0300 Subject: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails In-Reply-To: <577E759C.6040805@oracle.com> References: <9B81739F-3482-4A16-8A12-735ACB060A6E@oracle.com> <577E5279.1020403@oracle.com> <577E6152.3000903@oracle.com> <577E68A5.80500@oracle.com> <577E6E07.2010302@oracle.com> <577E759C.6040805@oracle.com> Message-ID: <158f2094-1ec4-a3a0-17e9-a8038c24eed4@oracle.com> On 7/7/2016 6:30 PM, Yuri Nesterenko wrote: > On 07/07/2016 06:15 PM, Semyon Sadetsky wrote: >> >> >> On 7/7/2016 5:58 PM, Yuri Nesterenko wrote: >>> On 07/07/2016 05:35 PM, Yuri Nesterenko wrote: >>>> On 07/07/2016 05:04 PM, Semyon Sadetsky wrote: >>>>> >>>>> >>>>> On 07.07.2016 16:35, Avik Niyogi wrote: >>>>>> Hi Semyon, >>>>>> >>>>>> Thank you for the review comment. >>>>>> >>>>>> In Mac OS X, *System Preferences > Displays > Colors > Display >>>>>> Profile* section, the default value is *Color LCD*. >>>>>> This causes a failure in some test cases which uses robot.The colour >>>>>> configuration it expects to use is the *Generic RGB Profile*. >>>>>> That is what ?Non-generic display settings? means. >>>>> AFAIK there are instruction that tests should be executed using color >>>>> profile with no color corrections on OS X. I guess there are many >>>>> other >>>>> tests that fail with color correction. >>>>> If this is a root cause than the bug doesn't need to be fixed. >>>> >>>> Well, I filed this bug and I used Generic RGB on all my >>>> test machines. There may be additional precautions in the tests >>>> about that but misconfiguration is not the root case here. >>>> That said, I feel vary about attempts to guess Apple colors >>> wary I mean >>>> in non-generic profiles. >> Yuri. Do you mean that the non-generic is not a root case? > No: I had Generic RGB everywhere, and it failed for me. > I should say that the new version of the test properly > fails with b120 and pass with current PIT. And colors > are visibly different in the two builds: so the test works OK now. That contradicts with the description of the fix. Probably the test does unnecessary care about the non-Generic profiles. 159 if (!foundMatch && isMac()) { 160 //One more chance for Mac due to non-Generic display setting 161 detectedColor = new Color(img.getRGB(x, y), true); 162 if (detectedColor.equals(colorCheck)) { 163 foundMatch = true; 164 break checkLoops; 165 } 166 } Does it mean that the code above, which is necessary to serve non-Generic profiles on OS X, may be removed and the test still passes? --Semyon > > -yan > >> >> --Semyon >>>> >>>> -yan >>>> >>>> >>>>> >>>>> --Semyon >>>>>> >>>>>> Regarding ?Negative scenarios?, these include cases where colours >>>>>> are >>>>>> different from the expected background or foreground colors >>>>>> is checked with the robot and BufferedImage respectively to >>>>>> *eliminate >>>>>> false positives due to coincidentally finding a match* by using >>>>>> robot >>>>>> or BufferedImage. >>>>>> >>>>>> Please find my changes appropriating the inputs provided. >>>>>> I removed the variable foundMatch as I found that it is not required >>>>>> at all and incorporated the suggestion to use return instead of a >>>>>> labelled break. >>>>>> >>>>>> http://cr.openjdk.java.net/~aniyogi/8160438/webrev.01/ >>>>>> >>>>>> >>>>>> >>>>>>> On 07-Jul-2016, at 6:30 pm, Semyon Sadetsky >>>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Hi Avik, >>>>>>> >>>>>>> could you clarify what is "Non-generic display settings"? Is it >>>>>>> known >>>>>>> bug on OS X? >>>>>>> And also please be more specific on "negative scenarios" why >>>>>>> they are >>>>>>> necessary ? >>>>>>> >>>>>>> Also could you replace labeled break with "return foundMatch; " >>>>>>> >>>>>>> --Semyon >>>>>>> >>>>>>> >>>>>>> On 07.07.2016 15:11, Avik Niyogi wrote: >>>>>>>> Hi All, >>>>>>>> >>>>>>>> Kindly review the fix for JDK9. >>>>>>>> >>>>>>>> *Bug: >>>>>>>> *https://bugs.openjdk.java.net/browse/JDK-8160438 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *Webrev: >>>>>>>> *http://cr.openjdk.java.net/~aniyogi/8160438/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *Issue: *test javax/swing/plaf/nimbus/8057791/bug8057791.java >>>>>>>> consistently fails on OS X 10.10 >>>>>>>> >>>>>>>> *Cause: * Due to bug in detecting color for Non-generic display >>>>>>>> settings for Mac hardware, test case failed >>>>>>>> >>>>>>>> *Fix: *Positive and negative scenarios was added to check the >>>>>>>> colour >>>>>>>> for the Nimbus LAF foreground and background colours. >>>>>>>> >>>>>>>> With Regards, >>>>>>>> Avik Niyogi >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From stevensro at gmail.com Thu Jul 7 18:37:41 2016 From: stevensro at gmail.com (Robin Stevens) Date: Thu, 7 Jul 2016 20:37:41 +0200 Subject: [9] Review request for JDK-8158325: [macosx]Memory leak in com.apple.laf.ScreenMenu In-Reply-To: References: <78a245fd-316d-fe7a-7796-efd306827733@oracle.com> <4d715efe-674f-e63c-e186-8e46be1d5c18@oracle.com> <5773B88C.1020307@oracle.com> <9cf61143-c2f8-f6bd-1722-dc91ca8074ce@oracle.com> <5af5baa8-8175-dbf9-7f58-ef644481fc47@oracle.com> Message-ID: Hello, I got approval for the backport to JDK8 from Rob McKenna (see http://mail.openjdk.java.net/pipermail/jdk8u-dev/2016-July/005686.html). The backport can just be applied after reshuffling the patch. Test succeeds after applying the patch. Note that for the reshuffling, you need to add the following line jdk/src/java.desktop/macosx/classes/com/apple/laf : jdk/src/macosx/classes/com/apple/laf to common/bin/unshuffle_list.txt . As I have no commit rights, I am looking for someone willing to do the backport to JDK8. Link to the JDK9 webrev: http://cr.openjdk.java.net/~alexsch/robin.stevens/8158325/webrev.01 Thanks, Robin On Thu, Jun 30, 2016 at 7:18 PM, Alexander Scherbatiy < alexandr.scherbatiy at oracle.com> wrote: > On 30/06/16 20:58, Robin Stevens wrote: > > Thanks for reviewing, and pushing this fix. > > My application which bumped into this memory leak is however still running > on JDK8. > Is this a kind of fix that can still be backported ? If so, do I just need > to send a new webrev to the mailinglist for the JDK8 repository and have it > reviewed ? > > > Try to backport the fix using the unshuffle_patch scrpt [1]. > If no more changes are required just send the request for approval to > the jdk8u-dev at openjdk.java.net alias using the template [2] and example > [3]. > > [1] http://cr.openjdk.java.net/~chegar/docs/portingScript.html > [2] http://openjdk.java.net/projects/jdk8u/approval-template.html > [3] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2016-June/005652.html > > Thanks, > Alexandr. > > > > > On Thu, Jun 30, 2016 at 6:06 PM, Alexander Scherbatiy < > alexandr.scherbatiy at oracle.com> wrote: > >> The fix looks good to me. >> >> Thanks, >> Alexandr. >> >> >> On 30/06/16 11:34, Alexander Zvegintsev wrote: >> >> The fix looks good to me. >> >> On 6/30/16 9:07 AM, Alexandr Scherbatiy wrote: >> >> On 6/29/2016 10:08 PM, Robin Stevens wrote: >> >> Hello, >> >> attached you find an updated webrev which addresses the comments: >> >> - no custom remove implementation, but instead call fItems.clear() after >> calling removeAll() >> - Attached the container listener to the popupmenu >> - Used the key instead of the value to remove items from the hashmap >> - The test is now marked to run only on OS X >> >> The uploaded webrev: >> http://cr.openjdk.java.net/~alexsch/robin.stevens/8158325/webrev.01 >> >> Thanks, >> Alexandr. >> >> >> Robin >> >> On Wed, Jun 29, 2016 at 2:01 PM, Alexander Zvegintsev < >> alexander.zvegintsev at oracle.com> wrote: >> >>> You should create the diff against the repository. This will allow to >>> test your fix without applying a bunch of patches. >>> >>> -- >>> Thanks, >>> Alexander. >>> >>> On 06/29/2016 02:49 PM, Robin Stevens wrote: >>> >>> Hello Alexander, >>> >>> just one last question. I assume I need to send a new webrev . But do I >>> have to create one which contains the diff compared to the current tip of >>> the repository, or do I need to create one which contains the diff compared >>> to my previous patch ? >>> >>> Robin >>> >>> On Wed, Jun 29, 2016 at 12:03 PM, Alexander Zvegintsev < >>> alexander.zvegintsev at oracle.com> wrote: >>> >>>> Hello Robin, >>>> >>>> Actually I missed your review, when I've posted mine. >>>> >>>> I think that we should proceed with your review as it was the first >>>> one. So please disregard my review request. >>>> >>>> On 6/29/16 12:40 PM, Robin Stevens wrote: >>>> >>>> Hello Alexandr, Semyon, >>>> >>>> 2 reviews of this proposed path have happened. >>>> >>>> One from Alexandr Scherbatiy who stated that the fix looked good. >>>> One from Alexander Zvegintsev who had some comments, and immediately >>>> mailed his own review with a modified version of my proposed patch (see >>>> >>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-June/006196.html). >>>> His patch is based on my patch, but implements the comments he had. >>>> >>>> I am not sure what I need to do now. >>>> I can address his comments, but then I would end up with the same patch >>>> as he proposed in >>>> >>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-June/006196.html >>>> . >>>> Please let me know how to proceed with this. >>>> >>>> Thanks, >>>> >>>> Robin >>>> >>>> On Wed, Jun 29, 2016 at 11:16 AM, Alexandr Scherbatiy < >>>> alexandr.scherbatiy at oracle.com> wrote: >>>> >>>>> On 6/29/2016 11:43 AM, Semyon Sadetsky wrote: >>>>> >>>>> It looks like that fix is posted twice for the same issue... >>>>> >>>>> Which one is the correct one? >>>>> >>>>> It should be the first contributed fix. We are just waiting fro the >>>>> response from the fix contributor: >>>>> >>>>> >>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-June/006200.html >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> --Semyon >>>>> >>>>> On 6/23/2016 7:08 PM, Robin Stevens wrote: >>>>> >>>>> Hello all, >>>>> >>>>> attached is a webrev for issue JDK-8158325 Memory leak in >>>>> com.apple.laf.ScreenMenu: removed JMenuItems are still referenced. >>>>> >>>>> Patch contains a test case which reveals the bug, and a fix. >>>>> >>>>> There were a few issues with the ScreenMenu class: >>>>> >>>>> - The ContainerListener was attached to the JMenu and not to the JMenu#getPopupMenu. >>>>> The JMenu itself does not fire any ContainerEvents, but >>>>> >>>>> the popup does. As a result, the cleanup code in ScreenMenu was never >>>>> triggered. The patch fixes this by attaching the ContainerListener to >>>>> the popup menu. >>>>> >>>>> Note that the ScreenMenu class also attaches a ComponentListener to >>>>> the JMenu. I had no idea whether that one must be attached to the >>>>> popup menu as well, so I did not change it. >>>>> >>>>> - The cleanup code was not triggered when removeAll() was called from >>>>> the updateItems method. I fixed this by overriding the remove(int) >>>>> method, and >>>>> >>>>> putting the cleanup code in that method. An alternative here would be >>>>> to not override the remove(int) method, but instead call >>>>> fItems.clear() after calling removeAll() . However, overriding the >>>>> remove(int) method sounded more robust to me. >>>>> >>>>> - The cleanup code was incorrect. It tried to remove an item from >>>>> fItems (a map) by calling remove with the value instead of the key. >>>>> Now the remove is called with the key. Because the cleanup code has >>>>> been moved, this required me to loop over the map as I have no direct >>>>> access to the key in the >>>>> >>>>> remove(int) method >>>>> >>>>> - The test can be run on all platforms, although it was written for an >>>>> OS X specific bug. As it can run on all platforms, I did not disable >>>>> it on non OS X platforms. Let me know if I need to adjust this. >>>>> >>>>> Kind regards, >>>>> >>>>> Robin >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Thu Jul 7 18:55:03 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 7 Jul 2016 21:55:03 +0300 Subject: [9] Review request for 8160986 Bad rendering of Swing UI controls with Metal L&F on HiDPI display Message-ID: Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8160986 webrev: http://cr.openjdk.java.net/~alexsch/8160986/webrev.00 The proposed fix changes icon shapes drawn by lines to ovals and polygons for JRadioButton, JComboBox and JScrollBar components for the Metal L&F. The screenshots [1] give a hint how UI controls look before and after the fix. [1] http://cr.openjdk.java.net/~alexsch/8160986/screenshots Thanks, Alexandr. From philip.race at oracle.com Thu Jul 7 19:00:28 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 07 Jul 2016 12:00:28 -0700 Subject: [9] Review request for 8160986 Bad rendering of Swing UI controls with Metal L&F on HiDPI display In-Reply-To: References: Message-ID: <577EA6CC.7040406@oracle.com> I imagine this was all done to maximise performance. Is there any impact on SwingMark - try D3D both on & off .. The change here : http://cr.openjdk.java.net/~alexsch/8160986/webrev.00/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalScrollButton.java.sdiff.html appears to handle only NORTH/SOUTH (ie up/down) and the screenshot here bears that out .. ie left/right do not look to be any better. http://cr.openjdk.java.net/~alexsch/8160986/screenshots/scrollpane-00.png -phil. On 07/07/2016 11:55 AM, Alexandr Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8160986 > webrev: http://cr.openjdk.java.net/~alexsch/8160986/webrev.00 > > The proposed fix changes icon shapes drawn by lines to ovals and > polygons for JRadioButton, JComboBox and JScrollBar components for the > Metal L&F. > > The screenshots [1] give a hint how UI controls look before and > after the fix. > > [1] http://cr.openjdk.java.net/~alexsch/8160986/screenshots > > Thanks, > Alexandr. > From avik.niyogi at oracle.com Fri Jul 8 01:28:18 2016 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Fri, 8 Jul 2016 06:58:18 +0530 Subject: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails In-Reply-To: <158f2094-1ec4-a3a0-17e9-a8038c24eed4@oracle.com> References: <9B81739F-3482-4A16-8A12-735ACB060A6E@oracle.com> <577E5279.1020403@oracle.com> <577E6152.3000903@oracle.com> <577E68A5.80500@oracle.com> <577E6E07.2010302@oracle.com> <577E759C.6040805@oracle.com> <158f2094-1ec4-a3a0-17e9-a8038c24eed4@oracle.com> Message-ID: <9BC3920C-8311-44BE-B78E-56305112AA78@oracle.com> The test does not pass if mac specific check is not done for backgroundcolor. The check is required to get the same values from BufferedImage as they are the same as found with Digital Color Meter. This test case fixes that. Please provide inputs if this fix will get a +1 or if not any positive inputs to modify the test case will be welcome. With Regards, Avik Niyogi > On 07-Jul-2016, at 9:51 pm, Semyon Sadetsky wrote: > > > > On 7/7/2016 6:30 PM, Yuri Nesterenko wrote: >> On 07/07/2016 06:15 PM, Semyon Sadetsky wrote: >>> >>> >>> On 7/7/2016 5:58 PM, Yuri Nesterenko wrote: >>>> On 07/07/2016 05:35 PM, Yuri Nesterenko wrote: >>>>> On 07/07/2016 05:04 PM, Semyon Sadetsky wrote: >>>>>> >>>>>> >>>>>> On 07.07.2016 16:35, Avik Niyogi wrote: >>>>>>> Hi Semyon, >>>>>>> >>>>>>> Thank you for the review comment. >>>>>>> >>>>>>> In Mac OS X, *System Preferences > Displays > Colors > Display >>>>>>> Profile* section, the default value is *Color LCD*. >>>>>>> This causes a failure in some test cases which uses robot.The colour >>>>>>> configuration it expects to use is the *Generic RGB Profile*. >>>>>>> That is what ?Non-generic display settings? means. >>>>>> AFAIK there are instruction that tests should be executed using color >>>>>> profile with no color corrections on OS X. I guess there are many other >>>>>> tests that fail with color correction. >>>>>> If this is a root cause than the bug doesn't need to be fixed. >>>>> >>>>> Well, I filed this bug and I used Generic RGB on all my >>>>> test machines. There may be additional precautions in the tests >>>>> about that but misconfiguration is not the root case here. >>>>> That said, I feel vary about attempts to guess Apple colors >>>> wary I mean >>>>> in non-generic profiles. >>> Yuri. Do you mean that the non-generic is not a root case? >> No: I had Generic RGB everywhere, and it failed for me. >> I should say that the new version of the test properly >> fails with b120 and pass with current PIT. And colors >> are visibly different in the two builds: so the test works OK now. > That contradicts with the description of the fix. > Probably the test does unnecessary care about the non-Generic profiles. > > 159 if (!foundMatch && isMac()) { > 160 //One more chance for Mac due to non-Generic display setting > 161 detectedColor = new Color(img.getRGB(x, y), true); > 162 if (detectedColor.equals(colorCheck)) { > 163 foundMatch = true; > 164 break checkLoops; > 165 } > 166 } > > Does it mean that the code above, which is necessary to serve non-Generic profiles on OS X, may be removed and the test still passes? > > --Semyon >> >> -yan >> >>> >>> --Semyon >>>>> >>>>> -yan >>>>> >>>>> >>>>>> >>>>>> --Semyon >>>>>>> >>>>>>> Regarding ?Negative scenarios?, these include cases where colours are >>>>>>> different from the expected background or foreground colors >>>>>>> is checked with the robot and BufferedImage respectively to *eliminate >>>>>>> false positives due to coincidentally finding a match* by using robot >>>>>>> or BufferedImage. >>>>>>> >>>>>>> Please find my changes appropriating the inputs provided. >>>>>>> I removed the variable foundMatch as I found that it is not required >>>>>>> at all and incorporated the suggestion to use return instead of a >>>>>>> labelled break. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~aniyogi/8160438/webrev.01/ >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 07-Jul-2016, at 6:30 pm, Semyon Sadetsky >>>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Avik, >>>>>>>> >>>>>>>> could you clarify what is "Non-generic display settings"? Is it known >>>>>>>> bug on OS X? >>>>>>>> And also please be more specific on "negative scenarios" why they are >>>>>>>> necessary ? >>>>>>>> >>>>>>>> Also could you replace labeled break with "return foundMatch; " >>>>>>>> >>>>>>>> --Semyon >>>>>>>> >>>>>>>> >>>>>>>> On 07.07.2016 15:11, Avik Niyogi wrote: >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> Kindly review the fix for JDK9. >>>>>>>>> >>>>>>>>> *Bug: >>>>>>>>> *https://bugs.openjdk.java.net/browse/JDK-8160438 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> *Webrev: >>>>>>>>> *http://cr.openjdk.java.net/~aniyogi/8160438/webrev.00/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> *Issue: *test javax/swing/plaf/nimbus/8057791/bug8057791.java >>>>>>>>> consistently fails on OS X 10.10 >>>>>>>>> >>>>>>>>> *Cause: * Due to bug in detecting color for Non-generic display >>>>>>>>> settings for Mac hardware, test case failed >>>>>>>>> >>>>>>>>> *Fix: *Positive and negative scenarios was added to check the colour >>>>>>>>> for the Nimbus LAF foreground and background colours. >>>>>>>>> >>>>>>>>> With Regards, >>>>>>>>> Avik Niyogi -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajit.ghaisas at oracle.com Fri Jul 8 05:02:05 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Fri, 8 Jul 2016 05:02:05 +0000 (UTC) Subject: [9] Fix for JDK-6567433 : JComponent.updateUI() may create StackOverflowError In-Reply-To: References: <6e84f122-4481-4696-b013-27e8fb291231@default> <9422a635-fa1a-46e5-a115-ca77163aaebe@default> Message-ID: Hi Andrej, Thanks for your suggestion. I have made the 'updateInProgress' member of these classes transient. This is out of the fact that - 'updateInProgress' member is just an internal field of the class that need not be preserved during serialization. Here is the updated webrev. Request you to review. http://cr.openjdk.java.net/~aghaisas/6567433/webrev.03/ Regards, Ajit -----Original Message----- From: Andrej Golovnin [mailto:andrej.golovnin at gmail.com] Sent: Thursday, July 07, 2016 4:44 PM To: Ajit Ghaisas Cc: Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net Subject: Re: [9] Fix for JDK-6567433 : JComponent.updateUI() may create StackOverflowError Hi Ajit, one more thing that I have just noticed: /** * Flag to indicate UI update is in progress */ private boolean updateInProgress; I think the field must be transient. In Swing every component is serializable. When updateInProgress is set to true and you serialize/deserialize the component, then the call of the #updateUI()-method on the deserialized instance would never update the UI of the deserialized component because the flag updateInProgress will never change from true to false. Best regards, Andrej Golovnin From rajeev.chamyal at oracle.com Fri Jul 8 07:31:55 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Fri, 8 Jul 2016 07:31:55 +0000 (UTC) Subject: Swing Dev> Review Request JDK-8158205 HiDPI hand cursor broken on Windows In-Reply-To: <2dce7708-cbec-16cd-19ba-1e6a1878e583@oracle.com> References: <7a94293f-fb5d-4591-abfd-abb605923325@default> <2dce7708-cbec-16cd-19ba-1e6a1878e583@oracle.com> Message-ID: Hello Alexandr, Please review the updated webrev. http://cr.openjdk.java.net/~rchamyal/8158205/webrev.01/ Test was always passing without fix also. I have converted it into manual test. Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 05 July 2016 13:29 To: Rajeev Chamyal; swing-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Swing Dev> Review Request JDK-8158205 HiDPI hand cursor broken on Windows On 7/5/2016 10:08 AM, Rajeev Chamyal wrote: Hello All, Please review the following fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8158205 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8158205/webrev.00/"http://cr.openjdk.java.net/~rchamyal/8158205/webrev.00/ Issue: Incorrect cursor type is displayed over frame in Hidpi screen. Cause: Windows getCursorPos API is returning scaled screen co-ordinates for mouse as a result the findComponentAt is not able to find the frame below mouse pointer and its returning incorrect cursor type. Fix: Updated awt_Cursor.cpp:: getCursorPos to return scaled down co-ordinates. - The call to JFrame methods should be done on EDT in the test. - It looks like there is no need to use the invokeLater() inside the invokeAndWait() call - In case the test fails the dispose method is never called. Thanks, Alexandr. Regards, Rajeev Chamyal -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Fri Jul 8 07:49:55 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Fri, 8 Jul 2016 10:49:55 +0300 Subject: Swing Dev> Review Request JDK-8158205 HiDPI hand cursor broken on Windows In-Reply-To: References: <7a94293f-fb5d-4591-abfd-abb605923325@default> <2dce7708-cbec-16cd-19ba-1e6a1878e583@oracle.com> Message-ID: <34c73b90-af44-fb77-60c4-868f8f938c40@oracle.com> The fix looks good to me. Thanks, Alexandr. On 7/8/2016 10:31 AM, Rajeev Chamyal wrote: > > Hello Alexandr, > > Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8158205/webrev.01/ > > > Test was always passing without fix also. I have converted it into > manual test. > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 05 July 2016 13:29 > *To:* Rajeev Chamyal; swing-dev at openjdk.java.net; Sergey Bylokhov > *Subject:* Re: Swing Dev> Review Request JDK-8158205 HiDPI hand cursor > broken on Windows > > On 7/5/2016 10:08 AM, Rajeev Chamyal wrote: > > Hello All, > > Please review the following fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8158205 > > Webrev: http://cr.openjdk.java.net/~rchamyal/8158205/webrev.00/ > > > Issue: Incorrect cursor type is displayed over frame in Hidpi screen. > > Cause: Windows getCursorPos API is returning scaled screen > co-ordinates for mouse > > as a result the findComponentAt is not able to find the frame > below mouse pointer and its returning incorrect cursor type. > > Fix: Updated awt_Cursor.cpp:: getCursorPos to return scaled down > co-ordinates. > > > - The call to JFrame methods should be done on EDT in the test. > - It looks like there is no need to use the invokeLater() inside the > invokeAndWait() call > - In case the test fails the dispose method is never called. > > Thanks, > Alexandr. > > Regards, > > Rajeev Chamyal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yuri.nesterenko at oracle.com Fri Jul 8 10:54:05 2016 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Fri, 8 Jul 2016 13:54:05 +0300 Subject: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails In-Reply-To: <9BC3920C-8311-44BE-B78E-56305112AA78@oracle.com> References: <9B81739F-3482-4A16-8A12-735ACB060A6E@oracle.com> <577E5279.1020403@oracle.com> <577E6152.3000903@oracle.com> <577E68A5.80500@oracle.com> <577E6E07.2010302@oracle.com> <577E759C.6040805@oracle.com> <158f2094-1ec4-a3a0-17e9-a8038c24eed4@oracle.com> <9BC3920C-8311-44BE-B78E-56305112AA78@oracle.com> Message-ID: <577F864D.4080303@oracle.com> It pass for me if I provide some time to process native events after the user activity simulation. For instance, setAutoDelay(50) for robot does that plus waitForIdle() after every mouseMove(). In this case, the part with that additional check and a (misleading, I think) comment about the color profiles may be removed. The test would take much more time though, and @run main/timeout=600 bug8057791 line would be necessary. Thanks, -yan On 07/08/2016 04:28 AM, Avik Niyogi wrote: > The test does not pass if mac specific check is not done for > backgroundcolor. > The check is required to get the same values from BufferedImage as they > are the same as found with Digital Color Meter. > This test case fixes that. > Please provide inputs if this fix will get a +1 or if not any positive > inputs to modify the test case will be welcome. > > With Regards, > Avik Niyogi >> On 07-Jul-2016, at 9:51 pm, Semyon Sadetsky >> > wrote: >> >> >> >> On 7/7/2016 6:30 PM, Yuri Nesterenko wrote: >>> On 07/07/2016 06:15 PM, Semyon Sadetsky wrote: >>>> >>>> >>>> On 7/7/2016 5:58 PM, Yuri Nesterenko wrote: >>>>> On 07/07/2016 05:35 PM, Yuri Nesterenko wrote: >>>>>> On 07/07/2016 05:04 PM, Semyon Sadetsky wrote: >>>>>>> >>>>>>> >>>>>>> On 07.07.2016 16:35, Avik Niyogi wrote: >>>>>>>> Hi Semyon, >>>>>>>> >>>>>>>> Thank you for the review comment. >>>>>>>> >>>>>>>> In Mac OS X, *System Preferences > Displays > Colors > Display >>>>>>>> Profile* section, the default value is *Color LCD*. >>>>>>>> This causes a failure in some test cases which uses robot.The colour >>>>>>>> configuration it expects to use is the *Generic RGB Profile*. >>>>>>>> That is what ?Non-generic display settings? means. >>>>>>> AFAIK there are instruction that tests should be executed using color >>>>>>> profile with no color corrections on OS X. I guess there are many >>>>>>> other >>>>>>> tests that fail with color correction. >>>>>>> If this is a root cause than the bug doesn't need to be fixed. >>>>>> >>>>>> Well, I filed this bug and I used Generic RGB on all my >>>>>> test machines. There may be additional precautions in the tests >>>>>> about that but misconfiguration is not the root case here. >>>>>> That said, I feel vary about attempts to guess Apple colors >>>>> wary I mean >>>>>> in non-generic profiles. >>>> Yuri. Do you mean that the non-generic is not a root case? >>> No: I had Generic RGB everywhere, and it failed for me. >>> I should say that the new version of the test properly >>> fails with b120 and pass with current PIT. And colors >>> are visibly different in the two builds: so the test works OK now. >> That contradicts with the description of the fix. >> Probably the test does unnecessary care about the non-Generic profiles. >> >> 159 if (!foundMatch && isMac()) { >> 160 //One more chance for Mac due to non-Generic >> display setting >> 161 detectedColor = new Color(img.getRGB(x, y), true); >> 162 if (detectedColor.equals(colorCheck)) { >> 163 foundMatch = true; >> 164 break checkLoops; >> 165 } >> 166 } >> >> Does it mean that the code above, which is necessary to serve >> non-Generic profiles on OS X, may be removed and the test still passes? >> >> --Semyon >>> >>> -yan >>> >>>> >>>> --Semyon >>>>>> >>>>>> -yan >>>>>> >>>>>> >>>>>>> >>>>>>> --Semyon >>>>>>>> >>>>>>>> Regarding ?Negative scenarios?, these include cases where >>>>>>>> colours are >>>>>>>> different from the expected background or foreground colors >>>>>>>> is checked with the robot and BufferedImage respectively to >>>>>>>> *eliminate >>>>>>>> false positives due to coincidentally finding a match* by using >>>>>>>> robot >>>>>>>> or BufferedImage. >>>>>>>> >>>>>>>> Please find my changes appropriating the inputs provided. >>>>>>>> I removed the variable foundMatch as I found that it is not required >>>>>>>> at all and incorporated the suggestion to use return instead of a >>>>>>>> labelled break. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~aniyogi/8160438/webrev.01/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On 07-Jul-2016, at 6:30 pm, Semyon Sadetsky >>>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi Avik, >>>>>>>>> >>>>>>>>> could you clarify what is "Non-generic display settings"? Is it >>>>>>>>> known >>>>>>>>> bug on OS X? >>>>>>>>> And also please be more specific on "negative scenarios" why >>>>>>>>> they are >>>>>>>>> necessary ? >>>>>>>>> >>>>>>>>> Also could you replace labeled break with "return foundMatch; " >>>>>>>>> >>>>>>>>> --Semyon >>>>>>>>> >>>>>>>>> >>>>>>>>> On 07.07.2016 15:11, Avik Niyogi wrote: >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> Kindly review the fix for JDK9. >>>>>>>>>> >>>>>>>>>> *Bug: >>>>>>>>>> *https://bugs.openjdk.java.net/browse/JDK-8160438 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *Webrev: >>>>>>>>>> *http://cr.openjdk.java.net/~aniyogi/8160438/webrev.00/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *Issue: *test javax/swing/plaf/nimbus/8057791/bug8057791.java >>>>>>>>>> consistently fails on OS X 10.10 >>>>>>>>>> >>>>>>>>>> *Cause: * Due to bug in detecting color for Non-generic display >>>>>>>>>> settings for Mac hardware, test case failed >>>>>>>>>> >>>>>>>>>> *Fix: *Positive and negative scenarios was added to check the >>>>>>>>>> colour >>>>>>>>>> for the Nimbus LAF foreground and background colours. >>>>>>>>>> >>>>>>>>>> With Regards, >>>>>>>>>> Avik Niyogi > From semyon.sadetsky at oracle.com Fri Jul 8 12:13:11 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 8 Jul 2016 15:13:11 +0300 Subject: Swing Dev> Review Request JDK-8158205 HiDPI hand cursor broken on Windows In-Reply-To: <34c73b90-af44-fb77-60c4-868f8f938c40@oracle.com> References: <7a94293f-fb5d-4591-abfd-abb605923325@default> <2dce7708-cbec-16cd-19ba-1e6a1878e583@oracle.com> <34c73b90-af44-fb77-60c4-868f8f938c40@oracle.com> Message-ID: <9a8abe98-9a6f-e03f-e12f-466d1584ad61@oracle.com> +1 --Semyon On 7/8/2016 10:49 AM, Alexandr Scherbatiy wrote: > The fix looks good to me. > > Thanks, > Alexandr. > > On 7/8/2016 10:31 AM, Rajeev Chamyal wrote: >> >> Hello Alexandr, >> >> Please review the updated webrev. >> >> http://cr.openjdk.java.net/~rchamyal/8158205/webrev.01/ >> >> >> Test was always passing without fix also. I have converted it into >> manual test. >> >> Regards, >> >> Rajeev Chamyal >> >> *From:*Alexandr Scherbatiy >> *Sent:* 05 July 2016 13:29 >> *To:* Rajeev Chamyal; swing-dev at openjdk.java.net; Sergey Bylokhov >> *Subject:* Re: Swing Dev> Review Request JDK-8158205 HiDPI hand >> cursor broken on Windows >> >> On 7/5/2016 10:08 AM, Rajeev Chamyal wrote: >> >> Hello All, >> >> Please review the following fix. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8158205 >> >> Webrev: http://cr.openjdk.java.net/~rchamyal/8158205/webrev.00/ >> >> >> Issue: Incorrect cursor type is displayed over frame in Hidpi screen. >> >> Cause: Windows getCursorPos API is returning scaled screen >> co-ordinates for mouse >> >> as a result the findComponentAt is not able to find the frame >> below mouse pointer and its returning incorrect cursor type. >> >> Fix: Updated awt_Cursor.cpp:: getCursorPos to return scaled down >> co-ordinates. >> >> >> - The call to JFrame methods should be done on EDT in the test. >> - It looks like there is no need to use the invokeLater() inside >> the invokeAndWait() call >> - In case the test fails the dispose method is never called. >> >> Thanks, >> Alexandr. >> >> Regards, >> >> Rajeev Chamyal >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Mon Jul 11 07:00:06 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 11 Jul 2016 10:00:06 +0300 Subject: Review Request JDK-8159168 [hidpi] Window.setShape() works incorrectly on HiDPI In-Reply-To: <177de961-76d1-4fa0-8ca0-1f9445e39b0b@default> References: <4df2cfca-d6d2-4dcf-b986-713d76f017a4@default> <7016c0cd-9ad3-4ffb-b4cb-be109a7a50b5@oracle.com> <2344f943-cbca-4df2-bec4-30c0fe766388@default> <6275c579-6947-bd61-c434-65ffa1839902@oracle.com> <177de961-76d1-4fa0-8ca0-1f9445e39b0b@default> Message-ID: Hi Rajeev, The fix itself looks good. I only did not get for what purpose mouse pointer is moved in the test? --Semyon On 7/5/2016 9:16 AM, Rajeev Chamyal wrote: > > Hello Alexandr, > > Please review updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8159168/webrev.02/ > > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 05 July 2016 11:38 > *To:* Rajeev Chamyal; swing-dev at openjdk.java.net; Sergey Bylokhov > *Subject:* Re: Review Request JDK-8159168 [hidpi] > Window.setShape() works incorrectly on HiDPI > > On 7/5/2016 8:25 AM, Rajeev Chamyal wrote: > > Hello Alexandr, > > Thanks for the review. > > As per windows specification X & Y scale are always equal that?s > why I have put scaleX == scaleY check. > > But it may change in future so I have removed this check. > > http://cr.openjdk.java.net/~rchamyal/8159168/webrev.01/ > > > > 1135 if (scaleX != 1 && scaleY != 1) { > > It is better to use 'or' operator because the shape should be scaled > when on of the scales is differ from 1. > > Thanks, > Alexandr. > > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 04 July 2016 18:03 > *To:* Rajeev Chamyal; swing-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: Review Request JDK-8159168 [hidpi] > Window.setShape() works incorrectly on HiDPI > > On 7/4/2016 3:09 PM, Rajeev Chamyal wrote: > > > Hello All, > > Please review the following webrev. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8159168 > > Webrev: > http://cr.openjdk.java.net/~rchamyal/8159168/webrev.00/ > > > Issue: In HiDPI screen shape set through window::setShape API > is not scaled based on system scale. > > Fix:. Updated the WComponentPeer::applyShape to update shape > based on system scale. > > 1131 double scaleX = > winGraphicsConfig.getDefaultTransform().getScaleX(); > 1132 double scaleY = > winGraphicsConfig.getDefaultTransform().getScaleY(); > > The getDefaultTransform() is called twice which leads that > AffineTransform object is created two times > 1133 if (scaleX != 1 && scaleY != 1 && scaleX == scaleY) { > > Is the check scaleX == scaleY really necessary here? > > Is it possible to make the test automated? Just run it with > option "@run main/othervm -Dsun.java2d.uiScale=2 TestName" and > check the area where the shape is drawn? > > Thanks, > Alexandr. > > > Regards, > > Rajeev Chamyal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajeev.chamyal at oracle.com Mon Jul 11 08:10:57 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Mon, 11 Jul 2016 01:10:57 -0700 (PDT) Subject: Review Request JDK-8159168 [hidpi] Window.setShape() works incorrectly on HiDPI In-Reply-To: References: <4df2cfca-d6d2-4dcf-b986-713d76f017a4@default> <7016c0cd-9ad3-4ffb-b4cb-be109a7a50b5@oracle.com> <2344f943-cbca-4df2-bec4-30c0fe766388@default> <6275c579-6947-bd61-c434-65ffa1839902@oracle.com> <177de961-76d1-4fa0-8ca0-1f9445e39b0b@default> Message-ID: <9485ca23-2afe-4a63-8117-590d6e88efc3@default> Hello Semyon, Thanks for the review. Yes, mouse move is not required I have removed it. Please review the updated webrev. http://cr.openjdk.java.net/~rchamyal/8159168/webrev.03/ Regards, Rajeev Chamyal From: Semyon Sadetsky Sent: 11 July 2016 12:30 To: Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request JDK-8159168 [hidpi] Window.setShape() works incorrectly on HiDPI Hi Rajeev, The fix itself looks good. I only did not get for what purpose mouse pointer is moved in the test? --Semyon On 7/5/2016 9:16 AM, Rajeev Chamyal wrote: Hello Alexandr, Please review updated webrev. http://cr.openjdk.java.net/~rchamyal/8159168/webrev.02/ Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 05 July 2016 11:38 To: Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request JDK-8159168 [hidpi] Window.setShape() works incorrectly on HiDPI On 7/5/2016 8:25 AM, Rajeev Chamyal wrote: Hello Alexandr, Thanks for the review. As per windows specification X & Y scale are always equal that's why I have put scaleX == scaleY check. But it may change in future so I have removed this check. http://cr.openjdk.java.net/~rchamyal/8159168/webrev.01/ 1135 if (scaleX != 1 && scaleY != 1) { It is better to use 'or' operator because the shape should be scaled when on of the scales is differ from 1. Thanks, Alexandr. Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 04 July 2016 18:03 To: Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request JDK-8159168 [hidpi] Window.setShape() works incorrectly on HiDPI On 7/4/2016 3:09 PM, Rajeev Chamyal wrote: Hello All, Please review the following webrev. Bug: https://bugs.openjdk.java.net/browse/JDK-8159168 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8159168/webrev.00/"http://cr.openjdk.java.net/~rchamyal/8159168/webrev.00/ Issue: In HiDPI screen shape set through window::setShape API is not scaled based on system scale. Fix:. Updated the WComponentPeer::applyShape to update shape based on system scale. 1131 double scaleX = winGraphicsConfig.getDefaultTransform().getScaleX(); 1132 double scaleY = winGraphicsConfig.getDefaultTransform().getScaleY(); The getDefaultTransform() is called twice which leads that AffineTransform object is created two times 1133 if (scaleX != 1 && scaleY != 1 && scaleX == scaleY) { Is the check scaleX == scaleY really necessary here? Is it possible to make the test automated? Just run it with option "@run main/othervm -Dsun.java2d.uiScale=2 TestName" and check the area where the shape is drawn? Thanks, Alexandr. Regards, Rajeev Chamyal -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Mon Jul 11 08:58:34 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 11 Jul 2016 11:58:34 +0300 Subject: Review Request JDK-8159168 [hidpi] Window.setShape() works incorrectly on HiDPI In-Reply-To: <9485ca23-2afe-4a63-8117-590d6e88efc3@default> References: <4df2cfca-d6d2-4dcf-b986-713d76f017a4@default> <7016c0cd-9ad3-4ffb-b4cb-be109a7a50b5@oracle.com> <2344f943-cbca-4df2-bec4-30c0fe766388@default> <6275c579-6947-bd61-c434-65ffa1839902@oracle.com> <177de961-76d1-4fa0-8ca0-1f9445e39b0b@default> <9485ca23-2afe-4a63-8117-590d6e88efc3@default> Message-ID: <8863940b-832e-ccb2-331c-37b28aab84fa@oracle.com> On 7/11/2016 11:10 AM, Rajeev Chamyal wrote: > Hello Semyon, > > Thanks for the review. Yes, mouse move is not required I have removed it. > > Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8159168/webrev.03/ > > Thanks. I also cannot see the reason to wait 1 second in line 59. It seems tx variable from line 53 is never used. --Semyon > > Regards, > > Rajeev Chamyal > > *From:*Semyon Sadetsky > *Sent:* 11 July 2016 12:30 > *To:* Rajeev Chamyal; Alexander Scherbatiy; > swing-dev at openjdk.java.net; Sergey Bylokhov > *Subject:* Re: Review Request JDK-8159168 [hidpi] > Window.setShape() works incorrectly on HiDPI > > Hi Rajeev, > > The fix itself looks good. I only did not get for what purpose mouse > pointer is moved in the test? > > --Semyon > > On 7/5/2016 9:16 AM, Rajeev Chamyal wrote: > > Hello Alexandr, > > Please review updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8159168/webrev.02/ > > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 05 July 2016 11:38 > *To:* Rajeev Chamyal; swing-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: Review Request JDK-8159168 [hidpi] > Window.setShape() works incorrectly on HiDPI > > On 7/5/2016 8:25 AM, Rajeev Chamyal wrote: > > > Hello Alexandr, > > Thanks for the review. > > As per windows specification X & Y scale are always equal > that?s why I have put scaleX == scaleY check. > > But it may change in future so I have removed this check. > > http://cr.openjdk.java.net/~rchamyal/8159168/webrev.01/ > > > > 1135 if (scaleX != 1 && scaleY != 1) { > > It is better to use 'or' operator because the shape should be > scaled when on of the scales is differ from 1. > > Thanks, > Alexandr. > > > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 04 July 2016 18:03 > *To:* Rajeev Chamyal; swing-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: Review Request JDK-8159168 [hidpi] > Window.setShape() works incorrectly on HiDPI > > On 7/4/2016 3:09 PM, Rajeev Chamyal wrote: > > > > Hello All, > > Please review the following webrev. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8159168 > > Webrev: > http://cr.openjdk.java.net/~rchamyal/8159168/webrev.00/ > > > Issue: In HiDPI screen shape set through window::setShape > API is not scaled based on system scale. > > Fix:. Updated the WComponentPeer::applyShape to update > shape based on system scale. > > 1131 double scaleX = > winGraphicsConfig.getDefaultTransform().getScaleX(); > 1132 double scaleY = > winGraphicsConfig.getDefaultTransform().getScaleY(); > > The getDefaultTransform() is called twice which leads that > AffineTransform object is created two times > 1133 if (scaleX != 1 && scaleY != 1 && scaleX == > scaleY) { > > Is the check scaleX == scaleY really necessary here? > > Is it possible to make the test automated? Just run it with > option "@run main/othervm -Dsun.java2d.uiScale=2 TestName" and > check the area where the shape is drawn? > > Thanks, > Alexandr. > > > > Regards, > > Rajeev Chamyal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajeev.chamyal at oracle.com Mon Jul 11 09:08:35 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Mon, 11 Jul 2016 02:08:35 -0700 (PDT) Subject: Review Request JDK-8159168 [hidpi] Window.setShape() works incorrectly on HiDPI In-Reply-To: <8863940b-832e-ccb2-331c-37b28aab84fa@oracle.com> References: <4df2cfca-d6d2-4dcf-b986-713d76f017a4@default> <7016c0cd-9ad3-4ffb-b4cb-be109a7a50b5@oracle.com> <2344f943-cbca-4df2-bec4-30c0fe766388@default> <6275c579-6947-bd61-c434-65ffa1839902@oracle.com> <177de961-76d1-4fa0-8ca0-1f9445e39b0b@default> <9485ca23-2afe-4a63-8117-590d6e88efc3@default> <8863940b-832e-ccb2-331c-37b28aab84fa@oracle.com> Message-ID: Hello Semyon, Please review the updated webrev as per review comments. http://cr.openjdk.java.net/~rchamyal/8159168/webrev.04/ Regards, Rajeev Chamyal From: Semyon Sadetsky Sent: 11 July 2016 14:29 To: Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request JDK-8159168 [hidpi] Window.setShape() works incorrectly on HiDPI On 7/11/2016 11:10 AM, Rajeev Chamyal wrote: Hello Semyon, Thanks for the review. Yes, mouse move is not required I have removed it. Please review the updated webrev. http://cr.openjdk.java.net/~rchamyal/8159168/webrev.03/ Thanks. I also cannot see the reason to wait 1 second in line 59. It seems tx variable from line 53 is never used. --Semyon Regards, Rajeev Chamyal From: Semyon Sadetsky Sent: 11 July 2016 12:30 To: Rajeev Chamyal; Alexander Scherbatiy; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request JDK-8159168 [hidpi] Window.setShape() works incorrectly on HiDPI Hi Rajeev, The fix itself looks good. I only did not get for what purpose mouse pointer is moved in the test? --Semyon On 7/5/2016 9:16 AM, Rajeev Chamyal wrote: Hello Alexandr, Please review updated webrev. http://cr.openjdk.java.net/~rchamyal/8159168/webrev.02/ Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 05 July 2016 11:38 To: Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request JDK-8159168 [hidpi] Window.setShape() works incorrectly on HiDPI On 7/5/2016 8:25 AM, Rajeev Chamyal wrote: Hello Alexandr, Thanks for the review. As per windows specification X & Y scale are always equal that's why I have put scaleX == scaleY check. But it may change in future so I have removed this check. http://cr.openjdk.java.net/~rchamyal/8159168/webrev.01/ 1135 if (scaleX != 1 && scaleY != 1) { It is better to use 'or' operator because the shape should be scaled when on of the scales is differ from 1. Thanks, Alexandr. Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 04 July 2016 18:03 To: Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: Review Request JDK-8159168 [hidpi] Window.setShape() works incorrectly on HiDPI On 7/4/2016 3:09 PM, Rajeev Chamyal wrote: Hello All, Please review the following webrev. Bug: https://bugs.openjdk.java.net/browse/JDK-8159168 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8159168/webrev.00/"http://cr.openjdk.java.net/~rchamyal/8159168/webrev.00/ Issue: In HiDPI screen shape set through window::setShape API is not scaled based on system scale. Fix:. Updated the WComponentPeer::applyShape to update shape based on system scale. 1131 double scaleX = winGraphicsConfig.getDefaultTransform().getScaleX(); 1132 double scaleY = winGraphicsConfig.getDefaultTransform().getScaleY(); The getDefaultTransform() is called twice which leads that AffineTransform object is created two times 1133 if (scaleX != 1 && scaleY != 1 && scaleX == scaleY) { Is the check scaleX == scaleY really necessary here? Is it possible to make the test automated? Just run it with option "@run main/othervm -Dsun.java2d.uiScale=2 TestName" and check the area where the shape is drawn? Thanks, Alexandr. Regards, Rajeev Chamyal -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Mon Jul 11 09:13:26 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 11 Jul 2016 12:13:26 +0300 Subject: Review Request JDK-8159168 [hidpi] Window.setShape() works incorrectly on HiDPI In-Reply-To: References: <4df2cfca-d6d2-4dcf-b986-713d76f017a4@default> <7016c0cd-9ad3-4ffb-b4cb-be109a7a50b5@oracle.com> <2344f943-cbca-4df2-bec4-30c0fe766388@default> <6275c579-6947-bd61-c434-65ffa1839902@oracle.com> <177de961-76d1-4fa0-8ca0-1f9445e39b0b@default> <9485ca23-2afe-4a63-8117-590d6e88efc3@default> <8863940b-832e-ccb2-331c-37b28aab84fa@oracle.com> Message-ID: Looks good to me. --Semyon On 7/11/2016 12:08 PM, Rajeev Chamyal wrote: > > Hello Semyon, > > Please review the updated webrev as per review comments. > > http://cr.openjdk.java.net/~rchamyal/8159168/webrev.04/ > > > Regards, > > Rajeev Chamyal > > *From:*Semyon Sadetsky > *Sent:* 11 July 2016 14:29 > *To:* Rajeev Chamyal; Alexander Scherbatiy; > swing-dev at openjdk.java.net; Sergey Bylokhov > *Subject:* Re: Review Request JDK-8159168 [hidpi] > Window.setShape() works incorrectly on HiDPI > > On 7/11/2016 11:10 AM, Rajeev Chamyal wrote: > > Hello Semyon, > > Thanks for the review. Yes, mouse move is not required I have > removed it. > > Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8159168/webrev.03/ > > > Thanks. > I also cannot see the reason to wait 1 second in line 59. > It seems tx variable from line 53 is never used. > > --Semyon > > Regards, > > Rajeev Chamyal > > *From:*Semyon Sadetsky > *Sent:* 11 July 2016 12:30 > *To:* Rajeev Chamyal; Alexander Scherbatiy; > swing-dev at openjdk.java.net ; > Sergey Bylokhov > *Subject:* Re: Review Request JDK-8159168 [hidpi] > Window.setShape() works incorrectly on HiDPI > > Hi Rajeev, > > The fix itself looks good. I only did not get for what purpose > mouse pointer is moved in the test? > > --Semyon > > On 7/5/2016 9:16 AM, Rajeev Chamyal wrote: > > Hello Alexandr, > > Please review updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8159168/webrev.02/ > > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 05 July 2016 11:38 > *To:* Rajeev Chamyal; swing-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: Review Request JDK-8159168 [hidpi] > Window.setShape() works incorrectly on HiDPI > > On 7/5/2016 8:25 AM, Rajeev Chamyal wrote: > > > > Hello Alexandr, > > Thanks for the review. > > As per windows specification X & Y scale are always equal > that?s why I have put scaleX == scaleY check. > > But it may change in future so I have removed this check. > > http://cr.openjdk.java.net/~rchamyal/8159168/webrev.01/ > > > > 1135 if (scaleX != 1 && scaleY != 1) { > > It is better to use 'or' operator because the shape should > be scaled when on of the scales is differ from 1. > > Thanks, > Alexandr. > > > > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 04 July 2016 18:03 > *To:* Rajeev Chamyal; swing-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: Review Request JDK-8159168 > [hidpi] Window.setShape() works incorrectly on HiDPI > > On 7/4/2016 3:09 PM, Rajeev Chamyal wrote: > > > > > Hello All, > > Please review the following webrev. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8159168 > > Webrev: > http://cr.openjdk.java.net/~rchamyal/8159168/webrev.00/ > > > > Issue: In HiDPI screen shape set through > window::setShape API is not scaled based on system scale. > > Fix:. Updated the WComponentPeer::applyShape to update > shape based on system scale. > > 1131 double scaleX = > winGraphicsConfig.getDefaultTransform().getScaleX(); > 1132 double scaleY = > winGraphicsConfig.getDefaultTransform().getScaleY(); > > The getDefaultTransform() is called twice which leads > that AffineTransform object is created two times > 1133 if (scaleX != 1 && scaleY != 1 && scaleX > == scaleY) { > > Is the check scaleX == scaleY really necessary here? > > Is it possible to make the test automated? Just run it > with option "@run main/othervm -Dsun.java2d.uiScale=2 > TestName" and check the area where the shape is drawn? > > Thanks, > Alexandr. > > > > > Regards, > > Rajeev Chamyal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Mon Jul 11 09:28:32 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 11 Jul 2016 12:28:32 +0300 Subject: [9] Review request for 8159587: IOOBE in javax/swing/JFileChooser/7199708/bug7199708.java Message-ID: <37d2fdb3-755a-a112-3a03-a49061022b47@oracle.com> Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8159587 webrev: http://cr.openjdk.java.net/~ssadetsky/8159587/webrev.00/ Exception is caused by row index value =0 which is not in a valid range because table model contains no rows at the moment. The issue is in FilePane's clear selection method. The correct way to clear a selection model is to set the anchor/lead index to -1 not to 0. --Semyon From alexandr.scherbatiy at oracle.com Mon Jul 11 10:12:11 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Mon, 11 Jul 2016 13:12:11 +0300 Subject: Review Request JDK-8159168 [hidpi] Window.setShape() works incorrectly on HiDPI In-Reply-To: References: <4df2cfca-d6d2-4dcf-b986-713d76f017a4@default> <7016c0cd-9ad3-4ffb-b4cb-be109a7a50b5@oracle.com> <2344f943-cbca-4df2-bec4-30c0fe766388@default> <6275c579-6947-bd61-c434-65ffa1839902@oracle.com> <177de961-76d1-4fa0-8ca0-1f9445e39b0b@default> <9485ca23-2afe-4a63-8117-590d6e88efc3@default> <8863940b-832e-ccb2-331c-37b28aab84fa@oracle.com> Message-ID: <1060a3a6-15ff-00de-5e05-ef8563bdabb6@oracle.com> The fix looks good to me. Thanks, Alexandr. On 7/11/2016 12:13 PM, Semyon Sadetsky wrote: > > Looks good to me. > > --Semyon > > On 7/11/2016 12:08 PM, Rajeev Chamyal wrote: >> >> Hello Semyon, >> >> Please review the updated webrev as per review comments. >> >> http://cr.openjdk.java.net/~rchamyal/8159168/webrev.04/ >> >> Regards, >> >> Rajeev Chamyal >> >> *From:*Semyon Sadetsky >> *Sent:* 11 July 2016 14:29 >> *To:* Rajeev Chamyal; Alexander Scherbatiy; >> swing-dev at openjdk.java.net; Sergey Bylokhov >> *Subject:* Re: Review Request JDK-8159168 [hidpi] >> Window.setShape() works incorrectly on HiDPI >> >> On 7/11/2016 11:10 AM, Rajeev Chamyal wrote: >> >> Hello Semyon, >> >> Thanks for the review. Yes, mouse move is not required I have >> removed it. >> >> Please review the updated webrev. >> >> http://cr.openjdk.java.net/~rchamyal/8159168/webrev.03/ >> >> Thanks. >> I also cannot see the reason to wait 1 second in line 59. >> It seems tx variable from line 53 is never used. >> >> --Semyon >> >> Regards, >> >> Rajeev Chamyal >> >> *From:*Semyon Sadetsky >> *Sent:* 11 July 2016 12:30 >> *To:* Rajeev Chamyal; Alexander Scherbatiy; >> swing-dev at openjdk.java.net; Sergey Bylokhov >> *Subject:* Re: Review Request JDK-8159168 [hidpi] >> Window.setShape() works incorrectly on HiDPI >> >> Hi Rajeev, >> >> The fix itself looks good. I only did not get for what purpose >> mouse pointer is moved in the test? >> >> --Semyon >> >> On 7/5/2016 9:16 AM, Rajeev Chamyal wrote: >> >> Hello Alexandr, >> >> Please review updated webrev. >> >> http://cr.openjdk.java.net/~rchamyal/8159168/webrev.02/ >> >> Regards, >> >> Rajeev Chamyal >> >> *From:*Alexandr Scherbatiy >> *Sent:* 05 July 2016 11:38 >> *To:* Rajeev Chamyal; swing-dev at openjdk.java.net; Sergey Bylokhov >> *Subject:* Re: Review Request JDK-8159168 [hidpi] >> Window.setShape() works incorrectly on HiDPI >> >> On 7/5/2016 8:25 AM, Rajeev Chamyal wrote: >> >> >> >> Hello Alexandr, >> >> Thanks for the review. >> >> As per windows specification X & Y scale are always equal >> that?s why I have put scaleX == scaleY check. >> >> But it may change in future so I have removed this check. >> >> http://cr.openjdk.java.net/~rchamyal/8159168/webrev.01/ >> >> >> 1135 if (scaleX != 1 && scaleY != 1) { >> >> It is better to use 'or' operator because the shape should >> be scaled when on of the scales is differ from 1. >> >> Thanks, >> Alexandr. >> >> >> >> >> Regards, >> >> Rajeev Chamyal >> >> *From:*Alexandr Scherbatiy >> *Sent:* 04 July 2016 18:03 >> *To:* Rajeev Chamyal; swing-dev at openjdk.java.net; Sergey >> Bylokhov >> *Subject:* Re: Review Request JDK-8159168 >> [hidpi] Window.setShape() works incorrectly on HiDPI >> >> On 7/4/2016 3:09 PM, Rajeev Chamyal wrote: >> >> >> >> >> Hello All, >> >> Please review the following webrev. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8159168 >> >> Webrev: >> http://cr.openjdk.java.net/~rchamyal/8159168/webrev.00/ >> >> >> >> Issue: In HiDPI screen shape set through >> window::setShape API is not scaled based on system scale. >> >> Fix:. Updated the WComponentPeer::applyShape to >> update shape based on system scale. >> >> 1131 double scaleX = >> winGraphicsConfig.getDefaultTransform().getScaleX(); >> 1132 double scaleY = >> winGraphicsConfig.getDefaultTransform().getScaleY(); >> >> The getDefaultTransform() is called twice which leads >> that AffineTransform object is created two times >> 1133 if (scaleX != 1 && scaleY != 1 && scaleX >> == scaleY) { >> >> Is the check scaleX == scaleY really necessary here? >> >> Is it possible to make the test automated? Just run it >> with option "@run main/othervm -Dsun.java2d.uiScale=2 >> TestName" and check the area where the shape is drawn? >> >> Thanks, >> Alexandr. >> >> >> >> >> Regards, >> >> Rajeev Chamyal >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Mon Jul 11 10:37:07 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Mon, 11 Jul 2016 13:37:07 +0300 Subject: [9] Review request for 8159587: IOOBE in javax/swing/JFileChooser/7199708/bug7199708.java In-Reply-To: <37d2fdb3-755a-a112-3a03-a49061022b47@oracle.com> References: <37d2fdb3-755a-a112-3a03-a49061022b47@oracle.com> Message-ID: <55eed300-cc42-148f-d6c9-b132aa6ac6ac@oracle.com> The fix looks good to me. Thanks, Alexandr. On 7/11/2016 12:28 PM, Semyon Sadetsky wrote: > Hello, > > Please review fix for JDK9: > > bug: https://bugs.openjdk.java.net/browse/JDK-8159587 > > webrev: http://cr.openjdk.java.net/~ssadetsky/8159587/webrev.00/ > > Exception is caused by row index value =0 which is not in a valid > range because table model contains no rows at the moment. The issue is > in FilePane's clear selection method. The correct way to clear a > selection model is to set the anchor/lead index to -1 not to 0. > > --Semyon > From alexandr.scherbatiy at oracle.com Mon Jul 11 12:31:32 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Mon, 11 Jul 2016 15:31:32 +0300 Subject: Result: New Swing Group Member: Sergey Bylokhov Message-ID: <50586824-f581-6bfd-1ad9-f7a814e7e538@oracle.com> The vote for Sergey Bylokhov [1] is now closed. Yes: 3 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Thanks, Alexandr. [1] http://mail.openjdk.java.net/pipermail/swing-dev/2016-June/006158.html [2] http://openjdk.java.net/bylaws#lazy-consensus From avik.niyogi at oracle.com Tue Jul 12 05:24:15 2016 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Tue, 12 Jul 2016 10:54:15 +0530 Subject: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails In-Reply-To: <577F864D.4080303@oracle.com> References: <9B81739F-3482-4A16-8A12-735ACB060A6E@oracle.com> <577E5279.1020403@oracle.com> <577E6152.3000903@oracle.com> <577E68A5.80500@oracle.com> <577E6E07.2010302@oracle.com> <577E759C.6040805@oracle.com> <158f2094-1ec4-a3a0-17e9-a8038c24eed4@oracle.com> <9BC3920C-8311-44BE-B78E-56305112AA78@oracle.com> <577F864D.4080303@oracle.com> Message-ID: <1ACD9FE4-0D8C-4366-97E0-90C8B3595254@oracle.com> Hi All, A gentle reminder, please review my code changes. With Regards, Avik Niyogi > On 08-Jul-2016, at 4:24 pm, Yuri Nesterenko wrote: > > It pass for me if I provide some time to process native events > after the user activity simulation. For instance, > setAutoDelay(50) for robot does that plus waitForIdle() > after every mouseMove(). In this case, the part with that additional > check and a (misleading, I think) comment about the color profiles > may be removed. The test would take much more time though, and > @run main/timeout=600 bug8057791 > line would be necessary. > > Thanks, > -yan > > On 07/08/2016 04:28 AM, Avik Niyogi wrote: >> The test does not pass if mac specific check is not done for >> backgroundcolor. >> The check is required to get the same values from BufferedImage as they >> are the same as found with Digital Color Meter. >> This test case fixes that. >> Please provide inputs if this fix will get a +1 or if not any positive >> inputs to modify the test case will be welcome. >> >> With Regards, >> Avik Niyogi >>> On 07-Jul-2016, at 9:51 pm, Semyon Sadetsky >>> > wrote: >>> >>> >>> >>> On 7/7/2016 6:30 PM, Yuri Nesterenko wrote: >>>> On 07/07/2016 06:15 PM, Semyon Sadetsky wrote: >>>>> >>>>> >>>>> On 7/7/2016 5:58 PM, Yuri Nesterenko wrote: >>>>>> On 07/07/2016 05:35 PM, Yuri Nesterenko wrote: >>>>>>> On 07/07/2016 05:04 PM, Semyon Sadetsky wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 07.07.2016 16:35, Avik Niyogi wrote: >>>>>>>>> Hi Semyon, >>>>>>>>> >>>>>>>>> Thank you for the review comment. >>>>>>>>> >>>>>>>>> In Mac OS X, *System Preferences > Displays > Colors > Display >>>>>>>>> Profile* section, the default value is *Color LCD*. >>>>>>>>> This causes a failure in some test cases which uses robot.The colour >>>>>>>>> configuration it expects to use is the *Generic RGB Profile*. >>>>>>>>> That is what ?Non-generic display settings? means. >>>>>>>> AFAIK there are instruction that tests should be executed using color >>>>>>>> profile with no color corrections on OS X. I guess there are many >>>>>>>> other >>>>>>>> tests that fail with color correction. >>>>>>>> If this is a root cause than the bug doesn't need to be fixed. >>>>>>> >>>>>>> Well, I filed this bug and I used Generic RGB on all my >>>>>>> test machines. There may be additional precautions in the tests >>>>>>> about that but misconfiguration is not the root case here. >>>>>>> That said, I feel vary about attempts to guess Apple colors >>>>>> wary I mean >>>>>>> in non-generic profiles. >>>>> Yuri. Do you mean that the non-generic is not a root case? >>>> No: I had Generic RGB everywhere, and it failed for me. >>>> I should say that the new version of the test properly >>>> fails with b120 and pass with current PIT. And colors >>>> are visibly different in the two builds: so the test works OK now. >>> That contradicts with the description of the fix. >>> Probably the test does unnecessary care about the non-Generic profiles. >>> >>> 159 if (!foundMatch && isMac()) { >>> 160 //One more chance for Mac due to non-Generic >>> display setting >>> 161 detectedColor = new Color(img.getRGB(x, y), true); >>> 162 if (detectedColor.equals(colorCheck)) { >>> 163 foundMatch = true; >>> 164 break checkLoops; >>> 165 } >>> 166 } >>> >>> Does it mean that the code above, which is necessary to serve >>> non-Generic profiles on OS X, may be removed and the test still passes? >>> >>> --Semyon >>>> >>>> -yan >>>> >>>>> >>>>> --Semyon >>>>>>> >>>>>>> -yan >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> --Semyon >>>>>>>>> >>>>>>>>> Regarding ?Negative scenarios?, these include cases where >>>>>>>>> colours are >>>>>>>>> different from the expected background or foreground colors >>>>>>>>> is checked with the robot and BufferedImage respectively to >>>>>>>>> *eliminate >>>>>>>>> false positives due to coincidentally finding a match* by using >>>>>>>>> robot >>>>>>>>> or BufferedImage. >>>>>>>>> >>>>>>>>> Please find my changes appropriating the inputs provided. >>>>>>>>> I removed the variable foundMatch as I found that it is not required >>>>>>>>> at all and incorporated the suggestion to use return instead of a >>>>>>>>> labelled break. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~aniyogi/8160438/webrev.01/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 07-Jul-2016, at 6:30 pm, Semyon Sadetsky >>>>>>>>>> > >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi Avik, >>>>>>>>>> >>>>>>>>>> could you clarify what is "Non-generic display settings"? Is it >>>>>>>>>> known >>>>>>>>>> bug on OS X? >>>>>>>>>> And also please be more specific on "negative scenarios" why >>>>>>>>>> they are >>>>>>>>>> necessary ? >>>>>>>>>> >>>>>>>>>> Also could you replace labeled break with "return foundMatch; " >>>>>>>>>> >>>>>>>>>> --Semyon >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 07.07.2016 15:11, Avik Niyogi wrote: >>>>>>>>>>> Hi All, >>>>>>>>>>> >>>>>>>>>>> Kindly review the fix for JDK9. >>>>>>>>>>> >>>>>>>>>>> *Bug: >>>>>>>>>>> *https://bugs.openjdk.java.net/browse/JDK-8160438 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *Webrev: >>>>>>>>>>> *http://cr.openjdk.java.net/~aniyogi/8160438/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *Issue: *test javax/swing/plaf/nimbus/8057791/bug8057791.java >>>>>>>>>>> consistently fails on OS X 10.10 >>>>>>>>>>> >>>>>>>>>>> *Cause: * Due to bug in detecting color for Non-generic display >>>>>>>>>>> settings for Mac hardware, test case failed >>>>>>>>>>> >>>>>>>>>>> *Fix: *Positive and negative scenarios was added to check the >>>>>>>>>>> colour >>>>>>>>>>> for the Nimbus LAF foreground and background colours. >>>>>>>>>>> >>>>>>>>>>> With Regards, >>>>>>>>>>> Avik Niyogi >> > From ajit.ghaisas at oracle.com Tue Jul 12 08:30:12 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Tue, 12 Jul 2016 01:30:12 -0700 (PDT) Subject: [9] Fix for JDK-6567433 : JComponent.updateUI() may create StackOverflowError In-Reply-To: References: <6e84f122-4481-4696-b013-27e8fb291231@default> <9422a635-fa1a-46e5-a115-ca77163aaebe@default> Message-ID: <92ee17a3-5a43-434d-86f9-541a948edb0e@default> Hi Andrej, Can you please review this? Regards, Ajit -----Original Message----- From: Ajit Ghaisas Sent: Friday, July 08, 2016 10:32 AM To: Andrej Golovnin Cc: Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net Subject: RE: [9] Fix for JDK-6567433 : JComponent.updateUI() may create StackOverflowError Hi Andrej, Thanks for your suggestion. I have made the 'updateInProgress' member of these classes transient. This is out of the fact that - 'updateInProgress' member is just an internal field of the class that need not be preserved during serialization. Here is the updated webrev. Request you to review. http://cr.openjdk.java.net/~aghaisas/6567433/webrev.03/ Regards, Ajit -----Original Message----- From: Andrej Golovnin [mailto:andrej.golovnin at gmail.com] Sent: Thursday, July 07, 2016 4:44 PM To: Ajit Ghaisas Cc: Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net Subject: Re: [9] Fix for JDK-6567433 : JComponent.updateUI() may create StackOverflowError Hi Ajit, one more thing that I have just noticed: /** * Flag to indicate UI update is in progress */ private boolean updateInProgress; I think the field must be transient. In Swing every component is serializable. When updateInProgress is set to true and you serialize/deserialize the component, then the call of the #updateUI()-method on the deserialized instance would never update the UI of the deserialized component because the flag updateInProgress will never change from true to false. Best regards, Andrej Golovnin From andrej.golovnin at gmail.com Tue Jul 12 12:58:30 2016 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Tue, 12 Jul 2016 14:58:30 +0200 Subject: [9] Fix for JDK-6567433 : JComponent.updateUI() may create StackOverflowError In-Reply-To: <92ee17a3-5a43-434d-86f9-541a948edb0e@default> References: <6e84f122-4481-4696-b013-27e8fb291231@default> <9422a635-fa1a-46e5-a115-ca77163aaebe@default> <92ee17a3-5a43-434d-86f9-541a948edb0e@default> Message-ID: Hi Ajit, it looks good for me. Thanks! And you need a reviewer from the Swing team as I don?t have the reviewer role. Best regards, Andrej Golovnin > > -----Original Message----- > From: Ajit Ghaisas > Sent: Friday, July 08, 2016 10:32 AM > To: Andrej Golovnin > Cc: Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net > Subject: RE: [9] Fix for JDK-6567433 : JComponent.updateUI() may create StackOverflowError > > Hi Andrej, > > Thanks for your suggestion. > > I have made the 'updateInProgress' member of these classes transient. > This is out of the fact that - 'updateInProgress' member is just an internal field of the class that need not be preserved during serialization. > > Here is the updated webrev. Request you to review. > http://cr.openjdk.java.net/~aghaisas/6567433/webrev.03/ > > Regards, > Ajit > > > > -----Original Message----- > From: Andrej Golovnin [mailto:andrej.golovnin at gmail.com] > Sent: Thursday, July 07, 2016 4:44 PM > To: Ajit Ghaisas > Cc: Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net > Subject: Re: [9] Fix for JDK-6567433 : JComponent.updateUI() may create StackOverflowError > > Hi Ajit, > > one more thing that I have just noticed: > > /** > * Flag to indicate UI update is in progress > */ > private boolean updateInProgress; > > I think the field must be transient. In Swing every component is serializable. When updateInProgress is set to true and you serialize/deserialize the component, then the call of the #updateUI()-method on the deserialized instance would never update the UI of the deserialized component because the flag updateInProgress will never change from true to false. > > Best regards, > Andrej Golovnin From alexandr.scherbatiy at oracle.com Tue Jul 12 13:32:43 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 12 Jul 2016 16:32:43 +0300 Subject: [9] Fix for JDK-6567433 : JComponent.updateUI() may create StackOverflowError In-Reply-To: References: <6e84f122-4481-4696-b013-27e8fb291231@default> <9422a635-fa1a-46e5-a115-ca77163aaebe@default> <92ee17a3-5a43-434d-86f9-541a948edb0e@default> Message-ID: The fix looks good to me. Thanks, Alexandr. On 7/12/2016 3:58 PM, Andrej Golovnin wrote: > Hi Ajit, > > it looks good for me. Thanks! > And you need a reviewer from the Swing team > as I don?t have the reviewer role. > > Best regards, > Andrej Golovnin > >> -----Original Message----- >> From: Ajit Ghaisas >> Sent: Friday, July 08, 2016 10:32 AM >> To: Andrej Golovnin >> Cc: Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net >> Subject: RE: [9] Fix for JDK-6567433 : JComponent.updateUI() may create StackOverflowError >> >> Hi Andrej, >> >> Thanks for your suggestion. >> >> I have made the 'updateInProgress' member of these classes transient. >> This is out of the fact that - 'updateInProgress' member is just an internal field of the class that need not be preserved during serialization. >> >> Here is the updated webrev. Request you to review. >> http://cr.openjdk.java.net/~aghaisas/6567433/webrev.03/ >> >> Regards, >> Ajit >> >> >> >> -----Original Message----- >> From: Andrej Golovnin [mailto:andrej.golovnin at gmail.com] >> Sent: Thursday, July 07, 2016 4:44 PM >> To: Ajit Ghaisas >> Cc: Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net >> Subject: Re: [9] Fix for JDK-6567433 : JComponent.updateUI() may create StackOverflowError >> >> Hi Ajit, >> >> one more thing that I have just noticed: >> >> /** >> * Flag to indicate UI update is in progress >> */ >> private boolean updateInProgress; >> >> I think the field must be transient. In Swing every component is serializable. When updateInProgress is set to true and you serialize/deserialize the component, then the call of the #updateUI()-method on the deserialized instance would never update the UI of the deserialized component because the flag updateInProgress will never change from true to false. >> >> Best regards, >> Andrej Golovnin From alexandr.scherbatiy at oracle.com Tue Jul 12 13:42:49 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 12 Jul 2016 16:42:49 +0300 Subject: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails In-Reply-To: <1ACD9FE4-0D8C-4366-97E0-90C8B3595254@oracle.com> References: <9B81739F-3482-4A16-8A12-735ACB060A6E@oracle.com> <577E5279.1020403@oracle.com> <577E6152.3000903@oracle.com> <577E68A5.80500@oracle.com> <577E6E07.2010302@oracle.com> <577E759C.6040805@oracle.com> <158f2094-1ec4-a3a0-17e9-a8038c24eed4@oracle.com> <9BC3920C-8311-44BE-B78E-56305112AA78@oracle.com> <577F864D.4080303@oracle.com> <1ACD9FE4-0D8C-4366-97E0-90C8B3595254@oracle.com> Message-ID: <6b1e1a5d-d4d3-87f7-d6a0-585c0d83d8f2@oracle.com> On 7/12/2016 8:24 AM, Avik Niyogi wrote: > Hi All, > A gentle reminder, please review my code changes. > > With Regards, > Avik Niyogi > >> On 08-Jul-2016, at 4:24 pm, Yuri Nesterenko wrote: >> >> It pass for me if I provide some time to process native events >> after the user activity simulation. For instance, >> setAutoDelay(50) for robot does that plus waitForIdle() >> after every mouseMove(). In this case, the part with that additional >> check and a (misleading, I think) comment about the color profiles >> may be removed. The test would take much more time though, and >> @run main/timeout=600 bug8057791 >> line would be necessary. Some more comments to the previous ones: - runColorTestCase() uses JList and should be run on EDT - "if (tryNimbusLookAndFeel()) {" It is supposed that the Nimbus L&F is supported on all platforms. May be it is better to fail the test if the Nimbus L&F is not set. - "if (osName.contains("Mac")) { isMac = true; }" can be simplified to "return osName.contains("Mac")" - " if (!"".equals(errorString)) {" can be simplified to !errorString.isEmpty() Thanks, Alexandr. >> >> Thanks, >> -yan >> >> On 07/08/2016 04:28 AM, Avik Niyogi wrote: >>> The test does not pass if mac specific check is not done for >>> backgroundcolor. >>> The check is required to get the same values from BufferedImage as they >>> are the same as found with Digital Color Meter. >>> This test case fixes that. >>> Please provide inputs if this fix will get a +1 or if not any positive >>> inputs to modify the test case will be welcome. >>> >>> With Regards, >>> Avik Niyogi >>>> On 07-Jul-2016, at 9:51 pm, Semyon Sadetsky >>>> > wrote: >>>> >>>> >>>> >>>> On 7/7/2016 6:30 PM, Yuri Nesterenko wrote: >>>>> On 07/07/2016 06:15 PM, Semyon Sadetsky wrote: >>>>>> >>>>>> On 7/7/2016 5:58 PM, Yuri Nesterenko wrote: >>>>>>> On 07/07/2016 05:35 PM, Yuri Nesterenko wrote: >>>>>>>> On 07/07/2016 05:04 PM, Semyon Sadetsky wrote: >>>>>>>>> >>>>>>>>> On 07.07.2016 16:35, Avik Niyogi wrote: >>>>>>>>>> Hi Semyon, >>>>>>>>>> >>>>>>>>>> Thank you for the review comment. >>>>>>>>>> >>>>>>>>>> In Mac OS X, *System Preferences > Displays > Colors > Display >>>>>>>>>> Profile* section, the default value is *Color LCD*. >>>>>>>>>> This causes a failure in some test cases which uses robot.The colour >>>>>>>>>> configuration it expects to use is the *Generic RGB Profile*. >>>>>>>>>> That is what ?Non-generic display settings? means. >>>>>>>>> AFAIK there are instruction that tests should be executed using color >>>>>>>>> profile with no color corrections on OS X. I guess there are many >>>>>>>>> other >>>>>>>>> tests that fail with color correction. >>>>>>>>> If this is a root cause than the bug doesn't need to be fixed. >>>>>>>> Well, I filed this bug and I used Generic RGB on all my >>>>>>>> test machines. There may be additional precautions in the tests >>>>>>>> about that but misconfiguration is not the root case here. >>>>>>>> That said, I feel vary about attempts to guess Apple colors >>>>>>> wary I mean >>>>>>>> in non-generic profiles. >>>>>> Yuri. Do you mean that the non-generic is not a root case? >>>>> No: I had Generic RGB everywhere, and it failed for me. >>>>> I should say that the new version of the test properly >>>>> fails with b120 and pass with current PIT. And colors >>>>> are visibly different in the two builds: so the test works OK now. >>>> That contradicts with the description of the fix. >>>> Probably the test does unnecessary care about the non-Generic profiles. >>>> >>>> 159 if (!foundMatch && isMac()) { >>>> 160 //One more chance for Mac due to non-Generic >>>> display setting >>>> 161 detectedColor = new Color(img.getRGB(x, y), true); >>>> 162 if (detectedColor.equals(colorCheck)) { >>>> 163 foundMatch = true; >>>> 164 break checkLoops; >>>> 165 } >>>> 166 } >>>> >>>> Does it mean that the code above, which is necessary to serve >>>> non-Generic profiles on OS X, may be removed and the test still passes? >>>> >>>> --Semyon >>>>> -yan >>>>> >>>>>> --Semyon >>>>>>>> -yan >>>>>>>> >>>>>>>> >>>>>>>>> --Semyon >>>>>>>>>> Regarding ?Negative scenarios?, these include cases where >>>>>>>>>> colours are >>>>>>>>>> different from the expected background or foreground colors >>>>>>>>>> is checked with the robot and BufferedImage respectively to >>>>>>>>>> *eliminate >>>>>>>>>> false positives due to coincidentally finding a match* by using >>>>>>>>>> robot >>>>>>>>>> or BufferedImage. >>>>>>>>>> >>>>>>>>>> Please find my changes appropriating the inputs provided. >>>>>>>>>> I removed the variable foundMatch as I found that it is not required >>>>>>>>>> at all and incorporated the suggestion to use return instead of a >>>>>>>>>> labelled break. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~aniyogi/8160438/webrev.01/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 07-Jul-2016, at 6:30 pm, Semyon Sadetsky >>>>>>>>>>> > >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Avik, >>>>>>>>>>> >>>>>>>>>>> could you clarify what is "Non-generic display settings"? Is it >>>>>>>>>>> known >>>>>>>>>>> bug on OS X? >>>>>>>>>>> And also please be more specific on "negative scenarios" why >>>>>>>>>>> they are >>>>>>>>>>> necessary ? >>>>>>>>>>> >>>>>>>>>>> Also could you replace labeled break with "return foundMatch; " >>>>>>>>>>> >>>>>>>>>>> --Semyon >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 07.07.2016 15:11, Avik Niyogi wrote: >>>>>>>>>>>> Hi All, >>>>>>>>>>>> >>>>>>>>>>>> Kindly review the fix for JDK9. >>>>>>>>>>>> >>>>>>>>>>>> *Bug: >>>>>>>>>>>> *https://bugs.openjdk.java.net/browse/JDK-8160438 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *Webrev: >>>>>>>>>>>> *http://cr.openjdk.java.net/~aniyogi/8160438/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *Issue: *test javax/swing/plaf/nimbus/8057791/bug8057791.java >>>>>>>>>>>> consistently fails on OS X 10.10 >>>>>>>>>>>> >>>>>>>>>>>> *Cause: * Due to bug in detecting color for Non-generic display >>>>>>>>>>>> settings for Mac hardware, test case failed >>>>>>>>>>>> >>>>>>>>>>>> *Fix: *Positive and negative scenarios was added to check the >>>>>>>>>>>> colour >>>>>>>>>>>> for the Nimbus LAF foreground and background colours. >>>>>>>>>>>> >>>>>>>>>>>> With Regards, >>>>>>>>>>>> Avik Niyogi From avik.niyogi at oracle.com Thu Jul 14 06:53:19 2016 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Thu, 14 Jul 2016 12:23:19 +0530 Subject: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails In-Reply-To: <6b1e1a5d-d4d3-87f7-d6a0-585c0d83d8f2@oracle.com> References: <9B81739F-3482-4A16-8A12-735ACB060A6E@oracle.com> <577E5279.1020403@oracle.com> <577E6152.3000903@oracle.com> <577E68A5.80500@oracle.com> <577E6E07.2010302@oracle.com> <577E759C.6040805@oracle.com> <158f2094-1ec4-a3a0-17e9-a8038c24eed4@oracle.com> <9BC3920C-8311-44BE-B78E-56305112AA78@oracle.com> <577F864D.4080303@oracle.com> <1ACD9FE4-0D8C-4366-97E0-90C8B3595254@oracle.com> <6b1e1a5d-d4d3-87f7-d6a0-585c0d83d8f2@oracle.com> Message-ID: <45B95487-4728-464C-91B4-5B360955F963@oracle.com> Hi All, Please find my webrev below for review which includes changes as perceived from inputs provided. http://cr.openjdk.java.net/~aniyogi/8160438/webrev.02/ With Regards, Avik Niyogi > On 12-Jul-2016, at 7:12 pm, Alexandr Scherbatiy wrote: > > On 7/12/2016 8:24 AM, Avik Niyogi wrote: >> Hi All, >> A gentle reminder, please review my code changes. >> >> With Regards, >> Avik Niyogi >> >>> On 08-Jul-2016, at 4:24 pm, Yuri Nesterenko wrote: >>> >>> It pass for me if I provide some time to process native events >>> after the user activity simulation. For instance, >>> setAutoDelay(50) for robot does that plus waitForIdle() >>> after every mouseMove(). In this case, the part with that additional >>> check and a (misleading, I think) comment about the color profiles >>> may be removed. The test would take much more time though, and >>> @run main/timeout=600 bug8057791 >>> line would be necessary. > Some more comments to the previous ones: > - runColorTestCase() uses JList and should be run on EDT > - "if (tryNimbusLookAndFeel()) {" It is supposed that the Nimbus L&F is supported on all platforms. May be it is better to fail the test if the Nimbus L&F is not set. > - "if (osName.contains("Mac")) { isMac = true; }" can be simplified to "return osName.contains("Mac")" > - " if (!"".equals(errorString)) {" can be simplified to !errorString.isEmpty() > > Thanks, > Alexandr. >>> >>> Thanks, >>> -yan >>> >>> On 07/08/2016 04:28 AM, Avik Niyogi wrote: >>>> The test does not pass if mac specific check is not done for >>>> backgroundcolor. >>>> The check is required to get the same values from BufferedImage as they >>>> are the same as found with Digital Color Meter. >>>> This test case fixes that. >>>> Please provide inputs if this fix will get a +1 or if not any positive >>>> inputs to modify the test case will be welcome. >>>> >>>> With Regards, >>>> Avik Niyogi >>>>> On 07-Jul-2016, at 9:51 pm, Semyon Sadetsky >>>>> > wrote: >>>>> >>>>> >>>>> >>>>> On 7/7/2016 6:30 PM, Yuri Nesterenko wrote: >>>>>> On 07/07/2016 06:15 PM, Semyon Sadetsky wrote: >>>>>>> >>>>>>> On 7/7/2016 5:58 PM, Yuri Nesterenko wrote: >>>>>>>> On 07/07/2016 05:35 PM, Yuri Nesterenko wrote: >>>>>>>>> On 07/07/2016 05:04 PM, Semyon Sadetsky wrote: >>>>>>>>>> >>>>>>>>>> On 07.07.2016 16:35, Avik Niyogi wrote: >>>>>>>>>>> Hi Semyon, >>>>>>>>>>> >>>>>>>>>>> Thank you for the review comment. >>>>>>>>>>> >>>>>>>>>>> In Mac OS X, *System Preferences > Displays > Colors > Display >>>>>>>>>>> Profile* section, the default value is *Color LCD*. >>>>>>>>>>> This causes a failure in some test cases which uses robot.The colour >>>>>>>>>>> configuration it expects to use is the *Generic RGB Profile*. >>>>>>>>>>> That is what ?Non-generic display settings? means. >>>>>>>>>> AFAIK there are instruction that tests should be executed using color >>>>>>>>>> profile with no color corrections on OS X. I guess there are many >>>>>>>>>> other >>>>>>>>>> tests that fail with color correction. >>>>>>>>>> If this is a root cause than the bug doesn't need to be fixed. >>>>>>>>> Well, I filed this bug and I used Generic RGB on all my >>>>>>>>> test machines. There may be additional precautions in the tests >>>>>>>>> about that but misconfiguration is not the root case here. >>>>>>>>> That said, I feel vary about attempts to guess Apple colors >>>>>>>> wary I mean >>>>>>>>> in non-generic profiles. >>>>>>> Yuri. Do you mean that the non-generic is not a root case? >>>>>> No: I had Generic RGB everywhere, and it failed for me. >>>>>> I should say that the new version of the test properly >>>>>> fails with b120 and pass with current PIT. And colors >>>>>> are visibly different in the two builds: so the test works OK now. >>>>> That contradicts with the description of the fix. >>>>> Probably the test does unnecessary care about the non-Generic profiles. >>>>> >>>>> 159 if (!foundMatch && isMac()) { >>>>> 160 //One more chance for Mac due to non-Generic >>>>> display setting >>>>> 161 detectedColor = new Color(img.getRGB(x, y), true); >>>>> 162 if (detectedColor.equals(colorCheck)) { >>>>> 163 foundMatch = true; >>>>> 164 break checkLoops; >>>>> 165 } >>>>> 166 } >>>>> >>>>> Does it mean that the code above, which is necessary to serve >>>>> non-Generic profiles on OS X, may be removed and the test still passes? >>>>> >>>>> --Semyon >>>>>> -yan >>>>>> >>>>>>> --Semyon >>>>>>>>> -yan >>>>>>>>> >>>>>>>>> >>>>>>>>>> --Semyon >>>>>>>>>>> Regarding ?Negative scenarios?, these include cases where >>>>>>>>>>> colours are >>>>>>>>>>> different from the expected background or foreground colors >>>>>>>>>>> is checked with the robot and BufferedImage respectively to >>>>>>>>>>> *eliminate >>>>>>>>>>> false positives due to coincidentally finding a match* by using >>>>>>>>>>> robot >>>>>>>>>>> or BufferedImage. >>>>>>>>>>> >>>>>>>>>>> Please find my changes appropriating the inputs provided. >>>>>>>>>>> I removed the variable foundMatch as I found that it is not required >>>>>>>>>>> at all and incorporated the suggestion to use return instead of a >>>>>>>>>>> labelled break. >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~aniyogi/8160438/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On 07-Jul-2016, at 6:30 pm, Semyon Sadetsky >>>>>>>>>>>> > >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Avik, >>>>>>>>>>>> >>>>>>>>>>>> could you clarify what is "Non-generic display settings"? Is it >>>>>>>>>>>> known >>>>>>>>>>>> bug on OS X? >>>>>>>>>>>> And also please be more specific on "negative scenarios" why >>>>>>>>>>>> they are >>>>>>>>>>>> necessary ? >>>>>>>>>>>> >>>>>>>>>>>> Also could you replace labeled break with "return foundMatch; " >>>>>>>>>>>> >>>>>>>>>>>> --Semyon >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 07.07.2016 15:11, Avik Niyogi wrote: >>>>>>>>>>>>> Hi All, >>>>>>>>>>>>> >>>>>>>>>>>>> Kindly review the fix for JDK9. >>>>>>>>>>>>> >>>>>>>>>>>>> *Bug: >>>>>>>>>>>>> *https://bugs.openjdk.java.net/browse/JDK-8160438 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> *Webrev: >>>>>>>>>>>>> *http://cr.openjdk.java.net/~aniyogi/8160438/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> *Issue: *test javax/swing/plaf/nimbus/8057791/bug8057791.java >>>>>>>>>>>>> consistently fails on OS X 10.10 >>>>>>>>>>>>> >>>>>>>>>>>>> *Cause: * Due to bug in detecting color for Non-generic display >>>>>>>>>>>>> settings for Mac hardware, test case failed >>>>>>>>>>>>> >>>>>>>>>>>>> *Fix: *Positive and negative scenarios was added to check the >>>>>>>>>>>>> colour >>>>>>>>>>>>> for the Nimbus LAF foreground and background colours. >>>>>>>>>>>>> >>>>>>>>>>>>> With Regards, >>>>>>>>>>>>> Avik Niyogi -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajeev.chamyal at oracle.com Thu Jul 14 07:08:27 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Thu, 14 Jul 2016 00:08:27 -0700 (PDT) Subject: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel In-Reply-To: <30e65d6d-cb35-4c55-b1b2-80752929576a@default> References: <340c1fa9-7da5-4fcb-9119-0e1e2dcaeb10@default> <9bd7ca3c-2297-0c36-c249-4a9b560275a2@oracle.com> <395e74b7-451e-453e-b552-be2a5bc0e348@default> <30e65d6d-cb35-4c55-b1b2-80752929576a@default> Message-ID: <3d266275-efcd-4d69-bfab-9604467856d1@default> Hello All, Gentle reminder. Please review the updated webrev. http://cr.openjdk.java.net/~rchamyal/8147648/webrev.02/ Update: simplified the test. Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 22 June 2016 15:46 To: Rajeev Chamyal; Sergey Bylokhov; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel The fix looks good to me. Thanks, Alexandr. On 6/22/2016 10:49 AM, Rajeev Chamyal wrote: Hello Alexandr, Thanks for the review. I have updated webrev as per comments. http://cr.openjdk.java.net/~rchamyal/8147648/webrev.01/ Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 21 June 2016 17:37 To: Rajeev Chamyal; Sergey Bylokhov; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel On 6/21/2016 12:16 PM, Rajeev Chamyal wrote: Hello All, Please review the following webrev. Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8147648/webrev.00/"http://cr.openjdk.java.net/~rchamyal/8147648/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8147648 Issue: Wrong resolution variant is used as icon in the Unity panel. Cause: The screen transforms are not applied to find the correct resolution variant image in current implementation. Fix: Applied the screen transforms to graphics object. 222 int scaleX = (int)tx.getScaleX(); 223 int scaleY = (int)tx.getScaleY(); 224 DataBufferInt buffer = new DataBufferInt(scaleX * width * scaleY * height); The fix is in the shared code and the scale factor can have floating point value on Windows. (for example 1.5). It is better to round the final width and height after scaling them. Thanks, Alexandr. Regards, Rajeev Chamyal -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Thu Jul 14 09:44:12 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 14 Jul 2016 09:44:12 +0000 Subject: [ping] RFR(L): 8160974: [TESTBUG] Mark more headful tests with @key headful. Message-ID: Hi, could someone please have a look at this? It's L, but the change is only one line in a lot of tests ... Thanks! Goetz. > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Donnerstag, 7. Juli 2016 17:01 > To: 'awt-dev at openjdk.java.net' ; swing- > dev at openjdk.java.net; '2d-dev' <2d-dev at openjdk.java.net> > Subject: RFR(L): 8160974: [TESTBUG] Mark more headful tests with @key headful. > > Hi, > > This change is 'L' because there are changes to a lot of files, but the changes > are all similar, so it's rather easy to review. > Similar to 8159690 I added @key headful to another around 600 tests. > I used different patterns to grep for the headful exceptions. > > These are now all I could find with grepping and the like. I have around > 80 failing tests remaining, where a row will probably also depend on > a display, but I want to look at them more closely, so I don't want > to include them here. > > Please review this change: > http://cr.openjdk.java.net/~goetz/wr16/8160974-headful/webrev.01/ > > Best regards, > Goetz. From rajeev.chamyal at oracle.com Thu Jul 14 10:18:26 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Thu, 14 Jul 2016 03:18:26 -0700 (PDT) Subject: Swing Dev>[9] Review Request JDK-8158918 setExtendedState(1) for maximized Frame results in state==7 Message-ID: Hello All, Please review the following webrev. Bug: https://bugs.openjdk.java.net/browse/JDK-8158918 Webrev: http://cr.openjdk.java.net/~rchamyal/8158918/webrev.00/ Issue: Frame setExtendedState = 1 on a maximized frame is not working. Cause: Issue is due to ::ShowWindow API call added as part of fix for HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8037575"JDK-8037575 Fix: Removed the ShowWindow call a sepate bug will be created for HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8037575"JDK-8037575 Regards, Rajeev Chamyal -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Thu Jul 14 11:28:07 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 14 Jul 2016 14:28:07 +0300 Subject: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel In-Reply-To: <3d266275-efcd-4d69-bfab-9604467856d1@default> References: <340c1fa9-7da5-4fcb-9119-0e1e2dcaeb10@default> <9bd7ca3c-2297-0c36-c249-4a9b560275a2@oracle.com> <395e74b7-451e-453e-b552-be2a5bc0e348@default> <30e65d6d-cb35-4c55-b1b2-80752929576a@default> <3d266275-efcd-4d69-bfab-9604467856d1@default> Message-ID: <57877747.3040904@oracle.com> Hi Rajeev, I have added 1px border to the icon in your test: private static BufferedImage generateImage(int scale, Color c) { int x = SZ * scale; BufferedImage img = new BufferedImage(x, x, BufferedImage.TYPE_INT_RGB); Graphics g = img.getGraphics(); if (g != null) { g.setColor(c); g.fillRect(0, 0, x, x); g.setColor(Color.YELLOW); g.drawRect(0, 0, x-1, x-1); } return img; } It seems the icon in the taskbar is not correct for UI scale > 1. By the way, graphics object should be disposed using g.dispose() when it is not needed anymore. --Semyon On 14.07.2016 10:08, Rajeev Chamyal wrote: > > Hello All, > > Gentle reminder. Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8147648/webrev.02/ > > > Update: simplified the test. > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 22 June 2016 15:46 > *To:* Rajeev Chamyal; Sergey Bylokhov; swing-dev at openjdk.java.net > > *Subject:* Re: [9] Review Request JDK-8147648 [hidpi] > multiresolution image: wrong resolution variant is used as icon in the > Unity panel > > The fix looks good to me. > > Thanks, > Alexandr. > > On 6/22/2016 10:49 AM, Rajeev Chamyal wrote: > > Hello Alexandr, > > Thanks for the review. I have updated webrev as per comments. > > http://cr.openjdk.java.net/~rchamyal/8147648/webrev.01/ > > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 21 June 2016 17:37 > *To:* Rajeev Chamyal; Sergey Bylokhov; swing-dev at openjdk.java.net > > *Subject:* Re: [9] Review Request JDK-8147648 [hidpi] > multiresolution image: wrong resolution variant is used as icon in > the Unity panel > > On 6/21/2016 12:16 PM, Rajeev Chamyal wrote: > > Hello All, > > Please review the following webrev. > > Webrev: > http://cr.openjdk.java.net/~rchamyal/8147648/webrev.00/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8147648 > > Issue: Wrong resolution variant is used as icon in the Unity > panel. > > Cause: The screen transforms are not applied to find the > correct resolution variant image in current implementation. > > Fix: Applied the screen transforms to graphics object. > > > 222 int scaleX = (int)tx.getScaleX(); > 223 int scaleY = (int)tx.getScaleY(); > 224 DataBufferInt buffer = new DataBufferInt(scaleX * > width * scaleY * height); > > The fix is in the shared code and the scale factor can have > floating point value on Windows. (for example 1.5). > It is better to round the final width and height after scaling them. > > Thanks, > Alexandr. > > Regards, > > Rajeev Chamyal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Thu Jul 14 15:16:25 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 14 Jul 2016 18:16:25 +0300 Subject: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails In-Reply-To: <45B95487-4728-464C-91B4-5B360955F963@oracle.com> References: <9B81739F-3482-4A16-8A12-735ACB060A6E@oracle.com> <577E5279.1020403@oracle.com> <577E6152.3000903@oracle.com> <577E68A5.80500@oracle.com> <577E6E07.2010302@oracle.com> <577E759C.6040805@oracle.com> <158f2094-1ec4-a3a0-17e9-a8038c24eed4@oracle.com> <9BC3920C-8311-44BE-B78E-56305112AA78@oracle.com> <577F864D.4080303@oracle.com> <1ACD9FE4-0D8C-4366-97E0-90C8B3595254@oracle.com> <6b1e1a5d-d4d3-87f7-d6a0-585c0d83d8f2@oracle.com> <45B95487-4728-464C-91B4-5B360955F963@oracle.com> Message-ID: <1c55a4fb-9c87-1716-8669-ca16906e959a@oracle.com> The fix looks good to me. Thanks, Alexandr. On 7/14/2016 9:53 AM, Avik Niyogi wrote: > Hi All, > Please find my webrev below for review which includes changes as > perceived from inputs provided. > > http://cr.openjdk.java.net/~aniyogi/8160438/webrev.02/ > > > With Regards, > Avik Niyogi >> On 12-Jul-2016, at 7:12 pm, Alexandr Scherbatiy >> > > wrote: >> >> On 7/12/2016 8:24 AM, Avik Niyogi wrote: >>> Hi All, >>> A gentle reminder, please review my code changes. >>> >>> With Regards, >>> Avik Niyogi >>> >>>> On 08-Jul-2016, at 4:24 pm, Yuri Nesterenko >>>> > wrote: >>>> >>>> It pass for me if I provide some time to process native events >>>> after the user activity simulation. For instance, >>>> setAutoDelay(50) for robot does that plus waitForIdle() >>>> after every mouseMove(). In this case, the part with that additional >>>> check and a (misleading, I think) comment about the color profiles >>>> may be removed. The test would take much more time though, and >>>> @run main/timeout=600 bug8057791 >>>> line would be necessary. >> Some more comments to the previous ones: >> - runColorTestCase() uses JList and should be run on EDT >> - "if (tryNimbusLookAndFeel()) {" It is supposed that the Nimbus L&F >> is supported on all platforms. May be it is better to fail the test >> if the Nimbus L&F is not set. >> - "if (osName.contains("Mac")) { isMac = true; }" can be simplified >> to "return osName.contains("Mac")" >> - " if (!"".equals(errorString)) {" can be simplified to >> !errorString.isEmpty() >> >> Thanks, >> Alexandr. >>>> >>>> Thanks, >>>> -yan >>>> >>>> On 07/08/2016 04:28 AM, Avik Niyogi wrote: >>>>> The test does not pass if mac specific check is not done for >>>>> backgroundcolor. >>>>> The check is required to get the same values from BufferedImage as >>>>> they >>>>> are the same as found with Digital Color Meter. >>>>> This test case fixes that. >>>>> Please provide inputs if this fix will get a +1 or if not any positive >>>>> inputs to modify the test case will be welcome. >>>>> >>>>> With Regards, >>>>> Avik Niyogi >>>>>> On 07-Jul-2016, at 9:51 pm, Semyon Sadetsky >>>>>> >>>>>> > wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 7/7/2016 6:30 PM, Yuri Nesterenko wrote: >>>>>>> On 07/07/2016 06:15 PM, Semyon Sadetsky wrote: >>>>>>>> >>>>>>>> On 7/7/2016 5:58 PM, Yuri Nesterenko wrote: >>>>>>>>> On 07/07/2016 05:35 PM, Yuri Nesterenko wrote: >>>>>>>>>> On 07/07/2016 05:04 PM, Semyon Sadetsky wrote: >>>>>>>>>>> >>>>>>>>>>> On 07.07.2016 16:35, Avik Niyogi wrote: >>>>>>>>>>>> Hi Semyon, >>>>>>>>>>>> >>>>>>>>>>>> Thank you for the review comment. >>>>>>>>>>>> >>>>>>>>>>>> In Mac OS X, *System Preferences > Displays > Colors > Display >>>>>>>>>>>> Profile* section, the default value is *Color LCD*. >>>>>>>>>>>> This causes a failure in some test cases which uses >>>>>>>>>>>> robot.The colour >>>>>>>>>>>> configuration it expects to use is the *Generic RGB Profile*. >>>>>>>>>>>> That is what ?Non-generic display settings? means. >>>>>>>>>>> AFAIK there are instruction that tests should be executed >>>>>>>>>>> using color >>>>>>>>>>> profile with no color corrections on OS X. I guess there are >>>>>>>>>>> many >>>>>>>>>>> other >>>>>>>>>>> tests that fail with color correction. >>>>>>>>>>> If this is a root cause than the bug doesn't need to be fixed. >>>>>>>>>> Well, I filed this bug and I used Generic RGB on all my >>>>>>>>>> test machines. There may be additional precautions in the tests >>>>>>>>>> about that but misconfiguration is not the root case here. >>>>>>>>>> That said, I feel vary about attempts to guess Apple colors >>>>>>>>> wary I mean >>>>>>>>>> in non-generic profiles. >>>>>>>> Yuri. Do you mean that the non-generic is not a root case? >>>>>>> No: I had Generic RGB everywhere, and it failed for me. >>>>>>> I should say that the new version of the test properly >>>>>>> fails with b120 and pass with current PIT. And colors >>>>>>> are visibly different in the two builds: so the test works OK now. >>>>>> That contradicts with the description of the fix. >>>>>> Probably the test does unnecessary care about the non-Generic >>>>>> profiles. >>>>>> >>>>>> 159 if (!foundMatch && isMac()) { >>>>>> 160 //One more chance for Mac due to non-Generic >>>>>> display setting >>>>>> 161 detectedColor = new Color(img.getRGB(x, >>>>>> y), true); >>>>>> 162 if (detectedColor.equals(colorCheck)) { >>>>>> 163 foundMatch = true; >>>>>> 164 break checkLoops; >>>>>> 165 } >>>>>> 166 } >>>>>> >>>>>> Does it mean that the code above, which is necessary to serve >>>>>> non-Generic profiles on OS X, may be removed and the test still >>>>>> passes? >>>>>> >>>>>> --Semyon >>>>>>> -yan >>>>>>> >>>>>>>> --Semyon >>>>>>>>>> -yan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> --Semyon >>>>>>>>>>>> Regarding ?Negative scenarios?, these include cases where >>>>>>>>>>>> colours are >>>>>>>>>>>> different from the expected background or foreground colors >>>>>>>>>>>> is checked with the robot and BufferedImage respectively to >>>>>>>>>>>> *eliminate >>>>>>>>>>>> false positives due to coincidentally finding a match* by using >>>>>>>>>>>> robot >>>>>>>>>>>> or BufferedImage. >>>>>>>>>>>> >>>>>>>>>>>> Please find my changes appropriating the inputs provided. >>>>>>>>>>>> I removed the variable foundMatch as I found that it is not >>>>>>>>>>>> required >>>>>>>>>>>> at all and incorporated the suggestion to use return >>>>>>>>>>>> instead of a >>>>>>>>>>>> labelled break. >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~aniyogi/8160438/webrev.01/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On 07-Jul-2016, at 6:30 pm, Semyon Sadetsky >>>>>>>>>>>>> >>>>>>>>>>>> > >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Avik, >>>>>>>>>>>>> >>>>>>>>>>>>> could you clarify what is "Non-generic display settings"? >>>>>>>>>>>>> Is it >>>>>>>>>>>>> known >>>>>>>>>>>>> bug on OS X? >>>>>>>>>>>>> And also please be more specific on "negative scenarios" why >>>>>>>>>>>>> they are >>>>>>>>>>>>> necessary ? >>>>>>>>>>>>> >>>>>>>>>>>>> Also could you replace labeled break with "return >>>>>>>>>>>>> foundMatch; " >>>>>>>>>>>>> >>>>>>>>>>>>> --Semyon >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 07.07.2016 15:11, Avik Niyogi wrote: >>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Kindly review the fix for JDK9. >>>>>>>>>>>>>> >>>>>>>>>>>>>> *Bug: >>>>>>>>>>>>>> *https://bugs.openjdk.java.net/browse/JDK-8160438 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> *Webrev: >>>>>>>>>>>>>> *http://cr.openjdk.java.net/~aniyogi/8160438/webrev.00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> *Issue: *test javax/swing/plaf/nimbus/8057791/bug8057791.java >>>>>>>>>>>>>> consistently fails on OS X 10.10 >>>>>>>>>>>>>> >>>>>>>>>>>>>> *Cause: * Due to bug in detecting color for Non-generic >>>>>>>>>>>>>> display >>>>>>>>>>>>>> settings for Mac hardware, test case failed >>>>>>>>>>>>>> >>>>>>>>>>>>>> *Fix: *Positive and negative scenarios was added to check the >>>>>>>>>>>>>> colour >>>>>>>>>>>>>> for the Nimbus LAF foreground and background colours. >>>>>>>>>>>>>> >>>>>>>>>>>>>> With Regards, >>>>>>>>>>>>>> Avik Niyogi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Thu Jul 14 15:24:24 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 14 Jul 2016 18:24:24 +0300 Subject: Swing Dev>[9] Review Request JDK-8158918 setExtendedState(1) for maximized Frame results in state==7 In-Reply-To: References: Message-ID: On 7/14/2016 1:18 PM, Rajeev Chamyal wrote: > > Hello All, > > Please review the following webrev. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8158918 > > Webrev: http://cr.openjdk.java.net/~rchamyal/8158918/webrev.00/ > > > Issue: Frame setExtendedState = 1 on a maximized frame is not working. > > Cause: Issue is due to ::ShowWindow API call added as part of fix for > JDK-8037575 > > Fix: Removed the ShowWindow call a sepate bug will be created for > JDK-8037575 > 40 if (frame.getExtendedState() != 1) { It is better to use the named frame state constant instead of just 1. Thanks, Alexandr. > > Regards, > > Rajeev Chamyal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Thu Jul 14 15:31:52 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 14 Jul 2016 18:31:52 +0300 Subject: [9] Review request for 8160054: The FileChooser didn't displayed large font with GTK LAF option. In-Reply-To: <0cf97edb-d403-ad74-6f1f-5b31ca77af48@oracle.com> References: <0cf97edb-d403-ad74-6f1f-5b31ca77af48@oracle.com> Message-ID: On 6/27/2016 9:23 PM, Semyon Sadetsky wrote: > Hello, > > Please review fix for JDK9: > > bug: https://bugs.openjdk.java.net/browse/JDK-8160054 > > webrev: http://cr.openjdk.java.net/~ssadetsky/8160054/webrev.00/ > > The root case is GTK LnF does not allow to change its default fonts. > > The proposed solution let's to use LnF font properties to change the > defaults. 292 if (propFont != null && !font.equals(propFont)) { 293 // if font property got different value then return it 294 return propFont; 295 } It looks like the !font.equals(propFont) condition is not necessary because when two fonts are equal it is right to return the propFont as well. Thanks, Alexandr. > > --Semyon > > From peter.brunet at oracle.com Fri Jul 15 01:39:32 2016 From: peter.brunet at oracle.com (Pete Brunet) Date: Thu, 14 Jul 2016 20:39:32 -0500 Subject: RfR JDK-8145207 [macosx] JList, VO can't access non-visible list items In-Reply-To: References: <359e3e73-72be-178e-f08a-6f5e81e4943d@oracle.com> Message-ID: <3d2ff435-4454-1b21-a201-c69a2ded581a@oracle.com> Hi Alexandr, Thanks very much for the review. I updated the webrev. See http://cr.openjdk.java.net/~ptbrunet/JDK-8145207/webrev.01/ >From your separate email you suggested the following in order to provide the AccessibleAction interface without changing the public API of JList.AccessibleJList.AccessibleJListChild: >Just create a private subclass of the AccessibleJListChild which implements AccessibleAction and return it in all places where new instance of the AccessibleJListChild is returned. I made that change. On 7/4/16 4:14 AM, Alexandr Scherbatiy wrote: > On 6/18/2016 5:31 AM, Pete Brunet wrote: >> Please review the following patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8145207 >> Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8145207/webrev.00/ >> >> This fixes the following functionality that was not working with the >> JList of ListDemo of SwingSet2. >> - start VoiceOver >> - start SwingSet2 >> - start the ListDemo >> - press Tab until focus is on the list, should hear VO when changing >> selections with up/down arrow >> - when interacting with list should hear that there are 30 (total) >> items, not 26 (visible) items >> - when using control+option+up/downarrow should be able to move to and >> select (control+option+spacebar) non-visible items past the 26th visible >> item >> - should be able to multi-select both visible and invisible items using >> control+option+command+return and VO should read the item just added >> - should be able to shift extend items with shift up or shift down arrow >> and VO should announce the item just added or removed > > CAccessibility: > 639 childrenAndRoles.clear(); > 640 childrenAndRoles.addAll(newArray); > > - Is it possible just to assign the newArray to the childrenAndRoles? > Is it necessary that the childrenAndRoles has final keyword? I made those changes. > - Please, format the code on lines 630-631 to romevo unnessary spaces > in round brackets. I prefer to keep the spaces in this kind of split line. Over the years I've found that style easier to read. > > CAccessible: > > - static method getActiveDescendant() is not used in the CAccessible > class but only in CAccessibility. Is it possible to move it to the > CAccessibility class? It's there because it accesses the private field, activeDescendant. > - Please, split the long lines. You may use static imports for constants. Done. > > JavaComponentAccessibility: > 716 if (returnValue == -1) { > 717 return NSNotFound; > 718 } else { > 719 return returnValue; > 720 } > > - This can be written shorter: return (returnValue == -1) ? > NSNotFound : returnValue; Done. > > 998 if ([self isSelectable:[ThreadUtilities getJNIEnv]]) { > 999 return YES; > 1000 } else { > 1001 return NO; > 1002 } > > - Is there a macros which can convert jboolean to BOOL? I could not find one. > - Could you also split the modified lines where it is possible? Done. Pete > > Thanks, > Alexandr. > >> >> Pete >> >> > From avik.niyogi at oracle.com Fri Jul 15 06:04:45 2016 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Fri, 15 Jul 2016 11:34:45 +0530 Subject: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails In-Reply-To: <1c55a4fb-9c87-1716-8669-ca16906e959a@oracle.com> References: <9B81739F-3482-4A16-8A12-735ACB060A6E@oracle.com> <577E5279.1020403@oracle.com> <577E6152.3000903@oracle.com> <577E68A5.80500@oracle.com> <577E6E07.2010302@oracle.com> <577E759C.6040805@oracle.com> <158f2094-1ec4-a3a0-17e9-a8038c24eed4@oracle.com> <9BC3920C-8311-44BE-B78E-56305112AA78@oracle.com> <577F864D.4080303@oracle.com> <1ACD9FE4-0D8C-4366-97E0-90C8B3595254@oracle.com> <6b1e1a5d-d4d3-87f7-d6a0-585c0d83d8f2@oracle.com> <45B95487-4728-464C-91B4-5B360955F963@oracle.com> <1c55a4fb-9c87-1716-8669-ca16906e959a@oracle.com> Message-ID: Another gentle reminder, please review my code changes. Thank you in advance. With Regards, Avik Niyogi > On 14-Jul-2016, at 8:46 pm, Alexandr Scherbatiy wrote: > > > The fix looks good to me. > > Thanks, > Alexandr. > > On 7/14/2016 9:53 AM, Avik Niyogi wrote: >> Hi All, >> Please find my webrev below for review which includes changes as perceived from inputs provided. >> >> http://cr.openjdk.java.net/~aniyogi/8160438/webrev.02/ >> >> With Regards, >> Avik Niyogi >>> On 12-Jul-2016, at 7:12 pm, Alexandr Scherbatiy > wrote: >>> >>> On 7/12/2016 8:24 AM, Avik Niyogi wrote: >>>> Hi All, >>>> A gentle reminder, please review my code changes. >>>> >>>> With Regards, >>>> Avik Niyogi >>>> >>>>> On 08-Jul-2016, at 4:24 pm, Yuri Nesterenko > wrote: >>>>> >>>>> It pass for me if I provide some time to process native events >>>>> after the user activity simulation. For instance, >>>>> setAutoDelay(50) for robot does that plus waitForIdle() >>>>> after every mouseMove(). In this case, the part with that additional >>>>> check and a (misleading, I think) comment about the color profiles >>>>> may be removed. The test would take much more time though, and >>>>> @run main/timeout=600 bug8057791 >>>>> line would be necessary. >>> Some more comments to the previous ones: >>> - runColorTestCase() uses JList and should be run on EDT >>> - "if (tryNimbusLookAndFeel()) {" It is supposed that the Nimbus L&F is supported on all platforms. May be it is better to fail the test if the Nimbus L&F is not set. >>> - "if (osName.contains("Mac")) { isMac = true; }" can be simplified to "return osName.contains("Mac")" >>> - " if (!"".equals(errorString)) {" can be simplified to !errorString.isEmpty() >>> >>> Thanks, >>> Alexandr. >>>>> >>>>> Thanks, >>>>> -yan >>>>> >>>>> On 07/08/2016 04:28 AM, Avik Niyogi wrote: >>>>>> The test does not pass if mac specific check is not done for >>>>>> backgroundcolor. >>>>>> The check is required to get the same values from BufferedImage as they >>>>>> are the same as found with Digital Color Meter. >>>>>> This test case fixes that. >>>>>> Please provide inputs if this fix will get a +1 or if not any positive >>>>>> inputs to modify the test case will be welcome. >>>>>> >>>>>> With Regards, >>>>>> Avik Niyogi >>>>>>> On 07-Jul-2016, at 9:51 pm, Semyon Sadetsky >>>>>>> >> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 7/7/2016 6:30 PM, Yuri Nesterenko wrote: >>>>>>>> On 07/07/2016 06:15 PM, Semyon Sadetsky wrote: >>>>>>>>> >>>>>>>>> On 7/7/2016 5:58 PM, Yuri Nesterenko wrote: >>>>>>>>>> On 07/07/2016 05:35 PM, Yuri Nesterenko wrote: >>>>>>>>>>> On 07/07/2016 05:04 PM, Semyon Sadetsky wrote: >>>>>>>>>>>> >>>>>>>>>>>> On 07.07.2016 16:35, Avik Niyogi wrote: >>>>>>>>>>>>> Hi Semyon, >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you for the review comment. >>>>>>>>>>>>> >>>>>>>>>>>>> In Mac OS X, *System Preferences > Displays > Colors > Display >>>>>>>>>>>>> Profile* section, the default value is *Color LCD*. >>>>>>>>>>>>> This causes a failure in some test cases which uses robot.The colour >>>>>>>>>>>>> configuration it expects to use is the *Generic RGB Profile*. >>>>>>>>>>>>> That is what ?Non-generic display settings? means. >>>>>>>>>>>> AFAIK there are instruction that tests should be executed using color >>>>>>>>>>>> profile with no color corrections on OS X. I guess there are many >>>>>>>>>>>> other >>>>>>>>>>>> tests that fail with color correction. >>>>>>>>>>>> If this is a root cause than the bug doesn't need to be fixed. >>>>>>>>>>> Well, I filed this bug and I used Generic RGB on all my >>>>>>>>>>> test machines. There may be additional precautions in the tests >>>>>>>>>>> about that but misconfiguration is not the root case here. >>>>>>>>>>> That said, I feel vary about attempts to guess Apple colors >>>>>>>>>> wary I mean >>>>>>>>>>> in non-generic profiles. >>>>>>>>> Yuri. Do you mean that the non-generic is not a root case? >>>>>>>> No: I had Generic RGB everywhere, and it failed for me. >>>>>>>> I should say that the new version of the test properly >>>>>>>> fails with b120 and pass with current PIT. And colors >>>>>>>> are visibly different in the two builds: so the test works OK now. >>>>>>> That contradicts with the description of the fix. >>>>>>> Probably the test does unnecessary care about the non-Generic profiles. >>>>>>> >>>>>>> 159 if (!foundMatch && isMac()) { >>>>>>> 160 //One more chance for Mac due to non-Generic >>>>>>> display setting >>>>>>> 161 detectedColor = new Color(img.getRGB(x, y), true); >>>>>>> 162 if (detectedColor.equals(colorCheck)) { >>>>>>> 163 foundMatch = true; >>>>>>> 164 break checkLoops; >>>>>>> 165 } >>>>>>> 166 } >>>>>>> >>>>>>> Does it mean that the code above, which is necessary to serve >>>>>>> non-Generic profiles on OS X, may be removed and the test still passes? >>>>>>> >>>>>>> --Semyon >>>>>>>> -yan >>>>>>>> >>>>>>>>> --Semyon >>>>>>>>>>> -yan >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> --Semyon >>>>>>>>>>>>> Regarding ?Negative scenarios?, these include cases where >>>>>>>>>>>>> colours are >>>>>>>>>>>>> different from the expected background or foreground colors >>>>>>>>>>>>> is checked with the robot and BufferedImage respectively to >>>>>>>>>>>>> *eliminate >>>>>>>>>>>>> false positives due to coincidentally finding a match* by using >>>>>>>>>>>>> robot >>>>>>>>>>>>> or BufferedImage. >>>>>>>>>>>>> >>>>>>>>>>>>> Please find my changes appropriating the inputs provided. >>>>>>>>>>>>> I removed the variable foundMatch as I found that it is not required >>>>>>>>>>>>> at all and incorporated the suggestion to use return instead of a >>>>>>>>>>>>> labelled break. >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~aniyogi/8160438/webrev.01/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On 07-Jul-2016, at 6:30 pm, Semyon Sadetsky >>>>>>>>>>>>>> > >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Avik, >>>>>>>>>>>>>> >>>>>>>>>>>>>> could you clarify what is "Non-generic display settings"? Is it >>>>>>>>>>>>>> known >>>>>>>>>>>>>> bug on OS X? >>>>>>>>>>>>>> And also please be more specific on "negative scenarios" why >>>>>>>>>>>>>> they are >>>>>>>>>>>>>> necessary ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Also could you replace labeled break with "return foundMatch; " >>>>>>>>>>>>>> >>>>>>>>>>>>>> --Semyon >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 07.07.2016 15:11, Avik Niyogi wrote: >>>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Kindly review the fix for JDK9. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Bug: >>>>>>>>>>>>>>> * https://bugs.openjdk.java.net/browse/JDK-8160438 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Webrev: >>>>>>>>>>>>>>> * http://cr.openjdk.java.net/~aniyogi/8160438/webrev.00/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Issue: *test javax/swing/plaf/nimbus/8057791/bug8057791.java >>>>>>>>>>>>>>> consistently fails on OS X 10.10 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Cause: * Due to bug in detecting color for Non-generic display >>>>>>>>>>>>>>> settings for Mac hardware, test case failed >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Fix: *Positive and negative scenarios was added to check the >>>>>>>>>>>>>>> colour >>>>>>>>>>>>>>> for the Nimbus LAF foreground and background colours. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> With Regards, >>>>>>>>>>>>>>> Avik Niyogi >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From avik.niyogi at oracle.com Fri Jul 15 06:10:39 2016 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Fri, 15 Jul 2016 11:40:39 +0530 Subject: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails In-Reply-To: <8F462C61-5401-4AB8-8D07-82853AB9C14C@oracle.com> References: <9B81739F-3482-4A16-8A12-735ACB060A6E@oracle.com> <577E5279.1020403@oracle.com> <577E6152.3000903@oracle.com> <577E68A5.80500@oracle.com> <577E6E07.2010302@oracle.com> <577E759C.6040805@oracle.com> <158f2094-1ec4-a3a0-17e9-a8038c24eed4@oracle.com> <9BC3920C-8311-44BE-B78E-56305112AA78@oracle.com> <577F864D.4080303@oracle.com> <1ACD9FE4-0D8C-4366-97E0-90C8B3595254@oracle.com> <6b1e1a5d-d4d3-87f7-d6a0-585c0d83d8f2@oracle.com> <45B95487-4728-464C-91B4-5B360955F963@oracle.com> <1c55a4fb-9c87-1716-8669-ca16906e959a@oracle.com> <8F462C61-5401-4AB8-8D07-82853AB9C14C@oracle.com> Message-ID: Hi Prasanta, Kindly request you to review the webrev raised with inputs taken from reviewers in the mail trail. Thank you in advance. With Regards, Avik Niyogi > On 15-Jul-2016, at 11:37 am, Avik Niyogi wrote: > > I will ask Prasanta to review since it is not a native code change. > >> On 15-Jul-2016, at 11:35 am, Praveen Srivastava > wrote: >> >> Rajeev is on sick leave, can someone else like Prasanta or Manajit review ? >> See if you can push it today.. >> >> Thanks >> Praveen >> >> >> From: Avik Niyogi >> Sent: Friday, July 15, 2016 11:35 AM >> To: Rajeev Chamyal >> Cc: Praveen Srivastava; swing-dev at openjdk.java.net >> Subject: Re: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails >> >> Another gentle reminder, please review my code changes. Thank you in advance. >> With Regards, >> Avik Niyogi >> On 14-Jul-2016, at 8:46 pm, Alexandr Scherbatiy > wrote: >> >> >> The fix looks good to me. >> >> Thanks, >> Alexandr. >> >> On 7/14/2016 9:53 AM, Avik Niyogi wrote: >> Hi All, >> Please find my webrev below for review which includes changes as perceived from inputs provided. >> >> http://cr.openjdk.java.net/~aniyogi/8160438/webrev.02/ >> >> With Regards, >> Avik Niyogi >> On 12-Jul-2016, at 7:12 pm, Alexandr Scherbatiy > wrote: >> >> On 7/12/2016 8:24 AM, Avik Niyogi wrote: >> >> Hi All, >> A gentle reminder, please review my code changes. >> >> With Regards, >> Avik Niyogi >> >> >> On 08-Jul-2016, at 4:24 pm, Yuri Nesterenko > wrote: >> >> It pass for me if I provide some time to process native events >> after the user activity simulation. For instance, >> setAutoDelay(50) for robot does that plus waitForIdle() >> after every mouseMove(). In this case, the part with that additional >> check and a (misleading, I think) comment about the color profiles >> may be removed. The test would take much more time though, and >> @run main/timeout=600 bug8057791 >> line would be necessary. >> Some more comments to the previous ones: >> - runColorTestCase() uses JList and should be run on EDT >> - "if (tryNimbusLookAndFeel()) {" It is supposed that the Nimbus L&F is supported on all platforms. May be it is better to fail the test if the Nimbus L&F is not set. >> - "if (osName.contains("Mac")) { isMac = true; }" can be simplified to "return osName.contains("Mac")" >> - " if (!"".equals(errorString)) {" can be simplified to !errorString.isEmpty() >> >> Thanks, >> Alexandr. >> >> >> Thanks, >> -yan >> >> On 07/08/2016 04:28 AM, Avik Niyogi wrote: >> >> The test does not pass if mac specific check is not done for >> backgroundcolor. >> The check is required to get the same values from BufferedImage as they >> are the same as found with Digital Color Meter. >> This test case fixes that. >> Please provide inputs if this fix will get a +1 or if not any positive >> inputs to modify the test case will be welcome. >> >> With Regards, >> Avik Niyogi >> >> On 07-Jul-2016, at 9:51 pm, Semyon Sadetsky >> >> wrote: >> >> >> >> On 7/7/2016 6:30 PM, Yuri Nesterenko wrote: >> >> On 07/07/2016 06:15 PM, Semyon Sadetsky wrote: >> >> >> On 7/7/2016 5:58 PM, Yuri Nesterenko wrote: >> >> On 07/07/2016 05:35 PM, Yuri Nesterenko wrote: >> >> On 07/07/2016 05:04 PM, Semyon Sadetsky wrote: >> >> >> On 07.07.2016 16:35, Avik Niyogi wrote: >> >> Hi Semyon, >> >> Thank you for the review comment. >> >> In Mac OS X, *System Preferences > Displays > Colors > Display >> Profile* section, the default value is *Color LCD*. >> This causes a failure in some test cases which uses robot.The colour >> configuration it expects to use is the *Generic RGB Profile*. >> That is what ?Non-generic display settings? means. >> AFAIK there are instruction that tests should be executed using color >> profile with no color corrections on OS X. I guess there are many >> other >> tests that fail with color correction. >> If this is a root cause than the bug doesn't need to be fixed. >> Well, I filed this bug and I used Generic RGB on all my >> test machines. There may be additional precautions in the tests >> about that but misconfiguration is not the root case here. >> That said, I feel vary about attempts to guess Apple colors >> wary I mean >> >> in non-generic profiles. >> Yuri. Do you mean that the non-generic is not a root case? >> No: I had Generic RGB everywhere, and it failed for me. >> I should say that the new version of the test properly >> fails with b120 and pass with current PIT. And colors >> are visibly different in the two builds: so the test works OK now. >> That contradicts with the description of the fix. >> Probably the test does unnecessary care about the non-Generic profiles. >> >> 159 if (!foundMatch && isMac()) { >> 160 //One more chance for Mac due to non-Generic >> display setting >> 161 detectedColor = new Color(img.getRGB(x, y), true); >> 162 if (detectedColor.equals(colorCheck)) { >> 163 foundMatch = true; >> 164 break checkLoops; >> 165 } >> 166 } >> >> Does it mean that the code above, which is necessary to serve >> non-Generic profiles on OS X, may be removed and the test still passes? >> >> --Semyon >> >> -yan >> >> >> --Semyon >> >> -yan >> >> >> >> --Semyon >> >> Regarding ?Negative scenarios?, these include cases where >> colours are >> different from the expected background or foreground colors >> is checked with the robot and BufferedImage respectively to >> *eliminate >> false positives due to coincidentally finding a match* by using >> robot >> or BufferedImage. >> >> Please find my changes appropriating the inputs provided. >> I removed the variable foundMatch as I found that it is not required >> at all and incorporated the suggestion to use return instead of a >> labelled break. >> >> http://cr.openjdk.java.net/~aniyogi/8160438/webrev.01/ >> >> >> >> >> On 07-Jul-2016, at 6:30 pm, Semyon Sadetsky >> > >> wrote: >> >> Hi Avik, >> >> could you clarify what is "Non-generic display settings"? Is it >> known >> bug on OS X? >> And also please be more specific on "negative scenarios" why >> they are >> necessary ? >> >> Also could you replace labeled break with "return foundMatch; " >> >> --Semyon >> >> >> On 07.07.2016 15:11, Avik Niyogi wrote: >> >> Hi All, >> >> Kindly review the fix for JDK9. >> >> *Bug: >> * https://bugs.openjdk.java.net/browse/JDK-8160438 >> >> >> >> *Webrev: >> * http://cr.openjdk.java.net/~aniyogi/8160438/webrev.00/ >> >> >> >> *Issue: *test javax/swing/plaf/nimbus/8057791/bug8057791.java >> consistently fails on OS X 10.10 >> >> *Cause: * Due to bug in detecting color for Non-generic display >> settings for Mac hardware, test case failed >> >> *Fix: *Positive and negative scenarios was added to check the >> colour >> for the Nimbus LAF foreground and background colours. >> >> With Regards, >> Avik Niyogi -------------- next part -------------- An HTML attachment was scrubbed... URL: From avik.niyogi at oracle.com Fri Jul 15 09:20:39 2016 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Fri, 15 Jul 2016 14:50:39 +0530 Subject: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails In-Reply-To: <1c55a4fb-9c87-1716-8669-ca16906e959a@oracle.com> References: <9B81739F-3482-4A16-8A12-735ACB060A6E@oracle.com> <577E5279.1020403@oracle.com> <577E6152.3000903@oracle.com> <577E68A5.80500@oracle.com> <577E6E07.2010302@oracle.com> <577E759C.6040805@oracle.com> <158f2094-1ec4-a3a0-17e9-a8038c24eed4@oracle.com> <9BC3920C-8311-44BE-B78E-56305112AA78@oracle.com> <577F864D.4080303@oracle.com> <1ACD9FE4-0D8C-4366-97E0-90C8B3595254@oracle.com> <6b1e1a5d-d4d3-87f7-d6a0-585c0d83d8f2@oracle.com> <45B95487-4728-464C-91B4-5B360955F963@oracle.com> <1c55a4fb-9c87-1716-8669-ca16906e959a@oracle.com> Message-ID: A gentle reminder, please review the changes > On 14-Jul-2016, at 8:46 pm, Alexandr Scherbatiy wrote: > > > The fix looks good to me. > > Thanks, > Alexandr. > > On 7/14/2016 9:53 AM, Avik Niyogi wrote: >> Hi All, >> Please find my webrev below for review which includes changes as perceived from inputs provided. >> >> http://cr.openjdk.java.net/~aniyogi/8160438/webrev.02/ >> >> With Regards, >> Avik Niyogi >>> On 12-Jul-2016, at 7:12 pm, Alexandr Scherbatiy > wrote: >>> >>> On 7/12/2016 8:24 AM, Avik Niyogi wrote: >>>> Hi All, >>>> A gentle reminder, please review my code changes. >>>> >>>> With Regards, >>>> Avik Niyogi >>>> >>>>> On 08-Jul-2016, at 4:24 pm, Yuri Nesterenko > wrote: >>>>> >>>>> It pass for me if I provide some time to process native events >>>>> after the user activity simulation. For instance, >>>>> setAutoDelay(50) for robot does that plus waitForIdle() >>>>> after every mouseMove(). In this case, the part with that additional >>>>> check and a (misleading, I think) comment about the color profiles >>>>> may be removed. The test would take much more time though, and >>>>> @run main/timeout=600 bug8057791 >>>>> line would be necessary. >>> Some more comments to the previous ones: >>> - runColorTestCase() uses JList and should be run on EDT >>> - "if (tryNimbusLookAndFeel()) {" It is supposed that the Nimbus L&F is supported on all platforms. May be it is better to fail the test if the Nimbus L&F is not set. >>> - "if (osName.contains("Mac")) { isMac = true; }" can be simplified to "return osName.contains("Mac")" >>> - " if (!"".equals(errorString)) {" can be simplified to !errorString.isEmpty() >>> >>> Thanks, >>> Alexandr. >>>>> >>>>> Thanks, >>>>> -yan >>>>> >>>>> On 07/08/2016 04:28 AM, Avik Niyogi wrote: >>>>>> The test does not pass if mac specific check is not done for >>>>>> backgroundcolor. >>>>>> The check is required to get the same values from BufferedImage as they >>>>>> are the same as found with Digital Color Meter. >>>>>> This test case fixes that. >>>>>> Please provide inputs if this fix will get a +1 or if not any positive >>>>>> inputs to modify the test case will be welcome. >>>>>> >>>>>> With Regards, >>>>>> Avik Niyogi >>>>>>> On 07-Jul-2016, at 9:51 pm, Semyon Sadetsky >>>>>>> >> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 7/7/2016 6:30 PM, Yuri Nesterenko wrote: >>>>>>>> On 07/07/2016 06:15 PM, Semyon Sadetsky wrote: >>>>>>>>> >>>>>>>>> On 7/7/2016 5:58 PM, Yuri Nesterenko wrote: >>>>>>>>>> On 07/07/2016 05:35 PM, Yuri Nesterenko wrote: >>>>>>>>>>> On 07/07/2016 05:04 PM, Semyon Sadetsky wrote: >>>>>>>>>>>> >>>>>>>>>>>> On 07.07.2016 16:35, Avik Niyogi wrote: >>>>>>>>>>>>> Hi Semyon, >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you for the review comment. >>>>>>>>>>>>> >>>>>>>>>>>>> In Mac OS X, *System Preferences > Displays > Colors > Display >>>>>>>>>>>>> Profile* section, the default value is *Color LCD*. >>>>>>>>>>>>> This causes a failure in some test cases which uses robot.The colour >>>>>>>>>>>>> configuration it expects to use is the *Generic RGB Profile*. >>>>>>>>>>>>> That is what ?Non-generic display settings? means. >>>>>>>>>>>> AFAIK there are instruction that tests should be executed using color >>>>>>>>>>>> profile with no color corrections on OS X. I guess there are many >>>>>>>>>>>> other >>>>>>>>>>>> tests that fail with color correction. >>>>>>>>>>>> If this is a root cause than the bug doesn't need to be fixed. >>>>>>>>>>> Well, I filed this bug and I used Generic RGB on all my >>>>>>>>>>> test machines. There may be additional precautions in the tests >>>>>>>>>>> about that but misconfiguration is not the root case here. >>>>>>>>>>> That said, I feel vary about attempts to guess Apple colors >>>>>>>>>> wary I mean >>>>>>>>>>> in non-generic profiles. >>>>>>>>> Yuri. Do you mean that the non-generic is not a root case? >>>>>>>> No: I had Generic RGB everywhere, and it failed for me. >>>>>>>> I should say that the new version of the test properly >>>>>>>> fails with b120 and pass with current PIT. And colors >>>>>>>> are visibly different in the two builds: so the test works OK now. >>>>>>> That contradicts with the description of the fix. >>>>>>> Probably the test does unnecessary care about the non-Generic profiles. >>>>>>> >>>>>>> 159 if (!foundMatch && isMac()) { >>>>>>> 160 //One more chance for Mac due to non-Generic >>>>>>> display setting >>>>>>> 161 detectedColor = new Color(img.getRGB(x, y), true); >>>>>>> 162 if (detectedColor.equals(colorCheck)) { >>>>>>> 163 foundMatch = true; >>>>>>> 164 break checkLoops; >>>>>>> 165 } >>>>>>> 166 } >>>>>>> >>>>>>> Does it mean that the code above, which is necessary to serve >>>>>>> non-Generic profiles on OS X, may be removed and the test still passes? >>>>>>> >>>>>>> --Semyon >>>>>>>> -yan >>>>>>>> >>>>>>>>> --Semyon >>>>>>>>>>> -yan >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> --Semyon >>>>>>>>>>>>> Regarding ?Negative scenarios?, these include cases where >>>>>>>>>>>>> colours are >>>>>>>>>>>>> different from the expected background or foreground colors >>>>>>>>>>>>> is checked with the robot and BufferedImage respectively to >>>>>>>>>>>>> *eliminate >>>>>>>>>>>>> false positives due to coincidentally finding a match* by using >>>>>>>>>>>>> robot >>>>>>>>>>>>> or BufferedImage. >>>>>>>>>>>>> >>>>>>>>>>>>> Please find my changes appropriating the inputs provided. >>>>>>>>>>>>> I removed the variable foundMatch as I found that it is not required >>>>>>>>>>>>> at all and incorporated the suggestion to use return instead of a >>>>>>>>>>>>> labelled break. >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~aniyogi/8160438/webrev.01/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On 07-Jul-2016, at 6:30 pm, Semyon Sadetsky >>>>>>>>>>>>>> > >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Avik, >>>>>>>>>>>>>> >>>>>>>>>>>>>> could you clarify what is "Non-generic display settings"? Is it >>>>>>>>>>>>>> known >>>>>>>>>>>>>> bug on OS X? >>>>>>>>>>>>>> And also please be more specific on "negative scenarios" why >>>>>>>>>>>>>> they are >>>>>>>>>>>>>> necessary ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Also could you replace labeled break with "return foundMatch; " >>>>>>>>>>>>>> >>>>>>>>>>>>>> --Semyon >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 07.07.2016 15:11, Avik Niyogi wrote: >>>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Kindly review the fix for JDK9. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Bug: >>>>>>>>>>>>>>> * https://bugs.openjdk.java.net/browse/JDK-8160438 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Webrev: >>>>>>>>>>>>>>> * http://cr.openjdk.java.net/~aniyogi/8160438/webrev.00/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Issue: *test javax/swing/plaf/nimbus/8057791/bug8057791.java >>>>>>>>>>>>>>> consistently fails on OS X 10.10 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Cause: * Due to bug in detecting color for Non-generic display >>>>>>>>>>>>>>> settings for Mac hardware, test case failed >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Fix: *Positive and negative scenarios was added to check the >>>>>>>>>>>>>>> colour >>>>>>>>>>>>>>> for the Nimbus LAF foreground and background colours. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> With Regards, >>>>>>>>>>>>>>> Avik Niyogi >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Fri Jul 15 13:42:18 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Fri, 15 Jul 2016 16:42:18 +0300 Subject: RfR JDK-8145207 [macosx] JList, VO can't access non-visible list items In-Reply-To: <3d2ff435-4454-1b21-a201-c69a2ded581a@oracle.com> References: <359e3e73-72be-178e-f08a-6f5e81e4943d@oracle.com> <3d2ff435-4454-1b21-a201-c69a2ded581a@oracle.com> Message-ID: <457d213e-8dc9-c724-6da4-43b43696f5c9@oracle.com> On 7/15/2016 4:39 AM, Pete Brunet wrote: > Hi Alexandr, Thanks very much for the review. I updated the webrev. See > http://cr.openjdk.java.net/~ptbrunet/JDK-8145207/webrev.01/ The fix looks good to me. > > From your separate email you suggested the following in order to provide > the AccessibleAction interface without changing the public API of > JList.AccessibleJList.AccessibleJListChild: > >> Just create a private subclass of the AccessibleJListChild which > implements AccessibleAction and return it in all places where new > instance of the AccessibleJListChild is returned. > > I made that change. You can create an enhancement that JList.AccessibleJListChild should implement AccessibleAction interface which can be fixed in JDK 9 only. Thanks, Alexandr. > > On 7/4/16 4:14 AM, Alexandr Scherbatiy wrote: >> On 6/18/2016 5:31 AM, Pete Brunet wrote: >>> Please review the following patch. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145207 >>> Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8145207/webrev.00/ >>> >>> This fixes the following functionality that was not working with the >>> JList of ListDemo of SwingSet2. >>> - start VoiceOver >>> - start SwingSet2 >>> - start the ListDemo >>> - press Tab until focus is on the list, should hear VO when changing >>> selections with up/down arrow >>> - when interacting with list should hear that there are 30 (total) >>> items, not 26 (visible) items >>> - when using control+option+up/downarrow should be able to move to and >>> select (control+option+spacebar) non-visible items past the 26th visible >>> item >>> - should be able to multi-select both visible and invisible items using >>> control+option+command+return and VO should read the item just added >>> - should be able to shift extend items with shift up or shift down arrow >>> and VO should announce the item just added or removed >> CAccessibility: >> 639 childrenAndRoles.clear(); >> 640 childrenAndRoles.addAll(newArray); >> >> - Is it possible just to assign the newArray to the childrenAndRoles? >> Is it necessary that the childrenAndRoles has final keyword? > I made those changes. >> - Please, format the code on lines 630-631 to romevo unnessary spaces >> in round brackets. > I prefer to keep the spaces in this kind of split line. Over the years > I've found that style easier to read. >> CAccessible: >> >> - static method getActiveDescendant() is not used in the CAccessible >> class but only in CAccessibility. Is it possible to move it to the >> CAccessibility class? > It's there because it accesses the private field, activeDescendant. >> - Please, split the long lines. You may use static imports for constants. > Done. >> JavaComponentAccessibility: >> 716 if (returnValue == -1) { >> 717 return NSNotFound; >> 718 } else { >> 719 return returnValue; >> 720 } >> >> - This can be written shorter: return (returnValue == -1) ? >> NSNotFound : returnValue; > Done. >> 998 if ([self isSelectable:[ThreadUtilities getJNIEnv]]) { >> 999 return YES; >> 1000 } else { >> 1001 return NO; >> 1002 } >> >> - Is there a macros which can convert jboolean to BOOL? > I could not find one. >> - Could you also split the modified lines where it is possible? > Done. > > Pete >> Thanks, >> Alexandr. >> >>> Pete >>> >>> From peter.brunet at oracle.com Fri Jul 15 14:24:56 2016 From: peter.brunet at oracle.com (Pete Brunet) Date: Fri, 15 Jul 2016 09:24:56 -0500 Subject: RfR JDK-8145207 [macosx] JList, VO can't access non-visible list items In-Reply-To: <457d213e-8dc9-c724-6da4-43b43696f5c9@oracle.com> References: <359e3e73-72be-178e-f08a-6f5e81e4943d@oracle.com> <3d2ff435-4454-1b21-a201-c69a2ded581a@oracle.com> <457d213e-8dc9-c724-6da4-43b43696f5c9@oracle.com> Message-ID: <055c5aa2-d1c6-aec9-6625-84ed1557ce89@oracle.com> On 7/15/16 8:42 AM, Alexandr Scherbatiy wrote: > On 7/15/2016 4:39 AM, Pete Brunet wrote: >> Hi Alexandr, Thanks very much for the review. I updated the webrev. >> See >> http://cr.openjdk.java.net/~ptbrunet/JDK-8145207/webrev.01/ > The fix looks good to me. Thank you Alexandr. Looking for one more +1. >> >> From your separate email you suggested the following in order to >> provide >> the AccessibleAction interface without changing the public API of >> JList.AccessibleJList.AccessibleJListChild: >> >>> Just create a private subclass of the AccessibleJListChild which >> implements AccessibleAction and return it in all places where new >> instance of the AccessibleJListChild is returned. >> >> I made that change. > You can create an enhancement that JList.AccessibleJListChild > should implement AccessibleAction interface which can be fixed in JDK > 9 only. Good Idea. I opened JDK-8161483. Not sure if an RFE will get into 9 at this point in time so that work might end up in 10. Pete > > Thanks, > Alexandr. >> >> On 7/4/16 4:14 AM, Alexandr Scherbatiy wrote: >>> On 6/18/2016 5:31 AM, Pete Brunet wrote: >>>> Please review the following patch. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145207 >>>> Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8145207/webrev.00/ >>>> >>>> This fixes the following functionality that was not working with the >>>> JList of ListDemo of SwingSet2. >>>> - start VoiceOver >>>> - start SwingSet2 >>>> - start the ListDemo >>>> - press Tab until focus is on the list, should hear VO when changing >>>> selections with up/down arrow >>>> - when interacting with list should hear that there are 30 (total) >>>> items, not 26 (visible) items >>>> - when using control+option+up/downarrow should be able to move to and >>>> select (control+option+spacebar) non-visible items past the 26th >>>> visible >>>> item >>>> - should be able to multi-select both visible and invisible items >>>> using >>>> control+option+command+return and VO should read the item just added >>>> - should be able to shift extend items with shift up or shift down >>>> arrow >>>> and VO should announce the item just added or removed >>> CAccessibility: >>> 639 childrenAndRoles.clear(); >>> 640 childrenAndRoles.addAll(newArray); >>> >>> - Is it possible just to assign the newArray to the childrenAndRoles? >>> Is it necessary that the childrenAndRoles has final keyword? >> I made those changes. >>> - Please, format the code on lines 630-631 to romevo unnessary spaces >>> in round brackets. >> I prefer to keep the spaces in this kind of split line. Over the years >> I've found that style easier to read. >>> CAccessible: >>> >>> - static method getActiveDescendant() is not used in the CAccessible >>> class but only in CAccessibility. Is it possible to move it to the >>> CAccessibility class? >> It's there because it accesses the private field, activeDescendant. >>> - Please, split the long lines. You may use static imports for >>> constants. >> Done. >>> JavaComponentAccessibility: >>> 716 if (returnValue == -1) { >>> 717 return NSNotFound; >>> 718 } else { >>> 719 return returnValue; >>> 720 } >>> >>> - This can be written shorter: return (returnValue == -1) ? >>> NSNotFound : returnValue; >> Done. >>> 998 if ([self isSelectable:[ThreadUtilities getJNIEnv]]) { >>> 999 return YES; >>> 1000 } else { >>> 1001 return NO; >>> 1002 } >>> >>> - Is there a macros which can convert jboolean to BOOL? >> I could not find one. >>> - Could you also split the modified lines where it is possible? >> Done. >> >> Pete >>> Thanks, >>> Alexandr. >>> >>>> Pete >>>> >>>> > From rajeev.chamyal at oracle.com Mon Jul 18 06:03:05 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Sun, 17 Jul 2016 23:03:05 -0700 (PDT) Subject: Swing Dev>[9] Review Request JDK-8158918 setExtendedState(1) for maximized Frame results in state==7 In-Reply-To: References: Message-ID: <94aabe00-9e3a-4aca-b5f3-d800cdbada34@default> Hello Alexandr, Please review the updated webrev. http://cr.openjdk.java.net/~rchamyal/8158918/webrev.01/ Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 14 July 2016 20:54 To: Rajeev Chamyal; Semyon Sadetsky; swing-dev at openjdk.java.net Subject: Re: Swing Dev>[9] Review Request JDK-8158918 setExtendedState(1) for maximized Frame results in state==7 On 7/14/2016 1:18 PM, Rajeev Chamyal wrote: Hello All, Please review the following webrev. Bug: https://bugs.openjdk.java.net/browse/JDK-8158918 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8158918/webrev.00/"http://cr.openjdk.java.net/~rchamyal/8158918/webrev.00/ Issue: Frame setExtendedState = 1 on a maximized frame is not working. Cause: Issue is due to ::ShowWindow API call added as part of fix for HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8037575"JDK-8037575 Fix: Removed the ShowWindow call a sepate bug will be created for HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8037575"JDK-8037575 40 if (frame.getExtendedState() != 1) { It is better to use the named frame state constant instead of just 1. Thanks, Alexandr. Regards, Rajeev Chamyal -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Mon Jul 18 08:46:44 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 18 Jul 2016 11:46:44 +0300 Subject: [9] Review request for 8160087: Change IOOBE to warning in the scenarios when it had not being thrown before the JDK-8078514 Message-ID: <19eeb5bb-18bc-85b2-7eaf-f16bfb6a0f9d@oracle.com> Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8160087 webrev: http://cr.openjdk.java.net/~ssadetsky/8160087/webrev.00/ A warning is added to avoid issues in user code to throw exceptions which were masked before. See bug descriptions for details. --Semyon From ajit.ghaisas at oracle.com Mon Jul 18 12:27:27 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Mon, 18 Jul 2016 05:27:27 -0700 (PDT) Subject: [9] Fix for JDK-7096375 : Swing ignores first click after decreasing system's time Message-ID: <459d9470-c5bf-44d5-bb57-c9ad3846a599@default> Hi, Bug : https://bugs.openjdk.java.net/browse/JDK-7096375 Swing ignores first click after decreasing system's time. Fix : BasicButtonListener keeps track of the last time when a button is pressed. This is used while discarding mouse press events to handle multiClickThreshold. The condition to discard mouse press event is corrected. Webrev : http://cr.openjdk.java.net/~aghaisas/7096375/webrev.00/ Request you to review. Regards, Ajit From philip.race at oracle.com Mon Jul 18 16:29:40 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 18 Jul 2016 09:29:40 -0700 Subject: [9] Review request for 7020860: BasicTreeUI contains getters/setters with unclear spec In-Reply-To: <8f30c1e8-f5bd-520b-0c12-f149e98cb3aa@oracle.com> References: <8f30c1e8-f5bd-520b-0c12-f149e98cb3aa@oracle.com> Message-ID: <578D03F4.1060509@oracle.com> /** - * Sets the {@code TreeCellRenderer} to {@code tcr}. This invokes - * {@code updateRenderer}. + * Called when the {@code cellRenderer} property is changed in + * the drawn tree component. * - * @param tcr the new value + * @param tcr the new value of the {@code cellRenderer} property */ protected void setCellRenderer(TreeCellRenderer tcr) { completeEditing(); @@ -468,10 +471,10 @@ } why did you remove the reference to updateRenderer() ? Was it wrong ? Also "Called when ... is changed" occurs a few times in this webrev .. but changed by what ? /** - * Returns the row height. + * Returns the height of each row in the drawn tree component. If the + * returned value is less than or equal to 0 the height for each row is + * determined by the renderer. * - * @return the row height + * @return the height of each row, in pixels */ protected int getRowHeight() { return (tree == null) ? -1 : tree.getRowHeight(); } Seems like it also returns -1 if there is no tree .. I don't see how the spec. words account for that. /** - * Returns {@code true} if the tree root is visible. + * Returns whether the root node of the drawn tree component is displayable. * - * @return {@code true} if the tree root is visible + * @return {@code true} if the root node of the tree is displayed */ protected boolean isRootVisible() { return (tree != null) ? tree.isRootVisible() : false; } The API says "visible". Why change to "displyable", which usually is reserved to mean whether something that has a native peer ? Maybe some clarification of what "visible" means is in order. -phil. On 06/21/2016 04:55 AM, Alexandr Scherbatiy wrote: > On 6/14/2016 5:37 PM, Semyon Sadetsky wrote: >> Hello, >> >> Please review fix for JDK9: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-7020860 >> >> webrev: http://cr.openjdk.java.net/~ssadetsky/7020860/webrev.00/ >> >> The methods mentioned in JIRA are not getters/setters according to >> JavaBeans specs, nevertheless some of them got wrong javadocs. The >> proposed fix improves the situation. > > I am not sure about the phrase "that is rendering each cell" in > > 474 * Returns the current instance of the {@link > TreeCellRenderer} that is > 475 * rendering each cell. > > Otherwise, the fix looks good to me. > > Thanks, > Alexandr. > > >> >> --Semyon >> > From semyon.sadetsky at oracle.com Mon Jul 18 17:37:10 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 18 Jul 2016 20:37:10 +0300 Subject: [9] Review request for 7020860: BasicTreeUI contains getters/setters with unclear spec In-Reply-To: <578D03F4.1060509@oracle.com> References: <8f30c1e8-f5bd-520b-0c12-f149e98cb3aa@oracle.com> <578D03F4.1060509@oracle.com> Message-ID: <3f433d5c-2ccc-ef36-c254-c75783c7f471@oracle.com> On 7/18/2016 7:29 PM, Phil Race wrote: > /** > - * Sets the {@code TreeCellRenderer} to {@code tcr}. This invokes > - * {@code updateRenderer}. > + * Called when the {@code cellRenderer} property is changed in > + * the drawn tree component. > * > - * @param tcr the new value > + * @param tcr the new value of the {@code cellRenderer} property > */ > protected void setCellRenderer(TreeCellRenderer tcr) { > completeEditing(); > @@ -468,10 +471,10 @@ > } > > why did you remove the reference to updateRenderer() ? Was it wrong ? I'm not sure that we want that level of the implementation details. Do you think the updateRenderer() call is more important than completeEditing() and updateSize() which called in the method as well? > Also "Called when ... is changed" occurs a few times in this webrev > .. but changed by what ? Is it incorrect phrase in English? The source of the change may be any user or internal code. Those methods update UI upon the change notification. > > > /** > - * Returns the row height. > + * Returns the height of each row in the drawn tree component. If > the > + * returned value is less than or equal to 0 the height for each > row is > + * determined by the renderer. > * > - * @return the row height > + * @return the height of each row, in pixels > */ > protected int getRowHeight() { > return (tree == null) ? -1 : tree.getRowHeight(); > } > > Seems like it also returns -1 if there is no tree .. I don't see how the > spec. words account for that. It seems this check is redundant and it was added to avoid questions about NPE. The tree field is null only if UI is not installed yet or is uninstalled already. So, getRowHeight() method does not need to be called if tree == null, but if called the value it returns doesn't have any sense. > > > /** > - * Returns {@code true} if the tree root is visible. > + * Returns whether the root node of the drawn tree component is > displayable. > * > - * @return {@code true} if the tree root is visible > + * @return {@code true} if the root node of the tree is displayed > */ > protected boolean isRootVisible() { > return (tree != null) ? tree.isRootVisible() : false; > } > > The API says "visible". Why change to "displyable", which usually is > reserved > to mean whether something that has a native peer ? > Maybe some clarification of what "visible" means is in order. O.k. I would use "displayed" because it simply proxies tree.isRootVisible() which has "displayed" in its specs. Returns whether the root node of the drawn tree component *should be displayed*. ? --Semyon > > -phil. > > > > On 06/21/2016 04:55 AM, Alexandr Scherbatiy wrote: >> On 6/14/2016 5:37 PM, Semyon Sadetsky wrote: >>> Hello, >>> >>> Please review fix for JDK9: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-7020860 >>> >>> webrev: http://cr.openjdk.java.net/~ssadetsky/7020860/webrev.00/ >>> >>> The methods mentioned in JIRA are not getters/setters according to >>> JavaBeans specs, nevertheless some of them got wrong javadocs. The >>> proposed fix improves the situation. >> >> I am not sure about the phrase "that is rendering each cell" in >> >> 474 * Returns the current instance of the {@link >> TreeCellRenderer} that is >> 475 * rendering each cell. >> >> Otherwise, the fix looks good to me. >> >> Thanks, >> Alexandr. >> >> >>> >>> --Semyon >>> >> > From peter.brunet at oracle.com Mon Jul 18 20:25:01 2016 From: peter.brunet at oracle.com (Pete Brunet) Date: Mon, 18 Jul 2016 15:25:01 -0500 Subject: RfR JDK-8145207 [macosx] JList, VO can't access non-visible list items In-Reply-To: <055c5aa2-d1c6-aec9-6625-84ed1557ce89@oracle.com> References: <359e3e73-72be-178e-f08a-6f5e81e4943d@oracle.com> <3d2ff435-4454-1b21-a201-c69a2ded581a@oracle.com> <457d213e-8dc9-c724-6da4-43b43696f5c9@oracle.com> <055c5aa2-d1c6-aec9-6625-84ed1557ce89@oracle.com> Message-ID: <7e7f479e-6236-b1ab-b51e-7736fbd13870@oracle.com> JPRT ran OK. On 7/15/16 9:24 AM, Pete Brunet wrote: > > On 7/15/16 8:42 AM, Alexandr Scherbatiy wrote: >> On 7/15/2016 4:39 AM, Pete Brunet wrote: >>> Hi Alexandr, Thanks very much for the review. I updated the webrev. >>> See >>> http://cr.openjdk.java.net/~ptbrunet/JDK-8145207/webrev.01/ >> The fix looks good to me. > Thank you Alexandr. > > Looking for one more +1. I forgot that Anton already has reviewed this. >>> From your separate email you suggested the following in order to >>> provide >>> the AccessibleAction interface without changing the public API of >>> JList.AccessibleJList.AccessibleJListChild: >>> >>>> Just create a private subclass of the AccessibleJListChild which >>> implements AccessibleAction and return it in all places where new >>> instance of the AccessibleJListChild is returned. >>> >>> I made that change. >> You can create an enhancement that JList.AccessibleJListChild >> should implement AccessibleAction interface which can be fixed in JDK >> 9 only. > Good Idea. I opened JDK-8161483. Not sure if an RFE will get into 9 at > this point in time so that work might end up in 10. > > Pete >> Thanks, >> Alexandr. >>> On 7/4/16 4:14 AM, Alexandr Scherbatiy wrote: >>>> On 6/18/2016 5:31 AM, Pete Brunet wrote: >>>>> Please review the following patch. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145207 >>>>> Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8145207/webrev.00/ >>>>> >>>>> This fixes the following functionality that was not working with the >>>>> JList of ListDemo of SwingSet2. >>>>> - start VoiceOver >>>>> - start SwingSet2 >>>>> - start the ListDemo >>>>> - press Tab until focus is on the list, should hear VO when changing >>>>> selections with up/down arrow >>>>> - when interacting with list should hear that there are 30 (total) >>>>> items, not 26 (visible) items >>>>> - when using control+option+up/downarrow should be able to move to and >>>>> select (control+option+spacebar) non-visible items past the 26th >>>>> visible >>>>> item >>>>> - should be able to multi-select both visible and invisible items >>>>> using >>>>> control+option+command+return and VO should read the item just added >>>>> - should be able to shift extend items with shift up or shift down >>>>> arrow >>>>> and VO should announce the item just added or removed >>>> CAccessibility: >>>> 639 childrenAndRoles.clear(); >>>> 640 childrenAndRoles.addAll(newArray); >>>> >>>> - Is it possible just to assign the newArray to the childrenAndRoles? >>>> Is it necessary that the childrenAndRoles has final keyword? >>> I made those changes. >>>> - Please, format the code on lines 630-631 to romevo unnessary spaces >>>> in round brackets. >>> I prefer to keep the spaces in this kind of split line. Over the years >>> I've found that style easier to read. >>>> CAccessible: >>>> >>>> - static method getActiveDescendant() is not used in the CAccessible >>>> class but only in CAccessibility. Is it possible to move it to the >>>> CAccessibility class? >>> It's there because it accesses the private field, activeDescendant. >>>> - Please, split the long lines. You may use static imports for >>>> constants. >>> Done. >>>> JavaComponentAccessibility: >>>> 716 if (returnValue == -1) { >>>> 717 return NSNotFound; >>>> 718 } else { >>>> 719 return returnValue; >>>> 720 } >>>> >>>> - This can be written shorter: return (returnValue == -1) ? >>>> NSNotFound : returnValue; >>> Done. >>>> 998 if ([self isSelectable:[ThreadUtilities getJNIEnv]]) { >>>> 999 return YES; >>>> 1000 } else { >>>> 1001 return NO; >>>> 1002 } >>>> >>>> - Is there a macros which can convert jboolean to BOOL? >>> I could not find one. >>>> - Could you also split the modified lines where it is possible? >>> Done. >>> >>> Pete >>>> Thanks, >>>> Alexandr. >>>> >>>>> Pete >>>>> >>>>> From peter.brunet at oracle.com Mon Jul 18 20:47:41 2016 From: peter.brunet at oracle.com (Pete Brunet) Date: Mon, 18 Jul 2016 15:47:41 -0500 Subject: RfR JDK-8145207 [macosx] JList, VO can't access non-visible list items In-Reply-To: <7e7f479e-6236-b1ab-b51e-7736fbd13870@oracle.com> References: <359e3e73-72be-178e-f08a-6f5e81e4943d@oracle.com> <3d2ff435-4454-1b21-a201-c69a2ded581a@oracle.com> <457d213e-8dc9-c724-6da4-43b43696f5c9@oracle.com> <055c5aa2-d1c6-aec9-6625-84ed1557ce89@oracle.com> <7e7f479e-6236-b1ab-b51e-7736fbd13870@oracle.com> Message-ID: <67791751-c400-492b-b280-a018967f58f3@oracle.com> Anton, If you'd like to check out the changeset I just pushed it. Pete On 7/18/16 3:25 PM, Pete Brunet wrote: > JPRT ran OK. > > On 7/15/16 9:24 AM, Pete Brunet wrote: >> On 7/15/16 8:42 AM, Alexandr Scherbatiy wrote: >>> On 7/15/2016 4:39 AM, Pete Brunet wrote: >>>> Hi Alexandr, Thanks very much for the review. I updated the webrev. >>>> See >>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8145207/webrev.01/ >>> The fix looks good to me. >> Thank you Alexandr. >> >> Looking for one more +1. > I forgot that Anton already has reviewed this. >>>> From your separate email you suggested the following in order to >>>> provide >>>> the AccessibleAction interface without changing the public API of >>>> JList.AccessibleJList.AccessibleJListChild: >>>> >>>>> Just create a private subclass of the AccessibleJListChild which >>>> implements AccessibleAction and return it in all places where new >>>> instance of the AccessibleJListChild is returned. >>>> >>>> I made that change. >>> You can create an enhancement that JList.AccessibleJListChild >>> should implement AccessibleAction interface which can be fixed in JDK >>> 9 only. >> Good Idea. I opened JDK-8161483. Not sure if an RFE will get into 9 at >> this point in time so that work might end up in 10. >> >> Pete >>> Thanks, >>> Alexandr. >>>> On 7/4/16 4:14 AM, Alexandr Scherbatiy wrote: >>>>> On 6/18/2016 5:31 AM, Pete Brunet wrote: >>>>>> Please review the following patch. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145207 >>>>>> Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8145207/webrev.00/ >>>>>> >>>>>> This fixes the following functionality that was not working with the >>>>>> JList of ListDemo of SwingSet2. >>>>>> - start VoiceOver >>>>>> - start SwingSet2 >>>>>> - start the ListDemo >>>>>> - press Tab until focus is on the list, should hear VO when changing >>>>>> selections with up/down arrow >>>>>> - when interacting with list should hear that there are 30 (total) >>>>>> items, not 26 (visible) items >>>>>> - when using control+option+up/downarrow should be able to move to and >>>>>> select (control+option+spacebar) non-visible items past the 26th >>>>>> visible >>>>>> item >>>>>> - should be able to multi-select both visible and invisible items >>>>>> using >>>>>> control+option+command+return and VO should read the item just added >>>>>> - should be able to shift extend items with shift up or shift down >>>>>> arrow >>>>>> and VO should announce the item just added or removed >>>>> CAccessibility: >>>>> 639 childrenAndRoles.clear(); >>>>> 640 childrenAndRoles.addAll(newArray); >>>>> >>>>> - Is it possible just to assign the newArray to the childrenAndRoles? >>>>> Is it necessary that the childrenAndRoles has final keyword? >>>> I made those changes. >>>>> - Please, format the code on lines 630-631 to romevo unnessary spaces >>>>> in round brackets. >>>> I prefer to keep the spaces in this kind of split line. Over the years >>>> I've found that style easier to read. >>>>> CAccessible: >>>>> >>>>> - static method getActiveDescendant() is not used in the CAccessible >>>>> class but only in CAccessibility. Is it possible to move it to the >>>>> CAccessibility class? >>>> It's there because it accesses the private field, activeDescendant. >>>>> - Please, split the long lines. You may use static imports for >>>>> constants. >>>> Done. >>>>> JavaComponentAccessibility: >>>>> 716 if (returnValue == -1) { >>>>> 717 return NSNotFound; >>>>> 718 } else { >>>>> 719 return returnValue; >>>>> 720 } >>>>> >>>>> - This can be written shorter: return (returnValue == -1) ? >>>>> NSNotFound : returnValue; >>>> Done. >>>>> 998 if ([self isSelectable:[ThreadUtilities getJNIEnv]]) { >>>>> 999 return YES; >>>>> 1000 } else { >>>>> 1001 return NO; >>>>> 1002 } >>>>> >>>>> - Is there a macros which can convert jboolean to BOOL? >>>> I could not find one. >>>>> - Could you also split the modified lines where it is possible? >>>> Done. >>>> >>>> Pete >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>>> Pete >>>>>> >>>>>> From peter.brunet at oracle.com Tue Jul 19 02:10:02 2016 From: peter.brunet at oracle.com (Pete Brunet) Date: Mon, 18 Jul 2016 21:10:02 -0500 Subject: RfR JDK-8161483 Implement AccessibleAction interface in JList.AccessibleJList.AccessibleJListChild Message-ID: Please review the following: Bug: https://bugs.openjdk.java.net/browse/JDK-8161483 Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8161483/webrev.00/ This is a followon to the patch for JDK-8145207 [macosx] JList, VO can't access non-visible list items In order to fixJDK-8145207the AccessibleAction interface was needed for JList.AccessibleJList.AccessibleJListChild but a backport of this fix has been requested and the released public API can not be changed in 8u or earlier. The workaround for JDK-8145207 is to create and use a private subclass of JList.AccessibleJList.AccessibleJListChild, JList.AccessibleJList.ActionableAccessibleJListChild. The downside of this fix is that it returns a subclass of the JList.AccessibleJList.AccessibleJListChild. If a user overrides the class and returns from its code it will not inherit the AccessibleAction behavior. For JDK 9 the ActionableAccessibleJListChild subclass should be removed and the AccessibleAction implementation moved to JList.AccessibleJList.AccessibleJListChild. TiA, Pete -------------- next part -------------- An HTML attachment was scrubbed... URL: From avik.niyogi at oracle.com Tue Jul 19 06:41:36 2016 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Tue, 19 Jul 2016 12:11:36 +0530 Subject: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails In-Reply-To: References: <9B81739F-3482-4A16-8A12-735ACB060A6E@oracle.com> <577E5279.1020403@oracle.com> <577E6152.3000903@oracle.com> <577E68A5.80500@oracle.com> <577E6E07.2010302@oracle.com> <577E759C.6040805@oracle.com> <158f2094-1ec4-a3a0-17e9-a8038c24eed4@oracle.com> <9BC3920C-8311-44BE-B78E-56305112AA78@oracle.com> <577F864D.4080303@oracle.com> <1ACD9FE4-0D8C-4366-97E0-90C8B3595254@oracle.com> <6b1e1a5d-d4d3-87f7-d6a0-585c0d83d8f2@oracle.com> <45B95487-4728-464C-91B4-5B360955F963@oracle.com> <1c55a4fb-9c87-1716-8669-ca16906e959a@oracle.com> Message-ID: <92F820BD-18D0-4F93-A81C-C2B59706CF1D@oracle.com> Hi All, Another gentle reminder. Please review the changes made. > On 15-Jul-2016, at 2:50 pm, Avik Niyogi wrote: > > A gentle reminder, please review the changes > >> On 14-Jul-2016, at 8:46 pm, Alexandr Scherbatiy > wrote: >> >> >> The fix looks good to me. >> >> Thanks, >> Alexandr. >> >> On 7/14/2016 9:53 AM, Avik Niyogi wrote: >>> Hi All, >>> Please find my webrev below for review which includes changes as perceived from inputs provided. >>> >>> http://cr.openjdk.java.net/~aniyogi/8160438/webrev.02/ >>> >>> With Regards, >>> Avik Niyogi >>>> On 12-Jul-2016, at 7:12 pm, Alexandr Scherbatiy > wrote: >>>> >>>> On 7/12/2016 8:24 AM, Avik Niyogi wrote: >>>>> Hi All, >>>>> A gentle reminder, please review my code changes. >>>>> >>>>> With Regards, >>>>> Avik Niyogi >>>>> >>>>>> On 08-Jul-2016, at 4:24 pm, Yuri Nesterenko > wrote: >>>>>> >>>>>> It pass for me if I provide some time to process native events >>>>>> after the user activity simulation. For instance, >>>>>> setAutoDelay(50) for robot does that plus waitForIdle() >>>>>> after every mouseMove(). In this case, the part with that additional >>>>>> check and a (misleading, I think) comment about the color profiles >>>>>> may be removed. The test would take much more time though, and >>>>>> @run main/timeout=600 bug8057791 >>>>>> line would be necessary. >>>> Some more comments to the previous ones: >>>> - runColorTestCase() uses JList and should be run on EDT >>>> - "if (tryNimbusLookAndFeel()) {" It is supposed that the Nimbus L&F is supported on all platforms. May be it is better to fail the test if the Nimbus L&F is not set. >>>> - "if (osName.contains("Mac")) { isMac = true; }" can be simplified to "return osName.contains("Mac")" >>>> - " if (!"".equals(errorString)) {" can be simplified to !errorString.isEmpty() >>>> >>>> Thanks, >>>> Alexandr. >>>>>> >>>>>> Thanks, >>>>>> -yan >>>>>> >>>>>> On 07/08/2016 04:28 AM, Avik Niyogi wrote: >>>>>>> The test does not pass if mac specific check is not done for >>>>>>> backgroundcolor. >>>>>>> The check is required to get the same values from BufferedImage as they >>>>>>> are the same as found with Digital Color Meter. >>>>>>> This test case fixes that. >>>>>>> Please provide inputs if this fix will get a +1 or if not any positive >>>>>>> inputs to modify the test case will be welcome. >>>>>>> >>>>>>> With Regards, >>>>>>> Avik Niyogi >>>>>>>> On 07-Jul-2016, at 9:51 pm, Semyon Sadetsky >>>>>>>> >> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 7/7/2016 6:30 PM, Yuri Nesterenko wrote: >>>>>>>>> On 07/07/2016 06:15 PM, Semyon Sadetsky wrote: >>>>>>>>>> >>>>>>>>>> On 7/7/2016 5:58 PM, Yuri Nesterenko wrote: >>>>>>>>>>> On 07/07/2016 05:35 PM, Yuri Nesterenko wrote: >>>>>>>>>>>> On 07/07/2016 05:04 PM, Semyon Sadetsky wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> On 07.07.2016 16:35, Avik Niyogi wrote: >>>>>>>>>>>>>> Hi Semyon, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thank you for the review comment. >>>>>>>>>>>>>> >>>>>>>>>>>>>> In Mac OS X, *System Preferences > Displays > Colors > Display >>>>>>>>>>>>>> Profile* section, the default value is *Color LCD*. >>>>>>>>>>>>>> This causes a failure in some test cases which uses robot.The colour >>>>>>>>>>>>>> configuration it expects to use is the *Generic RGB Profile*. >>>>>>>>>>>>>> That is what ?Non-generic display settings? means. >>>>>>>>>>>>> AFAIK there are instruction that tests should be executed using color >>>>>>>>>>>>> profile with no color corrections on OS X. I guess there are many >>>>>>>>>>>>> other >>>>>>>>>>>>> tests that fail with color correction. >>>>>>>>>>>>> If this is a root cause than the bug doesn't need to be fixed. >>>>>>>>>>>> Well, I filed this bug and I used Generic RGB on all my >>>>>>>>>>>> test machines. There may be additional precautions in the tests >>>>>>>>>>>> about that but misconfiguration is not the root case here. >>>>>>>>>>>> That said, I feel vary about attempts to guess Apple colors >>>>>>>>>>> wary I mean >>>>>>>>>>>> in non-generic profiles. >>>>>>>>>> Yuri. Do you mean that the non-generic is not a root case? >>>>>>>>> No: I had Generic RGB everywhere, and it failed for me. >>>>>>>>> I should say that the new version of the test properly >>>>>>>>> fails with b120 and pass with current PIT. And colors >>>>>>>>> are visibly different in the two builds: so the test works OK now. >>>>>>>> That contradicts with the description of the fix. >>>>>>>> Probably the test does unnecessary care about the non-Generic profiles. >>>>>>>> >>>>>>>> 159 if (!foundMatch && isMac()) { >>>>>>>> 160 //One more chance for Mac due to non-Generic >>>>>>>> display setting >>>>>>>> 161 detectedColor = new Color(img.getRGB(x, y), true); >>>>>>>> 162 if (detectedColor.equals(colorCheck)) { >>>>>>>> 163 foundMatch = true; >>>>>>>> 164 break checkLoops; >>>>>>>> 165 } >>>>>>>> 166 } >>>>>>>> >>>>>>>> Does it mean that the code above, which is necessary to serve >>>>>>>> non-Generic profiles on OS X, may be removed and the test still passes? >>>>>>>> >>>>>>>> --Semyon >>>>>>>>> -yan >>>>>>>>> >>>>>>>>>> --Semyon >>>>>>>>>>>> -yan >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> --Semyon >>>>>>>>>>>>>> Regarding ?Negative scenarios?, these include cases where >>>>>>>>>>>>>> colours are >>>>>>>>>>>>>> different from the expected background or foreground colors >>>>>>>>>>>>>> is checked with the robot and BufferedImage respectively to >>>>>>>>>>>>>> *eliminate >>>>>>>>>>>>>> false positives due to coincidentally finding a match* by using >>>>>>>>>>>>>> robot >>>>>>>>>>>>>> or BufferedImage. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please find my changes appropriating the inputs provided. >>>>>>>>>>>>>> I removed the variable foundMatch as I found that it is not required >>>>>>>>>>>>>> at all and incorporated the suggestion to use return instead of a >>>>>>>>>>>>>> labelled break. >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~aniyogi/8160438/webrev.01/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 07-Jul-2016, at 6:30 pm, Semyon Sadetsky >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Avik, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> could you clarify what is "Non-generic display settings"? Is it >>>>>>>>>>>>>>> known >>>>>>>>>>>>>>> bug on OS X? >>>>>>>>>>>>>>> And also please be more specific on "negative scenarios" why >>>>>>>>>>>>>>> they are >>>>>>>>>>>>>>> necessary ? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Also could you replace labeled break with "return foundMatch; " >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> --Semyon >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 07.07.2016 15:11, Avik Niyogi wrote: >>>>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Kindly review the fix for JDK9. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *Bug: >>>>>>>>>>>>>>>> * https://bugs.openjdk.java.net/browse/JDK-8160438 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *Webrev: >>>>>>>>>>>>>>>> * http://cr.openjdk.java.net/~aniyogi/8160438/webrev.00/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *Issue: *test javax/swing/plaf/nimbus/8057791/bug8057791.java >>>>>>>>>>>>>>>> consistently fails on OS X 10.10 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *Cause: * Due to bug in detecting color for Non-generic display >>>>>>>>>>>>>>>> settings for Mac hardware, test case failed >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *Fix: *Positive and negative scenarios was added to check the >>>>>>>>>>>>>>>> colour >>>>>>>>>>>>>>>> for the Nimbus LAF foreground and background colours. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> With Regards, >>>>>>>>>>>>>>>> Avik Niyogi >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From avik.niyogi at oracle.com Tue Jul 19 06:45:28 2016 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Tue, 19 Jul 2016 12:15:28 +0530 Subject: 8161470: [TEST_BUG] Failure javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java Message-ID: <948581F9-11FB-4664-A85C-570B3D239FE6@oracle.com> Hi All, Kindly review the fix for JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8161470 Webrev: http://cr.openjdk.java.net/~aniyogi/8161470/webrev.00/ Issue: This test consistently (12/12) fails on OS X 10.10 and also fails on Ubuntu 14.04. Cause: Due to quirk in robot.delay the UI was not getting appropriate behaviour response. Fix: Appropriate Robot methods were used to fix this. With Regards, Avik Niyogi -------------- next part -------------- An HTML attachment was scrubbed... URL: From avik.niyogi at oracle.com Tue Jul 19 07:03:16 2016 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Tue, 19 Jul 2016 12:33:16 +0530 Subject: 8161135: [TEST_BUG] swing not on EDT in closed/javax/swing/JComboBox/5100422/bug5100422.java Message-ID: <883658C5-328A-40FB-A1E3-98C61B7A2772@oracle.com> Hi All, Kindly review the fix for JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8161135 Webrev: http://cr.openjdk.java.net/~aniyogi/8161135/webrev.00/ Issue: This test does not do Swing manipulations on EDT and fails. Cause: Issue with Swing treads needed addressing Fix: waitForIdle and SwingUtilities were used to fix this test case. With Regards, Avik Niyogi -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajeev.chamyal at oracle.com Tue Jul 19 07:14:53 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Tue, 19 Jul 2016 00:14:53 -0700 (PDT) Subject: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails In-Reply-To: <92F820BD-18D0-4F93-A81C-C2B59706CF1D@oracle.com> References: <9B81739F-3482-4A16-8A12-735ACB060A6E@oracle.com> <577E5279.1020403@oracle.com> <577E6152.3000903@oracle.com> <577E68A5.80500@oracle.com> <577E6E07.2010302@oracle.com> <577E759C.6040805@oracle.com> <158f2094-1ec4-a3a0-17e9-a8038c24eed4@oracle.com> <9BC3920C-8311-44BE-B78E-56305112AA78@oracle.com> <577F864D.4080303@oracle.com> <1ACD9FE4-0D8C-4366-97E0-90C8B3595254@oracle.com> <6b1e1a5d-d4d3-87f7-d6a0-585c0d83d8f2@oracle.com> <45B95487-4728-464C-91B4-5B360955F963@oracle.com> <1c55a4fb-9c87-1716-8669-ca16906e959a@oracle.com> <92F820BD-18D0-4F93-A81C-C2B59706CF1D@oracle.com> Message-ID: <4e75e7a3-47cc-4a97-9980-208819ff8fb5@default> Looks good to me. Regards, Rajeev Chamyal From: Avik Niyogi Sent: 19 July 2016 12:12 To: Alexandr Scherbatiy Cc: Rajeev Chamyal; Semyon Sadetsky; Yuri Nesterenko; swing-dev at openjdk.java.net Subject: Re: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails Hi All, Another gentle reminder. Please review the changes made. On 15-Jul-2016, at 2:50 pm, Avik Niyogi wrote: A gentle reminder, please review the changes On 14-Jul-2016, at 8:46 pm, Alexandr Scherbatiy wrote: The fix looks good to me. Thanks, Alexandr. On 7/14/2016 9:53 AM, Avik Niyogi wrote: Hi All, Please find my webrev below for review which includes changes as perceived from inputs provided. HYPERLINK "http://cr.openjdk.java.net/%7Eaniyogi/8160438/webrev.02/"http://cr.openjdk.java.net/~aniyogi/8160438/webrev.02/ With Regards, Avik Niyogi On 12-Jul-2016, at 7:12 pm, Alexandr Scherbatiy wrote: On 7/12/2016 8:24 AM, Avik Niyogi wrote: Hi All, A gentle reminder, please review my code changes. With Regards, Avik Niyogi On 08-Jul-2016, at 4:24 pm, Yuri Nesterenko wrote: It pass for me if I provide some time to process native events after the user activity simulation. For instance, setAutoDelay(50) for robot does that plus waitForIdle() after every mouseMove(). In this case, the part with that additional check and a (misleading, I think) comment about the color profiles may be removed. The test would take much more time though, and @run main/timeout=600 bug8057791 line would be necessary. Some more comments to the previous ones: - runColorTestCase() uses JList and should be run on EDT - "if (tryNimbusLookAndFeel()) {" It is supposed that the Nimbus L&F is supported on all platforms. May be it is better to fail the test if the Nimbus L&F is not set. - "if (osName.contains("Mac")) { isMac = true; }" can be simplified to "return osName.contains("Mac")" - " if (!"".equals(errorString)) {" can be simplified to !errorString.isEmpty() Thanks, Alexandr. Thanks, -yan On 07/08/2016 04:28 AM, Avik Niyogi wrote: The test does not pass if mac specific check is not done for backgroundcolor. The check is required to get the same values from BufferedImage as they are the same as found with Digital Color Meter. This test case fixes that. Please provide inputs if this fix will get a +1 or if not any positive inputs to modify the test case will be welcome. With Regards, Avik Niyogi On 07-Jul-2016, at 9:51 pm, Semyon Sadetsky > wrote: On 7/7/2016 6:30 PM, Yuri Nesterenko wrote: On 07/07/2016 06:15 PM, Semyon Sadetsky wrote: On 7/7/2016 5:58 PM, Yuri Nesterenko wrote: On 07/07/2016 05:35 PM, Yuri Nesterenko wrote: On 07/07/2016 05:04 PM, Semyon Sadetsky wrote: On 07.07.2016 16:35, Avik Niyogi wrote: Hi Semyon, Thank you for the review comment. In Mac OS X, *System Preferences > Displays > Colors > Display Profile* section, the default value is *Color LCD*. This causes a failure in some test cases which uses robot.The colour configuration it expects to use is the *Generic RGB Profile*. That is what "Non-generic display settings" means. AFAIK there are instruction that tests should be executed using color profile with no color corrections on OS X. I guess there are many other tests that fail with color correction. If this is a root cause than the bug doesn't need to be fixed. Well, I filed this bug and I used Generic RGB on all my test machines. There may be additional precautions in the tests about that but misconfiguration is not the root case here. That said, I feel vary about attempts to guess Apple colors wary I mean in non-generic profiles. Yuri. Do you mean that the non-generic is not a root case? No: I had Generic RGB everywhere, and it failed for me. I should say that the new version of the test properly fails with b120 and pass with current PIT. And colors are visibly different in the two builds: so the test works OK now. That contradicts with the description of the fix. Probably the test does unnecessary care about the non-Generic profiles. 159 if (!foundMatch && isMac()) { 160 //One more chance for Mac due to non-Generic display setting 161 detectedColor = new Color(img.getRGB(x, y), true); 162 if (detectedColor.equals(colorCheck)) { 163 foundMatch = true; 164 break checkLoops; 165 } 166 } Does it mean that the code above, which is necessary to serve non-Generic profiles on OS X, may be removed and the test still passes? --Semyon -yan --Semyon -yan --Semyon Regarding "Negative scenarios", these include cases where colours are different from the expected background or foreground colors is checked with the robot and BufferedImage respectively to *eliminate false positives due to coincidentally finding a match* by using robot or BufferedImage. Please find my changes appropriating the inputs provided. I removed the variable foundMatch as I found that it is not required at all and incorporated the suggestion to use return instead of a labelled break. HYPERLINK "http://cr.openjdk.java.net/%7Eaniyogi/8160438/webrev.01/"http://cr.openjdk.java.net/~aniyogi/8160438/webrev.01/ HYPERLINK "http://cr.openjdk.java.net/%7Eaniyogi/8160438/webrev.01/" On 07-Jul-2016, at 6:30 pm, Semyon Sadetsky > wrote: Hi Avik, could you clarify what is "Non-generic display settings"? Is it known bug on OS X? And also please be more specific on "negative scenarios" why they are necessary ? Also could you replace labeled break with "return foundMatch; " --Semyon On 07.07.2016 15:11, Avik Niyogi wrote: Hi All, Kindly review the fix for JDK9. *Bug: *HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8160438"https://bugs.openjdk.java.net/browse/JDK-8160438 *Webrev: *HYPERLINK "http://cr.openjdk.java.net/%7Eaniyogi/8160438/webrev.00/"http://cr.openjdk.java.net/~aniyogi/8160438/webrev.00/ *Issue: *test javax/swing/plaf/nimbus/8057791/bug8057791.java consistently fails on OS X 10.10 *Cause: * Due to bug in detecting color for Non-generic display settings for Mac hardware, test case failed *Fix: *Positive and negative scenarios was added to check the colour for the Nimbus LAF foreground and background colours. With Regards, Avik Niyogi -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue Jul 19 08:01:53 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 19 Jul 2016 11:01:53 +0300 Subject: 8161470: [TEST_BUG] Failure javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java In-Reply-To: <948581F9-11FB-4664-A85C-570B3D239FE6@oracle.com> References: <948581F9-11FB-4664-A85C-570B3D239FE6@oracle.com> Message-ID: <4e122507-0132-4c7a-0fc8-270f17cc9a07@oracle.com> The fix looks good to me. Thanks, Alexandr. On 7/19/2016 9:45 AM, Avik Niyogi wrote: > Hi All, > > Kindly review the fix for JDK9. > > *Bug: https://bugs.openjdk.java.net/browse/JDK-8161470* > > *Webrev: http://cr.openjdk.java.net/~aniyogi/8161470/webrev.00/ > * > > *Issue: *This test consistently (12/12) fails on OS X 10.10 and also > fails on Ubuntu 14.04. > > *Cause: * Due to quirk in robot.delay the UI was not getting > appropriate behaviour response. > > *Fix:* Appropriate Robot methods were used to fix this. > > With Regards, > Avik Niyogi -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue Jul 19 08:17:29 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 19 Jul 2016 11:17:29 +0300 Subject: RfR JDK-8161483 Implement AccessibleAction interface in JList.AccessibleJList.AccessibleJListChild In-Reply-To: References: Message-ID: <7a429ccd-f0d0-f403-08f0-bb42a1953a4b@oracle.com> The fix looks good to me. Thanks, Alexandr. On 7/19/2016 5:10 AM, Pete Brunet wrote: > Please review the following: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8161483 > Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8161483/webrev.00/ > > This is a followon to the patch for > JDK-8145207 [macosx] JList, VO can't access non-visible list items > > In order to fixJDK-8145207the AccessibleAction interface was needed > for JList.AccessibleJList.AccessibleJListChild but a backport of this > fix has been requested and the released public API can not be changed > in 8u or earlier. The workaround for JDK-8145207 is to create and use > a private subclass of JList.AccessibleJList.AccessibleJListChild, > JList.AccessibleJList.ActionableAccessibleJListChild. The downside of > this fix is that it returns a subclass of the > JList.AccessibleJList.AccessibleJListChild. If a user overrides the > class and returns from its code it will not inherit the > AccessibleAction behavior. For JDK 9 the > ActionableAccessibleJListChild subclass should be removed and the > AccessibleAction implementation moved to > JList.AccessibleJList.AccessibleJListChild. > > TiA, > Pete -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue Jul 19 09:03:08 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 19 Jul 2016 12:03:08 +0300 Subject: [9] Fix for JDK-7096375 : Swing ignores first click after decreasing system's time In-Reply-To: <459d9470-c5bf-44d5-bb57-c9ad3846a599@default> References: <459d9470-c5bf-44d5-bb57-c9ad3846a599@default> Message-ID: On 7/18/2016 3:27 PM, Ajit Ghaisas wrote: > Hi, > > Bug : > https://bugs.openjdk.java.net/browse/JDK-7096375 > Swing ignores first click after decreasing system's time. > > Fix : > BasicButtonListener keeps track of the last time when a button is pressed. > This is used while discarding mouse press events to handle multiClickThreshold. > The condition to discard mouse press event is corrected. > > Webrev : > http://cr.openjdk.java.net/~aghaisas/7096375/webrev.00/ > > Request you to review. The template used for the test is rather old. It is better to use CountDownLatch for the manual test synchronization. Could you rewrite the test using the TitledBorderTest as a sample: http://hg.openjdk.java.net/jdk9/client/jdk/file/233b59b7ea2f/test/javax/swing/LookAndFeel/6439354/TitledBorderTest.java There can be added two simple changes. The thread creation is not necessary because the runnable can be directly executed by SwingUtilities.invokeAndWait(). The timeout can be added to the latch.await() call. Thanks, Alexandr. > > Regards, > Ajit From alexandr.scherbatiy at oracle.com Tue Jul 19 09:18:57 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 19 Jul 2016 12:18:57 +0300 Subject: [9] Review request for 8160087: Change IOOBE to warning in the scenarios when it had not being thrown before the JDK-8078514 In-Reply-To: <19eeb5bb-18bc-85b2-7eaf-f16bfb6a0f9d@oracle.com> References: <19eeb5bb-18bc-85b2-7eaf-f16bfb6a0f9d@oracle.com> Message-ID: <4bcb6a4a-030c-fea5-30d5-33ec1c0ff2c1@oracle.com> On 7/18/2016 11:46 AM, Semyon Sadetsky wrote: > Hello, > > Please review fix for JDK9: > > bug: https://bugs.openjdk.java.net/browse/JDK-8160087 > > webrev: http://cr.openjdk.java.net/~ssadetsky/8160087/webrev.00/ > > A warning is added to avoid issues in user code to throw exceptions > which were masked before. See bug descriptions for details. Should this behavior (which exists for long time) be specified in the DefaultRowSorter.convertRowIndexToView()/convertRowIndexToModel() javadoc? Thanks, Alexandr. > > --Semyon > From robin.stevens at scz.be Tue Jul 19 09:27:32 2016 From: robin.stevens at scz.be (Robin Stevens) Date: Tue, 19 Jul 2016 11:27:32 +0200 Subject: Input needed: JDK-8161664: Memory leak in com.apple.laf.AquaProgressBarUI: removed progress bar still referenced Message-ID: Hello, I wanted to discuss my approach for issue JDK-8161664 ( https://bugs.openjdk.java.net/browse/JDK-8161664) before I started working on this issue. In certain scenarios (see the JIRA issue for an example), the Timer in the Animator inner class of the AquaProgressBarUI class remains running, even when the JProgressBar has already been removed from the UI. This causes a memory leak, as that running Timer avoids that the JProgressBar can be GC-ed. As long as the Timer is running, the JProgressBar is referenced through Timer -> ActionListener (=Animator inner class) -> AquaProgressBarUI outer class -> JProgressBar field I see two possible approaches to fix this: 1) I carefully investigate the particular scenario I found, and try to figure out why the Timer is not stopped and fix this particular scenario. This offers of course no guarantees that there are no other scenarios which keep the Timer running. 2) I replace one of the hard references with a weak reference, hence avoiding the memory leak in all cases. If I do not attach the Animator inner class directly as listener to the timer, but use another ActionListener which only has a WeakReference to the Animator class, the memory leak is solved. The ActionListener could then stop the timer when the timer is fired and the WeakReference#get returns null. I prefer the second approach. By cutting the hard reference between the Timer and the Animator + stopping the Timer when the Animator is GC-ed, I ensure that the Timer cannot cause a memory leak anymore. This avoids overlooking certain scenarios. Any input on this ? Any preferences for a certain approach, or proposal for another approach. Robin -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Tue Jul 19 09:30:40 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 19 Jul 2016 12:30:40 +0300 Subject: [9] Review request for 8160087: Change IOOBE to warning in the scenarios when it had not being thrown before the JDK-8078514 In-Reply-To: <4bcb6a4a-030c-fea5-30d5-33ec1c0ff2c1@oracle.com> References: <19eeb5bb-18bc-85b2-7eaf-f16bfb6a0f9d@oracle.com> <4bcb6a4a-030c-fea5-30d5-33ec1c0ff2c1@oracle.com> Message-ID: <578DF340.8060204@oracle.com> On 19.07.2016 12:18, Alexandr Scherbatiy wrote: > On 7/18/2016 11:46 AM, Semyon Sadetsky wrote: >> Hello, >> >> Please review fix for JDK9: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8160087 >> >> webrev: http://cr.openjdk.java.net/~ssadetsky/8160087/webrev.00/ >> >> A warning is added to avoid issues in user code to throw exceptions >> which were masked before. See bug descriptions for details. > Should this behavior (which exists for long time) be specified in > the DefaultRowSorter.convertRowIndexToView()/convertRowIndexToModel() > javadoc? This was not a DefaultRowSorter.convertRowIndexToView()/convertRowIndexToModel() issue. It was a mistake in the FilePane class. RowSorter's javadoc mentions the correct way to use it: The view invokes a model change method when the underlying model has changed. There may be order dependencies in how the events are delivered, so a RowSorter should not update its mapping until one of these methods is invoked. --Semyon > > Thanks, > Alexandr. >> >> --Semyon >> > From anton.tarasov at jetbrains.com Tue Jul 19 09:58:27 2016 From: anton.tarasov at jetbrains.com (Anton Tarasov) Date: Tue, 19 Jul 2016 12:58:27 +0300 Subject: RfR JDK-8145207 [macosx] JList, VO can't access non-visible list items In-Reply-To: <67791751-c400-492b-b280-a018967f58f3@oracle.com> References: <359e3e73-72be-178e-f08a-6f5e81e4943d@oracle.com> <3d2ff435-4454-1b21-a201-c69a2ded581a@oracle.com> <457d213e-8dc9-c724-6da4-43b43696f5c9@oracle.com> <055c5aa2-d1c6-aec9-6625-84ed1557ce89@oracle.com> <7e7f479e-6236-b1ab-b51e-7736fbd13870@oracle.com> <67791751-c400-492b-b280-a018967f58f3@oracle.com> Message-ID: <69152837-1cd5-85bb-9be8-75aa643b6eb1@jetbrains.com> Thanks, Pete! Keeping an eye on JDK-8160893 status as well, as we discussed. Regards, Anton. On 7/18/2016 11:47 PM, Pete Brunet wrote: > Anton, If you'd like to check out the changeset I just pushed it. > > Pete > > On 7/18/16 3:25 PM, Pete Brunet wrote: >> JPRT ran OK. >> >> On 7/15/16 9:24 AM, Pete Brunet wrote: >>> On 7/15/16 8:42 AM, Alexandr Scherbatiy wrote: >>>> On 7/15/2016 4:39 AM, Pete Brunet wrote: >>>>> Hi Alexandr, Thanks very much for the review. I updated the webrev. >>>>> See >>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8145207/webrev.01/ >>>> The fix looks good to me. >>> Thank you Alexandr. >>> >>> Looking for one more +1. >> I forgot that Anton already has reviewed this. >>>>> From your separate email you suggested the following in order to >>>>> provide >>>>> the AccessibleAction interface without changing the public API of >>>>> JList.AccessibleJList.AccessibleJListChild: >>>>> >>>>>> Just create a private subclass of the AccessibleJListChild which >>>>> implements AccessibleAction and return it in all places where new >>>>> instance of the AccessibleJListChild is returned. >>>>> >>>>> I made that change. >>>> You can create an enhancement that JList.AccessibleJListChild >>>> should implement AccessibleAction interface which can be fixed in JDK >>>> 9 only. >>> Good Idea. I opened JDK-8161483. Not sure if an RFE will get into 9 at >>> this point in time so that work might end up in 10. >>> >>> Pete >>>> Thanks, >>>> Alexandr. >>>>> On 7/4/16 4:14 AM, Alexandr Scherbatiy wrote: >>>>>> On 6/18/2016 5:31 AM, Pete Brunet wrote: >>>>>>> Please review the following patch. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145207 >>>>>>> Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8145207/webrev.00/ >>>>>>> >>>>>>> This fixes the following functionality that was not working with the >>>>>>> JList of ListDemo of SwingSet2. >>>>>>> - start VoiceOver >>>>>>> - start SwingSet2 >>>>>>> - start the ListDemo >>>>>>> - press Tab until focus is on the list, should hear VO when changing >>>>>>> selections with up/down arrow >>>>>>> - when interacting with list should hear that there are 30 (total) >>>>>>> items, not 26 (visible) items >>>>>>> - when using control+option+up/downarrow should be able to move to and >>>>>>> select (control+option+spacebar) non-visible items past the 26th >>>>>>> visible >>>>>>> item >>>>>>> - should be able to multi-select both visible and invisible items >>>>>>> using >>>>>>> control+option+command+return and VO should read the item just added >>>>>>> - should be able to shift extend items with shift up or shift down >>>>>>> arrow >>>>>>> and VO should announce the item just added or removed >>>>>> CAccessibility: >>>>>> 639 childrenAndRoles.clear(); >>>>>> 640 childrenAndRoles.addAll(newArray); >>>>>> >>>>>> - Is it possible just to assign the newArray to the childrenAndRoles? >>>>>> Is it necessary that the childrenAndRoles has final keyword? >>>>> I made those changes. >>>>>> - Please, format the code on lines 630-631 to romevo unnessary spaces >>>>>> in round brackets. >>>>> I prefer to keep the spaces in this kind of split line. Over the years >>>>> I've found that style easier to read. >>>>>> CAccessible: >>>>>> >>>>>> - static method getActiveDescendant() is not used in the CAccessible >>>>>> class but only in CAccessibility. Is it possible to move it to the >>>>>> CAccessibility class? >>>>> It's there because it accesses the private field, activeDescendant. >>>>>> - Please, split the long lines. You may use static imports for >>>>>> constants. >>>>> Done. >>>>>> JavaComponentAccessibility: >>>>>> 716 if (returnValue == -1) { >>>>>> 717 return NSNotFound; >>>>>> 718 } else { >>>>>> 719 return returnValue; >>>>>> 720 } >>>>>> >>>>>> - This can be written shorter: return (returnValue == -1) ? >>>>>> NSNotFound : returnValue; >>>>> Done. >>>>>> 998 if ([self isSelectable:[ThreadUtilities getJNIEnv]]) { >>>>>> 999 return YES; >>>>>> 1000 } else { >>>>>> 1001 return NO; >>>>>> 1002 } >>>>>> >>>>>> - Is there a macros which can convert jboolean to BOOL? >>>>> I could not find one. >>>>>> - Could you also split the modified lines where it is possible? >>>>> Done. >>>>> >>>>> Pete >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>>> Pete >>>>>>> >>>>>>> From alexandr.scherbatiy at oracle.com Tue Jul 19 11:14:01 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 19 Jul 2016 14:14:01 +0300 Subject: Input needed: JDK-8161664: Memory leak in com.apple.laf.AquaProgressBarUI: removed progress bar still referenced In-Reply-To: References: Message-ID: <52afebd5-9534-0dc7-247a-67e903ebe52e@oracle.com> On 7/19/2016 12:27 PM, Robin Stevens wrote: > Hello, > > I wanted to discuss my approach for issue JDK-8161664 > (https://bugs.openjdk.java.net/browse/JDK-8161664) before I started > working on this issue. > > In certain scenarios (see the JIRA issue for an example), the Timer in > the Animator inner class of the AquaProgressBarUI class remains > running, even when the JProgressBar has already been removed from the > UI. This causes a memory leak, as that running Timer avoids that the > JProgressBar can be GC-ed. As long as the Timer is running, the > JProgressBar is referenced through > > Timer -> ActionListener (=Animator inner class) -> AquaProgressBarUI > outer class -> JProgressBar field > > > > I see two possible approaches to fix this: > > 1) I carefully investigate the particular scenario I found, and try to > figure out why the Timer is not stopped and fix this particular > scenario. This offers of course no guarantees that there are no other > scenarios which keep the Timer running. > > 2) I replace one of the hard references with a weak reference, hence > avoiding the memory leak in all cases. > If I do not attach the Animator inner class directly as listener to > the timer, but use another ActionListener which only has a > WeakReference to the Animator class, the memory leak is solved. > The ActionListener could then stop the timer when the timer is fired > and the WeakReference#get returns null. > > > > I prefer the second approach. By cutting the hard reference between > the Timer and the Animator + stopping the Timer when the Animator is > GC-ed, I ensure that the Timer cannot cause a memory leak anymore. > This avoids overlooking certain scenarios. > > Any input on this ? Any preferences for a certain approach, or > proposal for another approach. Does other L&Fs (for example Metal) have the same memory leak with the JProgressBar? If no, it would be interesting to know what is the difference between them and the AquaProgressBarUI. Thanks, Alexandr. > > > Robin From alexandr.scherbatiy at oracle.com Tue Jul 19 11:20:16 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 19 Jul 2016 14:20:16 +0300 Subject: [9] Review request for 8160087: Change IOOBE to warning in the scenarios when it had not being thrown before the JDK-8078514 In-Reply-To: <578DF340.8060204@oracle.com> References: <19eeb5bb-18bc-85b2-7eaf-f16bfb6a0f9d@oracle.com> <4bcb6a4a-030c-fea5-30d5-33ec1c0ff2c1@oracle.com> <578DF340.8060204@oracle.com> Message-ID: <7e874ada-48e0-ec9a-da52-1cbf5cd519c7@oracle.com> The fix prints the warning method in case of wrong row sorter usage. How often this can happen? Could the large number of the messages overflow a user output? Thanks, Alexandr. On 7/19/2016 12:30 PM, Semyon Sadetsky wrote: > > > On 19.07.2016 12:18, Alexandr Scherbatiy wrote: >> On 7/18/2016 11:46 AM, Semyon Sadetsky wrote: >>> Hello, >>> >>> Please review fix for JDK9: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8160087 >>> >>> webrev: http://cr.openjdk.java.net/~ssadetsky/8160087/webrev.00/ >>> >>> A warning is added to avoid issues in user code to throw exceptions >>> which were masked before. See bug descriptions for details. >> Should this behavior (which exists for long time) be specified in >> the DefaultRowSorter.convertRowIndexToView()/convertRowIndexToModel() >> javadoc? > This was not a > DefaultRowSorter.convertRowIndexToView()/convertRowIndexToModel() > issue. It was a mistake in the FilePane class. > RowSorter's javadoc mentions the correct way to use it: > > The view invokes a model change method when the underlying model has > changed. There may be order dependencies in how the events are > delivered, so a RowSorter should not update its mapping until one of > these methods is invoked. > > --Semyon >> >> Thanks, >> Alexandr. >>> >>> --Semyon >>> >> > From semyon.sadetsky at oracle.com Tue Jul 19 11:56:20 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 19 Jul 2016 14:56:20 +0300 Subject: [9] Review request for 8160087: Change IOOBE to warning in the scenarios when it had not being thrown before the JDK-8078514 In-Reply-To: <7e874ada-48e0-ec9a-da52-1cbf5cd519c7@oracle.com> References: <19eeb5bb-18bc-85b2-7eaf-f16bfb6a0f9d@oracle.com> <4bcb6a4a-030c-fea5-30d5-33ec1c0ff2c1@oracle.com> <578DF340.8060204@oracle.com> <7e874ada-48e0-ec9a-da52-1cbf5cd519c7@oracle.com> Message-ID: <578E1564.4010007@oracle.com> On 19.07.2016 14:20, Alexandr Scherbatiy wrote: > > The fix prints the warning method in case of wrong row sorter usage. > How often this can happen? Could the large number of the messages > overflow a user output? In the FilePane this happened only once after the initial file list loading. --Semyon > > Thanks, > Alexandr. > > On 7/19/2016 12:30 PM, Semyon Sadetsky wrote: >> >> >> On 19.07.2016 12:18, Alexandr Scherbatiy wrote: >>> On 7/18/2016 11:46 AM, Semyon Sadetsky wrote: >>>> Hello, >>>> >>>> Please review fix for JDK9: >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160087 >>>> >>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8160087/webrev.00/ >>>> >>>> A warning is added to avoid issues in user code to throw exceptions >>>> which were masked before. See bug descriptions for details. >>> Should this behavior (which exists for long time) be specified in >>> the >>> DefaultRowSorter.convertRowIndexToView()/convertRowIndexToModel() >>> javadoc? >> This was not a >> DefaultRowSorter.convertRowIndexToView()/convertRowIndexToModel() >> issue. It was a mistake in the FilePane class. >> RowSorter's javadoc mentions the correct way to use it: >> >> The view invokes a model change method when the underlying model has >> changed. There may be order dependencies in how the events are >> delivered, so a RowSorter should not update its mapping until one of >> these methods is invoked. >> >> --Semyon >>> >>> Thanks, >>> Alexandr. >>>> >>>> --Semyon >>>> >>> >> > From alexandr.scherbatiy at oracle.com Tue Jul 19 13:06:40 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 19 Jul 2016 16:06:40 +0300 Subject: [9] Review request for 8160087: Change IOOBE to warning in the scenarios when it had not being thrown before the JDK-8078514 In-Reply-To: <578E1564.4010007@oracle.com> References: <19eeb5bb-18bc-85b2-7eaf-f16bfb6a0f9d@oracle.com> <4bcb6a4a-030c-fea5-30d5-33ec1c0ff2c1@oracle.com> <578DF340.8060204@oracle.com> <7e874ada-48e0-ec9a-da52-1cbf5cd519c7@oracle.com> <578E1564.4010007@oracle.com> Message-ID: On 7/19/2016 2:56 PM, Semyon Sadetsky wrote: > On 19.07.2016 14:20, Alexandr Scherbatiy wrote: >> >> The fix prints the warning method in case of wrong row sorter usage. >> How often this can happen? Could the large number of the messages >> overflow a user output? > In the FilePane this happened only once after the initial file list > loading. I am just worrying that in a user application which does not properly use the row sorter there can be a lot of such warnings. And it could be some library which he can't be able to update. Is it possible to show the warning only once? Thanks, Alexandr. > > --Semyon >> >> Thanks, >> Alexandr. >> >> On 7/19/2016 12:30 PM, Semyon Sadetsky wrote: >>> >>> >>> On 19.07.2016 12:18, Alexandr Scherbatiy wrote: >>>> On 7/18/2016 11:46 AM, Semyon Sadetsky wrote: >>>>> Hello, >>>>> >>>>> Please review fix for JDK9: >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160087 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8160087/webrev.00/ >>>>> >>>>> A warning is added to avoid issues in user code to throw >>>>> exceptions which were masked before. See bug descriptions for >>>>> details. >>>> Should this behavior (which exists for long time) be specified in >>>> the >>>> DefaultRowSorter.convertRowIndexToView()/convertRowIndexToModel() >>>> javadoc? >>> This was not a >>> DefaultRowSorter.convertRowIndexToView()/convertRowIndexToModel() >>> issue. It was a mistake in the FilePane class. >>> RowSorter's javadoc mentions the correct way to use it: >>> >>> The view invokes a model change method when the underlying model has >>> changed. There may be order dependencies in how the events are >>> delivered, so a RowSorter should not update its mapping until one of >>> these methods is invoked. >>> >>> --Semyon >>>> >>>> Thanks, >>>> Alexandr. >>>>> >>>>> --Semyon >>>>> >>>> >>> >> > From robin.stevens at scz.be Tue Jul 19 13:33:52 2016 From: robin.stevens at scz.be (Robin Stevens) Date: Tue, 19 Jul 2016 15:33:52 +0200 Subject: Input needed: JDK-8161664: Memory leak in com.apple.laf.AquaProgressBarUI: removed progress bar still referenced In-Reply-To: <52afebd5-9534-0dc7-247a-67e903ebe52e@oracle.com> References: <52afebd5-9534-0dc7-247a-67e903ebe52e@oracle.com> Message-ID: Hello Alexandr, very valid remark. Running that same test program on Linux with the metal look and feel reveals no memory leak. I have no access to a Windows machine, so I couldn't get the Windows specific look and feel. The other ProgressBarUI implementations seem to extend from BasicProgressBarUI, which has the same mechanism of an Animator which uses a Timer. However, in the test program the Timer does not get started on Linux (while it gets started on OS X). In the BasicProgressBarUI class, all calls to startAnimationTimer are wrapped with an if check: if (progressBar.isDisplayable()) { startAnimationTimer(); } In the scenario from my test, the isDisplayable method returns false. On OS X, this check is missing so the timer is started. I assume adding that same check in the AquaProgressBarUI will fix the problem as well. So that is a third approach to solve the issue. Robin On Tue, Jul 19, 2016 at 1:14 PM, Alexandr Scherbatiy < alexandr.scherbatiy at oracle.com> wrote: > On 7/19/2016 12:27 PM, Robin Stevens wrote: > >> Hello, >> >> I wanted to discuss my approach for issue JDK-8161664 ( >> https://bugs.openjdk.java.net/browse/JDK-8161664) before I started >> working on this issue. >> >> In certain scenarios (see the JIRA issue for an example), the Timer in >> the Animator inner class of the AquaProgressBarUI class remains running, >> even when the JProgressBar has already been removed from the UI. This >> causes a memory leak, as that running Timer avoids that the JProgressBar >> can be GC-ed. As long as the Timer is running, the JProgressBar is >> referenced through >> >> Timer -> ActionListener (=Animator inner class) -> AquaProgressBarUI >> outer class -> JProgressBar field >> >> >> >> I see two possible approaches to fix this: >> >> 1) I carefully investigate the particular scenario I found, and try to >> figure out why the Timer is not stopped and fix this particular scenario. >> This offers of course no guarantees that there are no other scenarios which >> keep the Timer running. >> >> 2) I replace one of the hard references with a weak reference, hence >> avoiding the memory leak in all cases. >> If I do not attach the Animator inner class directly as listener to the >> timer, but use another ActionListener which only has a WeakReference to the >> Animator class, the memory leak is solved. >> The ActionListener could then stop the timer when the timer is fired and >> the WeakReference#get returns null. >> >> >> >> I prefer the second approach. By cutting the hard reference between the >> Timer and the Animator + stopping the Timer when the Animator is GC-ed, I >> ensure that the Timer cannot cause a memory leak anymore. This avoids >> overlooking certain scenarios. >> >> Any input on this ? Any preferences for a certain approach, or proposal >> for another approach. >> > Does other L&Fs (for example Metal) have the same memory leak with the > JProgressBar? If no, it would be interesting to know what is the difference > between them and the AquaProgressBarUI. > > Thanks, > Alexandr. > >> >> >> Robin >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Tue Jul 19 13:56:00 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 19 Jul 2016 16:56:00 +0300 Subject: [9] Review request for 8160246: Regression: 4410243 reproducible with GTK LaF Message-ID: Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8160246 webrev: http://cr.openjdk.java.net/~ssadetsky/8160246/webrev.00/ When the scrolled text component width is set to zero the text rootView is initialized and its preferred spans becomes unconstrained. But at the same time, the rootView preffered size is used to determine scroll bars visibility using getScrollableTracksViewportWidth/Height() and if unconstrained (and unwrapped) rootView height is less than the current viewport height then the vertical scroll bar is hidden which adds +15px to the viewport width and makes the rootView constrained in the next layout iteration which makes vertical scroll bar visible again... This layout cycle is infinite. The solution is to initialize the rootView only once when text component is firstly lay-outed. --Semyon From alexandr.scherbatiy at oracle.com Tue Jul 19 15:04:04 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 19 Jul 2016 18:04:04 +0300 Subject: [9] Review request for 8160246: Regression: 4410243 reproducible with GTK LaF In-Reply-To: References: Message-ID: <19d817bd-f619-f5e0-7670-7c3dbafac0eb@oracle.com> The fix looks good to me. Thanks, Alexandr. On 7/19/2016 4:56 PM, Semyon Sadetsky wrote: > Hello, > > Please review fix for JDK9: > > bug: https://bugs.openjdk.java.net/browse/JDK-8160246 > > webrev: http://cr.openjdk.java.net/~ssadetsky/8160246/webrev.00/ > > When the scrolled text component width is set to zero the text > rootView is initialized and its preferred spans becomes unconstrained. > But at the same time, the rootView preffered size is used to determine > scroll bars visibility using getScrollableTracksViewportWidth/Height() > and if unconstrained (and unwrapped) rootView height is less than the > current viewport height then the vertical scroll bar is hidden which > adds +15px to the viewport width and makes the rootView constrained in > the next layout iteration which makes vertical scroll bar visible > again... This layout cycle is infinite. > > The solution is to initialize the rootView only once when text > component is firstly lay-outed. > > --Semyon > From alexandr.scherbatiy at oracle.com Tue Jul 19 16:06:49 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 19 Jul 2016 19:06:49 +0300 Subject: Input needed: JDK-8161664: Memory leak in com.apple.laf.AquaProgressBarUI: removed progress bar still referenced In-Reply-To: References: <52afebd5-9534-0dc7-247a-67e903ebe52e@oracle.com> Message-ID: On 7/19/2016 4:33 PM, Robin Stevens wrote: > Hello Alexandr, > > very valid remark. > Running that same test program on Linux with the metal look and feel > reveals no memory leak. I have no access to a Windows machine, so I > couldn't get the Windows specific look and feel. > > The other ProgressBarUI implementations seem to extend from > BasicProgressBarUI, which has the same mechanism of an Animator which > uses a Timer. > However, in the test program the Timer does not get started on Linux > (while it gets started on OS X). > > In the BasicProgressBarUI class, all calls to startAnimationTimer are > wrapped with an if check: > > if (progressBar.isDisplayable()) { > startAnimationTimer(); > } > > In the scenario from my test, the isDisplayable method returns false. > On OS X, this check is missing so the timer is started. I believe that the changed AquaProgressBarUIMemoryLeakTest where the progress bar is visible and indeterminate value is set to true at the end should also not have the memory leaks. Thanks, Alexandr. > > I assume adding that same check in the AquaProgressBarUI will fix the > problem as well. So that is a third approach to solve the issue. > > Robin > > On Tue, Jul 19, 2016 at 1:14 PM, Alexandr Scherbatiy > > wrote: > > On 7/19/2016 12:27 PM, Robin Stevens wrote: > > Hello, > > I wanted to discuss my approach for issue JDK-8161664 > (https://bugs.openjdk.java.net/browse/JDK-8161664) before I > started working on this issue. > > In certain scenarios (see the JIRA issue for an example), the > Timer in the Animator inner class of the AquaProgressBarUI > class remains running, even when the JProgressBar has already > been removed from the UI. This causes a memory leak, as that > running Timer avoids that the JProgressBar can be GC-ed. As > long as the Timer is running, the JProgressBar is referenced > through > > Timer -> ActionListener (=Animator inner class) -> > AquaProgressBarUI outer class -> JProgressBar field > > > > I see two possible approaches to fix this: > > 1) I carefully investigate the particular scenario I found, > and try to figure out why the Timer is not stopped and fix > this particular scenario. This offers of course no guarantees > that there are no other scenarios which keep the Timer running. > > 2) I replace one of the hard references with a weak reference, > hence avoiding the memory leak in all cases. > If I do not attach the Animator inner class directly as > listener to the timer, but use another ActionListener which > only has a WeakReference to the Animator class, the memory > leak is solved. > The ActionListener could then stop the timer when the timer is > fired and the WeakReference#get returns null. > > > > I prefer the second approach. By cutting the hard reference > between the Timer and the Animator + stopping the Timer when > the Animator is GC-ed, I ensure that the Timer cannot cause a > memory leak anymore. This avoids overlooking certain scenarios. > > Any input on this ? Any preferences for a certain approach, or > proposal for another approach. > > Does other L&Fs (for example Metal) have the same memory leak > with the JProgressBar? If no, it would be interesting to know what > is the difference between them and the AquaProgressBarUI. > > Thanks, > Alexandr. > > > > Robin > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.brunet at oracle.com Tue Jul 19 16:48:08 2016 From: peter.brunet at oracle.com (Pete Brunet) Date: Tue, 19 Jul 2016 11:48:08 -0500 Subject: RfR JDK-8161483 Implement AccessibleAction interface in JList.AccessibleJList.AccessibleJListChild In-Reply-To: <7a429ccd-f0d0-f403-08f0-bb42a1953a4b@oracle.com> References: <7a429ccd-f0d0-f403-08f0-bb42a1953a4b@oracle.com> Message-ID: <291686a7-8c0e-48a8-d894-69bc7dea4bba@oracle.com> I added a regression test: http://cr.openjdk.java.net/~ptbrunet/JDK-8161483/webrev.01/ Could someone please review that? I also need one more +1 on the code change. TiA, Pete On 7/19/16 3:17 AM, Alexandr Scherbatiy wrote: > > The fix looks good to me. > > Thanks, > Alexandr. > > On 7/19/2016 5:10 AM, Pete Brunet wrote: >> Please review the following: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8161483 >> Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8161483/webrev.00/ >> >> This is a followon to the patch for >> JDK-8145207 [macosx] JList, VO can't access non-visible list items >> >> In order to fixJDK-8145207the AccessibleAction interface was needed >> for JList.AccessibleJList.AccessibleJListChild but a backport of this >> fix has been requested and the released public API can not be changed >> in 8u or earlier. The workaround for JDK-8145207 is to create and >> use a private subclass of JList.AccessibleJList.AccessibleJListChild, >> JList.AccessibleJList.ActionableAccessibleJListChild. The downside >> of this fix is that it returns a subclass of the >> JList.AccessibleJList.AccessibleJListChild. If a user overrides the >> class and returns from its code it will not inherit the >> AccessibleAction behavior. For JDK 9 the >> ActionableAccessibleJListChild subclass should be removed and the >> AccessibleAction implementation moved to >> JList.AccessibleJList.AccessibleJListChild. >> >> TiA, >> Pete > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.brunet at oracle.com Tue Jul 19 17:50:16 2016 From: peter.brunet at oracle.com (Pete Brunet) Date: Tue, 19 Jul 2016 12:50:16 -0500 Subject: RfR JDK-8161483 Implement AccessibleAction interface in JList.AccessibleJList.AccessibleJListChild In-Reply-To: <291686a7-8c0e-48a8-d894-69bc7dea4bba@oracle.com> References: <7a429ccd-f0d0-f403-08f0-bb42a1953a4b@oracle.com> <291686a7-8c0e-48a8-d894-69bc7dea4bba@oracle.com> Message-ID: Look at .02 instead. I had an extraneous println left in .01. http://cr.openjdk.java.net/~ptbrunet/JDK-8161483/webrev.02/ On 7/19/16 11:48 AM, Pete Brunet wrote: > I added a regression test: > http://cr.openjdk.java.net/~ptbrunet/JDK-8161483/webrev.01/ > > Could someone please review that? > > I also need one more +1 on the code change. > > TiA, Pete > > On 7/19/16 3:17 AM, Alexandr Scherbatiy wrote: >> >> The fix looks good to me. >> >> Thanks, >> Alexandr. >> >> On 7/19/2016 5:10 AM, Pete Brunet wrote: >>> Please review the following: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161483 >>> Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8161483/webrev.00/ >>> >>> This is a followon to the patch for >>> JDK-8145207 [macosx] JList, VO can't access non-visible list items >>> >>> In order to fixJDK-8145207the AccessibleAction interface was needed >>> for JList.AccessibleJList.AccessibleJListChild but a backport of >>> this fix has been requested and the released public API can not be >>> changed in 8u or earlier. The workaround for JDK-8145207 is to >>> create and use a private subclass of >>> JList.AccessibleJList.AccessibleJListChild, >>> JList.AccessibleJList.ActionableAccessibleJListChild. The downside >>> of this fix is that it returns a subclass of the >>> JList.AccessibleJList.AccessibleJListChild. If a user overrides the >>> class and returns from its code it will not inherit the >>> AccessibleAction behavior. For JDK 9 the >>> ActionableAccessibleJListChild subclass should be removed and the >>> AccessibleAction implementation moved to >>> JList.AccessibleJList.AccessibleJListChild. >>> >>> TiA, >>> Pete >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue Jul 19 18:43:29 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 19 Jul 2016 21:43:29 +0300 Subject: RfR JDK-8161483 Implement AccessibleAction interface in JList.AccessibleJList.AccessibleJListChild In-Reply-To: References: <7a429ccd-f0d0-f403-08f0-bb42a1953a4b@oracle.com> <291686a7-8c0e-48a8-d894-69bc7dea4bba@oracle.com> Message-ID: <3568fe5e-5eb4-a5d8-7658-421bc73103de@oracle.com> The fix looks good to me. Thanks, Alexandr. On 7/19/2016 8:50 PM, Pete Brunet wrote: > Look at .02 instead. I had an extraneous println left in .01. > http://cr.openjdk.java.net/~ptbrunet/JDK-8161483/webrev.02/ > > On 7/19/16 11:48 AM, Pete Brunet wrote: >> I added a regression test: >> http://cr.openjdk.java.net/~ptbrunet/JDK-8161483/webrev.01/ >> >> Could someone please review that? >> >> I also need one more +1 on the code change. >> >> TiA, Pete >> >> On 7/19/16 3:17 AM, Alexandr Scherbatiy wrote: >>> >>> The fix looks good to me. >>> >>> Thanks, >>> Alexandr. >>> >>> On 7/19/2016 5:10 AM, Pete Brunet wrote: >>>> Please review the following: >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161483 >>>> Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8161483/webrev.00/ >>>> >>>> This is a followon to the patch for >>>> JDK-8145207 [macosx] JList, VO can't access non-visible list items >>>> >>>> In order to fixJDK-8145207the AccessibleAction interface was needed >>>> for JList.AccessibleJList.AccessibleJListChild but a backport of >>>> this fix has been requested and the released public API can not be >>>> changed in 8u or earlier. The workaround for JDK-8145207 is to >>>> create and use a private subclass of >>>> JList.AccessibleJList.AccessibleJListChild, >>>> JList.AccessibleJList.ActionableAccessibleJListChild. The downside >>>> of this fix is that it returns a subclass of the >>>> JList.AccessibleJList.AccessibleJListChild. If a user overrides >>>> the class and returns from its code it will not inherit the >>>> AccessibleAction behavior. For JDK 9 the >>>> ActionableAccessibleJListChild subclass should be removed and the >>>> AccessibleAction implementation moved to >>>> JList.AccessibleJList.AccessibleJListChild. >>>> >>>> TiA, >>>> Pete >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Tue Jul 19 18:52:17 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 19 Jul 2016 11:52:17 -0700 Subject: RfR JDK-8161483 Implement AccessibleAction interface in JList.AccessibleJList.AccessibleJListChild In-Reply-To: <3568fe5e-5eb4-a5d8-7658-421bc73103de@oracle.com> References: <7a429ccd-f0d0-f403-08f0-bb42a1953a4b@oracle.com> <291686a7-8c0e-48a8-d894-69bc7dea4bba@oracle.com> <3568fe5e-5eb4-a5d8-7658-421bc73103de@oracle.com> Message-ID: <578E76E1.8000302@oracle.com> The fix is fine but as I've said elsewhere I really don't like BugXXXXXX as test names. -phil. On 07/19/2016 11:43 AM, Alexandr Scherbatiy wrote: > The fix looks good to me. > > Thanks, > Alexandr. > > On 7/19/2016 8:50 PM, Pete Brunet wrote: >> Look at .02 instead. I had an extraneous println left in .01. >> http://cr.openjdk.java.net/~ptbrunet/JDK-8161483/webrev.02/ >> >> On 7/19/16 11:48 AM, Pete Brunet wrote: >>> I added a regression test: >>> http://cr.openjdk.java.net/~ptbrunet/JDK-8161483/webrev.01/ >>> >>> Could someone please review that? >>> >>> I also need one more +1 on the code change. >>> >>> TiA, Pete >>> >>> On 7/19/16 3:17 AM, Alexandr Scherbatiy wrote: >>>> >>>> The fix looks good to me. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 7/19/2016 5:10 AM, Pete Brunet wrote: >>>>> Please review the following: >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161483 >>>>> Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8161483/webrev.00/ >>>>> >>>>> This is a followon to the patch for >>>>> JDK-8145207 [macosx] JList, VO can't access non-visible list items >>>>> >>>>> In order to fixJDK-8145207the AccessibleAction interface was >>>>> needed for JList.AccessibleJList.AccessibleJListChild but a >>>>> backport of this fix has been requested and the released public >>>>> API can not be changed in 8u or earlier. The workaround for >>>>> JDK-8145207 is to create and use a private subclass of >>>>> JList.AccessibleJList.AccessibleJListChild, >>>>> JList.AccessibleJList.ActionableAccessibleJListChild. The downside >>>>> of this fix is that it returns a subclass of the >>>>> JList.AccessibleJList.AccessibleJListChild. If a user overrides >>>>> the class and returns from its code it will not inherit the >>>>> AccessibleAction behavior. For JDK 9 the >>>>> ActionableAccessibleJListChild subclass should be removed and the >>>>> AccessibleAction implementation moved to >>>>> JList.AccessibleJList.AccessibleJListChild. >>>>> >>>>> TiA, >>>>> Pete >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.brunet at oracle.com Tue Jul 19 19:03:45 2016 From: peter.brunet at oracle.com (Pete Brunet) Date: Tue, 19 Jul 2016 14:03:45 -0500 Subject: RfR JDK-8161483 Implement AccessibleAction interface in JList.AccessibleJList.AccessibleJListChild In-Reply-To: <578E76E1.8000302@oracle.com> References: <7a429ccd-f0d0-f403-08f0-bb42a1953a4b@oracle.com> <291686a7-8c0e-48a8-d894-69bc7dea4bba@oracle.com> <3568fe5e-5eb4-a5d8-7658-421bc73103de@oracle.com> <578E76E1.8000302@oracle.com> Message-ID: <12d13a6d-1522-4854-3669-dd1215291013@oracle.com> On 7/19/16 1:52 PM, Phil Race wrote: > The fix is fine but as I've said elsewhere I really don't like > BugXXXXXX as test names. Hi Phil, I haven't seen any of your prior comments about this matter. I haven't seen any other style so just assumed that is/was the standard. Is there an alternative standard I should start to use? Pete > > -phil. > > On 07/19/2016 11:43 AM, Alexandr Scherbatiy wrote: >> The fix looks good to me. >> >> Thanks, >> Alexandr. >> >> On 7/19/2016 8:50 PM, Pete Brunet wrote: >>> Look at .02 instead. I had an extraneous println left in .01. >>> http://cr.openjdk.java.net/~ptbrunet/JDK-8161483/webrev.02/ >>> >>> On 7/19/16 11:48 AM, Pete Brunet wrote: >>>> I added a regression test: >>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8161483/webrev.01/ >>>> >>>> Could someone please review that? >>>> >>>> I also need one more +1 on the code change. >>>> >>>> TiA, Pete >>>> >>>> On 7/19/16 3:17 AM, Alexandr Scherbatiy wrote: >>>>> >>>>> The fix looks good to me. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 7/19/2016 5:10 AM, Pete Brunet wrote: >>>>>> Please review the following: >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161483 >>>>>> Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8161483/webrev.00/ >>>>>> >>>>>> This is a followon to the patch for >>>>>> JDK-8145207 [macosx] JList, VO can't access non-visible list items >>>>>> >>>>>> In order to fixJDK-8145207the AccessibleAction interface was >>>>>> needed for JList.AccessibleJList.AccessibleJListChild but a >>>>>> backport of this fix has been requested and the released public >>>>>> API can not be changed in 8u or earlier. The workaround for >>>>>> JDK-8145207 is to create and use a private subclass of >>>>>> JList.AccessibleJList.AccessibleJListChild, >>>>>> JList.AccessibleJList.ActionableAccessibleJListChild. The >>>>>> downside of this fix is that it returns a subclass of the >>>>>> JList.AccessibleJList.AccessibleJListChild. If a user overrides >>>>>> the class and returns from its code it will not inherit the >>>>>> AccessibleAction behavior. For JDK 9 the >>>>>> ActionableAccessibleJListChild subclass should be removed and the >>>>>> AccessibleAction implementation moved to >>>>>> JList.AccessibleJList.AccessibleJListChild. >>>>>> >>>>>> TiA, >>>>>> Pete >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Tue Jul 19 19:02:21 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 19 Jul 2016 12:02:21 -0700 Subject: RfR JDK-8161483 Implement AccessibleAction interface in JList.AccessibleJList.AccessibleJListChild In-Reply-To: <12d13a6d-1522-4854-3669-dd1215291013@oracle.com> References: <7a429ccd-f0d0-f403-08f0-bb42a1953a4b@oracle.com> <291686a7-8c0e-48a8-d894-69bc7dea4bba@oracle.com> <3568fe5e-5eb4-a5d8-7658-421bc73103de@oracle.com> <578E76E1.8000302@oracle.com> <12d13a6d-1522-4854-3669-dd1215291013@oracle.com> Message-ID: <578E793D.8090008@oracle.com> A meaningful name with some relevance to what the test tests ? -phil. On 07/19/2016 12:03 PM, Pete Brunet wrote: > > > On 7/19/16 1:52 PM, Phil Race wrote: >> The fix is fine but as I've said elsewhere I really don't like >> BugXXXXXX as test names. > Hi Phil, I haven't seen any of your prior comments about this matter. > I haven't seen any other style so just assumed that is/was the > standard. Is there an alternative standard I should start to use? > > Pete >> >> -phil. >> >> On 07/19/2016 11:43 AM, Alexandr Scherbatiy wrote: >>> The fix looks good to me. >>> >>> Thanks, >>> Alexandr. >>> >>> On 7/19/2016 8:50 PM, Pete Brunet wrote: >>>> Look at .02 instead. I had an extraneous println left in .01. >>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8161483/webrev.02/ >>>> >>>> On 7/19/16 11:48 AM, Pete Brunet wrote: >>>>> I added a regression test: >>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8161483/webrev.01/ >>>>> >>>>> Could someone please review that? >>>>> >>>>> I also need one more +1 on the code change. >>>>> >>>>> TiA, Pete >>>>> >>>>> On 7/19/16 3:17 AM, Alexandr Scherbatiy wrote: >>>>>> >>>>>> The fix looks good to me. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> On 7/19/2016 5:10 AM, Pete Brunet wrote: >>>>>>> Please review the following: >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161483 >>>>>>> Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8161483/webrev.00/ >>>>>>> >>>>>>> This is a followon to the patch for >>>>>>> JDK-8145207 [macosx] JList, VO can't access non-visible list items >>>>>>> >>>>>>> In order to fixJDK-8145207the AccessibleAction interface was >>>>>>> needed for JList.AccessibleJList.AccessibleJListChild but a >>>>>>> backport of this fix has been requested and the released public >>>>>>> API can not be changed in 8u or earlier. The workaround for >>>>>>> JDK-8145207 is to create and use a private subclass of >>>>>>> JList.AccessibleJList.AccessibleJListChild, >>>>>>> JList.AccessibleJList.ActionableAccessibleJListChild. The >>>>>>> downside of this fix is that it returns a subclass of the >>>>>>> JList.AccessibleJList.AccessibleJListChild. If a user overrides >>>>>>> the class and returns from its code it will not inherit the >>>>>>> AccessibleAction behavior. For JDK 9 the >>>>>>> ActionableAccessibleJListChild subclass should be removed and >>>>>>> the AccessibleAction implementation moved to >>>>>>> JList.AccessibleJList.AccessibleJListChild. >>>>>>> >>>>>>> TiA, >>>>>>> Pete >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.brunet at oracle.com Tue Jul 19 19:13:35 2016 From: peter.brunet at oracle.com (Pete Brunet) Date: Tue, 19 Jul 2016 14:13:35 -0500 Subject: RfR JDK-8161483 Implement AccessibleAction interface in JList.AccessibleJList.AccessibleJListChild In-Reply-To: <578E793D.8090008@oracle.com> References: <7a429ccd-f0d0-f403-08f0-bb42a1953a4b@oracle.com> <291686a7-8c0e-48a8-d894-69bc7dea4bba@oracle.com> <3568fe5e-5eb4-a5d8-7658-421bc73103de@oracle.com> <578E76E1.8000302@oracle.com> <12d13a6d-1522-4854-3669-dd1215291013@oracle.com> <578E793D.8090008@oracle.com> Message-ID: So rename Bug8161483 to AccessibleActionOnAccessibleJListChild? Do we need input from an SQE lead for guidance for this bug and all future bugs? Pete On 7/19/16 2:02 PM, Phil Race wrote: > A meaningful name with some relevance to what the test tests ? > > -phil. > > On 07/19/2016 12:03 PM, Pete Brunet wrote: >> >> >> On 7/19/16 1:52 PM, Phil Race wrote: >>> The fix is fine but as I've said elsewhere I really don't like >>> BugXXXXXX as test names. >> Hi Phil, I haven't seen any of your prior comments about this >> matter. I haven't seen any other style so just assumed that is/was >> the standard. Is there an alternative standard I should start to use? >> >> Pete >>> >>> -phil. >>> >>> On 07/19/2016 11:43 AM, Alexandr Scherbatiy wrote: >>>> The fix looks good to me. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 7/19/2016 8:50 PM, Pete Brunet wrote: >>>>> Look at .02 instead. I had an extraneous println left in .01. >>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8161483/webrev.02/ >>>>> >>>>> On 7/19/16 11:48 AM, Pete Brunet wrote: >>>>>> I added a regression test: >>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8161483/webrev.01/ >>>>>> >>>>>> Could someone please review that? >>>>>> >>>>>> I also need one more +1 on the code change. >>>>>> >>>>>> TiA, Pete >>>>>> >>>>>> On 7/19/16 3:17 AM, Alexandr Scherbatiy wrote: >>>>>>> >>>>>>> The fix looks good to me. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> On 7/19/2016 5:10 AM, Pete Brunet wrote: >>>>>>>> Please review the following: >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161483 >>>>>>>> Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8161483/webrev.00/ >>>>>>>> >>>>>>>> This is a followon to the patch for >>>>>>>> JDK-8145207 [macosx] JList, VO can't access non-visible list items >>>>>>>> >>>>>>>> In order to fixJDK-8145207the AccessibleAction interface was >>>>>>>> needed for JList.AccessibleJList.AccessibleJListChild but a >>>>>>>> backport of this fix has been requested and the released public >>>>>>>> API can not be changed in 8u or earlier. The workaround for >>>>>>>> JDK-8145207 is to create and use a private subclass of >>>>>>>> JList.AccessibleJList.AccessibleJListChild, >>>>>>>> JList.AccessibleJList.ActionableAccessibleJListChild. The >>>>>>>> downside of this fix is that it returns a subclass of the >>>>>>>> JList.AccessibleJList.AccessibleJListChild. If a user >>>>>>>> overrides the class and returns from its code it will not >>>>>>>> inherit the AccessibleAction behavior. For JDK 9 the >>>>>>>> ActionableAccessibleJListChild subclass should be removed and >>>>>>>> the AccessibleAction implementation moved to >>>>>>>> JList.AccessibleJList.AccessibleJListChild. >>>>>>>> >>>>>>>> TiA, >>>>>>>> Pete >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Tue Jul 19 19:16:56 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 19 Jul 2016 22:16:56 +0300 Subject: [OpenJDK 2D-Dev] RFR(L): 8160974: [TESTBUG] Mark more headful tests with @key headful. In-Reply-To: <87923b42e8c1478d8b4227e136fe69a5@DEWDFE13DE09.global.corp.sap> References: <87923b42e8c1478d8b4227e136fe69a5@DEWDFE13DE09.global.corp.sap> Message-ID: <1296e1b0-fa40-81cb-1083-edad0e0bf915@oracle.com> Look fine to me. On 07.07.16 18:01, Lindenmaier, Goetz wrote: > Hi, > > > > This change is ?L? because there are changes to a lot of files, but the > changes > > are all similar, so it?s rather easy to review. > > Similar to 8159690 I added @key headful to another around 600 tests. > > I used different patterns to grep for the headful exceptions. > > > > These are now all I could find with grepping and the like. I have around > > 80 failing tests remaining, where a row will probably also depend on > > a display, but I want to look at them more closely, so I don?t want > > to include them here. > > > > Please review this change: > > http://cr.openjdk.java.net/~goetz/wr16/8160974-headful/webrev.01/ > > > > Best regards, > > Goetz. > > > > > -- Best regards, Sergey. From goetz.lindenmaier at sap.com Tue Jul 19 19:39:45 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 19 Jul 2016 19:39:45 +0000 Subject: [OpenJDK 2D-Dev] RFR(L): 8160974: [TESTBUG] Mark more headful tests with @key headful. In-Reply-To: <1296e1b0-fa40-81cb-1083-edad0e0bf915@oracle.com> References: <87923b42e8c1478d8b4227e136fe69a5@DEWDFE13DE09.global.corp.sap> <1296e1b0-fa40-81cb-1083-edad0e0bf915@oracle.com> Message-ID: <497eea265ad64cd2ae850b66aa98c25f@DEWDFE13DE09.global.corp.sap> Hi Sergey, thanks a lot for looking at this! Best regards, Goetz. > -----Original Message----- > From: Sergey Bylokhov [mailto:Sergey.Bylokhov at oracle.com] > Sent: Tuesday, July 19, 2016 9:17 PM > To: Lindenmaier, Goetz ; awt- > dev at openjdk.java.net; swing-dev at openjdk.java.net; 2d-dev <2d- > dev at openjdk.java.net> > Subject: Re: [OpenJDK 2D-Dev] RFR(L): 8160974: [TESTBUG] Mark more > headful tests with @key headful. > > Look fine to me. > > On 07.07.16 18:01, Lindenmaier, Goetz wrote: > > Hi, > > > > > > > > This change is 'L' because there are changes to a lot of files, but the > > changes > > > > are all similar, so it's rather easy to review. > > > > Similar to 8159690 I added @key headful to another around 600 tests. > > > > I used different patterns to grep for the headful exceptions. > > > > > > > > These are now all I could find with grepping and the like. I have around > > > > 80 failing tests remaining, where a row will probably also depend on > > > > a display, but I want to look at them more closely, so I don't want > > > > to include them here. > > > > > > > > Please review this change: > > > > http://cr.openjdk.java.net/~goetz/wr16/8160974-headful/webrev.01/ > > > > > > > > Best regards, > > > > Goetz. > > > > > > > > > > > > > -- > Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Jul 19 19:42:34 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 19 Jul 2016 22:42:34 +0300 Subject: Review Request JDK-8159168 [hidpi] Window.setShape() works incorrectly on HiDPI In-Reply-To: References: <4df2cfca-d6d2-4dcf-b986-713d76f017a4@default> <7016c0cd-9ad3-4ffb-b4cb-be109a7a50b5@oracle.com> <2344f943-cbca-4df2-bec4-30c0fe766388@default> <6275c579-6947-bd61-c434-65ffa1839902@oracle.com> <177de961-76d1-4fa0-8ca0-1f9445e39b0b@default> <9485ca23-2afe-4a63-8117-590d6e88efc3@default> <8863940b-832e-ccb2-331c-37b28aab84fa@oracle.com> Message-ID: Hi, Rajeev. Can you please clarify how it works(if it works) on Linux/Solaris? On 11.07.16 12:08, Rajeev Chamyal wrote: > Hello Semyon, > > > > Please review the updated webrev as per review comments. > > http://cr.openjdk.java.net/~rchamyal/8159168/webrev.04/ > > > > Regards, > > Rajeev Chamyal > > > > *From:*Semyon Sadetsky > *Sent:* 11 July 2016 14:29 > *To:* Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net; > Sergey Bylokhov > *Subject:* Re: Review Request JDK-8159168 [hidpi] > Window.setShape() works incorrectly on HiDPI > > > > On 7/11/2016 11:10 AM, Rajeev Chamyal wrote: > > Hello Semyon, > > > > Thanks for the review. Yes, mouse move is not required I have > removed it. > > Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8159168/webrev.03/ > > Thanks. > I also cannot see the reason to wait 1 second in line 59. > It seems tx variable from line 53 is never used. > > --Semyon > > > > Regards, > > Rajeev Chamyal > > > > *From:*Semyon Sadetsky > *Sent:* 11 July 2016 12:30 > *To:* Rajeev Chamyal; Alexander Scherbatiy; > swing-dev at openjdk.java.net ; > Sergey Bylokhov > *Subject:* Re: Review Request JDK-8159168 [hidpi] > Window.setShape() works incorrectly on HiDPI > > > > Hi Rajeev, > > The fix itself looks good. I only did not get for what purpose mouse > pointer is moved in the test? > > --Semyon > > > > On 7/5/2016 9:16 AM, Rajeev Chamyal wrote: > > Hello Alexandr, > > > > Please review updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8159168/webrev.02/ > > > > Regards, > > Rajeev Chamyal > > > > *From:*Alexandr Scherbatiy > *Sent:* 05 July 2016 11:38 > *To:* Rajeev Chamyal; swing-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: Review Request JDK-8159168 [hidpi] > Window.setShape() works incorrectly on HiDPI > > > > On 7/5/2016 8:25 AM, Rajeev Chamyal wrote: > > > > Hello Alexandr, > > > > Thanks for the review. > > As per windows specification X & Y scale are always equal > that?s why I have put scaleX == scaleY check. > > But it may change in future so I have removed this check. > > > > http://cr.openjdk.java.net/~rchamyal/8159168/webrev.01/ > > > 1135 if (scaleX != 1 && scaleY != 1) { > > It is better to use 'or' operator because the shape should be > scaled when on of the scales is differ from 1. > > Thanks, > Alexandr. > > > > > > > Regards, > > Rajeev Chamyal > > > > *From:*Alexandr Scherbatiy > *Sent:* 04 July 2016 18:03 > *To:* Rajeev Chamyal; swing-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: Review Request JDK-8159168 > [hidpi] Window.setShape() works incorrectly on HiDPI > > > > On 7/4/2016 3:09 PM, Rajeev Chamyal wrote: > > > > > Hello All, > > > > Please review the following webrev. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8159168 > > Webrev: > http://cr.openjdk.java.net/~rchamyal/8159168/webrev.00/ > > > > > Issue: In HiDPI screen shape set through > window::setShape API is not scaled based on system scale. > > Fix:. Updated the WComponentPeer::applyShape to update > shape based on system scale. > > 1131 double scaleX = > winGraphicsConfig.getDefaultTransform().getScaleX(); > 1132 double scaleY = > winGraphicsConfig.getDefaultTransform().getScaleY(); > > The getDefaultTransform() is called twice which leads that > AffineTransform object is created two times > 1133 if (scaleX != 1 && scaleY != 1 && scaleX == > scaleY) { > > Is the check scaleX == scaleY really necessary here? > > Is it possible to make the test automated? Just run it > with option "@run main/othervm -Dsun.java2d.uiScale=2 > TestName" and check the area where the shape is drawn? > > Thanks, > Alexandr. > > > > > > > Regards, > > Rajeev Chamyal > > > > > > > > > > > -- Best regards, Sergey. From rajeev.chamyal at oracle.com Tue Jul 19 19:49:29 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Tue, 19 Jul 2016 12:49:29 -0700 (PDT) Subject: Review Request JDK-8159168 [hidpi] Window.setShape() works incorrectly on HiDPI In-Reply-To: References: <4df2cfca-d6d2-4dcf-b986-713d76f017a4@default> <7016c0cd-9ad3-4ffb-b4cb-be109a7a50b5@oracle.com> <2344f943-cbca-4df2-bec4-30c0fe766388@default> <6275c579-6947-bd61-c434-65ffa1839902@oracle.com> <177de961-76d1-4fa0-8ca0-1f9445e39b0b@default> <9485ca23-2afe-4a63-8117-590d6e88efc3@default> <8863940b-832e-ccb2-331c-37b28aab84fa@oracle.com> Message-ID: <68c5f48e-f615-45f2-96bc-c0e7b5fa87da@default> Hello Sergey, It works fine on linux. Regards, Rajeev Chamyal -----Original Message----- From: Sergey Bylokhov Sent: 20 July 2016 01:13 To: Rajeev Chamyal; Semyon Sadetsky; Alexander Scherbatiy; swing-dev at openjdk.java.net Subject: Re: Review Request JDK-8159168 [hidpi] Window.setShape() works incorrectly on HiDPI Hi, Rajeev. Can you please clarify how it works(if it works) on Linux/Solaris? On 11.07.16 12:08, Rajeev Chamyal wrote: > Hello Semyon, > > > > Please review the updated webrev as per review comments. > > http://cr.openjdk.java.net/~rchamyal/8159168/webrev.04/ > > > > Regards, > > Rajeev Chamyal > > > > *From:*Semyon Sadetsky > *Sent:* 11 July 2016 14:29 > *To:* Rajeev Chamyal; Alexander Scherbatiy; > swing-dev at openjdk.java.net; Sergey Bylokhov > *Subject:* Re: Review Request JDK-8159168 [hidpi] > Window.setShape() works incorrectly on HiDPI > > > > On 7/11/2016 11:10 AM, Rajeev Chamyal wrote: > > Hello Semyon, > > > > Thanks for the review. Yes, mouse move is not required I have > removed it. > > Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8159168/webrev.03/ > > Thanks. > I also cannot see the reason to wait 1 second in line 59. > It seems tx variable from line 53 is never used. > > --Semyon > > > > Regards, > > Rajeev Chamyal > > > > *From:*Semyon Sadetsky > *Sent:* 11 July 2016 12:30 > *To:* Rajeev Chamyal; Alexander Scherbatiy; > swing-dev at openjdk.java.net ; > Sergey Bylokhov > *Subject:* Re: Review Request JDK-8159168 [hidpi] > Window.setShape() works incorrectly on HiDPI > > > > Hi Rajeev, > > The fix itself looks good. I only did not get for what purpose mouse > pointer is moved in the test? > > --Semyon > > > > On 7/5/2016 9:16 AM, Rajeev Chamyal wrote: > > Hello Alexandr, > > > > Please review updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8159168/webrev.02/ > > > > Regards, > > Rajeev Chamyal > > > > *From:*Alexandr Scherbatiy > *Sent:* 05 July 2016 11:38 > *To:* Rajeev Chamyal; swing-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: Review Request JDK-8159168 [hidpi] > Window.setShape() works incorrectly on HiDPI > > > > On 7/5/2016 8:25 AM, Rajeev Chamyal wrote: > > > > Hello Alexandr, > > > > Thanks for the review. > > As per windows specification X & Y scale are always equal > that's why I have put scaleX == scaleY check. > > But it may change in future so I have removed this check. > > > > http://cr.openjdk.java.net/~rchamyal/8159168/webrev.01/ > > > 1135 if (scaleX != 1 && scaleY != 1) { > > It is better to use 'or' operator because the shape should be > scaled when on of the scales is differ from 1. > > Thanks, > Alexandr. > > > > > > > Regards, > > Rajeev Chamyal > > > > *From:*Alexandr Scherbatiy > *Sent:* 04 July 2016 18:03 > *To:* Rajeev Chamyal; swing-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: Review Request JDK-8159168 > [hidpi] Window.setShape() works incorrectly on HiDPI > > > > On 7/4/2016 3:09 PM, Rajeev Chamyal wrote: > > > > > Hello All, > > > > Please review the following webrev. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8159168 > > Webrev: > http://cr.openjdk.java.net/~rchamyal/8159168/webrev.00/ > > > > > > Issue: In HiDPI screen shape set through > window::setShape API is not scaled based on system scale. > > Fix:. Updated the WComponentPeer::applyShape to update > shape based on system scale. > > 1131 double scaleX = > winGraphicsConfig.getDefaultTransform().getScaleX(); > 1132 double scaleY = > winGraphicsConfig.getDefaultTransform().getScaleY(); > > The getDefaultTransform() is called twice which leads that > AffineTransform object is created two times > 1133 if (scaleX != 1 && scaleY != 1 && scaleX == > scaleY) { > > Is the check scaleX == scaleY really necessary here? > > Is it possible to make the test automated? Just run it > with option "@run main/othervm -Dsun.java2d.uiScale=2 > TestName" and check the area where the shape is drawn? > > Thanks, > Alexandr. > > > > > > > Regards, > > Rajeev Chamyal > > > > > > > > > > > -- Best regards, Sergey. From rajeev.chamyal at oracle.com Tue Jul 19 20:26:44 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Tue, 19 Jul 2016 13:26:44 -0700 (PDT) Subject: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel In-Reply-To: <57877747.3040904@oracle.com> References: <340c1fa9-7da5-4fcb-9119-0e1e2dcaeb10@default> <9bd7ca3c-2297-0c36-c249-4a9b560275a2@oracle.com> <395e74b7-451e-453e-b552-be2a5bc0e348@default> <30e65d6d-cb35-4c55-b1b2-80752929576a@default> <3d266275-efcd-4d69-bfab-9604467856d1@default> <57877747.3040904@oracle.com> Message-ID: Hello Semyon, Please review the updated webrev. http://cr.openjdk.java.net/~rchamyal/8147648/webrev.03/ Regards, Rajeev Chamyal From: Semyon Sadetsky Sent: 14 July 2016 16:58 To: Rajeev Chamyal; swing-dev at openjdk.java.net; Sergey Bylokhov; Alexander Scherbatiy Subject: Re: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel Hi Rajeev, I have added 1px border to the icon in your test: private static BufferedImage generateImage(int scale, Color c) { int x = SZ * scale; BufferedImage img = new BufferedImage(x, x, BufferedImage.TYPE_INT_RGB); Graphics g = img.getGraphics(); if (g != null) { g.setColor(c); g.fillRect(0, 0, x, x); g.setColor(Color.YELLOW); g.drawRect(0, 0, x-1, x-1); } return img; } It seems the icon in the taskbar is not correct for UI scale > 1. By the way, graphics object should be disposed using g.dispose() when it is not needed anymore. --Semyon On 14.07.2016 10:08, Rajeev Chamyal wrote: Hello All, Gentle reminder. Please review the updated webrev. http://cr.openjdk.java.net/~rchamyal/8147648/webrev.02/ Update: simplified the test. Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 22 June 2016 15:46 To: Rajeev Chamyal; Sergey Bylokhov; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel The fix looks good to me. Thanks, Alexandr. On 6/22/2016 10:49 AM, Rajeev Chamyal wrote: Hello Alexandr, Thanks for the review. I have updated webrev as per comments. http://cr.openjdk.java.net/~rchamyal/8147648/webrev.01/ Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 21 June 2016 17:37 To: Rajeev Chamyal; Sergey Bylokhov; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel On 6/21/2016 12:16 PM, Rajeev Chamyal wrote: Hello All, Please review the following webrev. Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8147648/webrev.00/"http://cr.openjdk.java.net/~rchamyal/8147648/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8147648 Issue: Wrong resolution variant is used as icon in the Unity panel. Cause: The screen transforms are not applied to find the correct resolution variant image in current implementation. Fix: Applied the screen transforms to graphics object. 222 int scaleX = (int)tx.getScaleX(); 223 int scaleY = (int)tx.getScaleY(); 224 DataBufferInt buffer = new DataBufferInt(scaleX * width * scaleY * height); The fix is in the shared code and the scale factor can have floating point value on Windows. (for example 1.5). It is better to round the final width and height after scaling them. Thanks, Alexandr. Regards, Rajeev Chamyal -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin.stevens at scz.be Tue Jul 19 21:22:31 2016 From: robin.stevens at scz.be (Robin Stevens) Date: Tue, 19 Jul 2016 23:22:31 +0200 Subject: Input needed: JDK-8161664: Memory leak in com.apple.laf.AquaProgressBarUI: removed progress bar still referenced In-Reply-To: References: <52afebd5-9534-0dc7-247a-67e903ebe52e@oracle.com> Message-ID: Alexandr, that sounds right. It took me a while to figure out the exact circumstances to trigger this memory leak. In my application where I found this bug, I have a progress bar which is repeatedly switched from between visible and invisible, and between determinate and indeterminate. I could probably work around this issue by altering the sequence in which setVisible and setIndeterminate is called, but I can just as well fix the problem in the JDK. Anyway, adding the isDisplayable checks in the AquaProgressBarUI class seems to work. Test runs fine when those are added. I will send a new email to the list tomorrow with a request for a review. Thanks for your valuable input, Robin On Tue, Jul 19, 2016 at 6:06 PM, Alexandr Scherbatiy < alexandr.scherbatiy at oracle.com> wrote: > On 7/19/2016 4:33 PM, Robin Stevens wrote: > > Hello Alexandr, > > very valid remark. > Running that same test program on Linux with the metal look and feel > reveals no memory leak. I have no access to a Windows machine, so I > couldn't get the Windows specific look and feel. > > The other ProgressBarUI implementations seem to extend from > BasicProgressBarUI, which has the same mechanism of an Animator which uses > a Timer. > However, in the test program the Timer does not get started on Linux > (while it gets started on OS X). > > In the BasicProgressBarUI class, all calls to startAnimationTimer are > wrapped with an if check: > > if (progressBar.isDisplayable()) { > startAnimationTimer(); > } > > In the scenario from my test, the isDisplayable method returns false. On > OS X, this check is missing so the timer is started. > > I believe that the changed AquaProgressBarUIMemoryLeakTest where the > progress bar is visible and indeterminate value is set to true at the end > should also not have the memory leaks. > > Thanks, > Alexandr. > > > I assume adding that same check in the AquaProgressBarUI will fix the > problem as well. So that is a third approach to solve the issue. > > Robin > > On Tue, Jul 19, 2016 at 1:14 PM, Alexandr Scherbatiy < > alexandr.scherbatiy at oracle.com> wrote: > >> On 7/19/2016 12:27 PM, Robin Stevens wrote: >> >>> Hello, >>> >>> I wanted to discuss my approach for issue JDK-8161664 ( >>> https://bugs.openjdk.java.net/browse/JDK-8161664) before I started >>> working on this issue. >>> >>> In certain scenarios (see the JIRA issue for an example), the Timer in >>> the Animator inner class of the AquaProgressBarUI class remains running, >>> even when the JProgressBar has already been removed from the UI. This >>> causes a memory leak, as that running Timer avoids that the JProgressBar >>> can be GC-ed. As long as the Timer is running, the JProgressBar is >>> referenced through >>> >>> Timer -> ActionListener (=Animator inner class) -> AquaProgressBarUI >>> outer class -> JProgressBar field >>> >>> >>> >>> I see two possible approaches to fix this: >>> >>> 1) I carefully investigate the particular scenario I found, and try to >>> figure out why the Timer is not stopped and fix this particular scenario. >>> This offers of course no guarantees that there are no other scenarios which >>> keep the Timer running. >>> >>> 2) I replace one of the hard references with a weak reference, hence >>> avoiding the memory leak in all cases. >>> If I do not attach the Animator inner class directly as listener to the >>> timer, but use another ActionListener which only has a WeakReference to the >>> Animator class, the memory leak is solved. >>> The ActionListener could then stop the timer when the timer is fired and >>> the WeakReference#get returns null. >>> >>> >>> >>> I prefer the second approach. By cutting the hard reference between the >>> Timer and the Animator + stopping the Timer when the Animator is GC-ed, I >>> ensure that the Timer cannot cause a memory leak anymore. This avoids >>> overlooking certain scenarios. >>> >>> Any input on this ? Any preferences for a certain approach, or proposal >>> for another approach. >>> >> Does other L&Fs (for example Metal) have the same memory leak with the >> JProgressBar? If no, it would be interesting to know what is the difference >> between them and the AquaProgressBarUI. >> >> Thanks, >> Alexandr. >> >>> >>> >>> Robin >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From avik.niyogi at oracle.com Wed Jul 20 06:00:26 2016 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Wed, 20 Jul 2016 11:30:26 +0530 Subject: 8161470: [TEST_BUG] Failure javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java In-Reply-To: <4e122507-0132-4c7a-0fc8-270f17cc9a07@oracle.com> References: <948581F9-11FB-4664-A85C-570B3D239FE6@oracle.com> <4e122507-0132-4c7a-0fc8-270f17cc9a07@oracle.com> Message-ID: A gentle reminder, please review my code changes. With Regards, Avik Niyogi > On 19-Jul-2016, at 1:31 pm, Alexandr Scherbatiy wrote: > > > The fix looks good to me. > > Thanks, > Alexandr. > > On 7/19/2016 9:45 AM, Avik Niyogi wrote: >> Hi All, >> >> Kindly review the fix for JDK9. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8161470 >> >> Webrev: http://cr.openjdk.java.net/~aniyogi/8161470/webrev.00/ >> >> Issue: This test consistently (12/12) fails on OS X 10.10 and also fails on Ubuntu 14.04. >> >> Cause: Due to quirk in robot.delay the UI was not getting appropriate behaviour response. >> >> Fix: Appropriate Robot methods were used to fix this. >> >> With Regards, >> Avik Niyogi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajeev.chamyal at oracle.com Wed Jul 20 06:11:03 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Tue, 19 Jul 2016 23:11:03 -0700 (PDT) Subject: 8161470: [TEST_BUG] Failure javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java In-Reply-To: References: <948581F9-11FB-4664-A85C-570B3D239FE6@oracle.com> <4e122507-0132-4c7a-0fc8-270f17cc9a07@oracle.com> Message-ID: <5e163ade-7390-4ff3-be25-edb094359c2d@default> Hello Avik, Line 67 can be removed from test. Regards, Rajeev Chamyal From: Avik Niyogi Sent: 20 July 2016 11:30 To: Rajeev Chamyal Cc: Praveen Srivastava; Alexandr Scherbatiy; swing-dev at openjdk.java.net Subject: Re: 8161470: [TEST_BUG] Failure javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java A gentle reminder, please review my code changes. With Regards, Avik Niyogi On 19-Jul-2016, at 1:31 pm, Alexandr Scherbatiy wrote: The fix looks good to me. Thanks, Alexandr. On 7/19/2016 9:45 AM, Avik Niyogi wrote: Hi All, Kindly review the fix for JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8161470 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Eaniyogi/8161470/webrev.00/"http://cr.openjdk.java.net/~aniyogi/8161470/webrev.00/ Issue: This test consistently (12/12) fails on OS X 10.10 and also fails on Ubuntu 14.04. Cause: Due to quirk in robot.delay the UI was not getting appropriate behaviour response. Fix: Appropriate Robot methods were used to fix this. With Regards, Avik Niyogi -------------- next part -------------- An HTML attachment was scrubbed... URL: From avik.niyogi at oracle.com Wed Jul 20 06:20:28 2016 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Wed, 20 Jul 2016 11:50:28 +0530 Subject: 8161470: [TEST_BUG] Failure javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java In-Reply-To: <5e163ade-7390-4ff3-be25-edb094359c2d@default> References: <948581F9-11FB-4664-A85C-570B3D239FE6@oracle.com> <4e122507-0132-4c7a-0fc8-270f17cc9a07@oracle.com> <5e163ade-7390-4ff3-be25-edb094359c2d@default> Message-ID: <1BC205AF-012C-45E7-A43C-9DD2000F6F43@oracle.com> Updated on the same webrev due to one line change. With Regards, Avik Niyogi > On 20-Jul-2016, at 11:41 am, Rajeev Chamyal wrote: > > Hello Avik, > > Line 67 can be removed from test. > > Regards, > Rajeev Chamyal > From: Avik Niyogi > Sent: 20 July 2016 11:30 > To: Rajeev Chamyal > Cc: Praveen Srivastava; Alexandr Scherbatiy; swing-dev at openjdk.java.net > Subject: Re: 8161470: [TEST_BUG] Failure javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java > > A gentle reminder, please review my code changes. > > With Regards, > Avik Niyogi > On 19-Jul-2016, at 1:31 pm, Alexandr Scherbatiy > wrote: > > > The fix looks good to me. > > Thanks, > Alexandr. > > On 7/19/2016 9:45 AM, Avik Niyogi wrote: > Hi All, > > Kindly review the fix for JDK9. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8161470 > > Webrev: http://cr.openjdk.java.net/~aniyogi/8161470/webrev.00/ > > Issue: This test consistently (12/12) fails on OS X 10.10 and also fails on Ubuntu 14.04. > > Cause: Due to quirk in robot.delay the UI was not getting appropriate behaviour response. > > Fix: Appropriate Robot methods were used to fix this. > > With Regards, > Avik Niyogi -------------- next part -------------- An HTML attachment was scrubbed... URL: From avik.niyogi at oracle.com Wed Jul 20 06:22:02 2016 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Wed, 20 Jul 2016 11:52:02 +0530 Subject: 8161470: [TEST_BUG] Failure javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java In-Reply-To: <5e163ade-7390-4ff3-be25-edb094359c2d@default> References: <948581F9-11FB-4664-A85C-570B3D239FE6@oracle.com> <4e122507-0132-4c7a-0fc8-270f17cc9a07@oracle.com> <5e163ade-7390-4ff3-be25-edb094359c2d@default> Message-ID: <6E92FD31-D4E7-4A53-938C-A4163187EB0E@oracle.com> Hi Rajeev, Updated on same webrev due to single line change. > On 20-Jul-2016, at 11:41 am, Rajeev Chamyal wrote: > > Hello Avik, > > Line 67 can be removed from test. > > Regards, > Rajeev Chamyal > From: Avik Niyogi > Sent: 20 July 2016 11:30 > To: Rajeev Chamyal > Cc: Praveen Srivastava; Alexandr Scherbatiy; swing-dev at openjdk.java.net > Subject: Re: 8161470: [TEST_BUG] Failure javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java > > A gentle reminder, please review my code changes. > > With Regards, > Avik Niyogi > On 19-Jul-2016, at 1:31 pm, Alexandr Scherbatiy > wrote: > > > The fix looks good to me. > > Thanks, > Alexandr. > > On 7/19/2016 9:45 AM, Avik Niyogi wrote: > Hi All, > > Kindly review the fix for JDK9. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8161470 > > Webrev: http://cr.openjdk.java.net/~aniyogi/8161470/webrev.00/ > > Issue: This test consistently (12/12) fails on OS X 10.10 and also fails on Ubuntu 14.04. > > Cause: Due to quirk in robot.delay the UI was not getting appropriate behaviour response. > > Fix: Appropriate Robot methods were used to fix this. > > With Regards, > Avik Niyogi -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajeev.chamyal at oracle.com Wed Jul 20 06:34:45 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Tue, 19 Jul 2016 23:34:45 -0700 (PDT) Subject: 8161470: [TEST_BUG] Failure javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java In-Reply-To: <6E92FD31-D4E7-4A53-938C-A4163187EB0E@oracle.com> References: <948581F9-11FB-4664-A85C-570B3D239FE6@oracle.com> <4e122507-0132-4c7a-0fc8-270f17cc9a07@oracle.com> <5e163ade-7390-4ff3-be25-edb094359c2d@default> <6E92FD31-D4E7-4A53-938C-A4163187EB0E@oracle.com> Message-ID: Looks fine to me. Regards, Rajeev Chamyal From: Avik Niyogi Sent: 20 July 2016 11:52 To: Rajeev Chamyal Cc: Praveen Srivastava; Alexander Scherbatiy; swing-dev at openjdk.java.net Subject: Re: 8161470: [TEST_BUG] Failure javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java Hi Rajeev, Updated on same webrev due to single line change. On 20-Jul-2016, at 11:41 am, Rajeev Chamyal wrote: Hello Avik, Line 67 can be removed from test. Regards, Rajeev Chamyal From: Avik Niyogi Sent: 20 July 2016 11:30 To: Rajeev Chamyal Cc: Praveen Srivastava; Alexandr Scherbatiy; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: 8161470: [TEST_BUG] Failure javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java A gentle reminder, please review my code changes. With Regards, Avik Niyogi On 19-Jul-2016, at 1:31 pm, Alexandr Scherbatiy wrote: The fix looks good to me. Thanks, Alexandr. On 7/19/2016 9:45 AM, Avik Niyogi wrote: Hi All, Kindly review the fix for JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8161470 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Eaniyogi/8161470/webrev.00/"http://cr.openjdk.java.net/~aniyogi/8161470/webrev.00/ Issue: This test consistently (12/12) fails on OS X 10.10 and also fails on Ubuntu 14.04. Cause: Due to quirk in robot.delay the UI was not getting appropriate behaviour response. Fix: Appropriate Robot methods were used to fix this. With Regards, Avik Niyogi -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Wed Jul 20 07:18:49 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 20 Jul 2016 10:18:49 +0300 Subject: [9] Review request for 8160087: Change IOOBE to warning in the scenarios when it had not being thrown before the JDK-8078514 In-Reply-To: References: <19eeb5bb-18bc-85b2-7eaf-f16bfb6a0f9d@oracle.com> <4bcb6a4a-030c-fea5-30d5-33ec1c0ff2c1@oracle.com> <578DF340.8060204@oracle.com> <7e874ada-48e0-ec9a-da52-1cbf5cd519c7@oracle.com> <578E1564.4010007@oracle.com> Message-ID: <66bd44af-5787-7a9b-57f5-43af52e9c5e5@oracle.com> On 7/19/2016 4:06 PM, Alexandr Scherbatiy wrote: > On 7/19/2016 2:56 PM, Semyon Sadetsky wrote: >> On 19.07.2016 14:20, Alexandr Scherbatiy wrote: >>> >>> The fix prints the warning method in case of wrong row sorter usage. >>> How often this can happen? Could the large number of the messages >>> overflow a user output? >> In the FilePane this happened only once after the initial file list >> loading. > I am just worrying that in a user application which does not > properly use the row sorter there can be a lot of such warnings. And > it could be some library which he can't be able to update. Is it > possible to show the warning only once? Yes. See the updated webrev: http://cr.openjdk.java.net/~ssadetsky/8160087/webrev.01/ --Semyon > > Thanks, > Alexandr. > >> >> --Semyon >>> >>> Thanks, >>> Alexandr. >>> >>> On 7/19/2016 12:30 PM, Semyon Sadetsky wrote: >>>> >>>> >>>> On 19.07.2016 12:18, Alexandr Scherbatiy wrote: >>>>> On 7/18/2016 11:46 AM, Semyon Sadetsky wrote: >>>>>> Hello, >>>>>> >>>>>> Please review fix for JDK9: >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160087 >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8160087/webrev.00/ >>>>>> >>>>>> A warning is added to avoid issues in user code to throw >>>>>> exceptions which were masked before. See bug descriptions for >>>>>> details. >>>>> Should this behavior (which exists for long time) be specified >>>>> in the >>>>> DefaultRowSorter.convertRowIndexToView()/convertRowIndexToModel() >>>>> javadoc? >>>> This was not a >>>> DefaultRowSorter.convertRowIndexToView()/convertRowIndexToModel() >>>> issue. It was a mistake in the FilePane class. >>>> RowSorter's javadoc mentions the correct way to use it: >>>> >>>> The view invokes a model change method when the underlying model >>>> has changed. There may be order dependencies in how the events are >>>> delivered, so a RowSorter should not update its mapping until one >>>> of these methods is invoked. >>>> >>>> --Semyon >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>>> >>>>>> --Semyon >>>>>> >>>>> >>>> >>> >> > From robin.stevens at scz.be Wed Jul 20 08:37:47 2016 From: robin.stevens at scz.be (Robin Stevens) Date: Wed, 20 Jul 2016 10:37:47 +0200 Subject: [9] Review Request: 8161664: Memory leak in com.apple.laf.AquaProgressBarUI: removed progress bar still referenced Message-ID: Hello, please review this patch for issue JDK-8161664: Bug: https://bugs.openjdk.java.net/browse/JDK-8161664 Patch: http://cr.openjdk.java.net/~rstevens/8161664/webrev.00/ The problem is that in certain scenarios, the Timer in the Animator of the AquaProgressBarUI does not get stopped when the progress bar is removed from the Swing hierarchy. Several approaches were discussed in another thread ( http://mail.openjdk.java.net/pipermail/swing-dev/2016-July/006330.html). In the linked webrev, I opted to use the same approach as what is done in the BasicProgressBarUI class: only start the timer when the progress bar is displayable. To achieve this, I wrapped all calls to startAnimationTimer with an if statement that checks the displayable state of the progress bar. There is one call to startAnimationTimer that is not adjusted. That call is only triggered from the paint method, which in turn is only triggered if the progress bar is displayable. As such, the if check was not needed there (imo). The patch includes a test, which fails without the fix and succeeds afterwards. Thanks, Robin -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajit.ghaisas at oracle.com Wed Jul 20 10:50:05 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Wed, 20 Jul 2016 03:50:05 -0700 (PDT) Subject: [9] Fix for JDK-7096375 : Swing ignores first click after decreasing system's time In-Reply-To: References: <459d9470-c5bf-44d5-bb57-c9ad3846a599@default> Message-ID: Hi, I have modified the test as per suggestion. Please review the updated webrev : http://cr.openjdk.java.net/~aghaisas/7096375/webrev.01/ Regards, Ajit -----Original Message----- From: Alexandr Scherbatiy Sent: Tuesday, July 19, 2016 2:33 PM To: Ajit Ghaisas; swing-dev at openjdk.java.net; Rajeev Chamyal Subject: Re: [9] Fix for JDK-7096375 : Swing ignores first click after decreasing system's time On 7/18/2016 3:27 PM, Ajit Ghaisas wrote: > Hi, > > Bug : > https://bugs.openjdk.java.net/browse/JDK-7096375 > Swing ignores first click after decreasing system's time. > > Fix : > BasicButtonListener keeps track of the last time when a button is pressed. > This is used while discarding mouse press events to handle multiClickThreshold. > The condition to discard mouse press event is corrected. > > Webrev : > http://cr.openjdk.java.net/~aghaisas/7096375/webrev.00/ > > Request you to review. The template used for the test is rather old. It is better to use CountDownLatch for the manual test synchronization. Could you rewrite the test using the TitledBorderTest as a sample: http://hg.openjdk.java.net/jdk9/client/jdk/file/233b59b7ea2f/test/javax/swing/LookAndFeel/6439354/TitledBorderTest.java There can be added two simple changes. The thread creation is not necessary because the runnable can be directly executed by SwingUtilities.invokeAndWait(). The timeout can be added to the latch.await() call. Thanks, Alexandr. > > Regards, > Ajit From alexandr.scherbatiy at oracle.com Wed Jul 20 11:26:40 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Wed, 20 Jul 2016 14:26:40 +0300 Subject: [9] Review Request: 8161664: Memory leak in com.apple.laf.AquaProgressBarUI: removed progress bar still referenced In-Reply-To: References: Message-ID: The fix looks good to me. Thanks, Alexandr. On 7/20/2016 11:37 AM, Robin Stevens wrote: > Hello, > > please review this patch for issue JDK-8161664: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8161664 > Patch: http://cr.openjdk.java.net/~rstevens/8161664/webrev.00/ > > > > The problem is that in certain scenarios, the Timer in the Animator of > the AquaProgressBarUI does not get stopped when the progress bar is > removed from the Swing hierarchy. > > Several approaches were discussed in another thread > (http://mail.openjdk.java.net/pipermail/swing-dev/2016-July/006330.html). > In the linked webrev, I opted to use the same approach as what is done > in the BasicProgressBarUI class: only start the timer when the > progress bar is displayable. > > To achieve this, I wrapped all calls to startAnimationTimer with an if > statement that checks the displayable state of the progress bar. > > There is one call to startAnimationTimer that is not adjusted. That > call is only triggered from the paint method, which in turn is only > triggered if the progress bar is displayable. As such, the if check > was not needed there (imo). > > The patch includes a test, which fails without the fix and succeeds > afterwards. > > Thanks, > > Robin From alexandr.scherbatiy at oracle.com Wed Jul 20 11:29:39 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Wed, 20 Jul 2016 14:29:39 +0300 Subject: [9] Review request for 8160087: Change IOOBE to warning in the scenarios when it had not being thrown before the JDK-8078514 In-Reply-To: <66bd44af-5787-7a9b-57f5-43af52e9c5e5@oracle.com> References: <19eeb5bb-18bc-85b2-7eaf-f16bfb6a0f9d@oracle.com> <4bcb6a4a-030c-fea5-30d5-33ec1c0ff2c1@oracle.com> <578DF340.8060204@oracle.com> <7e874ada-48e0-ec9a-da52-1cbf5cd519c7@oracle.com> <578E1564.4010007@oracle.com> <66bd44af-5787-7a9b-57f5-43af52e9c5e5@oracle.com> Message-ID: On 7/20/2016 10:18 AM, Semyon Sadetsky wrote: > On 7/19/2016 4:06 PM, Alexandr Scherbatiy wrote: > >> On 7/19/2016 2:56 PM, Semyon Sadetsky wrote: >>> On 19.07.2016 14:20, Alexandr Scherbatiy wrote: >>>> >>>> The fix prints the warning method in case of wrong row sorter >>>> usage. How often this can happen? Could the large number of the >>>> messages overflow a user output? >>> In the FilePane this happened only once after the initial file list >>> loading. >> I am just worrying that in a user application which does not >> properly use the row sorter there can be a lot of such warnings. And >> it could be some library which he can't be able to update. Is it >> possible to show the warning only once? > Yes. See the updated webrev: > http://cr.openjdk.java.net/~ssadetsky/8160087/webrev.01/ A property which should be used by users needs to have the CCC request. I believe that printing the warning message only once is enough. Thanks, Alexandr. > > --Semyon >> >> Thanks, >> Alexandr. >> >>> >>> --Semyon >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 7/19/2016 12:30 PM, Semyon Sadetsky wrote: >>>>> >>>>> >>>>> On 19.07.2016 12:18, Alexandr Scherbatiy wrote: >>>>>> On 7/18/2016 11:46 AM, Semyon Sadetsky wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review fix for JDK9: >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160087 >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8160087/webrev.00/ >>>>>>> >>>>>>> A warning is added to avoid issues in user code to throw >>>>>>> exceptions which were masked before. See bug descriptions for >>>>>>> details. >>>>>> Should this behavior (which exists for long time) be specified >>>>>> in the >>>>>> DefaultRowSorter.convertRowIndexToView()/convertRowIndexToModel() >>>>>> javadoc? >>>>> This was not a >>>>> DefaultRowSorter.convertRowIndexToView()/convertRowIndexToModel() >>>>> issue. It was a mistake in the FilePane class. >>>>> RowSorter's javadoc mentions the correct way to use it: >>>>> >>>>> The view invokes a model change method when the underlying model >>>>> has changed. There may be order dependencies in how the events are >>>>> delivered, so a RowSorter should not update its mapping until one >>>>> of these methods is invoked. >>>>> >>>>> --Semyon >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>>> >>>>>>> --Semyon >>>>>>> >>>>>> >>>>> >>>> >>> >> > From alexandr.scherbatiy at oracle.com Wed Jul 20 11:43:25 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Wed, 20 Jul 2016 14:43:25 +0300 Subject: [9] Fix for JDK-7096375 : Swing ignores first click after decreasing system's time In-Reply-To: References: <459d9470-c5bf-44d5-bb57-c9ad3846a599@default> Message-ID: On 7/20/2016 1:50 PM, Ajit Ghaisas wrote: > Hi, > > I have modified the test as per suggestion. > > Please review the updated webrev : > http://cr.openjdk.java.net/~aghaisas/7096375/webrev.01/ It is better to rethrow the exceptions during UI creation and disposing because it also means some unexpected behavior. Thanks, Alexandr. > > Regards, > Ajit > > -----Original Message----- > From: Alexandr Scherbatiy > Sent: Tuesday, July 19, 2016 2:33 PM > To: Ajit Ghaisas; swing-dev at openjdk.java.net; Rajeev Chamyal > Subject: Re: [9] Fix for JDK-7096375 : Swing ignores first click after decreasing system's time > > On 7/18/2016 3:27 PM, Ajit Ghaisas wrote: >> Hi, >> >> Bug : >> https://bugs.openjdk.java.net/browse/JDK-7096375 >> Swing ignores first click after decreasing system's time. >> >> Fix : >> BasicButtonListener keeps track of the last time when a button is pressed. >> This is used while discarding mouse press events to handle multiClickThreshold. >> The condition to discard mouse press event is corrected. >> >> Webrev : >> http://cr.openjdk.java.net/~aghaisas/7096375/webrev.00/ >> >> Request you to review. > The template used for the test is rather old. It is better to use CountDownLatch for the manual test synchronization. > Could you rewrite the test using the TitledBorderTest as a sample: > http://hg.openjdk.java.net/jdk9/client/jdk/file/233b59b7ea2f/test/javax/swing/LookAndFeel/6439354/TitledBorderTest.java > > There can be added two simple changes. The thread creation is not necessary because the runnable can be directly executed by SwingUtilities.invokeAndWait(). The timeout can be added to the > latch.await() call. > > Thanks, > Alexandr. >> Regards, >> Ajit From alexandr.scherbatiy at oracle.com Wed Jul 20 11:46:15 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Wed, 20 Jul 2016 14:46:15 +0300 Subject: 8161470: [TEST_BUG] Failure javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java In-Reply-To: References: <948581F9-11FB-4664-A85C-570B3D239FE6@oracle.com> <4e122507-0132-4c7a-0fc8-270f17cc9a07@oracle.com> <5e163ade-7390-4ff3-be25-edb094359c2d@default> <6E92FD31-D4E7-4A53-938C-A4163187EB0E@oracle.com> Message-ID: <9d158ea0-a518-0c49-5aac-25e698f53406@oracle.com> The fix looks good to me. Thanks, Alexandr. On 7/20/2016 9:34 AM, Rajeev Chamyal wrote: > > Looks fine to me. > > Regards, > > Rajeev Chamyal > > *From:*Avik Niyogi > *Sent:* 20 July 2016 11:52 > *To:* Rajeev Chamyal > *Cc:* Praveen Srivastava; Alexander Scherbatiy; swing-dev at openjdk.java.net > *Subject:* Re: 8161470: [TEST_BUG] Failure > javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java > > Hi Rajeev, > > Updated on same webrev due to single line change. > > On 20-Jul-2016, at 11:41 am, Rajeev Chamyal > > wrote: > > Hello Avik, > > Line 67 can be removed from test. > > Regards, > > Rajeev Chamyal > > *From:*Avik Niyogi > *Sent:*20 July 2016 11:30 > *To:*Rajeev Chamyal > *Cc:*Praveen Srivastava; Alexandr Scherbatiy; > swing-dev at openjdk.java.net > *Subject:*Re: 8161470: [TEST_BUG] Failure > javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java > > A gentle reminder, please review my code changes. > > With Regards, > > Avik Niyogi > > On 19-Jul-2016, at 1:31 pm, Alexandr Scherbatiy > > wrote: > > > The fix looks good to me. > > Thanks, > Alexandr. > > On 7/19/2016 9:45 AM, Avik Niyogi wrote: > > Hi All, > > Kindly review the fix for JDK9. > > *Bug: https://bugs.openjdk.java.net/browse/JDK-8161470* > > *Webrev: > http://cr.openjdk.java.net/~aniyogi/8161470/webrev.00/ > * > > *Issue: *This test consistently (12/12) fails on OS X > 10.10 and also fails on Ubuntu 14.04. > > *Cause: * Due to quirk in robot.delay the UI was not > getting appropriate behaviour response. > > *Fix:* Appropriate Robot methods were used to fix this. > > With Regards, > > Avik Niyogi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajit.ghaisas at oracle.com Wed Jul 20 12:20:18 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Wed, 20 Jul 2016 05:20:18 -0700 (PDT) Subject: [9] Fix for JDK-7096375 : Swing ignores first click after decreasing system's time In-Reply-To: References: <459d9470-c5bf-44d5-bb57-c9ad3846a599@default> Message-ID: <362267dd-ae7d-4253-a846-5cb26ed46103@default> Hi, Added throwing exception in case create UI or dispose UI fails. Here is the updated webrev: http://cr.openjdk.java.net/~aghaisas/7096375/webrev.02/ Regards, Ajit -----Original Message----- From: Alexandr Scherbatiy Sent: Wednesday, July 20, 2016 5:13 PM To: Ajit Ghaisas; swing-dev at openjdk.java.net; Rajeev Chamyal Subject: Re: [9] Fix for JDK-7096375 : Swing ignores first click after decreasing system's time On 7/20/2016 1:50 PM, Ajit Ghaisas wrote: > Hi, > > I have modified the test as per suggestion. > > Please review the updated webrev : > http://cr.openjdk.java.net/~aghaisas/7096375/webrev.01/ It is better to rethrow the exceptions during UI creation and disposing because it also means some unexpected behavior. Thanks, Alexandr. > > Regards, > Ajit > > -----Original Message----- > From: Alexandr Scherbatiy > Sent: Tuesday, July 19, 2016 2:33 PM > To: Ajit Ghaisas; swing-dev at openjdk.java.net; Rajeev Chamyal > Subject: Re: [9] Fix for JDK-7096375 : Swing ignores first click after > decreasing system's time > > On 7/18/2016 3:27 PM, Ajit Ghaisas wrote: >> Hi, >> >> Bug : >> https://bugs.openjdk.java.net/browse/JDK-7096375 >> Swing ignores first click after decreasing system's time. >> >> Fix : >> BasicButtonListener keeps track of the last time when a button is pressed. >> This is used while discarding mouse press events to handle multiClickThreshold. >> The condition to discard mouse press event is corrected. >> >> Webrev : >> http://cr.openjdk.java.net/~aghaisas/7096375/webrev.00/ >> >> Request you to review. > The template used for the test is rather old. It is better to use CountDownLatch for the manual test synchronization. > Could you rewrite the test using the TitledBorderTest as a sample: > http://hg.openjdk.java.net/jdk9/client/jdk/file/233b59b7ea2f/test/java > x/swing/LookAndFeel/6439354/TitledBorderTest.java > > There can be added two simple changes. The thread creation is not > necessary because the runnable can be directly executed by > SwingUtilities.invokeAndWait(). The timeout can be added to the > latch.await() call. > > Thanks, > Alexandr. >> Regards, >> Ajit From alexandr.scherbatiy at oracle.com Wed Jul 20 12:37:25 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Wed, 20 Jul 2016 15:37:25 +0300 Subject: [9] Fix for JDK-7096375 : Swing ignores first click after decreasing system's time In-Reply-To: <362267dd-ae7d-4253-a846-5cb26ed46103@default> References: <459d9470-c5bf-44d5-bb57-c9ad3846a599@default> <362267dd-ae7d-4253-a846-5cb26ed46103@default> Message-ID: The fix looks good to me. Thanks, Alexandr. On 7/20/2016 3:20 PM, Ajit Ghaisas wrote: > Hi, > > Added throwing exception in case create UI or dispose UI fails. > Here is the updated webrev: > http://cr.openjdk.java.net/~aghaisas/7096375/webrev.02/ > > Regards, > Ajit > > > -----Original Message----- > From: Alexandr Scherbatiy > Sent: Wednesday, July 20, 2016 5:13 PM > To: Ajit Ghaisas; swing-dev at openjdk.java.net; Rajeev Chamyal > Subject: Re: [9] Fix for JDK-7096375 : Swing ignores first click after decreasing system's time > > On 7/20/2016 1:50 PM, Ajit Ghaisas wrote: >> Hi, >> >> I have modified the test as per suggestion. >> >> Please review the updated webrev : >> http://cr.openjdk.java.net/~aghaisas/7096375/webrev.01/ > It is better to rethrow the exceptions during UI creation and disposing because it also means some unexpected behavior. > > Thanks, > Alexandr. >> Regards, >> Ajit >> >> -----Original Message----- >> From: Alexandr Scherbatiy >> Sent: Tuesday, July 19, 2016 2:33 PM >> To: Ajit Ghaisas; swing-dev at openjdk.java.net; Rajeev Chamyal >> Subject: Re: [9] Fix for JDK-7096375 : Swing ignores first click after >> decreasing system's time >> >> On 7/18/2016 3:27 PM, Ajit Ghaisas wrote: >>> Hi, >>> >>> Bug : >>> https://bugs.openjdk.java.net/browse/JDK-7096375 >>> Swing ignores first click after decreasing system's time. >>> >>> Fix : >>> BasicButtonListener keeps track of the last time when a button is pressed. >>> This is used while discarding mouse press events to handle multiClickThreshold. >>> The condition to discard mouse press event is corrected. >>> >>> Webrev : >>> http://cr.openjdk.java.net/~aghaisas/7096375/webrev.00/ >>> >>> Request you to review. >> The template used for the test is rather old. It is better to use CountDownLatch for the manual test synchronization. >> Could you rewrite the test using the TitledBorderTest as a sample: >> http://hg.openjdk.java.net/jdk9/client/jdk/file/233b59b7ea2f/test/java >> x/swing/LookAndFeel/6439354/TitledBorderTest.java >> >> There can be added two simple changes. The thread creation is not >> necessary because the runnable can be directly executed by >> SwingUtilities.invokeAndWait(). The timeout can be added to the >> latch.await() call. >> >> Thanks, >> Alexandr. >>> Regards, >>> Ajit From volker.simonis at gmail.com Wed Jul 20 13:29:41 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 20 Jul 2016 15:29:41 +0200 Subject: [OpenJDK 2D-Dev] RFR(L): 8160974: [TESTBUG] Mark more headful tests with @key headful. In-Reply-To: <1296e1b0-fa40-81cb-1083-edad0e0bf915@oracle.com> References: <87923b42e8c1478d8b4227e136fe69a5@DEWDFE13DE09.global.corp.sap> <1296e1b0-fa40-81cb-1083-edad0e0bf915@oracle.com> Message-ID: Hi G?tz, your change looks good. Thanks a lot for cleaning up all these tests! I only found one problem which you should fix: test/java/awt/Frame/MiscUndecorated/RepaintTest.java @@ -1,6 +1,6 @@ -/* +\/* Seems like there's an extra backslash at the beginning of the first line. You may also want to '@test' on a line by itself like you've done it for all the other tests in test/javax/swing/JTable/7068740/bug7068740.java /* @test - @bug 7068740 - @summary JTable wrapped in JLayer can't use PGUP/PGDOWN keys - @author Vladislav Karnaukhov - @run main bug7068740 -*/ + * @key headful + * @bug 7068740 + * @summary JTable wrapped in JLayer can't use PGUP/PGDOWN keys + * @author Vladislav Karnaukhov + * @run main bug7068740 + */ And correctly indent in the following two cases: diff --git a/test/javax/swing/LookAndFeel/6897701/JMenuItemsTest.java b/test/javax/swing/LookAndFeel/6897701/JMenuItemsTest.java --- a/test/javax/swing/LookAndFeel/6897701/JMenuItemsTest.java +++ b/test/javax/swing/LookAndFeel/6897701/JMenuItemsTest.java @@ -23,6 +23,7 @@ /* * @test + * @key headful * @bug 6897701 and: diff --git a/test/javax/swing/plaf/synth/7158712/bug7158712.java b/test/javax/swing/plaf/synth/7158712/bug7158712.java --- a/test/javax/swing/plaf/synth/7158712/bug7158712.java +++ b/test/javax/swing/plaf/synth/7158712/bug7158712.java @@ -21,7 +21,9 @@ * questions. */ -/* @test +/* + @test + @key headful @bug 7158712 There's no need to prepare a new webrev. I won't go through it one more time anyway :) Regards, Volker On Tue, Jul 19, 2016 at 9:16 PM, Sergey Bylokhov wrote: > Look fine to me. > > On 07.07.16 18:01, Lindenmaier, Goetz wrote: >> >> Hi, >> >> >> >> This change is ?L? because there are changes to a lot of files, but the >> changes >> >> are all similar, so it?s rather easy to review. >> >> Similar to 8159690 I added @key headful to another around 600 tests. >> >> I used different patterns to grep for the headful exceptions. >> >> >> >> These are now all I could find with grepping and the like. I have around >> >> 80 failing tests remaining, where a row will probably also depend on >> >> a display, but I want to look at them more closely, so I don?t want >> >> to include them here. >> >> >> >> Please review this change: >> >> http://cr.openjdk.java.net/~goetz/wr16/8160974-headful/webrev.01/ >> >> >> >> Best regards, >> >> Goetz. >> >> >> >> >> > > > -- > Best regards, Sergey. From semyon.sadetsky at oracle.com Wed Jul 20 13:46:23 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 20 Jul 2016 16:46:23 +0300 Subject: [9] Review request for 8160087: Change IOOBE to warning in the scenarios when it had not being thrown before the JDK-8078514 In-Reply-To: References: <19eeb5bb-18bc-85b2-7eaf-f16bfb6a0f9d@oracle.com> <4bcb6a4a-030c-fea5-30d5-33ec1c0ff2c1@oracle.com> <578DF340.8060204@oracle.com> <7e874ada-48e0-ec9a-da52-1cbf5cd519c7@oracle.com> <578E1564.4010007@oracle.com> <66bd44af-5787-7a9b-57f5-43af52e9c5e5@oracle.com> Message-ID: <413e1a77-b95e-15b3-203e-ccecccff3ec5@oracle.com> On 7/20/2016 2:29 PM, Alexandr Scherbatiy wrote: > On 7/20/2016 10:18 AM, Semyon Sadetsky wrote: >> On 7/19/2016 4:06 PM, Alexandr Scherbatiy wrote: >> >>> On 7/19/2016 2:56 PM, Semyon Sadetsky wrote: >>>> On 19.07.2016 14:20, Alexandr Scherbatiy wrote: >>>>> >>>>> The fix prints the warning method in case of wrong row sorter >>>>> usage. How often this can happen? Could the large number of the >>>>> messages overflow a user output? >>>> In the FilePane this happened only once after the initial file list >>>> loading. >>> I am just worrying that in a user application which does not >>> properly use the row sorter there can be a lot of such warnings. And >>> it could be some library which he can't be able to update. Is it >>> possible to show the warning only once? >> Yes. See the updated webrev: >> http://cr.openjdk.java.net/~ssadetsky/8160087/webrev.01/ > A property which should be used by users needs to have the CCC > request. It is added on the off-chance. It doesn't merit to be a documented property. --Semyon > I believe that printing the warning message only once is enough. > > Thanks, > Alexandr. >> >> --Semyon >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> --Semyon >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 7/19/2016 12:30 PM, Semyon Sadetsky wrote: >>>>>> >>>>>> >>>>>> On 19.07.2016 12:18, Alexandr Scherbatiy wrote: >>>>>>> On 7/18/2016 11:46 AM, Semyon Sadetsky wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review fix for JDK9: >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160087 >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8160087/webrev.00/ >>>>>>>> >>>>>>>> A warning is added to avoid issues in user code to throw >>>>>>>> exceptions which were masked before. See bug descriptions for >>>>>>>> details. >>>>>>> Should this behavior (which exists for long time) be specified >>>>>>> in the >>>>>>> DefaultRowSorter.convertRowIndexToView()/convertRowIndexToModel() >>>>>>> javadoc? >>>>>> This was not a >>>>>> DefaultRowSorter.convertRowIndexToView()/convertRowIndexToModel() >>>>>> issue. It was a mistake in the FilePane class. >>>>>> RowSorter's javadoc mentions the correct way to use it: >>>>>> >>>>>> The view invokes a model change method when the underlying model >>>>>> has changed. There may be order dependencies in how the events >>>>>> are delivered, so a RowSorter should not update its mapping until >>>>>> one of these methods is invoked. >>>>>> >>>>>> --Semyon >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>>> >>>>>>>> --Semyon >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From goetz.lindenmaier at sap.com Wed Jul 20 13:53:26 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 20 Jul 2016 13:53:26 +0000 Subject: [OpenJDK 2D-Dev] RFR(L): 8160974: [TESTBUG] Mark more headful tests with @key headful. In-Reply-To: References: <87923b42e8c1478d8b4227e136fe69a5@DEWDFE13DE09.global.corp.sap> <1296e1b0-fa40-81cb-1083-edad0e0bf915@oracle.com> Message-ID: Hi Volker, thanks for that thorough review, the wrong \ is a really good catch! I did'nt upload a new webrev, but maybe the incremental diff Is useful: http://cr.openjdk.java.net/~goetz/wr16/8160974-headful/webrev.02/incremental_fixes.patch Best regards, Goetz. > -----Original Message----- > From: Volker Simonis [mailto:volker.simonis at gmail.com] > Sent: Mittwoch, 20. Juli 2016 15:30 > To: Sergey Bylokhov > Cc: Lindenmaier, Goetz ; awt- > dev at openjdk.java.net; swing-dev at openjdk.java.net; 2d-dev <2d- > dev at openjdk.java.net> > Subject: Re: [OpenJDK 2D-Dev] RFR(L): 8160974: [TESTBUG] > Mark more headful tests with @key headful. > > Hi G?tz, > > your change looks good. Thanks a lot for cleaning up all these tests! > > I only found one problem which you should fix: > > test/java/awt/Frame/MiscUndecorated/RepaintTest.java > > @@ -1,6 +1,6 @@ > -/* > +\/* > > Seems like there's an extra backslash at the beginning of the first line. > > You may also want to '@test' on a line by itself like you've done it > for all the other tests in > test/javax/swing/JTable/7068740/bug7068740.java > > /* @test > - @bug 7068740 > - @summary JTable wrapped in JLayer can't use PGUP/PGDOWN keys > - @author Vladislav Karnaukhov > - @run main bug7068740 > -*/ > + * @key headful > + * @bug 7068740 > + * @summary JTable wrapped in JLayer can't use PGUP/PGDOWN keys > + * @author Vladislav Karnaukhov > + * @run main bug7068740 > + */ > > And correctly indent in the following two cases: > > diff --git a/test/javax/swing/LookAndFeel/6897701/JMenuItemsTest.java > b/test/javax/swing/LookAndFeel/6897701/JMenuItemsTest.java > --- a/test/javax/swing/LookAndFeel/6897701/JMenuItemsTest.java > +++ b/test/javax/swing/LookAndFeel/6897701/JMenuItemsTest.java > @@ -23,6 +23,7 @@ > > /* > * @test > + * @key headful > * @bug 6897701 > > and: > > diff --git a/test/javax/swing/plaf/synth/7158712/bug7158712.java > b/test/javax/swing/plaf/synth/7158712/bug7158712.java > --- a/test/javax/swing/plaf/synth/7158712/bug7158712.java > +++ b/test/javax/swing/plaf/synth/7158712/bug7158712.java > @@ -21,7 +21,9 @@ > * questions. > */ > > -/* @test > +/* > + @test > + @key headful > @bug 7158712 > > > There's no need to prepare a new webrev. I won't go through it one > more time anyway :) > > Regards, > Volker > > > On Tue, Jul 19, 2016 at 9:16 PM, Sergey Bylokhov > wrote: > > Look fine to me. > > > > On 07.07.16 18:01, Lindenmaier, Goetz wrote: > >> > >> Hi, > >> > >> > >> > >> This change is ?L? because there are changes to a lot of files, but the > >> changes > >> > >> are all similar, so it?s rather easy to review. > >> > >> Similar to 8159690 I added @key headful to another around 600 tests. > >> > >> I used different patterns to grep for the headful exceptions. > >> > >> > >> > >> These are now all I could find with grepping and the like. I have around > >> > >> 80 failing tests remaining, where a row will probably also depend on > >> > >> a display, but I want to look at them more closely, so I don?t want > >> > >> to include them here. > >> > >> > >> > >> Please review this change: > >> > >> http://cr.openjdk.java.net/~goetz/wr16/8160974-headful/webrev.01/ > >> > >> > >> > >> Best regards, > >> > >> Goetz. > >> > >> > >> > >> > >> > > > > > > -- > > Best regards, Sergey. From rajeev.chamyal at oracle.com Thu Jul 21 05:46:00 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Wed, 20 Jul 2016 22:46:00 -0700 (PDT) Subject: [9] Fix for JDK-7096375 : Swing ignores first click after decreasing system's time In-Reply-To: <362267dd-ae7d-4253-a846-5cb26ed46103@default> References: <459d9470-c5bf-44d5-bb57-c9ad3846a599@default> <362267dd-ae7d-4253-a846-5cb26ed46103@default> Message-ID: <653f7834-3eac-4a89-990c-cd7386b8f331@default> Hello Ajit, Frame dispose is called twice in case pass/fail button are pressed. Regards, Rajeev Chamyal -----Original Message----- From: Ajit Ghaisas Sent: 20 July 2016 17:50 To: Alexander Scherbatiy; swing-dev at openjdk.java.net; Rajeev Chamyal Subject: RE: [9] Fix for JDK-7096375 : Swing ignores first click after decreasing system's time Hi, Added throwing exception in case create UI or dispose UI fails. Here is the updated webrev: http://cr.openjdk.java.net/~aghaisas/7096375/webrev.02/ Regards, Ajit -----Original Message----- From: Alexandr Scherbatiy Sent: Wednesday, July 20, 2016 5:13 PM To: Ajit Ghaisas; swing-dev at openjdk.java.net; Rajeev Chamyal Subject: Re: [9] Fix for JDK-7096375 : Swing ignores first click after decreasing system's time On 7/20/2016 1:50 PM, Ajit Ghaisas wrote: > Hi, > > I have modified the test as per suggestion. > > Please review the updated webrev : > http://cr.openjdk.java.net/~aghaisas/7096375/webrev.01/ It is better to rethrow the exceptions during UI creation and disposing because it also means some unexpected behavior. Thanks, Alexandr. > > Regards, > Ajit > > -----Original Message----- > From: Alexandr Scherbatiy > Sent: Tuesday, July 19, 2016 2:33 PM > To: Ajit Ghaisas; swing-dev at openjdk.java.net; Rajeev Chamyal > Subject: Re: [9] Fix for JDK-7096375 : Swing ignores first click after > decreasing system's time > > On 7/18/2016 3:27 PM, Ajit Ghaisas wrote: >> Hi, >> >> Bug : >> https://bugs.openjdk.java.net/browse/JDK-7096375 >> Swing ignores first click after decreasing system's time. >> >> Fix : >> BasicButtonListener keeps track of the last time when a button is pressed. >> This is used while discarding mouse press events to handle multiClickThreshold. >> The condition to discard mouse press event is corrected. >> >> Webrev : >> http://cr.openjdk.java.net/~aghaisas/7096375/webrev.00/ >> >> Request you to review. > The template used for the test is rather old. It is better to use CountDownLatch for the manual test synchronization. > Could you rewrite the test using the TitledBorderTest as a sample: > http://hg.openjdk.java.net/jdk9/client/jdk/file/233b59b7ea2f/test/java > x/swing/LookAndFeel/6439354/TitledBorderTest.java > > There can be added two simple changes. The thread creation is not > necessary because the runnable can be directly executed by > SwingUtilities.invokeAndWait(). The timeout can be added to the > latch.await() call. > > Thanks, > Alexandr. >> Regards, >> Ajit From ajit.ghaisas at oracle.com Thu Jul 21 06:10:49 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Wed, 20 Jul 2016 23:10:49 -0700 (PDT) Subject: [9] Fix for JDK-7096375 : Swing ignores first click after decreasing system's time In-Reply-To: <653f7834-3eac-4a89-990c-cd7386b8f331@default> References: <459d9470-c5bf-44d5-bb57-c9ad3846a599@default> <362267dd-ae7d-4253-a846-5cb26ed46103@default> <653f7834-3eac-4a89-990c-cd7386b8f331@default> Message-ID: Good catch. I have corrected the test case. Please review. http://cr.openjdk.java.net/~aghaisas/7096375/webrev.03/ Regards, Ajit -----Original Message----- From: Rajeev Chamyal Sent: Thursday, July 21, 2016 11:16 AM To: Ajit Ghaisas; Alexander Scherbatiy; swing-dev at openjdk.java.net Subject: RE: [9] Fix for JDK-7096375 : Swing ignores first click after decreasing system's time Hello Ajit, Frame dispose is called twice in case pass/fail button are pressed. Regards, Rajeev Chamyal -----Original Message----- From: Ajit Ghaisas Sent: 20 July 2016 17:50 To: Alexander Scherbatiy; swing-dev at openjdk.java.net; Rajeev Chamyal Subject: RE: [9] Fix for JDK-7096375 : Swing ignores first click after decreasing system's time Hi, Added throwing exception in case create UI or dispose UI fails. Here is the updated webrev: http://cr.openjdk.java.net/~aghaisas/7096375/webrev.02/ Regards, Ajit -----Original Message----- From: Alexandr Scherbatiy Sent: Wednesday, July 20, 2016 5:13 PM To: Ajit Ghaisas; swing-dev at openjdk.java.net; Rajeev Chamyal Subject: Re: [9] Fix for JDK-7096375 : Swing ignores first click after decreasing system's time On 7/20/2016 1:50 PM, Ajit Ghaisas wrote: > Hi, > > I have modified the test as per suggestion. > > Please review the updated webrev : > http://cr.openjdk.java.net/~aghaisas/7096375/webrev.01/ It is better to rethrow the exceptions during UI creation and disposing because it also means some unexpected behavior. Thanks, Alexandr. > > Regards, > Ajit > > -----Original Message----- > From: Alexandr Scherbatiy > Sent: Tuesday, July 19, 2016 2:33 PM > To: Ajit Ghaisas; swing-dev at openjdk.java.net; Rajeev Chamyal > Subject: Re: [9] Fix for JDK-7096375 : Swing ignores first click after > decreasing system's time > > On 7/18/2016 3:27 PM, Ajit Ghaisas wrote: >> Hi, >> >> Bug : >> https://bugs.openjdk.java.net/browse/JDK-7096375 >> Swing ignores first click after decreasing system's time. >> >> Fix : >> BasicButtonListener keeps track of the last time when a button is pressed. >> This is used while discarding mouse press events to handle multiClickThreshold. >> The condition to discard mouse press event is corrected. >> >> Webrev : >> http://cr.openjdk.java.net/~aghaisas/7096375/webrev.00/ >> >> Request you to review. > The template used for the test is rather old. It is better to use CountDownLatch for the manual test synchronization. > Could you rewrite the test using the TitledBorderTest as a sample: > http://hg.openjdk.java.net/jdk9/client/jdk/file/233b59b7ea2f/test/java > x/swing/LookAndFeel/6439354/TitledBorderTest.java > > There can be added two simple changes. The thread creation is not > necessary because the runnable can be directly executed by > SwingUtilities.invokeAndWait(). The timeout can be added to the > latch.await() call. > > Thanks, > Alexandr. >> Regards, >> Ajit From semyon.sadetsky at oracle.com Thu Jul 21 08:49:45 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 21 Jul 2016 11:49:45 +0300 Subject: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel In-Reply-To: References: <340c1fa9-7da5-4fcb-9119-0e1e2dcaeb10@default> <9bd7ca3c-2297-0c36-c249-4a9b560275a2@oracle.com> <395e74b7-451e-453e-b552-be2a5bc0e348@default> <30e65d6d-cb35-4c55-b1b2-80752929576a@default> <3d266275-efcd-4d69-bfab-9604467856d1@default> <57877747.3040904@oracle.com> Message-ID: <57908CA9.600@oracle.com> Hello Rajeev, The taskbar icon is ok now. I change the resolution variants from the test a bit: final BaseMultiResolutionImage IMG = new BaseMultiResolutionImage( new BufferedImage[]{generateImage(4, Color.RED), generateImage(10, Color.BLUE)}); And the icon I see in the taskbar and in the button is blue. It seems to me the first resolution variant (red) is more appropriate in this case because its size is closer to the spot. I'm not sure if this is an issue. I have an extra question to you and Alexander. Most native apps on Linux set an array of icons with _NET_WM_ICON. Usually they are [16x16, 32x32, 64x64]. So, desktop environment may select icon of appropriate size. In this fix we are preselecting icon of a specific size in the app and send it to WM. Why not to send array of the resolution variants images and let the desktop environment to select the appropriate one, like native apps do? --Semyon On 19.07.2016 23:26, Rajeev Chamyal wrote: > > Hello Semyon, > > Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8147648/webrev.03/ > > > Regards, > > Rajeev Chamyal > > *From:*Semyon Sadetsky > *Sent:* 14 July 2016 16:58 > *To:* Rajeev Chamyal; swing-dev at openjdk.java.net; Sergey Bylokhov; > Alexander Scherbatiy > *Subject:* Re: [9] Review Request JDK-8147648 [hidpi] > multiresolution image: wrong resolution variant is used as icon in the > Unity panel > > Hi Rajeev, > > I have added 1px border to the icon in your test: > > private static BufferedImage generateImage(int scale, Color c) { > int x = SZ * scale; > BufferedImage img = new BufferedImage(x, x, > BufferedImage.TYPE_INT_RGB); > Graphics g = img.getGraphics(); > if (g != null) { > g.setColor(c); > g.fillRect(0, 0, x, x); > g.setColor(Color.YELLOW); > g.drawRect(0, 0, x-1, x-1); > } > return img; > } > > It seems the icon in the taskbar is not correct for UI scale > 1. > > By the way, graphics object should be disposed using g.dispose() when > it is not needed anymore. > > --Semyon > > On 14.07.2016 10:08, Rajeev Chamyal wrote: > > Hello All, > > Gentle reminder. Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8147648/webrev.02/ > > > Update: simplified the test. > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 22 June 2016 15:46 > *To:* Rajeev Chamyal; Sergey Bylokhov; swing-dev at openjdk.java.net > > *Subject:* Re: [9] Review Request JDK-8147648 [hidpi] > multiresolution image: wrong resolution variant is used as icon in > the Unity panel > > The fix looks good to me. > > Thanks, > Alexandr. > > On 6/22/2016 10:49 AM, Rajeev Chamyal wrote: > > Hello Alexandr, > > Thanks for the review. I have updated webrev as per comments. > > http://cr.openjdk.java.net/~rchamyal/8147648/webrev.01/ > > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 21 June 2016 17:37 > *To:* Rajeev Chamyal; Sergey Bylokhov; > swing-dev at openjdk.java.net > *Subject:* Re: [9] Review Request JDK-8147648 > [hidpi] multiresolution image: wrong resolution variant is > used as icon in the Unity panel > > On 6/21/2016 12:16 PM, Rajeev Chamyal wrote: > > Hello All, > > Please review the following webrev. > > Webrev: > http://cr.openjdk.java.net/~rchamyal/8147648/webrev.00/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8147648 > > Issue: Wrong resolution variant is used as icon in the > Unity panel. > > Cause: The screen transforms are not applied to find the > correct resolution variant image in current implementation. > > Fix: Applied the screen transforms to graphics object. > > > 222 int scaleX = (int)tx.getScaleX(); > 223 int scaleY = (int)tx.getScaleY(); > 224 DataBufferInt buffer = new DataBufferInt(scaleX * > width * scaleY * height); > > The fix is in the shared code and the scale factor can have > floating point value on Windows. (for example 1.5). > It is better to round the final width and height after > scaling them. > > Thanks, > Alexandr. > > Regards, > > Rajeev Chamyal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Thu Jul 21 09:39:13 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 21 Jul 2016 12:39:13 +0300 Subject: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel In-Reply-To: <57908CA9.600@oracle.com> References: <340c1fa9-7da5-4fcb-9119-0e1e2dcaeb10@default> <9bd7ca3c-2297-0c36-c249-4a9b560275a2@oracle.com> <395e74b7-451e-453e-b552-be2a5bc0e348@default> <30e65d6d-cb35-4c55-b1b2-80752929576a@default> <3d266275-efcd-4d69-bfab-9604467856d1@default> <57877747.3040904@oracle.com> <57908CA9.600@oracle.com> Message-ID: <0cfea8e4-b742-dccf-95cb-46e2ac138bfe@oracle.com> On 7/21/2016 11:49 AM, Semyon Sadetsky wrote: > Hello Rajeev, > > The taskbar icon is ok now. > > I change the resolution variants from the test a bit: > > final BaseMultiResolutionImage IMG = new > BaseMultiResolutionImage( > new BufferedImage[]{generateImage(4, > Color.RED), generateImage(10, Color.BLUE)}); > > And the icon I see in the taskbar and in the button is blue. It seems > to me the first resolution variant (red) is more appropriate in this > case because its size is closer to the spot. I'm not sure if this is > an issue. > > I have an extra question to you and Alexander. > Most native apps on Linux set an array of icons with _NET_WM_ICON. > Usually they are [16x16, 32x32, 64x64]. > So, desktop environment may select icon of appropriate size. > In this fix we are preselecting icon of a specific size in the app and > send it to WM. > Why not to send array of the resolution variants images and let the > desktop environment to select the appropriate one, like native apps do? This sounds as good idea. MultiResolutionImage has the special method for this "List getResolutionVariants()". We do the similar on Mac OS X where NSImage with several representations is created from a MultiResolutionImage: http://cr.openjdk.java.net/~alexsch/8028212/webrev.01/src/macosx/classes/sun/lwawt/macosx/CImage.java.udiff.html It has sense to try the same approach on Linux. Thanks, Alexandr. > > > --Semyon > > On 19.07.2016 23:26, Rajeev Chamyal wrote: >> >> Hello Semyon, >> >> Please review the updated webrev. >> >> http://cr.openjdk.java.net/~rchamyal/8147648/webrev.03/ >> >> Regards, >> >> Rajeev Chamyal >> >> *From:*Semyon Sadetsky >> *Sent:* 14 July 2016 16:58 >> *To:* Rajeev Chamyal; swing-dev at openjdk.java.net; Sergey Bylokhov; >> Alexander Scherbatiy >> *Subject:* Re: [9] Review Request JDK-8147648 [hidpi] >> multiresolution image: wrong resolution variant is used as icon in >> the Unity panel >> >> Hi Rajeev, >> >> I have added 1px border to the icon in your test: >> >> private static BufferedImage generateImage(int scale, Color c) { >> int x = SZ * scale; >> BufferedImage img = new BufferedImage(x, x, >> BufferedImage.TYPE_INT_RGB); >> Graphics g = img.getGraphics(); >> if (g != null) { >> g.setColor(c); >> g.fillRect(0, 0, x, x); >> g.setColor(Color.YELLOW); >> g.drawRect(0, 0, x-1, x-1); >> } >> return img; >> } >> >> It seems the icon in the taskbar is not correct for UI scale > 1. >> >> By the way, graphics object should be disposed using g.dispose() when >> it is not needed anymore. >> >> --Semyon >> >> On 14.07.2016 10:08, Rajeev Chamyal wrote: >> >> Hello All, >> >> Gentle reminder. Please review the updated webrev. >> >> http://cr.openjdk.java.net/~rchamyal/8147648/webrev.02/ >> >> Update: simplified the test. >> >> Regards, >> >> Rajeev Chamyal >> >> *From:*Alexandr Scherbatiy >> *Sent:* 22 June 2016 15:46 >> *To:* Rajeev Chamyal; Sergey Bylokhov; swing-dev at openjdk.java.net >> *Subject:* Re: [9] Review Request JDK-8147648 [hidpi] >> multiresolution image: wrong resolution variant is used as icon >> in the Unity panel >> >> The fix looks good to me. >> >> Thanks, >> Alexandr. >> >> On 6/22/2016 10:49 AM, Rajeev Chamyal wrote: >> >> Hello Alexandr, >> >> Thanks for the review. I have updated webrev as per comments. >> >> http://cr.openjdk.java.net/~rchamyal/8147648/webrev.01/ >> >> Regards, >> >> Rajeev Chamyal >> >> *From:*Alexandr Scherbatiy >> *Sent:* 21 June 2016 17:37 >> *To:* Rajeev Chamyal; Sergey Bylokhov; swing-dev at openjdk.java.net >> *Subject:* Re: [9] Review Request JDK-8147648 >> [hidpi] multiresolution image: wrong resolution variant is >> used as icon in the Unity panel >> >> On 6/21/2016 12:16 PM, Rajeev Chamyal wrote: >> >> Hello All, >> >> Please review the following webrev. >> >> Webrev: >> http://cr.openjdk.java.net/~rchamyal/8147648/webrev.00/ >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8147648 >> >> Issue: Wrong resolution variant is used as icon in the >> Unity panel. >> >> Cause: The screen transforms are not applied to find the >> correct resolution variant image in current implementation. >> >> Fix: Applied the screen transforms to graphics object. >> >> >> 222 int scaleX = (int)tx.getScaleX(); >> 223 int scaleY = (int)tx.getScaleY(); >> 224 DataBufferInt buffer = new DataBufferInt(scaleX >> * width * scaleY * height); >> >> The fix is in the shared code and the scale factor can have >> floating point value on Windows. (for example 1.5). >> It is better to round the final width and height after >> scaling them. >> >> Thanks, >> Alexandr. >> >> Regards, >> >> Rajeev Chamyal >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajit.ghaisas at oracle.com Thu Jul 21 09:42:39 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Thu, 21 Jul 2016 02:42:39 -0700 (PDT) Subject: [9] Fix for JDK-7096375 : Swing ignores first click after decreasing system's time In-Reply-To: References: <459d9470-c5bf-44d5-bb57-c9ad3846a599@default> <362267dd-ae7d-4253-a846-5cb26ed46103@default> <653f7834-3eac-4a89-990c-cd7386b8f331@default> Message-ID: <27acc516-ef16-4424-bc21-836e35d8b3bc@default> Fixed a typo in comment (from lable to label) http://cr.openjdk.java.net/~aghaisas/7096375/webrev.04/ Regards, Ajit -----Original Message----- From: Ajit Ghaisas Sent: Thursday, July 21, 2016 11:41 AM To: Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net Subject: Re: [9] Fix for JDK-7096375 : Swing ignores first click after decreasing system's time Good catch. I have corrected the test case. Please review. http://cr.openjdk.java.net/~aghaisas/7096375/webrev.03/ Regards, Ajit -----Original Message----- From: Rajeev Chamyal Sent: Thursday, July 21, 2016 11:16 AM To: Ajit Ghaisas; Alexander Scherbatiy; swing-dev at openjdk.java.net Subject: RE: [9] Fix for JDK-7096375 : Swing ignores first click after decreasing system's time Hello Ajit, Frame dispose is called twice in case pass/fail button are pressed. Regards, Rajeev Chamyal -----Original Message----- From: Ajit Ghaisas Sent: 20 July 2016 17:50 To: Alexander Scherbatiy; swing-dev at openjdk.java.net; Rajeev Chamyal Subject: RE: [9] Fix for JDK-7096375 : Swing ignores first click after decreasing system's time Hi, Added throwing exception in case create UI or dispose UI fails. Here is the updated webrev: http://cr.openjdk.java.net/~aghaisas/7096375/webrev.02/ Regards, Ajit -----Original Message----- From: Alexandr Scherbatiy Sent: Wednesday, July 20, 2016 5:13 PM To: Ajit Ghaisas; swing-dev at openjdk.java.net; Rajeev Chamyal Subject: Re: [9] Fix for JDK-7096375 : Swing ignores first click after decreasing system's time On 7/20/2016 1:50 PM, Ajit Ghaisas wrote: > Hi, > > I have modified the test as per suggestion. > > Please review the updated webrev : > http://cr.openjdk.java.net/~aghaisas/7096375/webrev.01/ It is better to rethrow the exceptions during UI creation and disposing because it also means some unexpected behavior. Thanks, Alexandr. > > Regards, > Ajit > > -----Original Message----- > From: Alexandr Scherbatiy > Sent: Tuesday, July 19, 2016 2:33 PM > To: Ajit Ghaisas; swing-dev at openjdk.java.net; Rajeev Chamyal > Subject: Re: [9] Fix for JDK-7096375 : Swing ignores first click after > decreasing system's time > > On 7/18/2016 3:27 PM, Ajit Ghaisas wrote: >> Hi, >> >> Bug : >> https://bugs.openjdk.java.net/browse/JDK-7096375 >> Swing ignores first click after decreasing system's time. >> >> Fix : >> BasicButtonListener keeps track of the last time when a button is pressed. >> This is used while discarding mouse press events to handle multiClickThreshold. >> The condition to discard mouse press event is corrected. >> >> Webrev : >> http://cr.openjdk.java.net/~aghaisas/7096375/webrev.00/ >> >> Request you to review. > The template used for the test is rather old. It is better to use CountDownLatch for the manual test synchronization. > Could you rewrite the test using the TitledBorderTest as a sample: > http://hg.openjdk.java.net/jdk9/client/jdk/file/233b59b7ea2f/test/java > x/swing/LookAndFeel/6439354/TitledBorderTest.java > > There can be added two simple changes. The thread creation is not > necessary because the runnable can be directly executed by > SwingUtilities.invokeAndWait(). The timeout can be added to the > latch.await() call. > > Thanks, > Alexandr. >> Regards, >> Ajit From Sergey.Bylokhov at oracle.com Thu Jul 21 10:13:42 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 21 Jul 2016 13:13:42 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: <8327e9bc-19f6-8ea0-a5a1-05292921638f@oracle.com> References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> <435db7a0-9ae3-0b81-ca94-5c9258d789af@oracle.com> <8984a4ae-38e6-2cbb-878a-b29f2394828c@oracle.com> <8327e9bc-19f6-8ea0-a5a1-05292921638f@oracle.com> Message-ID: <4faf3887-5857-e827-ecfb-25285b00b959@oracle.com> Is it intended to skip scales less than 1? On 07.07.16 10:01, Alexandr Scherbatiy wrote: > > The fix looks good to me. > > Thanks, > Alexandr. > > On 7/6/2016 10:03 PM, Semyon Sadetsky wrote: >> On 7/6/2016 6:03 PM, Alexandr Scherbatiy wrote: >> >>> On 7/6/2016 4:13 PM, Semyon Sadetsky wrote: >>>> Hello, >>>> >>>> Please review fix for JDK9: >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8058742 >>>> >>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.00/ >>> >>> - PangoFonts class is placed in the shared space and it uses the >>> X11GraphicsDevice from the unix space. Could there be problems with >>> build compilation on platforms differ from Unix? >> no it doesn't cause compilations problems. PangoFonts is used on Linux >> platform only. >>> - It is better to rename the scale field to nativeScale just to not >>> mix it with other scale types >> ok. webrev is updated: >> http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.01/ >>> - Does the test >>> test/java/awt/font/FontScaling/FontScalingTest.java fails without >>> the proposed fix on Linux? >> Yes it fails before and passes after the fix. >> >> --Semyon >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> After adding hdpi support to JDK the GTK LnF fonts are scaled twice >>>> using the JDK UI scale factor and the native scale factor derived >>>> from the screen dpi setting. The fix removes the native scale if it >>>> is already taken into account in the JDK UI scale. >>>> >>>> --Semyon >>>> >>> >> > -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Thu Jul 21 10:14:31 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 21 Jul 2016 13:14:31 +0300 Subject: Swing Dev>[9] Review Request JDK-8158918 setExtendedState(1) for maximized Frame results in state==7 In-Reply-To: <94aabe00-9e3a-4aca-b5f3-d800cdbada34@default> References: <94aabe00-9e3a-4aca-b5f3-d800cdbada34@default> Message-ID: <48d9bbfa-f9a1-d08b-cf44-4984880833f5@oracle.com> The fix looks good to me. Thanks, Alexandr. On 7/18/2016 9:03 AM, Rajeev Chamyal wrote: > > Hello Alexandr, > > Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8158918/webrev.01/ > > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 14 July 2016 20:54 > *To:* Rajeev Chamyal; Semyon Sadetsky; swing-dev at openjdk.java.net > *Subject:* Re: Swing Dev>[9] Review Request JDK-8158918 > setExtendedState(1) for maximized Frame results in state==7 > > On 7/14/2016 1:18 PM, Rajeev Chamyal wrote: > > Hello All, > > Please review the following webrev. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8158918 > > Webrev: http://cr.openjdk.java.net/~rchamyal/8158918/webrev.00/ > > > Issue: Frame setExtendedState = 1 on a maximized frame is not working. > > Cause: Issue is due to ::ShowWindow API call added as part of fix > for JDK-8037575 > > Fix: Removed the ShowWindow call a sepate bug will be created for > JDK-8037575 > > 40 if (frame.getExtendedState() != 1) { > It is better to use the named frame state constant instead of just 1. > > Thanks, > Alexandr. > > Regards, > > Rajeev Chamyal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Thu Jul 21 10:18:47 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 21 Jul 2016 13:18:47 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: <4faf3887-5857-e827-ecfb-25285b00b959@oracle.com> References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> <435db7a0-9ae3-0b81-ca94-5c9258d789af@oracle.com> <8984a4ae-38e6-2cbb-878a-b29f2394828c@oracle.com> <8327e9bc-19f6-8ea0-a5a1-05292921638f@oracle.com> <4faf3887-5857-e827-ecfb-25285b00b959@oracle.com> Message-ID: <5790A187.70004@oracle.com> We do not support non-integer scale on Linux. --Semyon On 21.07.2016 13:13, Sergey Bylokhov wrote: > Is it intended to skip scales less than 1? > > On 07.07.16 10:01, Alexandr Scherbatiy wrote: >> >> The fix looks good to me. >> >> Thanks, >> Alexandr. >> >> On 7/6/2016 10:03 PM, Semyon Sadetsky wrote: >>> On 7/6/2016 6:03 PM, Alexandr Scherbatiy wrote: >>> >>>> On 7/6/2016 4:13 PM, Semyon Sadetsky wrote: >>>>> Hello, >>>>> >>>>> Please review fix for JDK9: >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8058742 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.00/ >>>> >>>> - PangoFonts class is placed in the shared space and it uses the >>>> X11GraphicsDevice from the unix space. Could there be problems with >>>> build compilation on platforms differ from Unix? >>> no it doesn't cause compilations problems. PangoFonts is used on Linux >>> platform only. >>>> - It is better to rename the scale field to nativeScale just to not >>>> mix it with other scale types >>> ok. webrev is updated: >>> http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.01/ >>>> - Does the test >>>> test/java/awt/font/FontScaling/FontScalingTest.java fails without >>>> the proposed fix on Linux? >>> Yes it fails before and passes after the fix. >>> >>> --Semyon >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>> >>>>> After adding hdpi support to JDK the GTK LnF fonts are scaled twice >>>>> using the JDK UI scale factor and the native scale factor derived >>>>> from the screen dpi setting. The fix removes the native scale if it >>>>> is already taken into account in the JDK UI scale. >>>>> >>>>> --Semyon >>>>> >>>> >>> >> > > From Sergey.Bylokhov at oracle.com Thu Jul 21 10:24:11 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 21 Jul 2016 13:24:11 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: <5790A187.70004@oracle.com> References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> <435db7a0-9ae3-0b81-ca94-5c9258d789af@oracle.com> <8984a4ae-38e6-2cbb-878a-b29f2394828c@oracle.com> <8327e9bc-19f6-8ea0-a5a1-05292921638f@oracle.com> <4faf3887-5857-e827-ecfb-25285b00b959@oracle.com> <5790A187.70004@oracle.com> Message-ID: <88db89fb-4f9a-6bad-3c9e-374ea3b6b488@oracle.com> On 21.07.16 13:18, Semyon Sadetsky wrote: > We do not support non-integer scale on Linux. If it is unsupported then why it is validated in the pango fonts and not in X11GraphicsDevice? I am not sure how scale less than 1 prevent us from usage of 1.5 for example. > On 21.07.2016 13:13, Sergey Bylokhov wrote: >> Is it intended to skip scales less than 1? >> >> On 07.07.16 10:01, Alexandr Scherbatiy wrote: >>> >>> The fix looks good to me. >>> >>> Thanks, >>> Alexandr. >>> >>> On 7/6/2016 10:03 PM, Semyon Sadetsky wrote: >>>> On 7/6/2016 6:03 PM, Alexandr Scherbatiy wrote: >>>> >>>>> On 7/6/2016 4:13 PM, Semyon Sadetsky wrote: >>>>>> Hello, >>>>>> >>>>>> Please review fix for JDK9: >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8058742 >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.00/ >>>>> >>>>> - PangoFonts class is placed in the shared space and it uses the >>>>> X11GraphicsDevice from the unix space. Could there be problems with >>>>> build compilation on platforms differ from Unix? >>>> no it doesn't cause compilations problems. PangoFonts is used on Linux >>>> platform only. >>>>> - It is better to rename the scale field to nativeScale just to not >>>>> mix it with other scale types >>>> ok. webrev is updated: >>>> http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.01/ >>>>> - Does the test >>>>> test/java/awt/font/FontScaling/FontScalingTest.java fails without >>>>> the proposed fix on Linux? >>>> Yes it fails before and passes after the fix. >>>> >>>> --Semyon >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>>> >>>>>> After adding hdpi support to JDK the GTK LnF fonts are scaled twice >>>>>> using the JDK UI scale factor and the native scale factor derived >>>>>> from the screen dpi setting. The fix removes the native scale if it >>>>>> is already taken into account in the JDK UI scale. >>>>>> >>>>>> --Semyon >>>>>> >>>>> >>>> >>> >> >> > -- Best regards, Sergey. From semyon.sadetsky at oracle.com Thu Jul 21 10:28:51 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 21 Jul 2016 13:28:51 +0300 Subject: Swing Dev>[9] Review Request JDK-8158918 setExtendedState(1) for maximized Frame results in state==7 In-Reply-To: <94aabe00-9e3a-4aca-b5f3-d800cdbada34@default> References: <94aabe00-9e3a-4aca-b5f3-d800cdbada34@default> Message-ID: Hi Rajeev, As I understand you have reverted 8037575 fix. How the 8037575 will be addressed now? --Semyon On 7/18/2016 9:03 AM, Rajeev Chamyal wrote: > > Hello Alexandr, > > Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8158918/webrev.01/ > > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 14 July 2016 20:54 > *To:* Rajeev Chamyal; Semyon Sadetsky; swing-dev at openjdk.java.net > *Subject:* Re: Swing Dev>[9] Review Request JDK-8158918 > setExtendedState(1) for maximized Frame results in state==7 > > On 7/14/2016 1:18 PM, Rajeev Chamyal wrote: > > Hello All, > > Please review the following webrev. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8158918 > > Webrev: http://cr.openjdk.java.net/~rchamyal/8158918/webrev.00/ > > > Issue: Frame setExtendedState = 1 on a maximized frame is not working. > > Cause: Issue is due to ::ShowWindow API call added as part of fix > for JDK-8037575 > > Fix: Removed the ShowWindow call a sepate bug will be created for > JDK-8037575 > > 40 if (frame.getExtendedState() != 1) { > It is better to use the named frame state constant instead of just 1. > > Thanks, > Alexandr. > > Regards, > > Rajeev Chamyal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajeev.chamyal at oracle.com Thu Jul 21 10:30:30 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Thu, 21 Jul 2016 03:30:30 -0700 (PDT) Subject: Swing Dev>[9] Review Request JDK-8158918 setExtendedState(1) for maximized Frame results in state==7 In-Reply-To: References: <94aabe00-9e3a-4aca-b5f3-d800cdbada34@default> Message-ID: Hello Semyon, I will be creating a new bug for the old issue. Regards, Rajeev Chamyal From: Semyon Sadetsky Sent: 21 July 2016 15:59 To: Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net Subject: Re: Swing Dev>[9] Review Request JDK-8158918 setExtendedState(1) for maximized Frame results in state==7 Hi Rajeev, As I understand you have reverted 8037575 fix. How the 8037575 will be addressed now? --Semyon On 7/18/2016 9:03 AM, Rajeev Chamyal wrote: Hello Alexandr, Please review the updated webrev. HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8158918/webrev.01/"http://cr.openjdk.java.net/~rchamyal/8158918/webrev.01/ Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 14 July 2016 20:54 To: Rajeev Chamyal; Semyon Sadetsky; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: Swing Dev>[9] Review Request JDK-8158918 setExtendedState(1) for maximized Frame results in state==7 On 7/14/2016 1:18 PM, Rajeev Chamyal wrote: Hello All, Please review the following webrev. Bug: https://bugs.openjdk.java.net/browse/JDK-8158918 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8158918/webrev.00/"http://cr.openjdk.java.net/~rchamyal/8158918/webrev.00/ Issue: Frame setExtendedState = 1 on a maximized frame is not working. Cause: Issue is due to ::ShowWindow API call added as part of fix for HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8037575"JDK-8037575 Fix: Removed the ShowWindow call a sepate bug will be created for HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8037575"JDK-8037575 40 if (frame.getExtendedState() != 1) { It is better to use the named frame state constant instead of just 1. Thanks, Alexandr. Regards, Rajeev Chamyal -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajeev.chamyal at oracle.com Thu Jul 21 10:34:52 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Thu, 21 Jul 2016 03:34:52 -0700 (PDT) Subject: [9] Fix for JDK-7096375 : Swing ignores first click after decreasing system's time In-Reply-To: <27acc516-ef16-4424-bc21-836e35d8b3bc@default> References: <459d9470-c5bf-44d5-bb57-c9ad3846a599@default> <362267dd-ae7d-4253-a846-5cb26ed46103@default> <653f7834-3eac-4a89-990c-cd7386b8f331@default> <27acc516-ef16-4424-bc21-836e35d8b3bc@default> Message-ID: Looks good to me. Regards, Rajeev Chamyal -----Original Message----- From: Ajit Ghaisas Sent: 21 July 2016 15:13 To: Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net Subject: RE: [9] Fix for JDK-7096375 : Swing ignores first click after decreasing system's time Fixed a typo in comment (from lable to label) http://cr.openjdk.java.net/~aghaisas/7096375/webrev.04/ Regards, Ajit -----Original Message----- From: Ajit Ghaisas Sent: Thursday, July 21, 2016 11:41 AM To: Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net Subject: Re: [9] Fix for JDK-7096375 : Swing ignores first click after decreasing system's time Good catch. I have corrected the test case. Please review. http://cr.openjdk.java.net/~aghaisas/7096375/webrev.03/ Regards, Ajit -----Original Message----- From: Rajeev Chamyal Sent: Thursday, July 21, 2016 11:16 AM To: Ajit Ghaisas; Alexander Scherbatiy; swing-dev at openjdk.java.net Subject: RE: [9] Fix for JDK-7096375 : Swing ignores first click after decreasing system's time Hello Ajit, Frame dispose is called twice in case pass/fail button are pressed. Regards, Rajeev Chamyal -----Original Message----- From: Ajit Ghaisas Sent: 20 July 2016 17:50 To: Alexander Scherbatiy; swing-dev at openjdk.java.net; Rajeev Chamyal Subject: RE: [9] Fix for JDK-7096375 : Swing ignores first click after decreasing system's time Hi, Added throwing exception in case create UI or dispose UI fails. Here is the updated webrev: http://cr.openjdk.java.net/~aghaisas/7096375/webrev.02/ Regards, Ajit -----Original Message----- From: Alexandr Scherbatiy Sent: Wednesday, July 20, 2016 5:13 PM To: Ajit Ghaisas; swing-dev at openjdk.java.net; Rajeev Chamyal Subject: Re: [9] Fix for JDK-7096375 : Swing ignores first click after decreasing system's time On 7/20/2016 1:50 PM, Ajit Ghaisas wrote: > Hi, > > I have modified the test as per suggestion. > > Please review the updated webrev : > http://cr.openjdk.java.net/~aghaisas/7096375/webrev.01/ It is better to rethrow the exceptions during UI creation and disposing because it also means some unexpected behavior. Thanks, Alexandr. > > Regards, > Ajit > > -----Original Message----- > From: Alexandr Scherbatiy > Sent: Tuesday, July 19, 2016 2:33 PM > To: Ajit Ghaisas; swing-dev at openjdk.java.net; Rajeev Chamyal > Subject: Re: [9] Fix for JDK-7096375 : Swing ignores first click after > decreasing system's time > > On 7/18/2016 3:27 PM, Ajit Ghaisas wrote: >> Hi, >> >> Bug : >> https://bugs.openjdk.java.net/browse/JDK-7096375 >> Swing ignores first click after decreasing system's time. >> >> Fix : >> BasicButtonListener keeps track of the last time when a button is pressed. >> This is used while discarding mouse press events to handle multiClickThreshold. >> The condition to discard mouse press event is corrected. >> >> Webrev : >> http://cr.openjdk.java.net/~aghaisas/7096375/webrev.00/ >> >> Request you to review. > The template used for the test is rather old. It is better to use CountDownLatch for the manual test synchronization. > Could you rewrite the test using the TitledBorderTest as a sample: > http://hg.openjdk.java.net/jdk9/client/jdk/file/233b59b7ea2f/test/java > x/swing/LookAndFeel/6439354/TitledBorderTest.java > > There can be added two simple changes. The thread creation is not > necessary because the runnable can be directly executed by > SwingUtilities.invokeAndWait(). The timeout can be added to the > latch.await() call. > > Thanks, > Alexandr. >> Regards, >> Ajit From alexandr.scherbatiy at oracle.com Thu Jul 21 10:39:27 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 21 Jul 2016 13:39:27 +0300 Subject: [9] Fix for JDK-7096375 : Swing ignores first click after decreasing system's time In-Reply-To: References: <459d9470-c5bf-44d5-bb57-c9ad3846a599@default> <362267dd-ae7d-4253-a846-5cb26ed46103@default> <653f7834-3eac-4a89-990c-cd7386b8f331@default> <27acc516-ef16-4424-bc21-836e35d8b3bc@default> Message-ID: <77840675-ebf5-1e1c-9620-eec779c20311@oracle.com> The fix looks good to me. Thanks, Alexandr. On 7/21/2016 1:34 PM, Rajeev Chamyal wrote: > Looks good to me. > > Regards, > Rajeev Chamyal > > -----Original Message----- > From: Ajit Ghaisas > Sent: 21 July 2016 15:13 > To: Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net > Subject: RE: [9] Fix for JDK-7096375 : Swing ignores first click after decreasing system's time > > Fixed a typo in comment (from lable to label) > > http://cr.openjdk.java.net/~aghaisas/7096375/webrev.04/ > > Regards, > Ajit > > -----Original Message----- > From: Ajit Ghaisas > Sent: Thursday, July 21, 2016 11:41 AM > To: Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net > Subject: Re: [9] Fix for JDK-7096375 : Swing ignores first click after decreasing system's time > > Good catch. > I have corrected the test case. Please review. > http://cr.openjdk.java.net/~aghaisas/7096375/webrev.03/ > > Regards, > Ajit > > -----Original Message----- > From: Rajeev Chamyal > Sent: Thursday, July 21, 2016 11:16 AM > To: Ajit Ghaisas; Alexander Scherbatiy; swing-dev at openjdk.java.net > Subject: RE: [9] Fix for JDK-7096375 : Swing ignores first click after decreasing system's time > > Hello Ajit, > > Frame dispose is called twice in case pass/fail button are pressed. > > Regards, > Rajeev Chamyal > > -----Original Message----- > From: Ajit Ghaisas > Sent: 20 July 2016 17:50 > To: Alexander Scherbatiy; swing-dev at openjdk.java.net; Rajeev Chamyal > Subject: RE: [9] Fix for JDK-7096375 : Swing ignores first click after decreasing system's time > > Hi, > > Added throwing exception in case create UI or dispose UI fails. > Here is the updated webrev: > http://cr.openjdk.java.net/~aghaisas/7096375/webrev.02/ > > Regards, > Ajit > > > -----Original Message----- > From: Alexandr Scherbatiy > Sent: Wednesday, July 20, 2016 5:13 PM > To: Ajit Ghaisas; swing-dev at openjdk.java.net; Rajeev Chamyal > Subject: Re: [9] Fix for JDK-7096375 : Swing ignores first click after decreasing system's time > > On 7/20/2016 1:50 PM, Ajit Ghaisas wrote: >> Hi, >> >> I have modified the test as per suggestion. >> >> Please review the updated webrev : >> http://cr.openjdk.java.net/~aghaisas/7096375/webrev.01/ > It is better to rethrow the exceptions during UI creation and disposing because it also means some unexpected behavior. > > Thanks, > Alexandr. >> Regards, >> Ajit >> >> -----Original Message----- >> From: Alexandr Scherbatiy >> Sent: Tuesday, July 19, 2016 2:33 PM >> To: Ajit Ghaisas; swing-dev at openjdk.java.net; Rajeev Chamyal >> Subject: Re: [9] Fix for JDK-7096375 : Swing ignores first click after >> decreasing system's time >> >> On 7/18/2016 3:27 PM, Ajit Ghaisas wrote: >>> Hi, >>> >>> Bug : >>> https://bugs.openjdk.java.net/browse/JDK-7096375 >>> Swing ignores first click after decreasing system's time. >>> >>> Fix : >>> BasicButtonListener keeps track of the last time when a button is pressed. >>> This is used while discarding mouse press events to handle multiClickThreshold. >>> The condition to discard mouse press event is corrected. >>> >>> Webrev : >>> http://cr.openjdk.java.net/~aghaisas/7096375/webrev.00/ >>> >>> Request you to review. >> The template used for the test is rather old. It is better to use CountDownLatch for the manual test synchronization. >> Could you rewrite the test using the TitledBorderTest as a sample: >> http://hg.openjdk.java.net/jdk9/client/jdk/file/233b59b7ea2f/test/java >> x/swing/LookAndFeel/6439354/TitledBorderTest.java >> >> There can be added two simple changes. The thread creation is not >> necessary because the runnable can be directly executed by >> SwingUtilities.invokeAndWait(). The timeout can be added to the >> latch.await() call. >> >> Thanks, >> Alexandr. >>> Regards, >>> Ajit From semyon.sadetsky at oracle.com Thu Jul 21 10:40:12 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 21 Jul 2016 13:40:12 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: <88db89fb-4f9a-6bad-3c9e-374ea3b6b488@oracle.com> References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> <435db7a0-9ae3-0b81-ca94-5c9258d789af@oracle.com> <8984a4ae-38e6-2cbb-878a-b29f2394828c@oracle.com> <8327e9bc-19f6-8ea0-a5a1-05292921638f@oracle.com> <4faf3887-5857-e827-ecfb-25285b00b959@oracle.com> <5790A187.70004@oracle.com> <88db89fb-4f9a-6bad-3c9e-374ea3b6b488@oracle.com> Message-ID: On 7/21/2016 1:24 PM, Sergey Bylokhov wrote: > On 21.07.16 13:18, Semyon Sadetsky wrote: >> We do not support non-integer scale on Linux. > > If it is unsupported then why it is validated in the pango fonts and > not in X11GraphicsDevice? I am not sure how scale less than 1 prevent > us from usage of 1.5 for example. getNativeScale() returns int. int cannot be 1.5. > >> On 21.07.2016 13:13, Sergey Bylokhov wrote: >>> Is it intended to skip scales less than 1? >>> >>> On 07.07.16 10:01, Alexandr Scherbatiy wrote: >>>> >>>> The fix looks good to me. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 7/6/2016 10:03 PM, Semyon Sadetsky wrote: >>>>> On 7/6/2016 6:03 PM, Alexandr Scherbatiy wrote: >>>>> >>>>>> On 7/6/2016 4:13 PM, Semyon Sadetsky wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review fix for JDK9: >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8058742 >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.00/ >>>>>> >>>>>> - PangoFonts class is placed in the shared space and it uses the >>>>>> X11GraphicsDevice from the unix space. Could there be problems with >>>>>> build compilation on platforms differ from Unix? >>>>> no it doesn't cause compilations problems. PangoFonts is used on >>>>> Linux >>>>> platform only. >>>>>> - It is better to rename the scale field to nativeScale just to >>>>>> not >>>>>> mix it with other scale types >>>>> ok. webrev is updated: >>>>> http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.01/ >>>>>> - Does the test >>>>>> test/java/awt/font/FontScaling/FontScalingTest.java fails without >>>>>> the proposed fix on Linux? >>>>> Yes it fails before and passes after the fix. >>>>> >>>>> --Semyon >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>>> >>>>>>> After adding hdpi support to JDK the GTK LnF fonts are scaled twice >>>>>>> using the JDK UI scale factor and the native scale factor derived >>>>>>> from the screen dpi setting. The fix removes the native scale >>>>>>> if it >>>>>>> is already taken into account in the JDK UI scale. >>>>>>> >>>>>>> --Semyon >>>>>>> >>>>>> >>>>> >>>> >>> >>> >> > > From semyon.sadetsky at oracle.com Thu Jul 21 10:43:49 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 21 Jul 2016 13:43:49 +0300 Subject: Swing Dev>[9] Review Request JDK-8158918 setExtendedState(1) for maximized Frame results in state==7 In-Reply-To: References: <94aabe00-9e3a-4aca-b5f3-d800cdbada34@default> Message-ID: <67c66098-156c-fa12-4f2d-f0296fcd3110@oracle.com> On 7/21/2016 1:30 PM, Rajeev Chamyal wrote: > Hello Semyon, > > I will be creating a new bug for the old issue. > Could you, please, add the JBS link here. --Semyon > > Regards, > > Rajeev Chamyal > > *From:*Semyon Sadetsky > *Sent:* 21 July 2016 15:59 > *To:* Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net > *Subject:* Re: Swing Dev>[9] Review Request JDK-8158918 > setExtendedState(1) for maximized Frame results in state==7 > > Hi Rajeev, > > As I understand you have reverted 8037575 fix. > > How the 8037575 will be addressed now? > > --Semyon > > On 7/18/2016 9:03 AM, Rajeev Chamyal wrote: > > Hello Alexandr, > > Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8158918/webrev.01/ > > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 14 July 2016 20:54 > *To:* Rajeev Chamyal; Semyon Sadetsky; swing-dev at openjdk.java.net > > *Subject:* Re: Swing Dev>[9] Review Request JDK-8158918 > setExtendedState(1) for maximized Frame results in state==7 > > On 7/14/2016 1:18 PM, Rajeev Chamyal wrote: > > > Hello All, > > Please review the following webrev. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8158918 > > Webrev: > http://cr.openjdk.java.net/~rchamyal/8158918/webrev.00/ > > > Issue: Frame setExtendedState = 1 on a maximized frame is not > working. > > Cause: Issue is due to ::ShowWindow API call added as part of > fix for JDK-8037575 > > > Fix: Removed the ShowWindow call a sepate bug will be created > for JDK-8037575 > > 40 if (frame.getExtendedState() != 1) { > It is better to use the named frame state constant instead of > just 1. > > Thanks, > Alexandr. > > > Regards, > > Rajeev Chamyal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajeev.chamyal at oracle.com Thu Jul 21 10:51:17 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Thu, 21 Jul 2016 03:51:17 -0700 (PDT) Subject: Swing Dev>[9] Review Request JDK-8158918 setExtendedState(1) for maximized Frame results in state==7 In-Reply-To: <67c66098-156c-fa12-4f2d-f0296fcd3110@oracle.com> References: <94aabe00-9e3a-4aca-b5f3-d800cdbada34@default> <67c66098-156c-fa12-4f2d-f0296fcd3110@oracle.com> Message-ID: <34515e22-574f-4829-8ae5-d00f65f5ee11@default> Hello Semyon, Following is the new bug. https://bugs.openjdk.java.net/browse/JDK-8161995 Regards, Rajeev Chamyal From: Semyon Sadetsky Sent: 21 July 2016 16:14 To: Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net Subject: Re: Swing Dev>[9] Review Request JDK-8158918 setExtendedState(1) for maximized Frame results in state==7 On 7/21/2016 1:30 PM, Rajeev Chamyal wrote: Hello Semyon, I will be creating a new bug for the old issue. Could you, please, add the JBS link here. --Semyon Regards, Rajeev Chamyal From: Semyon Sadetsky Sent: 21 July 2016 15:59 To: Rajeev Chamyal; Alexander Scherbatiy; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: Swing Dev>[9] Review Request JDK-8158918 setExtendedState(1) for maximized Frame results in state==7 Hi Rajeev, As I understand you have reverted 8037575 fix. How the 8037575 will be addressed now? --Semyon On 7/18/2016 9:03 AM, Rajeev Chamyal wrote: Hello Alexandr, Please review the updated webrev. HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8158918/webrev.01/"http://cr.openjdk.java.net/~rchamyal/8158918/webrev.01/ Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 14 July 2016 20:54 To: Rajeev Chamyal; Semyon Sadetsky; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: Swing Dev>[9] Review Request JDK-8158918 setExtendedState(1) for maximized Frame results in state==7 On 7/14/2016 1:18 PM, Rajeev Chamyal wrote: Hello All, Please review the following webrev. Bug: https://bugs.openjdk.java.net/browse/JDK-8158918 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8158918/webrev.00/"http://cr.openjdk.java.net/~rchamyal/8158918/webrev.00/ Issue: Frame setExtendedState = 1 on a maximized frame is not working. Cause: Issue is due to ::ShowWindow API call added as part of fix for HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8037575"JDK-8037575 Fix: Removed the ShowWindow call a sepate bug will be created for HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8037575"JDK-8037575 40 if (frame.getExtendedState() != 1) { It is better to use the named frame state constant instead of just 1. Thanks, Alexandr. Regards, Rajeev Chamyal -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Jul 21 11:02:42 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 21 Jul 2016 14:02:42 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> <435db7a0-9ae3-0b81-ca94-5c9258d789af@oracle.com> <8984a4ae-38e6-2cbb-878a-b29f2394828c@oracle.com> <8327e9bc-19f6-8ea0-a5a1-05292921638f@oracle.com> <4faf3887-5857-e827-ecfb-25285b00b959@oracle.com> <5790A187.70004@oracle.com> <88db89fb-4f9a-6bad-3c9e-374ea3b6b488@oracle.com> Message-ID: On 21.07.16 13:40, Semyon Sadetsky wrote: >> If it is unsupported then why it is validated in the pango fonts and >> not in X11GraphicsDevice? I am not sure how scale less than 1 prevent >> us from usage of 1.5 for example. > getNativeScale() returns int. int cannot be 1.5. Then why PangoFonts.nativeScale is double? or it is a way to apply a generic solution in case some system will have double scales? In this case I suggest to request DefaultTransform.scaleY from the gc. In this case it will not be necessary to use X11GraphicsDevice. Related question: is this PangoFonts used in printing? >> >>> On 21.07.2016 13:13, Sergey Bylokhov wrote: >>>> Is it intended to skip scales less than 1? >>>> >>>> On 07.07.16 10:01, Alexandr Scherbatiy wrote: >>>>> >>>>> The fix looks good to me. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 7/6/2016 10:03 PM, Semyon Sadetsky wrote: >>>>>> On 7/6/2016 6:03 PM, Alexandr Scherbatiy wrote: >>>>>> >>>>>>> On 7/6/2016 4:13 PM, Semyon Sadetsky wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review fix for JDK9: >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8058742 >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.00/ >>>>>>> >>>>>>> - PangoFonts class is placed in the shared space and it uses the >>>>>>> X11GraphicsDevice from the unix space. Could there be problems with >>>>>>> build compilation on platforms differ from Unix? >>>>>> no it doesn't cause compilations problems. PangoFonts is used on >>>>>> Linux >>>>>> platform only. >>>>>>> - It is better to rename the scale field to nativeScale just to >>>>>>> not >>>>>>> mix it with other scale types >>>>>> ok. webrev is updated: >>>>>> http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.01/ >>>>>>> - Does the test >>>>>>> test/java/awt/font/FontScaling/FontScalingTest.java fails without >>>>>>> the proposed fix on Linux? >>>>>> Yes it fails before and passes after the fix. >>>>>> >>>>>> --Semyon >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>>> >>>>>>>> After adding hdpi support to JDK the GTK LnF fonts are scaled twice >>>>>>>> using the JDK UI scale factor and the native scale factor derived >>>>>>>> from the screen dpi setting. The fix removes the native scale >>>>>>>> if it >>>>>>>> is already taken into account in the JDK UI scale. >>>>>>>> >>>>>>>> --Semyon >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > -- Best regards, Sergey. From semyon.sadetsky at oracle.com Thu Jul 21 11:34:42 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 21 Jul 2016 14:34:42 +0300 Subject: Swing Dev>[9] Review Request JDK-8158918 setExtendedState(1) for maximized Frame results in state==7 In-Reply-To: <34515e22-574f-4829-8ae5-d00f65f5ee11@default> References: <94aabe00-9e3a-4aca-b5f3-d800cdbada34@default> <67c66098-156c-fa12-4f2d-f0296fcd3110@oracle.com> <34515e22-574f-4829-8ae5-d00f65f5ee11@default> Message-ID: On 7/21/2016 1:51 PM, Rajeev Chamyal wrote: > Hello Semyon, > > Following is the new bug. > > https://bugs.openjdk.java.net/browse/JDK-8161995 > Thank you. Please link it to 8037575 and 8158918. The fix looks good. --Semyon > > Regards, > > Rajeev Chamyal > > *From:*Semyon Sadetsky > *Sent:* 21 July 2016 16:14 > *To:* Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net > *Subject:* Re: Swing Dev>[9] Review Request JDK-8158918 > setExtendedState(1) for maximized Frame results in state==7 > > On 7/21/2016 1:30 PM, Rajeev Chamyal wrote: > > Hello Semyon, > > I will be creating a new bug for the old issue. > > Could you, please, add the JBS link here. > > --Semyon > > Regards, > > Rajeev Chamyal > > *From:*Semyon Sadetsky > *Sent:* 21 July 2016 15:59 > *To:* Rajeev Chamyal; Alexander Scherbatiy; > swing-dev at openjdk.java.net > *Subject:* Re: Swing Dev>[9] Review Request JDK-8158918 > setExtendedState(1) for maximized Frame results in state==7 > > Hi Rajeev, > > As I understand you have reverted 8037575 fix. > > How the 8037575 will be addressed now? > > --Semyon > > On 7/18/2016 9:03 AM, Rajeev Chamyal wrote: > > Hello Alexandr, > > Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8158918/webrev.01/ > > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 14 July 2016 20:54 > *To:* Rajeev Chamyal; Semyon Sadetsky; > swing-dev at openjdk.java.net > *Subject:* Re: Swing Dev>[9] Review Request JDK-8158918 > setExtendedState(1) for maximized Frame results in state==7 > > On 7/14/2016 1:18 PM, Rajeev Chamyal wrote: > > > > Hello All, > > Please review the following webrev. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8158918 > > Webrev: > http://cr.openjdk.java.net/~rchamyal/8158918/webrev.00/ > > > Issue: Frame setExtendedState = 1 on a maximized frame is > not working. > > Cause: Issue is due to ::ShowWindow API call added as part > of fix for JDK-8037575 > > > Fix: Removed the ShowWindow call a sepate bug will be > created for JDK-8037575 > > > 40 if (frame.getExtendedState() != 1) { > It is better to use the named frame state constant instead > of just 1. > > Thanks, > Alexandr. > > > > Regards, > > Rajeev Chamyal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Thu Jul 21 11:51:59 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 21 Jul 2016 14:51:59 +0300 Subject: [9] Review request for 8160087: Change IOOBE to warning in the scenarios when it had not being thrown before the JDK-8078514 In-Reply-To: <413e1a77-b95e-15b3-203e-ccecccff3ec5@oracle.com> References: <19eeb5bb-18bc-85b2-7eaf-f16bfb6a0f9d@oracle.com> <4bcb6a4a-030c-fea5-30d5-33ec1c0ff2c1@oracle.com> <578DF340.8060204@oracle.com> <7e874ada-48e0-ec9a-da52-1cbf5cd519c7@oracle.com> <578E1564.4010007@oracle.com> <66bd44af-5787-7a9b-57f5-43af52e9c5e5@oracle.com> <413e1a77-b95e-15b3-203e-ccecccff3ec5@oracle.com> Message-ID: <1e0f3003-d2c0-c11a-08f1-18cb8c891994@oracle.com> On 7/20/2016 4:46 PM, Semyon Sadetsky wrote: > > > On 7/20/2016 2:29 PM, Alexandr Scherbatiy wrote: >> On 7/20/2016 10:18 AM, Semyon Sadetsky wrote: >>> On 7/19/2016 4:06 PM, Alexandr Scherbatiy wrote: >>> >>>> On 7/19/2016 2:56 PM, Semyon Sadetsky wrote: >>>>> On 19.07.2016 14:20, Alexandr Scherbatiy wrote: >>>>>> >>>>>> The fix prints the warning method in case of wrong row sorter >>>>>> usage. How often this can happen? Could the large number of the >>>>>> messages overflow a user output? >>>>> In the FilePane this happened only once after the initial file >>>>> list loading. >>>> I am just worrying that in a user application which does not >>>> properly use the row sorter there can be a lot of such warnings. >>>> And it could be some library which he can't be able to update. Is >>>> it possible to show the warning only once? >>> Yes. See the updated webrev: >>> http://cr.openjdk.java.net/~ssadetsky/8160087/webrev.01/ >> A property which should be used by users needs to have the CCC >> request. > It is added on the off-chance. It doesn't merit to be a documented > property. Who should use the proposed property? Thanks, Alexandr. > > --Semyon >> I believe that printing the warning message only once is enough. >> >> Thanks, >> Alexandr. >>> >>> --Semyon >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>> >>>>> --Semyon >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> On 7/19/2016 12:30 PM, Semyon Sadetsky wrote: >>>>>>> >>>>>>> >>>>>>> On 19.07.2016 12:18, Alexandr Scherbatiy wrote: >>>>>>>> On 7/18/2016 11:46 AM, Semyon Sadetsky wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Please review fix for JDK9: >>>>>>>>> >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160087 >>>>>>>>> >>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8160087/webrev.00/ >>>>>>>>> >>>>>>>>> A warning is added to avoid issues in user code to throw >>>>>>>>> exceptions which were masked before. See bug descriptions for >>>>>>>>> details. >>>>>>>> Should this behavior (which exists for long time) be >>>>>>>> specified in the >>>>>>>> DefaultRowSorter.convertRowIndexToView()/convertRowIndexToModel() >>>>>>>> javadoc? >>>>>>> This was not a >>>>>>> DefaultRowSorter.convertRowIndexToView()/convertRowIndexToModel() >>>>>>> issue. It was a mistake in the FilePane class. >>>>>>> RowSorter's javadoc mentions the correct way to use it: >>>>>>> >>>>>>> The view invokes a model change method when the underlying model >>>>>>> has changed. There may be order dependencies in how the events >>>>>>> are delivered, so a RowSorter should not update its mapping >>>>>>> until one of these methods is invoked. >>>>>>> >>>>>>> --Semyon >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> --Semyon >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From semyon.sadetsky at oracle.com Thu Jul 21 13:40:20 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 21 Jul 2016 16:40:20 +0300 Subject: [9] Review request for 8160087: Change IOOBE to warning in the scenarios when it had not being thrown before the JDK-8078514 In-Reply-To: <1e0f3003-d2c0-c11a-08f1-18cb8c891994@oracle.com> References: <19eeb5bb-18bc-85b2-7eaf-f16bfb6a0f9d@oracle.com> <4bcb6a4a-030c-fea5-30d5-33ec1c0ff2c1@oracle.com> <578DF340.8060204@oracle.com> <7e874ada-48e0-ec9a-da52-1cbf5cd519c7@oracle.com> <578E1564.4010007@oracle.com> <66bd44af-5787-7a9b-57f5-43af52e9c5e5@oracle.com> <413e1a77-b95e-15b3-203e-ccecccff3ec5@oracle.com> <1e0f3003-d2c0-c11a-08f1-18cb8c891994@oracle.com> Message-ID: On 7/21/2016 2:51 PM, Alexandr Scherbatiy wrote: > On 7/20/2016 4:46 PM, Semyon Sadetsky wrote: >> >> >> On 7/20/2016 2:29 PM, Alexandr Scherbatiy wrote: >>> On 7/20/2016 10:18 AM, Semyon Sadetsky wrote: >>>> On 7/19/2016 4:06 PM, Alexandr Scherbatiy wrote: >>>> >>>>> On 7/19/2016 2:56 PM, Semyon Sadetsky wrote: >>>>>> On 19.07.2016 14:20, Alexandr Scherbatiy wrote: >>>>>>> >>>>>>> The fix prints the warning method in case of wrong row sorter >>>>>>> usage. How often this can happen? Could the large number of the >>>>>>> messages overflow a user output? >>>>>> In the FilePane this happened only once after the initial file >>>>>> list loading. >>>>> I am just worrying that in a user application which does not >>>>> properly use the row sorter there can be a lot of such warnings. >>>>> And it could be some library which he can't be able to update. Is >>>>> it possible to show the warning only once? >>>> Yes. See the updated webrev: >>>> http://cr.openjdk.java.net/~ssadetsky/8160087/webrev.01/ >>> A property which should be used by users needs to have the CCC >>> request. >> It is added on the off-chance. It doesn't merit to be a documented >> property. > Who should use the proposed property? If it will not be possible to correct the code (for example an old application that is not supported) and seeing the warning is displeased for some reasons. --Semyon > > Thanks, > Alexandr. > >> >> --Semyon >>> I believe that printing the warning message only once is enough. >>> >>> Thanks, >>> Alexandr. >>>> >>>> --Semyon >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>>> >>>>>> --Semyon >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> On 7/19/2016 12:30 PM, Semyon Sadetsky wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 19.07.2016 12:18, Alexandr Scherbatiy wrote: >>>>>>>>> On 7/18/2016 11:46 AM, Semyon Sadetsky wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Please review fix for JDK9: >>>>>>>>>> >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160087 >>>>>>>>>> >>>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8160087/webrev.00/ >>>>>>>>>> >>>>>>>>>> A warning is added to avoid issues in user code to throw >>>>>>>>>> exceptions which were masked before. See bug descriptions for >>>>>>>>>> details. >>>>>>>>> Should this behavior (which exists for long time) be >>>>>>>>> specified in the >>>>>>>>> DefaultRowSorter.convertRowIndexToView()/convertRowIndexToModel() >>>>>>>>> javadoc? >>>>>>>> This was not a >>>>>>>> DefaultRowSorter.convertRowIndexToView()/convertRowIndexToModel() >>>>>>>> issue. It was a mistake in the FilePane class. >>>>>>>> RowSorter's javadoc mentions the correct way to use it: >>>>>>>> >>>>>>>> The view invokes a model change method when the underlying >>>>>>>> model has changed. There may be order dependencies in how the >>>>>>>> events are delivered, so a RowSorter should not update its >>>>>>>> mapping until one of these methods is invoked. >>>>>>>> >>>>>>>> --Semyon >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>> --Semyon >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From rajeev.chamyal at oracle.com Thu Jul 21 14:25:55 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Thu, 21 Jul 2016 07:25:55 -0700 (PDT) Subject: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel In-Reply-To: <0cfea8e4-b742-dccf-95cb-46e2ac138bfe@oracle.com> References: <340c1fa9-7da5-4fcb-9119-0e1e2dcaeb10@default> <9bd7ca3c-2297-0c36-c249-4a9b560275a2@oracle.com> <395e74b7-451e-453e-b552-be2a5bc0e348@default> <30e65d6d-cb35-4c55-b1b2-80752929576a@default> <3d266275-efcd-4d69-bfab-9604467856d1@default> <57877747.3040904@oracle.com> <57908CA9.600@oracle.com> <0cfea8e4-b742-dccf-95cb-46e2ac138bfe@oracle.com> Message-ID: <79509b10-a343-4846-acfd-39c0494a4e93@default> Hello Semyon, The resolution variant image returned is based on the implementation of BaseMultiResolutionImage::getResolutionVariant API. Current implementation of BaseMultiResolutionImage::getResolutionVariant returns a resolution variant image which has width and height greater than or equal to the passed width and height. In the case you have suggested dimensions of RED and BLUE images are 32 and 80 respectively. Width and height passed to getResolutionVariant is 64 i.e. scaled width and height of base image(RED) (GDK_SCALE=2) and blue image is getting returned. The width and height passed to this API is that of base image not of the spot. Applications can control this behaviour by overriding this API in derived classes. Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 21 July 2016 15:09 To: Semyon Sadetsky; Rajeev Chamyal; swing-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel On 7/21/2016 11:49 AM, Semyon Sadetsky wrote: Hello Rajeev, The taskbar icon is ok now. I change the resolution variants from the test a bit: final BaseMultiResolutionImage IMG = new BaseMultiResolutionImage( new BufferedImage[]{generateImage(4, Color.RED), generateImage(10, Color.BLUE)}); And the icon I see in the taskbar and in the button is blue. It seems to me the first resolution variant (red) is more appropriate in this case because its size is closer to the spot. I'm not sure if this is an issue. I have an extra question to you and Alexander. Most native apps on Linux set an array of icons with _NET_WM_ICON. Usually they are [16x16, 32x32, 64x64]. So, desktop environment may select icon of appropriate size. In this fix we are preselecting icon of a specific size in the app and send it to WM. Why not to send array of the resolution variants images and let the desktop environment to select the appropriate one, like native apps do? This sounds as good idea. MultiResolutionImage has the special method for this "List getResolutionVariants()". We do the similar on Mac OS X where NSImage with several representations is created from a MultiResolutionImage: http://cr.openjdk.java.net/~alexsch/8028212/webrev.01/src/macosx/classes/sun/lwawt/macosx/CImage.java.udiff.html It has sense to try the same approach on Linux. Thanks, Alexandr. --Semyon On 19.07.2016 23:26, Rajeev Chamyal wrote: Hello Semyon, Please review the updated webrev. HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8147648/webrev.03/"http://cr.openjdk.java.net/~rchamyal/8147648/webrev.03/ Regards, Rajeev Chamyal From: Semyon Sadetsky Sent: 14 July 2016 16:58 To: Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov; Alexander Scherbatiy Subject: Re: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel Hi Rajeev, I have added 1px border to the icon in your test: private static BufferedImage generateImage(int scale, Color c) { int x = SZ * scale; BufferedImage img = new BufferedImage(x, x, BufferedImage.TYPE_INT_RGB); Graphics g = img.getGraphics(); if (g != null) { g.setColor(c); g.fillRect(0, 0, x, x); g.setColor(Color.YELLOW); g.drawRect(0, 0, x-1, x-1); } return img; } It seems the icon in the taskbar is not correct for UI scale > 1. By the way, graphics object should be disposed using g.dispose() when it is not needed anymore. --Semyon On 14.07.2016 10:08, Rajeev Chamyal wrote: Hello All, Gentle reminder. Please review the updated webrev. HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8147648/webrev.02/"http://cr.openjdk.java.net/~rchamyal/8147648/webrev.02/ Update: simplified the test. Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 22 June 2016 15:46 To: Rajeev Chamyal; Sergey Bylokhov; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel The fix looks good to me. Thanks, Alexandr. On 6/22/2016 10:49 AM, Rajeev Chamyal wrote: Hello Alexandr, Thanks for the review. I have updated webrev as per comments. HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8147648/webrev.01/"http://cr.openjdk.java.net/~rchamyal/8147648/webrev.01/ Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 21 June 2016 17:37 To: Rajeev Chamyal; Sergey Bylokhov; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel On 6/21/2016 12:16 PM, Rajeev Chamyal wrote: Hello All, Please review the following webrev. Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8147648/webrev.00/"http://cr.openjdk.java.net/~rchamyal/8147648/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8147648 Issue: Wrong resolution variant is used as icon in the Unity panel. Cause: The screen transforms are not applied to find the correct resolution variant image in current implementation. Fix: Applied the screen transforms to graphics object. 222 int scaleX = (int)tx.getScaleX(); 223 int scaleY = (int)tx.getScaleY(); 224 DataBufferInt buffer = new DataBufferInt(scaleX * width * scaleY * height); The fix is in the shared code and the scale factor can have floating point value on Windows. (for example 1.5). It is better to round the final width and height after scaling them. Thanks, Alexandr. Regards, Rajeev Chamyal -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Thu Jul 21 15:12:07 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 21 Jul 2016 18:12:07 +0300 Subject: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel In-Reply-To: <79509b10-a343-4846-acfd-39c0494a4e93@default> References: <340c1fa9-7da5-4fcb-9119-0e1e2dcaeb10@default> <9bd7ca3c-2297-0c36-c249-4a9b560275a2@oracle.com> <395e74b7-451e-453e-b552-be2a5bc0e348@default> <30e65d6d-cb35-4c55-b1b2-80752929576a@default> <3d266275-efcd-4d69-bfab-9604467856d1@default> <57877747.3040904@oracle.com> <57908CA9.600@oracle.com> <0cfea8e4-b742-dccf-95cb-46e2ac138bfe@oracle.com> <79509b10-a343-4846-acfd-39c0494a4e93@default> Message-ID: <508d9383-260e-9841-5fd4-96bc8f0c0239@oracle.com> On 7/21/2016 5:25 PM, Rajeev Chamyal wrote: > > Hello Semyon, > > The resolution variant image returned is based on the implementation > of BaseMultiResolutionImage::getResolutionVariant API. > > Current implementation of > BaseMultiResolutionImage::getResolutionVariant returns a resolution > variant image which has width and height greater than or equal to the > passed width and height. > There is a known issue on it: JDK-8148619 Select the closest resolution variant in BaseMultiResolutionImage https://bugs.openjdk.java.net/browse/JDK-8148619 Thanks, Alexandr. > > In the case you have suggested dimensions of RED and BLUE images are > 32 and 80 respectively. > > Width and height passed to getResolutionVariant is 64 i.e. scaled > width and height of base image(RED) (GDK_SCALE=2) and blue image is > getting returned. > > The width and height passed to this API is that of base image not of > the spot. > > Applications can control this behaviour by overriding this API in > derived classes. > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 21 July 2016 15:09 > *To:* Semyon Sadetsky; Rajeev Chamyal; swing-dev at openjdk.java.net; > Sergey Bylokhov > *Subject:* Re: [9] Review Request JDK-8147648 [hidpi] > multiresolution image: wrong resolution variant is used as icon in the > Unity panel > > On 7/21/2016 11:49 AM, Semyon Sadetsky wrote: > > Hello Rajeev, > > The taskbar icon is ok now. > > I change the resolution variants from the test a bit: > > final BaseMultiResolutionImage IMG = new > BaseMultiResolutionImage( > new BufferedImage[]{generateImage(4, > Color.RED), generateImage(10, Color.BLUE)}); > > And the icon I see in the taskbar and in the button is blue. It > seems to me the first resolution variant (red) is more appropriate > in this case because its size is closer to the spot. I'm not sure > if this is an issue. > > I have an extra question to you and Alexander. > Most native apps on Linux set an array of icons with _NET_WM_ICON. > Usually they are [16x16, 32x32, 64x64]. > So, desktop environment may select icon of appropriate size. > In this fix we are preselecting icon of a specific size in the app > and send it to WM. > Why not to send array of the resolution variants images and let > the desktop environment to select the appropriate one, like native > apps do? > > This sounds as good idea. MultiResolutionImage has the special > method for this "List getResolutionVariants()". We do the > similar on Mac OS X where NSImage with several representations is > created from a MultiResolutionImage: > http://cr.openjdk.java.net/~alexsch/8028212/webrev.01/src/macosx/classes/sun/lwawt/macosx/CImage.java.udiff.html > > > It has sense to try the same approach on Linux. > > Thanks, > Alexandr. > > > > --Semyon > > On 19.07.2016 23:26, Rajeev Chamyal wrote: > > Hello Semyon, > > Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8147648/webrev.03/ > > > Regards, > > Rajeev Chamyal > > *From:*Semyon Sadetsky > *Sent:* 14 July 2016 16:58 > *To:* Rajeev Chamyal; swing-dev at openjdk.java.net > ; Sergey Bylokhov; > Alexander Scherbatiy > *Subject:* Re: [9] Review Request JDK-8147648 > [hidpi] multiresolution image: wrong resolution variant is > used as icon in the Unity panel > > Hi Rajeev, > > I have added 1px border to the icon in your test: > > private static BufferedImage generateImage(int scale, > Color c) { > int x = SZ * scale; > BufferedImage img = new BufferedImage(x, x, > BufferedImage.TYPE_INT_RGB); > Graphics g = img.getGraphics(); > if (g != null) { > g.setColor(c); > g.fillRect(0, 0, x, x); > g.setColor(Color.YELLOW); > g.drawRect(0, 0, x-1, x-1); > } > return img; > } > > It seems the icon in the taskbar is not correct for UI scale > 1. > > By the way, graphics object should be disposed using > g.dispose() when it is not needed anymore. > > --Semyon > > > On 14.07.2016 10:08, Rajeev Chamyal wrote: > > Hello All, > > Gentle reminder. Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8147648/webrev.02/ > > > Update: simplified the test. > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 22 June 2016 15:46 > *To:* Rajeev Chamyal; Sergey Bylokhov; > swing-dev at openjdk.java.net > *Subject:* Re: [9] Review Request JDK-8147648 > [hidpi] multiresolution image: wrong resolution variant is > used as icon in the Unity panel > > The fix looks good to me. > > Thanks, > Alexandr. > > On 6/22/2016 10:49 AM, Rajeev Chamyal wrote: > > Hello Alexandr, > > Thanks for the review. I have updated webrev as per > comments. > > http://cr.openjdk.java.net/~rchamyal/8147648/webrev.01/ > > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 21 June 2016 17:37 > *To:* Rajeev Chamyal; Sergey Bylokhov; > swing-dev at openjdk.java.net > > *Subject:* Re: [9] Review Request > JDK-8147648 [hidpi] multiresolution image: wrong > resolution variant is used as icon in the Unity panel > > On 6/21/2016 12:16 PM, Rajeev Chamyal wrote: > > Hello All, > > Please review the following webrev. > > Webrev: > http://cr.openjdk.java.net/~rchamyal/8147648/webrev.00/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8147648 > > Issue: Wrong resolution variant is used as icon in > the Unity panel. > > Cause: The screen transforms are not applied to > find the correct resolution variant image in > current implementation. > > Fix: Applied the screen transforms to graphics object. > > > 222 int scaleX = (int)tx.getScaleX(); > 223 int scaleY = (int)tx.getScaleY(); > 224 DataBufferInt buffer = new > DataBufferInt(scaleX * width * scaleY * height); > > The fix is in the shared code and the scale factor > can have floating point value on Windows. (for example > 1.5). > It is better to round the final width and height > after scaling them. > > Thanks, > Alexandr. > > Regards, > > Rajeev Chamyal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Thu Jul 21 15:33:44 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 21 Jul 2016 18:33:44 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> <435db7a0-9ae3-0b81-ca94-5c9258d789af@oracle.com> <8984a4ae-38e6-2cbb-878a-b29f2394828c@oracle.com> <8327e9bc-19f6-8ea0-a5a1-05292921638f@oracle.com> <4faf3887-5857-e827-ecfb-25285b00b959@oracle.com> <5790A187.70004@oracle.com> <88db89fb-4f9a-6bad-3c9e-374ea3b6b488@oracle.com> Message-ID: On 7/21/2016 1:40 PM, Semyon Sadetsky wrote: > On 7/21/2016 1:24 PM, Sergey Bylokhov wrote: > >> On 21.07.16 13:18, Semyon Sadetsky wrote: >>> We do not support non-integer scale on Linux. >> >> If it is unsupported then why it is validated in the pango fonts and >> not in X11GraphicsDevice? I am not sure how scale less than 1 prevent >> us from usage of 1.5 for example. > getNativeScale() returns int. int cannot be 1.5. The fix JDK-8149115 "[hidpi] Linux: display-wise scaling factor should probably be taken into account" allows to read the UI scale factor from some system properties like J2D_UISCALE and com.ubuntu.user-interface scale-factor. Could they have floating point values? How do they relate to the "gnome.Xft/DPI" property from the PangoFonts? Is it possible that the "gnome.Xft/DPI" value is 192 which corresponds to 2x HiDPI display and the J2D_UISCALE is set to 3? Thanks, Alexandr. >> >>> On 21.07.2016 13:13, Sergey Bylokhov wrote: >>>> Is it intended to skip scales less than 1? >>>> >>>> On 07.07.16 10:01, Alexandr Scherbatiy wrote: >>>>> >>>>> The fix looks good to me. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 7/6/2016 10:03 PM, Semyon Sadetsky wrote: >>>>>> On 7/6/2016 6:03 PM, Alexandr Scherbatiy wrote: >>>>>> >>>>>>> On 7/6/2016 4:13 PM, Semyon Sadetsky wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review fix for JDK9: >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8058742 >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.00/ >>>>>>> >>>>>>> - PangoFonts class is placed in the shared space and it uses the >>>>>>> X11GraphicsDevice from the unix space. Could there be problems with >>>>>>> build compilation on platforms differ from Unix? >>>>>> no it doesn't cause compilations problems. PangoFonts is used on >>>>>> Linux >>>>>> platform only. >>>>>>> - It is better to rename the scale field to nativeScale just >>>>>>> to not >>>>>>> mix it with other scale types >>>>>> ok. webrev is updated: >>>>>> http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.01/ >>>>>>> - Does the test >>>>>>> test/java/awt/font/FontScaling/FontScalingTest.java fails without >>>>>>> the proposed fix on Linux? >>>>>> Yes it fails before and passes after the fix. >>>>>> >>>>>> --Semyon >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>>> >>>>>>>> After adding hdpi support to JDK the GTK LnF fonts are scaled >>>>>>>> twice >>>>>>>> using the JDK UI scale factor and the native scale factor derived >>>>>>>> from the screen dpi setting. The fix removes the native scale >>>>>>>> if it >>>>>>>> is already taken into account in the JDK UI scale. >>>>>>>> >>>>>>>> --Semyon >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > From semyon.sadetsky at oracle.com Thu Jul 21 16:04:25 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 21 Jul 2016 19:04:25 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> <435db7a0-9ae3-0b81-ca94-5c9258d789af@oracle.com> <8984a4ae-38e6-2cbb-878a-b29f2394828c@oracle.com> <8327e9bc-19f6-8ea0-a5a1-05292921638f@oracle.com> <4faf3887-5857-e827-ecfb-25285b00b959@oracle.com> <5790A187.70004@oracle.com> <88db89fb-4f9a-6bad-3c9e-374ea3b6b488@oracle.com> Message-ID: <5790F289.1000309@oracle.com> On 21.07.2016 18:33, Alexandr Scherbatiy wrote: > On 7/21/2016 1:40 PM, Semyon Sadetsky wrote: >> On 7/21/2016 1:24 PM, Sergey Bylokhov wrote: >> >>> On 21.07.16 13:18, Semyon Sadetsky wrote: >>>> We do not support non-integer scale on Linux. >>> >>> If it is unsupported then why it is validated in the pango fonts and >>> not in X11GraphicsDevice? I am not sure how scale less than 1 >>> prevent us from usage of 1.5 for example. >> getNativeScale() returns int. int cannot be 1.5. > > The fix JDK-8149115 "[hidpi] Linux: display-wise scaling factor > should probably be taken into account" allows to read the UI scale > factor from some system properties like J2D_UISCALE and > com.ubuntu.user-interface scale-factor. Could they have floating point > values? On the native side they are floating point. But since we do not support floating point scale on linux they are rounded to integer. > How do they relate to the "gnome.Xft/DPI" property from the > PangoFonts? Is it possible that the "gnome.Xft/DPI" value is 192 > which corresponds to 2x HiDPI display and the J2D_UISCALE is set to 3? gnome.Xft/DPI is set by desktop env. Usually it corresponds the system scale from gsettings db. But I cannot guarantee this for any WM/desktop combinations. J2D_UISCALE variable is only for java, it may be set to any value and it is unrelated to the native scale. --Semyon > > Thanks, > Alexandr. > >>> >>>> On 21.07.2016 13:13, Sergey Bylokhov wrote: >>>>> Is it intended to skip scales less than 1? >>>>> >>>>> On 07.07.16 10:01, Alexandr Scherbatiy wrote: >>>>>> >>>>>> The fix looks good to me. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> On 7/6/2016 10:03 PM, Semyon Sadetsky wrote: >>>>>>> On 7/6/2016 6:03 PM, Alexandr Scherbatiy wrote: >>>>>>> >>>>>>>> On 7/6/2016 4:13 PM, Semyon Sadetsky wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Please review fix for JDK9: >>>>>>>>> >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8058742 >>>>>>>>> >>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.00/ >>>>>>>> >>>>>>>> - PangoFonts class is placed in the shared space and it uses >>>>>>>> the >>>>>>>> X11GraphicsDevice from the unix space. Could there be problems >>>>>>>> with >>>>>>>> build compilation on platforms differ from Unix? >>>>>>> no it doesn't cause compilations problems. PangoFonts is used on >>>>>>> Linux >>>>>>> platform only. >>>>>>>> - It is better to rename the scale field to nativeScale just >>>>>>>> to not >>>>>>>> mix it with other scale types >>>>>>> ok. webrev is updated: >>>>>>> http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.01/ >>>>>>>> - Does the test >>>>>>>> test/java/awt/font/FontScaling/FontScalingTest.java fails without >>>>>>>> the proposed fix on Linux? >>>>>>> Yes it fails before and passes after the fix. >>>>>>> >>>>>>> --Semyon >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>>> >>>>>>>>> After adding hdpi support to JDK the GTK LnF fonts are scaled >>>>>>>>> twice >>>>>>>>> using the JDK UI scale factor and the native scale factor derived >>>>>>>>> from the screen dpi setting. The fix removes the native scale >>>>>>>>> if it >>>>>>>>> is already taken into account in the JDK UI scale. >>>>>>>>> >>>>>>>>> --Semyon >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > From semyon.sadetsky at oracle.com Thu Jul 21 17:30:46 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 21 Jul 2016 20:30:46 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> <435db7a0-9ae3-0b81-ca94-5c9258d789af@oracle.com> <8984a4ae-38e6-2cbb-878a-b29f2394828c@oracle.com> <8327e9bc-19f6-8ea0-a5a1-05292921638f@oracle.com> <4faf3887-5857-e827-ecfb-25285b00b959@oracle.com> <5790A187.70004@oracle.com> <88db89fb-4f9a-6bad-3c9e-374ea3b6b488@oracle.com> Message-ID: <579106C6.20805@oracle.com> On 21.07.2016 14:02, Sergey Bylokhov wrote: > On 21.07.16 13:40, Semyon Sadetsky wrote: >>> If it is unsupported then why it is validated in the pango fonts and >>> not in X11GraphicsDevice? I am not sure how scale less than 1 prevent >>> us from usage of 1.5 for example. >> getNativeScale() returns int. int cannot be 1.5. > > Then why PangoFonts.nativeScale is double? or it is a way to apply a > generic solution in case some system will have double scales? In this > case I suggest to request DefaultTransform.scaleY from the gc. In this > case it will not be necessary to use X11GraphicsDevice. Related > question: is this PangoFonts used in printing? DefaultTransform.scaleY got any scale not only the native scale. I think it is not used for printing. I doubt that the LnF is used for printing. --Semyon > >>> >>>> On 2 1.07.2016 13:13, Sergey Bylokhov wrote: >>>>> Is it intended to skip scales less than 1? >>>>> >>>>> On 07.07.16 10:01, Alexandr Scherbatiy wrote: >>>>>> >>>>>> The fix looks good to me. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> On 7/6/2016 10:03 PM, Semyon Sadetsky wrote: >>>>>>> On 7/6/2016 6:03 PM, Alexandr Scherbatiy wrote: >>>>>>> >>>>>>>> On 7/6/2016 4:13 PM, Semyon Sadetsky wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Please review fix for JDK9: >>>>>>>>> >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8058742 >>>>>>>>> >>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.00/ >>>>>>>> >>>>>>>> - PangoFonts class is placed in the shared space and it uses >>>>>>>> the >>>>>>>> X11GraphicsDevice from the unix space. Could there be problems >>>>>>>> with >>>>>>>> build compilation on platforms differ from Unix? >>>>>>> no it doesn't cause compilations problems. PangoFonts is used on >>>>>>> Linux >>>>>>> platform only. >>>>>>>> - It is better to rename the scale field to nativeScale just to >>>>>>>> not >>>>>>>> mix it with other scale types >>>>>>> ok. webrev is updated: >>>>>>> http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.01/ >>>>>>>> - Does the test >>>>>>>> test/java/awt/font/FontScaling/FontScalingTest.java fails without >>>>>>>> the proposed fix on Linux? >>>>>>> Yes it fails before and passes after the fix. >>>>>>> >>>>>>> --Semyon >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>>> >>>>>>>>> After adding hdpi support to JDK the GTK LnF fonts are scaled >>>>>>>>> twice >>>>>>>>> using the JDK UI scale factor and the native scale factor derived >>>>>>>>> from the screen dpi setting. The fix removes the native scale >>>>>>>>> if it >>>>>>>>> is already taken into account in the JDK UI scale. >>>>>>>>> >>>>>>>>> --Semyon >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From Sergey.Bylokhov at oracle.com Thu Jul 21 22:06:01 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 22 Jul 2016 01:06:01 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: <579106C6.20805@oracle.com> References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> <435db7a0-9ae3-0b81-ca94-5c9258d789af@oracle.com> <8984a4ae-38e6-2cbb-878a-b29f2394828c@oracle.com> <8327e9bc-19f6-8ea0-a5a1-05292921638f@oracle.com> <4faf3887-5857-e827-ecfb-25285b00b959@oracle.com> <5790A187.70004@oracle.com> <88db89fb-4f9a-6bad-3c9e-374ea3b6b488@oracle.com> <579106C6.20805@oracle.com> Message-ID: <231b22f8-b2be-8637-a526-dfbaa7f18c9d@oracle.com> On 21.07.16 20:30, Semyon Sadetsky wrote: >> Then why PangoFonts.nativeScale is double? or it is a way to apply a >> generic solution in case some system will have double scales? In this >> case I suggest to request DefaultTransform.scaleY from the gc. In this >> case it will not be necessary to use X11GraphicsDevice. Related >> question: is this PangoFonts used in printing? > DefaultTransform.scaleY got any scale not only the native scale. > I think it is not used for printing. I doubt that the LnF is used for printing. Default transform of the GraphicConfiguration for the screen should use only the native scale inside. And it is not necessary to validate the data which is returned by getDefaultTransform, because it is assumed that the public api return only supported data. >>>>> On 2 1.07.2016 13:13, Sergey Bylokhov wrote: >>>>>> Is it intended to skip scales less than 1? >>>>>> >>>>>> On 07.07.16 10:01, Alexandr Scherbatiy wrote: >>>>>>> >>>>>>> The fix looks good to me. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> On 7/6/2016 10:03 PM, Semyon Sadetsky wrote: >>>>>>>> On 7/6/2016 6:03 PM, Alexandr Scherbatiy wrote: >>>>>>>> >>>>>>>>> On 7/6/2016 4:13 PM, Semyon Sadetsky wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Please review fix for JDK9: >>>>>>>>>> >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8058742 >>>>>>>>>> >>>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.00/ >>>>>>>>> >>>>>>>>> - PangoFonts class is placed in the shared space and it uses >>>>>>>>> the >>>>>>>>> X11GraphicsDevice from the unix space. Could there be problems >>>>>>>>> with >>>>>>>>> build compilation on platforms differ from Unix? >>>>>>>> no it doesn't cause compilations problems. PangoFonts is used on >>>>>>>> Linux >>>>>>>> platform only. >>>>>>>>> - It is better to rename the scale field to nativeScale just to >>>>>>>>> not >>>>>>>>> mix it with other scale types >>>>>>>> ok. webrev is updated: >>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.01/ >>>>>>>>> - Does the test >>>>>>>>> test/java/awt/font/FontScaling/FontScalingTest.java fails without >>>>>>>>> the proposed fix on Linux? >>>>>>>> Yes it fails before and passes after the fix. >>>>>>>> >>>>>>>> --Semyon >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> After adding hdpi support to JDK the GTK LnF fonts are scaled >>>>>>>>>> twice >>>>>>>>>> using the JDK UI scale factor and the native scale factor derived >>>>>>>>>> from the screen dpi setting. The fix removes the native scale >>>>>>>>>> if it >>>>>>>>>> is already taken into account in the JDK UI scale. >>>>>>>>>> >>>>>>>>>> --Semyon >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > -- Best regards, Sergey. From semyon.sadetsky at oracle.com Fri Jul 22 06:58:16 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 22 Jul 2016 09:58:16 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: <231b22f8-b2be-8637-a526-dfbaa7f18c9d@oracle.com> References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> <435db7a0-9ae3-0b81-ca94-5c9258d789af@oracle.com> <8984a4ae-38e6-2cbb-878a-b29f2394828c@oracle.com> <8327e9bc-19f6-8ea0-a5a1-05292921638f@oracle.com> <4faf3887-5857-e827-ecfb-25285b00b959@oracle.com> <5790A187.70004@oracle.com> <88db89fb-4f9a-6bad-3c9e-374ea3b6b488@oracle.com> <579106C6.20805@oracle.com> <231b22f8-b2be-8637-a526-dfbaa7f18c9d@oracle.com> Message-ID: <5791C408.8010500@oracle.com> On 22.07.2016 01:06, Sergey Bylokhov wrote: > On 21.07.16 20:30, Semyon Sadetsky wrote: >>> Then why PangoFonts.nativeScale is double? or it is a way to apply a >>> generic solution in case some system will have double scales? In this >>> case I suggest to request DefaultTransform.scaleY from the gc. In this >>> case it will not be necessary to use X11GraphicsDevice. Related >>> question: is this PangoFonts used in printing? >> DefaultTransform.scaleY got any scale not only the native scale. >> I think it is not used for printing. I doubt that the LnF is used for >> printing. > > Default transform of the GraphicConfiguration for the screen should > use only the native scale inside. And it is not necessary to validate > the data which is returned by getDefaultTransform, because it is > assumed that the public api return only supported data. No. There may be debug scale. If debug scale=10 font size will be 10 less. > > >>>>>> On 2 1.07.2016 13:13, Sergey Bylokhov wrote: >>>>>>> Is it intended to skip scales less than 1? >>>>>>> >>>>>>> On 07.07.16 10:01, Alexandr Scherbatiy wrote: >>>>>>>> >>>>>>>> The fix looks good to me. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>> On 7/6/2016 10:03 PM, Semyon Sadetsky wrote: >>>>>>>>> On 7/6/2016 6:03 PM, Alexandr Scherbatiy wrote: >>>>>>>>> >>>>>>>>>> On 7/6/2016 4:13 PM, Semyon Sadetsky wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> Please review fix for JDK9: >>>>>>>>>>> >>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8058742 >>>>>>>>>>> >>>>>>>>>>> webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.00/ >>>>>>>>>> >>>>>>>>>> - PangoFonts class is placed in the shared space and it uses >>>>>>>>>> the >>>>>>>>>> X11GraphicsDevice from the unix space. Could there be problems >>>>>>>>>> with >>>>>>>>>> build compilation on platforms differ from Unix? >>>>>>>>> no it doesn't cause compilations problems. PangoFonts is used on >>>>>>>>> Linux >>>>>>>>> platform only. >>>>>>>>>> - It is better to rename the scale field to nativeScale >>>>>>>>>> just to >>>>>>>>>> not >>>>>>>>>> mix it with other scale types >>>>>>>>> ok. webrev is updated: >>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.01/ >>>>>>>>>> - Does the test >>>>>>>>>> test/java/awt/font/FontScaling/FontScalingTest.java fails >>>>>>>>>> without >>>>>>>>>> the proposed fix on Linux? >>>>>>>>> Yes it fails before and passes after the fix. >>>>>>>>> >>>>>>>>> --Semyon >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> After adding hdpi support to JDK the GTK LnF fonts are scaled >>>>>>>>>>> twice >>>>>>>>>>> using the JDK UI scale factor and the native scale factor >>>>>>>>>>> derived >>>>>>>>>>> from the screen dpi setting. The fix removes the native scale >>>>>>>>>>> if it >>>>>>>>>>> is already taken into account in the JDK UI scale. >>>>>>>>>>> >>>>>>>>>>> --Semyon >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From rajeev.chamyal at oracle.com Fri Jul 22 09:14:05 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Fri, 22 Jul 2016 02:14:05 -0700 (PDT) Subject: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel In-Reply-To: <508d9383-260e-9841-5fd4-96bc8f0c0239@oracle.com> References: <340c1fa9-7da5-4fcb-9119-0e1e2dcaeb10@default> <9bd7ca3c-2297-0c36-c249-4a9b560275a2@oracle.com> <395e74b7-451e-453e-b552-be2a5bc0e348@default> <30e65d6d-cb35-4c55-b1b2-80752929576a@default> <3d266275-efcd-4d69-bfab-9604467856d1@default> <57877747.3040904@oracle.com> <57908CA9.600@oracle.com> <0cfea8e4-b742-dccf-95cb-46e2ac138bfe@oracle.com> <79509b10-a343-4846-acfd-39c0494a4e93@default> <508d9383-260e-9841-5fd4-96bc8f0c0239@oracle.com> Message-ID: Hello Semyon, Your suggestion regarding _NET_WM_ICON requires some investigation and can be implemented as separate bug. Could you please review the webrev. HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8147648/webrev.03/"http://cr.openjdk.java.net/~rchamyal/8147648/webrev.03/ Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 21 July 2016 20:42 To: Rajeev Chamyal; Semyon Sadetsky; swing-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel On 7/21/2016 5:25 PM, Rajeev Chamyal wrote: Hello Semyon, The resolution variant image returned is based on the implementation of BaseMultiResolutionImage::getResolutionVariant API. Current implementation of BaseMultiResolutionImage::getResolutionVariant returns a resolution variant image which has width and height greater than or equal to the passed width and height. There is a known issue on it: JDK-8148619 Select the closest resolution variant in BaseMultiResolutionImage https://bugs.openjdk.java.net/browse/JDK-8148619 Thanks, Alexandr. In the case you have suggested dimensions of RED and BLUE images are 32 and 80 respectively. Width and height passed to getResolutionVariant is 64 i.e. scaled width and height of base image(RED) (GDK_SCALE=2) and blue image is getting returned. The width and height passed to this API is that of base image not of the spot. Applications can control this behaviour by overriding this API in derived classes. Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 21 July 2016 15:09 To: Semyon Sadetsky; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel On 7/21/2016 11:49 AM, Semyon Sadetsky wrote: Hello Rajeev, The taskbar icon is ok now. I change the resolution variants from the test a bit: final BaseMultiResolutionImage IMG = new BaseMultiResolutionImage( new BufferedImage[]{generateImage(4, Color.RED), generateImage(10, Color.BLUE)}); And the icon I see in the taskbar and in the button is blue. It seems to me the first resolution variant (red) is more appropriate in this case because its size is closer to the spot. I'm not sure if this is an issue. I have an extra question to you and Alexander. Most native apps on Linux set an array of icons with _NET_WM_ICON. Usually they are [16x16, 32x32, 64x64]. So, desktop environment may select icon of appropriate size. In this fix we are preselecting icon of a specific size in the app and send it to WM. Why not to send array of the resolution variants images and let the desktop environment to select the appropriate one, like native apps do? This sounds as good idea. MultiResolutionImage has the special method for this "List getResolutionVariants()". We do the similar on Mac OS X where NSImage with several representations is created from a MultiResolutionImage: HYPERLINK "http://cr.openjdk.java.net/%7Ealexsch/8028212/webrev.01/src/macosx/classes/sun/lwawt/macosx/CImage.java.udiff.html"http://cr.openjdk.java.net/~alexsch/8028212/webrev.01/src/macosx/classes/sun/lwawt/macosx/CImage.java.udiff.html It has sense to try the same approach on Linux. Thanks, Alexandr. --Semyon On 19.07.2016 23:26, Rajeev Chamyal wrote: Hello Semyon, Please review the updated webrev. HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8147648/webrev.03/"http://cr.openjdk.java.net/~rchamyal/8147648/webrev.03/ Regards, Rajeev Chamyal From: Semyon Sadetsky Sent: 14 July 2016 16:58 To: Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov; Alexander Scherbatiy Subject: Re: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel Hi Rajeev, I have added 1px border to the icon in your test: private static BufferedImage generateImage(int scale, Color c) { int x = SZ * scale; BufferedImage img = new BufferedImage(x, x, BufferedImage.TYPE_INT_RGB); Graphics g = img.getGraphics(); if (g != null) { g.setColor(c); g.fillRect(0, 0, x, x); g.setColor(Color.YELLOW); g.drawRect(0, 0, x-1, x-1); } return img; } It seems the icon in the taskbar is not correct for UI scale > 1. By the way, graphics object should be disposed using g.dispose() when it is not needed anymore. --Semyon On 14.07.2016 10:08, Rajeev Chamyal wrote: Hello All, Gentle reminder. Please review the updated webrev. HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8147648/webrev.02/"http://cr.openjdk.java.net/~rchamyal/8147648/webrev.02/ Update: simplified the test. Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 22 June 2016 15:46 To: Rajeev Chamyal; Sergey Bylokhov; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel The fix looks good to me. Thanks, Alexandr. On 6/22/2016 10:49 AM, Rajeev Chamyal wrote: Hello Alexandr, Thanks for the review. I have updated webrev as per comments. HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8147648/webrev.01/"http://cr.openjdk.java.net/~rchamyal/8147648/webrev.01/ Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 21 June 2016 17:37 To: Rajeev Chamyal; Sergey Bylokhov; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel On 6/21/2016 12:16 PM, Rajeev Chamyal wrote: Hello All, Please review the following webrev. Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8147648/webrev.00/"http://cr.openjdk.java.net/~rchamyal/8147648/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8147648 Issue: Wrong resolution variant is used as icon in the Unity panel. Cause: The screen transforms are not applied to find the correct resolution variant image in current implementation. Fix: Applied the screen transforms to graphics object. 222 int scaleX = (int)tx.getScaleX(); 223 int scaleY = (int)tx.getScaleY(); 224 DataBufferInt buffer = new DataBufferInt(scaleX * width * scaleY * height); The fix is in the shared code and the scale factor can have floating point value on Windows. (for example 1.5). It is better to round the final width and height after scaling them. Thanks, Alexandr. Regards, Rajeev Chamyal -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Fri Jul 22 09:50:42 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 22 Jul 2016 12:50:42 +0300 Subject: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel In-Reply-To: References: <340c1fa9-7da5-4fcb-9119-0e1e2dcaeb10@default> <9bd7ca3c-2297-0c36-c249-4a9b560275a2@oracle.com> <395e74b7-451e-453e-b552-be2a5bc0e348@default> <30e65d6d-cb35-4c55-b1b2-80752929576a@default> <3d266275-efcd-4d69-bfab-9604467856d1@default> <57877747.3040904@oracle.com> <57908CA9.600@oracle.com> <0cfea8e4-b742-dccf-95cb-46e2ac138bfe@oracle.com> <79509b10-a343-4846-acfd-39c0494a4e93@default> <508d9383-260e-9841-5fd4-96bc8f0c0239@oracle.com> Message-ID: <9b329c6a-5f54-4184-e047-6c78357c549e@oracle.com> On 7/22/2016 12:14 PM, Rajeev Chamyal wrote: > Hello Semyon, > > Your suggestion regarding _NET_WM_ICON requires some investigation and > can be implemented as separate bug. > Ok. Please create this bug. --Semyon > > Could you please review the webrev. > > http://cr.openjdk.java.net/~rchamyal/8147648/webrev.03/ > > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 21 July 2016 20:42 > *To:* Rajeev Chamyal; Semyon Sadetsky; swing-dev at openjdk.java.net; > Sergey Bylokhov > *Subject:* Re: [9] Review Request JDK-8147648 [hidpi] > multiresolution image: wrong resolution variant is used as icon in the > Unity panel > > On 7/21/2016 5:25 PM, Rajeev Chamyal wrote: > > Hello Semyon, > > The resolution variant image returned is based on the > implementation of BaseMultiResolutionImage::getResolutionVariant API. > > Current implementation of > BaseMultiResolutionImage::getResolutionVariant returns a > resolution variant image which has width and height greater than > or equal to the passed width and height. > > There is a known issue on it: > JDK-8148619 Select the closest resolution variant in > BaseMultiResolutionImage > https://bugs.openjdk.java.net/browse/JDK-8148619 > > Thanks, > Alexandr. > > In the case you have suggested dimensions of RED and BLUE images > are 32 and 80 respectively. > > Width and height passed to getResolutionVariant is 64 i.e. scaled > width and height of base image(RED) (GDK_SCALE=2) and blue image > is getting returned. > > The width and height passed to this API is that of base image not > of the spot. > > Applications can control this behaviour by overriding this API in > derived classes. > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 21 July 2016 15:09 > *To:* Semyon Sadetsky; Rajeev Chamyal; swing-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: [9] Review Request JDK-8147648 [hidpi] > multiresolution image: wrong resolution variant is used as icon in > the Unity panel > > On 7/21/2016 11:49 AM, Semyon Sadetsky wrote: > > > Hello Rajeev, > > The taskbar icon is ok now. > > I change the resolution variants from the test a bit: > > final BaseMultiResolutionImage IMG = new > BaseMultiResolutionImage( > new BufferedImage[]{generateImage(4, > Color.RED), generateImage(10, Color.BLUE)}); > > And the icon I see in the taskbar and in the button is blue. > It seems to me the first resolution variant (red) is more > appropriate in this case because its size is closer to the > spot. I'm not sure if this is an issue. > > I have an extra question to you and Alexander. > Most native apps on Linux set an array of icons with > _NET_WM_ICON. Usually they are [16x16, 32x32, 64x64]. > So, desktop environment may select icon of appropriate size. > In this fix we are preselecting icon of a specific size in the > app and send it to WM. > Why not to send array of the resolution variants images and > let the desktop environment to select the appropriate one, > like native apps do? > > This sounds as good idea. MultiResolutionImage has the special > method for this "List getResolutionVariants()". We do the > similar on Mac OS X where NSImage with several representations is > created from a MultiResolutionImage: > http://cr.openjdk.java.net/~alexsch/8028212/webrev.01/src/macosx/classes/sun/lwawt/macosx/CImage.java.udiff.html > > > It has sense to try the same approach on Linux. > > Thanks, > Alexandr. > > > > > --Semyon > > On 19.07.2016 23:26, Rajeev Chamyal wrote: > > Hello Semyon, > > Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8147648/webrev.03/ > > > Regards, > > Rajeev Chamyal > > *From:*Semyon Sadetsky > *Sent:* 14 July 2016 16:58 > *To:* Rajeev Chamyal; swing-dev at openjdk.java.net > ; Sergey Bylokhov; > Alexander Scherbatiy > *Subject:* Re: [9] Review Request JDK-8147648 > [hidpi] multiresolution image: wrong resolution variant is > used as icon in the Unity panel > > Hi Rajeev, > > I have added 1px border to the icon in your test: > > private static BufferedImage generateImage(int scale, > Color c) { > int x = SZ * scale; > BufferedImage img = new BufferedImage(x, x, > BufferedImage.TYPE_INT_RGB); > Graphics g = img.getGraphics(); > if (g != null) { > g.setColor(c); > g.fillRect(0, 0, x, x); > g.setColor(Color.YELLOW); > g.drawRect(0, 0, x-1, x-1); > } > return img; > } > > It seems the icon in the taskbar is not correct for UI > scale > 1. > > By the way, graphics object should be disposed using > g.dispose() when it is not needed anymore. > > --Semyon > > > > On 14.07.2016 10:08, Rajeev Chamyal wrote: > > Hello All, > > Gentle reminder. Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8147648/webrev.02/ > > > Update: simplified the test. > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 22 June 2016 15:46 > *To:* Rajeev Chamyal; Sergey Bylokhov; > swing-dev at openjdk.java.net > > *Subject:* Re: [9] Review Request > JDK-8147648 [hidpi] multiresolution image: wrong > resolution variant is used as icon in the Unity panel > > The fix looks good to me. > > Thanks, > Alexandr. > > On 6/22/2016 10:49 AM, Rajeev Chamyal wrote: > > Hello Alexandr, > > Thanks for the review. I have updated webrev as > per comments. > > http://cr.openjdk.java.net/~rchamyal/8147648/webrev.01/ > > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 21 June 2016 17:37 > *To:* Rajeev Chamyal; Sergey Bylokhov; > swing-dev at openjdk.java.net > > *Subject:* Re: [9] Review Request > JDK-8147648 [hidpi] multiresolution image: wrong > resolution variant is used as icon in the Unity panel > > On 6/21/2016 12:16 PM, Rajeev Chamyal wrote: > > Hello All, > > Please review the following webrev. > > Webrev: > http://cr.openjdk.java.net/~rchamyal/8147648/webrev.00/ > > > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8147648 > > Issue: Wrong resolution variant is used as > icon in the Unity panel. > > Cause: The screen transforms are not applied > to find the correct resolution variant image > in current implementation. > > Fix: Applied the screen transforms to graphics > object. > > > 222 int scaleX = (int)tx.getScaleX(); > 223 int scaleY = (int)tx.getScaleY(); > 224 DataBufferInt buffer = new > DataBufferInt(scaleX * width * scaleY * height); > > The fix is in the shared code and the scale > factor can have floating point value on Windows. > (for example 1.5). > It is better to round the final width and height > after scaling them. > > Thanks, > Alexandr. > > Regards, > > Rajeev Chamyal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajeev.chamyal at oracle.com Fri Jul 22 10:04:09 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Fri, 22 Jul 2016 03:04:09 -0700 (PDT) Subject: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel In-Reply-To: <9b329c6a-5f54-4184-e047-6c78357c549e@oracle.com> References: <340c1fa9-7da5-4fcb-9119-0e1e2dcaeb10@default> <9bd7ca3c-2297-0c36-c249-4a9b560275a2@oracle.com> <395e74b7-451e-453e-b552-be2a5bc0e348@default> <30e65d6d-cb35-4c55-b1b2-80752929576a@default> <3d266275-efcd-4d69-bfab-9604467856d1@default> <57877747.3040904@oracle.com> <57908CA9.600@oracle.com> <0cfea8e4-b742-dccf-95cb-46e2ac138bfe@oracle.com> <79509b10-a343-4846-acfd-39c0494a4e93@default> <508d9383-260e-9841-5fd4-96bc8f0c0239@oracle.com> <9b329c6a-5f54-4184-e047-6c78357c549e@oracle.com> Message-ID: Hello Semyon, Below is the bug id. https://bugs.openjdk.java.net/browse/JDK-8162387 Regards, Rajeev Chamyal From: Semyon Sadetsky Sent: 22 July 2016 15:21 To: Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel On 7/22/2016 12:14 PM, Rajeev Chamyal wrote: Hello Semyon, Your suggestion regarding _NET_WM_ICON requires some investigation and can be implemented as separate bug. Ok. Please create this bug. --Semyon Could you please review the webrev. HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8147648/webrev.03/"http://cr.openjdk.java.net/~rchamyal/8147648/webrev.03/ Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 21 July 2016 20:42 To: Rajeev Chamyal; Semyon Sadetsky; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel On 7/21/2016 5:25 PM, Rajeev Chamyal wrote: Hello Semyon, The resolution variant image returned is based on the implementation of BaseMultiResolutionImage::getResolutionVariant API. Current implementation of BaseMultiResolutionImage::getResolutionVariant returns a resolution variant image which has width and height greater than or equal to the passed width and height. There is a known issue on it: JDK-8148619 Select the closest resolution variant in BaseMultiResolutionImage https://bugs.openjdk.java.net/browse/JDK-8148619 Thanks, Alexandr. In the case you have suggested dimensions of RED and BLUE images are 32 and 80 respectively. Width and height passed to getResolutionVariant is 64 i.e. scaled width and height of base image(RED) (GDK_SCALE=2) and blue image is getting returned. The width and height passed to this API is that of base image not of the spot. Applications can control this behaviour by overriding this API in derived classes. Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 21 July 2016 15:09 To: Semyon Sadetsky; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel On 7/21/2016 11:49 AM, Semyon Sadetsky wrote: Hello Rajeev, The taskbar icon is ok now. I change the resolution variants from the test a bit: final BaseMultiResolutionImage IMG = new BaseMultiResolutionImage( new BufferedImage[]{generateImage(4, Color.RED), generateImage(10, Color.BLUE)}); And the icon I see in the taskbar and in the button is blue. It seems to me the first resolution variant (red) is more appropriate in this case because its size is closer to the spot. I'm not sure if this is an issue. I have an extra question to you and Alexander. Most native apps on Linux set an array of icons with _NET_WM_ICON. Usually they are [16x16, 32x32, 64x64]. So, desktop environment may select icon of appropriate size. In this fix we are preselecting icon of a specific size in the app and send it to WM. Why not to send array of the resolution variants images and let the desktop environment to select the appropriate one, like native apps do? This sounds as good idea. MultiResolutionImage has the special method for this "List getResolutionVariants()". We do the similar on Mac OS X where NSImage with several representations is created from a MultiResolutionImage: HYPERLINK "http://cr.openjdk.java.net/%7Ealexsch/8028212/webrev.01/src/macosx/classes/sun/lwawt/macosx/CImage.java.udiff.html"http://cr.openjdk.java.net/~alexsch/8028212/webrev.01/src/macosx/classes/sun/lwawt/macosx/CImage.java.udiff.html It has sense to try the same approach on Linux. Thanks, Alexandr. --Semyon On 19.07.2016 23:26, Rajeev Chamyal wrote: Hello Semyon, Please review the updated webrev. HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8147648/webrev.03/"http://cr.openjdk.java.net/~rchamyal/8147648/webrev.03/ Regards, Rajeev Chamyal From: Semyon Sadetsky Sent: 14 July 2016 16:58 To: Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov; Alexander Scherbatiy Subject: Re: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel Hi Rajeev, I have added 1px border to the icon in your test: private static BufferedImage generateImage(int scale, Color c) { int x = SZ * scale; BufferedImage img = new BufferedImage(x, x, BufferedImage.TYPE_INT_RGB); Graphics g = img.getGraphics(); if (g != null) { g.setColor(c); g.fillRect(0, 0, x, x); g.setColor(Color.YELLOW); g.drawRect(0, 0, x-1, x-1); } return img; } It seems the icon in the taskbar is not correct for UI scale > 1. By the way, graphics object should be disposed using g.dispose() when it is not needed anymore. --Semyon On 14.07.2016 10:08, Rajeev Chamyal wrote: Hello All, Gentle reminder. Please review the updated webrev. HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8147648/webrev.02/"http://cr.openjdk.java.net/~rchamyal/8147648/webrev.02/ Update: simplified the test. Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 22 June 2016 15:46 To: Rajeev Chamyal; Sergey Bylokhov; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel The fix looks good to me. Thanks, Alexandr. On 6/22/2016 10:49 AM, Rajeev Chamyal wrote: Hello Alexandr, Thanks for the review. I have updated webrev as per comments. HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8147648/webrev.01/"http://cr.openjdk.java.net/~rchamyal/8147648/webrev.01/ Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 21 June 2016 17:37 To: Rajeev Chamyal; Sergey Bylokhov; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel On 6/21/2016 12:16 PM, Rajeev Chamyal wrote: Hello All, Please review the following webrev. Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8147648/webrev.00/"http://cr.openjdk.java.net/~rchamyal/8147648/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8147648 Issue: Wrong resolution variant is used as icon in the Unity panel. Cause: The screen transforms are not applied to find the correct resolution variant image in current implementation. Fix: Applied the screen transforms to graphics object. 222 int scaleX = (int)tx.getScaleX(); 223 int scaleY = (int)tx.getScaleY(); 224 DataBufferInt buffer = new DataBufferInt(scaleX * width * scaleY * height); The fix is in the shared code and the scale factor can have floating point value on Windows. (for example 1.5). It is better to round the final width and height after scaling them. Thanks, Alexandr. Regards, Rajeev Chamyal -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Fri Jul 22 10:20:54 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 22 Jul 2016 13:20:54 +0300 Subject: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel In-Reply-To: References: <340c1fa9-7da5-4fcb-9119-0e1e2dcaeb10@default> <9bd7ca3c-2297-0c36-c249-4a9b560275a2@oracle.com> <395e74b7-451e-453e-b552-be2a5bc0e348@default> <30e65d6d-cb35-4c55-b1b2-80752929576a@default> <3d266275-efcd-4d69-bfab-9604467856d1@default> <57877747.3040904@oracle.com> <57908CA9.600@oracle.com> <0cfea8e4-b742-dccf-95cb-46e2ac138bfe@oracle.com> <79509b10-a343-4846-acfd-39c0494a4e93@default> <508d9383-260e-9841-5fd4-96bc8f0c0239@oracle.com> <9b329c6a-5f54-4184-e047-6c78357c549e@oracle.com> Message-ID: <79c4d6a4-493b-6136-2e10-e154076e6c46@oracle.com> On 7/22/2016 1:04 PM, Rajeev Chamyal wrote: > Hello Semyon, > > Below is the bug id. > > https://bugs.openjdk.java.net/browse/JDK-8162387 > Please add [hidpi] prefix to the title. Also link it to the JDK-8147648. --Semyon > > Regards, > > Rajeev Chamyal > > *From:*Semyon Sadetsky > *Sent:* 22 July 2016 15:21 > *To:* Rajeev Chamyal; Alexander Scherbatiy; > swing-dev at openjdk.java.net; Sergey Bylokhov > *Subject:* Re: [9] Review Request JDK-8147648 [hidpi] > multiresolution image: wrong resolution variant is used as icon in the > Unity panel > > On 7/22/2016 12:14 PM, Rajeev Chamyal wrote: > > Hello Semyon, > > Your suggestion regarding _NET_WM_ICON requires some investigation > and can be implemented as separate bug. > > Ok. Please create this bug. > > --Semyon > > Could you please review the webrev. > > http://cr.openjdk.java.net/~rchamyal/8147648/webrev.03/ > > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 21 July 2016 20:42 > *To:* Rajeev Chamyal; Semyon Sadetsky; swing-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: [9] Review Request JDK-8147648 [hidpi] > multiresolution image: wrong resolution variant is used as icon in > the Unity panel > > On 7/21/2016 5:25 PM, Rajeev Chamyal wrote: > > > Hello Semyon, > > The resolution variant image returned is based on the > implementation of > BaseMultiResolutionImage::getResolutionVariant API. > > Current implementation of > BaseMultiResolutionImage::getResolutionVariant returns a > resolution variant image which has width and height greater > than or equal to the passed width and height. > > There is a known issue on it: > JDK-8148619 Select the closest resolution variant in > BaseMultiResolutionImage > https://bugs.openjdk.java.net/browse/JDK-8148619 > > Thanks, > Alexandr. > > > In the case you have suggested dimensions of RED and BLUE > images are 32 and 80 respectively. > > Width and height passed to getResolutionVariant is 64 i.e. > scaled width and height of base image(RED) (GDK_SCALE=2) and > blue image is getting returned. > > The width and height passed to this API is that of base image > not of the spot. > > Applications can control this behaviour by overriding this API > in derived classes. > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 21 July 2016 15:09 > *To:* Semyon Sadetsky; Rajeev Chamyal; > swing-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: [9] Review Request JDK-8147648 > [hidpi] multiresolution image: wrong resolution variant is > used as icon in the Unity panel > > On 7/21/2016 11:49 AM, Semyon Sadetsky wrote: > > > > Hello Rajeev, > > The taskbar icon is ok now. > > I change the resolution variants from the test a bit: > > final BaseMultiResolutionImage IMG = new > BaseMultiResolutionImage( > new > BufferedImage[]{generateImage(4, Color.RED), > generateImage(10, Color.BLUE)}); > > And the icon I see in the taskbar and in the button is > blue. It seems to me the first resolution variant (red) is > more appropriate in this case because its size is closer > to the spot. I'm not sure if this is an issue. > > I have an extra question to you and Alexander. > Most native apps on Linux set an array of icons with > _NET_WM_ICON. Usually they are [16x16, 32x32, 64x64]. > So, desktop environment may select icon of appropriate size. > In this fix we are preselecting icon of a specific size in > the app and send it to WM. > Why not to send array of the resolution variants images > and let the desktop environment to select the appropriate > one, like native apps do? > > This sounds as good idea. MultiResolutionImage has the > special method for this "List getResolutionVariants()". > We do the similar on Mac OS X where NSImage with several > representations is created from a MultiResolutionImage: > http://cr.openjdk.java.net/~alexsch/8028212/webrev.01/src/macosx/classes/sun/lwawt/macosx/CImage.java.udiff.html > > > It has sense to try the same approach on Linux. > > Thanks, > Alexandr. > > > > > > --Semyon > > On 19.07.2016 23:26, Rajeev Chamyal wrote: > > Hello Semyon, > > Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8147648/webrev.03/ > > > Regards, > > Rajeev Chamyal > > *From:*Semyon Sadetsky > *Sent:* 14 July 2016 16:58 > *To:* Rajeev Chamyal; swing-dev at openjdk.java.net > ; Sergey Bylokhov; > Alexander Scherbatiy > *Subject:* Re: [9] Review Request > JDK-8147648 [hidpi] multiresolution image: wrong > resolution variant is used as icon in the Unity panel > > Hi Rajeev, > > I have added 1px border to the icon in your test: > > private static BufferedImage generateImage(int > scale, Color c) { > int x = SZ * scale; > BufferedImage img = new BufferedImage(x, x, > BufferedImage.TYPE_INT_RGB); > Graphics g = img.getGraphics(); > if (g != null) { > g.setColor(c); > g.fillRect(0, 0, x, x); > g.setColor(Color.YELLOW); > g.drawRect(0, 0, x-1, x-1); > } > return img; > } > > It seems the icon in the taskbar is not correct for UI > scale > 1. > > By the way, graphics object should be disposed using > g.dispose() when it is not needed anymore. > > --Semyon > > > > > On 14.07.2016 10:08, Rajeev Chamyal wrote: > > Hello All, > > Gentle reminder. Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8147648/webrev.02/ > > > Update: simplified the test. > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 22 June 2016 15:46 > *To:* Rajeev Chamyal; Sergey Bylokhov; > swing-dev at openjdk.java.net > > *Subject:* Re: [9] Review Request > JDK-8147648 [hidpi] multiresolution image: wrong > resolution variant is used as icon in the Unity panel > > The fix looks good to me. > > Thanks, > Alexandr. > > On 6/22/2016 10:49 AM, Rajeev Chamyal wrote: > > Hello Alexandr, > > Thanks for the review. I have updated webrev > as per comments. > > http://cr.openjdk.java.net/~rchamyal/8147648/webrev.01/ > > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 21 June 2016 17:37 > *To:* Rajeev Chamyal; Sergey Bylokhov; > swing-dev at openjdk.java.net > > *Subject:* Re: [9] Review Request > JDK-8147648 [hidpi] multiresolution image: > wrong resolution variant is used as icon in > the Unity panel > > On 6/21/2016 12:16 PM, Rajeev Chamyal wrote: > > Hello All, > > Please review the following webrev. > > Webrev: > http://cr.openjdk.java.net/~rchamyal/8147648/webrev.00/ > > > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8147648 > > > Issue: Wrong resolution variant is used as > icon in the Unity panel. > > Cause: The screen transforms are not > applied to find the correct resolution > variant image in current implementation. > > Fix: Applied the screen transforms to > graphics object. > > > 222 int scaleX = (int)tx.getScaleX(); > 223 int scaleY = (int)tx.getScaleY(); > 224 DataBufferInt buffer = new > DataBufferInt(scaleX * width * scaleY * height); > > The fix is in the shared code and the scale > factor can have floating point value on > Windows. (for example 1.5). > It is better to round the final width and > height after scaling them. > > Thanks, > Alexandr. > > Regards, > > Rajeev Chamyal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajeev.chamyal at oracle.com Fri Jul 22 10:26:52 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Fri, 22 Jul 2016 03:26:52 -0700 (PDT) Subject: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel In-Reply-To: <79c4d6a4-493b-6136-2e10-e154076e6c46@oracle.com> References: <340c1fa9-7da5-4fcb-9119-0e1e2dcaeb10@default> <9bd7ca3c-2297-0c36-c249-4a9b560275a2@oracle.com> <395e74b7-451e-453e-b552-be2a5bc0e348@default> <30e65d6d-cb35-4c55-b1b2-80752929576a@default> <3d266275-efcd-4d69-bfab-9604467856d1@default> <57877747.3040904@oracle.com> <57908CA9.600@oracle.com> <0cfea8e4-b742-dccf-95cb-46e2ac138bfe@oracle.com> <79509b10-a343-4846-acfd-39c0494a4e93@default> <508d9383-260e-9841-5fd4-96bc8f0c0239@oracle.com> <9b329c6a-5f54-4184-e047-6c78357c549e@oracle.com> <79c4d6a4-493b-6136-2e10-e154076e6c46@oracle.com> Message-ID: Linked to 8147648, added prefix Hidpi. Regards, Rajeev Chamyal From: Semyon Sadetsky Sent: 22 July 2016 15:51 To: Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel On 7/22/2016 1:04 PM, Rajeev Chamyal wrote: Hello Semyon, Below is the bug id. https://bugs.openjdk.java.net/browse/JDK-8162387 Please add [hidpi] prefix to the title. Also link it to the JDK-8147648. --Semyon Regards, Rajeev Chamyal From: Semyon Sadetsky Sent: 22 July 2016 15:21 To: Rajeev Chamyal; Alexander Scherbatiy; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel On 7/22/2016 12:14 PM, Rajeev Chamyal wrote: Hello Semyon, Your suggestion regarding _NET_WM_ICON requires some investigation and can be implemented as separate bug. Ok. Please create this bug. --Semyon Could you please review the webrev. HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8147648/webrev.03/"http://cr.openjdk.java.net/~rchamyal/8147648/webrev.03/ Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 21 July 2016 20:42 To: Rajeev Chamyal; Semyon Sadetsky; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel On 7/21/2016 5:25 PM, Rajeev Chamyal wrote: Hello Semyon, The resolution variant image returned is based on the implementation of BaseMultiResolutionImage::getResolutionVariant API. Current implementation of BaseMultiResolutionImage::getResolutionVariant returns a resolution variant image which has width and height greater than or equal to the passed width and height. There is a known issue on it: JDK-8148619 Select the closest resolution variant in BaseMultiResolutionImage https://bugs.openjdk.java.net/browse/JDK-8148619 Thanks, Alexandr. In the case you have suggested dimensions of RED and BLUE images are 32 and 80 respectively. Width and height passed to getResolutionVariant is 64 i.e. scaled width and height of base image(RED) (GDK_SCALE=2) and blue image is getting returned. The width and height passed to this API is that of base image not of the spot. Applications can control this behaviour by overriding this API in derived classes. Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 21 July 2016 15:09 To: Semyon Sadetsky; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel On 7/21/2016 11:49 AM, Semyon Sadetsky wrote: Hello Rajeev, The taskbar icon is ok now. I change the resolution variants from the test a bit: final BaseMultiResolutionImage IMG = new BaseMultiResolutionImage( new BufferedImage[]{generateImage(4, Color.RED), generateImage(10, Color.BLUE)}); And the icon I see in the taskbar and in the button is blue. It seems to me the first resolution variant (red) is more appropriate in this case because its size is closer to the spot. I'm not sure if this is an issue. I have an extra question to you and Alexander. Most native apps on Linux set an array of icons with _NET_WM_ICON. Usually they are [16x16, 32x32, 64x64]. So, desktop environment may select icon of appropriate size. In this fix we are preselecting icon of a specific size in the app and send it to WM. Why not to send array of the resolution variants images and let the desktop environment to select the appropriate one, like native apps do? This sounds as good idea. MultiResolutionImage has the special method for this "List getResolutionVariants()". We do the similar on Mac OS X where NSImage with several representations is created from a MultiResolutionImage: HYPERLINK "http://cr.openjdk.java.net/%7Ealexsch/8028212/webrev.01/src/macosx/classes/sun/lwawt/macosx/CImage.java.udiff.html"http://cr.openjdk.java.net/~alexsch/8028212/webrev.01/src/macosx/classes/sun/lwawt/macosx/CImage.java.udiff.html It has sense to try the same approach on Linux. Thanks, Alexandr. --Semyon On 19.07.2016 23:26, Rajeev Chamyal wrote: Hello Semyon, Please review the updated webrev. HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8147648/webrev.03/"http://cr.openjdk.java.net/~rchamyal/8147648/webrev.03/ Regards, Rajeev Chamyal From: Semyon Sadetsky Sent: 14 July 2016 16:58 To: Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov; Alexander Scherbatiy Subject: Re: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel Hi Rajeev, I have added 1px border to the icon in your test: private static BufferedImage generateImage(int scale, Color c) { int x = SZ * scale; BufferedImage img = new BufferedImage(x, x, BufferedImage.TYPE_INT_RGB); Graphics g = img.getGraphics(); if (g != null) { g.setColor(c); g.fillRect(0, 0, x, x); g.setColor(Color.YELLOW); g.drawRect(0, 0, x-1, x-1); } return img; } It seems the icon in the taskbar is not correct for UI scale > 1. By the way, graphics object should be disposed using g.dispose() when it is not needed anymore. --Semyon On 14.07.2016 10:08, Rajeev Chamyal wrote: Hello All, Gentle reminder. Please review the updated webrev. HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8147648/webrev.02/"http://cr.openjdk.java.net/~rchamyal/8147648/webrev.02/ Update: simplified the test. Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 22 June 2016 15:46 To: Rajeev Chamyal; Sergey Bylokhov; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel The fix looks good to me. Thanks, Alexandr. On 6/22/2016 10:49 AM, Rajeev Chamyal wrote: Hello Alexandr, Thanks for the review. I have updated webrev as per comments. HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8147648/webrev.01/"http://cr.openjdk.java.net/~rchamyal/8147648/webrev.01/ Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 21 June 2016 17:37 To: Rajeev Chamyal; Sergey Bylokhov; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel On 6/21/2016 12:16 PM, Rajeev Chamyal wrote: Hello All, Please review the following webrev. Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8147648/webrev.00/"http://cr.openjdk.java.net/~rchamyal/8147648/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8147648 Issue: Wrong resolution variant is used as icon in the Unity panel. Cause: The screen transforms are not applied to find the correct resolution variant image in current implementation. Fix: Applied the screen transforms to graphics object. 222 int scaleX = (int)tx.getScaleX(); 223 int scaleY = (int)tx.getScaleY(); 224 DataBufferInt buffer = new DataBufferInt(scaleX * width * scaleY * height); The fix is in the shared code and the scale factor can have floating point value on Windows. (for example 1.5). It is better to round the final width and height after scaling them. Thanks, Alexandr. Regards, Rajeev Chamyal -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Fri Jul 22 10:39:46 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 22 Jul 2016 13:39:46 +0300 Subject: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel In-Reply-To: References: <340c1fa9-7da5-4fcb-9119-0e1e2dcaeb10@default> <9bd7ca3c-2297-0c36-c249-4a9b560275a2@oracle.com> <395e74b7-451e-453e-b552-be2a5bc0e348@default> <30e65d6d-cb35-4c55-b1b2-80752929576a@default> <3d266275-efcd-4d69-bfab-9604467856d1@default> <57877747.3040904@oracle.com> <57908CA9.600@oracle.com> <0cfea8e4-b742-dccf-95cb-46e2ac138bfe@oracle.com> <79509b10-a343-4846-acfd-39c0494a4e93@default> <508d9383-260e-9841-5fd4-96bc8f0c0239@oracle.com> <9b329c6a-5f54-4184-e047-6c78357c549e@oracle.com> <79c4d6a4-493b-6136-2e10-e154076e6c46@oracle.com> Message-ID: On 7/22/2016 1:26 PM, Rajeev Chamyal wrote: > Linked to 8147648, added prefix Hidpi. > Thanks. The fix looks good to me. --Semyon > > Regards, > > Rajeev Chamyal > > *From:*Semyon Sadetsky > *Sent:* 22 July 2016 15:51 > *To:* Rajeev Chamyal; Alexander Scherbatiy; > swing-dev at openjdk.java.net; Sergey Bylokhov > *Subject:* Re: [9] Review Request JDK-8147648 [hidpi] > multiresolution image: wrong resolution variant is used as icon in the > Unity panel > > On 7/22/2016 1:04 PM, Rajeev Chamyal wrote: > > Hello Semyon, > > Below is the bug id. > > https://bugs.openjdk.java.net/browse/JDK-8162387 > > Please add [hidpi] prefix to the title. Also link it to the JDK-8147648. > > --Semyon > > Regards, > > Rajeev Chamyal > > *From:*Semyon Sadetsky > *Sent:* 22 July 2016 15:21 > *To:* Rajeev Chamyal; Alexander Scherbatiy; > swing-dev at openjdk.java.net ; > Sergey Bylokhov > *Subject:* Re: [9] Review Request JDK-8147648 [hidpi] > multiresolution image: wrong resolution variant is used as icon in > the Unity panel > > On 7/22/2016 12:14 PM, Rajeev Chamyal wrote: > > Hello Semyon, > > Your suggestion regarding _NET_WM_ICON requires some > investigation and can be implemented as separate bug. > > Ok. Please create this bug. > > --Semyon > > > Could you please review the webrev. > > http://cr.openjdk.java.net/~rchamyal/8147648/webrev.03/ > > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 21 July 2016 20:42 > *To:* Rajeev Chamyal; Semyon Sadetsky; > swing-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: [9] Review Request JDK-8147648 > [hidpi] multiresolution image: wrong resolution variant is > used as icon in the Unity panel > > On 7/21/2016 5:25 PM, Rajeev Chamyal wrote: > > > > Hello Semyon, > > The resolution variant image returned is based on the > implementation of > BaseMultiResolutionImage::getResolutionVariant API. > > Current implementation of > BaseMultiResolutionImage::getResolutionVariant returns a > resolution variant image which has width and height > greater than or equal to the passed width and height. > > There is a known issue on it: > JDK-8148619 Select the closest resolution variant in > BaseMultiResolutionImage > https://bugs.openjdk.java.net/browse/JDK-8148619 > > Thanks, > Alexandr. > > > > In the case you have suggested dimensions of RED and BLUE > images are 32 and 80 respectively. > > Width and height passed to getResolutionVariant is 64 > i.e. scaled width and height of base image(RED) > (GDK_SCALE=2) and blue image is getting returned. > > The width and height passed to this API is that of base > image not of the spot. > > Applications can control this behaviour by overriding this > API in derived classes. > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 21 July 2016 15:09 > *To:* Semyon Sadetsky; Rajeev Chamyal; > swing-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: [9] Review Request JDK-8147648 > [hidpi] multiresolution image: wrong resolution variant is > used as icon in the Unity panel > > On 7/21/2016 11:49 AM, Semyon Sadetsky wrote: > > > > > Hello Rajeev, > > The taskbar icon is ok now. > > I change the resolution variants from the test a bit: > > final BaseMultiResolutionImage IMG = > new BaseMultiResolutionImage( > new > BufferedImage[]{generateImage(4, Color.RED), > generateImage(10, Color.BLUE)}); > > And the icon I see in the taskbar and in the button is > blue. It seems to me the first resolution variant > (red) is more appropriate in this case because its > size is closer to the spot. I'm not sure if this is an > issue. > > I have an extra question to you and Alexander. > Most native apps on Linux set an array of icons with > _NET_WM_ICON. Usually they are [16x16, 32x32, 64x64]. > So, desktop environment may select icon of appropriate > size. > In this fix we are preselecting icon of a specific > size in the app and send it to WM. > Why not to send array of the resolution variants > images and let the desktop environment to select the > appropriate one, like native apps do? > > This sounds as good idea. MultiResolutionImage has the > special method for this "List > getResolutionVariants()". We do the similar on Mac OS X > where NSImage with several representations is created from > a MultiResolutionImage: > http://cr.openjdk.java.net/~alexsch/8028212/webrev.01/src/macosx/classes/sun/lwawt/macosx/CImage.java.udiff.html > > > It has sense to try the same approach on Linux. > > Thanks, > Alexandr. > > > > > > > --Semyon > > On 19.07.2016 23:26, Rajeev Chamyal wrote: > > Hello Semyon, > > Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8147648/webrev.03/ > > > Regards, > > Rajeev Chamyal > > *From:*Semyon Sadetsky > *Sent:* 14 July 2016 16:58 > *To:* Rajeev Chamyal; swing-dev at openjdk.java.net > ; Sergey > Bylokhov; Alexander Scherbatiy > *Subject:* Re: [9] Review Request > JDK-8147648 [hidpi] multiresolution image: wrong > resolution variant is used as icon in the Unity panel > > Hi Rajeev, > > I have added 1px border to the icon in your test: > > private static BufferedImage generateImage(int > scale, Color c) { > int x = SZ * scale; > BufferedImage img = new BufferedImage(x, > x, BufferedImage.TYPE_INT_RGB); > Graphics g = img.getGraphics(); > if (g != null) { > g.setColor(c); > g.fillRect(0, 0, x, x); > g.setColor(Color.YELLOW); > g.drawRect(0, 0, x-1, x-1); > } > return img; > } > > It seems the icon in the taskbar is not correct > for UI scale > 1. > > By the way, graphics object should be disposed > using g.dispose() when it is not needed anymore. > > --Semyon > > > > > > On 14.07.2016 10:08, Rajeev Chamyal wrote: > > Hello All, > > Gentle reminder. Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8147648/webrev.02/ > > > Update: simplified the test. > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 22 June 2016 15:46 > *To:* Rajeev Chamyal; Sergey Bylokhov; > swing-dev at openjdk.java.net > > *Subject:* Re: [9] Review Request > JDK-8147648 [hidpi] multiresolution image: > wrong resolution variant is used as icon in > the Unity panel > > The fix looks good to me. > > Thanks, > Alexandr. > > On 6/22/2016 10:49 AM, Rajeev Chamyal wrote: > > Hello Alexandr, > > Thanks for the review. I have updated > webrev as per comments. > > http://cr.openjdk.java.net/~rchamyal/8147648/webrev.01/ > > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 21 June 2016 17:37 > *To:* Rajeev Chamyal; Sergey Bylokhov; > swing-dev at openjdk.java.net > > *Subject:* Re: [9] Review > Request JDK-8147648 [hidpi] > multiresolution image: wrong resolution > variant is used as icon in the Unity panel > > On 6/21/2016 12:16 PM, Rajeev Chamyal wrote: > > Hello All, > > Please review the following webrev. > > Webrev: > http://cr.openjdk.java.net/~rchamyal/8147648/webrev.00/ > > > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8147648 > > > Issue: Wrong resolution variant is > used as icon in the Unity panel. > > Cause: The screen transforms are not > applied to find the correct resolution > variant image in current implementation. > > Fix: Applied the screen transforms to > graphics object. > > > 222 int scaleX = (int)tx.getScaleX(); > 223 int scaleY = (int)tx.getScaleY(); > 224 DataBufferInt buffer = new > DataBufferInt(scaleX * width * scaleY * > height); > > The fix is in the shared code and the > scale factor can have floating point value > on Windows. (for example 1.5). > It is better to round the final width > and height after scaling them. > > Thanks, > Alexandr. > > Regards, > > Rajeev Chamyal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Fri Jul 22 17:54:08 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Fri, 22 Jul 2016 20:54:08 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: <5790F289.1000309@oracle.com> References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> <435db7a0-9ae3-0b81-ca94-5c9258d789af@oracle.com> <8984a4ae-38e6-2cbb-878a-b29f2394828c@oracle.com> <8327e9bc-19f6-8ea0-a5a1-05292921638f@oracle.com> <4faf3887-5857-e827-ecfb-25285b00b959@oracle.com> <5790A187.70004@oracle.com> <88db89fb-4f9a-6bad-3c9e-374ea3b6b488@oracle.com> <5790F289.1000309@oracle.com> Message-ID: <5c5470c8-5310-79d2-43ad-66cb02d55a0d@oracle.com> On 7/21/2016 7:04 PM, Semyon Sadetsky wrote: > > > On 21.07.2016 18:33, Alexandr Scherbatiy wrote: >> On 7/21/2016 1:40 PM, Semyon Sadetsky wrote: >>> On 7/21/2016 1:24 PM, Sergey Bylokhov wrote: >>> >>>> On 21.07.16 13:18, Semyon Sadetsky wrote: >>>>> We do not support non-integer scale on Linux. >>>> >>>> If it is unsupported then why it is validated in the pango fonts >>>> and not in X11GraphicsDevice? I am not sure how scale less than 1 >>>> prevent us from usage of 1.5 for example. >>> getNativeScale() returns int. int cannot be 1.5. >> >> The fix JDK-8149115 "[hidpi] Linux: display-wise scaling factor >> should probably be taken into account" allows to read the UI scale >> factor from some system properties like J2D_UISCALE and >> com.ubuntu.user-interface scale-factor. Could they have floating >> point values? > On the native side they are floating point. But since we do not > support floating point scale on linux they are rounded to integer. >> How do they relate to the "gnome.Xft/DPI" property from the >> PangoFonts? Is it possible that the "gnome.Xft/DPI" value is 192 >> which corresponds to 2x HiDPI display and the J2D_UISCALE is set to 3? > gnome.Xft/DPI is set by desktop env. Usually it corresponds the system > scale from gsettings db. But I cannot guarantee this for any > WM/desktop combinations. > J2D_UISCALE variable is only for java, it may be set to any value and > it is unrelated to the native scale. May be it is better to include the "gnome.Xft/DPI" scale to the X11GraphicsDevice.getNativeScaleFactor(screen) method. Right now only GTK L&F uses it but may be others L&F also should be scaled according to this value. Thanks, Alexandr. > > --Semyon >> >> Thanks, >> Alexandr. >> >>>> >>>>> On 21.07.2016 13:13, Sergey Bylokhov wrote: >>>>>> Is it intended to skip scales less than 1? >>>>>> >>>>>> On 07.07.16 10:01, Alexandr Scherbatiy wrote: >>>>>>> >>>>>>> The fix looks good to me. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> On 7/6/2016 10:03 PM, Semyon Sadetsky wrote: >>>>>>>> On 7/6/2016 6:03 PM, Alexandr Scherbatiy wrote: >>>>>>>> >>>>>>>>> On 7/6/2016 4:13 PM, Semyon Sadetsky wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Please review fix for JDK9: >>>>>>>>>> >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8058742 >>>>>>>>>> >>>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.00/ >>>>>>>>> >>>>>>>>> - PangoFonts class is placed in the shared space and it >>>>>>>>> uses the >>>>>>>>> X11GraphicsDevice from the unix space. Could there be problems >>>>>>>>> with >>>>>>>>> build compilation on platforms differ from Unix? >>>>>>>> no it doesn't cause compilations problems. PangoFonts is used >>>>>>>> on Linux >>>>>>>> platform only. >>>>>>>>> - It is better to rename the scale field to nativeScale just >>>>>>>>> to not >>>>>>>>> mix it with other scale types >>>>>>>> ok. webrev is updated: >>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.01/ >>>>>>>>> - Does the test >>>>>>>>> test/java/awt/font/FontScaling/FontScalingTest.java fails without >>>>>>>>> the proposed fix on Linux? >>>>>>>> Yes it fails before and passes after the fix. >>>>>>>> >>>>>>>> --Semyon >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> After adding hdpi support to JDK the GTK LnF fonts are scaled >>>>>>>>>> twice >>>>>>>>>> using the JDK UI scale factor and the native scale factor >>>>>>>>>> derived >>>>>>>>>> from the screen dpi setting. The fix removes the native >>>>>>>>>> scale if it >>>>>>>>>> is already taken into account in the JDK UI scale. >>>>>>>>>> >>>>>>>>>> --Semyon >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> > From semyon.sadetsky at oracle.com Fri Jul 22 19:27:05 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 22 Jul 2016 22:27:05 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: <5c5470c8-5310-79d2-43ad-66cb02d55a0d@oracle.com> References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> <435db7a0-9ae3-0b81-ca94-5c9258d789af@oracle.com> <8984a4ae-38e6-2cbb-878a-b29f2394828c@oracle.com> <8327e9bc-19f6-8ea0-a5a1-05292921638f@oracle.com> <4faf3887-5857-e827-ecfb-25285b00b959@oracle.com> <5790A187.70004@oracle.com> <88db89fb-4f9a-6bad-3c9e-374ea3b6b488@oracle.com> <5790F289.1000309@oracle.com> <5c5470c8-5310-79d2-43ad-66cb02d55a0d@oracle.com> Message-ID: <988c9b26-929e-cf33-c217-4704b3d42368@oracle.com> On 7/22/2016 8:54 PM, Alexandr Scherbatiy wrote: > On 7/21/2016 7:04 PM, Semyon Sadetsky wrote: >> >> >> On 21.07.2016 18:33, Alexandr Scherbatiy wrote: >>> On 7/21/2016 1:40 PM, Semyon Sadetsky wrote: >>>> On 7/21/2016 1:24 PM, Sergey Bylokhov wrote: >>>> >>>>> On 21.07.16 13:18, Semyon Sadetsky wrote: >>>>>> We do not support non-integer scale on Linux. >>>>> >>>>> If it is unsupported then why it is validated in the pango fonts >>>>> and not in X11GraphicsDevice? I am not sure how scale less than 1 >>>>> prevent us from usage of 1.5 for example. >>>> getNativeScale() returns int. int cannot be 1.5. >>> >>> The fix JDK-8149115 "[hidpi] Linux: display-wise scaling factor >>> should probably be taken into account" allows to read the UI scale >>> factor from some system properties like J2D_UISCALE and >>> com.ubuntu.user-interface scale-factor. Could they have floating >>> point values? >> On the native side they are floating point. But since we do not >> support floating point scale on linux they are rounded to integer. >>> How do they relate to the "gnome.Xft/DPI" property from the >>> PangoFonts? Is it possible that the "gnome.Xft/DPI" value is 192 >>> which corresponds to 2x HiDPI display and the J2D_UISCALE is set to 3? >> gnome.Xft/DPI is set by desktop env. Usually it corresponds the >> system scale from gsettings db. But I cannot guarantee this for any >> WM/desktop combinations. >> J2D_UISCALE variable is only for java, it may be set to any value and >> it is unrelated to the native scale. > > May be it is better to include the "gnome.Xft/DPI" scale to the > X11GraphicsDevice.getNativeScaleFactor(screen) method. Right now only > GTK L&F uses it but may be others L&F also should be scaled according > to this value. From [1]: If you are not using a desktop environment such as GNOME, KDE, Xfce, or other that manipulates the X settings for you, you can set the desired DPI setting manually via the Xft.dpi variable in ~/.Xresources. JDK9 supported DEs manage scale in own settings and Xft/DPI is calculated from those settings. Also Xft/DPI is only for fonts, not for interface elements. That may be not easy to get this property per individual monitor. Also it is an relative DPI value and the real scale need to be restored somehow. [1] https://wiki.archlinux.org/index.php/HiDPI --Semyon > > Thanks, > Alexandr. > >> >> --Semyon >>> >>> Thanks, >>> Alexandr. >>> >>>>> >>>>>> On 21.07.2016 13:13, Sergey Bylokhov wrote: >>>>>>> Is it intended to skip scales less than 1? >>>>>>> >>>>>>> On 07.07.16 10:01, Alexandr Scherbatiy wrote: >>>>>>>> >>>>>>>> The fix looks good to me. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>> On 7/6/2016 10:03 PM, Semyon Sadetsky wrote: >>>>>>>>> On 7/6/2016 6:03 PM, Alexandr Scherbatiy wrote: >>>>>>>>> >>>>>>>>>> On 7/6/2016 4:13 PM, Semyon Sadetsky wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> Please review fix for JDK9: >>>>>>>>>>> >>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8058742 >>>>>>>>>>> >>>>>>>>>>> webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.00/ >>>>>>>>>> >>>>>>>>>> - PangoFonts class is placed in the shared space and it >>>>>>>>>> uses the >>>>>>>>>> X11GraphicsDevice from the unix space. Could there be >>>>>>>>>> problems with >>>>>>>>>> build compilation on platforms differ from Unix? >>>>>>>>> no it doesn't cause compilations problems. PangoFonts is used >>>>>>>>> on Linux >>>>>>>>> platform only. >>>>>>>>>> - It is better to rename the scale field to nativeScale >>>>>>>>>> just to not >>>>>>>>>> mix it with other scale types >>>>>>>>> ok. webrev is updated: >>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.01/ >>>>>>>>>> - Does the test >>>>>>>>>> test/java/awt/font/FontScaling/FontScalingTest.java fails >>>>>>>>>> without >>>>>>>>>> the proposed fix on Linux? >>>>>>>>> Yes it fails before and passes after the fix. >>>>>>>>> >>>>>>>>> --Semyon >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> After adding hdpi support to JDK the GTK LnF fonts are >>>>>>>>>>> scaled twice >>>>>>>>>>> using the JDK UI scale factor and the native scale factor >>>>>>>>>>> derived >>>>>>>>>>> from the screen dpi setting. The fix removes the native >>>>>>>>>>> scale if it >>>>>>>>>>> is already taken into account in the JDK UI scale. >>>>>>>>>>> >>>>>>>>>>> --Semyon >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> > From alexandr.scherbatiy at oracle.com Mon Jul 25 07:43:12 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Mon, 25 Jul 2016 10:43:12 +0300 Subject: [9] Review Request JDK-8147648 [hidpi] multiresolution image: wrong resolution variant is used as icon in the Unity panel In-Reply-To: References: <340c1fa9-7da5-4fcb-9119-0e1e2dcaeb10@default> <9bd7ca3c-2297-0c36-c249-4a9b560275a2@oracle.com> <395e74b7-451e-453e-b552-be2a5bc0e348@default> <30e65d6d-cb35-4c55-b1b2-80752929576a@default> <3d266275-efcd-4d69-bfab-9604467856d1@default> <57877747.3040904@oracle.com> <57908CA9.600@oracle.com> <0cfea8e4-b742-dccf-95cb-46e2ac138bfe@oracle.com> <79509b10-a343-4846-acfd-39c0494a4e93@default> <508d9383-260e-9841-5fd4-96bc8f0c0239@oracle.com> Message-ID: The fix looks good to me. Thanks, Alexandr. On 7/22/2016 12:14 PM, Rajeev Chamyal wrote: > > Hello Semyon, > > Your suggestion regarding _NET_WM_ICON requires some investigation and > can be implemented as separate bug. > > Could you please review the webrev. > > http://cr.openjdk.java.net/~rchamyal/8147648/webrev.03/ > > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 21 July 2016 20:42 > *To:* Rajeev Chamyal; Semyon Sadetsky; swing-dev at openjdk.java.net; > Sergey Bylokhov > *Subject:* Re: [9] Review Request JDK-8147648 [hidpi] > multiresolution image: wrong resolution variant is used as icon in the > Unity panel > > On 7/21/2016 5:25 PM, Rajeev Chamyal wrote: > > Hello Semyon, > > The resolution variant image returned is based on the > implementation of BaseMultiResolutionImage::getResolutionVariant API. > > Current implementation of > BaseMultiResolutionImage::getResolutionVariant returns a > resolution variant image which has width and height greater than > or equal to the passed width and height. > > There is a known issue on it: > JDK-8148619 Select the closest resolution variant in > BaseMultiResolutionImage > https://bugs.openjdk.java.net/browse/JDK-8148619 > > Thanks, > Alexandr. > > In the case you have suggested dimensions of RED and BLUE images > are 32 and 80 respectively. > > Width and height passed to getResolutionVariant is 64 i.e. scaled > width and height of base image(RED) (GDK_SCALE=2) and blue image > is getting returned. > > The width and height passed to this API is that of base image not > of the spot. > > Applications can control this behaviour by overriding this API in > derived classes. > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 21 July 2016 15:09 > *To:* Semyon Sadetsky; Rajeev Chamyal; swing-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: [9] Review Request JDK-8147648 [hidpi] > multiresolution image: wrong resolution variant is used as icon in > the Unity panel > > On 7/21/2016 11:49 AM, Semyon Sadetsky wrote: > > > Hello Rajeev, > > The taskbar icon is ok now. > > I change the resolution variants from the test a bit: > > final BaseMultiResolutionImage IMG = new > BaseMultiResolutionImage( > new BufferedImage[]{generateImage(4, > Color.RED), generateImage(10, Color.BLUE)}); > > And the icon I see in the taskbar and in the button is blue. > It seems to me the first resolution variant (red) is more > appropriate in this case because its size is closer to the > spot. I'm not sure if this is an issue. > > I have an extra question to you and Alexander. > Most native apps on Linux set an array of icons with > _NET_WM_ICON. Usually they are [16x16, 32x32, 64x64]. > So, desktop environment may select icon of appropriate size. > In this fix we are preselecting icon of a specific size in the > app and send it to WM. > Why not to send array of the resolution variants images and > let the desktop environment to select the appropriate one, > like native apps do? > > This sounds as good idea. MultiResolutionImage has the special > method for this "List getResolutionVariants()". We do the > similar on Mac OS X where NSImage with several representations is > created from a MultiResolutionImage: > http://cr.openjdk.java.net/~alexsch/8028212/webrev.01/src/macosx/classes/sun/lwawt/macosx/CImage.java.udiff.html > > > It has sense to try the same approach on Linux. > > Thanks, > Alexandr. > > > > > --Semyon > > On 19.07.2016 23:26, Rajeev Chamyal wrote: > > Hello Semyon, > > Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8147648/webrev.03/ > > > Regards, > > Rajeev Chamyal > > *From:*Semyon Sadetsky > *Sent:* 14 July 2016 16:58 > *To:* Rajeev Chamyal; swing-dev at openjdk.java.net > ; Sergey Bylokhov; > Alexander Scherbatiy > *Subject:* Re: [9] Review Request JDK-8147648 > [hidpi] multiresolution image: wrong resolution variant is > used as icon in the Unity panel > > Hi Rajeev, > > I have added 1px border to the icon in your test: > > private static BufferedImage generateImage(int scale, > Color c) { > int x = SZ * scale; > BufferedImage img = new BufferedImage(x, x, > BufferedImage.TYPE_INT_RGB); > Graphics g = img.getGraphics(); > if (g != null) { > g.setColor(c); > g.fillRect(0, 0, x, x); > g.setColor(Color.YELLOW); > g.drawRect(0, 0, x-1, x-1); > } > return img; > } > > It seems the icon in the taskbar is not correct for UI > scale > 1. > > By the way, graphics object should be disposed using > g.dispose() when it is not needed anymore. > > --Semyon > > > > On 14.07.2016 10:08, Rajeev Chamyal wrote: > > Hello All, > > Gentle reminder. Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8147648/webrev.02/ > > > Update: simplified the test. > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 22 June 2016 15:46 > *To:* Rajeev Chamyal; Sergey Bylokhov; > swing-dev at openjdk.java.net > > *Subject:* Re: [9] Review Request > JDK-8147648 [hidpi] multiresolution image: wrong > resolution variant is used as icon in the Unity panel > > The fix looks good to me. > > Thanks, > Alexandr. > > On 6/22/2016 10:49 AM, Rajeev Chamyal wrote: > > Hello Alexandr, > > Thanks for the review. I have updated webrev as > per comments. > > http://cr.openjdk.java.net/~rchamyal/8147648/webrev.01/ > > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 21 June 2016 17:37 > *To:* Rajeev Chamyal; Sergey Bylokhov; > swing-dev at openjdk.java.net > > *Subject:* Re: [9] Review Request > JDK-8147648 [hidpi] multiresolution image: wrong > resolution variant is used as icon in the Unity panel > > On 6/21/2016 12:16 PM, Rajeev Chamyal wrote: > > Hello All, > > Please review the following webrev. > > Webrev: > http://cr.openjdk.java.net/~rchamyal/8147648/webrev.00/ > > > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8147648 > > Issue: Wrong resolution variant is used as > icon in the Unity panel. > > Cause: The screen transforms are not applied > to find the correct resolution variant image > in current implementation. > > Fix: Applied the screen transforms to graphics > object. > > > 222 int scaleX = (int)tx.getScaleX(); > 223 int scaleY = (int)tx.getScaleY(); > 224 DataBufferInt buffer = new > DataBufferInt(scaleX * width * scaleY * height); > > The fix is in the shared code and the scale > factor can have floating point value on Windows. > (for example 1.5). > It is better to round the final width and height > after scaling them. > > Thanks, > Alexandr. > > Regards, > > Rajeev Chamyal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Mon Jul 25 08:02:29 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Mon, 25 Jul 2016 11:02:29 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: <988c9b26-929e-cf33-c217-4704b3d42368@oracle.com> References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> <435db7a0-9ae3-0b81-ca94-5c9258d789af@oracle.com> <8984a4ae-38e6-2cbb-878a-b29f2394828c@oracle.com> <8327e9bc-19f6-8ea0-a5a1-05292921638f@oracle.com> <4faf3887-5857-e827-ecfb-25285b00b959@oracle.com> <5790A187.70004@oracle.com> <88db89fb-4f9a-6bad-3c9e-374ea3b6b488@oracle.com> <5790F289.1000309@oracle.com> <5c5470c8-5310-79d2-43ad-66cb02d55a0d@oracle.com> <988c9b26-929e-cf33-c217-4704b3d42368@oracle.com> Message-ID: On 7/22/2016 10:27 PM, Semyon Sadetsky wrote: > > > On 7/22/2016 8:54 PM, Alexandr Scherbatiy wrote: >> On 7/21/2016 7:04 PM, Semyon Sadetsky wrote: >>> >>> >>> On 21.07.2016 18:33, Alexandr Scherbatiy wrote: >>>> On 7/21/2016 1:40 PM, Semyon Sadetsky wrote: >>>>> On 7/21/2016 1:24 PM, Sergey Bylokhov wrote: >>>>> >>>>>> On 21.07.16 13:18, Semyon Sadetsky wrote: >>>>>>> We do not support non-integer scale on Linux. >>>>>> >>>>>> If it is unsupported then why it is validated in the pango fonts >>>>>> and not in X11GraphicsDevice? I am not sure how scale less than 1 >>>>>> prevent us from usage of 1.5 for example. >>>>> getNativeScale() returns int. int cannot be 1.5. >>>> >>>> The fix JDK-8149115 "[hidpi] Linux: display-wise scaling factor >>>> should probably be taken into account" allows to read the UI scale >>>> factor from some system properties like J2D_UISCALE and >>>> com.ubuntu.user-interface scale-factor. Could they have floating >>>> point values? >>> On the native side they are floating point. But since we do not >>> support floating point scale on linux they are rounded to integer. >>>> How do they relate to the "gnome.Xft/DPI" property from the >>>> PangoFonts? Is it possible that the "gnome.Xft/DPI" value is 192 >>>> which corresponds to 2x HiDPI display and the J2D_UISCALE is set to 3? >>> gnome.Xft/DPI is set by desktop env. Usually it corresponds the >>> system scale from gsettings db. But I cannot guarantee this for any >>> WM/desktop combinations. >>> J2D_UISCALE variable is only for java, it may be set to any value >>> and it is unrelated to the native scale. >> >> May be it is better to include the "gnome.Xft/DPI" scale to the >> X11GraphicsDevice.getNativeScaleFactor(screen) method. Right now only >> GTK L&F uses it but may be others L&F also should be scaled according >> to this value. > From [1]: If you are not using a desktop environment such as GNOME, > KDE, Xfce, or other that manipulates the X settings for you, you can > set the desired DPI setting manually via the Xft.dpi variable in > ~/.Xresources. > JDK9 supported DEs manage scale in own settings and Xft/DPI is > calculated from those settings. Also Xft/DPI is only for fonts, not > for interface elements. > That may be not easy to get this property per individual monitor. Also > it is an relative DPI value and the real scale need to be restored > somehow. > > [1] https://wiki.archlinux.org/index.php/HiDPI There is one thing which is not clear for me. Where is the place that GTK font size is multiplied on the X11GraphicsDevice.getNativeScaleFactor(screen) the second time? The one place is the Graphics which gets additional scale factor from a GraphicsConfiguration. What is another place where the font is scaled using the native scale factor? Thanks, Alexandr. > > --Semyon >> >> Thanks, >> Alexandr. >> >>> >>> --Semyon >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>>> >>>>>>> On 21.07.2016 13:13, Sergey Bylokhov wrote: >>>>>>>> Is it intended to skip scales less than 1? >>>>>>>> >>>>>>>> On 07.07.16 10:01, Alexandr Scherbatiy wrote: >>>>>>>>> >>>>>>>>> The fix looks good to me. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> On 7/6/2016 10:03 PM, Semyon Sadetsky wrote: >>>>>>>>>> On 7/6/2016 6:03 PM, Alexandr Scherbatiy wrote: >>>>>>>>>> >>>>>>>>>>> On 7/6/2016 4:13 PM, Semyon Sadetsky wrote: >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> Please review fix for JDK9: >>>>>>>>>>>> >>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8058742 >>>>>>>>>>>> >>>>>>>>>>>> webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> - PangoFonts class is placed in the shared space and it >>>>>>>>>>> uses the >>>>>>>>>>> X11GraphicsDevice from the unix space. Could there be >>>>>>>>>>> problems with >>>>>>>>>>> build compilation on platforms differ from Unix? >>>>>>>>>> no it doesn't cause compilations problems. PangoFonts is used >>>>>>>>>> on Linux >>>>>>>>>> platform only. >>>>>>>>>>> - It is better to rename the scale field to nativeScale >>>>>>>>>>> just to not >>>>>>>>>>> mix it with other scale types >>>>>>>>>> ok. webrev is updated: >>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.01/ >>>>>>>>>>> - Does the test >>>>>>>>>>> test/java/awt/font/FontScaling/FontScalingTest.java fails >>>>>>>>>>> without >>>>>>>>>>> the proposed fix on Linux? >>>>>>>>>> Yes it fails before and passes after the fix. >>>>>>>>>> >>>>>>>>>> --Semyon >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> After adding hdpi support to JDK the GTK LnF fonts are >>>>>>>>>>>> scaled twice >>>>>>>>>>>> using the JDK UI scale factor and the native scale factor >>>>>>>>>>>> derived >>>>>>>>>>>> from the screen dpi setting. The fix removes the native >>>>>>>>>>>> scale if it >>>>>>>>>>>> is already taken into account in the JDK UI scale. >>>>>>>>>>>> >>>>>>>>>>>> --Semyon >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > From semyon.sadetsky at oracle.com Mon Jul 25 09:18:36 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 25 Jul 2016 12:18:36 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> <435db7a0-9ae3-0b81-ca94-5c9258d789af@oracle.com> <8984a4ae-38e6-2cbb-878a-b29f2394828c@oracle.com> <8327e9bc-19f6-8ea0-a5a1-05292921638f@oracle.com> <4faf3887-5857-e827-ecfb-25285b00b959@oracle.com> <5790A187.70004@oracle.com> <88db89fb-4f9a-6bad-3c9e-374ea3b6b488@oracle.com> <5790F289.1000309@oracle.com> <5c5470c8-5310-79d2-43ad-66cb02d55a0d@oracle.com> <988c9b26-929e-cf33-c217-4704b3d42368@oracle.com> Message-ID: On 7/25/2016 11:02 AM, Alexandr Scherbatiy wrote: > On 7/22/2016 10:27 PM, Semyon Sadetsky wrote: >> >> >> On 7/22/2016 8:54 PM, Alexandr Scherbatiy wrote: >>> On 7/21/2016 7:04 PM, Semyon Sadetsky wrote: >>>> >>>> >>>> On 21.07.2016 18:33, Alexandr Scherbatiy wrote: >>>>> On 7/21/2016 1:40 PM, Semyon Sadetsky wrote: >>>>>> On 7/21/2016 1:24 PM, Sergey Bylokhov wrote: >>>>>> >>>>>>> On 21.07.16 13:18, Semyon Sadetsky wrote: >>>>>>>> We do not support non-integer scale on Linux. >>>>>>> >>>>>>> If it is unsupported then why it is validated in the pango fonts >>>>>>> and not in X11GraphicsDevice? I am not sure how scale less than >>>>>>> 1 prevent us from usage of 1.5 for example. >>>>>> getNativeScale() returns int. int cannot be 1.5. >>>>> >>>>> The fix JDK-8149115 "[hidpi] Linux: display-wise scaling factor >>>>> should probably be taken into account" allows to read the UI scale >>>>> factor from some system properties like J2D_UISCALE and >>>>> com.ubuntu.user-interface scale-factor. Could they have floating >>>>> point values? >>>> On the native side they are floating point. But since we do not >>>> support floating point scale on linux they are rounded to integer. >>>>> How do they relate to the "gnome.Xft/DPI" property from the >>>>> PangoFonts? Is it possible that the "gnome.Xft/DPI" value is 192 >>>>> which corresponds to 2x HiDPI display and the J2D_UISCALE is set >>>>> to 3? >>>> gnome.Xft/DPI is set by desktop env. Usually it corresponds the >>>> system scale from gsettings db. But I cannot guarantee this for any >>>> WM/desktop combinations. >>>> J2D_UISCALE variable is only for java, it may be set to any value >>>> and it is unrelated to the native scale. >>> >>> May be it is better to include the "gnome.Xft/DPI" scale to the >>> X11GraphicsDevice.getNativeScaleFactor(screen) method. Right now >>> only GTK L&F uses it but may be others L&F also should be scaled >>> according to this value. >> From [1]: If you are not using a desktop environment such as GNOME, >> KDE, Xfce, or other that manipulates the X settings for you, you can >> set the desired DPI setting manually via the Xft.dpi variable in >> ~/.Xresources. >> JDK9 supported DEs manage scale in own settings and Xft/DPI is >> calculated from those settings. Also Xft/DPI is only for fonts, not >> for interface elements. >> That may be not easy to get this property per individual monitor. >> Also it is an relative DPI value and the real scale need to be >> restored somehow. >> >> [1] https://wiki.archlinux.org/index.php/HiDPI > There is one thing which is not clear for me. Where is the place > that GTK font size is multiplied on the > X11GraphicsDevice.getNativeScaleFactor(screen) the second time? One time is in the PangoFont ( dsize = ((double)(dpi * size)/ 72.0);), the second time in the graphics transformation if it uses the native scale. --Semyon > The one place is the Graphics which gets additional scale factor > from a GraphicsConfiguration. What is another place where the font is > scaled using the native scale factor? > > Thanks, > Alexandr. >> >> --Semyon >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> --Semyon >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>>>> >>>>>>>> On 21.07.2016 13:13, Sergey Bylokhov wrote: >>>>>>>>> Is it intended to skip scales less than 1? >>>>>>>>> >>>>>>>>> On 07.07.16 10:01, Alexandr Scherbatiy wrote: >>>>>>>>>> >>>>>>>>>> The fix looks good to me. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>> On 7/6/2016 10:03 PM, Semyon Sadetsky wrote: >>>>>>>>>>> On 7/6/2016 6:03 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>> >>>>>>>>>>>> On 7/6/2016 4:13 PM, Semyon Sadetsky wrote: >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> >>>>>>>>>>>>> Please review fix for JDK9: >>>>>>>>>>>>> >>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8058742 >>>>>>>>>>>>> >>>>>>>>>>>>> webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> - PangoFonts class is placed in the shared space and it >>>>>>>>>>>> uses the >>>>>>>>>>>> X11GraphicsDevice from the unix space. Could there be >>>>>>>>>>>> problems with >>>>>>>>>>>> build compilation on platforms differ from Unix? >>>>>>>>>>> no it doesn't cause compilations problems. PangoFonts is >>>>>>>>>>> used on Linux >>>>>>>>>>> platform only. >>>>>>>>>>>> - It is better to rename the scale field to nativeScale >>>>>>>>>>>> just to not >>>>>>>>>>>> mix it with other scale types >>>>>>>>>>> ok. webrev is updated: >>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.01/ >>>>>>>>>>>> - Does the test >>>>>>>>>>>> test/java/awt/font/FontScaling/FontScalingTest.java fails >>>>>>>>>>>> without >>>>>>>>>>>> the proposed fix on Linux? >>>>>>>>>>> Yes it fails before and passes after the fix. >>>>>>>>>>> >>>>>>>>>>> --Semyon >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> After adding hdpi support to JDK the GTK LnF fonts are >>>>>>>>>>>>> scaled twice >>>>>>>>>>>>> using the JDK UI scale factor and the native scale factor >>>>>>>>>>>>> derived >>>>>>>>>>>>> from the screen dpi setting. The fix removes the native >>>>>>>>>>>>> scale if it >>>>>>>>>>>>> is already taken into account in the JDK UI scale. >>>>>>>>>>>>> >>>>>>>>>>>>> --Semyon >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From alexandr.scherbatiy at oracle.com Mon Jul 25 10:46:20 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Mon, 25 Jul 2016 13:46:20 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> <435db7a0-9ae3-0b81-ca94-5c9258d789af@oracle.com> <8984a4ae-38e6-2cbb-878a-b29f2394828c@oracle.com> <8327e9bc-19f6-8ea0-a5a1-05292921638f@oracle.com> <4faf3887-5857-e827-ecfb-25285b00b959@oracle.com> <5790A187.70004@oracle.com> <88db89fb-4f9a-6bad-3c9e-374ea3b6b488@oracle.com> <5790F289.1000309@oracle.com> <5c5470c8-5310-79d2-43ad-66cb02d55a0d@oracle.com> <988c9b26-929e-cf33-c217-4704b3d42368@oracle.com> Message-ID: <4a29ef37-c0de-11c1-55b5-5966e6fd4cea@oracle.com> On 7/25/2016 12:18 PM, Semyon Sadetsky wrote: > > > On 7/25/2016 11:02 AM, Alexandr Scherbatiy wrote: >> On 7/22/2016 10:27 PM, Semyon Sadetsky wrote: >>> >>> >>> On 7/22/2016 8:54 PM, Alexandr Scherbatiy wrote: >>>> On 7/21/2016 7:04 PM, Semyon Sadetsky wrote: >>>>> >>>>> >>>>> On 21.07.2016 18:33, Alexandr Scherbatiy wrote: >>>>>> On 7/21/2016 1:40 PM, Semyon Sadetsky wrote: >>>>>>> On 7/21/2016 1:24 PM, Sergey Bylokhov wrote: >>>>>>> >>>>>>>> On 21.07.16 13:18, Semyon Sadetsky wrote: >>>>>>>>> We do not support non-integer scale on Linux. >>>>>>>> >>>>>>>> If it is unsupported then why it is validated in the pango >>>>>>>> fonts and not in X11GraphicsDevice? I am not sure how scale >>>>>>>> less than 1 prevent us from usage of 1.5 for example. >>>>>>> getNativeScale() returns int. int cannot be 1.5. >>>>>> >>>>>> The fix JDK-8149115 "[hidpi] Linux: display-wise scaling factor >>>>>> should probably be taken into account" allows to read the UI >>>>>> scale factor from some system properties like J2D_UISCALE and >>>>>> com.ubuntu.user-interface scale-factor. Could they have floating >>>>>> point values? >>>>> On the native side they are floating point. But since we do not >>>>> support floating point scale on linux they are rounded to integer. >>>>>> How do they relate to the "gnome.Xft/DPI" property from the >>>>>> PangoFonts? Is it possible that the "gnome.Xft/DPI" value is 192 >>>>>> which corresponds to 2x HiDPI display and the J2D_UISCALE is set >>>>>> to 3? >>>>> gnome.Xft/DPI is set by desktop env. Usually it corresponds the >>>>> system scale from gsettings db. But I cannot guarantee this for >>>>> any WM/desktop combinations. >>>>> J2D_UISCALE variable is only for java, it may be set to any value >>>>> and it is unrelated to the native scale. >>>> >>>> May be it is better to include the "gnome.Xft/DPI" scale to the >>>> X11GraphicsDevice.getNativeScaleFactor(screen) method. Right now >>>> only GTK L&F uses it but may be others L&F also should be scaled >>>> according to this value. >>> From [1]: If you are not using a desktop environment such as GNOME, >>> KDE, Xfce, or other that manipulates the X settings for you, you can >>> set the desired DPI setting manually via the Xft.dpi variable in >>> ~/.Xresources. >>> JDK9 supported DEs manage scale in own settings and Xft/DPI is >>> calculated from those settings. Also Xft/DPI is only for fonts, not >>> for interface elements. >>> That may be not easy to get this property per individual monitor. >>> Also it is an relative DPI value and the real scale need to be >>> restored somehow. >>> >>> [1] https://wiki.archlinux.org/index.php/HiDPI >> There is one thing which is not clear for me. Where is the place >> that GTK font size is multiplied on the >> X11GraphicsDevice.getNativeScaleFactor(screen) the second time? > One time is in the PangoFont ( dsize = ((double)(dpi * size)/ 72.0);), > the second time in the graphics transformation if it uses the native > scale. Let's run a java application with the debug scale 5 (-Dsun.java2d.uiScale=5) and GDK_SCALE system environment set to 2. The X11GraphicsDevice.getNativeScale() should be 2 (GDK_SCALE) and the PangoFonts.fontScale should be 5 (the debug scale from the GraphicsConfiguration.getDefaultScreenDevice().getDefaultConfiguration()). There are 2 formulas for the font size in the PangoFonts dsize = ((double)(dpi * size) / 72.0 / nativeScale); // "gnome.Xft/DPI" is set dsize = size * fontScale; // "gnome.Xft/DPI" is not set In the first case the size is divided by the nativeScale and then is multiplied by the fontScale (scale from the graphics configuration) in the Graphics. The final result is size * (dpi / 72) * fontScale / nativeScale = size * (dpi / 72) * 5 / 2. Probably it should be multiplied only on the fontScale in the graphics. In the second case dsize = size * fontScale which is multiplied by the fontScale in the graphics one more time. May be the fontScale should be omitted for this case in the PangoFonts. Thanks, Alexandr. > > --Semyon >> The one place is the Graphics which gets additional scale factor >> from a GraphicsConfiguration. What is another place where the font is >> scaled using the native scale factor? >> >> Thanks, >> Alexandr. >>> >>> --Semyon >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>> >>>>> --Semyon >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>>>> >>>>>>>>> On 21.07.2016 13:13, Sergey Bylokhov wrote: >>>>>>>>>> Is it intended to skip scales less than 1? >>>>>>>>>> >>>>>>>>>> On 07.07.16 10:01, Alexandr Scherbatiy wrote: >>>>>>>>>>> >>>>>>>>>>> The fix looks good to me. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>> On 7/6/2016 10:03 PM, Semyon Sadetsky wrote: >>>>>>>>>>>> On 7/6/2016 6:03 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On 7/6/2016 4:13 PM, Semyon Sadetsky wrote: >>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review fix for JDK9: >>>>>>>>>>>>>> >>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8058742 >>>>>>>>>>>>>> >>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> - PangoFonts class is placed in the shared space and it >>>>>>>>>>>>> uses the >>>>>>>>>>>>> X11GraphicsDevice from the unix space. Could there be >>>>>>>>>>>>> problems with >>>>>>>>>>>>> build compilation on platforms differ from Unix? >>>>>>>>>>>> no it doesn't cause compilations problems. PangoFonts is >>>>>>>>>>>> used on Linux >>>>>>>>>>>> platform only. >>>>>>>>>>>>> - It is better to rename the scale field to nativeScale >>>>>>>>>>>>> just to not >>>>>>>>>>>>> mix it with other scale types >>>>>>>>>>>> ok. webrev is updated: >>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.01/ >>>>>>>>>>>>> - Does the test >>>>>>>>>>>>> test/java/awt/font/FontScaling/FontScalingTest.java fails >>>>>>>>>>>>> without >>>>>>>>>>>>> the proposed fix on Linux? >>>>>>>>>>>> Yes it fails before and passes after the fix. >>>>>>>>>>>> >>>>>>>>>>>> --Semyon >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> After adding hdpi support to JDK the GTK LnF fonts are >>>>>>>>>>>>>> scaled twice >>>>>>>>>>>>>> using the JDK UI scale factor and the native scale factor >>>>>>>>>>>>>> derived >>>>>>>>>>>>>> from the screen dpi setting. The fix removes the native >>>>>>>>>>>>>> scale if it >>>>>>>>>>>>>> is already taken into account in the JDK UI scale. >>>>>>>>>>>>>> >>>>>>>>>>>>>> --Semyon >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From semyon.sadetsky at oracle.com Mon Jul 25 11:25:10 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 25 Jul 2016 14:25:10 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: <4a29ef37-c0de-11c1-55b5-5966e6fd4cea@oracle.com> References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> <435db7a0-9ae3-0b81-ca94-5c9258d789af@oracle.com> <8984a4ae-38e6-2cbb-878a-b29f2394828c@oracle.com> <8327e9bc-19f6-8ea0-a5a1-05292921638f@oracle.com> <4faf3887-5857-e827-ecfb-25285b00b959@oracle.com> <5790A187.70004@oracle.com> <88db89fb-4f9a-6bad-3c9e-374ea3b6b488@oracle.com> <5790F289.1000309@oracle.com> <5c5470c8-5310-79d2-43ad-66cb02d55a0d@oracle.com> <988c9b26-929e-cf33-c217-4704b3d42368@oracle.com> <4a29ef37-c0de-11c1-55b5-5966e6fd4cea@oracle.com> Message-ID: <921f0032-d802-2e89-e4e4-9811e5d446ce@oracle.com> On 7/25/2016 1:46 PM, Alexandr Scherbatiy wrote: > On 7/25/2016 12:18 PM, Semyon Sadetsky wrote: >> >> >> On 7/25/2016 11:02 AM, Alexandr Scherbatiy wrote: >>> On 7/22/2016 10:27 PM, Semyon Sadetsky wrote: >>>> >>>> >>>> On 7/22/2016 8:54 PM, Alexandr Scherbatiy wrote: >>>>> On 7/21/2016 7:04 PM, Semyon Sadetsky wrote: >>>>>> >>>>>> >>>>>> On 21.07.2016 18:33, Alexandr Scherbatiy wrote: >>>>>>> On 7/21/2016 1:40 PM, Semyon Sadetsky wrote: >>>>>>>> On 7/21/2016 1:24 PM, Sergey Bylokhov wrote: >>>>>>>> >>>>>>>>> On 21.07.16 13:18, Semyon Sadetsky wrote: >>>>>>>>>> We do not support non-integer scale on Linux. >>>>>>>>> >>>>>>>>> If it is unsupported then why it is validated in the pango >>>>>>>>> fonts and not in X11GraphicsDevice? I am not sure how scale >>>>>>>>> less than 1 prevent us from usage of 1.5 for example. >>>>>>>> getNativeScale() returns int. int cannot be 1.5. >>>>>>> >>>>>>> The fix JDK-8149115 "[hidpi] Linux: display-wise scaling >>>>>>> factor should probably be taken into account" allows to read the >>>>>>> UI scale factor from some system properties like J2D_UISCALE and >>>>>>> com.ubuntu.user-interface scale-factor. Could they have floating >>>>>>> point values? >>>>>> On the native side they are floating point. But since we do not >>>>>> support floating point scale on linux they are rounded to integer. >>>>>>> How do they relate to the "gnome.Xft/DPI" property from the >>>>>>> PangoFonts? Is it possible that the "gnome.Xft/DPI" value is >>>>>>> 192 which corresponds to 2x HiDPI display and the J2D_UISCALE is >>>>>>> set to 3? >>>>>> gnome.Xft/DPI is set by desktop env. Usually it corresponds the >>>>>> system scale from gsettings db. But I cannot guarantee this for >>>>>> any WM/desktop combinations. >>>>>> J2D_UISCALE variable is only for java, it may be set to any value >>>>>> and it is unrelated to the native scale. >>>>> >>>>> May be it is better to include the "gnome.Xft/DPI" scale to the >>>>> X11GraphicsDevice.getNativeScaleFactor(screen) method. Right now >>>>> only GTK L&F uses it but may be others L&F also should be scaled >>>>> according to this value. >>>> From [1]: If you are not using a desktop environment such as GNOME, >>>> KDE, Xfce, or other that manipulates the X settings for you, you >>>> can set the desired DPI setting manually via the Xft.dpi variable >>>> in ~/.Xresources. >>>> JDK9 supported DEs manage scale in own settings and Xft/DPI is >>>> calculated from those settings. Also Xft/DPI is only for fonts, not >>>> for interface elements. >>>> That may be not easy to get this property per individual monitor. >>>> Also it is an relative DPI value and the real scale need to be >>>> restored somehow. >>>> >>>> [1] https://wiki.archlinux.org/index.php/HiDPI >>> There is one thing which is not clear for me. Where is the place >>> that GTK font size is multiplied on the >>> X11GraphicsDevice.getNativeScaleFactor(screen) the second time? >> One time is in the PangoFont ( dsize = ((double)(dpi * size)/ >> 72.0);), the second time in the graphics transformation if it uses >> the native scale. > > Let's run a java application with the debug scale 5 > (-Dsun.java2d.uiScale=5) and GDK_SCALE system environment set to 2. > The X11GraphicsDevice.getNativeScale() should be 2 (GDK_SCALE) and the > PangoFonts.fontScale should be 5 (the debug scale from the > GraphicsConfiguration.getDefaultScreenDevice().getDefaultConfiguration()). > > There are 2 formulas for the font size in the PangoFonts > dsize = ((double)(dpi * size) / 72.0 / nativeScale); // > "gnome.Xft/DPI" is set > dsize = size * fontScale; // "gnome.Xft/DPI" is not set > > In the first case the size is divided by the nativeScale and then is > multiplied by the fontScale (scale from the graphics configuration) in > the Graphics. The final result is size * (dpi / 72) * fontScale / > nativeScale = size * (dpi / 72) * 5 / 2. Probably it should be > multiplied only on the fontScale in the graphics. > > In the second case dsize = size * fontScale which is multiplied by > the fontScale in the graphics one more time. May be the fontScale > should be omitted for this case in the PangoFonts. Second case is not considered in this fix. Since Xft/DPI is set for all supported Linux OSes, the second branch is never executed. --Semyon > > Thanks, > Alexandr. > >> >> --Semyon >>> The one place is the Graphics which gets additional scale factor >>> from a GraphicsConfiguration. What is another place where the font >>> is scaled using the native scale factor? >>> >>> Thanks, >>> Alexandr. >>>> >>>> --Semyon >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>>> >>>>>> --Semyon >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>>>> >>>>>>>>>> On 21.07.2016 13:13, Sergey Bylokhov wrote: >>>>>>>>>>> Is it intended to skip scales less than 1? >>>>>>>>>>> >>>>>>>>>>> On 07.07.16 10:01, Alexandr Scherbatiy wrote: >>>>>>>>>>>> >>>>>>>>>>>> The fix looks good to me. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>> On 7/6/2016 10:03 PM, Semyon Sadetsky wrote: >>>>>>>>>>>>> On 7/6/2016 6:03 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> On 7/6/2016 4:13 PM, Semyon Sadetsky wrote: >>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please review fix for JDK9: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8058742 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> - PangoFonts class is placed in the shared space and >>>>>>>>>>>>>> it uses the >>>>>>>>>>>>>> X11GraphicsDevice from the unix space. Could there be >>>>>>>>>>>>>> problems with >>>>>>>>>>>>>> build compilation on platforms differ from Unix? >>>>>>>>>>>>> no it doesn't cause compilations problems. PangoFonts is >>>>>>>>>>>>> used on Linux >>>>>>>>>>>>> platform only. >>>>>>>>>>>>>> - It is better to rename the scale field to nativeScale >>>>>>>>>>>>>> just to not >>>>>>>>>>>>>> mix it with other scale types >>>>>>>>>>>>> ok. webrev is updated: >>>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.01/ >>>>>>>>>>>>>> - Does the test >>>>>>>>>>>>>> test/java/awt/font/FontScaling/FontScalingTest.java fails >>>>>>>>>>>>>> without >>>>>>>>>>>>>> the proposed fix on Linux? >>>>>>>>>>>>> Yes it fails before and passes after the fix. >>>>>>>>>>>>> >>>>>>>>>>>>> --Semyon >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> After adding hdpi support to JDK the GTK LnF fonts are >>>>>>>>>>>>>>> scaled twice >>>>>>>>>>>>>>> using the JDK UI scale factor and the native scale >>>>>>>>>>>>>>> factor derived >>>>>>>>>>>>>>> from the screen dpi setting. The fix removes the native >>>>>>>>>>>>>>> scale if it >>>>>>>>>>>>>>> is already taken into account in the JDK UI scale. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> --Semyon >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From Sergey.Bylokhov at oracle.com Mon Jul 25 15:01:21 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 25 Jul 2016 18:01:21 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: <5791C408.8010500@oracle.com> References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> <435db7a0-9ae3-0b81-ca94-5c9258d789af@oracle.com> <8984a4ae-38e6-2cbb-878a-b29f2394828c@oracle.com> <8327e9bc-19f6-8ea0-a5a1-05292921638f@oracle.com> <4faf3887-5857-e827-ecfb-25285b00b959@oracle.com> <5790A187.70004@oracle.com> <88db89fb-4f9a-6bad-3c9e-374ea3b6b488@oracle.com> <579106C6.20805@oracle.com> <231b22f8-b2be-8637-a526-dfbaa7f18c9d@oracle.com> <5791C408.8010500@oracle.com> Message-ID: <6b49dffd-705d-ce15-a8a1-06f3251cb7bf@oracle.com> On 22.07.16 9:58, Semyon Sadetsky wrote: >> Default transform of the GraphicConfiguration for the screen should >> use only the native scale inside. And it is not necessary to validate >> the data which is returned by getDefaultTransform, because it is >> assumed that the public api return only supported data. > No. There may be debug scale. If debug scale=10 font size will be 10 less. If debug scale was set by the user and everything was scaled accordingly then why this font should not do the same? My understanding is that debug scale is a kind of emulation of some non-standart DPI for some the platform. >>>>>>> On 2 1.07.2016 13:13, Sergey Bylokhov wrote: >>>>>>>> Is it intended to skip scales less than 1? >>>>>>>> >>>>>>>> On 07.07.16 10:01, Alexandr Scherbatiy wrote: >>>>>>>>> >>>>>>>>> The fix looks good to me. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> On 7/6/2016 10:03 PM, Semyon Sadetsky wrote: >>>>>>>>>> On 7/6/2016 6:03 PM, Alexandr Scherbatiy wrote: >>>>>>>>>> >>>>>>>>>>> On 7/6/2016 4:13 PM, Semyon Sadetsky wrote: >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> Please review fix for JDK9: >>>>>>>>>>>> >>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8058742 >>>>>>>>>>>> >>>>>>>>>>>> webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> - PangoFonts class is placed in the shared space and it uses >>>>>>>>>>> the >>>>>>>>>>> X11GraphicsDevice from the unix space. Could there be problems >>>>>>>>>>> with >>>>>>>>>>> build compilation on platforms differ from Unix? >>>>>>>>>> no it doesn't cause compilations problems. PangoFonts is used on >>>>>>>>>> Linux >>>>>>>>>> platform only. >>>>>>>>>>> - It is better to rename the scale field to nativeScale >>>>>>>>>>> just to >>>>>>>>>>> not >>>>>>>>>>> mix it with other scale types >>>>>>>>>> ok. webrev is updated: >>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.01/ >>>>>>>>>>> - Does the test >>>>>>>>>>> test/java/awt/font/FontScaling/FontScalingTest.java fails >>>>>>>>>>> without >>>>>>>>>>> the proposed fix on Linux? >>>>>>>>>> Yes it fails before and passes after the fix. >>>>>>>>>> >>>>>>>>>> --Semyon >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> After adding hdpi support to JDK the GTK LnF fonts are scaled >>>>>>>>>>>> twice >>>>>>>>>>>> using the JDK UI scale factor and the native scale factor >>>>>>>>>>>> derived >>>>>>>>>>>> from the screen dpi setting. The fix removes the native scale >>>>>>>>>>>> if it >>>>>>>>>>>> is already taken into account in the JDK UI scale. >>>>>>>>>>>> >>>>>>>>>>>> --Semyon >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > -- Best regards, Sergey. From semyon.sadetsky at oracle.com Mon Jul 25 15:57:29 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 25 Jul 2016 18:57:29 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: <6b49dffd-705d-ce15-a8a1-06f3251cb7bf@oracle.com> References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> <435db7a0-9ae3-0b81-ca94-5c9258d789af@oracle.com> <8984a4ae-38e6-2cbb-878a-b29f2394828c@oracle.com> <8327e9bc-19f6-8ea0-a5a1-05292921638f@oracle.com> <4faf3887-5857-e827-ecfb-25285b00b959@oracle.com> <5790A187.70004@oracle.com> <88db89fb-4f9a-6bad-3c9e-374ea3b6b488@oracle.com> <579106C6.20805@oracle.com> <231b22f8-b2be-8637-a526-dfbaa7f18c9d@oracle.com> <5791C408.8010500@oracle.com> <6b49dffd-705d-ce15-a8a1-06f3251cb7bf@oracle.com> Message-ID: <0ea6c08f-cd15-b883-5d14-370c2592b6a3@oracle.com> On 7/25/2016 6:01 PM, Sergey Bylokhov wrote: > On 22.07.16 9:58, Semyon Sadetsky wrote: >>> Default transform of the GraphicConfiguration for the screen should >>> use only the native scale inside. And it is not necessary to validate >>> the data which is returned by getDefaultTransform, because it is >>> assumed that the public api return only supported data. >> No. There may be debug scale. If debug scale=10 font size will be 10 >> less. > > If debug scale was set by the user and everything was scaled > accordingly then why this font should not do the same? My > understanding is that debug scale is a kind of emulation of some > non-standart DPI for some the platform. because PangoFont ignores debug scale if Xft/DPI is set. > >>>>>>>> On 2 1.07.2016 13:13, Sergey Bylokhov wrote: >>>>>>>>> Is it intended to skip scales less than 1? >>>>>>>>> >>>>>>>>> On 07.07.16 10:01, Alexandr Scherbatiy wrote: >>>>>>>>>> >>>>>>>>>> The fix looks good to me. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>> On 7/6/2016 10:03 PM, Semyon Sadetsky wrote: >>>>>>>>>>> On 7/6/2016 6:03 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>> >>>>>>>>>>>> On 7/6/2016 4:13 PM, Semyon Sadetsky wrote: >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> >>>>>>>>>>>>> Please review fix for JDK9: >>>>>>>>>>>>> >>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8058742 >>>>>>>>>>>>> >>>>>>>>>>>>> webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> - PangoFonts class is placed in the shared space and it >>>>>>>>>>>> uses >>>>>>>>>>>> the >>>>>>>>>>>> X11GraphicsDevice from the unix space. Could there be problems >>>>>>>>>>>> with >>>>>>>>>>>> build compilation on platforms differ from Unix? >>>>>>>>>>> no it doesn't cause compilations problems. PangoFonts is >>>>>>>>>>> used on >>>>>>>>>>> Linux >>>>>>>>>>> platform only. >>>>>>>>>>>> - It is better to rename the scale field to nativeScale >>>>>>>>>>>> just to >>>>>>>>>>>> not >>>>>>>>>>>> mix it with other scale types >>>>>>>>>>> ok. webrev is updated: >>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.01/ >>>>>>>>>>>> - Does the test >>>>>>>>>>>> test/java/awt/font/FontScaling/FontScalingTest.java fails >>>>>>>>>>>> without >>>>>>>>>>>> the proposed fix on Linux? >>>>>>>>>>> Yes it fails before and passes after the fix. >>>>>>>>>>> >>>>>>>>>>> --Semyon >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> After adding hdpi support to JDK the GTK LnF fonts are scaled >>>>>>>>>>>>> twice >>>>>>>>>>>>> using the JDK UI scale factor and the native scale factor >>>>>>>>>>>>> derived >>>>>>>>>>>>> from the screen dpi setting. The fix removes the native >>>>>>>>>>>>> scale >>>>>>>>>>>>> if it >>>>>>>>>>>>> is already taken into account in the JDK UI scale. >>>>>>>>>>>>> >>>>>>>>>>>>> --Semyon >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From Sergey.Bylokhov at oracle.com Mon Jul 25 17:47:54 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 25 Jul 2016 20:47:54 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: <0ea6c08f-cd15-b883-5d14-370c2592b6a3@oracle.com> References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> <435db7a0-9ae3-0b81-ca94-5c9258d789af@oracle.com> <8984a4ae-38e6-2cbb-878a-b29f2394828c@oracle.com> <8327e9bc-19f6-8ea0-a5a1-05292921638f@oracle.com> <4faf3887-5857-e827-ecfb-25285b00b959@oracle.com> <5790A187.70004@oracle.com> <88db89fb-4f9a-6bad-3c9e-374ea3b6b488@oracle.com> <579106C6.20805@oracle.com> <231b22f8-b2be-8637-a526-dfbaa7f18c9d@oracle.com> <5791C408.8010500@oracle.com> <6b49dffd-705d-ce15-a8a1-06f3251cb7bf@oracle.com> <0ea6c08f-cd15-b883-5d14-370c2592b6a3@oracle.com> Message-ID: <6192bece-6333-0239-4fd6-35248baf78a1@oracle.com> On 25.07.16 18:57, Semyon Sadetsky wrote: >> If debug scale was set by the user and everything was scaled >> accordingly then why this font should not do the same? My >> understanding is that debug scale is a kind of emulation of some >> non-standart DPI for some the platform. > because PangoFont ignores debug scale if Xft/DPI is set. The question is why it ignores debug scale but takes into account the native scale(debug scale is a hook which should allow us to easily change the native scale). In this case all elements/fonts/etc will be scaled using debug scale and this font will not, it looks inconsistent. >> >>>>>>>>> On 2 1.07.2016 13:13, Sergey Bylokhov wrote: >>>>>>>>>> Is it intended to skip scales less than 1? >>>>>>>>>> >>>>>>>>>> On 07.07.16 10:01, Alexandr Scherbatiy wrote: >>>>>>>>>>> >>>>>>>>>>> The fix looks good to me. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>> On 7/6/2016 10:03 PM, Semyon Sadetsky wrote: >>>>>>>>>>>> On 7/6/2016 6:03 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On 7/6/2016 4:13 PM, Semyon Sadetsky wrote: >>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review fix for JDK9: >>>>>>>>>>>>>> >>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8058742 >>>>>>>>>>>>>> >>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> - PangoFonts class is placed in the shared space and it >>>>>>>>>>>>> uses >>>>>>>>>>>>> the >>>>>>>>>>>>> X11GraphicsDevice from the unix space. Could there be problems >>>>>>>>>>>>> with >>>>>>>>>>>>> build compilation on platforms differ from Unix? >>>>>>>>>>>> no it doesn't cause compilations problems. PangoFonts is >>>>>>>>>>>> used on >>>>>>>>>>>> Linux >>>>>>>>>>>> platform only. >>>>>>>>>>>>> - It is better to rename the scale field to nativeScale >>>>>>>>>>>>> just to >>>>>>>>>>>>> not >>>>>>>>>>>>> mix it with other scale types >>>>>>>>>>>> ok. webrev is updated: >>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.01/ >>>>>>>>>>>>> - Does the test >>>>>>>>>>>>> test/java/awt/font/FontScaling/FontScalingTest.java fails >>>>>>>>>>>>> without >>>>>>>>>>>>> the proposed fix on Linux? >>>>>>>>>>>> Yes it fails before and passes after the fix. >>>>>>>>>>>> >>>>>>>>>>>> --Semyon >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> After adding hdpi support to JDK the GTK LnF fonts are scaled >>>>>>>>>>>>>> twice >>>>>>>>>>>>>> using the JDK UI scale factor and the native scale factor >>>>>>>>>>>>>> derived >>>>>>>>>>>>>> from the screen dpi setting. The fix removes the native >>>>>>>>>>>>>> scale >>>>>>>>>>>>>> if it >>>>>>>>>>>>>> is already taken into account in the JDK UI scale. >>>>>>>>>>>>>> >>>>>>>>>>>>>> --Semyon >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > -- Best regards, Sergey. From semyon.sadetsky at oracle.com Mon Jul 25 17:56:43 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 25 Jul 2016 20:56:43 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: <6192bece-6333-0239-4fd6-35248baf78a1@oracle.com> References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> <435db7a0-9ae3-0b81-ca94-5c9258d789af@oracle.com> <8984a4ae-38e6-2cbb-878a-b29f2394828c@oracle.com> <8327e9bc-19f6-8ea0-a5a1-05292921638f@oracle.com> <4faf3887-5857-e827-ecfb-25285b00b959@oracle.com> <5790A187.70004@oracle.com> <88db89fb-4f9a-6bad-3c9e-374ea3b6b488@oracle.com> <579106C6.20805@oracle.com> <231b22f8-b2be-8637-a526-dfbaa7f18c9d@oracle.com> <5791C408.8010500@oracle.com> <6b49dffd-705d-ce15-a8a1-06f3251cb7bf@oracle.com> <0ea6c08f-cd15-b883-5d14-370c2592b6a3@oracle.com> <6192bece-6333-0239-4fd6-35248baf78a1@oracle.com> Message-ID: On 7/25/2016 8:47 PM, Sergey Bylokhov wrote: > On 25.07.16 18:57, Semyon Sadetsky wrote: >>> If debug scale was set by the user and everything was scaled >>> accordingly then why this font should not do the same? My >>> understanding is that debug scale is a kind of emulation of some >>> non-standart DPI for some the platform. >> because PangoFont ignores debug scale if Xft/DPI is set. > > The question is why it ignores debug scale but takes into account the > native scale(debug scale is a hook which should allow us to easily > change the native scale). In this case all elements/fonts/etc will be > scaled using debug scale and this font will not, it looks inconsistent. But the font doesn't need to be scaled if JDK supports scale already. Before the scale support is added to JDK the native scale was supported for GTK LnF only and using fonts size only. I kept this simplified scale support for compatibility with Linux OSes for which native scale is not supported. For Qt based WMs for example. > >>> >>>>>>>>>> On 2 1.07.2016 13:13, Sergey Bylokhov wrote: >>>>>>>>>>> Is it intended to skip scales less than 1? >>>>>>>>>>> >>>>>>>>>>> On 07.07.16 10:01, Alexandr Scherbatiy wrote: >>>>>>>>>>>> >>>>>>>>>>>> The fix looks good to me. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>> On 7/6/2016 10:03 PM, Semyon Sadetsky wrote: >>>>>>>>>>>>> On 7/6/2016 6:03 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> On 7/6/2016 4:13 PM, Semyon Sadetsky wrote: >>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please review fix for JDK9: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8058742 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> - PangoFonts class is placed in the shared space and it >>>>>>>>>>>>>> uses >>>>>>>>>>>>>> the >>>>>>>>>>>>>> X11GraphicsDevice from the unix space. Could there be >>>>>>>>>>>>>> problems >>>>>>>>>>>>>> with >>>>>>>>>>>>>> build compilation on platforms differ from Unix? >>>>>>>>>>>>> no it doesn't cause compilations problems. PangoFonts is >>>>>>>>>>>>> used on >>>>>>>>>>>>> Linux >>>>>>>>>>>>> platform only. >>>>>>>>>>>>>> - It is better to rename the scale field to nativeScale >>>>>>>>>>>>>> just to >>>>>>>>>>>>>> not >>>>>>>>>>>>>> mix it with other scale types >>>>>>>>>>>>> ok. webrev is updated: >>>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.01/ >>>>>>>>>>>>>> - Does the test >>>>>>>>>>>>>> test/java/awt/font/FontScaling/FontScalingTest.java fails >>>>>>>>>>>>>> without >>>>>>>>>>>>>> the proposed fix on Linux? >>>>>>>>>>>>> Yes it fails before and passes after the fix. >>>>>>>>>>>>> >>>>>>>>>>>>> --Semyon >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> After adding hdpi support to JDK the GTK LnF fonts are >>>>>>>>>>>>>>> scaled >>>>>>>>>>>>>>> twice >>>>>>>>>>>>>>> using the JDK UI scale factor and the native scale factor >>>>>>>>>>>>>>> derived >>>>>>>>>>>>>>> from the screen dpi setting. The fix removes the native >>>>>>>>>>>>>>> scale >>>>>>>>>>>>>>> if it >>>>>>>>>>>>>>> is already taken into account in the JDK UI scale. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> --Semyon >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From Sergey.Bylokhov at oracle.com Mon Jul 25 20:32:06 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 25 Jul 2016 23:32:06 +0300 Subject: [9] Review Request: 8161664: Memory leak in com.apple.laf.AquaProgressBarUI: removed progress bar still referenced In-Reply-To: References: Message-ID: <40fcdef0-72ec-3a7e-39d3-5be6f1072338@oracle.com> Hi, Robin. These calls do no guaranties that all weak references will be collected. 56 System.runFinalization(); 57 System.gc(); I suggest to generate OOM explicitly. see for example: javax/swing/UIDefaults/6795356/bug6795356.java Note that on other platforms it will cover Metal L&F but probably others can be tested as well. So it will be good to test all installed L&F in the loop. On 20.07.16 14:26, Alexandr Scherbatiy wrote: > > The fix looks good to me. > > Thanks, > Alexandr. > > On 7/20/2016 11:37 AM, Robin Stevens wrote: >> Hello, >> >> please review this patch for issue JDK-8161664: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8161664 >> Patch: http://cr.openjdk.java.net/~rstevens/8161664/webrev.00/ >> >> >> >> The problem is that in certain scenarios, the Timer in the Animator of >> the AquaProgressBarUI does not get stopped when the progress bar is >> removed from the Swing hierarchy. >> >> Several approaches were discussed in another thread >> (http://mail.openjdk.java.net/pipermail/swing-dev/2016-July/006330.html). >> In the linked webrev, I opted to use the same approach as what is done >> in the BasicProgressBarUI class: only start the timer when the >> progress bar is displayable. >> >> To achieve this, I wrapped all calls to startAnimationTimer with an if >> statement that checks the displayable state of the progress bar. >> >> There is one call to startAnimationTimer that is not adjusted. That >> call is only triggered from the paint method, which in turn is only >> triggered if the progress bar is displayable. As such, the if check >> was not needed there (imo). >> >> The patch includes a test, which fails without the fix and succeeds >> afterwards. >> >> Thanks, >> >> Robin > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Jul 25 21:19:32 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 26 Jul 2016 00:19:32 +0300 Subject: [9] Review request for 8160986 Bad rendering of Swing UI controls with Metal L&F on HiDPI display In-Reply-To: <577EA6CC.7040406@oracle.com> References: <577EA6CC.7040406@oracle.com> Message-ID: On 07.07.16 22:00, Phil Race wrote: > the screenshot here bears that out .. ie left/right do not look to be > any better. > > http://cr.openjdk.java.net/~alexsch/8160986/screenshots/scrollpane-00.png Since it was missed by the author, I am not sure that it will be found by the tester who will run the test. > On 07/07/2016 11:55 AM, Alexandr Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8160986 >> webrev: http://cr.openjdk.java.net/~alexsch/8160986/webrev.00 >> >> The proposed fix changes icon shapes drawn by lines to ovals and >> polygons for JRadioButton, JComboBox and JScrollBar components for the >> Metal L&F. >> >> The screenshots [1] give a hint how UI controls look before and >> after the fix. >> >> [1] http://cr.openjdk.java.net/~alexsch/8160986/screenshots >> >> Thanks, >> Alexandr. >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Jul 26 10:23:49 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 26 Jul 2016 13:23:49 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> <435db7a0-9ae3-0b81-ca94-5c9258d789af@oracle.com> <8984a4ae-38e6-2cbb-878a-b29f2394828c@oracle.com> <8327e9bc-19f6-8ea0-a5a1-05292921638f@oracle.com> <4faf3887-5857-e827-ecfb-25285b00b959@oracle.com> <5790A187.70004@oracle.com> <88db89fb-4f9a-6bad-3c9e-374ea3b6b488@oracle.com> <579106C6.20805@oracle.com> <231b22f8-b2be-8637-a526-dfbaa7f18c9d@oracle.com> <5791C408.8010500@oracle.com> <6b49dffd-705d-ce15-a8a1-06f3251cb7bf@oracle.com> <0ea6c08f-cd15-b883-5d14-370c2592b6a3@oracle.com> <6192bece-6333-0239-4fd6-35248baf78a1@oracle.com> Message-ID: <6f7d5215-c66c-879b-8c8e-6fbe9ca2c511@oracle.com> On 25.07.16 20:56, Semyon Sadetsky wrote: > But the font doesn't need to be scaled if JDK supports scale already. > Before the scale support is added to JDK the native scale was supported > for GTK LnF only and using fonts size only. I kept this simplified scale > support for compatibility with Linux OSes for which native scale is not > supported. For Qt based WMs for example. The question was why the native scale is taken into account, but debug scale not. In this case we will get a different results if the native scale=2 was read from J2D_UISCALE/scale-factor/GDK_SCALE/Xft.dpi or was set for debugging by the user. I think the logic should be: - Take debug scale into account if it was set and skip all others. - Check J2D_UISCALE - Check scale-factor, text-scale-factor, text-scaling-factor. - Check Xft.dpi. - If non of them was set then scale=1 should be used. I guess text-scale-factor, text-scaling-factor are text related scales, but we use it as a generic one, so why Xft.dpi should be different? -- Best regards, Sergey. From semyon.sadetsky at oracle.com Tue Jul 26 10:32:35 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 26 Jul 2016 13:32:35 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: <6f7d5215-c66c-879b-8c8e-6fbe9ca2c511@oracle.com> References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> <435db7a0-9ae3-0b81-ca94-5c9258d789af@oracle.com> <8984a4ae-38e6-2cbb-878a-b29f2394828c@oracle.com> <8327e9bc-19f6-8ea0-a5a1-05292921638f@oracle.com> <4faf3887-5857-e827-ecfb-25285b00b959@oracle.com> <5790A187.70004@oracle.com> <88db89fb-4f9a-6bad-3c9e-374ea3b6b488@oracle.com> <579106C6.20805@oracle.com> <231b22f8-b2be-8637-a526-dfbaa7f18c9d@oracle.com> <5791C408.8010500@oracle.com> <6b49dffd-705d-ce15-a8a1-06f3251cb7bf@oracle.com> <0ea6c08f-cd15-b883-5d14-370c2592b6a3@oracle.com> <6192bece-6333-0239-4fd6-35248baf78a1@oracle.com> <6f7d5215-c66c-879b-8c8e-6fbe9ca2c511@oracle.com> Message-ID: <42cdd713-c4e5-e407-9d43-5ced49f611ad@oracle.com> On 7/26/2016 1:23 PM, Sergey Bylokhov wrote: > On 25.07.16 20:56, Semyon Sadetsky wrote: >> But the font doesn't need to be scaled if JDK supports scale already. >> Before the scale support is added to JDK the native scale was supported >> for GTK LnF only and using fonts size only. I kept this simplified scale >> support for compatibility with Linux OSes for which native scale is not >> supported. For Qt based WMs for example. > > The question was why the native scale is taken into account, but debug > scale not. In this case we will get a different results if the native > scale=2 was read from J2D_UISCALE/scale-factor/GDK_SCALE/Xft.dpi or > was set for debugging by the user. I have answered you already the GTK font size will be unexpectedly small if divided on debug scale. > > I think the logic should be: > - Take debug scale into account if it was set and skip all others. > - Check J2D_UISCALE > - Check scale-factor, text-scale-factor, text-scaling-factor. > - Check Xft.dpi. > - If non of them was set then scale=1 should be used. Did you try to use scale from Xft.dpi? Its value is not a scale usually. Anyway, the above is about a global scale, so it is unrelated to the original issue which sounds like "Text size is twice bigger under GTK L&F". > > I guess text-scale-factor, text-scaling-factor are text related > scales, but we use it as a generic one, so why Xft.dpi should be > different? > From Sergey.Bylokhov at oracle.com Tue Jul 26 10:50:42 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 26 Jul 2016 13:50:42 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: <42cdd713-c4e5-e407-9d43-5ced49f611ad@oracle.com> References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> <435db7a0-9ae3-0b81-ca94-5c9258d789af@oracle.com> <8984a4ae-38e6-2cbb-878a-b29f2394828c@oracle.com> <8327e9bc-19f6-8ea0-a5a1-05292921638f@oracle.com> <4faf3887-5857-e827-ecfb-25285b00b959@oracle.com> <5790A187.70004@oracle.com> <88db89fb-4f9a-6bad-3c9e-374ea3b6b488@oracle.com> <579106C6.20805@oracle.com> <231b22f8-b2be-8637-a526-dfbaa7f18c9d@oracle.com> <5791C408.8010500@oracle.com> <6b49dffd-705d-ce15-a8a1-06f3251cb7bf@oracle.com> <0ea6c08f-cd15-b883-5d14-370c2592b6a3@oracle.com> <6192bece-6333-0239-4fd6-35248baf78a1@oracle.com> <6f7d5215-c66c-879b-8c8e-6fbe9ca2c511@oracle.com> <42cdd713-c4e5-e407-9d43-5ced49f611ad@oracle.com> Message-ID: On 26.07.16 13:32, Semyon Sadetsky wrote: >> The question was why the native scale is taken into account, but debug >> scale not. In this case we will get a different results if the native >> scale=2 was read from J2D_UISCALE/scale-factor/GDK_SCALE/Xft.dpi or >> was set for debugging by the user. > I have answered you already the GTK font size will be unexpectedly small > if divided on debug scale. Debug scale should always be taken into account, if the text will be small in this case then Xft.dpi should be ignored as I described below. We should use only one property at a time. >> I think the logic should be: >> - Take debug scale into account if it was set and skip all others. >> - Check J2D_UISCALE >> - Check scale-factor, text-scale-factor, text-scaling-factor. >> - Check Xft.dpi. >> - If non of them was set then scale=1 should be used. > Did you try to use scale from Xft.dpi? Its value is not a scale usually. What is the difference between text-scale-factor and Xft.dpi? Both of them text related. But one of them is used as a general/default scale of GC and another one affects the text only. > Anyway, the above is about a global scale, so it is unrelated to the > original issue which sounds like "Text size is twice bigger under GTK L&F". It is related since we should decide how and when to use Xft.dpi. -- Best regards, Sergey. From semyon.sadetsky at oracle.com Tue Jul 26 10:55:39 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 26 Jul 2016 13:55:39 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> <435db7a0-9ae3-0b81-ca94-5c9258d789af@oracle.com> <8984a4ae-38e6-2cbb-878a-b29f2394828c@oracle.com> <8327e9bc-19f6-8ea0-a5a1-05292921638f@oracle.com> <4faf3887-5857-e827-ecfb-25285b00b959@oracle.com> <5790A187.70004@oracle.com> <88db89fb-4f9a-6bad-3c9e-374ea3b6b488@oracle.com> <579106C6.20805@oracle.com> <231b22f8-b2be-8637-a526-dfbaa7f18c9d@oracle.com> <5791C408.8010500@oracle.com> <6b49dffd-705d-ce15-a8a1-06f3251cb7bf@oracle.com> <0ea6c08f-cd15-b883-5d14-370c2592b6a3@oracle.com> <6192bece-6333-0239-4fd6-35248baf78a1@oracle.com> <6f7d5215-c66c-879b-8c8e-6fbe9ca2c511@oracle.com> <42cdd713-c4e5-e407-9d43-5ced49f611ad@oracle.com> Message-ID: <06e261d1-4a7d-3016-5f22-531e909097f7@oracle.com> On 7/26/2016 1:50 PM, Sergey Bylokhov wrote: > On 26.07.16 13:32, Semyon Sadetsky wrote: >>> The question was why the native scale is taken into account, but debug >>> scale not. In this case we will get a different results if the native >>> scale=2 was read from J2D_UISCALE/scale-factor/GDK_SCALE/Xft.dpi or >>> was set for debugging by the user. >> I have answered you already the GTK font size will be unexpectedly small >> if divided on debug scale. > > Debug scale should always be taken into account, if the text will be > small in this case then Xft.dpi should be ignored as I described > below. We should use only one property at a time. I did not get, why in case of debug the GTK font size should be decreased by scale times while size of all other fonts and interface elements is being increased by scale times? > >>> I think the logic should be: >>> - Take debug scale into account if it was set and skip all others. >>> - Check J2D_UISCALE >>> - Check scale-factor, text-scale-factor, text-scaling-factor. >>> - Check Xft.dpi. >>> - If non of them was set then scale=1 should be used. >> Did you try to use scale from Xft.dpi? Its value is not a scale usually. > > What is the difference between text-scale-factor and Xft.dpi? Both of > them text related. But one of them is used as a general/default scale > of GC and another one affects the text only. > >> Anyway, the above is about a global scale, so it is unrelated to the >> original issue which sounds like "Text size is twice bigger under GTK >> L&F". > > It is related since we should decide how and when to use Xft.dpi. > From Sergey.Bylokhov at oracle.com Tue Jul 26 18:16:33 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 26 Jul 2016 21:16:33 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: <06e261d1-4a7d-3016-5f22-531e909097f7@oracle.com> References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> <435db7a0-9ae3-0b81-ca94-5c9258d789af@oracle.com> <8984a4ae-38e6-2cbb-878a-b29f2394828c@oracle.com> <8327e9bc-19f6-8ea0-a5a1-05292921638f@oracle.com> <4faf3887-5857-e827-ecfb-25285b00b959@oracle.com> <5790A187.70004@oracle.com> <88db89fb-4f9a-6bad-3c9e-374ea3b6b488@oracle.com> <579106C6.20805@oracle.com> <231b22f8-b2be-8637-a526-dfbaa7f18c9d@oracle.com> <5791C408.8010500@oracle.com> <6b49dffd-705d-ce15-a8a1-06f3251cb7bf@oracle.com> <0ea6c08f-cd15-b883-5d14-370c2592b6a3@oracle.com> <6192bece-6333-0239-4fd6-35248baf78a1@oracle.com> <6f7d5215-c66c-879b-8c8e-6fbe9ca2c511@oracle.com> <42cdd713-c4e5-e407-9d43-5ced49f611ad@oracle.com> <06e261d1-4a7d-3016-5f22-531e909097f7@oracle.com> Message-ID: On 26.07.16 13:55, Semyon Sadetsky wrote: >> Debug scale should always be taken into account, if the text will be >> small in this case then Xft.dpi should be ignored as I described >> below. We should use only one property at a time. > I did not get, why in case of debug the GTK font size should be > decreased by scale times while size of all other fonts and interface > elements is being increased by scale times? Why it should be decreased? it should work as other components. But we should use only one source of system scale information at a time. And debug scale should have the main priority. Xft.dpi should affect jdk in the same way as "text-scale-factor, text-scaling-factor". >> >>>> I think the logic should be: >>>> - Take debug scale into account if it was set and skip all others. >>>> - Check J2D_UISCALE >>>> - Check scale-factor, text-scale-factor, text-scaling-factor. >>>> - Check Xft.dpi. >>>> - If non of them was set then scale=1 should be used. >>> Did you try to use scale from Xft.dpi? Its value is not a scale usually. >> >> What is the difference between text-scale-factor and Xft.dpi? Both of >> them text related. But one of them is used as a general/default scale >> of GC and another one affects the text only. >> >>> Anyway, the above is about a global scale, so it is unrelated to the >>> original issue which sounds like "Text size is twice bigger under GTK >>> L&F". >> >> It is related since we should decide how and when to use Xft.dpi. >> > -- Best regards, Sergey. From semyon.sadetsky at oracle.com Tue Jul 26 18:25:21 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 26 Jul 2016 21:25:21 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> <435db7a0-9ae3-0b81-ca94-5c9258d789af@oracle.com> <8984a4ae-38e6-2cbb-878a-b29f2394828c@oracle.com> <8327e9bc-19f6-8ea0-a5a1-05292921638f@oracle.com> <4faf3887-5857-e827-ecfb-25285b00b959@oracle.com> <5790A187.70004@oracle.com> <88db89fb-4f9a-6bad-3c9e-374ea3b6b488@oracle.com> <579106C6.20805@oracle.com> <231b22f8-b2be-8637-a526-dfbaa7f18c9d@oracle.com> <5791C408.8010500@oracle.com> <6b49dffd-705d-ce15-a8a1-06f3251cb7bf@oracle.com> <0ea6c08f-cd15-b883-5d14-370c2592b6a3@oracle.com> <6192bece-6333-0239-4fd6-35248baf78a1@oracle.com> <6f7d5215-c66c-879b-8c8e-6fbe9ca2c511@oracle.com> <42cdd713-c4e5-e407-9d43-5ced49f611ad@oracle.com> <06e261d1-4a7d-3016-5f22-531e909097f7@oracle.com> Message-ID: <94897cb8-f94e-c573-cde3-8e1b95da73f6@oracle.com> On 7/26/2016 9:16 PM, Sergey Bylokhov wrote: > On 26.07.16 13:55, Semyon Sadetsky wrote: >>> Debug scale should always be taken into account, if the text will be >>> small in this case then Xft.dpi should be ignored as I described >>> below. We should use only one property at a time. >> I did not get, why in case of debug the GTK font size should be >> decreased by scale times while size of all other fonts and interface >> elements is being increased by scale times? > > Why it should be decreased? it should work as other components. But we > should use only one source of system scale information at a time. And > debug scale should have the main priority. Xft.dpi should affect jdk > in the same way as "text-scale-factor, text-scaling-factor". Please look at the code the fix is applied to. Native scale is in the divider. This fix is not related to the whole jdk scale it is only about GTK font size. Taking Xft.dpi as a global jdk scale (not in this fix, of cause) would require an additional investigation. But the supported OSes provide refined scale info from xsettings. > >>> >>>>> I think the logic should be: >>>>> - Take debug scale into account if it was set and skip all others. >>>>> - Check J2D_UISCALE >>>>> - Check scale-factor, text-scale-factor, text-scaling-factor. >>>>> - Check Xft.dpi. >>>>> - If non of them was set then scale=1 should be used. >>>> Did you try to use scale from Xft.dpi? Its value is not a scale >>>> usually. >>> >>> What is the difference between text-scale-factor and Xft.dpi? Both of >>> them text related. But one of them is used as a general/default scale >>> of GC and another one affects the text only. >>> >>>> Anyway, the above is about a global scale, so it is unrelated to the >>>> original issue which sounds like "Text size is twice bigger under GTK >>>> L&F". >>> >>> It is related since we should decide how and when to use Xft.dpi. >>> >> > > From Sergey.Bylokhov at oracle.com Tue Jul 26 18:42:23 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 26 Jul 2016 21:42:23 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: <94897cb8-f94e-c573-cde3-8e1b95da73f6@oracle.com> References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> <8984a4ae-38e6-2cbb-878a-b29f2394828c@oracle.com> <8327e9bc-19f6-8ea0-a5a1-05292921638f@oracle.com> <4faf3887-5857-e827-ecfb-25285b00b959@oracle.com> <5790A187.70004@oracle.com> <88db89fb-4f9a-6bad-3c9e-374ea3b6b488@oracle.com> <579106C6.20805@oracle.com> <231b22f8-b2be-8637-a526-dfbaa7f18c9d@oracle.com> <5791C408.8010500@oracle.com> <6b49dffd-705d-ce15-a8a1-06f3251cb7bf@oracle.com> <0ea6c08f-cd15-b883-5d14-370c2592b6a3@oracle.com> <6192bece-6333-0239-4fd6-35248baf78a1@oracle.com> <6f7d5215-c66c-879b-8c8e-6fbe9ca2c511@oracle.com> <42cdd713-c4e5-e407-9d43-5ced49f611ad@oracle.com> <06e261d1-4a7d-3016-5f22-531e909097f7@oracle.com> <94897cb8-f94e-c573-cde3-8e1b95da73f6@oracle.com> Message-ID: On 26.07.16 21:25, Semyon Sadetsky wrote: >> Why it should be decreased? it should work as other components. But we >> should use only one source of system scale information at a time. And >> debug scale should have the main priority. Xft.dpi should affect jdk >> in the same way as "text-scale-factor, text-scaling-factor". > Please look at the code the fix is applied to. Native scale is in the > divider. Because we take care about scale twice, the first time as a global scale and the second time here. We should do this only in one place. > This fix is not related to the whole jdk scale it is only about GTK font > size. Taking Xft.dpi as a global jdk scale (not in this fix, of cause) would > require an additional investigation. But the supported OSes provide > refined scale info from xsettings. It is actually directly related to the global scale, since support of Xft/ was added in JDK-4830281 as a way to scale java UI. And now the new solution and the old one conflicts. Can we skip the usage of gnome.Xft if default device scale is not identity (which means that some other scale factor is used)? >>>>>> I think the logic should be: >>>>>> - Take debug scale into account if it was set and skip all others. >>>>>> - Check J2D_UISCALE >>>>>> - Check scale-factor, text-scale-factor, text-scaling-factor. >>>>>> - Check Xft.dpi. >>>>>> - If non of them was set then scale=1 should be used. -- Best regards, Sergey. From semyon.sadetsky at oracle.com Tue Jul 26 19:05:37 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 26 Jul 2016 22:05:37 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> <8327e9bc-19f6-8ea0-a5a1-05292921638f@oracle.com> <4faf3887-5857-e827-ecfb-25285b00b959@oracle.com> <5790A187.70004@oracle.com> <88db89fb-4f9a-6bad-3c9e-374ea3b6b488@oracle.com> <579106C6.20805@oracle.com> <231b22f8-b2be-8637-a526-dfbaa7f18c9d@oracle.com> <5791C408.8010500@oracle.com> <6b49dffd-705d-ce15-a8a1-06f3251cb7bf@oracle.com> <0ea6c08f-cd15-b883-5d14-370c2592b6a3@oracle.com> <6192bece-6333-0239-4fd6-35248baf78a1@oracle.com> <6f7d5215-c66c-879b-8c8e-6fbe9ca2c511@oracle.com> <42cdd713-c4e5-e407-9d43-5ced49f611ad@oracle.com> <06e261d1-4a7d-3016-5f22-531e909097f7@oracle.com> <94897cb8-f94e-c573-cde3-8e1b95da73f6@oracle.com> Message-ID: On 26.07.2016 21:42, Sergey Bylokhov wrote: > On 26.07.16 21:25, Semyon Sadetsky wrote: >>> Why it should be decreased? it should work as other components. But we >>> should use only one source of system scale information at a time. And >>> debug scale should have the main priority. Xft.dpi should affect jdk >>> in the same way as "text-scale-factor, text-scaling-factor". >> Please look at the code the fix is applied to. Native scale is in the >> divider. > > Because we take care about scale twice, the first time as a global > scale and the second time here. We should do this only in one place. Our global solution is not full yet. non-integer scale is not supported. Also it does not work for all WMs/DEs. > >> This fix is not related to the whole jdk scale it is only about GTK font >> size. Taking Xft.dpi as a global jdk scale (not in this fix, of >> cause) would >> require an additional investigation. But the supported OSes provide >> refined scale info from xsettings. > > It is actually directly related to the global scale, since support of > Xft/ was added in JDK-4830281 as a way to scale java UI. And now the > new solution and the old one conflicts. Can we skip the usage of > gnome.Xft if default device scale is not identity (which means that > some other scale factor is used)? Do you mean if native scale > 1 then to use scale=1 for GTK font size? That will give the same result I guess. > >>>>>>> I think the logic should be: >>>>>>> - Take debug scale into account if it was set and skip all others. >>>>>>> - Check J2D_UISCALE >>>>>>> - Check scale-factor, text-scale-factor, text-scaling-factor. >>>>>>> - Check Xft.dpi. >>>>>>> - If non of them was set then scale=1 should be used. > From philip.race at oracle.com Tue Jul 26 20:57:10 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 26 Jul 2016 13:57:10 -0700 Subject: [9] Review request for 8156217 Selected text is shifted on HiDPI display In-Reply-To: <73ea24e4-331e-a5b5-3609-28e5ddc6f5b0@oracle.com> References: <574DE8A6.4090908@oracle.com> <5c690460-1915-9362-fbb7-d78f2670c3b9@oracle.com> <7823974c-523d-afea-c6db-4b5e9a6c33cb@oracle.com> <0798A861-8586-4DAA-92E5-08F540B7499F@cbfiddle.com> <73ea24e4-331e-a5b5-3609-28e5ddc6f5b0@oracle.com> Message-ID: <5797CEA6.10001@oracle.com> I have a lot of doubts about this as well as trouble getting my head around all of it. Given that apps need to 'buy in' to the floating point I am not sure what we are gaining but I need to make sure I understand the problem. It affects only the methods that the 3rd party code can over-ride in subclasses and that are called by the JDK internal code. There are just two protected methods that matter :- PlainView.drawSelectedText(..) and PlainView.drawUnselectedText(..) The hidpi precison matters since they are drawing a sub-range of the text. Is there any other method that matters / is used in this way ? Since 3rd party code is not over-riding these they will get the JDK super-class version, thus losing any customisation they might have done in the no-longer-called int version. Assuming that is correct, what customisation would be lost and how much does it matter? My prefernce is to deprecate the int versions and always call the float versions rather than the opt-in approach. Actually my real preference would be to come up with something that does not involve drawing the text in chunks like this. ie Swing should use AttributedCharacterIterator .. it looks like the code to do this might already be there ! 106 private float drawElement(int lineIndex, Element elem, Graphics g, 107 float x, float y, boolean fractionalCharBounds) 108 throws BadLocationException 109 { 110 int p0 = elem.getStartOffset(); 111 int p1 = elem.getEndOffset(); 112 p1 = Math.min(getDocument().getLength(), p1); 113 114 if (lineIndex == 0) { 115 x += firstLineOffset; 116 } 117 AttributeSet attr = elem.getAttributes(); 118 if (Utilities.isComposedTextAttributeDefined(attr)) { 119 g.setColor(unselected); 120 x = Utilities.drawComposedText(this, attr, g, x, y, 121 p0-elem.getStartOffset(), 122 p1-elem.getStartOffset()); 123 } else { In fact what *that* illustrates is that applications already cannot expect their over-ridden methods to be called, so this fix is trying to fix something that can't be fixed. So why can't we do that ? Just deprecate those int methods, don't add the float methods and use ACI .. BTW getTabSize() is supposed to be a character count isn't it ? Not a pixel count. So why does it need a float version. -phil On 06/30/2016 08:50 AM, Alexandr Scherbatiy wrote: > On 6/28/2016 8:14 PM, Alan Snyder wrote: >> Suppose an application is only partially fixed to use/override the >> floating point methods. Perhaps it uses a library that has not been >> fixed. >> >> Is there a more fine grained way to detect programmer awareness or >> lack of awareness of the new methods? > > Here is a slightly updated version which adds public > isUseFloatingPointAPI()/setUseFloatingPointAPI() methods to the > PlainView and WrappedPlainView classes: > http://cr.openjdk.java.net/~alexsch/8156217/webrev.02 > > Using the floating point API is disabled by default and enabled for > standard Swing text component classes. This has advantage that > selection will work for text component in users applications on HiDPI > display. > > But it still has the same problem. Applications which use custom > View classes needs to updated them to implement corresponding text > drawing methods with floating point arguments and enable the floating > point API usage. > > Thanks, > Alexandr. > >> >> Alan >> >> >>> On Jun 28, 2016, at 9:59 AM, Alexandr Scherbatiy >>> >> > wrote: >>> >>> >>> Hello, >>> >>> I tried to merge this fix with the 8132119 Provide public API for >>> text related methods in SwingUtilities2 >>> and found a flow in the used algorithm. >>> >>> For each method that uses integer coordinates the fix adds a pair >>> with floating point arguments. >>> The fix 8156217 uses only methods with floating point values to >>> correctly handle a selected text. >>> This leads that overridden method with integer arguments in user >>> code is not called anymore. >>> >>> I think that this can be handled in the following way: >>> - Add a property that enables to use methods with floating point >>> arguments in Swing. >>> By default it is false and all work as before. The issue with >>> selected text is reproduced. >>> An application with enabled property does not have issue with the >>> selected text but a user should override >>> all methods with floating point values if he uses corresponding >>> methods with integer values. >>> >>> Here is a proposed solution where new public system property >>> "javax.swing.floatingPoints.enabled" is added: >>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.01 >>> >>> - Fix the enhancement JDK-8157461 Glyph image rendering for HiDPI >>> displays >>> >>> Thanks, >>> Alexandr. >>> >>> On 6/16/2016 6:07 PM, Alexandr Scherbatiy wrote: >>>> On 6/16/2016 4:47 PM, Alexandr Scherbatiy wrote: >>>>> >>>>> I tried to look deeper in the code and it seems there is a >>>>> rounding issue when float values are summed up. >>>>> >>>>> Suppose a transform with scale 1.5 is used and the 'a' char >>>>> advance is 10 in a dev space. >>>>> The 'a' char has advance 10 / 1.5 = 6.666666666666667 as double >>>>> value and 6.6666665 when it is cast to float in user space. >>>>> The width of a string which consists of 15 'a' chars is 15 * >>>>> 6.6666665 = 100.000000. >>>>> But the same width calculated as sum of each glyph advance in >>>>> StandardGlyphVector.initPositions() method is 99.999992. >>>>> -------------- >>>>> double scale = 1.5; >>>>> float advance = (float) (10 / scale); >>>>> int N = 15; >>>>> System.out.printf("%d * %f = %f\n", N, advance, N * advance); >>>>> float sum = 0; >>>>> for (int i = 0; i < N; i++) { >>>>> sum += advance; >>>>> } >>>>> System.out.printf("sum: %f\n", sum); >>>>> -------------- >>>>> >>>>> Because of this a string drawn from float position 99.999998 is >>>>> shifted one pixel left which affects the text selection code in Swing: >>>>> ------------------------ >>>>> g.scale(1.5, 1.5); >>>>> String TEXT = "aaaaaaaaaaaaaaaa"; >>>>> Rectangle2D rect = font.getStringBounds(TEXT, 0, index, >>>>> g.getFontMetrics().getFontRenderContext()); >>>>> float selectedTextPosition = (float) rect.getWidth(); >>>>> // 99.999992 >>>>> g.drawString(TEXT.substring(0, index), x, y); // >>>>> non-selected text >>>>> g.drawString(TEXT.substring(index, TEXT.length()), x + >>>>> selectedTextPosition, y); // selected text is shifted to one pixel >>>>> left >>>>> ------------------------ >>>> The last step is how coordinates are scaled in >>>> Graphics2D.drawString() method. >>>> If the graphics has scale 1.5 and zero translate the transformed >>>> coordinates are: >>>> (99.999992 + 0) * 1.5 = 149.999985 >>>> (100.000000 + 0) * 1.5 = 150.000000 >>>> >>>> Both of them are rounded to the same value. >>>> >>>> If the translate is set to integer 1 value: >>>> (99.999992 + 1) * 1.5 = 151.499989 // shifted to one pixel left >>>> (100.000000 + 1) * 1.5 = 151.500000 >>>> >>>> A position 99.999992 in user space is rounded to 151 in dev space. >>>> A position 100.000000 in user space is rounded to 152 in dev space. >>>> >>>> And this difference can depend on the translate even it has >>>> integer value in user space because it is multiplied on the >>>> graphics scale. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 6/2/2016 11:41 PM, Alexandr Scherbatiy wrote: >>>>>> On 5/31/2016 10:40 PM, Phil Race wrote: >>>>>>> >>>>>>> I applied this and it is *much* better but there still seem to >>>>>>> be some tiny quirks. >>>>>>> When I drag the mouse to select text down and then up again, as >>>>>>> I pass the >>>>>>> original mouse click point vertically, repaint seem to jiggle >>>>>>> vertically by a pixel. >>>>>>> Perhaps a rounding issue in the repaint code's calculation of >>>>>>> the location of >>>>>>> the target y. I think I may see the same in left/right dragging >>>>>>> along a line too. >>>>>>> So I think this is repaint and not text related. Can you take a >>>>>>> look. >>>>>> >>>>>> I am able to reproduce this only using a floating point scale. >>>>>> It looks like 2d issue. I used a test which draws a text in >>>>>> two pieces. The second piece of the text is shifted from the >>>>>> first piece by the floating point size of the the first piece of >>>>>> the text. >>>>>> ----------- >>>>>> Rectangle2D rect = font.getStringBounds(TEXT, 0, index, >>>>>> g.getFontMetrics().getFontRenderContext()); >>>>>> float selectedTextPosition = (float) rect.getWidth(); >>>>>> g.drawString(TEXT.substring(0, index), x, y); >>>>>> g.drawString(TEXT.substring(index, TEXT.length()), x + >>>>>> selectedTextPosition, y); >>>>>> ----------- >>>>>> >>>>>> The second piece of the text can be shifted in the 2 cases: >>>>>> a) graphics scale is 1.5 and translation is 1. >>>>>> b) graphics scale is 2.25 without applied translation >>>>>> >>>>>> I have filed an issue on it: >>>>>> JDK-8158370 Text drawn from float pointing position and with >>>>>> float pointing scale is shifted >>>>>> https://bugs.openjdk.java.net/browse/JDK-8158370 >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> >>>>>>> On 05/06/2016 12:31 PM, Alexandr Scherbatiy wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Could you review the fix: >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8156217 >>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8156217/webrev.00 >>>>>>>> >>>>>>>> This is the second part of the fix related to the fact that >>>>>>>> char width can be fractional in user space. >>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-May/005814.html >>>>>>>> >>>>>>>> >>>>>>>> The Font.getStringBounds(...) method is used for the >>>>>>>> fractional string width calculation by Swing in user space. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin.stevens at scz.be Tue Jul 26 21:13:21 2016 From: robin.stevens at scz.be (Robin Stevens) Date: Tue, 26 Jul 2016 23:13:21 +0200 Subject: [9] Review Request: 8161664: Memory leak in com.apple.laf.AquaProgressBarUI: removed progress bar still referenced In-Reply-To: <40fcdef0-72ec-3a7e-39d3-5be6f1072338@oracle.com> References: <40fcdef0-72ec-3a7e-39d3-5be6f1072338@oracle.com> Message-ID: Hello, thank you both for the review. Updated webrev: http://cr.openjdk.java.net/~rstevens/8161664/webrev.01/ I have adjusted the test as suggested by Sergey: - I moved it to the javax/swing/JProgressBar package, as it is no longer specific for the Aqua look and feel - The test now loops over all installed look and feels. For that, I copied code from the test in javax/swing/JTab;e/7124218/SelectEditTableCell.java - The test now uses Util.generateOOME instead of the System.gc + System.finalization call Robin On Mon, Jul 25, 2016 at 10:32 PM, Sergey Bylokhov < Sergey.Bylokhov at oracle.com> wrote: > Hi, Robin. > These calls do no guaranties that all weak references will be collected. > 56 System.runFinalization(); > 57 System.gc(); > > I suggest to generate OOM explicitly. see for example: > javax/swing/UIDefaults/6795356/bug6795356.java > > Note that on other platforms it will cover Metal L&F but probably others > can be tested as well. So it will be good to test all installed L&F in the > loop. > > > On 20.07.16 14:26, Alexandr Scherbatiy wrote: > >> >> The fix looks good to me. >> >> Thanks, >> Alexandr. >> >> On 7/20/2016 11:37 AM, Robin Stevens wrote: >> >>> Hello, >>> >>> please review this patch for issue JDK-8161664: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161664 >>> Patch: http://cr.openjdk.java.net/~rstevens/8161664/webrev.00/ >>> >>> >>> >>> The problem is that in certain scenarios, the Timer in the Animator of >>> the AquaProgressBarUI does not get stopped when the progress bar is >>> removed from the Swing hierarchy. >>> >>> Several approaches were discussed in another thread >>> (http://mail.openjdk.java.net/pipermail/swing-dev/2016-July/006330.html >>> ). >>> In the linked webrev, I opted to use the same approach as what is done >>> in the BasicProgressBarUI class: only start the timer when the >>> progress bar is displayable. >>> >>> To achieve this, I wrapped all calls to startAnimationTimer with an if >>> statement that checks the displayable state of the progress bar. >>> >>> There is one call to startAnimationTimer that is not adjusted. That >>> call is only triggered from the paint method, which in turn is only >>> triggered if the progress bar is displayable. As such, the if check >>> was not needed there (imo). >>> >>> The patch includes a test, which fails without the fix and succeeds >>> afterwards. >>> >>> Thanks, >>> >>> Robin >>> >> >> > > -- > Best regards, Sergey. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Tue Jul 26 21:08:20 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 26 Jul 2016 14:08:20 -0700 Subject: [9] Review request for 8160986 Bad rendering of Swing UI controls with Metal L&F on HiDPI display In-Reply-To: References: <577EA6CC.7040406@oracle.com> Message-ID: <5797D144.20004@oracle.com> Since I noticed it right away, I am sure lots of others will soon enough. -phil. On 07/25/2016 02:19 PM, Sergey Bylokhov wrote: > On 07.07.16 22:00, Phil Race wrote: >> the screenshot here bears that out .. ie left/right do not look to be >> any better. >> >> http://cr.openjdk.java.net/~alexsch/8160986/screenshots/scrollpane-00.png >> > > Since it was missed by the author, I am not sure that it will be found > by the tester who will run the test. > >> On 07/07/2016 11:55 AM, Alexandr Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the fix: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8160986 >>> webrev: http://cr.openjdk.java.net/~alexsch/8160986/webrev.00 >>> >>> The proposed fix changes icon shapes drawn by lines to ovals and >>> polygons for JRadioButton, JComboBox and JScrollBar components for the >>> Metal L&F. >>> >>> The screenshots [1] give a hint how UI controls look before and >>> after the fix. >>> >>> [1] http://cr.openjdk.java.net/~alexsch/8160986/screenshots >>> >>> Thanks, >>> Alexandr. >>> >> > > From Sergey.Bylokhov at oracle.com Tue Jul 26 22:08:18 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 27 Jul 2016 01:08:18 +0300 Subject: [9] Review Request: 8161664: Memory leak in com.apple.laf.AquaProgressBarUI: removed progress bar still referenced In-Reply-To: References: <40fcdef0-72ec-3a7e-39d3-5be6f1072338@oracle.com> Message-ID: <9903f5ed-c6e6-a718-363d-998cb557564c@oracle.com> Sorry I missed two small issues in the previous review: - The date in copyright should have a comma "Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved." - The test should have "* @key headful" tag. On 27.07.16 0:13, Robin Stevens wrote: > Hello, > > thank you both for the review. > > Updated webrev: http://cr.openjdk.java.net/~rstevens/8161664/webrev.01/ > > I have adjusted the test as suggested by Sergey: > > - I moved it to the javax/swing/JProgressBar package, as it is no longer > specific for the Aqua look and feel > - The test now loops over all installed look and feels. For that, I > copied code from the test in > javax/swing/JTab;e/7124218/SelectEditTableCell.java > - The test now uses Util.generateOOME instead of the System.gc + > System.finalization call > > > Robin > > On Mon, Jul 25, 2016 at 10:32 PM, Sergey Bylokhov > > wrote: > > Hi, Robin. > These calls do no guaranties that all weak references will be collected. > 56 System.runFinalization(); > 57 System.gc(); > > I suggest to generate OOM explicitly. see for example: > javax/swing/UIDefaults/6795356/bug6795356.java > > Note that on other platforms it will cover Metal L&F but probably > others can be tested as well. So it will be good to test all > installed L&F in the loop. > > > On 20.07.16 14:26, Alexandr Scherbatiy wrote: > > > The fix looks good to me. > > Thanks, > Alexandr. > > On 7/20/2016 11:37 AM, Robin Stevens wrote: > > Hello, > > please review this patch for issue JDK-8161664: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8161664 > Patch: http://cr.openjdk.java.net/~rstevens/8161664/webrev.00/ > > > > The problem is that in certain scenarios, the Timer in the > Animator of > the AquaProgressBarUI does not get stopped when the progress > bar is > removed from the Swing hierarchy. > > Several approaches were discussed in another thread > (http://mail.openjdk.java.net/pipermail/swing-dev/2016-July/006330.html). > In the linked webrev, I opted to use the same approach as > what is done > in the BasicProgressBarUI class: only start the timer when the > progress bar is displayable. > > To achieve this, I wrapped all calls to startAnimationTimer > with an if > statement that checks the displayable state of the progress bar. > > There is one call to startAnimationTimer that is not > adjusted. That > call is only triggered from the paint method, which in turn > is only > triggered if the progress bar is displayable. As such, the > if check > was not needed there (imo). > > The patch includes a test, which fails without the fix and > succeeds > afterwards. > > Thanks, > > Robin > > > > > -- > Best regards, Sergey. > > -- Best regards, Sergey. From yuri.nesterenko at oracle.com Wed Jul 27 06:57:11 2016 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Wed, 27 Jul 2016 09:57:11 +0300 Subject: [9] Review request for 8160986 Bad rendering of Swing UI controls with Metal L&F on HiDPI display In-Reply-To: <5797D144.20004@oracle.com> References: <577EA6CC.7040406@oracle.com> <5797D144.20004@oracle.com> Message-ID: <57985B47.90002@oracle.com> You mean probably that the first test would not compile since it is "public class bug8160986 " in bug8031573.java ?:-) -yan On 07/27/2016 12:08 AM, Phil Race wrote: > Since I noticed it right away, I am sure lots of others will soon enough. > > -phil. > > On 07/25/2016 02:19 PM, Sergey Bylokhov wrote: >> On 07.07.16 22:00, Phil Race wrote: >>> the screenshot here bears that out .. ie left/right do not look to be >>> any better. >>> >>> http://cr.openjdk.java.net/~alexsch/8160986/screenshots/scrollpane-00.png >>> >> >> Since it was missed by the author, I am not sure that it will be found >> by the tester who will run the test. >> >>> On 07/07/2016 11:55 AM, Alexandr Scherbatiy wrote: >>>> >>>> Hello, >>>> >>>> Could you review the fix: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160986 >>>> webrev: http://cr.openjdk.java.net/~alexsch/8160986/webrev.00 >>>> >>>> The proposed fix changes icon shapes drawn by lines to ovals and >>>> polygons for JRadioButton, JComboBox and JScrollBar components for the >>>> Metal L&F. >>>> >>>> The screenshots [1] give a hint how UI controls look before and >>>> after the fix. >>>> >>>> [1] http://cr.openjdk.java.net/~alexsch/8160986/screenshots >>>> >>>> Thanks, >>>> Alexandr. >>>> >>> >> >> > From philip.race at oracle.com Wed Jul 27 12:33:29 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 27 Jul 2016 05:33:29 -0700 Subject: [9] Review request for 8160986 Bad rendering of Swing UI controls with Metal L&F on HiDPI display In-Reply-To: <57985B47.90002@oracle.com> References: <577EA6CC.7040406@oracle.com> <5797D144.20004@oracle.com> <57985B47.90002@oracle.com> Message-ID: <5798AA19.2020005@oracle.com> BTW I meant to point out (but forgot) that I want us to stop using bug ids as test names. When you stare at a list of tests in a directory I'd like to see meaningful names. I don't know what the intention was with the tests here but any new test should be so named .. -phil. On 7/26/16, 11:57 PM, Yuri Nesterenko wrote: > You mean probably that the first test would not compile since > it is "public class bug8160986 " in bug8031573.java ?:-) > > -yan > > On 07/27/2016 12:08 AM, Phil Race wrote: >> Since I noticed it right away, I am sure lots of others will soon >> enough. >> >> -phil. >> >> On 07/25/2016 02:19 PM, Sergey Bylokhov wrote: >>> On 07.07.16 22:00, Phil Race wrote: >>>> the screenshot here bears that out .. ie left/right do not look to be >>>> any better. >>>> >>>> http://cr.openjdk.java.net/~alexsch/8160986/screenshots/scrollpane-00.png >>>> >>>> >>> >>> Since it was missed by the author, I am not sure that it will be found >>> by the tester who will run the test. >>> >>>> On 07/07/2016 11:55 AM, Alexandr Scherbatiy wrote: >>>>> >>>>> Hello, >>>>> >>>>> Could you review the fix: >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160986 >>>>> webrev: http://cr.openjdk.java.net/~alexsch/8160986/webrev.00 >>>>> >>>>> The proposed fix changes icon shapes drawn by lines to ovals and >>>>> polygons for JRadioButton, JComboBox and JScrollBar components for >>>>> the >>>>> Metal L&F. >>>>> >>>>> The screenshots [1] give a hint how UI controls look before and >>>>> after the fix. >>>>> >>>>> [1] http://cr.openjdk.java.net/~alexsch/8160986/screenshots >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>> >>> >>> >> > From alexandr.scherbatiy at oracle.com Wed Jul 27 16:49:12 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Wed, 27 Jul 2016 19:49:12 +0300 Subject: [9] Review request for 8160986 Bad rendering of Swing UI controls with Metal L&F on HiDPI display In-Reply-To: <5798AA19.2020005@oracle.com> References: <577EA6CC.7040406@oracle.com> <5797D144.20004@oracle.com> <57985B47.90002@oracle.com> <5798AA19.2020005@oracle.com> Message-ID: Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8160986/webrev.01 - horizontal scroll bars are updated - the test name is updated - the instruction to test both vertical and horizontal scroll bars are added to the test I run the SwingMark for the JRadioButton which is painted with selected/deselected and enabled states and JScrollPane which shows vertical and horizontal scroll bars in turn. Each component was repainted 2002 times and the test was repeated 20 times. The results below show the SwingMark tests score for D3D on/off in format: test score for the component before the fix [link to the results] -> test score for the component after the fix (using ovals or polygons) [link to the results] performance increasing in percents. JRadioButton D3D on: 20468 [1] -> 21486 [2] performance increasing: 5% D3D off: 20299 [3] -> 21075 [4] performance increasing: 4% JScrollPane D3D on: 56184 [5] -> 57742 [6] performance increasing: 3% D3D off: 51758 [7] -> 52987 [8] performance increasing: 3% If it is necessary, polygons which draw triangles can be replaced by Line2D.Float(). Thanks, Alexandr. [1] http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/radio-button-d3d-on-base.txt [2] http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/radio-button-d3d-on-oval.txt [3] http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/radio-button-d3d-off-base.txt [4] http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/radio-button-d3d-off-oval.txt [5] http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/scroll-pane-d3d-on-base.txt [6] http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/scroll-pane-d3d-on-polygon.txt [7] http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/scroll-pane-d3d-off-base.txt [8] http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/scroll-pane-d3d-off-polygon.txt On 7/27/2016 3:33 PM, Philip Race wrote: > BTW I meant to point out (but forgot) that I want us > to stop using bug ids as test names. When you stare > at a list of tests in a directory I'd like to see meaningful names. > > I don't know what the intention was with the tests here but > any new test should be so named .. > > -phil. > > On 7/26/16, 11:57 PM, Yuri Nesterenko wrote: >> You mean probably that the first test would not compile since >> it is "public class bug8160986 " in bug8031573.java ?:-) >> >> -yan >> >> On 07/27/2016 12:08 AM, Phil Race wrote: >>> Since I noticed it right away, I am sure lots of others will soon >>> enough. >>> >>> -phil. >>> >>> On 07/25/2016 02:19 PM, Sergey Bylokhov wrote: >>>> On 07.07.16 22:00, Phil Race wrote: >>>>> the screenshot here bears that out .. ie left/right do not look to be >>>>> any better. >>>>> >>>>> http://cr.openjdk.java.net/~alexsch/8160986/screenshots/scrollpane-00.png >>>>> >>>>> >>>> >>>> Since it was missed by the author, I am not sure that it will be found >>>> by the tester who will run the test. >>>> >>>>> On 07/07/2016 11:55 AM, Alexandr Scherbatiy wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Could you review the fix: >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160986 >>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8160986/webrev.00 >>>>>> >>>>>> The proposed fix changes icon shapes drawn by lines to ovals and >>>>>> polygons for JRadioButton, JComboBox and JScrollBar components >>>>>> for the >>>>>> Metal L&F. >>>>>> >>>>>> The screenshots [1] give a hint how UI controls look before and >>>>>> after the fix. >>>>>> >>>>>> [1] http://cr.openjdk.java.net/~alexsch/8160986/screenshots >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>> >>>> >>>> >>> >> From philip.race at oracle.com Wed Jul 27 17:11:54 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 27 Jul 2016 10:11:54 -0700 Subject: [9] Review request for 8160986 Bad rendering of Swing UI controls with Metal L&F on HiDPI display In-Reply-To: References: <577EA6CC.7040406@oracle.com> <5797D144.20004@oracle.com> <57985B47.90002@oracle.com> <5798AA19.2020005@oracle.com> Message-ID: <5798EB5A.9050403@oracle.com> > D3D on: 20468 [1] -> 21486 [2] performance increasing: 5% If I recall correctly, the SwingMark summary score is actually the run time .. so an increasing number is actually a decrease in peformance. Still, the improvement in the visual results is worth it to me. The test is still odd and I am not sure what the intent is. If its an applet test then the @test tag should be on the .html file. The @bug tag in the Java file is 8040279 which is unrelated to this issue. But it looks like its just a way to display some instructions to run SwingSet2. I am not sure that it is at all worth adding something like that as a test. -phil On 07/27/2016 09:49 AM, Alexandr Scherbatiy wrote: > Hello, > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8160986/webrev.01 > > - horizontal scroll bars are updated > - the test name is updated > - the instruction to test both vertical and horizontal scroll bars are > added to the test > > I run the SwingMark for the JRadioButton which is painted with > selected/deselected and enabled states > and JScrollPane which shows vertical and horizontal scroll bars in turn. > Each component was repainted 2002 times and the test was repeated 20 > times. > > The results below show the SwingMark tests score for D3D on/off in > format: > test score for the component before the fix [link to the results] -> > test score for the component after the fix (using ovals or polygons) > [link to the results] performance increasing in percents. > > JRadioButton > D3D on: 20468 [1] -> 21486 [2] performance increasing: 5% > D3D off: 20299 [3] -> 21075 [4] performance increasing: 4% > > JScrollPane > D3D on: 56184 [5] -> 57742 [6] performance increasing: 3% > D3D off: 51758 [7] -> 52987 [8] performance increasing: 3% > > If it is necessary, polygons which draw triangles can be replaced by > Line2D.Float(). > > Thanks, > Alexandr. > > [1] > http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/radio-button-d3d-on-base.txt > [2] > http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/radio-button-d3d-on-oval.txt > [3] > http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/radio-button-d3d-off-base.txt > [4] > http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/radio-button-d3d-off-oval.txt > > [5] > http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/scroll-pane-d3d-on-base.txt > [6] > http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/scroll-pane-d3d-on-polygon.txt > [7] > http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/scroll-pane-d3d-off-base.txt > [8] > http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/scroll-pane-d3d-off-polygon.txt > > On 7/27/2016 3:33 PM, Philip Race wrote: >> BTW I meant to point out (but forgot) that I want us >> to stop using bug ids as test names. When you stare >> at a list of tests in a directory I'd like to see meaningful names. >> >> I don't know what the intention was with the tests here but >> any new test should be so named .. >> >> -phil. >> >> On 7/26/16, 11:57 PM, Yuri Nesterenko wrote: >>> You mean probably that the first test would not compile since >>> it is "public class bug8160986 " in bug8031573.java ?:-) >>> >>> -yan >>> >>> On 07/27/2016 12:08 AM, Phil Race wrote: >>>> Since I noticed it right away, I am sure lots of others will soon >>>> enough. >>>> >>>> -phil. >>>> >>>> On 07/25/2016 02:19 PM, Sergey Bylokhov wrote: >>>>> On 07.07.16 22:00, Phil Race wrote: >>>>>> the screenshot here bears that out .. ie left/right do not look >>>>>> to be >>>>>> any better. >>>>>> >>>>>> http://cr.openjdk.java.net/~alexsch/8160986/screenshots/scrollpane-00.png >>>>>> >>>>>> >>>>> >>>>> Since it was missed by the author, I am not sure that it will be >>>>> found >>>>> by the tester who will run the test. >>>>> >>>>>> On 07/07/2016 11:55 AM, Alexandr Scherbatiy wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Could you review the fix: >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160986 >>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8160986/webrev.00 >>>>>>> >>>>>>> The proposed fix changes icon shapes drawn by lines to ovals and >>>>>>> polygons for JRadioButton, JComboBox and JScrollBar components >>>>>>> for the >>>>>>> Metal L&F. >>>>>>> >>>>>>> The screenshots [1] give a hint how UI controls look before and >>>>>>> after the fix. >>>>>>> >>>>>>> [1] http://cr.openjdk.java.net/~alexsch/8160986/screenshots >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> > From robin.stevens at scz.be Wed Jul 27 21:16:40 2016 From: robin.stevens at scz.be (Robin Stevens) Date: Wed, 27 Jul 2016 23:16:40 +0200 Subject: [9] Review Request: 8161664: Memory leak in com.apple.laf.AquaProgressBarUI: removed progress bar still referenced In-Reply-To: <9903f5ed-c6e6-a718-363d-998cb557564c@oracle.com> References: <40fcdef0-72ec-3a7e-39d3-5be6f1072338@oracle.com> <9903f5ed-c6e6-a718-363d-998cb557564c@oracle.com> Message-ID: Here is the updated webrev which includes the comma in the copyright and the extra tag: http://cr.openjdk.java.net/~rstevens/8161664/webrev.02/ Robin On Wed, Jul 27, 2016 at 12:08 AM, Sergey Bylokhov < Sergey.Bylokhov at oracle.com> wrote: > Sorry I missed two small issues in the previous review: > - The date in copyright should have a comma "Copyright (c) 2016, Oracle > and/or its affiliates. All rights reserved." > - The test should have "* @key headful" tag. > > On 27.07.16 0:13, Robin Stevens wrote: > >> Hello, >> >> thank you both for the review. >> >> Updated webrev: http://cr.openjdk.java.net/~rstevens/8161664/webrev.01/ >> >> I have adjusted the test as suggested by Sergey: >> >> - I moved it to the javax/swing/JProgressBar package, as it is no longer >> specific for the Aqua look and feel >> - The test now loops over all installed look and feels. For that, I >> copied code from the test in >> javax/swing/JTab;e/7124218/SelectEditTableCell.java >> - The test now uses Util.generateOOME instead of the System.gc + >> System.finalization call >> >> >> Robin >> >> On Mon, Jul 25, 2016 at 10:32 PM, Sergey Bylokhov >> > wrote: >> >> Hi, Robin. >> These calls do no guaranties that all weak references will be >> collected. >> 56 System.runFinalization(); >> 57 System.gc(); >> >> I suggest to generate OOM explicitly. see for example: >> javax/swing/UIDefaults/6795356/bug6795356.java >> >> Note that on other platforms it will cover Metal L&F but probably >> others can be tested as well. So it will be good to test all >> installed L&F in the loop. >> >> >> On 20.07.16 14:26, Alexandr Scherbatiy wrote: >> >> >> The fix looks good to me. >> >> Thanks, >> Alexandr. >> >> On 7/20/2016 11:37 AM, Robin Stevens wrote: >> >> Hello, >> >> please review this patch for issue JDK-8161664: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8161664 >> Patch: >> http://cr.openjdk.java.net/~rstevens/8161664/webrev.00/ >> >> >> >> The problem is that in certain scenarios, the Timer in the >> Animator of >> the AquaProgressBarUI does not get stopped when the progress >> bar is >> removed from the Swing hierarchy. >> >> Several approaches were discussed in another thread >> ( >> http://mail.openjdk.java.net/pipermail/swing-dev/2016-July/006330.html). >> In the linked webrev, I opted to use the same approach as >> what is done >> in the BasicProgressBarUI class: only start the timer when the >> progress bar is displayable. >> >> To achieve this, I wrapped all calls to startAnimationTimer >> with an if >> statement that checks the displayable state of the progress >> bar. >> >> There is one call to startAnimationTimer that is not >> adjusted. That >> call is only triggered from the paint method, which in turn >> is only >> triggered if the progress bar is displayable. As such, the >> if check >> was not needed there (imo). >> >> The patch includes a test, which fails without the fix and >> succeeds >> afterwards. >> >> Thanks, >> >> Robin >> >> >> >> >> -- >> Best regards, Sergey. >> >> >> > > -- > Best regards, Sergey. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Jul 28 08:55:06 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 28 Jul 2016 11:55:06 +0300 Subject: [9] Review Request: 8161664: Memory leak in com.apple.laf.AquaProgressBarUI: removed progress bar still referenced In-Reply-To: References: <40fcdef0-72ec-3a7e-39d3-5be6f1072338@oracle.com> <9903f5ed-c6e6-a718-363d-998cb557564c@oracle.com> Message-ID: <3e27b13a-0f56-30e3-33ad-ed000f3f1abf@oracle.com> Thanks! Looks fine. On 28.07.16 0:16, Robin Stevens wrote: > Here is the updated webrev which includes the comma in the copyright and > the extra tag: > > http://cr.openjdk.java.net/~rstevens/8161664/webrev.02/ > > Robin > > On Wed, Jul 27, 2016 at 12:08 AM, Sergey Bylokhov > > wrote: > > Sorry I missed two small issues in the previous review: > - The date in copyright should have a comma "Copyright (c) 2016, > Oracle and/or its affiliates. All rights reserved." > - The test should have "* @key headful" tag. > > On 27.07.16 0:13, Robin Stevens wrote: > > Hello, > > thank you both for the review. > > Updated webrev: > http://cr.openjdk.java.net/~rstevens/8161664/webrev.01/ > > I have adjusted the test as suggested by Sergey: > > - I moved it to the javax/swing/JProgressBar package, as it is > no longer > specific for the Aqua look and feel > - The test now loops over all installed look and feels. For that, I > copied code from the test in > javax/swing/JTab;e/7124218/SelectEditTableCell.java > - The test now uses Util.generateOOME instead of the System.gc + > System.finalization call > > > Robin > > On Mon, Jul 25, 2016 at 10:32 PM, Sergey Bylokhov > > >> wrote: > > Hi, Robin. > These calls do no guaranties that all weak references will > be collected. > 56 System.runFinalization(); > 57 System.gc(); > > I suggest to generate OOM explicitly. see for example: > javax/swing/UIDefaults/6795356/bug6795356.java > > Note that on other platforms it will cover Metal L&F but > probably > others can be tested as well. So it will be good to test all > installed L&F in the loop. > > > On 20.07.16 14:26, Alexandr Scherbatiy wrote: > > > The fix looks good to me. > > Thanks, > Alexandr. > > On 7/20/2016 11:37 AM, Robin Stevens wrote: > > Hello, > > please review this patch for issue JDK-8161664: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8161664 > Patch: > http://cr.openjdk.java.net/~rstevens/8161664/webrev.00/ > > > > > The problem is that in certain scenarios, the Timer > in the > Animator of > the AquaProgressBarUI does not get stopped when the > progress > bar is > removed from the Swing hierarchy. > > Several approaches were discussed in another thread > > (http://mail.openjdk.java.net/pipermail/swing-dev/2016-July/006330.html). > In the linked webrev, I opted to use the same > approach as > what is done > in the BasicProgressBarUI class: only start the > timer when the > progress bar is displayable. > > To achieve this, I wrapped all calls to > startAnimationTimer > with an if > statement that checks the displayable state of the > progress bar. > > There is one call to startAnimationTimer that is not > adjusted. That > call is only triggered from the paint method, which > in turn > is only > triggered if the progress bar is displayable. As > such, the > if check > was not needed there (imo). > > The patch includes a test, which fails without the > fix and > succeeds > afterwards. > > Thanks, > > Robin > > > > > -- > Best regards, Sergey. > > > > > -- > Best regards, Sergey. > > -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Thu Jul 28 14:38:43 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 28 Jul 2016 17:38:43 +0300 Subject: [9] Review request for 8156217 Selected text is shifted on HiDPI display In-Reply-To: <5797CEA6.10001@oracle.com> References: <574DE8A6.4090908@oracle.com> <5c690460-1915-9362-fbb7-d78f2670c3b9@oracle.com> <7823974c-523d-afea-c6db-4b5e9a6c33cb@oracle.com> <0798A861-8586-4DAA-92E5-08F540B7499F@cbfiddle.com> <73ea24e4-331e-a5b5-3609-28e5ddc6f5b0@oracle.com> <5797CEA6.10001@oracle.com> Message-ID: <47c44221-9775-0c06-1029-8a90568772b6@oracle.com> See comments inline. On 7/26/2016 11:57 PM, Phil Race wrote: > I have a lot of doubts about this as well as trouble getting my head > around all of it. > > Given that apps need to 'buy in' to the floating point I am not sure > what we are gaining > but I need to make sure I understand the problem. > > It affects only the methods that the 3rd party code can over-ride > in subclasses and that are called by the JDK internal code. > > There are just two protected methods that matter :- > PlainView.drawSelectedText(..) > and > PlainView.drawUnselectedText(..) > > The hidpi precison matters since they are drawing a sub-range of the text. > Is there any other method that matters / is used in this way ? I have found the following methods which relate to text drawing, can be overridden and could have floating point coordinates: javax.swing.text.PlainView.drawLine(...) javax.swing.text.PlainView.lineToRect(...) javax.swing.text.PasswordView.drawEchoCharacter(...) javax.swing.plaf.TextUI.modelToView(...) javax.swing.plaf.TextUI.viewToModel(...) javax.swing.plaf.TextUI.getToolTipText(...) There is also a method which relates to a caret position in a text: javax.swing.text.DefaultCaret.setMagicCaretPosition(Point p) This requires additional investigation because DefaultCaret extends Rectangle and so its coordinates can't be float. > > Since 3rd party code is not over-riding these they will get the JDK > super-class version, thus losing any customisation they might have done > in the no-longer-called int version. > > Assuming that is correct, what customisation would be lost and how > much does it matter? The example is javax.swing.text.PasswordView class which overrides drawSelectedText(...)/drawUnselectedText(...) methods and draws echo chars instead of text. The similar can be done in a custom component: -------- public class CustomPasswordField extends FieldView { @Override protected int drawSelectedText(Graphics g, int x, int y, int p0, int p1) throws BadLocationException { // draw echo chars } } -------- Switching to support new methods with floating point coordinates will lead that real text will be shown for old applications in password fields. > > My prefernce is to deprecate the int versions and always call the > float versions > rather than the opt-in approach. > > Actually my real preference would be to come up with something that does > not involve drawing the text in chunks like this. > > ie Swing should use AttributedCharacterIterator .. it looks like the > code to > do this might already be there ! > > 106 private float drawElement(int lineIndex, Element elem, Graphics g, > 107 float x, float y, boolean fractionalCharBounds) > 108 throws BadLocationException > 109 { > 110 int p0 = elem.getStartOffset(); > 111 int p1 = elem.getEndOffset(); > 112 p1 = Math.min(getDocument().getLength(), p1); > 113 > 114 if (lineIndex == 0) { > 115 x += firstLineOffset; > 116 } > 117 AttributeSet attr = elem.getAttributes(); > 118 if (Utilities.isComposedTextAttributeDefined(attr)) { > 119 g.setColor(unselected); > 120 x = Utilities.drawComposedText(this, attr, g, x, y, > 121 p0-elem.getStartOffset(), > 122 p1-elem.getStartOffset()); > 123 } else { > > In fact what *that* illustrates is that applications already cannot expect > their over-ridden methods to be called, so this fix is trying to fix > something > that can't be fixed. The javadoc for the "protected PlainView.drawLine(...)" method is: --------- /** * Renders a line of text, suppressing whitespace at the end * and expanding any tabs. This is implemented to make calls * to the methods {@code drawUnselectedText} and * {@code drawSelectedText} so that the way selected and * unselected text are rendered can be customized. --------- Applications can rely on this behaviour and stopping to call the drawSelectedText(...)/drawUnselectedText(...) methods with int coordinates will be incompatible change. > > So why can't we do that ? Just deprecate those int methods, don't add > the float methods and use ACI .. New float methods allow to easily migrate on new API for applications without significant changes. > BTW getTabSize() is supposed to be a character count isn't it ? Not a > pixel > count. So why does it need a float version. Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8156217/webrev.04 - methods with int coordinates which can be overridden are deprecated - getFractionalTabSize() method is removed Thanks, Alexandr. > > -phil > > On 06/30/2016 08:50 AM, Alexandr Scherbatiy wrote: >> On 6/28/2016 8:14 PM, Alan Snyder wrote: >>> Suppose an application is only partially fixed to use/override the >>> floating point methods. Perhaps it uses a library that has not been >>> fixed. >>> >>> Is there a more fine grained way to detect programmer awareness or >>> lack of awareness of the new methods? >> >> Here is a slightly updated version which adds public >> isUseFloatingPointAPI()/setUseFloatingPointAPI() methods to the >> PlainView and WrappedPlainView classes: >> http://cr.openjdk.java.net/~alexsch/8156217/webrev.02 >> >> Using the floating point API is disabled by default and enabled for >> standard Swing text component classes. This has advantage that >> selection will work for text component in users applications on HiDPI >> display. >> >> But it still has the same problem. Applications which use custom >> View classes needs to updated them to implement corresponding text >> drawing methods with floating point arguments and enable the floating >> point API usage. >> >> Thanks, >> Alexandr. >> >>> >>> Alan >>> >>> >>>> On Jun 28, 2016, at 9:59 AM, Alexandr Scherbatiy >>>> >>> > wrote: >>>> >>>> >>>> Hello, >>>> >>>> I tried to merge this fix with the 8132119 Provide public API for >>>> text related methods in SwingUtilities2 >>>> and found a flow in the used algorithm. >>>> >>>> For each method that uses integer coordinates the fix adds a pair >>>> with floating point arguments. >>>> The fix 8156217 uses only methods with floating point values to >>>> correctly handle a selected text. >>>> This leads that overridden method with integer arguments in user >>>> code is not called anymore. >>>> >>>> I think that this can be handled in the following way: >>>> - Add a property that enables to use methods with floating point >>>> arguments in Swing. >>>> By default it is false and all work as before. The issue with >>>> selected text is reproduced. >>>> An application with enabled property does not have issue with >>>> the selected text but a user should override >>>> all methods with floating point values if he uses corresponding >>>> methods with integer values. >>>> >>>> Here is a proposed solution where new public system property >>>> "javax.swing.floatingPoints.enabled" is added: >>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.01 >>>> >>>> - Fix the enhancement JDK-8157461 Glyph image rendering for HiDPI >>>> displays >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 6/16/2016 6:07 PM, Alexandr Scherbatiy wrote: >>>>> On 6/16/2016 4:47 PM, Alexandr Scherbatiy wrote: >>>>>> >>>>>> I tried to look deeper in the code and it seems there is a >>>>>> rounding issue when float values are summed up. >>>>>> >>>>>> Suppose a transform with scale 1.5 is used and the 'a' char >>>>>> advance is 10 in a dev space. >>>>>> The 'a' char has advance 10 / 1.5 = 6.666666666666667 as double >>>>>> value and 6.6666665 when it is cast to float in user space. >>>>>> The width of a string which consists of 15 'a' chars is 15 * >>>>>> 6.6666665 = 100.000000. >>>>>> But the same width calculated as sum of each glyph advance in >>>>>> StandardGlyphVector.initPositions() method is 99.999992. >>>>>> -------------- >>>>>> double scale = 1.5; >>>>>> float advance = (float) (10 / scale); >>>>>> int N = 15; >>>>>> System.out.printf("%d * %f = %f\n", N, advance, N * advance); >>>>>> float sum = 0; >>>>>> for (int i = 0; i < N; i++) { >>>>>> sum += advance; >>>>>> } >>>>>> System.out.printf("sum: %f\n", sum); >>>>>> -------------- >>>>>> >>>>>> Because of this a string drawn from float position 99.999998 is >>>>>> shifted one pixel left which affects the text selection code in >>>>>> Swing: >>>>>> ------------------------ >>>>>> g.scale(1.5, 1.5); >>>>>> String TEXT = "aaaaaaaaaaaaaaaa"; >>>>>> Rectangle2D rect = font.getStringBounds(TEXT, 0, index, >>>>>> g.getFontMetrics().getFontRenderContext()); >>>>>> float selectedTextPosition = (float) rect.getWidth(); >>>>>> // 99.999992 >>>>>> g.drawString(TEXT.substring(0, index), x, y); // >>>>>> non-selected text >>>>>> g.drawString(TEXT.substring(index, TEXT.length()), x + >>>>>> selectedTextPosition, y); // selected text is shifted to one >>>>>> pixel left >>>>>> ------------------------ >>>>> The last step is how coordinates are scaled in >>>>> Graphics2D.drawString() method. >>>>> If the graphics has scale 1.5 and zero translate the >>>>> transformed coordinates are: >>>>> (99.999992 + 0) * 1.5 = 149.999985 >>>>> (100.000000 + 0) * 1.5 = 150.000000 >>>>> >>>>> Both of them are rounded to the same value. >>>>> >>>>> If the translate is set to integer 1 value: >>>>> (99.999992 + 1) * 1.5 = 151.499989 // shifted to one pixel left >>>>> (100.000000 + 1) * 1.5 = 151.500000 >>>>> >>>>> A position 99.999992 in user space is rounded to 151 in dev space. >>>>> A position 100.000000 in user space is rounded to 152 in dev space. >>>>> >>>>> And this difference can depend on the translate even it has >>>>> integer value in user space because it is multiplied on the >>>>> graphics scale. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> On 6/2/2016 11:41 PM, Alexandr Scherbatiy wrote: >>>>>>> On 5/31/2016 10:40 PM, Phil Race wrote: >>>>>>>> >>>>>>>> I applied this and it is *much* better but there still seem to >>>>>>>> be some tiny quirks. >>>>>>>> When I drag the mouse to select text down and then up again, as >>>>>>>> I pass the >>>>>>>> original mouse click point vertically, repaint seem to jiggle >>>>>>>> vertically by a pixel. >>>>>>>> Perhaps a rounding issue in the repaint code's calculation of >>>>>>>> the location of >>>>>>>> the target y. I think I may see the same in left/right dragging >>>>>>>> along a line too. >>>>>>>> So I think this is repaint and not text related. Can you take a >>>>>>>> look. >>>>>>> >>>>>>> I am able to reproduce this only using a floating point scale. >>>>>>> It looks like 2d issue. I used a test which draws a text in >>>>>>> two pieces. The second piece of the text is shifted from the >>>>>>> first piece by the floating point size of the the first piece of >>>>>>> the text. >>>>>>> ----------- >>>>>>> Rectangle2D rect = font.getStringBounds(TEXT, 0, index, >>>>>>> g.getFontMetrics().getFontRenderContext()); >>>>>>> float selectedTextPosition = (float) rect.getWidth(); >>>>>>> g.drawString(TEXT.substring(0, index), x, y); >>>>>>> g.drawString(TEXT.substring(index, TEXT.length()), x + >>>>>>> selectedTextPosition, y); >>>>>>> ----------- >>>>>>> >>>>>>> The second piece of the text can be shifted in the 2 cases: >>>>>>> a) graphics scale is 1.5 and translation is 1. >>>>>>> b) graphics scale is 2.25 without applied translation >>>>>>> >>>>>>> I have filed an issue on it: >>>>>>> JDK-8158370 Text drawn from float pointing position and with >>>>>>> float pointing scale is shifted >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8158370 >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> >>>>>>>> On 05/06/2016 12:31 PM, Alexandr Scherbatiy wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Could you review the fix: >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8156217 >>>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8156217/webrev.00 >>>>>>>>> >>>>>>>>> This is the second part of the fix related to the fact that >>>>>>>>> char width can be fractional in user space. >>>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-May/005814.html >>>>>>>>> >>>>>>>>> >>>>>>>>> The Font.getStringBounds(...) method is used for the >>>>>>>>> fractional string width calculation by Swing in user space. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Thu Jul 28 16:45:59 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 28 Jul 2016 19:45:59 +0300 Subject: [9] Review request for 8160986 Bad rendering of Swing UI controls with Metal L&F on HiDPI display In-Reply-To: <5798EB5A.9050403@oracle.com> References: <577EA6CC.7040406@oracle.com> <5797D144.20004@oracle.com> <57985B47.90002@oracle.com> <5798AA19.2020005@oracle.com> <5798EB5A.9050403@oracle.com> Message-ID: Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8160986/webrev.02 - html part of the test is removed On 7/27/2016 8:11 PM, Phil Race wrote: > > D3D on: 20468 [1] -> 21486 [2] performance increasing: 5% > If I recall correctly, the SwingMark summary score is actually > the run time .. so an increasing number is actually a decrease in > peformance. Sorry. The performance is definitely is decreased after the fix. Thanks, Alexandr. > > Still, the improvement in the visual results is worth it to me. > > The test is still odd and I am not sure what the intent is. > If its an applet test then the @test tag should be on the .html file. > The @bug tag in the Java file is 8040279 which is unrelated to this > issue. > But it looks like its just a way to display some instructions to run > SwingSet2. > I am not sure that it is at all worth adding something like that as a > test. > > -phil > > > > On 07/27/2016 09:49 AM, Alexandr Scherbatiy wrote: >> Hello, >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8160986/webrev.01 >> >> - horizontal scroll bars are updated >> - the test name is updated >> - the instruction to test both vertical and horizontal scroll bars >> are added to the test >> >> I run the SwingMark for the JRadioButton which is painted with >> selected/deselected and enabled states >> and JScrollPane which shows vertical and horizontal scroll bars in turn. >> Each component was repainted 2002 times and the test was repeated 20 >> times. >> >> The results below show the SwingMark tests score for D3D on/off in >> format: >> test score for the component before the fix [link to the results] -> >> test score for the component after the fix (using ovals or polygons) >> [link to the results] performance increasing in percents. >> >> JRadioButton >> D3D on: 20468 [1] -> 21486 [2] performance increasing: 5% >> D3D off: 20299 [3] -> 21075 [4] performance increasing: 4% >> >> JScrollPane >> D3D on: 56184 [5] -> 57742 [6] performance increasing: 3% >> D3D off: 51758 [7] -> 52987 [8] performance increasing: 3% >> >> If it is necessary, polygons which draw triangles can be replaced by >> Line2D.Float(). >> >> Thanks, >> Alexandr. >> >> [1] >> http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/radio-button-d3d-on-base.txt >> [2] >> http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/radio-button-d3d-on-oval.txt >> [3] >> http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/radio-button-d3d-off-base.txt >> [4] >> http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/radio-button-d3d-off-oval.txt >> >> [5] >> http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/scroll-pane-d3d-on-base.txt >> [6] >> http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/scroll-pane-d3d-on-polygon.txt >> [7] >> http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/scroll-pane-d3d-off-base.txt >> [8] >> http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/scroll-pane-d3d-off-polygon.txt >> >> On 7/27/2016 3:33 PM, Philip Race wrote: >>> BTW I meant to point out (but forgot) that I want us >>> to stop using bug ids as test names. When you stare >>> at a list of tests in a directory I'd like to see meaningful names. >>> >>> I don't know what the intention was with the tests here but >>> any new test should be so named .. >>> >>> -phil. >>> >>> On 7/26/16, 11:57 PM, Yuri Nesterenko wrote: >>>> You mean probably that the first test would not compile since >>>> it is "public class bug8160986 " in bug8031573.java ?:-) >>>> >>>> -yan >>>> >>>> On 07/27/2016 12:08 AM, Phil Race wrote: >>>>> Since I noticed it right away, I am sure lots of others will soon >>>>> enough. >>>>> >>>>> -phil. >>>>> >>>>> On 07/25/2016 02:19 PM, Sergey Bylokhov wrote: >>>>>> On 07.07.16 22:00, Phil Race wrote: >>>>>>> the screenshot here bears that out .. ie left/right do not look >>>>>>> to be >>>>>>> any better. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~alexsch/8160986/screenshots/scrollpane-00.png >>>>>>> >>>>>>> >>>>>> >>>>>> Since it was missed by the author, I am not sure that it will be >>>>>> found >>>>>> by the tester who will run the test. >>>>>> >>>>>>> On 07/07/2016 11:55 AM, Alexandr Scherbatiy wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> Could you review the fix: >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160986 >>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8160986/webrev.00 >>>>>>>> >>>>>>>> The proposed fix changes icon shapes drawn by lines to ovals and >>>>>>>> polygons for JRadioButton, JComboBox and JScrollBar components >>>>>>>> for the >>>>>>>> Metal L&F. >>>>>>>> >>>>>>>> The screenshots [1] give a hint how UI controls look before and >>>>>>>> after the fix. >>>>>>>> >>>>>>>> [1] http://cr.openjdk.java.net/~alexsch/8160986/screenshots >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >> > From philip.race at oracle.com Thu Jul 28 23:20:42 2016 From: philip.race at oracle.com (Philip Race) Date: Thu, 28 Jul 2016 16:20:42 -0700 Subject: [9] Review request for 8160986 Bad rendering of Swing UI controls with Metal L&F on HiDPI display In-Reply-To: References: <577EA6CC.7040406@oracle.com> <5797D144.20004@oracle.com> <57985B47.90002@oracle.com> <5798AA19.2020005@oracle.com> <5798EB5A.9050403@oracle.com> Message-ID: <579A934A.3020502@oracle.com> +1 -phil On 7/28/16, 9:45 AM, Alexandr Scherbatiy wrote: > > Hello, > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8160986/webrev.02 > > - html part of the test is removed > > On 7/27/2016 8:11 PM, Phil Race wrote: >> > D3D on: 20468 [1] -> 21486 [2] performance increasing: 5% >> If I recall correctly, the SwingMark summary score is actually >> the run time .. so an increasing number is actually a decrease in >> peformance. > Sorry. The performance is definitely is decreased after the fix. > > Thanks, > Alexandr. >> >> Still, the improvement in the visual results is worth it to me. >> >> The test is still odd and I am not sure what the intent is. >> If its an applet test then the @test tag should be on the .html file. >> The @bug tag in the Java file is 8040279 which is unrelated to this >> issue. >> But it looks like its just a way to display some instructions to run >> SwingSet2. >> I am not sure that it is at all worth adding something like that as a >> test. >> >> -phil >> >> >> >> On 07/27/2016 09:49 AM, Alexandr Scherbatiy wrote: >>> Hello, >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8160986/webrev.01 >>> >>> - horizontal scroll bars are updated >>> - the test name is updated >>> - the instruction to test both vertical and horizontal scroll bars >>> are added to the test >>> >>> I run the SwingMark for the JRadioButton which is painted with >>> selected/deselected and enabled states >>> and JScrollPane which shows vertical and horizontal scroll bars in >>> turn. >>> Each component was repainted 2002 times and the test was repeated 20 >>> times. >>> >>> The results below show the SwingMark tests score for D3D on/off in >>> format: >>> test score for the component before the fix [link to the results] -> >>> test score for the component after the fix (using ovals or polygons) >>> [link to the results] performance increasing in percents. >>> >>> JRadioButton >>> D3D on: 20468 [1] -> 21486 [2] performance increasing: 5% >>> D3D off: 20299 [3] -> 21075 [4] performance increasing: 4% >>> >>> JScrollPane >>> D3D on: 56184 [5] -> 57742 [6] performance increasing: 3% >>> D3D off: 51758 [7] -> 52987 [8] performance increasing: 3% >>> >>> If it is necessary, polygons which draw triangles can be replaced by >>> Line2D.Float(). >>> >>> Thanks, >>> Alexandr. >>> >>> [1] >>> http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/radio-button-d3d-on-base.txt >>> [2] >>> http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/radio-button-d3d-on-oval.txt >>> [3] >>> http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/radio-button-d3d-off-base.txt >>> [4] >>> http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/radio-button-d3d-off-oval.txt >>> >>> [5] >>> http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/scroll-pane-d3d-on-base.txt >>> [6] >>> http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/scroll-pane-d3d-on-polygon.txt >>> [7] >>> http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/scroll-pane-d3d-off-base.txt >>> [8] >>> http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/scroll-pane-d3d-off-polygon.txt >>> >>> On 7/27/2016 3:33 PM, Philip Race wrote: >>>> BTW I meant to point out (but forgot) that I want us >>>> to stop using bug ids as test names. When you stare >>>> at a list of tests in a directory I'd like to see meaningful names. >>>> >>>> I don't know what the intention was with the tests here but >>>> any new test should be so named .. >>>> >>>> -phil. >>>> >>>> On 7/26/16, 11:57 PM, Yuri Nesterenko wrote: >>>>> You mean probably that the first test would not compile since >>>>> it is "public class bug8160986 " in bug8031573.java ?:-) >>>>> >>>>> -yan >>>>> >>>>> On 07/27/2016 12:08 AM, Phil Race wrote: >>>>>> Since I noticed it right away, I am sure lots of others will soon >>>>>> enough. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 07/25/2016 02:19 PM, Sergey Bylokhov wrote: >>>>>>> On 07.07.16 22:00, Phil Race wrote: >>>>>>>> the screenshot here bears that out .. ie left/right do not look >>>>>>>> to be >>>>>>>> any better. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~alexsch/8160986/screenshots/scrollpane-00.png >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Since it was missed by the author, I am not sure that it will be >>>>>>> found >>>>>>> by the tester who will run the test. >>>>>>> >>>>>>>> On 07/07/2016 11:55 AM, Alexandr Scherbatiy wrote: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Could you review the fix: >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160986 >>>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8160986/webrev.00 >>>>>>>>> >>>>>>>>> The proposed fix changes icon shapes drawn by lines to ovals >>>>>>>>> and >>>>>>>>> polygons for JRadioButton, JComboBox and JScrollBar components >>>>>>>>> for the >>>>>>>>> Metal L&F. >>>>>>>>> >>>>>>>>> The screenshots [1] give a hint how UI controls look before and >>>>>>>>> after the fix. >>>>>>>>> >>>>>>>>> [1] http://cr.openjdk.java.net/~alexsch/8160986/screenshots >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>> >> > From Sergey.Bylokhov at oracle.com Fri Jul 29 11:30:51 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 29 Jul 2016 14:30:51 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> <4faf3887-5857-e827-ecfb-25285b00b959@oracle.com> <5790A187.70004@oracle.com> <88db89fb-4f9a-6bad-3c9e-374ea3b6b488@oracle.com> <579106C6.20805@oracle.com> <231b22f8-b2be-8637-a526-dfbaa7f18c9d@oracle.com> <5791C408.8010500@oracle.com> <6b49dffd-705d-ce15-a8a1-06f3251cb7bf@oracle.com> <0ea6c08f-cd15-b883-5d14-370c2592b6a3@oracle.com> <6192bece-6333-0239-4fd6-35248baf78a1@oracle.com> <6f7d5215-c66c-879b-8c8e-6fbe9ca2c511@oracle.com> <42cdd713-c4e5-e407-9d43-5ced49f611ad@oracle.com> <06e261d1-4a7d-3016-5f22-531e909097f7@oracle.com> <94897cb8-f94e-c573-cde3-8e1b95da73f6@oracle.com> Message-ID: <8f8372e2-7140-08f5-80d7-e9ea74e970aa@oracle.com> On 26.07.16 22:05, Semyon Sadetsky wrote: >> It is actually directly related to the global scale, since support of >> Xft/ was added in JDK-4830281 as a way to scale java UI. And now the >> new solution and the old one conflicts. Can we skip the usage of >> gnome.Xft if default device scale is not identity (which means that >> some other scale factor is used)? > Do you mean if native scale > 1 then to use scale=1 for GTK font size? > That will give the same result I guess. Did you try to implement it? In this case the gnome.Xft will be used only if no other scale was set, it should work like described below: > - Take debug scale into account if it was set and skip all others. > - Check J2D_UISCALE > - Check scale-factor, text-scale-factor, text-scaling-factor. > - Check Xft.dpi. > - If non of them was set then scale=1 should be used. -- Best regards, Sergey. From semyon.sadetsky at oracle.com Fri Jul 29 16:06:51 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 29 Jul 2016 19:06:51 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: <8f8372e2-7140-08f5-80d7-e9ea74e970aa@oracle.com> References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> <5790A187.70004@oracle.com> <88db89fb-4f9a-6bad-3c9e-374ea3b6b488@oracle.com> <579106C6.20805@oracle.com> <231b22f8-b2be-8637-a526-dfbaa7f18c9d@oracle.com> <5791C408.8010500@oracle.com> <6b49dffd-705d-ce15-a8a1-06f3251cb7bf@oracle.com> <0ea6c08f-cd15-b883-5d14-370c2592b6a3@oracle.com> <6192bece-6333-0239-4fd6-35248baf78a1@oracle.com> <6f7d5215-c66c-879b-8c8e-6fbe9ca2c511@oracle.com> <42cdd713-c4e5-e407-9d43-5ced49f611ad@oracle.com> <06e261d1-4a7d-3016-5f22-531e909097f7@oracle.com> <94897cb8-f94e-c573-cde3-8e1b95da73f6@oracle.com> <8f8372e2-7140-08f5-80d7-e9ea74e970aa@oracle.com> Message-ID: <5c967c6b-50e4-4079-fd9e-2f86628d5bb1@oracle.com> On 29.07.2016 14:30, Sergey Bylokhov wrote: > On 26.07.16 22:05, Semyon Sadetsky wrote: >>> It is actually directly related to the global scale, since support of >>> Xft/ was added in JDK-4830281 as a way to scale java UI. And now the >>> new solution and the old one conflicts. Can we skip the usage of >>> gnome.Xft if default device scale is not identity (which means that >>> some other scale factor is used)? >> Do you mean if native scale > 1 then to use scale=1 for GTK font size? >> That will give the same result I guess. > > Did you try to implement it? In this case the gnome.Xft will be used > only if no other scale was set, it should work like described below: Once again Xft.dpi cannot be used as global scale directly. This bug is not about global scale. > >> - Take debug scale into account if it was set and skip all others. >> - Check J2D_UISCALE >> - Check scale-factor, text-scale-factor, text-scaling-factor. >> - Check Xft.dpi. >> - If non of them was set then scale=1 should be used. > From semyon.sadetsky at oracle.com Fri Jul 29 18:03:42 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 29 Jul 2016 21:03:42 +0300 Subject: [9] Review request for 8160986 Bad rendering of Swing UI controls with Metal L&F on HiDPI display In-Reply-To: References: <577EA6CC.7040406@oracle.com> <5797D144.20004@oracle.com> <57985B47.90002@oracle.com> <5798AA19.2020005@oracle.com> <5798EB5A.9050403@oracle.com> Message-ID: Alexander, the slider thumb is not scaled at all. --Semyon On 7/28/2016 7:45 PM, Alexandr Scherbatiy wrote: > > Hello, > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8160986/webrev.02 > > - html part of the test is removed > > On 7/27/2016 8:11 PM, Phil Race wrote: >> > D3D on: 20468 [1] -> 21486 [2] performance increasing: 5% >> If I recall correctly, the SwingMark summary score is actually >> the run time .. so an increasing number is actually a decrease in >> peformance. > Sorry. The performance is definitely is decreased after the fix. > > Thanks, > Alexandr. >> >> Still, the improvement in the visual results is worth it to me. >> >> The test is still odd and I am not sure what the intent is. >> If its an applet test then the @test tag should be on the .html file. >> The @bug tag in the Java file is 8040279 which is unrelated to this >> issue. >> But it looks like its just a way to display some instructions to run >> SwingSet2. >> I am not sure that it is at all worth adding something like that as a >> test. >> >> -phil >> >> >> >> On 07/27/2016 09:49 AM, Alexandr Scherbatiy wrote: >>> Hello, >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8160986/webrev.01 >>> >>> - horizontal scroll bars are updated >>> - the test name is updated >>> - the instruction to test both vertical and horizontal scroll bars >>> are added to the test >>> >>> I run the SwingMark for the JRadioButton which is painted with >>> selected/deselected and enabled states >>> and JScrollPane which shows vertical and horizontal scroll bars in >>> turn. >>> Each component was repainted 2002 times and the test was repeated 20 >>> times. >>> >>> The results below show the SwingMark tests score for D3D on/off in >>> format: >>> test score for the component before the fix [link to the results] -> >>> test score for the component after the fix (using ovals or polygons) >>> [link to the results] performance increasing in percents. >>> >>> JRadioButton >>> D3D on: 20468 [1] -> 21486 [2] performance increasing: 5% >>> D3D off: 20299 [3] -> 21075 [4] performance increasing: 4% >>> >>> JScrollPane >>> D3D on: 56184 [5] -> 57742 [6] performance increasing: 3% >>> D3D off: 51758 [7] -> 52987 [8] performance increasing: 3% >>> >>> If it is necessary, polygons which draw triangles can be replaced by >>> Line2D.Float(). >>> >>> Thanks, >>> Alexandr. >>> >>> [1] >>> http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/radio-button-d3d-on-base.txt >>> [2] >>> http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/radio-button-d3d-on-oval.txt >>> [3] >>> http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/radio-button-d3d-off-base.txt >>> [4] >>> http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/radio-button-d3d-off-oval.txt >>> >>> [5] >>> http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/scroll-pane-d3d-on-base.txt >>> [6] >>> http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/scroll-pane-d3d-on-polygon.txt >>> [7] >>> http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/scroll-pane-d3d-off-base.txt >>> [8] >>> http://cr.openjdk.java.net/~alexsch/8160986/swingmark/00/scroll-pane-d3d-off-polygon.txt >>> >>> On 7/27/2016 3:33 PM, Philip Race wrote: >>>> BTW I meant to point out (but forgot) that I want us >>>> to stop using bug ids as test names. When you stare >>>> at a list of tests in a directory I'd like to see meaningful names. >>>> >>>> I don't know what the intention was with the tests here but >>>> any new test should be so named .. >>>> >>>> -phil. >>>> >>>> On 7/26/16, 11:57 PM, Yuri Nesterenko wrote: >>>>> You mean probably that the first test would not compile since >>>>> it is "public class bug8160986 " in bug8031573.java ?:-) >>>>> >>>>> -yan >>>>> >>>>> On 07/27/2016 12:08 AM, Phil Race wrote: >>>>>> Since I noticed it right away, I am sure lots of others will soon >>>>>> enough. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 07/25/2016 02:19 PM, Sergey Bylokhov wrote: >>>>>>> On 07.07.16 22:00, Phil Race wrote: >>>>>>>> the screenshot here bears that out .. ie left/right do not look >>>>>>>> to be >>>>>>>> any better. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~alexsch/8160986/screenshots/scrollpane-00.png >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Since it was missed by the author, I am not sure that it will be >>>>>>> found >>>>>>> by the tester who will run the test. >>>>>>> >>>>>>>> On 07/07/2016 11:55 AM, Alexandr Scherbatiy wrote: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Could you review the fix: >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160986 >>>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8160986/webrev.00 >>>>>>>>> >>>>>>>>> The proposed fix changes icon shapes drawn by lines to ovals >>>>>>>>> and >>>>>>>>> polygons for JRadioButton, JComboBox and JScrollBar components >>>>>>>>> for the >>>>>>>>> Metal L&F. >>>>>>>>> >>>>>>>>> The screenshots [1] give a hint how UI controls look before and >>>>>>>>> after the fix. >>>>>>>>> >>>>>>>>> [1] http://cr.openjdk.java.net/~alexsch/8160986/screenshots >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>> >> > From peter.brunet at oracle.com Fri Jul 29 19:14:42 2016 From: peter.brunet at oracle.com (Pete Brunet) Date: Fri, 29 Jul 2016 14:14:42 -0500 Subject: RfR JDK-8161483 Implement AccessibleAction interface in JList.AccessibleJList.AccessibleJListChild In-Reply-To: <3568fe5e-5eb4-a5d8-7658-421bc73103de@oracle.com> References: <7a429ccd-f0d0-f403-08f0-bb42a1953a4b@oracle.com> <291686a7-8c0e-48a8-d894-69bc7dea4bba@oracle.com> <3568fe5e-5eb4-a5d8-7658-421bc73103de@oracle.com> Message-ID: <60010bfc-1e84-2186-1297-41af86e1b245@oracle.com> JPRT jobs ran OK. On 7/19/16 1:43 PM, Alexandr Scherbatiy wrote: > The fix looks good to me. > > Thanks, > Alexandr. > > On 7/19/2016 8:50 PM, Pete Brunet wrote: >> Look at .02 instead. I had an extraneous println left in .01. >> http://cr.openjdk.java.net/~ptbrunet/JDK-8161483/webrev.02/ >> >> On 7/19/16 11:48 AM, Pete Brunet wrote: >>> I added a regression test: >>> http://cr.openjdk.java.net/~ptbrunet/JDK-8161483/webrev.01/ >>> >>> Could someone please review that? >>> >>> I also need one more +1 on the code change. >>> >>> TiA, Pete >>> >>> On 7/19/16 3:17 AM, Alexandr Scherbatiy wrote: >>>> >>>> The fix looks good to me. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 7/19/2016 5:10 AM, Pete Brunet wrote: >>>>> Please review the following: >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161483 >>>>> Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8161483/webrev.00/ >>>>> >>>>> This is a followon to the patch for >>>>> JDK-8145207 [macosx] JList, VO can't access non-visible list items >>>>> >>>>> In order to fixJDK-8145207the AccessibleAction interface was >>>>> needed for JList.AccessibleJList.AccessibleJListChild but a >>>>> backport of this fix has been requested and the released public >>>>> API can not be changed in 8u or earlier. The workaround for >>>>> JDK-8145207 is to create and use a private subclass of >>>>> JList.AccessibleJList.AccessibleJListChild, >>>>> JList.AccessibleJList.ActionableAccessibleJListChild. The >>>>> downside of this fix is that it returns a subclass of the >>>>> JList.AccessibleJList.AccessibleJListChild. If a user overrides >>>>> the class and returns from its code it will not inherit the >>>>> AccessibleAction behavior. For JDK 9 the >>>>> ActionableAccessibleJListChild subclass should be removed and the >>>>> AccessibleAction implementation moved to >>>>> JList.AccessibleJList.AccessibleJListChild. >>>>> >>>>> TiA, >>>>> Pete >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: