Some windows on start up don't show full window

[Pete Graner]

[Impact]

Lowest part of the window not drawn, causing visual problem and lack of access to information/controls there.

[Test Case]

(this is one of the cases that seems to happen every time, although unconfirmed if it happens with all drivers etc)

1. Launch Shotwell
2. Maximize the window
3. Close Shotwell
4. Launch Shotwell again

[Regression Potential]

(to be added if a commit fixing this bug is made)

---

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.

xchat-gnome seems to do it more than the others.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: unity 5.2.0-0ubuntu4
ProcVersionSignature: Ubuntu 3.2.0-16.25-generic 3.2.6
Uname: Linux 3.2.0-16-generic x86_64
.tmp.unity.support.test.0:

ApportVersion: 1.91-0ubuntu1
Architecture: amd64
CompizPlugins: [core,bailer,detection,composite,opengl,decor,move,mousepoll,gnomecompat,regex,snap,wall,compiztoolbox,imgpng,place,vpswitch,grid,resize,session,animation,expo,workarounds,ezoom,fade,scale,unityshell]
CompositorRunning: compiz
Date: Tue Feb 14 23:06:22 2012
DistUpgraded: Fresh install
DistroCodename: precise
DistroVariant: ubuntu
DkmsStatus:
 virtualbox, 4.1.8, 3.2.0-10-generic, x86_64: installed
 virtualbox, 4.1.8, 3.2.0-12-generic, x86_64: installed
 virtualbox, 4.1.8, 3.2.0-14-generic, x86_64: installed
 virtualbox, 4.1.8, 3.2.0-15-generic, x86_64: installed
 virtualbox, 4.1.8, 3.2.0-16-generic, x86_64: installed
EcryptfsInUse: Yes
GraphicsCard:
 Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09) (prog-if 00 [VGA controller])
   Subsystem: Lenovo Device [17aa:21db]
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64+mac (20111011)
MachineType: LENOVO 429637U
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-16-generic root=UUID=6fed87ec-67cb-40eb-aa47-aa507463916b ro quiet splash i915.i915_enable_rc6=1 vt.handoff=7
SourcePackage: unity
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 10/18/2011
dmi.bios.vendor: LENOVO
dmi.bios.version: 8DET54WW (1.24 )
dmi.board.asset.tag: Not Available
dmi.board.name: 429637U
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr8DET54WW(1.24):bd10/18/2011:svnLENOVO:pn429637U:pvrThinkPadX220Tablet:rvnLENOVO:rn429637U:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 429637U
dmi.product.version: ThinkPad X220 Tablet
dmi.sys.vendor: LENOVO
version.compiz: compiz 1:0.9.7.0~bzr2995-0ubuntu1
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.30-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 8.0~rc2-0ubuntu5
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 8.0~rc2-0ubuntu5
version.xserver-xorg-core: xserver-xorg-core 2:1.11.4-0ubuntu3
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.6.99.901+git20120126-0ubuntu2
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.14.99~git20111219.aacbd629-0ubuntu2
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.17.0-1ubuntu3
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:0.0.16+git20111201+b5534a1-1build2

[Didier Roche-Tolomelli (didrocks)]

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.

[Pete Graner (pgraner)]

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

[Pete Graner (pgraner)]

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.

[Łukasz Zemczak (sil2100)]

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.

[Daniel van Vugt (vanvugt)]

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.

[Launchpad Janitor (janitor)]

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

[Łukasz Zemczak (sil2100)]

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.

[Sam Spilsbury (smspillaz)]

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?

[James Page (james-page)]

Hi Sam

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

[Tim Penhey (thumper)]

Łukasz, are you actually working on this?

[Pete Graner (pgraner)]

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

[Roman Yepishev (rye)]

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.

[Łukasz Zemczak (sil2100)]

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

[Daniel van Vugt (vanvugt)]

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.

[Łukasz Zemczak (sil2100)]

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!

[Łukasz Zemczak (sil2100)]

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.

[Łukasz Zemczak (sil2100)]

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

[Łukasz Zemczak (sil2100)]

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.

[Wayne Stark (wastark-gmail)]

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?

[Nekhelesh Ramananthan (nik90)]

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

[Daniel van Vugt (vanvugt)]

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

[arnuschky (abrutschy)]

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

[Sebastien Bacher (seb128)]

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?

[Daniel van Vugt (vanvugt)]

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).

[Sebastien Bacher (seb128)]

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

[Daniel van Vugt (vanvugt)]

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

[Timo Jyrinki (timo-jyrinki)]

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.

[Amr Ibrahim (amribrahim1987)]

This video describes the problem with Shotwell.

[Timo Jyrinki (timo-jyrinki)]

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...

[Timo Jyrinki (timo-jyrinki)]

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.

[Amr Ibrahim (amribrahim1987)]

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

[Amr Ibrahim (amribrahim1987)]

@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.

[Timo Jyrinki (timo-jyrinki)]

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.

[Steve Langasek (vorlon)]

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