Re: lynx-dev Re: Lynx problems

[Leonid Pauzner]

19-Feb-2003 23:01 Ilya Zakharevich wrote:
> On Wed, Feb 19, 2003 at 12:43:08PM -0800, Ilya Zakharevich wrote:
>> To get better table support, I need to be able to freely
>> allocate/deallocate lines, including those deep inside the document.

> Leonid wrote:

>> Currently, we double the space in the worst case (=each line is in
>> Stbl).  This is not bad having in mind that most documents have
>> smaller tables, and 2^N malloc implementations waste 1/4 space at
>> average. Plus performance.

> I'm not concerned about quality of implementation (at this moment);
> only about the features.

>> The situation differs if you need multiple passes for your improved
>> table support.

> Yes.  What is currently missing in the table support is the vertical
> movement of the cells.  Currently Lynx produces:

>      Cell-1-line-1
>      Cell-1-line-2    Cell-2-line-1
>                     Cell-2-line-2

Ok, the factor change from 2 to 4 at worst.
At this moment you may think pool is a garbage collector,
just allocate lines when you need and sleep well:)
We may return to malloc-style at any moment (I will supply a patch).

> To fix it, we need to move cell-2 contents one line up.  All which is
> needed is a possibility to

>   a) split a line in two pieces (already present);

>   b) exchange two lines (trivial - the only non-trivial part is to
>      exchange two "runs" of the anchors chain)

>   c) merge two consequent lines into one (I have it done modulo
>      allocation).

> Hope this helps,
> Ilya

> P.S.    What the remaining statics are doing in GridText.c?  I see that
>       a lot of them were moved into struct HText (as they should).
>       Having the rest of them moved there we could easily implement
>       "real frames" in Lynx.  [Especially if Thomas included my
>       event-loop patches to NCurses. ;-]

I think most (if not all) GridText.c statics are parse-time variables,
can be moved into HText (with some performance degradation, and coding style
improvement). There was no need to encapsulate them until you implement the
real frames.

> P.P.S.  Why HText is not split into a (toplevel) Display-time part,
>       and a (child) Parse-time part (accessible via a pointer from
>       the Display part).  Then the (largish) Parse-time part could
>       be free()ed at the end of parse...

Looks reasonable. And what is the size of the parse-time part?
3Kb?




; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden