From philip.race at oracle.com Wed Mar 1 03:44:27 2017 From: philip.race at oracle.com (Philip Race) Date: Wed, 01 Mar 2017 09:14:27 +0530 Subject: RFR: 8175831 : Provide a javadoc description for jdk.accessibility module Message-ID: <58B6439B.7000500@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8175831 webrev: http://cr.openjdk.java.net/~prr/8175831/ Adds missing javadoc description. I observed that javadoc is not actually generated for this module and makefiles needed to be updated and made such changes to test it but the javadoc folks tell me that I should not push those as there are changes afoot that will automate this without needing to add per-module make targets. -phil. From sergey.bylokhov at oracle.com Wed Mar 1 09:18:41 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 1 Mar 2017 12:18:41 +0300 Subject: RFR: 8175831 : Provide a javadoc description for jdk.accessibility module In-Reply-To: <58B6439B.7000500@oracle.com> References: <58B6439B.7000500@oracle.com> Message-ID: <11F2D972-443C-404E-A8F1-BEB661F1CEE5@oracle.com> Looks fine. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8175831 > webrev: http://cr.openjdk.java.net/~prr/8175831/ > > Adds missing javadoc description. > I observed that javadoc is not actually generated for this module > and makefiles needed to be updated and made such changes to test it > but the javadoc folks tell me that I should not push those as there are changes afoot > that will automate this without needing to add per-module make targets. > > -phil. From alexander.zvegintsev at oracle.com Wed Mar 1 14:30:33 2017 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 1 Mar 2017 17:30:33 +0300 Subject: RFR: 8175831 : Provide a javadoc description for jdk.accessibility module In-Reply-To: <58B6439B.7000500@oracle.com> References: <58B6439B.7000500@oracle.com> Message-ID: <0cef78d4-e71b-bcad-fce7-db5de40c2bd9@oracle.com> +1 -- Thanks, Alexander. On 01.03.2017 6:44, Philip Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8175831 > webrev: http://cr.openjdk.java.net/~prr/8175831/ > > Adds missing javadoc description. > I observed that javadoc is not actually generated for this module > and makefiles needed to be updated and made such changes to test it > but the javadoc folks tell me that I should not push those as there > are changes afoot > that will automate this without needing to add per-module make targets. > > -phil. From sergey.bylokhov at oracle.com Wed Mar 1 18:20:55 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 1 Mar 2017 21:20:55 +0300 Subject: [9] Review request for 8171808: Performance problems in dialogs with large tables when JAB activated In-Reply-To: <2239d87a-c7e6-4a22-6b83-2e4d568e640e@oracle.com> References: <59c9c1b0-7ee5-3c3b-2916-22dc2e9b7e5d@oracle.com> <19bd5e16-2737-5842-716a-a67ca207849f@oracle.com> <86743D1E-C2D9-4015-B63E-1080B22C3D25@oracle.com> <2239d87a-c7e6-4a22-6b83-2e4d568e640e@oracle.com> Message-ID: <6AED46D2-5ED3-4EB8-AC19-A6555C9941A5@oracle.com> Looks fine. > 28 ????. 2017 ?., ? 17:40, Mikhail Cherkasov ???????(?): > > Hi Sergey, Alexander, > > I have to revert the fix back to first version: http://cr.openjdk.java.net/~mcherkas/8171808/9/webrev.03/ > because invokeAndWait has side affect and needs to be called on all components separately, otherwise runtime exceptions can be occurred. > > Thanks, > Mikhail. > > > On 2/27/2017 8:13 PM, Sergey Bylokhov wrote: >> Ok, Looks fine. >> >>> Hi again, >>> with this implementation I see a runtime exception, I see it in AccessBridge. getAccessibleNameFromContext. >>> InvocationUtils.invokeAndWait can't obtain AppContext. I don't see how it relates to my changes, but without >>> my changes it works fine, also it works fine with first version of the fix. >>> >>> Thanks, >>> Mikhail. >>> >>> On 2/27/2017 3:49 PM, Mikhail Cherkasov wrote: >>>> Hi Sergey, >>>> >>>> http://cr.openjdk.java.net/~mcherkas/8171808/9/webrev.02/ >>>> I wrapped the very fist invocations of _getVisibleChildrenCount and _getVisibleChild into InvocationUtils.invokeAndWait >>>> and removed all InvocationUtils.invokeAndWait inside those two methods. >>>> >>>> Thanks, >>>> Mikhail. >>>> >>>> On 2/24/2017 1:08 AM, Sergey Bylokhov wrote: >>>>> Hi, Mikhail >>>>> Why we call invokeAndWait() so many times in the new method? >>>>> I guess we can do some work on EDT in one step then we will speedup the code when the size of the table is huge and it has lots of visible items. >>>>> >>>>>> Hi all, >>>>>> >>>>>> Could you please review the fix: >>>>>> http://cr.openjdk.java.net/~mcherkas/8171808/9/webrev.01/ >>>>>> for the following issue: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8171808 >>>>>> >>>>>> When JAWS asks java how many visible elements in the frame are, >>>>>> java goes through the whole tree of component and asks each whether it visible or not. >>>>>> During this java creates accessContext for each element, so this requires to get data from model. >>>>>> So if user uses lazy loading or model is large, this counting makes app to freeze. >>>>>> >>>>>> I reduced the number of components that should be checked for visibility, >>>>>> if we get to a row that is invisible, there's no sense to check next rows, the same for columns. >>>>>> >>>>>> Thanks, >>>>>> Mikhail. > From sergey.bylokhov at oracle.com Wed Mar 1 18:37:37 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 1 Mar 2017 21:37:37 +0300 Subject: [9] Review Request: 8176046 Replace package.html files with package-info.java in the java.desktop module Message-ID: Hello, Please review the fix for jdk9. This is the last request which covers all packages in java.desktop(except javax.swing and java.awt which were covered earlier) - All "package.html" files were replaced by "package-info.java", even for internal packages like eawt. - All were replaced by {@tag }. - All files were manually reformatted - 80 chars per line. - TM was replaced by ™ This is why the specdiff contains some diffs. Bug: https://bugs.openjdk.java.net/browse/JDK-8176046 Webrev can be found at: http://cr.openjdk.java.net/~serb/8176046/webrev.00/ Specdiff: http://cr.openjdk.java.net/~serb/8176046/specdiff/overview-summary.html From alexandr.scherbatiy at oracle.com Thu Mar 2 09:14:56 2017 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 2 Mar 2017 12:14:56 +0300 Subject: [9] Review request for 8171808: Performance problems in dialogs with large tables when JAB activated In-Reply-To: <6AED46D2-5ED3-4EB8-AC19-A6555C9941A5@oracle.com> References: <59c9c1b0-7ee5-3c3b-2916-22dc2e9b7e5d@oracle.com> <19bd5e16-2737-5842-716a-a67ca207849f@oracle.com> <86743D1E-C2D9-4015-B63E-1080B22C3D25@oracle.com> <2239d87a-c7e6-4a22-6b83-2e4d568e640e@oracle.com> <6AED46D2-5ED3-4EB8-AC19-A6555C9941A5@oracle.com> Message-ID: <34105033-19d8-7427-9898-dcf0049e23fa@oracle.com> The fix looks good to me. Thanks, Alexandr. On 3/1/2017 9:20 PM, Sergey Bylokhov wrote: > Looks fine. > >> 28 ????. 2017 ?., ? 17:40, Mikhail Cherkasov ???????(?): >> >> Hi Sergey, Alexander, >> >> I have to revert the fix back to first version: http://cr.openjdk.java.net/~mcherkas/8171808/9/webrev.03/ >> because invokeAndWait has side affect and needs to be called on all components separately, otherwise runtime exceptions can be occurred. >> >> Thanks, >> Mikhail. >> >> >> On 2/27/2017 8:13 PM, Sergey Bylokhov wrote: >>> Ok, Looks fine. >>> >>>> Hi again, >>>> with this implementation I see a runtime exception, I see it in AccessBridge. getAccessibleNameFromContext. >>>> InvocationUtils.invokeAndWait can't obtain AppContext. I don't see how it relates to my changes, but without >>>> my changes it works fine, also it works fine with first version of the fix. >>>> >>>> Thanks, >>>> Mikhail. >>>> >>>> On 2/27/2017 3:49 PM, Mikhail Cherkasov wrote: >>>>> Hi Sergey, >>>>> >>>>> http://cr.openjdk.java.net/~mcherkas/8171808/9/webrev.02/ >>>>> I wrapped the very fist invocations of _getVisibleChildrenCount and _getVisibleChild into InvocationUtils.invokeAndWait >>>>> and removed all InvocationUtils.invokeAndWait inside those two methods. >>>>> >>>>> Thanks, >>>>> Mikhail. >>>>> >>>>> On 2/24/2017 1:08 AM, Sergey Bylokhov wrote: >>>>>> Hi, Mikhail >>>>>> Why we call invokeAndWait() so many times in the new method? >>>>>> I guess we can do some work on EDT in one step then we will speedup the code when the size of the table is huge and it has lots of visible items. >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Could you please review the fix: >>>>>>> http://cr.openjdk.java.net/~mcherkas/8171808/9/webrev.01/ >>>>>>> for the following issue: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8171808 >>>>>>> >>>>>>> When JAWS asks java how many visible elements in the frame are, >>>>>>> java goes through the whole tree of component and asks each whether it visible or not. >>>>>>> During this java creates accessContext for each element, so this requires to get data from model. >>>>>>> So if user uses lazy loading or model is large, this counting makes app to freeze. >>>>>>> >>>>>>> I reduced the number of components that should be checked for visibility, >>>>>>> if we get to a row that is invisible, there's no sense to check next rows, the same for columns. >>>>>>> >>>>>>> Thanks, >>>>>>> Mikhail. From sergey.bylokhov at oracle.com Thu Mar 2 18:27:59 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 2 Mar 2017 21:27:59 +0300 Subject: [9] Review Request: 8158209 Editing in TableView breaks the layout, when the document is I18n In-Reply-To: <79BB4BD6-BC56-432C-91A6-753AF3FE04C3@oracle.com> References: <79BB4BD6-BC56-432C-91A6-753AF3FE04C3@oracle.com> Message-ID: Hello, Webrev[1] for the bug[2] is updated and placed to the CR.openjdk: [1]The bug: http://cr.openjdk.java.net/~serb/8158209/webrev.00 [2] webrev: http://cr.openjdk.java.net/~serb/8158209/webrev.00 > 27 ????. 2017 ?., ? 20:18, Sergey Bylokhov ???????(?): > > Hi. > > Your evaluation and the fix seems reasonable. > If you already signed the OCA[1] then I can place your webrev to the cr.openjdk for official review request.. > > [1] http://www.oracle.com/technetwork/community/oca-486395.html > > >> 26 ????. 2017 ?., ? 13:03, Abossolo Foh Guy ???????(?): >> >> Hello, >> I insist. >> I know there will be hard stress and busy days until next release but could someone examins my patch and its test ? >> Please. >> Best regards. >> >> With JDK9 build 158 : >> When i18n enable, TableView layout wrong : Table width change when inserts and removes caracters, see JDK-8158209 and JDK-7169915. Before Table dx=0.0 After Table dx=28.0 >> When i18n disable, TableView layout wrong : Table width change when inserts and removes caracters, see JDK-8158209 and JDK-7169915. Before Table dx=0.0 After Table dx=28.0 >> >> -------- Message original -------- >> Objet: Re: [PATCH] JDK-7169915 : Swing Table Layout bad repaint of the row [REGRESSION] JDK-8133864 : Wrong display, when the document I18n properties is true. >> Date: 2016-11-05 6:59 >> De: Abossolo Foh Guy >> ?: Semyon Sadetsky >> >> Hello, >> >> I modified your test(test/javax/swing/text/TableView/I18nLayoutTest.java) to simulate user entries and removals as discribed in my bug reports JDK-7169915 and JDK-7072926. >> >> Rather than test the frame, I used four caret positions : one before, one after the table, one in the first and one in the last line of the table. >> I also test i18n enable and i18n disable. >> >> I think this test could replace the previous test I18nLayoutTest.java. >> >> The test fails before and passes after my fix : >> >> With JDK 8 current release (111) : >> When i18n enable, test can't be completed : TableView layout wrong, lines overlap, see JDK-8133864. >> When i18n disable, TableView layout wrong : Table width change when inserts and removes caracters, see JDK-8158209 and JDK-7169915. Before Table dx=0.0 After Table dx=28.0 >> >> With JDK9 build 142 : >> When i18n enable, TableView layout wrong : Table width change when inserts and removes caracters, see JDK-8158209 and JDK-7169915. Before Table dx=0.0 After Table dx=28.0 >> When i18n disable, TableView layout wrong : Table width change when inserts and removes caracters, see JDK-8158209 and JDK-7169915. Before Table dx=0.0 After Table dx=28.0 >> >> With JDK9 + fix : >> ok >> >> I used the latest JDK forest to build the fix and produce webrev. >> >> This bug occurs only for user keyboard entries, if I use JEditorPane.replaceSelection(...) the table layout is correct. >> >> Best regards. >> Guy. >> >> --------------------------------------------------------------------------------------------------- >> >> Le 2016-09-12 15:39, Semyon Sadetsky a ?crit : >>> Hello, >>> The JDK-8133864 seems has no a regression. I found that your test >>> works well after it (with corrections I described in JIRA for the >>> table frame). >>> If TableView layout is still an incorrect for you, please, attach a >>> test that fails before and passes after your fix. Test is required for >>> any JDK fixes and I didn't find in your webrev. >>> --Semyon >>> On 9/11/2016 11:34 AM, Abossolo Foh Guy wrote: >>>> Hi, >>>> Thank you very much for your great work. >>>> But I'm agree and not agree with your conclusion about JDK-8158209 : "Not an Issue". >>>> I'm agree : >>>> I understand your recommendations about the height and the width for the frame of the trView. >>>> I never talked about this problem because frame painting hasn't being a problem for me. >>>> I'm not agree : >>>> I made a mistake in writing the bug JDK-8158209 report : two problems in the same report. >>>> But JDK-7169915 and JDK-7072926 are really a different problem you solve in JDK-8158209. >>>> In 2012, codebug.java was designed first for these bugs. >>>> It is just an update problem, if you follow the steps discribe in JDK-7169915 and JDK-7072926 and if you read the text\html\tableView code you can understand my fix. >>>> text\html\tableView works (not public) fine and \text\tableView (public) works bad ? ? ? ? >>>> As Victor, don't worry about this fix, I'd just compare the two codes to built my fix. >>>> In attachment the documents asked by Alexandr about my fix. >>>> Yours faithfully. >>>> --------------------------------------- >>>> Hello, >>>>> Could you apply the fix to JDK 9 client repository ... >>>> I applied the fix to JDK 9 client repository http://hg.openjdk.java.net/jdk9/client : >>>> openjdk version "9-internal" >>>> OpenJDK Runtime Environment (build 9-internal+0-2016-05-28-142420.scientificware2016.9devClient) >>>> OpenJDK 64-Bit Server VM (build 9-internal+0-2016-05-28-142420.scientificware2016.9devClient, mixed mode) >>>> The webrev and JTreport/JTWork are in attachment. All works fine, except what is mentioned below. >>>>> You mentioned that there are artifacts with a table displaying in JDK 9. >>>> I can't say when it appeared because before your fix, the table size didn't changed when we insert text and all the text stay on the same line. >>>> But, I have just notice that if, in the I18nLayoutTest.java, you >>>> - change the line setUndecorated(true) to setUndecorated(false), >>>> - run the program and enlarge the window 2 times larger than the text size, >>>> - all the text come back on the same line. >>>> There no such artifacts when i18n is false. >>>> Thanks for your help. >>>> Guy. >>>> --------------------------------------------------------------------------------------------- Le 2016-05-27 16:53, Alexandr Scherbatiy a ?crit : >>>>> The fix should be prepared for the JDK 9 first and only after that be >>>>> backported to JDK 8u. >>>>> Could you apply the fix to JDK 9 client repository >>>>> http://hg.openjdk.java.net/jdk9/client >>>>> and send the webrev of the fix plus the test (see >>>>> http://openjdk.java.net/guide/webrevHelp.html). >>>>> The fix shouldn't contain comments with the old code lines. I believe >>>>> that references to the bug number are also unnecessary for this case. >>>>> You mentioned that there are artifacts with a table displaying in JDK >>>>> 9. Do they appear only after fix of they also present even without the >>>>> fix? >>>>> Thanks, >>>>> Alexandr. >>>>> On 5/27/2016 9:23 AM, Abossolo Foh Guy wrote: >>>>>> Hello, >>>>>> Please, please ... could someone examine the patch for JDK-8133864 that I suggested ? I really need it to implement matrix display in my application. I've spent long time in 2012 to find what was wrong in tableview. I know Victor's comment was not good but you could compare with the tableview implementation in the swing/text/html package which works fine. >>>>>> Beware, the display (with java 9 119) for I18nLayoutTest.java is not the same with i18n true (bad) or i18n false (good). With i18n true the table go down. >>>>>> Best regards. >>>>>> ---------------------------------------------------------------------------------------------------------------------- Hello, >>>>>> I built the recent OpenJDK8u and OpenJDK9 sources (openjdk_versions.txt) with the patch shown in the output_diff.txt attachment. >>>>>> I applied your patch for JDK-8133864 : Wrong display, when the document I18n properties is true. >>>>>> And I applied my patch for JDK-7169915 : Swing Table Layout bad repaint of the row. >>>>>> All works fine in OpenJDK8u and the document is well displayed. The table appears as I expected with all its lines and columns (JDK-8133864 solved), size and borders included even if we write some text inside (JDK-7169915 solved). I can modify it as I want. >>>>>> But with OpenJDK9, the display of the document is wrong. The table appears as I expected with all its lines and columns (JDK-8133864 solved), size and borders included (JDK-7169915 solved) but the entire document display is modified, the table is displayed on a new line. And the document became unuseable, I can't modify it as I want. >>>>>> This morning, I ran the same test programme (CodeBug.java in attachment) with the Oracle JDK9 b114 (i.e. OpenJDK9 only with your patch for JDK-8133864) : The table appears as I expected with all its lines and columns (JDK-8133864 solved) but the size and borders are bad repainted when we write some text inside (JDK-7169915 solved). And the document became unuseable too, I can't modify it as I want. >>>>>> My conclusion : >>>>>> 1- JDK-8133864 is solved with your PATCH. >>>>>> 2- JDK-7169915 could be solved with my PATCH. >>>>>> 3- There is regression between JDK8 and JDK9 may be in the Views arrangement. >>>>>> Best regards. >>>>>> ---------------------------------------------------------------------------------------------------------------------- Hello, >>>>>> Could you apply the modification I suggested 4 years ago about the Bug : JDK-7169915 : Swing Table Layout bad repaint of the row. >>>>>> The test case I had sent in 2012 is the same I used in : JDK-8133864 Wrong display, when the document I18n properties is true. >>>>>> A version of this test (called I18nLayoutTest.java) is now candidate as part of tests for JDK 9 (/test/javax/swing/text/TableView/) >>>>>> Yours faithfully. >> >> -- >> Abossolo Foh Guy >> 71 rue Guy de Maupassant >> 69500 Bron >> >> 06 87 01 82 27 >> 04 72 81 89 46 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Fri Mar 3 16:15:42 2017 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Fri, 3 Mar 2017 19:15:42 +0300 Subject: [9] Review Request: 8176046 Replace package.html files with package-info.java in the java.desktop module In-Reply-To: References: Message-ID: <3df4087c-7290-5e55-236a-5707ac50be50@oracle.com> The fix looks good to me. Thanks, Alexandr. On 3/1/2017 9:37 PM, Sergey Bylokhov wrote: > Hello, > Please review the fix for jdk9. This is the last request which covers all packages in java.desktop(except javax.swing and java.awt which were covered earlier) > - All "package.html" files were replaced by "package-info.java", even for internal packages like eawt. > - All were replaced by {@tag }. > - All files were manually reformatted - 80 chars per line. > - TM was replaced by ™ This is why the specdiff contains some diffs. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8176046 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8176046/webrev.00/ > Specdiff: http://cr.openjdk.java.net/~serb/8176046/specdiff/overview-summary.html From alexandr.scherbatiy at oracle.com Fri Mar 3 17:55:28 2017 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Fri, 3 Mar 2017 20:55:28 +0300 Subject: Review request for JDK-6490753 JComboBox doesn't look as native combobox in different states of component In-Reply-To: References: <90cb4507-2996-931a-1ec7-1f92e81545fe@oracle.com> Message-ID: <1429f917-4312-1c09-3f66-853650bb50b0@oracle.com> I have uploaded the webrev to the http://cr.openjdk.java.net: http://cr.openjdk.java.net/~alexsch/mraz.martin/6490753/webrev.01 Thanks, Alexandr. On 2/17/2017 2:41 PM, Martin M wrote: > AnimationController.java > 386 if (skin.haveToSwitchStates()) { > 387 skin.paintSkinRaw(g, dx, dy, dw, dh, state); > 388 g.setComposite(AlphaComposite.SrcOver.derive(1 - progress)); > 389 skin.paintSkinRaw(g, dx, dy, dw, dh, startState); > 390 } else { > > - Could the '1 - progress' value in AlphaComposite.SrcOver.derive(1 - > progress) be out of range? > > Value 'progress' is checked in method 'private void updateProgress()' > so it always is between 0 and 1. > > > WindowsComboBoxUI.java > 221 if (this.borderChecked == false) // check border of > component > 222 replaceBorder(); > > It is better to use 'if (!this.borderChecked) {replaceBorder();}'. > There are Java Style Guidelines [1] which we need to follow to. > > I removed this part and replaced it with one line into method 'public > void installUI( JComponent c )'. It has the same effect. > WindowsComboBoxUI.java > 159 // set empty border as default to see vista animated border > 160 comboBox.setBorder(new EmptyBorder(0,0,0,0)); > > > 454 if (comboBox.isPopupVisible()) > 455 getModel().setPressed(true); > 456 else > 457 getModel().setPressed(false); > > This can be simplified to > getModel().setPressed(comboBox.isPopupVisible()). > > Corrected. this was lame :( > > > 508 @Deprecated > 509 @SuppressWarnings("serial") // Superclass is not serializable > across versions > 510 protected class WindowsComboPopup extends BasicComboPopup { > 511 > 512 private class comboPopUpBorder extends EmptyBorder { > > The class WindowsComboPopup is marked as deprecated with comments '* > This class is now obsolete and doesn't do anything.' > Is it possible to move the popup border class outside and do not use > the WindowsComboPopup at all? > The comboPopUpBorder class name should start from capital char. > > I removed comboPopUpBorder class because painting of this border was > hardcoded and it looked the same in win7 and win10. > The border is now painted with system skin and looks properly in both > windows versions. > And I am not sure if it is ok, but I created new class WinComboPopUp > which extends BasicComboPopup > to avoid using deprecated WindowsComboPopup. But deprecated class > also extends BasicComboPopup. So.... > > > 566 Border border = (Border)UIManager.get("ComboBox.editorBorder"); > 567 > 568 // correct space on the left side of text (for > editable combobox) > 569 Insets i = border.getBorderInsets(editor); > 570 border = BorderFactory.createEmptyBorder(i.top, 4, > i.bottom, i.right); > 571 > 572 if (border != null) { > 573 editor.setBorder(border); > 574 } > > - The border.getBorderInsets(editor) is called before checking the > border to null. > - It seems that if a user sets a custom "ComboBox.editorBorder" it > should not be changed. > Is it possible just to update the dafult "ComboBox.editorBorder" in > the com.sun.java.swing.plaf.windows.WindowsLookAndFeel class? > > I updated default ComboBox.editorBorder. > > > XPStyle.java > 517 public boolean haveToSwitchStates() { > 518 return switchStates; > 519 } > 520 > 521 public void switchStates(boolean b) { > 522 switchStates = b; > 523 } > > Could you change the methods access from the public to package? Making > some API public, even in com.sun.* package may require some additional > process. > > I changed access modifier from public to package. > > And I also decreased shifting of list items to right from 3px to 2px. > If I see correctly native comboBox items have 2 px intendation from > left side of the border, when system font is used. > WindowsComboBoxUI.java > 600 return new Insets(0,2,0,0); (previous value was 3) > 609 setBorder(new EmptyBorder(0, 2, 0, i.right)); (previous value was > 3 as well) > > br > Martin > > > > 2017-02-03 13:31 GMT+01:00 Alexandr Scherbatiy > >: > > On 2/1/2017 3:41 PM, Martin M wrote: >> bug: https://bugs.openjdk.java.net/browse/JDK-6490753 >> >> webrev: >> http://cr.openjdk.java.net/~alexsch/mraz.martin/6490753/webrev.00 >> >> >> Problem description: >> Swing JComboBox looks different than native one in states like >> e.g. focused state or mouse rollover state and so on. >> >> The fix solves following issues: >> - Editable combobox border is regular dark rectangle in all >> states now. After the fix border will have light gray color in >> normal state, light blue in rollover or hot state and dark blue >> in pressed or focused state. >> - Editable combobox button is painted almost properly, but not >> animated as it should be. The fix will correct animation of the >> button. >> - popup with list of choices has black border. The fix will >> correct the border to proper colors. >> - All texts were rendered very close to left side of borders. The >> fix shifts texts few screen points to the left. > > AnimationController.java > 386 if (skin.haveToSwitchStates()) { > 387 skin.paintSkinRaw(g, dx, dy, dw, dh, state); > 388 > g.setComposite(AlphaComposite.SrcOver.derive(1 - progress)); > 389 skin.paintSkinRaw(g, dx, dy, dw, dh, > startState); > 390 } else { > > - Could the '1 - progress' value in > AlphaComposite.SrcOver.derive(1 - progress) be out of range? > > WindowsComboBoxUI.java > 221 if (this.borderChecked == false) // check border > of component > 222 replaceBorder(); > > It is better to use 'if (!this.borderChecked) {replaceBorder();}'. > There are Java Style Guidelines [1] which we need to follow to. > > > 454 if (comboBox.isPopupVisible()) > 455 getModel().setPressed(true); > 456 else > 457 getModel().setPressed(false); > > This can be simplified to > getModel().setPressed(comboBox.isPopupVisible()). > > > 508 @Deprecated > 509 @SuppressWarnings("serial") // Superclass is not > serializable across versions > 510 protected class WindowsComboPopup extends BasicComboPopup { > 511 > 512 private class comboPopUpBorder extends EmptyBorder { > > The class WindowsComboPopup is marked as deprecated with comments > '* This class is now obsolete and doesn't do anything.' > Is it possible to move the popup border class outside and do not > use the WindowsComboPopup at all? > The comboPopUpBorder class name should start from capital char. > > > 566 Border border = > (Border)UIManager.get("ComboBox.editorBorder"); > 567 > 568 // correct space on the left side of text (for > editable combobox) > 569 Insets i = border.getBorderInsets(editor); > 570 border = BorderFactory.createEmptyBorder(i.top, > 4, i.bottom, i.right); > 571 > 572 if (border != null) { > 573 editor.setBorder(border); > 574 } > > - The border.getBorderInsets(editor) is called before checking the > border to null. > - It seems that if a user sets a custom "ComboBox.editorBorder" it > should not be changed. > Is it possible just to update the dafult "ComboBox.editorBorder" > in the com.sun.java.swing.plaf.windows.WindowsLookAndFeel class? > > > XPStyle.java > 517 public boolean haveToSwitchStates() { > 518 return switchStates; > 519 } > 520 > 521 public void switchStates(boolean b) { > 522 switchStates = b; > 523 } > > Could you change the methods access from the public to package? > Making some API public, even in com.sun.* package may require some > additional process. > > [1] http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html > > > Thanks, > Alexandr. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.bylokhov at oracle.com Sun Mar 5 18:04:22 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Sun, 5 Mar 2017 21:04:22 +0300 Subject: [9] Review Request: 8158209 Editing in TableView breaks the layout, when the document is I18n In-Reply-To: References: <79BB4BD6-BC56-432C-91A6-753AF3FE04C3@oracle.com> Message-ID: <95AABC40-D06A-49E2-A027-350E1A225119@oracle.com> Hello. I have run the jck and jtreg tests and seems no new issues are found, so the fix looks fine to me. > > Hello, > Webrev[1] for the bug[2] is updated and placed to the CR.openjdk: > [1]The bug: http://cr.openjdk.java.net/~serb/8158209/webrev.00 > [2] webrev: http://cr.openjdk.java.net/~serb/8158209/webrev.00 > > >> 27 ????. 2017 ?., ? 20:18, Sergey Bylokhov > ???????(?): >> >> Hi. >> >> Your evaluation and the fix seems reasonable. >> If you already signed the OCA[1] then I can place your webrev to the cr.openjdk for official review request.. >> >> [1] http://www.oracle.com/technetwork/community/oca-486395.html >> >> >>> 26 ????. 2017 ?., ? 13:03, Abossolo Foh Guy > ???????(?): >>> >>> Hello, >>> I insist. >>> I know there will be hard stress and busy days until next release but could someone examins my patch and its test ? >>> Please. >>> Best regards. >>> >>> With JDK9 build 158 : >>> When i18n enable, TableView layout wrong : Table width change when inserts and removes caracters, see JDK-8158209 and JDK-7169915. Before Table dx=0.0 After Table dx=28.0 >>> When i18n disable, TableView layout wrong : Table width change when inserts and removes caracters, see JDK-8158209 and JDK-7169915. Before Table dx=0.0 After Table dx=28.0 >>> >>> -------- Message original -------- >>> Objet: Re: [PATCH] JDK-7169915 : Swing Table Layout bad repaint of the row [REGRESSION] JDK-8133864 : Wrong display, when the document I18n properties is true. >>> Date: 2016-11-05 6:59 >>> De: Abossolo Foh Guy > >>> ?: Semyon Sadetsky >>> >>> Hello, >>> >>> I modified your test(test/javax/swing/text/TableView/I18nLayoutTest.java) to simulate user entries and removals as discribed in my bug reports JDK-7169915 and JDK-7072926. >>> >>> Rather than test the frame, I used four caret positions : one before, one after the table, one in the first and one in the last line of the table. >>> I also test i18n enable and i18n disable. >>> >>> I think this test could replace the previous test I18nLayoutTest.java. >>> >>> The test fails before and passes after my fix : >>> >>> With JDK 8 current release (111) : >>> When i18n enable, test can't be completed : TableView layout wrong, lines overlap, see JDK-8133864. >>> When i18n disable, TableView layout wrong : Table width change when inserts and removes caracters, see JDK-8158209 and JDK-7169915. Before Table dx=0.0 After Table dx=28.0 >>> >>> With JDK9 build 142 : >>> When i18n enable, TableView layout wrong : Table width change when inserts and removes caracters, see JDK-8158209 and JDK-7169915. Before Table dx=0.0 After Table dx=28.0 >>> When i18n disable, TableView layout wrong : Table width change when inserts and removes caracters, see JDK-8158209 and JDK-7169915. Before Table dx=0.0 After Table dx=28.0 >>> >>> With JDK9 + fix : >>> ok >>> >>> I used the latest JDK forest to build the fix and produce webrev. >>> >>> This bug occurs only for user keyboard entries, if I use JEditorPane.replaceSelection(...) the table layout is correct. >>> >>> Best regards. >>> Guy. >>> >>> --------------------------------------------------------------------------------------------------- >>> >>> Le 2016-09-12 15:39, Semyon Sadetsky a ?crit : >>>> Hello, >>>> The JDK-8133864 seems has no a regression. I found that your test >>>> works well after it (with corrections I described in JIRA for the >>>> table frame). >>>> If TableView layout is still an incorrect for you, please, attach a >>>> test that fails before and passes after your fix. Test is required for >>>> any JDK fixes and I didn't find in your webrev. >>>> --Semyon >>>> On 9/11/2016 11:34 AM, Abossolo Foh Guy wrote: >>>>> Hi, >>>>> Thank you very much for your great work. >>>>> But I'm agree and not agree with your conclusion about JDK-8158209 : "Not an Issue". >>>>> I'm agree : >>>>> I understand your recommendations about the height and the width for the frame of the trView. >>>>> I never talked about this problem because frame painting hasn't being a problem for me. >>>>> I'm not agree : >>>>> I made a mistake in writing the bug JDK-8158209 report : two problems in the same report. >>>>> But JDK-7169915 and JDK-7072926 are really a different problem you solve in JDK-8158209. >>>>> In 2012, codebug.java was designed first for these bugs. >>>>> It is just an update problem, if you follow the steps discribe in JDK-7169915 and JDK-7072926 and if you read the text\html\tableView code you can understand my fix. >>>>> text\html\tableView works (not public) fine and \text\tableView (public) works bad ? ? ? ? >>>>> As Victor, don't worry about this fix, I'd just compare the two codes to built my fix. >>>>> In attachment the documents asked by Alexandr about my fix. >>>>> Yours faithfully. >>>>> --------------------------------------- >>>>> Hello, >>>>>> Could you apply the fix to JDK 9 client repository ... >>>>> I applied the fix to JDK 9 client repository http://hg.openjdk.java.net/jdk9/client : >>>>> openjdk version "9-internal" >>>>> OpenJDK Runtime Environment (build 9-internal+0-2016-05-28-142420.scientificware2016.9devClient) >>>>> OpenJDK 64-Bit Server VM (build 9-internal+0-2016-05-28-142420.scientificware2016.9devClient, mixed mode) >>>>> The webrev and JTreport/JTWork are in attachment. All works fine, except what is mentioned below. >>>>>> You mentioned that there are artifacts with a table displaying in JDK 9. >>>>> I can't say when it appeared because before your fix, the table size didn't changed when we insert text and all the text stay on the same line. >>>>> But, I have just notice that if, in the I18nLayoutTest.java, you >>>>> - change the line setUndecorated(true) to setUndecorated(false), >>>>> - run the program and enlarge the window 2 times larger than the text size, >>>>> - all the text come back on the same line. >>>>> There no such artifacts when i18n is false. >>>>> Thanks for your help. >>>>> Guy. >>>>> --------------------------------------------------------------------------------------------- Le 2016-05-27 16:53, Alexandr Scherbatiy a ?crit : >>>>>> The fix should be prepared for the JDK 9 first and only after that be >>>>>> backported to JDK 8u. >>>>>> Could you apply the fix to JDK 9 client repository >>>>>> http://hg.openjdk.java.net/jdk9/client >>>>>> and send the webrev of the fix plus the test (see >>>>>> http://openjdk.java.net/guide/webrevHelp.html). >>>>>> The fix shouldn't contain comments with the old code lines. I believe >>>>>> that references to the bug number are also unnecessary for this case. >>>>>> You mentioned that there are artifacts with a table displaying in JDK >>>>>> 9. Do they appear only after fix of they also present even without the >>>>>> fix? >>>>>> Thanks, >>>>>> Alexandr. >>>>>> On 5/27/2016 9:23 AM, Abossolo Foh Guy wrote: >>>>>>> Hello, >>>>>>> Please, please ... could someone examine the patch for JDK-8133864 that I suggested ? I really need it to implement matrix display in my application. I've spent long time in 2012 to find what was wrong in tableview. I know Victor's comment was not good but you could compare with the tableview implementation in the swing/text/html package which works fine. >>>>>>> Beware, the display (with java 9 119) for I18nLayoutTest.java is not the same with i18n true (bad) or i18n false (good). With i18n true the table go down. >>>>>>> Best regards. >>>>>>> ---------------------------------------------------------------------------------------------------------------------- Hello, >>>>>>> I built the recent OpenJDK8u and OpenJDK9 sources (openjdk_versions.txt) with the patch shown in the output_diff.txt attachment. >>>>>>> I applied your patch for JDK-8133864 : Wrong display, when the document I18n properties is true. >>>>>>> And I applied my patch for JDK-7169915 : Swing Table Layout bad repaint of the row. >>>>>>> All works fine in OpenJDK8u and the document is well displayed. The table appears as I expected with all its lines and columns (JDK-8133864 solved), size and borders included even if we write some text inside (JDK-7169915 solved). I can modify it as I want. >>>>>>> But with OpenJDK9, the display of the document is wrong. The table appears as I expected with all its lines and columns (JDK-8133864 solved), size and borders included (JDK-7169915 solved) but the entire document display is modified, the table is displayed on a new line. And the document became unuseable, I can't modify it as I want. >>>>>>> This morning, I ran the same test programme (CodeBug.java in attachment) with the Oracle JDK9 b114 (i.e. OpenJDK9 only with your patch for JDK-8133864) : The table appears as I expected with all its lines and columns (JDK-8133864 solved) but the size and borders are bad repainted when we write some text inside (JDK-7169915 solved). And the document became unuseable too, I can't modify it as I want. >>>>>>> My conclusion : >>>>>>> 1- JDK-8133864 is solved with your PATCH. >>>>>>> 2- JDK-7169915 could be solved with my PATCH. >>>>>>> 3- There is regression between JDK8 and JDK9 may be in the Views arrangement. >>>>>>> Best regards. >>>>>>> ---------------------------------------------------------------------------------------------------------------------- Hello, >>>>>>> Could you apply the modification I suggested 4 years ago about the Bug : JDK-7169915 : Swing Table Layout bad repaint of the row. >>>>>>> The test case I had sent in 2012 is the same I used in : JDK-8133864 Wrong display, when the document I18n properties is true. >>>>>>> A version of this test (called I18nLayoutTest.java) is now candidate as part of tests for JDK 9 (/test/javax/swing/text/TableView/) >>>>>>> Yours faithfully. >>> >>> -- >>> Abossolo Foh Guy >>> 71 rue Guy de Maupassant >>> 69500 Bron >>> >>> 06 87 01 82 27 >>> 04 72 81 89 46 >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Mon Mar 6 09:49:49 2017 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Mon, 6 Mar 2017 12:49:49 +0300 Subject: [9] Review Request: 8158209 Editing in TableView breaks the layout, when the document is I18n In-Reply-To: <95AABC40-D06A-49E2-A027-350E1A225119@oracle.com> References: <79BB4BD6-BC56-432C-91A6-753AF3FE04C3@oracle.com> <95AABC40-D06A-49E2-A027-350E1A225119@oracle.com> Message-ID: <928f3a66-62c5-cd37-175e-172bb7ae9e79@oracle.com> The fix looks good to me. It would be good to add the @Override annotation to the overridden methods in TableRow class before the push. Thanks, Alexandr. On 3/5/2017 9:04 PM, Sergey Bylokhov wrote: > Hello. > I have run the jck and jtreg tests and seems no new issues are found, > so the fix looks fine to me. > >> >> Hello, >> Webrev[1] for the bug[2] is updated and placed to the CR.openjdk: >> [1]The bug: http://cr.openjdk.java.net/~serb/8158209/webrev.00 >> >> [2] webrev: http://cr.openjdk.java.net/~serb/8158209/webrev.00 >> >> >> >>> 27 ????. 2017 ?., ? 20:18, Sergey Bylokhov >>> > >>> ???????(?): >>> >>> Hi. >>> >>> Your evaluation and the fix seems reasonable. >>> If you already signed the OCA[1] then I can place your webrev to the >>> cr.openjdk for official review request.. >>> >>> [1] http://www.oracle.com/technetwork/community/oca-486395.html >>> >>> >>>> 26 ????. 2017 ?., ? 13:03, Abossolo Foh Guy >>>> >>> > ???????(?): >>>> >>>> Hello, >>>> I insist. >>>> I know there will be hard stress and busy days until next release >>>> but could someone examins my patch and its test ? >>>> Please. >>>> Best regards. >>>> >>>> With JDK9 build 158 : >>>> When i18n enable, TableView layout wrong : Table width change when >>>> inserts and removes caracters, see JDK-8158209 and JDK-7169915. >>>> Before Table dx=0.0 After Table dx=28.0 >>>> When i18n disable, TableView layout wrong : Table width change when >>>> inserts and removes caracters, see JDK-8158209 and JDK-7169915. >>>> Before Table dx=0.0 After Table dx=28.0 >>>> >>>> -------- Message original -------- >>>> Objet: Re: [PATCH] JDK-7169915 : Swing Table Layout bad >>>> repaint of the row [REGRESSION] JDK-8133864 : Wrong display, when >>>> the document I18n properties is true. >>>> Date: 2016-11-05 6:59 >>>> De: Abossolo Foh Guy >>> > >>>> ?: Semyon Sadetsky >>>> >>>> Hello, >>>> >>>> I modified your >>>> test(test/javax/swing/text/TableView/I18nLayoutTest.java) to >>>> simulate user entries and removals as discribed in my bug reports >>>> JDK-7169915 and JDK-7072926. >>>> >>>> Rather than test the frame, I used four caret positions : one >>>> before, one after the table, one in the first and one in the last >>>> line of the table. >>>> I also test i18n enable and i18n disable. >>>> >>>> I think this test could replace the previous test I18nLayoutTest.java. >>>> >>>> The test fails before and passes after my fix : >>>> >>>> With JDK 8 current release (111) : >>>> When i18n enable, test can't be completed : TableView layout wrong, >>>> lines overlap, see JDK-8133864. >>>> When i18n disable, TableView layout wrong : Table width change when >>>> inserts and removes caracters, see JDK-8158209 and JDK-7169915. >>>> Before Table dx=0.0 After Table dx=28.0 >>>> >>>> With JDK9 build 142 : >>>> When i18n enable, TableView layout wrong : Table width change when >>>> inserts and removes caracters, see JDK-8158209 and JDK-7169915. >>>> Before Table dx=0.0 After Table dx=28.0 >>>> When i18n disable, TableView layout wrong : Table width change when >>>> inserts and removes caracters, see JDK-8158209 and JDK-7169915. >>>> Before Table dx=0.0 After Table dx=28.0 >>>> >>>> With JDK9 + fix : >>>> ok >>>> >>>> I used the latest JDK forest to build the fix and produce webrev. >>>> >>>> This bug occurs only for user keyboard entries, if I use >>>> JEditorPane.replaceSelection(...) the table layout is correct. >>>> >>>> Best regards. >>>> Guy. >>>> >>>> --------------------------------------------------------------------------------------------------- >>>> >>>> Le 2016-09-12 15:39, Semyon Sadetsky a ?crit : >>>>> Hello, >>>>> The JDK-8133864 seems has no a regression. I found that your test >>>>> works well after it (with corrections I described in JIRA for the >>>>> table frame). >>>>> If TableView layout is still an incorrect for you, please, attach a >>>>> test that fails before and passes after your fix. Test is required for >>>>> any JDK fixes and I didn't find in your webrev. >>>>> --Semyon >>>>> On 9/11/2016 11:34 AM, Abossolo Foh Guy wrote: >>>>>> Hi, >>>>>> Thank you very much for your great work. >>>>>> But I'm agree and not agree with your conclusion about >>>>>> JDK-8158209 : "Not an Issue". >>>>>> I'm agree : >>>>>> I understand your recommendations about the height and the width >>>>>> for the frame of the trView. >>>>>> I never talked about this problem because frame painting hasn't >>>>>> being a problem for me. >>>>>> I'm not agree : >>>>>> I made a mistake in writing the bug JDK-8158209 report : two >>>>>> problems in the same report. >>>>>> But JDK-7169915 and JDK-7072926 are really a different problem >>>>>> you solve in JDK-8158209. >>>>>> In 2012, codebug.java was designed first for these bugs. >>>>>> It is just an update problem, if you follow the steps discribe in >>>>>> JDK-7169915 and JDK-7072926 and if you read the >>>>>> text\html\tableView code you can understand my fix. >>>>>> text\html\tableView works (not public) fine and \text\tableView >>>>>> (public) works bad ? ? ? ? >>>>>> As Victor, don't worry about this fix, I'd just compare the two >>>>>> codes to built my fix. >>>>>> In attachment the documents asked by Alexandr about my fix. >>>>>> Yours faithfully. >>>>>> --------------------------------------- >>>>>> Hello, >>>>>>> Could you apply the fix to JDK 9 client repository ... >>>>>> I applied the fix to JDK 9 client repository >>>>>> http://hg.openjdk.java.net/jdk9/client : >>>>>> openjdk version "9-internal" >>>>>> OpenJDK Runtime Environment (build >>>>>> 9-internal+0-2016-05-28-142420.scientificware2016.9devClient) >>>>>> OpenJDK 64-Bit Server VM (build >>>>>> 9-internal+0-2016-05-28-142420.scientificware2016.9devClient, >>>>>> mixed mode) >>>>>> The webrev and JTreport/JTWork are in attachment. All works fine, >>>>>> except what is mentioned below. >>>>>>> You mentioned that there are artifacts with a table displaying >>>>>>> in JDK 9. >>>>>> I can't say when it appeared because before your fix, the table >>>>>> size didn't changed when we insert text and all the text stay on >>>>>> the same line. >>>>>> But, I have just notice that if, in the I18nLayoutTest.java, you >>>>>> - change the line setUndecorated(true) to setUndecorated(false), >>>>>> - run the program and enlarge the window 2 times larger than the >>>>>> text size, >>>>>> - all the text come back on the same line. >>>>>> There no such artifacts when i18n is false. >>>>>> Thanks for your help. >>>>>> Guy. >>>>>> --------------------------------------------------------------------------------------------- >>>>>> Le 2016-05-27 16:53, Alexandr Scherbatiy a ?crit : >>>>>>> The fix should be prepared for the JDK 9 first and only after >>>>>>> that be >>>>>>> backported to JDK 8u. >>>>>>> Could you apply the fix to JDK 9 client repository >>>>>>> http://hg.openjdk.java.net/jdk9/client >>>>>>> and send the webrev of the fix plus the test (see >>>>>>> http://openjdk.java.net/guide/webrevHelp.html). >>>>>>> The fix shouldn't contain comments with the old code lines. I >>>>>>> believe >>>>>>> that references to the bug number are also unnecessary for this >>>>>>> case. >>>>>>> You mentioned that there are artifacts with a table displaying >>>>>>> in JDK >>>>>>> 9. Do they appear only after fix of they also present even >>>>>>> without the >>>>>>> fix? >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> On 5/27/2016 9:23 AM, Abossolo Foh Guy wrote: >>>>>>>> Hello, >>>>>>>> Please, please ... could someone examine the patch for >>>>>>>> JDK-8133864 that I suggested ? I really need it to implement >>>>>>>> matrix display in my application. I've spent long time in 2012 >>>>>>>> to find what was wrong in tableview. I know Victor's comment >>>>>>>> was not good but you could compare with the tableview >>>>>>>> implementation in the swing/text/html package which works fine. >>>>>>>> Beware, the display (with java 9 119) for I18nLayoutTest.java >>>>>>>> is not the same with i18n true (bad) or i18n false (good). With >>>>>>>> i18n true the table go down. >>>>>>>> Best regards. >>>>>>>> ---------------------------------------------------------------------------------------------------------------------- >>>>>>>> Hello, >>>>>>>> I built the recent OpenJDK8u and OpenJDK9 sources >>>>>>>> (openjdk_versions.txt) with the patch shown in the >>>>>>>> output_diff.txt attachment. >>>>>>>> I applied your patch for JDK-8133864 : Wrong display, when the >>>>>>>> document I18n properties is true. >>>>>>>> And I applied my patch for JDK-7169915 : Swing Table Layout bad >>>>>>>> repaint of the row. >>>>>>>> All works fine in OpenJDK8u and the document is well displayed. >>>>>>>> The table appears as I expected with all its lines and columns >>>>>>>> (JDK-8133864 solved), size and borders included even if we >>>>>>>> write some text inside (JDK-7169915 solved). I can modify it as >>>>>>>> I want. >>>>>>>> But with OpenJDK9, the display of the document is wrong. The >>>>>>>> table appears as I expected with all its lines and columns >>>>>>>> (JDK-8133864 solved), size and borders included (JDK-7169915 >>>>>>>> solved) but the entire document display is modified, the table >>>>>>>> is displayed on a new line. And the document became unuseable, >>>>>>>> I can't modify it as I want. >>>>>>>> This morning, I ran the same test programme (CodeBug.java in >>>>>>>> attachment) with the Oracle JDK9 b114 (i.e. OpenJDK9 only with >>>>>>>> your patch for JDK-8133864) : The table appears as I expected >>>>>>>> with all its lines and columns (JDK-8133864 solved) but the >>>>>>>> size and borders are bad repainted when we write some text >>>>>>>> inside (JDK-7169915 solved). And the document became unuseable >>>>>>>> too, I can't modify it as I want. >>>>>>>> My conclusion : >>>>>>>> 1- JDK-8133864 is solved with your PATCH. >>>>>>>> 2- JDK-7169915 could be solved with my PATCH. >>>>>>>> 3- There is regression between JDK8 and JDK9 may be in the >>>>>>>> Views arrangement. >>>>>>>> Best regards. >>>>>>>> ---------------------------------------------------------------------------------------------------------------------- >>>>>>>> Hello, >>>>>>>> Could you apply the modification I suggested 4 years ago about >>>>>>>> the Bug : JDK-7169915 : Swing Table Layout bad repaint of the row. >>>>>>>> The test case I had sent in 2012 is the same I used in : >>>>>>>> JDK-8133864 Wrong display, when the document I18n properties is >>>>>>>> true. >>>>>>>> A version of this test (called I18nLayoutTest.java) is now >>>>>>>> candidate as part of tests for JDK 9 >>>>>>>> (/test/javax/swing/text/TableView/) >>>>>>>> Yours faithfully. >>>> >>>> -- >>>> Abossolo Foh Guy >>>> 71 rue Guy de Maupassant >>>> 69500 Bron >>>> >>>> 06 87 01 82 27 >>>> 04 72 81 89 46 >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Mon Mar 6 09:50:21 2017 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Mon, 6 Mar 2017 12:50:21 +0300 Subject: Review request for JDK-6490753 JComboBox doesn't look as native combobox in different states of component In-Reply-To: <1429f917-4312-1c09-3f66-853650bb50b0@oracle.com> References: <90cb4507-2996-931a-1ec7-1f92e81545fe@oracle.com> <1429f917-4312-1c09-3f66-853650bb50b0@oracle.com> Message-ID: <92f32470-9b4e-bd77-0c1b-761a852338a8@oracle.com> The fix looks good to me. Thanks, Alexandr. On 3/3/2017 8:55 PM, Alexandr Scherbatiy wrote: > > I have uploaded the webrev to the http://cr.openjdk.java.net: > http://cr.openjdk.java.net/~alexsch/mraz.martin/6490753/webrev.01 > > Thanks, > Alexandr. > > On 2/17/2017 2:41 PM, Martin M wrote: >> AnimationController.java >> 386 if (skin.haveToSwitchStates()) { >> 387 skin.paintSkinRaw(g, dx, dy, dw, dh, state); >> 388 g.setComposite(AlphaComposite.SrcOver.derive(1 - progress)); >> 389 skin.paintSkinRaw(g, dx, dy, dw, dh, startState); >> 390 } else { >> >> - Could the '1 - progress' value in AlphaComposite.SrcOver.derive(1 - >> progress) be out of range? >> >> Value 'progress' is checked in method 'private void updateProgress()' >> so it always is between 0 and 1. >> >> >> WindowsComboBoxUI.java >> 221 if (this.borderChecked == false) // check border of >> component >> 222 replaceBorder(); >> >> It is better to use 'if (!this.borderChecked) {replaceBorder();}'. >> There are Java Style Guidelines [1] which we need to follow to. >> >> I removed this part and replaced it with one line into method 'public >> void installUI( JComponent c )'. It has the same effect. >> WindowsComboBoxUI.java >> 159 // set empty border as default to see vista animated border >> 160 comboBox.setBorder(new EmptyBorder(0,0,0,0)); >> >> >> 454 if (comboBox.isPopupVisible()) >> 455 getModel().setPressed(true); >> 456 else >> 457 getModel().setPressed(false); >> >> This can be simplified to >> getModel().setPressed(comboBox.isPopupVisible()). >> >> Corrected. this was lame :( >> >> >> 508 @Deprecated >> 509 @SuppressWarnings("serial") // Superclass is not serializable >> across versions >> 510 protected class WindowsComboPopup extends BasicComboPopup { >> 511 >> 512 private class comboPopUpBorder extends EmptyBorder { >> >> The class WindowsComboPopup is marked as deprecated with comments '* >> This class is now obsolete and doesn't do anything.' >> Is it possible to move the popup border class outside and do not use >> the WindowsComboPopup at all? >> The comboPopUpBorder class name should start from capital char. >> >> I removed comboPopUpBorder class because painting of this border was >> hardcoded and it looked the same in win7 and win10. >> The border is now painted with system skin and looks properly in both >> windows versions. >> And I am not sure if it is ok, but I created new class WinComboPopUp >> which extends BasicComboPopup >> to avoid using deprecated WindowsComboPopup. But deprecated class >> also extends BasicComboPopup. So.... >> >> >> 566 Border border = (Border)UIManager.get("ComboBox.editorBorder"); >> 567 >> 568 // correct space on the left side of text (for >> editable combobox) >> 569 Insets i = border.getBorderInsets(editor); >> 570 border = BorderFactory.createEmptyBorder(i.top, 4, >> i.bottom, i.right); >> 571 >> 572 if (border != null) { >> 573 editor.setBorder(border); >> 574 } >> >> - The border.getBorderInsets(editor) is called before checking the >> border to null. >> - It seems that if a user sets a custom "ComboBox.editorBorder" it >> should not be changed. >> Is it possible just to update the dafult "ComboBox.editorBorder" in >> the com.sun.java.swing.plaf.windows.WindowsLookAndFeel class? >> >> I updated default ComboBox.editorBorder. >> >> >> XPStyle.java >> 517 public boolean haveToSwitchStates() { >> 518 return switchStates; >> 519 } >> 520 >> 521 public void switchStates(boolean b) { >> 522 switchStates = b; >> 523 } >> >> Could you change the methods access from the public to package? >> Making some API public, even in com.sun.* package may require some >> additional process. >> >> I changed access modifier from public to package. >> >> And I also decreased shifting of list items to right from 3px to 2px. >> If I see correctly native comboBox items have 2 px intendation from >> left side of the border, when system font is used. >> WindowsComboBoxUI.java >> 600 return new Insets(0,2,0,0); (previous value was 3) >> 609 setBorder(new EmptyBorder(0, 2, 0, i.right)); (previous value was >> 3 as well) >> >> br >> Martin >> >> >> >> 2017-02-03 13:31 GMT+01:00 Alexandr Scherbatiy >> >: >> >> On 2/1/2017 3:41 PM, Martin M wrote: >>> bug: https://bugs.openjdk.java.net/browse/JDK-6490753 >>> >>> webrev: >>> http://cr.openjdk.java.net/~alexsch/mraz.martin/6490753/webrev.00 >>> >>> >>> Problem description: >>> Swing JComboBox looks different than native one in states like >>> e.g. focused state or mouse rollover state and so on. >>> >>> The fix solves following issues: >>> - Editable combobox border is regular dark rectangle in all >>> states now. After the fix border will have light gray color in >>> normal state, light blue in rollover or hot state and dark blue >>> in pressed or focused state. >>> - Editable combobox button is painted almost properly, but not >>> animated as it should be. The fix will correct animation of the >>> button. >>> - popup with list of choices has black border. The fix will >>> correct the border to proper colors. >>> - All texts were rendered very close to left side of borders. >>> The fix shifts texts few screen points to the left. >> >> AnimationController.java >> 386 if (skin.haveToSwitchStates()) { >> 387 skin.paintSkinRaw(g, dx, dy, dw, dh, state); >> 388 >> g.setComposite(AlphaComposite.SrcOver.derive(1 - progress)); >> 389 skin.paintSkinRaw(g, dx, dy, dw, dh, >> startState); >> 390 } else { >> >> - Could the '1 - progress' value in >> AlphaComposite.SrcOver.derive(1 - progress) be out of range? >> >> WindowsComboBoxUI.java >> 221 if (this.borderChecked == false) // check border >> of component >> 222 replaceBorder(); >> >> It is better to use 'if (!this.borderChecked) {replaceBorder();}'. >> There are Java Style Guidelines [1] which we need to follow to. >> >> >> 454 if (comboBox.isPopupVisible()) >> 455 getModel().setPressed(true); >> 456 else >> 457 getModel().setPressed(false); >> >> This can be simplified to >> getModel().setPressed(comboBox.isPopupVisible()). >> >> >> 508 @Deprecated >> 509 @SuppressWarnings("serial") // Superclass is not >> serializable across versions >> 510 protected class WindowsComboPopup extends BasicComboPopup { >> 511 >> 512 private class comboPopUpBorder extends EmptyBorder { >> >> The class WindowsComboPopup is marked as deprecated with comments >> '* This class is now obsolete and doesn't do anything.' >> Is it possible to move the popup border class outside and do not >> use the WindowsComboPopup at all? >> The comboPopUpBorder class name should start from capital char. >> >> >> 566 Border border = >> (Border)UIManager.get("ComboBox.editorBorder"); >> 567 >> 568 // correct space on the left side of text (for >> editable combobox) >> 569 Insets i = border.getBorderInsets(editor); >> 570 border = BorderFactory.createEmptyBorder(i.top, >> 4, i.bottom, i.right); >> 571 >> 572 if (border != null) { >> 573 editor.setBorder(border); >> 574 } >> >> - The border.getBorderInsets(editor) is called before checking >> the border to null. >> - It seems that if a user sets a custom "ComboBox.editorBorder" >> it should not be changed. >> Is it possible just to update the dafult "ComboBox.editorBorder" >> in the com.sun.java.swing.plaf.windows.WindowsLookAndFeel class? >> >> >> XPStyle.java >> 517 public boolean haveToSwitchStates() { >> 518 return switchStates; >> 519 } >> 520 >> 521 public void switchStates(boolean b) { >> 522 switchStates = b; >> 523 } >> >> Could you change the methods access from the public to package? >> Making some API public, even in com.sun.* package may require >> some additional process. >> >> [1] >> http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html >> >> >> Thanks, >> Alexandr. >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.bylokhov at oracle.com Mon Mar 6 13:35:46 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 6 Mar 2017 16:35:46 +0300 Subject: Review request for JDK-6490753 JComboBox doesn't look as native combobox in different states of component In-Reply-To: <92f32470-9b4e-bd77-0c1b-761a852338a8@oracle.com> References: <90cb4507-2996-931a-1ec7-1f92e81545fe@oracle.com> <1429f917-4312-1c09-3f66-853650bb50b0@oracle.com> <92f32470-9b4e-bd77-0c1b-761a852338a8@oracle.com> Message-ID: <2D793DAE-F43E-4C23-8080-D6000C33711F@oracle.com> +1 > > > The fix looks good to me. > > Thanks, > Alexandr. > > On 3/3/2017 8:55 PM, Alexandr Scherbatiy wrote: >> >> I have uploaded the webrev to the http://cr.openjdk.java.net : >> http://cr.openjdk.java.net/~alexsch/mraz.martin/6490753/webrev.01 >> >> Thanks, >> Alexandr. >> >> On 2/17/2017 2:41 PM, Martin M wrote: >>> AnimationController.java >>> 386 if (skin.haveToSwitchStates()) { >>> 387 skin.paintSkinRaw(g, dx, dy, dw, dh, state); >>> 388 g.setComposite(AlphaComposite.SrcOver.derive(1 - progress)); >>> 389 skin.paintSkinRaw(g, dx, dy, dw, dh, startState); >>> 390 } else { >>> >>> - Could the '1 - progress' value in AlphaComposite.SrcOver.derive(1 - progress) be out of range? >>> >>> Value 'progress' is checked in method 'private void updateProgress()' so it always is between 0 and 1. >>> >>> >>> WindowsComboBoxUI.java >>> 221 if (this.borderChecked == false) // check border of component >>> 222 replaceBorder(); >>> >>> It is better to use 'if (!this.borderChecked) {replaceBorder();}'. >>> There are Java Style Guidelines [1] which we need to follow to. >>> >>> I removed this part and replaced it with one line into method 'public void installUI( JComponent c )'. It has the same effect. >>> WindowsComboBoxUI.java >>> 159 // set empty border as default to see vista animated border >>> 160 comboBox.setBorder(new EmptyBorder(0,0,0,0)); >>> >>> >>> 454 if (comboBox.isPopupVisible()) >>> 455 getModel().setPressed(true); >>> 456 else >>> 457 getModel().setPressed(false); >>> >>> This can be simplified to getModel().setPressed(comboBox.isPopupVisible()). >>> >>> Corrected. this was lame :( >>> >>> >>> 508 @Deprecated >>> 509 @SuppressWarnings("serial") // Superclass is not serializable across versions >>> 510 protected class WindowsComboPopup extends BasicComboPopup { >>> 511 >>> 512 private class comboPopUpBorder extends EmptyBorder { >>> >>> The class WindowsComboPopup is marked as deprecated with comments '* This class is now obsolete and doesn't do anything.' >>> Is it possible to move the popup border class outside and do not use the WindowsComboPopup at all? >>> The comboPopUpBorder class name should start from capital char. >>> >>> I removed comboPopUpBorder class because painting of this border was hardcoded and it looked the same in win7 and win10. >>> The border is now painted with system skin and looks properly in both windows versions. >>> And I am not sure if it is ok, but I created new class WinComboPopUp which extends BasicComboPopup >>> to avoid using deprecated WindowsComboPopup. But deprecated class also extends BasicComboPopup. So.... >>> >>> >>> 566 Border border = (Border)UIManager.get("ComboBox.editorBorder"); >>> 567 >>> 568 // correct space on the left side of text (for editable combobox) >>> 569 Insets i = border.getBorderInsets(editor); >>> 570 border = BorderFactory.createEmptyBorder(i.top, 4, i.bottom, i.right); >>> 571 >>> 572 if (border != null) { >>> 573 editor.setBorder(border); >>> 574 } >>> >>> - The border.getBorderInsets(editor) is called before checking the border to null. >>> - It seems that if a user sets a custom "ComboBox.editorBorder" it should not be changed. >>> Is it possible just to update the dafult "ComboBox.editorBorder" in the com.sun.java.swing.plaf.windows.WindowsLookAndFeel class? >>> >>> I updated default ComboBox.editorBorder. >>> >>> >>> XPStyle.java >>> 517 public boolean haveToSwitchStates() { >>> 518 return switchStates; >>> 519 } >>> 520 >>> 521 public void switchStates(boolean b) { >>> 522 switchStates = b; >>> 523 } >>> >>> Could you change the methods access from the public to package? Making some API public, even in com.sun.* package may require some additional process. >>> >>> I changed access modifier from public to package. >>> >>> And I also decreased shifting of list items to right from 3px to 2px. >>> If I see correctly native comboBox items have 2 px intendation from left side of the border, when system font is used. >>> WindowsComboBoxUI.java >>> 600 return new Insets(0,2,0,0); (previous value was 3) >>> 609 setBorder(new EmptyBorder(0, 2, 0, i.right)); (previous value was 3 as well) >>> >>> br >>> Martin >>> >>> >>> >>> 2017-02-03 13:31 GMT+01:00 Alexandr Scherbatiy >: >>> On 2/1/2017 3:41 PM, Martin M wrote: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-6490753 >>>> webrev: http://cr.openjdk.java.net/~alexsch/mraz.martin/6490753/webrev.00 >>>> >>>> Problem description: >>>> Swing JComboBox looks different than native one in states like e.g. focused state or mouse rollover state and so on. >>>> >>>> The fix solves following issues: >>>> - Editable combobox border is regular dark rectangle in all states now. After the fix border will have light gray color in normal state, light blue in rollover or hot state and dark blue in pressed or focused state. >>>> - Editable combobox button is painted almost properly, but not animated as it should be. The fix will correct animation of the button. >>>> - popup with list of choices has black border. The fix will correct the border to proper colors. >>>> - All texts were rendered very close to left side of borders. The fix shifts texts few screen points to the left. >>> >>> AnimationController.java >>> 386 if (skin.haveToSwitchStates()) { >>> 387 skin.paintSkinRaw(g, dx, dy, dw, dh, state); >>> 388 g.setComposite(AlphaComposite.SrcOver.derive(1 - progress)); >>> 389 skin.paintSkinRaw(g, dx, dy, dw, dh, startState); >>> 390 } else { >>> >>> - Could the '1 - progress' value in AlphaComposite.SrcOver.derive(1 - progress) be out of range? >>> >>> WindowsComboBoxUI.java >>> 221 if (this.borderChecked == false) // check border of component >>> 222 replaceBorder(); >>> >>> It is better to use 'if (!this.borderChecked) {replaceBorder();}'. >>> There are Java Style Guidelines [1] which we need to follow to. >>> >>> >>> 454 if (comboBox.isPopupVisible()) >>> 455 getModel().setPressed(true); >>> 456 else >>> 457 getModel().setPressed(false); >>> >>> This can be simplified to getModel().setPressed(comboBox.isPopupVisible()). >>> >>> >>> 508 @Deprecated >>> 509 @SuppressWarnings("serial") // Superclass is not serializable across versions >>> 510 protected class WindowsComboPopup extends BasicComboPopup { >>> 511 >>> 512 private class comboPopUpBorder extends EmptyBorder { >>> >>> The class WindowsComboPopup is marked as deprecated with comments '* This class is now obsolete and doesn't do anything.' >>> Is it possible to move the popup border class outside and do not use the WindowsComboPopup at all? >>> The comboPopUpBorder class name should start from capital char. >>> >>> >>> 566 Border border = (Border)UIManager.get("ComboBox.editorBorder"); >>> 567 >>> 568 // correct space on the left side of text (for editable combobox) >>> 569 Insets i = border.getBorderInsets(editor); >>> 570 border = BorderFactory.createEmptyBorder(i.top, 4, i.bottom, i.right); >>> 571 >>> 572 if (border != null) { >>> 573 editor.setBorder(border); >>> 574 } >>> >>> - The border.getBorderInsets(editor) is called before checking the border to null. >>> - It seems that if a user sets a custom "ComboBox.editorBorder" it should not be changed. >>> Is it possible just to update the dafult "ComboBox.editorBorder" in the com.sun.java.swing.plaf.windows.WindowsLookAndFeel class? >>> >>> >>> XPStyle.java >>> 517 public boolean haveToSwitchStates() { >>> 518 return switchStates; >>> 519 } >>> 520 >>> 521 public void switchStates(boolean b) { >>> 522 switchStates = b; >>> 523 } >>> >>> Could you change the methods access from the public to package? Making some API public, even in com.sun.* package may require some additional process. >>> >>> [1] http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html >>> >>> Thanks, >>> Alexandr. >>> >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.bylokhov at oracle.com Mon Mar 6 14:00:41 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 6 Mar 2017 17:00:41 +0300 Subject: [9] Review Request: 8176177 The new SwingContainer annotation can be removed from javax.accessibility.AccessibleContext Message-ID: Hello, Please review the fix for jdk9. When the new annotation SwingContainer was added to the Swing library, we applied it to all classes where the old compile time bean-info has an isContainer=false attribute. The goal of this annotation is to point that some class which extends Container in the Swing library is not actually a container. So it is an error to mark the class if is not a container. In the fix this annotation was removed from javax.accessibility.AccessibleContext. Bug: https://bugs.openjdk.java.net/browse/JDK-8176177 Webrev can be found at: http://cr.openjdk.java.net/~serb/8176177/webrev.00 CCC will be filed after technical review. From alexandr.scherbatiy at oracle.com Mon Mar 6 14:35:19 2017 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Mon, 6 Mar 2017 17:35:19 +0300 Subject: [9] Review Request: 8176177 The new SwingContainer annotation can be removed from javax.accessibility.AccessibleContext In-Reply-To: References: Message-ID: <63227751-8cde-3c41-f161-c03f4b43c51f@oracle.com> The fix looks good to me. Thanks, Alexandr. On 3/6/2017 5:00 PM, Sergey Bylokhov wrote: > Hello, > Please review the fix for jdk9. > When the new annotation SwingContainer was added to the Swing library, we applied it to all classes where the old compile time bean-info has an isContainer=false attribute. > The goal of this annotation is to point that some class which extends Container in the Swing library is not actually a container. So it is an error to mark the class if is not a container. > > In the fix this annotation was removed from javax.accessibility.AccessibleContext. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8176177 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8176177/webrev.00 > > CCC will be filed after technical review. From mahendra.gajera at gmail.com Tue Mar 7 05:50:02 2017 From: mahendra.gajera at gmail.com (mahendrag gajera) Date: Tue, 7 Mar 2017 11:20:02 +0530 Subject: Java_Swings/AWT Native Interface give error in 32-bit window OS Message-ID: Hello All, I follow step as mention in below link and create .dll and java application. https://en.wikibooks.org/wiki/Java_Swings/AWT. Every things work fine in window 7/8 64-bit OS. In window7 32-bit OS, It work after below change in code. *public class JavaSideCanvas extends Canvas {* * static {* * System.loadLibrary("jawt");* * System.loadLibrary("NativeSideCanvas");* * }* * public native void paint(Graphics g);* * public static void main(String[] args) {* * Frame frame = new Frame();* * frame.setBounds(0, 0, 500, 500);* * JavaSideCanvas jsc = new JavaSideCanvas();* * frame.add(jsc);* * frame.addWindowListener(new WindowAdapter() {* * public void windowClosing(WindowEvent ev) {* * System.exit(0);* * }* * });* * frame.show();* * }* *}* But it is not working in window8 32-bit OS. I found the cause,* jawt.lib* is giving error. If i remove from linker setting of my project,then it works fine Can any one help me why it is not working in window8 32-OS only?. or Can i write own *JAWT_GetAWT *method for window? So no need to link *jawt.lib.* *Environment * Project compiled in *jdk-7u55-windows-x86*. Using 32 bit JRE 6/7/8 in window8 32-bit OS Please look the attached code for the same. Thanks in Advance -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: JavaBridgeFileLoader.java Type: application/octet-stream Size: 2041 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: MyCanvas.java Type: application/octet-stream Size: 798 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Canvas.zip Type: application/zip Size: 6619 bytes Desc: not available URL: From alexandr.scherbatiy at oracle.com Tue Mar 7 14:23:34 2017 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 7 Mar 2017 17:23:34 +0300 Subject: Java_Swings/AWT Native Interface give error in 32-bit window OS In-Reply-To: References: Message-ID: <7d449d0f-8fc4-f89b-479d-1cd7ec68732f@oracle.com> Forwarded to the awt-dev alias. Thanks, Alexandr. On 3/7/2017 8:50 AM, mahendrag gajera wrote: > Hello All, > > I follow step as mention in below link and create .dll and java > application. > > https://en.wikibooks.org/wiki/Java_Swings/AWT. Every things work fine > in window 7/8 64-bit OS. > > In window7 32-bit OS, It work after below change in code. > > *public class JavaSideCanvas extends Canvas {* > * > * > * static {* > * System.loadLibrary("jawt");* > * System.loadLibrary("NativeSideCanvas");* > * }* > * > * > * public native void paint(Graphics g);* > * > * > * public static void main(String[] args) {* > * Frame frame = new Frame();* > * frame.setBounds(0, 0, 500, 500);* > * JavaSideCanvas jsc = new JavaSideCanvas();* > * frame.add(jsc);* > * frame.addWindowListener(new WindowAdapter() {* > * public void windowClosing(WindowEvent ev) {* > * System.exit(0);* > * }* > * });* > * frame.show();* > * }* > *}* > But it is not working in window8 32-bit OS. > > I found the cause,*jawt.lib* is giving error. If i remove from linker > setting of my project,then it works fine > > Can any one help me why it is not working in window8 32-OS only?. > or > Can i write own *JAWT_GetAWT *method for window? So no need to link > *jawt.lib.* > > *Environment * > Project compiled in *jdk-7u55-windows-x86*. > Using 32 bit JRE 6/7/8 in window8 32-bit OS > > Please look the attached code for the same. > > > Thanks in Advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From malenkov at gmail.com Tue Mar 7 10:19:56 2017 From: malenkov at gmail.com (Sergey Malenkov) Date: Tue, 7 Mar 2017 13:19:56 +0300 Subject: [9] Review Request: 8176177 The new SwingContainer annotation can be removed from javax.accessibility.AccessibleContext In-Reply-To: References: Message-ID: The fix looks good to me On Mon, Mar 6, 2017 at 5:00 PM, Sergey Bylokhov wrote: > Hello, > Please review the fix for jdk9. > When the new annotation SwingContainer was added to the Swing library, we applied it to all classes where the old compile time bean-info has an isContainer=false attribute. > The goal of this annotation is to point that some class which extends Container in the Swing library is not actually a container. So it is an error to mark the class if is not a container. > > In the fix this annotation was removed from javax.accessibility.AccessibleContext. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8176177 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8176177/webrev.00 > > CCC will be filed after technical review. -- Best regards, Sergey A. Malenkov From alexandr.scherbatiy at oracle.com Tue Mar 14 10:54:17 2017 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 14 Mar 2017 13:54:17 +0300 Subject: [9] Review request for 8174845 Bad scaling on Windows with large fonts with Java 9ea Message-ID: <9440fff8-47c1-8991-35b0-831f95cb1c88@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8174845 webrev: http://cr.openjdk.java.net/~alexsch/8174845/webrev.00 Metal JCheckBox and JMenuItem icons are updated to be drawn by ovals, arcs and polygons. The [1] folder contains screenshots how icons are drawn before the fix (on the left side) and after the fix (on the right side) with Default and Ocean Metal themes. [1] http://cr.openjdk.java.net/~alexsch/8174845/screenshots/00 Thanks, Alexandr. From prasanta.sadhukhan at oracle.com Tue Mar 14 11:46:57 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 14 Mar 2017 17:16:57 +0530 Subject: [9] JDK-8169897: [PIT] javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java fails Message-ID: <21055f66-7fd6-f66e-af07-63553cedeb2e@oracle.com> Hi All, Please review a testbug fix where the testcase is failing in linux because it is not able to find "Arial" font and tries to use the font found in 0th index of getAvailableFontFamilyNames() which is "Abyssinica SIL". Bug: https://bugs.openjdk.java.net/browse/JDK-8169897 webrev: http://cr.openjdk.java.net/~psadhukhan/8169897/webrev.00/ Modified the testcode to use "Serif" which is present in all platforms. Tested in windows,linux,mac. Regards Prasanta From philip.race at oracle.com Tue Mar 14 12:37:25 2017 From: philip.race at oracle.com (Philip Race) Date: Tue, 14 Mar 2017 05:37:25 -0700 Subject: [9] JDK-8169897: [PIT] javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java fails In-Reply-To: <21055f66-7fd6-f66e-af07-63553cedeb2e@oracle.com> References: <21055f66-7fd6-f66e-af07-63553cedeb2e@oracle.com> Message-ID: <58C7E405.7090508@oracle.com> I am not sure why the test went to the trouble of looking for Arial. If there was a good reason (Alexander ??) an alternative is to initialise String fontName = "Serif". although swapping out Arial for Serif is a very odd choice. Arial is a Sans Serif font and Serif fonts are not usually used in UIs. So "SansSerif" would be better -phil. On 3/14/17, 4:46 AM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a testbug fix where the testcase is failing in linux > because it is not able to find "Arial" font and tries to use the font > found in 0th index of getAvailableFontFamilyNames() > which is "Abyssinica SIL". > > Bug: https://bugs.openjdk.java.net/browse/JDK-8169897 > webrev: http://cr.openjdk.java.net/~psadhukhan/8169897/webrev.00/ > > Modified the testcode to use "Serif" which is present in all > platforms. Tested in windows,linux,mac. > > Regards > Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue Mar 14 13:18:12 2017 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 14 Mar 2017 16:18:12 +0300 Subject: [9] JDK-8169897: [PIT] javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java fails In-Reply-To: <58C7E405.7090508@oracle.com> References: <21055f66-7fd6-f66e-af07-63553cedeb2e@oracle.com> <58C7E405.7090508@oracle.com> Message-ID: <62d27dfd-2638-26aa-8cb6-f31d5e133dde@oracle.com> On 3/14/2017 3:37 PM, Philip Race wrote: > I am not sure why the test went to the trouble of looking for Arial. > If there was a good reason (Alexander ??) an alternative is to initialise The test tries to calculate number of intersection with letter O and its underline. It is sensitive to the position of the letter. Thanks, Alexandr. > String fontName = "Serif". > > although swapping out Arial for Serif is a very odd choice. > Arial is a Sans Serif font and Serif fonts are not usually used in UIs. > > So "SansSerif" would be better > -phil. > > On 3/14/17, 4:46 AM, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a testbug fix where the testcase is failing in linux >> because it is not able to find "Arial" font and tries to use the font >> found in 0th index of getAvailableFontFamilyNames() >> which is "Abyssinica SIL". >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8169897 >> webrev: http://cr.openjdk.java.net/~psadhukhan/8169897/webrev.00/ >> >> Modified the testcode to use "Serif" which is present in all >> platforms. Tested in windows,linux,mac. >> >> Regards >> Prasanta From philip.race at oracle.com Tue Mar 14 15:09:06 2017 From: philip.race at oracle.com (Philip Race) Date: Tue, 14 Mar 2017 08:09:06 -0700 Subject: JDK9 will be in RDP2 after March 16th PDT Message-ID: <58C80792.7010007@oracle.com> All, There will I am sure be an official email to jdk9-dev soon but I'd at least to give a reminder about this change in JDK 9 rules as it winds down towards release. If you have anything you need to push without incurring extra process you have just 2 and a half days to do it. After March 16th *all* pushes to any forest require some kind of explicit approval. For changes in product code, you will need a "jdk9-critical-request" label and a justification about why it is a critical or stopper bug for JDK9. That justification will be evaluated. P3 and above "test" and "doc" bugs can still go in with a much less formal "nod" which for the lists above you can get from me. I will monitor the lists for such issues. That is just a very brief and rough summary of what happens *after* Thursday. Others will give a more precise rundown of the rules. The main message here from me is (1) Push soon or incur process (2) After Thursday DO NOT push without approval. -phil. From sergey.bylokhov at oracle.com Tue Mar 14 15:12:29 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 14 Mar 2017 18:12:29 +0300 Subject: [9] Review Request: 8176448 [macos] Popups in JCombobox and Choice have incorrect location in multiscreen systems Message-ID: <13EDA312-4063-46EF-A9FC-2F7615654915@oracle.com> Hello, Please review the fix for jdk9. In the fixes for JDK-7072653 [1] and JDK-8129838 [2] and JDK-8144161[3] [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7606d0af7b80 Notes about JDK-7072653 - AquaComboBoxPopup.java the code "if (py + ph > scrBounds.y + scrBounds.height)? compares the vars in a different coordinate spaces(combobox vs screen). It is ok in BasicComboPopup.java because we translate scrBounds properly. - In Aqua the code was changed for the case when "JComboBox.isPopDown? property is false, I will create a separate CR to fix it when the property is true. [2] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/5ea7cbf6a7bd Notes about JDK-8129838 - AquaComboBoxPopup.java the second loop was changed to use "intersects" and "contains" at the same time, but if the point is located on the screen it will be found in the first loop, but if it was not found the second loop will be noop. - Some code was extracted to the new method getAvailableScreenArea(), but it was copied from the place where the only one screen was available, so it uses ?0? as a left point and does not take into account that the screen can have non-zero offset. [3] hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e8e9c65def6d Notes about JDK-8144161: - After JDK-7072653 [1] and JDK-8129838 were pushed the test which was pushed started to fail on OS X, and this was considered as a testbug, even if the code in Aqua l&f was changed to support this functionality. - The test was changed to use a different look and feels, but since it run the test code a few times it start to work incorrectly, because JFrame.getWindows() can return popup window from the different L&F.(dispose was called on it but it was not garbage collected). Fix description: - An additional check in the second loop in AquaComboBoxPopup.java was removed. - AquaComboBoxPopup.getAvailableScreenArea now takes into account that we can have a few screens. - AquaComboBoxPopup.computePopupBounds() was changed to take into account that scrBounds is in the screen coordinates space. - The test bug7072653.java now check all screen in the system. - Note that the new test ChoicePopupLocation.java will fail on linux in multiscreen because of JDK-8160270. I will fix it after this one. Bug: https://bugs.openjdk.java.net/browse/JDK-8176448 Webrev can be found at: http://cr.openjdk.java.net/~serb/8176448/webrev.04/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.bylokhov at oracle.com Tue Mar 14 16:31:00 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 14 Mar 2017 19:31:00 +0300 Subject: [9] Review request for 8174845 Bad scaling on Windows with large fonts with Java 9ea In-Reply-To: <9440fff8-47c1-8991-35b0-831f95cb1c88@oracle.com> References: <9440fff8-47c1-8991-35b0-831f95cb1c88@oracle.com> Message-ID: <3E8F39A5-36CC-4945-9D19-C283FFBF1866@oracle.com> The initial image at [1] also show some issues in the submenu pointer and the menu corners, did we solve them already? [1] http://stackoverflow.com/questions/41117190/java-9-on-windows-with-large-fonts > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8174845 > webrev: http://cr.openjdk.java.net/~alexsch/8174845/webrev.00 > > Metal JCheckBox and JMenuItem icons are updated to be drawn by ovals, arcs and polygons. > > The [1] folder contains screenshots how icons are drawn before the fix (on the left side) and after the fix (on the right side) with Default and Ocean Metal themes. > > [1] http://cr.openjdk.java.net/~alexsch/8174845/screenshots/00 > > Thanks, > Alexandr. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue Mar 14 18:50:47 2017 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 14 Mar 2017 21:50:47 +0300 Subject: [9] Review request for 8174845 Bad scaling on Windows with large fonts with Java 9ea In-Reply-To: <3E8F39A5-36CC-4945-9D19-C283FFBF1866@oracle.com> References: <9440fff8-47c1-8991-35b0-831f95cb1c88@oracle.com> <3E8F39A5-36CC-4945-9D19-C283FFBF1866@oracle.com> Message-ID: On 3/14/2017 7:31 PM, Sergey Bylokhov wrote: > The initial image at [1] also show some issues in the submenu pointer > and the menu corners, did we solve them already? The submenu icon is updated in the current fix and the issue with a menu corner is covered by the fix JDK-8162350 RepaintManager shifts repainted region when the floating point UI scale is used Thanks, Alexandr. > > [1] > http://stackoverflow.com/questions/41117190/java-9-on-windows-with-large-fonts > >> >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8174845 >> webrev: http://cr.openjdk.java.net/~alexsch/8174845/webrev.00 >> >> >> Metal JCheckBox and JMenuItem icons are updated to be drawn by >> ovals, arcs and polygons. >> >> The [1] folder contains screenshots how icons are drawn before the >> fix (on the left side) and after the fix (on the right side) with >> Default and Ocean Metal themes. >> >> [1] http://cr.openjdk.java.net/~alexsch/8174845/screenshots/00 >> >> >> Thanks, >> Alexandr. >> > From prasanta.sadhukhan at oracle.com Wed Mar 15 06:21:14 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 15 Mar 2017 11:51:14 +0530 Subject: [9] JDK-8169897: [PIT] javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java fails In-Reply-To: <62d27dfd-2638-26aa-8cb6-f31d5e133dde@oracle.com> References: <21055f66-7fd6-f66e-af07-63553cedeb2e@oracle.com> <58C7E405.7090508@oracle.com> <62d27dfd-2638-26aa-8cb6-f31d5e133dde@oracle.com> Message-ID: On 3/14/2017 6:48 PM, Alexandr Scherbatiy wrote: > On 3/14/2017 3:37 PM, Philip Race wrote: >> I am not sure why the test went to the trouble of looking for Arial. >> If there was a good reason (Alexander ??) an alternative is to >> initialise > The test tries to calculate number of intersection with letter O and > its underline. It is sensitive to the position of the letter. > If I use "SansSerif", it passes in windows,linux but fails in mac and screenshot of the letter O in mac is different compared to windows,linux [1] For Serif, the screenshot are same in all platforms. Alex, can you tell me how do you arrive at this hardcoded intersection number? if (backgroundChangesCount != intersections * 2) { throw new RuntimeException("String is not properly drawn!"); } [1] screenshot windows: http://cr.openjdk.java.net/~psadhukhan/8169897/8132119-windows.png linux: http://cr.openjdk.java.net/~psadhukhan/8169897/8132119-ubuntu.png mac: http://cr.openjdk.java.net/~psadhukhan/8169897/8132119-mac.png Regards Prasanta > Thanks, > Alexandr. >> String fontName = "Serif". >> >> although swapping out Arial for Serif is a very odd choice. >> Arial is a Sans Serif font and Serif fonts are not usually used in UIs. >> >> So "SansSerif" would be better >> -phil. >> >> On 3/14/17, 4:46 AM, Prasanta Sadhukhan wrote: >>> Hi All, >>> >>> Please review a testbug fix where the testcase is failing in linux >>> because it is not able to find "Arial" font and tries to use the >>> font found in 0th index of getAvailableFontFamilyNames() >>> which is "Abyssinica SIL". >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8169897 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8169897/webrev.00/ >>> >>> Modified the testcode to use "Serif" which is present in all >>> platforms. Tested in windows,linux,mac. >>> >>> Regards >>> Prasanta > From alexandr.scherbatiy at oracle.com Wed Mar 15 12:33:46 2017 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Wed, 15 Mar 2017 15:33:46 +0300 Subject: [9] Review Request: 8176448 [macos] Popups in JCombobox and Choice have incorrect location in multiscreen systems In-Reply-To: <13EDA312-4063-46EF-A9FC-2F7615654915@oracle.com> References: <13EDA312-4063-46EF-A9FC-2F7615654915@oracle.com> Message-ID: <0b8dd366-4f8e-a16f-2553-e7219e002e41@oracle.com> The fix looks good to me. Thanks, Alexandr. On 3/14/2017 6:12 PM, Sergey Bylokhov wrote: > Hello, > Please review the fix for jdk9. > In the fixes for JDK-7072653 [1] and JDK-8129838 [2] and JDK-8144161[3] > > [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7606d0af7b80 > > Notes about JDK-7072653 > - AquaComboBoxPopup.java the code "if (py + ph > scrBounds.y + > scrBounds.height)? compares the vars in a different coordinate > spaces(combobox vs screen). It is ok in BasicComboPopup.java because > we translate scrBounds properly. > - In Aqua the code was changed for the case when > "JComboBox.isPopDown? property is false, I will create a separate CR > to fix it when the property is true. > > [2] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/5ea7cbf6a7bd > > Notes about JDK-8129838 > - AquaComboBoxPopup.java the second loop was changed to use > "intersects" and "contains" at the same time, but if the point is > located on the screen it will be found in the first loop, but if it > was not found the second loop will be noop. > - Some code was extracted to the new method getAvailableScreenArea(), > but it was copied from the place where the only one screen was > available, so it uses ?0? as a left point and does not take into > account that the screen can have non-zero offset. > > [3] hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e8e9c65def6d > > > Notes about JDK-8144161: > - After JDK-7072653 [1] and JDK-8129838 were pushed the test which > was pushed started to fail on OS X, and this was considered as a > testbug, even if the code in Aqua l&f was changed to support this > functionality. > - The test was changed to use a different look and feels, but since > it run the test code a few times it start to work incorrectly, because > JFrame.getWindows() can return popup window from the different > L&F.(dispose was called on it but it was not garbage collected). > > Fix description: > - An additional check in the second loop in AquaComboBoxPopup.java > was removed. > - AquaComboBoxPopup.getAvailableScreenArea now takes into account > that we can have a few screens. > - AquaComboBoxPopup.computePopupBounds() was changed to take into > account that scrBounds is in the screen coordinates space. > - The test bug7072653.java now check all screen in the system. > - Note that the new test ChoicePopupLocation.java will fail on linux > in multiscreen because of JDK-8160270. I will fix it after this one. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8176448 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8176448/webrev.04/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.zvegintsev at oracle.com Wed Mar 15 14:30:10 2017 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 15 Mar 2017 17:30:10 +0300 Subject: [9] Review Request: 8176448 [macos] Popups in JCombobox and Choice have incorrect location in multiscreen systems In-Reply-To: <0b8dd366-4f8e-a16f-2553-e7219e002e41@oracle.com> References: <13EDA312-4063-46EF-A9FC-2F7615654915@oracle.com> <0b8dd366-4f8e-a16f-2553-e7219e002e41@oracle.com> Message-ID: <6d914b99-cf15-edb4-b786-787f34ace917@oracle.com> +1 Thanks, Alexander. On 15/03/2017 15:33, Alexandr Scherbatiy wrote: > > The fix looks good to me. > > Thanks, > Alexandr. > > On 3/14/2017 6:12 PM, Sergey Bylokhov wrote: >> Hello, >> Please review the fix for jdk9. >> In the fixes for JDK-7072653 [1] and JDK-8129838 [2] and JDK-8144161[3] >> >> [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7606d0af7b80 >> >> Notes about JDK-7072653 >> - AquaComboBoxPopup.java the code "if (py + ph > scrBounds.y + >> scrBounds.height)? compares the vars in a different coordinate >> spaces(combobox vs screen). It is ok in BasicComboPopup.java because >> we translate scrBounds properly. >> - In Aqua the code was changed for the case when >> "JComboBox.isPopDown? property is false, I will create a separate CR >> to fix it when the property is true. >> >> [2] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/5ea7cbf6a7bd >> >> Notes about JDK-8129838 >> - AquaComboBoxPopup.java the second loop was changed to use >> "intersects" and "contains" at the same time, but if the point is >> located on the screen it will be found in the first loop, but if it >> was not found the second loop will be noop. >> - Some code was extracted to the new method >> getAvailableScreenArea(), but it was copied from the place where the >> only one screen was available, so it uses ?0? as a left point and >> does not take into account that the screen can have non-zero offset. >> >> [3] hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e8e9c65def6d >> >> >> Notes about JDK-8144161: >> - After JDK-7072653 [1] and JDK-8129838 were pushed the test which >> was pushed started to fail on OS X, and this was considered as a >> testbug, even if the code in Aqua l&f was changed to support this >> functionality. >> - The test was changed to use a different look and feels, but since >> it run the test code a few times it start to work incorrectly, >> because JFrame.getWindows() can return popup window from the >> different L&F.(dispose was called on it but it was not garbage >> collected). >> >> Fix description: >> - An additional check in the second loop in AquaComboBoxPopup.java >> was removed. >> - AquaComboBoxPopup.getAvailableScreenArea now takes into account >> that we can have a few screens. >> - AquaComboBoxPopup.computePopupBounds() was changed to take into >> account that scrBounds is in the screen coordinates space. >> - The test bug7072653.java now check all screen in the system. >> - Note that the new test ChoicePopupLocation.java will fail on >> linux in multiscreen because of JDK-8160270. I will fix it after this >> one. >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8176448 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/8176448/webrev.04/ >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.zvegintsev at oracle.com Wed Mar 15 15:01:01 2017 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 15 Mar 2017 18:01:01 +0300 Subject: [9] Review request for 8174845 Bad scaling on Windows with large fonts with Java 9ea In-Reply-To: <9440fff8-47c1-8991-35b0-831f95cb1c88@oracle.com> References: <9440fff8-47c1-8991-35b0-831f95cb1c88@oracle.com> Message-ID: Looks good to me; Thanks, Alexander. On 14/03/2017 13:54, Alexandr Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8174845 > webrev: http://cr.openjdk.java.net/~alexsch/8174845/webrev.00 > > Metal JCheckBox and JMenuItem icons are updated to be drawn by > ovals, arcs and polygons. > > The [1] folder contains screenshots how icons are drawn before the > fix (on the left side) and after the fix (on the right side) with > Default and Ocean Metal themes. > > [1] http://cr.openjdk.java.net/~alexsch/8174845/screenshots/00 > > Thanks, > Alexandr. > From philip.race at oracle.com Wed Mar 15 15:21:12 2017 From: philip.race at oracle.com (Philip Race) Date: Wed, 15 Mar 2017 08:21:12 -0700 Subject: [9] JDK-8169897: [PIT] javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java fails In-Reply-To: References: <21055f66-7fd6-f66e-af07-63553cedeb2e@oracle.com> <58C7E405.7090508@oracle.com> <62d27dfd-2638-26aa-8cb6-f31d5e133dde@oracle.com> Message-ID: <58C95BE8.80305@oracle.com> This test sounds flaky and changing the font is clearly the wrong fix. -phil. On 3/14/17, 11:21 PM, Prasanta Sadhukhan wrote: > > > On 3/14/2017 6:48 PM, Alexandr Scherbatiy wrote: >> On 3/14/2017 3:37 PM, Philip Race wrote: >>> I am not sure why the test went to the trouble of looking for Arial. >>> If there was a good reason (Alexander ??) an alternative is to >>> initialise >> The test tries to calculate number of intersection with letter O >> and its underline. It is sensitive to the position of the letter. >> > If I use "SansSerif", it passes in windows,linux but > fails in mac and screenshot of the letter O in mac is different > compared to windows,linux [1] > For Serif, the screenshot are same in all platforms. > > Alex, can you tell me how do you arrive at this hardcoded intersection > number? > if (backgroundChangesCount != intersections * 2) { > throw new RuntimeException("String is not properly drawn!"); > } > > [1] screenshot windows: > http://cr.openjdk.java.net/~psadhukhan/8169897/8132119-windows.png > linux: > http://cr.openjdk.java.net/~psadhukhan/8169897/8132119-ubuntu.png > mac: http://cr.openjdk.java.net/~psadhukhan/8169897/8132119-mac.png > > Regards > Prasanta >> Thanks, >> Alexandr. >>> String fontName = "Serif". >>> >>> although swapping out Arial for Serif is a very odd choice. >>> Arial is a Sans Serif font and Serif fonts are not usually used in UIs. >>> >>> So "SansSerif" would be better >>> -phil. >>> >>> On 3/14/17, 4:46 AM, Prasanta Sadhukhan wrote: >>>> Hi All, >>>> >>>> Please review a testbug fix where the testcase is failing in linux >>>> because it is not able to find "Arial" font and tries to use the >>>> font found in 0th index of getAvailableFontFamilyNames() >>>> which is "Abyssinica SIL". >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8169897 >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8169897/webrev.00/ >>>> >>>> Modified the testcode to use "Serif" which is present in all >>>> platforms. Tested in windows,linux,mac. >>>> >>>> Regards >>>> Prasanta >> > From sergey.bylokhov at oracle.com Wed Mar 15 15:35:37 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 15 Mar 2017 18:35:37 +0300 Subject: [9] Review request for 8174845 Bad scaling on Windows with large fonts with Java 9ea In-Reply-To: References: <9440fff8-47c1-8991-35b0-831f95cb1c88@oracle.com> <3E8F39A5-36CC-4945-9D19-C283FFBF1866@oracle.com> Message-ID: <1AC15E91-5533-44BC-B0D6-D146F4A98FE3@oracle.com> > On 3/14/2017 7:31 PM, Sergey Bylokhov wrote: >> The initial image at [1] also show some issues in the submenu pointer and the menu corners, did we solve them already? > The submenu icon is updated in the current fix and the issue with a menu corner is covered by the fix > JDK-8162350 RepaintManager shifts repainted region when the floating point UI scale is used Thanks, Looks fine. > > Thanks, > Alexandr. >> >> [1] http://stackoverflow.com/questions/41117190/java-9-on-windows-with-large-fonts >> >>> >>> Hello, >>> >>> Could you review the fix: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8174845 >>> webrev: http://cr.openjdk.java.net/~alexsch/8174845/webrev.00 >>> >>> Metal JCheckBox and JMenuItem icons are updated to be drawn by ovals, arcs and polygons. >>> >>> The [1] folder contains screenshots how icons are drawn before the fix (on the left side) and after the fix (on the right side) with Default and Ocean Metal themes. >>> >>> [1] http://cr.openjdk.java.net/~alexsch/8174845/screenshots/00 >>> >>> Thanks, >>> Alexandr. >>> >> > From philip.race at oracle.com Wed Mar 15 17:11:07 2017 From: philip.race at oracle.com (Philip Race) Date: Wed, 15 Mar 2017 10:11:07 -0700 Subject: [9] Review request for 8174845 Bad scaling on Windows with large fonts with Java 9ea In-Reply-To: <1AC15E91-5533-44BC-B0D6-D146F4A98FE3@oracle.com> References: <9440fff8-47c1-8991-35b0-831f95cb1c88@oracle.com> <3E8F39A5-36CC-4945-9D19-C283FFBF1866@oracle.com> <1AC15E91-5533-44BC-B0D6-D146F4A98FE3@oracle.com> Message-ID: <58C975AB.6010709@oracle.com> Does this actually try to address everything they complained about here http://stackoverflow.com/questions/41117190/java-9-on-windows-with-large-fonts which points to an image : https://i.stack.imgur.com/fgpBu.png Check boxes are some of it but not all of it. There is what appears to be a custom icon there - the black outlined yellow zig-zg shape - and I don't see how we can draw that ourselves. Which is why I asked in the bug report if we had looked at how we are doing image scaling. It may be that we are already doing the best we can but I don't know that .. -phil. On 3/15/17, 8:35 AM, Sergey Bylokhov wrote: >> On 3/14/2017 7:31 PM, Sergey Bylokhov wrote: >>> The initial image at [1] also show some issues in the submenu pointer and the menu corners, did we solve them already? >> The submenu icon is updated in the current fix and the issue with a menu corner is covered by the fix >> JDK-8162350 RepaintManager shifts repainted region when the floating point UI scale is used > Thanks, Looks fine. > >> Thanks, >> Alexandr. >>> [1] http://stackoverflow.com/questions/41117190/java-9-on-windows-with-large-fonts >>> >>>> Hello, >>>> >>>> Could you review the fix: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8174845 >>>> webrev: http://cr.openjdk.java.net/~alexsch/8174845/webrev.00 >>>> >>>> Metal JCheckBox and JMenuItem icons are updated to be drawn by ovals, arcs and polygons. >>>> >>>> The [1] folder contains screenshots how icons are drawn before the fix (on the left side) and after the fix (on the right side) with Default and Ocean Metal themes. >>>> >>>> [1] http://cr.openjdk.java.net/~alexsch/8174845/screenshots/00 >>>> >>>> Thanks, >>>> Alexandr. >>>> From philip.race at oracle.com Wed Mar 15 17:48:29 2017 From: philip.race at oracle.com (Philip Race) Date: Wed, 15 Mar 2017 10:48:29 -0700 Subject: [9] Review request for 8174845 Bad scaling on Windows with large fonts with Java 9ea In-Reply-To: <58C975AB.6010709@oracle.com> References: <9440fff8-47c1-8991-35b0-831f95cb1c88@oracle.com> <3E8F39A5-36CC-4945-9D19-C283FFBF1866@oracle.com> <1AC15E91-5533-44BC-B0D6-D146F4A98FE3@oracle.com> <58C975AB.6010709@oracle.com> Message-ID: <58C97E6D.1000000@oracle.com> I see the fix was just pushed. But my comments are clearly not addressed. -phil. On 3/15/17, 10:11 AM, Philip Race wrote: > Does this actually try to address everything they complained about here > > http://stackoverflow.com/questions/41117190/java-9-on-windows-with-large-fonts > > which points to an image : https://i.stack.imgur.com/fgpBu.png > > Check boxes are some of it but not all of it. > > There is what appears to be a custom icon there - the black outlined > yellow zig-zg shape - and I don't see how we can draw that ourselves. > > Which is why I asked in the bug report if we had looked at how we are > doing image scaling. > It may be that we are already doing the best we can but I don't know > that .. > > -phil. > > On 3/15/17, 8:35 AM, Sergey Bylokhov wrote: >>> On 3/14/2017 7:31 PM, Sergey Bylokhov wrote: >>>> The initial image at [1] also show some issues in the submenu >>>> pointer and the menu corners, did we solve them already? >>> The submenu icon is updated in the current fix and the issue with >>> a menu corner is covered by the fix >>> JDK-8162350 RepaintManager shifts repainted region when the >>> floating point UI scale is used >> Thanks, Looks fine. >> >>> Thanks, >>> Alexandr. >>>> [1] >>>> http://stackoverflow.com/questions/41117190/java-9-on-windows-with-large-fonts >>>> >>>>> Hello, >>>>> >>>>> Could you review the fix: >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8174845 >>>>> webrev: >>>>> http://cr.openjdk.java.net/~alexsch/8174845/webrev.00 >>>>> >>>>> Metal JCheckBox and JMenuItem icons are updated to be drawn by >>>>> ovals, arcs and polygons. >>>>> >>>>> The [1] folder contains screenshots how icons are drawn before the >>>>> fix (on the left side) and after the fix (on the right side) with >>>>> Default and Ocean Metal themes. >>>>> >>>>> [1] >>>>> http://cr.openjdk.java.net/~alexsch/8174845/screenshots/00 >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> From alexandr.scherbatiy at oracle.com Thu Mar 16 13:22:59 2017 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 16 Mar 2017 16:22:59 +0300 Subject: [9] Review request for 8174845 Bad scaling on Windows with large fonts with Java 9ea In-Reply-To: <58C97E6D.1000000@oracle.com> References: <9440fff8-47c1-8991-35b0-831f95cb1c88@oracle.com> <3E8F39A5-36CC-4945-9D19-C283FFBF1866@oracle.com> <1AC15E91-5533-44BC-B0D6-D146F4A98FE3@oracle.com> <58C975AB.6010709@oracle.com> <58C97E6D.1000000@oracle.com> Message-ID: I prepared the image [1] which contains the middle.gif icon from the MenuSelectionManagerDemo drawn with scales from the top to the bottom 1, 1.25, 1.5, 2 and the interpolation rendering hint from the left to the right: not set, NEAREST_NEIGHBOR, BILINEAR, BICUBIC. If it may sense to add some rendering hints for the icons drawing for scale higher that one I can file a separate issue on it. [1] http://cr.openjdk.java.net/~alexsch/8174845/image-icons/00/icon-image.png Thanks, Alexandr. On 3/15/2017 8:48 PM, Philip Race wrote: > I see the fix was just pushed. But my comments are clearly not addressed. > > -phil. > > On 3/15/17, 10:11 AM, Philip Race wrote: >> Does this actually try to address everything they complained about here >> >> http://stackoverflow.com/questions/41117190/java-9-on-windows-with-large-fonts >> >> which points to an image : https://i.stack.imgur.com/fgpBu.png >> >> Check boxes are some of it but not all of it. >> >> There is what appears to be a custom icon there - the black outlined >> yellow zig-zg shape - and I don't see how we can draw that ourselves. >> >> Which is why I asked in the bug report if we had looked at how we are >> doing image scaling. >> It may be that we are already doing the best we can but I don't know >> that .. >> >> -phil. >> >> On 3/15/17, 8:35 AM, Sergey Bylokhov wrote: >>>> On 3/14/2017 7:31 PM, Sergey Bylokhov wrote: >>>>> The initial image at [1] also show some issues in the submenu >>>>> pointer and the menu corners, did we solve them already? >>>> The submenu icon is updated in the current fix and the issue with >>>> a menu corner is covered by the fix >>>> JDK-8162350 RepaintManager shifts repainted region when the >>>> floating point UI scale is used >>> Thanks, Looks fine. >>> >>>> Thanks, >>>> Alexandr. >>>>> [1] >>>>> http://stackoverflow.com/questions/41117190/java-9-on-windows-with-large-fonts >>>>> >>>>>> Hello, >>>>>> >>>>>> Could you review the fix: >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8174845 >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~alexsch/8174845/webrev.00 >>>>>> >>>>>> Metal JCheckBox and JMenuItem icons are updated to be drawn by >>>>>> ovals, arcs and polygons. >>>>>> >>>>>> The [1] folder contains screenshots how icons are drawn before >>>>>> the fix (on the left side) and after the fix (on the right side) >>>>>> with Default and Ocean Metal themes. >>>>>> >>>>>> [1] >>>>>> http://cr.openjdk.java.net/~alexsch/8174845/screenshots/00 >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> From alexandr.scherbatiy at oracle.com Thu Mar 16 16:03:15 2017 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 16 Mar 2017 19:03:15 +0300 Subject: [9] Review request for 8176883 Enable antialiasing for Metal L&F icons on HiDPI display Message-ID: Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8176883 webrev: http://cr.openjdk.java.net/~alexsch/8176883/webrev.00 Metal RadioButton and RadioButtonMenuItem icons are not drawn smoothly on HiDPI displays especially with floating point scales like 1.25 and 1.5. The fix enables the antialiasing rendering hint for the radio button and radio button menu item if the passed graphics is scaled. The [1] folder contains screenshots how icons are drawn before the fix (on the left side) and after the fix (on the right side). [1] http://cr.openjdk.java.net/~alexsch/8176883/screenshots/00 Thanks, Alexandr. From philip.race at oracle.com Thu Mar 16 16:47:07 2017 From: philip.race at oracle.com (Phil Race) Date: Thu, 16 Mar 2017 09:47:07 -0700 Subject: [9] Review request for 8176883 Enable antialiasing for Metal L&F icons on HiDPI display In-Reply-To: References: Message-ID: <286b808c-8427-c7cb-c180-0e3a7200159e@oracle.com> Hi, It looks to me as if this applies AA rendering even when you are drawing using G2D calls. Why ? Also this clearly only helps Metal. Is that because only Metal has such problems ? I would doubt that. FWIW Motif L&F probably should not get this treatment. Also if the desktop is "remote" we should avoid AA. I believe we do that for text with Metal so there should be example of how to detect that somewhere. -phil. On 03/16/2017 09:03 AM, Alexandr Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8176883 > webrev: http://cr.openjdk.java.net/~alexsch/8176883/webrev.00 > > Metal RadioButton and RadioButtonMenuItem icons are not drawn > smoothly on HiDPI displays especially with floating point scales like > 1.25 and 1.5. > The fix enables the antialiasing rendering hint for the radio button > and radio button menu item if the passed graphics is scaled. > > The [1] folder contains screenshots how icons are drawn before the > fix (on the left side) and after the fix (on the right side). > > [1] http://cr.openjdk.java.net/~alexsch/8176883/screenshots/00 > > Thanks, > Alexandr. > From alexandr.scherbatiy at oracle.com Thu Mar 16 18:04:29 2017 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 16 Mar 2017 21:04:29 +0300 Subject: [9] Review request for 8176883 Enable antialiasing for Metal L&F icons on HiDPI display In-Reply-To: <286b808c-8427-c7cb-c180-0e3a7200159e@oracle.com> References: <286b808c-8427-c7cb-c180-0e3a7200159e@oracle.com> Message-ID: <98d4bd11-93b4-a059-8476-abc95c4ab561@oracle.com> Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8176883/webrev.01 - The SwingUtilities2.getAndSetAntialisingHintForScaledGraphics() sets the AA rendering hint only for local display. - The SwingUtilities2.setAntialiasingHintForScaledGraphics() method javadoc is updated to mention that the null AA rendering hint means that the passed graphics is not instance of Graphics2D. On 3/16/2017 7:47 PM, Phil Race wrote: > > Hi, > > It looks to me as if this applies AA rendering even when you > are drawing using G2D calls. Why ? I updated the methods javadoc. The passed aaHint to the method setAntialiasingHintForScaledGraphics() must be null for the non Graphics2D. > > Also this clearly only helps Metal. Is that because only Metal has > such problems ? > I would doubt that. > > FWIW Motif L&F probably should not get this treatment. The The Windows L&F already uses the AA hints by the fix JDK-8165594. The GTK L&F uses only integer UI scale factor. > Also if the desktop is "remote" we should avoid AA. I believe we do that > for text with Metal so there should be example of how to detect that > somewhere. I updated the fix. Thanks, Alexandr. > > -phil. > > On 03/16/2017 09:03 AM, Alexandr Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8176883 >> webrev: http://cr.openjdk.java.net/~alexsch/8176883/webrev.00 >> >> Metal RadioButton and RadioButtonMenuItem icons are not drawn >> smoothly on HiDPI displays especially with floating point scales like >> 1.25 and 1.5. >> The fix enables the antialiasing rendering hint for the radio >> button and radio button menu item if the passed graphics is scaled. >> >> The [1] folder contains screenshots how icons are drawn before the >> fix (on the left side) and after the fix (on the right side). >> >> [1] http://cr.openjdk.java.net/~alexsch/8176883/screenshots/00 >> >> Thanks, >> Alexandr. >> > From philip.race at oracle.com Thu Mar 16 18:16:34 2017 From: philip.race at oracle.com (Phil Race) Date: Thu, 16 Mar 2017 11:16:34 -0700 Subject: [9] Review request for 8176883 Enable antialiasing for Metal L&F icons on HiDPI display In-Reply-To: <98d4bd11-93b4-a059-8476-abc95c4ab561@oracle.com> References: <286b808c-8427-c7cb-c180-0e3a7200159e@oracle.com> <98d4bd11-93b4-a059-8476-abc95c4ab561@oracle.com> Message-ID: <63c5be24-42eb-63fd-1050-6ecb3fcac681@oracle.com> Hi, What I was referring to regarding "draws using G2D calls" was that paintIcon(..) looks like this 1335 Object aaHint = getAndSetAntialisingHintForScaledGraphics(g); 1336 1337 if (MetalLookAndFeel.usingOcean()) { 1338 paintOceanIcon(c, g, x, y); 1339 setAntialiasingHintForScaledGraphics(g, aaHint); 1340 return; 1341 } ... .. 1386 g.setColor(dotColor); 1387 g.fillOval(2, 2, 7, 7); << Why does Graphics.fillOval (etc) need to be A-Aed here ? 1388 } 1389 1390 g.translate(-x, -y); 1391 setAntialiasingHintForScaledGraphics(g, aaHint); 1392 } -phil. On 03/16/2017 11:04 AM, Alexandr Scherbatiy wrote: > > Hello, > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8176883/webrev.01 > > - The SwingUtilities2.getAndSetAntialisingHintForScaledGraphics() > sets the AA rendering hint only for local display. > - The SwingUtilities2.setAntialiasingHintForScaledGraphics() method > javadoc is updated to mention that the null AA rendering hint means > that the passed graphics is not instance of Graphics2D. > > On 3/16/2017 7:47 PM, Phil Race wrote: >> >> Hi, >> >> It looks to me as if this applies AA rendering even when you >> are drawing using G2D calls. Why ? > I updated the methods javadoc. The passed aaHint to the method > setAntialiasingHintForScaledGraphics() must be null for the non > Graphics2D. >> >> Also this clearly only helps Metal. Is that because only Metal has >> such problems ? >> I would doubt that. >> >> FWIW Motif L&F probably should not get this treatment. > The The Windows L&F already uses the AA hints by the fix JDK-8165594. > The GTK L&F uses only integer UI scale factor. >> Also if the desktop is "remote" we should avoid AA. I believe we do that >> for text with Metal so there should be example of how to detect that >> somewhere. > I updated the fix. > > Thanks, > Alexandr. >> >> -phil. >> >> On 03/16/2017 09:03 AM, Alexandr Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the fix: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8176883 >>> webrev: http://cr.openjdk.java.net/~alexsch/8176883/webrev.00 >>> >>> Metal RadioButton and RadioButtonMenuItem icons are not drawn >>> smoothly on HiDPI displays especially with floating point scales >>> like 1.25 and 1.5. >>> The fix enables the antialiasing rendering hint for the radio >>> button and radio button menu item if the passed graphics is scaled. >>> >>> The [1] folder contains screenshots how icons are drawn before the >>> fix (on the left side) and after the fix (on the right side). >>> >>> [1] http://cr.openjdk.java.net/~alexsch/8176883/screenshots/00 >>> >>> Thanks, >>> Alexandr. >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Thu Mar 16 18:46:26 2017 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 16 Mar 2017 21:46:26 +0300 Subject: [9] Review request for 8176883 Enable antialiasing for Metal L&F icons on HiDPI display In-Reply-To: <63c5be24-42eb-63fd-1050-6ecb3fcac681@oracle.com> References: <286b808c-8427-c7cb-c180-0e3a7200159e@oracle.com> <98d4bd11-93b4-a059-8476-abc95c4ab561@oracle.com> <63c5be24-42eb-63fd-1050-6ecb3fcac681@oracle.com> Message-ID: <2b8d92b6-8001-8e87-59dc-dbc510da5ab2@oracle.com> On 3/16/2017 9:16 PM, Phil Race wrote: > Hi, > > What I was referring to regarding "draws using G2D calls" was that > paintIcon(..) looks like this > > > 1335 Object aaHint = getAndSetAntialisingHintForScaledGraphics(g); > 1336 > 1337 if (MetalLookAndFeel.usingOcean()) { > 1338 paintOceanIcon(c, g, x, y); > 1339 setAntialiasingHintForScaledGraphics(g, aaHint); > 1340 return; > 1341 } > ... > .. > 1386 g.setColor(dotColor); > 1387 g.fillOval(2, 2, 7, 7); << Why does Graphics.fillOval (etc) need to be A-Aed here ? The graphics has floating point scale on HiDPI display with 150% scale. The given oval is the center circle in the radio button. It is not painted smooth with the UI scale 1.5. I prepared the screenshot with a radio button (top is before the fix and bottom is after the fix with AA rendering hint enabled) http://cr.openjdk.java.net/~alexsch/8176883/screenshots/00/metal-radio-button-150pcs.png Thanks, Alexandr. > 1388 } > 1389 > 1390 g.translate(-x, -y); > 1391 setAntialiasingHintForScaledGraphics(g, aaHint); > 1392 } > > -phil. > > On 03/16/2017 11:04 AM, Alexandr Scherbatiy wrote: >> >> Hello, >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8176883/webrev.01 >> >> - The SwingUtilities2.getAndSetAntialisingHintForScaledGraphics() >> sets the AA rendering hint only for local display. >> - The SwingUtilities2.setAntialiasingHintForScaledGraphics() method >> javadoc is updated to mention that the null AA rendering hint means >> that the passed graphics is not instance of Graphics2D. >> >> On 3/16/2017 7:47 PM, Phil Race wrote: >>> >>> Hi, >>> >>> It looks to me as if this applies AA rendering even when you >>> are drawing using G2D calls. Why ? >> I updated the methods javadoc. The passed aaHint to the method >> setAntialiasingHintForScaledGraphics() must be null for the non >> Graphics2D. >>> >>> Also this clearly only helps Metal. Is that because only Metal has >>> such problems ? >>> I would doubt that. >>> >>> FWIW Motif L&F probably should not get this treatment. >> The The Windows L&F already uses the AA hints by the fix JDK-8165594. >> The GTK L&F uses only integer UI scale factor. >>> Also if the desktop is "remote" we should avoid AA. I believe we do >>> that >>> for text with Metal so there should be example of how to detect that >>> somewhere. >> I updated the fix. >> >> Thanks, >> Alexandr. >>> >>> -phil. >>> >>> On 03/16/2017 09:03 AM, Alexandr Scherbatiy wrote: >>>> >>>> Hello, >>>> >>>> Could you review the fix: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8176883 >>>> webrev: http://cr.openjdk.java.net/~alexsch/8176883/webrev.00 >>>> >>>> Metal RadioButton and RadioButtonMenuItem icons are not drawn >>>> smoothly on HiDPI displays especially with floating point scales >>>> like 1.25 and 1.5. >>>> The fix enables the antialiasing rendering hint for the radio >>>> button and radio button menu item if the passed graphics is scaled. >>>> >>>> The [1] folder contains screenshots how icons are drawn before >>>> the fix (on the left side) and after the fix (on the right side). >>>> >>>> [1] http://cr.openjdk.java.net/~alexsch/8176883/screenshots/00 >>>> >>>> Thanks, >>>> Alexandr. >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Mar 16 19:54:00 2017 From: philip.race at oracle.com (Phil Race) Date: Thu, 16 Mar 2017 12:54:00 -0700 Subject: [9] Review request for 8176883 Enable antialiasing for Metal L&F icons on HiDPI display In-Reply-To: <2b8d92b6-8001-8e87-59dc-dbc510da5ab2@oracle.com> References: <286b808c-8427-c7cb-c180-0e3a7200159e@oracle.com> <98d4bd11-93b4-a059-8476-abc95c4ab561@oracle.com> <63c5be24-42eb-63fd-1050-6ecb3fcac681@oracle.com> <2b8d92b6-8001-8e87-59dc-dbc510da5ab2@oracle.com> Message-ID: OK. In that case I am fine with it. I expect a small swingmark hit but that is the price we need to pay here. -phil. On 03/16/2017 11:46 AM, Alexandr Scherbatiy wrote: > On 3/16/2017 9:16 PM, Phil Race wrote: >> Hi, >> >> What I was referring to regarding "draws using G2D calls" was that >> paintIcon(..) looks like this >> >> >> 1335 Object aaHint = getAndSetAntialisingHintForScaledGraphics(g); >> 1336 >> 1337 if (MetalLookAndFeel.usingOcean()) { >> 1338 paintOceanIcon(c, g, x, y); >> 1339 setAntialiasingHintForScaledGraphics(g, aaHint); >> 1340 return; >> 1341 } >> ... >> .. >> 1386 g.setColor(dotColor); >> 1387 g.fillOval(2, 2, 7, 7); << Why does Graphics.fillOval (etc) need to be A-Aed here ? > The graphics has floating point scale on HiDPI display with 150% scale. > The given oval is the center circle in the radio button. It is not > painted smooth with the UI scale 1.5. > I prepared the screenshot with a radio button (top is before the > fix and bottom is after the fix with AA rendering hint enabled) > http://cr.openjdk.java.net/~alexsch/8176883/screenshots/00/metal-radio-button-150pcs.png > > Thanks, > Alexandr. >> 1388 } >> 1389 >> 1390 g.translate(-x, -y); >> 1391 setAntialiasingHintForScaledGraphics(g, aaHint); >> 1392 } >> >> -phil. >> >> On 03/16/2017 11:04 AM, Alexandr Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8176883/webrev.01 >>> >>> - The SwingUtilities2.getAndSetAntialisingHintForScaledGraphics() >>> sets the AA rendering hint only for local display. >>> - The SwingUtilities2.setAntialiasingHintForScaledGraphics() >>> method javadoc is updated to mention that the null AA rendering hint >>> means that the passed graphics is not instance of Graphics2D. >>> >>> On 3/16/2017 7:47 PM, Phil Race wrote: >>>> >>>> Hi, >>>> >>>> It looks to me as if this applies AA rendering even when you >>>> are drawing using G2D calls. Why ? >>> I updated the methods javadoc. The passed aaHint to the method >>> setAntialiasingHintForScaledGraphics() must be null for the non >>> Graphics2D. >>>> >>>> Also this clearly only helps Metal. Is that because only Metal has >>>> such problems ? >>>> I would doubt that. >>>> >>>> FWIW Motif L&F probably should not get this treatment. >>> The The Windows L&F already uses the AA hints by the fix >>> JDK-8165594. >>> The GTK L&F uses only integer UI scale factor. >>>> Also if the desktop is "remote" we should avoid AA. I believe we do >>>> that >>>> for text with Metal so there should be example of how to detect that >>>> somewhere. >>> I updated the fix. >>> >>> Thanks, >>> Alexandr. >>>> >>>> -phil. >>>> >>>> On 03/16/2017 09:03 AM, Alexandr Scherbatiy wrote: >>>>> >>>>> Hello, >>>>> >>>>> Could you review the fix: >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8176883 >>>>> webrev: http://cr.openjdk.java.net/~alexsch/8176883/webrev.00 >>>>> >>>>> Metal RadioButton and RadioButtonMenuItem icons are not drawn >>>>> smoothly on HiDPI displays especially with floating point scales >>>>> like 1.25 and 1.5. >>>>> The fix enables the antialiasing rendering hint for the radio >>>>> button and radio button menu item if the passed graphics is scaled. >>>>> >>>>> The [1] folder contains screenshots how icons are drawn before >>>>> the fix (on the left side) and after the fix (on the right side). >>>>> >>>>> [1] http://cr.openjdk.java.net/~alexsch/8176883/screenshots/00 >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.bylokhov at oracle.com Fri Mar 17 20:37:02 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 17 Mar 2017 23:37:02 +0300 Subject: [9] Review Request: 8176544 Compilation error in plaf.metal.MetalBumps.Test6657026 Message-ID: Hello, Please review the fix for jdk9. This test uses "ToolBarBorder.MetalBumps" which is not accessible because it is not public. The code was updated to use ToolBarBorder which contains MetalBumps. I have rechecked that the updated version of the test fails/pass before/after the initial bug was fixed. Bug: https://bugs.openjdk.java.net/browse/JDK-8176544 Webrev can be found at: http://cr.openjdk.java.net/~serb/8176544/webrev,00 From philip.race at oracle.com Fri Mar 17 20:49:03 2017 From: philip.race at oracle.com (Phil Race) Date: Fri, 17 Mar 2017 13:49:03 -0700 Subject: [9] Review Request: 8176544 Compilation error in plaf.metal.MetalBumps.Test6657026 In-Reply-To: References: Message-ID: <4123c98b-04fe-26ab-7982-8eae29c03832@oracle.com> Fine by me. I am curious why a compilation failure wasn't found immediately ? -phil. On 03/17/2017 01:37 PM, Sergey Bylokhov wrote: > Hello, > Please review the fix for jdk9. > This test uses "ToolBarBorder.MetalBumps" which is not accessible because it is not public. > The code was updated to use ToolBarBorder which contains MetalBumps. > I have rechecked that the updated version of the test fails/pass before/after the initial bug was fixed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8176544 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8176544/webrev,00 From sergey.bylokhov at oracle.com Thu Mar 23 14:24:29 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 23 Mar 2017 17:24:29 +0300 Subject: [9] Review Request: 8177461 Wrong references are used in the javadoc in the java.desktop module Message-ID: <553C207F-3FC6-4A78-8F82-3F30E5150B19@oracle.com> Hello, Please review the fix for jdk9. In java.desktop module in a various places we use incorrect links. Most of them are in the documentation in non-public classes/methods(But there are two places in public API - specdiff is provided) Common issues: - The method is referenced without # - The method which have some parameters is referenced as ?#method()? instead of ?#method? or ?#method(ParameterDescription)" - The type which is referenced is not imported - The reference to non-existed method/type. - Copy pasted javadoc was removed. - The type was renamed (like AppReOpenedListener to AppReopenedListener) Bug: https://bugs.openjdk.java.net/browse/JDK-8177461 Webrev can be found at: http://cr.openjdk.java.net/~serb/8177461/webrev.00 Specdiff: http://cr.openjdk.java.net/~serb/8177461/specdiff/overview-summary.html From philip.race at oracle.com Mon Mar 27 22:41:38 2017 From: philip.race at oracle.com (Phil Race) Date: Mon, 27 Mar 2017 15:41:38 -0700 Subject: RFR: 8043773: Deprecate JComponent.AccessibleJComponent.AccessibleFocusHandler Message-ID: <1677eec4-aba7-7b06-61fd-76964be14438@oracle.com> webrev: http://cr.openjdk.java.net/~prr/8043773/ bug : https://bugs.openjdk.java.net/browse/JDK-8043773 This just deprecates the un-used, un-needed inner classs. A CCC was approved ages ago however the fix was never pushed and I can't find any evidence a code review was even submitted. Since this is really just a doc change we should be OK to still fix this I've done a full build including docs + it looks fine. -phil. From alexandr.scherbatiy at oracle.com Tue Mar 28 11:21:24 2017 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 28 Mar 2017 14:21:24 +0300 Subject: RFR: 8043773: Deprecate JComponent.AccessibleJComponent.AccessibleFocusHandler In-Reply-To: <1677eec4-aba7-7b06-61fd-76964be14438@oracle.com> References: <1677eec4-aba7-7b06-61fd-76964be14438@oracle.com> Message-ID: <18ab97a6-438f-dae6-79be-0d10d648c5d4@oracle.com> The fix looks good to me. Thanks, Alexandr. On 3/28/2017 1:41 AM, Phil Race wrote: > webrev: http://cr.openjdk.java.net/~prr/8043773/ > bug : https://bugs.openjdk.java.net/browse/JDK-8043773 > > This just deprecates the un-used, un-needed inner classs. > > A CCC was approved ages ago however the fix was never pushed and I > can't find > any evidence a code review was even submitted. > > Since this is really just a doc change we should be OK to still fix this > > I've done a full build including docs + it looks fine. > > -phil. From alexander.zvegintsev at oracle.com Tue Mar 28 12:35:04 2017 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Tue, 28 Mar 2017 15:35:04 +0300 Subject: RFR: 8043773: Deprecate JComponent.AccessibleJComponent.AccessibleFocusHandler In-Reply-To: <18ab97a6-438f-dae6-79be-0d10d648c5d4@oracle.com> References: <1677eec4-aba7-7b06-61fd-76964be14438@oracle.com> <18ab97a6-438f-dae6-79be-0d10d648c5d4@oracle.com> Message-ID: +1 Thanks, Alexander. On 28/03/2017 14:21, Alexandr Scherbatiy wrote: > > The fix looks good to me. > > Thanks, > Alexandr. > > On 3/28/2017 1:41 AM, Phil Race wrote: >> webrev: http://cr.openjdk.java.net/~prr/8043773/ >> bug : https://bugs.openjdk.java.net/browse/JDK-8043773 >> >> This just deprecates the un-used, un-needed inner classs. >> >> A CCC was approved ages ago however the fix was never pushed and I >> can't find >> any evidence a code review was even submitted. >> >> Since this is really just a doc change we should be OK to still fix this >> >> I've done a full build including docs + it looks fine. >> >> -phil. > From sergey.bylokhov at oracle.com Wed Mar 29 08:22:26 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 29 Mar 2017 11:22:26 +0300 Subject: RFR: 8043773: Deprecate JComponent.AccessibleJComponent.AccessibleFocusHandler In-Reply-To: <1677eec4-aba7-7b06-61fd-76964be14438@oracle.com> References: <1677eec4-aba7-7b06-61fd-76964be14438@oracle.com> Message-ID: Hi, Phil. Why the new form of @deprecated is not used? "@Deprecated(since = "9")" > > webrev: http://cr.openjdk.java.net/~prr/8043773/ > bug : https://bugs.openjdk.java.net/browse/JDK-8043773 > > This just deprecates the un-used, un-needed inner classs. > > A CCC was approved ages ago however the fix was never pushed and I can't find > any evidence a code review was even submitted. > > Since this is really just a doc change we should be OK to still fix this > > I've done a full build including docs + it looks fine. > > -phil. From alexandr.scherbatiy at oracle.com Wed Mar 29 10:40:58 2017 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 29 Mar 2017 14:40:58 +0400 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8177461 Wrong references are used in the javadoc in the java.desktop module In-Reply-To: <553C207F-3FC6-4A78-8F82-3F30E5150B19@oracle.com> References: <553C207F-3FC6-4A78-8F82-3F30E5150B19@oracle.com> Message-ID: The fix looks good to me. Thanks, Alexandr. On 23/03/17 18:24, Sergey Bylokhov wrote: > Hello, > Please review the fix for jdk9. > > In java.desktop module in a various places we use incorrect links. > Most of them are in the documentation in non-public classes/methods(But there are two places in public API - specdiff is provided) > > Common issues: > - The method is referenced without # > - The method which have some parameters is referenced as ?#method()? instead of ?#method? or ?#method(ParameterDescription)" > - The type which is referenced is not imported > - The reference to non-existed method/type. > - Copy pasted javadoc was removed. > - The type was renamed (like AppReOpenedListener to AppReopenedListener) > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8177461 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8177461/webrev.00 > Specdiff: http://cr.openjdk.java.net/~serb/8177461/specdiff/overview-summary.html From sergey.bylokhov at oracle.com Wed Mar 29 12:46:34 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 29 Mar 2017 15:46:34 +0300 Subject: [9] Review Request: 8177766 [TEST_BUG] JPopupMenu tests fails intermittently Message-ID: Hello, Please review the fix for jdk9. The problem is that these tests shows popup menu and expects that some specific menuitems will be selected after keyboard navigation. But some other test in the javax/swing/JPopupMenu/** moves the mouse to some specific position, which causes an auto-selection(in Aqua Look&Feel) of the menu item and wrong final test result. Note that if the tests are executed alone it is always passed(if the mouse is not under popup menu). Bug: https://bugs.openjdk.java.net/browse/JDK-8177766 Webrev can be found at: http://cr.openjdk.java.net/~serb/8177766/webrev.00 From yuri.nesterenko at oracle.com Wed Mar 29 13:00:57 2017 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Wed, 29 Mar 2017 16:00:57 +0300 Subject: [9] Review Request: 8177766 [TEST_BUG] JPopupMenu tests fails intermittently In-Reply-To: References: Message-ID: Looks fine. -yan On 03/29/2017 03:46 PM, Sergey Bylokhov wrote: > Hello, > Please review the fix for jdk9. > > The problem is that these tests shows popup menu and expects that some specific menuitems will be selected after keyboard navigation. But some other test in the javax/swing/JPopupMenu/** moves the mouse to some specific position, which causes an auto-selection(in Aqua Look&Feel) of the menu item and wrong final test result. Note that if the tests are executed alone it is always passed(if the mouse is not under popup menu). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8177766 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8177766/webrev.00 > From alexandr.scherbatiy at oracle.com Wed Mar 29 13:31:14 2017 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 29 Mar 2017 17:31:14 +0400 Subject: [9] Review Request: 8177766 [TEST_BUG] JPopupMenu tests fails intermittently In-Reply-To: References: Message-ID: The fix looks good to me. Thanks, Alexandr. On 29/03/17 16:46, Sergey Bylokhov wrote: > Hello, > Please review the fix for jdk9. > > The problem is that these tests shows popup menu and expects that some specific menuitems will be selected after keyboard navigation. But some other test in the javax/swing/JPopupMenu/** moves the mouse to some specific position, which causes an auto-selection(in Aqua Look&Feel) of the menu item and wrong final test result. Note that if the tests are executed alone it is always passed(if the mouse is not under popup menu). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8177766 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8177766/webrev.00 From mikhail.cherkasov at oracle.com Fri Mar 31 11:28:57 2017 From: mikhail.cherkasov at oracle.com (Mikhail Cherkasov) Date: Fri, 31 Mar 2017 14:28:57 +0300 Subject: [9] Review Request: 8177450: javax.swing.text.html.parser.Parser parseScript ignores a character after commend end Message-ID: Hello, Could you please review the fix for jdk9? The problem is that Parser reads extra symbol after comment or script tag and missed the symbol. I added 'continue' after those tags, so it goes to beginning of Parser while loop and process the symbol. Bug: https://bugs.openjdk.java.net/browse/JDK-8177450 Webrev: http://cr.openjdk.java.net/~mcherkas/8177450/9/webrev/ Thanks, Mikhail. -------------- next part -------------- An HTML attachment was scrubbed... URL: