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.
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
>
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: bazaar. launchpad. net/~smspillaz/ compiz- core/trunk/ view/head: /plugins/ blur/src/ blur.cpp# L1215,
http://
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: decorator that draws the normal window shadows, why decorator would need a little bit of logic to match cpp:UnityScreen ::getWindowPain tList). Instead, we draw all window- decorator decorator. I'm sure I saw a blueprint for that /bugs.launchpad .net/bugs/ 731685
> On Wed, Jun 8, 2011 at 3:16 PM, Daniel van Vugt <email address hidden> wrote:
>> If it's unity-window-
>> shouldn't it also be made to draw the panel shadow in the same way? At
>> most, unity-window-
>> 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.
> 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-
>> and unity-window-
>> 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:/
>>
>> 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