Magyar Opera

WebGL támogatás és hardveres gyorsítás

Réges-régen egy messzi-messzi irodában... Az Opera kiadott egy előzetest, melyben a saját Canvas 3D implementációját mutatta be. Most, több mint 3 évvel később kiadták az első publikus előzetest a szabvány-alapú 3D canvas implementációval, amely WebGL-t használ. Csak Windows alá egyelőre.

A WebGL egy a Khronos csoport által fejlesztett szabvány és az Opera Software aktívan részt vesz a szabványosítási folyamatban. 2009 eleje óta dolgoznak a szabványosítási folyamaton. A specifikáció elég gyakran változott az utóbbi néhány évben, de mostanra eljutott arra a stabilitási szintre, hogy érdemes legyen kiadni az első publikus összeállítást belőle.

Azok számára, akik még nem hallottak a WebGL-ről, ez a canvas elem egyik kontextusa, amely lehetőséget ad hardveresen gyorsított JavaScript kódvégrehajtásra a 3D objektumok megjelenítése terén. Az API a OpenGL ES 2.0-n alapul, amely lehetőséget ad, hogy nagyon széles körben alkalmazzák a specifikációt különféle eszközökön, mint asztali számítógépek, mobileszközök és TV-k. A WebGL publikus wiki több információt is tartalmaz a szabványról, beleértve tutorialokat és rengeteg demót, tehát jó hely, ha ki akarjuk próbálni a WebGL működését.

Hardvergyorsítás

2008 júniusában - akkortájt, mikor a 3D canvas demó is megjelent az Opera fejlesztői bemutattak egy videót egy teljes egészében hardveresen gyorsított renderelésről. Egyik szükséges lépés a szoftveres visszafelé-kompatibilitás létrehozása volt, melyet akkor használunk, mikor a hardvergyorsítás nem elérhető az adott környezetben. És ennek legalább olyan gyorsnak kell lennie, mint ahogy az eddigi desktop változatoknál már megszokhattuk. Hogy ezt elérjék, a fejlesztők rengeteg időt és erőforrást áldoztak a szoftveres renderelés optimalizálására, melyet az Opera asztali változata már a 10.50-es verziótól kezdve használ és bebizonyította, hogy a jelenleg elérhető leggyorsabb szoftveres renderelést teszi lehetővé. Ismertebb nevén VEGA.

Tovább...

Opera Tech Break - 2. rész - A web 500 évet is élhet

Megérkezett a Choose Opera videosorozatának második része, amelyben ezúttal a CSS atyja, a jelenleg az Operánál dolgozó Håkon Wium Lie válaszol pár percben néhány beérkezett kérdésre, például arra, hogy miket terveznek a CSS jövőjében, milyen jövő vár a webre, valamint hogy milyen az igazi Opera szendvics :)

Fogai nőttek a Barracudának (b2014)

Új előzetes, új funkció. Vagyis egy régebbi funkció továbbfejlesztése. Így lehetne jellemezni a mai előzetest. A gyorshívóról van szó. Az Opera gyorshívója először egy Opera 9.20 snapshotban jelent meg Február 28-án 2007-ben. (A Magyar Opera cikke)

Az ötlet onnan jött, hogy megfigyelték a fejlesztők: az emberek új lap nyitásakor többnyire ugyanazt a néhány címet gépelik be újra és újra, amelyek az illető felhasználó kedvenc oldalai. Ez napi több száz felesleges billentyűleütést eredményezett minden egyes nap. Az ötlet nagyon egyszerű volt és nagyon hasznosnak bizonyult. Sőt, napjainkban ez a legnépszerűbb és leginkább lemásolt funkció, melyet az Opera ihletett.

Éppen ezért itt az ideje, hogy új szintre emeljék eme sokak által kedvelt funkciót. Sokkal rugalmasabbá, dinamikusabbá és egyszerűbbé fogják alakítani, melynek az első fázisa a mai napon következett be: az új külső. Ne feledd, lesznek még változások, ez csak az első előzetes.

