Наиболее быстро изменить размер Bitmap-а (уменьшить).

← →
DVM © (2006-11-29 13:13) [40]

> Сейчас обнаружил, что скорость StretchBlt с COLORONCOLOR
> имеет не вполне очевидную зависимость от глубины цвета

Ничего себе. А я и не знал.

> Чтоб одновременно всё-всё сравнить, прикрутил FastLIB к
> своему тесту:

Проверил у себя. Результаты такие:

ToScreen:

Stretchblt + 24bpp = 27004
FastLib + 24bpp = 10381

Stretchblt + 32bpp = 6219
FastLib + 24bpp = 8258

← →
Eraser © (2006-11-29 15:36) [41]

> [28] Sapersky (24.11.06 14:57)

> StretchBlt всё равно будет работать по крайней мере отчасти
> софтверно.

любая функция работает отчасти софтверно, а само преобразование картинки на современных видюхах - аппаратное.
насчет StretchBlt, вот тоже тест накатал

program StretchTest; {$APPTYPE CONSOLE} uses SysUtils, Windows, Graphics; const INTER_COUNT = 10; var bmpScreen, bmpDest: TBitmap; I: Integer; dt: TDateTime; begin bmpScreen := TBitmap.Create; bmpDest := TBitmap.Create; bmpScreen.Canvas.Lock; bmpDest.Canvas.Lock; try bmpScreen.Width := GetSystemMetrics(SM_CXSCREEN); bmpScreen.Height := GetSystemMetrics(SM_CYSCREEN); bmpDest.Width := bmpScreen.Width div 2; bmpDest.Height := bmpScreen.Height div 2; bmpScreen.PixelFormat := pf24bit; bmpDest.PixelFormat := pf24bit; // Заполняем bmpScreen рисунком рабочего стола. BitBlt(bmpScreen.Canvas.Handle, 0, 0, bmpScreen.Width, bmpScreen.Height, GetDC(GetDesktopWindow), 0, 0, SRCCOPY); // Тестируем режим COLORONCOLOR. Writeln("COLORONCOLOR mode testing..."); SetStretchBltMode(bmpDest.Canvas.Handle, COLORONCOLOR); SetBrushOrgEx(bmpDest.Canvas.Handle, 0, 0, nil); dt := Now; for I := 0 to INTER_COUNT do begin if not StretchBlt(bmpDest.Canvas.Handle, 0, 0, bmpDest.Width, bmpDest.Height, bmpScreen.Canvas.Handle, 0, 0, bmpScreen.Width, bmpScreen.Height, SRCCOPY) then begin Writeln("StretchBlt fails. Error code #" + IntToStr(GetLastError)); Exit; end; end; dt := Now - dt; Writeln("COLORONCOLOR duration: ", FormatDateTime("nn-ss-zzzz", dt)); bmpDest.SaveToFile("ColorOnColor.bmp"); // Тестируем режим HALFTONE. Writeln("HALFTONE mode testing..."); SetStretchBltMode(bmpDest.Canvas.Handle, HALFTONE); SetBrushOrgEx(bmpDest.Canvas.Handle, 0, 0, nil); dt := Now; for I := 0 to INTER_COUNT do begin if not StretchBlt(bmpDest.Canvas.Handle, 0, 0, bmpDest.Width, bmpDest.Height, bmpScreen.Canvas.Handle, 0, 0, bmpScreen.Width, bmpScreen.Height, SRCCOPY) then begin Writeln("StretchBlt fails. Error code #" + IntToStr(GetLastError)); Exit; end; end; dt := Now - dt; Writeln("HALFTONE duration: ", FormatDateTime("nn-ss-zzzz", dt)); bmpDest.SaveToFile("Halftone.bmp"); Writeln("Press Enter to exit..."); Readln; finally bmpScreen.Canvas.Unlock; bmpDest.Canvas.Unlock; bmpScreen.Free; bmpDest.Free; end; end.
мои результаты
COLORONCOLOR mode testing... COLORONCOLOR duration: 00-00-141 HALFTONE mode testing... HALFTONE duration: 00-00-609

← →
Eraser © (2006-11-29 15:40) [42]

однако здесь нет вывода на экран, в другом приложении, где активно используется вывод на экран, любой режим, отличный от HALFTONE приводит к жутким тормозам и увеличению нагрузки на CPU, возможно это связано с тем, что у сорсового битмапа формат пикселя отличен от экранного.

> [37] DVM © (28.11.06 15:28)

> FastResize не выводит на экран - она с битмапа на битмап
> масштабирует.

открою страшную тайну - StretchBlt тоже не обязана выводить на экран, доступен контекст устройства "битмап" :)

> После результирующий битмап надо BitBlt куда надо.

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

← →
Наиль © (2006-11-29 15:48) [43]

> Stretchblt + 24bpp = 27004
> FastLib + 24bpp = 10381
>
> Stretchblt + 32bpp = 6219
> FastLib + 24bpp = 8258

