Мастера DELPHI, Delphi programming community Рейтинг@Mail.ru Титульная страница Поиск, карта сайта Написать письмо 
| Новости |
Новости сайта
Поиск |
Поиск по лучшим сайтам о Delphi
FAQ |
Огромная база часто задаваемых вопросов и, конечно же, ответы к ним ;)
Статьи |
Подборка статей на самые разные темы. Все о DELPHI
Книги |
Новинки книжного рынка
Новости VCL
Обзор свежих компонент со всего мира, по-русски!
|
| Форумы
Здесь вы можете задать свой вопрос и наверняка получите ответ
| ЧАТ |
Место для общения :)
Орешник |
Коллекция курьезных вопросов из форумов
KOL и MCK |
KOL и MCK - Компактные программы на Delphi
Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / rsdn.org

 
Чтобы не потерять эту дискуссию, сделайте закладку « предыдущая ветвь | форум | следующая ветвь »
Страницы: 2 3 4 5 6 7 8 9 10 11 12 13

Быстрый канвас [Delphi, Windows, ХР]


Beermonza ©   (20.08.09 15:49[220]

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

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


antonn ©   (20.08.09 16:36[221]

Вот тут ставили тесты с поворотами: http://forum.vingrad.ru/forum/topic-241113/anchor-entry1734947/0.html
canvas.pixel - 20,66 сек, fps ~5
scanline - 5,43 сек, fps ~18
"массив" - 0,26 сек (с выводом в tbitmap в каждом кадре 0,28-0,29), fps~384

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


Sapersky   (20.08.09 19:29[222]

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


Beermonza ©   (21.08.09 00:08[223]

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


Sapersky   (21.08.09 13:30[224]

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


Beermonza ©   (21.08.09 16:58[225]

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

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

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

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

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


Sapersky   (21.08.09 17:55[226]

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

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


@!!ex ©   (21.08.09 18:31[227]

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

А что мешает?


Beermonza ©   (21.08.09 23:55[228]

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

Вот это безобразие )))
Inc(DWord(Pixels), dx);

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

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

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


antonn ©   (22.08.09 00:01[229]

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


Sapersky   (24.08.09 20:22[230]

Самый быстрый способ в памяти я показал выше, вообще без всего этого поползновения со 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 это исправили, но не факт.


CSS   (26.08.09 07:27[231]

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

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

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

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


antonn ©   (26.08.09 11:57[232]


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

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

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


Beermonza ©   (26.08.09 21:53[233]

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

Я вот так:
t := GetTickCount;

{фрагмент кода}

t := GetTickCount - t;
Label1.Caption := 'Время выполнения: '+IntToStr(t)+' мс';


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


antonn ©   (26.08.09 22:26[234]

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


miek   (12.10.09 22:37[235]

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


antonn ©   (13.10.09 01:19[236]


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

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

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


miek   (13.10.09 08:50[237]

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

да, это я.


MonoLife ©   (13.10.09 10:41[238]


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

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


CSS   (13.10.09 14:12[239]

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

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

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


Страницы: 2 3 4 5 6 7 8 9 10 11 12 13 версия для печати
Обсуждение закрыто


Наверх

  Рейтинг@Mail.ru     Титульная страница Поиск, карта сайта Написать письмо