И который из них настоящий

Galkov, тот, который больше размером. Старый для сравнения удалять не стал.

------------ Дoбавленo:


У меня идея родилась -- добаить сглаживание, но это тормознет обработку пропорционально коэффициенту сглаживания (от 0 до 4). Все таки программное, а не аппаратное сглаживание. Да и памяти сожрет во столько же раз больше.

nesco, ну оооочень хорошо! Молодец!
Сглаживание, конечно, уменьшит накапливание искажений при повороте уже повёрнутой картинки - не стоит овчинка выделки; даёшь скорость!

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

Человеческим языком расскажи, пожалуйста
Заодно и про "билинейную"

---

BTW: Использование сленга заставляет задумываться о том, что некто хочет показаться крутым
Глупо, и по-детски, ИМХО
Настоящая крутость наступает только тогда, когда у тебя ПОЛНОСТЬЮ пропадает потребность кому-то кем-то показываться

Ну вот, сразу "и по-детски".

Билинейное саживание самое простое -- делается две копии рисунка, но одна смещается по отношению к другой на один пиксель по диагонали, заполнение отсутствующих пикселей происхоит цветом фона (или глубиной альфа-канала). При расчете усредненного цвета пикселя целевой картинки испоьзуется матрица обоих картинок источников, размером 2х2, нечетные -- из первой картинки, четные -- из второй. В квадральной тоже самое, но уже нужно четыре картинки, смещенные по трем диагональным улам, матрица, в данном случе, буде уже 4х4.

------------ Дoбавленo:


Вот последняя версия. Несколько тюнингованная, за счет применения других типов данных и измененного битового копирования; рисунок при кратном повороте (0, 90, 180, 270,360) -- 32-х битный, при повороте -- 24-х битный. Результат -- 39 сек [72 мсек]. Как еще ускорить, и возможно ли это вообще, я уже не знаю.

А по моему, так надо:

сканировать точки НЕ по исходной картинке, а по результирующей, безо всяких там "дурацих пропусков"

если тупо - то просто находить наиболее близкую точку в исходной, и копировать ейные цвета

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

вычисления с плавающей арифметикой на самом внутреннем цикле, и сравнение этих вычислений по скорости, этим самым одним mov-ом - занятие для мазахистов

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

Помог бы откорректировать, особенно первые четыре пункта.

nesco - просто хочу СПАСИБО! , давно была необходимость в этом компоненте, есть некоторые задумки, хочу попробовать...

Да по-моему, после такого:
- надо идеологию менять
И с этого начинать...

У элемента у нутре должно быть две картинки одинакового размера: оригинал, и "повернутая"
Первая может быть св-м, может грузиться методом типа doLoad, не важно, главное, что в процессе работы НИКАКИХ операций с динамической памятью не производить

Один раз загрузил оригинал (создались две картинки)
Тьму раз сказал doRotate: происходит ТОЛЬКО рисование первой, неким хитрым (с размешиванием, или без...) макаром на второй
Вторая картинка может быть на нижней точке: кому надо, тот отрисует (тоже, между прочим, обыкновенный BitBlt безо всякой динамики, условно) этот результат там где ему приспичит: с прозрачностью там, или без...

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

Galkov, я одного понять не могу -- валялся компонент несколько лет в аплоаде, никому нафиг не надо было его переделывать. Только я взялся его немного довести рабочего состояния, как тут же пояаились кучи идей -- как надо и как не надо. Была поставлена задача Леонидом, добиться скорости похожей на Фотошоп, я ее достиг. Хочешь довести до ума, доводи -- я больше, ничего не хочу, тк как нет предела совершенства.

Чего там непонятного

Если не делать, значит другие проблемы есть
Если делать, значит делать хорошо сразу
Потому-что делать его пять раз - опять же и другие проблемы тоже есть

nesco, задачу поставил -=Driver=-, я пытался помочь, но не смог
Galkov, хорошо сразу редко получается, чаще "как всегда"

Насчет скорости задачу поставил не -=Driver=-, сначала была просьба довести до рабочего состояния в новых версиях, а уже потом, появилась задача его ускорить.
А насчет двух картинок, то я не согласен. Возможно, что оригинал и надо держать загруженным, но вот фоновую картинку-то зачем?
В компоненте, полученная картинка выводится наружу, зачем ее еще и отрисовывать на чем-то. А если мне нужна сама картинка, а не ее отрисовка, что тогда? Откуда взялось такое мнение, что графические компоненты непременно должны что-то отрисовывать на экране?

nesco,

Огроменное СПАСИБО !
nescoimage_rotate_1_25 Это что надо, работает быстро и качественно
Повороты поградусно мне не нужны, поэтому я доволен на 100%
СПАСИБО