Hello.
On Sun, 16 Sep 2012 12:26:21 +0200 Aurélien Aptel <aurelien.aptel_AT_gmail.com> wrote:
> On Sun, Sep 16, 2012 at 9:47 AM, Roberto E. Vargas Caballero
> <k0ga_AT_shike2.com> 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
Received on Sun Sep 16 2012 - 12:26:21 CEST