Adatbázisok tervezésénél nem árt figyelembe venni néhány szempontot, feltéve ha azt szeretnénk, hogy a későbbiekben minél kevesebb fejfájást okozzon a szinkronizálás megvalósítása a szinkronizációs szolgáltatások (Sync Services) felett.  Kliens / szerver szinkronizálásnál minden egyes rekord egyedien azonosított kell legyen minden csomópontban (ezalól kivételt képeznek a kliens/szerver snapshot szinkronizációk). Na most ez így nagyon egyszerűnek tűnik, de mindjárt meglátjuk, hogy milyen “problémákkal” kell szembesülni, amikor az elsődleges kulcs típusát megválasztjuk. Ugye például ha törölnek egy rekordot, akkor annak az elsődleges kulcsát nem nagyon kellene használni egy másik rekordhoz a továbbiakban (ezt pl. az auto inkrementált mezők automatikusan garantálják az SQL Server-ben). Amennyiben egy elsődleges kulcs egyszerre több mint egy csomópont (parasztosan és naívan kifejezve: adatbázis) által használt, abban az esetben kulcs-ütközés következhet be. Ez egy tipikus osztott rendszerek fejlesztésénél előforduló probléma és nem a Sync Services limitációja. Nézzünk néhány választási lehetőséget a probléma kiküszöbölésére:

Auto inkrementált (IDENTITY) oszlopok

Az adatbázis-tervező szakik gyakran választanak auto-inkrementált oszlopot eldődleges kulcsnak. Egy auto-inkrementált tulajdonság automatikusan generál új értéket minden egyes új beszúrt rekordhoz az adott táblában, amely növekedhet/csökkenhet egy ún. seed érték által. Az auto-inkrementált oszlopok tipikusan valamilyen tömör adattípust használnak, úgy mint egész számok (integers), stb. Eredményben ez azt jelenti, hogy a tömörebb klaszterizált (clustered) indexeknek köszönhetően hatékonyabbak a “join” műveletek, illetve kevesebb IO művelet szükséges a tábla lekérdezésekor.

Bármennyire is hatékony egy auto-inkrementált kulcs, mivel a seed és increment értékek fixáltak és véges számú lehetséges értékből lehetnek kiválasztottak, így a valószínűsége egy elődleges kulcs-ütközésnek nagyon magas. Ez a típusa a kulcsnak csak letöltési, adat-cachelési forgatókönyvekhez alkalmas. Ezekben a forgatókönyvekben az a lényeg, hogy egyetlen csomópont (a szerver vagy bármilyen más egyenrangú csomópont) generálja az új elsődleges kulcsértékeket, így garantált, hogy azok egyediek lesznek minden csomópontban a topológiában. Persze ugyanígy lehet alkalmazott az auto-inkrementált érték feltöltési és kétirányú szinkronizáció során is, ha az insert egyetlen csomópontban történik meg. Magyarra fordítva a szót, egy helyen lehet csak új rekordot felvinni, az pedig a szerver vagy kiemelt csomóponti adatbázis, a többi adatbázisban csak módosíthatók és törölhetők a rekordok. Amennyiben ez nem elég (és általában nem elég), az INSERT megszerzéséhez minden adatbázisban a következő alternatívák állnak rendelkezésre:

• GUID (Globally Unique Identifier)
  
  A GUID egyrészt garantálja az egyediséget minden csomópontban, illetve kiküszöböli az elsődleges kulcs-ütközéseket, melyek auto-inkrementált értékeknél lehetségesek. Azért van néhány dolog, amivel érdemes számolni:
  
  - Egy GUID 16 bájt, ami növeli a méretét a klaszterizált indexnek, így elég negatívan érinti a legtöbb közös műveletet, mint pl. JOIN is.
  
  - Rendezetlen GUID-ek esetében a töredezettsége (fragmentation) a klaszterizált indexnek jelentősen megnőhet. Ez negatívan érinti az IO műveleteket a lekérdezés során.
  
  SQL Server 2005-ben megjelent a newsequentialid() - amitől az SQL Server Management Studio még mindig hátast dob látszólag - jelentősen csökkentve általa a töredezettséget. Hatékonyságban a tesztek alapján közelíti a sima auto-inkrementált int oszlopok hatékonyságát. Mindenképp GUID-es primary key-t javasolnék minden olyan táblához, melyet szükséges szinkronizálni.
  
  
• Kulcsok, melyek magukba foglalnak egy csomópont azonosítót
  
  Ennek a megközelítésnek az a lényege, hogy egy olyan kulcsot használunk, amely összekombinál egy értéket (ami egyedi a szerveren vagy a kliens csomópontban) egy értékkel (ami egyedi az egész topológiában). Például, kliens/szerver szinkronizáció során használhatunk egy auto-inkrementált oszlopot összekombinálva egy másik oszloppal, ami tárolja a hash-ét az ID-nek, amit a Sync Services hozzárendel minden egyes klienshez. (Ez a ClientId, ami egyedi az egész topológiában) Aztán létrehozhatnánk ezalapján egy összetett elsődleges kulcsot, aminek két oszlopa van. Esetleg fejleszthetünk egy olyan rendszert is, amely beszúráskor valamilyen módszerrel összekombinálja a row ID-et a client ID-el egy oszlopba.
  
  
