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

← →
DVM © (2006-11-21 10:11) [0]

Как наиболее быстро изменить размер Bitmap-а? Скорость стандартного StretchBlt не совсем устраивает. Можно ли обогнать StretchBlt и если да, то как?
Может кто занимался подобным. Можно ли привлечь для масштабирования SSE, MMX и прочие наборы инструкций? Если кто знает, расскажите как.

← →
clickmaker © (2006-11-21 10:17) [1]

DirectDraw?

← →
KilkennyCat © (2006-11-21 10:21) [2]

TBitmap.Width := ...
TBitmap.Height := ...

← →
DVM © (2006-11-21 10:23) [3]

> KilkennyCat © (21.11.06 10:21) [2]

Это отсечение, а не масштабирование.

← →
DVM © (2006-11-21 10:23) [4]

> clickmaker © (21.11.06 10:17) [1]

DirectDraw, сам по себе как мне кажется скорости не прибавит. Мне нужно просто масштабирование, без вывода на экран. Я с DD знаком мало, там есть функции масштабирования более быстрые, чем StretchBlt? Идеальным бы вариантом оказалось использование аппаратной поддержки со стороны видеоадаптера (он наврняка умеет, такая мощь простаивает). Но как этим воспользоваться?

← →
WondeRu © (2006-11-21 10:26) [5]

http://rsdn.ru/forum/Message.aspx?mid=2201982 тут обсуждается

← →
KilkennyCat © (2006-11-21 10:29) [6]

> Это отсечение, а не масштабирование.

неправда. это
> наиболее быстро изменить размер Bitmap-а?

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

> Идеальным бы вариантом оказалось использование аппаратной
> поддержки со стороны видеоадаптера (он наврняка умеет, такая
> мощь простаивает). Но как этим воспользоваться?

DirectDraw... но не все видеокарты реализуют аппаратный StretchBlt.

← →
DVM © (2006-11-21 10:37) [7]

> неправда. это

Я не смотрел реализацию TBitmap.Width := ... и TBitmap.Height := ... в VCL, но что-то мне подсказывает, что за ними скрывается то же StretchBlt :)
Это вряд ли быстрее.

← →
DVM © (2006-11-21 10:39) [8]

> KilkennyCat © (21.11.06 10:21) [2]

Неправ я. Оказалось чуть-чуть быстрее. Но настолько незначительнее, что овчинка выделки не стоит.

← →
DVM © (2006-11-21 10:44) [9]

> KilkennyCat © (21.11.06 10:21) [2]

Только все же TBitmap.Width := ... и TBitmap.Height := не масштабируют - они обрезают лишнее. :)

← →
Barloggg (2006-11-21 10:51) [10]

из под винды аппаратно ускоренный есть bltfast на прямом WinApi, но масштабирования он не держит.
к тому же там вагон параметров в типе TBltFx с поганой документацией.

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

← →
clickmaker © (2006-11-21 10:51) [11]

> Только все же TBitmap.Width := ... и TBitmap.Height := не
> масштабируют - они обрезают лишнее

если через TImage и включено Strecth, то масштабируют

← →
DVM © (2006-11-21 10:57) [12]

> clickmaker © (21.11.06 10:51) [11]

Не, ни о каком TImage речь не идет. Медленно и тяжеловесно.

> Barloggg (21.11.06 10:51) [10]

> Но если это единичная операция, то загрузка битмапа в поверхность,
> потом масштабирование, потом выгрузка обратно займет столько
> времени, что ни о каком ускорении и речи идти не может

У меня в огромном количестве образуются картинки (получаются по сети). Они не того размера, какой нужен. Размер надо преобразовывать и возможно их отображать потом. Это я так понимаю подпадает под определение "единичные операции"?

← →
atruhin © (2006-11-21 11:46) [13]

Посмотри GraphicEx, там несколько способов масшабирования, может будет быстрее.

← →
Думкин © (2006-11-21 12:12) [14]

> DVM © (21.11.06 10:44) [9]

Но размер они меняют, что и требовалось в сабже.

← →
DVM © (2006-11-21 13:00) [15]

> Но размер они меняют, что и требовалось в сабже.

Буквоедство это. В том же сабже указано StretchBlt. Речь о масштабировании. Русский язык богат и неоднозначен.

