Re: [flexcoders] Speeding up draw time with nested VBoxes
Ya, I was joking about the grudge -- just some nice frustrated learning
experience feelings! I don't know why but I've always had the impression that
item renderers slowed down the list/datagrid display, so it's good to see
people telling me I'm wrong.
I'll do the custom renderer on my 2nd pass of finishing up this application.
With this experience I've also found that using binded x/y values
'y={something.x + something.y}' really really slows things down as well.
Changing that code I was able to get down to around 1000ms. Not what I wanted,
but more acceptable forsure!!
I can see where renderers would make the code much more managable, so it will
always be in the back of my mind as well.
I appreciate all the feedback and pointers...
Thanks much,
Jason
- Original Message -
From: Michael Schmalle
To: flexcoders@yahoogroups.com
Sent: Tuesday, September 23, 2008 6:26 PM
Subject: Re: [flexcoders] Speeding up draw time with nested VBoxes
plus I have a grudge against vboxes now :P
It's not the gun that kills but the finger that pulled the trigger... ;-)
VBoxs serve their purposes and perform great when they are used 'correctly'.
I know that sounds bad but I don't mean it like that.
There are while(loops) in the layout code that acts like a circular saw, when
it's grinding it's taking A LOT of energy from the Player, the large the wood,
the more power it needs.
The plus side is, since the algorithms are so good in it, with controls that
have limited children and layout logic, there is a lot you can do with boxes
(stretching).
But Tracy is totally right, item renderers are what you need. I think this
will change in the future, the way developers look at 'renderers'. Renderers
abstract and decouple your repetitive layout and child creation code from the
main component controller. You can then at any time in the future optimize a
renderer of any kind easily and efficiently.
Mike
__ Information from ESET NOD32 Antivirus, version of virus signature
database 3468 (20080924) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
Re: [flexcoders] Speeding up draw time with nested VBoxes
Jason,
values 'y={something.x + something.y}'
Avoid bindings at all costs. When you create a binding expression, it adds
many more calls to the stack during runtime. Not saying there bad, but here
again, they need to be used in the correct places.
commitProperties() is your friend. If you are creating a custom component
that needs to 'perform' IE itemRenderer, do it in actionscript, you will
always make out better in the end and it's more maintainable.
Until there is greater code creation optimization from the mxml compiler,
binding adds weight and stack calls, it's definitely not free.
Mike
On Wed, Sep 24, 2008 at 11:40 AM, Jason Reynolds
[EMAIL PROTECTED] wrote:
Ya, I was joking about the grudge -- just some nice frustrated learning
experience feelings! I don't know why but I've always had the impression
that item renderers slowed down the list/datagrid display, so it's good to
see people telling me I'm wrong.
I'll do the custom renderer on my 2nd pass of finishing up this
application. With this experience I've also found that using binded x/y
values 'y={something.x + something.y}' really really slows things down as
well. Changing that code I was able to get down to around 1000ms. Not what I
wanted, but more acceptable forsure!!
I can see where renderers would make the code much more managable, so it
will always be in the back of my mind as well.
I appreciate all the feedback and pointers...
Thanks much,
Jason
- Original Message -
*From:* Michael Schmalle [EMAIL PROTECTED]
*To:* flexcoders@yahoogroups.com
*Sent:* Tuesday, September 23, 2008 6:26 PM
*Subject:* Re: [flexcoders] Speeding up draw time with nested VBoxes
plus I have a grudge against vboxes now :P
It's not the gun that kills but the finger that pulled the trigger... ;-)
VBoxs serve their purposes and perform great when they are used
'correctly'. I know that sounds bad but I don't mean it like that.
There are while(loops) in the layout code that acts like a circular saw,
when it's grinding it's taking A LOT of energy from the Player, the large
the wood, the more power it needs.
The plus side is, since the algorithms are so good in it, with controls
that have limited children and layout logic, there is a lot you can do with
boxes (stretching).
But Tracy is totally right, item renderers are what you need. I think this
will change in the future, the way developers look at 'renderers'.
Renderers abstract and decouple your repetitive layout and child creation
code from the main component controller. You can then at any time in the
future optimize a renderer of any kind easily and efficiently.
Mike
__ Information from ESET NOD32 Antivirus, version of virus
signature database 3468 (20080924) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
--
Teoti Graphix, LLC
http://www.teotigraphix.com
Teoti Graphix Blog
http://www.blog.teotigraphix.com
You can find more by solving the problem then by 'asking the question'.
[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
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: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Jason Reynolds Sent: Tuesday, September 23, 2008 4:32 PM To: flexcoders@yahoogroups.com 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
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: flexcoders@yahoogroups.com 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: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Jason Reynolds Sent: Tuesday, September 23, 2008 4:32 PM To: flexcoders@yahoogroups.com 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
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: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Jason Reynolds Sent: Tuesday, September 23, 2008 5:18 PM To: flexcoders@yahoogroups.com 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 mailto:[EMAIL PROTECTED] To: flexcoders@yahoogroups.com mailto:flexcoders@yahoogroups.com 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: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Jason Reynolds Sent: Tuesday, September 23, 2008 4:32 PM To: flexcoders@yahoogroups.com 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
Re: [flexcoders] Speeding up draw time with nested VBoxes
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: flexcoders@yahoogroups.com 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: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Jason Reynolds Sent: Tuesday, September 23, 2008 5:18 PM To: flexcoders@yahoogroups.com 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: flexcoders@yahoogroups.com 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: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Jason Reynolds Sent: Tuesday, September 23, 2008 4:32 PM To: flexcoders@yahoogroups.com Subject: [flexcoders] Speeding up draw time with nested VBoxes Hi, I have a component that extends VBox. I am making around 20 instances
Re: [flexcoders] Speeding up draw time with nested VBoxes
plus I have a grudge against vboxes now :P It's not the gun that kills but the finger that pulled the trigger... ;-) VBoxs serve their purposes and perform great when they are used 'correctly'. I know that sounds bad but I don't mean it like that. There are while(loops) in the layout code that acts like a circular saw, when it's grinding it's taking A LOT of energy from the Player, the large the wood, the more power it needs. The plus side is, since the algorithms are so good in it, with controls that have limited children and layout logic, there is a lot you can do with boxes (stretching). But Tracy is totally right, item renderers are what you need. I think this will change in the future, the way developers look at 'renderers'. Renderers abstract and decouple your repetitive layout and child creation code from the main component controller. You can then at any time in the future optimize a renderer of any kind easily and efficiently. Mike
