Performance - Änderungen in einer eigenen DisplayList propagieren

[thomas_E]

ich bastel gerade an einem kleinen Framework, dass quasi eine DisplayList für BlittingObjekte zur verfügung stellt.

Blitting, für diejenigen die es nicht kennen: statt DisplayObjekte hab ich alle "Versionen" des Objektes in bitmapDatas gecacht.
Diese werden dann über copyPixels in ein grosses BitmapData (äquivalent zur Stage) reinkopiert.
Damit kaufe ich Geschwindigkeit (geringere Renderzeit) zu lasten des Arbeitsspeichers.

Um nun performanter zu arbeiten wollt ich u.a. Transformationsmatrizen und das Rechteck für getBounds(this) und getBounds(stage) speichern, und nur neu berechnen, wenn nötig.
Dadurch muss ich bei Änderung der Bounds bspw jedem Element bis zum root mitteilen, dass sich dessen Bounds nun ggf auch geändert haben und somit neu berechnet werden müssen.
Ebenso muss ich bei Änderung der Transformationsmatrix den Childnodes mitteilen das deren Transformationsmatrix (quasi transform.concatenatedMatrix) sich auch geändert hat, und ggf sogar ein neues Bild zum blitten verwendet werden muss (bspw. wenn sich dadurch die absolute rotation geändert hat).

Und da ist jetzt mein problem, wie implementier ich das am besten.
Was ich bisher über gefunden habe wurde entweder übers Event-Bubbling gelöst; das ich hier aber nicht nutzen kann, da das nur mit DisplayObjekten funktioniert
oder jedes Objekt überwacht seine direkten Eltern- und Child-Elemente und redispatcht die Events. Das ist mir aber viel zu viel Overhead.


Ich hatte überlegt, invalidate-Methoden zu implementieren, die entweder die invalidate-Methoden von Eltern-/KindElementen aufrufen, was mir jedoch wegen dieser Kaskade noch nicht so richtig gefallen will;
oder in einer Schleife bis zum root hochlaufen (bzw das selbe in die andere Richtung), und direkt die internen Eigenschaften des jeweiligen Objekts zu ändern (bspw auf null oder _invalid=true setzen), was aber auch nicht sauber ist, so an "fremden" Objekten rumzufummeln.

Oder würdet ihr diese Daten garnicht cachen, sondern jedes mal neu berechnen lassen? Das wäre aber auch nicht umbedingt toll, weil bspw für: a enthält b, der enthält c, der d, ...
um nun a rendern zu können brauch ich die Bounds für a, dafür die von b, dafür die von c und dafür die von d
für b brauch ich b, c, d
für c...
somit wäre hier die Anzahl der Zugriffe auf getBounds (und damit das neu berechnen) gleich der Verschachtelungstiefe. (pro renderzyklus)
und für die Transformationsmatrix gleich der anzahl der Child-Elemente (alle Tiefen)


Wie würdet ihr das bauen? Hat jemand vielleicht noch ein enderes Konzept dafür in petto, oder vielleicht Links / Design-Pattern, wo es um was ähnliches geht. Muss ja zugeben dass ich da noch nicht sooo die Übersicht habe, was es da alles an Pattern gibt.


Und noch ne Nebenfrage: hat jemand Infos über die Internas der positionierung von DisplayObjekten und der Klasse Transform? Wie die auf die Position/Rotation, etc des zugehörigen DisplayObjects zugreift / die globale Transformation berechnet, concatenatedMatrix, ...
Ich wunder mich, weil meine Implementierung immer noch deutlich langsamer ist als die DisplayList und Transform (die Klasse kann ich ja auch nicht nutzen )
und ich nicht weiss, wie/ob ich das noch schneller bekomme

[pixelslave]

Ich verstehe nicht ganz warum deine DisplayList noch Childs hat

Ansonsten geht der EventDispatcher nicht nur mit den DisplayObjects sondern DisplayObjects erbt von EventDispatcher. Schau dir mal von der CasaLib die EventObserver an.

Für das Property-Binding würde ich setter hernehmen die dann die EventObserver ansprechen, sobald sich eine Eigenschaft ändert.

Lee Brimelow hat darüber letztens einen Vortrag gehalten, die Slides dazu findest du auf seiner Website theflashblog.com

Grüße

Martin

[speedjunkie]

Zitat von thomas_E

iUnd da ist jetzt mein problem, wie implementier ich das am besten.
Was ich bisher über gefunden habe wurde entweder übers Event-Bubbling gelöst; das ich hier aber nicht nutzen kann, da das nur mit DisplayObjekten funktioniert
oder jedes Objekt überwacht seine direkten Eltern- und Child-Elemente und redispatcht die Events. Das ist mir aber viel zu viel Overhead.

Eventuell ist auch as3 signals von Robert Penner etwas für dich.

[thomas_E]

