QGraphicsScene + Изображения + Потоки Опции Подписка на тему Сообщить другу Версия для печати Скачать тему Подписка на этот форум Режимы отображения Древовидный Переключить на: Стандартный Переключить на: Линейный

[Elfinit]

Вобщем, ситуация такая. Прога для создания фотоальбомов.
Основной функциональный элемент - это собсно область просмотра фоток (QGraphicsView, в которую грузится некий наследник QGraphicsScene).
В области отображаются миникопии фоток. Прокрутка, просмотр каждой, одновременное масштабирование всех (как в пикасе например) - это всё более или менее есть.
Проблема в следующем:
Альбомов, само собой, может быть несколько. Ооочень хочется чтобы каждый альбом (хотя бы те первые фотки, которые должны быть сейчас видны) отображались моментально. Что происходит при открытии альбома и как поставлено сейчас:
1. Очищается текущий выбранный альбом (картинки на сцене и некоторые служебные объекта, выграженные из БД). Уже тут - можно ли это выделить в отдельный поток?
2. Запускается поток для загрузки фоток (п1)
3. В п1 из базы запрашиватся фотки выбранного альбома (количество и собственно фотки).
4. В п1 запускается поток п2, который будет заполнять миникопии собственно изображениями.
5. В п1 вычисляются размеры сцены с учётом текущего размера миникопии, количества фоток (строк и столбцов на сцене), размеров окна и т.п., всё это отправлется грубо говоря сцене, типа "на, готовься".
6. В перебираются все строки, полученные из базы, формируются объекты-PhotoData (перечисление свойств и т.п.), сразу после формирования отправляются сцене для формирования заготовки для миникопии (вообще, миникопия на сцене - это некий наследник QGraphicsPixmapItem). В поток п2 отправляется требование создать нужные картинки для миникопии.
7. п2 формирует (точнее, считывает с диска, они уже были созданы при добавлении фоток в альбом) 2 изображения - плохое и хорошее. 2 нужно для быстрого масштабирования, суть не в этом. Формирует значит 2 штуки QImage и отправляет ссылки сцене, типа "вставь в такую-то заготовку".
И так пока не кончается фотки.

Что происходит:
Поскольку формирование "заготовок" (пустых миникопий) происходит очень быстро, пользовательский интерфейс "замораживается" до тех пор, пока не сформируется всё (не успевает "отлипнуть" после очередной). Подгрузка изображений - тут проблем уже не возникает, пользовательский интерфейс доступен и постепенно все заготовки заполняются (как в Windows в режиме "эскизы страниц"). К тому же, на случай, если заготовка стала видна, но ещё не подгружено изображение, оно подгружается "форсированно" основным потоком. Т.о. гарантируется, что первые фотки, которые должны быть сразу видны, будут загружены. Проблема, повторяюсь, в "замораживании" пользовательского интерфейса на время формирования заготовок, разметки сцены. Проблема принципиальна для большого числа фоток. Так, для полутора тысяч заморозка происходит на 7-10 секунд.
Qt не позволяет "ковыряться" в UI из других потоков, поэтому приходится заниматься пересылками данных м/у потоками. К тому же, при получении картинок надо из QImage делать QPixmap, т.к. в дочерних потоках "опасно" работать с QPixmap.

И ещё - для QGraphicsView сделал отрисовку OpenGL, это не сильно ускорило процесс.

Вот как-то так. Для наглядности прилагаю скрин окна.

Эскизы прикрепленных изображений

Уменьшено Р Т‘Р С• 41% 448 x 313 (38.16 килобайт)

 

[ViGOur]

Уже не раз говорилось:

Есть замечательное правило, слот выполняется в том потоке, в котором был создан его объект.

Ты наверняка не следовал этому правилу.

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

[Elfinit]

Уже не раз говорилось:

Есть замечательное правило, слот выполняется в том потоке, в котором был создан его объект.

Ты наверняка не следовал этому правилу.

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

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

Добавил в цикл

msleep(10);

Действительно, успевает отмёзрнуть - менее чем через секунду (причём независимо от размера альбома) всё становится доступным. Но это, по-моему, не совсем элегантное лечение.

Я думаю происходит следующее:
Поток AlbumLoaderThread очень быстро эмитет сигнал photoReady, т.к. сигналы идут между потоками, они превращаются в события, которые кладутся в очередь главного потока. При переключении на главный поток, за отведенное время все эти события не успевают обработаться, после этого происходит опять переключение на поток AlbumLoader и он напихивает очередную партию события и т.д.
Включения msleep улучшает положение, но это не выход, т.к. на некоторых машинах этого времени будет много и поток будет простаивать, а на другой мало и опять получаться тормоза.
Можно попробовать сделать двух стороннее информирование, т.е. AlbumLoader отправил партию картинок и ждет пока главный поток, не сообщит ему, что они все добавлены на сцену.

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

[BRE]

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

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

[Elfinit]

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

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

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