Is Compiz On Its Deathbed?

[drago01]

Really, you're going to post Owen Taylor's (creator of mutter) benchmarks from last year?! ~ I am have (current day) mutter and Compiz both right in front of me and i can easily see for myself which works better for me/my system/hardware... I don't need to look at old (IMO potentially biased) benchmarks.

First I said that "does not have any recent fixes" secondly just because Owen maintains mutter does not mean that he "faked" the benchmarks. Also I didn't say that this couldn't be the case for specific hardware / software combinations hence while I have asked you to file a bug with details.

I am not interested in "A is better than B, no B is better than A" kind of discussions but rather want to identify real issues and fix them.

[ninez]

First I said that "does not have any recent fixes" secondly just because Owen maintains mutter does not mean that he "faked" the benchmarks. Also I didn't say that this couldn't be the case for specific hardware / software combinations hence while I have asked you to file a bug with details.

I am not interested in "A is better than B, no B is better than A" kind of discussions but rather want to identify real issues and fix them.

Who said i am? I only said, that i can see for myself, which one works better for me and that i didn't need to look at Owen's outdated benchmarks (they have zero impact on my choice of compositor).

i don't even see why you posted those benchmarks. If you knew it was outdated, surely there was little point in showing it... As for being 'faked', i just know at the time those were published ~ mutter was pure crap on my system(s) and visually was lagging. As an example, If i did things like launch 10 instances of mplayer, mutter lagged - if i did the same thing with compiz it didn't. .. and yes, this is actually something i have done... Mutter has improved a lot since then, but so has compiz. For me, compiz is still a much better choice/fit for my system && workflow.

As for filing bug reports against mutter/GnomeShell. ~ i am not interested in using either of them, so there is little reason, for me to sit down, test and file bug reports. Instead, i tend to do that for software that i actually use daily. GnomeShell dev's are aware of this issue (rt + xruns) anyway. it is a problem that has been brought up to them (almost a year ago)... And IMO GS isn't a good fit for proaudio users anyway, hence why proaudio distro's like UbuntuStudio/KxStudio/etc don't bother with it.

[drago01]

Who said i am? I only said, that i can see for myself, which one works better for me and that i didn't need to look at Owen's outdated benchmarks (they have zero impact on my choice of compositor).

Well I asked you what you miss in mutter because you called it "just basics" and one of your concerns was performance. I used Owen's benchmarks to back up my claim that "there is no reason for mutter to be any slower then compiz". It might be the case on your system but that isn't just because "mutter is slow" and "compiz is fast" but something specific in your configuration causes mutter to run slower then it ought to be (hence why I asked for a bug report).

As for filing bug reports against mutter/GnomeShell. ~ i am not interested in using either of them, so there is little reason, for me to sit down, test and file bug reports. Instead, i tend to do that for software that i actually use daily. GnomeShell dev's are aware of this issue (rt + xruns) anyway.

Not true you are currently talking to one and this was the first time I see any reports regarding xruns.

it is a problem that has been brought up to them (almost a year ago)...

Can't recall seeing any such bug report or mailing list post.

And IMO GS isn't a good fit for proaudio users anyway, hence why proaudio distro's like UbuntuStudio/KxStudio/etc don't bother with it.

The window manager / compositor should not matter for audio at all. If it does something else is just broken.

[droidhacker]

Compiz was never more than a toy. They came out with a whole lot of gawdy in-your-face bling, and now everybody has finally accepted that it only wastes resources, slows everything down, and creates instability. Let it die.

[kraftman]

Compiz was never more than a toy. They came out with a whole lot of gawdy in-your-face bling, and now everybody has finally accepted that it only wastes resources, slows everything down, and creates instability. Let it die.

Ubuntu is using it, so it won't die easily.

[d2kx]

Compiz is not dying short term, thanks to Daniel Van Vugt, who is responsible for lots of patches that dramatically improve the performance and reduce the power usage of both Compiz and Unity (on top of Compiz). Some is avaible in Ubuntu 12.04 Beta 1, but a alot more will be integrated before Ubuntu 12.04 releases. It fucking flies with all of them.

[ninez]

Well I asked you what you miss in mutter because you called it "just basics" and one of your concerns was performance. I used Owen's benchmarks to back up my claim that "there is no reason for mutter to be any slower then compiz". It might be the case on your system but that isn't just because "mutter is slow" and "compiz is fast" but something specific in your configuration causes mutter to run slower then it ought to be (hence why I asked for a bug report).

