Path: utzoo!attcan!uunet!lll-winken!ames!oliveb!apple!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!wastebasket
From: wastebasket@LARRY.MCRCIM.MCGILL.EDU (the bit bucket)
Newsgroups: comp.windows.x
Subject: (none)
Message-ID: <8905070552.AA01249@Larry.McRCIM.McGill.EDU>
Date: 7 May 89 05:52:34 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 43

>> And any half-bright implementation of layers on a machine with that
>> deep a display should track the colors used.  An XTERM window uses
>> at most four colors (fg, bg, cursor, and pointer), so if it backs up
>> more than two bitplanes it's horribly inefficient.

Five: the pointer takes two colors.  Or does xterm force you to use the
same background color for the mouse cursor and the window or some such?
But the mouse cursor isn't saved in the backing store, so it shouldn't
be counted, as pointed out in the following....

> Again, this mixes up number of colors (3, pointer is stored
> separately) with the number of bits in the union of the necessary
> (and arbitrary) pixel values.

If it uses no more than four colors, it takes no more than two bits per
pixel to back it up - that's all the information content there is.
(Since it's really only three colors, sufficiently clever coding will
allow you to approach lg(3) ~= 1.58496 bits per pixel.  If you can take
advantage of the redundancy of the xterm window you can do even better,
but that's unlikely since the server presumably doesn't know that an
xterm window will never contain anything but character images and some
very simple graphics such as a few rectangles.)

Of course, these compacted representations usually will adversely
affect speed of redisplay from the backing-store, often badly enough
that it's worth spending the extra memory to get good redisplay speed.

>> So, it's really a quality of implementation issue.
> No, it's really a boolean arithmetic issue.

Like many other things, it's an exercise in tradeoffs - in this case,
memory versus speed.  It *is* a quality-of-implementation issue; the
issue is how well the designer of the backing-store algorithm balanced
these tradeoffs for the target environment.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu

(Use the signature addresses to reach me; mail to the address in the
header will be silently bit-bucketed - this is my attempt to avoid the
flood of failure messages that inevitably follow mail to xpert.)