Thanks much for the insight! I have not been following the item renderer posts, but I'll have to take a gander. Mostly what I've used renderers for is just using a component as a column in a datagrid -- or making a checkbox list extended from the list component.
If I'm going to do this -- I'll go all the way -- plus I have a grudge against vboxes now :P -- so I'll check out ListItemRenderer, I don't know off the top of my head how exactly I'm starting here. Using a list component that uses the custom ListItemRenderer instead of the built in one? I'll figure it out. Thanks again for throwing me in a better direction so quickly! ----- Original Message ----- From: Tracy Spratt To: [email protected] Sent: Tuesday, September 23, 2008 4:51 PM Subject: RE: [flexcoders] Speeding up draw time with nested VBoxes Yes, Yes, Yes, a list based component will perform MUCH better than what you have. If you have been following any of the item renderer posts/answers, you will see that item renderers are tightly integrated with the Flex framework, and are optimized to minimize rendering. The visual elements are re-used, and they make heavy use of the invalidation mechanism to make sure they do only the work really required. This makes them a bit of a pain to code, but the benefit is performance in just this kind of case. Now, do NOT make the item renderer out of a Vbox. You will get noticable benefit from the recycling, but not the most. Instead, make your renderer out of UIComponent. To do this is kind complicated. Copy the ListItemRenderer.as code and start with it as your base and modify it as needed. Look especially at the measure() code. That is what you will use to deal with your variable height subcomponents. It is not trivial, but certainly reasonable. Ok, if you want to do this in steps, to make sure you are getting some benefit, go ahead and make your renderer out of a Vbox, but remember it is only going to give you part of the performance gain. Commit to making the UIComponent the next stage. Tracy ------------------------------------------------------------------------------ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Reynolds Sent: Tuesday, September 23, 2008 5:18 PM To: [email protected] Subject: Re: [flexcoders] Speeding up draw time with nested VBoxes Thanks for the response! Yes I need Vbox functionality (unless I want to code the layout on creationComplete, which is my next idea to try -- but I'm sure to run into some caveats with resizing I think). Each component has a textfield with variable textHeight -- so things need to line up appropriately. They are pretty simple -- in the main vbox... each component has a label + textfield(2) + vbox(which contains a graphic + textfield -- again variable height). I did try taking out my html textboxes and graphics, but that did not improve performance at all -- which makes me think it really is the vbox slowing it down. Also it does indeed use scrollbars -- there is no way I can fit this on the screen without vertical scrolling. When you say replace it with a list -- does that really have the potential to perform better if the renderers need all the components mentioned above?? That would be worth trying, but just doesn't seem right. Jason ----- Original Message ----- From: Tracy Spratt To: [email protected] Sent: Tuesday, September 23, 2008 4:00 PM Subject: RE: [flexcoders] Speeding up draw time with nested VBoxes The first question is, do you need Vbox functionality, punk? ;) If so, then you are stuck with it. If you are just using it to lay out static vertical display, then there may be other approaches. Layout containers are very easy to use, but are "heavy" (slow) Next thing is they way you are doing things, you are forcing the Player to render up to (20 * 6) visual objects. They must be pretty simple components, because 3 seconds is pretty good. If they were complex, you would be looking at much longer delay. Does this process produce elements that are not visible, ie scrollbars? If yes, then why would you want to render (make visible) things you can't see? The list-based controls and item renderer mechanisms are designed to minimize rendering of visual objects, which is, and has always been, the player's performance bottleneck. Consider replacing addChild and Vbox with a List and a custom item renderer. Tracy ---------------------------------------------------------------------------- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Reynolds Sent: Tuesday, September 23, 2008 4:32 PM To: [email protected] Subject: [flexcoders] Speeding up draw time with nested VBoxes Hi, I have a component that extends VBox. I am making around 20 instances of this component. That component also contains a VBox, each of which contains 2-6 components. This takes a long time from creation to when I can see it on the screen -- around 3000ms. If I don't use a VBox in that 2nd component, it shaves around 700ms off the time. If I take out all my addChild's from the main component that is creating all of this (just creating the components) the total time is around 30ms. Is it the VBox that is hurting my performance by nature? And does anyone have any suggestions to speed it up? This is my first real performance problem since I started using flex. I know it's not the same, but with AS2 I could make 10X more display objects and not see this kind of performance. Any help is appreciated! Jason __________ Information from ESET NOD32 Antivirus, version of virus signature database 3466 (20080923) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 3466 (20080923) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
