Unresponsive applications

[Bill Spitzak]

The linked document pretty clearly indicates that you can just extend 
the blurry render further into the window. There are only 4 parameters 
to set the margin thickness, yet the demo program draws a more complex 
rendering where the resulting shape two rectangular opaque areas. This 
is entirely determined by the app drawing two opaque rectangles into the 
buffer.

In fact the implementation communicates the border to the compositor so 
it can blur that thickness around the edge before the window buffer 
(which just contains the partial transparency and no blurriness) is 
composited atop. I would guess this was to save time over blurring the 
entire window area before compositing, and perhaps to allow non-blurry 
transparent holes in the interior of the window. Blur is not comosited 
into the client buffer because it would make window dragging too slow.

Further proof that it works this way is the need to fill the region 
between the window border with white. This is because the default 
transparency would show up as very dark gray on a non-compositing window 
manager. If the blur was done by the compositor into the buffer then it 
could also do this white if it is not doing compositing.

> [1] http://msdn.microsoft.com/en-us/library/ms748975.aspx

If this is necessary to achieve acceptable speed, then communicating the 
border thickness to the compositor in the same way Windows does may be 
necessary. Border thickness may also be useful for previewing resizes or 
drawing thumbnail versions. I was hoping however it could be determined 
from the alpha channel of the buffer.