Normal resize mode temporarily hangs the desktop

Bug #1100073 reported by Tony Houghton
62
This bug affects 10 people
Affects Status Importance Assigned to Milestone
Compiz
Confirmed
High
Unassigned
compiz (Ubuntu)
Confirmed
Medium
Unassigned

Bug Description

With compiz's resize mode set to "Normal" instead of "Rectangle", attempting to resize some windows causes the desktop to hang for a while. It seems like the longer or further I drag the longer the hang, and I think it's a non-linear relationship, eg exponential.

I think only windows that set geometry hints such as terminals (I've also found the problem with gvim), but it seems to affect all toolkits, even xterm as well as GTK2 and GTK 3 applications.

I'm using compiz 1:0.9.8.6-0ubuntu1 in quantal amd64.
---
ApportVersion: 2.6.1-0ubuntu9
Architecture: amd64
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
DistroCodename: quantal
DistroRelease: Ubuntu 12.10
DistroVariant: ubuntu
InstallationDate: Installed on 2013-01-15 (0 days ago)
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.5)
MarkForUpload: True
Package: compiz 1:0.9.8.6-0ubuntu1
PackageArchitecture: all
ProcVersionSignature: Ubuntu 3.5.0-21.32-generic 3.5.7.1
Tags: quantal running-unity quantal running-unity ubuntu
Uname: Linux 3.5.0-21-generic x86_64
UnreportableReason: Please work this issue through technical support channels first.
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please execute the following command, as it will automatically gather debugging information, in a terminal:
    apport-collect 1100073
When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

Revision history for this message
Tony Houghton (h-realh) wrote : Dependencies.txt

apport information

tags: added: apport-collected quantal running-unity ubuntu
description: updated
Revision history for this message
Tony Houghton (h-realh) wrote : GconfCompiz.txt

apport information

Revision history for this message
Tony Houghton (h-realh) wrote : ProcEnviron.txt

apport information

Changed in compiz (Ubuntu):
status: New → Confirmed
Changed in compiz:
status: New → Confirmed
milestone: none → 0.9.9.0
importance: Undecided → High
Changed in compiz (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Here are my comments on the resizing bottlenecks I found while we were fixing bug 1027211...

OK, I've tracked down the main offenders that remain _after_ this fix.

1. XSync() inside PrivateWindow::updateRegion()
2. XShapeGetRectangles() inside PrivateWindow::updateRegion()
3. XShapeGetRectangles() called from decor.

If you remove those from the equation then there is no longer a complete freeze. But it still stutters. Further analysis then shows compiz spending its time in one of:

(a) XSync in PixmapBinding::bind
(b) bindTexImageGLX
(c) PrivateVertexBuffer::render

I should add that reverting to the old asynchronous damage handling does not help at all with stutters/freezing. The main issues are those listed above.

It looks to me like our XShape support could be made more efficient instead if synchronously querying XShapeGetRectangles all the time.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Tony, are you using the nvidia driver? What graphics driver? Can you please attach output from running glxinfo?

Revision history for this message
Tony Houghton (h-realh) wrote :

Sorry, I should have mentioned that before. The laptop I reported the bug from has Intel HD 4000 graphics, I'll attach a glxinfo from it. Actually it also has an Nvidia GT650M with Optimus, but I haven't installed bumblebee or Nvidia drivers and I'm pretty sure Ubuntu is only using the Intel graphics at the moment.

I've also installed 12.10 on another PC which does use the Nvidia driver, that has the same bug.

But 12.04 (32-bit) on an old netbook with Intel Atom/945 is apparently unaffected. Resizing windows is a little sluggish on it, but perhaps to be expected on a slow system like that.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Yeah I found the same issue with Intel HD 2000. So confirmed.

But we know it's _much_ worse with nvidia. As discussed in bug 1027211.

Changed in compiz:
milestone: 0.9.9.0 → 0.9.9.2
Changed in compiz:
milestone: 0.9.9.2 → 0.9.10.0
MC Return (mc-return)
Changed in compiz:
milestone: 0.9.10.0 → 0.9.11.0
Revision history for this message
Mina (842mono) wrote :

I have this issue only affecting Google Chrome, and only when the Override software rendering list flag is enabled.

I'm using Ubuntu 14.04 64bit (up-to-date in all ways)
Google Chrome version 51.0.2704.79
Graphics card is Nvidia GTX770 2GB
using Nvidia drivers version 361.45.11
the bug was also there when I was using driver versions 340.96 and 355.11

Revision history for this message
Mina (842mono) wrote :

*edited*

forgot to mention; some chrome extension make windows auto-resize, while resizing the rest of the whole screen is frozen.I'm mainly talking about the hangouts chrome extension: https://chrome.google.com/webstore/detail/google-hangouts/nckgahadagoaajjgafhacjanaoiihapd?hl=en

better demonstration video https://youtu.be/kO6AibNpwFc

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.