1. Ablak kezelés

A rendszer átalakítását egészen az alapoknál kezdtük, mindjárt magának a Windows-nak az ablak-kezelőjénél. A Windows alaphelyzetben az egyes ablakok tartalmát, az ún. window context-et másolásolja a képernyőre, bitmap mozgatással (BitBlt). Ennek a megoldásnak azonban sok hátránya van. Többek között az, hogy több megjelenített elem esetén azokat először egyetlen windows bitmap-ben kell összemásolni (renderelni), ami több ezer objektum esetén eléggé fáradságos és időigényes művelet, másrészt ha nagyítani kell, az objektumokat külön-külön kell felnagyítani, majd megint összerakni. Nem megoldott továbbá, hogy több szinten (layeren) lehessen objektumokat rajzolni.

1.1. Window rendering

A Windows context renderelője helyére saját megoldás került, ami kapásból kétszer gyorsabb, mint elődje, de van sok további alapvető különbség is. Az itt szereplő sebesség adatok egy 3,4 GHz sebességű i7-3770 CPU-val és Nvidia GTX 650-es grafikus kártyával szerelt gépen mértek.

Sebesség növekedés összetevői:
Rendszer elem	Korábbi	Új	Sebesség növekedés
1. Window context redering Full HD kép megjelenítése	5 ms	2 ms	2,5 - szeres

1.2. Vektorgrafika alap szinten

A rajz a layeren nem bitmap többé, hanem egy vektor sík, amiből a Window tartalma a vektorgrafikából ismert supersampling eljárással készül. Ezáltal az objektumok tetszőlegesen nagyíthatók anélkül, hogy bármit újra kellene rajzolni, ill. helyette az alap szinten implementált ablak megjelenítő végzi ezt a műveletet, ami így sokkal gyorsabb, de főleg sokkal kényelmesebb:

Rendszer elem	Korábbi	Új	Sebesség növekedés
2. Vektorgrafika	egyedileg kellett az objektumokat újrarajzolni	Supersampling	kb. 3 - szoros

Ez a technika akkor mutatja meg a hatását, ha egy ablakba belenagyítunk. Eddig ez úgy ment, hogy átméreteztük az ablakot, és ha a kép ablakmérethez igazított volt, akkor az egér elengedésekor – némi várakozás után – megjelent az új, nagyított kép, miután mindent újrarajzoltunk. Mostantól ez folytonos, mivel nem kell semmit újrarajzolni, tehát nem is kell annyit várni. Az ablak tartalmát ezentúl magában az ablakban is felnagyíthatjuk a görgetővel, és szerkesztés közben is választhatunk vektoros és pixelgrafikus nagyítás között. Hovatovább a nagyítás animált, vagyis eléggé látványos.

1.3. Multilayer technológia

A harmadik fontos különbség, hogy mindez egyszerre több síkon is lehetséges, amelyek teljesen önálló pozícióval, átlátszósággal és nagyítással rendelkeznek! Ez talán a legfontosabb és leghatásosabb különbség. Az új ablak kezelő a layerek egymásra másolásával jeleníti meg a képet, vagyis a síkok rendeleréséről nem a VISION-nek kell gondoskodnia, következésképp annak nincs processzoridő igénye sem. Ellenben ezt a műveletet maga az ablak kezelő végzi, ami megint sokkal hatékonyabb:

Rendszer elem	Korábbi	Új	Sebesség növekedés
3. Többszintű rederelés	egyedi objektum összmásolás	multi-layer technológia	változatlan kép esetén kb. 2 - szeres; de: ügyes layer-struktúrával akár 10-szeres is lehet

Egyszerű gondolatsorral belátható, miért sokkal gyorsabb ez az eljárás összességében. Képzeljük el, hogy csak egy animációt frissítünk a képen, ami önálló layeren van, az egész bonyolult kép pedig egy másikon. Ezen a szinten a frissítés sebessége csak ettől az egyetlen objektumtól függ, hisz rajta kívül nincs semmi más, nem ütközik semmivel, miatta nem kell semmit újrarajzolni. Most a változást az új ablak kezelőnek kell összemásolnia a másik layer tartalmával. Tehát mintha csak átadtuk volna a munkát egy további szintnek – első ránézésre úgy tűnik, nem spóroltunk meg semmit. Igenám, de a renderelés csak abban négyszögben szükséges, amiben az objektum van; adott esetben csupán 64x64 pixelt érint a művelet ahelyett, hogy az egész full-HD képet újrarajzolnánk.

Ennél azonban fontosabb, hogy a rendszernek sokkal több szabadságot biztosít. Eddig ugyebár csak két szintünk volt: egy statikus és egy dinamikus. Mostantól akár 32 különböző szintünk is lehet, teljesen eltérő dinamikával, ciklus idővel. A layerek egymástól függetlenül nagyíthatók, mozgathatók, átlátszóvá tehetők vagy eltüntethetők feltételesen.

