Zrychlete práci s Canvasem!
Nálepky:
Vývojáři píšící aplikace v JavaScriptu znají pravidlo, které říká: Vyhněte se častým operacím s DOMem. Pokud potřebujete např. vytvořit větší množství entit, je lépe si je vytvořit „bokem“, a aktualizovat je nakonec a najednou.
Podobné pravidlo lze vztáhnout i na práci s pixely v canvasu, jak popsal ve svém článku Selim Arsever. Jeho postup je velmi jednoduchý – nejprve si vytvoří lokální kopii image.data, do ní provede potřebné změny, a výsledek přiřadí zpět. Tímto postupem (nazvaným „DOM detaching“, tedy „odpojení od DOMu“) dosáhl zrychlení o cca 40%. V článku naleznete i graf s porovnáním rychlosti různých variant v jednotlivých prohlížečích.
Zdroj: Ajaxian
Martin Malý
Začal programovat v roce 1984 s programovatelnou kalkulačkou. Pokračoval k BASICu, assembleru Z80, Forthu, Pascalu, Céčku, dalším assemblerům, před časem v PHP a teď by rád neprogramoval a radši se věnoval starým počítačům.
Starý dobrý double buffering :)
Skoro přesně tak. Jen se konečně našel někdo, kdo prakticky ověřil, že i s dvojím kopírováním to je v JS rychlejší. :)
cim linejsi platforma, tim vetsi smysl double buffering ma… to neni treba overovat :-)
Jde i o to, jak je implementováno přepínání bufferu. Pokud je programátor mocný čaroděj, dokáže ho udělat tak pomalé (např. jako kopii s kontrolou kdečeho po každém zkopírovaném bajtu – i to jsem viděl), že 2Buf ztrácí smysl. :)
protoze js predava objekty referenci, a vtom image.data je objekt typu pole. viz priklad:
var a = [1,2];
b = a;
b[0] = 4;
alert(a + ' ' + b);
zrychlení asi spočívá v tom, že v tom druhém případě se pracuje přímo s polem data, kdežto bez toho se pracuje s objektem image v DOM, přes který se přistupuje k poli data.
mydata = foo vs. image.mydata = foo
tedy asi není totéž jako
mydata = foo vs. otherdata = foo
On trochu mate ten název „detaching“, protože o žádný detaching nejde, spíš o „direct access“.
dobre, pokud to je teda jak rikate vy a kolega dole, ze jde jen o urychleni dejme tomu na urovni pri prochazeni nejakeho stromu pameti, diky hodne volani ve smycce, a pokud plati ze js pouziva vzdy reference, tak je stejne nesmysl to nakonci nastavovat zpatky tu hodnotu na tu puvodni, jak tam pise, And here we attache it back.
Přečetl jsem to, a celé mi to přijde jako nesmysl. Není to ani detach, ani double-buffer, je to obyčejné zkrácení cesty. Když napíšu v javascriptu ‚neco.neco.neco‘, tak se to musí pokaždé vyhodnotit, takže je logické, že zkrácením toho výrazu na ‚a = neco.neco.neco‘ dosáhnu o lepšího výkonu v hlavní smyčce. Pro některé je to asi objevení ameriky.
Spíš mě zaráží, že autor plní pixely úplně opačným směrem (což pro sběrnici určitě dobré není) a ve smyčce má chybu, pixel na souřadnici [0, 0] se nepřekreslí…