LinuxAsmTools - HowTo speed up displays



Fast text displays mini-HOWTO
jeff owens, jeff@linuxasmtools.net
v1.01, 19 April 2009

How to speed up text displays
______________________________________________________________________

Table of Contents


1. Disclaimer

2. Introduction

3. What is the problem?

4. How do text displays work?

5. What can we do?

6. What solutions are available?

7. Finding more information
______________________________________________________________________

1. Disclaimer

The following document is offered in good faith as comprising only
safe programming and procedures. No responsibility is accepted by the
author for any loss or damage caused in any way to any person or
equipment, as a direct or indirect consequence of following these
instructions.


2. Introduction

The most recent version of this document can always be found at
http://linuxasmtools.net

There has been a lot of interest in speeding up graphical
displays, but little discussion of text displays. Generally,
text display speeds have been sufficient or a few design
changes can fix the problems. Also, graphical applications
dominate much of the Linux world and their slow speed has
grabbed programmer attention. Should we spend time speeding
up text displays? This howto looks for some answers.

3. What is the problem?

Is there a problem? For most people the answer is: no!
The few that are having problems assume it is due to slow
hardware or something else.

The symptoms of text speed problems are:
* flickering displays
* flashing areas of screen that are too fast
to see.
* parts of display updating slowly
* And, the worst case, slow program execution.

These problems occur normally when a computer is under
heavy load, using older hardware, or running non-optimized
display handling.

It is difficult to know how may users have these
problems, it may be quite high.

4. How do text displays work?

There are three main areas of text usage on Linux,
they are:

* X window text
* X terminal
* console

All text handling converts ASCII codes to a graphic
using font tables. The resulting pixels are written
into display memory and a character appears.

4.1 X window text displays

The X server talks directly to display memory and
all text handling is internal to the server. It
is usually fast and of little interest to this howto.

Additionally, xlib includes some features
mentioned in this howto

4.2 X terminal displays and console displays

Both X terminals and console displays use control
codes embedded with the text. They must scan
the text for control codes such as line-feed,
cursor movement, color selection, and many others.
Once the control codes are processed, the remaining
ascii is converted to a graphic using font tables.

All this uses several layers of processing and may
be fertile ground for optimization.

5. What can we do?

If you look at the typical program, it builds a
line of data, sets the display color, moves the
cursor to start of line, and finally writes the
line.

We can save a little time by collecting all these
operations into one text string and writing
everything with one kernel call.

We could speed things up a little more by collecting
multiple lines and writing them all at once.

We could put the display in wrap mode, and eliminate
all the line-feed characters.

We could track display location and color and only
output control strings if a change occurs.

We could keep track of what is already on the display
and only send data if a area is changed.

We could sort the data by display location and
output data in sequence.

We could collect all writes and only send the
latest data for a area of the screen.

Would all these changes make a big difference?
For most programs that display a lot of text, they
will make a huge difference. Generally, programmers
focus on their application and not on display
optimization. This means, the typical program
has slow display logic.

Isn't this too complicated for programmers to
worry about? It is complicated, but programmers
don't need to worry about it. Instead, all we
need is a display handler to do it for us.

The design we need is a cache (image of display)
that can be read or written like a disk drive.
This provides a series of additional advantages:

* reading of data and colors from display
* functions better matched to most applications.
* ability to detect data that has not changed
and does not need display update.

The cache works by keeping a copy of each display
character and its color. Each character and
color also has a flag which is set when the
they are not in sync with display contents.

When a write request comes in the data is
compared to image contents and flags are
set only if the data will change the display.
The color is also tracked and if it changes,
the flags are set to force a display update.

6. What solutions are available?

The library asmliba provides all the features
discussed in this howto and also includes a
keyboard cache. See section 7

The AsmLiba_tutor has some example code and
introduces the cache functions.

The X server is usually called from xlib and it
has a function cache.


7. Finding more information

AsmLiba - fast display and keyboard cache.
http://linuxasmtools.net/asmliba.html

AsmLiba_tutor - tutorial
http://linuxasmtools.net/asmliba_tutorial.html