Innerhalb der nächsten Stunden wird die XClips API released. Einem XClip wird ein (aufwendig) Animiertes DisplayObject übergeben, aus dem dann der Bitmap-basierte XClip gerendert wird. Viele Filter, BlendModes oder etwa 3D-Szenen können auf diese weise in echtzeit zu einer Art Video zusammengestellt werden. Nach dem Rendern laufen Inhalte, an denen auch die neusten CPUs scheitern flüssig, schließlich handelt es sich nach dem Rendern nicht mehr um Vektor basierte Grafiken, die in echtzeit von Flash gerendert werden müssen.
Zu diesem Anlass habe ich einen kleinen Blog eingerichtet, den ich nach und nach mit Infos, Tuts, Experimenten und allem anderen rund um die Anwendung des XClip füllen werde. Links zu den XClips Docs und Download findet ihr ebenfalls unter xclips.opacki-flash.com. Oder folgt dem Link: XClips-Blog

Wenn Objekte zur Laufzeit erstellt und wieder entfernt werden sollen, kommt diese Methode zum Einsatz. Denn für Objekte, die eine begrenzte Lebenszeit zur Laufzeit der Applikation haben, ist es fast schon notwendig, eine destroy-funktion zu schreiben, die alle EventListener von dem Objekt entfernt. Natürlich ist das nur möglich, wenn es keine weiteren, von übergeordneten Objekten definierten Listener auf diesem Objekt gibt. In diesem Fall müsste das Übergeordnete Objekt die Destroy-Funktion besitzen.
Die Wichtigkeit dieser Vorgehensweise ergibt sich aus der Tatsache, dass der folgende code:

myObject = null

das Objekt nicht physikalisch aus dem Speicher entfernt, sondern lediglich den Verweis darauf über myObject löscht, solange es aktive EventListener für dieses Objekt gibt. Das wiederum führt zu unnötiger Speicherauslastung. Besonders Kritisch bei Flash-Spielen und Filmen in Endlosschleifen, wie Werbebannern. Mit der Kombination

myObject.destroyMe() //und...
myObject = null

wird der Speicher für das Objekt tatsächlich frei gegeben.

Rechnen können Computer bekannter Weise ganz gut, erst wenn viele Werte zur Laufzeit gebraucht werden, kann es kritisch werden. Wann immer es möglich ist, diese Werte hard zu coden (also direkt in den Programmcode zu schreiben) oder selbige vor dem eigentlichen Applikationsstart in einer Schleife zu berechnen und in einem Array zu speichern, sollte von dieser Methode Gebrauch gemacht werden. Die Vorteile liegen klar auf der Hand, weniger Berechnungen zur Laufzeit, bessere Performance.

Wie der Name schon sagt, wird der Eventhandler für dieses Event beim Eintritt in jedes neue Bild ausgeführt. Bei einer Framerate von 30 Bildern pro Sekunde sind das 30 Aufrufe und wer hier nachlässig wird, muss mit einer ernsten, zudem überflüssigen Belastung rechnen. Die Lösung ist denkbar einfach, der Listener wird mit dem Aufruf von removeEventListener() entfernt.
(Siehe DestroyMe)

Eine niedrige Framerate bedeutet natürlich höhere Performance, dennoch ist es nicht emfehlenswert bei bewegten Inhalten (und die kommen ja recht häufig vor mit einer Framerate unter 20 zu arbeiten. Für eine Flüssige Darstellung sind 30 Frames pro Sekunde und nicht weniger als 25 ratsam.