[JS] Aanpassingen aan DOM in 1 keer doorvoeren

[.oisyn]

Hoi!

Ik ben bezig met een wolfenstein-in-javascript projectje, en daarin animeer ik middels javascript wat IMG elementen op de pagina. Om precies te zijn verander ik in sommige situaties zowel de dimensies van het element als het SRC attribuut. Nou zie ik echter dat FireFox de veranderingen aan de SRC meteen op lijkt te pikken, maar de veranderingen aan de grootte een frame later toepast. Dit zorgt voor een irritante flikkering die ik graag probeer te vermijden. IE heeft hier geen last van.

Ik tast echter in het duister hoe ik dat aan moet pakken. Ik heb geprobeerd het onload event daarvoor te misbruiken, door de width/height properties dan alsnog toe te passen, maar dat mocht niet baten (logisch, want hij verandert éérst het plaatje, en daarna pas de afmetingen). En een onresize event wordt weer niet getriggered door aanpassingen vanuit javascript.

Zijn er nog andere trucjes die je kunt gebruiken om te zorgen dat dit soort veranderingen allemaal tegelijk plaatsvinden? In eerste instantie had ik overigens niet eens allemaal verschillende plaatjes maar zaten de textures allemaal verwerkt in 1 groot plaatje, maar hoe groter dat plaatje hoe meer dat van invloed was op rendering performance in IE, ookal laat je de in feite niet meer pixels zien.

Andere browsers naast FF en IE6/7 heb ik overigens nog helemaal niet getest

[André]

Kun je geen tussenweg nemen? Dus niet allemaal losse plaatjes, en ook niet 1 grote, maar een paar middelgrote?

/edit: ziet er goed uit, draait in de kleinste resolutie erg soepel, ben benieuwd wat je er mee van plan bent. Doet me denken aan de GoT DHTML contests.

[ Voor 41% gewijzigd door André op 16-03-2008 23:27 ]

[.oisyn]

Nou ja als dit probleem niet verholpen kan worden dan wordt m'n "tussenweg" gewoon browser-afhankelijke codepaden . Overigens neemt de performance al vrij drastisch af in IE bij grotere plaatjes, dus ik denk sowieso niet dat ik die kant op wil.

Maar los daarvan, dat zal het probleem niet goed verhelpen. Wat ik nu doe is voor elke verticale beeldlijn een plaatje laten zien. Dit plaatje laat in feite een enkele gescalede verticale pixelkolom zien. Als je bijvoorbeeld door een deur een grotere kamer in loopt, dan zal de kolom pixels die de huidige frame de hoek van de deurpost voorstelt, de volgende frame ineens een stuk muur een stuk verderop in de kamer zijn (dus een andere texture en in verticale afmeting kleiner geworden). Dat stuk muur is sowieso altijd anders dan de texture van de deurpost, en dit is tevens de plek waar je de flikkering het meest ziet. De enige manier om de flikkering te verhelpen is als de deurpost en de texture van de muur in hetzelfde plaatje staan, wat effectief betekent dat als ik middelgrote plaatjes gebruik, ik in feite de deurpost moet combineren met elk ander plaatje. En dan is het probleem alleen verholpen voor de deurposten, en niet in bepaalde andere gevallen waar grote veranderingen optreden .

Dus ik had gehoopt dat dit makkelijk opgelost kon worden, en zo niet dan zit er niets anders op dan voor FF 1 plaatje te gebruiken met alle textures, en voor IE een plaatje per texture. En voor andere browsers moet ik maar even kijken wat het handigst is.

André schreef op zondag 16 maart 2008 @ 23:24:
/edit: ziet er goed uit, draait in de kleinste resolutie erg soepel, ben benieuwd wat je er mee van plan bent. Doet me denken aan de GoT DHTML contests.

Mijn doel is gewoon een letterlijke port maken van het originele Wolfenstein 3D (ik weet niet hoe goed je het origineel kent maar wellicht herken je het eerste level van de eerste episode ). Omdat het kan en het mij van de straat houdt

