Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.ecn.uoknor.edu!qns3.qns.com!imci4!newsfeed.internetmci.com!in1.uu.net!athos.cc.bellcore.com!bnc.bellcore.com!bpane From: bpane@bnc.bellcore.com (Brian Pane) Newsgroups: comp.os.linux.development.apps,comp.os.linux.development.system,comp.os.linux.hardware,comp.os.linux.setup,comp.os.linux.x,comp.unix.bsd.386bsd.misc,comp.unix.bsd.bsdi.misc,comp.unix.bsd.freebsd.misc,comp.unix.bsd.netbsd.misc,comp.windows.x Subject: X Compression Re: Sometimes you need X server source Date: 3 Apr 1996 16:47:01 GMT Organization: Bell Communications Research Lines: 62 Distribution: world Message-ID: <4jua25$khh@athos.cc.bellcore.com> References: <4j21ph$crr@slappy.cs.utexas.edu> <4j36ev$prl@news.informatik.uni-oldenburg.de> <4ja099$r8k@ceylon.gte.com> <ragnaroek1996Mar28.063723.8733@news2.compulink.com> <4jkg1l$dl@titan.saturn.net> NNTP-Posting-Host: 128.96.164.33 Xref: euryale.cc.adfa.oz.au comp.os.linux.development.apps:14037 comp.os.linux.development.system:20539 comp.os.linux.hardware:35232 comp.os.linux.setup:48690 comp.os.linux.x:28359 comp.unix.bsd.386bsd.misc:422 comp.unix.bsd.bsdi.misc:2954 comp.unix.bsd.freebsd.misc:16524 comp.unix.bsd.netbsd.misc:2721 comp.windows.x:87000 In article <4jkg1l$dl@titan.saturn.net>, mi@aldan.saturn.net (Mikhail Teterin) writes: > Honorable Jonathan Walters > wrote on Mar 28, 1996 > (in article <ragnaroek1996Mar28.063723.8733@news2.compulink.com>): > > =Is it a figment of my imagination or do most modems already compress > =any data being transfered. That would make LBX a waste of time. > > 1st, LBX this is not really relevant, because it is not the only > thing one may or may not wish present in his/her X-server. > > 2nd, LBX is compressing on a much higher level, because it *knows*, > that it is compressing X-protocol. Modems, on the contrary, just > try to compress the stream of bits. A proper analogy whould be > optimization by compiler, which knows the source code (and can > easier understand what and how to optimize) and optimization of a > binary by hardware (CPU and friends). > > Back to X -- the whole idea of X-protocol (as well as of other > protocols) is, that it is to *explain* one side what the other side > wants. Like: > X-client: Hey, put the line from (X1,Y1) to (X2,Y2) for me > please. > X-server: Done. > X-client: I'd like to use the font like: "....". You have it? > [ ... ] > > Because LBX-aware X-software knows X-protocol, it can achieve much > better level of compression, then a "stupid" modem. Just like it > is easier (faster) to talk to someone, who has a clue (no offense ;) exactly! to elaborate on the issue a bit, the stream of X messages from client to server (or vice versa) tends to have a lot of patterns that can be exploited for use in compression. for example, many "Draw Rectangle" requests might have the same Y coordinate or the same Graphics Context. however, this sort of pattern isn't easily exploited by compression mechanisms that just look for repeated byte strings, since the values that show up repeatedly for a certain field of a certain message type are often small (16-bit) quantities. an X-protocol-aware compressor can achieve better results because it can parse the X messages to determine context. given that a message is a "Draw Rectangle" request, the compressor can compare the GC to the last 'n' GCs used for other requests of the same type; if there's a match, the compressor can transmit just the index (within the cache of 'n' values) of the GC value. based on my own experiences in developing dxpc, this works well for things like fonts, GCs, and Window IDs. it also works reasonably well for geometry (coordinates of lines/rectangles/etc). dxpc version 0.8 (available from ftp://sunsite.unc.edu/pub/Linux/Incoming, or from ftp://sunsite.unc.edu/pub/Linux/X11/xutils once they move it out of the "Incoming" directory) is currently getting about 3:1 compression on many X applications. the papers on HBX (http://www.cs.dartmouth.edu/~jmd/decs/DECSpage.html) contain a fairly extensive analysis of the merits of protocol-aware compression. brian pane bpane@bnc.bellcore.com