In message: <[EMAIL PROTECTED]>
alexander <[EMAIL PROTECTED]> 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
: > [EMAIL PROTECTED]
:
: 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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
