:

Szerző: Gálffy Csaba

2012. december 14. 08:47

Kipróbáltuk: kijelzőskálázódás Windows 8 alatt

Már több, nagy pixelsűrűségű panellel szerelt noteszgép esetében kifogásoltuk a Windows skálázódását. Most összefoglaltuk tapasztalatainkat, bőséges mennyiségű képpel is.

Ha egyetlen nagy tech-trendet kellene kiemelni 2012-ből, valószínűleg a minden korábbinál magasabb pixelsűrűségű kijelzőkre tenném a voksom. Az első Full HD okostelefontól a retinás MacBookokig és az év végére a felső kategóriában általánossá váló, szintén Full HD felbontású ultrabookokig egyszerre minden termékkategóriában felismerték a gyártók, hogy az egységnyi felületre jutó pixelszám növekedését a felhasználói érdeklődés is követi.

A nagy pixelsűrűséget azonban az operációs rendszernek is nagyon jól kell kezelnie, másképp túl apróvá válnak a felületelemek, olvashatatlan a szöveg, nehezen érinthető a virtuális gomb. A problémára minden operációs rendszer más megoldást választott. Android alatt például csak virtuális pixeleket célozhat meg a fejlesztő, ezeket a pontos képernyőméret és pixelsűrűség ismeretében az operációs rendszer fordítja le képelemekre, így minden kijelzőn nagyjából azonosan néz ki az alkalmazás. Ezzel szemben iOS alatt semmilyen felbontásfüggetlenség nincs, a kijelzőt a fejlesztő pontosan ismeri, arra közvetlenül rajzolhat. Emiatt az Apple mobil "retina" kijelzői rendszerint a korábbi generáció pixelszámát négyszerezik meg, így a visszafelé kompatibilitás garantált.

Így csinálja a Microsoft

A Windows-ban az XP óta megtalálható a skálázódás, ami a különböző verziók alatt sokat fejlődött. A Windows 8-ban ez a funkció a Control Panel - Appearance and Personalization - Display menüpontjában állítható, alapértelmezésben három fokozatban, 100-125-150 százalékos nagyításra, de tetszőleges egyéb skálázódás is beállítható. A globális változó hatására az alkalmazások kétféleképp viselkedhetnek: amelyek esetében a fejlesztő nem állította be a DPI-aware flaget, azok esetében csak az alkalmazás körítése (címsor, ablakkeret, menüsor) áll át az új beállításra, a többi elem változatlanul marad. A második csoport a skálázódásra figyelő alkalmazásoké, ezek esetében a fejlesztő beállítja a DPI-aware flaget, az alkalmazás képe pedig annak megfelelően alakul át - a felületelem (szövegdobozok, gombok) és a betűk mérete megnő, a bitmapek esetében pedig az alkalmazás a nagyobb felbontású képeket húzza elő (ha vannak ilyenek).

Nem túl bonyolult.

A Windows megoldása ugyanakkor nem kínál pixelpontos nagyítást, a pixelsűrűség megkétszerezésével és a skálázódás duplázásával nem marad minden pontosan ugyanolyan, csak élesebb. Ennek oka, hogy a rendszer egyes elemek esetében relatív, máshol abszolút értékeket használ, emiatt a skálázódás furán eltorzítja az alkalmazások képét. A problémát súlyosbítja a szövegmegjelenítésben használatos hinting is. Összehasonlításképp itt a Windows Intéző ablaka eredeti formában (100%), illetve 150 százalékra skálázva, majd visszaméretezve.

Nem pixelpontos.

Így csinálja az Apple

Az asztali operációs rendszerek világában idén nyáron, a "retina" MacBook Pro megjelenésével került az érdeklődés középpontjába a nagy pixelsűrűség, az Apple OS X ezen a téren egészen új megközelítésben hoz sokkal jobb felhasználói élményt. A lényeg, hogy alapértelmezésben a rMBP kijelzője egyszerűen ugyanazt jeleníti meg mint az előd, csupán kétszer akkora részletességgel, az iPhone 3GS - iPhone 4 vagy az iPad 2 - iPad 3 váltáshoz hasonlóan. A kijelző natív felbontása 2560x1600 pixel, vagyis pontosan négyszer annyi képelemet tartalmaz mint a korábbi generáció 1280x800 pixeles panelje. Ennek hatása a képminőség javulása igen látványos, a betűtípusok gyönyörűek, finom rajzolatúak, a képek pedig látványos részletességgel képesek megjelenni.

A szebb rajzolat elegendő is egy konzumer eszköz esetében, a haladó felhasználókat megcélzó MacBook Prók azonban nem állnak itt meg, a nagyfelbontású kijelzőn más megjelenítési módok is elérhetőek. A kétszeres nagyítás mellett ugyanis törtszámú nagyítást is képes helyesen kezelni a rendszer, így elérhető 1440x900 és 1680x1050 felbontásnak megfelelő megjelenítés is. Azért “megfelelő”, mert a kijelző ilyenkor is natív felbontáson működik, csupán a felületet méretezi másképp az operációs rendszer. Az eredmény: végre nem kell a vásárlásnál választani, hogy “nagyobb betűket” vagy “több területet” szeretnénk, ezt ugyanis folyamatosan, feladattól függően lehet változtatni.

