From: hedrick@dumas.rutgers.edu (Charles Hedrick) Subject: performance hints for X on slow systems Date: 1 Jul 92 03:03:27 GMT I'm currently trying out X on a 16MHz 386sx. I believe this is the slowest system capable of running Linux. Unfortunately scrolling is slow enough to present some problems. In the initial configuration it was so slow that I regarded it as unusable. However I've done a few things that make it almost OK. I thought I'd mention it for the benefit of others with similar problems: 1) you want to disable save unders and backing store (which saves both memory and CPU time). To do this, create a file .xserverrc in your home directory which is executable and contains #!/bin/sh exec /usr/bin/X11/X386 -su -bs or edit the startx script to pass -su -bs. 2) try to configure your software to avoid scrolling. In my case the major offender is more. It can be made to clear the screen rather than scrolling. Set an environment variable MORE=-p. I do this in .xinitrc: export MORE=-p and also in .bash_profile on systems to which I telnet. 3) there's a problem in my new KA9Q telnet (which may be present in the original code as well -- it's hard to tell at this point). It causes characters to be placed in the wrong position. I never saw it before because I was using a special linux termcap entry. Xterm sets TERM to vt100, which shows the problem. I'll upload a new KA9Q in a day or two, once I'm sure no other problems show up. In the meantime, if you're bothered by the problem, once you start KA9Q, you can use "stty -onlcr> /dev/ttypNN" (for the old stty) or "stty -onlcr </dev/ttypNN" (for the new one). To the X implementor: would it speed things up to support a reduced number of bitplanes? I really only need a few colors. I'd much rather have faster scrolling at the expense of fewer colors.
From: obz@sisd.kodak.com (Orest Zborowski COMP) Subject: Re: performance hints for X on slow systems Date: 1 Jul 92 15:40:17 GMT hedrick@dumas.rutgers.edu (Charles Hedrick) writes: >I'm currently trying out X on a 16MHz 386sx. I believe this is the >slowest system capable of running Linux. Unfortunately scrolling >is slow enough to present some problems. In the initial configuration >it was so slow that I regarded it as unusable. However I've done a >few things that make it almost OK. I thought I'd mention it for >the benefit of others with similar problems: > >1) you want to disable save unders and backing store (which saves >both memory and CPU time). To do this, create a file .xserverrc >in your home directory which is executable and contains > #!/bin/sh > exec /usr/bin/X11/X386 -su -bs >or edit the startx script to pass -su -bs. > >2) try to configure your software to avoid scrolling. In my case >the major offender is more. It can be made to clear the screen >rather than scrolling. Set an environment variable MORE=-p. >I do this in .xinitrc: > export MORE=-p >and also in .bash_profile on systems to which I telnet. these are great ideas. other ways is to use smaller windows. there is really not much we can do about the performance - the server is compiled with the highest optimization, we use shared libs, etc. if you've got a slow machine and slow video hardware... > >3) there's a problem in my new KA9Q telnet (which may be present in >the original code as well -- it's hard to tell at this point). It >causes characters to be placed in the wrong position. I never saw it >before because I was using a special linux termcap entry. Xterm sets >TERM to vt100, which shows the problem. I'll upload a new KA9Q in a >day or two, once I'm sure no other problems show up. In the meantime, >if you're bothered by the problem, once you start KA9Q, you can use >"stty -onlcr > /dev/ttypNN" (for the old stty) or "stty -onlcr >< /dev/ttypNN" (for the new one). > >To the X implementor: would it speed things up to support a reduced >number of bitplanes? I really only need a few colors. I'd much >rather have faster scrolling at the expense of fewer colors. that would be nice. apparently thomas roell had ideas to do this, since he has vga256 specifically (and ifdef'ed out vga16, etc). the problem is that he chose to take the 8bit cfb code (color framebuffer) and add the necessary bankswitching needed by the svga cards. to use lower depths would require writing a planar cfb package, which is not trivial. join the x11 mailing list - i'm gonna be better at supporting people who want to hack on the server, either to support new forms of svga or in supporting regular vga (through the vgalib, perhaps?) or in tackling vga16. zorst [obz@raster.kodak.com] -- zorst (orest zborowski) [obz@raster.Kodak.COM]