LINUX.ORG.RU

Кто знает, как в GTK, или в других тулкитах, реализована прокрутка списков?


0

3

Возьмем, скажем, виджет многоколоночного списка (в разных тулкитах он по разному зовется, но это не суть). При прокрутке,вероятно, логичнее всего отображаемую во вьюпорте часть картинки сдвинуть путем простого копирования пиксмапа. Новую часть списка, которая при прокрутке появляется, надо отрисовать. Самая затратная по времени операция - это отрисовка текста. Если список большой, а окно «распахнуто» широко, то при интенсивной прокрутке на компе с квелым процессором и видео картой (не современном компе) эта отрисовка может тормозить. Однако, даже на убогом компьютере под GTK (GTK в данном случае чисто для примера) списки прокручиваются плавно и без задержек. Это наводит на мысль, что уже готовые куски отрисованных строк списка кэшируются. Но с другой стороны, если список очень большой, то нельзя же его весь закэшировать в пиксмап. И тогда при интенсивной прокрутке мы получаем опять прямую перерисовку кусков текста. В чем может быть секрет? Как думаете?

Кэшируются отрисованные глифы.

fopen ★★
()

А вот интересный факт, список с 200+ строк прокручивается на моём 4х ядерном калькуляторе очень плавно и с GTK(2 и 3) и с Qt(4). Но если выделить все элементы(или большую их часть) то в ГТК начинает _ЖУТКО_ тормозить. Фреймрейт падает до 1к\с(на глаз)

FFSinit ★★
()

Однако, даже на убогом компьютере под GTK (GTK в данном случае чисто для примера) списки прокручиваются плавно и без задержек.

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

waker ★★★★★
()

В чем может быть секрет? Как думаете?

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

waker ★★★★★
()

Все оказалось несколько иначе, нежели мне представлялось. Хм ... Еще малость поэкспериментирую и отпишусь.

zloy_starper ★★★
() автор топика

а еще я как-то видел (в исходниках гтк) как функция списка length (или size) проходила все элементы

это так надо и я идиот, да?

unt1tled ★★★★
()
Ответ на: комментарий от unt1tled

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

anonymous
()

GTK не стал смотреть. Поковырял я FOX toolkit. Xfe работает на моем престарелом ноутбуке шустрее, чем соответствующие GTK-ые программулины. Нет там никакой буферизации, а все рисуется сразу в окно. Как оказалось, в FOX по умолчанию текст отрисовывается через Xft. Сделал тест на эту тему. Оказалось, что вывод текста через Xft на порядок быстрее, чем XLFD (XmbDrawString & etc). Вероятно, Xft кэширует пиксмапы глифов более эффективно. По крайней мере больше ничем я это объяснить не могу. Motif рисует текст еще медленнее. Но даже в нем Xft-текст рисуется быстрее, чем напрямую посредством XmbDrawString. Кстати, на моем ноутбуке GTK-я прокрутка тоже подтормаживает, просто это не так бросается в глаза. А вот FOX летает. Подозреваю, что FOX не может рисовать bidirectional text, соответственно не тратит время на разбор строк, как GTK.

И вот еще странность. На компе с Core i5 и видео Nvidia тормоза под GTK заметны. А рядом комп с Core 2 E2700 и тоже Nvidia все «летает» хоть FOX, хоть GTK, хоть Motif, хоть Xlib. Драйвера у обоих открытые.

zloy_starper ★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.