I've found that after starting applications that sometimes they don't show the bottom of the app. See attached screen shot. I noticed this after Feb 13th's update to compiz & unity. This has happened to several different apps:

xchat-gnome
thunderbird
chormium

it dosen't happen every time, and seems to do it more often on a clean boot.

I cannot reproduce this problem on neither compiz 1:0.9.7.0~bzr2995-0ubuntu4 nor lp:compiz-core revision 3013. Starting up maximized applications with launcher auto-hide enabled and everything seems ok. Is there some specific way I could easily reproduce this bug? Does it still happen most often after a clean boot? Thank you.

Actually, I finally observed this problem yesterday - but only once. It happened on my laptop screen - I usually use an external monitor and it never happened on a big screen. I experienced it on Firefox when started maximized. The effect was exactly as shown on Pete's screenshot. I wasn't able to reproduce it again, but I might try some more later.

I noticed this bug in 12.04 with normal windows too:
1. Use ccsm to set a slow window open animation.
2. Right click on desktop and select Change Desktop Background.
3. You will see the bottom of the window is missing for a couple of frames during the open animation.

You have to be very observant, because the problem is only visible right at the start of the animation. There's a gap above the bottom border/shadow of the window.

By observing shotwell with some debugging, I noticed that compiz simply sets the window height (CompWindow) invalidly for some cases. That's a good clue if it also happens for restored windows. Thanks!

I wrote the earlier thing wrongly - it's not the height/width that's wrong. It's the window x that is incorrect, due to the decorator. So the problem either lives in the decorator itself or the decorator plugin. The buggy maximized windows have correct width, but the x parameter in some moments of drawing is wrongly shifted by the width of the decorator titlebar.

The issue should be fixed in quantal, closing that part, ideally we would need to fix that in precise as well but the changes there are non trivial and it will be hard to SRU, maybe the specific issue described here can be fixed in a simpler way?

I believe this may be incorrectly added to 0.9.7.10 NEWS? At least I didn't find the commit mentioning this bug, and I still have the problem at least on precise with the same app I've always had it - Shotwell.

Some more details on this. The fix was committed to the branch that eventually became compiz/0.9.8 branch, so it was never applied to precise's branch 0.9.7.

The patch fixing the issue is http://bazaar.launchpad.net/~compiz-team/compiz/0.9.8/revision/3110 - and it actually applies on top of 0.9.7. However it is a big patch and according to Sam it might need some additional patches. There we bump into the problem of fulfilling SRU requirements, and it becomes hard to verify whether the fixes don't cause regressions somewhere else.

I believe the preferable way would be to have a simple patch that only addresses this single drawing problem and nothing else, but it's probably hard to do...

Sam mentioned those additional commits are not necessarily needed. Firstly they fix "in theory" regressions, not clearly identified ones. Secondly they cannot pulled in easily but parts of several commits may need to be extracted manually in order to get them.

Therefore I've now built a package with just the '3110' commit added (modified to fit on top of other patches) installable from the following PPA:

With a brief smoke testing on my own precise machine, the Shotwell problem seems to be gone and I see no immediate adverse effects. In order for this to have any chance to go in, we will need testing on various computers and uses (games/Steam, movies, browsing, normal whole day work use etc). So please install the update from the PPA and use it for a couple of days / a week, and report back regardless of if you had problems or not.

Amr: Thanks a lot for testing! Sam asked me to check the bugs found via these two links - http://is.gd/kGbNQu and http://is.gd/IUlOY4 - your problem seems to be bug #987639, which means this fix would introduce a regression while fixing the Shotwell drawing issue. Potentially some of the others are an issue as well. Therefore this fix can't go in in its current form, without fixing the regressions it's introducing.