performance regression in some apps (games?)

[pvanek]

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

• super tuxkart (game)
• xscreensaver

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

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

setup: nvidia, openbox 3.5.0

[richardgv]

Confirmed.

Environment: xorg-server-1.13.0 + nVidia GTX 670 (GigaByte GV-N670-OC-2GD) + nvidia-drivers-304.51

$ glxgears
# Running no compositing window manager
156219 frames in 5.0 seconds = 31243.713 FPS
155875 frames in 5.0 seconds = 31174.994 FPS
155753 frames in 5.0 seconds = 31150.344 FPS
# Start compton (with compton.sample.conf, so a lot of features enabled)
30123 frames in 5.3 seconds = 5673.983 FPS
31176 frames in 5.0 seconds = 6235.147 FPS
31260 frames in 5.0 seconds = 6251.558 FPS
31318 frames in 5.0 seconds = 6263.194 FPS
31263 frames in 5.0 seconds = 6252.570 FPS
# Shutdown compton
155875 frames in 5.0 seconds = 31174.959 FPS
156253 frames in 5.0 seconds = 31250.486 FPS
153008 frames in 5.0 seconds = 30601.582 FPS
# Start xcompmgr
62929 frames in 5.0 seconds = 12585.774 FPS
62951 frames in 5.0 seconds = 12590.188 FPS
62956 frames in 5.0 seconds = 12590.865 FPS
62990 frames in 5.0 seconds = 12597.651 FPS
# Shutdown xcompmgr
87211 frames in 5.0 seconds = 17442.121 FPS
155954 frames in 5.0 seconds = 31190.664 FPS
# Start compton but disable all options
24853 frames in 5.0 seconds = 4970.455 FPS
24951 frames in 5.0 seconds = 4989.810 FPS
24924 frames in 5.0 seconds = 4984.368 FPS
24947 frames in 5.0 seconds = 4989.377 FPS
# Wait, why FPS dropped when I disable all options?
# Start compton with no options but -c
25528 frames in 5.0 seconds = 5105.145 FPS
26688 frames in 5.0 seconds = 5337.567 FPS
26743 frames in 5.0 seconds = 5348.499 FPS
26702 frames in 5.0 seconds = 5340.302 FPS
# ... What the... `-f` and `-i 0.5` does not seemingly affect the FPS much.

(By the way, I noticed when glxgear is taking the full power, compton's fading is almost unusable, well, which could be the thing to expect.)

I wasn't able to notice anything different compton creates when running xscreensaver demos with xscreensaver-demo or /usr/lib/misc/xscreensaver/gears -fps, presumably because xscreensaver is not rendering with the full power of my GPU.

I will try to look into this problem but please don't expect much. Look, even xcompmgr with no options could trigger this problem, just less severe. This might indicate an issue in XRender. If you could show me a compositing window manager which does not affect OpenGL application performance, I may get something by comparing their mechanism.

For now, you'd better turn off anything compositing when you want OpenGL.

Update: By the way, check if "Sync to VBlank" in OpenGL setings in nvidia-settings could help.

[richardgv]

By enabling software VSync feature just added to richardgv-dev branch today, the FPS glxgears reports when compton is running drastically increased here. Without compton I got 32,000+ FPS, with compton (normal mode) I got 6,000 FPS, with compton (software VSync to 60Hz) I got around 24,000 FPS.

[richardgv]

I would prefer if somebody experiencing this issue could clone from richardgv-dev branch and tell me if the new version helps. Essentially, I hope b78ab316fd is helpful for this issue. Please also look at the CPU usage of the X process during tests.

[pvanek]

I'm just returning to this issue. How I can enable this feature, please?

[richardgv]

I'm just returning to this issue. How I can enable this feature, please?

Ah, this is a change in the painting process, and it's always "enabled".

[pvanek]

ok, tested. I can confirm compton behaves observably better with your branch in this area. It's not perfect, as yu said, but it's definitely better.

[richardgv]

@pvanek: Ah, pvanek, thanks for the test results. :-) Sorry but right now compton is doing almost minimal painting, I believe, and without optimizations based on refresh rate or something else extraordinary, the performance probably has little space of improvement.

