RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (03/10/88)
Date: Wed, 09 Mar 88 15:37:56 PST
From: hplabs!ardent!mlp <ardent!mlp@uunet.UU.NET>
Ii states on page 64 of the C interface to the X protocol
that GC's can be used with any drawable having the same
root and depth as the drawable used in creating it. Why
these restrictions but no restriction on the visual type's
of the two drawable's
A trivial answer might be that no one argued for such a restriction
during the protocol review.
The abstract view is that a drawable is just a collection of bits, and
the visual type indicates how the bits get mapped to colors. You will
find that none of the core graphics operations have their semantics
depend in any way on the visual type; rendering is orthogonal to
displaying (is there a standard term for this? visualization?). As
such, restricting the destination based on the visual type seemed
unnecessary. Also, we felt it very desirable for clients to be able to
use the same GC for both windows and pixmaps, when the depths matched.
Coupling that with the fact that pixmaps of a given depth can be used in
combination with any window of the same depth (e.g., in a CopyArea), it
isn't much of a stretch that the GC should therefore work with all
drawables of the same depth.
A related argument is that during the protocol design we talked about
providing the capability to change the visual type of a window
dynamically (the server would indicate what transformations were
allowed). That is still a possibility as an extension.
I realize that in hardware, for a given depth, different visual types
might imply different memory organization; if this is the basis of your
question, I would be interested in the details of why this is a problem.
If it is something else, like wanting to couple rendering with display
semantics, I would also like to hear more.carver@3d.DEC.COM (The danger on the rocks has surely passed, still I remain tied to the mast) (03/11/88)
> >Ii states on page 64 of the C interface to the X protocol >that GC's can be used with any drawable having the same >root and depth as the drawable used in creating it. Why >these restrictions but no restriction on the visual type's >of the two drawable's > >Mark Patrick >Ardent Computer >uunet!ardent!mlp > Let me start by saying that I would have liked GCs to be flexible enough to operate on drawables of differing depths. The reason this didn't happen, to my knowledge, is that it required additional state and semantics to manage variant and mixed depth operants/operations (e.g., tile depths that don't match destination depth). In addition, there are a number of compilications that arise with mixed depth operands: padding and truncation rules. If you disallowed any of the operations that would cause the above complication (i.e., match error), then having a GC operate on drawables of differing depths isn't much of an advantage and would produce more error conditions in the protocol (just more ways the application can go rong). But to address your question more directly, the semantics of the core GC are driven by drawing (rendition) considerations: how a window's (or pixmap's) pixels are accessed or updated. Visuals, on the otherhand, are specific to windows and specify how a window's pixels are displayed (i.e., mapped to video output). I believe the intention was to allow drawing to windows with matching depths, but different visuals, because the GC doesn't care how video is taken from the screen memory, it only cares how and where the window is organized in screen memory. One question I've been thinking about is whether windows having the same depth are required to be organized the same way in screen memory. I think that the answer is YES from the protocol's point of view, but possibly NO from the device dependent layer's point of view. If the DD layer was sensitive to the destination visual (probubly a no-no) or if extended window attributes entered into the picture then it could reorganize the drawing operations in an arbitrary way. --david carver