![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Аналог ACDSee по скорости [D7, WinXP]
Ландграф Павел © (2005-05-11 21:16:00)вобщем делаю сабж, но не "чтобы было", меня ACDSee полностью устраивает, а делаю типа фотоальбома где будут различные разделы, в том числе и ХХХ где надо ставить пароль и кодировать картинки, но енто все вступление.
Теперь вопрос=) в каталоге более 100 jpeg`ов высоких разрешений, и загрузка каждой фоты около 1~2сек, что напрягает, кешировать не получается, сдуру сделал кеширование 30 фоток, дык енто дело заняло 2 гб оперативки=) Можно конечное кешировать след. и предыдущую картинку по списку в потоке, но а если я захочу тыкнуть не на следующую по списку, а на последнюю, тогда смысл ентого кеширования будет полезен тока в режиме слайд-шоу, но как же сделать быструю загрузку как в ACDSee, вывод делаю через directdraw, так что все упирается в быстрой загрузке текстуры... мож какой юнит jpeg на асме есть?
Ландграф Павел (2005-05-14 17:05:00) [1]попробую, мож правда тормоза из-за долгого доступа к винту...
Deka (2005-05-13 11:15:00) [2]Я тут подумал что нет необходимости хранить JPEG высокого разрешения весь в памяти. Можно хранить его копию адаптированную под разрешение (размеры) экрана конкретного монитора. Это еще экономия памяти. Миниатюры можно хранить как в самом JPEG-файле (формат это позволяет, правда там кажется размеры ограничены) так и в именованных каналах файла (кажется эта фишка NTFS так называется).
Sapersky (2005-05-13 11:10:00) [3]Берём в лапки ASM и описание формата JPEG. И вперёд с песней!
Есть уже... Intel Jpeg Library называется.
XProger (2005-05-13 03:01:00) [4]Ландграф Павел,
Берём в лапки ASM и описание формата JPEG. И вперёд с песней! Если обгонишь по скорости ACDSee - вечная тебе память в сердцах любителей XXX ;)
programania (2005-05-12 19:44:00) [5]Для ускорения загрузки Jpeg можно использовать
TJPEGScale = (jsFullSize, jsHalf, jsQuarter, jsEighth);
грузить сначала не jsFullSize и показывать все равно большая картинка в экран не влезет,
а потом jsFullSize уже незаметно пока что-то не нажмут
и вначале делать масштабирование не качественно но быстро, а потом уже улучшено
Это заметно и в ACDSee когда картинка через секунду после показа вдруг как-то хорошеет
и все что загружено кешировать в памяти в виде миниатюр
для повторного быстрого некачественного показа и даже сбрасывать на диск или пристраивать к оригиналу.
Это и ACDsee делает когда открывает новую папку, то долго работает с диском
и создает какую-то базу, зато потом быстро открывает и показывает.
Но на современном компьютере С2.8 даже без всех этих ухищрений
картинки в 2500*2000 1.5-2mb показываются меньше чем за 1 сек. со сглаживанием и во весь экран
а с ухищрениями вообще десятые доли,
за это время человек и не заметит что ему подсунули jsEighth и stretchDraw,
а пока рассмотрит уже можно успеть и качественно.
>какой есть алгоритм чтобы сгладить не с сильным размазыванием, но и быстрый
по-моему алгоритмов 2: для уменьшения усреднять несколько исходных пикселов
а при увеличении складывать из четырех пропорционально
Ландграф Павел (2005-05-12 17:12:00) [6]Да, именно так, так-с..
Тада открываем каталог, запускаем поток, который будет все jpeg`и грузить в память, если их более 100 процедура будет не из быстрых, тада как сделать если открыли каталог и ткнули на последний jpeg в списке, который еще не успел прогрузиться, ведь в ACDsee нет никаких табличек "подождите", хотя можно блокировать скрул со списком файлов до того места где мы успели загрузить... пожалуй так и попробую...
Кстати, в ACDSee если нажать refresh на открытой картинке, то он ее аккуратненько сглаживает (если она открыта в уменьшеном масштабе), какой есть алгоритм чтобы сгладить не с сильным размазыванием, но и быстрый?
Deka (2005-05-12 11:32:00) [7]Меньший объем загрузится быстрее - поэтому JPEG. Скорость памяти гораздо выше скорости диска - поэтому хранить в памяти JPEG, а не Bitmap из него полученный. А ACDsee на этом-же фотоальбоме работает так как ты хочешь? Щелкаешь любую картинку и она мгновенно ее разворачивает на экран?
Ландграф Павел (2005-05-11 21:53:00) [8]>Jpeg хранится в памяти так, как захочет программист.
Я имел ввиду в виде загруженных текстур, а текстуры в directdraw хранятся битовой матрицей, конечное есть всякие аппаратные сжатия, но енто уже лишнее в этой задаче.
А хранить jpeg в памяти енто ничего не даст, ибо надо еще раскодировать и загрузить...
>Кешировать имеет смысл только уменьшенные копии изображений
я это и сам знаю, но пытался решить свою проблему разными способами... ты кстати уходишь от вопроса, не знаешь - так и скажи, нечего меня разводить на "левые" выяснения...
Gero (2005-05-11 21:44:00) [9]
> jpeg в памяти хранится как битовый образ
Jpeg хранится в памяти так, как захочет программист.
> а смысл кешировать на диске?
Кешировать имеет смысл только уменьшенные копии изображений.
Ландграф Павел (2005-05-11 21:34:00) [10]jpeg в памяти хранится как битовый образ, т.е. те самые 70 мегов!
а смысл кешировать на диске? перегонять в bmp что ли и сохранять для того чтобы не перегонять постоянно из jpeg в bmp?! дык енто глупо, и размеры таких кеш файлов будут как и в памяти по несколько гигов...
Gero (2005-05-11 21:20:00) [11]
> сдуру сделал кеширование 30 фоток, дык енто дело заняло
> 2 гб оперативки
У тебя, что по картинки по 70 мб?
А вобще кешировать на диске нужно, а не в памяти.