chjj / compton Goto Github PK

This is one that I do not know how to fix.

Problem:

Fvwm by default displays a window showing the geometry when the user interactively moves or resizes a window. This window does not show up if either xcompmgr or compton is running.

Debug info:

0x00000445 is the geometry window. Evidently fvwm gives no chance for compton to paint the window! compton retrieved the Map event then immediately the Unmap event. However in fact there should be at least two seconds of delay between the two events.

paint: 0x00c0049d 0x00c000c9
paint: 0x00c0049d 0x00c000c9
paint: 0x00c0049d 0x00c000c9
paint: 0x00c0049d 0x00c000c9
[     1.92 ] event   FocusOut serial 0x00000445 window 0x00c0049d "(null)"
[     1.92 ] event ConfigureN serial 0x00000445 window 0x00c000c1 "(null)"
{ send_event: 0, above: 0x00800001, override_redirect: 0 }
[     1.92 ] event        Map serial 0x00000445 window 0x00c000c1 "(null)"
[     1.92 ] event      Unmap serial 0x00000445 window 0x00c000c1 "(null)"
[     1.92 ] event    FocusIn serial 0x00000446 window 0x00c0049d "(null)"
[     1.92 ] event ConfigureN serial 0x00000446 window 0x00c0049d "(null)"
{ send_event: 0, above: 0x00c000c9, override_redirect: 0 }
[     1.92 ] event PropertyNo serial 0x00000446 window 0x01000009 "tmux"
[     1.92 ] event PropertyNo serial 0x00000449 window 0x00000291 "(Root window)"
paint: 0x00c0049d 0x00c000c9
paint: 0x00c0049d 0x00c000c9
paint: 0x00c0049d 0x00c000c9
paint: 0x00c0049d 0x00c000c9

So somehow fvwm is preventing xcompmgr and compton from getting the events?

@chjj:

I created this issue report for discussions related to the release schedule.

I would highly discourage, repeat, highly discourage, to create a release right now with the latest commits from richardgv-dev branch.

