Feature: Blur #69

Closed
Janhouse opened this Issue Dec 13, 2012 · 17 comments

5 participants

@Janhouse

Could someone implement window background blur for transparent windows?

@richardgv richardgv added a commit that referenced this issue Dec 14, 2012
@richardgv richardgv Feature #69: Blur window background
- Add window background blur support (--blur-background &
  --blur-background-frame), with X Render convolution filter.
  The performance sucks. The performance when the window is opaque but
  frame is transparent could be improved, but there are two possible
  ways and I'm hesitating.

- Known issue: The blurring effect looks very ungraceful during fading.
  I could partially fix the problem, but it probably isn't easy to fix
  it completely.
22cabf7
@richardgv
Collaborator

Allllllllllright... Your wish is granted, although imperfectly. Sorry for the delay. My dad again went home, and he again started monitoring me 24x7, so my time is tight...

Anyway, please clone from richardgv-dev and test --blur-background and --blur-background-frame. Note it looks bad during fading, and its performance, well, sucks pretty much, just like all other possible blurring algorithms. It uses the convolution filter in X Render, which I hope is present in recent Xorg versions (gaussian and binomial filters are better, but I don't see them on my Xorg). A warning message would be printed out if compton could not find the filter on your X.

Also, don't try it on Xephyr. Looks like the convolution filter doesn't work well there.

@Janhouse
@Janhouse

Well, it blurs something but the UI becomes unusable. Like 1 frame every 10 seconds. 🐺

@richardgv
Collaborator

Huh...

  1. In theory, I estimate blurring increases painting load on CPU for 1000% (could be a lot more smaller depending on the implementation of convolution filter in X Render, oh, and CPU registers, instruction optimization, SIMD, current weather, etc. :-D ), if almost all your windows are transparent; in the same case, I believe the load on GPU could increase by 200% (or more, if the convolution calculation is done on GPU).

  2. In practice, I found no very significant increase on CPU load with my Core i7 3770K. I didn't notice any performance level increase in nvidia-settings when constantly repainting an area with blur enabled, either, with nVidia GTX 670. And it does not affect the FPS of glxgears here. (I heard nVidia binary blob OpenGL does not report DamageNotify correctly for performance, though.)

  3. I'm afraid you cannot enable blurring on your "Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)", after all. The performance of X Render convolution is unfortunately possibly quite distant from the performance of OpenGL, and there's nothing I could do. I wasn't expecting the speed of 1 frame every 10 seconds, though.

  4. Anyway, I pushed another commit to richardgv-dev, which may have a positive or negative or no effect on the performance. I hope you could at least test that one.

  5. Is the CPU usage 100% with blurring enabled?

@Janhouse
@richardgv
Collaborator

Can't OpenGL be used? Bluring in Compiz works perfectly (but I guess Compiz works in a different way).

You think "Can't OpenGL be used?" is just a matter of a single sentence, Janhouse? Porting it to OpenGL basically means at least 70% of the code has to be rewritten (or 5,000+ lines). Compton has a single active developer as of now, and my knowledge on programming is extremely limited that I have to ask Google at a incredible frequency. Even porting to XCB (just an alternative set of X bindings) looks like mission impossible. And I don't know whether this will make compton super-bloated. Oh, if I work on compton as a job and somebody pays for my lunch, or if chjj comes back to work actively here, this would be possible. But right now... Sorry, you'd better not to expect it.

There are enough OpenGL compositing window managers already, I guess? If what you love is OpenGL, you should use Compiz, or at least, cairo-compmgr. Compiz provides a great wheel already, and we don't really have interest in reinventing that, even if it's possible.

@richardgv richardgv closed this Jan 8, 2013
@richardgv richardgv referenced this issue Feb 14, 2013
Open

Motion Blur #87

@richardgv richardgv added a commit that referenced this issue Mar 20, 2013
@richardgv richardgv Feature #69: GLX: Blur background
- GLX backend: Add blur background support using a GLSL shader. Only
  tested with nvidia-drivers-313.26. Known to cause quite some decrease
  in performance (~10%?).

- Detach shaders in glx_create_program(). Misc changes.
8208ec6
@richardgv
Collaborator

Firstly, I'm truly sorry for appearing rude in the last reply, 3 months ago. I'm a extremely moody person.

Could you please test if the blur background feature in GLX backend (8208ec6, richardgv-dev) works better for you? I use GLSL 1.1 for maximum compatibility, but it still isn't going to be as portable as ARB assembly language, which Compiz uses for blurring. As for performance, I see a 10% decrease in performance in my tests, but I do not know what will happen on your side.

@Janhouse

Hey, this is cool! :)
Performance is really good compared to the last time.

I'm using it like this:
./compton --opengl --sw-opti --vsync opengl-swc --paint-on-overlay -cCGb -r 10 -o 0.5 -l-12 -t-12 -fF -D35 -I0.4 -O0.4 --blur-background

P.S. No need to apologize, I don't get offended so easily. :)

@LauCham

Hi,
Very nice options. Also, we can add it on the file "compton.conf" by adding the lines:
blur-background=true;
blur-background-frame=true;

