Hardveres gyorsítás a böngészőben
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
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…
■ 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…
Jó lesz
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!
d2d
valóban
> Sokkal nehezebb egy új
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.
Értem
A külön szál viszont nem
Értem, máris tanultam alamit :-)
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.
threadekkel megvalosithato az
http://en.wikipedia.org/wiki/Multithread
Tyrael
Érdekes, köszi
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.
Teljesen egyetértek
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 :)
De hogy lesz ez kompatibilis?
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
Egy réteggel feljebb vagyunk
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.