Я думаю, что вы знакомы со статьёй http://www.delphimaster.ru/articles/pixels/index.html.
Так там, про эту зависмость очень хорошо сказано.
24 битные изображения можно считывать сразу через 4 байтные величины(которые 32 битный процессор обрабатывает быстрее всего) сдвигаясь по 3 байта (метод в FastLib), но тогда можно нарваться на AV. Поэтому, либо считывать, но делать постояную проверку для избегания AV, либо считывать побайтно. При считывании 32 битных изображений мудрить не чего не нужно, поэтому и быстрее.

← →
Sapersky (2006-11-29 17:24) [44]

Зависимость есть, но по FastLIB видно, что при желании негативный эффект от 24 битов можно свести к минимуму:
DVM: 24: 10381; 32: 8258,
У меня: 24: 3188; 32: 2694
А для StretchBlt:
DVM: 24: 27004; 32: 6219
У меня: 24: 14469; 32: 1970
Разница для StretchBlt в 4-7 раз (!).
Это насколько же криво нужно сделать обработку 3 байт, чтобы получить такое торможение?
Отчасти, возможно, дело в том, что FastResize24 никак не преобразует цвета пикселей, просто копирует 3 байтную запись, и компилятор реализует это как копирование word + byte, 2 операции вместо 3-х (см. окно CPU). Но я не думаю, что это такое уж большое преимущество, опять же проблемы с выравниванием.
Что касается выравнивания - пробовал я переписывать FastResize24 на копирование dword"а вместо TFColor. Ускорение если и есть, то весьма незначительное, а иногда вообще нет. Подозреваю, что причина - как раз плохое выравнивание, т.е. этот dword постоянно попадает на границу 4 байтов, и CPU вынужден делать два цикла чтения/записи вместо одного (во избежание этого Delphi, в частности, выравнивает поля записей).

← →
DVM © (2006-11-29 18:33) [45]

> Eraser © (29.11.06 15:36) [41]

COLORONCOLOR mode testing...
COLORONCOLOR duration: 00-00-125
HALFTONE mode testing...
HALFTONE duration: 00-00-531
Press Enter to exit...

1280x1024x32bit (ati x600 winxp)

> Sapersky (29.11.06 17:24) [44]

А что у нас так результаты различаются сильно? Разрешение разное?

← →
Sapersky (2006-11-29 20:32) [46]

Да, там было 800 * 600.
Для 1280 * 1024 * 32:

FastLIB: 24: 9231; 32: 7982
StretchBlt: 24: 42744 32: 5523

Cel2.8, видео - интегрированная i915, Win2k.

> Eraser © (29.11.06 15:36) [41]

171 и 407.
Но это вполне предсказуемо, интересно насколько быстрее (быстрее ли?) HALFTONE при выводе на экран. Попробуй моим тестом, не только StretchBlt/FastLIB, но и DirectDraw (DD Blt - stretch). И напиши какая конфигурация.

← →
Eraser © (2006-11-30 00:22) [47]

> [46] Sapersky (29.11.06 20:32)

твой тест в BDS2006, к сожалению, отказывается компилиться.

← →
Eraser © (2006-11-30 00:31) [48]

насчет версии компилятора подправил, но
Const FormatVars : array[ 0..3 ] of TPixelFormat = (pfDevice, pf8bit, pf24bit, pf32bit); FormatBpps : array[ 0..3 ] of Integer = (4, 1, 3, 4); ... FormatBpps[0] := GetDeviceCaps(DC, BITSPIXEL) shr 3;
как ТАКОЕ вообще у кого-то скомпилилось?

← →
Vovan#2 (2006-11-30 00:41) [49]

Если кому надо:

DD Blt - 191 (4043 mb/s)
(Q: 2004; T: 2005; C: 10494)

GDI BitBlt:
DDB: 198 (3896 mb/s)
(Q: 2002; T: 2002; C: 10099)
8: 348 (554 mb/s)
(Q: 2000; T: 2001; C: 5742)
24: 861 (673 mb/s)
(Q: 2000; T: 2000; C: 2324)
32: 1133 (681 mb/s)
(Q: 2000; T: 2000; C: 1765)

DD Blt - stretch - 849 (5892 mb/s)
(Q: 7159; T: 7160; C: 8437)

GDI StretchBlt:
DDB: 17923 (279 mb/s)
(Q: 2007; T: 2007; C: 112)
8: 4961 (252 mb/s)
(Q: 2004; T: 2003; C: 404)
24: 11743 (319 mb/s)
(Q: 2008; T: 2007; C: 171)
32: 3907 (1280 mb/s)
(Q: 2000; T: 2000; C: 512)
FastLIB:
8: 645 (1938 mb/s)
(Q: 2000; T: 2000; C: 3101)
24: 2388 (1570 mb/s)
(Q: 2001; T: 2001; C: 838)
32: 2563 (1951 mb/s)
(Q: 2001; T: 2001; C: 781)

← →
Eraser © (2006-11-30 00:41) [50]

скомпилил, заменив Const на var...

1280x1024x32, Athlon64 3000+, 1 GB RAM.

DD Blt - stretch - 1512 (3306 mb/s)

