Bookmark June 16 2007

Biasanya, frame rate benar-benar merepotkan bila di Flex. Ada banyak alasan untuk berpendapat seperti itu. Terutama bila dalam membuat sebuah SWF yang mempunyai banyak frame. Flash sudah tentu lebih baik dalam menghasilkan SWF yang tahu bagaimana cara menangani preload dari timeline dengan frame yang banyak, demikian juga dalam menangani playback-nya. Karena Flash lebih baik dalam membuat SWF yang mempunyai content berupa animasi.

Sebaliknya urusan animasi di Flex tidak akan semudah itu, pertama dalam proses pembuatannya tidak dikenal konsep timeline, kemudian dalam playback-nya, akan di-eksekusi “lebih lambat”.
Karena, kita terdogma menerapkan sebuah “state” aplikasi/animasi di Flash berdasarkan frame (frame state navigation) dengan gotoAndStop() atau gotoAndPlay(), atau dengan mengatur visible/ alpha transparansi dari MovieClip.

Tidak demikian dengan Flex, karena Flex mengatur “state” dengan menggunakan DisplayList (Flash Player 9 DisplayList).
DisplayList memungkinkan anda mempunyai sebuah Sprite/MovieClip yang exist, tapi belum di-render di stage. Jadi bila pada animasi yang mempunyai banyak frame di timeline-nya, maka SWF hasil dari Flash akan melakukan preload asset-asset yang akan dimainkan terlebih dahulu. Sedangkan SWF hasil dari Flex tidak menerapkan proses preload seperti itu, sehingga animasi akan dijalankan lebih lambat.

Urusan “state” dalam SWF penting dalam interaksi dengan user, baik untuk navigasi maupun “application state” dan animasi. Di Flash kita terbiasa mengatur sebuah MovieClip dengan visible property ke false, yang artinya MovieClip sudah berada ditempatnya di stage, hanya saja belum terlihat, dan kemudian membuat visible menjadi true pada saat yang diperlukan. Sedangkan pada Flex terdapat mekanisme yang lebih mendasar dalam mengatur state. Pada banyak UI Component di framework Flex mengatur “state” dengan “add” dan “remove children” dari DisplayList. Umumnya sesaat setelah asset di jalankan (di-animasi-kan) akan langsung di “removed” dari DisplayList, dan akan menjadi prioritas utama oleh Garbage Collector untuk disingkirkan dari RAM. Sehingga ketika animasi dijalankan lagi, akan lebih lambat karena asset tadi akan harus di-load lagi ke memory.

Sedangkan di Flash, proses tadi berlangsung simple, karena secara “alami” kita selalu membuat frame awal sebagai preload, untuk memberitahukan Flash Player me-load semua asset – asset animasi sebelum playback. Dan proses “removing asset” yang sudah dimainkan dari RAM oleh Garbage Collector (Flash Player 8) biasanya akan dilakukan secara berkala setiap 60 detik atau ketika penggunaan RAM meningkat 20% atau lebih.

Yang perlu dipertimbangkan lagi adalah sewaktu embedding sound dan image di Flex. Karena di Flex tidak dikenal konsep Library, sehingga anda perlu menggunakan tag embed di code Flex anda untuk meng-asosiasi-kan image dan suara external ke sebuah variable, dan menggunakan variable itu untuk “link” ke asset. Asset-asset external ini di embed ke SWF sehingga anda tidak perlu khawatir tentang preloading misalnya dengan loadMovie atau Sound.loadSound.
Flex membungkus asset ini dengan class-class khusus yang dinamakan Class “Asset”, hampir mirip dengan kondisi ketika anda meng-import sound ke Flash Library dan meng-export-nya dengan linkage.
Bila kita meng-embed sebuah symbol MovieClip dari SWF eksternal, maka Flex akan membungkusnya sebagai class mx.core.MovieClipAsset, dan ketika kita meng-embed sebuah image, Flex akan membungkusnya sebagai class mx.core.BitmapAsset.
Artinya.., akan sulit mengakses class ini di SWF Flash 9. Kecuali dengan menempatkan MovieClipAsset dan BitmapAsset beserta sebagian framework Flex yang terkait di Flash 9 classes directory.