Дорогой alexeis1, отвечаю на твои ИМХО.
По поводу "не задумывались ли вы" - задумывались. Я все проекты, а этот тем более тестирую на самых слабых кофигурациях. К примеру:
Ноутбук: 650Mhz, 128 озу XP SP2, ATI RAGE MOBILE (BELL), дрова не поставлены на видео. Результат по скорости на глаз одинаков, НО стандартная отрисовка глючит (визуально) - при перемещении дуратские полосы появляются - не успевает отрисовывать. С OpenGL всё отлично, плюс ещё и сглаживание.
На компах быстрее этого (стационарных уже) разницы никакой вообще нет. И это при всём при том что в OGL ещё и сглаживание есть, если его включить в стандартной отрисовке - она тормозит, но это понятно и так. Тестил именно на офисных компах, с интегрячим видео.

На счёт  и : я уже писал, что юзаю стандартный модуль openGL.pas от дельфи 7. Если ты посмотришь в него, то увидишь что это перевод сёвого заголовочного файла образца 1993 года, т.е. я использую только стандартные функции, рисую через glBegin/glEnd, никаких буферов, никаких расширений - только примитивные фунции. Так что можно уже сказать что любая софтварная эмуляция OpenGL отлично справится с отрисовкой, и если возникнут проблемы - то на PCIных карточках и если винда ниже 2000 - 95 или 98 - там да, после установки игра может внаглую заменить opengl32.dll своим файликом, но это я уже такие дебри гипотез строю, что не имеет смысла продолжать.

Резюмирую: я использую только стандартные функции отрисовки, которые реализованы в железе на любой видюхе у которой есть хоть какой-то ускоритель (не важно какой, хоть 3D хоть 2D) и будут нормально отрабатывать на винде от 98 (в 95 по дефолту opengl32.dll нет, нужно самому ставить).

В любом случае, если довести до ума - вынести всё в отдельный отрисовщик - то метод отрисовки можно будет переключать на лету - пусть юзер сам смотрит что у него быстрее работает.



Я эту понял твою мысль ещё с первого твоего поста  Зааметь: о том что я собираюсь стрелять по птичкам с гаубицы я предупредил с самого начала 
У тебя какое-то однобокое представление об OpenGL, типа OpenGL=GAMES. Не забывай, это изначально промышленный стандарт. С помощью него очень удобно рисовать графические примитивы, к тому же ещё и ускорение от железа получаем. Для интереса глянь код что я добавил - его минимум. Это действительно удобная штука, работать с ним одно удоводьствие, размер программы он никаким боком не увеличивает, ибо opengl.pas - это заголовочный файл, скорость работы OpenGL - см тест я в начале привёл, баги и прочая радость - я использую только стандартные, первородные функции, очень сомневаюсь что они хоть где-то будут глючить.


s-mike, 

Ок, простой пример и ты всё поймёшь: создай картинку-чекер - разлинованная в черно/белую клетку картинка. Сделай зум, скажем в 300% - и подёргай ширину/высоту компонента - увидишь (если сразу не увидел) искажения. Потом возьми мой компонент, сделай то же самое - искажений нет. Эти искажения из-за того что ClientWidth компонента не кратен ширине изображения после зума.

Добавлено @ 17:13 
Да, забыл сказать, даже если OpenGL будет эмулироваться - скорость будет такой же как у стандартной отрисовки, т.к. эмуляция идёт средствами того же GDI.

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

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


Ну с этого и надо было начинать.

А я кажется понял в чем проблема ;) Там небольшой баг, не выставляется halftone-сглаживание для StretchBlt. Его нужно вручную выбрать в комбобоксе Stretch Method (либо в свойствах самого компонента в design-time), тогда все будет отлично и со сглаживанием ;)

s-mike, 

Да, надо же, не знал про этот компонент раньше. Пришлось писать свой "image на ScrollBox"...

Сейчас посмотрю, но на всякий случай сразу предложение:
св-ва
"Умещать картинку"
"Умещать только картинку, бОльшую размера комп-та" (не трогать меньшую)
"Центрировать картинку" (для картинок, ментших размера комп-та)

Я у себя это реализовал, но не помешает и здесь, если потом надумаю этот комопнент использовать...

s-mike

"тогда все будет отлично и со сглаживанием " и с тормозами, незабывай.
И это - совсем не выход. Сглаживанием ты спрятал косяк. Выход - как сделал я - правильно рассчитал размеры. И меня в этом вопросе не переспорить. Я же говорю - ты пошел по быстрому пути - натянул на окно вывода изображение. Отсюда и глюки. А надо натягивать на виртуальное окно - которое по размерам чуть больше окна компонента (или чуть меньше) - его размеры должны рассчитываться исходя из зума и размеров окна компонента, чтобы остаток от деления ширины/высоты на велечину зума был нулевым.


