search

chjj / compton

A compositor for X11.
Other
2.25k stars 501 forks source link

Compton's past, present, and yet to come #105

Open chjj opened 11 years ago

chjj commented 11 years ago

I've been planning to make this post for a while.

I feel kind of melancholy about having deserted this project. I haven't had any involvement in a few months. Compton was one of my favorite little things to mess around with. I started this project on a whim because I was extremely annoyed that no decent compisitor existed, and now it's totally ingrained in the linux ecosystem. I didn't think I'd see that. I was just expecting to maintain compton for myself only.

A little while after compton started getting picked up by distros and more widely used, @richardgv showed up and impressed me with his debugging and coding skills. Now he is the primary committer and maintainer of this project. Over time I've slowly paid less attention to compton. I started a new job/career, which meant I ended up becoming more focused on other things. I regret not paying more attention compton. I really love this project, and I really love how people enjoy using it.

@richardgv has done an amazing job - probably better than I ever could have done. This is really his project now. He added more features in the past year than I ever did when I was working on this. He's the man.

@richardgv, I just want to let you know that you have control over this project. I'll try to pay attention and maybe comment from time to time, but your opinion holds more weight than mine at this point. Thank you for all your great work.

richardgv commented 11 years ago

Huh, I don't know what to say... I'm always clumsy when talking about non-technical things. But thanks you for your words, really. :-)

compton has surely being very helpful for me, because it forced me to learn a lot of new things. :-)

Have you looked into #79? Well, 3 months passed and the person who plans to donate has disappeared, though.

Right now compton's development is kinda stalled. I have no idea what I should work on. There are no interesting feature requests. Some bug reports are there but I couldn't reproduce the issue and have lost contact with the bug reporter. Anyway, this is my todo list. Do you any suggestions?

By the way, I will need to find a job very soon as well, I guess.

bwat47 commented 11 years ago

I'd just like to say I really appreciate the work being done on compton. I've always been a fan of lightweight desktops like XFCE and LXDE, but one thing I find to be completely unacceptable is video tearing, and these light desktops have that in spades. I've tried using compiz with them but it always ends up being a rather buggy experience and not integrated as well as I'd like. The other day I discovered that compton now has a GL backend and can properly vsync so I tried it out, and it worked great! XFCE is finally usable for me with intel graphics, butter smooth stable and zero video tearing its so great :) I love that compton doesn't have to take over the window manager or anything either, so I can use my desktop's native window management as its intended and compton can provide me with quick tear free output and some nice elementary effects :)

I hope to see compton keep improving and I appreciate the work!

Xubuntu 13.04 + richard's compton ppa is now my system of choice :)

richardgv commented 11 years ago

@bwat47:

Thanks for your support. I'm glad compton is working well there. :-)

I hope to see compton keep improving and I appreciate the work!

Thanks, but as stated above, I do wish to keep improving but I don't know what to improve... Do you have any suggestions?

Xubuntu 13.04 + richard's compton ppa is now my system of choice :)

Oh, by the way, the PPA is slightly outdated now, missing a few performance related changes... I will bring it up to date after my exam.

nodiscc commented 11 years ago

Just saying thanks too, I have built compton thanks to the debian source package at http://mentors.debian.net/package/compton. It works amazingly and it's blazing fast on decade-old machines. If you keep this debian stuff updated and make sure it gets packaged, this will be a great step forward for lightweight desktops on Debian and child distros (and that's a lot).

The only thing I'd miss is a better doc for the config file (I'm still trying to avoid shadows and transparency on menus)

@chjj @richardgv congrats for your work on this.

richardgv commented 11 years ago

@nodiscc:

If you keep this debian stuff updated and make sure it gets packaged, this will be a great step forward for lightweight desktops on Debian and child distros (and that's a lot).

Well, I don't really know who is managing the Debian package. I will check what I could do about Debian after finishing my exam. The packages in compton PPA or Crunchbang repo might be usable for Debian, though. Gosh, I don't want to install another distro just for packaging compton...

The only thing I'd miss is a better doc for the config file (I'm still trying to avoid shadows and transparency on menus)

Essentially most of the options in a configuration file each have a correspondent commandline switch, and most commandline switches are documented in compton -h or the man page.

The transparency of menu is controlled by the -m/menu-opacity or the wintypes settings in configuration file. Dropping them or use -m 1 should be enough to make menus opaque. -i/inactive-opacity doesn't affect menus by default (unless you use menu = { focus = false; } in the wintypes section of configuration file).

To remove shadow on all menu windows, there are two possible ways. The more efficient one is using the wintypes section in the configuration file.

wintypes:
{
  menu = { shadow = false; }
  dropdown_menu = { shadow = false; }
  popup_menu = { shadow = false; }
}

The less efficient approach is --shadow-exclude 'window_type *= "menu"'.

smlx commented 11 years ago

Well, I don't really know who is managing the Debian package. I will check what I could do about Debian after finishing my exam. The packages in compton PPA or Crunchbang repo might be usable for Debian, though. Gosh, I don't want to install another distro just for packaging compton...

I'm currently packaging compton for Debian, though the package is still lacking sponsorship for uploading to the main archive. Sponsorship is unlikely to happen for at least a few weeks - until after Debian 7 is released. The package at mentors is currently a little behind the current compton git (I'll package the latest version when I get some free time).

It would be very helpful for me if an official release could be tagged, as Debian tends to dislike git snapshots.

richardgv commented 11 years ago

@smlx:

Ah, I see. Thanks. :-) You may wish to wait for a few days before you update your package, since I finally got some free time and I'm planning to add some more fine-tune controls to GLX backend.

Yeah, a tag will be really helpful, but somehow I never got a good chance to create one... The code base is always so unstable.

bwat47 commented 11 years ago

@richardgv Off the top of my head the only improvements I can really think of is improvements to the shadows. Most of my windows have good sized shadows, but It seems certain types of windows/applications get comically huge shadows for some reason, such as the synapse launcher (and I already am using the -C and -G compton options):

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

And of course any continuing performance/vsync improvements to the GL backend :D (although it is already working quite well!, and as you mentioned I'm missing some improvements you've already made until the ppa gets updated :)

jonlap commented 11 years ago

I'm sure I'm not the only ARM board owner who would like to see GLESv2 support in compton. So, thumbs up for that feature, if it ever happens I'll be glad to test it out.

tserhii-gh commented 11 years ago

@bwat47 add: shadow-exclude = ["class_g ?= 'synapse'"] to compton.conf file

nodiscc commented 11 years ago

@bwat47 i use shadow-exclude = [ "n:e:Notification", "g:e:Synapse", "g:e:Conky"]; to fix the synapse problem (and some others).

bwat47 commented 11 years ago

Thanks, I'll give that a shot

richardgv commented 11 years ago

@bwat47:

Off the top of my head the only improvements I can really think of is improvements to the shadows. Most of my windows have good sized shadows, but It seems certain types of windows/applications get comically huge shadows for some reason, such as the synapse launcher (and I already am using the -C and -G compton options):

I remember I've already explained this somewhere... I should write a FAQ entry about this. Anyway:

  1. I'm aware of no compositor that could paint non-rectangular shadow, and this is no exception for compton.
  2. Even if we manage to paint non-rectangular shadow, it would still be literally impossible to detect the shape of the synapse window: It's an ARGB window, and transparency is determined by alpha channel of pixels. It is extremely costly to detect the shape by reading all pixels, and there's no reliable way to detect shape changes of an ARGB windows. Not to mention that as alpha value is not a boolean one but an integer (0-255, usually), how could we determine the shape if semi-transparent pixels are present?
  3. So what we eventually chose is to display a rectangular shadow for all windows, and hope all ARGB windows are mostly rectangular -- indeed, many of them are -- to make this problem unnoticeable. Yet in the case of synapse, I'm afraid you would have to either remove the shadow, using the method funeral1988 and nodisc mentioned, or live with it.

And of course any continuing performance/vsync improvements to the GL backend :D (although it is already working quite well!, and as you mentioned I'm missing some improvements you've already made until the ppa gets updated :)

Are you still suffering from performance/VSync issues? I thought they are gone already. Could you please describe your problem with more details so I could figure out what I could do?

@skry:

I'm sure I'm not the only ARM board owner who would like to see GLESv2 support in compton. So, thumbs up for that feature, if it ever happens I'll be glad to test it out.

compton makes extensive use of OpenGL legacy fixed pipeline functions to ensure maximum support on old graphic cards, while OpenGL ES v2 actually removed some support for them, so porting to OpenGL ES v2 would be tricky, let's say. Considering the relatively small number of users, maybe you shouldn't expect the feature coming any time soon.

bwat47 commented 11 years ago

The only "performance issue" I have at the moment is a slight "delay" when dragging windows. The movement is smooth, but its delayed behind the mouse movement a bit. Its not a big deal and I have the same window moving "delay" with gnome-shell/mutter when using the CLUTTER_PAINT=disable-clipped-redraws:disable-culling workaround (the workaround is necessary for me to have no tearing in gnome-shell with intel graphics, without it I get tearing near the top inch of the screen). Ubuntu's compiz is the only compositor I've used that doesn't give me this delay when moving windows while managing to have no tearing, so if its too tricky to fix I wouldn't expect you to. It doesn't really effect the usability of compton, it just makes window moving feel a bit "floaty", which is more of a cosmetic issue than anything else. I'd take the slight delay over video tearing any day :)

This is the command I use to start compton: compton --backend glx --paint-on-overlay --vsync opengl-swc -cCGb

Other than that performance seems to be spot on, overall its the best performing compositor that I've used on this rather weak graphics chip (intel ironlake), and most importantly it has no tearing :D

richardgv commented 11 years ago

@bwat47:

Sorry for the late reply, firstly.

The only "performance issue" I have at the moment is a slight "delay" when dragging windows. The movement is smooth, but its delayed behind the mouse movement a bit. Its not a big deal and I have the same window moving "delay" with gnome-shell/mutter when using the CLUTTER_PAINT=disable-clipped-redraws:disable-culling workaround (the workaround is necessary for me to have no tearing in gnome-shell with intel graphics, without it I get tearing near the top inch of the screen). Ubuntu's compiz is the only compositor I've used that doesn't give me this delay when moving windows while managing to have no tearing, so if its too tricky to fix I wouldn't expect you to. It doesn't really effect the usability of compton, it just makes window moving feel a bit "floaty", which is more of a cosmetic issue than anything else. I'd take the slight delay over video tearing any day :)

This is the command I use to start compton: compton --backend glx --paint-on-overlay --vsync opengl-swc -cCGb

I've just wrote a Performance Guide on the wiki, which might be worthy to read for you.

Not completely sure what CLUTTER_PAINT=disable-clipped-redraws:disable-culling actually does. Like all GNOME stuffs, clutter's code is full of high-level abstractions just like a maze that prevents me from understanding what it is trying to do...

My wild guess is this has something to do with your VSync. If the VSync isn't actually done properly it could introduce a delay of a frame or two. Could you please try to lift out --vsync opengl-swc and check the FPS using the method described in the performance guide? If the FPS you get is very close to your refresh rate, it could indicate some sort of improper implicit VSync your driver is trying to do.

bwat47 commented 11 years ago

@richardgv Nice guide, I like the work you've been doing on compton's documentation :)

Without the --vsync opengl-swc the delay is gone but there is tearing (as expected). The FPS seems fine when I have --vsync opengl-swc enabled (I haven't actually checked the FPS yet but from using it, it seems consistent and smooth). the only problem is the slight 1-2 frame delay behind the mouse when dragging windows which isn't a big deal.

I'll mess around with some of the settings when I get home from work and see if I can find a more optimal combination of settings.

richardgv commented 11 years ago

@bwat47:

Nice guide, I like the work you've been doing on compton's documentation :)

Thanks! :-) Well, at least it saves me from typing those suggestions again and again. I really can't recall how many times I repeated my suggestions about VSync...