1. b78ab31 is a experimental commit. It is known to cause drastic increase in CPU usage. I've indicated that point in my commit log and a few replies to issues. Currently I've only got feedback from a user (ichi-no-eda) and I need more information. My plan is to work on revising it in the near future, but I need time to figure out many details in Xorg's region calculation implementation to effectively fix the performance issue.
2. Our documentation is terribly outdated. My plan is to revise the man pages, README, etc. in a few days. The documentation right now is very misleading, should I say. And we still need to write the typical NEWS files, etc.
3. My belief is a commit needs to be tested in master branch for at least a week before it could be considered stable (unless it's a change in documentation). It does not sound like too great an idea to release a commit in my experimental branch only a single day after I pushed it.
4. It's the first formal release, do you think we could afford the risk of showing everybody in the world how unstable the first formal release is?
5. The VSync feature is currently broken. I need assistance from you or another Xorg expert to fix the feature.
6. Both plain Makefile and CMakeLists.txt are available right now on compton. We have to make a final decision about which one to use. Also, CPackConfig.cmake probably needs an update.
7. Considering releasing is a big thing, and some recent changes in code come from me, before you mark any sort of non-urgent release, I would prefer if you discuss with me. If you need some sort of private discussion, I'm sometimes available at #compton on FreeNode.

For now my recommendation is revoke 0.0.1 release immediately, before any package maintainers have time to push it out. I will revoke it myself if I'm not getting any messages from you within 24 hours.

By the way, I'm not sure about what your tag names mean.

I'd like to be able to define custom rules to prevent shadows on certain kind of windows.

Rules could look like this:

    _WM_WINDOW_LAYOUT = _WM_WINDOW_LAYOUT_TILED

And it would prevent shadows (and every other effects) for every window with matching 'property / value' pair.

I think it would be extremely useful for tiling window managers.

-C option should avoid shadows on panels and docks, but doesn't work with wbar. Tested in ArchLinux + Openbox.

Plus: -G option should avoid shadows on drag-and-drop objects, but doesn't work with my current system (Archlinux + Openbox).

@chjj: I hope you don't mind if I create a report for the issue you discovered. I would like to post my research result of the maximized Chromium window partially hidden bug you mentioned, and I don't want to do it in a different bug report. The last of your 3 pending issues, right? Although it is slightly less baffling than the ghost window one, it could be more frustrating as unfortunately this time only Chromium devs instead of you could produce a perfect fix, I guess.

The cause of the issue:

compton/xcompmgr uses border_size() to determine the exact size of a window with its borders -- despite its deceptive name. The very line of code that does this work is:

border = XFixesCreateRegionFromWindow (dpy, w->id, WindowRegionBounding);

It returns a region of one or more rectangles together covering the whole window precisely. When applying to rectangular windows, XFixesCreateRegionFromWindow() returns a region with single rectangle beautifully. Probably because Chrom{ium,e} has rounded corners on its main windows when it's not maximized, XFixesCreateRegionFromWindow() returns 5 rectangles that together form the region of the Chrom{ium,e} window, something like this:

(The format is, <x>, <y>, <width>, <height>
Rec #4: 3, 501, 584, 1
Rec #3: 1, 499, 588, 2
Rec #2: 0, 3, 590, 496
Rec #1: 1, 1, 588, 2
Rec #0: 3, 0, 584, 1

Of course, compton/xcompmgr is able to handle this situation. But when the Chrom{ium,e} window is maximized, Chrom{ium,e} stills returns these 5 small rectangles as its bounding rectangles, during a very very short period of time -- short enough for probably millions or tens of millions of instructions to be executed. A person's one second is more than a million year for a modern CPU. If you just wait for much less than a human second (or minimize the Chrom{ium,e} window now and restore it to maximized state), it will start to return the correct bounding rectangle, like:

Rec #0: 0, 0, 1440, 870

When Chrom{ium,e} starts maximized, it, too, creates a normal window firstly then maximizes it automatically, thus the problem could appear, too.

compton/xcompmgr doesn't ask a window for its bounding rectangles every time it paints, but maintains a cached result in w->border_size. If compton/xcompmgr happen to asked Chrom{ium,e} during the period of time in which it reports wrong bounding rectangles, the bug appears.

Moreover, there's another issue caused by a similar reason (it will be called "the second issue" later): If you restore a Chrom{ium,e} window from maximized state, chances are some parts of the content in window won't be cleared but left outside the resized window. It's caused by Chromium window returning the old bounding rectangle, a single rectangle of your screen size, after it restored from maximized state, for again a very very short period of time.

Here's the debug output of compton when the bugs appear, with comments: https://gist.github.com/3683925

The details:

1. Chromium creates a ConfigureNotify when it changes window size. When receiving it, compton/xcompmgr marks the area of the Chromium window (a rectangle formed with the dimensions returned by win_extents(), calculated using the window size reported in window attributes, this one is actually correct, it just does not handle windows with non-rectangular shapes, unlike border_size()) as damaged (add the rectangle to the damaged area damage with add_damage()), and turn on the flag clip_changed to indicate window sizes and window bounding rectangles need updates;
2. compton/xcompton starts painting after it finishes doing other things, calling paint_all(), and it requests new window bounding rectangles of the Chromium window from border_size();
3. border_size() retrieves the incorrect bounding rectangles of the Chromium window; paint_all() paints the non-transparent windows in the order of the window stack, from the highest to the lowest, in each step it restricts painting to the damaged area (argument region), removes the border_size rectangles of the window being painted from the damaged area, and set the remaining damaged area as the border_clip of this window, later used to restrict the area where the shadow of the window is painted. As the damage area of the resized Chromium window is an area returned by win_extents(), it does contain the whole Chromium window after resize, so the Chromium window is actually completely painted, it's just that later some parts of the window (the parts outside of the wrong bounding rectangles of the window border_size() got) are overlapped by windows behind it (including the root window) and possibly by shadows, because they are not removed from the damaged area, so lower windows could still be painted in the area, and they are kept in the border_clip of the Chromium window and possibly other windows, upon which shadows could be painted. Oh, well, surely xcompmgr has some confusing painting mechanisms.
4. And before xcompmgr/compton receives an event that enable the clip_changed flag (a CirculateNotify, ConfigureNotify, etc.) or the window gets unmapped, the wrong result will remain cached, so the problem persists until you do something to the windows.
5. The second bug is pretty much similar: Chromium sends the old bounding rectangle, the window gets an abnormally large bounding rectangle cached; xcompmgr/compton paints the content of the new window, of a smaller size, leaving some parts of the original window untouched in the screen buffer; these parts get removed from the damage area because of the wrong bounding rectangle, so no other windows, not even root window, could be painted on them, and the original content in the area is simply left there. These old content will only be wiped from the screen when they become a part of the damaged area -- for example, when you move another window over the area.

Possible fixes:

1. Ask Chromium developers to change the maximize and restore routine, update the window bounding rectangles before it changes window size. Well, I'm not sure about how X FIXES extension determines the bounding rectangles of a window, so it may not be Chromium's fault. The problem is, whether they are cooperative is unpredictable.

2. (Fixes the first issue only) Update window bounding rectangles every time compton paints things. Of course, it's bad performance-wise. I hope the performance penalty is acceptable on modern hardware.

   diff --git a/src/compton.c b/src/compton.c
   index b72dc59..98116ff 100644
   --- a/src/compton.c
   +++ b/src/compton.c
   @@ -1028,12 +1028,13 @@ paint_all(Display *dpy, XserverRegion region) {
        printf(" 0x%x", w->id);
    #endif
   
   +    if (w->border_size) {
   +      set_ignore(dpy, NextRequest(dpy));
   +      XFixesDestroyRegion(dpy, w->border_size);
   +      w->border_size = None;
   +    }
   +
        if (clip_changed) {
   -      if (w->border_size) {
   -        set_ignore(dpy, NextRequest(dpy));
   -        XFixesDestroyRegion(dpy, w->border_size);
   -        w->border_size = None;
   -      }
          if (w->extents) {
            XFixesDestroyRegion(dpy, w->extents);
            w->extents = None;
   @@ -1044,9 +1045,7 @@ paint_all(Display *dpy, XserverRegion region) {
          }
        }
   
   -    if (!w->border_size) {
   -      w->border_size = border_size(dpy, w);
   -    }
   +    w->border_size = border_size(dpy, w);
   
        if (!w->extents) {
          w->extents = win_extents(dpy, w);
   

3. (Fixes the second issue only, to be combined with fix 2) Forces a full screen refresh every time by always making the whole screen the damaged zone. This needs to be combined with fix 2 to ensure the bounding rectangles get updated. The drawback is performance, painting all the time is very costly.

   diff --git a/src/compton.c b/src/compton.c
   index b72dc59..d656f07 100644
   --- a/src/compton.c
   +++ b/src/compton.c
   @@ -1028,12 +1028,13 @@ paint_all(Display *dpy, XserverRegion region) {
        printf(" 0x%x", w->id);
    #endif
   
   +    if (w->border_size) {
   +      set_ignore(dpy, NextRequest(dpy));
   +      XFixesDestroyRegion(dpy, w->border_size);
   +      w->border_size = None;
   +    }
   +
        if (clip_changed) {
   -      if (w->border_size) {
   -        set_ignore(dpy, NextRequest(dpy));
   -        XFixesDestroyRegion(dpy, w->border_size);
   -        w->border_size = None;
   -      }
          if (w->extents) {
            XFixesDestroyRegion(dpy, w->extents);
            w->extents = None;
   @@ -1044,9 +1045,7 @@ paint_all(Display *dpy, XserverRegion region) {
          }
        }
   
   -    if (!w->border_size) {
   -      w->border_size = border_size(dpy, w);
   -    }
   +    w->border_size = border_size(dpy, w);
   
        if (!w->extents) {
          w->extents = win_extents(dpy, w);
   @@ -2586,13 +2585,11 @@ main(int argc, char **argv) {
          ev_handle((XEvent *)&ev);
        } while (QLength(dpy));
   
   -    if (all_damage) {
   -      static int paint;
   -      paint_all(dpy, all_damage);
   -      paint++;
   -      XSync(dpy, False);
   -      all_damage = None;
   -      clip_changed = False;
   -    }
   +    static int paint;
   +    paint_all(dpy, None);
   +    paint++;
   +    XSync(dpy, False);
   +    all_damage = None;
   +    clip_changed = False;
      }
    }
   

4. Change paint_all() so it paints in a different sequence: Paints the root window, paint the lowest window's shadow on it, paint the lowest window, paint the shadow of the second-lowest window... It looks a lot more intuitive, and it should be much easier to implement, perhaps helpful in performance. I'm afraid, nonetheless, these xcompmgr developers, with infinite wisdom, might choose the current seemingly-clumsy painting method on purpose. I believe it's the most promising fix, and it requires most code modification.

5. Let compton wait for a couple of milliseconds before it requests for the bounding rectangles of a window to make sure Chromium has enough time to react. Apparently it does not sound smart -- what if compton and Chromium are running on a 80386?

6. Add special code handling Chromium windows. Well, if you can manage to to identify them with 100% accuracy...

7. Remove area of a painted window from the damaged area according to the window dimension attributes instead of w->border_size. Good for rectangular or close-to-rectangular windows, disaster for specially-shaped windows without special handling -- more exactly, for the windows and shadows under a specially-shaped window.

8. (Fixes the second issue only) A milder version of the fix 7, cut the part of the bounding rectangles if they outside of the border determined by window dimension attributes. Some performance penalty yet not too bad. The rounded corners of Chromium window will not appear right but hardly noticeable.

   diff --git a/src/compton.c b/src/compton.c
   index b72dc59..a1483f5 100644
   --- a/src/compton.c
   +++ b/src/compton.c
   @@ -866,6 +866,19 @@ border_size(Display *dpy, win *w) {
        w->a.x + w->a.border_width,
        w->a.y + w->a.border_width);
   
   +  {
   +    XserverRegion reg = XFixesCreateRegion(dpy, NULL, 0);
   +    XRectangle r;
   +  
   +    r.x = w->a.x;
   +    r.y = w->a.y;
   +    r.width = w->a.width + w->a.border_width * 2;
   +    r.height = w->a.height + w->a.border_width * 2;
   +
   +    XFixesInvertRegion(dpy, reg, &r, border);
   +    XFixesInvertRegion(dpy, border, &r, reg);
   +  }
   +
      return border;
    }
   

9. Improved version of fix 8, detect abnormal results border_size() returns (compare the sizes and positions of the rectangular shapes with the window dimension attributes), then try to calculate a region closest to the actual region a Chromium window occupies. It requires quite some twists to fix both issues with this approach. Less time-efficient, does not look graceful, have the rounded corner issue as fix 6.

10. Minimize and restore every window when it maximizes, and wait for the event before proceeding. I must be insane...

By the way:

I couldn't reproduce this bug on fvwm as under fvwm without a border Chromium does not seem to maximize correctly.

And I hope you won't simply stop updating compton after the 3 issues get resolved. There are other bugs -- like menu transparency does not work without -f -- and other features that could be added -- at least review my colored shadow patch. :-)

Exactly what the title says.

The issue looks like this:

http://goput.it/ooz.png

(The messages in the console occurred after dragging files around in pcmanfm)

Applications pictured: rxvt-unicode 9.15, PCManFM 0.9.10

Options: -cCf -D 4 -O 0.065 -I 0.065 -m 0.86 -e 0.86 -o 0.44 -l -6 -t -5

Built from master on 2012-02-19 on Debian GNU/Linux wheezy

Origin of the idea: fluxbox panel is shown with a shadow. -C doesn't help since the panel doesn't have NET_WM_WINDOW_TYPE_DOCK. The ideal solution is, of course, to fix fluxbox, but it's harder (if even possible) then the suggested solution, and the suggested solution could probably be helpful in other cases (no specific examples here, I just guess they exist).

Solution: fluxbox panel appears not to have a window name (it's NULL). So the approach in the patch below is to allow to supply an empty target value in --shadow-exclude to exclude windows with empty (either "" or NULL) target values (in the case of fluxbox the whole option would look like --shadow-exclude n:e:).

Side effects: the patch leads compton to not distinguishing between NULL values and actually empty ("") values which is probably not wanted.

What do you think? Could it be applied to master?

diff -Napur chjj-compton-c7ca345/src/compton.c chjj-compton-c7ca345.new/src/compton.c
--- chjj-compton-c7ca345/src/compton.c  2012-10-01 07:57:46.000000000 +0400
+++ chjj-compton-c7ca345.new/src/compton.c      2012-10-06 23:29:54.000000000 +0400
@@ -730,15 +730,15 @@ win_match_once(win *w, const wincond *co
     case CONDTGT_CLASSG:
       target = w->class_general;
       break;
-  }
-
-  if (!target) {
+    default:
 #ifdef DEBUG_WINMATCH
-  printf(": Target not found\n");
+      printf(": Target not found\n");
 #endif
-    return false;
+      return false;
   }

+  if (!target) target = "";
+
   // Determine pattern type and match
   switch (cond->type) {
     case CONDTP_EXACT:

I read that compton has menu transparency option from Dana, but I don't see anywhere how to set it? Is it enabled ? if so how can I use it?

Thanks!

I would like to see the option to set the color for shadows. I currently have a black background with no wallpaper which makes shadows rather useless/invisible. I'm sure this option would help with any sort of dark theme and wallpaper combo.

What's the proper way to disable shadows?
Currently, I'm calling compton with -o 0.

If I send SIGUSR1 to a running tint2 instance with:

pkill -USR1 -x tint2

tint2 reloads its configuration and compton draws over tint2's window.

Compton crashes during dragging smth (chromium tab, file/folder in PCManFM and so on) with following errors:

error 3 (Unknown) request 20 minor 0 serial 5388
error 3 (Unknown) request 15 minor 0 serial 5389
Segmentation fault

With -S option crash does not observe.

Archlinux, Openbox 3.5, xf86-video-intel 2.17

I've got problems using compton in conjunction with conky.

Here's how it looks with compton: http://ge.tt/15VJnNB/4
And with xcompmgr: http://ge.tt/15VJnNB/5

My conkyrc is available here:
https://raw.github.com/baskerville/dotfiles/master/conkyrc

http://i.imgur.com/LqhVv.png

I'm not sure this is caused by compton or openbox, or it might be a problem in my X configuration. When I iconify a window and openbox's animateIconify option is set, I get this kind of result:

http://goput.it/f50.jpg

This can be worked around by unsetting the animateIconify, so no big deal.

When I shade a window, I get this kind of result:

http://goput.it/gc1.jpg

The shaded window starts as just a box where the window was, then if I move the shaded window's title bar around, I get the displayed artifacts seen.

I can live with this for now and otherwise no problems. I really like compton, so it's not a show stopper. But I would like to get it sorted out, eventually. If you're really busy but can give me any ideas for where to look for the problem, that would be great.

Thank you,
John

at first - thank you for compton, the 1st xcomposite manager I'm able to use with razor-qt.org!

I prepared some RPM packages:
http://software.opensuse.org/download?package=compton&project=X11:QtDesktop

But I'm not sure about compton version. Currently I use 0.0.1 as a dummy placeholder. Also source code is taken from git master - not from a tag etc.

So it would be great if you can make some "release" later.

Also some building system would be great to have. If you are interested, I can offer help with cmake.

repeat_the_title this is unfriendly with the Arch Linux packaging system, which usually does make PREFIX=$pkgdir/usr install, but your "install" target doesn't create those destinations. So I do install -d -m755 $pkgdir/usr/{bin,share/man/man1} manually before make install. I'm not so familiar with Makefile, afraid can't help you this time >_<. BTW thanks for the great work, I created a wiki page at Arch Wiki.

Images to demonstrate problem:
http://i.imgur.com/oJkpz.png
http://i.imgur.com/DnpRE.png

I imagine computing non-square shadows is rather difficult, so I would consider this a further motivator for blacklisting (so, let me prevent shading of windows I know are not square)

I'm thinking about to bundle compton with razor-qt DE (razor-qt.org) but I'd like to create a config GUI for it. It would be great if there can be some way how to change compton's settings in the runtime.

For example:

• a dbus interface, then save it into config file
• check changes in the config file and reload it automatically
• some interprocess communication I cannot name now ;)

Let's discuss it now...

First, many thanks for picking up xcompmgr and fix many bugs and peculiarities. You are on the way to make the default compositing manager for all our window managers! Currently I'm using Compton with Xfwm4, it is much better than the builtin compositing.

But there's still a problem for me. I'm planning to package Compton for Fedora. Currently we have a script named "settrans" which will be installed into $PREFIX/bin. For the time being there is actually no real problem, but the name sounds familiar to me, although we don't have settrans somewhere in Fedora. As far as I know, there is a network script in GNU Hurd with the same name. Could be we have some more occurences all around the free software...
Nevertheless, it would be better to use a more specific name, for example "compton-settrans". Would it be possible to change the name as proposed? It would be easier for packagers and more distinguisahble for users.

Using compton -f -D8 -I0.05 -O0.05 &, the 1px wide borders around Fluxbox windows don't render, but Fluxbox behaves as though they are there with window snapping.

I can provide screenshot(s) if necessary.

Thank you for working on compton.

For the most part, it works perfectly and I'm finding it preferable to other lightweight compositors. One thing that I have noticed is that when compton is run with the -f option, notification bubbles from notify-osd are completely invisible. notify-osd still appears to be running properly, because applications that depend on it do not crash or complain, but its notifications just don't appear on the screen.

For reference, xcompmgr also did not get along with notify-osd when its fade effect was enabled. I remember its fade effect making notification bubbles fade in and out two times before disappearing.

I am using the Archlinux with the latest versions of Openbox and notify-osd-customizable.

Also, a request: Would it be possible to add an exclude option to compton, so that it wouldn't apply its effects to specified applications?

Thanks for reading.

When I start compton (with no options), it constantly prints error messages like this:

[ 0.03 ] error 9 (BadDrawable) request 153 minor 4 serial 163
[ 0.03 ] error 9 (BadDrawable) request 153 minor 4 serial 170
[ 0.03 ] error 9 (BadDrawable) request 153 minor 4 serial 179
[ 0.03 ] error 9 (BadDrawable) request 153 minor 4 serial 188
[ 0.05 ] error 177 (BadPicture) request 153 minor 8 serial 225
[ 0.05 ] error 177 (BadPicture) request 153 minor 8 serial 231

The "error 9" messages only occur at the beginning, the rest are all "error 177". Compton seems to be working fine other than these messages, but perhaps they indicate an underlying problem?

I've tried it with fvwm 2.6.5, both with my normal config and a null config. I also tried with e16 1.0.11, which gave the same results. Openbox 3.5.0 did not produce the error messages. This happens on multiple machines, one with NVidia graphics and another with Intel.

I'm using commit c7ca345.

1. you unset CFLAGS which is very bad

remove line 8 or just append "-Wall"

1. you dont respect LDFLAGS which is bad too

change line 15 to
$(CC) $(LDFLAGS) $(CFLAGS) -o $@ $(OBJS) $(LIBS)

1. use something like "install -Dm755 ..." for the binaries and "install -Dm644 ..." for the manpage instead of "cp" for proper permissions
2. line 6 and 7 are problematic. they should be
   LIBS = $(shell pkg-config --libs $(PACKAGES)) -lm
   INCS = $(shell pkg-config --cflags $(PACKAGES))

Is it possible to make windows transparent when they're being moved only? It's a feature I tried getting to work with xcompmgr/transset in the past but never managed.

It's only today that I started using compton. I have an issue with fadein animation.

For popups like notify-osd, window menus, etc, it works perfectly. But, when on windows like chromium, tilda etc, it appears something like at first the window is shown (fully opaque) and then the the fadein occurs.

Hope you understand what I am saying. What I mean is, if suppose the transparency of window is measured from 0-100. Whenever I try to maximize the window from tasklist (awesome wm), at t=0, transparency is 100, then from t=0.01 to t=0.5s, it has a smooth transition from 0-100.

Has anyone else reported this issue or is it just me?

Hardware: Nvidia 320M (with proprietary driver)

The problem also appears in xcompmgr and unagi, so I just quoted my bug report on unagi bug tracker. I did replace all occurrences of unagi with compton, though.

If compton is started, and I have "double_buffer" turned on and "own_window" turned off in .conkyrc, all windows vanish when conky updates its graphs; If I turn off both "double_buffer" and "own_window", conky does not get rendered correctly, sometimes the graphs and numbers conky drawn appear on the top of all windows, sometimes new graphs overlaps on the old graphs. Turning "own_window" on in .conkyrc fixes it. So essentially if conky tries to draw on the root window when compton is on, weird things start happening. At first I thought it was a conflict related to fvwm, yet eventually found it's conky.

It's probably not an issue of compton itself, though, because xcompmgr has the same problem with its default compositing mode. I prefer to run conky with "own_window" turned off since then I could open fvwm's root menu when clicking on conky.

I'm getting a graphics performance degradation in some apps when is compton running. Affected apps are these with intensive graphics handling (not regular GUIs). Examples:

• super tuxkart (game)
• xscreensaver

it looks like frames per second are reduced to really low count resulting in twitching (run/freeze/run) steps.

Unfortunately I have no idea what to do in this case except kill compton.

setup: nvidia, openbox 3.5.0

Font drawing tends to be slow from 778a8b1 commit on my machine.

I upgrade compton recently from AUR of archlinux, and found that it get slow on some applications, especially SublimeText2 editor. Then I cloned the repo manually, checkout each commit as binary search, and finally located the bug was introduced in commit 778a8b1 . I can confirm that the bug was not there in e7da888 .

Sorry I have not enough time to debug inside the source code or describe the problem more accurate.

My setup:
HP z800 workstation
Archlinux
xorg-server : 1.12.4-1
awesome : 3.4.13-1
sublime-text : 2.0.1-2

Do you need more information?

I would suggest to include the dependencies from "bin/settrans" in the README as well
depending on the distribution that is "x11-utils" or "xorg-xprop + xorg-xwininfo"

we also need "xproto" (archlinux and gentoo) or "x11proto-core-dev" (Debian) which includes "X11/Xatom.h" as build-time dependency

to sum that up it would be something like this on gentoo
runtime-dependencies:
app-shells/bash
x11-apps/xprop
x11-apps/xwininfo
x11-libs/libXcomposite
x11-libs/libXdamage
x11-libs/libXfixes
x11-libs/libXrender
x11-libs/libX11

buildtime-dependencies:
dev-util/pkgconfig
x11-libs/libXcomposite
x11-libs/libXdamage
x11-libs/libXfixes
x11-libs/libXrender
x11-libs/libX11
x11-proto/xproto

seperating and clarifying those would make it easier for packagers, imo.

Hi,

First of all, thanks a lot for the excellent work you've done on compton.

The current bersion of compton doesn't work (anymore) at this date: 2012-09-26.
It was working on 2012-09-24.

When I run it with these parameters...
compton -Cc -fF -I-.015 -O-.03 -D1 -t-1 -l-3 -r4.2 -o.5 &
...all windows become invisible.

I run openbox under archlinux.

Any idea?
Do you need more info?

Cheers
valr

to my knowledge no way of setting transparency on focused window

The problems:

1. compton does not respect _NET_WM_OPACITY set when compton is not running, because, well, you commented out the line that fetches it in map_win() when implementing inactive_opacity. It's easy to reproduce: set the opacity of a window with compton-trans, run compton, and the window isn't rendered according to the opacity you just set.

2. compton does not respect _NET_WM_OPACITY when -i (inactive_opacity) is enabled, well, in most cases. If you set the opacity of a window when compton is running, the setting will be ignored after you change the focused window: The newly focused one gets opaque, the inactive ones get the value -i sets. Even if you refocus the window with _NET_WM_OPACITY set it still won't work.

3. When -i (inactive_opacity) is enabled, and you start compton, the currently focused window is rendered with the opacity of an inactive window, before you switch focus, i.e. when it receives FocusIn event. The cause is compton does not check for the current active window when it starts, and it marks every window with opacity of inactive windows.

4. compton uses unsigned int and memcpy to copy the content of _NET_WM_OPACITY returned, and there's no guarantee that unsigned int is always 32-bit on all archs. If it has a different size compton perhaps will display windows with _NET_WM_OPACITY set with incorrect opacity.

5. compton ignores -m (menu transparency) if -f is not enabled. I happened to resolve this bug when rewriting the opacity handling section, so I do not know what initially caused this.

6. compton's -e switch ignores the opacity of the main window when it paints frames. If the user runs compton as:

   compton -i 0.5 -e 0.9
   

   Then compton would display the inactive windows with 50% opacity, their frames with 90% opacity. Whether this is a bug or a design decision is not very clear.

The fix:

So you have to face a huge patch again... It fixes bug 1, 2, 3. 4, and 5. I did not do much tests to this patch, so please review it carefully.

Besides fixing the bugs it additionally changes some aspects of the program:

1. The opacity calculating is basically rewritten. Almost all opacity calculations are concentrated in a new function calc_opacity(). The new priority rules are indicated in the comments, change them if you need. Some code are cleaned up to increase code reusability.
2. An option boolean variable inactive_opacity_override is provided to restore the old behavior (i.e. bug 2) that the inactive_window has higher priority than _NET_WM_OPACITY. However I found no spare related characters to set up this as a short option. It's current case 0, and please change it to a character if you wish to use the option.
3. A new type opacity_t (aka uint32_t) is introduced as a fix of bug 3, and been used for the option inactive_opacity and the member opacity in struct _win. frame_opacity is left unchanged for (possibly) performance.
4. Caches _NET_WM_OPACITY's value in struct _win for performance, if I didn't misunderstand something.
5. To resolve bug 2 I need to check which window is currently focused. As looks like XGetInputFocus() often does not return the WM frame of a focused window but the application window itself, I used a rather awkward way to find out its WM frame. Change it if you have a better way.

And there's the patch:

diff --git a/src/compton.c b/src/compton.c
index b72dc59..4ad4662 100644
--- a/src/compton.c
+++ b/src/compton.c
@@ -72,9 +72,6 @@ Bool win_type_fade[NUM_WINTYPES];
  * Macros
  */

-#define INACTIVE_OPACITY \
-(unsigned long)((double)inactive_opacity * OPAQUE)
-
 #define IS_NORMAL_WIN(w) \
 ((w) && ((w)->window_type == WINTYPE_NORMAL \
          || (w)->window_type == WINTYPE_UTILITY))
@@ -99,8 +96,11 @@ Bool fade_trans = False;

 Bool clear_shadow = False;

-double inactive_opacity = 0;
-double frame_opacity = 0;
+/// Default opacity for inactive windows, 0.0 if unset
+opacity_t inactive_opacity = 0;
+/// Whether inactive_opacity overrides the opacity set by window attributes
+Bool inactive_opacity_override = True;
+double frame_opacity = 0.0;

 Bool synchronize = False;

@@ -194,21 +194,7 @@ set_fade(Display *dpy, win *w, double start,
   }

   f->callback = callback;
-  w->opacity = f->cur * OPAQUE;
-
-  determine_mode(dpy, w);
-
-  if (w->shadow) {
-    XRenderFreePicture(dpy, w->shadow);
-    w->shadow = None;
-
-    if (w->extents != None) {
-      XFixesDestroyRegion(dpy, w->extents);
-    }
-
-    /* rebuild the shadow */
-    w->extents = win_extents(dpy, w);
-  }
+  set_opacity(dpy, w, f->cur * OPAQUE);

   /* fading windows need to be drawn, mark
      them as damaged.  when a window maps,
@@ -1360,6 +1346,7 @@ map_win(Display *dpy, Window id,

   if (!w) return;

+  w->focused = False;
   w->a.map_state = IsViewable;
   w->window_type = determine_wintype(dpy, w->id, w->id);

@@ -1374,8 +1361,7 @@ map_win(Display *dpy, Window id,
     XSelectInput(dpy, id, PropertyChangeMask | FocusChangeMask);
   }

-  // this causes problems for inactive transparency
-  //w->opacity = get_opacity_prop(dpy, w, OPAQUE);
+  calc_opacity(dpy, w, True);

   determine_mode(dpy, w);

@@ -1477,8 +1463,7 @@ unmap_win(Display *dpy, Window id, Bool fade) {
     finish_unmap_win(dpy, w);
 }

-static unsigned int
-get_opacity_prop(Display *dpy, win *w, unsigned int def) {
+opacity_t get_opacity_prop(Display *dpy, win *w, opacity_t def) {
   Atom actual;
   int format;
   unsigned long n, left;
@@ -1489,9 +1474,8 @@ get_opacity_prop(Display *dpy, win *w, unsigned int def) {
     XA_CARDINAL, &actual, &format, &n, &left, &data);

   if (result == Success && data != NULL) {
-    unsigned int i;
-    memcpy(&i, data, sizeof(unsigned int));
-    XFree((void *)data);
+    opacity_t i = *((opacity_t *) data);
+    XFree(data);
     return i;
   }

@@ -1500,11 +1484,7 @@ get_opacity_prop(Display *dpy, win *w, unsigned int def) {

 static double
 get_opacity_percent(Display *dpy, win *w) {
-  double def = win_type_opacity[w->window_type];
-  unsigned int opacity =
-    get_opacity_prop(dpy, w, (unsigned int)(OPAQUE * def));
-
-  return opacity * 1.0 / OPAQUE;
+  return w->opacity * 1.0 / OPAQUE;
 }

 static void
@@ -1554,8 +1534,11 @@ determine_mode(Display *dpy, win *w) {
   }
 }

-static void
-set_opacity(Display *dpy, win *w, unsigned long opacity) {
+void set_opacity(Display *dpy, win *w, opacity_t opacity) {
+  // Do nothing if the opacity does not change
+  if (w->opacity == opacity)
+    return;
+
   w->opacity = opacity;
   determine_mode(dpy, w);
   if (w->shadow) {
@@ -1571,6 +1554,51 @@ set_opacity(Display *dpy, win *w, unsigned long opacity) {
   }
 }

+/**
+ * Calculate and set the opacity of a window.
+ *
+ * If window is inactive and inactive_opacity_override is set, the
+ * priority is: (Simulates the old behavior)
+ *
+ * inactive_opacity > _NET_WM_WINDOW_OPACITY (if not opaque)
+ * > window type default opacity
+ *
+ * Otherwise:
+ *
+ * _NET_WM_WINDOW_OPACITY (if not opaque)
+ * > window type default opacity (if not opaque)
+ * > inactive_opacity
+ *
+ * @param dpy
+ * @param w
+ */
+void calc_opacity(Display *dpy, win *w, Bool refetch_prop) {
+  opacity_t opacity;
+
+  // Do nothing for unmapped window, calc_opacity() will be called
+  // when it's mapped
+  // I suppose I need not to check for IsUnviewable here?
+  if (IsViewable != w->a.map_state)
+    return;
+
+  // Do not refetch the opacity window attribute unless necessary, this
+  // is probably an expensive operation in some cases
+  if (refetch_prop)
+    w->opacity_prop = get_opacity_prop(dpy, w, OPAQUE);
+
+  if (OPAQUE == (opacity = w->opacity_prop)) {
+    if (OPAQUE != win_type_opacity[w->window_type])
+      opacity = win_type_opacity[w->window_type] * OPAQUE;
+  }
+  
+  // Respect inactive_opacity in some cases
+  if (IS_NORMAL_WIN(w) && False == w->focused && inactive_opacity
+      && (OPAQUE == opacity || inactive_opacity_override))
+    opacity = inactive_opacity;
+
+  set_opacity(dpy, w, opacity);
+}
+
 static void
 add_win(Display *dpy, Window id, Window prev, Bool override_redirect) {
   if (find_win(dpy, id)) {
@@ -1628,6 +1656,8 @@ add_win(Display *dpy, Window id, Window prev, Bool override_redirect) {
   new->shadow_width = 0;
   new->shadow_height = 0;
   new->opacity = OPAQUE;
+  new->opacity_prop = OPAQUE;
+  new->focused = False;
   new->destroyed = False;
   new->need_configure = False;
   new->window_type = WINTYPE_UNKNOWN;
@@ -1657,9 +1687,6 @@ add_win(Display *dpy, Window id, Window prev, Bool override_redirect) {

   if (new->a.map_state == IsViewable) {
     new->window_type = determine_wintype(dpy, id, id);
-    if (inactive_opacity && IS_NORMAL_WIN(new)) {
-      new->opacity = INACTIVE_OPACITY;
-    }
     map_win(dpy, id, new->damage_sequence - 1, True, override_redirect);
   }
 }
@@ -1844,7 +1871,7 @@ destroy_win(Display *dpy, Window id, Bool fade) {

 #if HAS_NAME_WINDOW_PIXMAP
   if (w && w->pixmap && fade && win_type_fade[w->window_type]) {
-    set_fade(dpy, w, w->opacity * 1.0 / OPAQUE,
+    set_fade(dpy, w, get_opacity_percent(dpy, w),
       0.0, fade_out_step, destroy_callback,
       False, True);
   } else
@@ -2033,9 +2060,9 @@ ev_focus_in(XFocusChangeEvent *ev) {
   if (!inactive_opacity) return;

   win *w = find_win(dpy, ev->window);
-  if (IS_NORMAL_WIN(w)) {
-    set_opacity(dpy, w, OPAQUE);
-  }
+
+  w->focused = True;
+  calc_opacity(dpy, w, False);
 }

 inline static void
@@ -2052,9 +2079,9 @@ ev_focus_out(XFocusChangeEvent *ev) {
   }

   win *w = find_win(dpy, ev->window);
-  if (IS_NORMAL_WIN(w)) {
-    set_opacity(dpy, w, INACTIVE_OPACITY);
-  }
+
+  w->focused = False;
+  calc_opacity(dpy, w, False);
 }

 inline static void
@@ -2143,9 +2170,7 @@ ev_property_notify(XPropertyEvent *ev) {
     /* reset mode and redraw window */
     win *w = find_win(dpy, ev->window);
     if (w) {
-      double def = win_type_opacity[w->window_type];
-      set_opacity(dpy, w,
-        get_opacity_prop(dpy, w, (unsigned long)(OPAQUE * def)));
+      calc_opacity(dpy, w, True);
     }
   }

@@ -2447,10 +2472,13 @@ main(int argc, char **argv) {
         shadow_offset_y = atoi(optarg);
         break;
       case 'i':
-        inactive_opacity = (double)atof(optarg);
+        inactive_opacity = (normalize_d(atof(optarg)) * OPAQUE);
+        break;
+      case 0:
+        inactive_opacity_override = True;
         break;
       case 'e':
-        frame_opacity = (double)atof(optarg);
+        frame_opacity = normalize_d(atof(optarg));
         break;
       case 'z':
         clear_shadow = True;
@@ -2564,6 +2592,37 @@ main(int argc, char **argv) {
     add_win(dpy, children[i], i ? children[i-1] : None, False);
   }

+  // Check the currently focused window so we can apply appropriate
+  // transparency on it
+  {
+    Window wid = 0;
+    int revert_to;
+    win *w = NULL;
+
+    XGetInputFocus(dpy, &wid, &revert_to);
+
+    // XGetInputFocus seemingly returns the application window focused
+    // instead of the WM window frame, so we traverse through its parents
+    // to find out the frame
+    while(wid && wid != root
+        && !array_wid_exists(children, nchildren, wid)) {
+      Window troot;
+      Window parent;
+      Window *tchildren;
+      unsigned tnchildren;
+
+      XQueryTree(dpy, wid, &troot, &parent, &tchildren, &tnchildren);
+      XFree(tchildren);
+      wid = parent;
+    }
+
+    // And we set the focus state and opacity here
+    if (wid && wid != root && (w = find_win(dpy, wid))) {
+      w->focused = True;
+      calc_opacity(dpy, w, False);
+    }
+  }
+
   XFree(children);

   XUngrabServer(dpy);
diff --git a/src/compton.h b/src/compton.h
index 18e3859..17dd332 100644
--- a/src/compton.h
+++ b/src/compton.h
@@ -7,6 +7,7 @@
 #include <stdlib.h>
 #include <stdio.h>
 #include <string.h>
+#include <inttypes.h>
 #include <math.h>
 #include <sys/poll.h>
 #include <sys/time.h>
@@ -42,6 +43,8 @@
  * Types
  */

+typedef uint32_t opacity_t;
+
 typedef enum {
   WINTYPE_UNKNOWN,
   WINTYPE_DESKTOP,
@@ -92,8 +95,12 @@ typedef struct _win {
   int shadow_dy;
   int shadow_width;
   int shadow_height;
-  unsigned int opacity;
+  opacity_t opacity;
+  /// Cached value of opacity window attribute
+  opacity_t opacity_prop;
   wintype window_type;
+  /// Whether the window is focused
+  Bool focused;
   unsigned long damage_sequence; /* sequence when damage was created */
   Bool destroyed;
   unsigned int left_width;
@@ -128,6 +135,28 @@ typedef struct _fade {
  * Functions
  */

+// inline functions must be made static to compile correctly under clang:
+// http://clang.llvm.org/compatibility.html#inline
+
+static inline double normalize_d(double d) {
+  if (d > 1.0)
+    return 1.0;
+  if (d < 0.0)
+    return 0.0;
+
+  return d;
+}
+
+static inline Bool array_wid_exists(const Window *arr,
+    int count, Window wid) {
+  while (count--) {
+    if (arr[count] == wid)
+      return True;
+  }
+  
+  return False;
+}
+
 static int
 get_time_in_milliseconds();

@@ -248,8 +277,8 @@ unmap_callback(Display *dpy, win *w);
 static void
 unmap_win(Display *dpy, Window id, Bool fade);

-static unsigned int
-get_opacity_prop(Display *dpy, win *w, unsigned int def);
+opacity_t
+get_opacity_prop(Display *dpy, win *w, opacity_t def);

 static double
 get_opacity_percent(Display *dpy, win *w);
@@ -257,8 +286,9 @@ get_opacity_percent(Display *dpy, win *w);
 static void
 determine_mode(Display *dpy, win *w);

-static void
-set_opacity(Display *dpy, win *w, unsigned long opacity);
+void set_opacity(Display *dpy, win *w, opacity_t opacity);
+
+void calc_opacity(Display *dpy, win *w, Bool refetch_prop);

 static void
 add_win(Display *dpy, Window id, Window prev, Bool override_redirect);

The 6th bug (or design decision) is so easy to change and I don't need to explain anything, I guess.

By the way:

Could you please look into the second bug I mentioned in the last reply in the "Maximized Chromium window" issue? It should be somewhere you changed so you probably have an idea where it comes from.

Update: I fixed that one myself: #38

Consider this a humble request that you might find useful/interesting, and would have the upside of considerably increasing the usability of tiling window managers when used with it...

Would it be possible to implement a feature to dim inactive windows, similar to what Kwin allows? This would probably work almost identically to the current "-i" flag, except that rather than making inactive windows transparent it would darken (and possibly desaturate) them by the given amount. Possibly other useful flags: prevent panels from never being dimmed, dim all windows except foreground (i.e., make dialogs pop, probably should "double-dim" inactive windows).

I've been looking for a feature like this to use in conjunction with Xmonad for a long time, and compton looks to be the closes to something that can actually implement it.

Thanks for the consideration!

I could write problem description in the commit log but I won't be able to display the screenshots there, so, another issue report.

The problem:

-z (clear_shadow) has some glitches when using non-default shadow radius and offset, except on some special combinations.

compton -c -r 15 -z

compton -c -t -4 -l -4 -z

The cause is, well, how clear_shadow is internally implemented.

The fixes:

The fix will be committed to richardgv-dev branch soon.

compton -c -t -4 -l -4 -z

I added special handling for very aggressive cases, like:

compton -c -r 5 -t 50 -l 50 -z

I removed the code that prevent the shadow transparency from been affected by the window transparency if -z is enabled, as it sometimes make the shadow of a semi-transparent window much darker than the window itself (and I personally use a dark theme), somehow horrifying an effect. Revert it if you wish.

By the way:
I found both compton and xcompmgr causes fvwm's geometry window to disappear. Will look into this someday.

0d67243 causes the chromium omnibar dropdown completion menu to always have unfocused transparency. 8724101 doesn't have this problem.

This is a pretty simple problem. I created an issue for it just because my fix is ugly and possibly slow and I wonder if you guys have a better way.

The problem:

If a window gets mapped and instantly gets focus, compton will not notice it. When using -i (inactive_opacity), the window will be rendered as inactive. To reproduce it, start compton with -i, minimize a full screen window, then restore it.

The fix:

My fix will be committed to richardgv-dev branch soon. A description of the my guess about the cause is included in comments:

/*
 * Occasionally compton does not seem able to get a FocusIn event from a
 * window just mapped. I suspect it's a timing issue again when the
 * XSelectInput() is called too late. If this is the case, I could think
 * of two fixes: To monitor the focus events from the root window, and
 * to determine if the current window is focused in map_win(). Looks
 * like the XFocusChangeEvent sent to the root window contains no
 * information about where the WM frame of the focused window is, and 
 * XGetInputFocus() often returns an application window instead of the
 * WM frame, which compton keeps track of, in either way I believe we
 * have to travel through the ancestors of the focused window it
 * returns. The latter choice looks cheaper, so I'm doing it here.
 * But still, this could anyway be costly.
 *
 * An alternative route might be relying on _NET_ACTIVE_WINDOW.
 * Unfortunately as it's set by WM I'm not completely sure if it's
 * reliable and will be updated on the very moment a window is mapped.
 */

The problem of the fix:

I guess it would be slow. Querying X server for many times is not the fastest thing in the world.

I have used compton for a time. recently, I found a problem.
When I choose savePageAs or savePictureAs, the dialog window didn't show, it was under the main window.
this was also found when using stardict(choose preference from menu).
can you resolve it for fvwm users.

Update: Oops, I used issue code 43 instead of 42 in the commit message.

Again I need a place to write a piece of description of an issue that does not fit too much inside commit log.

Problem:

-e (frame_opacity) often does not work for windows created after compton starts. It's strictly timing-related. When introducing extra delay to add_win() the problem disappears. Debugging shows compton fails to determine the client window in add_win() when the bug appears.

Cause:

My personal guess is compton querys X server in add_win() too early, before the window manager set up the client window and frame correctly.

Fix:

I thought about two plans: Adding client window detection to ev_reparent_notify() to catch a client window when it reparents to its WM frame, or moving client window detection to map_win(), at which the client window should be ready. I chose the latter one as it looks cheaper and more reliable. The problem of this approach is compton may have to rely on the slower find_toplevel2() instead of find_toplevel() more frequently. The fix will be pushed to richardgv-dev branch soon.

Whenever I run any (OpenGL) game from PlayOnLinux in full screen mode there is a shadow above cloaking everything but respecting the offset parameters. The OpenGL window won't be redrawn either. Without compton it works just fine.
I run compton with the following options (plus numeric settings like offsets):

compton -CcfbG

Been running 778a8b1 for a few hours now. I switched workspaces back to my terminals, and the focused terminal wasn't painted at all. I had to kill compton entirely because I couldn't get it to render. This is the first time I've seen this happen so far. Will try to reproduce. Options: compton -cCfF -i 0.5.

I'm using compton with awesome WM and konsole. When I use the -f switch on compton, background transparency on konsole doesn't work. If I omit the -f switch, it works fine.

For the sake of reference, I don't get this behavior with xcompmgr.

Apologies for the poor bug title, but I am not sure how best to describe this issue. Anyhow, running Compton under Debian Wheezy, I am experiencing a strange shadow bug, whereby a window shadow stays on top of all other windows. When this happens, the shadow always appears at the same coordinates and appears to always have the same dimensions. Please see the following screenshot:

At first, the bug appeared to be happening at random, when opening an application, but I can now replicate the bug quite consistently by following these steps:

1. Launch VLC
2. Close VLC
3. Open File Roller (I use File Roller as an example, but most GTK+ 3 applications seem to trigger bug)

Given some instruction, I would be more than happy to help debug this.

Apart from this issue, Compton has been working perfectly, thank you :)

Hi,

I'm launching compton (great improvement over xcompmgr imho) with -cC -fF -I 0.065 -O 0.065 -D 10 -b but I'm noticing after a while (2-3 hours) the AwesomeWM panel start having a shadow over other windows too, which -C should prevent if I'm not misunderstanding its use.

Attached screen with panel and shadow over the Firefox window: Image

Switching to a desktop that has only terminals (no gtk/qt apps basically) removes that shadow.

On Archlinux with:
AwesomeWM 3.4.11
libxcomposite 0.4.3
libx11 1.4.99
xorg 1.12.0
compton-git 20120321

After pulling in the most recent changes from master, I cannot compile compton on Ubuntu 12.04, either 64 bit or 32 bit. I have previously been able to compile with no problems on both systems, the last time I compiled successfully was 2012-09-04.

First time I try to compile I get an error about libconfig not being found; I installed libconfig8-dev and tried again. This time I get these errors:

cc -Wall -std=c99    -c src/compton.c
src/compton.c: In function ‘condlst_add’:
src/compton.c:850:59: error: ‘PCRE_STUDY_JIT_COMPILE’ undeclared (first use in this function)
src/compton.c:850:59: note: each undeclared identifier is reported only once for each function it appears in
src/compton.c: In function ‘parse_config’:
src/compton.c:3072:5: warning: implicit declaration of function ‘config_set_include_dir’ [-Wimplicit-function-declaration]
src/compton.c:3089:3: warning: passing argument 3 of ‘config_lookup_int’ from incompatible pointer type [enabled by default]
/usr/include/libconfig.h:235:26: note: expected ‘long int *’ but argument is of type ‘int *’
src/compton.c:3098:3: warning: passing argument 3 of ‘config_lookup_int’ from incompatible pointer type [enabled by default]
/usr/include/libconfig.h:235:26: note: expected ‘long int *’ but argument is of type ‘int *’
src/compton.c:3102:3: warning: passing argument 3 of ‘config_lookup_int’ from incompatible pointer type [enabled by default]
/usr/include/libconfig.h:235:26: note: expected ‘long int *’ but argument is of type ‘int *’
src/compton.c:3104:3: warning: passing argument 3 of ‘config_lookup_int’ from incompatible pointer type [enabled by default]
/usr/include/libconfig.h:235:26: note: expected ‘long int *’ but argument is of type ‘int *’
make: *** [compton.o] Error 1

I tried make clean but it doesn't fix anything. Not sure if I'm missing a library, I didn't see any new dependencies listed in README, and I do have libpcre-dev

Hello.

I have recently istalled compton on 2 computers which run Debian squeeze LXDE: a netbook and a laptop. On the netbook it works like a charm. On my laptop I am facing an issue:

When I am moving a window with a mouse cursor the window movement is delayed related to the cursor. I had exactly the same window movement delay issue (not compton-related) using another distro right before installing the graphics card driver (nvidia). I have currently an nvidia driver installed on my laptop and the window movements are normal when compton is turned off.

I was running the simple autostart compton command "@Compton -cC -i 0.6 -e 0.6".

Any ideas for a fix?

Thanks in advance for any help.

I really like this compositor, but I have just only started using it. It is simple and does not produce so many problems as xcompmgr.
However, one thing I did notice (and which might be a feature) is that the transparency of windows (eg. transparent inactive windows) is not preserved when switching desktops (all windows loose transparency). Using help I was not able to correct this behavior.
I am using:
compton -cC -fF -I 0.065 -O 0.065 -D 6 -m 0.8 -i 0.6 -e 0.85 -b

on Gentoo with:
x11-misc/compton-0_pre20120316
x11-base/xorg-x11-7.4-r1
x11-wm/openbox-3.5.0_p20111019
lxde-base/lxde-meta-0.5.5
x11-libs/libX11-1.4.4
x11-libs/libXcomposite-0.4.3-r1

Thank you for any reaction.

Is it possible to implement vsync into compton? I like this compositor very much, but tearing is annoying some time.

This is the second bug I indicated in the "by the way" part of a reply to the Maximized Chromium window issue, just lifted out here to make the issue easier to see: #36 (comment)

The problem:
When a specially shaped (non-rectangular) window becomes transparent, compton renders the part out of its shape incorrectly. Just run compton, run oclock, then set oclock window's opacity to like 50%, and you see the issue. Try moving the oclock window around if it's not obvious where the problem is.

The patch:

Should I repeat my usual words that I know nothing and this patch can be very unreliable? :-) It's taken from xcompmgr:

diff --git a/src/compton.c b/src/compton.c
index b72dc59..57f9926 100644
--- a/src/compton.c
+++ b/src/compton.c
@@ -1122,6 +1122,10 @@ paint_all(Display *dpy, XserverRegion region) {
     if (w->mode != WINDOW_SOLID || HAS_FRAME_OPACITY(w)) {
       int x, y, wid, hei;

+      // Necessary to make sure specially-shaped windows are
+      // painted correctly
+      XFixesIntersectRegion(dpy, w->border_clip, w->border_clip, w->border_size);
+      XFixesSetPictureClipRegion (dpy, root_buffer, 0, 0, w->border_clip);
 #if HAS_NAME_WINDOW_PIXMAP
       x = w->a.x;
       y = w->a.y;

By the way:

To make sure you don't get puzzled, here's a list of the patches I posted that needs review so far:

• "Ultimate" patch for the two Chromium window issues, using ShapeNotify: #36 (comment)

  (I don't know a way to get around these two issues by simply changing painting sequence, without relying on the bounding region, which can be unreliable. Probably there's a way if we change how the Picture of a window is retrieved, but I suspect that painting in this way would result in huge performance loss. I guess listening to ShapeNotify is the best option right now.)

• Patch for the opacity bugs: #37

• Colored shadow patch, of course you may have a better way to implement it: #35 (comment)

• The patch above.