Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8261725

JOptionPane opened on scaled high DPI displays do not always layout correctly.

    XMLWordPrintable

    Details

    • Subcomponent:
    • Understanding:
      Fix Understood
    • CPU:
      x86_64
    • OS:
      windows_10

      Description

      ADDITIONAL SYSTEM INFORMATION :
      This problem occurs using JDK15 and JDK16rc but not on JDK14 or JDK11 (JDK 13 and 12 untested) , Windows 10 OS. (Bug tested against 1600x900 primary display, 3840x2160 secondary display with 150% display scaling).

      A DESCRIPTION OF THE PROBLEM :
      If a JOptionPane that is parented by a JFrame is made visible after the JFrame has been moved (e.g. user drag) from the frame's initial visible location on a non high DPI display to a location on an scaled high DPI display the JOptionPane size is not correct and as a consequence the option pane contents are cropped.

      REGRESSION : Last worked in version 14

      STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
      On a system with a non HDPI and HDPI display with 150% scaling (e.g notebook with attached HDPI monitor) set the primary monitor as the non HDPI display and run the test code below. After the JFrame appears on the primary monitor drag the JFrame to the the HDPI display and click the open button to display the JOptionPane.

      EXPECTED VERSUS ACTUAL BEHAVIOR :
      EXPECTED -
      Normal layout of the option pane with no clipping of the contents (as is the case in JDK14 and JDK 11 when these actions are performed)
      ACTUAL -
      Clipped contents in the open pane

      ---------- BEGIN SOURCE ----------
      public class Main extends JFrame {

          /**
           * @param args the command line arguments
           */
          public static void main(String[] args) {
              SwingUtilities.invokeLater(Main::createFrame);
          }
          
          public static void createFrame() {
              try {
                  JFrame frame = new JFrame();
                  frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
                  JButton open = new JButton("Open");
                  open.setPreferredSize(new Dimension(300,200));
                  open.addActionListener((ae)->Main.openMessage(frame));
                  frame.getContentPane().add(open);
                  frame.pack();
                  frame.setVisible(true);
              } catch (Exception ex) {
                  Logger.getLogger(Main.class.getName()).log(Level.SEVERE, null, ex);
              }
          }

          static public void openMessage(JFrame parent) {
              Box box = new Box(BoxLayout.PAGE_AXIS);
              box.add(new JLabel("This is line one"));
              box.add(new JLabel("This is line two"));
              box.add(new JLabel("This is line three"));
              JOptionPane.showConfirmDialog(parent, box, "Title", JOptionPane.OK_CANCEL_OPTION);
          }


      ---------- END SOURCE ----------

      CUSTOMER SUBMITTED WORKAROUND :
      Nothing reliable. JDialogs exhibit similar behavior. In the case of JDialog's attempting to change the GraphicsConfiguration to that of the parent frame (using the appropriate constructor) can lead to circumstances where layout is correct, but not in a way that seems predictable, and in any case that is not an option for JOptionPane based dialogs.

      FREQUENCY : always


        Attachments

        1. Actual_jdk_9-16-result.PNG
          Actual_jdk_9-16-result.PNG
          13 kB
        2. Expected.PNG
          Expected.PNG
          33 kB
        3. jdk16.bmp
          jdk16.bmp
          414 kB
        4. Main.java
          1 kB

          Activity

            People

            Assignee:
            serb Sergey Bylokhov
            Reporter:
            webbuggrp Webbug Group
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Dates

              Created:
              Updated: