Скачать: CL | DM;

Наиболее быстро изменить размер 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

---

← →
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)

---

← →
antonn ©   (2006-11-30 14:06) [53]

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

---

← →
Eraser ©   (2006-11-30 14:40) [54]

> [51] Sapersky   (30.11.06 12:55)

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

---

← →
homm ©   (2006-11-30 16:54) [55]

> [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 не даёт.

---

← →
DVM ©   (2006-12-01 10:30) [57]

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

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

---

← →
antonn ©   (2006-12-01 23:29) [58]

DVM ©   (01.12.06 10:30) [57]
Официальный релиз у меня есть
RTM 6000? я на нем тестировал

---

Страницы: 1 2 вся ветка

Скачать: CL | DM;



Память: 0.64 MB
Время: 0.015 c