GNOME Bugzilla – Bug 481096
Thumbnails in collection viewer not updated when scrolling
Last modified: 2007-10-20 16:14:44 UTC
Please describe the problem: I open a directory containing 44 images in the eog collection viewer. 8 images (thumbnails) are visible in the collection viewer. When I scroll to the right to see the other images, no thumbnails are shown, but only the clock icon. When scrolling back to the left (to the images which were shown correctly at startup), they now also appear as clock icons. Steps to reproduce: See description above Actual results: Expected results: Does this happen every time? Yes Other information: eog-2.20.0-1mdv2008.0 on Mandriva Cooker 2008.0 x 86_64
This sounds like there is some job (load/save,thumbnailing,transform) not finishing and thus blocking others. Does this happen in other directories too or is it just a single one? Can you still switch images when this happens? Btw, It is normal as of 2.20 that the previously shown thumbnails are gone when they get out of view as they are unloaded to save some memory. Except that they should reload once they get back into view.
Yes, this seems to happen in any directory. I can still switch to the images of which the correct thumbnail is not shown: the image itself will show up correctly in eog.
The exact same thing happens to me as well, with eog 2.20.1 on Gentoo. Felix, any hints on how to debug this? If it is indeed another task not finishing, how do we figure out which one?
After fiddling a bit with the nice eog-debug infrastructure I've determined that the jobs run fine, but that eog thinks that the thumbs are already set. In eog_list_store_thumbnail_set the check for thumb_set is true every time, which causes eog_list_store_add_thumbnail_job not to be called at all, and thus no actual thumbnails are generated. Commenting out the thumb_set check make eog work as expected for me, but that probably isn't a fix for the actual problem. One more data point is that at one point during instrumentation also the initial thumbnails did not get loaded. Perhaps there is some kind of race condition with other code that manipulates thumb_set?
Thanks Hans for trying to figure it out. The biggest problem I have is that I cannot reproduce it at the moment and I'm only able to guess where the problem is. So I guess I might need your help for testing. Concerning the jobs, on my machine I have the impression that there are actually too many jobs running. Starting eog and showing the first 8 thumbnails just launched over 60 thumbnailing jobs here.
I'll probably be online for a good part of the afternoon (also as graaff on IRC) if you'd want me to try out a few things.
Created attachment 97511 [details] [review] first try to patch it Just tried to get onto IRC but my client is a little unstable (guess it needs an update) so I'll attach the two patches I currently have here. This one tries to avoid multiple jobs on the same thumbnail. I guess I'll commit something like this anyway as it at least makes the initial thumbnails appear faster.
Created attachment 97512 [details] [review] 2nd fixing try This one adds some mutex calls around a list store set. If this is not working I guess we'll have to try if securing any access to the liststore with mutexes will help. It would be nice if you could test these patches for me.
I've just tested both patches. Applying patch 1 didn't make any difference, and applying patch 2 on top of that didn't make a difference either. I haven't tried patch 2 in isolation but I don't think this really makes a difference.
Too bad. :-( If you have some time you could check if the following patch I commited to SVN helps. It fixes a pointer which shouldn't be one; coincidentially in eog_list_store_thumbnail_set(). Theoretically it should have still worked without it, but you might never know (maybe there is some issue with gboolean (32bit) -> pointer (32 or 64 bit) conversion).
Ehh, patch URL: http://svn.gnome.org/viewvc/eog/trunk/src/eog-list-store.c?r1=4147&r2=4146&pathrev=4147&diff_format=u
Thanks, this patch fixes the problem for me. I'm on AMD64, so it probably is a 64-bit related issue.
Well, I must say I'm impressed. I wasn't really expecting it to fix the problem; like I said it shouldn't have affected the test. I guess I was wrong. :-) I am going to enhance the patch's ChangeLog entry to point here, so we know what was going on. Hans, thanks a lot for all the testing and investigation. :-) ------ This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.