Date: Fri, 20 May 2005 23:20:19 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: arundel@h3c.de Cc: freebsd-hackers@freebsd.org Subject: Re: Looking for ANSI/VT100 code replacement. Message-ID: <20050520.232019.24855681.imp@bsdimp.com> In-Reply-To: <20050521015105.GA9063@skatecity> References: <20050520224726.GA7951@skatecity> <20050520230845.GC51092@dan.emsphone.com> <20050521015105.GA9063@skatecity>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20050521015105.GA9063@skatecity>
alexander <arundel@h3c.de> writes:
: On Fri May 20 05, Dan Nelson wrote:
: >
: > How often are you doing this? I wrote a quick microbenchmark and my
: > pIII-900 box can do 80000 writes() per second of "\e[5D\e[Kabcde". I
: > don't think that's your bottleneck. If it is, the usual solution is to
: > not do a write on every iteration. You've got a (maximum) 100hz screen
: > refresh rate anyhow, so doing more than 100 updates per second won't do
: > you any good. Even 10 is probably more than you need.
: >
: > --
: > Dan Nelson
: > dnelson@allantgroup.com
:
: Ohh...sorry for not telling you this. Yes. The app works alright when
: executed from the console. But my problem is with xterm or Eterm. They don't
: handle VT100 very well. I've added a nanosleep after each VT100 output but
: that didn't solve the issue. In fact Eterm or xterm might not update the value
: for as long as 5-8 seconds. I tested burncd's code and it uses fprintf to
: update the bytes it sends. And that works perfectly under Eterm and xterm.
Actually, xterm handles VT100 very well. The console does not. The
console implements a variant of ANSI that's different from the variant
of ANSI that the vt100 did. so if it works on the console, but acts
differently in an X term, that's likely due to the differences between
the terminal emulation both provide. Maybe the problem isn't one of
performance, but one of emulation?
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050520.232019.24855681.imp>