[dhtml] performance verbeteren?

[killercow]

Ik en nog wat anderen zijn bezig met een dhtml isometrische engine, deze engine is na een behoorlijke lange ontwikkel tijd eindelijk soort van stable, maar hij is bijzonder traag.

De engine gebruikt al een ajax backend om tiles van de server op te halen, en ze weer te verwijderen zodat de Dom redelijk klein blijft.

Toch geeft dit nog een enorme belasting op de client.

Waar heeft dit mee te maken? met de transparantie op de hoekjes van de tiles? Of door de opacity van de water tiles?

We hebben al allerlei dingen geprobeert (bijvoorbeeld scrollen per Tile/ of scrollen met de hele Map div, of scrollen via een setTimeout (threaded).

Ook het toevoegen en verwijderen van tiles hebben we op verschillende manieren geprobeerd (via de Dom, of via innerHtml, of document.write), maar het wordt er niet echt sneller of langzamer van.

eventueel (mocht je een beefy pc hebben) kun je hier een demo bekijken:
http://www.pc-gamers.com/webgamex/iso_js_coords.php

(en ja er zitten nog wat bugs in, daarom is het nog een work in progress)

[r0bert]

Ik kan je zo niet helpen, maar wow, impressive! Moet ik je gewoon even meegeven //e: idd sloom

[ Voor 12% gewijzigd door r0bert op 29-08-2005 17:18 ]

[eamelink]

De eerste truc is natuurlijk uit te zoeken wát er nu eigenlijk traag gaat.

Heeft de browser moeite met het renderen zelf? Of zijn de scripts traag? Reageert de server te langzaam? Worden de tiles serieel binnengehaald, of parallel?

Probeer dat eerst uit te zoeken; draai het script bijvoorbeeld eens zonder output naar de browser om te kijken hoeveel tijd het renderen kost.

Heb je de boel al geprofiled? Hier lees je hoe je dat doet :
http://www.hacksrus.com/~...venkman-faq.html#profiler

[killercow]

@ R0bert, thanks wij vinden het hier ook erg stoer.

@ eamelink, Profilen ziet er inderdaad veelbelovend uit, maar hier thuis gaat dat niet lukken want ik heb een precompiled firefox waar venkman niet in zit. (amd-64 met 32bits firefox)
Morgen op m'n werk wel even proberen, als zal het daar gruwelijk traag draaien op die duron 800.

De server is snel zat, die geeft ook maar 8% cpu usage ofzo.
Het laden van de objects in Dom is redelijk snel, dat duurt wel even maar niet vreselijk lang.
Vooral het scrollen (dus volgens mij het renderen) is ongelooflijk traag.

Misschien een van de GOT dhtml goden die hier iets over kan zeggen? (crisp?)

[djluc]

Cache je al die afbeeldingen wel? En herbruik je die ook? Of laat je ze allemaal laden? Want de 2e keer is het wel snel namelijk.

[killercow]

nee, cachen op de schaal die hier voor nodig is hangt toch helemaal van de browser af.
Ik cache ze iig niet client side via javascript oid.

Ik zat eraan te denken om tiles per set in een sprite te dumpen en dan via clipping de juiste afbeelding te showen zoals crips heeft gedaan in Pumpkins/lemmings, maar dat wordt denk ik veeeeel te zwaar.

[bredend]

Error: img.src has no properties
Source File: http://www.pc-gamers.com/webgamex/iso_js_coords.php
Line: 491

Error: response has no properties
Source File: http://www.pc-gamers.com/webgamex/iso_js_coords.php
Line: 295

Error: response has no properties
Source File: http://www.pc-gamers.com/webgamex/iso_js_coords.php
Line: 332

Een paar errors die je in FF in de Javascript console krijgt.
Verder heb je wel gruwelijk veel div-jes en if-jes. Denk dat je inderdaad eens met kale versie's moet testen, of maar 1 ding steeds laten uitvoeren.

[crisp]

killercow schreef op maandag 29 augustus 2005 @ 21:54:
Misschien een van de GOT dhtml goden die hier iets over kan zeggen? (crisp?)

Renderen zal inderdaad de bottleneck zijn; je moet behoorlijk wat elementen verplaatsen, en de transparantie maakt het inderdaad nog een stukje zwaarder.
Het enige alternatief dat ik zo even kan bedenken is dat je niet alle objecten zelf verplaatst, maar je hele veld binnen je viewport. Beetje lastig uitleggen, dus ik heb even een voorbeeldje gemaakt: http://therealcrisp.xs4all.nl/meuk/fieldscroll.html

Als je de overflow:hidden op #container weghaald zie je nog iets beter wat er eigenlijk gebeurd.

Merk trouwens ook op dat ik hier de images eerst in een element stop dat niet tot het document behoort, en pas als laatste deze compleet aan het document toevoeg. De browser hoeft het geheel dan maar 1 keer te renderen ipv elke image apart - dat scheelt ook al enorm op de performance.

[ Voor 18% gewijzigd door crisp op 29-08-2005 22:35 ]

[Verwijderd]

waarom zet je om elke tile(<img>) een div?
ik denk dat als je alleen de img gebruik, zonder de div, dat je dan betere preformance hebt.
en de styles die nu op de div's staan kan je ook gewoon op die img zetten.

[killercow]

@ Brebend, yup d'r zitten nog wat foutjes in de mousemove code, maar dat komt nog.
Zoals je begrijpt heb ik hier genoeg itterations van gemaakt die allemaal net even anders werkten, en natuurlijk ook met en zonder al die javascipt.

@ crisp, Ik scroll al het hele veld waar de tiles in staan als een geheel (de map div)
, ik zal de map een als laatst toevoegen aan het document nadat alle tiles er al in staan, dat zou wel moeten schelen inderdaad.
Het een voor een verplaatsen van de images, ipv de containing div maakt het wel iets zwaarder, maar niet heel erg veel. Naarste is dat de map ergens halverwege breekt omdat de bovenste helft dan al gescrolled heeft, en de onderste er achter aan hinkt.

@dexus, Ook dat is een goed idee, tis wel een behoorlijke ingreep maar klinkt inderdaad logish, zou 50% van de objecten in de Dom schelen.

[Clay]

Wat je ook overwegen kan ...
Op zich zijn het niet de berekeningen zelf die de meeste tijd in beslag nemen, het is het verplaatsten van dingen op je scherm. Wat er dus gebeurt als je zowel berekeningen als schermupdates in dezelfde thread uitvoert, is dat je die berekeningen vertraagt met de tijd die nodig is het scherm te tekenen. Een wondermiddel is het niet, maar wat wel aardig werkt is als je de berekeningen en het updaten van het scherm elk in onafhankelijke threads doet, waar de berekeningen gewoon data opslaan, en de updates deze data opvragen en naar het scherm gooien.

[Verwijderd]

Zowiezo kun je voor het scrollen ook gebruik maken van de standaard scrollbars van een browser. Dan laat je het zware werk over een de browser die al een veel hogere performance kan geven dan Javascript.

Qua images, wellicht dat het gebruik van een grote sprite wat kan schelen. Dus een enkel resource bestand waarbij je de elementen definieert met coordinaten.

Verder is het toevoegen van een grote hoeveelheid afbeelding via innerHTML of document.write voor IE af te raden. IE is niet zo happig als het erop aankomt ineens heel veel connecties voor een image request te verwerken.

[Verwijderd]

Clay schreef op dinsdag 30 augustus 2005 @ 11:50:

Inderdaad, goed idee. Daar heb ik vorige week nog een stukje voor geschreven in deze thread. Met een idee wat het in de praktijk veroorzaakt.

[rml]Gordijnstok in "[ js] animatie, function queue oid"[/rml]

[killercow]

@clay, aangezien ik de hele map container al scroll heb ik eigenlijk maar een heel laag aantal berekeningen, (en die zijn nog simpel ook). de scroll gebeurt zelf al via een setTimeout (wat toch een nieuwe thread moet spawnen toch?)

@gordijkstok,
Het scrollen via de browser is eigenlijk net zo traag, het renderen duurt dan te lang, met als nadeel ook nog eens dat de hele map geladen moet zijn, waardoor er nog meer tiles in de DOM
zijn, en het dus nog veel trager is.

Ik moet dat hele sprite verhaal nog testen, dat is alleen een behoorljke ingreep (dus zal het wel een pure test omgeving worden voordat ik het in de normale map implementeer)

Ik zit zowiezo niet te wachten op innerHtml achtige constructies, die warn nog trager, en geven een behoorlijk ranzige code omdat je alles toch op een vrij ranzige manier moet gaan doen dan.

[crisp]

sprites moet je niet te groot maken, dan holt de performance juist weer achteruit.
Voor lemmings had ik eigenlijk een dubbele implementatie; voor non-IE browsers gebruikte ik de sprite als achtergrond op een verder lege div, maar voor IE met z'n caching-bugs moest ik wel een image-object gebruiken binnen diezelfde div - dat zijn dus 2 elementen ipv 1 wat dus weer trager is. Gelukkig is de rendering van IE wat sneller wat dat nadeel wel weer ophefde.

[killercow]

Dat is inderdaad wat ik verwachte,

en met het enorme aantal mogenlijke images die ik in de sprites zou moeten stoppen leek het mij initieel ook niet echt nuttig om de images tot een sprite te combineren en deze dan als gevolg daarvan honderden keren volledig te gebruiken.

Eerst maar eens die Div's weghalen uit de code, als het ook alleen met images kan.

_{We zijn btw wel geintresseerd in devvers die willen helpen. (ja ik weet dat zoiets niet gewaardeerd wordt hier op GOT)}

[Verwijderd]

ah, daar zat ik me ook over te verwonderen, waarom je niet overal 2 elementen deed, maar het is dus trager

gelukkig ben ik bezig met maar 1 sprite en dan boeit dat weer niet zo, dus ik heb gewoon alleen met een img element en een div gewerkt. Heb wel een vrij forse sprite (atm, dat wordt nog anders), maar heb eigenlijk weinig performance problemen ermee

daarom heb ik ook geen multithreading toegepast eigenlijk

[killercow]

De div's weghalen rond de img tags haalt weinig uit. Ik zie iig geen response in de loading times, of de scroll tijden.

Wel is de cursor iets meer responsive geworden, omdat deze iets minder stapjes hoeft te nemen in de DOM om de events af te handelen.

Stom genoeg heb ik hier op m'n werk een Firefox DeerPark 2 alpha draaien waardoor ik ook hier geen venkman heb.
Zou iemand hem voor mij willen profilen?

[ Voor 25% gewijzigd door killercow op 30-08-2005 14:34 ]

[eamelink]

Jahoor, maar ik zou toch echt proberen om zelf ook zo'n ding aan de praat te krijgen , dat is een heel stuk gemakkelijker als je aan het optimaliseren bent

http://www.eamelink.nl/zut/profiledata.html

Het bovenste stuk is rommel van mijn toolbars enzo

[killercow]

Ik heb maar een anonymous functie in de code staan, en die load de tiles vanaf de server.

Als ik echter alle tiles gewoon in het scherm donder is het ook behoorlijk traag.
Ik ga ff stoeien, (dat fetchen via een thread doen), en eventueel wat meer tiles in een keer fetchen zodat de balans tussen niet te veel tiles, en niet te veel fetchen duidelijk wordt.

bedankt voor de profile eamelink!