Mivel a nagy felbontású panel maximális kihasználásához szükség van a külső fejlesztőkre is, kiváló üzleti döntésnek bizonyult a 15-ös modell idő előtti piacra dobása. A limitált érdeklődésre számot tartó termék ugyanis kiváló tesztkörnyezetnek bizonyult, a várhatóan sokszorosan népszerűbb 13-as modell piaci rajtjára pedig már készen álltak a teljes mértékben "retinás" alkalmazások. A rövid tesztünk során csak néhány alkalmazást találtunk, amelyek nem támogatják a nagy felbontást, így a Steam maces kliense vagy a Diablo 3 telepítője - ezeket egyébként tipikusan percekig kell nézni, míg a megfelelő játék letöltődik. Az egyetlen, széles körben használt alkalmazás, amely nem támogatja a kijelzőt, a Mozilla Firefox, a böngészőt fejlesztő közösségnek máig nem sikerült ezt az egyébként nem túl bonyolult problémát megoldani - a Google Chrome vagy épp a Microsoft Office esetében a fejlesztők tempósan kiadták a megfelelő frissítést és támogatják a nagy felbontást.

Az Apple esetében a nagyítások a megközelítésből adódóan mindig pixelpontosak, vagyis a felület minden eleme relatíve skálázódik, nem keverednek fix és rugalmas elemek. Emiatt a felhasználó első látásra nem is érzékeli érdemben a különbséget egy retinás és egy sima rendszer képe között, az egyetlen eltérés, hogy az új modell képe sokkal élesebb.

Itt relatív, ott abszolút

A retina MacBook Pro utáni érdeklődést meglovagolva a windowsos gyártók is elkezdték magukból ontani a nagy pixelsűrűségű kijelzővel ellátott noteszgépeket, tableteket. A Windows 8 skálázódása azonban sajnos igencsak felemás, a rendszert szemmel láthatóan nem ilyen kijelzőkre tervezték, a skálázódás még most, a Windows XP után 11 évvel is csak egy utógondolat. Legjobb példa erre, hogy a rendszer rengeteg helyen pixelekben megadott felületi elemeket rajzol, függetlenül attól, hogy mekkora skálázódást állítunk be. Tipikus példa: a lenyíló menükben a doboz eleje és a benne található első betű között fix a távolság, ez pedig teljesen független a fejlesztő szándékától.

100% és 150% - az elem nem skálázódik

Ugyanígy, ha egy alkalmazás több nyitott ablakkal rendelkezik, akkor azt a rendszer finoman jelzi a tálcán, de a "fülek" szélessége fix méretű, nagy pixelsűrűségű kijelzőkön már alig láthatók. Hasonló példák tucatjait lehet felhozni megfelelő mennyiségű pixelbogarászás után, a lényeg, hogy már a rendszer programozása során sem fordított a Microsoft figyelmet a globális skálázódásra.

A betűk is

A Windows és az OS X különböző filozófiája sok helyen más megoldásokat eredményez. Például a két rendszer alapvetően eltérő megközelítést használ a fontok megjelenítésére, a Microsoft platformján a ClearType használja a hintinget, az Apple azonban elzárkózik attól. A hinting röviden összefoglalva azt jelenti, hogy például egy 10,5 pixel magas T betű felső élét a Windows a fizikai pixelrácshoz fogja igazítani, így az éles marad, míg az OS X ragaszkodik a fél pixelsorhoz, így a T felső éle szürke lesz.

Arial 12 és 14-es méret - ugyanaz a betűtípus?

Az eltérő megközelítés azt jelenti, hogy normál esetben Windows alatt a betűk tűélesek, míg OS X-en picit homályosnak, "szőrösnek" tűnnek. A probléma akkor jelentkezik, ha a betűk méretét megváltoztatjuk, ilyenkor a hintingnek köszönhetően minden méret gyakorlatilag más betűtípust jelent a kijelzőn, ahogy a Windows próbálja a pixelrácshoz igazítani a függőleges és vízszintes elemeket, függetlenül attól, hogy a vektoros grafika mit diktál. A probléma jól megfigyelhető például az Arial 12-es és 14-es mérete közti különbségnél, míg a kisebb méretnél a szárak egy pixel vastagságúak, a nagyobbnál ez már két pixel - maradt ugyanaz a betűtípus, mégis, mintha egyszerre félkövérre váltottunk volna.

CI/CD-vel folytatódik az AWS hazai online meetup-sorozata!

A sorozat december 12-i, ötödik állomásán bemutatjuk az AWS CodeCatalyst platformot, és a nyílt forráskódú Daggert is.

CI/CD-vel folytatódik az AWS hazai online meetup-sorozata! A sorozat december 12-i, ötödik állomásán bemutatjuk az AWS CodeCatalyst platformot, és a nyílt forráskódú Daggert is.

