Скорость чтения графических форматов

[vitaly_l]

Написал полезную утилиту... И обратил внимание на факт что, изображения 3000х2000 px - грузятся примерно одну или полторы секунды, в то время как, например в XnView(просмотр изображений) - тоже самое изображение загружается моментально. Размеры графики ~ 10 Мб, формат значения не имеет, все форматы грузятся одинаково долго. Попробовал заменить Timage на TBGRABitmap, TPicture - результат тот же: "грузится долго", а выводится на экран моментально. Загвоздка именно в считывании с диска... Но XnView и другие программки - как-то считывают и делают это моментально...

В чём секрет быстрого считывания графических форматов?


PS: Всех с новым годом!

[vitaly_l]

Ладно... никто не знает секрета быстрого считывания графических файлов... обидно...
Тогда другой вопрос, о графических файлах...

О великие и мудрые программисты! Сжальтесь над несведущим художником
и раскройте ПОЖАЛУЙСТА главный секрет программистов, о нижеследующем:

Есть два Timage, на TPageControl...
Первый Timage расположен на первом Tab в TPageControl, а второй соответственно на втором Tab...
При переключении с первого Tab на второй Tab - изображение сильно мигает(показывает фон TPageControl или Tab),
при этом - оба изображения уже загружены в оба Timage.

Соответственно вопрос: Как убрать мигание Timage при переключении Tab в TPageControl?





.

[xdsl]

Сложно чего-то советовать в отсутствии исходников.

[Padre_Mortius]

Но XnView и другие программки - как-то считывают и делают это моментально...

Хм... Ну не в курсе насчет 10 метровых файлов, а вот 14-ти метровые jpg вполне видно как грузятся и в XnView, и других быстрых просмотрщиках. А уж если кеширование отключить, то вообще видно как прогружается картинка. Подозреваю, что дело то не в отображении, а немного глубже...

[vitaly_l]

Сложно чего-то советовать в отсутствии исходников.

Касаемо кода примера про Tab в приложении 4 кб пример, но он без картинок, чтобы размер приложения был маленький. Картинки в TImage можно вставить любые. Чем больше размер(наверное), тем сильнее будет мерцание при смене табов... Суть в перерисовке, возможно если рисовать прямо на Canvas, то результат будет без моргания.

14-ти метровые jpg вполне видно как грузятся и в XnView, и других быстрых просмотрщиках

Я сравниваю так, загружаю один и тот JPG в XnView и в TImage, или в TBGRABitmap и вижу поразительную разницу по времени - загрузка на порядок медленнее... <=== Это-то и удивило.... решил спросить про секрет. Мудрые программисты всё знают... Скорее всего секрет в считывании с диска... и например в уменьшении изображения... или около того...

Иными словами возможно XnView считывает не весь файл, а только необходимую его часть, но как они это делают?



.

[debi12345]

Иными словами возможно XnView считывает не весь файл,

Может и весь (чтобы сделать превью), но в фоновом (Prefetch) режиме.
А может просто нужно включить двойную буферизацию отрисовки ? В МСЕ она включена по умолчанию, и поэтому никаких задержек и миганий нет (только что проверил на тестовом проекте)- даже с большими картаинками (150 Кб) с режиме автоподгонки. Хотя может это заслуга довольно мощной видяхи (ATI HD6850), не знаю...

Добавлено спустя 17 минут 45 секунд:
Хотя.. вспоминаю полемику в мире QT (накануне версии "4") - когда начала интенсивно внедряться медия и экранные эффекты, прозрачность - и сразу пошел убойный фликер даже на мощных машинах. QT-ники в итоге не нашли иного решения кроме как отказаться от средств операционной системы по отрисовке субконтролов. То есть перешли к одному окну (рисовальному контексту) на всю форму, в отличие от традиционного - где, кроме самой формы, каждый едитбокс, каждая табпэйдж, каждый булеанэдит и т.д. представляют собой окно - что приводит к большим накладным расходам при переключении контекста. В новом решении оставлены по факту только блоковые заливки, пересылки и копирования в пределах контекста (формы) [кажется BitBlt-оперfции] - прекрасно оптимизированные, полнстью проддерживаемые аппаратной акселерацией. Аналогичное QT решение положено и в дизайн MSE* - но этим виджеткитам проще - ведь им не нужно отдавать отрисовуу в ОС для придания луку нативного вида. Так что если дело именно вперключении контекстов, то проблема навернео нерешаемая без хитрстей врорже префетча и т.п., и реально надо смотреть код XnView.

[vitaly_l]

включить двойную буферизацию отрисовки ?

Спасибо... хоть это и не помогло... сделал запрос... прочитал что для включения буферизации достаточно вставить: DoubleBuffered := true; <= и попытался увидеть результат... А потом, когда результат при false|true - был нулевой, всё таки решил пролистать статью до конца... и выяснилось что, там нужно приготовить целый модуль BufferedGraphicsManager... а в другом форуме говорят достаточно только DoubleBuffered := true; а я не вижу разницы между false|true...

