On 9/3/13 9:19 AM, "Harbs" <[email protected]> wrote:
>Interesting that you are saying that states would be more performant than >resizing. Actually, I'm not saying that. I'm just pointing out different options. Some components could have very expensive resize algorithms or issues being shrunk to zero and restored. For example, mx:DataGrid will probably forget its column sizes when shrunk, and I've seen folks put a DataGrid in a renderer. > >Probably, the most performant method would be to calculate the placement >of each object programmatically without resizing anything. >(i.e. each obect has a placement position and you place the object based >on its placement and how many objects before its placement are visible.) > >That way all the built-in layout calculations should not be needed. > >On Sep 3, 2013, at 7:01 PM, Alex Harui wrote: > >> >> >> On 9/3/13 7:15 AM, "Harbs" <[email protected]> wrote: >> >>> To expand on Peter's response: >>> >>> Like Peter said, you create all the elements you need when the item >>> renderer is first created. If you don't want to show a button, set the >>> visibility to false and depending on how you are laying them out, you >>> might need to set the size to 0 as well. That way you can simulate them >>> being added and removed and have things reflow properly. You'll have to >>> set gap to 0 and you might need to play around with spacers as well for >>> this to work. >> FWIW, instead of "size to 0" others use includeInLayout and/or states to >> manage the existence and placement of widgets. Each strategy has >> different memory/performance trade-offs. >> >> -Alex >> >
