В архиве вродь версия 2.0   

Нет, там версия 2.1.1. Просто текстовка не поправлена 

Ага, первое впечатление отличное, да...
А когда начинаешь юзать........
В общем багов хватает.
Не, компонент рулезный, но баги... 
Замучался уже. И править всё конкретно лениво - вдруг автор опять за код сядет.
Да, возможность выделения области - было бы супер, сам сейчас это пытаюсь реализовать - столько ньансов...

Так, из последнего:
Прорисовщик компонента FastScroll отображает правую и нижнюю полоску пикселей при зуме только при определённых значениях ширины/высоты компонента. Так как блитом картинка тупо растягивается по ширине/высоте, не учитывая велечины зума. Отсюда же кстати и артефакты зуминга.
Зум - вообще отдельная песня, после того как его меняешь - летит всё. Во первых, зачем-то по умолчанию стоит в качестве рисовальщика метод контейнера с картинкой, после изменения зума устанавливается рисовальщик класса FastScroll. Потом, перестаёт работать кнопка скрола - срабатывает только левая, хотя до зума работает та что в настройках. Ну это примерно понятно почему, тоже поправил, но следствие - не причину(сообщения все поймал в компоненте и обработал).

Да уж, сумбурный пост получился, и негатива много, но компонент всё равно отличный - просто немного довести его надо. Для простейших вещей (для прямого назначения) его хватает за глаза, а вот что-то добавить (выделение области например) - уже баги попадаются.
В любом случае - автору ШПАСИБА и РЕШПЕКТ. 

Должен признать, что реализация у меня получилась весьма мутная. Даже я отказался от его практического использования, поскольку на доводку понадобилось бы слишком много времени. Поэтому решил ограничиться более простой, но намного более надежной реализацией с использованием GDI+. Правда производительностью скроллинга она не отличается. Вот и остается 2 дилемы - производительность либо практичность. FastScrollingImage и написан с целью обеспечить максимальную скорость скроллинга. Но когда необходимо было добавить масштабирование, то в компонент пришлось внести много костылей, чтобы не снизить прежнюю производительность в масштабе 100%.


Делать масштабирование субкомпонента уж слишком накладно

Это сообщение отредактировал(а) s-mike - 18.11.2006, 02:39

ПОДЕЛИСЬ КОДОМ!!! Пожалуйста 
Я тоже всё что добавляю делаю через GDI+


Дак после изменения зума при отрисовке вызывается Paint уже FastScroll'а, в нём примерно та же самая реализация что и в контейнере. Код практически 1:1

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

Кстати, хотелось бы посмотреть на внесенные исправления ;)

Так, я правильно понял - субкомпонент - это имеется в виду твой бипмап контейнер? 
(*стягивает на лоб ушанку и чешет затылок)

Изменения я вышлю тебе мылом, но сам понимаешь - если уж ты признал наличие костылей, то мои доделки даже костылями не назвать...

Намаялся я с проблемой нормальной работы + возможностью выделения прямоугольной области. Третью неделю ковыряю. Не каждый день конечно, но времени потерял много. Эта трабла мне напоминает мелкого и назойливого воробья - так и хочется достать свою любимую крупнокалиберную пушку (DirectX / OpenGL) и расстрелять этого воробья в клочья 

Вот какая идея:
Создаю свой TBitmapContainer, наследуя от твоего. Метод Paint - ф топку, у всех владельцев тоже. В конструкторе этого контейнера создаю thread safe D3DX8 устройство, рендеринг выношу в отдельный тред, ставлю ограничение на макс ФПС в 25 скажем, при Visible - рендеринг идёт, not Visible - рендеринг на паузе.
Сам рендеринг - бесконечный кикл, рендерится квад на весь handle родительского GraphicControl'а, для навигации и зума просто меняю текстурные координаты, если есть рамки - то еще по 4 квада на рамку.
В итоге, что получается:
1) Вся отрисовка переносится на видео, проц на 99% свободен. Даже на оффисном компе будет летать, ибо единственный напряг для проца - переслать несколько байт для обновления текстурных координат и вызов команды драйвера, который в большинстве случаев переадресует вызов на железо.
2) Можно делать красивые анимированные рамки (текстурной анимацией например).
3) Качество сглаживания по прежнему остаётся управляемым, причем железо это сделает по любому быстрее проца.
Минусы:
требование DX8. Восьмой с XP по дефолту идёт, но на машинах с младшими операционками придётся ставить. Можно сделать и на OpenGl - тада DX вообще не нужен будет - gl дрова от видюхи обновляют... Но это всё займёт у меня больше времени чем на DX, я ogl не очень знаю (хотя, для такой простой вещи...).

ВотЪ, такой вариант. Будет ли это работать с твоими конролами? Вот вопрос.

Итак, что сделал:
Во первых, отбросил идею рендеринга в отдельном потоке - не имеет смысла.
Во вторых реализовал задуманное на OpenGL, подключив стандартный дельфийский файл opengl.pas

Сделал через DEFINE - если определено USE_OPENGL - отрисовка идёт через OpenGL.
Все изменения затронули TCustomScrollingImage и TScrollingImage.
В TCustomScrollingImage инициализация OpenGL при создании окна, обновление текстуры.
В TScrollingImage добавил код в процедуру Paint - в случае существования USE_OPENGL используется не канвас с GDIшными блитами, а OpenGL код.
Так же добавил property ZoomFilter (NEAREST, LINEAR) - сглаживание на халяву, как говорится.

