Asynchronous loading of marks/metadata?

[xsdg]

One thing that's always been true for me is that loading marks for lots of camera raw images (structurally, TIFFs with embedded metadata) takes a super long time. This is because marks are a form of metadata, and trying to read metadata from a raw file takes a long time. Anecdotally, it takes 60+ seconds for the loading process to finish in a directory of 2,000 raw files from my Nikon D7100 (~30MB per file; dunno if that matters). And during that time, the UI is completely unresponsive.

I've attached a stack trace from during that period (I just waited for the UI to stop responding, and then hit ^C in gdb), and as expected, it's in the middle of Exif parsing: geeqie_mark_bt.txt

I'm not completely sure what the behavior here should be. One obvious option is to show all of the files (which takes less than 1 second), and then to load the metadata and marks asynchronously. Another obvious one is to only add the files into the ViewFileList/Icon once the metadata has loaded. Either way, it's still going to take the full 60+ seconds to have full functionality over the full set of images, but it means that I can start looking at the first images without having to wait for the last ones to load, which is always what makes the current state so painful.

Open to thoughts and suggestions on what the behavior should be, how to implement, and so on. At first glance, switching things from synchronous to async inside of vflist_setup_iter seems like it could work. I commented out the code to add the marks to the GtkTreeStore and that's when the load time dropped to <1sec. Everything works properly except that the marks don't show up in the ViewFile, as one would expect.

So maybe having some way to indicate in the ViewFile itself that the metadata is still loading for a particular file could work? And then every second or so (while the async metadata loading is in process), the ViewFile is refreshed with the new state? Dunno, I'm just tossing out ideas here. Please chime in

[caclark]

The marks data is held only in the filedata structures. I guess what happens is that there are keyword-marks links, so the code goes looking in the exif data for relevant keywords in every file.

Reading exif data is a big problem anywhere e.g. set the sort order to sort-by-exif-date, select a folder with a few thousand images, and Geeqie will freeze for a considerable time.

I assume the run-time is being consumed in the exiv2 library, and not in the Geeqie code. If so, the only solution is to read exif data either in the idle loop or in another thread. The idle loop is probably easiest because of the need to write filedata blocks.

Indication of reading exif data could be done with the thumbnail progress bar - just change the background colour if reading of both thumbnail and exif data is happening at the same time.

I made a half-hearted attempt to put exif reads into the idle loop a while ago. I suppose I should try again - program freezes count as being serious faults.

There is still the problem of the time taken to present the data. In that case, caching of the exif data is the only solution I can see.

[xsdg]

Hmm... sort-by-exif-date is a good point — with marks, at least the images are guaranteed to be in the right order; just without the right marks shown. And regardless of the displayed marks, the displayed keywords for the current image will always be up-to-date. With sort-by-exif-date, the image order is likely going to be incorrect until loading finishes.

I think that tends to favor a UX where each item has some feature (like a background color) that shows whether it's partially- or fully-loaded. Items that are partially-loaded might not have the right marks set, might not be in the correct location, etc.

I'll probably take a look at making exif loading async. FileData already has a notification system, so it shouldn't be too difficult to add a new mode to that for exif loading. One question is how to keep the notifications from being too expensive — notifying once per loaded file seems like it might not scale well, but I guess we'll see…

[caclark]

When using GTK3, and with ViewIcon selected, scrolling down the thumbnails is slow. If ViewList is selected, scrolling is fairly normal. The reason for the speed drop is calls made to gtk_render_check() and gtk_render_frame().

If this is the problem you see, maybe something can be done.