[ Voor 22% gewijzigd door .oisyn op 16-03-2008 23:40 ]

[frickY]

Probeer anders crips eens te benaderen. Als ik me niet vergis heeft hij Lemmings in DHTML gebouwt, en zou dus soortgelijke problemen gehad kunnen hebben.

[crisp]

.oisyn schreef op zondag 16 maart 2008 @ 23:22:
[...]
Zijn er nog andere trucjes die je kunt gebruiken om te zorgen dat dit soort veranderingen allemaal tegelijk plaatsvinden? In eerste instantie had ik overigens niet eens allemaal verschillende plaatjes maar zaten de textures allemaal verwerkt in 1 groot plaatje, maar hoe groter dat plaatje hoe meer dat van invloed was op rendering performance in IE, ookal laat je de in feite niet meer pixels zien.

Ik zat met soortgelijke problemen met DHTML Lemmings. IE wordt inderdaad erg traag op het moment dat je met grote image-objecten werkt, daarom heb ik uiteindelijk ook gekozen voor meerdere kleine sprites.

IE werkt het beste met IMG-elementen en positionering binnen een element met hidden overflow, Firefox werkt sneller met background-images en clipping ism background-position, maar daar heb jij denk ik weinig aan want background-images kan je weer niet opschalen.

Wellicht zal je toch moeten branchen tussen IE en Firefox en IE losse plaatjes geven en in Firefox met 1 gecombineerde image werken.

Wat overigens ook sneller is dit voor image-swaps:

JavaScript:

// preload some image
var preload = new Image();
preload.src = 'http://example.com/image.gif';

// swap some image
var img = document.getElementById('myImage');
img.src = preload.src;

dus in plaats van een string toe te kennen aan de src-property verwijzen naar de src property van je preloaded Image object. Maar daar zit je probleem nu net weer niet in dit geval...

[crisp]

Veel browsers renderen DOM-updates overigens pas als de JS interpreter weer de controle teruggeeft aan de browser zelf. Vaak worden deze render-updates in de tussentijd gequeued terwijl aan de andere kant het aanpassen van bijvoorbeeld .src asynchroon verloopt. Dat is wat hier volgens mij ook gebeurd.

Nu kan je in Firefox wel een redraw forceren tijdens JS executie, bijvoorbeeld door de offsetWidth of offsetHeight van betreffende element op te vragen, maar of het daar nu sneller van wordt...

[.oisyn]

Wat overigens ook sneller is dit voor image-swaps

Ja dit las ik ook in een eerdere post van je tijdens mijn zoektocht naar animatie-informatie. Ik twijfel niet aan jouw expertise, maar als informaticus met een gezonde interesse in compilerbouw wil dat er bij mij niet in. De properties zijn strings, en ik vind het lastig voor te stellen dat een assignment van de ene src naar de andere src sneller is dan bijvoorbeeld via een tussenvariabele . Maar ik zal het eens proberen.

.edit aangaande je tweede post: hmmm interessant. Dan zou ik de tijd ertussen waarschijnljik kunnen verminderen door bij te houden welke src veranderingen ik wil maken, en die aan het eind van m'n gameloop, dus vlak voordat de controle weer teruggaat naar de browser, dan die src aanpassingen te doen. Een andere mogelijkheid is double buffering, waarbij ik naast elke zichtbare kolom nog een onzichtbare kolom maak. De src verandering kan ik op de onzichtbare kolom doen (die dan meteen plaatsvindt, maar dat is onzichtbaar dus daar zie je niets van), en dan de visibilities van de kolommen om te draaien.

[ Voor 38% gewijzigd door .oisyn op 17-03-2008 01:11 ]

[crisp]

.oisyn schreef op maandag 17 maart 2008 @ 00:01:
[...]

Ja dit las ik ook in een eerdere post van je tijdens mijn zoektocht naar animatie-informatie. Ik twijfel niet aan jou expertise, maar als informaticus met een gezonde interesse in compilerbouw wil dat er bij mij niet in. De properties zijn strings, en ik vind het lastig voor te stellen dat een assignment van de ene src naar de andere src sneller is dan bijvoorbeeld via een tussenvariabele . Maar ik zal het eens proberen.

