Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ucbvax!ramoth.sgi.COM!msc
From: msc@ramoth.sgi.COM.UUCP
Newsgroups: comp.windows.x
Subject: Re: overlay canvases
Message-ID: <8706041752.AA25242@ramoth.sgi.com>
Date: Thu, 4-Jun-87 13:52:21 EDT
Article-I.D.: ramoth.8706041752.AA25242
Posted: Thu Jun  4 13:52:21 1987
Date-Received: Sat, 6-Jun-87 09:50:58 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 66


	> I've never seen NeWS in action, unfortunately.]
If you're ever in this area I'll be happy to give you a demo.

	    In NeWS the semantics of overlay canvases are identical to
	    that of any other canvas.  The only restriction is that it
	    can't be reshaped separately from its parent.

	> Wrong, at least according to Revision A of 29 March 1987 of
	> the NeWS Manual (copyright 1987 by Sun Microsystems).  I quote

	> "Because of the way that overlays are implemented on some
	> displays, there will be performance problems if too many things
	> are written into the overlay.  They are intended to be used for
	> animated objects like rubber band lines and bounding boxes."

	etc.

This paragraph refers specifically to the implementation.  The performance
problem in this implementation is due to the overlay canvas being
"taken down" every time the cursor is moved. This is necessary due to
the software cursor on the Sun and is done using the display
list I mentioned in my last message.  Again these are weaknesses in
the implementation not in the model.

	> "The current color is usually ignored when drawing in
	> overlays.  They will generally be done in black.  This weakness
	> in the specification of overlays is an explicit feature: it's
	> there to allow overlays to be implemented using a variety of
	> tricks on different types of hardware."
Yes this is indeed to allow overlays to be implementated using XOR
or a single overlay plane.

	> I don't see any mention about reshaping.
There isn't.  I discovered this while putting the menus in the overlays.
In the very early version of NeWS that I first acquired reshaping overlays
would crash the server.  In the current Release 1.0 (pre-release)
it is ignored.

	> How do you put up a paint palette
	> menu?
Full color menus of course won't work in the overlay planes.  However
it is easy to modify the postscript code that implements the menu package
so that it will paint full color menus in the image planes.
My preferred paint palette is the whole screen anyway.  I wouldn't use
a menu.  I'd just let you pick any color on the screen.
	

	> Yes.  Of course, it can be captured within a library so that
	> application writers don't have to think about it.  If there is
Except for remote clients compiled with someone else's library.

	> There are
	> those already hacking overlays, by treating them as independent
	> "screens" with particular "known" (a priori, which is the
	> difficult part to overcome) geometry and visual characteristics
	> with respect to the "normal" screens.
The restriction of overlays to black and white is an attempt to encapsulate
some of these visual characteristics.  I agree that such encapsulation is
difficult and think the overlay canvas is an excellent start.

--
From the TARDIS of Mark Callow
msc@sgi.sgi.com, ...{ames,decwrl,sun}!sgi!msc
"There is much virtue in a window.  It is to a human being as a frame is to
a painting, as a proscenium to a play.  It strongly defines its content."