8182043: Access to Windows Large Icons #2875

azuev-java · 2021-03-08T13:22:07Z

Fix updated after first round of review.

Progress

Change must not contain extraneous whitespace
Commit message must refer to an issue
Change must be properly reviewed

Issue

JDK-8182043: Access to Windows Large Icons

Reviewers

Alexey Ivanov (@aivanov-jdk - Reviewer) ⚠️ Review applies to 9e7bf90
Alexander Zvegintsev (@azvegint - Reviewer) ⚠️ Review applies to 911bc70
Phil Race (@prrace - Reviewer) ⚠️ Review applies to b3ca9da

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/2875/head:pull/2875
$ git checkout pull/2875

Update a local copy of the PR:
$ git checkout pull/2875
$ git pull https://git.openjdk.java.net/jdk pull/2875/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 2875

View PR using the GUI difftool:
$ git pr show -t 2875

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/2875.diff

Fix updated based on the previous review.

bridgekeeper · 2021-03-08T13:22:23Z

👋 Welcome back kizune! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

azuev-java · 2021-03-08T13:23:00Z

Continuation of review at #380

openjdk · 2021-03-08T13:23:40Z

@azuev-java The following labels will be automatically applied to this pull request:

2d
awt
swing

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

mlbridge · 2021-03-08T13:27:27Z

Webrevs

azuev-java · 2021-03-08T13:28:11Z

/csr needed

openjdk · 2021-03-08T13:28:45Z

@azuev-java this pull request will not be integrated until the CSR request JDK-8188238 for issue JDK-8182043 has been approved.

mrserb · 2021-03-10T00:55:00Z

Just to continue the thread from the old review, did you have a chance to look at the possibility of loading all existed icons embedded in the file? It was discussed here:
#380 (comment)

azuev-java · 2021-03-10T05:35:50Z

Just to continue the thread from the old review, did you have a chance to look at the possibility of loading all existed icons embedded in the file? It was discussed here:
#380 (comment)

Yes, i did. There were 3 shortcomings: 1. It works in about 10% of the cases in all other cases it reports only one icon available (32x32) even if there are other resolution icons. 2. It is quite slow, especially on network drives. 3. Does not work at all in files that are within AppData\Roaming folder - returning list is just empty.

aivanov-jdk · 2021-03-10T20:17:05Z

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java

-                return size == baseSize
-                        ? img
-                        : new MultiResolutionIconImage(baseSize, img);
+                        new BufferedImage(iconSize, iconSize, BufferedImage.TYPE_INT_ARGB);
+                img.setRGB(0, 0, iconSize, iconSize, iconBits, 0, iconSize);
+                return img;


There are cases where the size of the buffered image is different from the requested size. It could affect the layout because it breaks the assumption that the returned image has the requested size but it may be larger. (Or is it no longer possible?) I think it should be wrapped into MultiResolutionIconImage in this case.

Actually in makeImage we do not use requested size, we return the bits that system returns to us. How the generated image is treated depends on the implementation of the public methods - where it matters they are wrapped in the corresponding multi resolution images so it behaves correctly in UI.

Okay, if it always wrapped in a multi-resolution image where it matters.

aivanov-jdk · 2021-03-10T20:27:44Z

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java

