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.
