Hi, I've noticed a slow down in XFCE development. Maybe it's time to get rid of hard to maintain components, and I feel like xfwm4's compositing manager is one of those. It uses xrender and is horribly outdated, has bad performance, cannot use OpenGL... Compton (https://github.com/chjj/compton) is a very well maintained composite manager. It supports a GL backend and many other nice features. It's also very lightweight on resources. What about making compton an optional dependency for xfwm4 and use this for compositing? Then you could ditch the code for composite management and forget about it.
I support this idea and it is actually part of my XFCE set-up routine these days. Compton would suit XFCE great: it gets rid of tearing due to proper OpenGL backend and runs really fast on low-performance machines too. Here's a nice guide for Ubuntu folks if they want to try it out: http://ubuntuforums.org/showthread.php?t=2144468
What you need to xfwm4 was rewritten and got rid of this ancient?
I also support this idea c Compton, but how to implement it in a future release of Xfce. Have any options. What generally done in this direction?
Can create a new bug report on the Xfce 4 .10.1 or 4.12? It makes sense to hold discussions, if there is no progress in this topic?
Bug still exists in Xfce 4.10, confirms.
Compton is a standalone compositor manager, nothing stops you from using it as it is now with xfwm4, I don't see the point of this bug. You don't need to remove the existing embedded compositor to use Compton. As for the Xrender compositor being slow, it's just your opinion, other may disagree (depending on HW and software support of Open GL) If anything, it belongs to a page in the wiki, not in a bugzilla.
Thanks for the tour, but with a limit tear-free compositing manifested not the same machine)). Bug on launchpad - https://bugs.launchpad.net/ubuntu/+source/xfwm4/+bug/1294600
confirms bug on xfce 4.11.4 on Ubuntu 14.04 trusty
> Compton is a standalone compositor manager, nothing stops you from using it as it is now with xfwm4, I don't see the point of this bug. Compton is very fast (whether you use the Xrender or OpenGL backend), stable, conservative about new features, well maintained and the developers are very responsive. This bug is about replacing the compositor in xfwm4 with compton - as you said it's perfectly ok to use compton in standalone mode with xfwm, but it requires tweaking. Using compton as the default compositor in XFCE would provide better performance as the default (>90% of XFCE users). I've tried both compositors with different backends on low and high-end machines, and compton always performed better regarding CPU and RAM usage. This would also alleviate the need to maintain the old xfwm compositor, freeing some time for the XFCE team. Win-win. I think the compton devs would be glad to help integrating their work in XFCE. Olivier, what do you think?
(In reply to nodiscc from comment #9) > > Compton is a standalone compositor manager, nothing stops you from using it as it is now with xfwm4, I don't see the point of this bug. > > Compton is very fast (whether you use the Xrender or OpenGL backend), > stable, conservative about new features, well maintained and the developers > are very responsive. This bug is about replacing the compositor in xfwm4 > with compton(...) > > Olivier, what do you think? Again, you're confusing things, Compton is a standalone compositing manager, xfwm4 is a window manager *and* a compositing manager, you cannot replace the compositor in xfwm4 with Compton. What you /could/ do is rewrite the compositor in xfwm4 using OpenGL or even take example on Compton code to rewrite xfwm4 embedded compositor. But if you just want to use Compton with xfwm4, it's already doable and trivial, no need for a bug for that, at best a mention in the wiki/how to would suffice, thus my comment 6.
Note, choosing components is the prerogative of the distro maintainers, not our role upstream, i.e. we maintain code, they choose the packages. In other words, we cannot depend or force users on using Compton, but distro can prefer to use it and ship it as a dependency on Xfce, and set up the desktop accordingly.
Thanks for the reply. For what it's worth, I have set up my desktop to use compton by adding ~/.config/autostart/compton.desktop, and disabling xfwm4's composite manager (pretty sure there's a command line to do this). $ cat ~/.config/autostart/compton.desktop [Desktop Entry] Type=Application Name=Compton Name[fr]=Compton Comment=Enable transparency effects Comment[fr]=Activer les effets de transparence Icon=display Tryexec=compton Exec=compton StartupNotify=true Terminal=false Categories=System NoDisplay=false Hidden=true $ cat ~/.config/compton.conf #backend = "glx"; #disabled by default, buggy on some drivers, see https://github.com/chjj/compton/issues/151 # Shadow shadow = true; no-dnd-shadow = true; no-dock-shadow = true; #clear-shadow = true; shadow-radius = 6 shadow-offset-x = -8 shadow-offset-y = -8 shadow-opacity = 0.6 #shadow-red = 0.0 #shadow-green = 0.0 #shadow-blue = 0.0 shadow-exclude = [ "n:e:Notification", "n:e:Menu" , "g:e:Synapse", "g:e:Conky"]; #shadow-exclude = "n:e:Notification"; # Opacity menu-opacity = 1.0; #inactive-opacity = 0.9; #frame-opacity = 0.7; inactive-opacity-override = true; # Fading fading = true; fade-delta = 10 fade-in-step = 0.08 fade-out-step = 0.08 # no-fading-openclose = true; # Other mark-wmwin-focused = true; # Window type settings wintypes: { tooltip = { fade = false; shadow = false; opacity = 0.90; }; } Using the compton codebase to rewrite the compositing manager in xfwm4 may be a good idea for the future though. This workaround is ok for me, I'll just close this bug. Thanks again