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

JTable default rowHeight is not DPI scaled

    Details

      Description

      FULL PRODUCT VERSION :
      java version "1.7.0_45"
      Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
      Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)

      ADDITIONAL OS VERSION INFORMATION :
      Microsoft Windows [Version 6.1.7601]

      EXTRA RELEVANT SYSTEM CONFIGURATION :
      Retina display.
      (run on OS X 10.9 via Parallels 9)

      A DESCRIPTION OF THE PROBLEM :
      When using the Windows Look & Feel on a high DPI display, JLabel fonts and other widgets are scaled, so that they look good on the display.
      That's great.
      Unfortunately, it seems like the default JTable row height was forgotten. It is still set to 16 pixels, which is (a lot) too small and looks horrible.

       (btw, when using the standard L&F, no scaling occurs, opening up a great business opportunity for selling magnifying glasses).

      STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
      Run the following class on a machine with high DPI display, using DPI scaling.

      import javax.swing.*;
      import javax.swing.table.DefaultTableModel;
      import java.awt.*;

      /**
       * Demo table to demonstrate bad row height on HiDPI displays.
       */
      public class TableRowHeight {

          public static void main(String[] args) throws ClassNotFoundException, UnsupportedLookAndFeelException, InstantiationException, IllegalAccessException {
              UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
              final JFrame frame = new JFrame();
              frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
              final JTable table = new JTable();
              final DefaultTableModel dataModel = new DefaultTableModel(4, 1);
              dataModel.setValueAt("Some String", 0, 0);
              dataModel.setValueAt("Some String", 1, 0);
              dataModel.setValueAt("Some String", 2, 0);
              dataModel.setValueAt("Some String", 3, 0);
              table.setModel(dataModel);
              table.setAutoCreateColumnsFromModel(true);
              frame.getContentPane().setLayout(new BorderLayout());
              frame.getContentPane().add(table, BorderLayout.CENTER);
              frame.getContentPane().add(new JLabel("Label"), BorderLayout.NORTH);
              final JMenuBar menuBar = new JMenuBar();
              menuBar.add(new JMenu("Menu"));
              frame.setJMenuBar(menuBar);
              frame.setBounds(100, 100, 300, 300);
              SwingUtilities.invokeLater(new Runnable() {
                  @Override
                  public void run() {
                      frame.setVisible(true);
                  }
              });
          }

      }


      EXPECTED VERSUS ACTUAL BEHAVIOR :
      EXPECTED -
      Using this plain vanilla approach I would expect to see a table with appropriately sized rows.
      ACTUAL -
      The rows are not high enough. Standard table content appears clipped.

      REPRODUCIBILITY :
      This bug can be reproduced always.

      ---------- BEGIN SOURCE ----------
      import javax.swing.*;
      import javax.swing.table.DefaultTableModel;
      import java.awt.*;

      /**
       * Demo table to demonstrate bad row height on HiDPI displays.
       */
      public class TableRowHeight {

          public static void main(String[] args) throws ClassNotFoundException, UnsupportedLookAndFeelException, InstantiationException, IllegalAccessException {
              UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
              final JFrame frame = new JFrame();
              frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
              final JTable table = new JTable();
              final DefaultTableModel dataModel = new DefaultTableModel(4, 1);
              dataModel.setValueAt("Some String", 0, 0);
              dataModel.setValueAt("Some String", 1, 0);
              dataModel.setValueAt("Some String", 2, 0);
              dataModel.setValueAt("Some String", 3, 0);
              table.setModel(dataModel);
              table.setAutoCreateColumnsFromModel(true);
              frame.getContentPane().setLayout(new BorderLayout());
              frame.getContentPane().add(table, BorderLayout.CENTER);
              frame.getContentPane().add(new JLabel("Label"), BorderLayout.NORTH);
              final JMenuBar menuBar = new JMenuBar();
              menuBar.add(new JMenu("Menu"));
              frame.setJMenuBar(menuBar);
              frame.setBounds(100, 100, 300, 300);
              SwingUtilities.invokeLater(new Runnable() {
                  @Override
                  public void run() {
                      frame.setVisible(true);
                  }
              });
          }

      }

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

        Activity

        Hide
        serb Sergey Bylokhov added a comment -
        On second thought, perhaps the 16 pixels Table.rowHeight is the correct approach.
        And scaling up fonts to be a lot larger (as it happens in Win L&F) is what's wrong.

        Because it violates write once, run anywhere.

        On OS X you guys have been struggling to implement MultiResolutionImages and the like, so that if the physical display resolution is high, Java can automatically render a high resolution version of a given image. In the same spirit the L&F font sizes aren't suddenly changed, but instead they are rendered with greater detail. Because we use a virtual desktop resolution.

        Now, if on Windows with Windows L&F suddenly all fonts are a lot larger, but images are still the same size (status quo) and in relation to labels way too small, things look out of proportion, layouts are broken.

        The OS X solution allows for seamless migration, even if the programmer does not supply MultiResolutionImages. The current (1.7.0_45) Windows L&F does not allow this.

        And regardless which approach is better: Shouldn't both L&Fs use the same approach?!

        If you agree and have access to the Oracle bug database, please add this opinion as a comment (Oracle bug id 9008405). Or better—talk to the guys in charge of Windows L&F.

        Thanks,

        -hendrik
        Show
        serb Sergey Bylokhov added a comment - On second thought, perhaps the 16 pixels Table.rowHeight is the correct approach. And scaling up fonts to be a lot larger (as it happens in Win L&F) is what's wrong. Because it violates write once, run anywhere. On OS X you guys have been struggling to implement MultiResolutionImages and the like, so that if the physical display resolution is high, Java can automatically render a high resolution version of a given image. In the same spirit the L&F font sizes aren't suddenly changed, but instead they are rendered with greater detail. Because we use a virtual desktop resolution. Now, if on Windows with Windows L&F suddenly all fonts are a lot larger, but images are still the same size (status quo) and in relation to labels way too small, things look out of proportion, layouts are broken. The OS X solution allows for seamless migration, even if the programmer does not supply MultiResolutionImages. The current (1.7.0_45) Windows L&F does not allow this. And regardless which approach is better: Shouldn't both L&Fs use the same approach?! If you agree and have access to the Oracle bug database, please add this opinion as a comment (Oracle bug id 9008405). Or better—talk to the guys in charge of Windows L&F. Thanks, -hendrik
        Hide
        serb Sergey Bylokhov added a comment - - edited
        We need to decide how to process hidpi on windows in general. Like on osx or like native windows applications or somehow?
        Show
        serb Sergey Bylokhov added a comment - - edited We need to decide how to process hidpi on windows in general. Like on osx or like native windows applications or somehow?
        Hide
        serb Sergey Bylokhov added a comment -
        8-defer-request: This mode isn't completely supported now, not a regression.
        Show
        serb Sergey Bylokhov added a comment - 8-defer-request: This mode isn't completely supported now, not a regression.
        Hide
        yan Yuri Nesterenko (Inactive) added a comment -
        jdk8: SQE OK to defer
        Show
        yan Yuri Nesterenko (Inactive) added a comment - jdk8: SQE OK to defer
        Hide
        maxelsso Mathias Axelsson (Inactive) added a comment -
        Release team: Approved for deferral.
        Show
        maxelsso Mathias Axelsson (Inactive) added a comment - Release team: Approved for deferral.
        Hide
        hschreiber Hendrik Schreiber added a comment -
        > We need to decide how to process hidpi on windows in general. Like on osx or like native windows applications or somehow?

        I'm under the impression that that is all figured out by now and perhaps it is time to re-visit this bug again. More and more people running Windows are moving to HiDPI/4k displays and Swing apps don't look the best they can (last time I checked).
        Show
        hschreiber Hendrik Schreiber added a comment - > We need to decide how to process hidpi on windows in general. Like on osx or like native windows applications or somehow? I'm under the impression that that is all figured out by now and perhaps it is time to re-visit this bug again. More and more people running Windows are moving to HiDPI/4k displays and Swing apps don't look the best they can (last time I checked).

          People

          • Assignee:
            psadhukhan Prasanta Sadhukhan
            Reporter:
            serb Sergey Bylokhov
          • Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

            Dates

            • Created:
              Updated: