--- In flexcoders@yahoogroups.com, gabriel <[EMAIL PROTECTED]> wrote: > > On Wed, Nov 19, 2008 at 1:55 AM, manfred.karrer <[EMAIL PROTECTED]> wrote: > > is there an event dispatched when the callLater() is executed the last > > time? [...] > > Are you using callLater yourself? Or are you trying to figure out when will > your validation methods will get run?
i am not calling callLater() myself, but it seems that it is triggered by the flex framework because of performance peaks. my main problem is that i don´t get an event when the last item in the callLater stack is executed and the view is rendered. after the rendering i have to start an animation, but now i cannot know for sure the exact moment (different due cpu speed). alex harui has give me the solution for my problem in his answer (...updateComplete Event from the layoutManager...). i have to check if this solve my problem, but it looks promising. > > When you set something to be called by using callLater, it will get added to a > queue that will get processed at the handler for the Event.RENDER event, which > will run as the last possible moment before the player runs a screen update. yes i know about this. but it could happen that the queue cannot be completely precessed in one frame and then it will be delayed to the next frame (as far as i understood it). > > > we have the problem that a ui is rendered while a lot of other things are > > going on at the application. so the flex framework calls internally > > callLater() > > The framework will use callLater for it's validation cycles (again, it does > nothing then except adding the function and arguments to a queue to be run > later); hopefully it will clear out all the invalidations before it draws the > frame, again, on it's handler for the RENDER event, but if something goes > wrong or something is not well designed and something gets invalidated again > then, it will try to figure it out on the ENTER_FRAME handler on the next > frame (that is, it will draw the current frame without processing what has > just been added to the queue) because there's nothing you can do after the > RENDER handler gets run. This goes on, going from ENTER_FRAME to RENDERER > handlers until nothing is dirty. thanks for the detailed explanation! there could be some potential for performance loss because of unnecessary invalidations. i have to check the code if this could be the case. > > > to avoid the performance peak. but we need to know when the > > rendering of the ui is acually done, because some animation starts after > > rendering. now it seems that the creationComplete event if fired at some > > point, but the ui is not rendered fully but is delayed (depending on the > > target machines speed) > > CREATION_COMPLETE is dispatched from a UIComponent (or one of it's subclasses, > of course) after it's initialization phase has completed. That is, when the > parent of your component has added your component, it will run initialize, > that will make your component dispatch PREINITIALIZE, then your > createChildren() method will be run. A first pass at invalidateProperties, > invalidateSize and invalidateDisplay list will be run, and INITIALIZE will be > dispatched. > > Only after the LayoutManager has completely cleared out your invalidations > (only when your properties, size and layout have been processed completely > that first time) will your component dispatch CREATION_COMPLETE. > it seems for me that CREATION_COMPLETE is fired when the code like you discribe but because some execution could be delayed due the internal handling of callLater() it is unpredictable to say when the view is rendered completely. but as i mentioned before the updateComplete from the LayoutManager seems to be the solution. > > for a certain time. is this assumption correct? is there an event or another > > way how to gat the point when there is no more code to be executed which is > > delayed via callLater()? so far i understand callLater() it introduces a > > If you're using call later yourself for your own methods, you shouldn't have > any problems assuming that what you send it will get called before the current > frame is rendered. Only if you call it too late (on something that's being > called just before the frame is going to be rendered, probably on one of the > validation methods, updateDisplayList, measure, commitProperties) will it run > on the next frame. > > > uncotrollable asynchronity to the code execution. i have not investigated it > > so far, so maybe i am wrong with my assumtions, but if it behaves like this, > > i am wondering if callLater() is a good solution for avoiding the > > performance peaks because of the downside of asynchronity. is there a way > > how i can deactivate the callLater behaviour? > > callLater is a Good Thing for flex performance and the whole validation cycle > is based upon it. You have to be careful, though, of how you build your > components so that the dirty properties and be figured out quickly and in the > correct order. > > I'm writing this very quickly so it might come out messy and disorganized, > perhaps you might want to check out this short presentation, > > http://rojored.com/presentations/ts08/abrealey_gmontagne.presentation.pdf > http://rojored.com/presentations/ts08/abrealey_gmontagne.slides.pdf > > I hope this helps, > gabriel thanks a lot for your detailed answer! > > -- > gabriel montagné láscaris comneno > http://rojored.com > t/506.8367.6794 >
