garrity@garrity.applicon.UUCP (06/01/87)
I am currently reading the X Window System Protocol, V11 document. I am, naturally, getting a little confused. I can't find any trace of ClipMode. Is it really gone? I would consider it a godsend if it was, because the ClipModeDrawThru was turning out to be a real headache. Does anyone know what the story is on this? -- Mike Garrity -- -- Asking is just polite demanding. -- Max Headroom -- -- snail: Applicon, a division of Schlumberger Systems, Inc. -- 829 Middlesex Tpk. -- P.O. box 7004 -- Billerica MA, 01821 -- -- uucp: {allegra|decvax|mit-eddie|utzoo}!linus!raybed2!applicon!garrity -- {amd|bbncca|cbosgd|wjh12|ihnp4|yale}!ima!applicon!garrity
RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (06/03/87)
ClipMode still exists in V11, as the subwindow-mode of a graphics context. It still exists because I don't know a reasonable way to support rubber-banding without it, and there are other uses for overlays that span window boundaries. The NeWS abstraction of an overlay is interesting, but I'm not yet convinced it suffices (viz., it seems to have an extremely weak semantics in NeWS).
jg@jumbo.dec.com (Jim Gettys) (06/03/87)
The subwindow mode in GC's allow you to control whether graphics draw through or not, rather than it being an attribute of the window. This seemed to be a better place for the function, since it is graphics related. - Jim
msc@ramoth.sgi.COM (Mark Callow) (06/03/87)
From: Robert Scheifler > ClipMode still exists in V11, as the subwindow-mode of a > graphics context. > It still exists because I don't know a reasonable way to > support rubber-banding without it, and there are other uses for > overlays that span window boundaries. The NeWS abstraction of > an overlay is interesting, but I'm not yet convinced it > suffices (viz., it seems to have an extremely weak semantics in > NeWS). 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. An overlay canvas is displayed above its parent without causing damage to the parent. Rubberbanding for moving and reshaping windows is done in an overlay canvas that covers the root window (and all other windows). The mechanism for display of overlay canvases is left up to server which can take advantage of overlay planes when they exist. On monochrome systems the server displays overlays by using an XOR drawing function and it builds a small display list that it uses to take down (remove) the overlay. The overlay canvas is a very powerful paradigm that allows the hardware to be used to its fullest advantage. The only weakness of overlays in NeWS is in the implementation of the monochrome server which does not support all drawing operations. 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. 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. According to my understanding of the V11 Protocol Document, these subwindow modes are simply mechanisms that allow a client to draw outside its usual boundaries. -- 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."
RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (06/04/87)
[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.