unity panel shadow opacity does not match panel opacity

The drop shadow on the top panel totally destroys the integrity of the desktop, when using the transparency feature.

Also, the drop shadow doesn't gel well with the top of the Launcher Panel. Looks very amateurish and unpolished!

Personally, I would like to see a check-box option for disabling the hideous drop shadow entirely, regardless of the Panel Opacity.

This could be placed in either the CCMS Ubuntu Unity Plugin or Window Decoration module.

Please, please! Fix this!

Definite ditto here! I'm sure it looks luvverley with a visible panel. Sadly, not so with a transparent panel. Quite hideous actually :-)
Please give us the option to delete it :-) Thanks.

Before n' after screenshots...

http://ubuntuforums.org/showpost.php?p=10628517&postcount=4

You used to be able to control which windows/panels (if any) had shadows in the Window Decorations section of CCSM. Is the Unity panel now outside of the control of the shadow settings accessible there? On older versions I think putting "any -dock" got rid of panel shadows; I see now that that's no longer the case. Maybe the Unity panel goes by a different name? Or is the drop shadow for the panel independent of the compiz settings?

This panel shadow causes #762247.

Here is a workaround...

CMMS -> Image Loading -> Disable (uncheck) Png

This makes the Drop shadow disappear.

Disabling Png Image Loading precludes you from enabling Unity MT "Love" Handles, but it's a fair trade-off, IMO.

Shadow should be as transparent as the window that casts it is - so when the panel is set to 0, then the shadow should also have transparency 0.

Sorry, I haven't been able to compile unity to test it, but I think that something like this would be possible.

My apologies If I'm totally wrong.