Visszatérve ahhoz a problémához, hogyan nagyítsuk egy ablak tartalmát, mindenek előtt azt kell megértenünk, hogy egy ablaknak nem minden elemét kell nagyítanunk általában és szinte sohasem egyformán. Például a fejlécben található menüsort nem, de egy táblázatban lévő szöveget sem kell, csupán a táblázatot magát. Aztán vannak kötések jobbra, balra, le, fel, ami megint azt eredményezi, hogy az egyes objektumokat teljesen eltérő módon kell hozzáigazítani a változó méretű ablaktartalomhoz. Na pontosan ezért nem lehetett “normálisan” megoldani a vektorgrafikus képek nagyítását a korábbi verzióban, amikor is csak egy síkunk volt, mert vagy mindig azonos pixelméretűek voltak az objetumaink és kötöttek az ablakszélekhez, vagy változó méretűek, azaz nagyíthatóak, de akkor nagyított a program mindent, a fejlécben található menüt is és az összes szöveget.

A multilayer technika változást hoz ezen a téren. A menüket, ribbon kontrol sort, sőt az egész template-et is felrajzolhatjuk egy külön layer-re, amit nem nagyítunk (csak az ablakszélhez kötünk). Egy másik része a képnek közben nagyítható; egy hamadik, egy táblázat mondjuk, csak átméreteződik stb. Ráadásul a nagyítás lehet arányos, központosított stb.

A multilayer technológia sok előnnyel jár és sok új lehetőséget teremt, miközben minden sokkal gyorsabb is lett, mint korábban.

2. Windows rajzelemek cseréje

Megint az a kérdés vetődhet fel az olvasóban, hogy erre mi szükség volt? Valójában nagyon sok oka van. Például az előző fejezetben ismertetett vektorgrafikus rajzolást sem tudtuk volna megoldani, de probléma volt az is, hogy a Windows nem elég gyors. Ez desktop környezetben nem annyira zavaró (a felhasználó nem veszi észre, ha fél másodperc alatt rajzolunk fel egy képet), de Web-es környezetben már problémát okozott, ha egyszerre mondjuk 20-an léptek rá a szerverre (20x0.5sec!). Ráadásul a Windows saját rajzelemei nem támogatják a multithreading-et, így még az a lehetőség is elmaradt, hogy a rajzolást több szálon futtatva gyorsítsuk. Nem véletlenül használ saját rajzoló rutinokat a legtöbb Web browser is; a Webkit alapú rendszerek még a betűket is maguk festik, ahogy mi is.

A képelemek rajzolása a VISION X10 változattól kezdve sokkal gyorsabb, futtatható több szálon, s persze támogatja a supersampling-et, ami a vektorgrafikához kell.

2.1. Szövegek kirajzolása

Akármilyen durván hangzik, mostantól a Truetype fontok minden egyes pixelét VISION rutinnal rajzoljuk fel – kihagyva a Windowst és vele az idióta Clear-Type-ot. Mint a legtöbb Web browser! Nem volt egyszerű feladat, mivel a fontrajzolás rendkívül sok megfontolást igényel – korrekt nagyíthatóság, antialiasing, stílusok, lumineszcenciától való függőségek stb. –, de végül megoldottuk. S ha már hozzányúltunk, kibővítettük a fontok stíluskészletét is pár hasznos új típussal. Ilyen a hullámmal való aláhúzás hibás állapot megjelenítésére, a gradiens színátmenet és a karakterek, sorok távolságának az állíthatósága (mint a CorelDraw-ban). De a legfontosabb eredmény ez:

Rendszer elem	Korábbi	Új	Sebesség növekedés
4. Betű rajzoló	Windows	VISION	20 - szoros!

Ez annyira hatásos változtatásnak bizonyult, hogy a VISION X9.64 változatába is betettük. A leglátványosabban a változó szerkesztőben lehet látni a sebesség növekedést, amikor a strukturált változók 50 oszlopos listáját görgetjük: nincs semmilyen megakadás, akárhogy rángatjuk is az egeret, pedig százával kell szélsimított truetype szövegeket köpni a képre.

2.2. PNG rajzoló

Sajnos a PNG rajzoló is elég gyenge volt, ami a sebességet illeti. Ez persze nem véletlen, hisz egyrészt a PNG fájlok tömörítettek, ezért felrajzolás előtt ki kell bontani őket, másrészt a PNG alpha layerét össze kell renderelni a képháttérrel. S akkor a képet még csak nem is nagyítottuk. Az új rajzoló pedig:

Rendszer elem	Korábbi	Új	Sebesség növekedés
5. PNG rajzoló	Embarcadero	Vision	23 - szoros!

A sebesség növekedés fő oka az, hogy az alpha rendering a Windows context renderelőjébe lett beépítve. Remélem, ezen a ponton kezdi élvezni a kedves olvasó ezt az amúgy megjelehetősen száraz, a néhány szektás rendszerprogramozón kívül mást nem érdeklő témát! J

