I made up (via find -name '*.jpg' >> foo.list) a .list file with about 3500 biggish images in it. Pressed the edit button. Waited. Disk activity gets worse and worse. Out of memory. Oops, I won't try that again :-(
Additional information: It'd be nice if I could say "descend recursively into XYZ directory and use any images there as backdrop candidates", as with MacOSX, and preferably without using 512MB ram :/
ouch... which xfce version is it ?
4.0.5. Didn't see any previous reports for such a bug, though.
i don't use an image list, so i haven't hit this. there are definitely some performance issues with image list handling that i need to resolve, but i'm not so sure that they'll be backported to the 4.0.x branch.
Yep. I don't think that the aforementioned behaviour is a bug, as such, but it sure does use way more memory than I expected it to. It seems to work ok with much smaller lists.
this works fine in CVS, using an image list file with >2500 images. memory usage jumps about a bit while loading the list, but after it's finished, usage is about the same as before it started. this is probably a 4.0.x-only bug, and i really don't have the time or inclination to look into it. if someone else wants to come up with a patch, that's fine.
I have tested with a list of about 13000 images Bringing up the list by saying Edit list ... from the desktop settings page no longer uses up lots of memory in the CVS version as it used to in 4.0.x However, it did use up lots of CPU (I waited 10 minutes and then interrupted it) Debugging showed that this was happening in xfdesktop/settings/backdrop-mgr.c in check_image.c - basically all the images in a list are read into a pixbuf to check that they are valid. Disabling this code caused the list to come up quickly. Then I looked in CVS and saw that this has been fixed there :-)
i wrote a short routine for CVS that doesn't actually load the entire image, but just stuffs enough data into a pixbuf loader until the loader can verify that it is indeed a valid image, and then it closes it. for most image formats, i would guess that this involves just a few kB of the file. it still will take a long time (linear time with respect to the # of images) and eat up CPU, but nowhere near as much time as it used to (plus, the progress bar now displays a percentage value instead of just bouncing back and forth). i'm considering removing the validation entirely and just making sure in a different way that xfdesktop doesn't try to paint an invalid image to the desktop. that'll make things a lot faster from the editor's perspective, but you can then end up with invalid images in the list. i guess it just depends on whether or not we care about that.
this actually is fixed, i've just been keeping it open with the intent of figuring out if i want to remove the file validation entirely. but i should open up a new bug for that
really marking FIXED this time ^_~