• Természetes kulcsok
  
  Ebben az esetben nem használjuk a tényleges elsődleges kulcsokat, hanem valamilyen üzleti kulcsot használunk a rekord azonosítására. Például, ha tároljuk az ügyfél TB számát, akkor szinkronizálhatunk azzal is. Na most mi a különbség? Látszólag tök mindegy lenne, de nem az. Ugyanis GUID/ID esetében nincs garancia arra, hogy ha két oldalon ugyanaz a felhasználó már regisztrálva lett, de más-más azonosítóval, ne kerüljön be kétszer (hacsak nincs valami globális szabályozási rendszer a GUID/ID meghatározására). De ez sem ilyen egyszerű, mivel a hozzá kapcsolódó egyéb táblák rekordjainak idegen kulcsai szintén ahhoz a GUID/ID-hez kötődnek, tehát ha pl. a megrendeléseit is szinkronizálni kell hősünknek, akkor nyilván az eredeti GUID/ID-el kell szinkronizálni magát az emberkét is, mégha kétszer is kerül be, hacsak a megrendelés sem a már létező másikra képes rászinkronizálódni. Na ezt most eléggé megcsavartam, de szerintem érthető. A lényeg, mindig a szituáció hozza magával a megfelelő módszert.
  
  
• Online beszúrás
  
  Ez maximum akkor, ha nem szükséges giga mennyiségű beszúrási műveletet végrehajtani túl sűrűn. Ilyenkor a beszúrási műveleteket közvetlen a szerveren kell elvégezni, majd a legközelebbi szinkronizálás alkalmával azok lefrissülnek a kliensekre is. Így garantált, hogy nem lesz kulcsütközés.

Remélem valamennyit segít ez a kis cikk az eldöntésében annak, hogy érdemes nekiállni megtervezni az adatbázist annak tudatában, hogy az a későbbiekben könnyedén Sync képes lehessen.

Ebbe most kezdek jó lenni. Nemrég jött a levél, hogy végre nem fog a VS 2010 állandóan behallni úgy, hogy repül vele minden. Megérte annyit levelezgeti a WPF team-el:

Hi, János,

I would like to update you about the status of this issue.  The VS crash (due to StackOverflowException when WPF designer shows) is now fixed in our most recent build. We thank you for your help in reporting and  investigating the issue. Should you encounter other WPF/Silverlight designer issues within Visual Studio, please feel free to contact me.

Éljen! Azóta találtam pár kemény bugot az Expression Encoder-ben is. Én nem tudom, nálam minden behal mostanában, az Internet Explorer-t azóta se lehet alap. böngészőnek beállítani. Ez a Vista egy kész katasztrófa.

Egy havi kihagyás után újra belevetettem magam a fejlesztésbe - máshoz úgyse nagyon értek - közbe pedig megjelent néhány olyan új technológia, amely felkeltette az érdeklődésemet. Erről adnék most itt egy rövidke kis áttekintést. Tehát most a Windows-on elérhető 2D-s prezentációs technológiák összehasonlításáról lesz szó.

Windowson jelen pillanatban elérhető három darab 2D-s prezentációs technológia:

1. GDI (Graphics Device Interface)
   
   

   Az alkalmazások javarésze (beleértve a MS alkalmazásokat), még ma is ezt használja. Az igazság az, hogy a GDI alapvető hiányosságoktól szenved. Nem támogat magas minőségű rajzolást. Nincs támogatás élsimításhoz (anti-aliasing), aminek köszönhetően a ferde vonalak csipkézettnek tűnnek. Mi több, nincs teljes támogatás áttetszőség (transparency) kezeléshez, úgy mint támogatása a félig áttetsző (semi-transparent) ecseteknek (brushes) és tollaknak (pens).

   
   A GDI-t nem párhuzamos feldolgozáshoz tervezték és emiatt egy kevésbé hatékony lokkolási mechanizmustól szenved. A Windows 7-ben és Windows Server 2008 R2-ben újratervezték ezt a lokkolási mechanizmust, hogy legyen sokkal kifinomultabb, szemcsésebb, de a teszteredmények azt igazolják, hogy az új Direct2D még mindig jobban skálázódik.
   
   Egy másik probléma, hogy a GDI handle-k totális száma limitált 10240/process és 65536/session-re, mert belsőleg a Windows egy 16 bites egész számot használ, hogy tárolja az indexeit ezeknek minden egyes session-höz. A stock objektumok kikerültek a limitációból. Az egyetlen út áthidalni ezt a limitet egy új session beiktatása, de ez növeli a memória használatot.
   
   
2. GDI+ (Graphics Device Interface Plus)
   
   A fő probléma a GDI+-al szerver oldali forgatókönyveknél az, hogy nincs hivatalos támogatás futtatni Session 0 izolációs szinten. Ez annyit tesz, hogy függvények, amelyek próbálnak kapcsolatot teremteni a megjelenítő eszközzel, hibákat fognak kapni, mert nem engedettek Session 0 izolációban. Egyéb függvények is elbukhatnak, mert még ha nem is tűnik úgy, hogy a függvény kapcsolódik a megjelenítő eszközhöz, használhatna valamilyen kerülő utat, ami tiltott.
   
   Máskülönben a GDI+ támogatja az anti-aliasing-et és alpha-blending-et egyaránt, tehát minőségbeli problémái nincsenek mint a GDI-nek, viszont vannak teljesítménybeli problémái továbbra is a lokkolási mechanizmus miatt, és ez az új Windowsokban (Windows 7, Windows Server 2008 S2) sem lett tovább fejlesztve.
   
   
3. Direct2D
   
   A Direct2D a Windows 7 részeként megjelenő új 2D-s prezentációs technológia, részben az elavult GDI/GDI+ leváltására. Nemrégiben portolásra került Windows Vista alá is, így a Windows Vista Platform Update keretében mindenki gépére felkerülhetett. Sajnos hozzá kell tegyem, hogy Windows XP-re nem nagyon várható ez a technológia, ugyanis a Direct3D 10 tetejére épül, ami pedig erősen támaszkodik a Vista óta bevezetett új driver modellre, ennélfogva nem valósítható meg az XP-re történő visszaportolás. Megjegyezném, hogy az új Internet Explorer 9 is a Direct2D-t fogja használni weboldalak megjelenítéséhez, használva a GPU erejét az oldalak rendereléséhez.
   
   Technikailag a D2D többszálúság (multi-threading) és Session 0 tudatában lett tervezve az elejétől fogva. Több szál használatakor, a D2D lokk-mentes lehet, használva több egyszálú factory-t, minden egyes szálhoz egyet. Egy factory széles lokkolás mindenképp lesz, ha az adott programnak használnia kell a többszálú módját a factorynak, de ez sokkal szemcsésebb, kifinomultabb, mint a GDI és GDI+ esetében. A hatása a lokkolásnak elhanyagolható és nem exponenciálisan növekszik a szálak számával.

A GDI összehasonlítása a Direct2D-vel

Még mielőtt kitérnék a címben szereplő témára, erősen érzékelhető a neten utánaolvasgatva, hogy eléggé ketté osztja a társadalmat ez a technológia. Egy Direct3D-s játékfejlesztő, akinek a kisujjában van az egész D3D, nevet egyet és azt mondja, hogy én megcsináltam ugyanazt a demot Direct3D-vel 500 sorba, amit a Microsoft Direct2D-vel 800 sorba. Természetesen ez minden további nélkül lehetséges, hiszen a D3D nem zárja ki, hogy 2D-ben programozzunk, sőt mivel a D2D a D3D tetején csücsül, ez fordítva is igaz. De mindazonáltal fontos megemlíteni, hogy a D3D-n túlmenően a D2D garantálja az interoperabilitást a GDI-vel is. Tehát ez nem igazán D3D fejlesztőknek kitalált technológia, hanem sokkal inkább a GDI/GDI+ fejlesztőket próbálják kimozdítani abból az árokból, amibe már hosszú évek óta bele vannak kényszerítve. Ennélfogva ezzel a cikkel csak bizonyos mértékig tudok egyetérteni. Abban teljesen igaza van az írónak, hogy bizonyos szinten feleslegesen túl lett komplikálva, illetve ugyanazokat a konvenciókat követi, mint a D3D, pl. rendering_2d(), ami valóban zavarba ejtő lehet egy GDI/GDI+ fejlesztőnek elsőre, de ez valójában a GDI koncepcionális megvalósítása körül volt igazából elszúrva. Nincs mese, néhány dolgot újra kell tanulni, értelmezni, de annyira nem vészes.

A GDI és a Direct2D is azonnali módú 2D-s renderelő API és mindkettő ajánl bizonyos fokú hardveres gyorsítást. Ez okoz némi zavart - ugyanis akkor miben különböznek ezek egymástól? Miben hasonlítanak egymáshoz? A Direct2D teszi a GDI-t gyorsabbá? Miben különbözik a Direct2D hardveres gyorsítása a GDI hardveres gyorsításától? Ezekre keressük most a választ.

Miben különbözik a Direct2D és GDI-től?

A Direct2D és GDI jobbára a részletekben térnek el, abban ahogy renderelik a képet, ahogy elérik a megjelenítő hardvert, illetve némileg különböznek tervezési elvekben is.