Compton (in richardgv-dev branch) has some support for refresh-rate-based optimizations, basically limiting compton to paint at most 60 times per second if your refresh rate is 60Hz. (Thus, if your FPS without xcompmgr/compton running is not much higher than your refresh rate, the effects could be pretty limited.) There are 3 choices:

1. compton --sw-opti --refresh-rate YOUR-REFRESH-RATE, fallback option, purely software-based, limits compton's painting interval only, you could specify a lower refresh rate than the actual value to further reduce painting, as far as you consider it tolerable.
2. compton --vsync opengl, OpenGL VSync, also limiting compton's painting interval, relies on an OpenGL extension which your driver may or may not support;
3. compton --vsync drm, DRM VSync, similar to OpenGL VSync but relies on something in DRM instead, so will probably not work on the binary blobs.

I hope you will see some further performance boosts by using one of those options. But maybe you can't expect reducing the performance impact to zero.

By the way, have you noticed that compton causes X to use more CPU than usual?

[tserhii-gh]

There is some issue with nvidia blob, latest richradgv-dev branch, two times in past when using mplayer+vdpau after some time compton cause high CPU load and lagging, i'll try to get more information.

Update: Last 12 hours i was trying to reproduce high CPU load issue or picture freezing by watching video on vdpau output, intensive browsing web and watching flash, and during this time did not have any issue, i'm satisfied with this.

[richardgv]

@funeral1988: We are truly grateful for your continuous feedback. :-) Sorry, my network dropped yesterday all a sudden so I couldn't continue the discussion. I tried saving 20+ pictures in Chromium, and noticed nothing wrong. It is indeed one of the weirdest bug I've ever heard. :-)

[corenominal]

I am not too sure if I am experiencing the same problem, but it sounds like it. I have experienced similar high CPU usage by xorg when running the richradgv-dev branch, to the point where restarting compton is required to fix it. The issue is difficult to replicate as it only seems to happen after an extended period of use. Also, I have only experienced it when running numerous applications, so I cannot tell if the issue is being triggered by a particular app. I have experienced the issue on 2 different machines, one running an Intel card and the other an NVIDIA card. Is there anything I can do to help debug this?

[OrdinaryMagician]

Oh I'm glad this issue is being worked on. I've had these framerate drops everywhere when using pretty much any composite manager, and also the fact that just by having compositing enabled it's impossible to also have VSync (in games, or even in video playback with any output driver)

[richardgv]

I am not too sure if I am experiencing the same problem, but it sounds like it. I have experienced similar high CPU usage by xorg when running the richradgv-dev branch, to the point where restarting compton is required to fix it. The issue is difficult to replicate as it only seems to happen after an extended period of use. Also, I have only experienced it when running numerous applications, so I cannot tell if the issue is being triggered by a particular app. I have experienced the issue on 2 different machines, one running an Intel card and the other an NVIDIA card. Is there anything I can do to help debug this?

Thanks for your report. So finally, the thing I fear the most happened. If the compton process is using too much CPU, we have a million ways to trace what's happening; if it's Xorg... My suggestion is compile xorg-server with debugging symbols, and do profiling on it when you are meeting the problem. This most likely will only provide a hint of what's wrong, but does not tell us where exactly the issue is. If I could reproduce this bug and attach gdb to X, maybe I will get more info, but for such a long period of time I've being suspecting the same thing, and I've never being able to reproduce it. As the actual bug might be just a single line in compton, and it could be tied to the deep internal logics of X (or even an obscure bug in X), I'm afraid you can't expect too much. Sorry...

By the way, corenominal, have you tried VSync recently? Some users reported my latest changes has successfully moved the tearing line to the top of the screen (instead of kicking it out!), with full discussion in #7. I hope I could get some extra feedback. I asked the question regarding VSync on Xorg user mailing list, and nobody replied. Do you know a better place to ask about these sort of things?

By the way, I will push another possibly problematic commit to richardgv-dev very soon, which is very likely to lead to very obscure bug that only appears with specific WMs and specific behaviors. I hope you could test it later.

Oh I'm glad this issue is being worked on. I've had these framerate drops everywhere when using pretty much any composite manager, and also the fact that just by having compositing enabled it's impossible to also have VSync (in games, or even in video playback with any output driver)

