Уже не раз говорилось:
Ты наверняка не следовал этому правилу.

Потому и происходит подвисание из-за загрузки картинок не во второстепенном, а в главном потоке.

Объект сцены создаётся в основном потоке и photoReady пересылается на него. Объект-наследник QGraphicsPixmapItem (который выше известен как ThumbnailItem) создаётся именно там. Во второстепенном потоке его создавать нельзя (понятно,почему). Создаётся он изначально без картинки и просто добавляется на сцену. Пересылка в основной поток объектов QImage проблем и зависаний не вызывает. А загрузка их происходит во второстепенном потоке (поток2).



Двухсторонне информирование это типа отправил N фоток (а как определить это N) и уснул либо на M мсек (а как его определить?), либо до тех пор, пока основной поток не сообщит, что снова готов принимать?
А можно как-то оценить (определить,вычислить), сколько событий может обработать поток в заданный промежуток времени?

Вычислять ничего не надо.
Например, можно попробовать так:
AlbumLoader лочит мьютекс и готовит один ряд эскизов, после этого освобождает мьютекс и посылает сигнал "Блок картинок готов".
Главный поток, после получения сигнала, лочит тот же мьютекс и начинает добавлять эскизы в сцену, после освобождает мьютекс.
Т.е. пока мьютекс залочен в главном потоке (добавляются картинки на сцену), второй будет ожидать завершение этого процесса.

Спс, интересно,надо попробовать))
Но всё-таки надо же как-то оценивать количество картинок, которое должно быть в блоке....А если удастся получить такую оценку, то можно просто усыплять поток на некоторое время через каждые N отправленных photoReady

Ты попробуй: один ряд, три ряда, все видимые, ...

Небольшая поправочка:
Наверное лучше не блокировать поток AlbumLoaderThread на все время добавления картинок на сцену, пусть он создает объекты PhotoData, а когда их наберется на новый блок, лочить мьютекс, добавлять в коллекцию, освобождает мьютекс и отсылает сигнал.

по опыту пользования смотрелок, как пользователь, я рассудил бы так:
процесс загрузки миниатюр, для картинок, должен быть паралелен, т.к. я могу в сотый раз в ходить в один и тот же каталог и зарание знать, что именно мне надо и где это примерно находится (сколько прокрутить линейку прокрутки в случае большого числа файлов). И я хочу иметь быструю навигацию (это не значит, что я хочу быстро увидеть все миниатюры).
Предположим, что я хочу попасть в такую точку в дереве:

\
|--folder_1
|     |--folder_2
|     |     |--file_2_1
|     |     .
|     |     .
|     |     .
|     |     |--file_2_105   -- Эту картинку хочу!
|     |     .
|     |     .
|     |     .
|     |     |--file_2_1305
|     |--file_1
|     .
|     .
|     .
|     |--file_1200

здесь видно, что я сначало вхожу в каталог folder_1, в котором 1200 файлов (по ним начинает строится миниатюры), а я почти сразу лезу в каталог folder_2, в котором 1305 файлов (по ним тоже начинают строится миниатюры), однако я прокручивю этот список к предпологаемому мету интерисующей меня миниатюры, следовательно процесс построения миниатюр должен иметь некий фокус - что стрить в первую очередь.

Litkevich Yuriy, Такая штука уже имеется - если пользователь прокрутит сцену до места, где картинки ещё не подгрузились, они загружаются в эскиз "форсированно", тупо в paint (у каждого эскиза есть флаг isLoaded, если он false, то подгружается)

Elfinit, нет нужды цитировать все мое сообщение