Loss of window border (white flash) when using compiz resize plugin, option=normal

Bug #454218 reported by andbelo
78
This bug affects 18 people
Affects Status Importance Assigned to Milestone
Compiz
Fix Released
High
Sam Spilsbury
Compiz Core
Fix Released
High
Łukasz Zemczak
compiz (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: compiz

My settings have compiz enabled, the resize plugin enabled with the option mode=0. This option corresponds to "Normal", which is the draw of the window during resizing and not a rectangle. The expected was to have the windows resized without any image artifacts. Currently, the window decoration is lost and a white border is shown (see attachments for examples). This happens with both metacity and emerald window decorators.

Ubuntu Karmic (development branch)
Compiz 0.8.4-0ubuntu1

ProblemType: Bug
Architecture: amd64
CompizPlugins: [core,move,resize,place,decoration,animation,ccp,vpswitch,png,regex,extrawm,neg,session,commands,mousepoll,video,dbus,gnomecompat,text,imgjpeg,resizeinfo,svg,workarounds,obs,wobbly,fade,cube,3d,expo,rotate,scale,ezoom,scaleaddon,staticswitcher]
Date: Sat Oct 17 16:45:00 2009
DistroRelease: Ubuntu 9.10
MachineType: Dell Inc. Studio 1537
NonfreeKernelModules: wl
Package: compiz 1:0.8.4-0ubuntu1
PackageArchitecture: all
PciDisplay: 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07)
ProcCmdLine: BOOT_IMAGE=/vmlinuz-2.6.31-14-generic root=/dev/mapper/laptop-root ro quiet splash
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
RelatedPackageVersions:
 xserver-xorg 1:7.4+3ubuntu5
 libgl1-mesa-glx 7.6.0-1ubuntu4
 libdrm2 2.4.14-1ubuntu1
 xserver-xorg-video-intel 2:2.9.0-1ubuntu2
 xserver-xorg-video-ati 1:6.12.99+git20090929.7968e1fb-0ubuntu1
SourcePackage: compiz
Uname: Linux 2.6.31-14-generic x86_64
XorgConf: Error: [Errno 2] No such file or directory: '/etc/X11/xorg.conf'
dmi.bios.date: 12/03/2008
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A07
dmi.board.name: 0P173H
dmi.board.vendor: Dell Inc.
dmi.board.version: A07
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.chassis.version: A07
dmi.modalias: dmi:bvnDellInc.:bvrA07:bd12/03/2008:svnDellInc.:pnStudio1537:pvrA07:rvnDellInc.:rn0P173H:rvrA07:cvnDellInc.:ct8:cvrA07:
dmi.product.name: Studio 1537
dmi.product.version: A07
dmi.sys.vendor: Dell Inc.
system: distro = Ubuntu, architecture = x86_64, kernel = 2.6.31-14-generic

Related branches

Revision history for this message
andbelo (andbelo) wrote :
Revision history for this message
Johannes H. Jensen (joh) wrote :

I can confirm this bug. I have the exact same behavior on my Intel GM965:

00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
        Subsystem: Lenovo Device 20b5
        Flags: bus master, fast devsel, latency 0, IRQ 28
        Memory at f8000000 (64-bit, non-prefetchable) [size=1M]
        Memory at e0000000 (64-bit, prefetchable) [size=256M]
        I/O ports at 1800 [size=8]
        Capabilities: <access denied>
        Kernel driver in use: i915
        Kernel modules: i915

It seems only to appear on some windows though. For example, Update Manager windows can be resized without any artefacts...

Revision history for this message
Сергей (skaunov) wrote :

I have slightly different bug, which can be described by the same words "loss of window border when using compiz", and I use Normal option for resize too. At this moment changing of this option gives me nothing. The problem is that all outside the application area of window is _completely_ lost (see attached screenshot). Maximized windows fill all the screen, so that it doesn't even think that there should be some border elements.
Should I file another bug or is it modification of this one?

I use an 8th generation Nvidia videocard.

Revision history for this message
Сергей (skaunov) wrote :
Revision history for this message
Keno Cabazares (kenocabazares) wrote :

i happened to also have the same problem,.. i solved it by checking "loose binding" under compiz options accessed from fusion-icon.

Revision history for this message
andbelo (andbelo) wrote : Re: [Bug 454218] Re: [Karmic] loss of window border when using compiz resize plugin, option=normal

this sounds interesting, but when I tried to find the "loose binding"
option I couldn't find it. I'm running the compiz installed by default.
Are you using any other installed package or version of compiz?

Keno Cabazares wrote:
> i happened to also have the same problem,.. i solved it by checking
> "loose binding" under compiz options accessed from fusion-icon.
>
>

Revision history for this message
Сергей (skaunov) wrote : Re: [Karmic] loss of window border when using compiz resize plugin, option=normal

hmm… my problems gone after removing with aptitude compiz files and e17 files & installing compiz again.

Revision history for this message
dreadyman (dreadyman16) wrote :

I tested and with compiz-fusion with "loose-binding" option enabled the problem is solved.

Revision history for this message
Jan van de Velde (jmvdvelde) wrote :

Just bought a new videocard wirh Nvidia chipset to replace freaking ATI Radeon. Got same problem no borders, solved by loose binding option. Thanx>!

Revision history for this message
Adam Lyall (magicmyth) wrote :

I'm seeing this same issue on multiple Intel IGP chips in different laptops. GMA 950, x3100, and a GMA 4500M. I also have a system with a ATI R300 running Ubuntu Karmic with the 2.6.32 kernel from ppa using KMS and Xorg-updates which does not exhibit this issue so it seems specific to the Intel cards. Not sure if the Nvidia issue is the same as I believe loose-binding was intended to always be used with the Nvidia blob anyway.
I first noticed this issue during Jaunty when I moved to the Linux kernel 2.6.31 (from kernel ppa) on my Sony Vaio CR11s (x3100). Prior to that I had not experience the issue. I'm writing this from a live usb using a daily Lucid release and the same issue is present but appears to affect the new theme even more. I can produce the affect with any window but it is much harder with some apps than others. For example the Update Manager rarely shows the issue unless you go crazy with resizing (grab a corner and throw it around the screen), where as firefox will show it constantly when resizing. It also seems more common with some themes than others. I would say the more complex the apps is (more widgets to cause redrawing) the more easier the bug is to produce.
I can grab some more info from my Sony Vaio if needed (after I have poke through the wikis on how to do this).

Revision history for this message
Bálint Magyar (balintm) wrote :

I can confirm this bug on GMA950 on Lucid beta1. Problem does not occur unless the Mode setting of the Resize plugin is on "Normal." Perhaps a bug of gtk-window-decorator?

$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)

Revision history for this message
andbelo (andbelo) wrote : Re: loss of window border when using compiz resize plugin, option=normal

It also happens in Lucid beta2

summary: - [Karmic] loss of window border when using compiz resize plugin,
- option=normal
+ loss of window border when using compiz resize plugin, option=normal
Revision history for this message
willjcroz (willjcroz) wrote :

Same problem here: flickering window borders when resizing with resize plugin option=normal. Fixed with loose binding workaround. Thanks.

Revision history for this message
willjcroz (willjcroz) wrote :

oops, forgot to say using Lucid Beta2 with radeon (open source) driver

Revision history for this message
Adam Lyall (magicmyth) wrote :

I was wrong about it not occurring on my Ati GPU earlier. It just takes more effort and happens more frequently with the new Ambiance theme.
$ lspci | grep VGA
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R300 ND [Radeon 9700 Pro]

The Sony Vaio Cr Intel GPU
$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)

I've upgraded both these systems to Lucid beta 2 and the same issue still persists. Like others, using compiz with --loose-binding fixes the issue. Does anyone know what loose binding really does or more specifically what is the downside to using it as I imagine it would be used by default if there were no issues with it? All I could find out is that "textures are enabled when created" from the Compiz troubleshooting wiki.

Revision history for this message
Patrick Pfeifer (patrick2000) wrote :

This must be kernel related as well. Adding "nomodeset" to the kernel command line (press F6 in ubuntu 10.04 boot screen and choose "nomodeset") solves the issue for me.

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

Confirmed, this is still a problem in Ubuntu 11.10.

affects: linux → compiz-core
Changed in compiz-core:
importance: Undecided → High
status: New → Incomplete
status: Incomplete → Triaged
Changed in compiz (Ubuntu):
status: New → Confirmed
Changed in compiz-core:
status: Triaged → Fix Committed
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Sam, do you mean this was fixed by: lp:~smspillaz/compiz-core/compiz-core.fix_930071 ?

If it wasn't that commit then I'm pretty sure this isn't fixed yet, because I was still seeing it in testing 2 days ago.

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

Just tested the latest lp:compiz-core (revision 2996) and this bug still occurs when I resize a window rapidly.

Changed in compiz-core:
status: Fix Committed → Triaged
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Tracked the colour of the flash down to:
plugins/opengl/src/screen.cpp:GLushort defaultColor[4] = { 0xffff, 0xffff, 0xffff, 0xffff };

Changing that colour changes the colour seen with this bug. So it would seem that when this bug occurs, it means the decor plugin has somehow failed to texture the window decorations and just fills the decorations with the default fill colour.

summary: - loss of window border when using compiz resize plugin, option=normal
+ Loss of window border (white flash) when using compiz resize plugin,
+ option=normal
Revision history for this message
Sam Spilsbury (smspillaz) wrote : Re: [Compiz] [Bug 454218] Re: Loss of window border (white flash) when using compiz resize plugin, option=normal

On Mon, 5 Mar 2012, Daniel van Vugt wrote:

> Tracked the colour of the flash down to:
> plugins/opengl/src/screen.cpp:GLushort defaultColor[4] = { 0xffff, 0xffff, 0xffff, 0xffff };
>
> Changing that colour changes the colour seen with this bug. So it would
> seem that when this bug occurs, it means the decor plugin has somehow
> failed to texture the window decorations and just fills the decorations
> with the default fill colour.
>

Indeed, see the "failed to bind pixmap to texture" errors from the
terminal. The fix for this is to use XSync to synchronize between pixmap
updates while resizing, but that could be a rather tricky task. Maybe
keeping a list of pixmaps in gtk-w-d and then having an XSyncAlarm to
notify gtk-w-d when its ok to free a pixmap would be good ?

>
> ** Summary changed:
>
> - loss of window border when using compiz resize plugin, option=normal
> + Loss of window border (white flash) when using compiz resize plugin, option=normal
>
> --
> You received this bug notification because you are a member of compiz
> packagers, which is subscribed to compiz in Ubuntu.
> https://bugs.launchpad.net/bugs/454218
>
> Title:
> Loss of window border (white flash) when using compiz resize plugin,
> option=normal
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/compiz-core/+bug/454218/+subscriptions
>
> _______________________________________________
> Mailing list: https://launchpad.net/~compiz
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~compiz
> More help : https://help.launchpad.net/ListHelp
>

Changed in compiz-core:
status: Triaged → In Progress
assignee: nobody → Sam Spilsbury (smspillaz)
milestone: none → 0.9.8.0
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Fix committed into lp:compiz-core at revision 3131

Changed in compiz-core:
status: In Progress → Fix Committed
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Fix reverted in r3132. Apparently it was causing instability in some cases (bug 996901)

Changed in compiz-core:
status: Fix Committed → In Progress
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Fix committed into lp:compiz-core at revision 3137

