Input region support in the Shape extension

[Keith Packard]

Around 13 o'clock on Jan 28, Owen Taylor wrote:

> How does the Clip region come into play here?

The Clip region is purely for output; if the Clip region is different from 
the Input region, then the application may have input areas which are 
"invisible".

However, I see the Clip region as an anachronism now that we have ARGB 
windows.  A clip region will force non-AA borders between the window and 
the underlying content while an ARGB window provides for smooth blending.

And, ARGB windows have all of the same issues, without any way for the 
server to easily notice which areas are transparent.

In Twin, I actually look at the window and pass mouse events through 
transparent areas, but in X, I prefer the separation permitting 
applications to capture input in transparent areas.

> By "extents of the window", do you mean the "default Bounding region",
> as defined in shape extension? 

Yes.  Sorry for using mixed terminology.

> Do you also need fixes for the usage of
> [Xinerama]PointerInWindowIsVisible in WarpPointer?

Thanks for finding these.  I think this is right -- the assertion here is 
that WarpPointer checks the source to assert that the pointer is currently 
"inside" the window, which seems to now include the input region checks.

I've added the 5 line change to both of these functions.

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20050128/9354fa0d/attachment.pgp>