git.iko.soy/vty
on 5.3 help sign in
vty/DESIGN
32 lines 1.7 kB history raw
1On the design of vty
3 It appears to me that there are two kinds of graphical
4applications, regardless of the output form; the synchronous and the
5asynchronous. Synchronous displays update as changes occur; a good
6example of this type is nethack, with its many newsym() calls embedded
7in the logic. Synchronous applications use very little abstractable
8code, and in practice all use low level interfaces such as terminfo.
10 Asynchronous screen programs, OTOH, do not have update code within
11the main logic. Instead, they perform output "lazily", only computing
12it at periodic refresh points. Because "backtracking" is not
13rendered, asynchronous screen programs use less bandwidth, and can
14(but usually don't) use less CPU. Asynchronous programs have their
15update logic centralized in such a way that it can be abstracted as a
16library; this is what both vty and curses are.
18 In the past, vty has had considerable confusion and race
19conditions due to the fact that screen resizes can occur
20asynchronously with respect to output. Vty 3.0 handles this in an
21very elegant (IMO) way, by treating resizes as just another input
22event; the size of the picture being output at any time need have no
23relation to the screen, though of course corruption will result if
24they are different.
26 On a "real" terminal (termcap, not xcurses), output and input can
27be completely separated; they can occur concurrently, and do not
28effect each other. Because of this we simplify the internal structure
29by using entirely different mechanisms for input and output. This is
30also a great benefit because of the differing characteristics of input
31code (complicated, best table driven, etc) versus output code
32(performance critical).