At some point a TextBlock is generated to create TextLines and then they are added to the display list. You can try hanging on to them, but it might mess up the recycler.
-Alex On 4/6/14 10:50 AM, "Harbs" <harbs.li...@gmail.com> wrote: > >On Apr 6, 2014, at 8:28 PM, Alex Harui wrote: > >>> Does anyone have any concerns with this approach? >> Performance and memory, of course. Don't know if pooling would help or >> avoiding spending too much time on cells that are off-screen. > >I'd expect performance to be better for most cases. Cells would only be >recomposed if the cells themselves were marked damaged. The only issue I >see in terms of performance would be overset cells since they would be >composed even though they would never be drawn on screen. It seems like a >reasonable tradeoff to me. > >As far as memory goes, I'm in the dark here. How much of a memory >overhead does a TextFlow have? I'm guessing that's where the memory >overhead would be with this approach? Maybe > >> Also: I'd like to reuse the composed cells of header and footer cells. >>> I'm not sure exactly where the text content is actually drawn. Can >>>anyone >>> point me in the right direction? >> Not sure what you mean here. > >Well, I'm not sure either. ;-) I suppose I'm talking about addChild(). I >suppose that's what "draws" it to screen. I'm guessing I could add a >Sprite for each header/footer cell, and add the same TextFlow to the >Sprites at the start/end of each table segment.