Changed in compiz-core:
status: In Progress → Fix Committed
Changed in compiz:
milestone: none → 0.9.8.0
status: New → Fix Committed
importance: Undecided → High
assignee: nobody → Sam Spilsbury (smspillaz)
Changed in compiz-core:
milestone: 0.9.8.0 → none
Changed in compiz-core:
milestone: none → 0.9.7.10
status: Fix Committed → In Progress
assignee: Sam Spilsbury (smspillaz) → Łukasz Zemczak (sil2100)
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Fix committed into lp:compiz-core/0.9.7 at revision 3103

Changed in compiz-core:
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (7.6 KiB)

This bug was fixed in the package compiz - 1:0.9.8+bzr3249-0ubuntu1

---------------
compiz (1:0.9.8+bzr3249-0ubuntu1) quantal-proposed; urgency=low

  * New upstream snapshot.
    - Fall back to a refresh rate that is more likely to look correct; 60Hz.
      (LP: #1009338)
    - Benchmark plugin should consume its key binding, and not pass the key to
      the underlying window. (LP: #1009320)
    - Avoid needless STL operations leading to expensive heap operations.
      (LP: #1006335)
    - Fix a typo that was causing (LP: #1002606)
      (widthIncBorders/heightIncBorders)
    - Check if the window is decorated before trying to change its event window
      states (which won't exist if not decorated) (LP: #1007754)
    - Use the XDamage extension more efficiently (the way it was designed to be
      used). This dramatically reduces CPU usage, reduces wakeups, and
      increases frame rates. It also solves at least one observed performance
      bug (LP: #1007299) and probably several more.
    - Avoid constructing and destructing lots of strings on every single event,
      which was wasting lots of CPU (LP: #1005569)
    - md LINGUAS doesn't exist, it's mnk (Mandinka in ISO 639-3)
    - Move grid plugin to google test and don't depend on the plugin for the
      test (LP: #1005009)
    - Don't read plugin.Initialized and test the value. (LP: #1004848)
    - libcompizconfig's install () commands were still using the old includedir
      and libdir variables rather than their libcompizconfig_* variants.
      (LP: #1005176)
    - Execute the cmake files separately to ensure that DESTDIR is respected.
      (LP: #1005177)
    - Don't set_target_properties on a target that might not exist
      (LP: #1005008)
    - Don't allow windows which we weren't even tracking as decoratable to
      become decorated if they try and change their hints. (LP: #963794)
    - Change the mouse pointer while dragging windows in expo. Just like the
      ubuntu branches do. (LP: #987647)
    - Fix uninitialized memory use (LP: #1004338)
    - Fix uninitialized variable (LP: #1004335)
    - Delay unbinding of pixmaps until then next rebind (LP: #729979)
      (LP: #1002602)
    - Don't drop plugins from the list to try and load before you've even tried
      to load them. Doing so makes missing plugins silently ignored instead of
      an error message (LP: #1002715). It also means valid plugins in more
      unusual, but real locations in LD_LIBRARY_PATH will never get loaded
      (LP: #1002721).
    - If running test cases under a real X server, we don't care if Xvfb is
      missing (LP: #994841)
    - Don't assume pkg_check_modules always sets _PREFIX (LP: #993608)
    - Don't clear selections in ~PrivateScreen because it causes a race between
      the existing and the new compiz instances, breaking --replace and
      non-replace behaviour. (LP: #988684) (LP: #989545)
    - Always paint with infiniteRegion as the clip region if the window is
      transformed and always use the supplied region if painting with offset or
      on transformed screen. (LP: #987639)
    - Add synchronization primitives to the decoration protocol so that there
      isn't a r...

Read more...

Changed in compiz (Ubuntu):
status: Confirmed → Fix Released
Changed in compiz:
status: Fix Committed → Fix Released
Changed in compiz-core:
status: Fix Committed → Fix Released
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.