Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!columbia!rutgers!ames!ucbcad!ucbvax!ZERMATT.LCS.MIT.EDU!RWS From: RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) Newsgroups: comp.windows.x Subject: Re: ClipMode & V11 Message-ID: <870604083836.6.RWS@KILLINGTON.LCS.MIT.EDU> Date: Thu, 4-Jun-87 08:38:00 EDT Article-I.D.: KILLINGT.870604083836.6.RWS Posted: Thu Jun 4 08:38:00 1987 Date-Received: Sun, 7-Jun-87 17:40:21 EDT References: <8706032030.AA23855@ramoth.sgi.com> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 98 [I am not a NeWS expert. I may well be misunderstanding something. I've never seen NeWS in action, unfortunately.] 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 from the description of createoverlay, page 122 (Sun, please don't sue me): "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." "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." "NOTE In the current implementation, if there are multiple overlays active on the screen, only one of them will be visible, chosen essentially at random". I don't see any mention about reshaping. Only the NOTE sounds to me like a "feature of the current implemention", so I assume that any application writer should take the rest as gospel. The comment about "too many things" is so weak that I wouldn't know what a reasonable number was, and I certainly wouldn't depend on the results on a particular configuration as a guide. I would probably stick to very simple outline shapes, and it suggests. I note that there is no mention of suitability for menus, and the restriction to monochrome significantly reduces its utility for such things; I can think of lots of menu and other examples where color (and more than two) are useful. How do you put up a paint palette menu? And certainly the "chosen at random" of the current implementation (likely to remain a permanent feature?) means you can't use it for much but VERY ephemeral tasks, probably associated with the mouse. Otherwise, if two applications have overlays, and the user switches the input focus, there is no guarantee the user will see anything that makes sense. The overlay canvas is a very powerful paradigm that allows the hardware to be used to its fullest advantage. To me, the above all adds up to "not very powerful". Hardware with an overlay plane will be used to reasonable advantage, but I doubt "fullest", since application writers seem to have no way of discovering the true power of the particular overlay implementation. And hardware with multiple overlay planes will probably be under-utilized. The only weakness of overlays in NeWS is in the implementation of the monochrome server which does not support all drawing operations. I wonder if this is an omission from the documentation, or a misfeature of the implementation? Or maybe the "too many things" clause was really intended to capture this as well? I wrote an overlay canvas implementation that uses overlay planes and supports all the drawing operations of a regular canvas. I now use overlay canvases for menus as well as rubberbanding. Great, but how many application writers should depend on this working across all implementations of NeWS? In X, which has no similar notion, every client has to figure out for itself the most effective way to do rubberbanding and other feedback; i.e., display something without damaging the underlying image. Yes. Of course, it can be captured within a library so that application writers don't have to think about it. If there is no hardware overlay, then there isn't really that much you can do on a static color display besides xor, and that is fairly trivial to provide, and each application can do it independently (within their own windows) without interference from others. On a display with changeable colormaps, it is possible to do plane subset allocation and achieve the equivalent of (multiple) hardware overlays. Again, each application can do it independently, with the only interference being how many windows are off-color due to colormap conflicts. It is unclear to me at this point what the tradeoffs are between (as I understand NeWS) all windows at "true" color but at unknown reduction in their total color space and unknown "closeness" to their desired colors, and (as I understand X) having at least the "current" application at true color with full color space and known closeness to desired colors. This relates to the disagreement between the "ask for resources up front" and the "ask for resources as you go" methodologies. X is definitely missing the notion of discovering the existence of hardware overlays. This is an omission by design, since there seems to be very little agreement yet on hardware design of overlays. However, if such things can be codified, then applications can take advantage of them as well. 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.