Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!elroy.jpl.nasa.gov!sdd.hp.com!think.com!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.windows.x
Subject: Re: PC X servers / backing store
Message-ID: <1991Mar6.034359.5255@Think.COM>
Date: 6 Mar 91 03:43:59 GMT
References: <9103032356.AA00215@devnull.Eng.Sun.COM> <952@boing.UUCP>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 58

In article <952@boing.UUCP> dale@boing.UUCP (Dale Luck) writes:
>If the application is required to maintain the backing pixmap, guess what?
>The same resources get chewed too. 

But they aren't really the *same* resources.  Clients (certainly complex
ones that produce such complicated output that it can't be regenerated
easily) generally run on powerful computers with lots of physical memory
and virtual memory with lots of swap space.  Servers are frequently
small-memory X terminals, or PCs without virtual memory.  A megabyte on the
server is a much bigger deal than on the client machine.

>So now let's say the server does do backing store but the client can depend on
>it? So they now do there own backing store, but the user has requested that
>all windows have backing store and we see that the server now wastes backing
>store bits on a window that is doing its own backing store. So when that window
>goes behind all others we see the server eating twice as much memory for that
>window.

I don't understand the above paragraph.  Was the "can" in the first
sentence supposed to be "can't"?  In either case, why is the *server*
eating *twice* as much memory?

>
>IMHO, there is nothing wrong with a decision by a company to specify
>that the servers that are used to display their application must have a
>working backing store implementation as well as enough resources(memory) to
>insure that the bits do not get lost during standard operation of the program.
>These are prerequisites for running this application.

How much is "enough resources"?  The server doesn't know how many windows
the application plans on opening.  It doesn't know how many applications
will be trying to use it.  It can only maintain backing store for a finite
number of windows simultaneously, and not too many if it only has physical
memory to use.

>The Amiga guarentees backing store with it's SMART_REFRESH windows.
>The programmer is able to choose whether they can handle expose
>events or not. SIMPLE_REFRESH windows always generate expose events
>whenever it is uncovered. SMART_REFRESH windows do not.
>If the Amiga was able to do this in a 16k layer library and a 64k
>graphics library (nearly all written in C) then it could be done
>in the X Window system as well.

It has nothing to do with the size of the library.  The X server can
faithfully maintain backing store for as long as it has memory.  Since
backing store is considered just an optimization, the X designers specified
that it has lower priority than other things; if the server needs to throw
away some backing store in order to allow another window to be opened or a
font to be loaded, it may, since fonts and windows are more important than
backing store.

How many SMART_REFRESH windows can you have at one time on an average sized
Amiga?
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar