[Utils] make remote image loading asynchronous

[jku]

Remote images were previously loaded synchronously in image_from_file(). Change that into a PixbufAsyncLoader that takes a url and a callback. Callback will be called when pixbuf is ready.

Fixes #12.

Signed-off-by: Jussi Kukkonen jussi.kukkonen@intel.com

[markdryan]

Hi Jussi,

Great. Do you mind if I squash the commits?

Just one question on the case where the user closes the player window while an image is loading. So what I'm really wondering is do we need to explicitly call g_cancellable_cancel to cancel the asynchronous operation started by read_async? Or will the operation be automatically cancelled when the GFIle object is destroyed? If it is automatically cancelled by the destruction of the GFile object, is this object destroyed when the window is closed or only when the operation completes? What I'm trying to work out is whether the current code will continue to asynchronously load an image after the user has closed the player window.

[jku]

Yes, feel free to squash.

My understanding is that the nothing is actually destroyed until things like an async operation have finished (it basically takes a reference), even if the object is not referenced in the code anymore. I believe the image will continue to be loaded after the player closes and nothing bad should happen when loading finishes... But I'm not a python guru: I can try and test this with the PixbufAsyncLoader.

[markdryan]

Okay, so this is my understanding as well. The question is, do we want to continue downloading an image we are not going to use or would it be better to cancel the download? How hard would it be to cancel?

[jku]

Oh, now I see. It's not very difficult, I suppose. I'm not sure the benefit of possibly saving some bandwidth is worth the downside of added complexity though... but I can add that if you want.

Also, comment for future work that is somewhat related: It's possible that this implementation needs to be extended later if we want to load icons for the treeview media item rows as we would not want to start 100 downloads all at once. In this case the "canceling" feature certainly makes sense as quick actions in the treeview are common: canceling already started downloads may be premature optimization even in that case.

[jku]

Actually, don't merge this yet: it seems my reasons for not using Gio.load_contents_async() were based on a misunderstanding. This can be simpler, at least when we move to gi-repository api.

[jku]

Ok, so two points after discussing with some developers more familiar with the api:

• current method of GFile.read_async() and then handling chunks with GInputStream API is indeed the best one as even the image file parsing happens in chunks
• unfortunately the gobject-introspection coverage for GInputStream API is not complete: we can't actually use this method with gi.repository yet

I'll close this request and add a commit on top of the gtk3 branch to use Gio.load_contents_async().