From semyon.sadetsky at oracle.com Tue Oct 3 19:11:40 2017 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 3 Oct 2017 12:11:40 -0700 Subject: [10] Review request for 8182041: File Chooser Shortcut Panel folders under on JDK 9 Message-ID: Hello, Please review fix for JDK10 (the changes involve AWT and Swing): bug: https://bugs.openjdk.java.net/browse/JDK-8182041 webrev: http://cr.openjdk.java.net/~ssadetsky/8182041/webrev.00/ New API method was added letting to query shortcut panel entries for JFileChooser. --Semyon From alexandre.iline at oracle.com Wed Oct 4 18:13:50 2017 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Wed, 4 Oct 2017 11:13:50 -0700 Subject: RFR 8188779: Synchronize test/jdk/sanity/client/lib/jemmy with code-tools/jemmy/v2 Message-ID: Hi, Please take a look on the set of changes brought into JDK Jemmy copy from the code-tools Jemmy repository. The changes include next fixes and enhancements 1. CODETOOLS-7901931: JFileChooserOperator.enterSubDir does not navigate to sub directory 2. CODETOOLS-7901925: Add subcomponents accessor methods to JColorChooserOperator 3. other minor enhancements which were done while the repositories were not synchronized. 4. Change of README file to point to proper Jemmy repository Bug: https://bugs.openjdk.java.net/browse/JDK-8188779 Webrev: http://cr.openjdk.java.net/~shurailine/8188779/webrev.00/ Thank you Shura From Koen.VanDenBorre at esko.com Thu Oct 5 10:32:14 2017 From: Koen.VanDenBorre at esko.com (Van Den Borre, Koen) Date: Thu, 5 Oct 2017 10:32:14 +0000 Subject: Issue with setComponentPopupMenu Message-ID: <085E7B01-7E1C-49DD-BFD8-3D21C151D15E@esko.com> Hey, I am seeing an issue when using setComponentPopupMenu. When you use setComponentPopupMenu in a window and create a modeless dialog and position that over that window. A contextual menu click in the modeless dialog will show the contextual men of the component in the parent window. I traced the issue down to processMouseEvent in the Container class. There, a call is made to trackMouseEnterExit which will create and dispatch a MouseEvent.MOUSE_ENTERED mouse event. This generated mouse event still has the isPopupTrigger attribute set to true which will then triggers the componentPopupMenu to be shown. As always an example says more that a thousand words: import javax.swing.JDialog; import javax.swing.JFrame; import javax.swing.JLabel; import javax.swing.JMenuItem; import javax.swing.JPopupMenu; import javax.swing.SwingUtilities; public class ComponentPopupMenuTest { public static void main(String[] args) { SwingUtilities.invokeLater(new Runnable() { @Override public void run() { test(); } }); } private static void test() { JPopupMenu popupMenu = new JPopupMenu(); popupMenu.add(new JMenuItem("You should not see me")); JFrame frame = new JFrame("Main Frame"); frame.getRootPane().setComponentPopupMenu(popupMenu); frame.setSize(400, 400); frame.setLocation(0, 0); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); frame.setVisible(true); JDialog dialog = new JDialog(frame, "Modeless Dialog", false); dialog.getContentPane().add(new JLabel("Do a contextual mouse click here")); dialog.setSize(300, 300); dialog.setLocation(50, 50); dialog.setDefaultCloseOperation(JDialog.DISPOSE_ON_CLOSE); dialog.setVisible(true); } } Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment. From Koen.VanDenBorre at esko.com Thu Oct 5 10:35:48 2017 From: Koen.VanDenBorre at esko.com (Van Den Borre, Koen) Date: Thu, 5 Oct 2017 10:35:48 +0000 Subject: Issue with setComponentPopupMenu In-Reply-To: <085E7B01-7E1C-49DD-BFD8-3D21C151D15E@esko.com> References: <085E7B01-7E1C-49DD-BFD8-3D21C151D15E@esko.com> Message-ID: <2D79C5DD-DF3C-47D0-BAE9-F30B7B4BD3C1@esko.com> I forgot to mention that I see this behavior on macOS Sierra 10.12.6 (16G29) java version "1.8.0_152-ea" Java(TM) SE Runtime Environment (build 1.8.0_152-ea-b05) Java HotSpot(TM) 64-Bit Server VM (build 25.152-b05, mixed mode) On 5 Oct 2017, at 12:32, Van Den Borre, Koen > wrote: Hey, I am seeing an issue when using setComponentPopupMenu. When you use setComponentPopupMenu in a window and create a modeless dialog and position that over that window. A contextual menu click in the modeless dialog will show the contextual men of the component in the parent window. I traced the issue down to processMouseEvent in the Container class. There, a call is made to trackMouseEnterExit which will create and dispatch a MouseEvent.MOUSE_ENTERED mouse event. This generated mouse event still has the isPopupTrigger attribute set to true which will then triggers the componentPopupMenu to be shown. As always an example says more that a thousand words: import javax.swing.JDialog; import javax.swing.JFrame; import javax.swing.JLabel; import javax.swing.JMenuItem; import javax.swing.JPopupMenu; import javax.swing.SwingUtilities; public class ComponentPopupMenuTest { public static void main(String[] args) { SwingUtilities.invokeLater(new Runnable() { @Override public void run() { test(); } }); } private static void test() { JPopupMenu popupMenu = new JPopupMenu(); popupMenu.add(new JMenuItem("You should not see me")); JFrame frame = new JFrame("Main Frame"); frame.getRootPane().setComponentPopupMenu(popupMenu); frame.setSize(400, 400); frame.setLocation(0, 0); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); frame.setVisible(true); JDialog dialog = new JDialog(frame, "Modeless Dialog", false); dialog.getContentPane().add(new JLabel("Do a contextual mouse click here")); dialog.setSize(300, 300); dialog.setLocation(50, 50); dialog.setDefaultCloseOperation(JDialog.DISPOSE_ON_CLOSE); dialog.setVisible(true); } } Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment. Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Oct 5 15:58:14 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 5 Oct 2017 08:58:14 -0700 Subject: RFR 8188779: Synchronize test/jdk/sanity/client/lib/jemmy with code-tools/jemmy/v2 In-Reply-To: References: Message-ID: <67afe9de-beba-6772-8076-98198c7445e7@oracle.com> Looks fine. On 10/4/17 11:13, Alexandre (Shura) Iline wrote: > Hi, > > Please take a look on the set of changes brought into JDK Jemmy copy from the code-tools Jemmy repository. > > The changes include next fixes and enhancements > 1. CODETOOLS-7901931: JFileChooserOperator.enterSubDir does not navigate to sub directory > 2. CODETOOLS-7901925: Add subcomponents accessor methods to JColorChooserOperator > 3. other minor enhancements which were done while the repositories were not synchronized. > 4. Change of README file to point to proper Jemmy repository > > Bug: https://bugs.openjdk.java.net/browse/JDK-8188779 > Webrev: http://cr.openjdk.java.net/~shurailine/8188779/webrev.00/ > > Thank you > > Shura > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Thu Oct 5 16:01:55 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 5 Oct 2017 09:01:55 -0700 Subject: Issue with setComponentPopupMenu In-Reply-To: <2D79C5DD-DF3C-47D0-BAE9-F30B7B4BD3C1@esko.com> References: <085E7B01-7E1C-49DD-BFD8-3D21C151D15E@esko.com> <2D79C5DD-DF3C-47D0-BAE9-F30B7B4BD3C1@esko.com> Message-ID: Hello. Thank you for the report. Could you please create CR for this bug here: http://bugreport.java.com/bugreport On 10/5/17 03:35, Van Den Borre, Koen wrote: > I forgot to mention that I see this behavior on macOS Sierra?10.12.6 > (16G29) > > java version "1.8.0_152-ea" > Java(TM) SE Runtime Environment (build 1.8.0_152-ea-b05) > Java HotSpot(TM) 64-Bit Server VM (build 25.152-b05, mixed mode) > >> On 5 Oct 2017, at 12:32, Van Den Borre, Koen >> > wrote: >> >> Hey, >> >> I am seeing an issue when using setComponentPopupMenu. >> >> When you use setComponentPopupMenu in a window and create a modeless >> dialog and position that over that window. A contextual menu click in >> the modeless dialog will show the contextual men of the component in >> the parent window. >> >> I traced the issue down to processMouseEvent in the Container class. >> There, a call is made to trackMouseEnterExit which will create and >> dispatch a MouseEvent.MOUSE_ENTERED mouse event. >> >> This generated mouse event still has the isPopupTrigger attribute set >> to true which will then triggers the componentPopupMenu to be shown. >> >> As always an example says more that a thousand words: >> >> import javax.swing.JDialog; >> import javax.swing.JFrame; >> import javax.swing.JLabel; >> import javax.swing.JMenuItem; >> import javax.swing.JPopupMenu; >> import javax.swing.SwingUtilities; >> >> public class ComponentPopupMenuTest { >> public static void main(String[] args) { >> SwingUtilities.invokeLater(new Runnable() { >> @Override >> public void run() { >> test(); >> } >> }); >> } >> >> private static void test() { >> JPopupMenu popupMenu = new JPopupMenu(); >> popupMenu.add(new JMenuItem("You should not see me")); >> >> JFrame frame = new JFrame("Main Frame"); >> frame.getRootPane().setComponentPopupMenu(popupMenu); >> frame.setSize(400, 400); >> frame.setLocation(0, 0); >> frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); >> frame.setVisible(true); >> >> JDialog dialog = new JDialog(frame, "Modeless Dialog", false); >> dialog.getContentPane().add(new JLabel("Do a contextual mouse click >> here")); >> dialog.setSize(300, 300); >> dialog.setLocation(50, 50); >> dialog.setDefaultCloseOperation(JDialog.DISPOSE_ON_CLOSE); >> dialog.setVisible(true); >> } >> } >> >> >> Please be advised that this email may contain confidential >> information. If you are not the intended recipient, please notify us >> by email by replying to the sender and delete this message. The sender >> disclaims that the content of this email constitutes an offer to enter >> into, or the acceptance of, any agreement; provided that the foregoing >> does not invalidate the binding effect of any digital or other >> electronic reproduction of a manual signature that is included in any >> attachment. > > Please be advised that this email may contain confidential information. > If you are not the intended recipient, please notify us by email by > replying to the sender and delete this message. The sender disclaims > that the content of this email constitutes an offer to enter into, or > the acceptance of, any agreement; provided that the foregoing does not > invalidate the binding effect of any digital or other electronic > reproduction of a manual signature that is included in any attachment. -- Best regards, Sergey. From semyon.sadetsky at oracle.com Thu Oct 5 16:14:57 2017 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 5 Oct 2017 09:14:57 -0700 Subject: RFR 8188779: Synchronize test/jdk/sanity/client/lib/jemmy with code-tools/jemmy/v2 In-Reply-To: References: Message-ID: <38ac9384-a5dd-f954-e9ce-7e43b822e16b@oracle.com> +1 --Semyon On 10/04/2017 11:13 AM, Alexandre (Shura) Iline wrote: > Hi, > > Please take a look on the set of changes brought into JDK Jemmy copy from the code-tools Jemmy repository. > > The changes include next fixes and enhancements > 1. CODETOOLS-7901931: JFileChooserOperator.enterSubDir does not navigate to sub directory > 2. CODETOOLS-7901925: Add subcomponents accessor methods to JColorChooserOperator > 3. other minor enhancements which were done while the repositories were not synchronized. > 4. Change of README file to point to proper Jemmy repository > > Bug: https://bugs.openjdk.java.net/browse/JDK-8188779 > Webrev: http://cr.openjdk.java.net/~shurailine/8188779/webrev.00/ > > Thank you > > Shura > From Sergey.Bylokhov at oracle.com Thu Oct 5 22:20:54 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 5 Oct 2017 15:20:54 -0700 Subject: [10] Review request for 8182043: Access to Windows Large Icons In-Reply-To: <59CED263.4000104@oracle.com> References: <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com> <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com> <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com> <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com> <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com> <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com> <59CEA177.5010305@oracle.com> <6b4d35b9-2d1f-0010-a7b6-ed2e17dfa661@oracle.com> <59CED263.4000104@oracle.com> Message-ID: <94176865-6907-5933-8b4f-818895a26012@oracle.com> On 9/29/17 16:08, Semyon Sadetsky wrote: > On 9/29/2017 3:15 PM, Sergey Bylokhov wrote: >> On 9/29/17 12:39, Semyon Sadetsky wrote: >>>>> Why 128 pixels? Windows shell usually provides icons up to 256 >>>>> pixels, for example there are 256?256 icons for folders and generic >>>>> file type. >>>> >>>> It is limitation of our implementation: >>>> https://bugs.openjdk.java.net/browse/JDK-8151385 >>>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010777.html >>>> >>> Sergey, it is not clear how those links are related to the icon size >>> returned by Windows? >> >> It was a fix where the MAX_ICON_SIZE=128 was added. > Actually it limits nothing. We told about the Extract call which may > return any size. I do not understand how it could be "that it limits nothing". The method "makeIcon(long hIcon, int bsize)" is the only place where we create BufferedImage which contains the data of icon, and this content cannot be bigger than 128x128 pixels because of MAX_ICON_SIZE=128 >> >> And every time we will try to make an icon it will be limited to >> 128x128. But it is not critical. >> >> The issue is that this api, as you said, will depends from some >> general "current scale". which is unrelated to the transform of the >> screen in java. >> >> If the user will want to use FILE_ICON_LARGE, then to work properly he >> will need to use this code every time in the the paint(): >> Icon icon = getSystemIcon(file, FILE_ICON_LARGE); >> Icon hicon = getSystemIcon(file, icon.getIconWidth()*currentScreenScale); > This is just wrong. The first line is the correct one for both HiDPI and > nonHiDPI. If you want to have icons like in native apps. For custom > behavior - please use the second line. Why it is wrong? If the native application will request the large icon, get the icon of size=32 and draw it to the screen, then the user will see the icon inside 32x32 pixels on the screen. If the same steps will be done in java the the user will see the icon inside 64x64 pixels, because we will apply the java scale on top of the native scale. In case of different dpi for a different screens we will get the similar bug, because the icon which include the native scale is not applicable for the low-dpi screen. -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Fri Oct 6 11:12:41 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 6 Oct 2017 16:42:41 +0530 Subject: [10] RFR JDK-8187989: Documentation error in JComponent.paintComponent Message-ID: <68d45239-11a2-2282-5a3c-12126a60e881@oracle.com> Hi All, Please review a doc fix where it mentioned in JComponent.paintComponent() > if this component is opaque, you must completely fill in the background in a non-opaque color It should read "opaque color", or "non-transparent color". webrev:http://cr.openjdk.java.net/~psadhukhan/8187989/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8187989 Regards Prasanta From semyon.sadetsky at oracle.com Fri Oct 6 14:58:55 2017 From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com) Date: Fri, 6 Oct 2017 07:58:55 -0700 Subject: [10] RFR JDK-8187989: Documentation error in JComponent.paintComponent In-Reply-To: <68d45239-11a2-2282-5a3c-12126a60e881@oracle.com> References: <68d45239-11a2-2282-5a3c-12126a60e881@oracle.com> Message-ID: <64b9acbb-4564-a5a7-fc32-14c965fcdd7f@oracle.com> +1 --Semyon On 10/6/17 4:12 AM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a doc fix where it mentioned in JComponent.paintComponent() > > > if this component is opaque, you must completely fill in the > background in a non-opaque color > It should read "opaque color", or "non-transparent color". > > webrev:http://cr.openjdk.java.net/~psadhukhan/8187989/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8187989 > > Regards > Prasanta From alexey.ivanov at oracle.com Fri Oct 6 16:53:29 2017 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 6 Oct 2017 17:53:29 +0100 Subject: [10] Review request for 8182043: Access to Windows Large Icons In-Reply-To: References: <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com> <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com> <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com> <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com> <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com> <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com> Message-ID: <2ef8eb3e-a1e1-5d86-a5a2-7cc9cc614f07@oracle.com> Hi Sergey, Sorry for a long delay? On 29/09/2017 20:29, Sergey Bylokhov wrote: > On 9/29/17 07:34, Alexey Ivanov wrote: >>> Ok, so it means that we will support 1-128 pixels >>> natively(MAX_ICON_SIZE) and others via MRI. >> >> Why 128 pixels? Windows shell usually provides icons up to 256 >> pixels, for example there are 256?256 icons for folders and generic >> file type. > > It is limitation of our implementation: > https://bugs.openjdk.java.net/browse/JDK-8151385 > http://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010777.html I see. And it can be changed, if deemed necessary, can't it? > >> >> Since |IExtractIcon::Extract| gives you the requested size, >> performing scaling if required, then MRI will never be crea > > As far as I understand the bug above, it is possible that OS returns > some other size. No, it is not. In that bug icons are extracted from Image List which is created a part of Toolbar: 1036 ??? HWND hWndToolbar = ::CreateWindowEx(0, TOOLBARCLASSNAME, NULL, Then an icon is extracted from that image list. Obviously, Toolbar can create and creates, as the bug report shows, its icon set of different size depending on the current DPI setting, or rather the DPI settings of the main display. As for JOptionPane, the icons are loaded using ::LoadIcon which loads icon of the default size only. Depending on the current DPI setting, it may return icon of larger size. Yet in this fix, the file icon is requested with explicit size. You will get the size you requested. Regards, Alexey From alexey.ivanov at oracle.com Fri Oct 6 17:01:08 2017 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 6 Oct 2017 18:01:08 +0100 Subject: [10] Review request for 8182043: Access to Windows Large Icons In-Reply-To: <59CEA177.5010305@oracle.com> References: <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com> <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com> <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com> <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com> <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com> <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com> <59CEA177.5010305@oracle.com> Message-ID: Hi Semyon, On 29/09/2017 20:39, Semyon Sadetsky wrote: > > > On 9/29/2017 12:29 PM, Sergey Bylokhov wrote: >> On 9/29/17 07:34, Alexey Ivanov wrote: >>>> Ok, so it means that we will support 1-128 pixels >>>> natively(MAX_ICON_SIZE) and others via MRI. >>> >>> Why 128 pixels? Windows shell usually provides icons up to 256 >>> pixels, for example there are 256?256 icons for folders and generic >>> file type. >> >> It is limitation of our implementation: >> https://bugs.openjdk.java.net/browse/JDK-8151385 >> http://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010777.html >> > Sergey, it is not clear how those links are related to the icon size > returned by Windows? >>> >>> Since |IExtractIcon::Extract| gives you the requested size, >>> performing scaling if required, then MRI will never be crea >> >> As far as I understand the bug above, it is possible that OS returns >> some other size. > You've probably didn't understand what Alexey meant. The Extract call > may return any size you request (it does scaling internally if there > are no suitable image). Yes, that's what I meant. IExtractIcon::Extract always returns the size you requested, if necessary it does internal scaling. > But the bug above is about queering the fixed size (small or long) > which size is determined by OS shell according to the current scale. > For those fixed sizes we use SHGetFileInfo not the Extract. However, I'm afraid IExtractIcon::Extract does not scale the icon to the current DPI scaling, it's the task of the programmer to request the icon size that's required in current scaling settings to make sure the icon is crisp. Regards, Alexey > > > --Semyon From alexey.ivanov at oracle.com Fri Oct 6 18:42:14 2017 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 6 Oct 2017 19:42:14 +0100 Subject: [10] Review request for 8182043: Access to Windows Large Icons In-Reply-To: <59CED263.4000104@oracle.com> References: <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com> <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com> <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com> <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com> <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com> <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com> <59CEA177.5010305@oracle.com> <6b4d35b9-2d1f-0010-a7b6-ed2e17dfa661@oracle.com> <59CED263.4000104@oracle.com> Message-ID: <4cb5fc2d-ea4e-5878-135c-79c368e72bd5@oracle.com> Hi Semyon, Sergey, On 30/09/2017 00:08, Semyon Sadetsky wrote: > On 9/29/2017 3:15 PM, Sergey Bylokhov wrote: >> On 9/29/17 12:39, Semyon Sadetsky wrote: >>>>> Why 128 pixels? Windows shell usually provides icons up to 256 >>>>> pixels, for example there are 256?256 icons for folders and >>>>> generic file type. >>>> >>>> It is limitation of our implementation: >>>> https://bugs.openjdk.java.net/browse/JDK-8151385 >>>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010777.html >>>> >>> Sergey, it is not clear how those links are related to the icon size >>> returned by Windows? >> >> It was a fix where the MAX_ICON_SIZE=128 was added. > Actually it limits nothing. We told about the Extract call which may > return any size. Yes, it does. It limits the size of the returned icon to 128?128. I guess if a larger icon is requested, then we'll get a distorted image. >>>> As far as I understand the bug above, it is possible that OS >>>> returns some other size. >>> You've probably didn't understand what Alexey meant. The Extract >>> call may return any size you request (it does scaling internally if >>> there are no suitable image) > But the bug above is about queering >>> the fixed size >>> (small or long) which size is determined by OS shell according to >>> the current scale. For those fixed sizes we use SHGetFileInfo not >>> the Extract. >> >> And every time we will try to make an icon it will be limited to >> 128x128. But it is not critical. >> >> The issue is that this api, as you said, will depends from some >> general "current scale". which is unrelated to the transform of the >> screen in java. >> >> If the user will want to use FILE_ICON_LARGE, then to work properly >> he will need to use this code every time in the the paint(): >> Icon icon = getSystemIcon(file, FILE_ICON_LARGE); >> Icon hicon = getSystemIcon(file, >> icon.getIconWidth()*currentScreenScale); > This is just wrong. The first line is the correct one for both HiDPI > and nonHiDPI. If you want to have icons like in native apps. For > custom behavior - please use the second line. > Why is it wrong? getSystemIcon(file) requests FILE_ICON_SMALL from the OS, then all Java has to paint at any DPI scale is 16?16 icon. Or am I missing anything? Regards, Alexey From alexey.ivanov at oracle.com Fri Oct 6 19:13:37 2017 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 6 Oct 2017 20:13:37 +0100 Subject: [10] Review request for 8182043: Access to Windows Large Icons In-Reply-To: <33b00e0b-5b67-4a32-a4ee-fcdc32099071@oracle.com> References: <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com> <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com> <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com> <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com> <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com> <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com> <59CAC884.6070207@oracle.com> <59CD37FA.8010805@oracle.com> <0ee0bd28-bf23-b726-97b4-8bbde57e65bc@oracle.com> <33b00e0b-5b67-4a32-a4ee-fcdc32099071@oracle.com> Message-ID: <0d84a309-447d-9a4c-83c5-f3c560f6aeee@oracle.com> Hi Sergey, On 29/09/2017 22:06, Sergey Bylokhov wrote: > On 9/29/17 07:11, Alexey Ivanov wrote: >> If I understand correctly, the introduction of the new API does not >> change the behaviour in this case, does it? >> >> The icon extracted from Windows was 16?16 and will continue to be used. >> That is the icon will be scaled when painted. >> >> To support HiDPI displays the implementation of >> |getFileChooser().getFileSystemView().getSystemIcon(f)| should be >> enhanced to fetch the icon at the appropriate size according to the >> current rendering scale. I mean in standard resolution, get 16?16 >> icon, for 125% scale factor, get 20?20 icon, for 150% scale factor, >> get icon 24?24. (As far as I know, |IExtractIcon::Extract| does not >> perform any scaling to account for HiDPI rendering. And it really >> can't because different displays can have different DPI settings. >> Thus if you request icon size of 16?16, you'll get 16?16 icon, not >> 32?32 even if this size is more appropriate to the current HiDPI >> scaling.) > > Yes, the old getSystemIcon(f) can be enhanced to support MRI and this > will fix all its usages. But my point was for a new API and how this > new API can solve the problem of access to different dpi icons. > ?- We cannot use FILE_ICON_SMALL because it does not depend from the > screen, and it is unclear what the small icons means. > ?- We cannot use FILE_ICON_LARGE by the same reason. > ?- We cannot request some specific size because we know the scale > which should be applied to the default icon, but we do not know the > size of the default icon. > So everywhere we should do something like this: > Icon icon = getSystemIcon(file); > Icon hicon = getSystemIcon(file, icon.getIconWidth()*screenScale); I think getSystemIcon(file) could be re-implemented as a call to getSystemIcon(file, SMALL_ICON_SIZE * screenScale). The only problem is that screenScale is unknown, it cannot be determined in advance, right? >> Different icon sizes could be combined into MRI lazily. >> To support it, we could use different APIs to extract the icons. For >> example, we can get the list of icon sizes for a file type, and >> extract only ?native? size. If larger size is required for HiDPI and >> the icon has it, then get the larger version and use it for rendering >> rather than scaling the one we already have. > > It is not necessary to update other parts of the Swing right now, but > it should be possible to update it later and use the new API which > will be added in this fix, since this fix is a about access to a good > quality icons, some comments here: > https://bugs.openjdk.java.net/browse/JDK-8156183 No, I didn't mean to update other parts. Since Swing operates logical coordinates, getting larger icon size from the underlying OS should be hidden from user. It could be done via MRI. But to request the right physical pixel size of the icon, it's necessary to know the current scaling factor in Graphics. Alternative is to get the entire set from the OS: for example if icon of SMALL_ICON_SIZE, i.e. 16?16, is requested, then the getSystemIcon(file) returns MRI which contains the following sizes: 16, 20, 24, 32. However, it means we'll waste system resources by requesting extra sizes that we'll throw away as soon as paint completes. To optimize this solution, the API can request only the sizes that correspond to screen DPI. For example, if there's only one display in the system, the only one (scaled) size is requested; if there are two displays, the returned MRI contains physical-sized icons for either display if their DPI settings are different. Regards, Alexey > >> >> However, it looks to be out of the scope for this particular fix. Yet >> this approach will make UI look crispier at higher resolutions. > > > From Sergey.Bylokhov at oracle.com Fri Oct 6 19:38:33 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 6 Oct 2017 12:38:33 -0700 Subject: [10] Review request for 8182043: Access to Windows Large Icons In-Reply-To: <2ef8eb3e-a1e1-5d86-a5a2-7cc9cc614f07@oracle.com> References: <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com> <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com> <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com> <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com> <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com> <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com> <2ef8eb3e-a1e1-5d86-a5a2-7cc9cc614f07@oracle.com> Message-ID: On 10/6/17 09:53, Alexey Ivanov wrote: >> It is limitation of our implementation: >> https://bugs.openjdk.java.net/browse/JDK-8151385 >> http://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010777.html > > I see. And it can be changed, if deemed necessary, can't it? Yes we can. >> As far as I understand the bug above, it is possible that OS returns >> some other size. > > No, it is not. > In that bug icons are extracted from Image List which is created a part > of Toolbar: > > 1036 ??? HWND hWndToolbar = ::CreateWindowEx(0, TOOLBARCLASSNAME, NULL, > > Then an icon is extracted from that image list. > Obviously, Toolbar can create and creates, as the bug report shows, its > icon set of different size depending on the current DPI setting, or > rather the DPI settings of the main display. > > As for JOptionPane, the icons are loaded using ::LoadIcon which loads > icon of the default size only. Depending on the current DPI setting, it > may return icon of larger size. > > > Yet in this fix, the file icon is requested with explicit size. You will > get the size you requested. Probably we have some other bug in the fix, but unfortunately I cannot confirm behavior you describe. For example if I request the icon for some pdf,java.txt files of size 100m then: - On HiDPI screen I get the native icon of size 64. - On LowDPI screen I get the native icon of size 32. In both cases the user will get MRI, which will scale the native icon. -- Best regards, Sergey. From alexey.ivanov at oracle.com Fri Oct 6 20:00:13 2017 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 6 Oct 2017 21:00:13 +0100 Subject: [10] Review request for 8182043: Access to Windows Large Icons In-Reply-To: References: <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com> <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com> <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com> <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com> <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com> <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com> <2ef8eb3e-a1e1-5d86-a5a2-7cc9cc614f07@oracle.com> Message-ID: <5d366454-6afe-0f3a-d79a-d015ca7a2b21@oracle.com> Hi Sergey, On 06/10/2017 20:38, Sergey Bylokhov wrote: > On 10/6/17 09:53, Alexey Ivanov wrote: >>> It is limitation of our implementation: >>> https://bugs.openjdk.java.net/browse/JDK-8151385 >>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010777.html >> >> I see. And it can be changed, if deemed necessary, can't it? > > Yes we can. > >>> As far as I understand the bug above, it is possible that OS returns >>> some other size. >> >> No, it is not. >> In that bug icons are extracted from Image List which is created a >> part of Toolbar: >> >> 1036 ??? HWND hWndToolbar = ::CreateWindowEx(0, TOOLBARCLASSNAME, NULL, >> >> Then an icon is extracted from that image list. >> Obviously, Toolbar can create and creates, as the bug report shows, >> its icon set of different size depending on the current DPI setting, >> or rather the DPI settings of the main display. >> >> As for JOptionPane, the icons are loaded using ::LoadIcon which loads >> icon of the default size only. Depending on the current DPI setting, >> it may return icon of larger size. >> >> >> Yet in this fix, the file icon is requested with explicit size. You >> will get the size you requested. > > Probably we have some other bug in the fix, but unfortunately I cannot > confirm behavior you describe. For example if I request the icon for > some pdf,java.txt files of size 100m then: > ?- On HiDPI screen I get the native icon of size 64. > ?- On LowDPI screen I get the native icon of size 32. > In both cases the user will get MRI, which will scale the native icon. I tested it myself. For some reason, in some cases the icon looks crisp, in other cases it is scaled: At 200% the icons look this way: Icon Java / JFileChooser Paint / Open dialog This PC DPI shortcut In the second row, the icon is obviously correct because the small icon is flat. Regards, Alexey -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hbgmamicdmgelolp.png Type: image/png Size: 994 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ocaadlodhdhkgeon.png Type: image/png Size: 2220 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pjfelinklmcmgdld.png Type: image/png Size: 2691 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: midjlhnbgoiclgdp.png Type: image/png Size: 2698 bytes Desc: not available URL: From semyon.sadetsky at oracle.com Fri Oct 6 20:01:41 2017 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 6 Oct 2017 13:01:41 -0700 Subject: [10] Review request for 8182043: Access to Windows Large Icons In-Reply-To: References: <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com> <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com> <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com> <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com> <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com> <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com> <2ef8eb3e-a1e1-5d86-a5a2-7cc9cc614f07@oracle.com> Message-ID: On 10/06/2017 12:38 PM, Sergey Bylokhov wrote: > On 10/6/17 09:53, Alexey Ivanov wrote: >>> It is limitation of our implementation: >>> https://bugs.openjdk.java.net/browse/JDK-8151385 >>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010777.html >> >> I see. And it can be changed, if deemed necessary, can't it? > > Yes we can. Since you were the person who approved this fix can you explain why the limitation was introduced? We can decide whether this limitation should be reverted in a separate bug. > >>> As far as I understand the bug above, it is possible that OS returns >>> some other size. >> >> No, it is not. >> In that bug icons are extracted from Image List which is created a >> part of Toolbar: >> >> 1036 HWND hWndToolbar = ::CreateWindowEx(0, TOOLBARCLASSNAME, NULL, >> >> Then an icon is extracted from that image list. >> Obviously, Toolbar can create and creates, as the bug report shows, >> its icon set of different size depending on the current DPI setting, >> or rather the DPI settings of the main display. >> >> As for JOptionPane, the icons are loaded using ::LoadIcon which loads >> icon of the default size only. Depending on the current DPI setting, >> it may return icon of larger size. >> >> >> Yet in this fix, the file icon is requested with explicit size. You >> will get the size you requested. > > Probably we have some other bug in the fix, but unfortunately I cannot > confirm behavior you describe. For example if I request the icon for > some pdf,java.txt files of size 100m then: > - On HiDPI screen I get the native icon of size 64. > - On LowDPI screen I get the native icon of size 32. > In both cases the user will get MRI, which will scale the native icon. From Sergey.Bylokhov at oracle.com Fri Oct 6 20:16:58 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 6 Oct 2017 13:16:58 -0700 Subject: [10] Review request for 8182043: Access to Windows Large Icons In-Reply-To: References: <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com> <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com> <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com> <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com> <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com> <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com> <2ef8eb3e-a1e1-5d86-a5a2-7cc9cc614f07@oracle.com> Message-ID: <64444271-d2e7-7dea-2d11-b635af662112@oracle.com> On 10/6/17 13:01, Semyon Sadetsky wrote: > On 10/06/2017 12:38 PM, Sergey Bylokhov wrote: > >> On 10/6/17 09:53, Alexey Ivanov wrote: >>>> It is limitation of our implementation: >>>> https://bugs.openjdk.java.net/browse/JDK-8151385 >>>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010777.html >>> >>> I see. And it can be changed, if deemed necessary, can't it? >> >> Yes we can. > Since you were the person who approved this fix can you explain why the > limitation was introduced? > We can decide whether this limitation should be reverted in a separate bug. The maximum icon which we use is 32pixel's icon, and 128 is a size of this icon on 4k monitor. >> >>>> As far as I understand the bug above, it is possible that OS returns >>>> some other size. >>> >>> No, it is not. >>> In that bug icons are extracted from Image List which is created a >>> part of Toolbar: >>> >>> 1036???? HWND hWndToolbar = ::CreateWindowEx(0, TOOLBARCLASSNAME, NULL, >>> >>> Then an icon is extracted from that image list. >>> Obviously, Toolbar can create and creates, as the bug report shows, >>> its icon set of different size depending on the current DPI setting, >>> or rather the DPI settings of the main display. >>> >>> As for JOptionPane, the icons are loaded using ::LoadIcon which loads >>> icon of the default size only. Depending on the current DPI setting, >>> it may return icon of larger size. >>> >>> >>> Yet in this fix, the file icon is requested with explicit size. You >>> will get the size you requested. >> >> Probably we have some other bug in the fix, but unfortunately I cannot >> confirm behavior you describe. For example if I request the icon for >> some pdf,java.txt files of size 100m then: >> ?- On HiDPI screen I get the native icon of size 64. >> ?- On LowDPI screen I get the native icon of size 32. >> In both cases the user will get MRI, which will scale the native icon. > > -- Best regards, Sergey. From semyon.sadetsky at oracle.com Fri Oct 6 20:33:27 2017 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 6 Oct 2017 13:33:27 -0700 Subject: [10] Review request for 8182043: Access to Windows Large Icons In-Reply-To: <4cb5fc2d-ea4e-5878-135c-79c368e72bd5@oracle.com> References: <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com> <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com> <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com> <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com> <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com> <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com> <59CEA177.5010305@oracle.com> <6b4d35b9-2d1f-0010-a7b6-ed2e17dfa661@oracle.com> <59CED263.4000104@oracle.com> <4cb5fc2d-ea4e-5878-135c-79c368e72bd5@oracle.com> Message-ID: Hi Alexey, On 10/06/2017 11:42 AM, Alexey Ivanov wrote: > Hi Semyon, Sergey, > > On 30/09/2017 00:08, Semyon Sadetsky wrote: >> On 9/29/2017 3:15 PM, Sergey Bylokhov wrote: >>> On 9/29/17 12:39, Semyon Sadetsky wrote: >>>>>> Why 128 pixels? Windows shell usually provides icons up to 256 >>>>>> pixels, for example there are 256?256 icons for folders and >>>>>> generic file type. >>>>> >>>>> It is limitation of our implementation: >>>>> https://bugs.openjdk.java.net/browse/JDK-8151385 >>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010777.html >>>>> >>>> Sergey, it is not clear how those links are related to the icon >>>> size returned by Windows? >>> >>> It was a fix where the MAX_ICON_SIZE=128 was added. >> Actually it limits nothing. We told about the Extract call which may >> return any size. > > Yes, it does. It limits the size of the returned icon to 128?128. > I guess if a larger icon is requested, then we'll get a distorted image. This is artificial limitation when the image is transfered from native to java. WinAPI may return bigger images without any issues. > >>>>> As far as I understand the bug above, it is possible that OS >>>>> returns some other size. >>>> You've probably didn't understand what Alexey meant. The Extract >>>> call may return any size you request (it does scaling internally if >>>> there are no suitable image) > But the bug above is about queering >>>> the fixed size >>>> (small or long) which size is determined by OS shell according to >>>> the current scale. For those fixed sizes we use SHGetFileInfo not >>>> the Extract. >>> >>> And every time we will try to make an icon it will be limited to >>> 128x128. But it is not critical. >>> >>> The issue is that this api, as you said, will depends from some >>> general "current scale". which is unrelated to the transform of the >>> screen in java. >>> >>> If the user will want to use FILE_ICON_LARGE, then to work properly >>> he will need to use this code every time in the the paint(): >>> Icon icon = getSystemIcon(file, FILE_ICON_LARGE); >>> Icon hicon = getSystemIcon(file, >>> icon.getIconWidth()*currentScreenScale); >> This is just wrong. The first line is the correct one for both HiDPI >> and nonHiDPI. If you want to have icons like in native apps. For >> custom behavior - please use the second line. >> > > Why is it wrong? > getSystemIcon(file) requests FILE_ICON_SMALL from the OS, then all > Java has to paint at any DPI scale is 16?16 icon. > > Or am I missing anything? Sorry, I did not get how is the small icon related to the code above. Probably we understood it differently because the explanation is not the best. My interpretation is: For the low DPI screen one should use icon=getSystemIcon(file, FILE_ICON_LARGE) when the window is moved to hiDPI screen the hicon=getSystemIcon(file, icon.getIconWidth()*currentScreenScale) should be used. And this approach is wrong. The primary purpose of the current fix is to fix the compatibility issue we got when we closed shell folder API in 9. The user code which doesn't work in 9 should not be changed in the way proposed by Sergey. This code should be updated to use getSystemIcon(file, FILE_ICON_LARGE) instead of closed getIcon(true) and getSystemIcon(file, FILE_ICON_SMALL) instead of closed getIcon(false). The newly written code may use getSystemIcon(file, FILE_ICON_LARGE/SMALL) to get the icon in the native platform which determines its size at the current DPI (DPI-unaware usage) or getSystemIcon(file, size) to have any custom size which can be multiplied by DPI. I see no reason to use both approaches simultaneously at any circumstances. --Semyon > > > Regards, > Alexey From semyon.sadetsky at oracle.com Fri Oct 6 20:50:42 2017 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 6 Oct 2017 13:50:42 -0700 Subject: [10] Review request for 8182043: Access to Windows Large Icons In-Reply-To: <64444271-d2e7-7dea-2d11-b635af662112@oracle.com> References: <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com> <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com> <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com> <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com> <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com> <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com> <2ef8eb3e-a1e1-5d86-a5a2-7cc9cc614f07@oracle.com> <64444271-d2e7-7dea-2d11-b635af662112@oracle.com> Message-ID: <96e0bb87-eda9-93c9-6c13-e51c08edefd0@oracle.com> On 10/06/2017 01:16 PM, Sergey Bylokhov wrote: > On 10/6/17 13:01, Semyon Sadetsky wrote: >> On 10/06/2017 12:38 PM, Sergey Bylokhov wrote: >> >>> On 10/6/17 09:53, Alexey Ivanov wrote: >>>>> It is limitation of our implementation: >>>>> https://bugs.openjdk.java.net/browse/JDK-8151385 >>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010777.html >>>> >>>> I see. And it can be changed, if deemed necessary, can't it? >>> >>> Yes we can. >> Since you were the person who approved this fix can you explain why >> the limitation was introduced? >> We can decide whether this limitation should be reverted in a >> separate bug. > > The maximum icon which we use is 32pixel's icon, and 128 is a size of > this icon on 4k monitor. This is not true because in addition to LARGE which you probably mean as 32-128 (ignoring the fact that this sizes may be changed in the Windows registry), Windows supports EXTRA_LARGE and JAMBO since Vista. But these constants are related to the predefined system icon sizes while the Extract() may scale icon to any size. So, I still do not see what was the reason to introduce this limitation. > >>> >>>>> As far as I understand the bug above, it is possible that OS >>>>> returns some other size. >>>> >>>> No, it is not. >>>> In that bug icons are extracted from Image List which is created a >>>> part of Toolbar: >>>> >>>> 1036 HWND hWndToolbar = ::CreateWindowEx(0, TOOLBARCLASSNAME, >>>> NULL, >>>> >>>> Then an icon is extracted from that image list. >>>> Obviously, Toolbar can create and creates, as the bug report shows, >>>> its icon set of different size depending on the current DPI >>>> setting, or rather the DPI settings of the main display. >>>> >>>> As for JOptionPane, the icons are loaded using ::LoadIcon which >>>> loads icon of the default size only. Depending on the current DPI >>>> setting, it may return icon of larger size. >>>> >>>> >>>> Yet in this fix, the file icon is requested with explicit size. You >>>> will get the size you requested. >>> >>> Probably we have some other bug in the fix, but unfortunately I >>> cannot confirm behavior you describe. For example if I request the >>> icon for some pdf,java.txt files of size 100m then: >>> - On HiDPI screen I get the native icon of size 64. >>> - On LowDPI screen I get the native icon of size 32. >>> In both cases the user will get MRI, which will scale the native icon. >> >> > > From Sergey.Bylokhov at oracle.com Fri Oct 6 22:57:34 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 6 Oct 2017 15:57:34 -0700 Subject: [10] Review request for 8182043: Access to Windows Large Icons In-Reply-To: <96e0bb87-eda9-93c9-6c13-e51c08edefd0@oracle.com> References: <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com> <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com> <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com> <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com> <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com> <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com> <2ef8eb3e-a1e1-5d86-a5a2-7cc9cc614f07@oracle.com> <64444271-d2e7-7dea-2d11-b635af662112@oracle.com> <96e0bb87-eda9-93c9-6c13-e51c08edefd0@oracle.com> Message-ID: On 10/6/17 13:50, Semyon Sadetsky wrote: > This is not true because in addition to LARGE which you probably mean as > 32-128 (ignoring the fact that this sizes may be changed in the Windows > registry), Windows supports EXTRA_LARGE and JAMBO since Vista. The maximum icon which we used before you fix is 32pixel's icon(yes it is a large icon), and 128 is a size of this icon on 4k monitor( The windows can return a 128pixel's icon on 4k monitor) The EXTRA_LARGE and JAMBO was not used in our code. > But these constants are related to the predefined system icon sizes while the > Extract() may scale icon to any size. Does it really scale for any size? For example if I request the icon for some pdf,java,txt files of size 100 then: - On HiDPI screen I get the native icon of size 64. - On LowDPI screen I get the native icon of size 32. In both cases the user will get MRI, which will scale the native icon. http://mail.openjdk.java.net/pipermail/awt-dev/2017-October/013179.html -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri Oct 6 23:11:47 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 6 Oct 2017 16:11:47 -0700 Subject: [10] RFR JDK-8187989: Documentation error in JComponent.paintComponent In-Reply-To: <68d45239-11a2-2282-5a3c-12126a60e881@oracle.com> References: <68d45239-11a2-2282-5a3c-12126a60e881@oracle.com> Message-ID: <4f343eb5-0abd-ba1c-a821-8273c7c5cfbe@oracle.com> Looks fine. On 10/6/17 04:12, Prasanta Sadhukhan wrote: > Hi All, > > Please review a doc fix where it mentioned in JComponent.paintComponent() > > > if this component is opaque, you must completely fill in the > background in a non-opaque color > It should read "opaque color", or "non-transparent color". > > webrev:http://cr.openjdk.java.net/~psadhukhan/8187989/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8187989 > > Regards > Prasanta -- Best regards, Sergey. From semyon.sadetsky at oracle.com Sat Oct 7 00:16:30 2017 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 6 Oct 2017 17:16:30 -0700 Subject: [10] Review request for 8182043: Access to Windows Large Icons In-Reply-To: References: <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com> <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com> <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com> <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com> <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com> <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com> <2ef8eb3e-a1e1-5d86-a5a2-7cc9cc614f07@oracle.com> <64444271-d2e7-7dea-2d11-b635af662112@oracle.com> <96e0bb87-eda9-93c9-6c13-e51c08edefd0@oracle.com> Message-ID: <68e02999-be33-5ca9-2e9d-d1feb6c9446a@oracle.com> On 10/06/2017 03:57 PM, Sergey Bylokhov wrote: > On 10/6/17 13:50, Semyon Sadetsky wrote: >> This is not true because in addition to LARGE which you probably mean >> as 32-128 (ignoring the fact that this sizes may be changed in the >> Windows registry), Windows supports EXTRA_LARGE and JAMBO since Vista. > > The maximum icon which we used before you fix is 32pixel's icon(yes it > is a large icon), and 128 is a size of this icon on 4k monitor( The > windows can return a 128pixel's icon on 4k monitor) The EXTRA_LARGE > and JAMBO was not used in our code. So, it is not supposed to work on 8k monitor? Why we should have this limit while the native platform hasn't it? > >> But these constants are related to the predefined system icon sizes >> while the Extract() may scale icon to any size. > > Does it really scale for any size? > For example if I request the icon for some pdf,java,txt files of size > 100 then: > - On HiDPI screen I get the native icon of size 64. > - On LowDPI screen I get the native icon of size 32. > In both cases the user will get MRI, which will scale the native icon. > http://mail.openjdk.java.net/pipermail/awt-dev/2017-October/013179.html Why returning MRI is wrong? Which calls are you talking about DPI-aware or DPI-unaware? From alexandre.iline at oracle.com Mon Oct 9 23:14:34 2017 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Mon, 9 Oct 2017 16:14:34 -0700 Subject: RFR JDK-8188824: sanity/client/SwingSet/src/ProgressBarDemoTest: Failed with NullPointerException Message-ID: Please take a quick look on this simple fix. Webrev: http://cr.openjdk.java.net/~shurailine/8188824/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8188824 This fix is a copy of fix made in the Jemmy code-tools repository. Webrev: http://cr.openjdk.java.net/~shurailine/7902046/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7902046 Thank you. Shura From semyon.sadetsky at oracle.com Tue Oct 10 00:52:48 2017 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 9 Oct 2017 17:52:48 -0700 Subject: RFR JDK-8188824: sanity/client/SwingSet/src/ProgressBarDemoTest: Failed with NullPointerException In-Reply-To: References: Message-ID: <7be9049b-a34f-ff2d-c9b0-dc20b7afda46@oracle.com> +1 --Semyon On 10/09/2017 04:14 PM, Alexandre (Shura) Iline wrote: > Please take a quick look on this simple fix. > > Webrev: http://cr.openjdk.java.net/~shurailine/8188824/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8188824 > > This fix is a copy of fix made in the Jemmy code-tools repository. > Webrev: http://cr.openjdk.java.net/~shurailine/7902046/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7902046 > > Thank you. > > Shura From prasanta.sadhukhan at oracle.com Wed Oct 11 09:43:37 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 11 Oct 2017 15:13:37 +0530 Subject: [10] RFR JDK-8178025:HiDPI with non-integer scale factor - SPANs in HTML are rendered overlapping each other Message-ID: Hi All, Please review a fix for an issue whereby, when using a non-integer resolution (e.g. 225%) for a HiDPI display, the Swing HTML rendering incorrectly calculates the width of SPAN elements which results in SPANs being incorrectly positioned and overlapping with each other. Issue was, when a JLabel with an html text is created, the GlyphPainter1.getSpan() uses a FontrenderedContext with transform scale 1 and also the obtained width is converted to int and not to float. Proposed fix is to use correct transform while calculating the string width and also use floating point API to get floating point width. webrev:http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8178025 Regards Prasanta From semyon.sadetsky at oracle.com Wed Oct 11 17:20:17 2017 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 11 Oct 2017 10:20:17 -0700 Subject: [10] RFR JDK-8178025:HiDPI with non-integer scale factor - SPANs in HTML are rendered overlapping each other In-Reply-To: References: Message-ID: <1713d491-3520-5f72-ccd8-796d5a9ae107@oracle.com> +1 --Semyon On 10/11/2017 02:43 AM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix for an issue whereby, when using a non-integer > resolution (e.g. 225%) for a HiDPI display, > the Swing HTML rendering incorrectly calculates the width of SPAN > elements which results in SPANs being > incorrectly positioned and overlapping with each other. > > Issue was, when a JLabel with an html text is created, the > GlyphPainter1.getSpan() uses a FontrenderedContext with transform scale 1 > and also the obtained width is converted to int and not to float. > > Proposed fix is to use correct transform while calculating the string > width and also use floating point API to get floating point width. > > webrev:http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8178025 > > Regards > Prasanta From semyon.sadetsky at oracle.com Wed Oct 11 18:37:18 2017 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 11 Oct 2017 11:37:18 -0700 Subject: [10] Review request for 8180821: [macosx]com/apple/laf/ScreenMenu/ScreenMenuMemoryLeakTest.java: The menu item should have been GC-ed Message-ID: <729ee830-c90f-0147-096a-c72c8ce57848@oracle.com> Hello, Please review fix for JDK10 (the changes involve AWT and Swing): bug: https://bugs.openjdk.java.net/browse/JDK-8180821 webrev: http://cr.openjdk.java.net/~ssadetsky/8180821/webrev.00/ This is a test bug. The test fails intermittently because the System.runFinalization() method invocation just triggers the finalization thread in parallel so it may be not accomplished yet after the method exits. Adding 1s delay makes the test passing stably. --Semyon From philip.race at oracle.com Wed Oct 11 19:03:54 2017 From: philip.race at oracle.com (Phil Race) Date: Wed, 11 Oct 2017 12:03:54 -0700 Subject: [10] Review request for 8180821: [macosx]com/apple/laf/ScreenMenu/ScreenMenuMemoryLeakTest.java: The menu item should have been GC-ed In-Reply-To: <729ee830-c90f-0147-096a-c72c8ce57848@oracle.com> References: <729ee830-c90f-0147-096a-c72c8ce57848@oracle.com> Message-ID: If it makes the test pass .. +1 -phil. On 10/11/2017 11:37 AM, Semyon Sadetsky wrote: > Hello, > > Please review fix for JDK10 (the changes involve AWT and Swing): > > bug: https://bugs.openjdk.java.net/browse/JDK-8180821 > > webrev: http://cr.openjdk.java.net/~ssadetsky/8180821/webrev.00/ > > This is a test bug. The test fails intermittently because the > System.runFinalization() method invocation just triggers the > finalization thread in parallel so it may be not accomplished yet > after the method exits. Adding 1s delay makes the test passing stably. > > --Semyon > From prasanta.sadhukhan at oracle.com Thu Oct 12 05:37:00 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 12 Oct 2017 11:07:00 +0530 Subject: [10] Review request for 8180821: [macosx]com/apple/laf/ScreenMenu/ScreenMenuMemoryLeakTest.java: The menu item should have been GC-ed In-Reply-To: References: <729ee830-c90f-0147-096a-c72c8ce57848@oracle.com> Message-ID: You need to add the bugid to @bug tag. +1 otherwise. Regards Prasanta On 10/12/2017 12:33 AM, Phil Race wrote: > If it makes the test pass .. > > +1 > > > -phil. > > > On 10/11/2017 11:37 AM, Semyon Sadetsky wrote: >> Hello, >> >> Please review fix for JDK10 (the changes involve AWT and Swing): >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8180821 >> >> webrev: http://cr.openjdk.java.net/~ssadetsky/8180821/webrev.00/ >> >> This is a test bug. The test fails intermittently because the >> System.runFinalization() method invocation just triggers the >> finalization thread in parallel so it may be not accomplished yet >> after the method exits. Adding 1s delay makes the test passing stably. >> >> --Semyon >> > From Sergey.Bylokhov at oracle.com Thu Oct 12 20:39:54 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 12 Oct 2017 13:39:54 -0700 Subject: [10] Review request for 8182043: Access to Windows Large Icons In-Reply-To: <68e02999-be33-5ca9-2e9d-d1feb6c9446a@oracle.com> References: <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com> <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com> <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com> <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com> <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com> <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com> <2ef8eb3e-a1e1-5d86-a5a2-7cc9cc614f07@oracle.com> <64444271-d2e7-7dea-2d11-b635af662112@oracle.com> <96e0bb87-eda9-93c9-6c13-e51c08edefd0@oracle.com> <68e02999-be33-5ca9-2e9d-d1feb6c9446a@oracle.com> Message-ID: <6b192c97-37bf-9df0-16be-178e0d445417@oracle.com> On 06/10/2017 17:16, Semyon Sadetsky wrote: >> The maximum icon which we used before you fix is 32pixel's icon(yes it >> is a large icon), and 128 is a size of this icon on 4k monitor( The >> windows can return a 128pixel's icon on 4k monitor) The EXTRA_LARGE >> and JAMBO was not used in our code. > So, it is not supposed to work on 8k monitor? Why we should have this > limit while the native platform hasn't it? This is my understanding, before those fix the maximum size was 32x32. >> >>> But these constants are related to the predefined system icon sizes >>> while the Extract() may scale icon to any size. >> >> Does it really scale for any size? >> For example if I request the icon for some pdf,java,txt files of size >> 100 then: >> ? - On HiDPI screen I get the native icon of size 64. >> ? - On LowDPI screen I get the native icon of size 32. >> In both cases the user will get MRI, which will scale the native icon. >> http://mail.openjdk.java.net/pipermail/awt-dev/2017-October/013179.html > Why returning MRI is wrong? The MRI is good, if this is what the user is expected. My point was that the native system is not scale the icon and the user gets MRI which content is unrelated to the passed "size". > Which calls are you talking about DPI-aware > or DPI-unaware? This is jdk10client + the current patch. -- Best regards, Sergey. From philip.race at oracle.com Thu Oct 12 22:08:17 2017 From: philip.race at oracle.com (Phil Race) Date: Thu, 12 Oct 2017 15:08:17 -0700 Subject: [10] Review request for 8187599: Remove dependency of Building Nimbus L&F on JAXB In-Reply-To: <7c7cbb01-a99d-2c0e-49eb-2ef748fda853@oracle.com> References: <85c5735a-4f64-71e9-d930-03d766e5c9b6@oracle.com> <02cb5dfa-44f7-b9ee-e334-6c5085bcdc7e@oracle.com> <7c7cbb01-a99d-2c0e-49eb-2ef748fda853@oracle.com> Message-ID: <3e06f66b-d8dd-037b-7287-5849119b7a7c@oracle.com> +1 -phil. On 9/27/2017 11:21 AM, Sergey Bylokhov wrote: > On 9/25/17 10:34, Semyon Sadetsky wrote: >> ObjectFactory.java was missed from the webrev. It should be deleted >> actually. >> The updated webrev: >> http://cr.openjdk.java.net/~ssadetsky/8187599/webrev.01/ > > Looks fine. > > From Sergey.Bylokhov at oracle.com Fri Oct 13 01:54:06 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 12 Oct 2017 18:54:06 -0700 Subject: [10] Review Request: 8075255 Metal L&F has dependency on the Windows L&F Message-ID: <8f8102cd-6593-b1ca-94b5-02131d16102c@oracle.com> Hello, Please review the fix for jdk10. Bug: https://bugs.openjdk.java.net/browse/JDK-8075255 Webrev can be found at: http://cr.openjdk.java.net/~serb/8075255/webrev.01 In the fix the dependency of MetalLookAndFeel from WindowsLookAndFeel is broken. The old DesktopProperty which contains the general functionality was moved to sun/swing/plaf/DesktopProperty.java. This class can be reused later by other platforms/l&f if needed. The Windows/Metal specific functionality was placed in WindowsDesktopProperty(used in win L&F) and in MetalFontDesktopProperty(used in metal l&f). The new test was added to check that this functionality actually works. -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Fri Oct 13 04:04:27 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 13 Oct 2017 09:34:27 +0530 Subject: [10] Review Request: 8075255 Metal L&F has dependency on the Windows L&F In-Reply-To: <8f8102cd-6593-b1ca-94b5-02131d16102c@oracle.com> References: <8f8102cd-6593-b1ca-94b5-02131d16102c@oracle.com> Message-ID: <97b6be78-421d-6f63-d9c7-80b0ea1a76fb@oracle.com> looks good to me. bugid needs to be added to Test6824600.java Regards Prasanta On 10/13/2017 7:24 AM, Sergey Bylokhov wrote: > Hello, > Please review the fix for jdk10. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8075255 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8075255/webrev.01 > > In the fix the dependency of MetalLookAndFeel from WindowsLookAndFeel > is broken. > > The old DesktopProperty which contains the general functionality was > moved to sun/swing/plaf/DesktopProperty.java. This class can be reused > later by other platforms/l&f if needed. > > The Windows/Metal specific functionality was placed in > WindowsDesktopProperty(used in win L&F) and in > MetalFontDesktopProperty(used in metal l&f). The new test was added to > check that this functionality actually works. > From alexander.zvegintsev at oracle.com Fri Oct 13 08:01:53 2017 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Fri, 13 Oct 2017 13:31:53 +0530 Subject: [OpenJDK 2D-Dev] [10] Review Request: 8187399 Different problems in the javadoc's links in java.desktop package In-Reply-To: <8d147726-4e2f-b633-29e5-9ffd7c4cfb54@oracle.com> References: <8d147726-4e2f-b633-29e5-9ffd7c4cfb54@oracle.com> Message-ID: +1 Thanks, Alexander. On 14/09/2017 04:09, Sergey Bylokhov wrote: > Hello, > Please review the fix for jdk10. > > Some of the tidy warnings were fixed. > Report is here: > http://cr.openjdk.java.net/~jjg/doc-report/jdk-by-module/java.desktop/report.html > > > Description: > ?- java/awt/Desktop.java: the links to "developer.apple.com" were > removed, it seems that the URLs for these documents are changed over > time as well as content. We will mention only "CFBundleDocumentTypes" > and "Info.plist" in the description. > ?- javax/print/attribute/standard/PresentationDirection.java: the link > was changed from ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf > to ftp://ftp.pwg.org/pub/pwg/standards/temp_archive/pwg5100.3.pdf , > but I guess this is a stable location because the files are there from > 2004. > ?- others are just broken links which were fixed. > > I checked the whole list of links in the desktop module, and found > that some of them are broken. For example I cannot find an official > place for the tiff specification(and related documents). Also during > migration from sun.com we lost some documents, I leave such links > as-is, and plan to resurrect the documents somewhere. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187399 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8187399/webrev.00 > > From alexander.zvegintsev at oracle.com Fri Oct 13 08:04:47 2017 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Fri, 13 Oct 2017 13:34:47 +0530 Subject: [OpenJDK 2D-Dev] [10] Review Request: 8187399 Different problems in the javadoc's links in java.desktop package In-Reply-To: <1b9669d9-80e2-bc6c-b693-4b04c479d3d8@oracle.com> References: <8d147726-4e2f-b633-29e5-9ffd7c4cfb54@oracle.com> <9ad3322c-3333-555c-6f53-6321eab1435e@oracle.com> <1b9669d9-80e2-bc6c-b693-4b04c479d3d8@oracle.com> Message-ID: +1 Thanks, Alexander. On 16/09/2017 07:16, Sergey Bylokhov wrote: > That's of course a stylistic issue, but I think that the keywords(not > necessary a java) look better when they are highlighted. Depending > from the style it can look like this: > http://cr.openjdk.java.net/~serb/8187399/img.png > > Here is an updated webrev: > http://cr.openjdk.java.net/~serb/8187399/webrev.01 > ?- The link to the "Apple Developer Documentation" was added. > ?- Info.plist is also wrapped in the {@code} > ?- Mac OS was replaced by macOS > > > On 9/15/17 12:34, Phil Race wrote: >> 771????? * @implNote Please note that for Mac OS, notifications >> ? 772????? * are only sent if the Java app is a bundled application, >> ? 773????? * with a {@code CFBundleDocumentTypes} array present in its >> 774 * Info.plist. >> >> >> Should we be using {@code ..} for CFBundleDocumentTypes. It is not >> Java code, >> but this makes it look like it is. >> >> I think we should have some reference to "go see Apple developer >> docs" to find out what >> that and Info.plist are .. even if it not a direct link. >> >> -phil. >> >> >> On 09/13/2017 03:39 PM, Sergey Bylokhov wrote: >>> Hello, >>> Please review the fix for jdk10. >>> >>> Some of the tidy warnings were fixed. >>> Report is here: >>> http://cr.openjdk.java.net/~jjg/doc-report/jdk-by-module/java.desktop/report.html >>> >>> >>> Description: >>> ?- java/awt/Desktop.java: the links to "developer.apple.com" were >>> removed, it seems that the URLs for these documents are changed over >>> time as well as content. We will mention only >>> "CFBundleDocumentTypes" and "Info.plist" in the description. >>> ?- javax/print/attribute/standard/PresentationDirection.java: the >>> link was changed from ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf >>> to ftp://ftp.pwg.org/pub/pwg/standards/temp_archive/pwg5100.3.pdf , >>> but I guess this is a stable location because the files are there >>> from 2004. >>> ?- others are just broken links which were fixed. >>> >>> I checked the whole list of links in the desktop module, and found >>> that some of them are broken. For example I cannot find an official >>> place for the tiff specification(and related documents). Also during >>> migration from sun.com we lost some documents, I leave such links >>> as-is, and plan to resurrect the documents somewhere. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8187399 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/8187399/webrev.00 >>> >>> >> > > From anton.litvinov at oracle.com Fri Oct 13 18:54:23 2017 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Fri, 13 Oct 2017 19:54:23 +0100 Subject: [8u] Review request for 8166772: Touch keyboard is not shown for text components on a screen touch Message-ID: <75b95220-4ff4-3d48-c521-c25f46572670@oracle.com> Hello Sergey and Alexander, Could you please review the following back port of the fix, which you already reviewed for JDK 10, from JDK 10 to JDK 8. Bug: https://bugs.openjdk.java.net/browse/JDK-8166772 JDK 8 webrev: http://cr.openjdk.java.net/~alitvinov/8166772/jdk8/webrev.00 JDK 10 changeset: http://hg.openjdk.java.net/jdk10/client/rev/3b244a98d5ab JDK 10 webrev: http://cr.openjdk.java.net/~alitvinov/8166772/jdk10/webrev.01 The back port fix is identical to the original fix for JDK 10, except for the next micro changes: 1. "SunToolkit.java" file - In JDK 8 version of the fix "AccessController.doPrivileged(new GetPropertyAction(" is used instead of "GetPropertyAction.privilegedGetProperty(", since "GetPropertyAction.privilegedGetProperty" does not exist in JDK 8. 2. "WToolkit.java" file - In JDK 8 version of the fix the import statement "import sun.awt.AWTAccessor;" was added. Thank you, Anton From Sergey.Bylokhov at oracle.com Fri Oct 13 22:38:42 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 13 Oct 2017 15:38:42 -0700 Subject: [8u] Review request for 8166772: Touch keyboard is not shown for text components on a screen touch In-Reply-To: <75b95220-4ff4-3d48-c521-c25f46572670@oracle.com> References: <75b95220-4ff4-3d48-c521-c25f46572670@oracle.com> Message-ID: Looks fine. On 13/10/2017 11:54, Anton Litvinov wrote: > Hello Sergey and Alexander, > > Could you please review the following back port of the fix, which you > already reviewed for JDK 10, from JDK 10 to JDK 8. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166772 > JDK 8 webrev: http://cr.openjdk.java.net/~alitvinov/8166772/jdk8/webrev.00 > JDK 10 changeset: http://hg.openjdk.java.net/jdk10/client/rev/3b244a98d5ab > JDK 10 webrev: > http://cr.openjdk.java.net/~alitvinov/8166772/jdk10/webrev.01 > > The back port fix is identical to the original fix for JDK 10, except > for the next micro changes: > > 1.? "SunToolkit.java" file - In JDK 8 version of the fix > "AccessController.doPrivileged(new GetPropertyAction(" is used instead > of "GetPropertyAction.privilegedGetProperty(", since > "GetPropertyAction.privilegedGetProperty" does not exist in JDK 8. > > 2.? "WToolkit.java" file - In JDK 8 version of the fix the import > statement "import sun.awt.AWTAccessor;" was added. > > Thank you, > Anton -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Sat Oct 14 01:10:17 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 13 Oct 2017 18:10:17 -0700 Subject: [10] RFR JDK-8178025:HiDPI with non-integer scale factor - SPANs in HTML are rendered overlapping each other In-Reply-To: References: Message-ID: <4121aef8-bbae-c5ef-dfe2-d3b8efda318c@oracle.com> Hi, Prasanta. On 11/10/2017 02:43, Prasanta Sadhukhan wrote: > Issue was, when a JLabel with an html text is created, the > GlyphPainter1.getSpan() uses a FontrenderedContext with transform scale 1 > and also the obtained width is converted to int and not to float. Probably this is a root cause of the bug? FontrenderedContext is an abstraction which encapsulate information about text attributes for some specific surface such as screen, window, etc. If the label or any other components will use some FRC for rendering then the same FRC should be used for font size measurement. So why the scale is 1? > Proposed fix is to use correct transform while calculating the string > width and also use floating point API to get floating point width. It will apply the screens scale to the FRC even if the component is located on some other screen. -- Best regards, Sergey. From javalists at cbfiddle.com Sat Oct 14 01:31:35 2017 From: javalists at cbfiddle.com (Alan Snyder) Date: Fri, 13 Oct 2017 18:31:35 -0700 Subject: [10] RFR JDK-8178025:HiDPI with non-integer scale factor - SPANs in HTML are rendered overlapping each other In-Reply-To: <4121aef8-bbae-c5ef-dfe2-d3b8efda318c@oracle.com> References: <4121aef8-bbae-c5ef-dfe2-d3b8efda318c@oracle.com> Message-ID: Having run into similar problems, I believe this is an area where Swing has a serious design flaw. When a component is created, it has no idea which window it will be displayed in, and even when the window is known, the window could be moved to a different screen at any time. In addition, it seems the antialiasing and fractional metrics options are sometimes obtained from the Look and Feel, the rationale for which puzzles me. If these are not actual problems, please point me to appropriate documentation or supply an explanation. Alan > On Oct 13, 2017, at 6:10 PM, Sergey Bylokhov wrote: > > Hi, Prasanta. > > On 11/10/2017 02:43, Prasanta Sadhukhan wrote: >> Issue was, when a JLabel with an html text is created, the GlyphPainter1.getSpan() uses a FontrenderedContext with transform scale 1 >> and also the obtained width is converted to int and not to float. > > Probably this is a root cause of the bug? FontrenderedContext is an abstraction which encapsulate information about text attributes for some specific surface such as screen, window, etc. If the label or any other components will use some FRC for rendering then the same FRC should be used for font size measurement. So why the scale is 1? > >> Proposed fix is to use correct transform while calculating the string width and also use floating point API to get floating point width. > > It will apply the screens scale to the FRC even if the component is located on some other screen. > > > -- > Best regards, Sergey. From prasanta.sadhukhan at oracle.com Mon Oct 16 09:50:45 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 16 Oct 2017 15:20:45 +0530 Subject: [10] RFR JDK-8178025:HiDPI with non-integer scale factor - SPANs in HTML are rendered overlapping each other In-Reply-To: <4121aef8-bbae-c5ef-dfe2-d3b8efda318c@oracle.com> References: <4121aef8-bbae-c5ef-dfe2-d3b8efda318c@oracle.com> Message-ID: <540b95d9-3b3e-2c1d-37cf-a60c8a831cff@oracle.com> Hi Sergey, On 10/14/2017 6:40 AM, Sergey Bylokhov wrote: > Hi, Prasanta. > > On 11/10/2017 02:43, Prasanta Sadhukhan wrote: >> Issue was, when a JLabel with an html text is created, the >> GlyphPainter1.getSpan() uses a FontrenderedContext with transform >> scale 1 >> and also the obtained width is converted to int and not to float. > > Probably this is a root cause of the bug? Does not seem like. If we only use floating point API getTabbedTextWidth() in GlyphPainter1.getSpan() to get floating point width, it calls SwingUtilities2.getFontStringWidth() which calls getStringBounds() with default FRC. When getStringBounds() calls fm.getFontRenderContext(), it returns DEFAULT_FRC which has a null AffineTransform so when we try to get the transform for that through getTransform(), it creates a new AffineTransform with scale 1 public AffineTransform getTransform() { ??????? return (tx == null) ? new AffineTransform() : new AffineTransform(tx); ??? } > FontrenderedContext is an abstraction which encapsulate information > about text attributes for some specific surface such as screen, > window, etc. If the label or any other components will use some FRC > for rendering then the same FRC should be used for font size > measurement. So why the scale is 1? > >> Proposed fix is to use correct transform while calculating the string >> width and also use floating point API to get floating point width. > > It will apply the screens scale to the FRC even if the component is > located on some other screen. I was of the opinion that this GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration().getDefaultTransform().getScaleX() will give the scale factor as passed to sun.java2d.uiScale which should be applicable for all screen(s), which is what I leveraged in my fix. > > Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Mon Oct 16 19:38:09 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 16 Oct 2017 12:38:09 -0700 Subject: [10] RFR JDK-8178025:HiDPI with non-integer scale factor - SPANs in HTML are rendered overlapping each other In-Reply-To: <540b95d9-3b3e-2c1d-37cf-a60c8a831cff@oracle.com> References: <4121aef8-bbae-c5ef-dfe2-d3b8efda318c@oracle.com> <540b95d9-3b3e-2c1d-37cf-a60c8a831cff@oracle.com> Message-ID: <97834ff5-4d40-e267-ff73-8ac3727e7f95@oracle.com> On 16/10/2017 02:50, Prasanta Sadhukhan wrote: >> Probably this is a root cause of the bug? > Does not seem like. If we only use floating point API > getTabbedTextWidth() in GlyphPainter1.getSpan() to get floating point > width, it calls SwingUtilities2.getFontStringWidth() which calls > getStringBounds() with default FRC. > When getStringBounds() calls fm.getFontRenderContext(), it returns > DEFAULT_FRC which has a null AffineTransform so when we try to get the > transform for that through getTransform(), it creates a new > AffineTransform with scale 1 > public AffineTransform getTransform() { > ??????? return (tx == null) ? new AffineTransform() : new > AffineTransform(tx); > ??? } So this is a problem why default FRC is used. We should find a way to create a correct one instead. >> It will apply the screens scale to the FRC even if the component is >> located on some other screen. > I was of the opinion that this > > GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration().getDefaultTransform().getScaleX() > > > will give the scale factor as passed to sun.java2d.uiScale which should > be applicable for all screen(s), which is what I leveraged in my fix. The "sun.java2d.uiScale" is a debug option which applies the scale on all screens, but in case of the common configuration it is possible to have different scales(example: hidpi laptop + lowdpi external screen). GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration().getDefaultTransform().getScaleX() Will returns default transform for default configuration of the main/default screen. -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Tue Oct 17 04:52:38 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 17 Oct 2017 10:22:38 +0530 Subject: [10] RFR JDK-8178025:HiDPI with non-integer scale factor - SPANs in HTML are rendered overlapping each other In-Reply-To: <97834ff5-4d40-e267-ff73-8ac3727e7f95@oracle.com> References: <4121aef8-bbae-c5ef-dfe2-d3b8efda318c@oracle.com> <540b95d9-3b3e-2c1d-37cf-a60c8a831cff@oracle.com> <97834ff5-4d40-e267-ff73-8ac3727e7f95@oracle.com> Message-ID: On 10/17/2017 1:08 AM, Sergey Bylokhov wrote: > On 16/10/2017 02:50, Prasanta Sadhukhan wrote: >>> Probably this is a root cause of the bug? >> Does not seem like. If we only use floating point API >> getTabbedTextWidth() in GlyphPainter1.getSpan() to get floating point >> width, it calls SwingUtilities2.getFontStringWidth() which calls >> getStringBounds() with default FRC. >> When getStringBounds() calls fm.getFontRenderContext(), it returns >> DEFAULT_FRC which has a null AffineTransform so when we try to get >> the transform for that through getTransform(), it creates a new >> AffineTransform with scale 1 >> public AffineTransform getTransform() { >> ???????? return (tx == null) ? new AffineTransform() : new >> AffineTransform(tx); >> ???? } > > So this is a problem why default FRC is used. We should find a way to > create a correct one instead. I guess that is what I did which is to create a FRC with correct transform . Regards Prasanta > >>> It will apply the screens scale to the FRC even if the component is >>> located on some other screen. >> I was of the opinion that this >> >> GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration().getDefaultTransform().getScaleX() >> >> >> will give the scale factor as passed to sun.java2d.uiScale which >> should be applicable for all screen(s), which is what I leveraged in >> my fix. > > The "sun.java2d.uiScale" is a debug option which applies the scale on > all screens, but in case of the common configuration it is possible to > have different scales(example: hidpi laptop + lowdpi external screen). > > GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration().getDefaultTransform().getScaleX() > > Will returns default transform for default configuration of the > main/default screen. > From prasanta.sadhukhan at oracle.com Tue Oct 17 10:48:20 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 17 Oct 2017 16:18:20 +0530 Subject: [10] RFR JDK-8178025:HiDPI with non-integer scale factor - SPANs in HTML are rendered overlapping each other In-Reply-To: References: <4121aef8-bbae-c5ef-dfe2-d3b8efda318c@oracle.com> <540b95d9-3b3e-2c1d-37cf-a60c8a831cff@oracle.com> <97834ff5-4d40-e267-ff73-8ac3727e7f95@oracle.com> Message-ID: On 10/17/2017 10:22 AM, Prasanta Sadhukhan wrote: > > > On 10/17/2017 1:08 AM, Sergey Bylokhov wrote: >> On 16/10/2017 02:50, Prasanta Sadhukhan wrote: >>>> Probably this is a root cause of the bug? >>> Does not seem like. If we only use floating point API >>> getTabbedTextWidth() in GlyphPainter1.getSpan() to get floating >>> point width, it calls SwingUtilities2.getFontStringWidth() which >>> calls getStringBounds() with default FRC. >>> When getStringBounds() calls fm.getFontRenderContext(), it returns >>> DEFAULT_FRC which has a null AffineTransform so when we try to get >>> the transform for that through getTransform(), it creates a new >>> AffineTransform with scale 1 >>> public AffineTransform getTransform() { >>> ???????? return (tx == null) ? new AffineTransform() : new >>> AffineTransform(tx); >>> ???? } >> >> So this is a problem why default FRC is used. We should find a way to >> create a correct one instead. > I guess that is what I did which is to create a FRC with correct > transform . > When JLabel with html tag span is created, GlyphPainter1.getSpan() calls sync() which finds JLabel.getFontMetrics() which calls SwingUtilities2.getFontMetrics which calls getFRCProperty() and it tries to find JLabel.getGraphicsConfiguration() which comes out to be null so affinetransform also becomes null. AffineTransform tx = (gc == null) ? null : gc.getDefaultTransform(); It seems for JLabel, Component.updateGraphicsData() with proper GraphicsConfiguraiton is never called which it does for JTextComponent or JDialog. Do you know why? Because of this, correct FRC is not created. I am not sure what else I can do to create correct FRC. > Regards > Prasanta >> >>>> It will apply the screens scale to the FRC even if the component is >>>> located on some other screen. >>> I was of the opinion that this >>> >>> GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration().getDefaultTransform().getScaleX() >>> >>> >>> will give the scale factor as passed to sun.java2d.uiScale which >>> should be applicable for all screen(s), which is what I leveraged in >>> my fix. >> >> The "sun.java2d.uiScale" is a debug option which applies the scale on >> all screens, but in case of the common configuration it is possible >> to have different scales(example: hidpi laptop + lowdpi external >> screen). >> >> GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration().getDefaultTransform().getScaleX() >> >> Will returns default transform for default configuration of the >> main/default screen. >> > From semyon.sadetsky at oracle.com Tue Oct 17 15:08:00 2017 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 17 Oct 2017 08:08:00 -0700 Subject: [10] RFR JDK-8178025:HiDPI with non-integer scale factor - SPANs in HTML are rendered overlapping each other In-Reply-To: References: <4121aef8-bbae-c5ef-dfe2-d3b8efda318c@oracle.com> <540b95d9-3b3e-2c1d-37cf-a60c8a831cff@oracle.com> <97834ff5-4d40-e267-ff73-8ac3727e7f95@oracle.com> Message-ID: Hi Prasanta, Hi Prasanta, It seems another global issue was missed during this bug evaluation. After HiDPI support is introduced all text UIs need to receive notifications about graphics configuration update as about font change. This is because another GC scale changes font size but since symbols and spaces are not scaled linearly the text layout should be fully refreshed with the new GC. --Semyon On 10/17/2017 03:48 AM, Prasanta Sadhukhan wrote: > > > On 10/17/2017 10:22 AM, Prasanta Sadhukhan wrote: >> >> >> On 10/17/2017 1:08 AM, Sergey Bylokhov wrote: >>> On 16/10/2017 02:50, Prasanta Sadhukhan wrote: >>>>> Probably this is a root cause of the bug? >>>> Does not seem like. If we only use floating point API >>>> getTabbedTextWidth() in GlyphPainter1.getSpan() to get floating >>>> point width, it calls SwingUtilities2.getFontStringWidth() which >>>> calls getStringBounds() with default FRC. >>>> When getStringBounds() calls fm.getFontRenderContext(), it returns >>>> DEFAULT_FRC which has a null AffineTransform so when we try to get >>>> the transform for that through getTransform(), it creates a new >>>> AffineTransform with scale 1 >>>> public AffineTransform getTransform() { >>>> ???????? return (tx == null) ? new AffineTransform() : new >>>> AffineTransform(tx); >>>> ???? } >>> >>> So this is a problem why default FRC is used. We should find a way >>> to create a correct one instead. >> I guess that is what I did which is to create a FRC with correct >> transform . >> > When JLabel with html tag span is created, GlyphPainter1.getSpan() > calls sync() which finds JLabel.getFontMetrics() which calls > SwingUtilities2.getFontMetrics which calls getFRCProperty() and it > tries to find > JLabel.getGraphicsConfiguration() which comes out to be null so > affinetransform also becomes null. > AffineTransform tx = (gc == null) ? null : gc.getDefaultTransform(); > > It seems for JLabel, Component.updateGraphicsData() with proper > GraphicsConfiguraiton is never called which it does for JTextComponent > or JDialog. Do you know why? Because of this, correct FRC is not created. > I am not sure what else I can do to create correct FRC. >> Regards >> Prasanta >>> >>>>> It will apply the screens scale to the FRC even if the component >>>>> is located on some other screen. >>>> I was of the opinion that this >>>> >>>> GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration().getDefaultTransform().getScaleX() >>>> >>>> >>>> will give the scale factor as passed to sun.java2d.uiScale which >>>> should be applicable for all screen(s), which is what I leveraged >>>> in my fix. >>> >>> The "sun.java2d.uiScale" is a debug option which applies the scale >>> on all screens, but in case of the common configuration it is >>> possible to have different scales(example: hidpi laptop + lowdpi >>> external screen). >>> >>> GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration().getDefaultTransform().getScaleX() >>> >>> Will returns default transform for default configuration of the >>> main/default screen. >>> >> > From semyon.sadetsky at oracle.com Tue Oct 17 16:26:00 2017 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 17 Oct 2017 09:26:00 -0700 Subject: [10] Review Request: JDK-6463710 : ListSelectionModel.setSelectionMode() underspecified In-Reply-To: References: Message-ID: <209a22e8-dbb4-e4e3-39d9-3e2d39f81135@oracle.com> +1 --Semyon On 09/28/2017 04:57 AM, Pankaj Bansal wrote: > > Hi, > > I have updated the webrev for the review comments. Now I have > preserved the consistent part for the selection depending upon old and > new selectionMode. Please review. > > webrev: > > http://cr.openjdk.java.net/~aghaisas/pankaj/6463710/webrev.01/ > > > Regards, > > Pankaj Bansal > > *From:*Semyon Sadetsky > *Sent:* Wednesday, September 27, 2017 10:25 PM > *To:* Pankaj Bansal; swing-dev at openjdk.java.net > *Subject:* Re: [10] Review Request: JDK-6463710 : > ListSelectionModel.setSelectionMode() underspecified > > Hi Pankaj, > > Clearing current selection each time the selection mode is changed > could be a good solution for the issue but this may cause > compatibility problems in existing applications. > > I'd suggest you try to preserve the consistent part of the current > selection, at least the topmost single row. > > --Semyon > > On 09/26/2017 11:17 PM, Pankaj Bansal wrote: > > Hi All, > > Please review the fix for JDK 10. > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-6463710 > > Webrev: > > http://cr.openjdk.java.net/~aghaisas/pankaj/6463710/webrev.00/ > > > Issue: > > ListSelectionModel.setSelectionMode() or JList.setSelectionMode() > does not change the selection and leaves the selection in > inconsistent state. This bug will affect the JList and JTable as > they both use ListSelectionModel. The JTree uses it indirectly > through TreeSelectionModel which handles it. > > Fix: > > Made changes in ListSelectionModel to check if the selectionMode > has changed and if yes, clear the selection. > > Made changes in JList to make it consistent with JTable. > > Added a test program to test the functionality for > ListSelectionModel.setSelectionMode() > > Regards, > > Pankaj Bansal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ivanov at oracle.com Tue Oct 17 16:42:28 2017 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Tue, 17 Oct 2017 17:42:28 +0100 Subject: [10] Review request for 8182043: Access to Windows Large Icons In-Reply-To: <6b192c97-37bf-9df0-16be-178e0d445417@oracle.com> References: <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com> <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com> <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com> <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com> <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com> <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com> <2ef8eb3e-a1e1-5d86-a5a2-7cc9cc614f07@oracle.com> <64444271-d2e7-7dea-2d11-b635af662112@oracle.com> <96e0bb87-eda9-93c9-6c13-e51c08edefd0@oracle.com> <68e02999-be33-5ca9-2e9d-d1feb6c9446a@oracle.com> <6b192c97-37bf-9df0-16be-178e0d445417@oracle.com> Message-ID: Hi Sergey, Semyon, On 12/10/2017 21:39, Sergey Bylokhov wrote: > On 06/10/2017 17:16, Semyon Sadetsky wrote: >>> The maximum icon which we used before you fix is 32pixel's icon(yes >>> it is a large icon), and 128 is a size of this icon on 4k monitor( >>> The windows can return a 128pixel's icon on 4k monitor) The >>> EXTRA_LARGE and JAMBO was not used in our code. >> So, it is not supposed to work on 8k monitor? Why we should have this >> limit while the native platform hasn't it? > > This is my understanding, before those fix the maximum size was 32x32. It is my understanding too. Thus limiting the size of icon to 128 pixels seemed reasonable. At this moment the buffer for icon pixels is allocated on the stack, therefore the size cannot be dynamic. If memory for icon pixels is allocated dynamically, the limitation can be removed. It makes sense to address this limitation under a separate issue, do you agree? Regards, Alexey >>>> But these constants are related to the predefined system icon sizes >>>> while the Extract() may scale icon to any size. >>> >>> Does it really scale for any size? >>> For example if I request the icon for some pdf,java,txt files of >>> size 100 then: >>> ? - On HiDPI screen I get the native icon of size 64. >>> ? - On LowDPI screen I get the native icon of size 32. >>> In both cases the user will get MRI, which will scale the native icon. >>> http://mail.openjdk.java.net/pipermail/awt-dev/2017-October/013179.html >> Why returning MRI is wrong? > > > The MRI is good, if this is what the user is expected. My point was > that the native system is not scale the icon and the user gets MRI > which content is unrelated to the passed "size". > >> Which calls are you talking about DPI-aware or DPI-unaware? > > This is jdk10client + the current patch. > > From alexey.ivanov at oracle.com Tue Oct 17 17:05:19 2017 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Tue, 17 Oct 2017 18:05:19 +0100 Subject: [10] Review request for 8182043: Access to Windows Large Icons In-Reply-To: References: <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com> <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com> <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com> <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com> <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com> <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com> <59CEA177.5010305@oracle.com> <6b4d35b9-2d1f-0010-a7b6-ed2e17dfa661@oracle.com> <59CED263.4000104@oracle.com> <4cb5fc2d-ea4e-5878-135c-79c368e72bd5@oracle.com> Message-ID: <30d4f814-ae99-cab5-5758-fddb99218eda@oracle.com> Hi Semyon, On 06/10/2017 21:33, Semyon Sadetsky wrote: > Hi Alexey, > > On 10/06/2017 11:42 AM, Alexey Ivanov wrote: >> Hi Semyon, Sergey, >> >> On 30/09/2017 00:08, Semyon Sadetsky wrote: >>> On 9/29/2017 3:15 PM, Sergey Bylokhov wrote: >>>> On 9/29/17 12:39, Semyon Sadetsky wrote: >>>>>>> Why 128 pixels? Windows shell usually provides icons up to 256 >>>>>>> pixels, for example there are 256?256 icons for folders and >>>>>>> generic file type. >>>>>> >>>>>> It is limitation of our implementation: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8151385 >>>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010777.html >>>>>> >>>>>> >>>>> Sergey, it is not clear how those links are related to the icon >>>>> size returned by Windows? >>>> >>>> It was a fix where the MAX_ICON_SIZE=128 was added. >>> Actually it limits nothing. We told about the Extract call which may >>> return any size. >> >> Yes, it does. It limits the size of the returned icon to 128?128. >> I guess if a larger icon is requested, then we'll get a distorted image. > This is artificial limitation when the image is transfered from native > to java. WinAPI may return bigger images without any issues. Yes, I understand it. Yet, it's still a limitation. With the current implementation, the caller of the API cannot get icon larger than 128?128. >>>>>> As far as I understand the bug above, it is possible that OS >>>>>> returns some other size. >>>>> You've probably didn't understand what Alexey meant. The Extract >>>>> call may return any size you request (it does scaling internally >>>>> if there are no suitable image) > But the bug above is about >>>>> queering the fixed size >>>>> (small or long) which size is determined by OS shell according to >>>>> the current scale. For those fixed sizes we use SHGetFileInfo not >>>>> the Extract. >>>> >>>> And every time we will try to make an icon it will be limited to >>>> 128x128. But it is not critical. >>>> >>>> The issue is that this api, as you said, will depends from some >>>> general "current scale". which is unrelated to the transform of the >>>> screen in java. >>>> >>>> If the user will want to use FILE_ICON_LARGE, then to work properly >>>> he will need to use this code every time in the the paint(): >>>> Icon icon = getSystemIcon(file, FILE_ICON_LARGE); >>>> Icon hicon = getSystemIcon(file, >>>> icon.getIconWidth()*currentScreenScale); >>> This is just wrong. The first line is the correct one for both HiDPI >>> and nonHiDPI. If you want to have icons like in native apps. For >>> custom behavior - please use the second line. >>> >> >> Why is it wrong? >> getSystemIcon(file) requests FILE_ICON_SMALL from the OS, then all >> Java has to paint at any DPI scale is 16?16 icon. >> >> Or am I missing anything? > Sorry, I did not get how is the small icon related to the code above. > Probably we understood it differently because the explanation is not? > the best. My interpretation is: > For the low DPI screen one should use icon=getSystemIcon(file, > FILE_ICON_LARGE) when the window is moved to hiDPI screen the > hicon=getSystemIcon(file, icon.getIconWidth()*currentScreenScale) > should be used. And this approach is wrong. > > The primary purpose of the current fix is to fix the compatibility > issue we got when we closed shell folder API in 9. > The user code which doesn't work in 9 should not be changed in the way > proposed by Sergey. This code should be updated to use > getSystemIcon(file, FILE_ICON_LARGE) instead of closed getIcon(true) > and getSystemIcon(file, FILE_ICON_SMALL) instead of closed > getIcon(false). > The newly written code may use getSystemIcon(file, > FILE_ICON_LARGE/SMALL) to get the icon in the native platform which > determines its size at the current DPI (DPI-unaware usage) > or getSystemIcon(file, size) to have any custom size which can be > multiplied by DPI. I see no reason to use both approaches > simultaneously? at any circumstances. > > --Semyon Thank you Semyon for your explanation. I think I understand it better now. In either case, Swing components should use the size in component coordinates. In case of JFileChooser file view, it's FILE_ICON_SMALL. I didn't expect native OS, Windows in my case, to adjust icon resolution automatically to account for HiDPI scaling because documentation for IExtractIcon::Extract [1] does not mention that such scaling is performed. However, my testing [2] with opening JFileChooser in SwingDemo shows that the scaling is performed, at least in some cases. Overall, the fix looks fine. It resolves the stated problem that is it provides access to larger icons via public API. The issues with the current icon size limitation to 128 and with HiDPI support, if any, can be resolved later under separate bug ids. Does it sound sensible? Regards, Alexey [1] https://msdn.microsoft.com/en-us/library/windows/desktop/bb761850%28v=vs.85%29.aspx [2] http://mail.openjdk.java.net/pipermail/awt-dev/2017-October/013181.html From Koen.VanDenBorre at esko.com Wed Oct 18 06:51:03 2017 From: Koen.VanDenBorre at esko.com (Van Den Borre, Koen) Date: Wed, 18 Oct 2017 06:51:03 +0000 Subject: Why is JDK-8188081 not an issue?: Text selection does not clear after focus is lost Message-ID: <5FD0CAEB-8702-4E25-9BD8-F431D0546819@esko.com> Hey, With regards to a JTextField the expected behavior on windows and mac is quite clear. When the focus is lost, the text selection is cleared. When focus is gained all text is selected. I fail to see how one would look at the behavior of notepad to verify what a JTextField should do. Please look at the behavior of a real text field in both mac and windows and observe the behavior. Please re-evaluate this bug report. Thanks, Koen Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment. From semyon.sadetsky at oracle.com Wed Oct 18 17:10:56 2017 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 18 Oct 2017 10:10:56 -0700 Subject: Why is JDK-8188081 not an issue?: Text selection does not clear after focus is lost In-Reply-To: <5FD0CAEB-8702-4E25-9BD8-F431D0546819@esko.com> References: <5FD0CAEB-8702-4E25-9BD8-F431D0546819@esko.com> Message-ID: Hi Koen, Thank you for signaling the issue. I will take care about this bug. --Semyon On 10/17/2017 11:51 PM, Van Den Borre, Koen wrote: > Hey, > > With regards to a JTextField the expected behavior on windows and mac is quite clear. > > When the focus is lost, the text selection is cleared. > When focus is gained all text is selected. > > I fail to see how one would look at the behavior of notepad to verify what a JTextField should do. > Please look at the behavior of a real text field in both mac and windows and observe the behavior. > > Please re-evaluate this bug report. > > Thanks, > > Koen > Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment. From Sergey.Bylokhov at oracle.com Wed Oct 18 20:54:10 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 18 Oct 2017 13:54:10 -0700 Subject: [10] Review Request: 8184219 Fix accessibility of tables in the java.desktop module In-Reply-To: <7b7b2012-af3a-714b-97a8-225cecd4f7aa@oracle.com> References: <7b7b2012-af3a-714b-97a8-225cecd4f7aa@oracle.com> Message-ID: <845bd428-5e1d-edbd-24cd-587057f14bad@oracle.com> FYI. The fix was updated based on offline comments from Jonathan Gibbons(he approved the fix). http://cr.openjdk.java.net/~serb/8184219/webrev.02 On 02/09/2017 17:58, Sergey Bylokhov wrote: > Hello, > Please review the fix for jdk10. > > This is the first step to cleanup these warnings: > http://cr.openjdk.java.net/~jjg/doc-report/jdk-by-module/java.desktop/report.html > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8184219 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8184219/webrev.00 > Specdiff:http://cr.openjdk.java.net/~serb/8184219/specdiff.00/java.desktop-summary.html > > > In this fix most of the "striped" tables in the javadoc of java.desktop > module are updated: > ?- New attribute scope="col/"row" was added to all headers. > ?- Optional tags like , were removed. > ?- Most of custom table styles like "style=text-align:center" were > removed, so all tables now unified. > ?- In a few places the """ was replaced by ", because " is widely > used in our docs anyway. > > Some unchanged tables will be updated later(html files inside doc-files > folder, and some tables which are used for layout). > > More information about a reason for these changes is in the review > request for java.base module: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-July/048519.html > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Oct 18 22:09:43 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 18 Oct 2017 15:09:43 -0700 Subject: [10] Review Request: JDK-6463710 : ListSelectionModel.setSelectionMode() underspecified In-Reply-To: References: Message-ID: <16a8f0e5-9ac8-b0a6-beab-08b1eed9d851@oracle.com> Hi, Pankaj. Can you please tweak a test to use the Swing components on EDT(you can use EventQueue.invokeAndWait()). Also please use 80 chars per line convention. On 28/09/2017 04:57, Pankaj Bansal wrote: > Hi, > > I have updated the webrev for the review comments. Now I have preserved > the consistent part for the selection depending upon old and new > selectionMode. Please review. > > webrev: > > http://cr.openjdk.java.net/~aghaisas/pankaj/6463710/webrev.01/ > > Regards, > > Pankaj Bansal > > *From:*Semyon Sadetsky > *Sent:* Wednesday, September 27, 2017 10:25 PM > *To:* Pankaj Bansal; swing-dev at openjdk.java.net > *Subject:* Re: [10] Review Request: JDK-6463710 : > ListSelectionModel.setSelectionMode() underspecified > > Hi Pankaj, > > Clearing current selection each time the selection mode is changed could > be a good solution for the issue but this may cause compatibility > problems in existing applications. > > I'd suggest you try to preserve the consistent part of the current > selection, at least the topmost single row. > > --Semyon > > On 09/26/2017 11:17 PM, Pankaj Bansal wrote: > > Hi All, > > Please review the fix for JDK 10. > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-6463710 > > Webrev: > > http://cr.openjdk.java.net/~aghaisas/pankaj/6463710/webrev.00/ > > > Issue: > > ListSelectionModel.setSelectionMode() or JList.setSelectionMode() > does not change the selection and leaves the selection in > inconsistent state. This bug will affect the JList and JTable as > they both use ListSelectionModel. The JTree uses it indirectly > through TreeSelectionModel which handles it. > > Fix: > > Made changes in ListSelectionModel to check if the selectionMode has > changed and if yes, clear the selection. > > Made changes in JList to make it consistent with JTable. > > Added a test program to test the functionality for > ListSelectionModel.setSelectionMode() > > Regards, > > Pankaj Bansal > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Oct 18 22:19:10 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 18 Oct 2017 15:19:10 -0700 Subject: [10] RFR JDK-8178025:HiDPI with non-integer scale factor - SPANs in HTML are rendered overlapping each other In-Reply-To: References: <4121aef8-bbae-c5ef-dfe2-d3b8efda318c@oracle.com> <540b95d9-3b3e-2c1d-37cf-a60c8a831cff@oracle.com> <97834ff5-4d40-e267-ff73-8ac3727e7f95@oracle.com> Message-ID: <5993e71c-2605-a81e-b6fc-faa90b7fcaf5@oracle.com> On 17/10/2017 03:48, Prasanta Sadhukhan wrote: > It seems for JLabel, Component.updateGraphicsData() with proper > GraphicsConfiguraiton is never called which it does for JTextComponent > or JDialog. Do you know why? Because of this, correct FRC is not created. > I am not sure what else I can do to create correct FRC. But at some point we will get a correct GraphicsConfiguraiton for a component, right? It should be called for the window and child when we show the window on the screen, when we move the window to another screen, etc. -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Thu Oct 19 10:12:45 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 19 Oct 2017 15:42:45 +0530 Subject: [10] RFR JDK-8178025:HiDPI with non-integer scale factor - SPANs in HTML are rendered overlapping each other In-Reply-To: <5993e71c-2605-a81e-b6fc-faa90b7fcaf5@oracle.com> References: <4121aef8-bbae-c5ef-dfe2-d3b8efda318c@oracle.com> <540b95d9-3b3e-2c1d-37cf-a60c8a831cff@oracle.com> <97834ff5-4d40-e267-ff73-8ac3727e7f95@oracle.com> <5993e71c-2605-a81e-b6fc-faa90b7fcaf5@oracle.com> Message-ID: <0f39426f-e681-cb50-6db6-dce5824734d6@oracle.com> On 10/19/2017 3:49 AM, Sergey Bylokhov wrote: > On 17/10/2017 03:48, Prasanta Sadhukhan wrote: >> It seems for JLabel, Component.updateGraphicsData() with proper >> GraphicsConfiguraiton is never called which it does for >> JTextComponent or JDialog. Do you know why? Because of this, correct >> FRC is not created. >> I am not sure what else I can do to create correct FRC. > > But at some point we will get a correct GraphicsConfiguraiton for a > component, right? It should be called for the window and child when we > show the window on the screen, when we move the window to another > screen, etc. > > Yes, it seems to be called when JLabel is added to JFrame but not before. Span is calculated in GlyphPainter1.getSpan() which is called when JLabel is created and as it seems, not when JLabel is added to JFrame (which is when we get the correct graphics configuration and therefore correct transform). So, we need to make sure spans are recalculated when the JLabel is added to frame, which is what modified webrev does by calling JLabel.updateUI() http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.01/ Regards Prasana From javalists at cbfiddle.com Thu Oct 19 14:24:18 2017 From: javalists at cbfiddle.com (Alan Snyder) Date: Thu, 19 Oct 2017 07:24:18 -0700 Subject: [10] RFR JDK-8178025:HiDPI with non-integer scale factor - SPANs in HTML are rendered overlapping each other In-Reply-To: <0f39426f-e681-cb50-6db6-dce5824734d6@oracle.com> References: <4121aef8-bbae-c5ef-dfe2-d3b8efda318c@oracle.com> <540b95d9-3b3e-2c1d-37cf-a60c8a831cff@oracle.com> <97834ff5-4d40-e267-ff73-8ac3727e7f95@oracle.com> <5993e71c-2605-a81e-b6fc-faa90b7fcaf5@oracle.com> <0f39426f-e681-cb50-6db6-dce5824734d6@oracle.com> Message-ID: Do you mean JLabel.updateGraphicsData()? Also, this issue could affect applications as well, if they are computing data based on layout information such as the default preferred size. What is the recommended method for an application to respond to a change in the graphics configuration? From looking at the code, it appears that addNotify() would be the right place, but I would never guess that just from the documentation. Alan > On Oct 19, 2017, at 3:12 AM, Prasanta Sadhukhan wrote: > > > > On 10/19/2017 3:49 AM, Sergey Bylokhov wrote: >> On 17/10/2017 03:48, Prasanta Sadhukhan wrote: >>> It seems for JLabel, Component.updateGraphicsData() with proper GraphicsConfiguraiton is never called which it does for JTextComponent or JDialog. Do you know why? Because of this, correct FRC is not created. >>> I am not sure what else I can do to create correct FRC. >> >> But at some point we will get a correct GraphicsConfiguraiton for a component, right? It should be called for the window and child when we show the window on the screen, when we move the window to another screen, etc. >> >> > Yes, it seems to be called when JLabel is added to JFrame but not before. > Span is calculated in GlyphPainter1.getSpan() which is called when JLabel is created and > as it seems, not when JLabel is added to JFrame (which is when we get the correct graphics configuration and therefore correct transform). > > So, we need to make sure spans are recalculated when the JLabel is added to frame, which is what modified webrev does by calling JLabel.updateUI() > http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.01/ > > Regards > Prasana > From semyon.sadetsky at oracle.com Thu Oct 19 18:36:34 2017 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 19 Oct 2017 11:36:34 -0700 Subject: [10] Review request for 8188081: Text selection does not clear after focus is lost Message-ID: Hello, Please review fix for JDK10 (the changes involve AWT and Swing): bug: https://bugs.openjdk.java.net/browse/JDK-8188081 webrev: http://cr.openjdk.java.net/~ssadetsky/8188081/webrev.00 The 8025082 fix is reverted. Swing text selection visibility behavior is changed according to the next rules: - There may be only one visible selection per window. - If the input focus moved to another window selection remains visible or may change its color (depends on L&F). - Selection may not be shown in the same color in several windows simultaneously. - Activating a popup menu does not hide the current selection. The fix should make Swing selection visibility behaving in standard way as in native systems UIs. --Semyon From javalists at cbfiddle.com Thu Oct 19 19:10:13 2017 From: javalists at cbfiddle.com (Alan Snyder) Date: Thu, 19 Oct 2017 12:10:13 -0700 Subject: [10] Review request for 8188081: Text selection does not clear after focus is lost In-Reply-To: References: Message-ID: <51DAA3AF-19C6-4260-B297-404229587D48@cbfiddle.com> I?m confused about this part. Couldn?t a selection be in more than one inactive window at the same time and thus all use the inactive selection color? Alan > On Oct 19, 2017, at 11:36 AM, Semyon Sadetsky wrote: > > - Selection may not be shown in the same color in several windows simultaneously. -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Thu Oct 19 19:29:06 2017 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 19 Oct 2017 12:29:06 -0700 Subject: [10] Review request for 8188081: Text selection does not clear after focus is lost In-Reply-To: <51DAA3AF-19C6-4260-B297-404229587D48@cbfiddle.com> References: <51DAA3AF-19C6-4260-B297-404229587D48@cbfiddle.com> Message-ID: <359deaef-9809-4ed5-c8b8-ffa8281dc0f7@oracle.com> Yes, an inactive selection (if it is supported by L&F) may be shown in several windows at the same time. I meant the global (active) selection which can be only one. Also, I missed that selection may be shown only for the focused component in the window. This is reflected in the bug title also. --Semyon On 10/19/2017 12:10 PM, Alan Snyder wrote: > I?m confused about this part. Couldn?t a selection be in more than one > inactive window at the same time and thus all use the inactive > selection color? > > ? Alan > >> On Oct 19, 2017, at 11:36 AM, Semyon Sadetsky >> > wrote: >> >> - Selection may not be shown in the same color in several windows >> simultaneously. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Oct 19 21:46:24 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 19 Oct 2017 14:46:24 -0700 Subject: [OpenJDK 2D-Dev] [10] Review Request: 8187399 Different problems in the javadoc's links in java.desktop package In-Reply-To: References: <8d147726-4e2f-b633-29e5-9ffd7c4cfb54@oracle.com> <9ad3322c-3333-555c-6f53-6321eab1435e@oracle.com> <1b9669d9-80e2-bc6c-b693-4b04c479d3d8@oracle.com> Message-ID: <7d3a517e-bc35-7531-a2d5-25caa6238454@oracle.com> Hello. If there are no other comments I'll push the .01 version of fix. On 13/10/2017 01:04, Alexander Zvegintsev wrote: > +1 > > Thanks, > Alexander. > > On 16/09/2017 07:16, Sergey Bylokhov wrote: >> That's of course a stylistic issue, but I think that the keywords(not >> necessary a java) look better when they are highlighted. Depending >> from the style it can look like this: >> http://cr.openjdk.java.net/~serb/8187399/img.png >> >> Here is an updated webrev: >> http://cr.openjdk.java.net/~serb/8187399/webrev.01 >> ?- The link to the "Apple Developer Documentation" was added. >> ?- Info.plist is also wrapped in the {@code} >> ?- Mac OS was replaced by macOS >> >> >> On 9/15/17 12:34, Phil Race wrote: >>> 771????? * @implNote Please note that for Mac OS, notifications >>> ? 772????? * are only sent if the Java app is a bundled application, >>> ? 773????? * with a {@code CFBundleDocumentTypes} array present in its >>> 774 * Info.plist. >>> >>> >>> Should we be using {@code ..} for CFBundleDocumentTypes. It is not >>> Java code, >>> but this makes it look like it is. >>> >>> I think we should have some reference to "go see Apple developer >>> docs" to find out what >>> that and Info.plist are .. even if it not a direct link. >>> >>> -phil. >>> >>> >>> On 09/13/2017 03:39 PM, Sergey Bylokhov wrote: >>>> Hello, >>>> Please review the fix for jdk10. >>>> >>>> Some of the tidy warnings were fixed. >>>> Report is here: >>>> http://cr.openjdk.java.net/~jjg/doc-report/jdk-by-module/java.desktop/report.html >>>> >>>> >>>> Description: >>>> ?- java/awt/Desktop.java: the links to "developer.apple.com" were >>>> removed, it seems that the URLs for these documents are changed over >>>> time as well as content. We will mention only >>>> "CFBundleDocumentTypes" and "Info.plist" in the description. >>>> ?- javax/print/attribute/standard/PresentationDirection.java: the >>>> link was changed from ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf >>>> to ftp://ftp.pwg.org/pub/pwg/standards/temp_archive/pwg5100.3.pdf , >>>> but I guess this is a stable location because the files are there >>>> from 2004. >>>> ?- others are just broken links which were fixed. >>>> >>>> I checked the whole list of links in the desktop module, and found >>>> that some of them are broken. For example I cannot find an official >>>> place for the tiff specification(and related documents). Also during >>>> migration from sun.com we lost some documents, I leave such links >>>> as-is, and plan to resurrect the documents somewhere. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8187399 >>>> Webrev can be found at: >>>> http://cr.openjdk.java.net/~serb/8187399/webrev.00 >>>> >>>> >>> >> >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri Oct 20 00:23:03 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 19 Oct 2017 17:23:03 -0700 Subject: [10] Review request for 8188081: Text selection does not clear after focus is lost In-Reply-To: References: Message-ID: <58cc6ddb-1ab0-8bfb-5d13-02316ab0a0bd@oracle.com> Hi, Semyon. On 19/10/2017 11:36, Semyon Sadetsky wrote: > The 8025082 fix is reverted. Swing text selection visibility behavior is > changed according to the next rules: Please recheck that the bug 8025082 is not reproducible. It was a jck bug which should fix in one way or another. -- Best regards, Sergey. From semyon.sadetsky at oracle.com Fri Oct 20 04:01:09 2017 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 19 Oct 2017 21:01:09 -0700 Subject: [10] Review request for 8188081: Text selection does not clear after focus is lost In-Reply-To: <58cc6ddb-1ab0-8bfb-5d13-02316ab0a0bd@oracle.com> References: <58cc6ddb-1ab0-8bfb-5d13-02316ab0a0bd@oracle.com> Message-ID: Hi Sergey, Actually the 8025082 was a JCK issue. It doesn't need to be fixed in JDK. --Semyon On 10/19/2017 05:23 PM, Sergey Bylokhov wrote: > Hi, Semyon. > On 19/10/2017 11:36, Semyon Sadetsky wrote: >> The 8025082 fix is reverted. Swing text selection visibility behavior >> is changed according to the next rules: > > Please recheck that the bug 8025082 is not reproducible. It was a jck > bug which should fix in one way or another. > > From prasanta.sadhukhan at oracle.com Fri Oct 20 05:21:25 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 20 Oct 2017 10:51:25 +0530 Subject: [10] RFR JDK-8178025:HiDPI with non-integer scale factor - SPANs in HTML are rendered overlapping each other In-Reply-To: References: <4121aef8-bbae-c5ef-dfe2-d3b8efda318c@oracle.com> <540b95d9-3b3e-2c1d-37cf-a60c8a831cff@oracle.com> <97834ff5-4d40-e267-ff73-8ac3727e7f95@oracle.com> <5993e71c-2605-a81e-b6fc-faa90b7fcaf5@oracle.com> <0f39426f-e681-cb50-6db6-dce5824734d6@oracle.com> Message-ID: <7adf151b-a21f-0f90-dee9-761401db06e6@oracle.com> updateGraphicsData() is called implicitly when component is added to frame. We need to call JLabel.updateUI() for this, as it will trigger calling BasicHTML.updateRenderer() which will go on to recalculate spans. Ideally, I would guess, we should wait for propertyChange() in BasicLabelUI to be called when graphics configuration is updated but I only see it being called with "ancestor" property name, I am not sure if that is property that would be used to notify if gc is updated or not. Regards Prasanta On 10/19/2017 7:54 PM, Alan Snyder wrote: > Do you mean JLabel.updateGraphicsData()? > > Also, this issue could affect applications as well, if they are computing data based on layout information such as the default preferred size. > > What is the recommended method for an application to respond to a change in the graphics configuration? > > From looking at the code, it appears that addNotify() would be the right place, but I would never guess that just from the documentation. > > Alan > > > >> On Oct 19, 2017, at 3:12 AM, Prasanta Sadhukhan wrote: >> >> >> >> On 10/19/2017 3:49 AM, Sergey Bylokhov wrote: >>> On 17/10/2017 03:48, Prasanta Sadhukhan wrote: >>>> It seems for JLabel, Component.updateGraphicsData() with proper GraphicsConfiguraiton is never called which it does for JTextComponent or JDialog. Do you know why? Because of this, correct FRC is not created. >>>> I am not sure what else I can do to create correct FRC. >>> But at some point we will get a correct GraphicsConfiguraiton for a component, right? It should be called for the window and child when we show the window on the screen, when we move the window to another screen, etc. >>> >>> >> Yes, it seems to be called when JLabel is added to JFrame but not before. >> Span is calculated in GlyphPainter1.getSpan() which is called when JLabel is created and >> as it seems, not when JLabel is added to JFrame (which is when we get the correct graphics configuration and therefore correct transform). >> >> So, we need to make sure spans are recalculated when the JLabel is added to frame, which is what modified webrev does by calling JLabel.updateUI() >> http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.01/ >> >> Regards >> Prasana >> From pankaj.b.bansal at oracle.com Fri Oct 20 11:11:58 2017 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Fri, 20 Oct 2017 04:11:58 -0700 (PDT) Subject: [10] Review Request: JDK-6463710 : ListSelectionModel.setSelectionMode() underspecified In-Reply-To: <16a8f0e5-9ac8-b0a6-beab-08b1eed9d851@oracle.com> References: <16a8f0e5-9ac8-b0a6-beab-08b1eed9d851@oracle.com> Message-ID: <4a7d0a9a-889e-4a84-a6e4-bfa4f5300c0b@default> Hi Sergey, I have updated the webrev for the changes you have proposed. Please have a look. Webrev http://cr.openjdk.java.net/~aghaisas/pankaj/6463710/webrev.02/ Regards, Pankaj Bansal -----Original Message----- From: Sergey Bylokhov Sent: Thursday, October 19, 2017 3:40 AM To: Pankaj Bansal; Semyon Sadetsky; swing-dev at openjdk.java.net Subject: Re: [10] Review Request: JDK-6463710 : ListSelectionModel.setSelectionMode() underspecified Hi, Pankaj. Can you please tweak a test to use the Swing components on EDT(you can use EventQueue.invokeAndWait()). Also please use 80 chars per line convention. On 28/09/2017 04:57, Pankaj Bansal wrote: > Hi, > > I have updated the webrev for the review comments. Now I have > preserved the consistent part for the selection depending upon old and > new selectionMode. Please review. > > webrev: > > http://cr.openjdk.java.net/~aghaisas/pankaj/6463710/webrev.01/ > > Regards, > > Pankaj Bansal > > *From:*Semyon Sadetsky > *Sent:* Wednesday, September 27, 2017 10:25 PM > *To:* Pankaj Bansal; swing-dev at openjdk.java.net > *Subject:* Re: [10] Review Request: JDK-6463710 : > ListSelectionModel.setSelectionMode() underspecified > > Hi Pankaj, > > Clearing current selection each time the selection mode is changed > could be a good solution for the issue but this may cause > compatibility problems in existing applications. > > I'd suggest you try to preserve the consistent part of the current > selection, at least the topmost single row. > > --Semyon > > On 09/26/2017 11:17 PM, Pankaj Bansal wrote: > > Hi All, > > Please review the fix for JDK 10. > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-6463710 > > Webrev: > > http://cr.openjdk.java.net/~aghaisas/pankaj/6463710/webrev.00/ > > > Issue: > > ListSelectionModel.setSelectionMode() or JList.setSelectionMode() > does not change the selection and leaves the selection in > inconsistent state. This bug will affect the JList and JTable as > they both use ListSelectionModel. The JTree uses it indirectly > through TreeSelectionModel which handles it. > > Fix: > > Made changes in ListSelectionModel to check if the selectionMode has > changed and if yes, clear the selection. > > Made changes in JList to make it consistent with JTable. > > Added a test program to test the functionality for > ListSelectionModel.setSelectionMode() > > Regards, > > Pankaj Bansal > -- Best regards, Sergey. From javalists at cbfiddle.com Fri Oct 20 14:39:08 2017 From: javalists at cbfiddle.com (Alan Snyder) Date: Fri, 20 Oct 2017 07:39:08 -0700 Subject: [10] RFR JDK-8178025:HiDPI with non-integer scale factor - SPANs in HTML are rendered overlapping each other In-Reply-To: <7adf151b-a21f-0f90-dee9-761401db06e6@oracle.com> References: <4121aef8-bbae-c5ef-dfe2-d3b8efda318c@oracle.com> <540b95d9-3b3e-2c1d-37cf-a60c8a831cff@oracle.com> <97834ff5-4d40-e267-ff73-8ac3727e7f95@oracle.com> <5993e71c-2605-a81e-b6fc-faa90b7fcaf5@oracle.com> <0f39426f-e681-cb50-6db6-dce5824734d6@oracle.com> <7adf151b-a21f-0f90-dee9-761401db06e6@oracle.com> Message-ID: updateGraphicsData() is also called when the graphics configuration changes, which is what you want. Without that, you are stuck with the default graphics configuration, which is all that is available until the window is displayed. updateUI() seems like the wrong place to trigger the layout related recalculation, as layout calculation is only one of things that updateUI() does. Alan > On Oct 19, 2017, at 10:21 PM, Prasanta Sadhukhan wrote: > > updateGraphicsData() is called implicitly when component is added to frame. > We need to call JLabel.updateUI() for this, as it will trigger calling BasicHTML.updateRenderer() which will go on to recalculate spans. > Ideally, I would guess, we should wait for propertyChange() in BasicLabelUI to be called when graphics configuration is updated > but I only see it being called with "ancestor" property name, I am not sure if that is property that would be used to notify if gc is updated or not. > > Regards > Prasanta > On 10/19/2017 7:54 PM, Alan Snyder wrote: >> Do you mean JLabel.updateGraphicsData()? >> >> Also, this issue could affect applications as well, if they are computing data based on layout information such as the default preferred size. >> >> What is the recommended method for an application to respond to a change in the graphics configuration? >> >> From looking at the code, it appears that addNotify() would be the right place, but I would never guess that just from the documentation. >> >> Alan >> >> >> >>> On Oct 19, 2017, at 3:12 AM, Prasanta Sadhukhan wrote: >>> >>> >>> >>> On 10/19/2017 3:49 AM, Sergey Bylokhov wrote: >>>> On 17/10/2017 03:48, Prasanta Sadhukhan wrote: >>>>> It seems for JLabel, Component.updateGraphicsData() with proper GraphicsConfiguraiton is never called which it does for JTextComponent or JDialog. Do you know why? Because of this, correct FRC is not created. >>>>> I am not sure what else I can do to create correct FRC. >>>> But at some point we will get a correct GraphicsConfiguraiton for a component, right? It should be called for the window and child when we show the window on the screen, when we move the window to another screen, etc. >>>> >>>> >>> Yes, it seems to be called when JLabel is added to JFrame but not before. >>> Span is calculated in GlyphPainter1.getSpan() which is called when JLabel is created and >>> as it seems, not when JLabel is added to JFrame (which is when we get the correct graphics configuration and therefore correct transform). >>> >>> So, we need to make sure spans are recalculated when the JLabel is added to frame, which is what modified webrev does by calling JLabel.updateUI() >>> http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.01/ >>> >>> Regards >>> Prasana >>> > From prasanta.sadhukhan at oracle.com Fri Oct 20 17:01:19 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 20 Oct 2017 22:31:19 +0530 Subject: [10] RFR JDK-8178025:HiDPI with non-integer scale factor - SPANs in HTML are rendered overlapping each other In-Reply-To: References: <4121aef8-bbae-c5ef-dfe2-d3b8efda318c@oracle.com> <540b95d9-3b3e-2c1d-37cf-a60c8a831cff@oracle.com> <97834ff5-4d40-e267-ff73-8ac3727e7f95@oracle.com> <5993e71c-2605-a81e-b6fc-faa90b7fcaf5@oracle.com> <0f39426f-e681-cb50-6db6-dce5824734d6@oracle.com> <7adf151b-a21f-0f90-dee9-761401db06e6@oracle.com> Message-ID: <8c7a0a99-2381-c0c4-b387-a30ca28982c9@oracle.com> I do not see how updateGraphicsData() woud trigger layout/span calculation. Moreover, it has package-protected access to be called for JLabel. Regards Prasanta On 10/20/2017 8:09 PM, Alan Snyder wrote: > updateGraphicsData() is also called when the graphics configuration changes, which is what you want. > > Without that, you are stuck with the default graphics configuration, which is all that is available until the window is displayed. > > updateUI() seems like the wrong place to trigger the layout related recalculation, as layout calculation is only one of things that updateUI() does. > > Alan > > > >> On Oct 19, 2017, at 10:21 PM, Prasanta Sadhukhan wrote: >> >> updateGraphicsData() is called implicitly when component is added to frame. >> We need to call JLabel.updateUI() for this, as it will trigger calling BasicHTML.updateRenderer() which will go on to recalculate spans. >> Ideally, I would guess, we should wait for propertyChange() in BasicLabelUI to be called when graphics configuration is updated >> but I only see it being called with "ancestor" property name, I am not sure if that is property that would be used to notify if gc is updated or not. >> >> Regards >> Prasanta >> On 10/19/2017 7:54 PM, Alan Snyder wrote: >>> Do you mean JLabel.updateGraphicsData()? >>> >>> Also, this issue could affect applications as well, if they are computing data based on layout information such as the default preferred size. >>> >>> What is the recommended method for an application to respond to a change in the graphics configuration? >>> >>> From looking at the code, it appears that addNotify() would be the right place, but I would never guess that just from the documentation. >>> >>> Alan >>> >>> >>> >>>> On Oct 19, 2017, at 3:12 AM, Prasanta Sadhukhan wrote: >>>> >>>> >>>> >>>> On 10/19/2017 3:49 AM, Sergey Bylokhov wrote: >>>>> On 17/10/2017 03:48, Prasanta Sadhukhan wrote: >>>>>> It seems for JLabel, Component.updateGraphicsData() with proper GraphicsConfiguraiton is never called which it does for JTextComponent or JDialog. Do you know why? Because of this, correct FRC is not created. >>>>>> I am not sure what else I can do to create correct FRC. >>>>> But at some point we will get a correct GraphicsConfiguraiton for a component, right? It should be called for the window and child when we show the window on the screen, when we move the window to another screen, etc. >>>>> >>>>> >>>> Yes, it seems to be called when JLabel is added to JFrame but not before. >>>> Span is calculated in GlyphPainter1.getSpan() which is called when JLabel is created and >>>> as it seems, not when JLabel is added to JFrame (which is when we get the correct graphics configuration and therefore correct transform). >>>> >>>> So, we need to make sure spans are recalculated when the JLabel is added to frame, which is what modified webrev does by calling JLabel.updateUI() >>>> http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.01/ >>>> >>>> Regards >>>> Prasana >>>> From javalists at cbfiddle.com Fri Oct 20 17:10:52 2017 From: javalists at cbfiddle.com (Alan Snyder) Date: Fri, 20 Oct 2017 10:10:52 -0700 Subject: [10] RFR JDK-8178025:HiDPI with non-integer scale factor - SPANs in HTML are rendered overlapping each other In-Reply-To: <8c7a0a99-2381-c0c4-b387-a30ca28982c9@oracle.com> References: <4121aef8-bbae-c5ef-dfe2-d3b8efda318c@oracle.com> <540b95d9-3b3e-2c1d-37cf-a60c8a831cff@oracle.com> <97834ff5-4d40-e267-ff73-8ac3727e7f95@oracle.com> <5993e71c-2605-a81e-b6fc-faa90b7fcaf5@oracle.com> <0f39426f-e681-cb50-6db6-dce5824734d6@oracle.com> <7adf151b-a21f-0f90-dee9-761401db06e6@oracle.com> <8c7a0a99-2381-c0c4-b387-a30ca28982c9@oracle.com> Message-ID: <97BA17E8-B56F-421F-80B0-39247E5C01B6@cbfiddle.com> Code would have to be changed to make it do that. I?m suggesting that is the right hook, but it is up to you to use it. Presumably as Swing is part of the JDK, access can be arranged... > On Oct 20, 2017, at 10:01 AM, Prasanta Sadhukhan wrote: > > I do not see how updateGraphicsData() woud trigger layout/span calculation. Moreover, it has package-protected access to be called for JLabel. > > Regards > Prasanta From Sergey.Bylokhov at oracle.com Fri Oct 20 19:36:48 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 20 Oct 2017 12:36:48 -0700 Subject: [10] Review request for 8188081: Text selection does not clear after focus is lost In-Reply-To: References: <58cc6ddb-1ab0-8bfb-5d13-02316ab0a0bd@oracle.com> Message-ID: On 19/10/2017 21:01, Semyon Sadetsky wrote: > Actually the 8025082 was a JCK issue. It doesn't need to be fixed in JDK. Ok, Looks fine. > > --Semyon > > > On 10/19/2017 05:23 PM, Sergey Bylokhov wrote: >> Hi, Semyon. >> On 19/10/2017 11:36, Semyon Sadetsky wrote: >>> The 8025082 fix is reverted. Swing text selection visibility behavior >>> is changed according to the next rules: >> >> Please recheck that the bug 8025082 is not reproducible. It was a jck >> bug which should fix in one way or another. >> >> > -- Best regards, Sergey. From javalists at cbfiddle.com Sat Oct 21 17:17:24 2017 From: javalists at cbfiddle.com (Alan Snyder) Date: Sat, 21 Oct 2017 10:17:24 -0700 Subject: Swing performance issue on JDK 9 Message-ID: I have a Swing program that works fine on JDK 8 but runs like a dog [unusably slowly] on JDK 9. My investigation finds the problem in text layout (e.g. FlowView.layout), which is a whopping 20?25 times slower on JDK 9. Any idea what might have changed to cause this slowdown? Could it be the result of the new String implementation? Alan From prasanta.sadhukhan at oracle.com Mon Oct 23 06:23:50 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 23 Oct 2017 11:53:50 +0530 Subject: [10] RFR JDK-8178025:HiDPI with non-integer scale factor - SPANs in HTML are rendered overlapping each other In-Reply-To: <0f39426f-e681-cb50-6db6-dce5824734d6@oracle.com> References: <4121aef8-bbae-c5ef-dfe2-d3b8efda318c@oracle.com> <540b95d9-3b3e-2c1d-37cf-a60c8a831cff@oracle.com> <97834ff5-4d40-e267-ff73-8ac3727e7f95@oracle.com> <5993e71c-2605-a81e-b6fc-faa90b7fcaf5@oracle.com> <0f39426f-e681-cb50-6db6-dce5824734d6@oracle.com> Message-ID: <49bcfe1b-2818-ba85-c479-a9b8e85b33e4@oracle.com> On 10/19/2017 3:42 PM, Prasanta Sadhukhan wrote: > > > On 10/19/2017 3:49 AM, Sergey Bylokhov wrote: >> On 17/10/2017 03:48, Prasanta Sadhukhan wrote: >>> It seems for JLabel, Component.updateGraphicsData() with proper >>> GraphicsConfiguraiton is never called which it does for >>> JTextComponent or JDialog. Do you know why? Because of this, correct >>> FRC is not created. >>> I am not sure what else I can do to create correct FRC. >> >> But at some point we will get a correct GraphicsConfiguraiton for a >> component, right? It should be called for the window and child when >> we show the window on the screen, when we move the window to another >> screen, etc. >> >> > Yes, it seems to be called when JLabel is added to JFrame but not before. > Span is calculated in GlyphPainter1.getSpan() which is called when > JLabel is created and > as it seems, not when JLabel is added to JFrame (which is when we get > the correct graphics configuration and therefore correct transform). > > So, we need to make sure spans are recalculated when the JLabel is > added to frame, which is what modified webrev does by calling > JLabel.updateUI() > http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.01/ > Modified webrev to only update html renderer when JLabel is added to frame by listening to property "ancestor" which implies component is added/made visible, at which point correct graphics configuration is set. http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.02/ Regards Prasanta > Regards > Prasana > From prasanta.sadhukhan at oracle.com Mon Oct 23 07:03:16 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 23 Oct 2017 12:33:16 +0530 Subject: [10] Review request for 8188081: Text selection does not clear after focus is lost In-Reply-To: References: Message-ID: Hi Semyon, looks good to me. BTW, Test copyright should update the year. Since, we are reverting 8025082, shouldn't we re(clone/open) the bug and move it to JCK project so that it does not get raised again? Regards Prasanta On 10/20/2017 12:06 AM, Semyon Sadetsky wrote: > Hello, > > Please review fix for JDK10 (the changes involve AWT and Swing): > > bug: https://bugs.openjdk.java.net/browse/JDK-8188081 > > webrev: http://cr.openjdk.java.net/~ssadetsky/8188081/webrev.00 > > The 8025082 fix is reverted. Swing text selection visibility behavior > is changed according to the next rules: > > - There may be only one visible selection per window. > > - If the input focus moved to another window selection remains visible > or may change its color (depends on L&F). > > - Selection may not be shown in the same color in several windows > simultaneously. > > - Activating a popup menu does not hide the current selection. > > The fix should make Swing selection visibility behaving in standard > way as in native systems UIs. > > --Semyon > > From javalists at cbfiddle.com Mon Oct 23 14:21:06 2017 From: javalists at cbfiddle.com (Alan Snyder) Date: Mon, 23 Oct 2017 07:21:06 -0700 Subject: [10] RFR JDK-8178025:HiDPI with non-integer scale factor - SPANs in HTML are rendered overlapping each other In-Reply-To: <49bcfe1b-2818-ba85-c479-a9b8e85b33e4@oracle.com> References: <4121aef8-bbae-c5ef-dfe2-d3b8efda318c@oracle.com> <540b95d9-3b3e-2c1d-37cf-a60c8a831cff@oracle.com> <97834ff5-4d40-e267-ff73-8ac3727e7f95@oracle.com> <5993e71c-2605-a81e-b6fc-faa90b7fcaf5@oracle.com> <0f39426f-e681-cb50-6db6-dce5824734d6@oracle.com> <49bcfe1b-2818-ba85-c479-a9b8e85b33e4@oracle.com> Message-ID: Does it handle the case where the graphics configuration is later changed? Alan > On Oct 22, 2017, at 11:23 PM, Prasanta Sadhukhan wrote: > > > > On 10/19/2017 3:42 PM, Prasanta Sadhukhan wrote: >> >> >> On 10/19/2017 3:49 AM, Sergey Bylokhov wrote: >>> On 17/10/2017 03:48, Prasanta Sadhukhan wrote: >>>> It seems for JLabel, Component.updateGraphicsData() with proper GraphicsConfiguraiton is never called which it does for JTextComponent or JDialog. Do you know why? Because of this, correct FRC is not created. >>>> I am not sure what else I can do to create correct FRC. >>> >>> But at some point we will get a correct GraphicsConfiguraiton for a component, right? It should be called for the window and child when we show the window on the screen, when we move the window to another screen, etc. >>> >>> >> Yes, it seems to be called when JLabel is added to JFrame but not before. >> Span is calculated in GlyphPainter1.getSpan() which is called when JLabel is created and >> as it seems, not when JLabel is added to JFrame (which is when we get the correct graphics configuration and therefore correct transform). >> >> So, we need to make sure spans are recalculated when the JLabel is added to frame, which is what modified webrev does by calling JLabel.updateUI() >> http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.01/ >> > Modified webrev to only update html renderer when JLabel is added to frame by listening to property "ancestor" which implies component is added/made visible, at which point correct graphics configuration is set. > http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.02/ > > Regards > Prasanta >> Regards >> Prasana -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Mon Oct 23 15:08:00 2017 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 23 Oct 2017 08:08:00 -0700 Subject: Swing performance issue on JDK 9 In-Reply-To: References: Message-ID: <8a90f490-b163-cf52-796f-d60b44417542@oracle.com> Hi Alan, Do you have a test to reproduce the issue or can you describe the steps to reveal it? --Semyon On 10/21/2017 10:17 AM, Alan Snyder wrote: > I have a Swing program that works fine on JDK 8 but runs like a dog [unusably slowly] on JDK 9. My investigation finds the problem in text layout (e.g. FlowView.layout), which is a whopping 20?25 times slower on JDK 9. > > Any idea what might have changed to cause this slowdown? > > Could it be the result of the new String implementation? > > Alan > From semyon.sadetsky at oracle.com Mon Oct 23 17:30:28 2017 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 23 Oct 2017 10:30:28 -0700 Subject: Swing performance issue on JDK 9 In-Reply-To: <8a90f490-b163-cf52-796f-d60b44417542@oracle.com> References: <8a90f490-b163-cf52-796f-d60b44417542@oracle.com> Message-ID: <8607e525-9eca-5c77-021c-d6784325ff42@oracle.com> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8189809 --Semyon On 10/23/2017 08:08 AM, Semyon Sadetsky wrote: > Hi Alan, > > Do you have a test to reproduce the issue or can you describe the > steps to reveal it? > > --Semyon > > > On 10/21/2017 10:17 AM, Alan Snyder wrote: >> I have a Swing program that works fine on JDK 8 but runs like a dog >> [unusably slowly] on JDK 9. My investigation finds the problem in >> text layout (e.g. FlowView.layout), which is a whopping 20?25 times >> slower on JDK 9. >> >> Any idea what might have changed to cause this slowdown? >> >> Could it be the result of the new String implementation? >> >> ?? Alan >> > From Sergey.Bylokhov at oracle.com Mon Oct 23 17:32:54 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 23 Oct 2017 10:32:54 -0700 Subject: [10] Review Request: JDK-6463710 : ListSelectionModel.setSelectionMode() underspecified In-Reply-To: <4a7d0a9a-889e-4a84-a6e4-bfa4f5300c0b@default> References: <16a8f0e5-9ac8-b0a6-beab-08b1eed9d851@oracle.com> <4a7d0a9a-889e-4a84-a6e4-bfa4f5300c0b@default> Message-ID: <802421e8-4b7c-f31e-195c-add4e692e9df@oracle.com> Looks fine, but before the push please update the comments in DefaultListSelectionModel.java to fit 80 chars per line as well. On 20/10/2017 04:11, Pankaj Bansal wrote: > Hi Sergey, > > I have updated the webrev for the changes you have proposed. Please have a look. > Webrev > http://cr.openjdk.java.net/~aghaisas/pankaj/6463710/webrev.02/ > > Regards, > Pankaj Bansal > > -----Original Message----- > From: Sergey Bylokhov > Sent: Thursday, October 19, 2017 3:40 AM > To: Pankaj Bansal; Semyon Sadetsky; swing-dev at openjdk.java.net > Subject: Re: [10] Review Request: JDK-6463710 : ListSelectionModel.setSelectionMode() underspecified > > Hi, Pankaj. > Can you please tweak a test to use the Swing components on EDT(you can use EventQueue.invokeAndWait()). Also please use 80 chars per line convention. > > On 28/09/2017 04:57, Pankaj Bansal wrote: >> Hi, >> >> I have updated the webrev for the review comments. Now I have >> preserved the consistent part for the selection depending upon old and >> new selectionMode. Please review. >> >> webrev: >> >> http://cr.openjdk.java.net/~aghaisas/pankaj/6463710/webrev.01/ >> >> Regards, >> >> Pankaj Bansal >> >> *From:*Semyon Sadetsky >> *Sent:* Wednesday, September 27, 2017 10:25 PM >> *To:* Pankaj Bansal; swing-dev at openjdk.java.net >> *Subject:* Re: [10] Review Request: JDK-6463710 : >> ListSelectionModel.setSelectionMode() underspecified >> >> Hi Pankaj, >> >> Clearing current selection each time the selection mode is changed >> could be a good solution for the issue but this may cause >> compatibility problems in existing applications. >> >> I'd suggest you try to preserve the consistent part of the current >> selection, at least the topmost single row. >> >> --Semyon >> >> On 09/26/2017 11:17 PM, Pankaj Bansal wrote: >> >> Hi All, >> >> Please review the fix for JDK 10. >> >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-6463710 >> >> Webrev: >> >> http://cr.openjdk.java.net/~aghaisas/pankaj/6463710/webrev.00/ >> >> >> Issue: >> >> ListSelectionModel.setSelectionMode() or JList.setSelectionMode() >> does not change the selection and leaves the selection in >> inconsistent state. This bug will affect the JList and JTable as >> they both use ListSelectionModel. The JTree uses it indirectly >> through TreeSelectionModel which handles it. >> >> Fix: >> >> Made changes in ListSelectionModel to check if the selectionMode has >> changed and if yes, clear the selection. >> >> Made changes in JList to make it consistent with JTable. >> >> Added a test program to test the functionality for >> ListSelectionModel.setSelectionMode() >> >> Regards, >> >> Pankaj Bansal >> > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From semyon.sadetsky at oracle.com Mon Oct 23 17:36:34 2017 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 23 Oct 2017 10:36:34 -0700 Subject: [10] Review Request: JDK-6463710 : ListSelectionModel.setSelectionMode() underspecified In-Reply-To: <4a7d0a9a-889e-4a84-a6e4-bfa4f5300c0b@default> References: <16a8f0e5-9ac8-b0a6-beab-08b1eed9d851@oracle.com> <4a7d0a9a-889e-4a84-a6e4-bfa4f5300c0b@default> Message-ID: <286c6144-5de6-86df-fc8d-cef256dec31a@oracle.com> +1 --Semyon On 10/20/2017 04:11 AM, Pankaj Bansal wrote: > Hi Sergey, > > I have updated the webrev for the changes you have proposed. Please have a look. > Webrev > http://cr.openjdk.java.net/~aghaisas/pankaj/6463710/webrev.02/ > > Regards, > Pankaj Bansal > > -----Original Message----- > From: Sergey Bylokhov > Sent: Thursday, October 19, 2017 3:40 AM > To: Pankaj Bansal; Semyon Sadetsky; swing-dev at openjdk.java.net > Subject: Re: [10] Review Request: JDK-6463710 : ListSelectionModel.setSelectionMode() underspecified > > Hi, Pankaj. > Can you please tweak a test to use the Swing components on EDT(you can use EventQueue.invokeAndWait()). Also please use 80 chars per line convention. > > On 28/09/2017 04:57, Pankaj Bansal wrote: >> Hi, >> >> I have updated the webrev for the review comments. Now I have >> preserved the consistent part for the selection depending upon old and >> new selectionMode. Please review. >> >> webrev: >> >> http://cr.openjdk.java.net/~aghaisas/pankaj/6463710/webrev.01/ >> >> Regards, >> >> Pankaj Bansal >> >> *From:*Semyon Sadetsky >> *Sent:* Wednesday, September 27, 2017 10:25 PM >> *To:* Pankaj Bansal; swing-dev at openjdk.java.net >> *Subject:* Re: [10] Review Request: JDK-6463710 : >> ListSelectionModel.setSelectionMode() underspecified >> >> Hi Pankaj, >> >> Clearing current selection each time the selection mode is changed >> could be a good solution for the issue but this may cause >> compatibility problems in existing applications. >> >> I'd suggest you try to preserve the consistent part of the current >> selection, at least the topmost single row. >> >> --Semyon >> >> On 09/26/2017 11:17 PM, Pankaj Bansal wrote: >> >> Hi All, >> >> Please review the fix for JDK 10. >> >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-6463710 >> >> Webrev: >> >> http://cr.openjdk.java.net/~aghaisas/pankaj/6463710/webrev.00/ >> >> >> Issue: >> >> ListSelectionModel.setSelectionMode() or JList.setSelectionMode() >> does not change the selection and leaves the selection in >> inconsistent state. This bug will affect the JList and JTable as >> they both use ListSelectionModel. The JTree uses it indirectly >> through TreeSelectionModel which handles it. >> >> Fix: >> >> Made changes in ListSelectionModel to check if the selectionMode has >> changed and if yes, clear the selection. >> >> Made changes in JList to make it consistent with JTable. >> >> Added a test program to test the functionality for >> ListSelectionModel.setSelectionMode() >> >> Regards, >> >> Pankaj Bansal >> > > -- > Best regards, Sergey. From semyon.sadetsky at oracle.com Mon Oct 23 19:50:47 2017 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 23 Oct 2017 12:50:47 -0700 Subject: [10] Review request for 8188081: Text selection does not clear after focus is lost In-Reply-To: References: Message-ID: <257f52aa-900b-fe28-22ac-17bd4ca635fa@oracle.com> Hi Prasanta, I have created JCK-7308916. The year I will change inline, if you don't mind. --Semyon On 10/23/2017 12:03 AM, Prasanta Sadhukhan wrote: > Hi Semyon, > > looks good to me. BTW, Test copyright should update the year. > Since, we are reverting 8025082, shouldn't we re(clone/open) the bug > and move it to JCK project so that it does not get raised again? > > Regards > Prasanta > On 10/20/2017 12:06 AM, Semyon Sadetsky wrote: >> Hello, >> >> Please review fix for JDK10 (the changes involve AWT and Swing): >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8188081 >> >> webrev: http://cr.openjdk.java.net/~ssadetsky/8188081/webrev.00 >> >> The 8025082 fix is reverted. Swing text selection visibility behavior >> is changed according to the next rules: >> >> - There may be only one visible selection per window. >> >> - If the input focus moved to another window selection remains >> visible or may change its color (depends on L&F). >> >> - Selection may not be shown in the same color in several windows >> simultaneously. >> >> - Activating a popup menu does not hide the current selection. >> >> The fix should make Swing selection visibility behaving in standard >> way as in native systems UIs. >> >> --Semyon >> >> > From Sergey.Bylokhov at oracle.com Mon Oct 23 23:22:17 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 23 Oct 2017 16:22:17 -0700 Subject: [10] Review request for 8182043: Access to Windows Large Icons In-Reply-To: References: <2588de5b-b04e-d089-835c-69f73eb993ed@oracle.com> <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com> <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com> <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com> <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com> <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com> <2ef8eb3e-a1e1-5d86-a5a2-7cc9cc614f07@oracle.com> <64444271-d2e7-7dea-2d11-b635af662112@oracle.com> <96e0bb87-eda9-93c9-6c13-e51c08edefd0@oracle.com> <68e02999-be33-5ca9-2e9d-d1feb6c9446a@oracle.com> <6b192c97-37bf-9df0-16be-178e0d445417@oracle.com> Message-ID: On 17/10/2017 09:42, Alexey Ivanov wrote: >> This is my understanding, before those fix the maximum size was 32x32. > > It is my understanding too. Thus limiting the size of icon to 128 pixels > seemed reasonable. > > At this moment the buffer for icon pixels is allocated on the stack, > therefore the size cannot be dynamic. If memory for icon pixels is > allocated dynamically, the limitation can be removed. > > It makes sense to address this limitation under a separate issue, do you > agree? I agree that this can be moved to a separate bug. But my complaints were not related to it. - The new flags are not strictly specified. It is unclear what are small and large icons. For example the old "getSystemIcon" specified that it returns "an icon as it would be displayed by a native file chooser". How the new flags are related to this? I see that the SMALL flag is the same as the old method, and the large cion is just a HiDPI version of default icon. - SMALL/LARGE flags depends from the native main screen scale, probably it is possible to remove this dependency? Otherwise in the two screen configuration it will produce different images depending from the main screen. - In case of multi-monitor config in the discussion above there was a suggestion that the user can create MRI on top of the new API. I am not sure how it will work because we already return MRI for most of the files. I am still thinking that we should investigate the possibility to return MRI directly w/o ImageIcon/Icon wrappers. This MRI could load data lazily depends from the destination scale. The user ill able to get any resolution variants via getResolutionVariant(double,double) and also can get the list of the icons attached to some file via getResolutionVariants(); > > > Regards, > Alexey > >>>>> But these constants are related to the predefined system icon sizes >>>>> while the Extract() may scale icon to any size. >>>> >>>> Does it really scale for any size? >>>> For example if I request the icon for some pdf,java,txt files of >>>> size 100 then: >>>> ? - On HiDPI screen I get the native icon of size 64. >>>> ? - On LowDPI screen I get the native icon of size 32. >>>> In both cases the user will get MRI, which will scale the native icon. >>>> http://mail.openjdk.java.net/pipermail/awt-dev/2017-October/013179.html >>> Why returning MRI is wrong? >> >> >> The MRI is good, if this is what the user is expected. My point was >> that the native system is not scale the icon and the user gets MRI >> which content is unrelated to the passed "size". >> >>> Which calls are you talking about DPI-aware or DPI-unaware? >> >> This is jdk10client + the current patch. >> >> > -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Tue Oct 24 05:19:27 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 24 Oct 2017 10:49:27 +0530 Subject: [10] RFR JDK-8178025:HiDPI with non-integer scale factor - SPANs in HTML are rendered overlapping each other In-Reply-To: <2A27CA08-6BEB-4326-A4E0-078A6BE26509@cbfiddle.com> References: <4121aef8-bbae-c5ef-dfe2-d3b8efda318c@oracle.com> <540b95d9-3b3e-2c1d-37cf-a60c8a831cff@oracle.com> <97834ff5-4d40-e267-ff73-8ac3727e7f95@oracle.com> <5993e71c-2605-a81e-b6fc-faa90b7fcaf5@oracle.com> <0f39426f-e681-cb50-6db6-dce5824734d6@oracle.com> <49bcfe1b-2818-ba85-c479-a9b8e85b33e4@oracle.com> <2A27CA08-6BEB-4326-A4E0-078A6BE26509@cbfiddle.com> Message-ID: <6a7f06bb-7710-4b25-e713-c0e1ac75e86a@oracle.com> I would guess so as "ancestor" listener is to support notification when changes occur to a JComponent or one of its ancestors. Regards Prasanta On 10/23/2017 7:45 PM, Alan Snyder wrote: > Does it handle the case where the graphics configuration is later changed? > > ? Alan > > >> On Oct 22, 2017, at 11:23 PM, Prasanta Sadhukhan >> > > wrote: >> >> >> >> On 10/19/2017 3:42 PM, Prasanta Sadhukhan wrote: >>> >>> >>> On 10/19/2017 3:49 AM, Sergey Bylokhov wrote: >>>> On 17/10/2017 03:48, Prasanta Sadhukhan wrote: >>>>> It seems for JLabel, Component.updateGraphicsData() with proper >>>>> GraphicsConfiguraiton is never called which it does for >>>>> JTextComponent or JDialog. Do you know why? Because of this, >>>>> correct FRC is not created. >>>>> I am not sure what else I can do to create correct FRC. >>>> >>>> But at some point we will get a correct GraphicsConfiguraiton for a >>>> component, right? It should be called for the window and child when >>>> we show the window on the screen, when we move the window to >>>> another screen, etc. >>>> >>>> >>> Yes, it seems to be called when JLabel is added to JFrame but not >>> before. >>> Span is calculated in GlyphPainter1.getSpan() which is called when >>> JLabel is created and >>> as it seems, not when JLabel is added to JFrame (which is when we >>> get the correct graphics configuration and therefore correct transform). >>> >>> So, we need to make sure spans are recalculated when the JLabel is >>> added to frame, which is what modified webrev does by calling >>> JLabel.updateUI() >>> http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.01/ >>> >>> >> Modified webrev to only update html renderer when JLabel is added to >> frame by listening to property "ancestor" which implies component is >> added/made visible, at which point correct graphics configuration is set. >> http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.02/ >> >> >> Regards >> Prasanta >>> Regards >>> Prasana > -------------- next part -------------- An HTML attachment was scrubbed... URL: From javalists at cbfiddle.com Tue Oct 24 05:43:38 2017 From: javalists at cbfiddle.com (Alan Snyder) Date: Mon, 23 Oct 2017 22:43:38 -0700 Subject: [10] RFR JDK-8178025:HiDPI with non-integer scale factor - SPANs in HTML are rendered overlapping each other In-Reply-To: <6a7f06bb-7710-4b25-e713-c0e1ac75e86a@oracle.com> References: <4121aef8-bbae-c5ef-dfe2-d3b8efda318c@oracle.com> <540b95d9-3b3e-2c1d-37cf-a60c8a831cff@oracle.com> <97834ff5-4d40-e267-ff73-8ac3727e7f95@oracle.com> <5993e71c-2605-a81e-b6fc-faa90b7fcaf5@oracle.com> <0f39426f-e681-cb50-6db6-dce5824734d6@oracle.com> <49bcfe1b-2818-ba85-c479-a9b8e85b33e4@oracle.com> <2A27CA08-6BEB-4326-A4E0-078A6BE26509@cbfiddle.com> <6a7f06bb-7710-4b25-e713-c0e1ac75e86a@oracle.com> Message-ID: <25C95568-7F09-4E11-BBAA-15ED9A8C439F@cbfiddle.com> You?re guessing? Really? > On Oct 23, 2017, at 10:19 PM, Prasanta Sadhukhan wrote: > > I would guess so as "ancestor" listener is to support notification when changes occur to a JComponent or one of its ancestors. > > Regards > Prasanta > On 10/23/2017 7:45 PM, Alan Snyder wrote: >> Does it handle the case where the graphics configuration is later changed? >> >> Alan >> >> >>> On Oct 22, 2017, at 11:23 PM, Prasanta Sadhukhan > wrote: >>> >>> >>> >>> On 10/19/2017 3:42 PM, Prasanta Sadhukhan wrote: >>>> >>>> >>>> On 10/19/2017 3:49 AM, Sergey Bylokhov wrote: >>>>> On 17/10/2017 03:48, Prasanta Sadhukhan wrote: >>>>>> It seems for JLabel, Component.updateGraphicsData() with proper GraphicsConfiguraiton is never called which it does for JTextComponent or JDialog. Do you know why? Because of this, correct FRC is not created. >>>>>> I am not sure what else I can do to create correct FRC. >>>>> >>>>> But at some point we will get a correct GraphicsConfiguraiton for a component, right? It should be called for the window and child when we show the window on the screen, when we move the window to another screen, etc. >>>>> >>>>> >>>> Yes, it seems to be called when JLabel is added to JFrame but not before. >>>> Span is calculated in GlyphPainter1.getSpan() which is called when JLabel is created and >>>> as it seems, not when JLabel is added to JFrame (which is when we get the correct graphics configuration and therefore correct transform). >>>> >>>> So, we need to make sure spans are recalculated when the JLabel is added to frame, which is what modified webrev does by calling JLabel.updateUI() >>>> http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.01/ >>>> >>> Modified webrev to only update html renderer when JLabel is added to frame by listening to property "ancestor" which implies component is added/made visible, at which point correct graphics configuration is set. >>> http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.02/ >>> >>> Regards >>> Prasanta >>>> Regards >>>> Prasana >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Tue Oct 24 06:06:46 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 24 Oct 2017 11:36:46 +0530 Subject: [10] RFR JDK-8178025:HiDPI with non-integer scale factor - SPANs in HTML are rendered overlapping each other In-Reply-To: <25C95568-7F09-4E11-BBAA-15ED9A8C439F@cbfiddle.com> References: <4121aef8-bbae-c5ef-dfe2-d3b8efda318c@oracle.com> <540b95d9-3b3e-2c1d-37cf-a60c8a831cff@oracle.com> <97834ff5-4d40-e267-ff73-8ac3727e7f95@oracle.com> <5993e71c-2605-a81e-b6fc-faa90b7fcaf5@oracle.com> <0f39426f-e681-cb50-6db6-dce5824734d6@oracle.com> <49bcfe1b-2818-ba85-c479-a9b8e85b33e4@oracle.com> <2A27CA08-6BEB-4326-A4E0-078A6BE26509@cbfiddle.com> <6a7f06bb-7710-4b25-e713-c0e1ac75e86a@oracle.com> <25C95568-7F09-4E11-BBAA-15ED9A8C439F@cbfiddle.com> Message-ID: <57163fb8-98f8-0d90-edf7-c7149444def2@oracle.com> Whatever testing I have done, propertyChange gets called during. If you have any test/steps which changes GC at "later" stage, please provide and I will see if it does not call propertyChange. On 10/24/2017 11:13 AM, Alan Snyder wrote: > You?re guessing? Really? > >> On Oct 23, 2017, at 10:19 PM, Prasanta Sadhukhan >> > > wrote: >> >> I would guess so as "ancestor" listener is to support notification >> when changes occur to a JComponent or one of its ancestors. >> >> Regards >> Prasanta >> On 10/23/2017 7:45 PM, Alan Snyder wrote: >>> Does it handle the case where the graphics configuration is later >>> changed? >>> >>> ? Alan >>> >>> >>>> On Oct 22, 2017, at 11:23 PM, Prasanta Sadhukhan >>>> >>> > wrote: >>>> >>>> >>>> >>>> On 10/19/2017 3:42 PM, Prasanta Sadhukhan wrote: >>>>> >>>>> >>>>> On 10/19/2017 3:49 AM, Sergey Bylokhov wrote: >>>>>> On 17/10/2017 03:48, Prasanta Sadhukhan wrote: >>>>>>> It seems for JLabel, Component.updateGraphicsData() with proper >>>>>>> GraphicsConfiguraiton is never called which it does for >>>>>>> JTextComponent or JDialog. Do you know why? Because of this, >>>>>>> correct FRC is not created. >>>>>>> I am not sure what else I can do to create correct FRC. >>>>>> >>>>>> But at some point we will get a correct GraphicsConfiguraiton for >>>>>> a component, right? It should be called for the window and child >>>>>> when we show the window on the screen, when we move the window to >>>>>> another screen, etc. >>>>>> >>>>>> >>>>> Yes, it seems to be called when JLabel is added to JFrame but not >>>>> before. >>>>> Span is calculated in GlyphPainter1.getSpan() which is called when >>>>> JLabel is created and >>>>> as it seems, not when JLabel is added to JFrame (which is when we >>>>> get the correct graphics configuration and therefore correct >>>>> transform). >>>>> >>>>> So, we need to make sure spans are recalculated when the JLabel is >>>>> added to frame, which is what modified webrev does by calling >>>>> JLabel.updateUI() >>>>> http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.01/ >>>>> >>>>> >>>> Modified webrev to only update html renderer when JLabel is added >>>> to frame by listening to property "ancestor" which implies >>>> component is added/made visible, at which point correct graphics >>>> configuration is set. >>>> http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.02/ >>>> >>>> >>>> Regards >>>> Prasanta >>>>> Regards >>>>> Prasana >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From javalists at cbfiddle.com Tue Oct 24 13:07:04 2017 From: javalists at cbfiddle.com (Alan Snyder) Date: Tue, 24 Oct 2017 06:07:04 -0700 Subject: [10] RFR JDK-8178025:HiDPI with non-integer scale factor - SPANs in HTML are rendered overlapping each other In-Reply-To: <57163fb8-98f8-0d90-edf7-c7149444def2@oracle.com> References: <4121aef8-bbae-c5ef-dfe2-d3b8efda318c@oracle.com> <540b95d9-3b3e-2c1d-37cf-a60c8a831cff@oracle.com> <97834ff5-4d40-e267-ff73-8ac3727e7f95@oracle.com> <5993e71c-2605-a81e-b6fc-faa90b7fcaf5@oracle.com> <0f39426f-e681-cb50-6db6-dce5824734d6@oracle.com> <49bcfe1b-2818-ba85-c479-a9b8e85b33e4@oracle.com> <2A27CA08-6BEB-4326-A4E0-078A6BE26509@cbfiddle.com> <6a7f06bb-7710-4b25-e713-c0e1ac75e86a@oracle.com> <25C95568-7F09-4E11-BBAA-15ED9A8C439F@cbfiddle.com> <57163fb8-98f8-0d90-edf7-c7149444def2@oracle.com> Message-ID: <8FA69D74-45B1-49AF-B10E-055CF5CACA07@cbfiddle.com> I cannot see any code that replaces the graphics configuration based on the screen where the window is displayed, so maybe this is a feature not currently supported. Perhaps GraphicsDevice.setFullScreenWindow() can do this. Looking at the code, I see that setting the graphics configuration calls addNotify() which changes the ?ancestor? property. I assume that is what you are referring to. Alan > On Oct 23, 2017, at 11:06 PM, Prasanta Sadhukhan wrote: > > Whatever testing I have done, propertyChange gets called during. If you have any test/steps which changes GC at "later" stage, please provide and I will see if it does not call propertyChange. > > On 10/24/2017 11:13 AM, Alan Snyder wrote: >> You?re guessing? Really? >> >>> On Oct 23, 2017, at 10:19 PM, Prasanta Sadhukhan > wrote: >>> >>> I would guess so as "ancestor" listener is to support notification when changes occur to a JComponent or one of its ancestors. >>> >>> Regards >>> Prasanta >>> On 10/23/2017 7:45 PM, Alan Snyder wrote: >>>> Does it handle the case where the graphics configuration is later changed? >>>> >>>> Alan >>>> >>>> >>>>> On Oct 22, 2017, at 11:23 PM, Prasanta Sadhukhan > wrote: >>>>> >>>>> >>>>> >>>>> On 10/19/2017 3:42 PM, Prasanta Sadhukhan wrote: >>>>>> >>>>>> >>>>>> On 10/19/2017 3:49 AM, Sergey Bylokhov wrote: >>>>>>> On 17/10/2017 03:48, Prasanta Sadhukhan wrote: >>>>>>>> It seems for JLabel, Component.updateGraphicsData() with proper GraphicsConfiguraiton is never called which it does for JTextComponent or JDialog. Do you know why? Because of this, correct FRC is not created. >>>>>>>> I am not sure what else I can do to create correct FRC. >>>>>>> >>>>>>> But at some point we will get a correct GraphicsConfiguraiton for a component, right? It should be called for the window and child when we show the window on the screen, when we move the window to another screen, etc. >>>>>>> >>>>>>> >>>>>> Yes, it seems to be called when JLabel is added to JFrame but not before. >>>>>> Span is calculated in GlyphPainter1.getSpan() which is called when JLabel is created and >>>>>> as it seems, not when JLabel is added to JFrame (which is when we get the correct graphics configuration and therefore correct transform). >>>>>> >>>>>> So, we need to make sure spans are recalculated when the JLabel is added to frame, which is what modified webrev does by calling JLabel.updateUI() >>>>>> http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.01/ >>>>>> >>>>> Modified webrev to only update html renderer when JLabel is added to frame by listening to property "ancestor" which implies component is added/made visible, at which point correct graphics configuration is set. >>>>> http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.02/ >>>>> >>>>> Regards >>>>> Prasanta >>>>>> Regards >>>>>> Prasana >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ivanov at oracle.com Tue Oct 24 16:10:54 2017 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Tue, 24 Oct 2017 17:10:54 +0100 Subject: [10] Review request for 8182043: Access to Windows Large Icons In-Reply-To: References: <0537d0cd-26eb-a82b-7843-3c34d192aa33@oracle.com> <534e09a7-ad62-e189-d977-40c9d07dc623@oracle.com> <6a3f2f22-02d8-8138-186e-5faa438c51f6@oracle.com> <421fc67b-c809-4bb7-378f-11ccf940f0da@oracle.com> <34cc2024-8571-da9e-46f6-28ed8747caae@oracle.com> <2ef8eb3e-a1e1-5d86-a5a2-7cc9cc614f07@oracle.com> <64444271-d2e7-7dea-2d11-b635af662112@oracle.com> <96e0bb87-eda9-93c9-6c13-e51c08edefd0@oracle.com> <68e02999-be33-5ca9-2e9d-d1feb6c9446a@oracle.com> <6b192c97-37bf-9df0-16be-178e0d445417@oracle.com> Message-ID: <34bfc925-e6a1-f22f-6b80-177c018d941e@oracle.com> Hi Sergey, On 24/10/2017 00:22, Sergey Bylokhov wrote: > On 17/10/2017 09:42, Alexey Ivanov wrote: >>> This is my understanding, before those fix the maximum size was 32x32. >> >> It is my understanding too. Thus limiting the size of icon to 128 >> pixels seemed reasonable. >> >> At this moment the buffer for icon pixels is allocated on the stack, >> therefore the size cannot be dynamic. If memory for icon pixels is >> allocated dynamically, the limitation can be removed. >> >> It makes sense to address this limitation under a separate issue, do >> you agree? > > I agree that this can be moved to a separate bug. But my complaints > were not related to it. > ?- The new flags are not strictly specified. It is unclear what are > small and large icons. For example the old "getSystemIcon" specified > that it returns "an icon as it would be displayed by a native file > chooser". How the new flags are related to this? I see that the SMALL > flag is the same as the old method, and the large cion is just a HiDPI > version of default icon. > ?- SMALL/LARGE flags depends from the native main screen scale, > probably it is possible to remove this dependency? Otherwise in the > two screen configuration it will produce different images depending > from the main screen. Per my understanding, SMALL and LARGE flags correspond to the previous private API behaviour where you could get two icon sizes: 16?16 and 32?32. These flags will return the same logical-sized icons, subject to HiDPI scaling performed by native system. So these constants provide backward compatibility to sun.awt.shell.ShellFolder.getShellFolder(file).getIcon(getLargeIcon): either SMALL or LARGE. > ?- In case of multi-monitor config in the discussion above there was a > suggestion that the user can create MRI on top of the new API. I am > not sure how it will work because we already return MRI for most of > the files. > > I am still thinking that we should investigate the possibility to > return MRI directly w/o ImageIcon/Icon wrappers. This MRI could load > data lazily depends from the destination scale. The user ill able to > get any resolution variants via getResolutionVariant(double,double) > and also can get the list of the icons attached to some file via > getResolutionVariants(); My suggestion was to create MRI internally inside the new API. [1] This seems like the best option. On the other hand, we need to overcome native system scaling, otherwise the rendering could be broken. Testing performed by you [2] and me [3] shows that native system scales the returned hIcon, and, if there are several displays in the system with different scaling factors, the underlying icon size could be wrong. It seems there's no easy-to-use API for icons, Microsoft admits [4] working with icons is one of the areas where Win32 API does not provide a DPI context. It is still possible to use low-level resource APIs to enumerate all the provided sizes in RT_GROUP_ICON resource. Regards, Alexey [1] http://mail.openjdk.java.net/pipermail/awt-dev/2017-September/013147.html [2] http://mail.openjdk.java.net/pipermail/awt-dev/2017-October/013179.html [3] http://mail.openjdk.java.net/pipermail/awt-dev/2017-October/013181.html [4] https://msdn.microsoft.com/library/windows/desktop/mt843498(v=vs.85).aspx#Common_Pitfalls__Win32__ From Arshan.Arshi at us.abb.com Tue Oct 24 22:31:01 2017 From: Arshan.Arshi at us.abb.com (Arshan Arshi) Date: Tue, 24 Oct 2017 22:31:01 +0000 Subject: Experienced Swing Consultant (UI performance improvements) Message-ID: We are looking for an experienced Swing Consultant for Applet based UI performance improvements. We are located in San Jose CA. If you are interested, please respond to this email. Thanks, Arshan -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.zvegintsev at oracle.com Wed Oct 25 04:22:50 2017 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 25 Oct 2017 09:52:50 +0530 Subject: [10] Review request for 8182041: File Chooser Shortcut Panel folders under on JDK 9 In-Reply-To: References: Message-ID: <8ec1366f-c6bc-08bb-7552-63b8ee7e1455@oracle.com> Hi Semyon, the fix looks good to me, but I found a minor typo in the test: testShortcatPanelFiles -> testShortcutPanelFiles no need for a new webrev Thanks, Alexander. On 04/10/2017 00:41, Semyon Sadetsky wrote: > Hello, > > Please review fix for JDK10 (the changes involve AWT and Swing): > > bug: https://bugs.openjdk.java.net/browse/JDK-8182041 > > webrev: http://cr.openjdk.java.net/~ssadetsky/8182041/webrev.00/ > > New API method was added letting to query shortcut panel entries for > JFileChooser. > > --Semyon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Wed Oct 25 09:02:59 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 25 Oct 2017 14:32:59 +0530 Subject: [10] RFR JDK-8178025:HiDPI with non-integer scale factor - SPANs in HTML are rendered overlapping each other In-Reply-To: <8FA69D74-45B1-49AF-B10E-055CF5CACA07@cbfiddle.com> References: <4121aef8-bbae-c5ef-dfe2-d3b8efda318c@oracle.com> <540b95d9-3b3e-2c1d-37cf-a60c8a831cff@oracle.com> <97834ff5-4d40-e267-ff73-8ac3727e7f95@oracle.com> <5993e71c-2605-a81e-b6fc-faa90b7fcaf5@oracle.com> <0f39426f-e681-cb50-6db6-dce5824734d6@oracle.com> <49bcfe1b-2818-ba85-c479-a9b8e85b33e4@oracle.com> <2A27CA08-6BEB-4326-A4E0-078A6BE26509@cbfiddle.com> <6a7f06bb-7710-4b25-e713-c0e1ac75e86a@oracle.com> <25C95568-7F09-4E11-BBAA-15ED9A8C439F@cbfiddle.com> <57163fb8-98f8-0d90-edf7-c7149444def2@oracle.com> <8FA69D74-45B1-49AF-B10E-055CF5CACA07@cbfiddle.com> Message-ID: <6474b315-8786-4f42-7e52-82ccb3732811@oracle.com> On 10/24/2017 6:37 PM, Alan Snyder wrote: > Looking at the code, I see that setting the graphics configuration > calls addNotify() which changes the ?ancestor? property. I assume that > is what you are referring to. Yes From krishna.addepalli at oracle.com Thu Oct 26 08:43:27 2017 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Thu, 26 Oct 2017 01:43:27 -0700 (PDT) Subject: [10][JDK-8075084] JOptionPane.showMessageDialog causes JScrollBar to move In-Reply-To: References: <619c955e-ce29-440c-959c-2e84f350d6be@default> <8d29331d-477f-4a5a-a9c5-4c4c88ad0385@default>> <<5279e2de-5122-4a5d-805d-6d98a49eaacb@default> Message-ID: Hi Sergey, I have recreated the webrev for JDK-10 consolidated repo: http://cr.openjdk.java.net/~kaddepalli/8075084/webrev01/ Please review and let me know your comments. Thanks, Krishna -----Original Message----- From: Jason Mehrens [mailto:jason_mehrens at hotmail.com] Sent: Wednesday, August 30, 2017 7:54 PM To: Krishna Addepalli ; swing-dev at openjdk.java.net Subject: Re: [10][JDK-8075084] JOptionPane.showMessageDialog causes JScrollBar to move Related bug: http://mail.openjdk.java.net/pipermail/swing-dev/2014-April/003394.html ________________________________________ From: swing-dev on behalf of Krishna Addepalli Sent: Tuesday, August 29, 2017 3:17 AM To: swing-dev at openjdk.java.net Subject: Re: [10][JDK-8075084] JOptionPane.showMessageDialog causes JScrollBar to move Hi Sergey, Can we have the fix pushed in, as per our conversation? Thanks, Krishna From: Krishna Addepalli Sent: Wednesday, July 26, 2017 3:07 PM To: swing-dev at openjdk.java.net Cc: Prasanta Sadhukhan ; Sergey Bylokhov Subject: [10][JDK-8075084] JOptionPane.showMessageDialog causes JScrollBar to move Hi All, Please review the fix for bug: Bug: JDK- 8075084 https://bugs.openjdk.java.net/browse/JDK-8075084 JDK 10 Webrev : http://cr.openjdk.java.net/~psadhukhan/8075084/webrev00/ Summary: This is an interesting test case written by Drew Jetter (http://webbugs.us.oracle.com/IMWeb/incidentReportView.do?incidentID=2688093). The test shows a vertical scroll bar, and whenever the user clicks on the arrow buttons, it pops up a message dialog. The moment user clicks on "OK" button, the movement of the scrollbar doesnot stop, and it keeps showing up the dialog box again and again, while also moving the scroll bar till it reaches the end. This issue has already been root-caused here : http://mail.openjdk.java.net/pipermail/swing-dev/2016-November/006938.html , just reiterating here again: The problem is that once a Modal dialog is shown on top of the scrollbar, it loses focus, and hence doesnot get the mouse release event (which is swallowed by the DialogBox). For the mouse press event, the scrollbar would have started a timer, which keeps firing and generating the move events, which is why the slider moves repeatedly. Proposed fix is, once the scroll bar has moved by unit distance, check if it is still in focus, and only then start the timer. Otherwise *do not* start the timer, and also set the button press to false. PS: This could be a design decision as well, since the use case is not that common for scrollbar to lose focus on mouse press, so I decided to check out the behavior in Qt 5.9.1, and found that it too behaves the same way. Of course it's not binding that Java should behave the same way as Qt, but it was interesting to know that Qt also had similar behavior. Thanks, Krishna From Sergey.Bylokhov at oracle.com Thu Oct 26 23:18:22 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 26 Oct 2017 16:18:22 -0700 Subject: [10] Review Request: 5031664 Increase thread safety of EventListenerList Message-ID: <0594b421-e73c-447b-ccf3-be62cd6dfc70@oracle.com> Hello, Please review the fix for jdk10. The EventListenerList class was implemented to be thread safe. To achieve the correct state of the object: - two mutators(add/remove) were marked as synchronized. - the internal array is updated via copy-on-write, the internal array is never modified after it was set. It was assumed that the getXXX methods will get the value which was already set by the mutator or the previous value if mutator is in-progress but was not update the array. The problem is that the getXXX is not necessary read the value which was set, because of lack of happens-before between add/remove and getXXX. In the fix the array was marked as volatile to solve the problem. The CSR will be created after the technical review (the field is protected in public class) Bug: https://bugs.openjdk.java.net/browse/JDK-5031664 Webrev can be found at: http://cr.openjdk.java.net/~serb/5031664/webrev.00 -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Fri Oct 27 05:20:13 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 27 Oct 2017 10:50:13 +0530 Subject: [10] RFR JDK-8178025:HiDPI with non-integer scale factor - SPANs in HTML are rendered overlapping each other In-Reply-To: <49bcfe1b-2818-ba85-c479-a9b8e85b33e4@oracle.com> References: <4121aef8-bbae-c5ef-dfe2-d3b8efda318c@oracle.com> <540b95d9-3b3e-2c1d-37cf-a60c8a831cff@oracle.com> <97834ff5-4d40-e267-ff73-8ac3727e7f95@oracle.com> <5993e71c-2605-a81e-b6fc-faa90b7fcaf5@oracle.com> <0f39426f-e681-cb50-6db6-dce5824734d6@oracle.com> <49bcfe1b-2818-ba85-c479-a9b8e85b33e4@oracle.com> Message-ID: On 10/23/2017 11:53 AM, Prasanta Sadhukhan wrote: > > > On 10/19/2017 3:42 PM, Prasanta Sadhukhan wrote: >> >> >> On 10/19/2017 3:49 AM, Sergey Bylokhov wrote: >>> On 17/10/2017 03:48, Prasanta Sadhukhan wrote: >>>> It seems for JLabel, Component.updateGraphicsData() with proper >>>> GraphicsConfiguraiton is never called which it does for >>>> JTextComponent or JDialog. Do you know why? Because of this, >>>> correct FRC is not created. >>>> I am not sure what else I can do to create correct FRC. >>> >>> But at some point we will get a correct GraphicsConfiguraiton for a >>> component, right? It should be called for the window and child when >>> we show the window on the screen, when we move the window to another >>> screen, etc. >>> >>> >> Yes, it seems to be called when JLabel is added to JFrame but not >> before. >> Span is calculated in GlyphPainter1.getSpan() which is called when >> JLabel is created and >> as it seems, not when JLabel is added to JFrame (which is when we get >> the correct graphics configuration and therefore correct transform). >> >> So, we need to make sure spans are recalculated when the JLabel is >> added to frame, which is what modified webrev does by calling >> JLabel.updateUI() >> http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.01/ >> > Modified webrev to only update html renderer when JLabel is added to > frame by listening to property "ancestor" which implies component is > added/made visible, at which point correct graphics configuration is set. > http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.02/ > Any comments about this fix? Is it ok to commit? > Regards > Prasanta >> Regards >> Prasana >> > From Sergey.Bylokhov at oracle.com Fri Oct 27 06:27:55 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 26 Oct 2017 23:27:55 -0700 Subject: [10] RFR JDK-8178025:HiDPI with non-integer scale factor - SPANs in HTML are rendered overlapping each other In-Reply-To: <57163fb8-98f8-0d90-edf7-c7149444def2@oracle.com> References: <4121aef8-bbae-c5ef-dfe2-d3b8efda318c@oracle.com> <540b95d9-3b3e-2c1d-37cf-a60c8a831cff@oracle.com> <97834ff5-4d40-e267-ff73-8ac3727e7f95@oracle.com> <5993e71c-2605-a81e-b6fc-faa90b7fcaf5@oracle.com> <0f39426f-e681-cb50-6db6-dce5824734d6@oracle.com> <49bcfe1b-2818-ba85-c479-a9b8e85b33e4@oracle.com> <2A27CA08-6BEB-4326-A4E0-078A6BE26509@cbfiddle.com> <6a7f06bb-7710-4b25-e713-c0e1ac75e86a@oracle.com> <25C95568-7F09-4E11-BBAA-15ED9A8C439F@cbfiddle.com> <57163fb8-98f8-0d90-edf7-c7149444def2@oracle.com> Message-ID: I am not sure that it is called when the window is moved from one screen(HiDPI) to another screen(lowDpi). In this case the updateGraphicsData() will be called and we need to recalculate our data. On 23/10/2017 23:06, Prasanta Sadhukhan wrote: > Whatever testing I have done, propertyChange gets called during. If you > have any test/steps which changes GC at "later" stage, please provide > and I will see if it does not call propertyChange. > > > On 10/24/2017 11:13 AM, Alan Snyder wrote: >> You?re guessing? Really? >> >>> On Oct 23, 2017, at 10:19 PM, Prasanta Sadhukhan >>> >> > wrote: >>> >>> I would guess so as "ancestor" listener is to support notification >>> when changes occur to a JComponent or one of its ancestors. >>> >>> Regards >>> Prasanta >>> On 10/23/2017 7:45 PM, Alan Snyder wrote: >>>> Does it handle the case where the graphics configuration is later >>>> changed? >>>> >>>> ? Alan >>>> >>>> >>>>> On Oct 22, 2017, at 11:23 PM, Prasanta Sadhukhan >>>>> >>>> > wrote: >>>>> >>>>> >>>>> >>>>> On 10/19/2017 3:42 PM, Prasanta Sadhukhan wrote: >>>>>> >>>>>> >>>>>> On 10/19/2017 3:49 AM, Sergey Bylokhov wrote: >>>>>>> On 17/10/2017 03:48, Prasanta Sadhukhan wrote: >>>>>>>> It seems for JLabel, Component.updateGraphicsData() with proper >>>>>>>> GraphicsConfiguraiton is never called which it does for >>>>>>>> JTextComponent or JDialog. Do you know why? Because of this, >>>>>>>> correct FRC is not created. >>>>>>>> I am not sure what else I can do to create correct FRC. >>>>>>> >>>>>>> But at some point we will get a correct GraphicsConfiguraiton for >>>>>>> a component, right? It should be called for the window and child >>>>>>> when we show the window on the screen, when we move the window to >>>>>>> another screen, etc. >>>>>>> >>>>>>> >>>>>> Yes, it seems to be called when JLabel is added to JFrame but not >>>>>> before. >>>>>> Span is calculated in GlyphPainter1.getSpan() which is called when >>>>>> JLabel is created and >>>>>> as it seems, not when JLabel is added to JFrame (which is when we >>>>>> get the correct graphics configuration and therefore correct >>>>>> transform). >>>>>> >>>>>> So, we need to make sure spans are recalculated when the JLabel is >>>>>> added to frame, which is what modified webrev does by calling >>>>>> JLabel.updateUI() >>>>>> http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.01/ >>>>>> >>>>>> >>>>> Modified webrev to only update html renderer when JLabel is added >>>>> to frame by listening to property "ancestor" which implies >>>>> component is added/made visible, at which point correct graphics >>>>> configuration is set. >>>>> http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.02/ >>>>> >>>>> >>>>> Regards >>>>> Prasanta >>>>>> Regards >>>>>> Prasana >>>> >>> >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri Oct 27 06:38:59 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 26 Oct 2017 23:38:59 -0700 Subject: [10] RFR JDK-8178025:HiDPI with non-integer scale factor - SPANs in HTML are rendered overlapping each other In-Reply-To: References: <4121aef8-bbae-c5ef-dfe2-d3b8efda318c@oracle.com> Message-ID: <85d0d44f-8e59-d33b-91e8-0d7ae1aed598@oracle.com> The main/default graphicsconfiguration should be used when the component is created but still not added to the window and/or has null GConfig. When the GConfig is changed then the component hierarchy should be invalidated/validated somehow. We already update the size of the window based on the default transform/scale of the screen->this will revalidate the components. The problem is that in some cases the components or ui-delegates uses default(or incorrect) screen instead of the screen where the component is located. On 13/10/2017 18:31, Alan Snyder wrote: > Having run into similar problems, I believe this is an area where Swing has a serious design flaw. When a component is created, it has no idea which window it will be displayed in, and even when the window is known, the window could be moved to a different screen at any time. In addition, it seems the antialiasing and fractional metrics options are sometimes obtained from the Look and Feel, the rationale for which puzzles me. If these are not actual problems, please point me to appropriate documentation or supply an explanation. > > Alan > > > > > > >> On Oct 13, 2017, at 6:10 PM, Sergey Bylokhov wrote: >> >> Hi, Prasanta. >> >> On 11/10/2017 02:43, Prasanta Sadhukhan wrote: >>> Issue was, when a JLabel with an html text is created, the GlyphPainter1.getSpan() uses a FontrenderedContext with transform scale 1 >>> and also the obtained width is converted to int and not to float. >> >> Probably this is a root cause of the bug? FontrenderedContext is an abstraction which encapsulate information about text attributes for some specific surface such as screen, window, etc. If the label or any other components will use some FRC for rendering then the same FRC should be used for font size measurement. So why the scale is 1? >> >>> Proposed fix is to use correct transform while calculating the string width and also use floating point API to get floating point width. >> >> It will apply the screens scale to the FRC even if the component is located on some other screen. >> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. From krishna.addepalli at oracle.com Fri Oct 27 09:45:17 2017 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Fri, 27 Oct 2017 02:45:17 -0700 (PDT) Subject: [10][JDK-8178430] JMenu in GridBagLayout flickets when label text shows "..." and is updated Message-ID: Hi All, Please review the fix for bug: Bug: JDK-8178430: https://bugs.openjdk.java.net/browse/JDK-8178430 Webrev: http://cr.openjdk.java.net/~kaddepalli/8178430/webrev00/ Summary: The issue is when the label text width is more than the container(JPanel) width, the container tries to render with minimum width for all the components. In such case, the JMenuItem, which is added to the JMenuBar also returns its height dimension as 1 (the default minimum). The test case alternates between the short text and long text on the label, and it gives a flickering effect of the Menu. The fix is to return preferred size from JMenuItem, if its parent is a JMenuBar, since JMenuBar is added to the top level window. Thanks, Krishna -------------- next part -------------- An HTML attachment was scrubbed... URL: From krishna.addepalli at oracle.com Fri Oct 27 11:12:58 2017 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Fri, 27 Oct 2017 04:12:58 -0700 (PDT) Subject: [10][JDK-8187936] Automatically selecting a new JTree node in a model listener can cause unusual behavior. Message-ID: Hi All, Please review the help text that is updated for this bug: Bug: JDK-8187936: https://bugs.openjdk.java.net/browse/JDK-8187936 Webrev: http://cr.openjdk.java.net/~kaddepalli/8187936/webrev00/ Summary: As the bug title mentions, this is an unrecommended way of using the model listeners. The code posted in the bug tries to update the JTree path in the model listener callback, and since the JTree is yet to change itself to the underlying model, it results in weird UI behavior. Attached code in the bug is corrected and re-uploaded. This typically happens since listeners are called in a particular order (either last to first or first to last in the order of registration), and if the model listener tries to change the GUI before the GUI has had a chance to react itself to the changes in the underlying model. For example, highlighting a selection path for a node added in the JTree, in the TreeModelListener callback could lead to an extra node being added or existing nodes not being shown, since JTree would not have yet updated its state based on the model changes. In such cases it is recommended to wrap the callback function contents into a lambda, and invoke it through "SwingUtilities.invokeLater". This ensures that all the UI elements have had a chance to react to the model changes, and any UI actions will be guaranteed to operate on the updated widgets. Similar update has been done in package-info.java for Swing, so that it acts as a reference. Thanks, Krishna -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Mon Oct 30 19:42:31 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 30 Oct 2017 12:42:31 -0700 Subject: [10][JDK-8178430] JMenu in GridBagLayout flickets when label text shows "..." and is updated In-Reply-To: References: Message-ID: Hi, Krishna. Can you please clarify in what situation the test will stop working(it does not have any assertions)? On 27/10/2017 02:45, Krishna Addepalli wrote: > Hi All, > > Please review the fix for bug: > > > Bug: JDK-8178430: https://bugs.openjdk.java.net/browse/JDK-8178430 > > Webrev: http://cr.openjdk.java.net/~kaddepalli/8178430/webrev00/ > > Summary: > > The issue is when the label text width is more than the > container(JPanel) width, the container tries to render with minimum > width for all the components. In such case, the JMenuItem, which is > added to the JMenuBar also returns its height dimension as 1 (the > default minimum). The test case alternates between the short text and > long text on the label, and it gives a flickering effect of the Menu. > The fix is to return preferred size from JMenuItem, if its parent is a > JMenuBar, since JMenuBar is added to the top level window. > > Thanks, > > Krishna > -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Tue Oct 31 06:12:06 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 31 Oct 2017 11:42:06 +0530 Subject: [10] RFR JDK-8178025:HiDPI with non-integer scale factor - SPANs in HTML are rendered overlapping each other In-Reply-To: References: <4121aef8-bbae-c5ef-dfe2-d3b8efda318c@oracle.com> <540b95d9-3b3e-2c1d-37cf-a60c8a831cff@oracle.com> <97834ff5-4d40-e267-ff73-8ac3727e7f95@oracle.com> <5993e71c-2605-a81e-b6fc-faa90b7fcaf5@oracle.com> <0f39426f-e681-cb50-6db6-dce5824734d6@oracle.com> <49bcfe1b-2818-ba85-c479-a9b8e85b33e4@oracle.com> <2A27CA08-6BEB-4326-A4E0-078A6BE26509@cbfiddle.com> <6a7f06bb-7710-4b25-e713-c0e1ac75e86a@oracle.com> <25C95568-7F09-4E11-BBAA-15ED9A8C439F@cbfiddle.com> <57163fb8-98f8-0d90-edf7-c7149444def2@oracle.com> Message-ID: Ok. Modified webrev to make sure data is recalculated by listening to "graphicsConfig" change http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.03/ Regards Prasanta On 10/27/2017 11:57 AM, Sergey Bylokhov wrote: > I am not sure that it is called when the window is moved from one > screen(HiDPI) to another screen(lowDpi). In this case the > updateGraphicsData() will be called and we need to recalculate our data. > > On 23/10/2017 23:06, Prasanta Sadhukhan wrote: >> Whatever testing I have done, propertyChange gets called during. If >> you have any test/steps which changes GC at "later" stage, please >> provide and I will see if it does not call propertyChange. >> >> >> On 10/24/2017 11:13 AM, Alan Snyder wrote: >>> You?re guessing? Really? >>> >>>> On Oct 23, 2017, at 10:19 PM, Prasanta Sadhukhan >>>> >>> > wrote: >>>> >>>> I would guess so as "ancestor" listener is to support notification >>>> when changes occur to a JComponent or one of its ancestors. >>>> >>>> Regards >>>> Prasanta >>>> On 10/23/2017 7:45 PM, Alan Snyder wrote: >>>>> Does it handle the case where the graphics configuration is later >>>>> changed? >>>>> >>>>> ? Alan >>>>> >>>>> >>>>>> On Oct 22, 2017, at 11:23 PM, Prasanta Sadhukhan >>>>>> >>>>> > wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 10/19/2017 3:42 PM, Prasanta Sadhukhan wrote: >>>>>>> >>>>>>> >>>>>>> On 10/19/2017 3:49 AM, Sergey Bylokhov wrote: >>>>>>>> On 17/10/2017 03:48, Prasanta Sadhukhan wrote: >>>>>>>>> It seems for JLabel, Component.updateGraphicsData() with >>>>>>>>> proper GraphicsConfiguraiton is never called which it does for >>>>>>>>> JTextComponent or JDialog. Do you know why? Because of this, >>>>>>>>> correct FRC is not created. >>>>>>>>> I am not sure what else I can do to create correct FRC. >>>>>>>> >>>>>>>> But at some point we will get a correct GraphicsConfiguraiton >>>>>>>> for a component, right? It should be called for the window and >>>>>>>> child when we show the window on the screen, when we move the >>>>>>>> window to another screen, etc. >>>>>>>> >>>>>>>> >>>>>>> Yes, it seems to be called when JLabel is added to JFrame but >>>>>>> not before. >>>>>>> Span is calculated in GlyphPainter1.getSpan() which is called >>>>>>> when JLabel is created and >>>>>>> as it seems, not when JLabel is added to JFrame (which is when >>>>>>> we get the correct graphics configuration and therefore correct >>>>>>> transform). >>>>>>> >>>>>>> So, we need to make sure spans are recalculated when the JLabel >>>>>>> is added to frame, which is what modified webrev does by calling >>>>>>> JLabel.updateUI() >>>>>>> http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.01/ >>>>>>> >>>>>>> >>>>>> Modified webrev to only update html renderer when JLabel is added >>>>>> to frame by listening to property "ancestor" which implies >>>>>> component is added/made visible, at which point correct graphics >>>>>> configuration is set. >>>>>> http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.02/ >>>>>> >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>>> Regards >>>>>>> Prasana >>>>> >>>> >>> >> > > From pankaj.b.bansal at oracle.com Tue Oct 31 11:59:21 2017 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Tue, 31 Oct 2017 04:59:21 -0700 (PDT) Subject: [10] Review Request JDK - 8164811 : [hidpi]Tests fail with OpenGL Rendering Message-ID: <4d69560c-370c-471d-864f-c0a0ff59387d@default> Hi All, Please review the fix for JDK 10. Bug: https://bugs.openjdk.java.net/browse/JDK-8164811 Webrev: http://cr.openjdk.java.net/~pbansal/8164811/webrev.00/ Issue: The tests given in the bug were failing when run with OpenGL and GDI. This bug is related to https://bugs.openjdk.java.net/browse/JDK-8189257 which states that that HIDPI does not work with swing components when Translucent window is used. Because of which all the tests in the bug were failing. Fix: The TranslucentWindowPainter class was creating BufferedImage for OpenGL (when forceOpt is false) and GDI pipeline, but it is not considering the device HiDPI scale. There is no way to create a scaled BufferedImage because of which the scale value in BufImgSurfaceData is always 1. Made changes to store graphics config in Buffered image, so that the BufImgSurfaceManager can create BufImgSurfaceData with scale set properly. This fix also fixes https://bugs.openjdk.java.net/browse/JDK-8189257 Regards, Pankaj Bansal -------------- next part -------------- An HTML attachment was scrubbed... URL: From krishna.addepalli at oracle.com Tue Oct 31 12:00:34 2017 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Tue, 31 Oct 2017 05:00:34 -0700 (PDT) Subject: [10][JDK-8178430] JMenu in GridBagLayout flickets when label text shows "..." and is updated In-Reply-To: References: Message-ID: <09bba8a9-6ade-49e7-ac95-a47086d9edc3@default> Hi Sergey, Thanks for pointing that out. Fixed the test case and created a new webrev here: http://cr.openjdk.java.net/~kaddepalli/8178430/webrev01/ Now, the testcase throws an exception and also after a few trials, closes on its own. Thanks, Krishna -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, October 31, 2017 1:13 AM To: Krishna Addepalli ; swing-dev at openjdk.java.net Subject: Re: [10][JDK-8178430] JMenu in GridBagLayout flickets when label text shows "..." and is updated Hi, Krishna. Can you please clarify in what situation the test will stop working(it does not have any assertions)? On 27/10/2017 02:45, Krishna Addepalli wrote: > Hi All, > > Please review the fix for bug: > > > Bug: JDK-8178430: https://bugs.openjdk.java.net/browse/JDK-8178430 > > Webrev: http://cr.openjdk.java.net/~kaddepalli/8178430/webrev00/ > > Summary: > > The issue is when the label text width is more than the > container(JPanel) width, the container tries to render with minimum > width for all the components. In such case, the JMenuItem, which is > added to the JMenuBar also returns its height dimension as 1 (the > default minimum). The test case alternates between the short text and > long text on the label, and it gives a flickering effect of the Menu. > The fix is to return preferred size from JMenuItem, if its parent is a > JMenuBar, since JMenuBar is added to the top level window. > > Thanks, > > Krishna > -- Best regards, Sergey. From semyon.sadetsky at oracle.com Tue Oct 31 14:58:05 2017 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 31 Oct 2017 07:58:05 -0700 Subject: [10] RFR JDK-8178025:HiDPI with non-integer scale factor - SPANs in HTML are rendered overlapping each other In-Reply-To: References: <4121aef8-bbae-c5ef-dfe2-d3b8efda318c@oracle.com> <540b95d9-3b3e-2c1d-37cf-a60c8a831cff@oracle.com> <97834ff5-4d40-e267-ff73-8ac3727e7f95@oracle.com> <5993e71c-2605-a81e-b6fc-faa90b7fcaf5@oracle.com> <0f39426f-e681-cb50-6db6-dce5824734d6@oracle.com> <49bcfe1b-2818-ba85-c479-a9b8e85b33e4@oracle.com> <2A27CA08-6BEB-4326-A4E0-078A6BE26509@cbfiddle.com> <6a7f06bb-7710-4b25-e713-c0e1ac75e86a@oracle.com> <25C95568-7F09-4E11-BBAA-15ED9A8C439F@cbfiddle.com> <57163fb8-98f8-0d90-edf7-c7149444def2@oracle.com> Message-ID: <046bf5af-2e0b-d1a1-679b-61a23e080a68@oracle.com> Hi Prasanta, Can you also check at BasicMenuItemUI. It seems it may have the similar issue. --Semyon On 10/30/2017 11:12 PM, Prasanta Sadhukhan wrote: > Ok. Modified webrev to make sure data is recalculated by listening to > "graphicsConfig" change > > http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.03/ > > Regards > Prasanta > On 10/27/2017 11:57 AM, Sergey Bylokhov wrote: >> I am not sure that it is called when the window is moved from one >> screen(HiDPI) to another screen(lowDpi). In this case the >> updateGraphicsData() will be called and we need to recalculate our data. >> >> On 23/10/2017 23:06, Prasanta Sadhukhan wrote: >>> Whatever testing I have done, propertyChange gets called during. If >>> you have any test/steps which changes GC at "later" stage, please >>> provide and I will see if it does not call propertyChange. >>> >>> >>> On 10/24/2017 11:13 AM, Alan Snyder wrote: >>>> You?re guessing? Really? >>>> >>>>> On Oct 23, 2017, at 10:19 PM, Prasanta Sadhukhan >>>>> >>>> > wrote: >>>>> >>>>> I would guess so as "ancestor" listener is to support notification >>>>> when changes occur to a JComponent or one of its ancestors. >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 10/23/2017 7:45 PM, Alan Snyder wrote: >>>>>> Does it handle the case where the graphics configuration is later >>>>>> changed? >>>>>> >>>>>> ? Alan >>>>>> >>>>>> >>>>>>> On Oct 22, 2017, at 11:23 PM, Prasanta Sadhukhan >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 10/19/2017 3:42 PM, Prasanta Sadhukhan wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 10/19/2017 3:49 AM, Sergey Bylokhov wrote: >>>>>>>>> On 17/10/2017 03:48, Prasanta Sadhukhan wrote: >>>>>>>>>> It seems for JLabel, Component.updateGraphicsData() with >>>>>>>>>> proper GraphicsConfiguraiton is never called which it does >>>>>>>>>> for JTextComponent or JDialog. Do you know why? Because of >>>>>>>>>> this, correct FRC is not created. >>>>>>>>>> I am not sure what else I can do to create correct FRC. >>>>>>>>> >>>>>>>>> But at some point we will get a correct GraphicsConfiguraiton >>>>>>>>> for a component, right? It should be called for the window and >>>>>>>>> child when we show the window on the screen, when we move the >>>>>>>>> window to another screen, etc. >>>>>>>>> >>>>>>>>> >>>>>>>> Yes, it seems to be called when JLabel is added to JFrame but >>>>>>>> not before. >>>>>>>> Span is calculated in GlyphPainter1.getSpan() which is called >>>>>>>> when JLabel is created and >>>>>>>> as it seems, not when JLabel is added to JFrame (which is when >>>>>>>> we get the correct graphics configuration and therefore correct >>>>>>>> transform). >>>>>>>> >>>>>>>> So, we need to make sure spans are recalculated when the JLabel >>>>>>>> is added to frame, which is what modified webrev does by >>>>>>>> calling JLabel.updateUI() >>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.01/ >>>>>>>> >>>>>>>> >>>>>>> Modified webrev to only update html renderer when JLabel is >>>>>>> added to frame by listening to property "ancestor" which implies >>>>>>> component is added/made visible, at which point correct graphics >>>>>>> configuration is set. >>>>>>> http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.02/ >>>>>>> >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>>> Regards >>>>>>>> Prasana >>>>>> >>>>> >>>> >>> >> >> >