A GDI opaque (átlátszatlan) és aliased geometriákat (paths, lines, stb.) renderel. Továbbá tud renderelni aliased és ClearType szöveget és támogatja a transparency blendinget (áttetszőségi keverést) az AlphaBlend API által. Bárhogy is, az áttetszőség kezelése inkonzisztens. A legtöbb API egyszerűen mellőzi az alfa csatornákat, némelyik pedig használja azt. Talán az egyik legfontosabb dolog, hogy a GDI renderelés nem térképezi fel könnyen, hogy egy modern GPU mit renderel a leghatékonyabban a 3D-s részén a renderelési motornak. Például a ROP-ok (Raster Operations Pipeline) nem lehetnek megvalósítottak a keverési szakászában a GPU-nak. Bárhogy is, az alfa lehet. Egy másik példa, a Direct2D aliased vonalai úgy lettek tervezve, hogy legyenek implementáltak egyszerűen mint két darab háromszög, amik a GPU-ban renderelődnek. A GDI garantálja hogy a Bresenham féle vonal rajzolási algoritmus használt.

A Direct2D opaque (átlátszatlan), transparent (áttetsző), aliased és anti-aliased (élsimított) primitíveket renderel. Szigorúan garantálja az elfogadását és renderelését áttetsző tartalmaknak. Lehetővé teszi tervezni modern felhasználó felületeket, illetve enged renderelni minden primitívet használva hardveres gyorsítást. A Direct2D azonban nem egy tiszta szuperhalmaza a GDI-nek, a primitívek indokolatlanul lassúak volnának ahhoz, hogy implementálva legyenek egy GPU-n, amik nem a Direct2D-ben jelennek meg. Ez az egyik válasz. Tehát a Direct2D nem segít növelni a teljesítményét a GDI-nek, mivel a GDI nem használ Direct2D-t. Ugyanakkor a Direct2D használ(hat) GDI-t (interoperabilitás a régi programokkal).

A Direct2D a Direct3D-t használja, hogy elnyerje a hardveres gyorsítást. A Direct3D egy user modú display driver-t használ, amely becsomagolja a parancsfolyamokat (command streams). A Direct3D leküldi ezeket a parancsfolyamokat és erőforrásokat kernel módba a hardvernek feldolgozásra. Egy nagy előnye ennek az architektúrának, hogy egy alkalmazás tudja használni mind a Direct2D, mint a Direct3D képességeit együtt, hiszen a Direct2D is a Direct3D tetején ül.

A Windows NT 4 óta, a GDI kernel módban fut. Az alkalmazás hív GDI-t, amely aztán hívja a kernel módú hasonmását. Ott, a GDI átpasszolja a primitíveket a saját driver modelljének. Ez a driver aztán elküldi az eredményeket a globális kernel módú display drivernek. Kb. a Windows 2000 óta a GDI és a GDI driverek egy független térben futnak a kernelben, ami "session space"-nek hívott. Egy session címtér létrejön minden bejelentkezett session-höz és mindegyik példányához a GDI-nek, amik futnak függetlenül ebben a különböző kernel módú címtérben.

Mi a különbség a GDI és Direct2D hardveres gyorsítás között?

A legfontosabb különbség, hogy a Direct2D a Direct3D tetejére rétegződik, míg a GDI-nek van egy saját független megfogalmazású driver modellje. Ez a driver modell (GDI Device Driver Interface vagy DDI) megfelel a GDI primitíveknek, míg a Direct3D driver modell megfelel amit a 3D-s hardver a saját grafikus processzorában (GPU) renderel. Amikor a GDI DDI először volt definiált (a 90-es évek elején), a legtöbb megjelenítést gyorsító hardver a GDI primitíveket célozta meg. Idővel, bárhogy is, sokkal de sokkal nagyobb hangsúly helyeződött a 3D-s játék gyorsításra és kevesebb az alkalmazás gyorsításra. Ennek következtében a GDI DDI nem lett implementálva a megjelenítő driverek által, s végül, a BitBlt művelet lett egyedül igazán gyorsított és a legtöbb egyéb művelet nem.

Növekedése a megjelenítő driverek összetettségének és méretének

Időközben a képernyőillesztők egyre összetettebbé váltak, ahogy egyre jobban növekedett a komplexitása a driver 3D-s részének. A magasabb komplexitású kód hajlamos elkövetni több hibát, ezért elvárás volt áthelyezni a driver-t user módba, ahol nem okozhat rendszerújraindulást. Mint ahogy a következő ábrán is látható, a megjelenítő driver ketté-osztott egy komplex user módú komponensre és egy egyszerű kernel módú komponensre:

Nehézség a sessionök és a globális kernel címterek szinkronizálásában

