[Qt] Производительность QGraphicsScene. 200,000 статичных итемов и 1 подвижный.

Если бы этот двигающийся итем можно бы было класть в отдельный индекс... или вообще не включать его в индекс (ведь itemAt и прочее, возвращающее указатель на этот итем, мне не нужно)...

Пока было 2 идеи:

1) Класть этот двигающийся итем во вью. Но я ушёл от этого, т.к. было неудобно.

2) Класть этот двигающийся итем в foreground у сцены. Но это невозможно средствами кьюта, придётся писать хитрые классы ForegroundScene и ForegroundItem, как-то так.

Вот зачем тебе в сцене 200000 неподвижных прямоугольничков? Их просто нарисовать нельзя было?

А вот надо. Каждый итем является блоком, имеющий свои свойства. Вот, если интересно.

Скриншоты.

Для чего мне блоки

Посмотри второй скриншот в первом списке, это прояснит, зачем мне много блоков.

Все равно это не объясняет наличия 200000 объектов на сцене. :)
Блоки ты можешь иметь и боком, делая отрисовку блока на бакграунде. Каждый блок имел бы просто привязку к координатам сцены. Что-то мне подсказывает, что это бы и работало намного быстрее.

Я активно использую фичи сцены, а именно itemAt и itemsAt. Они используют bsp-деревья сцены и всё такое. Переносить блоки из сцены точно не надо. А вот всё, кроме блоков (двигающиеся фигнюшки) — возможно.

Если блоки всегда располагаются по регулярной сетке, то зачем все эти премудрости с индексами и bsp-деревьями для них?

Блоки не обязательно не располагаются по сетке.

Я так понимаю, ты к тому, что если бы располагались, то можно бы было отказаться от индексирования сцены?

> Блоки не обязательно не располагаются по сетке.

не обязательно располагаются.

Блоки не обязательно располагаются по сетке.

На этом скриншоте как раз все по регулярной сетке. Как еще могут располагаться? Если эти блоки неподвижны, то для них лучше иметь специальный индекс, который не будет перестраиваться постоянно.

Скриншот это частность. Может быть так: http://rghost.ru/4104325/image.png

Т.к. модель блоковая, а не сеточная, то это блоки в полном понимании этого слова.

Боженька, хоть тебя и нет, но, пожалуйста, как будет свободное время - убей всех программистов на Qt, особенно тех, которые используют его в качестве 3д-движка. Еще можешь убить всех программистов на PHP и HMTL, но это не обязательно.

при чём тут 3d?

{X,Y,ANOTHER_PARAM} 3 dimension :)

Так ли нужен этот подвижный элемент? Может просто подсвечивать статичный при прохождении курсора над ним?

Там ещё как минимум инструменты (выделение и прочее) есть. Да и подсвечивать по идее тоже не вариант — это привязка (как в автокаде) и она может привязываться к сетке и т.п.

Склоняюсь к перемещению во вью к теперь, ибо дефолтный rubberband в кутях лежит во вью, да и логично это, хоть и неудобно.

Петросян.

а в другом потоке нельзя пересчитывать индексы?

попробуй все неподвижные квадратики засунуть в QGraphicsItemGroup и включить у QGraphicsItemGroup кэширование. тот элемент который перемещаете не добавляй в QGraphicsItemGroup.

> а в другом потоке нельзя пересчитывать индексы?

это фишка Qt, нельзя (да и вряд ли возможно идеологически)

Кстати, я кеширование QGraphicsItem вообще не понимаю... что оно даёт? В доках непонятно.

Используй OpenGL. перестань выносить себе и людям мозг.

QGraphicsScene в плане рисования и с миллионом блоков не тормозит. Индекс айтемов — это другое. Оно нужно для, например, нахождения айтема в данной точке или айтемов в данном прямоугольники. И к графике отношения не имеет.

> попробуй все неподвижные квадратики засунуть в QGraphicsItemGroup и включить у QGraphicsItemGroup кэширование. тот элемент который перемещаете не добавляй в QGraphicsItemGroup.

QGraphicsGroup мне не подходит, ибо оно select и прочее попортит. Сделал иначе: все статичные итемы добавляю как детей одного итема.

Тормозит гораздо меньше теперь. Чуть-чуть подтормаживает при пересчёте индеса, но не так, как раньше. Кеширование не включал.

Спасибо!

p.s.: кстати, тормоза эти забавно проявляются. Пересчёт индекса заметен, только когда динамический итем входит в ту чутверть плоскости, где статичных итемов много.

