When a GUI terminal emulator prints out a string, it has to convert the string to font codepoints, send the codepoints to a font renderer, get back a bitmap and blit that bitmap to the display via the X server.
The font renderer has to retrieve the glyphs and run them (did you know that Truetype/Opentype fonts are programs running inside a virtual machine in the font renderer?). During the process of running each glyph, an insane number of decisions are made with respect to font metrics, kerning (though monospace fonts and kerning don't mix well), Unicode compliance, and that's before we even reach the rasteriser which probably uses sub-pixel addressing. The terminal then has to take the buffer produced by the font rasteriser and blit it to the right place, taking care of pixel format conversions, alpha channels (for sub-pixel addressing), scrolling (which involves more blitting), et cetera.
In comparison, writing a string to a Virtual Terminal running in text mode (note: not a graphical console) involves writing that string to video memory. ‘Hello, World!’ involves writing 13 bytes (13 16-bit words if you want colours, too). The X font rasteriser hasn't even started its stretching exercises and knuckle cracking yet, and we're done. This is why text mode was so incredibly important in decades past. It's very fast to implement. Even scrolling is easier than you think: even on the venerable Motorola 6845-based MDA and CGA, you could scroll the screen vertically by writing a single 8-bit value to a register (could be 16... it's been too long). The screen refresh circuitry did the rest. You were essentially changing the start address of the frame buffer.
There's nothing you can do to make a graphical terminal as fast as a text mode terminal on the same computer. But take heart: there have been computers with slower text modes than the slowest graphical terminal you're ever likely to see on a modern computer. The original IBM PC was pretty bad (DOS did software scrolling, sigh). When I saw my first Minix console on an 80286, I was amazed at the speed of the (jump) scrolling. Progress is good.
Update: how to accelerate the terminal
@poige has already mentioned three in his answer, but here's my own take on them:
- Decrease the size of the terminal. My own terminals tend to grow till they fill screens, and they get slow as they do that. I get exasperated, annoyed at graphical terminals, then I resize them and everything's better. :)
- (@poige) Use a different terminal emulator. You can get a huge speed boost at the cost of some modern features.
xterm and rxvt work really well, it has a fantastic terminal emulator. I suspect your tests may have showed they perform better than the ‘modern’ ones.
- (@poige) Don't use scalable fonts. 1986 may call and ask for its terminals back, but you can't deny they're faster. ;)
- (@poige) Dumb down the font rasteriser by turning off anti-aliasing/sub-pixel addressing and hinting. Most of them allow overrides in environment variables, so you don't have to do this globally. Note: pointless if you choose a bitmap font.
- This will hurt the most: don't use (multiple panes in)
tmux — run two separate terminals side by side. When tmux displays two panes, it has to use terminal directives to move the cursor around a lot. Even though modern terminal libraries are very fast and good at optimising, they're still stealing bytes from your raw terminal bandwidth. To move the cursor to an arbitrary row on a DEC VT-compatible terminal, you send ESC [ row ; col H. That's 6–10 bytes. With multiple terminals, you're segregating the work, doing away with the need for positioning, optimisation, buffering and all the other stuff curses does, and making better use of multiple CPU cores.
There are eight standard ANSI colors, supported by every terminal emulator. Most terminal emulators also have eight bright variants of the standard ANSI colors.
However, the actual color values that the escape codes map to aren't standardized, and in fact they often slightly vary among terminal emulators. So if you do printf "\e[31;47mTest\n" to print red text on a white background, the actual hues of red and white you get may be different depending on the terminal emulator you use.
So that partly explains the problem: color values aren't standard, and LXTerminal may have different defaults for its color palette that you're not used to. If you look around in the settings, usually you can configure the color scheme to be whatever you like.
The other problem you face is that what the bold attribute actually does isn't standardized either. There are three possibilities: it can make the font bold, it can make the foreground color brighter, or it can both make the foreground color brighter and make the font bold.
Again, the default behavior here varies among terminal emulators, and you can usually change it if can you find the right setting. Grep for something mentioning 'bold' or 'bright'.
If you want to use a bright color, then you can use the so-called aixterm color escape codes instead of bold. These aren't standard, but they're supported in every modern terminal emulator I know of. Unlike bold, they always use bright colors, plus they can be used to display bright background colors.
So for example, if you wanted to print bright red text on a bright white background, you would do this: printf "\e[91;107mTest\n".
For reference, here's a table of all the color escape codes:
| ANSI | ANSI | ANSI | | Aixterm | Aixterm
| Color | FG Code | BG Code | Bright Color | FG Code | BG Code
+---------+---------+-------- +----------------+---------+--------
| Black | 30 | 40 | Bright Black | 90 | 100
| Red | 31 | 41 | Bright Red | 91 | 101
| Green | 32 | 42 | Bright Green | 92 | 102
| Yellow | 33 | 43 | Bright Yellow | 93 | 103
| Blue | 34 | 44 | Bright Blue | 94 | 104
| Magenta | 35 | 45 | Bright Magenta | 95 | 105
| Cyan | 36 | 46 | Bright Cyan | 96 | 106
| White | 37 | 47 | Bright White | 97 | 107
Best Answer
VT100s responded to character sequences sent to them as output. So echo'ing characters works because the terminal sees it as output. Typing characters is input; the terminal will respond only if the characters are echoed by the receiving computer. Your typical shell doesn't echo ESC, it interprets ESC as the prefix for some interactive input command. Run
catand type ESC Z RETURN and you'll see the usual VT100 response.