[FusionDev] Compiz-manager sloweness (Was: Release)

[Sam Spilsbury]

Oh, and my set up is :
OpenSUSE 10.2
GNOME 2.16
X.org 7.3 Alpha
Intel (INTEL_BATCH=1)
Xgl
Latest Compiz Fusion.
Not-So-Latest Compiz-Manager / Icon


On 8/11/07, Sam Spilsbury <smspillaz at gmail.com> wrote:
>
>
>
> On 8/11/07, Kristian Lyngstøl <kristian at bohemians.org> wrote:
> >
> > On 8/11/07, Sam Spilsbury <smspillaz at gmail.com> wrote:
> > > On 8/11/07, Kristian Lyngstøl < kristian at bohemians.org> wrote:
> > > > I'd like to move my compiz-manager script into a more
> > central/official
> > > > repo and get proper feedback without getting 20 different forks of
> > it
> > > > (it's a pain, to be honest, to be sent a rewrite of your own code
> > > > instead of ideas on how to improve it or patches). Any objections
> > > > against this?
> > >
> > > To be honest, your wrapper script is actually a bit slow when it comes
> > to
> > > starting compiz. I don't know why, it just is. I know that fusion-icon
> > is
> > > written in python and it seems to handle starting compiz quite well.
> > For
> > > some reason I don't agree on making it a bash script as it seems to
> > have
> > > problems when using gnome-autostart. I figure a python script or a
> > binary
> > > exec that does the system checking stuff would be good. Maybe just
> > install
> > > it as 'cfusion' or something so I don't have to write a bazillion
> > guides on
> > > how to start compiz on every configuration.
> >
> > This is the FIRST time anyone has ever mentioned this to me. Can you
> > please explain this in detail? What setup do you have? Is it
> > consistently slower? When using verbose, is it possible for you to
> > tell which part of it is slower? Is it slow after the initial run
> > where it saves the results too? Or is the slowness mainly caused by
> > the delay in the window decorator?
>
>
> I'm not with my CFusion desktop at the moment, but from what I recall, it
> takes about 5 seconds to start compiz with your script, and it seems to hang
> gnome-autostart for about 15 seconds. Like I said, I need to have a look at
> it in greater detail, but it is considerably slower than beryl's old system
> check.
>
> NOTE : The autostart slowness might be caused by the fact that it's trying
> to kill metacity while it's starting.
>
> Can anyone else confirm this?
> >
> > I also wanted fusion-icon to actually USE compiz-manager which was the
> > goal all along but there has been ZERO communication between the
> > author and myself. Compiz-manager was discussed on the compiz ml
> > before it's creation and the compcomm list afterwards, I've had very
> > little usefull feedback on it to be frank. Maybe I'm to be blamed,
> > maybe not, but I still believe compiz-manager is the way to go.
> >
> > Also, there's no reason at all a python script or a binary would be
> > faster than a bash script in this case. So the problem is somewhere
> > else.
> >
> > I also would NOT want a icon to be required. It makes no sense. I'm
> > sorry, but fusion-icon, which apparently does it's own detection,
> > should be using compiz-manager. One of the ideas behind compiz-manager
> > to begin with was just this sort of usage, that Christopher didn't
> > send me a single mail about it or mention it on the list, even though
> > I have mentioned that multiple times on IRC is strange. Of course, I
> > am partially to be blamed for this since I didn't actively get
> > involved, though I did mention this early in the development phase. I
> > have not payed attention to the thread on the forums, as the forum is
> > swamped with non-developer stuff that makes it a time sink, which is
> > why this mailing list exist.
> >
> > In this area, we need a single, good, working and solid solution that
> > can be used all around. Not everyone want an icon (I'm not even
> > running a notification area myself), and they shouldn't be required
> > too. And this sort of task is also quite perfect for a bash script
> > too. There are probably several ways to improve compiz-manager, but
> > scrapping it in favor of fusion-icon is not one of them. It was
> > written for the job of being a wrapper script, if it's not good
> > enough, that should be fixed, but we do need a fully command line
> > based tool. And no, a binary solution is not acceptable either, python
> > might have been but it just so happens we have one in bash already.
> >
> > --
> > Regards,
> > Kristian
> > _______________________________________________
> > Dev mailing list
> > Dev at lists.compiz-fusion.org
> > http://lists.compiz-fusion.org/mailman/listinfo/dev
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.compiz-fusion.org/pipermail/dev/attachments/20070811/6723161b/attachment.htm