xcompmgr -- Proposal 2: ARGB-window dropoff shadow

[Eeri Kask]

>> Why not fix the shadow under window issue and then this
>> won't be a problem?  XShape windows, of course, should
>> still have no shadows (unless the shadows can be shaped
>> to the window, but that seems like it would be hard to
>> achieve).
>
> Creating rectangular shadows is a bad things for windows
> with non-rectangular content.
>
> And creating a shadow that match the content shape is not
> trivial (at least for me :): you should take care of "hole"
> in the window content (think of a donut for example: is
> there a full shadow in the center, or only on the border ?)


It looks like drop-off shadows make sense only at window borders.
Then, the only question is how is a window border defined, i.e.
which pixels in the topologically "connected neighbourhood"
certainly don't belong to the window?

One possible choice to answer this question is: these pixels, which
don't belong to the "bounding-area" of the window as defined by the
XShape-extension.  This extension provides a very elegant concept of
which is window inferior, border area, and exterior.

Not quite unrelated is, in contrast, the XComposite-extension
(provided I understand it correctly) doesn't talk about window
topology at all but only about mixing pixel color values.  This is
an essential point: pixel colors and the topological structure of
some 2D-area are unrelated issues, i.e. 100% transparent pixel
doesn't automatically qualify this pixel to belong to the window
exterior!  If it did, then even with plain X11-protocol I can create
a completely transparent window by neither specifying its background
pixmap nor background color and this window appears invisible if
mapped.  (If this window has neither a title bar nor border, then
there is no way to decide if it exists and is mapped at all; anyways
we certainly don't think this window has a shape different than
given by its window-attributes (...if not, which shape would it have
then?).)

Therefore if xcompmgr could access the XShape bounding-area of a
particular window, and this area is not rectangular, the shadow
computation procedure is obvious; on current machines even
computationally not very expensive, as gaussian convolution is
2D->1D separable, so the only timecritical part is checking if a
particular pixel is "outside", and then adding up some
precomputed/stored values across some 1D-range.

(Unfortunately currently it looks like the XShape-extension and the
composite extension don't work together very well if at all:
consequently following the above reasoning would mean both of the
compositing routines, XRenderComposite() and XRenderFillRectangle(),
should be restricted to the "clip-area" of the XShape-extension.) :-)

Greetings,

    Eeri Kask