← →
Sapersky (2006-11-21 13:39) [16]

StretchBlt требуется с фильтрацией или без?
Если с фильтрацией, FastLIB"овский Bilinear быстрее, хотя и даёт несколько худшее качество (видимо, сам алгоритм проще). Если без (FastResize) - скорость примерно та же, что и у StretchBlt.
Насчёт единичных операций - да, от DDraw в такой ситуации будет мало пользы. Разве что хранить в том размере, который пришёл, и делать stretch непосредственно при выводе.

← →
DVM © (2006-11-21 14:12) [17]

> StretchBlt требуется с фильтрацией или без?

Не фильтрация необязательна.
Т.е.
SetStretchBltMode(Canvas.Handle, COLORONCOLOR); Для StretchBlt

Вобщем я пришел к выводу, что не обогнать StretchBlt.
Попробовал и DrawDibDraw() и INTEL Image Processing Library - все медленнее, чем StretchBlt с COLORONCOLOR;

Результат для 100 повторов на некоторой картинке:

StretchBlt - 281 тиков
DrawDibDraw - 625 тиков (хотя это скорее подготовительные операции)
INTEL Image Processing Library - 844 (тоже подготовка дольше, чем обработка)

← →
DVM © (2006-11-21 14:15) [18]

Для StretchBlt + HALFTONE - 1547 тиков.

← →
Sapersky (2006-11-21 14:47) [19]

Сейчас потестировал - FastResize оказалась быстрее... (когда тестировал в прошлый раз - комп был другой, возможно в этом дело).
http://sourceforge.net/project/showfiles.php?group_id=173551

← →
DVM © (2006-11-21 15:53) [20]

> Sapersky (21.11.06 14:47) [19]

Для FastResize результат - 79 тиков. Однако.

← →
Pavia © (2006-11-22 00:30) [21]

Быстрее всего будет если на ассемблере написать. Немогу точно сказать будетли прирост от MXX и SSE нужно пробовать.

Насчет DDraw не все видео карты поддерживают маштабированный вывод для спрайтов, но можно задействовать 3D рэндринг. Правда скорее всего если боддерживался то виндоус его бы использовал. И можно было бы маштабировать через BitBlt(не помню точно).
Так вот для аппоратного ускорения нужно делать 3D рэндринг использовать Direct3D. Но аппоратный вывод он долгий из за всяких простоев.
Незнаю как в DirectX но в OpenGL есть функция GlFlush для того чтобы была возможность немедленно скинуть результат обработки из видео памяти. Кто то сказал что передача в видео память операция медленная. Это зависет от компьютера если брать AGP8 то 66МГц что в 6 раз медленнее памяти. А если EPCI-16 то 1056МГц что наровне с памятью компьютера.

← →
Eraser © (2006-11-22 01:54) [22]

> [21] Pavia © (22.11.06 00:30)

Стандартная Bit/StretchBlt тоже уже аппаратно-ускоренная на сколько это возможно, получить более быстрый результат проблематично.

← →
DVM © (2006-11-22 10:17) [23]

> Eraser © (22.11.06 01:54) [22]

Обогнать в плане вывода на экран - да вряд ли возможно. Тут BitBlt вне конкуренции. А вот изменение размера у StretchBlt сделано не самым быстрым способом. У FastDIB FastResize в 3 раза быстрее. На нем и остановился. Вообще FastDIB удобнее в использовании, чем стандартный TBitmap из VCL. В нем есть все то, чего мне не хватало в TBitmap.

← →
Sapersky (2006-11-22 13:46) [24]

Стандартная Bit/StretchBlt тоже уже аппаратно-ускоренная на сколько это возможно

Аппаратно-ускоренной реализации StretchBlt я ещё не встречал. См. ссылку на rsdn из [5] - там человек пишет, что теоретически её можно ускорить, но практически, по моему опыту, производители драйверов почему-то этого не делают. Для подтверждения опыта я выкладывал пример - хотя скорость он иногда меряет криво, преимущество DirectDraw в stretch по нему видно невооружённым глазом.

Вообще FastDIB удобнее в использовании, чем стандартный TBitmap из VCL

Угу, я уже почти забыл, что такое TBitmap :)
Хотя есть у FastLIB и свои недостатки, слабая устойчивость к ошибкам, например (шаг влево, шаг вправо - AV).

