> antonn ©   (20.08.09 00:34) [219]
> это если последовательно перебирать строки, в случае с поворотами там разница раз в 20 будет точно :)

Ой, и не говорите :) ...это просто зверь софтварный.

Вот тут ставили тесты с поворотами: http://forum.vingrad.ru/forum/topic-241113/anchor-entry1734947/0.html


массив - даже без оптимизаций, тот же код что и со scanline, просто "пиксели" заменены на массив, разница в 20 раз =)

Ну сделайте себе копию сканлайнов в массив array of PRGBArray, чтобы обращаться к ним без вызова функции. Должно быть ещё быстрее, т.к. лишних копирований нет.
Про библиотеку с изначально "правильным" сканлайном я уж молчу.

PChar быстрее, я проверял все варианты. С ним можно работать на указателях, что, собственно, и показал в примерах, ...загоняем подряд, берем по указателю на ячейку памяти.

А сканлайн что такое, не указатель? Проблема в том, что у TBitmap получение сканлайна сделано, мягко говоря, неоптимально (см. [99]).

> Sapersky   (21.08.09 13:30) [224]
> А сканлайн что такое, не указатель? Проблема в том, что у TBitmap получение
> сканлайна сделано, мягко говоря, неоптимально (см. [99]).

Я про применение иного типа массива.

> Ну сделайте себе копию сканлайнов в массив array of PRGBArray

А можно ли так же элегантно и быстро "прыгать" по данным как с массивом PChar, просто прибавляя число, соответствующее длине строки?



В этой строчке все, что нужно, без лишних затрат.

А можно ли так же элегантно и быстро "прыгать" по данным как с массивом PChar, просто прибавляя число, соответствующее длине строки?

См. пример [97].
В общем случае ширина строки в битмапе не обязательно равна Width * BytesPP, она округляется до 4 байт, т.е. в конце строки может быть "хвост". Поэтому в начале вычисляется "шаг" между строками dx (данные + возможный "хвост"). И уже с помощью этого шага автор "прыгает" по картинке.
Если у вас всё 32-битное - можно не заморачиваться с "хвостами", ширина уже кратна 4-м.
Разве что с верхом-низом может быть путаница, но это решаемо, во всяком случае мне не сильно мешает.

> [225] Beermonza ©   (21.08.09 16:58)
> А можно ли так же элегантно и быстро "прыгать" по данным
> как с массивом PChar, просто прибавляя число, соответствующее
> длине строки?
> TexPoint := TexPoint + TexLine;

А что мешает?

> @!!ex ©   (21.08.09 18:31) [227]
> А что мешает?

Вот это безобразие )))



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

Я лично себе задал четко вопрос: "мне нужна скорость или не нужна?" , нужна, ...посему не стану делать действия ради действий, иначе какой смысл во всех этих выскребаниях хотя бы 2% прироста скорости кода.

Самый быстрый способ в памяти я показал выше, вообще без всего этого поползновения со ScanLine и шагания по строкам.

попробуй для своего способа выше юзать ММХ, я переделал свои под SSE, оказалось хуже :( видмо придется смотреть как грузануть и можно ли в 128 бит 4 пикселя разом...

Самый быстрый способ в памяти я показал выше, вообще без всего этого поползновения со ScanLine и шагания по строкам.

Переделал пример Антона с вращением под "правильные" сканлайны:
http://narod.ru/disk/12367000000/TBT_li_right_scanline.rar.html
Исключительно для демонстрации "кто виноват", мерянье органами устраивать не собираюсь. Тем более что всё уже написано до нас, FastLib -> FastFX.Transform32, и гораздо лучше, без плавающей точки и Round, да ещё и со сглаживанием есть вариант.

попробуй для своего способа выше юзать ММХ, я переделал свои под SSE, оказалось хуже :( видмо придется смотреть как грузануть и можно ли в 128 бит 4 пикселя разом...

Может, с выравниванием проблемы? SSE нужно на 16, а не на 8.
Ещё здесь:
http://www.tommesani.com/SSE2MMX.html
в самом конце пишут, что на P3-4 128-битный SSE обрабатывает данные "половинками" по 64 бита, и выигрыш можно получить только за счёт большей развёртки циклов. Может быть, на CoreDuo это исправили, но не факт.

Интересно...)

Чтобы сравнивать насколько "Быстрый канвас" быстр надо мерять скорость выполнения кода...
Мой способ на одном из форумов просто обсмеяли... :(

Пока буду пробовать способ из примера Sapersky (пост 230), но хотелось бы услышать чьё-нибудь мнение...
Ну, например, включать ли создание TBitmap в измерение? Насколько точны измерения и сильно ли зависят от "железа"...

Beermonza, antonn, а как вы измеряете скорость "построения" кадра?

> а как вы измеряете скорость "построения" кадра?

тот же самый, что из [230] :)

на каком форуме обсмеяли? :)

> CSS   (26.08.09 07:27) [231]
> Beermonza, antonn, а как вы измеряете скорость "построения" кадра?

Я вот так:



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

и юзать QueryPerformanceCounter для более точных измерений

неверно. так мерять нельзя ни в коем случае.
скорость выполнения меряется как _минимум_ из длительной (100+) серии повторов, выполненной на приоритете time_critical или realtime. qpf/qpc  - да, так точнее.

> неверно. так мерять нельзя ни в коем случае.

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

PS Вы автор spriteutils? приятно видеть, подсмотрел оттуда много чего :)

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

да, это я.

> antonn ©   (13.10.09 01:19) [236]
>
>PS Вы автор spriteutils? приятно видеть, подсмотрел оттуда много чего :)

A вы автор новогодней "кликомании"?

Э... Как-как мерять нельзя?

На максимальных приоритетах ведь получится максимальная скорость... Но это ж вроде всё равно результат на конкретной машине...

А насчёт ''серии повторов'' - я пробовал в цикле делать, но цикл и без ''внутренностей'' много времени съедает... =(