Tovább...

Ragnarök, avagy az Opera új evolúciója!

Frissítés! Úgy tűnik, akadt némi félreértés ezzel a kiadással kapcsolatban. Ez egy adott funkciót bemutató labs kiadás, ami alapvetően a korábban elérhetővé tett Opera 11.10.2005 előzetes és az új HTML5 értelmező összeépítéséből született. A verziószám 11.50, de ebben az esetben ez nem jelent semmit, csak megkülönböztetésül változtattak a 11.10-hez képest. Szóval a leendő funkcionalitásokat illetően senki ne vonjon le messzemenő következtetéseket...

Ma megjelent az Opera újabb (Labs) verziója egy új Ragnarök kódnevű HTML5 feldolgozó algoritmussal.

Alább a megjelenés alkalmából készült operás bemutatkozó cikk fordítását olvashatjátok, aminek eredetije az Opera Labs oldalán jelent meg.

A legkirályabb HTML5 demó, amit látni fogsz ezen a héten.

A Web tele van canvas demókkal, HTML5 videó lejátszókkal, drag n' drop cuccokkal és társaival. De itt egy demó, amely valószínűleg a legkirályabb, amit ezen a héten látni fogsz. Felkészültél?

<b><i>Yo!</b></i>
Ássunk mélyebbre. A fenti elemek hibásan vannak beágyazva. A legközelebbi elemnek (esetünkben az <i>-nek, kellene az első helyen lenni a bezáró tageknél. Mit csinál a motor a DOM fával ilyen esetekben különböző böngészőknél? Leellenőrizhetjük a Dragonfly-jal és és ennek más böngészőkben lévő megfelelőjével, vagy Ian Hickson DOM viewer-ének használatával. Az Internet Explorer 9 és Safari 5 ebben az innerHTML-ben:
<!DOCTYPE HTML>
<html><HEAD></HEAD><BODY>
<B><I>Yo!</I></B><I></I>
</BODY></html>

miközben az Opera, Firefox és a Chrome ezt produkálja:

<!DOCTYPE HTML>
<html><HEAD></HEAD><BODY>
<B><I>Yo!</I></B>
</BODY></html>
Tovább...

Magyar Opera BrowserJS Plus

Ez a post elsősorban JavaScriptben jártas embereknek szól. A címben szereplő kiegészítő fejlesztése egy közösségi projekt keretében történne. A név már sokak számára beszédes, de azért leírom.

A browser.js egy felhasználói JavaScript fájl (UserJS), ami minden Operában jelen van, automatikusan frissül és a hibás oldalakat javítja, amikre még vagy nem készült Core javítás, vagy az oldal fejlesztője nem javította még a hibát.

Több, mint 200 weboldalt javítanak vele, a magyar oldalak azonban ennek csak töredékei.

A Szégyenfal 2 éve indult és több-kevesebb sikerrel el is érte célját.

A kiegészítők között is született egy figyelemreméltó kezdeményezés, az Anti BrowserSniffer, ez viszont globális volta miatt nem csodaszer és mivel minden oldalon be van kapcsolva sokszor problémák forrása is.

Itt az ideje, hogy cselekedjünk és összefogjuk a már meglévő javításokat, akár userJS-ről, akár userCSS-ről van szó és mindezt egyetlen kiegészítőbe integráljuk.

Központi célok

  • Egyszerű használhatóság, telepíthetőség: Ez a kiegészítők létezése óta lehetséges.
  • Problémaspecifikus megoldások: Ahol csak padding hibák vannak oda a UserCSS is bőven elég.
  • Erőforrásigény, megbízhatóság: Minden kódrészlet csak ott fusson le, amely oldalakra vonatkozik az általa eszközölt javítás.
  • Jól strukturált, modulárisan felépített kód: Egyszerűen lehessen elavult javításokat kivenni és új javításokkal bővíteni.
  • A javítások legyenek jól dokumentáltak, lehetőleg angol nyelven, hogy a fejlesztők is értsék.
süti beállítások módosítása