Some windows on start up don't show full window

Bug #932520 reported by Pete Graner on 2012-02-15
This bug affects 25 people
Affects Status Importance Assigned to Milestone
Sam Spilsbury
Compiz Core
Unity Distro Priority
Sam Spilsbury
compiz (Ubuntu)
Sam Spilsbury

Bug Description


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:


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

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
 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
 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
 PATH=(custom, user)
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) 10/18/2011
dmi.bios.vendor: LENOVO
dmi.bios.version: 8DET54WW (1.24 )
dmi.board.asset.tag: Not Available 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: 429637U
dmi.product.version: ThinkPad X220 Tablet
dmi.sys.vendor: LENOVO
version.compiz: compiz 1:
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:
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

Related branches

Daniel van Vugt: Approve on 2012-04-24
Alan Griffiths: Approve on 2012-04-23
Sam Spilsbury: Pending requested 2012-04-19
Superseded for merging into lp:compiz-core
Daniel van Vugt: Needs Fixing on 2012-04-19
Sam Spilsbury: Pending requested 2012-04-18
Alan Griffiths: Pending requested 2012-04-18
Superseded for merging into lp:compiz-core/0.9.5
Daniel van Vugt: Resubmit on 2012-02-06
Alan Griffiths: Needs Fixing on 2012-02-02
Pete Graner (pgraner) wrote :
Didier Roche (didrocks) wrote :

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.

Changed in unity (Ubuntu):
importance: Undecided → High
affects: unity (Ubuntu) → compiz (Ubuntu)
Changed in compiz-core:
importance: Undecided → High
milestone: none →
Changed in unity-distro-priority:
importance: Undecided → High
status: New → Fix Committed
Pete Graner (pgraner) wrote :

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

Pete Graner (pgraner) wrote :

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.

Tim Penhey (thumper) on 2012-02-20
tags: added: distro-priority
Łukasz Zemczak (sil2100) wrote :

I cannot reproduce this problem on neither compiz 1: 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) wrote :

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.

Changed in compiz-core:
importance: High → Medium
Launchpad Janitor (janitor) wrote :

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

Changed in compiz (Ubuntu):
status: New → Confirmed
Changed in compiz-core:
milestone: →
Łukasz Zemczak (sil2100) wrote :

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.

Changed in compiz-core:
assignee: nobody → Łukasz Zemczak (sil2100)
Didier Roche (didrocks) on 2012-03-13
Changed in compiz-core:
importance: Medium → High
tags: added: rls-p-tracking
Changed in compiz-core:
milestone: →
Sam Spilsbury (smspillaz) wrote :

I put a fix into lp:compiz-core on 5/03 related to this problem.

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

James Page (james-page) wrote :

Hi Sam

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

Tim Penhey (thumper) wrote :

Łukasz, are you actually working on this?

Pete Graner (pgraner) wrote :

I'm still hitting this with Beta2

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

Roman Yepishev (rye) wrote :

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.

Changed in compiz-core:
milestone: → none
Changed in compiz-core:
milestone: none →
Łukasz Zemczak (sil2100) wrote :

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

Changed in compiz-core:
status: New → In Progress
Daniel van Vugt (vanvugt) wrote :

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) wrote :

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!

Didier Roche (didrocks) on 2012-04-02
Changed in compiz (Ubuntu):
status: Confirmed → Fix Committed
status: Fix Committed → Confirmed
Łukasz Zemczak (sil2100) wrote :

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) wrote :

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

Łukasz Zemczak (sil2100) wrote :

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.

Changed in compiz-core:
status: In Progress → Confirmed
assignee: Łukasz Zemczak (sil2100) → nobody
summary: - Maximzed windows on start up don't show full window
+ Some windows on start up don't show full window
Changed in compiz-core:
milestone: →
Changed in compiz-core:
assignee: nobody → Sam Spilsbury (smspillaz)
Changed in compiz (Ubuntu):
assignee: nobody → Sam Spilsbury (smspillaz)
Changed in unity-distro-priority:
assignee: nobody → Sam Spilsbury (smspillaz)
Changed in compiz-core:
status: Confirmed → In Progress
Wayne Stark (wastark-gmail) wrote :

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) wrote :

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) wrote :

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

arnuschky (abrutschy) wrote :

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

Changed in compiz:
status: New → Fix Committed
importance: Undecided → High
assignee: nobody → Sam Spilsbury (smspillaz)
milestone: none →
no longer affects: compiz-core/0.9.7
no longer affects: compiz-core/0.9.8
Changed in compiz-core:
milestone: → none
Sebastien Bacher (seb128) wrote :

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?

Changed in compiz (Ubuntu Precise):
importance: Undecided → High
status: New → Triaged
milestone: none → ubuntu-12.04.1
Changed in compiz (Ubuntu):
status: Confirmed → Fix Released
Daniel van Vugt (vanvugt) wrote :

This fix was part of the famous "work" branch. We're still polishing the regressions that the work branch introduced in r3110:

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

Sebastien Bacher (seb128) wrote :

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

Changed in compiz (Ubuntu Precise):
milestone: ubuntu-12.04.1 → ubuntu-12.04.2
Changed in compiz:
status: Fix Committed → Fix Released
Daniel van Vugt (vanvugt) wrote :

This bug was fixed in the package compiz - 1:

compiz (1: 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 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

Changed in compiz-core:
milestone: none →
Changed in compiz-core:
status: Fix Committed → Fix Released
Timo Jyrinki (timo-jyrinki) wrote :

I believe this may be incorrectly added to 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.

Changed in compiz-core:
status: Fix Released → Triaged
assignee: Sam Spilsbury (smspillaz) → nobody
Changed in compiz-core:
milestone: →
Colin Watson (cjwatson) on 2013-02-13
Changed in compiz (Ubuntu Precise):
milestone: ubuntu-12.04.2 → ubuntu-12.04.3
Amr Ibrahim (amribrahim1987) wrote :

This video describes the problem with Shotwell.

description: updated
Timo Jyrinki (timo-jyrinki) wrote :

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 - 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) wrote :

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.

Changed in compiz (Ubuntu Precise):
assignee: nobody → Timo Jyrinki (timo-jyrinki)
Amr Ibrahim (amribrahim1987) wrote :

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

Amr Ibrahim (amribrahim1987) wrote :

@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) wrote :

Amr: Thanks a lot for testing! Sam asked me to check the bugs found via these two links - and - 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.

Changed in compiz (Ubuntu Precise):
assignee: Timo Jyrinki (timo-jyrinki) → nobody
To post a comment you must log in.