Without the --vsync opengl-swc the delay is gone but there is tearing (as expected). The FPS seems fine when I have --vsync opengl-swc enabled (I haven't actually checked the FPS yet but from using it, it seems consistent and smooth). the only problem is the slight 1-2 frame delay behind the mouse when dragging windows which isn't a big deal. I'll mess around with some of the settings when I get home from work and see if I can find a more optimal combination of settings.

Oh, then my guess is right, VSync is causing the delay. The reason I ask you to test FPS is it normally should be much higher than your refresh rate with VSync in compton disabled. If it is very close to the refresh rate, it could indicate you have some sort of "implicit" driver-level VSync, and I've seen the case where the driver-level VSync doesn't do VSync properly and when it works together with compton's VSync, it causes FPS to fall to around 50 with a 60Hz monitor -- with a ATI card and radeon driver, though. Seemingly the intel driver has some options in xorg.conf that could be related, and DRI options (those you configure with driconf) could affect this as well.

jerri commented 11 years ago

thanks for all the work, guys! Better transparency blur and better configuration for blur would be cool. Right now blur is almost not visible!

richardgv commented 11 years ago

@jerri:

thanks for all the work, guys! Better transparency blur and better configuration for blur would be cool. Right now blur is almost not visible!

Oh, not visible? Well, I feel it pretty visible for me. Anyway, in case you have not noticed, I've explained why we don't have an option to adjust blur strength and possible ways to increase blur strength in #104, specifically in the last paragraph of my reply. Do you find them useful?

jerri commented 11 years ago

@richardgv: Thanks for the hint. Didn't see #104.

The 3x3 blur is nearly unnoticable on my laptop which has a high pixel density. But I see your point about performance-problems. Thanks nevertheless for the fast response and your great work!

richardgv commented 11 years ago

@jerri:

Oh, I see. I just added blur convolution kernel customization to compton, which could be used to create more blurry effects (see my last reply to #104). I have no idea if your graphic card could sustain a 5x5 convolution, though.

madscientist159 commented 10 years ago

I thought you might like to know that a modified version of compton is now being used as the Trinity Desktop Project's default compositor (replacing the old buggy kompmgr application): http://git.trinitydesktop.org/cgit/tdebase/tree/twin/compton-tde

Great job, and I really enjoy the modern GLX compositing (on everything exept my fglrx machine that is)!

richardgv commented 10 years ago

@madscientist159:

That's cool! :-) Utilizing the reg_ignore logic might bring some performance boost to your TRANSPARENT_TO_BLACK/TRANSPARENT_TO_DESKTOP windows, by the way.

And, may I know what is happening on your fglrx box?

madscientist159 commented 10 years ago

Thanks for the tip regarding reg_ignore. I have some other bugs that I need to fix as well, like the shadow offsets (the calculations I brought over from kompmgr are causing shadows to only appear on popup menus); I'll try to add that in when I fix those problems.

On my fglrx box there is a half-second stutter every time I move the mouse from a window to its decorated areas. Granted, it's a mobility 3400 so it's not very powerful, but then again on a machine with even less powerful Intel integrated graphics the glx mode is silky smooth. I'm testing nVidia now; so far no problems noted.

richardgv commented 10 years ago

@madscientist159:

I have some other bugs that I need to fix as well, like the shadow offsets (the calculations I brought over from kompmgr are causing shadows to only appear on popup menus)

Not sure. I used the following patch to make your fork of compton simulate kcompmgr's shadow:

diff --git a/twin/compton-tde/compton.c b/twin/compton-tde/compton.c
index 123703a..c880d4c 100644
--- a/twin/compton-tde/compton.c
+++ b/twin/compton-tde/compton.c
@@ -2926,8 +2926,9 @@ calc_win_size(session_t *ps, win *w) {
  */
 static void
 calc_shadow_geometry(session_t *ps, win *w) {
-  w->shadow_dx = ps->o.shadow_offset_x * w->shadow_size;
-  w->shadow_dy = ps->o.shadow_offset_y * w->shadow_size;
+  static const int shadowRadius = 100;
+  w->shadow_dx = (((- ps->o.shadow_radius * 7 / 5) - ps->o.shadow_offset_x * shadowRadius / 100) * w->shadow_size) / 100;
+  w->shadow_dy = (((- ps->o.shadow_radius * 7 / 5) - ps->o.shadow_offset_y * shadowRadius / 100) * w->shadow_size) / 100;
   w->shadow_width = w->widthb + ps->gaussian_map->size;
   w->shadow_height = w->heightb + ps->gaussian_map->size;
 }
@@ -5904,7 +5905,7 @@ get_cfg(session_t *ps, int argc, char *const *argv, bool first_pass) {

   for (i = 0; i < NUM_WINTYPES; ++i) {
     ps->o.wintype_fade[i] = false;
-    ps->o.wintype_shadow[i] = false;
+    ps->o.wintype_shadow[i] = true;
     ps->o.wintype_opacity[i] = 1.0;
   }

@@ -7086,8 +7087,8 @@ session_init(session_t *ps_old, int argc, char **argv) {
       .shadow_green = 0.0,
       .shadow_blue = 0.0,
       .shadow_radius = 12,
-      .shadow_offset_x = -15,
-      .shadow_offset_y = -15,
+      .shadow_offset_x = 0,
+      .shadow_offset_y = 0,
       .shadow_opacity = .75,
       .clear_shadow = false,
       .shadow_blacklist = NULL,

On my fglrx box there is a half-second stutter every time I move the mouse from a window to its decorated areas. Granted, it's a mobility 3400 so it's not very powerful, but then again on a machine with even less powerful Intel integrated graphics the glx mode is silky smooth. I'm testing nVidia now; so far no problems noted.

  1. What is repainted on the screen when you move the mouse to window frame? I suppose that actually shouldn't trigger a redraw. Could you please record a screencast and show us the situation?
  2. Does it look like a performance/global-synchorization issue (e.g. when compton stops updating other windows when the stutter occurs) or compton just fails to update the problematic window itself?
  3. Do the performance optimization options help? Like --glx-no-stencil, --glx-swap-method, --glx-no-rebind-pixmap, etc.
  4. Does disabling VSync in your driver and compton help?
  5. Do you see high CPU usage when it occurs?
  6. Does xr-glx-hybrid backend work?
madscientist159 commented 9 years ago

@richardgv

Sorry for the very long delay in response; my attention was on other more critical TDE bugs but I have now come back to compton-tde as we are now very close to the next major release of TDE.

Thank you for the shadow patch; it has been tested and incorporated into our branch. Unfortunately the fglrx behaviour is still a major problem; I just tested it on a more powerful desktop ATI machine and Xorg itself crashed as soon as I fired up compton. I will be trying again with the ATI laptop I was previously testing on to gather the requested information as soon as I have more time.

Should all of these ATI problems be filed in a new bug report instead of cluttering up this one?

Thanks!

madscientist159 commented 9 years ago

Just tested on the same Mobility ATI laptop but with an upgraded Compton and fglrx drivers. No issues noted thus far; I'm going to guess the fglrx driver update fixed the issues as I had been noticing sluggish behaviour on the original fglrx drivers in Steam on my desktop.

Is there any way to provide useful information to you regarding the Xorg crash on the desktop fglrx machine?

richardgv commented 9 years ago

@madscientist159:

Sorry for the late reply.

Is there any way to provide useful information to you regarding the Xorg crash on the desktop fglrx machine?

If you couldn't reproduce the issue with updated fglrx, I guess we don't really need to deal with the crash, do we?

Should it still be a problem, a backtrace of X (with proper debugging symbols and indication of the version of the packages so I could look up the sources) might help. But it quite likely that I won't be able to solve it.

By the way, I have some questions regarding the changes you made to compton-tde:

  1. Regarding a3a88afd2e65e34fb3aa9a0f4095a03894f6c327:

    diff --git a/twin/compton-tde/compton.c b/twin/compton-tde/compton.c
index 74302da..dedbfdd 100644
--- a/twin/compton-tde/compton.c
+++ b/twin/compton-tde/compton.c
@@ -2406,6 +2413,10 @@ map_win(session_t *ps, Window id) {
  w->in_openclose = true;
  set_fade_callback(ps, w, finish_map_win, true);
  win_determine_fade(ps, w);
+  if (w->fade) {
+    // Make sure the new window fades in properly
+    w->opacity = 0;
+  }

  win_determine_blur_background(ps, w);

    The change will suddenly decrease the opacity of a window to 0 if it is mapped again when it is fading out. w->opacity is set to 0 in add_win() for new windows, already. Why doing this?

  2. Regarding a582c6e22dc2ca97d3589b2459aba83aaf95ed0d: Just out of curiosity, why would you need to desaturate the background of semi-transparent windows?
madscientist159 commented 9 years ago

@richardgv

Sorry I wasn't clear earlier; my laptop (ATI mobility radeon) now works fine but my desktop (ATI desktop radeon) crashes Xorg as soon as compton is run. I can try to geneate a full Xorg backtrace assuming I can find time.

Regarding the changes...

1.) Compton was not fading in any windows, but was fading all of them out perfectly fine. I don't remember the specifics at this point but it boiled down to the current opacity of newly mapped windows being set to 100% therefore the fading code was not running. This was on my Intel test system.

EDIT: Come to think of it with the above description I think I know why this was happening. The TDE window manager controls window opacity via the opacity atom; I suspect this was overriding the "default" 0 opacity to 100% before the window was mapped causing the glitch. If our window manager does this it's possible other (potentially obscure) transparency-aware window managers could do the same thing. I'm not convinced at all that our WM is doing anything wrong; it just looks like a bad interaction.

2.) It's a new feature. I missed the old fake-transparency option of converting the terminal background to greyscale (as well as the old Compiz greyscale window option) so I thought I'd add it back in. It accentuates the terminal contents while still showing the background windows, and it's less resource intensive than blur for a similar terminal contents to background visual contrast level.

I also have some plans to use it in the logout dialog as an additional visual indicator that the session is about to be terminated/suspended.

richardgv commented 9 years ago

@madscientist159:

Sorry I wasn't clear earlier; my laptop (ATI mobility radeon) now works fine but my desktop (ATI desktop radeon) crashes Xorg as soon as compton is run. I can try to geneate a full Xorg backtrace assuming I can find time.

Oops, sorry, I didn't read your reply carefully. This is embarrassing...

1.) Compton was not fading in any windows, but was fading all of them out perfectly fine. I don't remember the specifics at this point but it boiled down to the current opacity of newly mapped windows being set to 100% therefore the fading code was not running. This was on my Intel test system.

EDIT: Come to think of it with the above description I think I know why this was happening. The TDE window manager controls window opacity via the opacity atom; I suspect this was overriding the "default" 0 opacity to 100% before the window was mapped causing the glitch. If our window manager does this it's possible other (potentially obscure) transparency-aware window managers could do the same thing. I'm not convinced at all that our WM is doing anything wrong; it just looks like a bad interaction.

The real issue is you used w->opacity instead of w->opacity_tgt in map_win(), in fbd3a27d6e0998f6052e93ce60f68c5261b38d2d. This is the simple fix:

diff --git a/twin/compton-tde/compton.c b/twin/compton-tde/compton.c
index 74302da..8b42209 100644
--- a/twin/compton-tde/compton.c
+++ b/twin/compton-tde/compton.c
@@ -2357,7 +2357,7 @@ map_win(session_t *ps, Window id) {
   XFlush(ps->dpy);

   /* This needs to be here since we don't get PropertyNotify when unmapped */
-  w->opacity = wid_get_opacity_prop(ps, w->id, OPAQUE);
+  w->opacity_tgt = wid_get_opacity_prop(ps, w->id, OPAQUE);
   w->show_root_tile = determine_window_transparent_to_desktop(ps, id);
   w->show_black_background = determine_window_transparent_to_black(ps, id);

And this is the good fix:

diff --git a/twin/compton-tde/compton.c b/twin/compton-tde/compton.c
index 74302da..c022b96 100644
--- a/twin/compton-tde/compton.c
+++ b/twin/compton-tde/compton.c
@@ -2357,7 +2357,7 @@ map_win(session_t *ps, Window id) {
   XFlush(ps->dpy);

   /* This needs to be here since we don't get PropertyNotify when unmapped */
-  w->opacity = wid_get_opacity_prop(ps, w->id, OPAQUE);
+  calc_opacity(ps, w);
   w->show_root_tile = determine_window_transparent_to_desktop(ps, id);
   w->show_black_background = determine_window_transparent_to_black(ps, id);

So my proposed patch is:

diff --git a/twin/compton-tde/compton.c b/twin/compton-tde/compton.c
index e9097a7..190d923 100644
--- a/twin/compton-tde/compton.c
+++ b/twin/compton-tde/compton.c
@@ -2440,7 +2440,7 @@ map_win(session_t *ps, Window id) {
   XFlush(ps->dpy);

   /* This needs to be here since we don't get PropertyNotify when unmapped */
-  w->opacity = wid_get_opacity_prop(ps, w->id, OPAQUE);
+  calc_opacity(ps, w);
   w->show_root_tile = determine_window_transparent_to_desktop(ps, id);
   w->show_black_background = determine_window_transparent_to_black(ps, id);

@@ -2489,10 +2489,6 @@ map_win(session_t *ps, Window id) {
   w->in_openclose = true;
   set_fade_callback(ps, w, finish_map_win, true);
   win_determine_fade(ps, w);
-  if (w->fade) {
-    // Make sure the new window fades in properly
-    w->opacity = 0;
-  }

   win_determine_blur_background(ps, w);
   win_determine_greyscale_background(ps, w);

2.) It's a new feature. I missed the old fake-transparency option of converting the terminal background to greyscale (as well as the old Compiz greyscale window option) so I thought I'd add it back in. It accentuates the terminal contents while still showing the background windows, and it's less resource intensive than blur for a similar terminal contents to background visual contrast level.

I also have some plans to use it in the logout dialog as an additional visual indicator that the session is about to be terminated/suspended.

I see, although in my opinion, blur is less distracting in the case.

And by the way, there's one really really really bad thing in your code:

compton.c:3088:81: warning: incompatible pointer to integer conversion passing 'win *'
      (aka 'struct _win *') to parameter of type 'Window' (aka 'unsigned long') [-Wint-conversion]
  bool greyscale_background_new = (get_window_transparency_filter_greyscale(ps, w) ||
madscientist159 commented 9 years ago

Thanks for the code review; I appreciate it!

There were so many warnings generated on compilation that I completely missed the win pointer to Window parameter passage; thanks for the heads up. Normally I'd get in there and clean the compiler warnings up but I am hesitant to do so in the compton-tde fork as this will make future merges even harder than before. If I cleaned up the warnings in a stock compton repository and submitted a patch would that be helpful?

I have completely revamped the greyscale code to use GLSL; this allowed me to implement the second part of my idea which was to add a rudimentary color/gresycale background blend filter as opposed to the normal mode of operation (blend window with background). This modification is now in use in TDE's logout dialogs and, as with the old non-composited version, I like the effect better than a blur (this is personal preference I know). In any case if you want to incorporate any of this code into compton please feel free.

I would like to see Compton gain desktop cube functionality at some point; I don't know if this is already planned or even desired but I have been learning more about OpenGL (slowly) and wouldn't mind taking a crack at it sometime. I assume it's mostly a matter of mapping the various override redirect windows (one for each desktop) onto a cube primitive but haven't looked into any of the details yet. :-)

EDIT: The suggested fix works; I'll commit in the next merge window. Thanks again for catching that mistake!

richardgv commented 9 years ago

Thanks for the code review; I appreciate it!

You are welcome. :-)

There were so many warnings generated on compilation that I completely missed the win pointer to Window parameter passage; thanks for the heads up. Normally I'd get in there and clean the compiler warnings up but I am hesitant to do so in the compton-tde fork as this will make future merges even harder than before. If I cleaned up the warnings in a stock compton repository and submitted a patch would that be helpful?

I'm personally pretty conservative about clearing warnings unless they really make sense. We have like 10 warnings right now (when compiled with gcc-4.8.3 and default configuration), 7 of them are about unused variable/functions that are useful for debugging -- so instead of writing a lot of #ifdef which increases the chance of making mistakes with them in the future, I ignored them -- and 3 are about the unhandled NUM_BKEND enumeration value -- which shouldn't be handled, anyway, and handling it generates extra instructions. Generally I just review the list of warnings thrown by clang with CFG_DEV=1, which is a lot less noisy than the gcc one, before I commit.

So, I'm inclined to not to suppress the existing warnings until the amount of harmless warnings grows to an unmanageable number. If you hate the amount of warnings, try clang with CFG_DEV=1.

I have completely revamped the greyscale code to use GLSL; this allowed me to implement the second part of my idea which was to add a rudimentary color/gresycale background blend filter as opposed to the normal mode of operation (blend window with background). This modification is now in use in TDE's logout dialogs and, as with the old non-composited version, I like the effect better than a blur (this is personal preference I know). In any case if you want to incorporate any of this code into compton please feel free.

Thanks! :-)

I would like to see Compton gain desktop cube functionality at some point; I don't know if this is already planned or even desired but I have been learning more about OpenGL (slowly) and wouldn't mind taking a crack at it sometime.

compton is intend to be a lightweight standalone compositor. I don't implement and integrate features with the crazy pace of ffmpeg developers. And I try to stay away from what the WM should take care of, which guarantees maximum compatibility with all those WMs that does all sorts of weird and stupid things. :-D Desktop cube is fancy, but I'm not interested. It might worth implementing this in compton-tde since it only serves to one WM, though.

I assume it's mostly a matter of mapping the various override redirect windows (one for each desktop) onto a cube primitive but haven't looked into any of the details yet. :-)

Probably more complicated than that. There's no "one window for each desktop" thing, normally. I guess caching the composited image of the contents of each virtual desktop is the easiest route?

EDIT: The suggested fix works; I'll commit in the next merge window. Thanks again for catching that mistake!

Cool. :-)