Het is volgens mij sneller omdat bij een dergelijke toewijzing het betreffende image object al 'in scope' is dus niet apart opgezocht hoeft te worden in de lokale cache...

.edit aangaande je tweede post: hmmm interessant. Dan zou ik de tijd ertussen waarschijnljik kunnen verminderen door bij te houden welke src veranderingen ik wil maken, en die aan het eind van m'n gameloop, dus vlak voordat de controle weer teruggaat naar de browser, dan die src aanpassingen te doen. Een andere mogelijkheid is double buffering, waarbij ik naast elke zichtbare kolom nog een onzichtbare kolom maak. De src verandering kan ik op de onzichtbare kolom doen (die dan meteen plaatsvindt, maar dat is onzichtbaar dus daar zie je niets van), en dan de visibilities van de kolommen om te draaien.

Net getest en het tussendoor opvragen van offsetWidth lijkt het probleem op te lossen zonder noemenswaardige performance-penalty. Testcase:

HTML:

<body>
<script>

var preload = [];
preload[0] = new Image();
preload[0].src = 'http://gathering.tweakers.net/global/smileys/wink.gif';
preload[1] = new Image();
preload[1].src = 'http://www.xs4all.nl/~crisp/pictures/jeremy_avatar_new.jpg';

var img = document.createElement('img');
img.src = preload[0].src;
img.width = 15;
img.heigh = 15;

document.body.appendChild(img);

function swap0()
{
    count++;
    img.width = 15;
    img.height = 15;
    var a = img.offsetWidth;
    img.src = preload[0].src;
    if (count > 100)
    {
        var end = new Date().getTime();
        alert(end - start);
    }
    else
        setTimeout(swap1, 10);
}

function swap1()
{
    img.width = 60;
    img.height = 60;
    var a = img.offsetWidth;
    img.src = preload[1].src;
    setTimeout(swap0, 10);
}

var count = 0;
var start = new Date().getTime();
swap1();

</script>

Overigens doen niet alle browsers pas de DOM updates aan het eind uitvoeren. Opera staat er om bekend dat die zoveel mogelijk al tijdens de JS executie redrawed (en IE ook in mindere mate). Firefox heeft echter een extra 'zetje' nodig (maar ook alleen als de src-property veranderd).

[ Voor 3% gewijzigd door crisp op 17-03-2008 00:30 ]

[.oisyn]

Woei, het opvragen van de offsetWidth verhelpt het euvel wel . En ik merk weinig performanceveranderingen daardoor. Ik doe het overigens wel aan het eind - zoals gezegd queue ik nu de veranderingen aan de src attributen, die pas ik aan het eind toe en daarna vraag ik een offsetWidth op.

Thanks

[Clay]

Waarom maak je dit eigenlijk niet in canvas? Dat is gewoon een imagebuffer waar je pixels in gooit. Straks moet je wapens, interface, monsters etc erin zetten; wil je dat echt allemaal met meer dom elementen gaan doen? Dat maakt het immers ook trager. En bovendien is canvas vet

[crisp]

Clay: IE?

.oisyn: waarom declareer je nergens je variabelen in de functie-scope? Dat vertraagt de scope resolution elke keer dat je een variabele gebruikt omdat hij eerst in de functie-scope kijkt en dan pas in de global scope (plus het verhoogd de kans op obscure bugs).

[.oisyn]

Omdat ik niet wist dat dat wat uitmaakte , en omdat ik microoptimalisaties op dit moment compleet onbelangrijk vind. Wat ik momenteel merk is dat de meeste performance opgaat aan het opnieuw renderen door de browser, en niet zozeer javascript executie

Clay schreef op maandag 17 maart 2008 @ 10:05:
Waarom maak je dit eigenlijk niet in canvas?

Omdat dat HTML5 is en IE het niet ondersteunt?

