Windows fail to repaint where popup windows appeared before

Bug #775508 reported by Ugo Riboni on 2011-05-02
This bug affects 1 person
Affects Status Importance Assigned to Milestone
X.Org X server
Fix Released
Ugo Riboni
unity-2d (Ubuntu)
xorg-server (Ubuntu)

Bug Description

To reproduce:

- Open a window
- Right click on the desktop to make a popup menu appear, and make it so that the menu overlaps partially the window
- Left click on the desktop to make the menu disappear
- Right click again on the desktop but this time in a different position that will not cause the menu to overlap the window

- The part of window that was originally covered by the first menu now displays a "hole" in the shape of the menu (i.e. it shows the desktop background instead of the window content).

Moving the window will cause it to repaint and fix the corrupted area.

This happens regardless of the capture_before_unmap option being enabled in metacity.
This doesn't happen if metacity's compositor is enabled and active.
This was reproduced consistently both with different nvidia cards and with intel integrated graphics.
This can't be reproduced in a gnome classic session (metacity).

Olivier Tilloy (osomon) wrote :

I can consistently reproduce.

Changed in unity-2d:
importance: Undecided → Critical
status: New → Confirmed
Ugo Riboni (uriboni) on 2011-05-02
Changed in unity-2d:
assignee: nobody → Ugo Riboni (uriboni)
milestone: none → 3.10
Ugo Riboni (uriboni) wrote :

It seems that when we make sure that none of the unity-2d related applications that enable compositing are running, the corruption doesn't happen anymore. This includes our metacity's capture_before_unmap option, which should be turned off and metacity restarted.

This seems to point out at something wrong that we do when we turn compositing on with a call to XCompositeRedirectSubwindows. To prove this, I wrote a small C app that just does the minimal necessary to initalize the extension and call that function.
You can find it in lp:~uriboni/unity-2d/minimal-composite/

Created attachment 46321
Test program to help reproduce the bug

If the root window and all its subwindows are redirected to off-screen storage by using XCompositeRedirectSubwindows with the update parameter set to CompositeRedirectAutomatic, some windows fail to repaint correctly in some conditions.

To reproduce this bug:
(1) ensure that windows are NOT currently redirected to off-screen storage
(2) run the attached test application, or run "xcompmgr -a" if you have it installed.
(3) open any regular window, then open a "menu" window so that it overlaps with it partially
(4) close the menu window and open it again in another position so that it will not overlap with the regular window
(5) observe that the part of the regular window that was covered by the first menu window is cleared and then it's not normally repainted anymore

I can reproduce reliably on a machine running Ubuntu Linux 11.04, which runs version 1.10.1, with Linux kernel 2.6.24-29-server x86_64
The window manager running is Metacity (with Metacity's own compositor disabled).

The "menu" windows mentioned in steps 3 to 5 are those that appear when right clicking on the desktop. I don't know what is special about them in X11 terms, but there are no other windows that exhibit this behavior that I could find.

I could reproduce this bug both on an Nvidia card and on a machine with integrated Intel graphics.

Created attachment 46322
Screenshot of one of the windows showing the corrupt area

Sounds like bug 36699 / bug 22566 ...

(In reply to comment #2)
> I could reproduce this bug both on an Nvidia card [...]

Using which driver?

Ugo Riboni (uriboni) wrote :

This also happens in the gnome classic session when running "xcompmgr -a" (-a causes xcompmgr to activate composting in automatic mode instead of manual mode)

Ugo Riboni (uriboni) wrote :

After discussing it with Alberto Milone it seems likely to be an bug in itself and the way it handles automatic redirection of windows.
Therefore I reported a bug against

Ugo Riboni (uriboni) on 2011-05-04
Changed in unity-2d:
status: Confirmed → In Progress

(In reply to comment #2)
> Sounds like bug 36699 / bug 22566 ...
> (In reply to comment #2)
> > I could reproduce this bug both on an Nvidia card [...]
> Using which driver?

It can be reproduced with nvidia, fglrx and intel. I haven't tried to reproduce it with radeon yet but, if it can help, I will.

Changed in xorg-server:
importance: Unknown → Medium
status: Unknown → Confirmed
Changed in xorg-server (Ubuntu):
assignee: nobody → Alberto Milone (albertomilone)
importance: Undecided → Medium
status: New → Triaged

The issue seems to be caused only when override redirect windows (such as GtkMenus) overlap a window, then the menu is destroyed and somehow the area previously occupied by the menu is clipped (and the wallpaper is visible) when a new menu (which doesn't overlap the same window) is created. Moving the window makes the hole go away as miMoveWindow() does a RegionCopy().

I guess something weird happens when the window is no longer marked as overlapped. Maybe miMarkOverlappedWindows() doesn't play well with override redirect windows in CompositeRedirectAutomatic mode.

Any ideas as to how I can further debug the issue?


Didier Roche (didrocks) on 2011-05-31
Changed in unity-2d (Ubuntu):
status: New → In Progress
Florian Boucault (fboucault) wrote :

A workaround was released in Unity 2D some time ago (milestone 3.8.8): we activated Metacity's compositor by default

Changed in unity-2d:
milestone: 3.8.10 → none
status: In Progress → Fix Released
Changed in unity-2d (Ubuntu):
status: In Progress → Fix Released
Bryce Harrington (bryce) on 2011-10-18
Changed in xorg-server (Ubuntu):
importance: Medium → High
Changed in xorg-server (Ubuntu):
assignee: Alberto Milone (albertomilone) → nobody

I'm unable to reproduce this in 1.16. I suspect this was fixed by:

commit a5266dcb3a60587e1877f90c18552baf60b597a0
Author: Ville Syrjala <email address hidden>
Date: Sun Oct 9 01:11:04 2011 +0300

    composite: Update borderClip in compAllocPixmap()

And that this is therefore sort of a duplicate of bug #22566.

Changed in xorg-server:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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