Windows XP-ben egy display driver két különböző címtérben létezik, session space és kernel space. Néhány részének a drivernek szükséges válaszolni plug & play és power menedzsment eseményekre. Ez az állapot szükséges, hogy szinkronizálva legyen a driver állapotával a session címtérben. Ez egy kemény feladat és a megjelenítő driverek hajlamosak hibázni, amikor megpróbálják kezelni ezeket a különböző címtereket.

Az összetett asztal

Az összetett asztalnak szüksége van a GDI-re, hogy képes legyen renderelni egy felületre, amely aztán renderelt a Direct3D által a megjelenítőre. Ez nem lehetett könnyedén megvalósítható az XP driver modelljében, mert a GDI-nek és Direct3D-nek párhuzamos driver stack-je volt.

Ennek eredményeként, a Vista-ban a GDI DDI display driver megváltozott és implementálva lett Microsoft szállított driverek által, névlegesen Canonical Display Driver (CDD). A GDI renderelt egy rendszermemória biképre. Az ún. piszkos (dirty) régiók voltak használva frissíteni a videó memória textúrát, amelyet az ablakmenedzser használt, hogy összeállítsa a desktop-ot.

GDI renderelés a Windows 7-ben

A fő hátránya a Windows Vista driver modelljének az, hogy minden GDI ablakot megkellett tartani mind a videó memória felület, mind a rendszermemória felület által. Ezek az eredmények a rendszermemóriában válnak használttá minden nyitott GDI ablakhoz.

Ezen okokból a GDI megváltozott újra a Windows 7-ben, hogy biztosítsa, ne legyen szükség rendszermemória-felületre ablakonként. Mivel a GDI rendereléshez szükséges olvasni, módosítani, írni a rendszer-memória felületet, és mivel a CPU nem tud direktbe hozzáférni a videó-memóriához, a GDI módosítva lett, hogy rendereljen egy részébe a rekesz memóriának. A rekesz-memória lehet frissített a videó-memória felületből megtartva az ablak tartalmakat. A GDI visszatud renderelni a rekesz memóriába, és az eredmény aztán lehet visszaküldött az ablakfelületre. Mivel a rekesz-memória címezhető a GPU által, a GPU tudja gyorsítani ezeket a frissítéseket a videó-memória felületre. Például, a szöveg renderelés, BitBlt közös ROP-al, AlphaBlend, TransparentBlt, StretchBlt, mind gyorsított ebben az esetben. Továbbá, néhány művelet megkerülheti a rekesz-memóriát teljesen, úgy mint BitBlt, ColorFill.

Összehasonlítása a Direct2D és GDI gyorsításnak Windows 7-ben

A Direct2D és a GDI mindketten azonnali módú renderelési API-k, és mindkettőről elmondható (legalábbis részben), hogy hardveresen gyorsított. Akárhogyan is, van számos különbség közöttük.

Helye az erőforrásoknak

A GDI az erőforrásait részleges bitképekben kezeli, rendszer-memóriában alapértelmezésben. A Direct2D az erőforrásait a videó-memóriában, a megjelenítő adapterében kezeli. Ez azt eredményezi, hogy amikor a GDI-nek szükséges frissíteni a videó-memóriát, akkor ezt mindig a fizikai busz felett kell végrehajtani, kivéve ha az erőforrások már történetesen belemásoltak a rekesz-memória szegmensbe, vagy ha a művelet kifejezett lehet direktbe. Egy kivétel itt a bitképek, amelyek a CreateBitmapFromDxSurface API-val vannak létrehozva, amely rezidens a videó-memóriában. A Direct2D viszont egyszerűen átfordítja az ő primitívjeit Direct3D primitívekké, mivel az erőforrások már a videó memóriában vannak.

Metódusa a renderelésnek

A GDI egy nagy részét a renderelésnek a rekesz-memóriába teljesíti, használva a CPU-t. Direct2D-ben van egy translator (fordító), ami átfordítja az ő API hívásait Direct3D primitívekké, az eredmény aztán renderelt a GPU-n. Néhány GDI renderelés is a GPU-n teljesített, amikor a rekesz-memória átmásolt a videó-memória felületre, reprezentálva a GDI ablakot, vagy amikor ez lehetséges.

Méretezhetőség

A Direct2D renderelési hívásai mind független parancsfolyamok a GPU-ba. Minden Direct2D factory reprezentál egy különböző Direct3D eszközt. A GDI egyetlen parancsfolyamot használ minden alkalmazáshoz a rendszerben. A GDI metódusok eredményezhetnek felesleges költséget néhány amortizációjában a GPU és CPU renderelési kontextusnak. A Direct2D megközelítésében kevésbé szükséges a szerializáció a független parancsfolyamok között.

Elhelyezkedés

Természetesen, a Direct2D teljesen user módú, beleértve a Direct3D-t és Direct3D driver-t is. A GDI két módot használ, egy része a session térben van kernel módban, az API felülete pedig user módban.