A compositing window manager is to either occupy a part of your CPU, or to occupy a part of your GPU. Unfortunately, you probably won't see a compositing window manager with no performance penalty until the end of the world. Please try all the suggestions I gave to pvanek above: Clone from richardgv-dev branch, build it, run with --sw-opti or --vsync XXX, and see how things go.

Another possibility is to disable compositing if we could detect you are using a full screen app, well, which does not work if you are watching a video in a smaller window.

And we are working on VSync right now. Please try --vsync opengl or --vsync drm, and post your feedback in #7.

[tserhii-gh]

today's compiling of richardgv-dev total uptime 5 h during this time intensive browsing, flash, video(vdpau), irc, audacious, then only watch video.

Then after 32 minutes of watching video on vdpau output i get laggin, If doing some actions on screen, like playing video, moving windows Xorg cpu usage run to 100%, compton state as usual. Very strange issue.

sysprof: http://bit.ly/YxGvgH nvidia-smi output: http://pastebin.com/6TbbC0VD

[richardgv]

@funeral1988:

Ah, truly grateful I am for all the info you provided. :-)

Firstly please test with latest build from richardgv-dev branch. I hope 9fb62874c1 fixes the thing.

The whole story is: From your sysprof result, I saw most of the CPU time are taken by GetXIDRange in X. A Google search reveals a ton of similar issues: KDE Bug 216289, Debian Bug #557762, freedesktop.org Bug 49416, a thread in nV News Forums, and Debian bug #677470.

Then I looked at the source code of xorg-server and found GetXIDRange() is somewhat related to resources. I found xrestop, used it to monitor compton's X resource usage, and discovered compton is probably leaking resources in the "unknowns" category, seemingly at least on every window damage event. I suspect it's leaking XserverRegions, so I added debugging code to XFixesCreate/DestroyRegion(), and discovered there's a leak in the beginning of paint_all(). It leaks one XserverRegion on every paint, but after 5 hours of usage, if we assume it paints once every 20ms, we get 900,000 regions leaked. It's not a primary part of the function and I never thought it would cause such a big issue. Anyway, I pushed out a fix, and let's see if it works.

If the latest build still has the issue, please use xrestop to check if "xcompmgr" (which is actually compton) is using an absurd amount of X resources. And please try running a program that paints extremely rapidly (and turn off --vsync and --sw-opti in compton), to check if the problem appears earlier when compton paints rapidly. Considering similar bug reports appeared in some pretty reputable software, too, I can't exclude the probablity of an issue in X server itself. And I've seen vdpau causing ridiculous CPU usage on some drivers ( https://github.com/chjj/compton/issues/25#issuecomment-9935036 ), although in a different way, therefore vdpau is to be suspected, too.

[tserhii-gh]

@richardgv: Just compiled from richardgv-dev and starting to test:) Also, if get issue how i can share xrestop output?

[richardgv]

@funeral1988:

Thanks. :-)

Also, if get issue how i can share xrestop output?

xrestop has a -b option that might dump things in a slightly better format:

xrestop -b | grep -A 14 xcompmgr

[corenominal]

@richardgv, I've been running the 9fb6287 commit for 14+ hours and so far I have not experienced the previous issue. I'll continue to keep it running, but I am pretty sure you've nailed it. Nice job, thank you!

[OrdinaryMagician]

I've been running the latest version (of the richardgv-dev branch) as of now (2012-11-05 23:00 CET), for some time, playing games windowed while also streaming with ffmpeg. It took some hours for X to become terribly sluggish. So much that I had to switch to a tty and kill compton from there.

[richardgv]

@OrdinaryMagician:

Very well then... I did yet another test and could not find visibility XserverRegion leakage during some normal usages. When the issue is appearing, if you notice 100% CPU usage from the X process or compton process, please provide a system-wide profiling result (using sysprof, oprofile, perf, or whatever you want), your commandline arguments and configuration file of compton, and all the information I asked for in last paragraph of the reply above ( https://github.com/chjj/compton/issues/50#issuecomment-10035751 ). If the CPU is not 100% occupied when the problem appears, this thing could be related to your driver and is going to a million times hard to to debug... And if possible please stay in #compton on FreeNode, so I could ask questions more synchronously when I'm online, which may be help, too.

Sorry, My time is pretty tight recently, so I cannot do much tests myself.

[richardgv]

@OrdinaryMagician:

Please, read my reply above firstly.

I did three extra tests. Two tests with compton --config /dev/null -cf, the other with the configuration I personally use (basically compton.sample.conf). Tried various actions: Creating, destroying, moving windows, video playback... And after I closed all windows, the only region not freed yet was the screen region. When I started with one window, 4 (or 5? Sorry, I forgot the number) regions are allocated initially, and after all those operations, I closed all other windows, still only regions of exactly the same amount were left.

There are only two functions I used in the program that could allocate a region, as far as I know: XFixesCreateRegion() and XFixesCreateRegionFromWindow(). The former is traced with a macro, the later is used only once and the region it returns is immediately freed. So I would assume it isn't too likely that there are XserverRegion leakages with the commandline parameters I used.

However, I cannot exclude the possibility of a Picture or Pixmap leakage, or leakages happening only when using specific options. The usages of Picture or Pixmap is pretty small in number, and -cf should be able to cover most cases, though.

So, I just want to say, despite all my efforts, I still have not found what the hell is wrong with compton right now. I have to wait for your profiling result, xrestop output, and all other information I asked for.

[OrdinaryMagician]

I run compton with --config ~/.compton.conf --vsync opengl First of all, here's my ~/.compton.conf http://hastebin.com/raw/giyuwajate I'm gonna do the profiling and xrestop thingies now. Will just do what I did last night.

[richardgv]

@OrdinaryMagician:

Ah, I'm glad you are there. You didn't miss the reply I posted 6 minutes ago, did you? :-)

A few notes:

1. You don't need --config ~/.compton.conf. compton does read ~/.compton.conf by default (unless you have a ~/.config/compton.conf, which has higher priority). More details in the man page.
2. We do not recommend turning inactive-opacity-override on. That option is known to create annoying effects sometimes. Although it has no effect unless you enable inactive-opacity, we would recommend you to disable it for now, in case you forget about that someday when you start using inactive-opacity. Sorry that I turned it on in compton.sample.conf in accident once, but I did reverted it eventually.
3. Already it's possible to specify VSync option in configuration file. See the compton.sample.conf in richardgv-dev branch.

[OrdinaryMagician]

Well, I don't know what to say. After some time of gameplay nothing happened, until I started Doom 3. Then everything started lagging terribly and I had to switch to a tty to kill compton. The data from sysprof is here (it's about 50MB uncompressed): http://ompldr.org/vZzV6NQ

[richardgv]

Well, I'm sorry. I read your reply this morning but the curse-inducing work just took yet another day from me.

First things first, please tell me whether the CPU is 100% occupied when it's lagging. I did ask for that, I remember.

The second thing I wish to say, is that I forgot to mention you must start profiling after it starts lagging, and stop profiling before you kill compton. (If you have troubles operating on sysprof's interface when it's lagging, sysprof has a commandline interface, sysprof-cli.) Samples collected when X is not lagging will distort the profiling result. I believe you know the point, but somehow your profiling result is giving me the impression that you were not following the rules. You did the right thing, right?

Now let's get to the point: I inspected your profiling result, in which:

1. Neither X (13% of total CPU time) nor compton (0.26%) is using a large percentage of the CPU time;
2. I looked into the CPU time distribution inside the X process, and there's not any abnormal sign that I could see: nvidia binary blob took 5%, of the 13% total CPU time X process took, the rest are evenly distributed between various functions. In particular, in funeral1988's profiling result I saw much CPU time used by GetXIDRange, which is a sign of X resource leakage. I couldn't see anything even remotely similar in your profiling result.

There are several possibilities:

1. The bottleneck is on GPU, not CPU. It's usually the case if when it's lagging, the CPU usage is below 100%. A possible cause is your other applications are stressing GPU too much. If the problem appears even when you have --vsync or --sw-opti enabled, my advice is to turn on OpenGL "Sync to VBlank" in nvidia-settings.
2. There is a problem in compton but you didn't reproduce it in the correct way. The lagging you met two days ago comes from a different reason.
3. You didn't do profiling at the correct moment.
4. You are running too many things altogether, and X did not get enough CPU time.

Had you provided xrestop output (when it's lagging), we could figure out more things.

[OrdinaryMagician]

It's funny, when I want the problem to happen and I'm ready to track it, it just doesn't happen. And when it happens, I forget to open sysprof. The lag just stops before I can launch it. Somehow it seems to be completely random, too.

I also have discarded temperature issues, all my sensors report temperatures inside safe limits.

I'm sorry but I think I won't be able to help, I fail at reporting bugs. :(

[richardgv]

@OrdinaryMagician:

Ah, I understood. Yes, that's a very annoying situation indeed. Just a reminder: it's more than sysprof data that I want. If you forgot to open xrestop, too, at least tell me if the CPU usage is 100% or not.

I guess this has something to do with your OpenGL applications and your drivers, but it's dangerous to make any assumption right now. Anyway, I will wait for a few extra days. If I still don't see any other definite reports from you or another user by then, I will probably merge richardgv-dev into master. @chjj looks really inactive recently somehow...

I have a few bug fixes to push in the computer at home, but yesterday I poured half glass of water onto my keyboard... And it got drunk, giving me 3 characters when I have pressed only one key... I hope I will have some extra luck today when I come back home. :-D

[richardgv]

Well, just to prove I didn't forget what I promised a long time ago... Here you go, compton now could disable itself (on the GPU side only, technically) when it detects a full-screen opaque window with no semi-transparent frames, 59e54b0665 in richardgv-dev branch. Which means, hopefully, almost zero performance penalty for full-screen games and video playback. I hope you guys could test if there are some issues. Please read the commit message for how to enable it (it is not enabled by default because of the flickering) and known issues.

There's another known issue: Updates to _NET_FRAME_EXTENTS are sometimes not picked up by compton. Will look into that thing tomorrow. Update: should be fixed on aaeafbd19d.

[Gavcheg]

Hello! From issue #56 "and nobody is testing, nobody!" - i'm testing and it works! Because my mplayer always start in fullscreen, my problem wish video tearing is gone. Many thanks. But, in last commits looks like broken "--shadow-ignore-shaped" - i use this for tooltips in opera browser tabs. In opera tooltips is png images with shadows. So, "--shadow-ignore-shaped" avoid double shadow in opera. Also i enable "-z" option. Anyway, thanks and sorry for my terrible english :)

[richardgv]

@Gavcheg:

Ah, thanks for your support, firstly. :-)

Well, for the Opera issue: I see Opera is using a window with transparent ARGB background (yep, as what you said, PNG image with shadows) for its browser tab tooltip window, when --shadow-ignore-shaped is only effective for those that set window shape though X shape extension. So, it's the intended behavior that --shadow-ignore-shaped has no effect on Opera's tab tooltip windows.

Compton could not detect how much fully-transparent part a window has in its ARGB background. The only thing it could know is this window is using ARGB background -- and a window using ARGB background may actually have no fully transparent parts, like the case of a semi-transparent terminal window. So we cannot just turn off shadow on all ARGB windows, despite all the complaints.

Why you consider --shadow-ignore-shaped working for you previously is what I do not know. I see two workarounds for the problem right now:

1. Disable -z. This gives the Opera tab tooltip a big black shadow.
2. Disable shadow on all tooltip windows. On the bottom of compton.sample.conf in the root directory of the richardgv-dev branch, you can find this:

# Window type settings
wintypes:
{
  tooltip = { fade = true; shadow = false; opacity = 0.75; };
};

See the shadow = false? Just copy the whole section into your configuration file, and shadow on all tooltip windows will vanish. (Consult the man page if you have any doubt about configuration file).

Because my mplayer always start in fullscreen, my problem wish video tearing is gone. Many thanks.

Huh, I can't say if this is a good news or a bad one for me, because doesn't compton already have VSync support in richardgv-dev branch? I wonder if you have tried --vsync drm or --vsync opengl, and how well/poorly they work.

And, do you think the flickering is tolerable when compton redirects/unredirects all windows?

Anyway, thanks and sorry for my terrible english :)

Your English is good enough already as far as everybody could understand what you are trying to say -- that's what a language is for, after all. In this sense, your English is not much worse than William Shakespeare's -- Well, maybe better than his, considering the fact that I would have great troubles understanding Shakespeare's Early Modern English if he tries to report a bug to me. :-D Don't worry.

[Gavcheg]

@richardgv

Why you consider --shadow-ignore-shaped working for you previously is what I do not know.

I dont know too :) So, i found solution without disable "-z" (big black shadow really ugly) and without disable shadows on all tooltips. Specific to Opera: add -noargb. Example: opera-next -noargb. And everything now ok! Thanks for explanation about ARGB.

I wonder if you have tried --vsync drm or --vsync opengl, and how well/poorly they work.

Because i'm nvidia user, i try "opengl" and "sw-opti" with/without other options. In my case "opengl" is fast but powermizer on my ion show maximum clock's if vsync opengl enabled. At the same time, in video tearing present (without --unredir-if-possible of couse). --sw-opti slow and tearing when windows move, but if i add something like "--refresh-rate 120" (my native rate is 60) speed id ok, powermizer show lowest clock, but tearing still presents on windows and video (without --unredir-if-possible). However, i was not worried about a possible tearing, because without vsync all fast and i do not have time to notice it on the windows. For video now i use --unredir-if-possible and it great solution. My graphics card is Nvidia Ion and i'm using a completely passive cooling. If not for that, i would use vsync opengl and not paying attention to the high temperature, because the GPU frequency raised to the maximum because of the use vsync opengl. By the way, with vsync opengl i did not notice the tearing in the video in a window, but it still there of fullscreen video (without --unredir-if-possible).

And, do you think the flickering is tolerable when compton redirects/unredirects all windows?

Its not problem for me. I do not see a strong flicker. I do not see much of a difference, even if i use -paint-on-overlay. As i recall, it was a flicker in ancient compiz when using "unredirect fullscreen blah-bla-bla". I do not know where things stand now.

Overall, i would recommend all include vsync opengl and --unredir-if-possible for best results when using active cooling and the temperature does not matter.

:-D Don't worry.

Thanks. I'll be glad to help any way i can. :)

[richardgv]

@Gavcheg:

I dont know too :) So, i found solution without disable "-z" (big black shadow really ugly) and without disable shadows on all tooltips. Specific to Opera: add -noargb. Example: opera-next -noargb. And everything now ok! Thanks for explanation about ARGB.

Cool, thanks for the tip! :-)

Because i'm nvidia user, i try "opengl" and "sw-opti" with/without other options. In my case "opengl" is fast but powermizer on my ion show maximum clock's if vsync opengl enabled. At the same time, in video tearing present (without --unredir-if-possible of couse). --sw-opti slow and tearing when windows move, but if i add something like "--refresh-rate 120" (my native rate is 60) speed id ok, powermizer show lowest clock, but tearing still presents on windows and video (without --unredir-if-possible).

Ah, somehow my GTX 670 + nvidia-drivers-304.64 generally uses performance level 0 with 25'C temperature even if I turn on --vsync opengl in compton. Could be related to the differences of internal graphic card logics, but maybe you could try upgrading your nvidia-drivers.

I hope turning on the two "Sync to VBlank" in nvidia-settings (one in XV settings, one in OpenGL settings) could eliminate tearing, but many reported things didn't go in the way I expect.

--sw-opti does not do any vsync, so it isn't surprising that the tearing problem does not go away with its presence. I wasn't expecting --sw-opti creating annoying delay, though. Gosh, I could tolerate --refresh-rate 30 myself. You must have lightningly quick eyes! :-D

However, i was not worried about a possible tearing, because without vsync all fast and i do not have time to notice it on the windows. For video now i use --unredir-if-possible and it great solution.

Pretty awesome. :-)

My graphics card is Nvidia Ion and i'm using a completely passive cooling. If not for that, i would use vsync opengl and not paying attention to the high temperature, because the GPU frequency raised to the maximum because of the use vsync opengl.

Pretty unexpected it is that even nVidia Ion would suffer from cooling issues, I feel. I recalled how I burnt my GeForce 8400GS a few years ago. That card uses passive cooling, too.

By the way, with vsync opengl i did not notice the tearing in the video in a window, but it still there of fullscreen video (without --unredir-if-possible).

Yep, many reported the same thing in #7: Tearing on the top of the screen. Unfortunately, I'm afraid as far as we still use X Render as backend, what we could do is pretty limited.

Its not problem for me. I do not see a strong flicker. I do not see much of a difference, even if i use -paint-on-overlay. As i recall, it was a flicker in ancient compiz when using "unredirect fullscreen blah-bla-bla". I do not know where things stand now.

When I run Firefox in full-screen mode, then right click, the flickering is pretty obvious. Maybe it's less obvious for video player as the screen content usually changes when you switch in/out of full-screen mode, though.

[Gavcheg]

@richardgv

Could be related to the differences of internal graphic card logics, but maybe you could try upgrading your nvidia-drivers.

I use 304.64 drivers too. Both "Sync to VBlank" checkbox always enabled. Maybe the problem is that it is a slow ion video and my slow atom 330 processor... Anyway, i waiting stable 310 series drivers :)

Pretty unexpected it is that even nVidia Ion would suffer from cooling issues, I feel.

Also, i use "OnDemandVBlankInterrupts" enabled to powersaving..

When I run Firefox in full-screen mode, then right click, the flickering is pretty obvious. Maybe it's less obvious for video player as the screen content usually changes when you switch in/out of full-screen mode, though.

My bad, you right! Screen flickering in full-screen mode. I test opera & pidgin. So, --paint-on-overlay little bit helps but the problem is not completely solved.. I did not notice this, because in full screen mode using only mplayer.

[richardgv]

With the newly added OpenGL backend (8ffcf1c in richardgv-dev branch), I spot a huge performance boost, especially in transparency / color negation handling. The performance of OpenGL backend without --sw-opti is close to the performance of X Render backend with --sw-opti: 24,000 FPS. And it never changes even with costly operations like color negation. (Well, this may not be the case for those with weaker GPUs, though.) I hope this means an end to the performance issues. Yet, really, why can't the FPS exceed 24,000?

[pvanek]

great!

[richardgv]

We have received a mail complaining slowdown using, presumably, 75912d2 from richardgv-dev branch, compared with the version from master branch. I assume he is using XRender backend. He provided too little information for us to trace the problem, unfortunately. Please, if any of you have noticed performance problems that happens on a build of richardgv-dev branch, after 4bc3de81ab (current master), with XRender backend, report back to us.

[richardgv]

Well, I've met a problem regarding the usage of stencil buffer. Originally (at the time I spot 24,000 FPS last time) we aren't using stencil buffer in OpenGL backend, but I later discovered as X Fixes doesn't guarantee the rectangles in a region don't overlap, without using stencil buffer, certain regions may be painted for more than one, break opacity, dimming, and background blur -- this didn't practically happen so far, though. So I started using stencil buffer but kept --glx-no-stencil to restore the old behavior. Yet I just found glxgears and compton --benchmark are reporting different results to me regarding --glx-no-stencil. compton's FPS is roughly 20% lower with --glx-no-stencil, yet when compton is running without --glx-no-stencil, the FPS of glxgears gets extremely low -- like 3,000 sometimes, while with --glx-no-stencil it's a lot more higher... I suspect it has something do with the CPU bottleneck on my system. Well, if any of you discovered performance issues with OpenGL backend, please check if --glx-no-stencil helps.

Update: Did some experiments with cpulimit. I have a 4-core i7 3770K. If it's working as expected, --benchmark 10000, --glx-no-stencil mode: compton process is limited to 50% CPU, X process uses 80% CPU, 8 seconds to draw 10,000 frames; no --glx-no-stencil: compton 50% CPU, X 35% CPU, 11 seconds to draw 10,000 frames. --glx-no-stencil makes painting slower and increases CPU usage. I tried limiting glxgear's CPU usage to 30%, neither compton nor X are using 100% CPU, but glxgears still performs much better with --glx-no-stencil, indicating the issue isn't in CPU... Why when stencil buffer actually reduces workload on GPU according to benchmark above, it has more negative effect on glxgears?

Update 2: With extra optimizations on performance of --glx-no-stencil (a053c0ac64), it now outperforms normal mode for 15% in --benchmark mode. But I still don't know if it's safe to make it the default mode. Also I found with the optimizations glxgears actually runs slower -- presumably because my changes reduced the time waiting for X reply thus increases paint frequency. I guess it probably isn't reliable to measure performance with glxgears...