Regarding "patched" - " haven't been able to compile unity to test it" , think you may want to try that first...
(creates an undefined error here

@Doug sorry to hear that, I followed the INSTALL instructions from bzr trunk but on compiz building they seem to be wrong, I'll continue trying compilation :(

Deleted patch, It was completely nonsense (namespaces were not used by me).

Sorry by the inconveniences :(

Is it possible to set the importance here to be higher than "wishlist"? Anything that isn't configurable is a major bug.

Please attach a screenshot of the problem

As to the orig. description - that has been recently fixed, when you hit 0 the shadow is removed from the desktop.
As to whether the shadow should change on the way from 1 > 0 I don't think it does (nor really matters

thanks for the quick response, closing this bug now.

As requested, here's a screenshot.

@Doug.

Thanks for the partial fix, but still, if the opacity is set to, say, 50%, the shadow still looks weird. The shadow should follow the panel's opacity.

in oneiric

On Fri, Sep 16, 2011 at 5:38 PM, Scott Severance
<email address hidden> wrote:
> As requested, here's a screenshot.
>
> ** Attachment added: "Screenshot of the panel at 0% opacity"
>   https://bugs.launchpad.net/ubuntu/+source/unity/+bug/747682/+attachment/2412725/+files/Workspace%201_037.png
>
> ** Changed in: unity
>       Status: Invalid => Confirmed
>
> ** Changed in: unity (Ubuntu)
>       Status: Invalid => Confirmed
>
> --
> You received this bug notification because you are subscribed to unity.
> https://bugs.launchpad.net/bugs/747682
>
> Title:
>  unity panel shadow opacity does not match panel opacity
>
> Status in Unity:
>  Confirmed
> Status in “unity” package in Ubuntu:
>  Confirmed
>
> Bug description:
>  Binary package hint: unity
>
>  The option exists to use a fully transparent panel, however this does not work well with the newly enabled drop shadow.
>  Maybe at some point the shadow could be disabled when a fully trans. panel is chosen (0.0000
>
>  ProblemType: Bug
>  DistroRelease: Ubuntu 11.04
>  Package: unity 3.8.2-0ubuntu1
>  ProcVersionSignature: Ubuntu 2.6.38-7.39-generic 2.6.38
>  Uname: Linux 2.6.38-7-generic i686
>  NonfreeKernelModules: nvidia
>  Architecture: i386
>  CompizPlugins: [core,bailer,detection,composite,opengl,decor,vpswitch,regex,gnomecompat,resize,compiztoolbox,mousepoll,place,move,staticswitcher,session,fade,cube,scale,scaleaddon,expo,rotate,unityshell]
>  Date: Fri Apr  1 15:21:30 2011
>  InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Alpha i386 (20110308)
>  ProcEnviron:
>   LANGUAGE=en_US:en
>   PATH=(custom, user)
>   LANG=en_US.UTF-8
>   SHELL=/bin/bash
>  SourcePackage: unity
>  UpgradeStatus: No upgrade log present (probably fresh install)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/unity/+bug/747682/+subscriptions
>

@ Scott
While I can't speak for design or those implementing what you're asking for would seem to introduce some add. complexity for very little gain.
As it stands now the drop shadow is just a .png drawn on the desktop, not part of the panel. So having it disappear when lowered to 0 was obviously much simpler than what you'd like to see - (I think the 'trigger' to disable is @ 0.0050

I had planned to look at eliminating the Unity panel shadowing code completely (at some point) and make it use the compiz decorator to draw shadows. Two separate packages drawing shadows seems a bit redundant. However such a change was impossible until bug 731685 was fixed.

Now that bug 731685 is fixed, it is finally possible to consider removing the Unity shadowing code, and working on a way to tell compiz to draw the shadow of a window that is not usually in it's painting list (because Unity paints the panel itself).

One potential way to do this that I have experimented with is the _NET_WM_WINDOW_OPACITY atom, which compiz seems to pay attention to. But compiz only seemed to use it in an on/off way. If we can make compiz paint shadow opacities according to the alpha value _NET_WM_WINDOW_OPACITY, then it's theoretically possible to fix this bug for _any_ type of window. Not just the Unity panel.

P.S. Yes, I know the Unity panel only has an X window to handle input and is otherwise painted using pure OpenGL. But that doesn't make it impossible to implement...

In the shorter term, I would have thought that adjusting the alpha blending of the existing panel shadowing code wouldn't be that hard (?!). Though I haven't looked at the code to prove that yet...

That was easy; once I figured out the feature I wanted was texture modulation:
https://code.launchpad.net/~vanvugt/unity/fix-747682-trunk/+merge/76000

The fix is available for testing in ppa:vanvugt/unity
https://launchpad.net/~vanvugt/+archive/unity

And before you ask, I know the shadow does not update immediately. It only changes when the desktop is redrawn so just switch desktops to see the change.

Fix committed to lp:unity r1604.

>Now that bug 731685 is fixed, it is finally possible to consider removing the Unity shadowing code, and working on a way to tell compiz to draw the shadow of a window that is not usually in it's painting list (because Unity paints the panel itself).

>One potential way to do this that I have experimented with is the _NET_WM_WINDOW_OPACITY atom, which compiz seems to pay attention to. But compiz only seemed to use it in an on/off way. If we can make compiz paint shadow opacities according to the alpha value _NET_WM_WINDOW_OPACITY, then it's theoretically possible to fix this bug for _any_ type of window. Not just the Unity panel.

I might add here that the unity windows are completely removed from the paint list. We did this because we didn't want any other plugins to see them and be able to change their opacity such that they would be visible.

I plan to re-write the paint system in compiz such that decorations can be painted separately to the windows that own them. As such, when this happens we will be able to have compiz generate the panel shadow on the input window while keeping the input window removed from the paint stack.

It's probably not impossible to do already. Certainly, in my hacking I have accidentally made compiz apply shadow to the unity panel and launcher already. But it was a little buggy, and the compiz changes you suggest sound like the clean way to do it...

I recommend any new decoration/shadow logic should maintain and use virtual Z (depth) values for each window. Then draw the shadows and windows SEPARATELY in appropriate Z order. That would solve and simplify, potentially, all the overlapping shadow issues and support arbitrary window shapes and opacities.

for each unique z value (descending):
    draw all the shadows of windows at depth z
    draw all the windows and non-shadow decorations of windows at depth z
end for

So you can see, if two windows are the same depth (like two menus, or like a top-level window and a dock), then the shadow of one will never overdraw the content of the other.

Shouldn't this discussion be continued in a new bug or blueprint?

On Fri, Sep 23, 2011 at 3:20 PM, Daniel van Vugt <email address hidden> wrote:
> It's probably not impossible to do already. Certainly, in my hacking I
> have accidentally made compiz apply shadow to the unity panel and
> launcher already. But it was a little buggy, and the compiz changes you
> suggest sound like the clean way to do it...
>

Indeed, however what would happen at the moment would be that you'd
either see the InputOutput windows for the launcher and panel (ugly)
or, when trying to make them transparent, the shadow would also be
painted translucent.

It is possible to try and pick out if what is being drawn *might* be
the shadow, but that approach is error prone as you can only tell when
a texture being passed to GLWindow::glDrawTexture is not the window
texture, but not if the texture is actually the shadow texture.

> I recommend any new decoration/shadow logic should maintain and use
> virtual Z (depth) values for each window. Then draw the shadows and
> windows SEPARATELY in appropriate Z order. That would solve and
> simplify, potentially, all the overlapping shadow issues and support
> arbitrary window shapes and opacities.
>
> for each unique z value (descending):
>    draw all the shadows of windows at depth z
>    draw all the windows and non-shadow decorations of windows at depth z
> end for
>
> So you can see, if two windows are the same depth (like two menus, or
> like a top-level window and a dock), then the shadow of one will never
> overdraw the content of the other.
>
> Shouldn't this discussion be continued in a new bug or blueprint?
>

Yes, that's exactly how it would work. I'm not sure about making a
blueprint or a bug for it yet though, that should really be done in
the planning for the next cycle when we look at our priorities. It
might be useful for me to do a feature-spec write up of how it would
work.

> --
> 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/747682
>
> Title:
>  unity panel shadow opacity does not match panel opacity
>
> Status in Unity:
>  Fix Committed
> Status in “unity” package in Ubuntu:
>  In Progress
>
> Bug description:
>  Binary package hint: unity
>
>  The option exists to use a fully transparent panel, however this does not work well with the newly enabled drop shadow.
>  Maybe at some point the shadow could be disabled when a fully trans. panel is chosen (0.0000
>
>  ProblemType: Bug
>  DistroRelease: Ubuntu 11.04
>  Package: unity 3.8.2-0ubuntu1
>  ProcVersionSignature: Ubuntu 2.6.38-7.39-generic 2.6.38
>  Uname: Linux 2.6.38-7-generic i686
>  NonfreeKernelModules: nvidia
>  Architecture: i386
>  CompizPlugins: [core,bailer,detection,composite,opengl,decor,vpswitch,regex,gnomecompat,resize,compiztoolbox,mousepoll,place,move,staticswitcher,session,fade,cube,scale,scaleaddon,expo,rotate,unityshell]
>  Date: Fri Apr  1 15:21:30 2011
>  InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Alpha i386 (20110308)
>  ProcEnviron:
>   LANGUAGE=en_US:en
>   PATH=(custom, user)
>   LANG=en_US.UTF-8
>   SHELL=/bin/bash
>  SourcePackage: unity
>  UpgradeStatus: No upgrade log present (probably fr...

To be more precise, the fix is not committed yet for an Ubuntu release. It is comitted in the Unity project upstream though, so should appear in oneiric next time the code is pulled from upstream.

http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/oneiric/unity/oneiric/view/head:/plugins/unityshell/src/unityshell.cpp#L504

we keep the status of both upstream and downstream the same for Unity bugs.

OK. It's inaccurate, but I'll go along with that. Is there a wiki documenting that policy somewhere?

This bug was fixed in the package unity - 4.18.0-0ubuntu1

---------------
unity (4.18.0-0ubuntu1) oneiric; urgency=low

  * New upstream release.
    - Screen corruption when resuming from suspend/hibernate (LP: #676166)
    - unity-panel-service crashed with SIGSEGV in bamf_factory_view_for_path()
      (LP: #764024)
    - Dash and launcher appear underneath windows (LP: #805087)
    - unity-panel-service crashed with SIGSEGV in g_type_check_instance_cast()
      (LP: #811401)
    - [Oneric] unity-panel-service crashed with SIGSEGV in getenv()
      (LP: #817691)
    - compiz crashed with SIGSEGV in unity::FilterBar::RemoveFilter()
      (LP: #845732)
    - crash on closing a window (LP: #856015)
    - Cannot open a window that starts iconified (LP: #732997)
    - Launcher - When useing Alt F1 launcher keyboard navigation, Launcher
      should not scroll until top or bottom of Launcher is reached
      (LP: #765749)
    - Stacking problem when switching between apps with multiple windows
      (LP: #802527)
    - Pull panel to de-maximize window occasionally not working in a secondary
      screen (LP: #802651)
    - Window under Dash gets focused if it opened later (LP: #830730)
    - Clickable areas of previously active window remains on 'Show Desktop'
      (LP: #836325)
    - A minimized window 'remains' behind on the desktop if
      /apps/compiz-1/plugins/unityshell/screen0/options/show_minimized_windows
      is set to true (LP: #847967)
    - a11y support on Unity is broken (LP: #851103)
    - compiz crashed with SIGSEGV in dee_model_get_tag() (LP: #840758)
    - crash when looping paint list in preparePaint (on closing windows)
      (LP: #853807)
    - Alt-Tab should not preview windows at excessively large sizes
      (LP: #854740)
    - Clicking on a tweet/message link sometimes does not work (LP: #790565)
    - Dragging a launcher icon makes it squashed (LP: #855761)
    - unable to unminimize gedit windows where more than one window where one
      has a dialog open (LP: #856030)
    - (oneiric) alt-tab UX doesn't work well on multi-monitor (LP: #855364)
    - Launcher shows on the primary monitor instead of the left most monitor
      (LP: #857668)
    - Keynav - pressing down key causes launcher items to jump up and down
      (LP: #858469)
    - Windows creep cross the screen with ALT+TAB (LP: #722830)
    - Minimize animation flickr when for maximized apps (LP: #737125)
    - All unity windows are invisible (panel, launcher, dash) (LP: #745996)
    - Dash "See 97 more results" has ~1 second of latency (LP: #731158)
    - Windows cannot be dragged down from panel if banshee closed to sound
      menu (LP: #781215)
    - no menu bar on top, compositing bug? (LP: #806358)
    - Launcher - a spread can accidentally be triggered during the 'dragging
      and dropping behind the Launcher' interaction (LP: #832988)
    - Impossible to navigate between panel menus when the mouse cursor is over
      the panel (LP: #834065)
    - Pressing alt on maximized window does show menu but not window controls
      (LP: #836274)
    - Application name drawn under Dash controls when window opens under Dash
      (LP: #838176)
    - Start ...