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

[Andrei Rybak]

On 09/08/2023 01:35, Andrei Rybak wrote:
> 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 

I've forwarded a more organized list of notes from emails in this thread to
the "Additional Information" form on bugreport.java.com.