Some windows on start up don't show full window

Pete confirmed that the button state are really "maximized", so it seems that the bottom of the app is cut (see the screenshot). Started with the new compiz snaphost.

Here is a screen shot of xchat-gnome exhibiting the behavior

Ok, after experimenting more, this behavior only occurs when the launcher is set to "Hidden". If its set to any other the other settings then it works normally.

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.

I can't reproduce the problem either. So lowering in priority for now. As far as I can tell Pete is the only person affected so far.

Status changed to 'Confirmed' because the bug affects multiple users.

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 put a fix into lp:compiz-core on 5/03 related to this problem.

http://bazaar.launchpad.net/~compiz-team/compiz-core/0.9.7/revision/3039

Pete, Lukasz can you please re-test and see if this is still a problem?

Hi Sam

I still get this issue with 1:0.9.7.2-0ubuntu4 of compiz in xchat-gnome.

Łukasz, are you actually working on this?

I'm still hitting this with Beta2

pgraner@x220:~$ dpkg -l | grep compiz
ii compiz 1:0.9.7.2-0ubuntu4 OpenGL window and compositing manager
ii compiz-core 1:0.9.7.2-0ubuntu4 OpenGL window and compositing manager
ii compiz-gnome 1:0.9.7.2-0ubuntu4 OpenGL window and compositing manager - GNOME window decorator
ii compiz-plugins 1:0.9.7.2-0ubuntu4 OpenGL window and compositing manager - plugins
ii compiz-plugins-default 1:0.9.7.2-0ubuntu4 OpenGL window and compositing manager - default plugins
ii compiz-plugins-main 1:0.9.7.0~bzr19-0ubuntu7 Compiz plugins - main collection
ii compiz-plugins-main-default 1:0.9.7.0~bzr19-0ubuntu7 Compiz plugins - main default collection
ii compizconfig-backend-gconf 0.9.5.92-0ubuntu4 Compiz Fusion configuration system - gconf backend
ii compizconfig-settings-manager 0.9.5.92-0ubuntu3 Compiz configuration settings manager
ii libcompizconfig0 0.9.7.0~bzr428-0ubuntu6 Settings library for plugins - OpenCompositing Project
ii python-compizconfig 0.9.5.94-0ubuntu4 Compizconfig bindings for python

This is 100% reproducible for me in shotwell if it was set to full screen during previous launch.
Subsequent launching of shotwell will always show the gap below the fullscreen window.

I can confirm that this issue is also reproducible every time here when using shotwell. This is really helpful - thanks!

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.

I meant of course the y parameter and window height, not x and width. What's wrong with me today...

I'm rather deep in this bug, getting closer to finding why it's broken - but I think I need to context switch to something else for a moment, since this corruption is not really a blocking issue.

This bug is still affecting me as of today.
System monitor, Luckbackup & Ubuntu Tweak, seem to be my culprits.
Anyone know if a fix is in line before final release?

Wayne, this is a bug in progress...I already see a merge request which is currently being reviewed.. Should land soon..

Fix committed into lp:compiz-core at revision 3110.

Can confirm on 12.04 64bit, happens almost every time with kile and claws, sometimes with xpdf

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?

This fix was part of the famous "work" branch. We're still polishing the regressions that the work branch introduced in r3110:
https://bugs.launchpad.net/compiz/+bugs?field.tag=compiz-r3110-regression

So can't backport the fix to precise till at least those regressions are fixed (and also included in the backport).

Daniel, do you know if it would be easy to fix that particular issue with a smaller fix than the refactoring done in trunk?

This bug was fixed in the package compiz - 1:0.9.8.0-0ubuntu1

---------------
compiz (1:0.9.8.0-0ubuntu1) quantal-proposed; urgency=low

  * debian/control, debian/rules:
    - enable gles on armel and armhf
    - use dh-translations rather than custom code

  [ Sam Spilsbury ]
  * Enable OpenGL ES building
    - Refresh debian/patches/workaround_broken_drivers.patch
    - Remove non-ported plugins from compiz-plugins
    - Add FindOpenGLES2.cmake to compiz-dev

  [ Timo Jyrinki ]
  * New upstream release.
    - Code to make compiz work on GLES. This includes several changes
      to the compiz API. (LP: #201342) (LP: #901097) (LP: #1004251)
      (LP: #1037710)
    - Draft first 0.9.8.0 NEWS and bump VERSION
  * debian/patches/compiz-package-gles2.patch:
    - Remove, obsoleted by the upstream GLES work
  * Disable plugins that don't work on pure GLES on armhf/armel:
    - bench, firepaint, mblur, showmouse, splash, showrepaint, td, widget
 -- Sebastien Bacher <email address hidden> Fri, 31 Aug 2012 22:59:50 +0200

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.

This video describes the problem with 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:

https://launchpad.net/~timo-jyrinki/+archive/compiz-12.04-fix-932520

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.

@Timo, your PPA fixes the bug with Shotwell described in comment #29. I will continue testing for a week or so.

@Timo, although your PPA fixes the original bug with Shotwell, it introduces graphical glitches in Spread mode. I attached a video describing the problem.

The glitches were not present before updating from your PPA.

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.

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release