Table Cell Composition

[Harbs <ha...@gmail.com>]

While working on TLF tables, I came to the conclusion that the simplest way to handle the composition is to create a separate TExtFlow for each cell in a table. The reason for this being that the composition of each cell is in fact completely separate from the composition of the main text, and by separating it, we can compose all the cells before starting composition of the table. Once the cells are composed, composing the table is very straight-forward because we are dealing with known sizes.

I think each cell would have its own EditManager, but share an UndoManager with the main text.

Does anyone have any concerns with this approach?

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?

Harbs

Re: Table Cell Composition

[Alex Harui <ah...@adobe.com>]

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" <ha...@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.

Re: Table Cell Composition

[Harbs <ha...@gmail.com>]

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.

Re: Table Cell Composition

[Alex Harui <ah...@adobe.com>]

On 4/6/14 2:42 AM, "Harbs" <ha...@gmail.com> wrote:

>While working on TLF tables, I came to the conclusion that the simplest
>way to handle the composition is to create a separate TExtFlow for each
>cell in a table. The reason for this being that the composition of each
>cell is in fact completely separate from the composition of the main
>text, and by separating it, we can compose all the cells before starting
>composition of the table. Once the cells are composed, composing the
>table is very straight-forward because we are dealing with known sizes.
Makes sense to me.
>
>I think each cell would have its own EditManager, but share an
>UndoManager with the main text.
>
>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.
>
>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.

-Alex