ugrás a tartalomhoz

Hardveres gyorsítás a böngészőben

Joó Ádám · 2010. Már. 5. (P), 22.42
Habár nagyságrendi eltolódás figyelhető meg évek óta az informatikában a web javára a mindenmással szemben, továbbra is sokan vannak, akik ilyen-olyan okból komolytalannak tartják a platformot. Akár a praktikus oldaláról, akár a megkomolyodást indikáló jelenségként, de a grafikus hardver kihasználásáról érkező hírek újabb lapot adnak a szkeptikusokat meggyőzni kívánók kezébe.

A hullámot a Microsoft indította útjára, amikor novemberben bejelentette, hogy a készülő IE9 már ki fogja használni a GPU nyújtotta lehetőségeket a kétdimenziós rajzolás és a szövegmegjelenítés (szép kép is illusztrálja) gyorsítása és finomítása céljából.

Néhány napja pedig Bas Schouten, a Mozilla fejlesztője jelentette be naplóbejegyzésében, hogy immár a Firefox legfrissebb éjjeli pillanatképében is elérhető a Direct2D és DirectWrite támogatás a megfelelő videókártyával és Vistával vagy Windows 7-tel rendelkező felhasználók számára (némi about:config matatás után).

Az Opera már jelezte, hogy hamarosan maguk is előrukkolnak saját megvalósításukkal, és azt hiszem ezek után a Webkit sem fog sokáig váratni magára a felzárkózással (gondoljunk csak a Google ambiciózus terveire a területen).

Azon túl, hogy a grafikus kártya megdolgoztatása általában javítja a rajzolási sebességet, ezek a fejlesztések már egyértelműen a CSS transzformációk és animációk, illetve a még robusztusabb JavaScript megvalósítások előtt kövezik ki az utat. És persze a szellem már kiszabadult a palackból a 3D terén is…
 ■
1

Jó lesz

zzrek · 2010. Már. 6. (Szo), 12.58
Jó lesz. Bár eleve nem értem, hogy miért nem az elejétől fogva ilyenre csinálták, ha valaki hozzáértő felvilágosítana, örülnék. Eleve adódik, hogy egyrészt a grafikus kártyát ki kéne használni, másrészt hogy a külön lapokat külön szálon kell futtatni, nem is értem, hogy miért nem jutott eszükbe hamarabb.
Kérdésem egy hozzá értőhöz:
Sokkal nehezebb Direct2D-re programozni, mint GDI-re?
(Miért nem raknak eleve a GDI-be hardveres GPU gyorsítást?)
Sokkal nehezebb egy új szálon indítani egy böngészőfül kezelését?

Bár ez nem webprogramozás téma, kíváncsi lennék, hogy ezek a dolgok tényleg nehezebben megvalósíthatók-e, vagy csak a régi kódbázis megtartása miatti kényelem volt-e az oka annak, hogy csak mostanra van elmozdulás az ügyben, köszi!
2

d2d

Drawain · 2010. Már. 6. (Szo), 13.50
Inkább a platformfüggetlenség az oka, a Mozilla próbált minden operációs rendszeren hasonló szolgáltatásokat nyújtani. Ennek oka az is, hogy nincsen külön Windows-ra optimalizált FireFox, pedig lehetne.
4

valóban

zzrek · 2010. Már. 6. (Szo), 15.51
Valóban, ez nem jutott eszembe. Bár a Chrome, ha csinál ilyen optimalizálást a Google, biztosan Linuxon is menni fog.
3

> Sokkal nehezebb egy új

kmARC · 2010. Már. 6. (Szo), 15.32
> Sokkal nehezebb egy új szálon indítani egy böngészőfül kezelését?
A legtöbb widgetkészletben van lehetőség tabok létrehozására, néhány kattintás az IDE-ben, vagy pár sor kód, és már több lapra is tehetsz pl.: webkit, vagy gecko widgetet. Ha kell, egy-két perc alatt össze lehet dobni ma már egy alapvető böngészésre alkalmas "browsert".

Namost, ha a tabokon levő cuccok külön threadben vannak, az már egy nagyobb meló. De külön címtérbe, azaz külön processzbe delegálni a kódot nem annyi, hogy egy runnable osztályt implementálsz, hanem szükség van bizony mindenféle IPC-re, processzek közti kommunikációra.

Ezzel a pár perces tab-programozásból több hetes tervezési, még néhány hetes implementálásra, majd még több hetes tesztelési-visszajelzési iterációs részre.

És ahelyett, hogy ezt megvalósította volna bármelyik böngészőgyártó, inkább új fícsöröket, jobb CSS-megvalósítást, kompatibilitást implementáltak. Aztán jött a chrome, és minden felbolydult, mindenki hirtelen többprocesszes böngészőt fejleszt.

Nagyjából ennyi - szerintem.
5

Értem

zzrek · 2010. Már. 6. (Szo), 16.05
Köszi a választ, értem, de azért ez a felépítés (ahol kevés kommunikáció kell az egyes böngészőlapok közt) azért elég jól fekszik a külön szálra húzáshoz.
9