Ez a probléma jelentkezik a skálázódásnál is. Ugyan a betűk vektoros grafikai elemek, vagyis nagyítással nem válnak homályossá, pixelessé, a hinting miatt a Windows felületei elemeit felskálázva mintha az összes betűtípust lecserélték volna. Tény, az olvashatóság semmiben nem csorbul, az operációs rendszer konzisztenciája azonban ezen a szinten is teljesen megbomlik, egész más képet ad a Windows kinagyítva.

Alkalmazás, az nincs hozzá

A csupasz operációs rendszer legtöbb eleme egészen jól kezeli a skálázódást, az ikonok, illetve a legtöbb beépített bitmap támogatja a nagyobb pixelsűrűséget, mellékelve van rendszerint nagyobb felbontású változat is, amit magas DPI-beállítás mellett húz elő a rendszer. A Windows skálázódásának azonban nagy problémája, hogy gyakorlatilag egyetlen külső alkalmazás sem tartja tiszteletben, mi több, a Microsoft saját alkalmazásai is elvesztik néha a fonalat. Ennek jó példája  a WordPad, ennek egyes ikonjai nagy felbontással, mások pedig alacsony felbontással jelennek meg, teljesen véletlenszerűen.

Fix távolság a szövegboxnál és homályos bitmapek az ikonok egy részén [+]

A Microsoft-tulajdonú Skype legújabb verziója is semmibe veszi a rendszerszintű beállításokat és csak a címsort, illetve a menüsort méretezi, a főablak többi része marad apró, beleértve a szöveget, képeket. Az Office vagy a Visual Studio esetében is működik a skálázódás, egyes bitmapes felületelemek azonban maradnak homályosak, mások már új, nagy felbontású assetekből dolgoznak - összességében a programok jól használható nagy pixelsűrűségű kijelzőkön is, de észrevehetők a különbségek a 100 százalékra állított és a nagyított verziók között.

A címsor és a menü megnőtt, a többi maradt apró [+]

A külső, Microsofttól független alkalmazások esetében a skálázódás támogatása egészen elkeserítő. Gyakorlatilag bármely alkalmazást vizsgáltuk, a Mozilla Firefoxtól a Google Chrome-on át az Adobe Readerig, szinte minden alkalmazás elbukott a teszten, kisebb-nagyobb, akár a használhatóságot és a funkcionalitást befolyásoló hibákat mutatott. Az egyik "átmenő" a Dropbox volt, az apró vezérlőpult mindent tud amit a microsoftos alkalmazások skálázódás tekintetében.

A Dropboxnak jár a dicséret [+]

A fülek szélessége nem skálázódik [+]

További probléma, hogy a rendszer és a Windows nem támogatja a menet közbeni átméretezést. A "nagyításhoz" vagy "kicsinyítéshez" ki kell jelentkezni, ami nyilván az alkalmazások grafikus felületének újrarajzolása miatt szükséges, ez persze azt is jelenti, hogy munka közben ez a forgatókönyv teljességgel esélytelen. Itt megint a "másik" operációs rendszerre mutogatunk, az Apple-nek sikerült megoldania, hogy a skálázódás bármikor állítható legyen, segédprogrammal pedig akár kettő kattintással megnövelhetjük az asztalon rendelkezésünkre álló helyet.

További elrettentő példák:

iTunes 11 [+]

Google Earth [+]

Konklúzió

Nem érdemes kertelni: a Microsoft operációs rendszerén jelenleg gyakorlatilag használhatatlan az Asztal skálázódása. Ez a felhasználók elsöprő többsége számára nem problémás, az új generációs, nagy pixelsűrűségű kijelzőket használók életét viszont képes nagyon megkeseríteni. A helyzet másik nagy vesztesei a számítógépgyártók, amelyek szeretnének az új retinás MacBookokkal szemben valódi ellenfeleket állítani, a Windows képességein azonban nem áll módjukban változtatni. A gyártókat a tabletes felhasználás is szorítja, a drágább modellekben ma már abszolút elvárás a nagysűrűségű kijelző - ezt a Microsoft is jól tudja, a Surface Pro januárban érkező, 10,6 hüvelykes Full HD panelje is ezt igazolja.

A helyzetet várakozásaink szerint a jövőben sem fog változni. A Windows 8-ban a Microsoft várhatóan már nem fogja javítani az alapjaiban hibás implementációt, így leghamarabb a "Windows 9" hozhat előrelépést ezen a téren - addig azonban a nagyon magas pixelsűrűségű panelek a windowsos felhasználóknak elérhetetlenek maradnak. A HWSW tapasztalatai szerint a használhatóság abszolút felső határa mintegy 150 pixel/hüvelykes sűrűség, efölött már kényelmetlenné válik a munka még a jó szeműek számára is. Összehasonlításképp a 13 hüvelykes "retinás" MacBook Pro pixelsűrűsége 226 pixel/hüvelyk, az ASUS UX21A 11,6 hüvelykes Full HD panelje pedig 189 ppi sűrűségű.

November 25-26-án 6 alkalmas K8s security és 10 alkalmas, a Go és a cloud native szoftverfejlesztés alapjaiba bevezető képzéseket indítunk. Az élő képzések órái utólag is visszanézhetők, és munkaidő végén kezdődnek.

a címlapról