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 [EMAIL PROTECTED]