.edit: ik zie dat oa Google een script heeft dat canvas support add voor IE. Zal wel op dat ActiveX teken object layeren, op zich interessant. Maar dat maakt mijn project wel meteen weer een stuk minder leuk. Ik wilde bestaande features misbruiken en hacken, niet zelf tekenen

[ Voor 51% gewijzigd door .oisyn op 17-03-2008 11:31 ]

[crisp]

.oisyn schreef op maandag 17 maart 2008 @ 11:16:
Omdat ik niet wist dat dat wat uitmaakte , en omdat ik microoptimalisaties op dit moment compleet onbelangrijk vind. Wat ik momenteel merk is dat de meeste performance opgaat aan het opnieuw renderen door de browser, en niet zozeer javascript executie

Het is niet zozeer een micro-optimalisatie maar gewoon good practice om variabelen te declareren in de juiste scope. Eventuele performancewinst is gewoon mooi meegenomen

[Clay]

Is dat echt zo interessant dat IE het dan niet doet? Firefox, safari en opera doen het bv allemaal wel, en je bent dan tegen een domloze (dus snellere) interface aan aan het praten waar de image bewerkingen waar je hier mee zit te stoeien gewoon standaard inzitten. Daarnaast is het een voorbeeld van de schowcases voor de techniek zelf die juist nodig zijn om canvas verder van de grond te krijgen.

IE8 bv gaat bv het dataURL protocol ondersteunen wat canvas standaard uitpoept als je toDataURL() erop uitvoert. Onder water zou je canvas vanalles uit kunnen laten rekenen wat je daarna weer naar css toe stuurt; ronde hoekjes, gestapelde images, je kan het zo gek niet bedenken.

Waarom laat je je tegenhouden door IE zou ik eerder vragen. Het is toch een showcase, "omdat het kan" ?

sterker nog, d'r is al een gast die openGL in canvas had draaien ergens

[ Voor 5% gewijzigd door Clay op 17-03-2008 12:04 ]

[.oisyn]

crisp schreef op maandag 17 maart 2008 @ 11:58:
[...]

Het is niet zozeer een micro-optimalisatie maar gewoon good practice om variabelen te declareren in de juiste scope.

Zoals ik al zei, ik wist niet dat dat wat uitmaakte. Kwa semantiek bedoel ik dan, niet zozeer kwa performance

[.oisyn]

Clay schreef op maandag 17 maart 2008 @ 12:00:
Waarom laat je je tegenhouden door IE zou ik eerder vragen?

Omdat ik gewoon een IE gebruiker ben? FYI: niet iedereen is zo'n webhippie die vindt dat kosten wat kost IE vermeden moet worden . De enige reden waarom ik FireFox heb geinstalleerd is omdat ik wilde zien hoe het in een andere browser draaide.

Daarnaast is het een beetje suf als je het iemand laat zien en dan de reactie terug krijgt: "het werkt niet bij mij"

[ Voor 39% gewijzigd door .oisyn op 17-03-2008 12:14 ]

[crisp]

Clay schreef op maandag 17 maart 2008 @ 12:00:
IE8 bv gaat bv het dataURL protocol ondersteunen wat canvas standaard uitpoept als je toDataURL() erop uitvoert. Onder water zou je canvas vanalles uit kunnen laten rekenen wat je daarna weer naar css toe stuurt; ronde hoekjes, gestapelde images, je kan het zo gek niet bedenken.

IE8 heeft een beperking mbt de URL lengte voor data-URI's van 32K wat de bruikbaarheid ook meteen inperkt tot hetgeen je hier noemt: kleine plaatjes... Helaas kan je hier dus geen canvas-cloon op bouwen.

[Clay]

FYI: niet iedereen is zo'n webhippie die vindt dat kosten wat kost IE vermeden moet worden .

IE hoeft niet vermeden te worden Ik probeer alleen maar aan te geven dat als je toch al bezig bent met dit soort dingen (experimenteel / showcase / lol), dat je het ook net zo goed in een technologie kan doen die er meer geschikt voor is, waarbij het naar mijn mening minder uitmaakt dat het dan in IE niet werkt. Of het nou canvas, vml, svg of wat anders is; er wordt nog steeds hard aan de weg getimmerd om meer dingen mogelijk te maken dan er met standaard html/js mogelijk zijn, en dat juich ik toe.

