> 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:
I tried do the same thing putting the draw at the end of the loop, so if you have a high throughput you will read more characters in ttyread and you will do more operations that will not be rended. Maybe a way to improve my patches is testing is some data can be read from the file descriptors and in this case continue the loop. something like: int i = 0; for(;;) { FD_ZERO(&rfd); FD_SET(cmdfd, &rfd); FD_SET(xfd, &rfd); if(select(MAX(xfd, cmdfd)+1, &rfd, NULL, NULL, NULL) < 0) if(errno == EINTR) continue; die("select failed: %s\n", SERRNO); } repeat: if(FD_ISSET(cmdfd, &rfd)) ttyread(); while(XPending(xw.dpy)) { XNextEvent(xw.dpy, &ev); if(XFilterEvent(&ev, xw.win)) continue; if(handler[ev.type]) (handler[ev.type])(&ev); } if(i++ < 4) { struct timeval tv = {0}; FD_ZERO(&rfd); FD_SET(cmdfd, &rfd); FD_SET(xfd, &rfd); if(select(MAX(xfd, cmdfd)+1, &rfd, NULL, NULL, &tv) > 0) goto repeat; } i = 0; draw(); XFlush(xw.dpy); } > 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. $ time dd if=/dev/zero bs=4K count=100 | hexdump -C -v st before patches: real 0m1.250s user 0m0.616s sys 0m0.308s st after patches: real 0m1.151s user 0m0.536s sys 0m0.296s xterm: real 0m4.501s user 0m0.380s sys 0m0.156s uxterm: real 0m1.384s user 0m0.492s sys 0m0.256s