After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 754425 - fuzzy looking album placeholder icon
fuzzy looking album placeholder icon
Status: RESOLVED FIXED
Product: gnome-music
Classification: Applications
Component: general
3.17.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-music-maint
gnome-music-maint
Depends on:
Blocks: 766258
 
 
Reported: 2015-09-01 22:56 UTC by Andreas Nilsson
Modified: 2016-10-04 12:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
screenshot (70.62 KB, image/png)
2015-09-01 22:56 UTC, Andreas Nilsson
  Details
Patch for using load_icon_for_scale instead of load_icon (6.30 KB, patch)
2016-03-24 12:58 UTC, Chieh-Min Wang
none Details | Review
Patch for using load_icon_for_scale instead of load_icon (6.89 KB, patch)
2016-03-24 13:12 UTC, Chieh-Min Wang
none Details | Review
Using load_icon_for_scale to get hidpi icon for hidpi environment (7.56 KB, patch)
2016-03-28 06:13 UTC, Chieh-Min Wang
needs-work Details | Review

Description Andreas Nilsson 2015-09-01 22:56:12 UTC
Created attachment 310455 [details]
screenshot

The graphics used for the album without a album cover on the right is upscaled and looks a bit blurry.
Comment 1 Vadim Rutkovsky 2015-09-01 23:02:51 UTC
Is this an HiDPI display? I think we already have a bug filed for that.

Not sure if we can fix it - we don't choose the size of thumbnail from last.fm. It might also be some incorrect downscaling on our side though
Comment 2 Andreas Nilsson 2015-09-02 09:40:11 UTC
Yup, it's a hidpi (3200x1800).
The thumbnail from lastfm is OK, but the placeholder icon on the right comes from gnome-icon-theme-symbolic I think.
https://git.gnome.org/browse/gnome-music/tree/data/NoMusic.ui#n16
Comment 3 Chieh-Min Wang 2016-03-24 12:58:18 UTC
Created attachment 324673 [details] [review]
Patch for using load_icon_for_scale instead of load_icon

Use load_icon_for_scale to show icon for higher dpi
Comment 4 Chieh-Min Wang 2016-03-24 13:12:34 UTC
Created attachment 324675 [details] [review]
Patch for using load_icon_for_scale instead of load_icon

Fix some get_default_icon not using the new format error of previous patch
Comment 5 Chieh-Min Wang 2016-03-28 06:13:44 UTC
Created attachment 324862 [details] [review]
Using load_icon_for_scale to get hidpi icon for hidpi environment

Using git format-patch to generate patch
Comment 6 Marinus Schraal 2016-05-11 09:44:05 UTC
Review of attachment 324862 [details] [review]:

In general I think this patch is on the right track, however I think the scale shouldn't be passed back and forth. Whenever an icon/albumart is requested it should figure out the current scale and use that, so that should be artcache class contained.

I guess it's technically possible for scale to shift during run time, not sure if and how we should react to that.
Comment 7 Marinus Schraal 2016-09-27 22:58:07 UTC
I've added a wip/mschraal/coverart branch on git, which should fix this issue. Please test and report back.
Comment 8 Marinus Schraal 2016-10-04 12:33:04 UTC
see #7

This problem has been fixed in the unstable development version. The fix will be available in the next major software release. You may need to upgrade your Linux distribution to obtain that newer version.