Alexeyt, 

Да, ага, все кинулись дописывать, чтобы МОЖЕТ БЫТЬ, КОГДА НИБУДЬ, дорогой Alexeyt заюзал компонент :-D
А серьёзно - это всё есть в этом мегакомпоненте, ищи лучше.

Пробую демо:

1. при уменьшении картинки (уменьшении масштаба меньше 100%) картинка (jpeg) идет какими-то квадратиками. Отчего это? Система Win XP SP2.

2. Опция AutoCenter что должна делать - центрировать картинку? И без нее все центрируется, а с ней инчего не меняется...

3. Ту опцию которая "may hang" я бы вообще запретил. 
Т.е. использовать бы не стал - на каком-то железе может зависнуть, зачем это нужно.

4. Не хвататет опции "ресемплинг такой-то". Как в IrfanView, там где-то 4-6 вариантов фильтра ресайза (правильно я понимаю, что это и есть ресемплинг?)

А так комопнент неплохой, нужный...


Coriolis


Спасибо, буду смотреть. 


Это сообщение отредактировал(а) Alexeyt - 31.1.2007, 19:34

Писал выше. Поставь в комбобоксе halftone сглаживание.


Опция влияет только на центрирование изображений, которые по размерам больше клиентской области компонента.


Железо тут причем? Зависит от реализации компонента для работы с конкретным графическим форматом. С TJpegImage работает. А вот с TRxGifImage не работает, зависает. Разбираться не было времени, подозреваю, что класс-декодер (как и в случае с TBitmap) просто не генерирует событие OnProgress. Узнать программно об этом невозможно, поэтому я и сделал предупреждение.


Насчет ресемплинга: смотри выше про halftone.

Это сообщение отредактировал(а) s-mike - 31.1.2007, 19:54

А тормоза причем тут к неверной отрисовке? Я написал, почему изображение может неправильно отрисовываться. Это во-первых.

А во-вторых я не понимаю, чем твой "быстрый и более грамотный" метод отрисовки отличается от ничуть не менее быстрого COLORONCOLOR, то есть простой Stretch? Как его можно сравнивать с HALFTONE? Взгляни сам на разницу:
http://smike.drkb.ru/temp/OpenGL.png
http://smike.drkb.ru/temp/Halftone.png
http://smike.drkb.ru/temp/Stretch.png

Что касается грамотности. Возможно для OpenGL хранение смасштабированной текстуры изображения и является грамотным подходом. Но не забывай, что для хранения текстуры размером 2048x2048 потребуется более 4 мегабайт памяти. Твой вариант программы с изображением размером 2976x1952 в BMP формате масштабом 410% занимает в памяти более чем 80 мегабайт оперативной памяти и столько же виртуальной. В то время как мой вариант занимает более чем в 2 раза меньше (40 оперативной и 35 виртуальной). Поэтому я не исключаю твоего варианта, но я не считаю, что он самый грамотный и оправдан в любых ситуациях (особенно в случае ограниченного количества оперативной памяти). Они оба имеют право на жизнь и использовать нужно тот, который более оптимален в конкретной задаче.

Это сообщение отредактировал(а) s-mike - 31.1.2007, 20:26

s-mike, 


Ясно. Хотя лучше бы влияла на любой случай (и бОльшие, и меньшие картинки). Напр.: видел в Тотал Коммандере 7 опицю "Центрировать изображение"? Она на все размеры влияет...

С halftone ясно.

А прикрутить другие фильтры ресайза можно?
Я про IrfanView.

Возможно, не задумывался как-то. Возможно учту.


В IrfanView при просмотре изображение тоже halftone-ом масштабируется. Дело в том, что "прикрутить" не такая уж и проблема (даже событие есть для этого), только не лучшим способом это скажется на производительности. Все-таки нужно различать фильтры для просмотра и для качественного уменьшения картинок.

Есть у компонента англ. страница/описание? Финскому товарищу показать, он как раз просмотр картинок делает, мучается с TImage...

Пока нет.

А почему в демо нет (или есть, я не вижу?) опции рендера через DirectX/OpenGL?
На скринах, выложенных в теме, рендерится через OGL, как это повторить?

Потому что тему читать нужно 
http://forum.vingrad.ru/index.php?showtopi...st&p=957000