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!garrityRWS@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.