IE8 heeft een beperking mbt de URL lengte voor data-URI's van 32K wat de bruikbaarheid ook meteen inperkt tot hetgeen je hier noemt: kleine plaatjes... Helaas kan je hier dus geen canvas-cloon op bouwen.

omfg waarom!

't gaat me trouwens niet om een canvas cloon, daar bestaat al wat voor ook. 't is meer dat de support voor dataURL's een stap in de goeie richting is, en dat er dus best hoop gloort wbt IE ontwikkeling.

En dat ik na tig jaar werken voor een groot commercieel webbureau nog steeds hippie genoemd word vind ik best vleiend

[.oisyn]

Clay schreef op maandag 17 maart 2008 @ 14:25:
[...]


IE hoeft niet vermeden te worden Ik probeer alleen maar aan te geven dat als je toch al bezig bent met dit soort dingen (experimenteel / showcase / lol), dat je het ook net zo goed in een technologie kan doen die er meer geschikt voor is,

Zoals C++ icm framebuffer access?
Ik kan het ook IE-only maken door zo'n activex teken object te instantieren. Waar het mij om gaat is dat het bij iedereen werkt

[Bosmonster]

crisp schreef op zondag 16 maart 2008 @ 23:51:
[...]

Wat overigens ook sneller is dit voor image-swaps:

JavaScript:

// preload some image
var preload = new Image();
preload.src = 'http://example.com/image.gif';

// swap some image
var img = document.getElementById('myImage');
img.src = preload.src;

dus in plaats van een string toe te kennen aan de src-property verwijzen naar de src property van je preloaded Image object. Maar daar zit je probleem nu net weer niet in dit geval...

Mijn ervaring is dat getElementById ook niet de snelste is en dat het cachen hiervan ook een flinke snelheidswinst op kan leveren. (Heb er nu met een grote applicatie een flinke snelheidswinst mee geboekt, waar ik ongeveer 500 elementen langs moet lopen, daar ging die routine na cachen van 2 seconden naar ongeveer 0,02 seconde ).

Overigens ben ik het hier met oisyn eens wat betreft browsercompatibiliteit. Als je al besluit een dergelijk project in en compleet ongeschikte techniek (html/js) te bouwen, doe het dan tenminste ook cross-browser.

[ Voor 10% gewijzigd door Bosmonster op 17-03-2008 15:55 ]

[crisp]

Bosmonster schreef op maandag 17 maart 2008 @ 15:52:
[...]


Mijn ervaring is dat getElementById ook niet de snelste is en dat het cachen hiervan ook een flinke snelheidswinst op kan leveren. (Heb er nu met een grote applicatie een flinke snelheidswinst mee geboekt, waar ik ongeveer 500 elementen langs moet lopen, daar ging die routine na cachen van 2 seconden naar ongeveer 0,02 seconde ).

De gEbyI was hier puur ter illustratie, uiteraard is het aan te bevelen pointers naar je elementen te cachen (hoewel lookups by ID in de meestebetere browsers puur een lookup in een locale hash-table is)

[crisp]

Clay schreef op maandag 17 maart 2008 @ 14:25:
[...]

omfg waarom!

't gaat me trouwens niet om een canvas cloon, daar bestaat al wat voor ook. 't is meer dat de support voor dataURL's een stap in de goeie richting is, en dat er dus best hoop gloort wbt IE ontwikkeling.

Die gebruikt IE's VML support ja. Ik zat zelf ook niet te denken aan een echte canvas-kloon maar meer aan een simpele toepassing zoals het on the fly genereren van bijvoorbeeld grafiekjes in een bitmap formaat, dat is redelijk eenvoudig en met weinig code te realiseren. Je loopt dan echter wel heel snel tegen die 32K limiet aan. Nou ja, ik kan dan nog mijn JS gif-implementatie gebruiken, maar sneller wordt het daar ook niet van

