Cancellation happens too late

listviews have a cache area, that's why items off screen are not deleted immediately.

Thanks for that. Yes, I figured that too. The question is whether, they way things are at the moment, things are ever deleted. We allow up to 20 async requests via dbus and then queue any additional ones up on the client side. With the remote server taking 3-10 seconds for each image, it's easy to pile up a few hundred requests just by scrolling down quickly.

Now, when we get a cancel(), we actually cancel() the request if it's one that is still in the queue waiting to be sent. And we don't kick the queue to start working on another request until an earlier request completes. The question for me right now is "at what point (if any) does the listview cancel requests that scroll off the top of the screen while they are still waiting?"

The behavior I'm seeing when scrolling forward suggests that nothing is ever cancelled (or that cancellation isn't working for some reason). If cancellation did work, I wouldn't have to wait for the 200 requests that I just scrolled past to complete before the current region of the listview gets its thumbnails.

At this point, it's still investigation. I don't know what exactly is happening just yet. It's possible that there is still a bug in our request cancellation.

Fixed. The backlog of 20 was too large, meaning that the UI could never cancel requests quickly enough to actually be still in the queue because, each time we dropped back to the event loop, we'd fire another request. That turned all the cancel messages effectively into no-ops.

I also changed the rate limiter to use LIFO instead of FIFO. This gives a cancel message a much better chance of still finding a request waiting in the queue, so it can really be cancelled. This massively improves the user experience with a cold cache when scrolling through a large collection of songs because the requests that become visible once scrolling stops are dealt with first. (Previously, the thumbnails for songs visible at the end of the scroll would appear only once all preceding thumbnails (now no longer visible) had been dealt with.)

This bug was fixed in the package thumbnailer - 2.3+16.04.20160107.1-0ubuntu1

---------------
thumbnailer (2.3+16.04.20160107.1-0ubuntu1) xenial; urgency=medium

  * Fix for lp:1531038. Much better user experience this way. (LP:
    #1531038)

 -- Michi Henning <email address hidden> Thu, 07 Jan 2016 06:33:30 +0000