← →
Eraser © (2006-11-23 19:57) [25]

> [24] Sapersky (22.11.06 13:46)

> Аппаратно-ускоренной реализации StretchBlt я ещё не встречал

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

← →
Eraser © (2006-11-23 20:00) [26]

к слову у меня StretchBlt + HALFTONE работает намного быстрее и меньше жрет проц, чем остальные режимы StretchBlt.
почему? сам не знаю.

← →
DVM © (2006-11-24 10:43) [27]

> к слову у меня StretchBlt + HALFTONE работает намного быстрее
> и меньше жрет проц, чем остальные режимы StretchBlt.
> почему? сам не знаю.

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

← →
Sapersky (2006-11-24 14:57) [28]

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

В смысле, они ещё больше будут тормозить, чем с фирменными драйверами? Ну это само собой, но я не о том. Я о том, что какие фирменные драйвера ни ставь, StretchBlt всё равно будет работать по крайней мере отчасти софтверно. Т.е. медленнее surface.Blt.

Хотя вот это:

к слову у меня StretchBlt + HALFTONE работает намного быстрее и меньше жрет проц, чем остальные режимы StretchBlt.

может указывать на то, что чудеса иногда случаются :) Дело в том, что во всех аппаратных реализациях DirectDraw-stretch, которые я видел, HALFTONE прошит намертво и никак не отключается (хотя это не совсем то, что софтверный HALFTONE, качество несколько хуже). Т.е. если HALFTONE быстрее, StretchBlt в этом случае, возможно, работает аппаратно.

Если интересно, можешь проверить это предположение (тест-exe, 160 кб):
http://slil.ru/23461557

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

Может, имелся в виду вывод на экран, т.е. "обратно" не надо. А DDB-битмап, как говорили на rsdn (и это, в общем, подтверждается опытами), может жить в видеопамяти.

← →
DVM © (2006-11-27 10:28) [29]

> Sapersky (24.11.06 14:57) [28]

> Если интересно, можешь проверить это предположение (тест-
> exe, 160 кб):
> http://slil.ru/23461557

А можно исходник данного теста?

← →
Sapersky (2006-11-27 14:26) [30]

http://slil.ru/23476254

← →
DVM © (2006-11-27 15:41) [31]

> Sapersky (27.11.06 14:26) [30]

Спасибо

← →
DVM © (2006-11-27 16:42) [32]

DDraw почти в 3 раза медленне FastDIB из за долгой загрузки Bitmap-a.
Если без загрузки то раз в 5 быстрее.

← →
Дмитрий Белькевич © (2006-11-28 04:08) [33]

>Посмотри GraphicEx, там несколько способов масшабирования, может будет быстрее.

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

Самый быстрый способ:
строится матрица координат, два массива линий получающегося изображения в координатах исходного. Т.е. откуда брать точки из исходного массива.
Дальше идут вложенные циклы по оси х, и у, для каждой линии х и у выбираются согласно предварительно рассчитанным координатам точки из исходного битмапа-сырья.
Скорость очень высокая, mmx/sse здесь не поможет, т.к. считать особо нечего, только пересылки.
Качество, конечно, от скорости страдает, но в моём случае, работая с большими картинками не критично, у меня изображения достаточно монотонные (или как это сказать)? Отбрасывание 3/4 точек почти не заметно.
Есть у них же похожие алгоритмы, но со сглаживанием.

← →
Дмитрий Белькевич © (2006-11-28 04:22) [34]

Посмотрел rsdn:

>В варианте видео->видео DirectDraw, по моим тестам, быстрее GDI в десятки-сотни раз

Здесь тоже, мягко говоря, не всё так просто. Для того, что бы изображение отстретчить, его нужно в видеопамять перегнать, а это процесс. Это хорошо, когда изображение одно, а когда их отстретченных на экране штук 20, и все изначально метров по 40-50, последовательно - agp не выдерживает, параллельно - видеопамяти не напасёшься. Я у себя недавно именно из-за этого второй 2d движок писал. Для мелких изображений всё ок, а вот когда по agp начинаешь гонять гигабайты, тут она и помирает. А хочеться полёта... ;)
Вот и приходится предварительно в обычной памяти масштабировать, а потом уже в видео перикидывать и отображать как есть. Так что, обычный процессор, без gdi и дайректа, может работать не хуже последного. Качество, правда, страдает, видюхи хардварно сглаживают хорошо и быстро, что есть, то есть...

