Every screen change triggers full screen XDamage event

Thank you for taking the time to report this bug and helping to make Ubuntu better. This particular bug has already been reported and is a duplicate of bug 1080947, so it is being marked as such. Please look at the other bug report to see if there is any missing information that you can provide, or to see if there is a workaround for the bug. Additionally, any further discussion regarding the bug should occur in the other report. Feel free to continue to report any other bugs you may find.

OK, I'm not so sure it is a duplicate.

Reviewing the compiz code reminds me that we never generate or trigger XDamage in compiz. We only respond to XDamage.

Maybe _something_ is happening to trigger XDamage to the desktop window, but I don't know what it could be. Although I'm struggling to imagine how it's possible because we already know and test that small updates to the screen do not damage any more than the region that is changing... unless it overlaps the Unity shell. Then it would be bug 1080947.

Please try installing compiz-plugins and compizconfig-settings-manager. Then run ccsm and enable Show Repaint. That will show you the regions being damaged according to compiz by flashing colours. If you find the whole screen flashes on every frame then there's something unique to your system that I can't reproduce right now.

Also, please don't count window open animations or interacting with Unity like opening the dash. Because those fall into bug 1080947.

Interesting, Show Repaint does show the outlines of the damaged regions. (My previous attempt at using "Show Repaint" failed because compiz crashed because of some unrelated compiz bug).

Now back to the code attached, do you believe it is not a representative test? I was not able to receive XDamage event for full screen on 12.04 but I was able to get the same issue on 12.10 installation on my netbook so something must have changed.

Ok, I found what plugin that is - Window decorations - upon enabling the plugin, XDamage events are being dispatched with full screen area. Is gtk-window-decorator the one to blame?

On the other hand any plugin I enable tends to do this so a "bare" compiz with "core" and "ccp" does not manifest the issue but anything more than that and XDamages are all over the screen.

I can't see any bug in your test program right now. But I also can't explain it.

If the root window was constantly getting damaged though, Show Repaint would be flashing the whole screen and Compiz' CPU would be higher.

I see two possible explanations:
 1. A bug in your program (which I can't see)
 2. Compiz is choosing to ignore damage to the root window (which I doubt, because it does smoothly respond to root window redraws)

Both seem quite unlikely. Maybe there's a third explanation... ?

On Fri, Jan 18, 2013 at 7:50 AM, Launchpad Bug Tracker
<email address hidden> wrote:
> You have been subscribed to a public bug:
>
> STR:
>
> 1. Compile and run the attached code - http://paste.ubuntu.com/1538829/ dumping the output to a file
> 2. Do something, open applications, open Dash, etc
> 2. Analyse the output
>
> Expected results:
> Various offsets and area width/height.
>

No, it is not supposed to be like that.

> Actual results:
> XDamage @ x=0 y=0 - 1366x768

OpenGL applications always post full-screen damage whenever they call
glXSwapBuffers.

Just because you get getting a fullscreen damage rectangle reported
when using XDamageReportRawRectangles, it doesn't necessarily mean the
whole screen got redrawn. Think about it, if libGL needs to calculate
and post the damage region to the server, how is it supposed to figure
out what regions of the image changed when it gets told that the
pointer to the image itself changed. For all OpenGL cares, the new
buffer is completely different to the old buffer, because the new
buffer always starts out in an undefined state, so it could be
anything.

Having a full-screen damage region is just another way of telling
clients "I have no idea what the contents of this window are going to
be". Which is about accurate.

It doesn't actually ask the server to redraw the whole window. When
you draw directly to a double-buffered root window, its effectively
the same as the monitor scanning out the pixels from the buffer you're
drawing into. So changing the pointer is a very inexpensive operation.

It sucks if you're either a compositor or a VNC app. For VNC apps -
that's life: OpenGL simply can't know what the contents of new buffers
will be. For compositors: thats why we have full screen window
unredirection.

>
> ProblemType: Bug
> DistroRelease: Ubuntu 13.04
> Package: unity 6.12.0daily13.01.11.2bzr3042pkg0raring0 [origin: LP-PPA-unity-team-staging]
> ProcVersionSignature: Ubuntu 3.8.0-0.4-generic 3.8.0-rc3
> Uname: Linux 3.8.0-0-generic x86_64
> .tmp.unity.support.test.0:
>
> ApportVersion: 2.8-0ubuntu1
> Architecture: amd64
> CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
> CompositorRunning: compiz
> CrashDB: unity
> Date: Wed Jan 16 21:30:47 2013
> DistUpgraded: Fresh install
> DistroCodename: raring
> DistroVariant: ubuntu
> GraphicsCard:
> Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09) (prog-if 00 [VGA controller])
> Subsystem: Lenovo Device [17aa:21e2]
> InstallationDate: Installed on 2013-01-04 (12 days ago)
> InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Alpha amd64 (20130104)
> MachineType: LENOVO 1141PZ5
> MarkForUpload: True
> ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.8.0-0-generic root=UUID=0e822d3c-f45d-4f15-a2c9-7968357ac544 ro quiet splash vt.handoff=7
> SourcePackage: unity
> UpgradeStatus: No upgrade log present (probably fresh install)
> dmi.bios.date: 11/03/2011
> dmi.bios.vendor: LENOVO
> dmi.bios.version: 8HET40WW(1.22)
> dmi.board.asset.tag: Not Available
> dmi.board.name: 1141PZ5
> dmi.board.vendor: LENOVO
> dmi.board.version: Not Available
> dmi.chassis.asset.ta...

To clarify some important things:

XDamage on the root window != screen redraws, especially with hardware overlays
XDamage on the root window != compiz damage. Its actually representative of what's changed as a result of libGL doing a buffer swap
Composite and OpenGL being implicitly loaded when move, resize, decor are loaded is bug 1101026

Cool, thanks Sam

Hi there, reading the comments and having issues myself that seem similar to this bug, I tried enabling the 'Show Repaint' plugin.

I soon as I activate it, my whole screen is constantly blinking: full screen receives a pink overlay then some small area receives the pink overlay once out of three (subjective feeling).

And that's without touching the mouse nor typing anything.

Let me know if there is some way for me to provide more information.

FTR, since I upgraded to quantal, the dash became very slow even when I login. It then becomes slower and slower and I usually need to login/logout every day to restore some usability.

About this computer/Graphics says:
  Driver: GeForce 7300 GT/PCIe/SSE2
  Experience: Standard

Cough, I hope that's not the "standard" experience ;)

And I can see it's specific to this desktop, my other one is slower but still usable. Unfortunately, the other says Driver: unknown

Vincent,

This bug has been found to be invalid as discussed above. That is still true unless your full screen blinks constantly. If the full screen is pink or coloured then that is not a problem. That's normal for Show Repaint. It has to be /changing/ colour to indicate redraws.

First thing to check is that you don't have a fullscreen/maximized window behind everything that is redrawing constantly. So close all apps. Does it still happen? If so then please take a video and attach it here.

I don't know why this bug has been marked as invalid. "Every screen change triggers full screen XDamage event" This is exactly what happens and it didn't used to be this way. I run software that depends on damage events and it has now ground to a halt. Yes, a damage event doesn't mean that every single pixel within the area has been updated, but there's a big difference between a little margin for correctness and just invalidating the entire screen all the time.

Frankly, I've had it with whatever compiz quirks get introduced with every new version of Ubuntu and I've switched my WM to KWin.