Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!think!ames!lll-tis!helios.ee.lbl.gov!nosc!ucsd!ucsdhub!esosun!seismo!uunet!masscomp!black
From: black@masscomp.UUCP (Sam Black)
Newsgroups: comp.windows.x
Subject: Re: Multiple screens and multiple visuals
Keywords: screens,visuals,overlay
Message-ID: <142@masscomp.UUCP>
Date: 26 Aug 88 14:00:48 GMT
References: <13562@agate.BERKELEY.EDU> <8808231403.AA22734@EXPO.LCS.MIT.EDU>
Reply-To: black@masscomp.UUCP (Sam Black)
Organization: MASSCOMP - Westford, Ma
Lines: 62
Summary:
Expires:
Sender:
Followup-To:
Distribution:

In article <8808231403.AA22734@EXPO.LCS.MIT.EDU> jim@EXPO.LCS.MIT.EDU (Jim Fulton) writes:
>
>Two visuals can coexist on the same screen.  Several of the various graphics
>supercomputers that are hitting the market already allow 24-bit deep
>DirectColor or some number of bits of PseudoColor window to be located at
>arbitrary locations on the screen.
>
> ...
>
>Instead of having these two separate screens, it would be much nicer to
>have both visuals available on one screen (if people like the extra real
>estate, they should use a window manager that provides rooms).  This would
>allow monochrome applications to use the faster StaticGray visual and color
>applications to use a PseudoColor visual.
>
>							Jim Fulton
>							MIT X Consortium

I agree with Jim for displays that use multiple screens to try to support
both color and monochrome (or the like).  But it does not deal gracefully with
overlay planes.

Our servers support both multiple visuals AND multiple virtual screens on the
same physical display.  Screen 1 supports the overlay planes on our displays.

For example, our 28-plane display supports (basicallly) 4 24-plane DirectColor
visuals on screen 0 (4 concurrent colormaps), and a a 2-plane StaticGray visual
on screen 1 to support the 2 overlay planes.  Likewise, our 12-plane display
supports 1 10-plane PseudoColor visual, 4 8-plane PseudoColor visuals (subsets
of the 10-plane visual to simulate 4 hardware colormaps), and a 2-plane
StaticGray visual on screen 1 to support the 2 overlay planes.

Graphics in the overlay planes are INDEPENDENT of graphics in the other
visuals.  We initially implemented the overlay planes as a separate visual,
but this had problems.

First of all, it created unnecessary exposure events.  When an overlay window
gets unmapped, the underlying graphics need not be redrawn.  Implemented as a
visual, it was forced to be redrawn.

The other problem had to do with overlay planes in general.  Since overlay
planes always appear OVER the normal graphics, overlay windows always visually
"obscure" graphics windows, although they may be lower in the stacking order.
With separate screens, the stacking orders are disjoint, so the input focus
is screen-dependent.

Overall, the second screen solved all the problems that another visual would
have caused.  Screen jumping is not implemented in the server, but as a client
(actually we have 2 clients with different interfaces).

(I hope this explanation made sense.)

			- sam black

--------------------------------------

I'm pink, therefore I'm Spam.

	...!{decvax,uunet}!masscomp!black	UUCP
	black@masscomp.com			Internet

--------------------------------------