← →
Pent (2006-11-28 15:24) [35]

Где-то у вас ошибка в тесте.. На моем компьютере StretchBlt быстрее, чем FastResize, чуть ли не на порядок. Даже с интерполяцией. Это при условии, что отрисовка происходит сразу на экран, а если на другой Bitmap, то скорости должны быть примерно одинаковыми.

← →
Pent (2006-11-28 15:26) [36]

А использование DirectX не для игр мало когда оправдано, не в последнюю очередь из-за вопросов совместимости имхо.

← →
DVM © (2006-11-28 15:28) [37]

> Pent (28.11.06 15:24) [35]
> Где-то у вас ошибка в тесте.. На моем компьютере StretchBlt
> быстрее, чем FastResize, чуть ли не на порядок. Даже с интерполяцией.
> Это при условии, что отрисовка происходит сразу на экран,
> а если на другой Bitmap, то скорости должны быть примерно
> одинаковыми.

Не верю. :) Что за видеокарта? Какие драйвера, какая ОС?

В каком тесте?

FastResize не выводит на экран - она с битмапа на битмап масштабирует.
После результирующий битмап надо BitBlt куда надо.

← →
Sapersky (2006-11-28 19:50) [38]

Сейчас обнаружил, что скорость StretchBlt с COLORONCOLOR имеет не вполне очевидную зависимость от глубины цвета, 32 bpp в 7-8 раз быстрее чем 24 bpp. А я раньше тестировал 24...
При выводе на экран в таком варианте StretchBlt немного быстрее FastResize, при масштабировании в другой битмап - наоборот.
Чтоб одновременно всё-всё сравнить, прикрутил FastLIB к своему тесту:
http://slil.ru/23483988
(исходник)

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

> Sapersky (28.11.06 19:50) [38]

Прикрути еще DrawDIBDraw из vfw:

procedure DDDraw( Canvas: TCanvas; dTop, dLeft, dHeight, dWidth: Integer; Bitmap: TBitmap); var lpBits : Pointer; pBmpInfo: PBitmapInfo; nColors : Cardinal; hdd : HDRAWDIB; BitmapStream: TMemoryStream; procedure SetSize; var RatioH, RatioW : Extended; begin with pBmpInfo^.bmiHeader do begin if ( biWidth > dWidth ) or ( biHeight > dHeight ) then begin RatioH := dHeight / biHeight; RatioW := dWidth / biWidth; if RatioH > RatioW then RatioH := RatioW; dHeight := Trunc( biHeight * RatioH ); dWidth := Trunc( biWidth * RatioH ); Exit; end; dHeight := biHeight; dWidth := biWidth; end; end; begin if Bitmap = nil then exit; BitmapStream := TMemoryStream.Create; Bitmap.SaveToStream(BitmapStream); pBmpInfo := PBitmapInfo( PChar( BitmapStream.Memory ) + SizeOf(TBitmapFileHeader) ); with pBmpInfo^, bmiHeader do begin if biClrUsed = 1 then nColors := biClrUsed else nColors := ( 1 shl biBitCount ); if biBitCount > 8 then begin lpBits := PChar( @bmiColors ) + Ord( biClrUsed ) + Ord( biCompression = BI_BITFIELDS ) * 3; end else lpBits := PChar( @bmiColors ) + nColors; hdd := DrawDibOpen; try DrawDibRealize( hdd, Canvas.Handle, True ); SetSize; DrawDibDraw( hdd, Canvas.Handle, dLeft, dTop, dWidth, dHeight, PBitmapInfoHeader( @bmiHeader ), lpBits, 0, 0, biWidth, biHeight, DDF_HALFTONE ); finally DrawDibClose( hdd ); end; end; BitmapStream.Free; end;

Еще INTEL Image Processing Library тоже. Будет полезная весчь.

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

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

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

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

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

ToScreen:

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

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

> [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

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

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

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

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

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

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

> 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, в частности, выравнивает поля записей).

> 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). И напиши какая конфигурация.

> [46] Sapersky (29.11.06 20:32)

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

насчет версии компилятора подправил, но
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)

скомпилил, заменив 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 то же самое.

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-а (уменьшить). Найти похожие ветки