I like this:
addEventListener(Event.ADDED_TO_STAGE, bindEvents);
addEventListener(Event.UNLOAD, unbindEvents);
It's a nice pattern, I might steal it, although weak listeners will probably
suffice in most cases.
-Josh
On Tue, Sep 23, 2008 at 2:31 PM, Samuel Colak <[EMAIL PROTECTED]>wrote:
> Ralf,
>
> By the way - there is a statement at the end that got me a bit surprised
> relating to the calling of events or how things take place...He got it
> wrong...
>
> In effect from what i have witnessed.....
>
> ADDED_TO_STAGE
>
> occurs at the beginning of placing any object (even the application object
> gets "added" to the stage).
> The constructor of course is initiated very quickly but this does not mean
> its on the stage at all. Simply
> means that the object has been instantiated.
>
> When this event happens, you then has visibility of the stage object.
>
> In all UI Code which i write, the first thing i do in the constructor is
> the following...
>
> public class foo extends UIComponent {
>
> private var $hasInit:Boolean = false;
>
> public function get hasInit():Boolean { return $hasInit; }
>
> public function foo():void { // constructor
> init();
> addEventListener(Event.ADDED_TO_STAGE, bindEvents);
> addEventListener(Event.UNLOAD, unbindEvents);
> }
>
> protected function redraw(_isInit:Boolean=false):void {
> if (!$hasInit && !_isInit) return;
> if (_isInit) $hasInit = true; // initialisation code call made !
> // redraw code here !!
> }
>
> protected function bindEvents(_event:Event=null):void {
> removeEventListener(Event.ADDED_TO_STAGE, bindEvents); // clear the
> listener !!
> // the stage object is now in place - can do UI operations from this point
> forwards !
> redraw(true);
> }
>
> protected function unbindEvents(_event:Event=null):void {
> removeEventListener(Event.UNLOAD, unbindEvents); // clear the listener !!
> }
>
> protected function init():void {
> // customized init functionality !!
> }
>
> }
>
> The UI does not get updated until "AFTER" this point.
>
> Regards
> Samuel
>
> On Sep 23, 2008, at 6:14 AM, Samuel Colak wrote:
>
> Ralf,
> Thanks for the link - unfortunately its making a number of guesses and to
> be honest its not entirely accurate.
>
> Flex / Flash obviously is an event driven paradigm. The ENTER_FRAME is
> simply an avenue to do time-based
> event processing however this is not to say that the renderer itself is
> suspended at any time.
>
> It is just a coordinated timely event which unfortunately doesn't help in
> the UI rendering mechanism.
>
> Im pretty sure that certain graphic operations have been coordinated such
> that the UI Renderer effects things
> such as bitmap draw and fill operations in a locked fashion, but i would
> hazzard to state that the whole graphics
> pipeline does not get suspended for large number of modifications but
> rather per-operation followed by a "flush"
> instruction.
>
> This is why i'm kinda looking into a way of seeing if this exists on some
> low-level point.
>
> On a side-note, there exists functionality to suspend all background
> processing (basically suspending the event-
> notification recorder) - something i noticed a bit of time ago which gave
> me hope - since i wondered if in the
> bowel's of flex's core, there was such a UI function?
>
> I have attached a sample movie file - testTdCode.swf - about 300k which
> shows off the TDRenderer i wrote.
>
> Please excuse (Adobe that is) the use of the Flex Logo - obviously this is
> their property.
>
> It does a number of 3D manipulations (again my code for the renderer is
> open if people are interested) and then restructures a
> bitmap in realtime to the new dimension. You'll note that the hit on the
> CPU is very low until the mouse-move / mouse-down
> operations are detected within the "overlay".
>
> Regards,
> Samuel
>
> <testTDCode.swf>
>
> Im-At-Home BV
> http://www.im-at-home.com
>
> Overtoom 238-II / 1054HZ Amsterdam / The Netherlands
> Tel: +31 20 750 8304 (Amsterdam, NL) / +1 646 385 7345 (Manhattan, US)
> / Mobile: +31 64 328 5922
>
> Skype: samcolak / MSN: [EMAIL PROTECTED] / AIM: [EMAIL PROTECTED]
>
> On Sep 22, 2008, at 7:38 PM, Ralf Bokelberg wrote:
>
> You might want to have a look at this excerpt from Colin Mook's AS3 book:
> http://www.moock.org/blog/archives/000235.html
> It should give you a good understanding of how rendering works in
> Flash/Flex.
> Cheers
> Ralf.
>
> On Mon, Sep 22, 2008 at 7:15 PM, Ralf Bokelberg
> <[EMAIL PROTECTED] <ralf.bokelberg%40gmail.com>> wrote:
> > Afaik the Flashplayer does this for you. Nothing is rendered as long
> > as you are in a script. You can try to draw a line and then do a
> > simple while loop for 5 seconds. You will not see any updates of the
> > screen.
> >
> > Cheers
> > Ralf.
> >
> > On Mon, Sep 22, 2008 at 5:05 PM, Samuel Colak <[EMAIL
> > PROTECTED]<sam.colak%40im-at-home.com>>
> wrote:
> >> Alex, Adobe Guys, Community, Romans.....
> >>
> >> Is there a way to halt the UI Graphics Renderer so that (in a way) you
> >> can achieve the ability to post UI changes (in effect double
> >> buffering) before
> >> the renderer performs any UI update ? An obvious although troublesome
> >> way of doing this is with bitmap however the routines for drawing do not
> >> appear to be common between BitmapData and DisplayObject.
> >>
> >> Such like under DisplayObject
> >>
> >> graphics.unlock; // disassociate graphics device from
> >> renderer...
> >> graphics.[do stuff here].... // misc graphics routines...
> >> graphics.lock; // re-associate renderer to graphics device and
> >> flush activity to renderer
> >>
> >> (lock/unlock might be switched depending upon your perspective to the
> >> renderer)
> >>
> >> I might be jumping the gun with you guys producing some hardware
> >> acceleration so if i am apologies in advance.
> >>
> >> I am also aware that there is a possibility that if the re-associate
> >> does not take place, then all other render activity might be lost....
> >> so obviously
> >> this is not something that you do on a whim. Since everything is more
> >> of less sequential then im pretty sure that most programmers would not
> >> forget to do this.
> >
>
>
>
>
>
--
"Therefore, send not to know For whom the bell tolls. It tolls for thee."
http://flex.joshmcdonald.info/
:: Josh 'G-Funk' McDonald
:: 0437 221 380 :: [EMAIL PROTECTED]