Javascript snelheid

[ZeroXT]

Als ik bijvoorbeeld een stukje code schrijf die een plaatje van 50x50 pixels laat bewegen om de 25 miliseconden voor 2 seconden lang:

JavaScript:

setInterval
(
    function()
    {
        document.getElementById('afbeelding').style.left = parseInt(document.getElementById('afbeelding').style.left) + 'px';
    }, 25
)

Bovenstaande code heb ik heel snel uit de mouw geschud.

Maar ik merk gewoon dat in oudere browsers dit trager kan gaan terwijl als je een javascript lib erbij pakt zoals jquery oid. dit niet het geval is.

Waar moet je dan rekening mee houden met het (zelf) maken van deze functies?

Nee ik wil geen jquery oid gebruiken, ik wil weten wat er onder de motorkap gebeurd en ben op zoek naar tips om dit soort constructies te versnellen.

[ Voor 0% gewijzigd door BtM909 op 15-09-2011 14:31 ]

[TERW_DAN]

Wat sowieso al wat sneller kan zijn (geen idee hoeveel invloed het precies heeft) is 'document.getElementById('afbeelding')' gewoon in een variabele te smijten die je de hele tijd gebruikt. Ik verwacht daar niet echt een schrikwekkende performance verbetering, maar het zou wat sneller moeten zijn.

[Bosmonster]

jquery is gewoon open source, dus ik zou ook zeggen, kijk daar eens naar

http://code.jquery.com/jquery-latest.js

[ZeroXT]

Terw_Dan, bedankt voor je bericht. Het zal waarschijnlijk niet veel uitmaken maar er zal wel een hele kleine prestatiewinst zijn.

Bosmonster.. dat had iedereen kunnen verzinnen natuurlijk.. Overigens was ik dat al aan het doen. Maar je reactie biedt geen meerwaarde naar mijn mening. Dat is net zoiets als iemand vraagt hoe hij een variable moet aanmaken in PHP en vervolgens een link geeft naar het Zend Framework omdat het daar ook in zou staan.

Iemand nog andere tips of dingen waarmee je rekening moet houden?

[Bosmonster]

Ehmm.. je zegt zelf letterlijk:

Maar ik merk gewoon dat in oudere browsers dit trager kan gaan terwijl als je een javascript lib erbij pakt zoals jquery oid. dit niet het geval is.

Bij mij werkt het niet en bij jQuery wel. Dan is het toch logisch dat je daar even kijkt waarom het bij hen wel goed gaat? Wij kunnen namelijk ook niet ruiken waarom dat zo is en zullen hetzelfde doen.

Er valt aan je code niet bijster veel te optimaliseren, dus waarschijnlijk zit de hele fx-module van jQuery slimmer in elkaar dan alleen intervals. Misschien skippen ze slim frames bijvoorbeeld. Of misschien blijkt die 25 ms wel te laag voor oudere browsers en ronden ze dat af. Er is maar 1 manier om daar achter te komen, en dat is die code uitpluizen en testen

[ Voor 6% gewijzigd door Bosmonster op 15-09-2011 13:57 ]

[.oisyn]

Zorg dat je een javascript model hebt van je objecten, en pas dat toe op de DOM, ipv dat je de DOM gebruikt voor de objecten zelf. Nu haal je bijvoorbeeld de hele tijd afbeelding.style.left op, en die moet je dan ook nog eens eerst moet gaan zitten parsen. Zorg dat je dat in een variabele hebt staan, zodat je 'm alleen maar in hoeft te stellen.

Bosmonster schreef op donderdag 15 september 2011 @ 13:55:
Er valt aan je code niet bijster veel te optimaliseren

Nou noem het maar niet bijster veel.

JavaScript:

var afbeeldingStyle = document.getElementById("afbeelding").style;
var position = 0;

setInterval(function()
{
    position += 10;
    afbeeldingStyle.left = position + "px";
}, 25);

[ Voor 40% gewijzigd door .oisyn op 15-09-2011 13:59 ]

[Bosmonster]

.oisyn schreef op donderdag 15 september 2011 @ 13:56:
Zorg dat je een javascript model hebt van je objecten, en pas dat toe op de DOM, ipv dat je de DOM gebruikt voor de objecten zelf. Nu haal je bijvoorbeeld de hele tijd afbeelding.style.left op, die je dan eerst moet gaan zitten parsen. Zorg dat je dat in een variabele hebt staan, zodat je 'm alleen maar in hoeft te stellen.

Dat gaat in de praktijk alleen niet of nauwelijks iets uitmaken, aangezien je voor de animatie toch die style-property zult moeten uitlezen (om inconsistenties te voorkomen) en zetten.

Het uitlezen kun je alleen voorkomen door eerst alle animatie-frames uit te werken en deze af te gaan. Dit is overigens dus ook wat jQuery doet

.oisyn schreef op donderdag 15 september 2011 @ 13:56:
Nou noem het maar niet bijster veel.

Denk eerlijk gezegd niet dat een read-actie en een parseInt heel veel uit gaat maken in deze hoeveelheden (40/s)

[ Voor 14% gewijzigd door Bosmonster op 15-09-2011 14:02 ]

[.oisyn]

Bosmonster schreef op donderdag 15 september 2011 @ 13:58:
[...]


Dat gaat in de praktijk alleen niet of nauwelijks iets uitmaken, aangezien je voor de animatie toch die style-property zult moeten uitlezen (om inconsistenties te voorkomen) en zetten.

Niet als je DOM gewoon louter een view is van je model. Als andere dingen de DOM properties ook nog eens aan zitten te passen dan doe je gewoon iets verkeerd.

Bosmonster schreef op donderdag 15 september 2011 @ 13:58:
Denk eerlijk gezegd niet dat een read-actie en een parseInt heel veel uit gaat maken in deze hoeveelheden (40/s)

Voor 1 image per frame zal het idd geen zak uitmaken nee

[ Voor 24% gewijzigd door .oisyn op 15-09-2011 14:16 ]

[R4gnax]

Bosmonster schreef op donderdag 15 september 2011 @ 13:58:

Het uitlezen kun je alleen voorkomen door eerst alle animatie-frames uit te werken en deze af te gaan. Dit is overigens dus ook wat jQuery doet

jQuery leest eenmalig de huidige style uit voor de beginwaarden van een animatie, berekent eenmalig uit een combinatie van die beginwaarden en de instellingen van de animatie de eindwaaarden, en interpoleert daarna tussen deze twee waardes.

Niet alle frames worden van tevoren uitgewerkt.

[Bosmonster]

.oisyn schreef op donderdag 15 september 2011 @ 14:01:
[...]

Niet als je DOM gewoon louter een view is van je model. Als andere dingen de DOM properties ook nog eens aan zitten te passen dan doe je gewoon iets verkeerd.

Helaas heb je geen garantie dat andere scripts of plugins niet direct de DOM aanpassen. Je model is maar een eigen brouwsel waar geen enkele ander zich aan confirmeert natuurlijk. Dat is geen realistische basis voor een crossbrowser framework dus.

.oisyn schreef op donderdag 15 september 2011 @ 14:01:
[...]

Voor 1 image per frame zal het idd geen zak uitmaken nee

Doh

Maar TS zegt dat het met 1 afbeelding in IE dus al veel trager wordt, wat ik me dan niet voor kan stellen dat het aan iets dergelijks ligt bedoel ik.

R4gnax schreef op donderdag 15 september 2011 @ 21:12:
[...]

Niet alle frames worden van tevoren uitgewerkt.

Ow ik dacht dat ie dat onder water wel deed. Leek me op zich wel logisch. Elke realtime berekening/afronding die je kunt voorkomen zorgt voor een stabielere cross-config animatie.

[ Voor 61% gewijzigd door Bosmonster op 15-09-2011 23:50 ]

[.oisyn]

Bosmonster schreef op donderdag 15 september 2011 @ 23:39:
[...]


Doh

Maar TS zegt dat het met 1 afbeelding in IE dus al veel trager wordt, wat ik me dan niet voor kan stellen dat het aan iets dergelijks ligt bedoel ik.

Nee idd.

Zou het met positionering te maken kunnen hebben? Bijvoorbeeld dat jQuery een element tijdens zijn animatie even position:absolute oid maakt? Dan hoeft de browser ook de flow niet steeds opnieuw te bepalen.

[ Voor 39% gewijzigd door .oisyn op 15-09-2011 23:50 ]

[Bosmonster]

Nee jQuery zelf verandert niks anders, aangezien je ook gewoon in flow kunt animeren natuurlijk. Zou het echt niet weten tot ik een voorbeeldje zie van TS eerlijk gezegd.

Misschien dat oudere browsers een ander minimum hanteren van bijvoorbeeld 30fps bij setInterval (oftewel iets van 30 ms). Daar was wel iets mee geloof ik, maar even geen zin om het uit te zoeken

[ Voor 37% gewijzigd door Bosmonster op 15-09-2011 23:55 ]

[Kiphaas7]

Bosmonster schreef op donderdag 15 september 2011 @ 23:51:
Nee jQuery zelf verandert niks anders, aangezien je ook gewoon in flow kunt animeren natuurlijk. Zou het echt niet weten tot ik een voorbeeldje zie van TS eerlijk gezegd.

Natuurlijk kan dat, maar volgens mij bedoelt .oisyn hier dat een absoluut gepositioneerd element dat geanimeerd wordt geen redraw zou triggeren, wat weer een optimalisatieslag zou kunnen betekenen.