Path: utzoo!mnetor!uunet!husc6!cmcl2!nrl-cmf!ames!pasteur!ucbvax!ZERMATT.LCS.MIT.EDU!RWS From: RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) Newsgroups: comp.windows.x Subject: GC's and visual types Message-ID: <880310081928.5.RWS@KILLINGTON.LCS.MIT.EDU> Date: 10 Mar 88 13:19:00 GMT References: <8803092338.AA04490@sandoz.ardent.ether> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 36 Date: Wed, 09 Mar 88 15:37:56 PST From: hplabs!ardent!mlp 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.