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?

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.

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.

Ez a bejegyzés a "Test automation with OperaWatir" című cikk fordítása. Az eredeti cikk 2009. március 6-án jelent meg a Core blogon.

Annak érdekében, hogy még a termék kiadása előtt megbizonyodhassunk az Opera motorjának megfelelő működéséről, különböző konfigurációkon több, mint 100 ezer automatikus tesztet futtatunk le minden egyes összeállítás elkészültekor.

A futtatott tesztek között találunk (automatikus) vizuális, JavaScript, teljesítmény-, stabilitás-, memória- és öntesztet, sok egyéb mellett. Hiányzott viszont az olyan műveletek vizsgálata, amik valamiféle felhasználói aktivitást igényelnek, például űrlapok kitöltése, hivatkozásokra kattintás vagy az összetett webes alkalmazások használata.

Így volt ez - egészen mostanáig.

Jelenleg a Scope protokollon keresztüli vezérlés támogatásán dolgozunk. Ez az a protokoll, amit a Dragonfly nevű fejlesztőeszközünkben is használunk. Egy egyszerű szkript segítségével például arra utasíthatjuk a böngészőt, hogy automatikusan használja a Google keresőt, jelentkezzen be a Hotmailbe és küldjön el egy üzenetet, vásároljon könyveket az Amazonon, vagy keressen repülőjegyeket az Expedián.

Íme egy példa, hogy hogyan nézhet ki egy ilyen szkript:

require "operawatir"

browser = OperaWatir::Opera.new
browser.goto("http://www.google.com")
browser.text_field(:name, "q").value = "Wikipedia"
browser.button(:name, "btnG").click

browser.link(:text, "Wikipedia").click

puts "PASS" if browser.text.include? "Wikipedia"

A fenti kód a Watir API-t használja, ami egy eredetileg az Internet Explorerhez fejlesztett, Ruby nyelven írt tesztalkalmazás. Mostanra már Operára, és több más böngészőre is portolták.

Nem, sajnos még nem lehet kipróbálni az új VEGA vektorgrafikus motort. Addig is, amíg várakozunk rá, - jobb híján - olvassuk el, mit írtak róla az Opera fejlesztői, még idén februárban, a Core blogon. Akkor át is adnám nekik a szót...

Ez a bejegyzés a "Vega - Opera's vector graphics library" című cikk fordítása. Az eredeti cikk 2009. február 4-én jelent meg a Core blogon.

A korábbi bejegyzésemben írtam egy keveset az Opera hardveresen gyorsított vektorgrafikus könyvtáráról. Ebben az írásban további részleteket olvashattok róla.

A Vega története

A Vega-t nem sokkal az SVG támogatás fejlesztésének megkezdését követően alkottuk meg. Amikor implementáltuk az SVG támogatást az Operába, szükségünk volt egy vektorgrafikus könyvtárra. Körülnéztünk az akkori alternatívák között, hogy melyik felelne meg leginkább az igényeinknek (gyors, alacsony memóriaigény, telefontól kezdve a TV-n át a PC-ig sok platformon működjön). Mivel egyet sem találtunk, ami megfelelt volna, egy saját verzió megírása mellett döntöttünk.

Röviddel a Vega megalkotását követően implementáltuk a canvas támogatást is, ami szintén a Vega-t használja.

A Vega legújabb funkciója, hogy képes a hardveresen gyorsított kimenetek (back-end) alkalmazására is. A pillanatnyilag használt két kimenet az OpenGL és a Direct3D.