But, opposite to the shadow, we can't exclude some windows.
Per example, I try the option "blur-exclude" on the same idea of "shadow-exclude" but it didn't work.
Maybe, it could be interesting to add it.

This was referenced Mar 23, 2013
@avDuma

Hi all!
Thank you for whis wonderful composite, I've used Compiz for years and now that I've discovered Compton I say: "Oh Man, how much time have you wasted with Compiz?!". It's incredible light and speed and it works like a charm with XFCE.

I've tried the blur-background option and I've found amazing, but I can't set a gaussian kernel with --blur-kern option.
If I set any kernel with a decimal value (e.g.: '3,3,0,0.1,...') I get the following error:

[albi@albi-desktop ~]$ compton --config ~/.compton.conf --blur-kern '3,3,0.1,1,1,1,1,1,1,1'
glx_create_shader(): Failed to compile shader with type 35632: 0(10) : error C0128: invalid digit '9' in octal constant
0(10) : error C1068: too much data in type constructor
0(19) : error C0128: invalid digit '9' in octal constant
0(19) : error C1068: too much data in type constructor

The kernel it is just a test, if I set a decimal value i get the glx error... any clue?

@richardgv
Collaborator

@avDuma:

I'm able to reproduce your issue with locale pl_PL.UTF-8 (which uses comma as decimal point) and a build of 5da8026, so I assume it's the locale issue in #143. Upgrade your compton to the latest version on git master or richardgv-dev branch should fix it. And you could use a more "normal" locale (en_US.UTF-8) when launching compton, as a workaround, if it's not possible to upgrade.

If you believe the problem is not related to locale, you may build compton with CPPFLAGS='-DDEBUG_GLX_GLSL' to display the problematic GLSL code.

By the way, we have a few predefined Gaussian kernels that could be used with --blur-kern: 3x3gaussian, 5x5gaussian, 7x7gaussian, 9x9gaussian, 11x11gaussian . See compton -h or the man page for more details. Compton comes with a blur kernel generator (./bin/compton-convgen.py), if you want more control.

Thank you for whis wonderful composite, I've used Compiz for years and now that I've discovered Compton I say: "Oh Man, how much time have you wasted with Compiz?!".

Compiz is still a lot more feature-complete. We are just going along different routes.

@avDuma

Thank you for your reply.
I've tried with gaussian blur-kern option as you suggested me, but the issue is the same.
I've installed compton with the AUR package compton on Arch ( https://aur.archlinux.org/packages/compton/ ). There's also available a compton-git package ( https://aur.archlinux.org/packages/compton-git/ ):but compton-git seems older than compton package.

How can I launch compton with english locale, so I can see if is a locale issues without reinstalling the composite?

@richardgv
Collaborator

@avDuma:

The version number of compton-git in AUR is incorrect. It always pulls the latest version from master branch.

To change environment variable for an application in shell, use LANG=en_US.UTF-8 compton. In other cases where this is not possible (e.g. menu entry), you may use env LANG=en_US.UTF-8 compton. Make sure you have the new locale in your system. On Gentoo you typically edit /etc/locale.gen to add the locale and run locale-gen, not sure about Arch, but most likely it's not needed.

@avDuma

Ok, guess what? As you have said, IT IS the locale issue. I suppose I'll launch it with the english locale at the startup.
I haven't understood if it is more stable and/or update the compton-git package (that download the git://github.com/chjj/compton.git ) or the compton package (that download compton from the archive https://github.com/chjj/compton/archive/v0.1_beta1.tar.gz ).

Thank you for the quick and exaustive answer, anyway ;)

@WorMzy

@avDuma:

Although it looks newer, the compton package in the AUR builds using the two month old release tarball. It's there for people who don't need/want the cutting edge -git package, but still want a damn fine compositor. I'm hoping it will get enough attention, and be proved stable enough to warrant a Trusted User adopting it and moving it to community, where it will be available as a binary package, installable via pacman (for those who don't want to deal with the AUR at all). Heck, it may even be picked up by a dev and moved to extra, replacing the old and crusty xcompmgr. ;)

If you need a feature in the git repo, use the -git PKGBUILD.

@richardgv
Collaborator

@avDuma:

WorMzy has kindly answers most of your questions, I hope. To have more users using a bleeding-edge version is certainly beneficial for us, but whether it's good for you... Please decide it yourself. By installing from the git repo (and constantly check for updates), you get the latest bugs as well as the latest bug fixes. With the stable version you get no new bugs but no bug fixes either.

@WorMzy:

Thanks for helping! :-)

I'm hoping it will get enough attention, and be proved stable enough to warrant a Trusted User adopting it and moving it to community, where it will be available as a binary package, installable via pacman (for those who don't want to deal with the AUR at all). Heck, it may even be picked up by a dev and moved to extra, replacing the old and crusty xcompmgr. ;)

The core feature set of compton has been frozen since almost half a year ago, and I still see bursts and bursts of bug reports. No idea when compton will actually go stable. Well, maybe at the moment Wayland dominates the Unix world, like what X does now. :-D

@avDuma

@richardgv @WorMzy Thank you for your kind and complete answer.
I will stay with the stable version and hope soon will be moved to community repo.
I suppose I will write about this great composite on my Linux Italian Blog soon: it is not much, but it is something I can do for this great project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment