Tabelle ..Leere Zeile gelöscht .. wie rutscht der Rest der Tabelle nach oben. ?

[hgseib]

Zitat von andrelehnert

Ich habe den Speed aus dem Weg/(die benötigte Zeit * fps) berechnet und gebe so beiden Engines dieselbe Aufgabe.

das eine verschiebt die objekte mit sich ändernden abständen und damit 10000*8 mal (wird also 8x ausgeführt).
das andere verschiebt die objekte linear, somit 10000*20mal (die 20 habe ich jetzt nicht gezählt - wird also 20x ausgeführt).

entweder beide schieben linear (so habe ich das geändert - und das macht aus, wie oft die selbe arbeit ausgeführt werden muss) oder beide schieben nach den abstandsberechnungen von easeOut.

ist mir auch egal ;-) jedem so wie es ihm gefällt.
aber sagt mir doch bitte konkret, wo die tweenengines, die ja auch nur mit AS programmiert sind, diese angebliche geschwindigkeit erreichen? irgendwo muss ja dann im script eine schleife oder sonstwas was sein, was um soviel schneller ist !?
z.b. int ist schneller als number usw. also woran liegt es? enterframe kann es nicht sein, das benützen beide.

[Martin Kraft]

Zitat von hgseib

aber sagt mir doch bitte konkret, wo die tweenengines, die ja auch nur mit AS programmiert sind, diese angebliche geschwindigkeit erreichen? irgendwo muss ja dann im script eine schleife oder sonstwas was sein, was um soviel schneller ist !?
z.b. int ist schneller als number usw. also woran liegt es? enterframe kann es nicht sein, das benützen beide.

Ich denke, es ist die Summe aus all dem:
Um mit einer selbstgestrickten Tweening-Konstruktionen zu vergleichbaren Geschwindigkeiten zu kommen, müsste man stets all die Performanceoptimierungen selbsts implementieren, die die Authoren die Tweening-Engines in z.T. jahrelanger Optimierungsarbeit herausgefunden haben.

So lange es nur um ein Event.ENTER_FRAME geht, das eine Sorte von Objekten zu einer Position schiebt, könnte eine Eigenkonstruktion wahrscheinlich noch einen Geschwindigkeitsvorsprung haben. Sobald es aber um viele verschiedene Objekte, mit unterschiedlichen Zielen und Easings geht, ist eine Engine schon allein deshalb im Vorteil, weil sie mit einem zentralen Taktgeber und einer Zeitnahme arbeiten kann, statt mit zig. seperaten Listenern zu jonglieren.

Außerdem: warum sollte man jedes Mal das Rad neu erfinden?!

Zitat von hgseib

das eine verschiebt die objekte mit sich ändernden abständen und damit 10000*8 mal (wird also 8x ausgeführt).
das andere verschiebt die objekte linear, somit 10000*20mal (die 20 habe ich jetzt nicht gezählt - wird also 20x ausgeführt).

Die Rechnung versteh ich nicht
Wenn beide Funktion gleich lang (d.h. eine identische Anzahl von Frames) Zeit haben, ein Objekt zu verschieben, führen sie auch eine identische Anzahl von Berechnungen durch; und zwar unabhängig davon ob sie das Objekt immer gleich weit (linear) oder unterschiedlich weit (easing) verschieben?! Dem FlashRender ist es schließlich vollkommen egal, ob ein Objekt seine Position um 0,5 oder um 50 Pixel verändern - er muss es in beiden Fällen neu rendern. Die geeasete Bewegung, dürfte dabei sogar etwas rechenaufwändiger sein, weil die Formel für eine cubischer Interploration eben aufwändiger ist als die für eine lineare.

[hgseib]

"..ca. 3-4x langsamer.."
und wir reden bei der enterframe-schleife nicht von einem hochkomplexen script, wo man was falsch machen könnte.

also bitte ganz konkret: womit wird dieser angebliche geschwindigkeitsvorteil erreicht?

die 8 schleifen- aufrufe gegenüber den 20, das könnte das 3-4x erklären. aussagen wie 'die haben halt länger drann programmiert' nicht ;-)


"..Wenn beide Funktion gleich lang (d.h. eine identische Anzahl von Frames) Zeit haben.."
das kann ja nicht sein, sonst würde man keine unterschiedlichen zeiten messen können. der script zum testen führt zu einer unterschiedlichen anzahl von frames. das habe ich in einer test-version korrigiert.

[Martin Kraft]

Zitat von hgseib

