lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev dev.16 patch 3 - SOURCE_CACHE etc.


From: Leonid Pauzner
Subject: Re: lynx-dev dev.16 patch 3 - SOURCE_CACHE etc.
Date: Thu, 9 Dec 1999 22:53:44 +0300 (MSK)

9-Dec-99 06:30 Klaus Weide wrote:

> * Corrected line counting in HTDisplayPartial, taking into account offsets
>   used for the various variables being compared.

> Index: 2.31/WWW/Library/Implementation/HTFormat.c
> --- 2.31/WWW/Library/Implementation/HTFormat.c Sat, 04 Dec 1999 12:57:50 -0600
> +++ 2.31(w)/WWW/Library/Implementation/HTFormat.c Wed, 08 Dec 1999 23:50:03 
> -0600
> @@ -528,11 +528,11 @@
>       **
>       **  So repaint the page only when necessary:
>       */
> -     if (((Newline_partial + display_lines) > NumOfLines_partial)
> +     if (((Newline_partial + display_lines) - 1 >= NumOfLines_partial)
                                                   ^^
>               /* current page not complete... */
                               ^
That is an equivalent changes above,
perhaps '>' should be used instead of '>=' here,
otherwise "current page is complete".

Thanks for the fix below.
[This tiny calculations aren't so shape as we could think since having
two asynchronous processes one could get another read from the socket
while executing display_page() so HText_getNumOfLines() may be increased
then. We are working with the pessimistic estimation, though.
One could work from the optimistic estimation if moving
LYMainLoop_pageDisplay() call before NumOfLines_partial = HText_getNumOfLines
Does this have any sence?]

>       && (partial_threshold > 0 ?
> -             ((Newline_partial + partial_threshold) < HText_getNumOfLines()) 
> :
> -             ((Newline_partial + display_lines) < HText_getNumOfLines()))
> +             ((Newline_partial + partial_threshold) -1 <= 
> HText_getNumOfLines()) :
> +             ((Newline_partial + display_lines) - 1 <= 
> HText_getNumOfLines()))
>               /*
>                * Originally we rendered by increments of 2 lines,
>                * but that got annoying on slow network connections.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]