Open atauenis opened 10 years ago
Итак, было опробовано заменить создание виджетов на OnDraw (для справки - override void OnDraw
, это аналог обработчика события Paint в Windows Forms и аналогичных тулкитах). Результат оказался ненамного лучше. И это на примитивнейшем варианте, без иконок, закраски фона, жёстко зашитом размером строки и т.д.. Вероятно, добавление иконок, фона, обработки кликов, переименования файлов и подобного функционала текущего варианта скорость уменьшит до уровня оригинала. Ищутся другие варианты...
Посмотрел на внешние признаки работы листвью в Total Commander (без дизассемблирования). По всей видимости, там применено: 1.) Прямая отрисовка, т.к. win32 window не просматриваются глубже самого "LCLListBox". 2.) Строки не прокручиваются, а перерисовываются. Т.е. на экране всегда одно количество строк, равное количеству вмещающихся, во время прокрутки заменяется их содержимое (по всей видимости, используется многопоточный метод работы, т.к. при быстрой прокрутке не подвисает, а только кратковременно выводит пустоту). Считаю данную архитектуру годной для применения в FC.
Осталось сделать прокрутку перетасовыванием содержимого ListView2Item'ов (сейчас они тупо перемещаются за пределы экрана). Ещё есть проблема с GTK, надо как-то сделать пониже z-index у lv2i, т.к. последние закрывают полосы прокрутки. А z-index в XWT похоже нет )))
Ещё есть момент, что не умещающиеся по длинне надписи закрывают расположенные справа от них.
UPD 23/07: Устранено в 9a70e0a.
Подозреваю, что в tcmd используется виртуализация панели, чтоб не отрисовывать все эелементы (классическая проблема прокручивающихся списков).
Именно так и планируется сделать. Есть массив элементов каталога, FS.DirectoryContent, из которого и нужно брать данные. Затык в том, как грамотнее определить список необходимых для отображения DirItem'ов (окно может менять размер, не пересчитывать же virtual ListView2 при изменении его размера на каждый 1 px).
После #25 производительность LV2 увеличилась в разы. Но большие каталоги загружаются более чем за 1 сек, что неприемлемо. Виртуальный режим всё же необходим.
Решил посмотреть, что можно сделать, пара вопросов:
И еще 1 проблема, возможно, связанная с ListView2 -- при 20000 файлов возникает такая штука: При 10000 ее нет.
И еще 1 проблема, возможно, связанная с ListView2 -- при 20000 файлов возникает такая штука
Похоже, это баг Xwt Table. Кстати, такая же петрушка есть и при 1000 файлов, но через 0,5 секунд всё само расставляется как надо. От Table надо отказываться, хотя бы в пользу Vbox (а лучше на самописный вариант, отрисовывающий кусками по 50-100 файлов, т.е. каждые 0,5 сек. на средней системе).
А сколько времени у вас занимает отрисовка видимой части панели? Надо выносить чтение каталога в отдельный поток, а панель виртуализировать.
998 файлов и папок за 5,592 сек., из которых на парсинг каталога уходит 2,19 сек. 70 файлов и папок 0,39 сек, из которых парсинг 0,276. Т.е. основная проблема именно в отрисовке. Как я уже писал, надо избавляться от Table. Замена ему должна уметь размещать виджеты произвольно по сетке, т.к. требуется чёткое позиционирование виджетов по двум осям (в перспективе для режима "значки", "эскизы" и т.п.). В прочем, это даже облегчает написание виртуализиции. ;-)
По той статистике что ты указал, на отрисовку уходит от 29% до 61%. И чем больше файлов, тем больше уходит на отрисовку. Но на больших кол-вах файлов и парсинг тормозит - им тоже надо заниматься.
Мне кажется, обе проблемы должен решить виртуальный режим с подгрузкой необходимой части списка файлов напрямую от плагина FS (благо на небольших объёмах входной информации, а они в виртуальном режиме большими быть не могут, текущий метод формирования ListView2Item'ов и их добавления на ListView2 работает удовлетворительно).
Угу, надо реализовать ассинхронную подгрузку, а в ListView2 держать не больше 100 элементов, подгружая их по мере надобности.
Полез реализовывать, но столкнулся с определенной проблемой: при фоновом чтении каталога нельзя (по крайней мере, очевидным мне способом), показывать долю загруженных файлов и директорий. Нормально это выкинуть?
Нет. Пользователь должен видеть, сколько ещё осталось "загрузить" (актуально при чтении больших каталогов через сеть или с дискет).
Проблема в том, что, если я загружаю содержимое папки в фоне, то я не могу предсказать, сколько в ней всего файлов.
Ну, если никак, можете убрать все RaiseProgressChanged и RaiseStatusChanged, чтобы не вылезало уведомление о процессе загрузки. Будут песочные часы, этого достаточно (за 20 лет существования Windows/Total Commander, даже во времена дискет и dial-up, никто не жаловался :-) ).
Похоже, это баг Xwt Table. Кстати, такая же петрушка есть и при 1000 файлов, но через 0,5 секунд всё само расставляется как надо. От Table надо отказываться, хотя бы в пользу Vbox (а лучше на самописный вариант, отрисовывающий кусками по 50-100 файлов, т.е. каждые 0,5 сек. на средней системе).
Займусь этим #28.
На больших каталогах FileListpanel, в основе которого лежит ListView2, ощутимо тормозит. Предположительной причиной является изъян архитектуры ListView2Item, где для каждого дела в HBox добавляется по виджету.