Font drawing slow from 778a8b177c

[farseerfc]

Font drawing tends to be slow from 778a8b177c commit on my machine.

I upgrade compton recently from AUR of archlinux, and found that it get slow on some applications, especially SublimeText2 editor. Then I cloned the repo manually, checkout each commit as binary search, and finally located the bug was introduced in commit 778a8b177c . I can confirm that the bug was not there in e7da888 .

Sorry I have not enough time to debug inside the source code or describe the problem more accurate.

My setup: HP z800 workstation Archlinux xorg-server : 1.12.4-1 awesome : 3.4.13-1 sublime-text : 2.0.1-2

Do you need more information?

[richardgv]

1. Firstly, I grabbed Sublime Text 2.0.1 and is unable to reproduce your issue. Nor am I enable to notice any slowdown, neither did anybody else report substantial slowdown caused by compton in non-OpenGL operations.
2. Theoretically, this looks like a problem that we either is receiving or handles DamageNotify incorrectly, compton is painting extremely slowly, or we have a timing issue. 778a8b1 is a change about fading, and fading will generally not be triggered when you are just typing text. I believe 778a8b1 may increase the number of painting (but it's actually try to fix the fading issues in previous versions) and increase CPU usage of compton process. I'm unsure how this could be associated with your problem.
3. Could you please try experimenting with different commandline switches / configuration options? Are you actually using fading? You could also try grabbing the latest build from richardgv-dev branch, which corrects some timing issues in fading, and enable --vsync sw option. (Supposedly, this option will reduce the number of painting, although it's doesn't quite do VSync well).
4. It was reported once that Sublime Text 2 renders text slowly with x11-drivers/xf86-video-intel -- but under Kwin. It's not entirely impossible that this has something to do with the performance of your graphic chip/card and driver. Please check if the advices in that thread helps.

[farseerfc]

Thank you for your advice!

I checkout richardgv-dev branch and enabled --vsync sw option, it solved the problem, thank you ! Although without --vsync sw option, drawing gets more slow than master branch.

I used fading, with config -cfCF each time, tested on every commit.

I am using a ATI graph card, with xf86-video-ati installed and enabled only.

lspci | grep VGA 0f:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV620 [ATI FireGL V3700]

[richardgv]

I'm glad that --vsync sw resolves your problem. But I wasn't expecting the 5 commits I pushed to the richardgv-dev branch that has not yet been merged into master branch would have so much negative effects to the performance of compton. It sounds like a pretty fatal issue.

If you have the time (and "a Linux system to play with freely"), it would be helpful if you execute the following commands and show me the dumped output of compton:

$ cd path/to/compton/git/tree
$ git checkout richardgv-dev
# Let compton display DamageNotify events in DEBUG_EVENTS mode
$ sed -i 's/\(ev->type != damage_event + XDamageNotify\)/\1 || 1/' src/compton.c
$ make clean; CFLAGS='-ggdb -DDEBUG_EVENTS -DDEBUG_REPAINT' make
# Then run compton with your usual options, do something that causes the bug
# to appear and dump the output
$ ./compton --config /dev/null -cfCF > /tmp/compton-dump.txt

And I would still recommend you to experiment with different options so I could see where the problem is probably at.

[farseerfc]

I get the following dumps:

dump--vsync_sw.txt dump-c--vsync_sw.txt dump-cfCF--vsync_sw.txt dump-.txt dump-c.txt dump-cf.txt dump-cfCF.txt

And this list is roughly sorted as performance from fastest to slowest, by my feeling. Each file name contains options I switched on. They can be downloaded: https://www.dropbox.com/s/ju0sqp4hymmtmqf/compton-dump.tar.bz2 or http://ge.tt/1lJ4LFP/v/0

During that, I noticed that desktop switch of awesome wm(hiding all window of current tag, show all window of another) is also slow.

I hope this is useful.

[richardgv]

Thanks for all the information you provided, farseerfc.

By reading some of your dump files (not all of them, they are too long!) I'm more inclined to believe that the problem perhaps is not in compton.

The behavior of compton (without --vsync) is to repaint the damaged part of the screen once it receives a report that the content of a window is modified -- more technically, DamageNotify. And after every paint it waits for all painting operations to finish with XSync(), so if compton paints at an extremely fast pace, it's comprehensible that all things appear changing much more slowly than expected.

And from your dumped output I see your Sublime Text 2 window ("~/Dropbox/projects/fica/view.py (farseerfc) - Sublime Text 2 (UNREGISTERED)") and another window named "AlwaysAngela" is sending out DamageNotify at a rather ridiculous pace, forcing compton to repaint once every 1/300 second, sometimes even faster. I ran Sublime Text 2 on my own system, and it seemingly is sending out DamageNotify rapidly, too, although somewhat less usually than your case.

Oh, do the windows named "AlwaysAngela" and "火星大气研究群" belong to a QQ session running in Wine? Considering QQ is, well, can't say it's designed too great, it is not impossible that there's a problem in its design or a problem when it communicates with wine, that eventually cause it to send DamageNotify too fast.

The reason I couldn't reproduce this problem might be the fact that my nVidia GTX 670 + binary blob has far superior performance than your ATI FirePro V3700 + open-source driver. Oh, I wish I have my old computer with VIA UniChrome Pro at hand...

I do see some consecutive paints without events in your dump log (the true sign of a possible issue), but considering their small number I guess they come from the fading process.

Overall, it's pretty possible that the problem is caused by the design of Sublime Text 2 and your "AlwaysAngela" window, I would say. Why would this be related to 778a8b1 is what I do not know. In my test e7da888 paints with the identical pace that current richardgv-dev branch does. We may get something if I can see your dumped output of e7da888 (the last commit before you think the problem gets worse).

Another probability is you have a window that is doing heavy graphical tasks, that drains the power of your GPU. The chances are small, though.

By the way, currently -F == -f, so compton -cfCF should actually be faster than compton -cf, well, very slightly.

[farseerfc]

Thank you

Sorry for using wine-qq (and also wine tweetdect) without mentioning that. But I thought wine-qq has little effect to this problem because I experienced the same problem without wine-qq running during last week.

This time I turned all most all unrelated windows off and I get 3 dumps:

dump2-cfCF.txt dump2-cfCF--vsync_sw.txt dumpold-cfCF.txt

last one by doing

$ git checkout e7da888
$ make clean; CFLAGS='-ggdb -DDEBUG_EVENTS -DDEBUG_REPAINT' make
$ ./compton -cfCF >  dumpold-cfCF.txt

https://www.dropbox.com/s/wevapga2gjg96fi/compton-dump2.tar.bz2 or http://ge.tt/5xeIiJP/v/0

dump2 are still from HEAD of richardgv-dev branch, dumpold is from e7da888 , all with -cCfF enabled.

Hope that will help you improve compton, I am loving this compositor. Thank you very much.

[richardgv]

Thanks for your support.

I did a test myself, wrote a bash script to execute a command for a specific amount of time, and measure how many paints occured in the debugging output. The result:

With a bunch of windows open (Firefox, conky, multiple gVim), doing nothing: 20 seconds, commit e7da888, compton -cCfF: 59 paints 20 seconds, current richardgv-dev, compton -cCfF: 62 paints, 34 DamageNotify

With the windows above and a focused Sublime Text 2.0.1 window (the problem seemingly does not appear when Sublime Text 2 window is not focused), doing nothing: 20 seconds, commit e7da888, compton -cCfF: 335 paints 20 seconds, current richardgv-dev, compton -cCfF: 325 paints, 300 DamageNotify

In your test results: dumpold-cfCF.txt, time unknown (somewhere around 7 seconds, I guess): 1414 paints dump2-cfCF.txt, about 7 seconds: 524 paints dump2-cfCF--vsync_sw.txt, 7 seconds, 201 paints And 9 identical windows are painted each time in both files, although with different orders.

So, it all points to one direction, that Sublime Text 2 window is sending DamageNotify at extremely high pace, forcing compton to paint and paint and paint and paint. e7da888 paints even more than frequently than current version. I don't know why e7da888 seemingly does not have this problem.

The reason Sublime Text 2 constantly updates its window when it's focused but idling (i.e. no typing) is probably the design of the fading blinking cursor. But the speed of DamageNotify when idling does not look high enough here to trigger the issue.

I noticed some behaviors of Sublime Text 2 window: When you type a letter it sends a DamageNotify, and after a very short period of time (< 0.0001 second) it sends another one, forcing compton to repaint twice. If you have minimap or statusbar enabled, the window might try to paint for more than twice for a single letter. This is closely tied to timing: if the kernel lets Sublime Text 2 use more CPU time, or compton itself takes more time processing events, compton could catch both DamageNotify before one paint; otherwise compton will have to paint twice. However, this should result in the old compton paints less than the new compton when you are constantly typing (you are typing when dumping the results, right? You must obtain the dump file when you are doing the things that could make compton reacting slow.), and in your dump file the situation is the exact opposite.

I've tried dumping the region each paint changes from the old and the new version, and they are roughly identical here.

Also, please execute the sed line on the old version, too, so I can see the time when compton receives DamageNotify.

[farseerfc]

Thank you for your explanation. Sorry for my description be not so clear and also sorry for missed sed.

I was actually doing scrolling during tests. I opened a long enough file with thousands lines, then scrolling using middle wheel of mouse, or scrolling by dragging minimap. And yes, I enabled minimap. It was slow when scrolling inside a long enough file.

I am currently away from the machine I used, and I will report a new dump with sed executed when I am back to office. Thank you.

[farseerfc]

Here is the 3rd dumps: http://ge.tt/8oYk2OP/v/0 with: dump3-cfCF.txt dump3-cfCF--vsync_sw.txt dumpold3-cfCF.txt

with sed command processed in e7da888 , generating dumpold3, comparing with HEAD of richardgv-dev

Hope that will help you

Thank you

[richardgv]

I still could not see anything interesting. But I thought about another thing: paint_preprocess(), added in e7da888, might be taking too long time on your system (although it really shouldn't happen if there's not a window chaging opacity before paint). I will see if implementing my plan here about pregenerating alpha pictures helps -- but not right now, when I have 5 days before a big exam. Sorry, but you most likely won't see me working on this any time sooner than a week later.

[richardgv]

Clone richardgv-dev and test, please. I've pushed the alpha picture pregeneration. It shouldn't affect your issue. But if it does, we might get one more hint about what the hell is wrong.

I realized cdf7db750d definitely decrease performance much. I will try revoking it after I finish my exam. But still I have no idea what is actually causing your issue.

[richardgv]

I've finished my exam. Although I did pretty bad in the test, I at least got more time to work on compton recently. Clone richardgv-dev and test, please. I hope b78ab316fd could be proved a fix for your problem. However, please also tell me if 07e4420ab4 is helping in any ways.

According to my test, b78ab316fd introduces an aggressive boost in CPU usage of the X process under heavy work. Whether it is helpful to reduce GPU load is not entirely clear. glxgears test reveals highly varied results: Sometimes I get as high as 18000 FPS (it was 6000 FPS beforehand when compton is running), sometimes 2000 FPS.

I've being successful in neither reducing the power of my graphic card nor monitoring its exact usage ratio, unfortunately. It's something I truly cannot understand that why nvidia-smi does not allow me to see the usage ratio on such an expensive card. So, so far I'm still not able to reproduce or even notice your issue.

I've taken #compton on FreeNode. Although synchronous communication (i.e. chat) has been proved as one of the biggest time waster in the world, it's more effective than asynchronous communication in some cases, still. I would prefer if somebody experiencing the performance issue could come to the channel, I have a few questions to ask. I have no idea why people seemingly have the tendency to ignore my questions if I ask them in a reply to an issue report.

My next step plan is to either completely revert to the pre-cdf7db750d method to reduce CPU load, or use a hash table based system to do it, depending on feedback from you and ichi-no-eda. And, I want to cut the support for HAS_NAME_WINDOW_PIXMAP = 0, can't maintain it and can't see what it is still good for today.

[farseerfc]

Sorry for being absent for such a long time.

I cloned the recent richardgv-dev and it fixed my problem. And I checked b78ab31 too, it also fixed the problem. Although I can not figure out what solved that.

Thank you very much, thank you for all these efforts helping me debugging in this issue that seems only happened on my own machine.

I think I should close this issue as well.

Thank you again.