Дело точно не в адаптере т.к. в других программах мигания нет. Суть в каких-то настройках, подобных буферизации. Когда переключается с одного таба на другой, перерисовывается экран... Однако ===> вначале почему-то - прорисовывается пустой экран, а потом прорисовывается изображение и поэтому виден дрыжёк, когда табы переключаются. Скорее всего в других программах "рисуют" прямо на канве, без TImage и т.д. <=== Это так?





.

[debi12345]

Скорее всего в других программах "рисуют" прямо на канве, без TImage и т.д. <=== Это так?

Правильно , вся форма = канвас, а виджеты на ней - области этого канваса (а не маленькие канвасики - со своими кистями, контекстами, ). Если так, то это еще одно доказательстов что отдавать в ОС прорисовку элементов форм ( используя нативные графические примитивы этой ОС) даже из благих сображений достижения нативного лука - плохая идея. Хотя решаемая через трюки Я бы на Вашем месте поискал "3д пати компонент" - где все эти трюки уже применены.

Добавлено спустя 27 минут 13 секунд:
Если хотите, то проверьте MSE-вариант http://www.likan.uz/uploads/tabflick.rar на своей видяхе - он рисует на одном канвасе. Файл большой потому, что FPC (2.6.0 с сайта ФПЦ) - без смартлинковых юнитов, плюс картинки включены в сам файл

[vitaly_l]

используя нативные графические примитивы этой ОС

Любое априорное нативное знание - сила.

Посмотрел пример - мерцания нет!
Это то что нужно. Как это делается????!

ПОЖАЛУЙСТА - пример...



.

Добавлено спустя 4 минуты 39 секунд:
Или это без Timage?

он рисует на одном канвасе

Напрямую в канвас...

А у меня там ещё под Timage ScrollBox лежит его тоже нужно убирать и писать свой ScrollBox?


/

[debi12345]

Посмотрел пример - мерцания нет!

Какой пример ? С "likan.uz" ? Он написан на MSE, на Лазурус не переделаешь.

А у меня там ещё под Timage ScrollBox лежит его тоже нужно убирать и писать свой ScrollBox?

А не лень ? Я бы поискал в сети пакет оптимизированных компонентов %)

[vitaly_l]

Он написан на MSE

Всё понял... искренне расстроился... тобишь это баг Лазарус?
MSE (среда визуального программирования) — на FreePascal

Я бы поискал в сети пакет оптимизированных компонентов %)

Очевидно это единственное решение...




/

Добавлено спустя 1 минуту 11 секунд:
PS: Спасибо за информацию.

[debi12345]

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

тобишь это баг Лазарус?

Да не баг, а design-flaw, инспирированный намеренеим поддерживать нативный лук наименьшими усилиями. Хотя под него вроде пилится нативный виджетсет, может быть он одноканвасный

[vitaly_l]

Вопрос чистоты эксперимента

Да. Тоже самое.

design-flaw

Так любой баг можно обозвать: design-flaw...

наименьшими усилиями

Ага... логично... а результат? ==> (Я бы поискал в сети пакет оптимизированных компонентов %))


/

[debi12345]

Ага... логично... а результат?

Ну доверились люди операционке - видимо считая что оптимизация графики есть задача автров ОС (хотя это сомнительно - ОС должна бысто и аппаратно акселированно рисовать на отдельном канвасе, и она это прекрасно делает, используя даже DirectX/OpenGL - а то, что программеры громоздят стэки из канвасов - уже их(программеров) заскоки ). В винде еще более менее, а вот в ЛИнускс с его "сетевый графикой" (=асинхронной отрисовкой отдельных "канвасиков") может быть вообще жуть.

[alexey38]

Еще лет 10-12 назад на Дельфях делали прогу, типа специализированного графического редактора. Компы были тогда Пень1, Пень2, что по современным меркам был полный тормоз. Из того что помню на память, то получалось если делать все классически, то начинались всякие там моргания, поэлементная прорисовка и т.п. Мы тогда сделали примерно следующим образом. Вначале всю свою графику и растры выводили на TMetaFile, т.е. на невизуальный компонент. А затем TMetaFile выводили на TBitMap, т.е. тоже на невизуальный компонент, но с нужным масштабом, нужным сдвигом и т.п. И на саму форму на визуальный компонент, по-моему был TImage или прямо на конву формы выводили уже TBitMap. И все было гладко, быстро и без моргания даже на тем компах.

Суть в том, что 10 МБ JPEG имеет разрешение явно не по разрешению конкретного TImage, и скорее всего при каждой перерисовки происходит повторное масштабирование картинки. Что значить сегодня двойная буферизация не знаю, т.к. давно этой темой не занимался. Может это именно то, что надо.