What is Reddit's opinion of
Compton?
From 3.5 billion Reddit comments
➔ Compton website
By popularity on Reddit, this Service is:
96 reviews of this app found across Reddit:
You could give Compton a shot. Just use a DE that let's you turn off its own compositor, e.g. Xfce does. Then use Compton's --backend glx option in conjunction with --refresh-rate 144. Lastly, try the different --vsync options (see documentation). Just play around with the configuration options, maybe there's a combination that works for you.
I had the same issue after upgrading to Meas 18.0. The problem for me was the compositor. It can be fixed by adding this to your environment variables.
allow_rgb10_configs=false
Or, if you are using Compton as your compositor you can edit ~/.config/compton.conf and change the backend from glx to xr_glx_hybrid.
I found the answer here: Mesa 18.0.0: GLX backend broken
Are you running Compton? There's a workaround for it on the Arch wiki page for Compton. On mobile now but will find the link for you later.
Edit: Looked up my config. What worked for me is to add "_GTK_FRAME_EXTENTS@:c" to shadow-exclude in my compton.conf. Source: https://github.com/chjj/compton/issues/189
Xorg tears a lot. I don't know enough of the technical side of it to explain why, but it does. Wayland was created to address the (many, many) shortcomings of Xorg, one of the things it fixes is screen tearing.
One thing I would suggest to help with tearing is Compton. It's a compositor for Xorg that fixes the tearing problem. Use http://duncanlock.net/blog/2013/06/07/how-to-switch-to-compton-for-beautiful-tear-free-compositing-in-xfce/ configuration and you should be good to go!
xfwm has a built-in compositor. All it does is basic compositing and a drop shadow (no fading effects or any extra flash), but it's pretty nice. I personally use fvwm with xcompmgr-dana. That said, I just found compton, which I've provided a github link to, which claims to be a xcompmgr maintenance project, which might be decent.
From the compton wiki in the section about the --benchmark option:
> Usually we measure performance of compton’s GLX backend with --benchmark, which forces compton to repeatedly repaint for specified times then exit
Emphasis mine. So, that parameter explains why compton is exiting for you. The benchmark you told it to run is done, so it exists. I don't think it's crashing, but to confirm you can run it from console after starting i3 and observe the output (use your command you have in i3/config but remove the & at the end)
Read that perf page I linked to in my previous comment.. seriously. It discusses the various backends, and discusses tweaks you can try to improve performance. Keep in mind that some of the most aggressive performance tweaks can/will impact stability, and some of them may not even work with the GPU/drivers you are using.
Speaking of which, what GPU and drivers are you using?
compton will get you a fade in/out when you switch desktops - try:
compton -f
I've not used it in depth, so I don't know what else it can do - but it does have a lot of options to play with...
I'm really happy with two new additions to my desktop: compton and dunst.
Compton is a compositor, which is much cleaner and bug-free than any other xcompmgr forks in my humble opinion.
dunst is a notification daemon that fits in well with a tiled window WM, is nice and light, and doesn't steal focus light xfce's notification daemon does. It also handles notification spamming really well, and you can dismiss notifications with a keyboard shortcut. Really happy with this one!
There is an issue: https://github.com/chjj/compton/issues/477, there seems to be a workaround.
> I didn't really investigate any further yet, just disabled compton for the moment.
I think killing compton is/should be the de facto first response on any visual glitch.
XFCE is known to have awful tearing with Nvidia cards. You have to install Nvidia propetary driver, then try this http://www.thelinuxrain.com/articles/got-tearing-with-proprietary-nvidia-try-this .
If that doesn't work you have to install Compton and modify the config file, also you'll have to disable XFCE default compositor. https://github.com/chjj/compton/wiki/vsync-guide
You wont really find luck with true transparency in i3. See here: https://github.com/chjj/compton/wiki/faq#3-why-does-transparency-not-work-correctly-in-i3
What works great for me is native transparency. When using native transparency not the composition manager but the terminal makes itself look semi transparent by using your background image as it's own background. This looks a bit strange when you have such a window floating but it actually has the benefit that in stacking or tabbed mode you don't see the text of all the terminals under the active terminal.
You can configure native transparency for urxvt in your ~/.Xresources like this:
URxvt.transparent: true URxvt.shading:20
! Included this so you know how to make your foreground not match the color of your background URxvt.foreground: #eeeeee
Shading is a value between 0 and 200 where 0 is completely black, 100 completely transparent and 200 completely white.
Of cause you then have to apply that settings at start in your ~/.xinitrc by using
xrdb ~/.Xresources
There may be ways to do this in other terminal emulators as well, but unfortunately I don't know those. If you don't use urxvt yet, you might want to give it a try. Start here: https://wiki.archlinux.org/index.php/Rxvt-unicode
edit: language
You should try Compton (https://github.com/chjj/compton). It's a new composite manager forked from Dana Jansen's version of Xcompmgr. I have been testing this recently and it is much more stable and consistent then Cairo-compmgr and Xcompmgr. Great for Openbox! More info here: http://crunchbanglinux.org/forums/topic/15949/new-composite-manager-compton/
For me, I just set URxvt.background to an RGB and did the transparency stuff in compton.conf. I assume you might have something like
active-opacity = 0.7; inactive-opacity = 0.7; frame-opacity = 0.7;
If you wanted opaque to be the default you could set those values to 1.0 and then add this
opacity-rule = [ "70:class_g = 'Scratchpad'" ]; where the 70 corresponds to 70 percent. Per the doc it might be better to use compton-trans however.
This sounds to me like you don't have a compositor running/ your compositor isn't compatible with flashfocus. If you don't have one installed, I recommend compton.
If that's not the issue could you redirect flashfocus' stderr to a logfile and send it my way (flashfocus 2> flash.log should work).
My polybar dotfiles are here. Full disclosure, I ripped them off from a post on here, wish I could remember who so I could give them credit. Ignore the README for the gmail module, I edited the script a bunch so its no longer accurate.
Ubuntu already started using the 'modesetting' DDX in favor or the 'intel' DDX since version 16.10
So, there shouldn't be any requirement for you to play around with the drivers.
Just make sure that you don't put any Xorg configuration /etc/X11 that manually re-enables the intel DDX.
You didn't mention which compositor you are using when you enable vsync.
In case you are using compton, you could try out the different vsync methods in compton and see if any of them works better.
Is it this?
https://github.com/chjj/compton/issues/152
I don't use compton myself as I don't need transparency. The system is a lot smoother for that decision and Intel SNA tearfree solves my video tearing issues :)
It may have to do with drivers. Also try this config for Compton (and use Compton if you don't, it's a good compositor). Also according to this:
> First of all, compton cannot do VSync better > than your driver could. For vesa and other > pure-software or broken drivers, or when you > turned off the hardware acceleration in your > driver, you shouldn’t expect much about > VSync.
Then you did something wrong. Both that option or a proper compositor with VSync would negate tearing.
The nouveau is basically useless for anything so unless you have no choice, there's no reason to use it.
Check out this thread on how to properly use the option - https://github.com/chjj/compton/issues/227
You might be interested in taking a look at this.
I myself personally haven't ran into video tearing, but maybe that's because I use a Chromebook, so the drivers are good. compton's page on vsync does say it can't do vsync better than your driver could.
The problem is that kwin uses vsync by default and it's possible that your framerate would be locked to 60 then.
If you are on NVIDIA, it is possible to disable vsync in kwin without getting tearing:
https://github.com/chjj/compton/issues/227
make sure to back up your xorg.conf before making any changes:
cp /etc/X11/xorg.conf ~
This should also eliminate any tearing in games without any performance-cost. If your screen is locked at 60 again, make sure your monitor is set to 144 Hz in the nvidia-settings.
edit:
to disable vsync in kwin, go to System Settings>Display and Monitors>Compositor and set "Tearing prevention" to "Never" and apply.
There are some compton builds available in COPR. I haven't tried them but I would try out one of those repos and see if they fit your needs. You can use dnf to interact with COPR repositories.
The tarballs provided from the Arch packages / AUR aren't tarballs for the actual application. They are tarballs containing PKGBUILDS and any other files the PKGBUILD requires. The PKGBUILD is a file describing how Arch's package management tools should build and package an application. So no, those tarballs won't be of any use to you on Fedora.
If you want to build compton yourself, you'll need to pull the sources from GitHub then follow the included build instructions. Before doing this though I'd recommend trying to use one of the compton builds available from COPR so that the package manager is aware of what you install and can manage it for you.
>transparency without the use of a composite manager
Sorry, but you need a composite manager to do anything with transparency. Compton is quite nice and lightweight.
>file manager that can support native widget transparency
What does this even mean? What kind of widget do you want from a file manager?
This would be the job of a compositor rather than dwm itself. Picom and compton both have active issues requesting a zoom feature. Maybe you'll find another compositor which already comes with that feature.
>The same hardware runs FO4 flawlessly on High graphics in Windows.
One thing that I discovered that clobbered FO4 performance was running with a compositor. This is the thing that aggregates everything that applications are drawing to one set of 3d operations and hands them off to the GPU...it's mostly-interesting for tear-free window dragging. I think that use of compositors is the default for Linux desktops these days. I was using compton, and flipping it off dramatically improved performance.
Compton has an option to temporarily disable itself if it detects a full-screen opaque window (an option which is not enabled by default), but I've no idea whether all compositors do that, or what the situation is for the typical Linux desktop these days. Just one more thing to take a stab at if you're still banging on this.
There are also various mods that can cause significant slowdowns, so I'm assuming that you're comparing an unmodded Linux and unmodded Windows installation.
Have you tried playing about with runtime arguments;
compton -c --backend glx --vsync opengl-swc --xrender-sync-fence -i1
This seems to fix things for me (previously i ran compton alone and would kill the compositor before launching a graphically heavy game.)
I don't remember what those flags do to be honest, but probably worth fiddling with. Some info on solutions here:
I was just shitposting since you said people were arguing "meaningless semantics", but I didn't actually know this for sure offhand, so I looked into it.
I figure bspwm is a good example of a non-compositing WM and can serve as a good example, so I scoured its source. First and foremost, no XComposite calls are made in its entire source tree. All XComposite functions, as documented by XComposite(3), are prefixed with "XComposite", thus the search is comprehensive.
But it doesn't include possible calls in dependencies. Here's its be-all end-all code for showing a window: it does some talking to X and calls a couple XCB functions for mapping and unmapping a window. The code calls xcb_map_window(3), which, naturally, wraps and extends XMapWindow(3) with some IPC stuff and a few window attributes. XCB also features no calls to XComposite (you'll have to clone and grep the source tree to verify this yourself).
In addition to simply hiding a window, X offers calls to reposition and resize windows: XConfigureWindow(3), XMoveWindow(3), XResizeWindow(3), etc. bspwm uses XCB calls that wrap these functions as well.
Thus, since neither bspwm nor its dependencies use XComposite, an X Window Manager need not do any compositing at all. It can let X handle it; no OpenGL shenanigans required.
Similarly, standalone compositing managers exist for WMs that don't do compositing.
Well, actually it can, but it needs a precalculated Gaussian blur matrix AFAIK. See this issue on GitHub.
The thing is most compton configurations use box blur instead of Gaussian blur, which is much less "subtle"
To add to what others wrote: if you want to stay updated on this issue, here are the relevant bug reports:
What compositor does your window manager use? Before switching to Gnome 3 I used to use the Mate desktop with the Marco (software) compositor and the tearing - especially in videos - was pretty bad. After installing the compton compositor[1] the experience was much improved.
To avoid screen tearing make sure you are using a hardware accelerated compositor. This could be compton, compiz or any other software.
You can also try to install the Intel HD3000 drivers which I believe are not delivered with Debian (or Debian based) distributions. You can use Intels Update Tools[2] for this.
Like @pedantic_jackass already suggested you should also look into configuration options of your X11 (look for your xorg.conf.d file and check out @pedantic_jackass 's link.
[1] https://github.com/chjj/compton [2] https://01.org/linuxgraphics/downloads/update-tool
Looks okay, but you could probably stand to use a newer version of Mesa if you play any 3D games (it probably won't help you for this particular case).
Anyway, how you can force V-Sync, depends on what xorg driver you are using. If you are using the Intel driver, you can set "TearFree" to "True" (look up your distro's XOrg documentation to see how to do this). If you are using the modesetting driver, you'll probably need to use compton but if you are using Unity as your DE, it's likely they won't work together. If you are using Unity, look for an option like "unredirect fullscreen windows" (and disable it) which may allow VSync to be forced in Wine (and other fullscreen applications).
Alternatively, you can try something like strangle to limit FPS, which now supposedly works with games under Wine (but I'm not sure if 2D games are covered under "most").
Not related to I3.. but you should probably start by removing the benchmark parameter.
Then refer to the Compton wiki on other parameters you might want to change.. It's very dependent upon the
There are several ways to prevent tearing with Nvidia cards + binary blob. One is to use Compton as compositor. Another is to add ForceFullCompositionPipeline to the metamodes in the xorg.conf. Or both.
Some Window managers / Compositors also give the option to unredirect fullscreen windows to prevent tearing, like Compton, Compiz, Mutter (Gnome3), Muffin (Cinnamon).
On the version of Xfwm4 you are using, "sync to vblank" is implemented using DRM. The Nvidia driver does not support DRM, so this option does absolutely nothing at all.
OpenGL compositing isn't actually that much better. It can still tear, because there's no mechanism in OpenGL to send a buffer to the video card and have the card wait until the next vsync before displaying it. What it actually does is immediately display your buffer and then delay until after the vsync. You then have to push the next buffer before the next retrace starts. If you're not fast enough you will still get tearing.
Compton is in fact a collection of different "hacks" for different video cards and drivers, which is why it has so many options (and especially options labelled "only works on some drivers"). One of those options, xr_glx_hybrid, attempts to render and composite individual windows with Xrender and then present the final result with OpenGL in order to limit the performance hit on Nvidia cards. (OpenGL compositing is MUCH slower than Xrender on Nvidia which is why it isn't a magic bullet.) This is a feature I suggested to the Compton author.
The latest (as in probably still unreleased) version of Xfwm4 has an OpenGL compositor and a Present compositor. Present is the successor to Xrender and it has a mechanism by which you can stream buffers to the GPU and have it present them immediately after a vsync. That means it finally fixes the tearing problem once and for all. Just one problem though: Nvidia drivers don't support it, and so the Present API will just fall back to using Xrender. You can use the OpenGL compositor, but it isn't as advanced (ie: it doesn't contain as many different "hacks") as Compton, so results might not be as good.
it's.. complicated
but vdpau should always display perfect video
if you want to mess with debugging it; first open nvidia-settings, play a video and look at the "Video Engine Utilization:" under "GPU 0" to confirm if vdpau is used
if you don't have compositing and do use vdpau but still have tearing, it's probably a driver bug and should be reported to nvidia
compositing shouldn't interfere with vdpau, and you can set ForceFullCompositionPipeline to make it work a bit better
I'm getting the best performance without tearing by using these changes in my xorg.conf
https://github.com/chjj/compton/issues/227
for the WM I'm using kwin which is handy because it comes with a shortcut for disabling the compositor. For other compositors you need to enable the unredirect fullscreen option that AiwendilH posted.
I think it should work with your card but sometimes compton can be a Diva ;-)
- You dont need to uninstall compton, you can remove it from the autostart Settings -> Openbox -> Edit Autostart.
On the next time you will use compton write
- backend = "xrender"
in your config file...
next try... will it work better with the drivers from nvidia?
last try... post your problem on https://github.com/chjj/compton/issues
In my experience the best compositor for Xfce is Compton (will use Xfce WM settings, unlike Compiz). I get great experience in both desktop and games using Compton like this (on proprietary Nvidia drivers):
$ compton -cCGb --backend glx --vsync opengl --unredir-if-possible --paint-on-overlay
the -cCGb is about using shadows and running in the background but the other options are rather self-explanatory. Using the GLX backend with Vsync mode 'opengl' ('opengl-swc' doesn't work as well for me). --unredir-if-possible makes fullscreen windows display directly.
Compton has a ton of options to play with for vsync and performance tuning, and it's very light weight. Still I think KDE's Kwin is probably the best compositor around (all things considered), but Compton is pretty close and I get good performance both on the desktop (without tearing) and in games. Also note that I disable 'Sync to VBlank' in the Nvidia Setting Manager, and I don't actually start Compton manually (plus there are some switches I use which I didn't list as their mostly unimportant to performance).
[EDIT] Actually looks like --vsync opengl-swc might be the best option to use (and try playing with --glx-swap-method).
[EDIT 2] Actually it seems --vsync opengl works best but there's a bug (or configuration issues on my system) in the Nvidia-Setting with Allow Flipping which causes the stutter. If I disable Allow Flipping --> re-enable it --> start Compton, then everything works butter smooth without any lag or tearing even for windows above other OpenGL windows.
Here is the bug-report I made on the Compton github with more details: https://github.com/chjj/compton/issues/304
Sorry for posting my details comment so late.
>+ How I made the Whisker menu background transparent:
> Right click on whisker menu > properties > background opacity.
I configured compton to add a blur to all transparent windows. Here's my compton start command: http://pastebin.com/P8Tk0cTD
I made all those numbers after --blur-kern like this:
python compton-convgen.py --dump-compton -f=sigma=5 gaussian 15
compton-convgen.py is a Python script that can be found here on Github.
On closer inspection I'm getting tearing with Unity games too. But with vsync enabled and/or a composite manager running it's less severe. I suspect that vsync itself does work with Unity but there is some related issue causing mild tearing. My system is running at 100 hz so it's even more subtle, which is why I didn't notice it before.
BTW, something I found that isn't well documented is that nvidia's drivers have a built in tearing reduction feature which appears to perform better than a full compositor. I can't say it will workaround any Gnome3 issues, and it doesn't completely solve Unity tearing, but it could be useful. Read more here: https://github.com/chjj/compton/issues/227
Enable "sync to vblank" under the OpenGL options in nvidia-settings.
If you are using Gnome, KDE, or Unity, try dicking with the compositor options. You want to be using OpenGL, and you want vsync enabled if there's an option for it.
If that doesn't work, or you are not using Gnome, KDE, or Unity, or you are using one of those and you can't find compositor options (Gnome may not have them, Unity is probably configured with compizconfig-settings-manager):
Disable compositing if you're using a desktop environment that does compositing.
Install compton.
Arrange for compton to be started on login, with this command line:
compton --backend glx --vsync opengl
If that doesn't work, try experimenting with the different backend options, listed in compton --help.
> depending on whether the xorg 'Composite' extention is activated or not? Just to clarify, do the menus work when it's disabled, or are they not working regardless of what the setting is? Sounds like it's an issue with another package (gtk issue maybe?) if the later.
Anyways, I personally never can get the X.org composite extension to work myself, mostly because I have nVidia hardware. :P I normally just use compton, it's very lightweight and will get the job done:
> For exmple, there's no "Wayland assumes a compositor is present". The "Wayland" you seem to want to refer to is the compositor.
This is the same and you are missing the point if that is all you see. The Wayland API assumes there is a compositor present, the X11 API does not and can be used either way. It isn't completely impossible from a technical perspective to implement Wayland without having a compositor but it wasn't designed for that.
> Xorg is a compositor utilizing OpenGl, which can't be disabled
Or we refer to different things. With "compositor" i mean this, like this. I do have noticed that some Wayland developers like to use "compositor" to mean the window system implementation itself (and then retrofitting the term on Xorg) but while it might be in one way valid with Wayland that assumes composition always happen, it is not correct for X.
Very interesting, i had a look there and it seems as if im getting an error,
[ 11/07/21 12:00:29.384 parse_config_libconfig FATAL ERROR ] Invalid blur method kawase
[ 11/07/21 12:00:29.384 main FATAL ERROR ] Failed to create new session.
Rather annoying but i asked on github https://github.com/chjj/compton/issues/579
Compton can filter X window properties to disable composition on fullscreen. That should do what you need.
https://github.com/chjj/compton/blob/master/man/compton.1.asciidoc
--unredir-if-possible Unredirect all windows if a full-screen opaque window is detected, to maximize performance for full-screen windows. Known to cause flickering when redirecting/unredirecting windows. --paint-on-overlay may make the flickering less obvious.
This will depend on the compositor you choose to use. For DIY desktop environments based on X11, you can use Compton to set blur on translucent windows.
Wayland has it's own API for compositors, and I don't know much about how you can set blur on translucent windows, but there is surely a way to do it.
The issue with it is that it only checks for that atom to be the first in the array. To make it a bit more stable you'd have to check more indices. In compton there was no way to just check for "includes", unfortunately, not sure if picom added that possibility.
See https://github.com/chjj/compton/issues/403#issuecomment-326798836 and https://github.com/chjj/compton/issues/408
Compton seems to be abandoned. The most recent changes are 3 years old, and most changes are from 5-8 years ago.
In any case, what do you think makes Compton better than the three compositors KDE includes?
The nearest I've seen were solutions along the lines of this, which looks like it could pretty easily have been adapted to have a particular hue; unfortunately as they were discussing in that link, --glx-fshader-win seems to be gone now. That's the most recent discussion I could find of even just plain grayscale, if folks have switched to doing it a different way perhaps that could lead to something?
For the cursor, the gigantic cursor was the first thing I tried, unfortunately it was slow to draw whenever I moved the mouse, showing blocky patches along the lines for a bit until I left the mouse in place for some time. Sorry for the loud video but the way this is working at the start of the video is the best example I could quickly find of what I'm looking to do; it seems to show up in drawing and CAD programs pretty frequently, I'm just looking to do it across the entire screen rather than inside a particular window.
>Picom is a fork of <strong>compton</strong>, which is a fork of <strong>xcompmgr-dana</strong>, which in turn is a fork of <strong>xcompmgr</strong>.
yo dawg
"sync to vblank" is basically just forcing vsync on everything that is using OpenGL.
Heres my compton config:
shadow = false; no-dnd-shadow = true; no-dock-shadow = true; clear-shadow = true; shadow-radius = 7; shadow-offset-x = -7; shadow-offset-y = -7; shadow-exclude = [ "name = 'Notification'", "class_g = 'Conky'", "class_g ?= 'Notify-osd'", "class_g = 'Cairo-clock'", "_GTK_FRAME_EXTENTS@:c" ]; menu-opacity = 0.8; inactive-opacity = 0.8; frame-opacity = 0.7; inactive-opacity-override = false; alpha-step = 0.06; blur-kern = "3x3box"; blur-background-exclude = [ "window_type = 'dock'", "window_type = 'desktop'", "_GTK_FRAME_EXTENTS@:c" ]; fading = true; fade-in-step = 0.03; fade-out-step = 0.03; fade-exclude = [ ]; mark-wmwin-focused = true; mark-ovredir-focused = true; detect-rounded-corners = true; detect-client-opacity = true; refresh-rate = 0; vsync = "none"; dbe = false; paint-on-overlay = true; focus-exclude = [ "class_g = 'Cairo-clock'" ]; detect-transient = true; detect-client-leader = true; invert-color-include = [ ]; backend = "glx"; glx-copy-from-front = false; glx-swap-method = "exchange"; wintypes : { tooltip : { fade = true; shadow = true; opacity = 0.75; focus = true; }; }; shadow-ignore-shaped = false; shadow-red = 0.0; shadow-green = 0.0; shadow-blue = 0.0;
You will probably be interested in the "vsync = none" option, here is a performance guide by the guy that made compton so try messing with that a bit if you want if you have performance issues, and I made this config mostly using "compton-conf".
Thanks for the feedback! I find it strange that you're experiencing flickering at all; I have absolutely zero visual artefacts during normal use, just a tiny initial "jump" the first time after a restart when Kitti3 is spawning Kitty and has to reposition and float the terminal window. Though it might just be differences between our systems... If you get an idea for what might be causing it please don't hesitate to create an issue on GitHub!
When it comes to transparency I use Compton as my compositor to allow for transparency and fade in/out effects. I'd recommend giving it a try, though if you do then please remember to respawn your Kitty window after starting Compton in order to enable transparency. For me Kitty won't listen to opacity values I set in the config, but you can lower the background opacity of Kitty on-the-fly by ctrl-shift-a followed by l.
In the original repo @ https://github.com/chjj/compton, the last change was something like 2 years ago.
But there is an active fork here: https://github.com/yshui/compton; with last commit Aug 8. The README states:
> The current battle plan of this fork is to refactor it to make the code possible to maintain, so potential contributors won't be scared away when they take a look at the code
Did you try asking this yshui to be maintaner?
you can try switching to the glx backend instead of the xrender one if you havent already, or look into other suggestions from here: https://github.com/chjj/compton/issues/227
otherwise you can use a different compositor or just dont use one :/... honestly imo compton's performance is substandard in general and the screen tearing is a side effect
I've defined the blur radius in my compton.conf, you can choose the way it blurs the background by adding blur-kern=<string>; to it, as explained in this comment. Mine is set as blur-kern="7x7box";
Hi everyone.
Finally created a pull request of this feature to https://github.com/chjj/compton . Let's hope the devs like it and any of you using my fork can go back to "the big papa" project soon :)
Hey,
No worries! I checked the configuration file and looks identical to mine
I am not experiencing any flickering issues but my laptop has only intel hd graphics.
Are you using an external GPU? If that's the case, sorry, but I don't know how to help :(. Maybe you can find more on compton's issue page or here
Make sure you have the right drivers working fine for your GPU first of all. Then you can enable Compton to use vsync to get rid of the tearing. Here's a good guide: https://github.com/chjj/compton/wiki/vsync-guide.
I haven't tried MPV. VLC doesn't have this problem but I frequently see the problem reported here https://github.com/chjj/compton/issues/494 when using VLC which is why I switched to mplayer initially.
I found this bug also reported on compton tracker https://github.com/chjj/compton/issues/494
Also, unfortunately, your setup is not useable in my case. Could be that it's too much for compton to blur 4k screen. After enable blurring system becomes super slow. While CPU useage is not high the GPU usage (intel i7-7700HQ here) is working on maximum performance. For example, usage of GPU without compton blur https://imgur.com/a/XCGIqPe vs GPU with blur on (the rest of the settings are the same) https://imgur.com/a/VelVfI0 In general the RC6 state of GPU happens rarely with blur, the clock speed is always boosted to 1100mhz instead of regular 350 and power consumptions is around 4kmW instead of 200 :( Bottom line, that's hella beautiful but damn heavy, at least on my GPU and 4k screen (going to try to it on nvidia GPU now :) )
Update: With NVIDIA GPU enabled I don't feek the lag anymore, so my guess that it does happen because of 4k screen and intel's GPU inability to handle this resolution properly. Compton still consumes ~300MB GPU RAM while without blur it stands around 50M, yet for nvidia 1050 with 4GB dedicated RAM it's not that painful. The GPU is working harder with 8% avg GPU utilization, which is much better than 100% intel's GPU utilization :) Bottom line, on 4k screen blur is only usable with a powerful GPU, sad :(
I am not really sure, since it's been a long time since I last used compton. But IIRC you can't use blur-kern that way; instead, you need to calculate a gaussian kern matrix and supply it to the config file.
However I just found this branch which allows you to use blur-kern="11x11gaussian" and performs the calculations automatically, but I have not tested it.
Have you tried upstreaming yet?
> But maybe it won't be merged because the master-branch got no commit since a year.
chjj/compton seems dead, but there's yshui/compton. E.g. Arch Linux is using that branch. It would be nice having the patches in there.
I also maintain a low-resource Pantheon Lite desktop, with Openbox for the window manager and Compton for a few effects (richardgv and I collaborated on this script that emulates compiz's 'neg' plugin). For me it isn't about eye-candy; I don't make much use of those features in compiz--I even disable animations entirely. A transparent compiz cube offers a kind of desktop interaction that isn't available anywhere else; it's like having a big desk with enough space to lay all your papers and books out on it without having to lose sight of anything.
According to this issue it should work with 0.1_beta2. It works for me, I'm on version 0.1_beta2.5 though. If it is not available on your distro, you could try to build it from source. It is explained on their Github readme.
I had this issue on my Acer Chromebook 14 running Gallium via dual boot, and though I haven't tested it with games, I think I've found a solution in tweaking compton. Killing it works to stop flicker on video playback but that seemed a bit much, so I messed around setting a number of flags in the default config to false including redir-if-possible, and it seems to be a lot happier. You can see what config file is being loaded with 'ps -auxwww | grep compton', edit that file with sudo and hopefully you'll see improvements. More info on compton here: https://github.com/chjj/compton/wiki/perf-guide
Did you clone my dotfiles? Maybe you need to get compton package via pacman and use a config file of sorts that fixes that. Here is a link to one that might fix your issue. https://github.com/chjj/compton/blob/master/compton.sample.conf
I use that and don't have a back bar which sounds like a compton issue.
To use that config with compton: compton --config /path/to/your/.conf/
Be sure to share if this works!
Are you sure it's 15% when recording ? An encoding overload warning usually pops when the CPU can't keep up and OBS takes close to 100% (minus the cpu usage of your other applications).
When it comes to recording on linux, I've found it best to have nvidia's binary drivers (not nouveau), and to disable the compositor (such as compton, but depends on your distro/display manager). If you have tearing problems without a compositor, follow this advice.
By the way, have you tried disabling the webcam ? Is the performance any better without it ? And if you keep having trouble stopping the recording, try another output format such as MKV.
Also, while it won't affect performance, I strongly discourage the use of zerolatency tuning since it will severely degrade the video's quality and is only useful when not recording. And I wouldn't bother with libx265 because if you already lag with libx264, then it's gonna make things even worse. x265 encodes video using the next generation standard HEVC but requires much more CPU resources. Finally, for recording in high quality, it's recommended to use CRF as rate control rather than CBR, and to set CRF to something low like 14-16.
I've been experiencing the same problem. According to this issue on GitHub, it's a known problem with Compton. I've gone through the issue and tried some of the suggested flags, like --vsync opengl but it didn't seem to make a difference for me.
If you end up finding a fix, please post it!
As stated, it's generally a driver issue and has little to do with your Desktop Environment, which would mask the problem at best.
In the video, when you start compton then start spamming letters, is the issue that sometimes pressing a key, makes it not appear? And when you press another key, both those letters show up? Is your issue the same as this one? https://github.com/chjj/compton/issues/313
Hmm, are you sure Chrome is hardware accelerated? Check chrome://gpu and make sure it says "Video Decode: Hardware Accelerated" If it does say that, then I'm thinking it's the nouveau driver.
Maybe this guide for compton will help:
https://github.com/chjj/compton/wiki/vsync-guide
EDIT: For YouTube, I recommend downloading the videos and watching them with mpv or VLC or something, as web browser playback is generally worse from my experience.
What window manager are you using? Compositing must be enabled for it to get rid of tearing. And if the window manager supports no compositing (or you use xfce and prefer working compositing) have a look at some window manager extension like compton
As I said in the OP I used to have the problem in fluxbox, but it disappeared when I switched to XFCE. Now recently I got the issue again, so it seems to haunt me hehe. But I've had compton disabled for a bit now and done terminal work, and I've not encountered the issue once. And you're right, it's super annoying.
I made a github issue so hopefully it can be resolved. Although compton seems pretty inactive :(
It is because i3 doesn't have extra display compositing to prevent screen tearing like gnome has.
Most people us a program called compton to prevent screen tearing, enable transparency and apply shadow effects.
It is probably in your distros repos and dont forget to create a configuration file, it is almost useless without one.
Google brought me here while searching for a solution to problems with Compton and Chrome. In my case the context menu didn't appear until the mouse pointer passed over it. I also had other rendering problems.
Eventually I found the solution posted here worked for me. So it's just changing compton's backend from glx to xrender (edit ~/.compton.conf).
The xfce compositor works perfect without lag or other problems but i get tearing.
EDIT: Found the solution here https://github.com/chjj/compton/issues/227 I had to add Option "metamodes" "nvidia-auto-select +0+0 { ForceFullCompositionPipeline = On }" in my xorg.conf
> * screen tearing prevention causes image flickering (the settings module warned beforehand though);
- If you are on NVIDIA proprietary, you might want to take a look here: https://github.com/chjj/compton/issues/227 and then disable the tearing-prevention altogether since your hardware will take care of that now.
Also put this into your Device section in the xorg.conf:
Option "TripleBuffer" "true"
>* noticeable delay or lag when performing simple actions like opening Dolphin or typing on a document, even on a SSD.
- Yep, noticed that too. Dolphin is completely unusable and fails to carry out even the simplest tasks of a file manager, so I just use Nautilus. I really really hope they can improve Dolphin in the future.
Personally I can deal with bugs and crashes as long as my regular applications work and Plasma 5 is the prettiest DE I've used so far. I love kwin for its desktop effects (muh wobbly windows and cube) and for the easy shortcut for disabling the compositor, which is very handy for gaming. My setup is also rather minimal:
http://i.imgur.com/L0Cg5jD.png
I'm using Synapse for launching applications and Cairo-Dock as task bar. Not much left of Plasma 5 now, so that's probably why I don't experience as many bugs as most. I also don't really touch widgets or the activities.
There's a lot of configuration options for compton, so it's possible there is a misconfiguration somewhere. This should be helpful: https://github.com/chjj/compton/wiki/vsync-guide
FWIW I've had no performance issues on any of my systems (High end nvidia, mobile AMD, and mobile Intel). The latter hasn't been extensively tested with 3D games, mainly because it's just too slow full stop.
Sorry to bug you again, but just wanted to let you know that actually it seems --vsync opengl works best but there's a bug (or configuration issues on my system) in the Nvidia-Setting with Allow Flipping which causes the stutter. If I disable Allow Flipping --> re-enable it --> start Compton, then everything works butter smooth without any lag or tearing even for windows above other OpenGL windows.
Here is the bug-report I made on the Compton github with more details: https://github.com/chjj/compton/issues/304
Last time I bug you, I swear.. just wanted to tell you about this discovery as it was a direct result of our conversion here, and might be relevant to you if you're adjusting Compton setting scratching your head over this odd behavior like I was yesterday.
"First of all, compton cannot do VSync better than your driver could. For vesa and other pure-software or broken drivers, or when you turned off the hardware acceleration in your driver, you shouldn’t expect much about VSync." from this guide - https://github.com/chjj/compton/wiki/vsync-guide - I use to have a bind for restart xorg but lost it during my distro hopping days.
Unfortunately it seems to be inactive - the devs haven't touched it in months, and there's some open pull requests to fix memory leaks and the like. It's a shame, because I really like compton. I should hack on it a bit...
Which WM are you using? Most tiling/floating wms don't come with a compositor. They allow you to use things like true transparency and vsync, which will get rid of screen tearing. Compton is currently (imho) the best one available. Its easy to set up, most of the time you can literally just copy and paste the config off the internet and it'll work perfectly.
There's a lot of documentation out there for optimizing glx and compton; the xrender compton uses by default is most likely slower than glx would be.
Here's some stuff to try -
https://github.com/chjj/compton/wiki/perf-guide
good luck!
https://github.com/chjj/compton/archive/v0.1_beta2.tar.gz, directly from the AUR page listed in the original post. Also, I thought passing the -m argument for pacman -Qm lets me see local packages like the one I've built(?).
Does this work with the xrender backend as well? I've been unable to get it to work due to this issue with Intel drivers (I'm using i915). Perhaps it would be wise to use absolute paths rather than relative, just for good measure.
There's a typo here:
> \3. Run mumble.
i3 is known for having issues with compositors, and transparency. This FAQ item is about compton, but the point stands. I use compton as my compositor, but don't mess with any transparency to avoid these issues—I only use it to stop screen tearing.
Thanks pezzotto, that's getting closer to it I think. I've just come across this solution as well here: https://steamcommunity.com/app/240760/discussions/1/613936673462417321/
https://github.com/chjj/compton/issues/227
My only concern is that this is supposed to incur a performance loss...
- Clone my config git repo.
- Run the provisioning script and wait an hour or so for all the updating and installation to finish.
- Reboot.
- Install proprietary GPU drivers and reboot again, if applicable.
- Tweak compton config to work well with whatever graphics hardware the machine has.
- Linpack that motherfucker.
I have had great results (no tearing) with XFCE + Compton on Nvidia and Intel graphics.
Compton configuration on Ubuntu Forums: http://ubuntuforums.org/showthread.php?t=2144468
Build from source (if not in distro): https://github.com/chjj/compton
There's an easy fix: Create the file ~/.config/gtk-3.0/gtk.css with the following contents:
.window-frame, .window-frame:backdrop { box-shadow: 0 0 0 black; border-style: none; margin: 0; border-radius: 0; }
.titlebar { border-radius: 0; }
Works fine for me.
I tried to setup Compton once but it didn't work quite right.
Their FAQ lists i3 as a trouble maker which I have found to be the case regardless of compositors.
Are you not using a compositor? With modern graphics hardware, anything that isn't full-screen, double-buffered (or more), and vsynced is really only supported as an afterthought (as well it should be).
I recommend Compton. For proper behavior on Intel, you probably want (at minimum) --backend glx --vsync opengl.