A leggyorsabb és módosíthatja bitmap méretű (csökkenteni)
A leggyorsabb változás Bitmap-a (csökkentett) méretű.
> Ez a cut-off, hanem méretezés.
igaz. azt
> Leggyorsabb változás Bitmap-és mérete?
és ha változtatni a képet, ez függ az algoritmus.
> True. azt
Még nem néztem TBitmap.Width végrehajtása: =. és TBitmap.Height: =. A VCL, de valami azt súgja, hogy a mögöttük rejlik azonos StretchBlt :)
Ez aligha gyorsabb.
alól a Windows hardveresen gyorsított bltfast kell élni WinAPI, de az átméretezés nem érvényes.
mellett ott autó paraméterei típus TBltFx csúnya dokumentációt.
Tehát igen, direktdrav. lehetővé Delphi, akkor a fejlécet.
De ha ez egy egyszeri művelet, be a bitmap a felületet, majd nagyítás, majd töltse vissza, hogy ilyen sok időt, hogy bármilyen gyorsítás és a beszéd nem megy.
> Csak még TBitmap.Width: =. és TBitmap.Height: = nem
> Skálázott - levágták a felesleges
ha TImage és befogadó Strecth, majd pikkelyes
Nézd GraphicEx, számos módja van masshabirovaniya gyorsabb lehet.
> De változtatni méretét szükség szerint egy alanyban.
Fontoskodás azt. Szintén egy alanyban meghatározott StretchBlt. Ez körülbelül méretezés. Orosz nyelv gazdag és egyértelmű.
StretchBlt szükséges vagy szűrés nélkül?
Ha a szűrés, FastLIB „ovsky Bilinear gyorsabb, bár, és ad néhány gyengébb minőségű (látszólag maga az algoritmus egyszerűbb), ha nem (FastResize) -. A sebesség körülbelül ugyanaz, mint a StretchBlt.
Ami a műveleti egységek - igen, honnan ddraw ilyen helyzetben lenne sok haszna. Van, hogy a tároló méretét, hogy jön, és nem nyúlik közvetlenül a kimenetre.
> StretchBlt szükséges vagy szűrés nélkül?
Nem szűrés nem kötelező.
Ie
SetStretchBltMode (Canvas.Handle, COLORONCOLOR); a StretchBlt
Általában azt a következtetést vonta le, hogy ne lepjen StretchBlt.
Próbáltam és DrawDibDraw () és az Intel Image Processing Library - alacsonyabb, mint a StretchBlt COLORONCOLOR;
Eredmények 100 ismétlődés egy kép:
StretchBlt - 281 kullancsok
DrawDibDraw - 625 kullancsot (bár ez inkább az előkészítő műveletek)
INTEL Image Processing Library - 844 (szintén hosszabb képzési, mint a kezelés)
a StretchBlt # XA0; + FÉLTÓNUS - 1547 kullancsok.
> Sapersky # XA0; (21.11.06 14:47) [19]
Eredmények FastResize - 79 kullancsot. Azonban.
A leggyorsabb módja az lenne, ha írsz a szerelő. Cant pontosan megmondani budetli származó nyereség MXX és SSE ízlés szerint.
Normál Bit / StretchBlt is hardveresen gyorsított, amennyire csak lehet
Hardveresen gyorsított végrehajtása StretchBlt én még nem találkoztam. Lásd a linket rsdn [5] -. Ha egy személy írja, hogy elméletileg lehetséges, hogy gyorsítsa fel, de a gyakorlatban, az én tapasztalatom, a gyártó vezetők valamilyen okból nem. Annak igazolására, a tapasztalat azt tegye példaként - bár néha a sebességét méri görbe DirectDraw előnye a szakaszon is látható szabad szemmel.
FastDIB általában könnyebb használni, mint a standard VCL TBitmap
Ja, majdnem elfelejtettem, milyen TBitmap :)
Annak ellenére, hogy van FastLIB és hátrányai, gyenge stabilitás, például (lépés van hátra, jobbra lépés - AV).
Mellesleg én StretchBlt + FÉLTÓNUS sokkal gyorsabb és kevésbé evés százalékkal, mint más üzemmódokban StretchBlt.
Miért? Nem tudom.
Bizonyos értelemben ők még lassítják mint saját meghajtó? Nos, ez magától értetődik, de nem vagyok róla. Azt, hogy minden saját meghajtó vagy Tedd StretchBlt továbbra is működni fog, legalábbis részben a szoftver. Ie lassabb surface.Blt.
Mellesleg én StretchBlt + FÉLTÓNUS sokkal gyorsabb és kevésbé evés százalékkal, mint más üzemmódokban StretchBlt.
jelezheti, hogy csodák történnek néha :) A tény az, hogy minden # XA0; hardver eszközök DirectDrawot-szakaszon, láttam, FÉLTÓNUS varrott szorosan, és nem kapcsol ki (bár ez nem elég, amit a szoftver FÉLTÓNUS, kissé rosszabb minőségű). Ie ha FÉLTÓNUS gyorsabb, StretchBlt, ebben az esetben lehetőség van arra, hogy a munka hardver.
Ddraw közel 3-szor lassabb FastDIB miatt a hosszú letöltési Bitmap-a.
Ha nincs terhelés mindössze 5 gyorsabb.
> Look GraphicEx, számos módja van masshabirovaniya gyorsabb lehet.
Van egy nagyon jó algoritmusok, mellesleg. Azt javaslom. Ne magad átírni az AFM teszi nagy képek.
A leggyorsabb módja:
mátrixát koordinátáit, két tömb vonalak kapott kép az eredeti koordinátákat. Ie ahol egy pontot az eredeti tömb.
Aztán ott vannak beágyazott hurok szerint az X tengely, és y, minden egyes sorban az x és y szerint vannak megválasztva előre kiszámított koordinátáit a kiindulási pont a nyers bittérkép.
Speed nagyon magas, MMX / SSE itt nem segít, hiszen helység semmi különös, csak egy transzfer.
Minőség, persze, a sebesség a szenvedés, de az én esetemben, a nagy méretű képek nem kritikus, én nagyon monoton a kép (vagy hogy mondják)? Leejtése 3/4 pontot alig észrevehető.
Ők ugyanazt a algoritmust, de az anti-aliasing.
Valahol van egy hiba a vizsgálat. A számítógépen StretchBlt gyorsabban FastResize, majdnem egy nagyságrenddel. Még interpoláció. Ez azt feltételezi, hogy a renderelés azonnal bekövetkezik a képernyőn, és ha egy másik Bitmap, a mértéke körülbelül azonos.
És használata DirectX nem a kis játék, ha indokolt, nem utolsósorban azért, mert a kompatibilitási problémák IMHO.
FastResize nem jelenik - ez egy bitmap a bitmap mérleg.
BitBlt szükséges, ha az szükséges után a kapott bitmap.
> Sapersky # XA0; (28.11.06 19:50) [38]
Csavar másik DrawDIBDraw a vfw:
eljárás DDDraw (vászon: TCanvas; dTop, dLeft, dHeight, dWidth: egész;
# 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; eljárás setSize;
# XA0; var
# XA0; # XA0; RatioH,
# XA0; # XA0; RatioW # XA0;: Extended;
# XA0; kezdődik
# XA0; # XA0, azzal pBmpInfo ^ .bmiHeader nem kezdődik
# XA0; # XA0; # XA0; ha (biWidth> dWidth) vagy (biHeight> dHeight), majd
# XA0; # XA0; # XA0; # XA0; kezdődik
# XA0; # XA0; # XA0; # XA0; # XA0; RatioH: = dHeight / biHeight;
# XA0; # XA0; # XA0; # XA0; # XA0; RatioW: = dWidth # XA0; / biWidth;
# XA0; # XA0; # XA0; # XA0; # XA0; ha RatioH> RatioW majd 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; kilépés;
# XA0; # XA0; # XA0; # XA0; end;
# XA0; # XA0; # XA0; dHeight: = biHeight;
# XA0; # XA0; # XA0; dWidth # XA0 ;: = biWidth;
# XA0; # XA0; end;
# XA0; end;
kezdődik
# XA0, ha Bitmap = nil majd kilép;
# 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, azzal pBmpInfo ^, bmiHeader nem kezdődik
# XA0; # XA0; ha biClrUsed = 1, akkor
# XA0; # XA0; # XA0; nColors: = biClrUsed
# XA0; # XA0; máshol
# XA0; # XA0; # XA0; nColors: = (1 SHL biBitCount);
# XA0; # XA0; ha biBitCount> 8, akkor
# XA0; # XA0; # XA0; kezdődik
# 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; end
# XA0; # XA0; mást lpBits: = PChar (@bmiColors) + nColors;
# XA0; # XA0; HDD: = DrawDibOpen;
# XA0; # XA0, próbálja
# 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, végül
# XA0; # XA0; # XA0; DrawDibClose (HDD);
# XA0; # XA0; end;
# XA0; end;
# XA0; BitmapStream.Free;
végén;
Tovább INTEL Image Processing Library is. Ez hasznos lesz vesch.
> Ki fedezte fel, hogy az a sebesség, StretchBlt COLORONCOLOR
> Nem nyilvánvaló, függés a színmélység
Wow. És én nem tudom.
> Egyszerre összehasonlítani mindent, mindent, csavarozva FastLIB
> Saját teszt:
Megnéztem a. Az eredmények a következők:
Stretchblt + 24bpp = 27.004
FastLib + 24bpp = 10381
Stretchblt + 32bpp = 6219
FastLib + 24bpp = 8258
> [28] Sapersky # XA0; (24.11.06 14:57)
> StretchBlt továbbra is működni fog, legalábbis részben
> Szoftver.
Minden olyan funkció része szoftver, és maga a transzformáció a kép a modern vidyuha - hardver.
a StretchBlt, itt is a vizsgálat szaggatott
felhasználások
# XA0; SysUtils,
# XA0, a Windows,
# XA0; Graphics;
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]
És van olyan eredménye nagyban? Engedély más?
Igen, volt egy 800 * 600.
1280 * 1024 * 32:
FastLIB: # XA0; 24: 9231; # XA0; 32: 7982
StretchBlt: 24: 32 42.744: 5523
171 és 407.
De ez elég kiszámítható, vajon mennyivel gyorsabb FÉLTÓNUS (ez? Gyorsabb), amikor megjelenik. Próbálja én teszt, nem csak StretchBlt / FastLIB, de DirectDrawot (DD Blt - szakaszon). És írja, amit konfigurációt.
a javított változat a fordító, de
const
# XA0; FormatVars. array [0..3] a TPixelFormat =
# XA0; # XA0; (pfDevice, pf8bit, pf24bit, pf32bit);
# XA0; FormatBpps. array [0..3] Integer =
# XA0; # XA0; (4, 1, 3, 4);
.
FormatBpps [0]: = GetDeviceCaps (DC, BITSPIXEL) SHR 3;
Hogy is van ez akkor is, valaki össze?
DD Blt - szakaszon - 849 (5892 MB / s)
(K: 7159; T: 7160; C: 8437)
által összeállított helyett Const a var.
1280x1024x32. Athlon64 3000+, 1 GB RAM.
DD Blt - szakaszon - 1512 (3306 MB / s)
GDI StretchBlt:
32: 5680 (880 MB / s)
GDI StretchBlt:
24. 17990 (208 MB / s)
FastLIB:
32: 3720 (1344 MB / s)
Hogy is van ez akkor is, valaki össze?
A D5 beírt alapértelmezett állandók lehet változtatni.
Mivel, mint például, a D6 vagy 7 - az alapértelmezett lehetetlen, de akkor is olyan fordítóprogram opciót.
1152 * 864, WinXP_SP2, PIV4 3GHz / 1 Gb / GF7600GT
DD Blt - szakaszon - 430 (8835 MB / s)
(K: 2360; T: 2361; C: 5492)
1152 * 864, Vista b.6000, PIV4 3GHz / 1 Gb / GF7600GT
> [51] Sapersky # XA0; (30.11.06 12:55)
Az ok, amiért FÉLTÓNUS sokkal gazdaságosabb és gyorsabb, mint rájöttem, sőt, FÉLTÓNUS nagyon lassan is, de az én esetemben - sokkal gyorsabban - ez annak köszönhető, hogy az eltérő viselkedést funkciót, ha a rajz egy WM_PAINT, nincs összefüggésben az alanynak)
> [44] Sapersky
> Ezért minden olvasás, de folyamatosan ellenőrizni
> AV elkerülésére vagy olvasott byte byte.
Format hranieniya dibov deklararuet kapacitását a hossza az egyes linnii krutnuyu 4 byte, úgy, hogy nem olvassa el, narvatsya nem működik. Még a következő sorban a képpontok nem fogja.
Hmmm, az eredmények a Vista nem lenyűgöző, sőt megígérte, hogy gyorsítsák fel minden ilyen.
Bár jobb, talán várni a hivatalos kiadás és a normális vezetők, és akkor a következtetések levonása.
Ez nem én írtam, de én válaszolok :)
Először is, a többszörös 4 bájt hosszú string nem garantálja a jelenléte a „farok” a végén a szkennelési vonalat. Másodszor, az AV nehéz elkapni több és emiatt CreateDIBSection memóriát ráhagyással van kerekítve 4 kb jelenik meg. De aztán megint, akkor „sikeresen” podgadat a méretét és az ugyanaz.
Ezért óvintézkedésekre van szükség, de nem feltétlenül folyamatos ellenőrzése - tudod, hogy ciklus szélesség-1 pixel dword, és az utolsó bájt példányt.
De mindez nem számít, mert Az én tapasztalatom szerint (lásd. [44] ismét) a különleges előnyöket a használat dword nem.
> Bár jobban talán várni a hivatalos kiadás és a normál
> Drivers, aztán következtetéseket levonni.
A hivatalos kiadás van. Pilóta is normális. Lassabb, mint a Vista.