С точки зрения конечного пользователя ничего не изменилось (в плане кода). Поэтому просьба к людям, которые использовали ImageControls в проектах опробовать изменённый компонент и отписаться о результате.

Сегодня запустил на работе у товарисча с компом с интегрированным видео - вполне шустро работало, по моему быстрей даже чем через GDI, чего и добивался.

Известные глюки(сейчас над ними работаю):
- переворачивает мелкую картинку.

То, что добавлю в ближайшее время (после борьбы с глюками)
- событие OnGLPaint, в котором юзер сможет отрисовывать что-то поверх картинки gl функциями, рамочки там, и прочую графику.

Предупреждаю, баги компонента я не правил, они все так и остались. Я взял последнюю доступную версию и добавил GL код через DEFINE.
В FastScroll чтобы заработало OpenGL надо после сразу после загрузки картинки сделать
Zoom := 200;
Zoom := 100;
Чтобы включился нужный отрисовщик, это баг не мой - это баг компонента (или фича?.. я так и не понял s-mike).

Вообще, s-mike пропал. Письмо для него назад приходит, на личку не отвечает. Баги бы поправить... Да он мне нужен еще чтобы поставил свой штамп "Одобряю" на коде. ;)

Это сообщение отредактировал(а) Coriolis - 12.12.2006, 12:06

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

Посмотрел пример с OpenGL-ем. Интересная идея, но работает не совсем корректно. И лично я против влезания в сам исходник компонента для добавления не относящейся к нему напрямую функциональности. Предлагаю сделать вывод через OpenGL по другому: наследником. Для этого я переделаю иерархию классов, сделаю в основном классе виртуальные события самой отрисовки, но при этом основной класс будет управлять выводом (что выводить, когда, масштабирование, вывод скроллбаров).

О, а вот и сам разработчик.
На счёт работает некорректно - это был прототип, он должен был показать саму идею, тем более тут лежала старая версия твоих контролов, и я встраивал в старую версию.
Твоя версия так вообще бажила по страшному - мне непонятно почему ты сделал растягивание картинки на область отображения - ведь она при зуминге искажается и "гуляет" при изменении размера компонента. По идее надо расчитывать размер куска отображаемой картинки исходя от зума а не от высоты/ширины компонента. Я в последней версии заколебался уже с этим бороться и сделал свой расчёт этого куска, он без искажений - как во всех нормальных редакторах.

Сейчас я уже утилиту написал с использованием openGL версии, и отловил все баги которыу нашёл.

По поводу того что встраивать в компонент так жёстко нехорошо - согласен на 100%, это совсем некрасиво, но так как тебя небыло, и единственный код который ты предоставил не позволил сделать это безболезненно... Так что сделал как смог. Но ведь работает же 

Выложу сюда на всякий случай последнюю версию компонента с OpenGL, я там дополнительный функционал по отрисовке примитивов (рамки, прямоугольники) вынес в отдельный компонент.

Когда переделаешь иерархию - я напишу OpenGL отрисовщик, будет вообще супер. При проектировании обрати внимание на функцию CreateWnd - там у меня GL инициализируется на хандл окна компонента, поэтому мне как-то надо в отрисовщике тоже самое сделать.

Это сообщение отредактировал(а) Coriolis - 12.12.2006, 13:11

Присоединённый файл ( Кол-во скачиваний: 35 )
 Image_Controls.zip 105,59 Kb

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

  Меня посетила вот такая вот мысля. Насколько я знаю OpenGL хорошо работает только там где установлены драйвера на видюху от производителя, т.е. ATI или NVidia, а вы не задумывалсь, что в офисах или на ноутбуках могут ставить просто дефолтные драйвера, которые "не знают" как эффективно использовать OpenGL в результате вас ждут приличные тормоза из-за процессорной эмуляции. OpenGL не всегда нормально инициализируется на встроенных карточках. Вы что не видели сколько проблем иногда возникает после инсталяции игр. Одна видна нормально запускает другая глючит. Ладно игры там нужно 3D ускорение и без него совсем труба. Но тут же требуется 2D ускорение с которым легко справится стандартный драйвер, тем более, что он то как раз умеет работать с железом видюхи так Microsoft свои технологии поддерживает своими драйверами. Я рекомендую использовать GDI или GDI+. При их правильном использовании можно получить тоже неплохую скорость. Если, что я могу тоже включится в работу.

alexeis1, речь о том и ведётся, чтобы сделать наследника.
Хочешь - через GDI делай, а хошь - через GL.
Что касается скорости - у меня на ноуте видео интегрячее.
Но визуально по скорости отличий не заметил.
Посмотрю дома - с ускорителем.
Там явно GL пошустрее будет работать.

В офисах устанавливают драйвера, а не оставляют дефолтные.
С дефолтными просто задница какая-то, а не работа.
И GL на машинах есть практически всегда.

  Не сказал бы. Возможно так на ATI. Например, хрюша находит для моей старушки GeForce440 mx приличный драйвер, с которым можно отлично работать, и даже в игры играть и при этом никакой разницы практически нет. Аналогичная ситуация с Riva TNT. Для нее вообще при работе на DirectX реализуются все ее апартные возможности, а вот с OpenGL нифига, без драйвера от производителя все будет эмулироваться процом. 


ИМХО на OpenGl - это как из пушки по воробьям.