Hozzáférhetősége a hardveres gyorsításnak

A GDI hardvergyorsított XP-n és Windows 7-en, amikor a DWM fut és amikor a WDDM 1.5 driver használatban van. A Direct2D hardvergyorsított minden körülmény között és bármilyen WDDM driveren, függetlenül attól, hogy a DWM használatban van-e. A Direct2D Vista-ra szintén visszaportolt, ugyanakkor érdemes megjegyezni, hogy a GDI Vista-n mindig a CPU-n fog renderelődni.

Prezentációs modell

Amikor a Windows először tervezve volt, nem volt elég hatékony a memória, hogy minden ablak tárolt legyen az ő bitképében. Ez azt eredményezte, hogy a GDI mindig logikailag direktbe a képernyőre renderelt, változó kivágású régiókat alkalmazván biztosítva azt, hogy ne rendereljen az ablakon kívülre. A Direct2D követ egy modellt, ahol az alkalmazás renderel egy háttér bufferba és az eredmény automatikusan tükrözött ("flipped"), amikor az elkészült a rajzolással. Ez engedi a Direct2D-nek, hogy kezeljen animációs jeleneteket folyékonyabban, mint a GDI (és villogás-mentesen).

Fontos kihangsúlyozni, hogy a GDI ezt a fajta hardveres gyorsítási eljárást csak a Windows 7 óta támogatja. Ugyanakkor érdemes figyelembe venni azt is, hogy a Direct2D XP-n majdnem biztos, hogy nem lesz elérhető. Szóval, aki arra adja a fejét, hogy framework nélküli, cool grafikával ellátott, GPU gyorsított, XP kompatibilis szoftvert készítsen, továbbra is a Direct3D 8/9 a járható út. Ugyanez igaz a játékfejlesztőkre is, mivel viszonylag elég nagy a tesztek alapján az overhead a D3D-hez képest. Viszont akinek adott a lehetőség, hogy Vista/Win7-re fejlesszen natív alkalmazásokat, annak mindenképp érdemes számolnia ezzel és végképp letenni a GDI/GDI+-ról.

Ennyit bevezetőül és szülessen az a Star Craft megfele! :D

Bocs mindenkitől, hogy mostanában nem voltam a pályán és elérhetetlen voltam, tele is van a postaláda, de el kellett intézzek néhány dolgot. Információ áradatba kellett visszatérjek, látom készül az Internet Explorer 9 is, ráadásul Direct2D lesz a prezentációs motor alatta… Látom van már Silverlight 4.0 Beta, megjött a Vista Platform Update is DirectWrite és Direct2D-vel, illetve Ribbon controlokkal, stb. Fúúú, sokmindent kell most pótolni, meg egy kis millió levélre válaszolni. :D

Indult egy új oldal azoknak, akik még csak most kezdenek ismerkedni a témával: Welcome to the Beginner Developer Learning Center

Elfelejtettem megírni, hogy megjelent az új Opera 10-es böngésző, amiben már megy a Silverlight 3.0 is. Letöltés itt. 77x jobb, mint a többi böngésző, minden tekintetben. Arról nem beszélve, hogy az Internet Explorer 8 nálam működni se akar. Már alapértelmezett böngészőnek se lehet beállítani, ráadásul tetű mind az IE, mind a FireFox az Opera-hoz képest.

Itt az új Silverlightos: Bing – VisualSearch. Egyenlőre nálam csak Internet Explorerbe akar működni.

Letöltés itt. Bejelentés itt.

