On Sun, 15 Aug 1999, Grant Stockly wrote:

> >I looked at this some time ago. The foolproof fix, to introduce checks
> >to wrap each line properly, has the potential to impact performance.
> 
> Have you tried that?

No, I haven't. I don't use dt anymore, and the question is not how it
works for me, the question is how it would it affect the slower macs.

> >Simply increasing the length of the buffers is dumb--how big do would
> >they have to be to satisfy every case, and then how much memory would
> >that waste on 640x480 monitors?
> 
> I'd be willing to waste the memory.  Is it just that easy?

I think so. Try increasing BUFSIZE in main.c. (The comment above the
assignment is bogus.)

> >I've come to think that a decent
> >solution would be to enter the resolution with a command line switch,
> >with suitable defaults, or even better, to detect the resolution at
> >start up and set the length of the buffers accordingly.
> 
> First we'd have to get the code working for long lines...

vt_putchar(), in vt.c, handles long lines by writing past the end of
the line buffer, into the "next" line. Since the lines buffers aren't
really in order this usually produces garbage on the right side of the
screen. Last line segfaults. Not good.

> I'm willing to do some work on it.

My idea was to rip off code from the Xserver to determine the
resolution, and then use that to set the buffer sizes. Now that I'm
looking at this code again, it looks easy enough to simply increase
the BUFSIZE to 256. Does that work for you?