Ускорение просмотра дерева GTK

Question

Я пишу приложение для платформы Maemo, используя pygtk, и скорость рендеринга древовидного представления кажется проблемой. Поскольку приложение является медиа-контроллером, я использую анимацию перехода в пользовательском интерфейсе. Эти анимации передвигают элементы управления при перемещении по пользовательскому интерфейсу. Проблема с управлением деревом заключается в том, что он медленный.

Простое перемещение виджета по центру экрана не так уж и медленно, но при экспонировании ячеек частота кадров действительно падает. Что делает это еще более раздражающим, так это то, что если единственная видимая область - это строка заголовка с метками строк, частота кадров остается под контролем.

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

Также есть ли разница между использованием окна просмотра и прокруткой вверх и использованием панели «Макет» и перемещением виджетов вниз? Я бы предположил, что Viewport работает быстрее, но я не увидел реальной разницы, когда попробовал обе версии.

Я понимаю, что это не обязательно то, для чего был создан GTK. Другая альтернатива, которую я пробовал, - это pygame, но я бы предпочел реализацию более высокого уровня, в которой встроена обработка событий на основе виджетов. Кроме того, pygtk имеет преимущество в том, что он работает в Windows и в окне, что облегчает разработку.

Answer 1

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

В PyGTK вы можете использовать gtk.GenericCellRenderer. В вашем рендерере ячеек декоратора сделайте следующее, когда вас попросят отрендерить:

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

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

• если все ячейки уникальны, не так уж и много, как кэширование всего до определенного предела или какая-то стратегия MRU
• если у вас есть какое-то распределение Zipf , то есть некоторые ячейки очень распространены, в то время как другие очень редки, вам следует только кэшировать ячейки с высокой частотой и избавиться от накладных расходов на кэширование для редких ячеек значения.

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

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