"..Wenn beide Funktion gleich lang (d.h. eine identische Anzahl von Frames) Zeit haben.."
das kann ja nicht sein, sonst würde man keine unterschiedlichen zeiten messen können. der script zum testen führt zu einer unterschiedlichen anzahl von frames. das habe ich in einer test-version korrigiert.

So darf man aber nicht messen: Tweening-Engines arbeiten in der Regel zeit- und nicht framebasierend!

D.h. der Weg von A nach B dauert (abgesehen vom »Rundungsfehler« im letzten Frame) immer gleich lang. Die Zeit eignet sich also nicht als Maßstab für die Performance einer Tweening-Engine. Stattdessen sollte man auf Prozessorlast und Framerate schauen:

Speed Test – Tweening Engine Comparison Tool « GreenSock

Wenn ich nachher mal etwas Zeit haben sollte, versuch ich mal einen validen Vergleich zusammenzubasteln.

[hgseib]

:-)
zeit oder frame ist beides egal.

der eine rückt 300 dann 200 dann 100 und ist nach 3 durchläufen bei 600.
der andere darf nur 60 dann 60 dann 60 dann 60 dann 60 dann 60 ... dann 60 rücken, bis er die 600 erreicht hat.

quizfrage: welcher der beiden ist schneller am ziel und hat die geringere leistung erbringen müssen?


sinn und zweck von engines steht ja auch vollkommen ausser frage.
hier gänge es nur noch darum (zumindestens mir), was programmieren die anders? was kann ich davon für meine programmiererei abgucken. ich will auch diese erfahrung haben.

[Martin Kraft]

Zitat von hgseib

:-)
zeit oder frame ist beides egal.

der eine rückt 300 dann 200 dann 100 und ist nach 3 durchläufen bei 600.
der andere darf nur 60 dann 60 dann 60 dann 60 dann 60 dann 60 ... dann 60 rücken, bis er die 600 erreicht hat.

Wie kommst Du zu diesen Zahlen

Wenn man ein vergleichbares Tweening erzeugen will, müssen ja 3 Dinge gegeben sein:

• die Ausgangsposition
• die Endposition
• die Dauer

Und das hat zur Folge, dass die Berechnung der Position in jedem Frame zwischen jetzt und jetzt+Dauer durchgeführt werden muss. Und zwar völlig unabhängig davon, ob dass nun durch eine Tweening-Engine oder irgendeine eigene Konstruktion geschieht und ob es linear oder irgendwie dynamisch "geeast" wird.

Zitat von hgseib

quizfrage: welcher der beiden ist schneller am ziel und hat die geringere leistung erbringen müssen?

Wenn man so argumentierst, ist das schnellste Tweening die direkte Zuweisung

this.x = zielX; 
trace("Erster!"); 

Zitat von hgseib

sinn und zweck von engines steht ja auch vollkommen ausser frage.
hier gänge es nur noch darum (zumindestens mir), was programmieren die anders? was kann ich davon für meine programmiererei abgucken. ich will auch diese erfahrung haben.

Das wäre tatsächlich interessant. Allerdings werden diese Dinge IMHO eh erst richtig ins Gewicht fallen, wenn man eine Masse asynchroner Tweenings betrachtet...

[hgseib]

Zitat von Martin Kraft

Wie kommst Du zu diesen Zahlen

das versuche ich die ganze zeit zu erklären. im test von andrelehnert wird auf unterschiedliche weisse getweent. in folge wird die schleife in loop viel öfters ausgeführt, als die vergleichbare funktion in TweenLite. DAS erklärt den leistungsunterschied von 300..400%.

ja, die tweenart ist egal, aber nicht wie oft eine function ausgeführt wird. wenn eine gesamtstrecke in 8 steps erreicht wird ist das weniger aufwendig als wenn ich die selbe strecke in 20 steps erreichen soll.

aber das ist jetzt schon x-mal beschrieben worden - soll jetzt langen. ich welde mich mal wieder, falls es was neues geben sollte.

[andrelehnert]

Sorry hgseib, ich halte Dich echt für ne Koryphäe in unserem Sandkasten,
aber Deine Logik stimmt einfach nicht.
in 1 Sekunde wird der FIlm in beiden VArianten genausoft(25mal) gerendert. Und entsprechend werden sowohl die selbstgebaute als auch die in Tweenlite intergrierte ENTERFRAME genauso oft ausgeführt. Wie Du auf die "Sprünge" in TweenLite kommst, ist mir -wie auch Martin- ein Rätsel.

Zu Deiner Frage, was denn anders programmiert sein könnte hatte ich eine Vermutung geäußert:

Zitat von andrelehnert
Berechnet TweenLite den Tweenverlauf vielleicht am Anfang komplett im Voraus?

Könnte das einen Leistungsschub bringen?

@Martin: Der valide Test war eigentlich mein Ziel. Denkst Du, ich hab da was falsch gemacht? Deine aufgelisteten Voraussetzungen habe ich alle erfüllt.

@all: Ach, ich liebe Frickel-Diskussionen. Und JEDER kann immer weiter LERNEN.

LG ANdré

[Martin Kraft]

Zitat von andrelehnert

aber Deine Logik stimmt einfach nicht.
in 1 Sekunde wird der FIlm in beiden VArianten genausoft(25mal) gerendert. Und entsprechend werden sowohl die selbstgebaute als auch die in Tweenlite intergrierte ENTERFRAME genauso oft ausgeführt. Wie Du auf die "Sprünge" in TweenLite kommst, ist mir -wie auch Martin- ein Rätsel.

+1

Zitat von andrelehnert

@Martin: Der valide Test war eigentlich mein Ziel. Denkst Du, ich hab da was falsch gemacht? Deine aufgelisteten Voraussetzungen habe ich alle erfüllt.

Nicht wirklich: Du misst die Zeit. Und die sollte ja (bis auf den Frame-Rundungsfehler) eigentlich gleich?!

• Richtig wäre es, die Frames in einem gewissen Zeitraum (also die Framerate) zu messen.
  
  
• Voraussetzung dafür wäre aber, dass auch das ENTER_FRAME die Verschiebung zeitbasierend errechnet und nicht wie bisher stumpf immer dieselbe Zahl addiert. So werden quasi Frames gedropt, wodurch es erst möglich wird, dass beide Methoden unabhängig von ihrer Performance gleich lang dauert.
  
  
• Außerdem sollte man nicht direkt beim Start der Anwendung mit den Tests beginnen, weil der FlashPlayer zu diesem Zeitpunkt noch mit ein paar anderen Dingen beschäftigt ist, was natürlich das Ergebnis verfälscht.

[andrelehnert]

Zitat von Martin Kraft

Nicht wirklich: Du misst die Zeit. Und die sollte ja (bis auf den Frame-Rundungsfehler) eigentlich gleich?!

nein eben nicht. Wie Du in der swf siehst, braucht es wg des performanceeinbruchs etwa die 3fache zeit

Zitat von Martin Kraft

Richtig wäre es, die Frames in einem gewissen Zeitraum (also die Framerate) zu messen.

Deshalb hatte ich den FPS/Memory-Checker eingebaut. Aber da hast Du recht.

Zitat von Martin Kraft

Voraussetzung dafür wäre aber, dass auch das ENTER_FRAME die Verschiebung zeitbasierend errechnet und nicht wie bisher stumpf immer dieselbe Zahl addiert. So werden quasi Frames gedropt, wodurch es erst möglich wird, dass beide Methoden unabhängig von ihrer Performance gleich lang dauert.

Ah ja, also in jedem Frame nochmal schauen, wo sich das Objekt aktuell befindet, wieviel Zeit zum Erreichen des Ziels bleibt und die verbleibende Strecke auf die verbleibende Zeit aufteilen? So wirds dann wohl auch eine Tweenengine machen, oder?

Zitat von Martin Kraft

Außerdem sollte man nicht direkt beim Start der Anwendung mit den Tests beginnen, weil der FlashPlayer zu diesem Zeitpunkt noch mit ein paar anderen Dingen beschäftigt ist, was natürlich das Ergebnis verfälscht.

Das stimmt - Genau aus diesem Grund wird das Ganze wiederholt.

Vielleicht baust Du ja auch noch nen Test - würde mich interessieren.

LG ANdré

LG ANdré

[Martin Kraft]

Zitat von andrelehnert

Ah ja, also in jedem Frame nochmal schauen, wo sich das Objekt aktuell befindet, wieviel Zeit zum Erreichen des Ziels bleibt und die verbleibende Strecke auf die verbleibende Zeit aufteilen? So wirds dann wohl auch eine Tweenengine machen, oder?

Ja, genau diese Parameter werden auch den Easing-Funktion übergeben. Diese Funktionen sollte man IMHO auch in beiden Fällen für einen wirklich vergleichbaren Test nutzen.

Zitat von andrelehnert

Vielleicht baust Du ja auch noch nen Test - würde mich interessieren.

Man sollte nicht rum mäckeln, bevor man's besser macht
Bin grade echt etwas eingespannt, aber vielleicht komm ich ja am WE mal dazu.