Вместо того чтобы вызывать QGraphicsItem::paint каждый раз при перерисовке, изображение будет браться из кеша. Допустим ты хочешь сделать ChartItem который рисует график из миллиона точек, ты перегружаешь QGraphicsItem::paint и там обходишь все миллион точек и рисуешь график. После включения кеша, тяжелый ChartItem::paint вызовется один раз(или когда график изменится), а дальше при перерисовке график будет браться из кеша (QPixmapCache - через него кешируются изображения). Тоесть при включенном кеша, painter в функции ChartItem::paint(QPainter * -->painter<--, .....) рисует в QPixmap, который в дальнейшем кешируется, и этот же закешированный QPixmap в дальнейшем используется для рисование графика. Если же в данном случае не включить кеш, то при каждом чихе будет вызыватся тяжелый ChartItem::paint().

PS: Вроде ничего не напутал.

Спасибо за пояснение. Но нарисовать прямоугольник быстрее, чем подгрузить и нарисовать битмап кеша, разве нет?

Что касается скорости рисования, то тут такая проблема и не стоит. Всё рисуется очень быстро, если использовать -graphycssystem raster. А вот индексы сцены иногда мешаются.

Короче, вот так сделаю:

1) статичные итемы надо делать дочками некого итема-контейнера. Не знаю, почему, но это заметно повышает производительность не только setPos у динамичного итема, но и скорость работы индексов сцены вообще.

2) динамичный итем выношу во вью... ну то есть считать его позицию всё так же будет сцена, но отрисовываться он будет во вью.

>Спасибо за пояснение. Но нарисовать прямоугольник быстрее, чем подгрузить и нарисовать битмап кеша, разве нет?

Сейчас посмотрел исходники QGraphicsItemGroup, и действительно включение кеша у QGraphicsItemGroup, похоже ничего бы не дало. Я думал что QGraphicsItemGroup::paint обходит все элементы группы, и у каждого вызывает функцию paint, но это не так.

Вот выдрал важный момент:
QGraphicsItemGroup::addToGroup(QGraphicsItem * item)
{
....
item->setParentItem(this)
....
}

статичные итемы надо делать дочками некого итема-контейнера

  (DynItem                        CollectItem) <- BspTree_1
  /   |   \                      /    |     \
(It1  It2  It3) <- BspTree_2   (It1  It2   It3) <- BspTree_3
                                     /  \
                                   (It1  It2) <- BspTree_4

Короче для каждго уровня итемов (в иерархии итемов) создается отдельное Bsp дерево. А так как на верху иерархии у тебя всего лишь 2 итема то при перемещщении DynItem и дерево пересчитывается быстро. Раньше на одном уровне иерархии у тебя было очень много итемов.

То есть если я 100000 итемов разобью на 10 итемов-контейнеров, то оно должно ещё шустрее быть?

>То есть если я 100000 итемов разобью на 10 итемов-контейнеров, то оно должно ещё шустрее быть?

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

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

Я сейчас так сделал: добавил в сцену addItems(const QList<QGraphicsItem*>& items) и аналогичный метод для удаления итемов порциями. При добавлении создаётся пустой итем, все итемы в списке делаются его дочками, после чего этот итем добавляется в сцену. При удалении аналогично. Так как удаление-добавление итемов всегда происходит большими порциями, то несколько контейнеров появляется «автоматически».

Наверное, надо будет поэкспериментировать с addItems, возможно надо будет создавать несколько контейнеров, разбивая входной список на несколько частей с лимитом размера. Чтобы сбалансировать bsp-деревья.

> а дальше при перерисовке график будет браться из кеша

Сделали zoom и/или rotate для view и нужно или опять обновлять кэш, или рисовать картинку с zoom/rotate с ухудшением качества. Т.е. фактически такое кэширование работает только для translate view, и только на целое число пикселей (для долей пикселя нужно пересчитывать antialiasing).

оставлю тут несколько линков по теме, чтобы потом их не гуглить опять (пока не читал)

http://thesmithfam.org/blog/2007/02/03/qt-improving-qgraphicsview-performance/

http://www.qtcentre.org/threads/37981-Performance-issue-with-complex-QGraphic...

http://www.qtcentre.org/threads/11096-QGraphicsScene-QGraphicsView-performanc...

http://www.qtcentre.org/threads/29995-QGraphicsScene-with-lots-of-static-items

http://www.qtcentre.org/threads/22145-QGraphicsItem-Creation-Process-slower-s...

Если стандартное кеширование не подходит, то можно в своем Item-e сделать более умное кеширование.