Jon wrote:
"DisplayFusion builds a big list of images from all folders that aren't in the history, then randomly picks one and adds it to the image history."
After writing my comment yesterday I thought of this option too. In my case I have the images in 3 parent directories, one for each monitor, with time interval changes of 15, 20, and 15 seconds. I've "only" got something over 50,000 images though, not 350,000. But even with my smaller library, that's still enumerating 20,000 + 20,000 every 15 seconds, and something over 10,000 every 20 seconds. Then converting every filename to an index code as stored in the WallpaperHistoryV4 file, doing a massive compare/delete until a net undisplayed file list remains, and selecting one from this subset to display.
Wow. That's a lot of CPU cycles!
If Rick's observations are correct though, and I think they are because they agree with mine, this final selection from the subset is not quite as random as "random" would suggest.
I'd like to offer a suggestion for your next release (v7.1?): Do a directory enumeration every say 60 minutes (or better, make it user configurable in the advanced settings). Do the huge comparison/delete process and come up with a net not-displayed list, and just work off this smaller (little or a lot depending on how old/full the history is) until the next cycle. Then as each image is displayed all the code has to do is update the WallpaperHistoryV4 file and randomly select the next image from the smaller list. You don't even need to keep the non-displayed-image list in memory, just add a new table to WallpaperHistoryV4 and simply delete each image entry as it is shown and move it to the already-shown history table.
And, if you do the initial writes to the not-shown list in random order (not sure what this would cost CPU-wise though), then at each wallpaper change it would be just an increment to the next entry instead of code doing a random selection every time. And you don't have to write the entire list, just enough entries to last until the next cycle (60 min or whatever).
And (yes, another one
this can be done asynchronously in the background to minimize CPU impact.
Even with a smaller image library this will save huge CPU time. And you can probably get rid of the use-less-memory option too.
Just some thoughts.
And I agree with Rick that DF rocks. And with the improvements you've already made I think it's one of the best multi-monitor wallpaper programs out there.