summaryrefslogtreecommitdiff
path: root/x11/dxpc/DESCR
diff options
context:
space:
mode:
authoradam <adam>2005-01-19 15:10:12 +0000
committeradam <adam>2005-01-19 15:10:12 +0000
commite6374018ef5195b13fbb70b1606db26d88549275 (patch)
treec4ac12075856c4deb70bf4a6243375d2a806b602 /x11/dxpc/DESCR
parentb05758669fa234c6e1c24ef3228df4d7c5b34f35 (diff)
downloadpkgsrc-e6374018ef5195b13fbb70b1606db26d88549275.tar.gz
Changes 3.8.2:
* Enable build on system with gcc-3.x (which deprecate the old-style iostrams.h)
Diffstat (limited to 'x11/dxpc/DESCR')
-rw-r--r--x11/dxpc/DESCR41
1 files changed, 0 insertions, 41 deletions
diff --git a/x11/dxpc/DESCR b/x11/dxpc/DESCR
index 528ceebb8b6..7ae772c6310 100644
--- a/x11/dxpc/DESCR
+++ b/x11/dxpc/DESCR
@@ -7,44 +7,3 @@ dxpc consists of two processes:
the X clients are running)
2. a Server Proxy that runs on the "local" machine (the machine where
the X server is running)
-
-(Starting in the dxpc-3.0, release, the Client Proxy and Server Proxy
-are instances of the same program, called "dxpc"; command-line arguments
-tell the program whether it is acting as a Client Proxy or a Server Proxy.)
-
-The Client Proxy mimics an X server. X client applications connect
-to the Client Proxy using display "unix:8" (or "<hostname>:8"; dxpc
-supports both UNIX domain and TCP sockets). The Client Proxy receives
-X requests from the application, compresses them, and sends them to
-the Server Proxy. The Server Proxy uncompresses the requests and
-sends them to the real X server. Similarly, the Server Proxy receives
-X events, replies, and errors from the real X server. It compresses
-these messages and sends them to the Client Proxy, which uncompresses
-them and sends them to the client application.
-
-dxpc attempts to exploit patterns in X protocol messages to limit
-the amount of data sent between the Client Proxy and Server Proxy.
-For many X message types, each field has a high probability of having
-the same value as it had in some previous message of the same type.
-For such fields, dxpc maintains caches of the last 'n' values, with a
-least-recently-used replacement policy. If a field value in a new
-message is already present in the corresponding cache, dxpc transmits
-the value's index within the cache rather than the value itself.
-Because the number of bits needed to represent this index is typically
-much smaller than the number of bits needed to represent the value
-itself, transmission of cache indices typically results in a
-significant reduction in the number of bytes transmitted over
-the low-bandwidth link.
-
-In other cases, the value of a field in an X message may differ from
-that field's value in the last message of the same type by a small
-value. Some X messages contain sequence numbers or timestamps that
-have this property. X requests that create new objects also tend
-to have this property; in a "Create Window" request, for example,
-the value of the "Window ID" being created is typically equal to
-"(Window ID of the last window created) + (some small positive integer)."
-For fields like these, dxpc transmits the difference between the field
-value in the new message and the value of the corresponding field in
-the previous message of the same type. This value usually is a
-small number that can be encoded in far fewer bits than the actual
-field value.