Flicker upon session start

[Hernando Torque]

The screen flickers upon session start (seems I get a filled rectangle for every element that's about to get drawn).

Attaching a clip of it happening in VirtualBox, but it also happens on two actual systems (Intel HD 2000 and 3000).

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: unity-2d 3.8.14.1-0ubuntu1
ProcVersionSignature: Ubuntu 3.0.0-7.9-generic 3.0.0
Uname: Linux 3.0.0-7-generic x86_64
Architecture: amd64
Date: Wed Aug 3 21:48:23 2011
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Alpha amd64 (20110630)
PackageArchitecture: all
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: unity-2d
UpgradeStatus: No upgrade log present (probably fresh install)

[Alberto Mardegan (mardy)]

I investigated the issue a bit, and according to my findings this is not a bug in unity-2d: if I remove the unity-2d related names from the "RequiredProviders" line in the /usr/share/gnome-session/sessions/ubuntu-2d.session file, the flickering still happens.

I suspect that this bug might be related to metacity: in fact, if I don't start metacity, no flickering occurs; and if I manually start metacity from an xterm (with no other window manager running), then flickering occurs inside the xterm.

I'm reassigning this to metacity for investigation.

[Florian Boucault (fboucault)]

Marking it as affecting Unity 2D again so that it shows up in searches and listings.

[Didier Roche-Tolomelli (didrocks)]

In addition to this, reverting to the natty version didn't fix it, all seems to due to compositing activated.

in gconf, disable: /apps/metacity/general/compositing_manager and you won't get any more issue (that's why we didn't get any issue in metacity in natty).

In oneiric, if you enable compositing, you get tons of:

Inexplicable intersection with new extents!
resize_win (XSR): 1 rects, bounds: -9,17 (1938,1074)
expose_area (XSR): 1 rects, bounds: 0,24 (1920,1056)
repair_win (XSR): 1 rects, bounds: -9,17 (1938,1074)
determine_mode (XSR): 1 rects, bounds: -9,17 (1938,1074)
resize_win (XSR): 1 rects, bounds: -15,9 (1956,1092)
expose_area (XSR): 1 rects, bounds: 804,275 (708,21)
expose_area (XSR): 1 rects, bounds: 804,296 (4,550)
expose_area (XSR): 1 rects, bounds: 1508,296 (4,550)
expose_area (XSR): 1 rects, bounds: 804,846 (708,4)
repair_win (XSR): 1 rects, bounds: 795,268 (726,593)
expose_area (XSR): 1 rects, bounds: 1920,24 (1920,21)
repair_win (XSR): 1 rects, bounds: 1911,17 (1938,1194)
repair_win (XSR): 1 rects, bounds: -66,101 (66,379)
paint_all (XSR): 5 rects, bounds: -66,9 (3915,1202)
 -15,17 (3864,84)
 -66,101 (3915,379)
 -15,480 (3864,621)
 1911,1101 (1938,110)
repair_win (XSR): 1 rects, bounds: -35,376 (4,4)
repair_win (XSR): 1 rects, bounds: 0,45 (1920,1035)
configure notify 0 0 1
 extents (XSR): 1 rects, bounds: 20,96 (1884,708)
 xy (29 103), wh (1866 677)

which seems to be those rectangles.

[Gerry Boland (gerboland)]

This appears relevant: http://lists.x.org/archives/xorg-devel/2010-June/010091.html

I quote:

Changes to the root background pixmap would previously cause the new
image to flicker into visibility briefy before windows were redrawn
over it. This was apparently caused by calling XClearWindow when the
_XROOTPMAP_ID property on the root window changed.

This patch fixes this by dropping the XClearWindow call and providing
a new function ("damage_screen") to force a redraw of the entire screen.

Most programs that change the root window pixmap will call XClearWindow,
anyway, so xcompmgr doing the same is redundant. However, dropping
the call makes it possible to use the _XROOTPMAP_ID property of the root
window to pass new pixmaps to xcompmgr from another process. The other
process can then neglect to call XClearWindow, resulting in a
flicker-free change to the new background image.

[Gerry Boland (gerboland)]

No, the above is not relevant. The actual flickering comes from Metacity, it has a debug mode "show_redraw" which runs this piece of code in compositor-xrender.c:

  if (DISPLAY_COMPOSITOR (display)->show_redraw)
    {
      Picture overlay;

      dump_xserver_region ("paint_all", display, region);

      /* Make a random colour overlay */
      overlay = solid_picture (display, screen, TRUE, 1, /* 0.3, alpha */
                               ((double) (rand () % 100)) / 100.0,
                               ((double) (rand () % 100)) / 100.0,
                               ((double) (rand () % 100)) / 100.0);

      XRenderComposite (xdisplay, PictOpOver, overlay, None, info->root_picture,
                        0, 0, 0, 0, 0, 0, screen_width, screen_height);
      XRenderFreePicture (xdisplay, overlay);
      XFlush (xdisplay);
      usleep (100 * 1000);
    }

DISPLAY_COMPOSITOR (display)->show_redraw seems to not be initialised at Metacity start. I'll have a patch to submit which will fix this.

[Launchpad Janitor (janitor)]

This bug was fixed in the package metacity - 1:2.34.1-1ubuntu3

---------------
metacity (1:2.34.1-1ubuntu3) oneiric; urgency=low

  * debian/patches/21_fix_compositing_startup.patch:
    Fix some weird rendering effect at startup with compositing activated
    (LP: #820553)
 -- Didier Roche <email address hidden> Wed, 14 Sep 2011 07:51:11 +0200