When using guitarix-git with oxygen-gtk, xrestop shows a lot of GCs objects growing until the gui became slow and choppy. Reproducible: Always Steps to Reproduce: 0. Use oxygen-gtk2 1. Install jack, qjacktcl and guitarix-gtk 2. start guitarix-git 3. in qjackctl, feed gx_head_amp with some audio source so that the vmeter starts to move 4. start xrestop 5. see that the number under Gcs is growing 6. Wait an hour (or trust me!), and the framerate will slow down. 7. set redmond theme for gtk apps, repeat from point 1 till 5, and see that with this theme is ok.
*** This bug has been marked as a duplicate of bug 316066 ***
Are you sure this bug is a duplicate of bug 316066? I'm asking because 316066 is claimed as fixed, but i just tried oxygen-gtk2 from the git repo and guitarix is still leaking Gcs in xrestop.
Well, why verified duplicate then? :) This was closed as dup because the bug 316066 symptoms looked quite the same as yours. But, if you insist that it's not fixed, I'm reopening it.
@Antonio You are sure this is a leak and not simply the caches getting filled ? Namely: you can reproduce the conditions of comment #1, and not simply watch the gc count growing at the beginning of running the applications ? (the number of allocated GCs is expected to grow at the beginning and then eventually saturate) Also: what's your cairo version ?
after installing guitarix, my observations are: GC: stable Pixmaps: first increase then stable (around 1000, which, I think, is expected - will double check) Misc: seams to be leaking. (always increasing, when, for instance I keep clicking on a menu entry) No clue what Misc is. Will investigate.
I'm just trying; Gcs is growing constantly, now at 6900. pxms is bteween 49 and 50; misc is stable. my cairo version is 1.12.14 and it contains patches for nvidia blob that basically skips gradient acceleration because that driver slows down. https://aur.archlinux.org/packages/cairo-nvidia/?setlang=it At the end of this message GCs reached 16697. I'll wait a while and will test plain cairo next ; will report back.
I have cairo 1.12.12 what you report is clearly different from what I see here ... will be hard to debug.
I stopped watching when Gc reached about 30000. Then i installed upstream cairo, same version without any patch, but things are the same. I'm testing this git: # git describe v1.3.2.1-89-g76735ff Does it includes your latest fix?
(In reply to comment #7) > I have cairo 1.12.12 > what you report is clearly different from what I see here ... > will be hard to debug. I tried cairo 1.12.12, same result. Are you sure you connected an audio source to gx_head_amp? if the meter doesn't move then Gcs are stable for me as well.
Update: if i run guitarix into Xnest, Gcs are stable, maybe this could help (?)
v1.3.2.1-89-g76735ff <- yes includes patch. "Are you sure you connected an audio source to gx_head_amp?" mmm sorry, missed that from the "description". Trying now.
"in qjackctl, feed gx_head_amp with some audio source so that the vmeter starts to move" how do you do that ?
ok. I sort of can reproduce the GC grow what worries me is that it is triggered by something that is definitely not rendered by oxygen-gtk (the vu-meters). also: (to Ruslan): another case of application being useless with our grab from empty areas. Bottomline: this is definitely not a duplicate of the other bug.
... I wonder if it could be related to "compositing" @Antonio can you try recompile oxygen-gtk with ENABLE_INNER_SHADOWS_HACK set to 0 (see README) ? just to take that off the hook
(In reply to comment #12) > "in qjackctl, feed gx_head_amp with some audio source so that the vmeter > starts to move" > how do you do that ? you just start qjackctl first, then guitarix then start mplayer this way: mplayer longaudiofile -ao jack -loop 0 then, while mplayer is playing, go into qjackctl gui and click on "Connect" button. In the "Audio tab", you have a two side pane view, with mplayer on the left and gx_head_amp on the right. click mplayer on the left, click gx_head_amp on the right, then click connect. Now mplayer output goes into gx_head_amp and vmeter start to move. Anyway, I investigated further by using Xephir instead of Xnest. Xephir allows you to manually disable X extensions, and i found that as soon as i disable DAMAGE, i've no leak anymore.
mmm. Here, using Raleigh as a widget style, GC's also seem to increase infinitly when the VU meters move ... You sure it is not the case on your side ?
(In reply to comment #16) > mmm. Here, using Raleigh as a widget style, GC's also seem to increase > infinitly when the VU meters move ... You sure it is not the case on your > side ? I changed theme using gtk-chtheme (i'm sure i changed it because the menus looks different, are you sure you are testing Raleigh?) Anyway nope; with Raleigh it seems that Gcs grows for every Vmeter position, not indefinitely (eg: after it went from position 0% to position 100%, Gcs stops growing). (In reply to comment #14) > ... I wonder if it could be related to "compositing" Nope, i tried with openbox (so no compositing at all) into the Real X server and Gcs still grows. And sorry for my last message, it overlapped with yours. My try with Xephir (with COMPOSE enabled but with DAMAGE disabled) shows stable Gcs. (What the heck does it means Gcs!? ) > @Antonio > can you try recompile oxygen-gtk with ENABLE_INNER_SHADOWS_HACK set to 0 > (see README) ? > just to take that off the hook Going to try.
> > @Antonio > > can you try recompile oxygen-gtk with ENABLE_INNER_SHADOWS_HACK set to 0 > > (see README) ? > > just to take that off the hook > > Going to try. Gcs are stable with ENABLE_INNER_SHADOWS_HACK set to 0 at compile time!
(In reply to comment #18) > > > @Antonio > > > can you try recompile oxygen-gtk with ENABLE_INNER_SHADOWS_HACK set to 0 > > > (see README) ? > > > just to take that off the hook > > > > Going to try. > > Gcs are stable with ENABLE_INNER_SHADOWS_HACK set to 0 at compile time! #OXYGEN_DISABLE_INNER_SHADOWS_HACK=1 guitarix works as well.
@Antonio
argh @antonio yes: I can reproduce/confirm your last 3 comments. that definitely helps; there is hope. (at worse we can attempt to blacklist the guilty custom widget, both for inner_shadow, and for window grab) Thanks for all the information. I'll come back to you when I have something new.
That's nothing compared to your work, thanks to you! At least there is an easy workaround.
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.
(In reply to Justin Zobel from comment #23) > Thank you for the bug report. > > As this report hasn't seen any changes in 5 years or more, we ask if you can > please confirm that the issue still persists. > > If this bug is no longer persisting or relevant please change the status to > resolved. Guitarix switched to gtk3, i think this bug can be killed without mercy. Not sure how to close it, feel free to change the reason! Thanks ;)