+                                    newIcon2 = imageCache.get(Integer.valueOf(index));
+                                    if (newIcon2 == null) {
+                                        long hIcon = getIcon(getAbsolutePath(), !getLargeIcon);
+                                        newIcon2 = makeIcon(hIcon, getLargeIcon ? SMALL_ICON_SIZE
+                                                : LARGE_ICON_SIZE);
+                                        disposeIcon(hIcon);
+                                    }
+                                }
+
+                                if (newIcon2 != null) {
+                                    Map<Integer, Image> bothIcons = new HashMap<>(2);
+                                    bothIcons.put(getLargeIcon? LARGE_ICON_SIZE : SMALL_ICON_SIZE, newIcon);
+                                    bothIcons.put(getLargeIcon? SMALL_ICON_SIZE : LARGE_ICON_SIZE, newIcon2);
+                                    newIcon = new MultiResolutionIconImage(getLargeIcon ? LARGE_ICON_SIZE
+                                            : SMALL_ICON_SIZE, bothIcons);


I still propose to refactor this code to make it clearer. The code always returns two icons: small + large or large + small — combined in MultiResolutionIconImage.

You can get smallIcon and largeIcon and then wrap them into MultiResolutionIconImage in the correct order and store each icon in the cache.

My opinion hasn't changed here.

I still think there's not much value in getting smaller icon size in addition to larger one. Or does it provide an alternative image for the case where the system scaling is 200% and the window is moved to a monitor with scaling of 100%?

Getting smaller icon is relevant in the case of the scaling. I do not think refactoring image caches from icons to multiresolution images will make code much cleaner - at the end we will have to extract images from the multiresolution image to repack them into different multiresolution image because the base size of the image will not be the same and it does matter in how they will be scaled on the different screens. And we still need to extract both images because sometimes small resolution image looks not like the large resolution one and for a reason - so small resolution image is not blurred by the small detail on the large icon when scaling on the low resolution screen.

No, I can't see how it's relevant. If the scale factor is 100% and the requested icon size is 16, then 16×16 is used; if the window is moved to a monitor with scale factor 200%, then 32×32 icon is used for rendering which is already fetched and available in the multi-resolution image — perfect, there's the benefit.

But when is it possible that the scale factor is less than 100%?

If JFileChooser requests a large icon that is 32×32, then it will be used for rendering when the scale factor is 100%. When the scale factor is 200%, the icon of 64×64 is required but it's not available, instead there's 16×16 icon. For this icon to be used, the scale factor needs to be 50%.

Ok, changed so only the icons that are higher or same size as requested will be in the resulting set (unless size requested exceeds the maximum allowed quality, in this case only maximum quality variant will be provided).

aivanov-jdk · 2021-03-10T20:32:12Z

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java

     */
-    static Image getShell32Icon(int iconID, boolean getLargeIcon) {
+    static Image getShell32Icon(int iconID, int size) {
        boolean useVGAColors = true; // Will be ignored on XP and later


I cannot see where useVGAColors is used. Since the supported OS are later than XP, it can be removed, can't it?

I think so. Fixed.

src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp

aivanov-jdk · 2021-03-10T20:40:40Z

test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java

+                throw new RuntimeException("icon is null!!!");
+            }
+
+            if (icon.getIconWidth() != size) {


Does it make sense to check that the icon is a multi-resolution image with the expected sizes?
We know for sure explorer.exe contains the entire set of icons.

Since the test always expects a multi-resolution image, does it make sense to assert icon instanceof MultiResolutionImage at the very least?

Ok, added testing for multiresolution icon.

aivanov-jdk · 2021-03-10T20:44:19Z

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java

+    * a system file browser for the requested size.
+    * <p>
+    * The default implementation gets information from the
+    * <code>ShellFolder</code> class. Whenever possible, the icon


Do we continue using <code> elements? I thought that {@code} is the preferred way to markup class names.

aivanov-jdk · 2021-03-10T20:46:15Z

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java

+                                    bothIcons.put(getLargeIcon? LARGE_ICON_SIZE : SMALL_ICON_SIZE, newIcon);
+                                    bothIcons.put(getLargeIcon? SMALL_ICON_SIZE : LARGE_ICON_SIZE, newIcon2);


Suggested change

bothIcons.put(getLargeIcon? LARGE_ICON_SIZE : SMALL_ICON_SIZE, newIcon);

bothIcons.put(getLargeIcon? SMALL_ICON_SIZE : LARGE_ICON_SIZE, newIcon2);

bothIcons.put(getLargeIcon ? LARGE_ICON_SIZE : SMALL_ICON_SIZE, newIcon);

bothIcons.put(getLargeIcon ? SMALL_ICON_SIZE : LARGE_ICON_SIZE, newIcon2);

aivanov-jdk · 2021-03-10T20:53:43Z

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java

+                }
+            }
+            Map<Integer, Image> multiResolutionIcon = new HashMap<>();
+            int start = size > MAX_QUALITY_ICON ? ICON_RESOLUTIONS.length - 1 : 0;


Does it make sense to always start at zero?
The icons of smaller size will never be used, will they?
Thus it's safe to start at the index which corresponds to the requested size if size matches, or the index such as ICON_RESOLUTIONS[index] < size && ICON_RESOLUTIONS[index + 1] > size.

This comment is also about the case of not fetching icons of sizes smaller than requested size.

Sorry, missed that in my latest fix. Indeed there is no legitimate ways to set scaling factor to less than 100% on Windows so yes, omitting the icons that are less than expected size. As for starting the count from the correct index - to get the correct index we would have to traverse the array of possible resolutions anyways so there is no performance gain.

The MRI image takes care of graphics transformation which might be the same as a scale factor of the screen for the onscreen rendering, but in general, it might be set to any value by the application when rendered to the image.

aivanov-jdk · 2021-03-10T20:53:55Z

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java

+            int start = size > MAX_QUALITY_ICON ? ICON_RESOLUTIONS.length - 1 : 0;
+            int increment = size > MAX_QUALITY_ICON ? -1 : 1;
+            int end = size > MAX_QUALITY_ICON ? -1 : ICON_RESOLUTIONS.length;
+            for (int i = start; i != end; i+=increment) {


Suggested change

for (int i = start; i != end; i+=increment) {

for (int i = start; i != end; i += increment) {

aivanov-jdk · 2021-03-10T20:54:56Z

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java

+            // We only care about width since we don't support non-rectangular icons
+            int w = (int) width;
+            int retindex = 0;
+            for (Integer i: resolutionVariants.keySet()) {


Suggested change

for (Integer i: resolutionVariants.keySet()) {

for (Integer i : resolutionVariants.keySet()) {

aivanov-jdk · 2021-04-02T21:10:29Z

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java

    }

+   /**
+    * Icon for a file, directory, or folder as it would be displayed in


Returns an icon for a file…

aivanov-jdk · 2021-04-02T21:20:49Z

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java

+    * </pre>
+    *
+    * @param f a <code>File</code> object
+    * @param size width and height of the icon in pixels


Pixels could be ambiguous now. Usually, Swing deals with user's space. That is 16×16 icon should actually be 32×32 if the scale factor of the current display is 200%.

Yes, this issue is somewhat irrelevant because the method returns multi-resolution icon. However, the terminology used must be unambiguous and clear; for consistency with other Swing API, it should be in terms of user's space coordinates, virtual pixels.

Remived size parameter from makeIcon Removed useVGAColors usage as irrelevant since it is ignored on all supported platforms now

Select one icon at a time. Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk@users.noreply.github.com>

aivanov-jdk · 2021-04-30T20:15:25Z

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java

        Toolkit toolkit = Toolkit.getDefaultToolkit();
        String shellIconBPP = (String)toolkit.getDesktopProperty("win.icon.shellIconBPP");


Looks like these lines aren't used any more and should be removed too.

Yes. Fixed.

aivanov-jdk · 2021-04-30T20:19:04Z

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java

+    * JLabel label = new JLabel(icon);
+    * </pre>
+    *
+    * @param f a <code>File</code> object


Suggested change

* @param f a <code>File</code> object

* @param f a {@code File} object

aivanov-jdk · 2021-04-30T20:23:21Z

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java

+    * which will allow better scaling with different
+    * magnification factors.


I'm not sure what are the standard terms to refer to High DPI environments and the scale factors associated with High DPI.

In Windows environment it is scaling size or scaling factor. On Mac it is called scaled resolution. So i would say scaling factor is an appropriate term.

aivanov-jdk · 2021-04-30T20:28:51Z

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java

-                return size == baseSize
-                        ? img
-                        : new MultiResolutionIconImage(baseSize, img);
+                        new BufferedImage(iconSize, iconSize, BufferedImage.TYPE_INT_ARGB);
+                img.setRGB(0, 0, iconSize, iconSize, iconBits, 0, iconSize);
+                return img;


Okay, if it always wrapped in a multi-resolution image where it matters.

aivanov-jdk · 2021-04-30T20:34:01Z

src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java

+    /**
+     * Returns the icon of the specified size used to display this shell folder.
+     *
+     * @param size size of the icon > 0 (Valid range: 1 to 256)


I'm unsure the valid range of 1 to 256 makes sense provided the icon smaller than 16×16 is never returned (on Windows at least).

Well, user still can request 1x1 icon - we will return the multiresolution image with minimal (1x1) icon inside that will be scaled every time the actual painting occurs. The size will define the layout of the component with the icon and can be auto-generated from the user code so i do not see why we should limit the lowest requested size - especially in the shared instance that not only specific for Windows platform.

Even though 1×1 icon doesn't make much sense, you're right imposing a limitation is no good either.

Added testing for MultiResolutionImage

aivanov-jdk · 2021-05-11T10:07:30Z

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java

    * which will allow better scaling with different
-    * magnification factors.
+    * scaling factors.


“…which will allow better support for High DPI environments with different scaling factors.” — does it look better?
“scaling with … scaling factors” doesn't sound good to me.

Yes, much better. I updated the wording and once the PR is approved i will fix it in CSR too.

aivanov-jdk · 2021-05-11T10:26:29Z

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java

-                                        return getShell32Icon(1, getLargeIcon);
+                                        imageCache = getLargeIcon ? smallSystemImages : largeSystemImages;
+                                    }
+                                    newIcon2 = imageCache.get(Integer.valueOf(index));


Probably, explicit boxing is unnecessary.

aivanov-jdk · 2021-05-11T10:40:18Z

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java

        if (hIcon != 0) {
-            Image icon = makeIcon(hIcon, getLargeIcon);
+            Image icon = makeIcon(hIcon);
            disposeIcon(hIcon);
            return icon;


Shall it not be wrapped into multi-resolution image if the size is different from the actual size of the icon?
Previously, it was inside makeIcon.

Wherever it is necessary down the line we are wrapping the result in multi-resolution and if we wrap it here too we will have multi-resolution icon that contains multi-resolution images as a resolution variant. Unfortunately AWT can't handle painting of such abomination.

No, it isn't wrapped: if getShell32Icon is called in getIcon(final boolean getLargeIcon), the returned value is immediately returned to the caller, see lines 1157–1163 in the updated code:

if (hIcon <= 0) { if (isDirectory()) { return getShell32Icon(FOLDER_ICON_ID, size); } else { return getShell32Icon(FILE_ICON_ID, size); } }

It's not wrapped into multi-resolution icon when called from Win32ShellFolder2.get() for keys shell32Icon * and shell32LargeIcon * (lines 411/413–414).

Neither is the returned value of Win32ShellFolder2.getSystemIcon wrapped; it's also called from Win32ShellFolder2.get() when getting icons for optionPaneIcon * (lines 405/407). These icons are supposed to be large 32×32 icons, thus if the size of the icon in getSystemIcon(SystemIcon iconType) differs from 32, it should be wrapped. Otherwise, it could cause regression for JDK-8151385: [hidpi] JOptionPane-Icons only partially visible when using Windows 10 L&F.

I see - but still it has to be solved in the getShell32Icon method - which i'm going to do in a moment.

Win32ShellFolder2.getSystemIcon is still affected, the return value should be wrapped into MR-icon if its size is not equal to LARGE_ICON_SIZE.

static Image getSystemIcon(SystemIcon iconType) { long hIcon = getSystemIcon(iconType.getIconID()); Image icon = makeIcon(hIcon); if (LARGE_ICON_SIZE != icon.getWidth(null)) { icon = new MultiResolutionIconImage(size, icon); } disposeIcon(hIcon); return icon; }

aivanov-jdk · 2021-05-11T10:53:06Z

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java

-
-        long hIcon = getIconResource("shell32.dll", iconID, size, size, useVGAColors);
+    static Image getShell32Icon(int iconID, int size) {
+        long hIcon = getIconResource("shell32.dll", iconID, size, size);


It's outside the scope for this code review but still, should getIconResource free the loaded library? With each call, the library gets loaded but it's never freed and thus it's never unloaded even if it's not needed any more.

I will create a separate bug to track this - i do not know if library loading gets cached on some level and what impact on performance will we have if we release it every call. But i will check it out separately.

Sure! I just wanted to bring it up. I could've submitted the bug myself… yet I decided to ask at first.
As far as I can see JDK_LoadSystemLibrary has no caching, it just loads the library. If any icons are accessed shell32.dll will already be loaded. Probably, we never fully release it from COM. So in this case, loading and freeing will just increase and decrease the counters. Even if it's never really unloaded, we should release the resources that's not needed any more.

For documentation purposes, JDK-8266948: ShellFolder2::getIconResource does not release the library loaded.

aivanov-jdk · 2021-05-11T11:02:30Z

src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp

+        return FALSE;
+    }
+    HRESULT hres;
+    IExtractIconW* pIcon;


pIcon->Release() must be called before returning as done in extractIcon.

Removing unnecessary boxing of int Releasing the pIcon in native code properly

requested icon size and actual icon size mismatch.

aivanov-jdk · 2021-05-14T13:30:13Z

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java

    * returned will be a multi-resolution icon image,
-    * which will allow better scaling with different
-    * scaling factors.
+    * which will allow better support for High DPI environments


I'm not sure but probably “…which allows better…” is more grammatical, as well as in the line above: “the icon returned is a multi-resolution”.

Phil or Joe could correct this.

aivanov-jdk · 2021-05-14T13:32:59Z

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java

-
-        long hIcon = getIconResource("shell32.dll", iconID, size, size, useVGAColors);
+    static Image getShell32Icon(int iconID, int size) {
+        long hIcon = getIconResource("shell32.dll", iconID, size, size);


For documentation purposes, JDK-8266948: ShellFolder2::getIconResource does not release the library loaded.

Fixed Win32ShellFolder2.getSystemIcon scaling issue

azvegint · 2021-05-16T18:49:24Z

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java

+    * <p>
+    * Example: <pre>
+    * FileSystemView fsv = FileSystemView.getFileSystemView();
+    * Icon icon = fsv.getSystemIcon("application.exe", 64);


Shouldn't the first parameter be a File instance instead of String?
Icon icon = fsv.getSystemIcon(new File("application.exe"), 64);

Good catch! Yes, fixed both here and in CSR.

Are we sure that all possible paths can be pointed by the file object? Especially some "Windows Libraries" which are accessed by the shell folder?

Later we say that this method returns null for non-existed files. is it always correct? I am not sure that the file created for the library report true for the exists() method; DId we test this usecase?

We do not test for that in the regression test but i did tested it manually and we do return null for the non-existed files. I tested it on non-windows platform too. We still return null.

It is accessible from the "JFileChooser" drop-down menu. On my system, the Libraries at that drop down menu contain "GIT", "Documents", "Music". https://docs.microsoft.com/en-us/windows/client-management/windows-libraries

There are also "known folders" such as "Network" or "My computer" which do not have a real path but can be navigated in the JFileChooser and has an icon.

Ok, got it. Well, since they can be translated into the file system paths - even if these paths do not belong to physical filesystem - they are supported by the new API. Not for all of them i am able to receive the high resolution icons - like "Recent Items" for some reason only provides 32x32 and 16x16 no matter what size i am asking for. Others such as Documents, My Computer or 3D Objects do provide all resolutions available. For example here's the screenshot of all the available icons for 3D Objects

But how you got them via this method? I am not sure what parameters should be passed to it.

Didn't you answer your question already? If FileSystemView.getRoots() returns Desktop in Windows shell namespace. Otherwise, I don't know a way to get a reference to a virtual folder in Windows shell namespace which doesn't reference a file system object.

Alex's example uses "3D Objects" folder which is one of the known folders and has its own icon instead of the standard folder icon.

It's possible that I don't understand the question clearly.

Alex's fix affects WindowsPlacesBar on the left of JFileChooser in Windows LaF, the icons there look crispier in High DPI environment.

But how you got them via this method? I am not sure what parameters should be passed to it.
String userdir = System.getenv("userprofile"); Icon icon = FileSystemView.getFileSystemView().getSystemIcon(new File(userdir + "\\3D Objects"), 64);

For some of the libraries getting file reference is quite easy, for some - not so much. But still doable.

prrace · 2021-05-21T20:10:55Z

Please note that I added a number of comments in the CSR itself.
I had suggestions about what to do in many of the cases but there's a couple of cases where
I could not either divine what was intended or know the best way to phrase it.

azuev-java · 2021-05-21T20:19:42Z

Please note that I added a number of comments in the CSR itself.
I had suggestions about what to do in many of the cases but there's a couple of cases where
I could not either divine what was intended or know the best way to phrase it.

I am responding to CSR comments right now but honestly i would prefer to do a review in one place - preferably here. For some reason i do not receive any notifications from JBS about new comments in CSR so i had to monitor it manually by refreshing the page.

prrace · 2021-05-21T21:24:10Z

I was reviewing the CSR so comments in the CSR are the obvious place for that.
We can continue it here if you like

Will you be updating to explain how we map to (theoretical) non-square icons ?

As for the square icons - yes, we imply that the greater dimension is specified so in case of 256x128 icon
the 256x256 icon will be returned with the 256x128 bitmap inside and the 256x256 reported size.

FWIW I think now I understand that you mean we will always return a square icon, that may be an issue.
Imagine if the OS has icons that are 256x128 or 128x256 and we need to display a bunch of them side by side
and tow by row you will find it impossible to layout well. Surely we should return the same if we can
It is theoretically possible that the platform will do something bananas like return 128x256 then 256x256 then
384x256 alternative images in which case we'd need logic to handle that as sensibly as possible, acc.
to the way MRI handles cuch cases, but if the aspect ratio is consistent as I expect is typical we should support that

I can't agree that IAE is wrong for a negative size. The argument that a developer may make a mistake
is not sufficient. Virtually every Image related API we have throws an exception (usually IAE) if you pass <= 0
and folks get that right all the time. Allowing it here would be anomalous.

azuev-java · 2021-05-22T00:55:22Z

if the aspect ratio is consistent as I expect is typical we should support that

Ok, i see your point. I can do that for sure, it is just a change of API for now, no implementation will be affected since Windows does not support non-square icons for files and passage about exact size can not be guaranteed will save us from "i requested 128x20 and you returned 128x128" complaints. One will get what platform is able to serve. However, i do not see why we should limit the maximum requested size.

I can't agree that IAE is wrong for a negative size.

How about non-existing file or file? Also IAE?

prrace

if the aspect ratio is consistent as I expect is typical we should support that

Ok, i see your point. I can do that for sure, it is just a change of API for now, no implementation will be affected since Windows does not support non-square icons for files and passage about exact size can not be guaranteed will save us from "i requested 128x20 and you returned 128x128" complaints. One will get what platform is able to serve. However, i do not see why we should limit the maximum requested size.

Did I say that? I think I said something more like the opposite.

The spec you wrote seems to suggest that if the user exceeds some unknown size that you aren't telling them,
you'll return null, leaving them in a guessing game as to what is the maximum.
That can't be right.
So either you provide another API telling them the maximum size, or, if they exceed the maximum size
you specify that the API will return the best fit, just like in other cases.

The question I raised was around what "size" means. If you meant the API to return the size to
which the image will scale when drawn, you need to make this very clear to the developer,
or since you don't have an API telling them the max available, they'll respond by asking for ridiculous sizes
to get the best quality image.

So what do you intend ?

I can't agree that IAE is wrong for a negative size.

How about non-existing file or file? Also IAE?

First .. "inaccessible" should not be distinguishable from "non-existing".
If I ask for a file that the system has hidden from me for whatever reason.
Now since this is something where the app may not know that for platform reasons,
I think a file that cannot be "found" should not throw IAE, just return null.

Passing in null directly tho' probably should be IAE because what are they doing that for ??

prrace · 2021-05-21T21:55:29Z

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java

+    * underlying implementation.
+    * @return an icon as it would be displayed by a native file chooser
+    * or null if invalid parameters are passed such as pointer to a
+    * non-existing file or a size outside of supported range.


pointer -> reference

prrace · 2021-05-21T22:07:30Z

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java

+    * @param f a {@code File} object for which the icon will be retrieved
+    * @param size width and height of the icon in user coordinate system.
+    * This API only supports square icons with the edge length
+    * equals or greater than 1. Maximum size allowed is defined by the


I think this is a weird way to say size >=1.

We should throw IAE for <=0 .

I also think we need to allow for rectangular icons, not bake it in to the spec in such strong terms that we don't.
I suppose it could be revised if a platform that needs it comes along but ...

Still not sure about failing if you exceed the maximum size.

Why ? Why not just return the largest possible - it is the same thing as other cases, we'll return the best match.

If that is what you already mean, then say it more clearly.

Ok, in order to allow rectangular items API needs to be slightly modified and tests and documentation should be amended accordingly. I did that, please take a look, once it is settled i will update and finalize CSR.

accordingly Fixed test to support updated API Added negative test cases

prrace · 2021-05-25T23:12:07Z

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java

+    * @see JFileChooser#getIcon
+    * @see AbstractMultiResolutionImage
+    * @see FileSystemView#getSystemIcon(File)
+    * @since 17


You need to add the IAE to the javadoc.

prrace · 2021-05-25T23:12:10Z

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java

+    */
+    public Icon getSystemIcon(File f, int width, int height) {
+        if (height <1 || width < 1) {
+            throw new IllegalArgumentException("Icon size can not be below 1");


(minor) spacing. <1

Typo. Fixed.

prrace · 2021-05-25T23:14:11Z

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java

+        }
+
+        if (f == null || !f.exists()) {
+            return null;


I suggested the a null File ought to be IAE too - this is showing up in the conversation thread but not here.

prrace · 2021-05-25T23:17:39Z

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java

+    * @param height height of the icon in user coordinate system.
+    * @return an icon as it would be displayed by a native file chooser
+    * or null if invalid parameters are passed such as reference to a
+    * non-existing file.


non-existent not non-existing, but I think null deserves an IAE - as I had written a couple of days ago.

I see you dropped the words about null if the size is too large.
Should I interpret that as meaning one of the things I suggested - that this is just another case of a closest match ?

Thanks for correction. Yes - we will return the best match no matter how big the requested size is.

Fixed IAE in case of null file.

Small fixed in JavaDoc

prrace

Approving but fix the grammar!

prrace · 2021-05-26T14:50:45Z

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java

+    * @param height height of the icon in user coordinate system.
+    * @return an icon as it would be displayed by a native file chooser
+    * or null if invalid parameters are passed such as reference to a
+    * non-existent file.


grammar : "a reference"

prrace · 2021-05-26T14:53:43Z

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java

+    * non-existent file.
+    * @throws IllegalArgumentException if invalid parameter such
+    * as negative size or null file reference is passed.
+    * @see JFileChooser#getIcon


minor grammar : add "an"or "a" as appropriate, ie change to :
"if an invalid parameter such a negative size or a null file reference"

aivanov-jdk · 2021-05-26T15:07:30Z

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java

+        }
+
+        if (f == null){
+            throw new IllegalArgumentException("File reference should be specified");


Shall the exception message be more specific: "The file reference should not be null"?

aivanov-jdk · 2021-05-26T15:15:42Z

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java

+        if(!f.exists()) {
            return null;


Shall it throw FileNotFoundException or IllegalArgumentException if the file doesn't exist?
It could more convenient to return null rather than catch an exception.

The space is missing between if and the opening parenthesis.

It definitely should not be IAE. But FNFE is a reasonable idea.
However it changes the usage since it is a checked exception.
I'm on the fence and could go either way.

The older similar method, getSystemIcon(File f), returns null if the file doesn't exist. It could make sense to preserve the behaviour from this point of view and not to make the user of the API handle FNFE; thus the new method could easily be used instead.

aivanov-jdk · 2021-05-26T15:18:18Z

test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java

+    }
+
+    static void negativeTests() {
+        ImageIcon icon;


Can it be icon? This test doesn't use the fact that the returned object is ImageIcon.

aivanov-jdk · 2021-05-26T15:21:53Z

test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java

+        boolean gotException = false;
+        try {
+            icon = (ImageIcon) fsv.getSystemIcon(new File("."), -1, 16);
+        } catch (IllegalArgumentException iae) {
+            gotException = true;
+        }
+        if (!gotException) {
+            throw new RuntimeException("Negative size icon should throw invalid argument exception");
+        }


A suggestion: throw the exception inside try-block and ignore the expected exception, then gotException can be dropped.

Suggested change

boolean gotException = false;

try {

icon = (ImageIcon) fsv.getSystemIcon(new File("."), -1, 16);

} catch (IllegalArgumentException iae) {

gotException = true;

}

if (!gotException) {

throw new RuntimeException("Negative size icon should throw invalid argument exception");

}

try {

fsv.getSystemIcon(new File("."), -1, 16);

throw new RuntimeException("Negative size icon should throw invalid argument exception");

} catch (IllegalArgumentException iae) {

// expected

}

Shall the test also exercise 0 as an invalid parameter? Shall the test also pass an invalid height?

I do not think such detailed testing is required. After all it is not a full spec conformance test.

Adjustments in the test

mrserb · 2021-05-26T21:06:49Z

Did somebody run the test on Linux and macOS, Does our stub implementation there confirms the specification?

mrserb · 2021-05-26T21:11:41Z

test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java

+                throw new RuntimeException("icon is null!!!");
+            }
+
+            if (implComplete && icon.getIconWidth() != size) {


Why the size of the returned images might be different? The spec state the size parameter in the getSystemIcon is the size of the icon in the userspace.

The spec says that we are taking into consideration requested sizes but depending on the platform implementation exact match can not be guaranteed. On Windows it can so i'm checking for that.

Is this requirement is so important? can we return an MRI(same as on Windows) which will have just one resolution? Otherwise what the user should do if the requested size was 32x32 but returned image will be 21x21? Paint the small icon or rescale it by the application?

Is this requirement is so important? can we return an MRI(same as on Windows) which will have just one resolution?

We might - when the implementation will be done on other platforms. Probably it will be done by me, probably - by someone else. Right now we return whatever we have so on Linux it is UIManager default icons for file or a folder (which is exactly what any file manager on Linux shows for any file and this is exactly what we promised in the method description). In the future it can change but for now it is all we can guarantee.

This is my point I think we should update this implementation to always return MRI of the requested size, otherwise, the code example of this will look like this:

Icon icon = fsv.getSystemIcon(file, width, height); if (icon.getIconWidth() != width && icon.getIconHeight() != height) { return scaleTheIconInTheSameWayAsBeforeTheFix(icon, width, height); } else if (icon instanceof ImageIcon) { ImageIcon imageIcon = (ImageIcon) icon; if (icon.getImage() instanceof MultiResolutionImage) { MultiResolutionImage mri = (MultiResolutionImage) icon.getImage(); return mri.getResolutionVariant(width, height); } else { return imageIcon; } } else { return icon; }

I pretty sure we can do better than the code above.

mrserb · 2021-05-26T21:12:16Z

test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java

+    static void testSystemIcon(File file, boolean implComplete) {
+        int[] sizes = new int[] {16, 32, 48, 64, 128};
+        for (int size : sizes) {
+            ImageIcon icon = (ImageIcon) fsv.getSystemIcon(file, size, size);


Is this cast allowed without instanceof check?

On Windows - yes. When implementation is complete on other platforms test will have to be updated depending on the way it will be implemented there.

Hmm .. I focused too much on the spec it seems. The API returns Icon and the test should not
"know" or depend on it being anything more specific.
Why does it need to do this ?

prrace · 2021-05-27T00:18:13Z

test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java

+ * @test
+ * @bug 8182043
+ * @summary Access to Windows Large Icons
+ * sun.awt.shell.ShellFolder


What's the comment here mean ?

That's a leftover from the first iteration of the test. I guess i have to remove it.

prrace · 2021-05-27T00:19:26Z

test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java

+    static void testSystemIcon(File file, boolean implComplete) {
+        int[] sizes = new int[] {16, 32, 48, 64, 128};
+        for (int size : sizes) {
+            ImageIcon icon = (ImageIcon) fsv.getSystemIcon(file, size, size);


Hmm .. I focused too much on the spec it seems. The API returns Icon and the test should not
"know" or depend on it being anything more specific.
Why does it need to do this ?

azuev-java · 2021-05-27T01:39:28Z

Why does it need to do this ?

I'm testing the implementation here and i know that on Windows for these well known files and folders it is possible to get icons of all the sizes mentioned in the test and we will return the correct icon size - so that's what i'm testing it this way.

azuev-java · 2021-05-27T02:00:10Z

Did somebody run the test on Linux and macOS, Does our stub implementation there confirms the specification?

I did run fill tier4 and visually compared the JFileChooser appearance on both Linux and Mac OS X - this change introduced no visual degradation to them and the test passed.

azuev-java · 2021-05-27T21:47:31Z

/integrate

openjdk · 2021-05-27T21:49:47Z

@azuev-java Since your change was applied there have been 360 commits pushed to the master branch:

8a31c07: 8267886: ProblemList javax/management/remote/mandatory/connection/RMIConnector_NPETest.java
ae258f1: 8265418: Clean-up redundant null-checks of Class.getPackageName()
41185d3: 8229517: Support for optional asynchronous/buffered logging
7c85f35: 8267123: Remove RMI Activation
0754266: 8267709: Investigate differences between HtmlStyle and stylesheet.css
23189a1: 8191786: Thread-SMR hash table size should be dynamic
ef368b3: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load inside a container
10a6f5d: 8230623: Extract command-line help for -Xlint sub-options to new --help-lint
bea4109: 8187649: ArrayIndexOutOfBoundsException in java.util.JapaneseImperialCalendar
ec65cf8: 8240347: remove undocumented options from jlink --help message
... and 350 more: https://git.openjdk.java.net/jdk/compare/880c138b587e0902cd19c27a02baf41b57ac0bb0...master

Your commit was automatically rebased without conflicts.

Pushed as commit 7f52c50.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

8182043: Access to Windows Large Icons

19a0efe

Fix updated based on the previous review.

openjdk bot added the rfr Pull request is ready for review label Mar 8, 2021

openjdk bot added 2d client-libs-dev@openjdk.org swing client-libs-dev@openjdk.org awt client-libs-dev@openjdk.org labels Mar 8, 2021

openjdk bot added the csr Pull request needs approved CSR before integration label Mar 8, 2021

aivanov-jdk reviewed Mar 10, 2021

View reviewed changes

aivanov-jdk reviewed Apr 2, 2021

View reviewed changes

azuev-java and others added 2 commits April 29, 2021 22:05

Small fixes

6607b61

Remived size parameter from makeIcon Removed useVGAColors usage as irrelevant since it is ignored on all supported platforms now

Update src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp

4a36062

Select one icon at a time. Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk@users.noreply.github.com>

aivanov-jdk reviewed Apr 30, 2021

View reviewed changes

azuev-java added 2 commits May 7, 2021 09:51

Merge remote-tracking branch 'origin/master' into JDK-8182043

5b2c941

Small fixes

237d407

Added testing for MultiResolutionImage

aivanov-jdk reviewed May 11, 2021

View reviewed changes

aivanov-jdk suggested changes May 11, 2021

View reviewed changes

azuev-java added 2 commits May 11, 2021 13:16

Slightly changing javadoc wording

a481b29

Removing unnecessary boxing of int Releasing the pIcon in native code properly

Make getShell32Icon method return multi-resolition image in case of

10bae9b

requested icon size and actual icon size mismatch.

aivanov-jdk suggested changes May 14, 2021

View reviewed changes

Slight change of wording in javadoc

4cd5a50

Fixed Win32ShellFolder2.getSystemIcon scaling issue

aivanov-jdk approved these changes May 14, 2021

View reviewed changes

azvegint reviewed May 16, 2021

View reviewed changes

Example in JavaDoc fixed

911bc70

Chenged implementation specification based on CSR review

5628578

prrace reviewed May 22, 2021

View reviewed changes

Changed API to support non-square icons and updated documentation

d679dc0

accordingly Fixed test to support updated API Added negative test cases

prrace reviewed May 25, 2021

View reviewed changes

null file now properly causes IllegalArgumentException

b3ca9da

Small fixed in JavaDoc

prrace approved these changes May 26, 2021

View reviewed changes

aivanov-jdk reviewed May 26, 2021

View reviewed changes

azuev-java added 2 commits May 26, 2021 08:23

Grammar fix in method documentation

4835302

Fixed small errors

9e7bf90

Adjustments in the test

aivanov-jdk approved these changes May 26, 2021

View reviewed changes

mrserb reviewed May 26, 2021

View reviewed changes

prrace reviewed May 27, 2021

View reviewed changes

Test comment fixed.

0652197

openjdk bot closed this May 27, 2021

openjdk bot added integrated Pull request has been integrated and removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels May 27, 2021

azuev-java deleted the JDK-8182043 branch April 7, 2022 18:02

openjdk bot added the client client-libs-dev@openjdk.org label Apr 7, 2022

mrserb mentioned this pull request Jun 21, 2022

8282526: Default icon is not painted properly #7805

Closed

3 tasks

		bothIcons.put(getLargeIcon? LARGE_ICON_SIZE : SMALL_ICON_SIZE, newIcon);
		bothIcons.put(getLargeIcon? SMALL_ICON_SIZE : LARGE_ICON_SIZE, newIcon2);

	for (int i = start; i != end; i+=increment) {
	for (int i = start; i != end; i += increment) {

	for (Integer i: resolutionVariants.keySet()) {
	for (Integer i : resolutionVariants.keySet()) {

		Toolkit toolkit = Toolkit.getDefaultToolkit();
		String shellIconBPP = (String)toolkit.getDesktopProperty("win.icon.shellIconBPP");

	* @param f a <code>File</code> object
	* @param f a {@code File} object

		* which will allow better scaling with different
		* magnification factors.

8182043: Access to Windows Large Icons #2875

8182043: Access to Windows Large Icons #2875

Uh oh!

Conversation

azuev-java commented Mar 8, 2021 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Reviewing

Uh oh!

bridgekeeper bot commented Mar 8, 2021

Uh oh!

azuev-java commented Mar 8, 2021

Uh oh!

openjdk bot commented Mar 8, 2021

Uh oh!

mlbridge bot commented Mar 8, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

azuev-java commented Mar 8, 2021

Uh oh!

openjdk bot commented Mar 8, 2021

Uh oh!

mrserb commented Mar 10, 2021

Uh oh!

azuev-java commented Mar 10, 2021

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

azuev-java commented Mar 8, 2021 •

edited by openjdk bot

Loading

mlbridge bot commented Mar 8, 2021 •

edited

Loading