🚀 go-pugleaf

In article <4015@vdsvax.steinmetz.ge.com> barnett@steinmetz.ge.com (Bruce G. Barnett) writes:
[...]
>Then there are issues that complex window systems must address.
>Let's assume you have several applications running at once.
>Now let's assume that one application wants to track the mouse cursor
>as it passes through, while others are only interested in the
>selection of an item from a menu.
>
>SunView has a selection service that sits above all applications,
>and analyzes the stream of input events. It distributes to the
>applications the events they are interested in, in a concise 
>and efficient manner. Mouse-ahead works even in these conditions.
>
>I don't know how the Mac handles this task. I would assume that it is
>a lot simpler because only one task runs at a time.

Every application can define exactly what events it wants to
look at.  If it is running in single application environment
(i.e., the "normal" mode until now) this is not very
important, but under MultiFinder this can save time.

>Another example is the evolution from monochrome to color.
>How was the migration to a color system handled? Were the system calls
>changed, and therefore incompatible? Or were new calls created, that
>had similar functions to the monochrome but had new names and
>features?
>
>I would be extremely suprised, and extremely impressed, if the
>original calls to the monochrome Mac toolkit were integrated into
>the color version of the same. If you look at the complexity of
>coloring single pixels, and applying boolean masking operations to the
>screen, you can see that handling 1-bit deep and 2, 4, 8 or 24 bit
>deep pixels are very different at the hardware level.
>
>Yet the software interface should be the same, with only a few
>differences. I am guessing about the Mac toolkit. But Sun's PixRect
>package has only two special calls for color systems - setting and
>getting the current colormap. All of the other calls are used for
>both monochrome and color screens.

Surprise, same thing on the Mac II.  The entire original Mac
toolkit is still there and most routines have been updated to
act in a color environment if necessary.  For instance,
CopyBits() now copies bitmaps of any depth, performing the
necessary mapping between different color tables.

>This leads me to a third example.  SunView allows applications to
>specify the number of colors needed for each application. If possible,
>the colormap will contain as many maps as possible in the 256 possible
>values, allowing several tasks to run using just one colormap.

The Mac II has something better, called the Palette Manager.
A program can define what colors are necessary for displaying
any given window, with various contraints on the colors.  For
instance you can insist that such-and-such colors be present,
or insist that such-and-such colors are present, plus or minus
a certain tolerance, or ask for certain colors to be present, if
possible.   You can also ask that certain colors be present in
certain color table locations exactly, but that is frowned
upon by Apple since it is unfriendly to other programs in a
multitasking environment.

The Palette Manager makes sure that those colors are available
whenever the user switches the active window.  If there is a
color conflict (if an inactive window wants different colors
from the active window), the Palette Manager will try to
determine which colors are least used and replace them.

The Palette Manager also has color table animation
routines. 


David Fry				fry@huma1.harvard.EDU
Department of Mathematics		fry@harvma1.bitnet
Harvard University			...!harvard!huma1!fry
Cambridge, MA  02138