[SOLVED-the issue was NOT related to Compton]

I`ve finally managed to install a kernel that goes well with my hardware and Waldorf. Siduction 3.6-8. But regardless of which kernel I use, I have issues with compositing. In the default autostart file, compositing gets started right after nitrogen restores wallpaper. If I use this startup sequence then compton doesn`t work properly. Icons get ugly with artifacts and stripes, and often the background colors on the icons is missing. As with Thunar. Just a hammer on white background. If I disable compositing or restart it then it displays the icon properly, but then I have to restart compositing for each icon that I open in the taskbar...

After trying and failing I found a workaround. If I delay the startup of compton to 10 seconds behind everything else, then compositing works fine, and all icons are displayed properly. And it sticks. No need to restart compositing...

But because I`m working on a setup with a second tint2-panel that is manually started through a button, and is opened and closed frequently, then this workaround isn`t good enough. Because I get the same compositing issue. It seems like Compton is having trouble if a tint2 panel is started while Compton is already running.

What could cause this? I need to be able to start tint2-panels on demand, AFTER startup, because i`m only starting the taskbar and systray during startup. The rest gets activated when I want and need them:)

I have read that there has been a issue with Compton being uncompatible with VLC, and VLC is back in the image I installed from, but I can`t imagine that such a bug in either VLC or Compton should cause the issues that I have with Compton and Tint 2. So what could this be? And how to solve it?

Re: [SOLVED-the issue was NOT related to Compton]

Update #4: Again, if you are indeed talking about corruption in tint2 window: I think it may be related to your icon theme or icon size. Maybe you could try switching to a different icon theme, and use a standard icon size (16x16 should be guaranteed to be present).

Update #3: I saw your screenshot in "February 2013 Screenshot Thread". Just a small note, about the big ugly shadow on your CPU/MEM monitor window: You may use --shadow-exclude in compton to disable shadow on specific windows. -C and window-type specific settings in compton configuration file may be helpful as well.

Update #2:

Oh, wait, I guess I'm looking at a different problem. I found fcitx sometimes leaves a broken icon on systray that show up with random content, on tint2. Other applications may do the same?

Also, if you are indeed talking about corruption that appears in tint2 window: looking into tint2's source code reveals tint2 behaves different when there is a compositor (./src/server.c, line 360, server_init_visual(), and src/tint.c, line 1199 (search _NET_WM_CM_S0 in the file)): It uses an ARGB 32-bit visual when there's a compositor, and uses a 24-bit visual when there isn't. This means, a bug in tint2 may actually cause graphic corruptions that appear only when a compositor is running. If you think it's possible, please tell us the version of tint2 you use, and show us the configuration file. A good way to verify if it's actually a problem in compton is to check if the issue appears with Compiz or cairo-compmgr. They use entirely different mechanisms and Compiz, specifically, is much more mature than compton.

Update: I grabbed tint2 from SVN, and seemingly there's indeed a problem! Looking into this...

Crunchbang may come with a rather outdated build of compton. Please try to build compton from our Git repo directly (use richardgv-dev branch if possible). My personal PPA contains newer DEB packages (not necessarily the latest) for Ubuntu, that may or may not work for Crunchbang.

Please try to run compton with all options off, and see if the problem is still reproducible.:

compton --config /dev/null

It feels like you are complaining about corruption in tint2 window, right? I don't see you mentioning "tint2" in the whole first paragraph, and I feel uncertain about what you meant. If it's tint2 indeed, then in it's happening in taskbar, or systray, or both.

When the issue appears, try moving a window over the region that looks wrong, or switch to a virtual console then back, to force compton to do a repaint, and see things changes.

A screenshot of the problem might be helpful for diagnostics, as well.

Some kernel options, Xorg options, or driver options may have effects on compton's operation. Please check if you have some extraordinary setups (e.g. multiple monitors, rotated screen, special OpenGL settings, user patches).

As a general rule, please tell us the WM you use, its version, your GPU, and version of your X driver, OpenGL engine, the application window(s) that exhibits the problem, and all programs that creates overlay windows on your screen, if any.

If possible, check if the corrupted windows have some strange attributes, e.g. if it's semi-transparent, an ARGB window, or have non-rectangular shapes.

You meant it happens with xcompmgr, too, right? Have you tried other compositors (cairo-compmgr, unagi, Compiz)?

I'm a tint2 user myself -- tint2-0.11, I will try the svn version later -- and never once had I meet a problem. I tried executing compton right after `nitrogen --restore`. Nothing strange, as far as I could see. And I've never seen a similar report.

If your compton version is new enough, sending compton a SIGUSR1 will cause it to reset itself, if you need a temporary workaround.

Re: [SOLVED-the issue was NOT related to Compton]

I will take a look at it later. If I`m going to dive in so deep, then I need a bit of time. So far I`ve worked around the problem, and I see the shadows you are talking about, but I`m not sure that I want crisp edges. I`ll try it though...

As for Compiz, I have no issues in Ubuntu 12.10, but haven`t tried it with Crunchbang. I will report back when I`ve tried your suggestions...

Update. I have reproduced the by starting compton before the tint2-panels. It looks like this: Screenshot below...

Re: [SOLVED-the issue was NOT related to Compton]

I got pretty little information about this issue so far. You didn't even tell me the version of your tint2. I fully understand you may be tight in time when replying. However, I would expect you to read my all my replies carefully and provide all, or at least most of, the information I've asked for, before you post next reply.

I've edited my previous reply for a few times, and please make sure you have read the "update" sections of it.

A compositor doesn't operate on specific parts of a window, so in general, a problem in compositor will exhibit as corruptions of a whole window, or a part of a window that just get changed. From your screenshot I see this is probably not the case. And as what I've said, tint2 behaves differently when there's a compositor present (it uses true transparency when there's a compositor, false transpareny otherwise). And the issue appears with xcompmgr, too, right? If I were in your shoes, the first thing I would suspect is tint2, not compton.

In addition to the suggestions I mentioned previously, please also try dragging taskbar icons around in tint2. It's very likely a tint2 bug if the icon doesn't get back to norm after being moved.

Re: [SOLVED-the issue was NOT related to Compton]

RichardGv wrote:

