Най-бързият промяна Bitmap-а (намален) размер.
> Това е прекъсване на захранването, а не мащабиране.
вярно. то
> Най-бърз промяна Bitmap-и размер?
и ако промените изображението, то зависи от алгоритъма.
> Вярно. то
Аз не съм погледна TBitmap.Width изпълнение: =. и TBitmap.Height: =. в VCL, но нещо ми подсказва, че зад тях се крие една и съща StretchBlt :)
Това едва ли е по-бързо.
изпод Windows хардуерно-ускорени bltfast трябва да живеем WinAPI, но мащабиране то не държи.
освен там параметри на автомобили в тип TBltFx с гаден документация.
Така че, да, direktdrav. възможно чрез Делфи, тя може да бъде чрез заглавки.
Но ако това е една операция, зареждане на растерна графика в повърхността, а след това я увеличите, след това да качите назад да вземе толкова много време, че за всяко ускорение и реч не може да продължава.
> Само още TBitmap.Width: =. и TBitmap.Height: = не
> Мащабирани - те отсека излишъкът
ако в TImage и приобщаващ Strecth, тогава мащабирани
Виж GraphicEx, има няколко начина masshabirovaniya може да бъде по-бързо.
> Но те се променят размера, както се изисква в субект.
то педантичност. Също така в предмет, посочен StretchBlt. Става въпрос за мащабиране. Руски език е богат и двусмислен.
StretchBlt се изисква с или без филтрация?
Ако филтриране, FastLIB "ovsky Bilinear по-бързо, все пак, и дава някои по-ниско качество (очевидно, самата лесно алгоритъм), ако не (FastResize.) - Скоростта е приблизително същата като тази на StretchBlt.
Що се отнася до отделните операции - да, от DDraw в такава ситуация би било от голяма полза. Е, че в магазина е размерът, който дойде и се простират директно в изхода.
> StretchBlt се изисква с или без филтрация?
Не филтриране не е задължително.
Т.е.
SetStretchBltMode (Canvas.Handle, COLORONCOLOR); за StretchBlt
По принцип, аз стигнах до заключението, че не изпревари StretchBlt.
Опитах се и DrawDibDraw () и INTEL за обработка на изображения библиотека - по-бавно, отколкото с StretchBlt COLORONCOLOR;
Резултати за 100 повторения на една снимка:
StretchBlt - 281 кърлежи
DrawDibDraw - 625 кърлежи (въпреки че това е по-подготвителни операции)
Обработка Библиотека INTEL изображението - 844 (също вече обучение, отколкото лечение)
за StretchBlt # XA0 + полутонално - 1547 кърлежи.
> Sapersky # XA0; (11/21/06 14:47) [19]
Резултати за FastResize - 79 кърлежи. Въпреки това.
Най-бързият начин би било, ако ти пиша на асемблер. Cant каже точно budetli печалби от MXX и SSE на вкус.
Standard Bit / StretchBlt също имат хардуерно ускорение на колкото е възможно повече
Хардуерно ускорена реализация StretchBlt Все още не съм срещал. Вижте линк към rsdn [5] -. Когато човек пише, че на теория е възможно да се ускори, но на практика, в моя опит, шофьори на производителя за някаква причина не го правят. За да потвърдите, опита да публикувам един пример - въпреки че той понякога измерва крива на скоростта, DirectDraw предимство в отсечката от него се вижда с невъоръжено око.
FastDIB обикновено лесни за използване от стандарта на VCL TBitmap
Да, бях почти забравил какво TBitmap :)
Въпреки че има FastLIB и недостатъци, лоша стабилност, например (стъпка вляво, стъпка вдясно - AV).
от начина, по който StretchBlt + Полутоново е много по-бързо и по-малко ядене на сто от StretchBlt на други режими.
Защо? Не знам.
В известен смисъл, те са още по-бавно надолу, отколкото с патентовани шофьори? Е, няма нужда да казвам, но аз не съм за това. Аз, че всички патентовани драйвери или Сложете, StretchBlt ще продължават да работят поне отчасти на софтуера. Т.е. бавно surface.Blt.
от начина, по който StretchBlt + Полутоново е много по-бързо и по-малко ядене на сто от StretchBlt на други режими.
може да означава, че чудеса се случват понякога :) Факт е, че във всички # XA0; хардуерни реализации DirectDraw разтегливост, аз съм виждал, Полутоново зашити плътно и не изключвайте (въпреки че това не е съвсем това, което Полутоново софтуер, малко по-зле на качеството). Т.е. ако Полутоново по-бързо, StretchBlt, в този случай, е възможно да се работи в хардуера.
DDraw почти 3 пъти по-бавно FastDIB поради дългия изтегляне Bitmap-а.
Ако няма натоварване е само на 5-бързо.
> Виж GraphicEx, има няколко начина masshabirovaniya може да бъде по-бързо.
Те имат много добри алгоритми, между другото. Аз препоръчвам. Да си се пренаписват в ръководството за летателна експлоатация прави страхотни снимки.
Най-бързият начин:
матрица на координати, два масива линии полученото изображение в оригиналните координати. Т.е. къде да вземе точка от оригиналния масив.
След това се вложени примки съгласно ос X, и Y, за всеки ред от х и у са избрани съгласно предварително изчислени координати на началната точка на суров растерна графика.
Скоростта е много висока, MMX / SSE не помага тук, тъй като счита нищо особено, просто трансфер.
Качество, разбира се, от скоростта на страдание, но в моя случай, работещи с големи изображения не е от решаващо значение, аз доста монотонен изображение (или как да го кажа)? Отпадането 3/4 точки едва забележим.
Те имат същия алгоритъм, но с анти-псевдоними.
Някъде имате грешка в теста. На моя компютър StretchBlt по-бързо от FastResize, почти един порядък. Дори и с интерполация. Това предполага, че изобразяването става веднага на екрана, а ако друг Bitmap, скоростта трябва да е едно и също.
И използването на DirectX не е за малки игри, когато е оправдано, не на последно място поради проблеми със съвместимостта IMHO.
FastResize не се показва - това е растерна графика в размера на растерни.
BitBlt е необходимо, когато е необходимо След получената растерното изображение.
> Sapersky # XA0; (11/28/06 19:50) [38]
Завийте друг DrawDIBDraw на VFW:
Процедура DDDraw (платно: TCanvas; dTop, dLeft, dHeight, dWidth: цяло число;
# XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; Bitmap: TBitmap);
Var
# XA0; lpBits # XA0;: Стрелката;
# XA0; pBmpInfo: PBitmapInfo;
# XA0; nColors. кардинал;
# XA0; HDD # XA0; # XA0. HDRAWDIB;
# XA0; BitmapStream: TMemoryStream;
# XA0; процедура SetSize;
# XA0; Var
# XA0; # XA0; RatioH,
# XA0; # XA0; RatioW # XA0;: разширен;
# XA0; започне
# XA0; # XA0; с pBmpInfo ^ .bmiHeader започвайте
# XA0; # XA0; # XA0; ако (biWidth> dWidth) или (biHeight> dHeight) след това
# XA0; # XA0; # XA0; # XA0; започне
# XA0; # XA0; # XA0; # XA0; # XA0; RatioH: = dHeight / biHeight;
# XA0; # XA0; # XA0; # XA0; # XA0; RatioW: = dWidth # XA0 / biWidth;
# XA0; # XA0; # XA0; # XA0; # XA0; ако RatioH> RatioW след RatioH: = RatioW;
# XA0; # XA0; # XA0; # XA0; # XA0; dHeight: = TRUNC (biHeight * RatioH);
# XA0; # XA0; # XA0; # XA0; # XA0; dWidth # XA0 ;: = TRUNC (biWidth # XA0 * RatioH);
# XA0; # XA0; # XA0; # XA0; # XA0; Exit;
# XA0; # XA0; # XA0; # XA0; край;
# XA0; # XA0; # XA0; dHeight: = biHeight;
# XA0; # XA0; # XA0; dWidth # XA0 ;: = biWidth;
# XA0; # XA0; край;
# XA0; край;
започвам
# XA0; ако Bitmap = нула след излизане;
# XA0; BitmapStream: = TMemoryStream.Create;
# XA0; Bitmap.SaveToStream (BitmapStream);
# XA0; pBmpInfo: = PBitmapInfo (PChar (BitmapStream.Memory)
# XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; + SizeOf (TBitmapFileHeader));
# XA0; с pBmpInfo ^, bmiHeader започвайте
# XA0; # XA0; ако biClrUsed = 1 тогава
# XA0; # XA0; # XA0; nColors: = biClrUsed
# XA0; # XA0; останало
# XA0; # XA0; # XA0; nColors: = (1 SHL biBitCount);
# XA0; # XA0; ако biBitCount> 8 тогава
# XA0; # XA0; # XA0; започне
# XA0; # XA0; # XA0; # XA0; lpBits: = PChar (@bmiColors) + Ord (biClrUsed)
# XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; + Ord (biCompression = BI_BITFIELDS) * 3;
# XA0; # XA0; # XA0; край
# XA0; # XA0; друго lpBits: = PChar (@bmiColors) + nColors;
# XA0; # XA0; HDD: = DrawDibOpen;
# XA0; # XA0; опитате
# XA0; # XA0; # XA0; DrawDibRealize (HDD, Canvas.Handle, True);
# XA0; # XA0; # XA0; SetSize;
# XA0; # XA0; # XA0; DrawDibDraw (HDD,
# XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; Canvas.Handle,
# XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; dLeft, # XA0; dTop,
# XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; dWidth, dHeight,
# XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; PBitmapInfoHeader (@bmiHeader),
# XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; lpBits,
# XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; 0, 0,
# XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; biWidth, biHeight,
# XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; # XA0; DDF_HALFTONE);
# XA0; # XA0; накрая
# XA0; # XA0; # XA0; DrawDibClose (HDD);
# XA0; # XA0; край;
# XA0; край;
# XA0; BitmapStream.Free;
приключи;
Друг INTEL за обработка на изображения библиотека, също. Тя ще бъде полезна vesch.
> Кой е открил, че скоростта, с StretchBlt COLORONCOLOR
> Не е съвсем очевидно зависимост от дълбочината на цвета
Уау. И аз не знаех.
> Едновременно за сравнение всичко, всичко, завинтена за FastLIB
> Моят тест:
Проверих в. Резултатите са както следва:
Stretchblt + 24bpp = 27004
FastLib + 24bpp = 10381
Stretchblt + 32 bpp = 6219
FastLib + = 8258 24bpp
> [28] Sapersky # XA0; (24.11.06 14:57)
> StretchBlt ще продължи да работи поне отчасти
> Software.
Всяка функция е част от софтуера, а самата трансформация в образа на съвременна vidyuha - хардуер.
за StretchBlt, тук също теста пунктирана
употреби
# XA0; SysUtils,
# XA0; Windows,
# XA0; графика;
конст
# XA0; INTER_COUNT = 10;
Var
# XA0; bmpScreen, bmpDest: TBitmap;
# XA0; I: Integer;
# XA0; DT: TDateTime;
1280x1024x32bit (ATI X600 WinXP)
> Sapersky # XA0; (11/29/06 17:24) [44]
И ние имаме толкова резултати се различават значително? Разрешение по-различно?
Да, имаше 800 * 600.
За 1280 * 1024 * 32:
FastLIB: # XA0; 24: 9231; # XA0; 32: 7982
StretchBlt: 24: 32 42744: 5523
171 и 407.
Но това е доста предвидим, чудейки се как много по-бързо с полутонове (това? По-бързо), когато се появи. Опитайте тест ми, не само StretchBlt / FastLIB, но DirectDraw (DD Blt - участък). И напишете какво конфигурация.
за коригираната версия на компилатора, но
строителство
# XA0; FormatVars. масив [0..3] на TPixelFormat =
# XA0; # XA0 (pfDevice, pf8bit, pf24bit, pf32bit);
# XA0; FormatBpps. масив [0..3] на цяло число =
# XA0; # XA0 (4, 1, 3, 4);
.
FormatBpps [0]: = GetDeviceCaps (DC, BITSPIXEL) SHR 3;
Как е, че дори и някой да компилира?
DD Blt - участък - 849 (5892 MB / сек)
(Q: 7159; T: 7160; C: 8,437)
изготвя чрез заместване на строителство на Вар.
1280x1024x32. Athlon64 3000+, 1 GB RAM.
DD Blt - участък - 1512 (3306 Мб / с)
GDI StretchBlt:
32: 5680 (880 Мб / с)
GDI StretchBlt:
24. 17,990 (208 Мб / с)
FastLIB:
32: 3720 (1344 MB / сек)
Как е, че дори и някой да компилира?
D5 въведените константи по подразбиране могат да бъдат променяни.
Тъй като, с D6 или 7 - по подразбиране е невъзможно, но може да включва опция компилатор.
1,152 * 864, WinXP_SP2, PIV4 3GHz / 1Gb / GF7600GT
DD Blt - участък - 430 (8835 MB / сек)
(Q: 2360; T: 2361; C: 5,492)
1152 * 864, Vista b.6000, PIV4 3GHz / 1Gb / GF7600GT
> [51] Sapersky # XA0; (30.11.06 12:55)
причината, поради която аз Полутоново много по-икономичен и по-бързо, отколкото аз осъзнах, всъщност, Полутоново наистина бавно, но в моя случай - много по-бързо - това се дължи на различното поведение на функцията при изготвянето в WM_PAINT, няма никаква връзка с обект)
> [44] Sapersky
> Ето защо, всеки четене, но постоянно се проверява за
> AV избягване или чете байт по байт.
капацитет Формат hranieniya dibov deklararuet в дължината на всеки linnii krutnuyu 4 байта, така че те не се четат, не narvatsya работи. Дори и с следващия ред пиксели не се възползва.
Хммм, резултатите от Vista не е впечатляващо, а в действителност обеща да ускори всичко има такива.
Въпреки, че по-добре, може би, да се изчака официалното пускане и нормални драйвери, а след това се правят изводи.
Това не съм написал, но аз ще отговори :)
На първо място, кратно на 4 байта дължина низ не е гаранция за наличието на "опашка" в края на линията на сканиране. Второ, AV трудно да се хване повече и заради това CreateDIBSection заделя памет с марж, се закръгля до 4 Появяват кб. Но след това отново, можете да "успешно" podgadat размера и лети същото.
Поради това са необходими предпазни мерки, не е задължително постоянна проверка - можете да направите цикъл Ширина-1 пиксела на DWORD, а последният байт копие.
Но всичко това няма значение, защото В моя опит (вж. [44] отново) специалните предимства на DWORD на употреба не.
> Докато по-добре може би да се изчака официалното пускане и нормално
> Drivers, а след това да се направят изводи.
В официалното съобщение, което имам. Шофьор също е нормално. По-бавно, отколкото Vista.