Veerus & Maxie Devine Feat. Janice Robinson - Dreamer 09 (TV Rock Remix)
Schiller feat. September - Breathe (Dave Ramone Radio Edit)
Artie Cabrera feat. Lisa Pure - Rain Falls (Dj. Dove's Bright Lights Vocal Remix)
Bertie Blackman - Byrds of Prey (TV ROCK Remix)
Bingo Players feat Dan'Thony - I will follow
Inaya day vs manyus and d.j. eako - Destiny
Markus Gardeweg feat. Michael Feiner - Fairplay (Let There Be Love) (D.O.N.S & DBN Remix)
Meck feat. Dino - So Strong (Inpetto Remix)
Meck Feat. Dino - So Strong
Nadia Ali - Love Story (Andy Moor Remix)
ZoëXenia - This Must Be Really Something
MYNC Project - Something on your mind
Knife - Pass This On
Pet Shop Boys - Love Etc (Gui Boratto Mix)
Paul van Dyk & Austin Leeds - New York City (Ibiza RemiX)
Jürgen Paape & Boy Schaufler - We Love
Avicii - So Excited (Sebastien Drums & Eric G Work Machine Remix)
Late Night Alumni - Empty Streets [Seamus Haji & Paul Emmanuel Remix]
Lal Meri feat. Carmen Rizzo - Bad Things (Morgan Page Remix)
GLM Feat. Randolph - Run To You (Maurizio Gubellini Remix)
Avicii & Sebastien Drums Even Rip from Radio FG
David Guetta feat. Kelly Rowland - When Love Takes Over (Official Music Video)
Cosmic Gate feat. Emma Hewitt - Not Enough Time (Extended Mix) [HQ]
Late Night Alumni - Empty Streets [Seamus Haji & Paul Emmanuel Remix]
Soulsearcher - Can't Get Enough (Henrik B Remix) Defected
Chicane - Poppiholla (Disco Citizens Remix)
Big World & Denis The Menace - Going Back to My Roots feat Inusa Dawuda ~Only the Best House~
Three Drives On A Vinyl - Greece 2000 (Original Mix)
Delerium - Silence (Lisatt And Voltraxx Remix)
Norman Doray & Tristan Garner - Last Forever
Hook N Sling - The Best Thing (Tv Rock Remix) v1
Hook N Sling - The Best Thing (Tv Rock Remix) v2
Fao vs. Chuckie - Bass Kick In Miami Inphinitys WMC 09 Mix
DJ Dove and Milk & Sugar - Unkind (Milk & Sugar Dub Mix)
Chicane Feat Marie Brenhan - Saltwater 2009 (Paul Thomas Mix)
Axwell, Ingrosso, Angello, Laidback Luke ft. Deborah Cox - Leave The World Behind (Original Mix)
Dany P. - Nu Life (Fedde Le Grand & Funkerman Mix) *HQ
In The Air - Axwell Remix (TV Rock feat. Rudy) [HQ]
Back to Zero by Robbie Rivera (original) (HQ)
Julien Jabre - Vicious Circle (John Dahlback Club Mix)
Thomas Gold - Something's Gotta Give feat. Amanda Wilson (Nash La'salle Remix)
Faithless feat. Cass Fox - Music Matters (Mark Knight Remix - Jason Mill PowerMash)
FAITHLESS - MUSIC MATTERS (Axwell Remix) (HQ Audio)
Starsplash - Endless Fantasy
Beautiful U R (Massimo Nocito Radio Edit) - Deborah Cox
Tommy Vee and Mauro Ferrucci with Ce Ce Rogers - Stay (Thomas Gold Vocal Mix)
Da Groove Doctors Feat Tommie Nibbs - All We Need Is Love (G-Rubin Mix)
Deborah Cox - Beutiful U R
Deborah cox - beautiful U R (Massimo Nocito Remix)
JULIET - Avalon (Jacques Lu Cont Versus Remix Edit w/outro)
Dario Nuñez & David Vio feat Nieves - Be Yours (Original Mix)
David Penn & Peter Gelderblom feat. Sheylah Cuffy - Miracle Of Love (Vocal Mix)
Bucovina (Juan Magan & Marcos Rodriguez Remix)
Annagrace - Let the feelings go ( Hardwell Remix )
Dj Andrew Dee Vs. Kama & Mac Gregor And Elijah-Nova Send Me An Angel (Live Mash Up Mix) Preview Mix
CJ Stone - Shining Star (Inpetto Remix)
La Serenissima - Mike Candys & Jack Holiday (work that body remix)
Dennis The Menace -Show me a reason
Inna - Hot (Dancing in the Dark Video Edit)

Lássátok milyen jó szívű vagyok, készítettem saját kezűleg egy kis meglepetést nektek. Innen letudjátok tölteni és futtatni (fel/le nyilakkal lehet szabályozni a rakéták számát). A zene direkt ilyen nyugtató, csak hogy jó kedvetek legyen: HIM – Close To The Flame. :)