sry, kam gestern nicht dazu mich hierum zu kümmern.

@speedjunkie
muss ich mir mal genauer anschauen. bin zwar schon paar mal drüber gestolpert hab aber das Konzept bisher nicht so wirklich verstanden bzw wie ich das verwenden soll. häng halt noch am "normalen" Event-System.

@pixelslave
ich nehme an, du meinst die Slides zur Render for Speed Session at FOTB? danke, die kannte ich noch nicht. da sind mir noch paar andere Dinge aufgefallen, die ich nochmal überdenken muss. gehen aber an meine Thema etwas vorbei. Das Blitting selbst und auch die Mathematik dafür sind kein Problem.

Ich verstehe nicht ganz warum deine DisplayList noch Childs hat

vielleicht ist der Begriff falsch gewählt. ich mein damit die Objekt-Hierarchie von stage, über root, etlichen verschachtelten Containern bis hin zu den eigentlichen Formen. Also mehr ein Baum als ne Liste.
Nur geht es bei mir halt nicht um die Flasheigenen Objekte und Klassen, sondern um einen zweiten Baum, der die Position, transformation, etc der einzelnen nodes verwaltet, sowie deren Verschachtelung.
* ich erklär unten noch, wozu das ganze

Ansonsten geht der EventDispatcher nicht nur mit den DisplayObjects sondern DisplayObjects erbt von EventDispatcher.

soweit klar, und meine Objekte sind halt auch EventDispatcher, aber eben keine DisplayObjekte, weshalb ich kein Event-Bubbling nutzen kann und ich nach einer anderen (performanten) Lösung suche, um Änderungen an einen Teil meines Objektbaumes zu propagieren.
am besten, ohne dass jedem Objekt alle anderen bekannt gemacht werden müssen.

Schau dir mal von der CasaLib die EventObserver an.

hab mal reingeschaut und versucht zu finden, was du meinst. wollt mich jetzt aber noch nicht durch deren komplette Doku wühlen. könntest du mir Klasse und ggf Methode/Parameter sagen wo ich reinschauen soll. weiter finde ich mich dann auch selbst zurecht.

Für das Property-Binding würde ich setter hernehmen die dann die EventObserver ansprechen, sobald sich eine Eigenschaft ändert.

nur heisst das nicht a) 1 Dispatcher zu 1 Listener? und b) dass diese beiden sich kennen müssen?

*Erklärung:
beim Blitten hab ich ja eine grosse Leinwand und jede menge Bilddaten. soweit so einfach. jetzt muss ich nur noch wissen was wohin gezeichnet werden soll.

Wenn meine Objekthierarchie flach ist, sprich alle Objekte in einem gemeinsamen (globalen) Koordiantensystem plaziert werden ist das ganze (mein Projekt) überflüssig. Da entspricht die Position zum Zeichnen der Position des Objektes selbst. Was ist aber, wenn meine Figur aus mehreren Teilen besteht? bspw Body + Kopf + Ausrüstungsgegenstände.
Dann fängt es an aufwändig zu werden; deren Position, Rotation, etc im globalen Koordinatensystem zu verwalten. Mit Vektoren würde ich mein Männchen als Sprite anlegen, und alle Einzelteile da reinpacken.
Wenn ich nun mein männchen bewege, werden die automatisch mitbewegt.

Und das ist es worum es mir geht. Einen Objektbaum zu erstellen, der diese Positionierung, Transformation, etc verwaltet, und so Methoden wie localToGlobal für die Blitting-Objekte zur verfügung stellt.
Das mach ich indem ich für jedes Objekt aus der Position und den Transformationen eine Transformationsmatrix erstelle, und über matrix.concat() eine zweite (globale) Transformationsmatrix berechne.
Um diese jetzt nicht unnötig oft neu berechnen zu müssen speicher ich die intern im Objekt selber, und berechne sie nur neu wenn es nötig ist.
Nötig wird es, wenn sich entweder das Objekt selber, oder ein Eltern-Element bewegt hat.

Und das ist die Stelle wo meine Frage drauf abzielt. Wie ein solcher Knoten, am besten die Transformationsmatrizen eines ganzen Teilbaums ungültig macht; am besten, ohne die Objekte alle selber kennen zu müssen.


sry wegen der langen Texte, nur ich hab mir da schon den ein oder anderen Gedanken zu dem ganzen gemacht.


//nachtrag: hab gestern mal in den Sourcecode von Starling reingeschaut, die machen im Grunde das selbe, nur halt mit Stage3D statt mit Blitting. Starling berechnet diese Matrizen tatsächlich bei jedem Bedarf neu. Das ist bspw bei jedem localToGlobal, globalToLocal und getBounds, und noch paar mehr; und zum Zeichnen der Vertices.
An der Stelle frage ich mich, ob da nicht die Verwendung dieser Methoden das schnelle rendering auf der GPU ausbremst.