I got pretty little information about this issue so far. You didn't even tell me the version of your tint2. I fully understand you may be tight in time when replying. However, I would expect you to read my all my replies carefully and provide all, or at least most of, the information I've asked for, before you post next reply.

I've edited my previous reply for a few times, and please make sure you have read the "update" sections of it.

A compositor doesn't operate on specific parts of a window, so in general, a problem in compositor will exhibit as corruptions of a whole window, or a part of a window that just get changed. From your screenshot I see this is probably not the case. And as what I've said, tint2 behaves differently when there's a compositor present (it uses true transparency when there's a compositor, false transpareny otherwise). And the issue appears with xcompmgr, too, right? If I were in your shoes, the first thing I would suspect is tint2, not compton.

In addition to the suggestions I mentioned previously, please also try dragging taskbar icons around in tint2. It's very likely a tint2 bug if the icon doesn't get back to norm after being moved.

I`m sorry, but I have never reported a issue with Compton. I have just asked a general question here at Crunchbang, asking if anyone know what could cause this, and I have never said that it`s a Compton-issue. That`s the reason why I haven`t reported the issue upstream, because I have the same issue with xcompmgr, and the issue is just with Tint2. I also have installed Waldorf on an older laptop, and there I have no issues with Compton and Tint. The issue is only on this new ivybridge pc, and I have a lot of issues with the ivybridge graphics and linux in general. 3.2 kernel freezes, 3.5 and 3.6 is fine, but when I go to 3.7 kernels it doesn`t boot....

So you see, I haven`t supplied the info that you request, because it was never my intention to report a issue to you. Then I think it`s kind of rude to expect me to supply you with anything, and even worse to tell me how and when I can reply in my own thread. I`ve never asked you to reply or assist me in any way, so there`s no need for the tone in your replys....

Re: [SOLVED-the issue was NOT related to Compton]

ew wrote:

I`m sorry, but I have never reported a issue with Compton. I have just asked a general question here at Crunchbang, asking if anyone know what could cause this, and I have never said that it`s a Compton-issue. That`s the reason why I haven`t reported the issue upstream, because I have the same issue with xcompmgr, and the issue is just with Tint2. I also have installed Waldorf on an older laptop, and there I have no issues with Compton and Tint. The issue is only on this new ivybridge pc, and I have a lot of issues with the ivybridge graphics and linux in general. 3.2 kernel freezes, 3.5 and 3.6 is fine, but when I go to 3.7 kernels it doesn`t boot....

So you see, I haven`t supplied the info that you request, because it was never my intention to report a issue to you. Then I think it`s kind of rude to expect me to supply you with anything, and even worse to tell me how and when I can reply in my own thread. I`ve never asked you to reply or assist me in any way, so there`s no need for the tone in your replys....

Oops, I'm truly sorry. I'm a very awkward person in socialization, and somehow specialized in annoying others when I'm just trying to provide some help...

I got the impression that you are complaining about a bug in compton because of your title "Compton/Xcompmgr issue", some of the expressions you used ("compton doesn`t work properly", "Compton is having trouble if...") and the mentioning of another compton bug. Honestly I was initially even a bit puzzled, because I don't even see tint2 being mentioned in the first two paragraphs. And the word compton is mentioned much more frequently in your thread than "tint2" indeed. Well, looks like I'm seriously misunderstanding this, anyway...

Also, hmm, maybe you could try thinking from my position. After spending quite many hours into midnight looking into an issue, and replying with almost 900 words / over 5,000 characters, you won't really be happy if you find your advices are not followed, and you don't even receive a "thanks", will you? Oh, look, I'm not blaming you. Just, please consider my feelings as well, if you are willing.

And, I'm still willing to help, even though this probably isn't an issue of compton, but to proceed further I would really need more information.

And another thing: If the corruption does not disappear when you move windows over it to force a repaint, or when you drag the task item to change its position, I'm more inclined to believe this is a bug in tint2, unrelated to your graphic chip. I heard graphic driver faults may lead to corrupted text rendering, though.

By the way, I asked a few of my friends, using both tint2 and compton, and they said they haven't encountered similar things.

Re: [SOLVED-the issue was NOT related to Compton]

RichardGv wrote:

[And, I'm still willing to help, even though this probably isn't an issue of compton, but to proceed further I would really need more information.

And another thing: If the corruption does not disappear when you move windows over it to force a repaint, or when you drag the task item to change its position, I'm more inclined to believe this is a bug in tint2, unrelated to your graphic chip. I heard graphic driver faults may lead to corrupted text rendering, though.

By the way, I asked a few of my friends, using both tint2 and compton, and they said they haven't encountered similar things.

Ok. When I look at my initial post, I see how you could read it that way. It was never my intention to blaime Compton, because it`s working fine for me with other installs. Even with Waldorf on a 10 year old Toshiba. I just wanted to know if anyone maybe had experienced this, and maybe knew what could cause it. It was never my intention to start a big issue and have anyone using a lot of time and resources to solve it for me. But I agree with you, It`s more likely to be a Tint2 issue, than a Compton issue.

Also, english is not my native language, and i guess that could cause that something is concieved in another way than what was intended. I also see your need for more detailed information, but I`m a linux-newbie, and a lot of the things you ask me for, is brand new for me. I don`t compile stuff, and i don`t know how to find all the info you ask of me. So, therefore I just said that it would take me some time to provide such info. I`m at a stage where I learn new things as I need to, and many things are new to me. I`ve used Windows all my life, and first started to look at linux a short time ago...

So I`m sorry we misunderstood each other, and I would have supplied you with more info in my reply, but I didn`t have the time to look into it at that time, and my reply was mainly to inform you that it would take some time to do so. I`ve hardly been able to startup my pc the last days. You know, the usual things. Work, familiy, projects in the house, and I also traveled to fetch a new puppy yesterday, which kept me up and going all night. I will try to look further into it when I get the time, perhaps tonight, if our new puppy has settled a bit.... But I just haven`t had the time yet.

By the way, I just found out how to check for version in linux, and it reports that it is: Tint2-652M. Compton doesn`t recognize the "--version" option, so I haven`t got a clue how to find that. I will google for it.

Update:Quote: "And another thing: If the corruption does not disappear when you move windows over it to force a repaint, or when you drag the task item to change its position, I'm more inclined to believe this is a bug in tint2, unrelated to your graphic chip."==> Tried this, and the corruption doesn`t disappear either when moving windows over it, or when I drag the task item to a new desktop. Then it isn`t my graphic chip that cause this...

I also noticed that the synaptic-icon doesn`t get corrupted. Neither does the vlc-ikon, and now I see that the xchat-icon also is displaying properly, so I guess that it`s now up to me to find what the icons that works have in common, and what separates them from all those that doesn`t work. Me and Vastone have earlier found issues with Tint2 in regards to displaying the correct icon according to the set icon theme for the system. Tint2 follows the theme for some icons, but for other icons Tint2 seames to have a mind of it`s own, and it`s quite difficult to find out where tint2 actually is getting the icons from... I will add more as I get time to check it. Now I have to take care of my new puppy:)

Re: [SOLVED-the issue was NOT related to Compton]

ew wrote:

By the way, I just found out how to check for version in linux, and it reports that it is: Tint2-652M. Compton doesn`t recognize the "--version" option, so I haven`t got a clue how to find that. I will google for it.

The most common command line options to get a programs version are "-v", "--version", and "-version".Some programs print their version in their help command which is commonly "-h", or "--help".The help command usually will tell you what the version command is for that program if it has one.

ew wrote:

but for other icons Tint2 seames to have a mind of it`s own, and it`s quite difficult to find out where tint2 actually is getting the icons from... I will add more as I get time to check it. Now I have to take care of my new puppy:)

You can run a program through strace to see what files it opens or accesses.

strace "command you normally start tint2 with"

That should let you see where it is loading the icons from.

strace outputs a lot of data so you probably want to redirect its output to a file so you can read it in a text editor.

Re: [SOLVED-the issue was NOT related to Compton]

Update: Oh, I forgot to say: The impression of the vertical tint2 bar in your screenshot gives me is, the alpha channel of some icons are messed up, and the the garbage inside the area that should be fully transparent are rendered out -- but strangely enough, even in a single icon, only alpha channel of some areas are lost, but not all. And the horizontal tint2 on the top seemingly suffered from some weirder corruptions. Maybe you could find something by comparing the configuration files of those two tint2 bars? In particular, I suspect it has something to do with icon alpha, saturation, and brightness settings in tint2.

ew wrote:

Also, english is not my native language, and i guess that could cause that something is concieved in another way than what was intended.

I also see your need for more detailed information, but I`m a linux-newbie, and a lot of the things you ask me for, is brand new for me. I don`t compile stuff, and i don`t know how to find all the info you ask of me. So, therefore I just said that it would take me some time to provide such info. I`m at a stage where I learn new things as I need to, and many things are new to me. I`ve used Windows all my life, and first started to look at linux a short time ago...So I`m sorry we misunderstood each other, and I would have supplied you with more info in my reply, but I didn`t have the time to look into it at that time, and my reply was mainly to inform you that it would take some time to do so. I`ve hardly been able to startup my pc the last days. You know, the usual things. Work, familiy, projects in the house, and I also traveled to fetch a new puppy yesterday, which kept me up and going all night. I will try to look further into it when I get the time, perhaps tonight, if our new puppy has settled a bit.... But I just haven`t had the time yet.

Oops, I thought you are a very experienced Linux user, because of your post count, and because Crunchbang is a rather advanced distro. And that's why I was expecting you to tell us the version of your tint2 instantly in the previous reply. Hmm, guess I just provided too little info for you, then.

ew wrote:

By the way, I just found out how to check for version in linux, and it reports that it is: Tint2-652M. Compton doesn`t recognize the "--version" option, so I haven`t got a clue how to find that. I will google for it.

I think "652M" might mean SVN revision 652, which seemingly is indeed the latest revision of tint2 right now on Google Code. However, I believe normally tint2 --version prints "tint2 version 0.11-svn" if it's built from SVN (both the version I built myself and gotten from packages.crunchbang.org do so). Huh, maybe you could get a more accurate version number by querying the package manager?

Anyway, you could try downgrading tint2 to the latest stable version (0.11), and see if anything changes.

compton doesn't have a --version option. Since git revision 3521f10a97, compton could print out the Git revision hash in the output of compton -h / --help; before the point, it just prints "compton (development version)". Apparently, you are using a version older than the point. Your package manager probably could reveal the date of the snapshot you are using.

ew wrote:

Update:Quote: "And another thing: If the corruption does not disappear when you move windows over it to force a repaint, or when you drag the task item to change its position, I'm more inclined to believe this is a bug in tint2, unrelated to your graphic chip."==> Tried this, and the corruption doesn`t disappear either when moving windows over it, or when I drag the task item to a new desktop. Then it isn`t my graphic chip that cause this...

I see... As far as I could see, tint2 fetches task / window icons in the same way regardless of whether there's a compositor, or to say, whether tint2 is using real transparency or false transparency. Nonetheless, with real transparency on, tint2 uses X Render to render the icon (./src/util/common.c, render_image(), line 326); with false transparency, it uses imlib_render_image_on_drawable() for rendering. Tint2 seemingly internally caches pictures of areas, and icon area of a task is a separate area, thus once an icon is drawn, the render result will possibly not be refreshed until the icon changes. So, the problem is more likely in the rendering process, and it may have something to do with X Render. I'm not completely sure, but I heard X Render uses the functions from your graphic driver to render things sometimes. Hmm, is this a bug in tint2, a bug in compton, a bug in X Render, a bug in the icon theme, or a bug in your graphic driver?

And, I was a bit puzzled by your description in the first post: "If I delay the startup of compton to 10 seconds behind everything else, then compositing works fine" means starting compton after tint2 fixes the issue, right? But later I saw "It seems like Compton is having trouble if a tint2 panel is started while Compton is already running". So, have I misunderstood something? Does the problem occur when compton is started after tint2, or before tint2?

I think the most direct way to figure out what's wrong is to insert debugging code to tint2. Well, but I guess it isn't a fun thing for you.

ew wrote:

I also noticed that the synaptic-icon doesn`t get corrupted. Neither does the vlc-ikon, and now I see that the xchat-icon also is displaying properly, so I guess that it`s now up to me to find what the icons that works have in common, and what separates them from all those that doesn`t work. Me and Vastone have earlier found issues with Tint2 in regards to displaying the correct icon according to the set icon theme for the system. Tint2 follows the theme for some icons, but for other icons Tint2 seames to have a mind of it`s own, and it`s quite difficult to find out where tint2 actually is getting the icons from... I will add more as I get time to check it. Now I have to take care of my new puppy:)

As far as I know, tint2 (SVN r652) retrieves the icon of a window from its _NET_WM_ICON property. If it couldn't find _NET_WM_ICON property on a window, it gets the icon from icon_pixmap field in WM_HINTS property. If it fails in this step, it uses a default icon. (./src/taskbar/task.c, get_icon(), line 213, in SVN r652). It then adjusts icon size, opacity, etc. with imlib2, and render with X Render or imlib2. Correct me if I'm wrong, please. So, I'm not really sure, but I assume tint2 asks the application for icon, and it displays the icon according to the theme if the application does so, otherwise it just displays whatever the application provides. It's another thing for launcher icons in tint2, which probably lookup icons in icon theme directory firstly, but I believe you are talking about task / window icons, right?

Oh, and have you tried changing icon theme to a safe fallback (e.g. GNOME icon theme), and adjusting the panel height to change icon size? Also, probably you could try resetting task icon settings (alpha, saturation, and brightness) in tint2 to their default values.

Re: [SOLVED-the issue was NOT related to Compton]

arclance wrote:

ew wrote:

By the way, I just found out how to check for version in linux, and it reports that it is: Tint2-652M. Compton doesn`t recognize the "--version" option, so I haven`t got a clue how to find that. I will google for it.

The most common command line options to get a programs version are "-v", "--version", and "-version".Some programs print their version in their help command which is commonly "-h", or "--help".The help command usually will tell you what the version command is for that program if it has one.

ew wrote:

but for other icons Tint2 seames to have a mind of it`s own, and it`s quite difficult to find out where tint2 actually is getting the icons from... I will add more as I get time to check it. Now I have to take care of my new puppy:)

You can run a program through strace to see what files it opens or accesses.

strace "command you normally start tint2 with"

That should let you see where it is loading the icons from.

strace outputs a lot of data so you probably want to redirect its output to a file so you can read it in a text editor.

strace "command you normally start tint2 with" >> file.txt

Thanks. There is a lot of text, and it seems like tint2 sometimes fetches the icons from my set theme, and other times from pixmap and the gnome-hicolor theme. It will take a while to debug, but thanks for leading me in the right direction. strace will be most helpful to me.

Re: [SOLVED-the issue was NOT related to Compton]

Also, you didn't reply to my last reply. Is there anything in my last reply that was written badly and you couldn't understand, or something else?

Regarding the source of icons, shall I repeat here, just in case: If you are talking about window / task icons in tint2 instead of launcher icons: as far as I know, tint2 does not read window / task icons from any a file, it reads those things from X window property, as what I said previously:

RichardGv wrote:

As far as I know, tint2 (SVN r652) retrieves the icon of a window from its _NET_WM_ICON property. If it couldn't find _NET_WM_ICON property on a window, it gets the icon from icon_pixmap field in WM_HINTS property. If it fails in this step, it uses a default icon. (./src/taskbar/task.c, get_icon(), line 213, in SVN r652). It then adjusts icon size, opacity, etc. with imlib2, and render with X Render or imlib2. Correct me if I'm wrong, please. So, I'm not really sure, but I assume tint2 asks the application for icon, and it displays the icon according to the theme if the application does so, otherwise it just displays whatever the application provides. It's another thing for launcher icons in tint2, which probably lookup icons in icon theme directory firstly, but I believe you are talking about task / window icons, right?

If you are talking about launcher icons in tint2 (but you haven't mention the word "launcher" in this thread, have you?), they are read from theme directories indeed. icon_path() and scale_icon() in ./src/launcher/launcher.c are used to search for the icons and read them (in a rather ugly way).

There's another little thing I would like to say. Well, just in case you don't know this. As far as I know, strace outputs things to stderr instead of stdout, so using ">>" redirection operator on strace, is not going to work. (I mean, arclance possibly made a small mistake in his reply). You have to use "&>" or "2&>1 >":

strace tint2 &> /tmp/out.txt
strace tint2 2&>1 > /tmp/out.txt

An additional point: Could you please try sending SIGUSR1 to tint2 process when the issue appears, and see if anything changes?

Re: [SOLVED-the issue was NOT related to Compton]

RichardGv wrote:

Update: Oh, I forgot to say: The impression of the vertical tint2 bar in your screenshot gives me is, the alpha channel of some icons are messed up, and the the garbage inside the area that should be fully transparent are rendered out -- but strangely enough, even in a single icon, only alpha channel of some areas are lost, but not all. And the horizontal tint2 on the top seemingly suffered from some weirder corruptions. Maybe you could find something by comparing the configuration files of those two tint2 bars? In particular, I suspect it has something to do with icon alpha, saturation, and brightness settings in tint2.

==> I will definately look into that and report back.

"Oops, I thought you are a very experienced Linux user, because of your post count, and because Crunchbang is a rather advanced distro. And that's why I was expecting you to tell us the version of your tint2 instantly in the previous reply. Hmm, guess I just provided too little info for you, then."

==> Nope, I`m a newbie at linux. Very experienced with MS and Windows, but was getting bored by it, and didn`t like the direction that MS is going with W8 and Modern UI, therefore I`m migrating to Linux. The reason why I started with Crunchbang was that My laptop at the time was old and needed a fast lightweight distro, and I found Crunchbang very fast, and in addition here is a very friendly and helpful community. Not like many other forums that do their best to scare away the newbies:)

I think "652M" might mean SVN revision 652, which seemingly is indeed the latest revision of tint2 right now on Google Code. However, I believe normally tint2 --version prints "tint2 version 0.11-svn" if it's built from SVN (both the version I built myself and gotten from packages.crunchbang.org do so). Huh, maybe you could get a more accurate version number by querying the package manager?

Anyway, you could try downgrading tint2 to the latest stable version (0.11), and see if anything changes.

compton doesn't have a --version option. Since git revision 3521f10a97, compton could print out the Git revision hash in the output of compton -h / --help; before the point, it just prints "compton (development version)". Apparently, you are using a version older than the point. Your package manager probably could reveal the date of the snapshot you are using.

==> I will also look into that. And come back with a cleaner reply of where I am in the process, and what I`ve figured out.

I see... As far as I could see, tint2 fetches task / window icons in the same way regardless of whether there's a compositor, or to say, whether tint2 is using real transparency or false transparency. Nonetheless, with real transparency on, tint2 uses X Render to render the icon (./src/util/common.c, render_image(), line 326); with false transparency, it uses imlib_render_image_on_drawable() for rendering. Tint2 seemingly internally caches pictures of areas, and icon area of a task is a separate area, thus once an icon is drawn, the render result will possibly not be refreshed until the icon changes. So, the problem is more likely in the rendering process, and it may have something to do with X Render. I'm not completely sure, but I heard X Render uses the functions from your graphic driver to render things sometimes. Hmm, is this a bug in tint2, a bug in compton, a bug in X Render, a bug in the icon theme, or a bug in your graphic driver?

==> Same as above. Will come back with more info, but have figured out that the icons that Tint2 fetches from image files in "pixmaps" is displayed correctly, while the other icons gets distorted...

And, I was a bit puzzled by your description in the first post: "If I delay the startup of compton to 10 seconds behind everything else, then compositing works fine" means starting compton after tint2 fixes the issue, right? But later I saw "It seems like Compton is having trouble if a tint2 panel is started while Compton is already running". So, have I misunderstood something? Does the problem occur when compton is started after tint2, or before tint2?

==> The problem only occurs when Compton is started before Tint2. In other words it looks like Tint2 messes it up.

As far as I know, tint2 (SVN r652) retrieves the icon of a window from its _NET_WM_ICON property. If it couldn't find _NET_WM_ICON property on a window, it gets the icon from icon_pixmap field in WM_HINTS property. If it fails in this step, it uses a default icon. (./src/taskbar/task.c, get_icon(), line 213, in SVN r652). It then adjusts icon size, opacity, etc. with imlib2, and render with X Render or imlib2. Correct me if I'm wrong, please. So, I'm not really sure, but I assume tint2 asks the application for icon, and it displays the icon according to the theme if the application does so, otherwise it just displays whatever the application provides. It's another thing for launcher icons in tint2, which probably lookup icons in icon theme directory firstly, but I believe you are talking about task / window icons, right?

==> Ok. That shared som light on the issue. Because Icons that are present as image files in "pixmap" is displayed correctly. And yes, I`m talking about task icons, but also launcher icons... Perhaps there`s aanother mechanism for the launcher-icons?

Oh, and have you tried changing icon theme to a safe fallback (e.g. GNOME icon theme), and adjusting the panel height to change icon size? Also, probably you could try resetting task icon settings (alpha, saturation, and brightness) in tint2 to their default values.

==> Will try those things. This reply is just to let you know that I am looking into it, and will report back when I I have covered some ground in debugging this issue:)

Re: [SOLVED-the issue was NOT related to Compton]

RichardGv wrote:

There's another little thing I would like to say. Well, just in case you don't know this. As far as I know, strace outputs things to stderr instead of stdout, so using ">>" redirection operator on strace, is not going to work. (I mean, arclance possibly made a small mistake in his reply). You have to use "&>" or "2&>1 >":

That might be right I did not have time to check when I wrote my last reply.

Re: [SOLVED-the issue was NOT related to Compton]

I haven`t gotten around to it yet, but to clear up any confusion about task icons and launcer icons. The vertical bar to the left contains only launchers, and have no other function. The horisontal bar at the top, is the default tint2bar that comes with Waldorf. It contains taskbar, systray. clock and battery. No launchers in that bar... I will add stuff to this post, as I have any thing to report... I have a little bit of time right now, but I don`t know how long it lasts. When the puppy wakes up again, then I have to take care of her. Housebreaking her you know. Have to watch her 24/7:)

Yes, by downgrading to tint2-0.11 you lose the launcher, at least. But I'm just asking you to do this temporarily to help figuring out the source of the issue.

I tried applying all the 3 patches on r652, and I still couldn't reproduce the issue.

You are right, the output of "tint2 -v" with a version built from SVN should be "tint2 version <SVN revision>". I got "tint2 version 0.11-svn" because my package manager (Portage) doesn't build tint2 from the SVN directory directly.

By the way, it's generally recommended to tell us on the first moment if you are using development snapshots or custom patches. They are particularly likely to have bugs.

ew wrote:

And, I was a bit puzzled by your description in the first post: "If I delay the startup of compton to 10 seconds behind everything else, then compositing works fine" means starting compton after tint2 fixes the issue, right? But later I saw "It seems like Compton is having trouble if a tint2 panel is started while Compton is already running". So, have I misunderstood something? Does the problem occur when compton is started after tint2, or before tint2?

==> The problem only occurs when Compton is started before Tint2. In other words it looks like Tint2 messes it up.

Actually tint2 tries to detect changes in compositor status: whenever it detects a change in _NET_WM_CM_S0 (A symbol of presence of a compositor, defined in EWMH standard), it resets itself. (./src/tint.c) But there's one bug in tint2, that it could detect when a X compositor is stopped, but cannot detect when a X compositor is started. (I did a brief Google search, and didn't find how notifications of X Selection changes are performed. Maybe it's entirely impossible to detect X Selection changes without polling periodically.) The result is:

If there's a compositor running when tint2 starts, but the compositor later quits, tint2 could detect the event, and switch to false transparency.

Once tint2 goes into false transparency mode, it never goes to true transparency, even if you start a compositor later.

So, if the problem appears when tint2 is started after compton, but does not appear in the opposite order, I believe this means the issue appears whenever tint2 uses true transparency -- Well, wait, we know that fact already, don't we?

Really, true transparency is not the most useful feature in tint2. If you don't need the feature, and wants a quick & dirty fix, this is a patch that disables true transparency in tint2, forever and ever: (The patch is for tint2 SVN r652.)

If you really need the true transparency feature and does not like my dirty patch... Well, I found asynchronous communication rather inefficient, because I spend too much time guessing what you mean/want or what's happening on your side. Do you usually stay in some IRC channels? Maybe you could try asking tint2's IRC support channel, or Crunchbang's IRC channel? I personally usually stay in #compton on FreeNode when I'm online, if you wish to discuss with me.

