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 700443 - cover art locks UI
cover art locks UI
Status: RESOLVED FIXED
Product: gnome-music
Classification: Applications
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-music-maint
gnome-music-maint
Depends on:
Blocks: 701427
 
 
Reported: 2013-05-16 10:46 UTC by Jakub Steiner
Modified: 2013-06-04 10:42 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch (13.04 KB, patch)
2013-06-01 14:23 UTC, Arnel Borja
needs-work Details | Review
Updated patch (12.40 KB, patch)
2013-06-01 18:07 UTC, Arnel Borja
none Details | Review
Updated patch: show default in toolbar too (12.57 KB, patch)
2013-06-01 18:40 UTC, Arnel Borja
none Details | Review
Updated patch rebased against master (12.63 KB, patch)
2013-06-01 18:48 UTC, Arnel Borja
none Details | Review
Updated patch to "cache" default icon (13.76 KB, patch)
2013-06-02 13:54 UTC, Arnel Borja
committed Details | Review
Make loading of cover art asynchronous (13.81 KB, patch)
2013-06-04 10:42 UTC, Vadim Rutkovsky
committed Details | Review

Description Jakub Steiner 2013-05-16 10:46:02 UTC
When cover art is being looked up and downloaded the UI stutters (scrolling around becomes difficult). UI should remain responsive and background tasks non-locking.
Comment 1 Arnel Borja 2013-06-01 14:23:55 UTC
Created attachment 245826 [details] [review]
Patch

I tried creating a patch for this.
Comment 2 Seif Lotfy 2013-06-01 16:19:39 UTC
Review of attachment 245826 [details] [review]:

Very good start Arnel :D
Thanks for the amazing effort. Can you take care of the small comments I made?

::: src/albumArtCache.js
@@ +54,3 @@
 
+    try_load: function(size, artist, album, i, callback) {
+        var key, path, file;

CamelCase :P and I assume this is a private method so append an underscore ==> _tryLoad

@@ +58,2 @@
+        if (i >= this._keybuilder_funcs.length) {
+            callback (null);

No need to do a callback. Just ignore it and do a return

::: src/widgets.js
@@ +257,3 @@
+                            if (pixbuf == null)
+                                pixbuf = albumArtCache.makeDefaultIcon(256, 256);
+                            this.ui.get_object("cover").set_from_pixbuf (pixbuf);

You are waiting for the callback to set the default icon. The default icon should be set before we call lookup (since we know it exists and does not require lots of crawling)
Comment 3 Arnel Borja 2013-06-01 18:07:14 UTC
Created attachment 245835 [details] [review]
Updated patch

(In reply to comment #2)
> Review of attachment 245826 [details] [review]:
> 
> Very good start Arnel :D
> Thanks for the amazing effort. Can you take care of the small comments I made?
> 
> ::: src/albumArtCache.js
> @@ +54,3 @@
> 
> +    try_load: function(size, artist, album, i, callback) {
> +        var key, path, file;
> 
> CamelCase :P and I assume this is a private method so append an underscore ==>
> _tryLoad

Fixed. Vala habit :D

> @@ +58,2 @@
> +        if (i >= this._keybuilder_funcs.length) {
> +            callback (null);
> 
> No need to do a callback. Just ignore it and do a return

Are you sure? The code in view.js checks only the cache then uses grilo to get the cover art if not found. Also, see below.

> ::: src/widgets.js
> @@ +257,3 @@
> +                            if (pixbuf == null)
> +                                pixbuf = albumArtCache.makeDefaultIcon(256,
> 256);
> +                            this.ui.get_object("cover").set_from_pixbuf
> (pixbuf);
> 
> You are waiting for the callback to set the default icon. The default icon
> should be set before we call lookup (since we know it exists and does not
> require lots of crawling)

I moved the default icon part to before the new is inserted to the model. It is then inserted as default value. After loading, only sets the icon if successful.

Is the scaling part alright? I didn't use async there because there is no async function for just scaling which would make reloading from the stream required, and I think streams could be used only once.
Comment 4 Arnel Borja 2013-06-01 18:40:04 UTC
Created attachment 245836 [details] [review]
Updated patch: show default in toolbar too

Updated patch to show default icon in toolbar too.

Now only ArtistAlbumWidget._updateAlbumArt and ViewContainer._updateAlbumArt remains users of that callback (null).
Comment 5 Arnel Borja 2013-06-01 18:48:44 UTC
Created attachment 245837 [details] [review]
Updated patch rebased against master
Comment 6 Arnel Borja 2013-06-02 06:32:17 UTC
I think my patch needs further improvement, so don't push it yet unless you think the improvements should be or could be moved to a different patch.

My concern is with the default icons. Seems like they are still causing a small delay in the playback (especially the default image in the toolbar). I am still investigating which ones are causing these.

I think we should cache the default image. Since calling albumArtCache.makeDefaultIcon is not asynchronous. I think the small delay will be further minimized by doing so - we just call that function once, causing a small delay, then reuse it while adding tracks. Because we add the tracks after loading the default icon, I don't think making albumArtCache.makeDefaultIcon asynchronous is a good thing - it will add another layer of callbacks.

I can't easily say these into words, so I'll just show what the current situation is:

=== Views ===
Current situation in views:
- Look for tracks
  - Create default icon synchronously  <- This causes delay
  - Load the cover art synchronously   <- Causes a lot of delay

Situation in views after current patch:
- Look for tracks
  - Create default icon synchronously  <- This causes delay
  - Load the cover art asynchronously

Possible improvement for views:
- Create default icon synchronously    <- Causes delay, but smaller
- Look for tracks
  - Load cover art asynchronously

=== Toolbar ===
Current situation in toolbar:
- Load track
- Load cover art synchronously         <- Causes a lot of delay
- Set cover art                        <- Might be causing some delay
- Set state to playing

Situation in toolbar after current patch:
- Load track
- Load default icon                    <- Causes some delay
- Set cover art                        <- Might be causing some delay
- Load cover art asynchronously
- Set state to playing

Possible improvement for toolbar:
- Load default icon in _init           <- Causes delay, but smaller
- Load track
- Set cover art                        <- Might be causing some delay
- Load cover art asynchronously
- Set state to playing

Setting the cover art might be causing some delay, maybe make an idle function which sets the default icon and loads the cover art asynchronously? So that the state would be changed to playing immediately. (I already tried this, but there are still some delay, especially when the next song is shorter than the current one, the scrollbar jumps to start, to end then to start again. I'm still investigating it).

What do you think? Do you have a better idea?
Comment 7 Arnel Borja 2013-06-02 13:54:25 UTC
Created attachment 245853 [details] [review]
Updated patch to "cache" default icon
Comment 8 Vadim Rutkovsky 2013-06-04 10:42:11 UTC
Awesome, worked like charm for me, thanks!

The following fix has been pushed:
e579c23 Make loading of cover art asynchronous
Comment 9 Vadim Rutkovsky 2013-06-04 10:42:19 UTC
Created attachment 245981 [details] [review]
Make loading of cover art asynchronous