Történt egy figyelemfelhívás az MS részéről mostanában, hogy a Ribbon controlokban komolyabb változások fognak beállni, melyek keményen érinteni fogják a meglévő CTP-re épülő alkalmazásokat /az enyémet is :(/, mint pl. a RibbonCommand el lesz távolítva a RibbonControlsLibrary-ből és sokkal szorosabban fog integrálódni a WPF commanding és styling modelljéhez. Ezenfelül. jönnek majd új vezérlők is, mint pl. Gallery, SplitButton és Spinner… Még elvileg lesz egy CTP2 és a végleges V1 2009 vége/2010 eleje felé várható.

Ma bejelentették a kiadását az új Delphi, C++Builder és Delphi Prism for .NET 4.0 fejlesztőeszközöknek. A lényeg ebben van. Van ebben munka azért rendesen. Csak a compiler fejlesztéseket emelem most ki ide:

Delphi 2010 native compiler (x64 támogatás nincs):

• Enhanced in 2010! High-performance 32-bit optimizing Delphi® native code compiler, including
  High performance x86 Assembler - 32-bit inline assembler supporting the Intel® x86 instruction
  set (including Intel Pentium® Pro, Pentium III, Pentium 4, Intel MMX,™ SIMD, Streaming SIMD
  Extensions, SSE, SSE2, SSE3, SSE 4.1, SSE 4.2, AMD SSE4A and AMD® 3DNow!®
  
  
• New in 2010! Object-oriented file and directory IO classes (.NET System.IO namespace)
  
  
• New in 2010! RTTI support for exposure of Methods, Fields, and Properties to support
  dynamic invocations and other meta-programming approaches
  
  
• New in 2010! Custom attribute support for most code elements - types, fields, properties,
  methods and parameters
  
  
• Enhanced in 2010! TStringBuilder for easier and faster string concatenation and manipulation
  
  
• Generics with full RTL list and collection support
  
  
• Enhanced in 2010! Support for localized resources
  
  
• Introduced in 2009! UnicodeString type as the default string type
  
  
• Introduced in 2009! UnicodeString class
  
  
• Introduced in 2009! TObject now contains virtual methods ToString, GetHashCode, and Equals
  
  
• Introduced in 2009! Anonymous methods
  
  
• Introduced in 2009! Exit procedure takes optional Result parameter (C/C++/C# return)
  
  
• Expression evaluation in compiler directives
  
  
• Create reusable native 32-bit dynamically linked libraries (.DLL), COM controls (.OCX),
  and standalone executables
  
  
• Custom variants with support of your own data types, complex numbers, safe arrays,
  and passing variants through data sets
  
  
• Expanded variant support for Int64, unsigned types and Unicode strings
  

Delphi Prism 2010 compiler:

• New in 2010! Support for Aspect Oriented Programming (AOP)
  
  
• Parallel programming support for Futures, Parallel Loops, Asynchronous Statements,
  an improved locked directive, and more
  
  
• LINQ query expressions to combine the querying capabilities of database languages such
  as SQL and apply it to any type of data, natively within the Delphi Prism language
  
  
• Property notifications make it easy to develop solutions that follow the
  Model/View/Controller design pattern
  
  
• Nullable expressions with support for nullable types in arithmetic and other expressions
  
  
• QA Analysis Tools to provide feedback on quality of code, including Code Flow Analysis
  and FxCop Code Analysis options integrated with the compiler, and the option to enforce
  proper case when using identifiers
  
  
• Additional language features include: class contracts, Anonymous types, Anonymous
  methods and delegates, Lambda expressions, Generics, Iterators, Extension Methods,
  inline variable declaration, and Asynchronous methods + C# 4.0 features
  
  
• .NET 1.1, 2.0, 3.0, 3.5 and 4.0
  
  
• .NET Compact Framework 1.0 and 2 (No designer support)
  
  
• Mono, including Linux and Mac OSX
  
  
• Code-level support for Cocoa# and Gtk#

Mindez kiegészül a Windows 7, Windows Vista és XP összes API-ának támogatásával, beleértve az új Windows 7 Direct2D támogatást, illetve az új touch technológiát minden kiadásán a Windowsnak. C++Builder fejlesztőknek C++0x szabvány támogatás és .NET API access for C++. A próba verzió innen letölthető. Az ára biztos, hogy egy vagyon lesz. :)

Nagyon megy ez a touch őrület mostanában: MonoTouch and Delphi Prism (.NET). Csak vas is kééééne hozzá olcsón wazze!!!

Gondoltam egy kicsit kipofozom a Vista-t, köszönet érte a VistaGlazz nevű alkalmazásnak. Rengeteg szép téma érhető el egyébként Vista-hoz, többek között Windows 7 stílus is, így én is kerestem egyet, majd bemásoltam a C:\Windows\Resources\Theme mappába, és beállogatva a dolgokat egyszer csak elkezdett működni a dolog:

Na most az odáig még hagyján, hogy elkezdett működni, de a Vista azóta sokkal gyorsabb is lett, mint a beépített stílussal volt.

Szépen dolgoznak a srácok natív oldalon is. Legalább az eddigi natív alkalmazások is képesek lesznek kihasználni mindenfajta komolyabb megeröltetés nélkül az új technológiák adotta lehetőségeket. Mit értek ezalatt? Kukkancsátok meg ezt (ja, és elvileg ez nemcsak Windows 7-el megy). A RAD Studio 2010 már képes lesz x64-es kódot is fordítani, továbbá a teljes DPL (Delphi Parallel Library)-t tartalmazni fogja. Ezenfelül egy új adatkötési modellt is tartalmazni fog, mely nemcsak Data Source, hanem bármilyen objektummal képes lesz együttműködni. A Delphi Prism .NET compiler úgyszint sok új szolgáltatással bővül, mint pl. dinamikus típusok támogatása, lambda kifejezések testtel, generikus típus variancok, csak olvasható osztályok, volatile fieldek, új tartomány típusok (var x := 10..20), unmagelt exportok…

A legfrisebb hírek itt: RAD Studio 2010 Preview Center