In case you're wondering, the relevant code for the shadow clipping is here:

http://bazaar.launchpad.net/~smspillaz/compiz-core/trunk/view/head:/plugins/decor/src/decor.cpp#L77

What that does is for panels at least, recalculates every time a
window changes geometry, what should be "overlapping" the panel shadow
and then creates a region (eg nonrectangular space) of where the panel
shadow should be drawn so as /not/ to overlap those windows. Then on
::glDraw it clips the drawing of the panel shadow to that space.

However, this only takes into account the window position on the
assumption that *every window is exactly rectangular and not
transformed*. Which is obviously not the case considering that the
decorations have rounded corners.

Its probably possible to re-use some of the code from blur here:
http://bazaar.launchpad.net/~smspillaz/compiz-core/trunk/view/head:/plugins/blur/src/blur.cpp#L1215,
which is what blur uses to get the *exact nonrectangular clipping
area* for the blur underneath the window.

Unfortunately that code is largely undocumented and I haven't been
able to make it work for this case. Maybe a mathematical genius can
figure it out :)

On Wed, Jun 8, 2011 at 3:31 PM, Sam Spilsbury <email address hidden> wrote:
> On Wed, Jun 8, 2011 at 3:16 PM, Daniel van Vugt <email address hidden> wrote:
>> If it's unity-window-decorator that draws the normal window shadows, why
>> shouldn't it also be made to draw the panel shadow in the same way? At
>> most, unity-window-decorator would need a little bit of logic to match
>> the Dock window type. Admittedly that might affect the Launcher too...
>> But my limited understanding of the unity code is suggesting to me that
>> there are two separate components which draw shadows, and really there
>> should be only one.
>
> In gnome-classic it draws the panel shadow, correct.
>
> In unity, unity actually draws its own shadow on the panel. This is
> because there's a giant hac^Winnovative solution (tm) that we use to
> ensure that the panels get stacked correctly, yet we can blit them to
> the screen with OpenGL. So what actually happens is that the input
> windows for the panels are InputOutput and generally filled with
> garbage, yet we don't actually draw them (see
> unityshell.cpp:UnityScreen::getWindowPaintList). Instead, we draw all
> the screen elements directly using OpenGL.
>
> Because of this, the decor plugin is never able to "see" the panel
> being drawn and thus it cant put the shadow that the decorator asked
> to put on the panel on the panel.
>
> This isn't really too important for the unity case though, since there
> we're able to draw the panel shadow without painting the window twice
> (expensive)
>
>>
>> I guess it falls into the bucket of re-unifying compiz-window-decorator
>> and unity-window-decorator. I'm sure I saw a blueprint for that
>> somewhere...
>>
>> Please do correct me if this is just wild speculation :)
>>
>> --
>> You received this bug notification because you are a member of Unity
>> Bugs, which is subscribed to unity in Ubuntu.
>> https://bugs.launchpad.net/bugs/731685
>>
>> Title:
>>  Panel shadow conflicts with Window shadow in Ubuntu Classic Desktop
>>  Session
>>
>> Status in Compiz:
>>  New
>> Status in Unity:
>>  Confirmed
>> Status in “compiz” package in Ubuntu:
>>  New
>> Status in “unity” package in Ubuntu:
>>  Confirmed
>>
>> Bug description:
>>  When logging in with the session 'Ubuntu Classic Desktop' (with the
>>  traditional gnome environment) there seems to be a problem with the
>>  panel shadows drawn by Compiz. When moving a window close to one of
>>  the panels, the shadows seem to cancel one another out. I've attached
>>  a screenshot to show what I mean.
>>
>
>
>
> --
> Sam Spilsbury
>



-- 
Sam Spilsbury