GDI StretchBlt:
32: 5680 (880 mb/s)

GDI StretchBlt:
24: 17990 (208 mb/s)

FastLIB:
32: 3720 (1344 mb/s)

FastLIB:
24: 5636 (665 mb/s)

← →
Sapersky (2006-11-30 12:55) [51]

как ТАКОЕ вообще у кого-то скомпилилось?

В D5 типизированные константы по умолчанию можно изменять.
Начиная, вроде, с D6 или 7 - по умолчанию нельзя, но можно включить какой-то опцией компилятора.

Что касается результатов - Filtering (которое и есть HALFTONE) включено или нет? По умолчанию оно выключено, т.к. DVM нужно было без фильтрации.
Конфигурацию просьба писать полностью - CPU, видеокарта, ОС...
Относительно того, что StretchBlt в 24 бит тормозит из-за несовпадения форматов пикселей - попробуй отключить ToScreen (будет выполняться stretch в битмап того же формата), у меня при этом соотношение скорости 24 и 32 то же самое.

← →
antonn © (2006-11-30 14:04) [52]

1152*864, WinXP_SP2, PIV4 3GHz/1Gb/GF7600GT

DD Blt - 348 (7914 mb/s)
(Q: 2014; T: 2013; C: 5784)

GDI BitBlt:
DDB:344 (8014 mb/s)
(Q: 2011; T: 2011; C: 5849)
8:1055 (653 mb/s)
(Q: 2004; T: 2005; C: 1899)
24:3338 (619 mb/s)
(Q: 2003; T: 2002; C: 600)
32:3033 (908 mb/s)
(Q: 2002; T: 2002; C: 660)

DD Blt - stretch - 430 (8835 mb/s)
(Q: 2360; T: 2361; C: 5492)

GDI StretchBlt:
DDB:60823 (62 mb/s)
(Q: 2007; T: 2007; C: 33)
8:54664 (17 mb/s)
(Q: 2023; T: 2024; C: 37)
24:48663 (59 mb/s)
(Q: 2044; T: 2044; C: 42)
32:51366 (74 mb/s)
(Q: 2055; T: 2055; C: 40)

--------------------------------------------------------

1152*864, Vista b.6000, PIV4 3GHz/1Gb/GF7600GT

DD Blt - 600 (5208 mb/s)
(Q: 2001; T: 2000; C: 3333)

GDI BitBlt:
DDB:4304 (726 mb/s)
(Q: 2002; T: 2000; C: 465)
8:4475 (175 mb/s)
(Q: 2005; T: 2016; C: 448)
24:4325 (542 mb/s)
(Q: 2011; T: 2015; C: 465)
32:4289 (729 mb/s)
(Q: 2003; T: 2016; C: 467)

DD Blt - stretch - 510 (7447 mb/s)
(Q: 2000; T: 2000; C: 3923)

GDI StretchBlt:
DDB:55670 (68 mb/s)
(Q: 2004; T: 2000; C: 36)
8:60373 (16 mb/s)
(Q: 2053; T: 2062; C: 34)
24:57654 (49 mb/s)
(Q: 2018; T: 2015; C: 35)
32:57220 (66 mb/s)
(Q: 2003; T: 2000; C: 35)

+ [52] дрова для видео на висте "родные"

> [51] Sapersky (30.11.06 12:55)

причину, по которой у меня HALFTONE намного экономичне и быстрее я понял, на самом деле, HALFTONE действительно медленнее, но в моем случае - намного быстрее - это связано с разным поведением функции при прорисовке в WM_PAINT, к сабжу отношения не имеет )

> [44] Sapersky

> Поэтому, либо считывать, но делать постояную проверку для
> избегания AV, либо считывать побайтно.
Формат храниения дибов в пямяти декларарует длину каждой линнии крутную 4-м байтам, так что как не читай, нарватся не получится. Даже со следующей строчки пиксель не ухватить.

← →
Sapersky (2006-11-30 19:46) [56]

antonn © (30.11.06 14:04) [52]

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

homm © (30.11.06 16:54) [55]
> Поэтому, либо считывать, но делать постояную проверку для
> избегания AV, либо считывать побайтно.

Это не я писал, но отвечу :)
Во-первых, кратная 4-м байтам длина строки не гарантирует наличие "хвоста" в конце скан-линии. Во-вторых, AV поймать сложно ещё и из-за того, что CreateDIBSection выделяет память с запасом, округляет до 4 кб по всей видимости. Но опять же можно "удачно" подгадать с размером и вылететь-таки.
Поэтому меры предосторожности нужны, необязательно постоянная проверка - можно сделать цикл по Width-1 пикселям для dword, а последний скопировать побайтно.
Но всё это неважно, т.к. по моему опыту (см. [44] ещё раз) особого преимущества использование dword не даёт.

> Хотя лучше, наверное, подождать официального релиза и нормальных
> драйверов, и тогда уже делать выводы.

Официальный релиз у меня есть. Драйвера тоже нормальные. Медленнее Vista.

Наиболее быстро изменить размер Bitmap-а (уменьшить). Найти похожие ветки