Magyar Opera

Címkék » core


Opera 12.5 újítások (b1577)

A végleges Opera 12.02 már ma megjelent, a 12.5 alias Marlin viszont még csak a távoli(?) jövő zenéje. Ebben a fejlesztési szakaszban pedig jellemző (legalábbis mostanában, hisz' nem volt ez mindig így), hogy a szorgos javítgatások mellett időről-időre komolyabb újdonság kap helyet a böngésző lelkét jelentő Presto renderelő motorban.

Érdekes módon a legutóbbi nagy javítás szinte egybeesett a 12.01 érkezésével, két nappal később jött, most viszont ugyanennyivel előzi a 12.02-t. Az, hogy az ezekről szóló cikkek nálunk pontosan egybeesnek inkább a mi hibánk...

De vissza a 12.50.1577 újdonságaihoz, mert akad belőlük jócskán. Illetve esetenként az az új, hogy bekerültek a fősodorba, hiszen a teljes képernyős (Fullscreen) API, vagy az SPDY protokoll támogatás nem új azoknak, akik  bő másfél hónapja már olvasták a Labs kiadásról szóló cikkünket. Ezek tehát helyet kapnak majd a 12.5-ben, ha nem is pont ebben a formában. A Fullscreen API ugyanis még a februári szabványvázlatot tükrözi, de az Operánál már dolgoznak a frissebb, júliusi állapot kódba öntésén. Hiába, ezek még nem kiforrott technikák.

Ami viszont az és már régóta hiányolható a böngészőből, az a színprofilok támogatása. Arról van szó, hogy bizonyos képtípusokban lehetőség van a kép adatain túl extra információk elhelyezésére, például a színtér definiálására, amiknek inkább professzionális felhasználásnál lehet jelentősége. Viszont bizonyos webhelyeken már használatosak egy ideje és a különbség igen látványos lehet.

Vegyük például a lenti képet a kissé lökött Opera alkalmazott Bruce-ról, aki - bár a kép alapján ki nem találnánk - meglehetősen otthon van a HTML5 területén, olyannyira, hogy könyvet is írt róla. Ha a böngésződben a felső képen is inkább navii-nak látszik, mintsem embernek (azaz kék a bőre), akkor nem támogatott a színprofilok használata. Mint a 12.50.1577 előtt egyik Operában sem.

Bonyolítja a dolgot, hogy alapvetően két fő verzió létezik, a v2 és a v4 (a legfrissebb egészen pontosan a v4.3). Egyes böngészők - például a Chrome - csak az előbbit támogatják, mások - például az IE9 és most már végre az Opera is! - az utóbbit is. Az ICC honlapján lévő tesztkép alapján erről mi is meggyőződhetünk. Ha a kép teljesen normális, böngészőnk a v4-et támogatja. Ha két negyed is furcsa színű, akkor v2-ről van szó, ha pedig mind a négy rész torz, akkor még nem frissítettük az Operánkat a legfrissebb előzetesre.

A dolog gyakorlati hasznát talán jobban le lehet mérni más példákkal. A megadott oldalon számos képet látunk, alattuk linkekkel. A felső sorbeli gombokra  állva megnézhetjük, hogy az egyes színterek milyen különbséget jelentenek. Az alsó soron végigmenve ugyanezeket láthatjuk, de már beágyazott színprofillal, aminek segítségével a böngésző - elvileg - ugyanazt az eredményt adja minden esetben, változást tehát nem tapasztalunk.

Ha már kiörvendeztük magunkat, lépjünk is túl ezen, hiszen van még más is. Nem is olyan régen az Operánál úgy döntöttek - jól vagy rosszul ezt most ne feszegessük - hogy mások mellett süllyesztőbe teszik a Unite-ot és a minialkalmazásokat, hogy jobban a kiegészítőkre fókuszálhassanak. Amikre rá is fér a támogatás, hiszen még a Chrome-os megfelelőikben is több a potenciál, nemhogy a firefoxos változatban.

Persze csak lépésről-lépésre haladnak, most például a környezeti menü (Context Menu) API került bele, aminek segítségével a fejlesztők képesek elemeket hozzáadatni az Opera környezeti menüihez. Az erre fogékonyak itt olvashatják az API dokumentációját.

Ezen felül jutott még a jövevénybe fordított lista (HTML5-ös reversed ol), valamint beágyazott @media támogatás, ezekről bővebben az ODIN blogon lehet olvasni. De hozzányúltak a billentyűzet kezeléshez is, amit főleg a Mac tulajdonosok fognak értékelni. A többieknek marad a lehetőség, hogy billentyűzettel jelöljenek ki szöveget.

Mindezen túl érkezett még egy raklapnyi javítás és apró optimalizáció a WebGL-hez, a Dragonfly-hoz, a hálózat kezeléshez és úgy általában az Operához. Egy jópofa újítás a ráncfelvarrott opera:cpu, ami már négyzet alakú narancssárga jelölőket használ, de ami sokkal fontosabb: a fülek listájában szereplő kis vissza-nyílra kattintva, alul windows feladatkezelős stílusú grafikonban tájékoztat az adott oldal időbeli processzor-éhségéről, ami további segítséget jelent a gépet "megfogó" renitens oldalak felkutatásában és elliminálásában.

A sok jó mellé pár bug is jutott: a Gyorshívó bejegyzései automatikus frissítés után kiüresedhetnek, illetve - és ez a durvább - Linux/Unix alatt minden beépülő fagy...

Ha még mindig érdekel, a teljes változási közleményt megtalálod a Desktop Team bejegyzésében.

Letöltés (Opera 12.50.1577):

A nagy nyári Core frissítés (b1538)

Mindig örömteli, ha hosszas hallgatás után a Desktop Team blogon új verzió jelenik meg. Hát még ha olyan hosszú a lista, mint a most pénteki kiadásé. Mindezt annak dacára, hogy éppen a nyári szabadságolási szezonban vagyunk.

A legtöbb változás az oldalak összeállítását és megjelenését végző Presto renderelő motort érintette: immár a 2.12.363 változatnál járunk. Ez persze sok belső változással jár, a teljes listát elolvashatjátok a blogon (tényleg hosszú), én itt most csak a legfontosabbakat emelném ki.

Ismert hibák:

  • a címsorbeli csillag ikonra kattintás lefagyasztja az Operát
  • hibás text-shadow Windows alatt
  • billentyűzet-eseménykezeléssel kapcsolatps problémák Mac alatt
  • Google+nem szereti az új UA karakterláncot

Főbb változások:

  • teljesítményfokozó optimalizációk (VEGA, CSS3 animációk, magas CPU használat... stb.)
  • új, rfc6455 kompatibilis WebSocket implementáció (mostantól alapból engedélyezve!)
  • Unicode 6.1.0 implementáció
  • URL szűrő API fejlesztések (fehérlista!)
  • Screenshot API
  • Resource Loader API
  • Page Visibility API
  • rövidített User Agent azonosító (jelenleg Google+ problémákat okoz)
  • már nincsenek támogatva az -o- előtagú CSS utasítások (Transitions, Animations és Transform esetén)
  • a találatok javított láthatósága a forráskód-megjelenítőben
  • számos renderelési és oldalkompatibilitási hiba javítva
  • Voice XML, CSS Speech támogatás eltávolítva
  • Pretty-print és más javítások a Dragonfly-hoz

Letöltés (Opera 12.50 b1538)

Operások írták - oldalak hibáinak javítása

Az Operának régóta sok gondot okoznak a nem szabványos, böngészőspecifikusan megírt, vagy éppen elavult oldalak. Ez ellen sokféle módon próbálnak védekezni, ma az oldalakat betöltődés közben javító browser.js-ről lesz szó.

Ez a bejegyzés az "Opera's site patching" című cikk fordítása. Az eredeti cikk 2009. április 7-én jelent meg a Core blogon.

Tudod, a web technológiák komplexitása kezelhetetlenné válik, amikor minden egyes oldal valami egyedi kezelést igényel. Képzeld el, milyen lenne az autóvezetés, ha minden új utcába bekanyarodáskor kicsit bütykölni kellene a motoron, vagy le kellene cserélni a kerekeket. A böngészőfejlesztés sokban emlékeztet erre napjainkban.

Szinte minden modern böngésző rendekezik valamilyen oldal-hibamentesítő eljárással arra az esetre, ha meg kell kicsit olajozni web kiszámíthatatlan elemeinek kitett szabványok fogaskerekeit:

  • az IE8 egy kompatibilitási lista alapján IE7 módban jelenít meg bizonyos oldalakat
  • a Google Chrome álcázza magát a Hotmail-en
  • a Safari homályos, dokumentálatlan trükköket alkalmaz
  • a Firefoxnak úgy tűnik, csak a böngészőazonosító-váltó kiterjesztése van - de az eléggé népszerű
  • az Opera álcázást és browser.js-t használ

Minden oldalt külön kezelni? Elég őrülten hangzik. Egyértelműen lehetetlen. Kezdőknek: több milliárd weboldal létezik és mind különböző. És változnak is, hiszen millió sornyi kódot adnak hozzá, és cserélnek le minden áldott nap. Hogyan lehet ezzel egyáltalán lépést tartani? Mellesleg nem a szabványoknak kellene a megoldást szolgáltatniuk?

Tovább...

Operások írták - a "video" visszatér

Ez a bejegyzés a "(re-)Introducing video" című cikk fordítása. Az eredeti cikk 2009. december 31-én jelent meg a Core blogon.

Ma [azaz 2010 január 1-én] a Desktop Team kiadta az év első Opera 10.5 pre-alfáját, ami már tartalmazza az új HTML5-ös video implementációnkat. Az Opera volt az első, aki javasolta a video elemet, és már 2007-ben elérhetővé tette az első demonstrációs célú (proof-of-concept) előzetest. Ebben a bejegyzésben az azóta végzett munkáról beszélnék, az általunk hozott döntésekről és a lehetséges folytatásról.

Kodekek

A kezdetektől fogva az egyik legfontosabb kérdés, hogy melyik audió- és videóformátumokat kellene használnia a HTML5-nek. A kérdés komoly vitákat indukált a web standard közösségen belül, de azóta sincs egyetértés. Mi úgy gondoljuk, hogy a webes platformnak nyílt szabványokon kell alapulnia, emiatt folytatjuk az Ogg formátumok támogatását: a Vorbis audió- és a Theora videóformátumot. Az alap WAVE PCM hanggal együtt ezek alkotják az "alap" kodekjeinket, amit minden platformon támogatni fogunk.

Tovább...

Operások írták - Carakan újratöltve

A nemrég megjelent Opera 10.5 pre-alfa verziójának sztárja egyértelműen az új, Carakan névre hallgató JavaScript motor volt. Úgy gondolom, hogy a fejlesztőik megérdemelnek annyit, hogy teljesítményüket bemutathassák, és azt mindenki megismerhesse. Át is adnám nekik a szót...

Ez a bejegyzés a "Carakan Revisited" című cikk fordítása. Az eredeti cikk 2009. december 22-én jelent meg a Core blogon.

Kicsi több mint egy év telt el azóta hogy elindítottuk a Carakan-projektet, ami az Opera ECMAScript végrehajtási sebességének drasztikus növelését célozta, és most jött el az első fejlesztői kiadás ideje.

Amit bő egy éve elkezdtünk implementálni, az - ahogy azt már a Carakanról szóló korábbi bejegyzésemben is írtam - egy új keresztplatform bájtkód-értelmező az új, regiszter alapú utasításkészlethez, egy új belső objektummodell automatikus osztályozással és belső tulajdonság-gyorsítótárral, és egy gépi kód generáló. És mi mindezt elkészítettük, sőt, ennél többet is.

Az új bájtkód-értelmező és az új objektummodell keresztplatform fejlesztés, ami azt jelenti, hogy minden hardveres platformon működik, amire az Operát átültetjük. Ezek önmagukban is jelentős teljesítmény-növekedést jelentenek a korábbi Futhark motorhoz viszonyítva, amiket a jelenlegi Operákban alkalmazunk.

Egy átlagos asztali gépen a Carakan bájtkód-értelmezője a SunSpider teszten körülbelül három és félszer gyorsabb, mint a Futharké, és korai tesztjeink az ennél kisebb teljesítményű processzorokkal üzemelő beágyazott rendszerek esetében még nagyobb előnyt mutatnak a Carakan javára.

Az optimális sebesség elérésére azonban a gépi kód generálás (másképpen JIT - Just In Time, [azaz futásidejű generálás]) a helyes megközelítés, és erre összpontosítottuk az optimalizációs munka nagy részét is.

A Carakant felszereltük egy forrópont (hot-spot) detektáló JIT fordítóval, ami olyan gépi kódot fordít, ami a legkomplexebbek kivételével minden utasítást képes végrehajtani a bájtkód-értelmező meghívása nélkül. Ez a technika ötvözi a kód fordítás-időbeli (compile-time) statikus analízisét és a bájtkód-motor futásidejű állítását az optimális bájtkód generálása érdekében, különös tekintettel az aritmetikai számításokra.

A motor funkció-beágyazásokat is végez (function inlining), mind a beépített funkciók (például Math.sqrt() négyzetgyök-vonáshoz), mind programozó által készített funkciók esetén. A JIT fordító jelenleg csak 32 illetve 64 bites x86-os gépi kódot generál, de idővel további architektúrákat is támogatni fog, az ARM-al kezdve a sort.

Tovább...