[.oisyn]

Ik heb canvas geimplementeerd, maar kwa performance is het onder FireFox nadelig bij het tekenen van veel pixels (dus als je dicht op muren staat - tot wel een factor 2 verschil) en ongeveer gelijk bij het tekenen van weinig pixels (in het midden van grote kamers). De tekenroutines lijken dus langzamer (de boel wordt dan ook wel bilineair gefilterd), maar de overhead die je hebt bij het aanpassen van de DOM is er natuurlijk niet.

IE heb ik niet getest, maar wat ik van de canvas implementaties voor IE gezien heb is dat het een stuk trager is dan FF's implementatie.

Nogal een dead end dus wmb... maar ik zal eens kijken hoe het zich verhoudt als de sprites erin komen.

[ Voor 4% gewijzigd door .oisyn op 20-03-2008 18:32 ]

[Verwijderd]

je doet nu plaatjes in een div om te clippen, heb je al eens een test gedraait met de css clip property? scheelt je de div elementen, dus lijkt me de boel te kunnen versnellen

[crisp]

Verwijderd schreef op donderdag 20 maart 2008 @ 12:47:
je doet nu plaatjes in een div om te clippen, heb je al eens een test gedraait met de css clip property? scheelt je de div elementen, dus lijkt me de boel te kunnen versnellen

niet in IE kan ik je uit ervaring vertellen...

[.oisyn]

Verwijderd schreef op donderdag 20 maart 2008 @ 12:47:
je doet nu plaatjes in een div om te clippen, heb je al eens een test gedraait met de css clip property? scheelt je de div elementen, dus lijkt me de boel te kunnen versnellen

Ja, en ik kreeg dezelfde resultaten als crisp. Daarnaast denkt IE ook nog eens dat de pagina breder is dan dat hij daadwerkelijk is (oftewel de elementen doen wel volledig mee in de flow, ondanks hun clip) zodat je de hele tijd de horizontal scroll bar groter en kleiner ziet worden. Maar dat is natuurlijk wel weer op te lossen door de images in een div te plaatsen met een hidden overflow.

[BtM909]

Kicken voelt altijd lekker

Als het gaat om DOM Nodes aanmaken, dan is er wellicht nog een snelheidsverbetering mogelijk: http://ajaxian.com/archiv...ode-insertion-performance

[crisp]

BtM909 schreef op dinsdag 22 juli 2008 @ 11:54:
Kicken voelt altijd lekker

Als het gaat om DOM Nodes aanmaken, dan is er wellicht nog een snelheidsverbetering mogelijk: http://ajaxian.com/archiv...ode-insertion-performance

blegh, onzin

dit is niet sneller:

JavaScript:

var container = document.createDocumentFragment();
container.appendChild(foo);
container.appendChild(foo);
// etcetera

dan dit:

JavaScript:

var container = document.createElement('div');
container.appendChild(foo);
container.appendChild(foo);
// etcetera

en ook het appenden van die container zal weinig verschil maken qua performance. Het enige verschil is dat je in het 2e geval een extra wrapper in je DOM-tree hebt, en tot nu toe heb ik zelf nog geen situaties gehad waarbij ik zelf niet zo'n wrapper nodig had, of sowieso een bestaande wrapper in de DOM wou replacen.

John Resig vergelijkt appels met peren; het grootste performanceverschil komt doordat hij in het ene geval puur meer iteraties (vooral op zijn manier al extra traag in IE) en appends doet.

DocumentFragment moet je dus gebruiken als je geen extra wrapper nodig hebt maar puur meerdere child-elementen wilt toevoegen aan een element. Alleen dan is er een 'performancewinst' boven meerdere appendChild()'s (duh). Voor de rest geldt gewoon de algemene regel: eerst je fragment zoveel mogelijk detached opbouwen en dan pas in de DOM gooien.

edit: ik heb maar even gereageerd op John's blogpost

[ Voor 16% gewijzigd door crisp op 22-07-2008 13:28 ]