Okay, i use an RT-kernel (full preemption) all of the time. Now, with both Cinnamon and GS, i experience lag in GUI. one example, Cinnamon's menu often takes a second to load (when it should take no time at all). ... But it is similar with GS, just not as bad, and in different situations. But you're right, it could be something in my configuration, the fact that i use RT (all of the time), the fact that i am using the Nvidia proprietary driver, or any number of other things...But the whole bug report thing, is a waste of *my time*, being as i know GnomeShell isn't the sort of Desktop experience that i want, and IMO isn't a good fit for proaudio, either. (partially because of xrun issues, partially because i don't like the way it handles windows/applications/or my desktop in general and partially because there are more flexible reliable alternatives)...

Not true you are currently talking to one and this was the first time I see any reports regarding xruns.

I initially mentioned it on the GnomeShell list, right after Gnome3 was released. admittedly, the message was very heated (I was pissed at the time) as GnomeShell was complete garbage, at that point, on my Desktop... To explain what i mean by garbage; Archlinux was the first to have G3 come through as an 'update' to replace gnome2. At that point, my Gnome Desktop become totally useless, because of a combination of xruns and even worse GnomeSehll && Nvidia blob not working (very well) together. (ie: things like garbled GFX/GL, apps being unusable, etc). Gnome-devs recommended using Nouveau (which wasn't an option because of apps that i use that require Nvidia / proper GL)... Then after some tinkering, my desktop became Gnome3/compiz 0.9.x (much like how it was before the upgrade to GnomeShell). The GS xrun problem has been mentioned on LAU (linux-audio-user-list) on several occasions (over the last year), and i have also read about it in other forums. Generally speaking, the odd (non-specific) daemon can cause xruns, so it's not surprising that GS with all of it's bling could do the same. (and i have a quadcore/SATA6g/8g DDR3/pci soundcard, proaudio, not consumer grade), so it's not like i'm running an older core 2 duo and crap hardware or something)... years ago, this was an issue with compiz too, but for me it hasn't been in quite some time.

You probably haven't seen bug reports, because unless someone actually *really* has their heart set on using GS, they probably don't go to the effort to file a bug report, but instead just moved on to a lighter DE/WM, or one they know doesn't cause them issues.

Can't recall seeing any such bug report or mailing list post.

...then you don't recall seeing/reading it...and to be clear, i never filed a bug report - because i have no intention of using GS, i only muck around with it, every now and again when i see progress or hear about a new extension that may be of interest. I sort of view GS as a toy, not as something to use in production.

The window manager / compositor should not matter for audio at all. If it does something else is just broken.

How familiar are you with Both RT-kernels and proaudio (in linux)???? While in theory it shouldn't, that doesn't mean in practice that it wont. Lets put it this way ~ If a process monopolizes a little too much cpu time, you can get xruns...

[ninez]

Compiz is not dying short term, thanks to Daniel Van Vugt, who is responsible for lots of patches that dramatically improve the performance and reduce the power usage of both Compiz and Unity (on top of Compiz). Some is avaible in Ubuntu 12.04 Beta 1, but a alot more will be integrated before Ubuntu 12.04 releases. It fucking flies with all of them.

good point. Daniel is doing lots of good stuff for compiz. The cpu-fix cut compiz' cpu usage in half, on my hardware.

[drago01]

Okay, i use an RT-kernel (full preemption) all of the time. Now, with both Cinnamon and GS, i experience lag in GUI. one example, Cinnamon's menu often takes a second to load (when it should take no time at all). ... But it is similar with GS, just not as bad, and in different situations.

Does/did this happen more then once in one session? The textures are cached after the first load so it should show up instantaneously after being loaded once. (Yes the first load shouldn't be slow either but even if it is at least subsequent accesses shouldn't be).

But you're right, it could be something in my configuration, the fact that i use RT (all of the time), the fact that i am using the Nvidia proprietary driver, or any number of other things...But the whole bug report thing, is a waste of *my time*, being as i know GnomeShell isn't the sort of Desktop experience that i want, and IMO isn't a good fit for proaudio, either. (partially because of xrun issues, partially because i don't like the way it handles windows/applications/or my desktop in general and partially because there are more flexible reliable alternatives)...

OK, fair enough. Just for the record which CPU / GPU are you using (or did you use back then) ?

I initially mentioned it on the GnomeShell list, right after Gnome3 was released. admittedly, the message was very heated (I was pissed at the time)

Ah OK, I tend to skip such emotionally loaded posts because they almost never result into a useful discussion. I'd advise you to keep emitions out of such report (not only for GNOME but when talking to any other projects.); otherwise you just trigger defensive reactions and no constructive discussion on the issues you raise.

as GnomeShell was complete garbage, at that point, on my Desktop...

To explain what i mean by garbage; Archlinux was the first to have G3 come through as an 'update' to replace gnome2. At that point, my Gnome Desktop become totally useless, because of a combination of xruns and even worse GnomeSehll && Nvidia blob not working (very well) together. (ie: things like garbled GFX/GL, apps being unusable, etc). Gnome-devs recommended using Nouveau (which wasn't an option because of apps that i use that require Nvidia / proper GL)

The advise the use nouveau was because the NVIDIA driver had a bug where we worked with NVIDIA to identify it. They told us that they where working on a fix, because we didn't have access to the drivers source code there was no way for us to fix it so we advised users to use nouveau at this time. The bug got fix a while ago though.

... Then after some tinkering, my desktop became Gnome3/compiz 0.9.x (much like how it was before the upgrade to GnomeShell). The GS xrun problem has been mentioned on LAU (linux-audio-user-list) on several occasions (over the last year), and i have also read about it in other forums.

Do you have a link to any of this discussions?

Generally speaking, the odd (non-specific) daemon can cause xruns, so it's not surprising that GS with all of it's bling could do the same. (and i have a quadcore/SATA6g/8g DDR3/pci soundcard, proaudio, not consumer grade), so it's not like i'm running an older core 2 duo and crap hardware or something)... years ago, this was an issue with compiz too, but for me it hasn't been in quite some time.

With that alone I cannot explain why it happens even in the case where the compositor monopolizes a whole CPU you'd have three other cores left. And neither gnome-shell nor compiz ever put any pressure on all CPU cores. Maybe you where running in a situation where the bus bandwidth was saturated due to texture transfers. Hard to say without debugging it.

You probably haven't seen bug reports, because unless someone actually *really* has their heart set on using GS, they probably don't go to the effort to file a bug report, but instead just moved on to a lighter DE/WM, or one they know doesn't cause them issues.

...then you don't recall seeing/reading it...and to be clear, i never filed a bug report - because i have no intention of using GS, i only muck around with it, every now and again when i see progress or hear about a new extension that may be of interest. I sort of view GS as a toy, not as something to use in production.

OK fine but OTOH you can't blame us for not fixing bugs that we don't hit ourselves and do not get reported.

While in theory it shouldn't, that doesn't mean in practice that it wont..

Sure let me quote my comment again I said "should not matter for audio at all. If it does something else is just broken." that does not imply that it never happens I just said that when this happens something is broken and has to be fixed. And that "something" is at a lower level then the window or compositing manager. (By swapping it you are dealing with the symptoms and leave the root cause as is).

[ninez]

Does/did this happen more then once in one session? The textures are cached after the first load so it should show up instantaneously after being loaded once. (Yes the first load shouldn't be slow either but even if it is at least subsequent accesses shouldn't be).

Yes, it does.

OK, fair enough. Just for the record which CPU / GPU are you using (or did you use back then) ?

AMD Phenom II 965 Black edition (3.2ghz quadcore) - This machine is my primary (Linux) Desktop... i could, but don't overclock it. I've also got an i7 in my Mac (which also runs Archlinux/dualboot) although, i don't think i've ever used GnomeShell on that machine, as it is primarily used for it's Mac side.

Nvidia card at the time, *i think* was Geforce 9800GT - but i gave that card to my dad. Now, i am using Nvidia GTX 295 - but i have several other nvidia cards laying around, or in other machines, too.

Ah OK, I tend to skip such emotionally loaded posts because they almost never result into a useful discussion. I'd advise you to keep emitions out of such report (not only for GNOME but when talking to any other projects.); otherwise you just trigger defensive reactions and no constructive discussion on the issues you raise.

Yup... i agree. I was pretty bitter stressed out at the time, and GS put a fork in the road, when i was actually *needing" my computer to get real work done, it also blew me away that Gnome3 was even being released in the state it was in at the time.

The advise the use nouveau was because the NVIDIA driver had a bug where we worked with NVIDIA to identify it. They told us that they where working on a fix, because we didn't have access to the drivers source code there was no way for us to fix it so we advised users to use nouveau at this time. The bug got fix a while ago though.

I already all know this stuff.

Do you have a link to any of this discussions?

I probably do, but i will have to search through my inbox, as i usually hold on to most of the LAU emails, as from time to time ~ there is useful info in there, that i might want find useful down the road. I'll have a look.

With that alone I cannot explain why it happens even in the case where the compositor monopolizes a whole CPU you'd have three other cores left. And neither gnome-shell nor compiz ever put any pressure on all CPU cores. Maybe you where running in a situation where the bus bandwidth was saturated due to texture transfers. Hard to say without debugging it.

I think your making the grand assumption that my 3 (or even 4) cores aren't already busy with other processing. It is quite typical on my desktop to be running 30-40 applications (all proaudio, using/requiring RT-scheduling), right now, *idling* i am using 34% of my CPU(s), keep in mind that i am running 28 proaudio applications, not including Firefox, gedit and musescore. Not one of my cores is idling at zero (or even close to zero). As for the latter part of your comment, not sure, wouldn't want to speculate either.

OK fine but OTOH you can't blame us for not fixing bugs that we don't hit ourselves and do not get reported.

Who said i blame you? I don't use GS, so i don't do bug reports for it.

Sure let me quote my comment again I said "should not matter for audio at all. If it does something else is just broken." that does not imply that it never happens I just said that when this happens something is broken and has to be fixed. And that "something" is at a lower level then the window or compositing manager. (By swapping it you are dealing with the symptoms and leave the root cause as is).

Fair enough. But by swapping out GS/mutter, my problem is completely gone. and theoretically, if i had left GS - i would be left with a Linux Desktop that i wouldn't even want to use, so it really doesn't matter if i left the 'root cause' there or not ~ because it exists in software, that really isn't what i am looking for to begin with. ~ let's put it this way, the GnomeShell package (currently) wouldn't even be installed on my machines, if it wasn't a dependency for things like 'gnome-tweak-tool'.