Follow up to "8313698: BaseMultiResolutionImage doesn't work as icon of java.awt.Window on Linux"

[Andrei Rybak]

Hello Aleksei, thank you for looking into this issue.

On 08/08/2023 22:04, Aleksei Ivanov wrote:
> You may want to update your test case so that it generates icons on the 
> fly and uses numbers to easily distinguish one from another. You can get 
> code from WindowIconUpdateOnDPIChangingTest.java [1].

This is cool, but not applicable.  With images generated on the fly,
the bug doesn't reproduce.  As far as I can tell from stepping
through this in the debugger, this has something to do with loading
the images from resources.

On openjdk 17.0.8: at java.desktop/sun/awt/X11/XWindowPeer.java:318,
IconInfo gets created in method updateIconImages(), and gets
initialized with `width == -1` and `height == -1`, because `null`s
are passed for parameter ImageObserver into java.awt.Image#getWidth
and java.awt.Image#getHeight, which AbstractMultiResolutionImage
delegates to its "base image".  But without an ImageObserver,
the underlying ToolkitImage has no way to update the caller about
the updates that might happen after the image is loaded.

`width == -1` and `height == -1` then gets checked a couple of lines
down at java.desktop/sun/awt/X11/XWindowPeer.java:324, where method
`sun.awt.IconInfo#isValid` returns `false`.

> You can read the commends in PR #6180 [2] where the test was added. 
> During the code review, it was determined the fix wasn't applicable to 
> Linux and macOS, so only Windows-specific changes remain.

The linked PR is about "8276849: Refresh the window icon on graphics
configuration changes".  I'm not sure if this is applicable to 8313698.
The issue is reproducible without graphics configuration changes,
on a singular monitor.

> As far as I know, Ubuntu doesn't show icons in the title bar of a 
> window, there's an app icon on the dock only, similar to macOS.

Ah, I see.  I should have also been more specific about that.  You're
probably describing Gnome Shell 3.  My results were taken in KDE,
with window decorations by KWin.  I haven't used other desktop
environments and window managers in a while, sorry for the confusion.

Here's how it looks in KDE: https://i.imgur.com/s5KSpkS.png

> Javadoc for Window.setIconImages [3] mentions, “the icons list can 
> contain MultiResolutionImage images”.

Yep. The bug report is about setIconImage (singular), and the workaround
is to just pass the same images as a List to setIconImages (plural),
without BaseMultiResolutionImage being involved.  It's included in
section "CUSTOMER SUBMITTED WORKAROUND".  The bug is also reproducible
with an exaggerated example of:

     window.setIconImages(Collections.singletonList(new BaseMultiResolutionImage(...)));

I've updated the reproducer on GitHub with more details to make it
more clear.  The bug is also reproducible when only a single image
is inside BaseMultiResolutionImage.

Thank you for helping me clarify these details.  I hope that my original
point about "Duke icon" being too ambiguous with files currently attached
to the Jira issue won't fall through the cracks.

> Disclaimer: I didn't run the test case.
> 
> -- 
> Regards,
> Alexey 
> 
> [1] https://github.com/openjdk/jdk/blob/6864441163f946d0bec7380a2a120e31b812a6dc/test/jdk/java/awt/Window/WindowIconUpdateOnDPIChanging/WindowIconUpdateOnDPIChangingTest.java
> [2] https://github.com/openjdk/jdk/pull/6180
> [3] https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/Window.html#setIconImages(java.util.List)
>
>
> On 08/08/2023 19:40, Andrei Rybak wrote: 
> > [...]
> > 
> > Because the person who reproduced the bug (Praveen Narayanaswamy) used
> > two images of Duke for files icon32x32.png and icon64x64.png [1] as input for
> > the _custom_ icon with BaseMultiResolutionImage, it gets really confusing.
> > My reproducer, available on GitHub, just uses two images of the numbers "32"
> > and "64" [2] for clarity. I have updated the wording in the reproducer on GitHub
> > to stop mentioning the Duke icon.[3] 
> > 
> > I hope this clarifies the ticket description. 
> > 
> > [1] The images in the Jira issue right now are not of the resolution claimed
> >     in the filenames, but the resolution doesn't matter for the bug's
> >     reproducibility.
> > [2] https://github.com/rybak/foobar/blob/master/baz/src/main/resources/swing/icon32x32.png
> >     and https://github.com/rybak/foobar/blob/master/baz/src/main/resources/swing/icon64x64.png
> >     with honest resolutions, just to be as close as possible for the actual use-case
> > [3] up-to-date reproducer on the branch master: 
> >     https://github.com/rybak/foobar/blob/master/baz/src/main/java/swing/MultiResolutionImageBug.java