JDK-8149453 : [hidpi] JFileChooser does not scale properly on Windows with HiDPI display and Windows L&F
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 8u72,9
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_7,windows_8,windows_10
  • CPU: generic
  • Submitted: 2016-02-09
  • Updated: 2016-07-27
  • Resolved: 2016-04-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
8u102Fixed 9Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Under the Windows Look & Feel, most icons in the javax.swing.JFileChooser are not scaled properly. This applies both to the icons of shown files and icons shown as part of the UI (one-up, new folder, display mode).
Further, the panel on the left (Recent, Desktop, Documents, ...) is scaled in such a way that the labels aren't fully visible. See attached screenshots.

The problem occurs only with Windows Look & Feel, but with Windows 7, Windows 8.1, Windows 10 (those are the ones I tested).

Steps to reproduce: Run this code:
import javax.swing.*;
import java.awt.*;

public class JFileChooserTest {

    public static void main(String[] args) {
        try {
        } catch (Exception e) {

        SwingUtilities.invokeLater(() -> {
            final JFrame frame = new JFrame();
            frame.setLayout(new BorderLayout());
            final JButton open = new JButton("Open");
            open.addActionListener(l -> {
                final JFileChooser chooser = new JFileChooser();
            frame.setBounds(200, 200, 200, 200);
Yes, just create a new issue, target it to JDK 8 and link to the JDK-8157838

Regardless what happened to it: How do we proceed? Create a new bug with the same content?

The fix was integrated into JDK 8u102 b03. It is strange if it does not work there. After that it has been removed from the JDK 8u112 b01 because of the issue: JDK-8157838 Personalized Windows Font Size is not taken into account in Java8u102 See the discussion: http://mail.openjdk.java.net/pipermail/awt-dev/2016-May/011359.html

I've just tried using JFileChooser with Windows 7 and HiDPI on Java 8u102 (Windows L&F). It looks exactly like the screenshots in this bug report. So, should I simply create a new bug with the same content?

The new bug should be created instead if there are issues with JFileChooser on HiDPI display with Windows L&F.

JDK-8143064 refers to Checkmarks of JCheckBoxMenuItems (don't occur in JFileChooser). I had assumed that you only get to close an issue, once it is resolved. I.e. in this case, once the dialog is displayed properly all the way. If that means, some other bug has to be fixed first���great: Then it should be fixed first. Anyhow. Since I'm mostly a spectator on the sideline here, and you, Alexander, are doing the actual work, I don't really care too much about proper process. What I do care about is back ports to JDK8, so I can use the fruits of your labor as soon as possible!! :-) So please don't let me irritate you. You're work is much appreciated.

> The dialog is still broken. Some icons are coarse or seem to have the wrong sizes. See the jdk9 b114 screenshot in the attachments of this bug. There is a separate issue filled on it: JDK-8143064 Icons are not properly rendered with Windows L&F on HiDPI display

Thanks for the explanation. > Another question - do you have any behavior changes after 8149453 fix? Not quite sure what you mean with that question. The original fix was not a complete fix, IMHO. That's all there is to it as far as I can tell.

@ Alexander: please re-evaluate the FixFailed (FF) case @Hendrik : in case of re-fix activity we will need another bugID since another changeset (FF fix) can't be associated with original one anymore, this is why we are opening next ID. Another question - do you have any behavior changes after 8149453 fix? Alexander can do it.

Hey Victor, I don't quite understand the logic: The bug isn't fixed, that's why I re-opened it. That's the proper workflow, right? Why should we create a new bug then, just because there is already a changeset associated with it?

Hi Hendrik, could you please open separated new bug to track it? this bugID is associated with changeset: URL: http://hg.openjdk.java.net/jdk9/client/jdk/rev/4c4c633ca2c1

The dialog is still broken. Some icons are coarse or seem to have the wrong sizes. See the jdk9 b114 screenshot in the attachments of this bug.

I have just tried this using idk9 b114, which contains the fix. As you can see in the screenshot, it's still broken.

Regarding JDK-8151385, there is a bit of overlap, I guess, because Java_sun_awt_shell_Win32ShellFolder2_getIconBits(..) is called and that is modified by that JDK-8151385 patch I sent (not passing in the iconSize anymore, but rather detecting it).

Patch that introduces support for small/large ToolBar icons sourced from Windows OS. To be used in JFileChooser dialog. Completely untested. Didn't even try to compile.

JDK-8151385 won't fix this. To get upFolder etc. images right, you will have to modify jintArray JNICALL Java_sun_awt_shell_Win32ShellFolder2_getStandardViewButton0(...) in ShellFolder2.cpp. There we create a toolbar (not shown) and ask it for its icons. This is done via SendMessage(hWndToolbar, TB_LOADIMAGES, (WPARAM)IDB_VIEW_SMALL_COLOR, (LPARAM)HINST_COMMCTRL); By sending IDB_VIEW_LARGE_COLOR instead of IDB_VIEW_SMALL_COLOR we could get a hires/larger variant. This is defined in https://msdn.microsoft.com/en-us/library/windows/desktop/bb760433(v=vs.85).aspx Suggestion: Provide a way to load either the small or the large variant in the native code (e.g. with a parameter "boolean small"). Java_sun_awt_shell_Win32ShellFolder2_getStandardViewButton0(...) is called from Win32ShellFolderManager2.java, getStandardViewButton(..). There we could load both the large and the small image and use them to create a multi resolution image. Something like: private static Image getStandardViewButton(int iconIndex) { Image result = STANDARD_VIEW_BUTTONS[iconIndex]; if (result != null) { return result; } boolean small = true; BufferedImage imgSmall = new BufferedImage(16, 16, BufferedImage.TYPE_INT_ARGB); imgSmall.setRGB(0, 0, 16, 16, Win32ShellFolder2.getStandardViewButton0(iconIndex, small), 0, 16); small = false; BufferedImage imgLarge = new BufferedImage(32, 32, BufferedImage.TYPE_INT_ARGB); imgLarge.setRGB(0, 0, 32, 32, Win32ShellFolder2.getStandardViewButton0(iconIndex, small), 0, 32); Image img = new BaseMultiResolutionImage(imgSmall, imgLarge); STANDARD_VIEW_BUTTONS[iconIndex] = img; return img; } I will attach a (completely untested, not even compiled) patch that shows in detail what I'm suggesting.

I believe that these icons are correctly sized, but they have low-resolution. Does fix for the JDK-8151385 "[hidpi] JOptionPane-Icons only partially visible when using Windows 10 L&F" can resolve this? There is also known issue which can be related to this JDK-8143064 "Icons are not properly rendered with Windows L&F on HiDPI display"

Hey Alexander, Just glanced over you patch. With it applied, are the UpFolder, NewFolder and Details buttons (upper right corner) correctly sized under Windows 10 with HiDPI display and Windows Look&Feel? Do they also have the correct resolution?

Screenshot of the JFileChooser dialog on Windows 10 with a HiDPI display and Windows L&F. The used JDK is JDK 9 ea build 109: Z:\>java -version java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+109-2016-03-09-181019.javare.4620.nc) Java HotSpot(TM) 64-Bit Server VM (build 9-ea+109-2016-03-09-181019.javare.4620.nc, mixed mode) Fonts are too big, icons are truncated and low res.

Yes. It's broken in different ways. Screenshot attached.

does it affect 9?

Once JDK-8151385 is fixed, we have icons in the correct size. Then the hardcoded layout has to be adjusted. In particular the button sizes in sun.swing.WindowsPlacesBar (currently (83, 69), (83, 65) and (83, 54)). It would probably already make things a lot better, if there was a simple way to determine whether we are in HiDPI mode and then simply multiply those dimensions with 2 (assuming the classic Windows model of one virtual pixel == actual pixel). I doubt, that the upFolder, newFolder etc. icons on the right of the combobox are even available in a suitably sized hires version. But I may be wrong, it remains to be seen. I understand this is piecemeal, but it makes things *less* broken as opposed to *very* broken. The big solution would be a rewrite (see below). If we are actually going the OS X route with JDK8 (one virtual pixel is translated to one or more actual pixels, depending on the resolution mode), this needs other work, obviously. As for JDK9, it's time to rewrite the thing altogether to reflect modern Windows file dialogs (Common Item Dialog, https://msdn.microsoft.com/en-us/library/windows/desktop/bb776913(v=vs.85).aspx). If that's too hard for Swing (as it's basically deprecated by now), IMHO at least the AWT FileDialog should be rewritten to use Common Item Dialog.

BTW: The AWT-based file dialog does not look right in HiDPI mode on Windows, either.