[comp.windows.x] Backing store and ClipByChildren

jdi@sparky.UUCP (John Irwin) (10/27/88)

I am using Release 2 on a Sun with Adam de Boor's backing store code.

Page 22 of the Protocol doc (CreateWindow) states:
  "When the contents of obscured regions of a window are being maintained,
   regions obscured by non-inferior windows are included in the destination
   (and source, when the window is the source) of graphics requests, but
   regions obscured by inferior windows are not included.)"

Page 48 of the Protocol doc (CreateGC) states:
  "For ClipByChildren, both source and destination windows are additionally
   clipped by all viewable InputOutput children."

But what's actually happening is that input and output from/to a window with
a backing store and a viewable child is *not* being clipped by the child.  This
would seem to violate the above statements.  Is this the case in Release 3?

It seems that the Protocol is deficient here.  It would be useful to have
another GC boolean (with a better name than) ClipByChildrenWhenBackingStored,
which would allow a choice between being able to "slide" output under a child
window (the observed behaviour) and clipping it with the child window (the
documented behaviour).  Perhaps more useful is the ability to "slide" input
from under a child window; this seems more useful than the documented behaviour
which requires a blank space in the input where the child is.

Obviously none of this is an issue for a window without a backing store.


One other quick question.  Page 103 of the Xlib doc (drawing text) states:
  "Some applications, in particular terminal emulators, need to print image
   text in which both the foreground and background bits of each character
   are painted.  This avoids annoying flicker on many displays."

How does drawing the background avoid flicker?  Is performance another reason
for using image text?  Ie: Are there some displays that do image text faster
than regular text?

FYI:  These problems arose when trying to shoehorn X11 into Common Windows,
      which doesn't have an idea of "flavors" of text.


	-- John Irwin, Franz Inc.  (jdi%franz.UUCP@ucbarpa.Berkeley.EDU)