Разработка собственного ListView

[BOBAH13]

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

1. Делаю свой список, потому что так надо и ненужен мне никакой другой... объяснять не буду
2. Приводить коды пока что ненадо

И так что конкретно меня интерисует, а именно теория...

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

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

Мои варианты решения и очень хочу услышать ваши предложения:

1. Все элементы отрисовывать один раз и хранить их в памяти. Это даст выйгрыш в скорости но даст так же огромную затрату на ОЗУ, что мне кажется не допустимо.

2. Рисуется много, поэтому требуемое время на отрисовку занимает прилично. Вариант мне кажется интересен. Дело даже не в том что отрисовка долго происходит, а в том что например при изменении размеров окна, окно получает WM_SIZE и после вызывается метод Paint а если мы уже рисуем что либо, то пока мы не дорисуем новая отрисовка не начнется. Значит если очень быстро менять размеры то в очереди отрисовки будут приличное кол-во, программа даже может зависнуть на некоторое время.
Мне кажется решением данного варианта было бы каким то образом обрубывать отрисовку и начинать сначала при приходе к примеру WM_SIZE. Но как это реализовать в одном потоке, в голове пока не укладывается.

Пока это все. С нетерпением жду ваших ответов.

p.s. как обычно уже процентов так 80% уверен что тема опять простоит без единого ответа кроме моих но все же из-за уважения к форуму

[mihali4]

Ключевая фраза:

элементов в списке может достигать сколько угодно и поэтому требуется быстрая отрисовка данных

Винда рисует только отображаемое в окошке компонента и перерисовывает при скроллинге или ресайзе компонента. Поэтому никакого разговора о "элементов в списке может достигать сколько угодно" при отрисовке идти не может...
Хранить в памяти проскроленную картинку??? Это явно бредовая идея.

[BOBAH13]

Причем тут ресайз и скроллинг виндовса ? Я ведь пишу все руками свое. НУ да ладно... сделал хранение каждого отрисованного элемента в памяти повыисилась скорость намного, причем память даже не изменилась.. наверное мало элементов. Буду значит совмещать этот метод и гдет за 4 или 3 строки вниз вверх буду уже подготавливать новые картинки для прокрутки...

[evg_m]

Не Хранить в памяти рисунки текста вывода а только список
знать что требуется показывать (попадает в область видимости)
Рисовать на лету то что попадает в область видимости и там где требуется

[Stilet]

сделал хранение каждого отрисованного элемента в памяти

Чет не врубаюсь, а до этого элементы где были?

буду уже подготавливать новые картинки для прокрутки

Какой в этом смысл? Все равно перерисовку видимых элементов делать.

[BOBAH13]

Короче Все ясно... народ без обид.. нашел самый оптимальный вариант...

Stilet - есть вариант что можно не хранить картинки каждого элемента а просто их рисовать в нужный момент.. вот что имелось ввиду...


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

Лучше наверное варианта нет хотя всеравно жду предложений... что из этого вышло ? Смотрим скрин

[Stilet]

Гм. с флагом вроде логично.
Вопрос таков - вот эти твои картинки итемов, это ведь иконки ассоциированные с файлом (папкой)? Тогда я бы проверял если иконка определенного типа уже отрисована а нужно нарисовать еще такую то просто скопировать старую. Это предложение к тому что если будеш вид иконок где-то хранить.
Сам вопрос в том откуда ты изначально получаеш картинки итемов?

[BOBAH13]

Ты не понял... иконки то уже просто сама прога погружает.. а я веду речь о самом компоненте. Просто item хранит иконку + текст ну и флаги там выделения и отрисовки. Так вот.. когда допустим вид установлен в значки - как на первом скрине, то для каждого итема ) нужна область для отрисовки допустим 60х60 пикселей... тогда если флаг не установлен и итем виден на контроле то выделяется эта область в память и там рисуется.. а потом допустим при мелкой прокрутке контрола, итем всеравно остается видимым то вот сейчас уже установлен флаг отрисовки и нет смысла еще раз рисовать а просто скопируем тот самый 60х60 кусок из памяти ))

Иконка для каждого просто прога грузит в итем... ну и текст присваивает. Это ведь простой контрол, ему ненадо ничего знать о том что там прога собирается отображать ))

[Stilet]

Хм. не знаю для чего ты себе такую мороку на голову придумал, но как по мне эта работа особого смысля окромя самообучения не принесет.
Но все равно желаю удачи )

[BOBAH13]

Сообщение от Stilet

Хм. не знаю для чего ты себе такую мороку на голову придумал, но как по мне эта работа особого смысля окромя самообучения не принесет.
Но все равно желаю удачи )

Ты на скрины присмотрись )) я прогу делаю.. замену explorer'a... там все контролы руками рисуются.. т.к. красивей думаю сделать не удасться. Так что я пока расчитываю что буду продавать данный продукт... ну будет видно вообщем