Cea mai rapidă modalitate de a modifica dimensiunea Bitmap (reducere).
> Aceasta este tăiere, nu scalare.
nu este adevărat. aceasta este
> modificați cel mai rapid dimensiunea imaginii Bitmap?
și dacă schimbați imaginea, aceasta depinde de algoritm.
> nu este adevărat. aceasta este
Nu am văzut implementarea TBitmap.Width: =. și TBitmap.Height: =. în VCL, dar ceva îmi spune că în spatele lor este același StretchBlt :)
Acest lucru este greu de repede.
de la sub Windows hardware accelerate există bltfast pe WinApi direct, dar nu scară.
În plus, există o mașină a parametrilor în tipul TBltFx cu documentație murdară.
așa că da, apă directă. este posibil prin DelphiH, este posibil prin fișiere antet.
Dar dacă aceasta este o singură operație, atunci încărcarea bitmap-ului în suprafață, apoi scalarea, apoi descărcarea înapoi va dura atât de mult timp încât să nu se poată accelera și vorbi.
> Numai în continuare TBitmap.Width: =. și TBitmap.Height: = nu
> Scară - au tăiat excesul
dacă prin TImage și Strecth este activată, atunci scară
Uită-te GraphicEx, există mai multe moduri de a scala, poate fi mai rapid.
> Dar schimba dimensiunea, care era cerută în subiect.
Bukovoedstvo aceasta. În același subiect este StretchBlt. Este vorba de scalare. Limba rusă este bogată și ambiguă.
StretchBlt necesar cu sau fără filtrare?
Dacă, cu filtrare, Bilinear-ul FastLIB este mai rapid, deși oferă o calitate mai slabă (se pare că algoritmul este mai ușor). Dacă fără (FastResize) viteza este aproximativ aceeași cu cea a StretchBlt.
Despre operațiunile unice - da, de la DDraw în această situație nu va mai fi de folos. Cu excepția cazului în care stocați în dimensiunea care a venit, și să se întindă direct la ieșire.
> StretchBlt necesar cu sau fără filtrare?
Nici o filtrare nu este opțională.
Ie
SetStretchBltMode (Canvas.Handle, COLORONCOLOR); Pentru StretchBlt
În general, am ajuns la concluzia că nu trebuie să depășesc StretchBlt.
Am încercat atât DrawDibDraw (), cât și Biblioteca de procesare a imaginilor INTEL - toate mai lent decât StretchBlt cu COLORONCOLOR;
Rezultat pentru 100 de repetări pe o anumită imagine:
StretchBlt - 281 căpușe
DrawDibDraw - 625 căpușe (deși aceasta este mai degrabă o operațiune pregătitoare)
Biblioteca de procesare a imaginilor INTEL - 844 (de asemenea, de formare mai lungă decât prelucrarea)
Pentru StretchBlt # xA0; + HALFTONE - 1547 căpușe.
> Sapersky # xA0; (21.11.06 14:47) [19]
Pentru FastResize rezultatul este de 79 de căpușe. Cu toate acestea.
Cea mai rapidă cale este de a scrie în asamblare. Imposibil de spus cu exactitate va fi câștigul de la MXX și SSE trebuie să încercați.
De asemenea, standardul Bit / StretchBlt este accelerat hardware cât mai mult posibil
Implementarea accelerată de hardware a StretchBlt nu am întâlnit încă. Vedeți linkul către rsdn de la [5] - acolo persoana scrie că teoretic poate fi accelerată, dar practic, din experiența mea, producătorii de șoferi dintr-un motiv oarecare nu. Pentru a confirma experiența, am arătat un exemplu - deși viteza pe care o măsoară câteodată în mod necinstit, avantajul DirectDraw-ului în întindere pe el este vizibil cu ochiul liber.
În general, FastDIB este mai convenabil de utilizat decât TBitmap standard de VCL
Da, aproape că am uitat ce este TBitmap :)
Deși există FastLIB și neajunsurile sale, rezistență slabă la erori, de exemplu (pas în stânga, pas spre dreapta - AV).
Apropo, StretchBlt + HALFTONE funcționează mult mai rapid și cu mai puține procente decât alte moduri StretchBlt.
De ce? Eu însumi nu știu.
Vreau să spun că vor mai frâna și mai mult decât cu șoferii de marcă? Ei bine, asta este de la sine, dar nu vorbesc despre asta. Vreau să spun că ceea ce șoferii de marcă nu pun, StretchBlt va funcționa în continuare cel puțin parțial. Ie suprafata mai lenta.Blt.
Apropo, StretchBlt + HALFTONE funcționează mult mai rapid și cu mai puține procente decât alte moduri StretchBlt.
poate indica faptul că miracolele se întâmplă uneori :) Faptul este că în toate # xA0; implementări hardware DirectDraw-stretch, pe care le-am văzut, HALFTONE cusături strânse și nu se închide (deși nu este chiar că software-ul HALFTONE, calitatea este ceva mai proastă). Ie Dacă HALFTONE este mai rapid, StretchBlt, în acest caz, poate fi hardware de lucru.
DDraw este de aproape 3 ori mai lent decât FastDIB datorită încărcării lungi Bitmap-a.
Dacă fără descărcare este de 5 ori mai rapid.
> Uită-te GraphicEx, există mai multe moduri de a scala, poate fi mai rapid.
Ei au algoritmi foarte buni, apropo. Vă recomand. În mine de la ei copiate pe asm făcut pentru imaginile mari.
Cea mai rapidă cale:
se construiește o matrice de coordonate, două array de linii ale imaginii rezultate în coordonatele originalului. Ie unde să obțineți puncte din matricea sursă.
Apoi, buclele imbricate de-a lungul axei x și y, pentru fiecare linie x și y, punctele din materia primă bitmap originală sunt selectate conform coordonatelor calculate anterior.
Viteza este foarte mare, mmx / sse nu va ajuta aici. nu este absolut nimic de luat în considerare, doar transporturile.
Calitatea, desigur, suferă de viteză, dar în cazul meu, lucrul cu imagini mari nu este critică, am imagini care sunt mai degrabă monotone (sau cum să le spun)? Eliminarea a 3/4 puncte este aproape imposibil de remarcat.
De asemenea, au algoritmi similari, dar cu anti-aliasing.
Undeva ai o eroare în test. Pe calculatorul meu, StretchBlt este mai rapid decât FastResize, aproape de un ordin de mărime. Chiar și cu interpolare. Acest lucru este prevăzut ca desenul să apară imediat pe ecran, iar dacă la un alt Bitmap, atunci vitezele ar trebui să fie aproximativ aceleași.
Și utilizarea DirectX nu pentru jocuri nu este suficientă atunci când este justificată, nu în ultimul rând datorită problemelor de compatibilitate IMHO.
FastResize nu se afișează - se scală de la bitmap la bitmap.
După bitmapul rezultat, aveți nevoie de BitBlt unde aveți nevoie.
> Sapersky # xA0; (28.11.06 19:50) [38]
Șurubați încă DrawDIBDraw de la vfw:
Procedura DDDraw (Canvas: TCanvas; dTop, dLeft, dHeight, dWidth: Integer;
# 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;: Pointer;
# xA0; pBmpInfo: PBitmapInfo;
# xA0; nColors. Cardinal;
# xA0; hdd # xA0; # xA0;. HDRAWDIB;
# xA0; BitmapStream: TMemoryStream;
# xA0; procedura SetSize;
# xA0; var
# xA0; # xA0; RatioH,
# xA0; # xA0; RatioW # xA0;: Extended;
# xA0; începeți
# xA0; # xA0; cu pBmpInfo ^ .bmiHeader nu începe
# xA0; # xA0; # xA0; dacă (biWidth> dWidth) sau (biHeight> dHeight) atunci
# xA0; # xA0; # xA0; # xA0; începeți
# xA0; # xA0; # xA0; # xA0; # xA0; RatioH: = dHeight / biHeight;
# xA0; # xA0; # xA0; # xA0; # xA0; RatioW: = dWidth # xA0; / biWidth;
# xA0; # xA0; # xA0; # xA0; # xA0; dacă RatioH> RatioW then 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; Ieșire;
# xA0; # xA0; # xA0; # xA0; sfârșitul;
# xA0; # xA0; # xA0; dHeight: = biHeight;
# xA0; # xA0; # xA0; dWidth # xA0 ;: = biWidth;
# xA0; # xA0; sfârșitul;
# xA0; sfârșitul;
începe
# xA0; dacă Bitmap = zero, atunci ieșiți;
# 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; + DimensiuneOf (TBitmapFileHeader));
# xA0; cu pBmpInfo ^, începe bmiHeader
# xA0; # xA0; dacă biClrUsed = 1 atunci
# xA0; # xA0; # xA0; nColors: = biClrUsed
# xA0; # xA0; altceva
# xA0; # xA0; # xA0; nColori: = (1 shl biBitCount);
# xA0; # xA0; dacă biBitCount> 8 atunci
# xA0; # xA0; # xA0; începeți
# 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; sfârșitul
# xA0; # xA0; altfel lpBits: = PChar (@bmiColors) + nColori;
# xA0; # xA0; hdd: = DrawDibOpen;
# xA0; # xA0; încercați
# 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; în cele din urmă
# xA0; # xA0; # xA0; DrawDibClose (hdd);
# xA0; # xA0; sfârșitul;
# xA0; sfârșitul;
# xA0; BitmapStream.Free;
se încheie;
O altă Bibliotecă de prelucrare a imaginilor INTEL, de asemenea. Va fi util să cântăriți.
> Acum am aflat că viteza StretchBlt cu COLORONCOLOR
> are o dependență destul de evidentă de adâncimea de culoare
Wow. Și nu știam.
> Pentru a compara simultan, fixați FastLIB la
> Pentru test:
Am verificat-o singură. Rezultatele sunt următoarele:
Stretchblt + 24bpp = 27004
FastLib + 24bpp = 10381
Stretchblt + 32bpp = 6219
FastLib + 24bpp = 8258
> [28] Sapersky # xA0; (24.11.06 14:57)
> StretchBlt va funcționa încă cel puțin parțial
> software.
orice funcție funcționează parțial în software, iar transformarea reală a unei imagini pe vidyuhah modern este hardware.
Despre StretchBlt, și aici testul a fost rulat
utilizări
# xA0; SysUtils,
# xA0; Windows,
# xA0; Grafică;
const
# xA0; INTER_COUNT = 10;
var
# xA0; bmpScreen; bmpDest: TBitmap;
# xA0; I: Integer;
# xA0; dt: TDateTime;
1280x1024x32bit (ati x600 winxp)
> Sapersky # xA0; (29.11.06 17:24) [44]
Și despre noi, deci rezultatele diferă mult? Rezoluția este diferită?
Da, au fost 800 * 600.
Pentru 1280 * 1024 * 32:
FastLIB: # xA0; 24: 9231; # xA0; 32: 7982
StretchBlt: 24: 42744 32: 5523
171 și 407.
Dar acest lucru este destul de previzibil, mă întreb cât de repede (mai repede?) HALFTONE când se afișează pe ecran. Încercați testul meu, nu numai StretchBlt / FastLIB, dar și DirectDraw (DD Blt - stretch). Și scrieți ce configurație.
Despre versiunea compilatorului corectată, dar
const
# xA0; FormatVars. array [0..3] de TPixelFormat =
# xA0; # xA0; (pfDevice, pf8bit, pf24bit, pf32bit);
# xA0; FormatBpps. array [0..3] de Integer =
# xA0; # xA0; (4, 1, 3, 4);
.
FormatBpps [0]: = GetDeviceCaps (DC, BITSPIXEL) shr 3;
cum este compilat cineva?
DD Blt - întindere - 849 (5892 mb / s)
(Q: 7159; T: 7160; C: 8437)
compilat, înlocuind Const cu var.
1280x1024x32. Athlon64 3000+, 1 GB de memorie RAM.
DD Blt - întindere - 1512 (3306 mb / s)
GDI StretchBlt:
32: 5680 (880 mb / s)
GDI StretchBlt:
24. 17990 (208 mb / s)
FastLIB:
32: 3720 (1344 mb / s)
cum este compilat cineva?
În D5, constantele tastate pot fi modificate în mod implicit.
Începând cu D6 sau 7 - în mod implicit este imposibil, dar este posibil să includeți și o opțiune de compilator.
1152 * 864, WinXP_SP2, PIV4 3GHz / 1Gb / GF7600GT
DD Blt - întindere - 430 (8835 mb / s)
(Q: 2360; T: 2361; C: 5492)
1152 * 864, Vista b.6000, PIV4 3GHz / 1Gb / GF7600GT
> [51] Sapersky # xA0; (11/30/06 12:55 PM)
motivul pentru care am Semiton mult mai economic și mai rapid decât am realizat, de fapt, Semiton într-adevăr lent, dar în cazul meu - mult mai rapid - acest lucru se datorează comportamentului diferit al funcției atunci când desen într-un WM_PAINT, nu are nici o legătură cu un subiect)
> [44] Sapersky
> Prin urmare, citiți, dar verificați constant
> Evitați AV sau citiți octeți.
Formatul de stocare a dibas în memorie declară lungimea fiecărei linii să fie abrupte de 4 octeți, astfel încât să nu se citească, nu se va întâmpla. Chiar și de pe următoarea linie, pixelul nu poate fi înțeles.
Hmmm, rezultatele lui Vista nu sunt impresionante, dar a promis să accelereze lucrurile oricum.
Deși este mai bine să aștepți eliberarea oficială și șoferii normali și apoi să tragem deja concluzii.
Nu am scris, dar voi răspunde :)
Mai întâi, un multiplu de 4 octeți de lungime a șirului nu garantează prezența unei "coadă" la capătul liniei de scanare. În al doilea rând, AV este dificil de capturat din cauza faptului că CreateDIBSection alocă memoria cu o marjă, rotunjește până la 4 KB, cu toate probabilitățile. Dar, din nou, puteți ghici cu succes cu mărimea și puteți zbura la fel.
Prin urmare, sunt necesare măsuri de precauție, nu neapărat o verificare constantă - puteți face un ciclu de Lățime-1 pixeli pentru dword, iar ultima este copiată cu byte.
Dar toate acestea nu sunt importante, pentru că din experiența mea (a se vedea [44] din nou) avantajul special de a folosi dword nu.
> Deși este mai bine să aștepți eliberarea oficială și normal
> șoferi, și apoi trage deja concluzii.
Am o eliberare oficială. De asemenea, șoferii sunt normali. Slower Vista.
Trimiteți-le prietenilor: