Hello.

On Sun, 16 Sep 2012 12:26:21 +0200 Aurélien Aptel <[email protected]> 
wrote:
> On Sun, Sep 16, 2012 at 9:47 AM, Roberto E. Vargas Caballero
> <[email protected]> wrote:
> > This serie of patches try fix the problem of the timeout in main loop, which
> > causes st wakeup each 20 ms even thare is noting to do.
> 
> The timeout "problem" was introduced to speed up the rendering when a
> lot of text is printed.
> The logic is basically to not redraw on every read when the throughput is 
> high:
> - try to read data for SELECT_TIMEOUT ms max
> - if something was read, handle it in the term
> - if something was read and the last call to draw was more than
> DRAW_TIMEOUT ms ago then redraw.
> 
> I don't have a unix machine at the moment but here is a simple testcase:
> 
>     $ dd if=/dev/random bs=4K count=100 | hexdump
> 
> Increase the count and compare with other terms if necessary.

Look at tip. I added a solution mostly based on heuristics, but it works
and it’s simple.

If  there  is  something  to read from the tty, handle it, then wait for
five microseconds in select() and see if the  buffer  filled  again.  If
yes,  handle  this and do it again. After a certain amount of such loops
(1000) break and redraw the terminal. This arbitary break is  there  be‐
cause  without  it  the user would see a stuttering in the output and it
seems to go wrong. This loop number is related to my development machine
and  a  better  solution  to calculate or replace it with a more natural
value would be more fitting solution.

In  the  benchmark  you  proposed (count=500) I could reproduce the same
times as urxvt with the above changes.


Sincerely,

Christoph Lohmann


Reply via email to