[comp.windows.x] Painting through obscuring windows

jcb@lfcs.ed.ac.uk (Julian Bradfield) (06/24/88)

I've just started using X (V10R4) for an application, and I used 
XBitmapBitsPut to paint a window. Since I only read the Xlib
documentation for XBitmapBitsPut at first, I didn't know that the
mask  could be given as zero to mean no mask, so I created an
all-ones bitmap to use as a mask. The result of this was that the
whole window was painted on the screen, including the bits that
were obscured by sibling windows. This surprised me, since I had
thought from what I read that one should be able to draw through
windows only with DrawThrough, and then only through your children.
Could somebody point me to the piece of documentation that I need to
reinterpret?  Thanks.

mbl@lri.lri.fr (Lafon) (07/02/88)

In article <432@etive.ed.ac.uk> jcb@lfcs.ed.ac.uk (Julian Bradfield) writes:

> I've just started using X (V10R4) for an application, and I used 
> XBitmapBitsPut to paint a window. Since I only read the Xlib
> documentation for XBitmapBitsPut at first, I didn't know that the
> mask  could be given as zero to mean no mask, so I created an
> all-ones bitmap to use as a mask. The result of this was that the
> whole window was painted on the screen, including the bits that
> were obscured by sibling windows. This surprised me, since I had
> thought from what I read that one should be able to draw through
> windows only with DrawThrough, and then only through your children.
> Could somebody point me to the piece of documentation that I need to
> reinterpret?  Thanks.

The problem is not in the documentation, but in the code ...

The Sun implementation of the XV10R4 server has a bug: when you
write a bitmap with a mask (with XBitmapBitsPut) the clipping is ignored
and the bitmap can be displayed out of the window and on top of its
subwindows.
I discovered this while trying to display icons ala Macintosh Finder:
icons on the border of the window were overflowing, scrambling the windows
below or the screen background!

The patch below fixes this. It applies to the file libsun/put.c.
The line numbers are relative to a unmodified XV10R4 version.
(sure it's a bug of the sun implementation because it does not happen on HP)

=== patch to X.V10R4/X/libsun/put.c (function BitsPut)

*** put.c.gen	Thu Jan 22 00:08:20 1987
--- put.c	Wed Nov 11 19:13:08 1987
***************
*** 254,262 ****
--- 254,275 ----
  
  	    GetNextClip(clips, cleft, ctop, cwidth, cheight);
  	    if (OverLap(cleft, ctop, cwidth, cheight, dstx, dsty, width, height)) {
+ /***[mbl]11/11/87***/
+ 		int         tleft = (cleft > dstx ? cleft : dstx);
+ 		int         ttop = (ctop > dsty ? ctop : dsty);
+ 		int         twidth = (cleft + cwidth < dstx + width ? cleft + cwidth : dstx + width) - tleft;
+ 		int         theight = (ctop + cheight < dsty + height ? ctop + cheight : dsty + height) - ttop;
+ 		int         sx = (tleft - dstx);
+ 		int         sy = (ttop - dsty);
+ 
  		CheckCursor(cleft, ctop, cwidth, cheight);
+ 		pr_stencil(PixRect, tleft, ttop, twidth, theight, op | PIX_DONTCLIP,
+ 		    stencil, sx, sy, Src, sx, sy);
+ /***original
+ 		CheckCursor(cleft, ctop, cwidth, cheight);
  		pr_stencil(PixRect, dstx, dsty, width, height, op,
  		    stencil, 0, 0, Src, 0, 0);
+ ***/
  	    }
  	} while (--clipcount > 0);
  	pr_destroy(stencil);

=== end of patch

If you have applied the patches for color support distributed here a (long)
while ago, the patch is the same but the line numbers are the following:
*** 281,289 ****
--- 281,302 ----

Hope this helps... (and happy to see some people still use X10,
a small & fast & understandable system :-)


Michel Beaudouin-Lafon				(1) 69 41 66 29
Laboratoire de Recherche en Informatique	mbl@sun1.lri.fr
Batiment 490 - Faculte d'Orsay
91405 - ORSAY Cedex
FRANCE