This /was/ going to be a report about how the two photos linked below were causing me 100% CPU usage when their thumbnails were onscreen.

http://www.geekport.com/files/sf-wadesnow.jpg
http://www.geekport.com/files/walt_concept_map.jpg

Scrolling those particular image thumbnails offscreen and the CPU went back to normal. However as I was writing the report I noticed that zooming made f-spot happy and the CPU return to idle.

You should be able to reproduce this but importing one of those images, giving it a unique tag and search on that tag so it's thumbnail is being viewed alone. If you aren't getting high CPU usage already, if you adjust the zoom to certain points -- usually at the exact point after the padding recalculates and the image quickly jumps to a new size -- the CPU will spike.

So a lot of --trace and WriteLines later, i've determined that there are some unlucky pixel ratio images that at certain sizes don't produce a thumbnail at exactly the size IconView wants, it's -- at those particular zoom points -- one pixel too small. IconView redraws, sees the thumbnail (still) needs updating because of the size difference, and re-requests it. Again and again. Infinite loop!

My newness to f-spot and C# means I am not sure on the best way to avoid this loop. Maybe someone can look at that section of code in IconView again to see if there is someplace else this needs to be fixed, but what I did is add two additional conditions to check for the thumbnail only being 1px too small.

Feedback welcome and let me know if I need to rephrase the steps to reproduce.