NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/windows/x/16535

Internet Message Format | 1992-09-10 | 3.5 KB

Path: sparky!uunet!mcsun!Germany.EU.net!Informatik.Uni-Dortmund.DE!tommy!klute
From: [e-mail] (Rainer Klute)
Newsgroups: comp.windows.x
Subject: Re: Server modifications to minimise network traffic
Date: 11 Sep 1992 07:30:08 GMT
Organization: CS Department, Dortmund University, Germany
Lines: 64
Sender: klute@tommy (Rainer Klute)
Distribution: world
Message-ID: <[e-mail]>
References: <[e-mail]>
NNTP-Posting-Host: tommy

In article <[e-mail]>, [e-mail]
(Milquetoast) writes:
|> The scenario we have is a closed network with a number of X terminals
|> or
|> workstations used as X terminals, with custom applications being run on
|> a
|> number of fileservers. We need to be able to minimise network traffic.
|> One
|> way that has been suggested of doing this is to build the bitmaps into
|> the
|> server and then use calls to the server to update the screen, rather
|> than
|> having to transmit the bitmaps. There would only need to be a limited
|> number
|> of bitmaps and there are no restrictions on the amount of memory and
|> cpu
|> power we could use. So, my questions:
|>
|> 1)    Is this technically possible?
|> 2)    Is it desirable?
|> 3)    Is there any documentation or books that would point me in the right
|> direction, or do I have to go straight to the source?
|> 3)    Are there other ways of minimising network traffic that we should
|> also
|> investigate?

You should take a look into The X Resource, Issue 3. It contains an
interesting article about "Improving X Application Performance" by Chris D.
Peterson and Sharon Chang. You will find there a lot of programming hints
to speed up Xlib and Xt applications, focussed especially on minimizing
network traffic.

There is one topic, however, that I missed in the article: "bitmaps" (as
you call them) or pixel graphics in general. Transferring images over the
network causes a lot of traffic and should be reduced as much as possible.
My approach would be as follows:

1. Draw the image on a window once, and use backing store if possible. This
tells the server that it would be useful to keep the window's contents even
if it is obscured. When it gets unobscured the server redraws the contents
itself and does not send an expose event. The drawback of this approach is
that your server might not maintain backing store at all, or might decide
to give up your window's backing store at any time. So while backing store
is useful in general, your client must be prepared to redraw the window's
contents at any time.

2. Instead of drawing to the window directly you could create a pixmap on
the server and transfer the image to the pixmap. An expose event on the
window could be answered by copying the pixmap's contents to the window
then. This is an operation performed in the server - the network traffic is
limited to the expose event and the request to copy from pixmap to window.
The drawback is that large pixmaps take away a lot of server memory.
Especially on X terminals you must be aware of the fact that the server
might fail to allocate a pixmap. And even if it doesn't, the server's free
memory is reduced, which may have a considerable impact on other clients.

Bottom line: Use as much of the server's capabilities as possible, but
don't rely on them. Be always prepared to handle redraw yourself.

--
  Dipl.-Inform. Rainer Klute      [e-mail]
  Univ. Dortmund, IRB
  Postfach 500500         |)|/    Tel.: [phone]
D-W4600 Dortmund 50       |\|\    Fax : [phone]