2.3. Bmp, Jpg, Gif…

Ezekből is a leghatékonyabb megoldások kerültek a programba. Például a Jpeg-re maga az Intel gyártotta az eljárást a saját processzorára optimalizálva. Állítólag ennél nincs jobb.

A legfontosabb változás azonban, hogy az összes bitmap korrektül nagyítható és kicsinyíthető ezentúl. A korábbi, tisztán pixeles nagyítás helyébe komoly pixelprocessing lép. Például a nagyítás az ún. bidirectional interpolation nevű elrárással valósul meg kontraszt korrekcióval, a kicsinyítés pedig a leglátványosabb eredményt biztosító, már említett supersamplinggel. Ezáltal még az MS-Word képnagyítójánál is szebb eredményt kapunk, pedig a Word-be épített megoldás egyike a legjobbaknak a világon.

Minden bitmap forgatható, perspektívába állítható, lehet áttettsző stb. Ezek egy része eddig is létezett, lehetett például a bitmapet átlátszóvá tenni, de csak Windows Bmp-t. Mostantól nincs korlát és még a gradiens transzparencia is lehet bármilyen szögű.

Végül, de nem utolsó sorban bekerült a színkorrekció lehetősége a programba (világosság, kontraszt, színdinamika), és lehet azonos átlagos tónust is forszírozni. Hol van erre szükség? Manapság egyre gyakrabban rakunk flat ikonokat a képre és egyszínűeket, hogy ne a szinkavalkád vonja el a felhasználó figyelmét (ld. flat design). Ezért fekete fehér konverziót kérünk a programtól. Majd észrevesszük, hogy a korábban színes ikonjaink a feketétől az egészen világos szürkéig változtatják a tónusukat. Az említett opcióval azonban ez mostantól kiegyenlíthető.

3. Fordító

Teljesen új, sokkal gyorsabb fordítóprogram került a VISION-be, ami képes a korábbi XSDL képleírók feldolgozására, de persze sok új lehetőséget is rejt. A hatékonyabb eljárás rendkívüli eredménnyel járt:

Megszűntek az objekt fájlok!

A program ezentúl közvetlenül a forrásból dolgozik, mint a Javascript alapú rendszerek is például. A belső fordító JIT (Just-In-Time) alapon működik, vagyis amikor egy új képre váltunk, beolvassuk a szövegfájlt és már nézhetjük is a képet. Egy átlagos kép esetén a feldolgozási idő 5 ms (a korábbi kb. 200ms-os linkelési időhöz képest!).

A fordítóra eddig azért volt szükség, mert az objekt fájlok linkelése jóval gyorsabb volt, mintha mindig mindent újrafordítottunk volna. Mivel azonban ez a probléma megszűnt, hisz a források fordítása baromi gyors lett, objekt fájlokra sincs szükség többé! Mit jelent ez a baromi gyors?

Az egyik legnagyobb projektünk 75,000 változóból álló változó listájának a lefordítása mindössze 850ms, vagyis kevesebb, mint 1 másodperc az új rendszerben. A korábbi változatban ez 3 perc volt, ami durvan 200-szoros sebesség növekedés! Az igazsághoz tartozik, hogy ez nem általános, mivel a változófájl fordítása korábban a mérettel négyzetesen nőtt, az új rendszerben azonban közel linerálisan. Vagyis kisebb var fájlok esetén az eltérés is kisebb, de mindenképpen igen jelentős, átlagosan kb. 50-szeres. Erre ugyanakkor szükségünk is van, hisz az objekt fájl megszűnt, s mivel a lefordított var fájlt a régi rendszer is viszonylag gyorsan betöltötte, most ezzel a gyorsabb szöveg alapú JIT fordítónak kell versenyeznie.

A képfájlok és a többi taszk fordítása is sokkal gyorsabb lett, de ott nem olyan látványos az eltérés, mint a var fájlok estén. Viszont még így is sokkal gyorsabb még a régi OBJ betöltésénél is linkelésénél is.

Az összes forrásfájlt figyelembe véve a fordító átlagos sebességnövekedése:

Rendszer elem	Korábbi	Új	Sebesség növekedés
6. Fordító	Vision X9	Vision X10	15 – szörös!

4. Futtatás

Ami a kód futtatását illeti, a legnagyobb változás a képek objekt listájának a kiértékelésénél van, itt minimum 100-szoros a sebességnövekedés, azonban a többi rendszer objektum esetén (ciklikus program, alarm stb.) csak kb. 2,5-szeres. A végrehajtható kód sebessége régi rendszerben is nagyon gyors volt, de még ezt is sikerült túlszárnyalni:

Rendszer elem	Korábbi	Új	Sebesség növekedés
7. Futtató	Vision X9	Vision X10	2,5 - szeres!