A külön szál viszont nem

kmARC · 2010. Már. 8. (H), 23.52
A külön szál viszont nem ugyanaz, mint a külön processz. Ha a külön szálban elesik a flash player, az magával rántja a böngészőt. A külön processz esetén ez nem áll fenn.
10

Értem, máris tanultam alamit :-)

zzrek · 2010. Már. 9. (K), 10.15
Hát nem értek hozzá, de azért szeretném ha néhány fogalom tisztázódna a fejemben; ahogy írtad: "...ha a tabokon levő cuccok külön threadben vannak, az már egy nagyobb meló. De külön címtérbe, azaz külön processzbe..."
A thread-et szokták "szál"-nak nevezni?
Ha a külön szál nem jelent külön processzt, akkor mire jó?
Természetesen ha a "külön szál" nem azt jelenti hogy nem rántja el a fő processzt a rajta lévő hiba, akkor én külön processzre gondoltam, vagyis úgy értettem, hogy a feladat adja magát, hogy külön processzen fusson, hiszen a processzek közt (a lapok közt) nem kell, hogy jelentős kommunikáció legyen.
11

threadekkel megvalosithato az

Tyrael · 2010. Már. 9. (K), 10.45
threadekkel megvalosithato az asszinkron parhuzamos programozas, viszont kozos process ter van, es sokkal egyszerubb egymassal kommunikalo thread-eket hasznalni, mint processzeket, valamint a thread letrehozasa olcsobb/gyorsabb mint a forkolas/uj processz inditasa.
http://en.wikipedia.org/wiki/Multithread

Tyrael
12

Érdekes, köszi

zzrek · 2010. Már. 9. (K), 11.52
Majd egyszer jobban utánanézek ezeknek, mert végülis érdekel. Ami furcsán hangzik abban amit írsz, hogy thread-ekkel is aszinkron párhuzamosság van (vagyis akkor elvileg külön processzoron is lehet ugyanannak az alkalmazásnak más thread-jei?) és mégis közös a process tér.
Most ez csak "magamnak költői kérdés" volt, nem várok rá választ, majd utánanézek ha lesz időm, köszi az eddigi infókat.
8

Teljesen egyetértek

vbence · 2010. Már. 7. (V), 11.16
Egyszer végre osztja valaki a véleményemet.

Az első pillanattól kezdve exponálni kellett volna az OpenGL API-t JS-re (Nem kell azonnal a legutóbbi szabványt, de a legbutább OpenGL is kielégíti egy nem-játék alkalmazás igényeit).

JIT fordítót a JS alá - ezt sem értem miért nem alap dolog... Ha szkriptet akarsz futtatni miért ne akarnád gyorsan futtatni :o

Az OpenGL valóban alacsonyszintű (ahogy a DOM is az HTML manipulációra), de semmi nem állítja meg a közösséget, hogy ezer meg ezer frameworkben készerítse a gondolkodásmódját másokra :)
6

De hogy lesz ez kompatibilis?

Ustak · 2010. Már. 6. (Szo), 22.25
Régen volt már hogy Számítógép Arhitectúrák könyvet a kezembe vettem, úgyhogy bocsi ha hülyeséget mondok, de itt nem nyomhatom rá a 2Ds (vagy később 3Ds) weboldalamra hogy "runs on MAC and PC" mint ahogy a játékokra teszik. Emlékszem hogy a wowot már kisebb trükközéssel húztam fel linuxra (de futott mint állat:-)) ám akkor is egy elég "lokális" dologról beszélünk, jó esetben is két típusú gépre kapjuk őket (mármint az asztali alkalmazásokat), és kész.
A "compile once runs everywhere" kompatibilitás világcsúcsa java - val is jártam úgy, hogy lám, OLPC-n nem működött a csudának sem a SWING.
A weben ez gyakorlatban hogy fog kijönni? Elképzelni nem tudom.
Viszont az ötlet nagyon dícséretes.
Üdv:

Gábor
7

Egy réteggel feljebb vagyunk

zzrek · 2010. Már. 6. (Szo), 23.30
Egy réteggel feljebb vagyunk, szerintem ez nem azt jelenti hogy javascripttel Direct2D parancsokat fogsz kiadni, hanem hogy mondjuk egy ablak elemeit, kontrolt, boxot vagy canvas elemet milyen motorral jelenítenek meg: ha a direct2d elérhető, akkor gyorsabban jelenik meg a tartalom, egyébként lassabban, ugyanúgy mint most. A webfejlesztő számára ez nem jelent majd különbséget (csak sebességben), szóval a kompatibilitás megmarad.

Más kérdés, hogy valóban lesznek olyan oldalak, amiknek lesz majd hardverigénye is. De azért ez most is megvan: vannak olyan oldalak (webes alkalmazások, vagy CSS-sel, JS-sel túlcicomázott megvalósítások), amik mondjuk kb 1Ghz alatti géppel már élvezhetetlenek. De ezzel már a webfejlesztőnek kell számolnia: hány látogatót veszít, ha túl magasra teszi a lécet, stb.