ew wrote:

As far as I know, tint2 (SVN r652) retrieves the icon of a window from its _NET_WM_ICON property. If it couldn't find _NET_WM_ICON property on a window, it gets the icon from icon_pixmap field in WM_HINTS property. If it fails in this step, it uses a default icon. (./src/taskbar/task.c, get_icon(), line 213, in SVN r652). It then adjusts icon size, opacity, etc. with imlib2, and render with X Render or imlib2. Correct me if I'm wrong, please. So, I'm not really sure, but I assume tint2 asks the application for icon, and it displays the icon according to the theme if the application does so, otherwise it just displays whatever the application provides. It's another thing for launcher icons in tint2, which probably lookup icons in icon theme directory firstly, but I believe you are talking about task / window icons, right?

==> Ok. That shared som light on the issue. Because Icons that are present as image files in "pixmap" is displayed correctly. And yes, I`m talking about task icons, but also launcher icons... Perhaps there`s aanother mechanism for the launcher-icons?

Oh, that looks like a valuable clue! As what I've said above, launcher icons are fetched from icon theme files, while task / window ones come from X window properties. But could you please explain what "image files in "pixmap"" means? Are you talking about icons fetched from icon_pixmap field in WM_HINTS, or something else? And what have you observed on launcher icons?

Re: [SOLVED-the issue was NOT related to Compton]

Ok. I probably should tell you that I`m on Siduction 3.6.10 kernel, and have the sid repos activated in my software sources, so many packaaages gets upgraded beyond current stable build. I had to do this because my system freezes on wheezy kernels, but newer kernel fixes that issue. Anyway, I had the same issues with tint2 with the default Waldorf install, kernel 3.2.0.3 and 3.2.0.4, so it`s not my new kernel or the sid repos that has caused any of this.

Yes, we know it`s NOT a compton issue because I am multibooting Linux-distros on this computer, and I only have these issues with Tint2 on this install. I have had several issues with incompability with ivy-bridge on other distros and kernels, like boot-issues. But I have never seen anything like the issues you see in the screenshots of my two bars. So I understand why you are a bit puzzled by the issue. I`m just as puzzled, because I`ve been trough 40-50 different distros with all kinds of DE/WM`s, but never seen anything simmular to this.

But you may have saved my day, and all my issues. Do I understand you correctly when I perceived it as your patch will disable true transparancy in Tint2, but leave it on for other apps like terminal-emulators etc... That would actually solve all my problems, because I do not need real transparancy in Tint2. It`s probably what I`m already doing in my workarounds, because If I understand you correctly, Tint2 starts with fake transparancy when no compositor is present, and continues using fake transparancy even though I start a compositor at later stage. That`s why it seems to work when I start Compton later. Then Tint2 isn`t using real transparancy at all. Thanks man, you have saved my day....

I will try your patch, and if it disables real transparancy in tint2, but still makes it possible to use real transparancy with other programs and apps, then I`m fine with it. Then the issue is solved for me, unless you feel a need to solve the issue for the Tint2-developers. I have no need to do that. Since I`m a newbie and Vastone is very experienced, she reported issues we discovered with the icons for the tint2-launchers. The launcher wouldn`t follow the icon-theme that was set. It did it for some apps, but for other apps it was impossible to get Tint2 to display the correct icons according to the theme. We had to manually track each icon and replace them with the one we wanted Tint2 to use. We found it so troublesome that we instead replaced the apps that Tint 2 didn`t use the correct icons for.

For example. We used the LinuxLex8 icon-theme. Tint2 agreed to use the LinuxLex8-icon for "medit", but not for "Geany", so we used "Medit" instead. The same with Thunar. We replaced it with SpaceFM, since Tint2 agreed with the icon for SpaceFM. Also, most people would want Tint2 to use the same icons for tasks, as it uses for launchers. But that turned out to be quite difficult to achieve. Anyway, as I understand it, the Tint2-developers wouldn`t do anything with this issue, so we just have to live with it...

So if it`s ok for you, then I thank you very much for solving my issue with you patch. I have no need of real transparancy in Tint2, so if you don`t see the need either, then I guess we`re both happy. By the way, thanks for the tip about the shadows around my CPU/MEM/HDD/NET-monitor. It looks much better without the sshadow:)

Re: [SOLVED-the issue was NOT related to Compton]

Big thanks to RichardGv. I patched tint2 with the patch you provided, and now everything works perfectly. Finally I`m able to set up my Tint2-bars like I want them, without any distortion or corruptions of the icons. I`m able to do this without sacrifizing compositing in general, because Compton works like a charm, and I`m able to use the default autostart-file in Waldorf, without delaying any startup-entrys. Not even Conky. The patch was perfect, and is stored in my dropbox-folder for other occations. Thanks man:)))

Re: [SOLVED-the issue was NOT related to Compton]

Update: I forgot to say, could you please post your tint2rc out?

ew wrote:

I will try your patch, and if it disables real transparancy in tint2, but still makes it possible to use real transparancy with other programs and apps, then I`m fine with it. Then the issue is solved for me, unless you feel a need to solve the issue for the Tint2-developers. I have no need to do that.

... I patched tint2 with the patch you provided, and now everything works perfectly...

... So if it`s ok for you, then I thank you very much for solving my issue with you patch. I have no need of real transparancy in Tint2, so if you don`t see the need either, then I guess we`re both happy.

Very well, then. Glad to see you enjoy it. If I can manage to save some more disk space for another distro, I will later try Wardolf to see if I'm able to reproduce the issue. It's indeed not very sensible to ask you to continue looking into this problem when you have a baby to take care of, I'm afraid.

ew wrote:

Since I`m a newbie and Vastone is very experienced, she reported issues we discovered with the icons for the tint2-launchers. The launcher wouldn`t follow the icon-theme that was set. It did it for some apps, but for other apps it was impossible to get Tint2 to display the correct icons according to the theme. We had to manually track each icon and replace them with the one we wanted Tint2 to use. We found it so troublesome that we instead replaced the apps that Tint 2 didn`t use the correct icons for.

For example. We used the LinuxLex8 icon-theme. Tint2 agreed to use the LinuxLex8-icon for "medit", but not for "Geany", so we used "Medit" instead. The same with Thunar. We replaced it with SpaceFM, since Tint2 agreed with the icon for SpaceFM. Also, most people would want Tint2 to use the same icons for tasks, as it uses for launchers. But that turned out to be quite difficult to achieve. Anyway, as I understand it, the Tint2-developers wouldn`t do anything with this issue, so we just have to live with it...

I will say what I found here, which may or may not be right. Correct me, please, if you or your friend found I said something wrong.

tint2 uses a moderately complicated algorithm to choose which icon to use, which your friend may or may not have told you. What tint2 will eventually choose is highly dependent on the desired icon size -- that is, panel height -- and your selected theme is not the only thing tint2 considers.

The first step tint2 takes is to figure out the user-requested icon theme. This is done by querying a XSETTINGS manager or reading "launcher_icon_theme" in configuration file. As you stated some icons are loaded from the requested theme, I would assume there's no issue in this step.

Then, tint2 loads index.theme of the requested theme, to figure out the directories that may contain icons. (tint2 doesn't do automagic recursive search in your theme directories, it relies completely on index.theme, searches only the directories mentioned there, and does NOT search recursively, so a broken index.theme will make it impossible for tint2 to find your icons.) It appends any inherited icon themes (specified with "Inherits" in index.theme), and at last, "hicolor", to the search queue. For example, Faenza-Dark inherits Faenza, Faenza inherits "gnome,hicolor", so tint2 reads all possible icon directories from the themes "Faenza-Dark", "Faenza", "gnome", and "hicolor", in the order. There are types and sizes (minimal/maximum sizes) specified for each icon directory, which tint2 also records. So, in this step, tint2 gets a sorted list of themes and possible icon directories in them (relative paths, like: theme "Faenza" -> "apps/16", "apps/24", "apps/32"... theme "gnome" -> "128x128/apps"...), with icon type and icon size of each. (src/launcher.c, launcher_load_themes(), line 794)

After that, when tint2 searches for icons, it reads the icon name ("Icon=") from the .desktop file you specified in "launcher_item_app". If "Icon=" entry does not exist in the .desktop file, it uses "application-x-executable" as a fallback. Note, the icon name is case sensitive, (huh, probably not if your icons are on a case-insensitive filesystem like FAT32, but that's an extremely rare case), so a desktop file with "Icon=Thunar" will not match "/usr/share/icons/your-theme/32/thunar.png".

If the icon name is a full path (contains "/"), tint2 just uses the path, otherwise it continues searching.

It appends ".png" and ".xpm" extension to the icon name, unless the icon name contains ".png" or ".xpm" already. So, icons with other extensions are NOT searched, and this is case sensitive as well.

Now, the real match starts: It uses the sorted list of possible theme name and icon directories acquired above, prepend the possible basenames, append icon name (with possible extensions), and search for icons files in the order. (Note, it doesn't use the basename in which it found index.theme, it just tries every possible basename.)

For each icon file it discovers, it firstly calculates a "distance" between the size of the found icon file (actually it's the size specified in index.theme of the icon theme for the icon directory. Tint2 doesn't actually read the icon file and test its geometry, Later it uses imlib to do a transparent resize, so you could deceive it by putting an icon of a wrong size to one of the directories) and the desired icon size. For an icon directory with "fixed" type, the distance is the difference between the desired icon size and the size of the icon; for "scalable" type, the difference is 0 if the desired icon size is in the icon size min-max range of the icon directory, otherwise it's the difference between the min/max icon size of the directory and the desired size; for "threshold" type, it's pretty similar to "scalable". (src/launcher/launcher.c, directory_size_distance(), line 879) Whenever it finds a smaller distance than the previous smallest distance, it changes the smallest-distance match to this one.

Tint2 keeps track of another thing: next-larger match. If the size of an icon found (again, actually it's the "icon directory" icon size) is larger than or equals to the desired one, it's tracked as the next larger icon. Whenever an icon that is larger than the desired size but is closer to it than the previously matched one (i.e. smaller than the old one), it replaces the previous next-larger match.

In the end, tint2 chooses the next-larger match, if it exists. Otherwise, it uses the match with lowest distance. An icon in hicolor theme of a more suitable size will be selected over an icon in your selected icon theme but of a worse size. Exact size matches have the highest precedence, then larger matches, at least small matches, so if tint2 wants a 96x96 icon, a 256x256 icon in hicolor theme has higher precedence than a 95x95 one in your selected theme.

If tint2 couldn't find any a matching icon, it will looks for an icon desperately directly under basenames -- like "/usr/share/icons/YOUR_APP.png" -- and use the first one it finds.

So, I explained the whole process tint2 searches for launcher icons, and I hope you have already found out why the icons in your favored theme is not chosen by tint2, and possible ways to resolve the issue. And there are indeed a lot of things in the process that you could exploit to change icon precedence.

If you are still not really certain about why your preferred icon is not chosen, tint2 developers have kindly provided a debugging feature, at line 902 in src/launcher/launcher.c:

#define DEBUG_ICON_SEARCH 0

Replace 0 with 1, recompile tint2, and tint2 will tell you how exactly it chooses icons. There are a lot of output. You may use redirection/pipe to read it, or you could comment out specific debugging code in src/launcher/launcher.c. (You may wish to comment out line 1012-1013, "printf("checking %s\n", file_name);", as it produces a huge amount of pretty useless output, for example.)

ew wrote:

Also, most people would want Tint2 to use the same icons for tasks, as it uses for launchers. But that turned out to be quite difficult to achieve. Anyway, as I understand it, the Tint2-developers wouldn`t do anything with this issue, so we just have to live with it...

I think it's indeed the application / window manager's job to take care of window icon theming. An application may have multiple windows, and some windows may need different icons than the default one. How do you expect tint2 to know this? The Linux world is much less standardized than the Windows world, and this is a double-edged sword. The safest choice of tint2 is to display the icon the window provides, in my opinion.

I heard some dock application uses theme icons for tasks, though. (And tint2 is a taskbar, not a dock.) Maybe you could try Docky / cairo-dock, although with their fancy appearance they are usually much more resource-hogging than tint2.

==>Not sure. That isn`t her. I haven`t seen the actual post, but it seems to be a simmular issue.

Quote: RichardGv : Now, regarding the launcher icon theme issue:==> Thanks for the info. I will study it to see if I can use it to get Tint2 to display the task-icons I would like it to reveal. But to clearify one thing, I`m of course certain that my chosen icon theme includes the relevant icon in the correct pixel-sizes, and of course that it includes Thunar.png, not thunar.png. I`m a newbie, but I discovered very early on that most things are case-sensitive in linux:)))

ew wrote:

Also, most people would want Tint2 to use the same icons for tasks, as it uses for launchers. But that turned out to be quite difficult to achieve. Anyway, as I understand it, the Tint2-developers wouldn`t do anything with this issue, so we just have to live with it...

Quote RichardGv:I think it's indeed the application / window manager's job to take care of window icon theming. An application may have multiple windows, and some windows may need different icons than the default one. How do you expect tint2 to know this?

==> I just expect Tint2 to follow my icon-theme when ever there are available icons in the correct size. No mather what you say, Tint2 doesn`t do this. For example, it will always display the yellow "geany-tepot", regardless if the set icon-theme includes other icons for geany, in all sizes.

The Linux world is much less standardized than the Windows world, and this is a double-edged sword. The safest choice of tint2 is to display the icon the window provides, in my opinion.

==> Sure, but it doesn`t look good when you have a slick modern icon-theme, and tint2 still displays that ugly yellow teapot that`s supposed to look like a lamp. Together with a cartoon-like theme I guess you could live with it:)

I heard some dock application uses theme icons for tasks, though. (And tint2 is a taskbar, not a dock.) Maybe you could try Docky / cairo-dock, although with their fancy appearance they are usually much more resource-hogging than tint2.

==> I am already trying everything you talk about. At the moment I have 7 different distros installed, many of them with several working sessions, and for example xfce4-panel do use my theme icons, and that`s not a dock either. No complaint there:)

As for my "baby", you are correct. It`s more important to take care of her, than it is to help solve a tint2-issue that really is of no importance to me. Especially when it never can become what I want it to be. If I should assist in something like that, then Tint2 is needed to aspire to be something more. For example, Tint2 need to make it possible to display simple text, and labels below launcher icons, so that I can use it to build a custom categorized menu-system. Then it would be interesting...

Of course, I can always create a test install of waldorf to use for testing, but I don`t want to mess up this install, because it`s been a pain to get it to work like it does now. It`s only Ubuntu 12.10 and LM14 that has handled my hardware out of the box...

Re: [SOLVED-the issue was NOT related to Compton]

==>Sure... It`s the default tint2rc in Waldorf. Unchanged, exept that I don`t use the launchers in this bar/file.

...

I tested your configuration, and I couldn't reproduce the bug.

ew wrote:

Quote: RichardGv : Now, regarding the launcher icon theme issue:==> Thanks for the info. I will study it to see if I can use it to get Tint2 to display the task-icons I would like it to reveal. But to clearify one thing, I`m of course certain that my chosen icon theme includes the relevant icon in the correct pixel-sizes, and of course that it includes Thunar.png, not thunar.png. I`m a newbie, but I discovered very early on that most things are case-sensitive in linux:)))

If you are short of time or something, you could just enable "DEBUG_ICON_SEARCH" with the method I indicated above, and show us the output, so we can look into this for you.

ew wrote:

Quote RichardGv:I think it's indeed the application / window manager's job to take care of window icon theming. An application may have multiple windows, and some windows may need different icons than the default one. How do you expect tint2 to know this?

==> I just expect Tint2 to follow my icon-theme when ever there are available icons in the correct size. No mather what you say, Tint2 doesn`t do this. For example, it will always display the yellow "geany-tepot", regardless if the set icon-theme includes other icons for geany, in all sizes.

The Linux world is much less standardized than the Windows world, and this is a double-edged sword. The safest choice of tint2 is to display the icon the window provides, in my opinion.

==> Sure, but it doesn`t look good when you have a slick modern icon-theme, and tint2 still displays that ugly yellow teapot that`s supposed to look like a lamp. Together with a cartoon-like theme I guess you could live with it:)

I heard some dock application uses theme icons for tasks, though. (And tint2 is a taskbar, not a dock.) Maybe you could try Docky / cairo-dock, although with their fancy appearance they are usually much more resource-hogging than tint2.

==> I am already trying everything you talk about. At the moment I have 7 different distros installed, many of them with several working sessions, and for example xfce4-panel do use my theme icons, and that`s not a dock either. No complaint there:)

As far as I could see, both tint2 and xfce4-panel uses the Geany icon in my Faenza theme for launchers, but they both use the original teapot icons for Geany windows on taskbar.

As far as I could see, xfce4-panel-4.10.0 uses wnck_window_get_icon() / wnck_window_get_mini_icon() to get window icons (./plugins/tasklist/tasklist-widget.c, xfce_tasklist_button_icon_changed(), line 2376) , libwnck-2.31.0 reads icons from _NET_WM_ICON, icon_pixmap in WM_HINTS, and KWM_WIN_ICON, in the order, almost in the same way as tint2 (./libwnck/xutils.c, _wnck_read_icons(), line 2070). (They probably uses different algorithm in choosing the best icon size, though.)

ew wrote:

As for my "baby", you are correct. It`s more important to take care of her, than it is to help solve a tint2-issue that really is of no importance to me. Especially when it never can become what I want it to be. If I should assist in something like that, then Tint2 is needed to aspire to be something more. For example, Tint2 need to make it possible to display simple text, and labels below launcher icons, so that I can use it to build a custom categorized menu-system. Then it would be interesting...

Of course, I can always create a test install of waldorf to use for testing, but I don`t want to mess up this install, because it`s been a pain to get it to work like it does now. It`s only Ubuntu 12.10 and LM14 that has handled my hardware out of the box...

So forgive me for not rushing to the Tint2-issue like it was about life and death...

Just to clarify this: I'm a developer of compton, not a developer of anything else, so it's none of my business as far as it's unrelated to compton. I'm only helping here because I wish to help. If you are uninterested in debugging the problems, it's fine to stop here.