Announcement

Collapse
No announcement yet.

Is Compiz On Its Deathbed?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Originally posted by ninez View Post
    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.

    Comment


    • #42
      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.

      Comment


      • #43
        Originally posted by droidhacker View Post
        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.

        Comment


        • #44
          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.

          Comment


          • #45
            Originally posted by drago01 View Post
            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)...

            Originally posted by drago01 View Post
            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.

            Originally posted by drago01 View Post
            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.

            Originally posted by drago01 View Post
            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...
            Last edited by ninez; 06 March 2012, 03:33 PM.

            Comment


            • #46
              Originally posted by d2kx View Post
              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.

              Comment


              • #47
                Originally posted by ninez View Post
                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).

                Comment


                • #48
                  Originally posted by drago01 View Post
                  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.

                  Originally posted by drago01 View Post
                  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.

                  Originally posted by drago01 View Post
                  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.

                  Originally posted by drago01 View Post
                  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.

                  Originally posted by drago01 View Post
                  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.

                  Originally posted by drago01 View Post
                  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.

                  Originally posted by drago01 View Post
                  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.

                  Originally posted by drago01 View Post
                  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'.
                  Last edited by ninez; 06 March 2012, 05:04 PM.

                  Comment


                  • #49
                    Originally posted by ninez View Post

                    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.
                    Wow! That's more overhead than even I thought rt would have, based on our earlier discussions.
                    Have you tried adjusting the slack timer so it can avoid some wakeups?

                    Comment


                    • #50
                      Originally posted by liam View Post
                      Wow! That's more overhead than even I thought rt would have, based on our earlier discussions.
                      Have you tried adjusting the slack timer so it can avoid some wakeups?
                      Hey liam, let me clarify a little.

                      When i say 'idle', i really mean something along the lines of, 'as idle as it is can be'. ie: even in an idle state, their is a lot of processing going on. So it's not so much overhead for RT 'specifically', this is just overhead of running certains programs, that will use cpu regardless of whether or not, you actually can hear what they are doing (or processing).

                      I haven't played around with /proc/<procid>/task/<task_id>/timer_slack_ns (if that is what you mean)

                      I've seen that cgroups can manage this stuff, but i haven't investigated it.

                      the best tunables that i have played with in the past, that are rt-related that yielded good results (but this was latency related) were these three tunables;

                      /proc/sys/kernel/sched_latency_ns
                      /proc/sys/kernel/sched_min_granularity_ns
                      /proc/sys/kernel/sched_wakeup_granularity_ns

                      i had to run tests over and over until i got the right mix between them. (using standard rt-related tools, like Cyclitest). But these days, things run very smooth and i haven't felt the need to be as crazy about those sorts of tweaks, as my box has been working very well.
                      Last edited by ninez; 06 March 2012, 11:42 PM.

                      Comment

                      Working...
                      X