I’m developing a python plugin for Rhythmbox – this contains a GtkScrolledWindow with a child which is a GtkIconView. The IconView is fed from a Gtk.TreeModel.
It looks like this:
Currently – and somewhat inefficient, every icon is drawn for every row in the tree-model – each icon is a GdkPixbuf from a file. If you have thousands of rows, it can take quite a while for the whole iconview to be fully updated with every picture icon.
What I am trying to achieve is to only update the icons that are in the current drawing area – when the user scrolls and releases the scrollbar (or navigates via the keyboard), the icons in the new drawing area should be updated with relevant pictures.
N.B. – the tree-model would be fully populated at this point – only the icons would not have been loaded.
This is not really my area of expertise – I’m looking for pointers for the best approach I should use to achieve the above.
Specifically – which Gtk+3 drawing-area signal (or signals) can be exposed (Gtk.ScrolledWindow / Gtk.IconView ?) to write python code to calculate what icons should be updated?
You should profile you application to see what takes time.
Is that loading the images ? If it is, then loading a default image and adding it everywhere in your view would be quick enough, as you’d load only one image. You’d then load and update the images on-demand using idle_add, based on the images that should appear in the viewport.
If what takes times is adding the images to the model, then you’d need to do the adding on-demand, by checking what is visible on the viewport in your idle_add callback.
If both are slow, you’d need a mix of both solutions: loading and adding on-demand.
Think also about the proxy design pattern that can be useful to create a fake cover object that will load in the background, and contain the loading policy.
For the signals, your GtkIconView widget implements GtkScrollable, which explains how to implement scrolling. You’d set your vertical adjustment and check when it has changed by connecting to its value-changed signal. This would mean the user scrolled up or down, and you’d need to fire up a timer with timeout_add. If after a short timeout (between 0.5 and 1s I think, but needs testing), the adjustment hasn’t changed, this means the user stopped scrolling, and you can update what is displayed. Otherwise, it would be updated during the scrolling, slowing everything down. You then just need to figure out how to find which items appear in the viewport, to update their cover.
I’ve never done this before though, but I know GTK a bit and just tried to figure out how it would be done, so read that with a bit of caution. Anyway, the answer to reactivity is “on-demand”.