You are not logged in.
[EDIT]: I've altered the subject of this thread to reflect the course it has talken; it's now used for following up on compiz 0.9 issues, and attempting to report bugs upstream and support reports we can each reproduce.
-----
[community] has, for long, had "compiz-core 0.8.x", since 0.9 was regarded as the "unstable" version when it was initially release.
For a long time now, the 0.9 has been stable. Compiz is currently being shipped in-house at Cannonical (they actually hired the developer to work for them), and what they deem to be the stable version is the 0.9.x branch, and have shipped two mayor releases with it.
Although compiz.org states taht 0.9.x is the unstable branch, it also announces 0.9.5 as the latest release, while 0.9.7 as the latest, proving that this site is somewhat abandoned and out-of-date.
I'd like to propuse we move "compiz-*-dev" from the AUR (which it 0.9.7) into community and replace 0.8.8. 0.9.7 is deemed the stable branch by the developers (cannonical), and, after testing it myself, I conclude the same.
Here's a short list of pros and cons. I'd very much like to see what everyone thinks about this, and, in particular, if there's any good technical reason not to do this.
Pros of 0.9.7:
- There are some more plugins available, which provide useful functionalities, such as GRID.
- Clicking on the border of the screen works as intended, the event is passed onto the window there present whenever appropriate. This is broken on 0.8.x.
- Suposedly, less resourse-intensive.
- Actual latest stable release, as is usual in Arch: bleeding edge.
Pros of 0.8.8
- Emerald support.
Cons of the migration:
- The configuration file is stored in a slightly different format, forcing users to reconfigure compiz.
Last edited by hobarrera (2012-04-26 17:38:38)
Offline
Compiz 0.9.x is not regarded as stable by the dev team on platforms other than Ubuntu.
"Its too big and too slow"
Offline
Compiz 0.9.x is not regarded as stable by the dev team on platforms other than Ubuntu.
For what version of 0.9 was this announced? Do you have any reference as to why that is? Or any other related info (what would need fixing, etc)?
Offline
- grid plugin is also available for compiz 0.8.4-0.8.8
- Suposedly, less resourse-intensive. - to be confirmed, I know many many people that switched back to 0.8.8 for the very same reason
Offline
Long time compiz user here.
I tried many 0.9 versions in the last months. I am a frequent visitor on #compiz@freenode.irc, and have always told (by sorau, one of the developers) that the 0.9 branch is buggy. It is indeed, I could not make a stable installation of any 0.9 compiz here, whereas the 0.8 version is rock stable. The ubuntu version might be more stable as I heard, but it is heavily patched towards unity, so that branch is not usable as standalone wm (again, according to soreau, I have no experience with that). When people come to the irc to complain about any ubuntu compiz problems, they are directed straight to #ubuntu, it is a different beast than standalone.
zʇıɹɟʇıɹʞsuɐs AUR || Cycling in Budapest with a helmet camera || Revised log levels proposal: "FYI" "WTF" and "OMG" (John Barnette)
Offline
The lack of emerald support saddens me, as it is the best decorator on the market.
Offline
The lack of emerald support saddens me, as it is the best decorator on the market.
It's the prettiest decorator on the market. Also by far the buggiest and crashiest.
@OP:
It was decided by the Compiz devs that 0.9.x would be a development branch and that 1.0 will be the next stable release. Though, I agree that the .9 releases are pretty nice and I haven't hit too many bugs.
Offline
I use Compiz (0.9.7.x~bzr) and i personally think any update (upstream) for Archlinux, should wait until after Compiz 1.0 is released.
There is just a lot going on in the 0.9.7 branch, lots of changes - most daily. There is definitely bugs, although any that i bumped into i've reported and/or worked around. (everyone who uses Compiz, should be reporting bugs on Launchpad @ lp:compiz, or the relevant branch) I also got a bug fixed for DSO linking issues, which affected compilation on non-ubuntu systems, such as Archlinux, Fedora, etc.
I think 1.0 will be a good release, and at that time, maybe Compiz should be reviewed to replace 0.8.8 ...
Latest versions of compiz are lighter on resources (at least on my AMD Phenom II x4 965 + Nvidia blob).
here's hoping Compiz shapes up for the 1.0 release
cheerz
SIDENOTE: Compiz can be compiled with Link Time Optimizations with the latest GCC, but don't do this unless you've got 4-8gig of RAM, as it will suck up lots of memory in the process, and it takes much longer to compile. (not to mention CPU usage will be very high during LTOs) ~ but now, when i login - compiz seems to be up and running decidedly faster than without LTO
Offline
Long time compiz user here.
I tried many 0.9 versions in the last months. I am a frequent visitor on #compiz@freenode.irc, and have always told (by sorau, one of the developers) that the 0.9 branch is buggy. It is indeed, I could not make a stable installation of any 0.9 compiz here, whereas the 0.8 version is rock stable. The ubuntu version might be more stable as I heard, but it is heavily patched towards unity, so that branch is not usable as standalone wm (again, according to soreau, I have no experience with that). When people come to the irc to complain about any ubuntu compiz problems, they are directed straight to #ubuntu, it is a different beast than standalone.
This saddens me a bit. Cannonical hired the only developer to work in-house, and they kind of forgot about the rest of the community.
- grid plugin is also available for compiz 0.8.4-0.8.8
The functionality is not the same, grid for 0.8.8 lacks most of the functions I use in 0.9 (drag to border have a window ocupy half the screen, drag to top to maximize).
The lack of emerald support saddens me, as it is the best decorator on the market.
It is indeed, and by far. I hate titlebars, but love pretty borders, and Emerald is the only one that alow me to have this configuration.
I wish I knew enough C++ and about WMs so as to even have a look at it, but I'm nowhere near that
[...]SIDENOTE: Compiz can be compiled with Link Time Optimizations with the latest GCC, but don't do this unless you've got 4-8gig of RAM, as it will suck up lots of memory in the process, and it takes much longer to compile. (not to mention CPU usage will be very high during LTOs) ~ but now, when i login - compiz seems to be up and running decidedly faster than without LTO
Out of curiosity, how do you enable these?
From the responses I've seen to this thread, I'm guessing it's best to keep 0.8 in [community] for now. I may have just been luck to manage to get a stable configuration.
Is there any change 0.8 and 0.9 can coexist in [community], though?
Last edited by hobarrera (2012-04-09 12:49:49)
Offline
It seems 0.9.x is now into the tidying-up phase; a shed load of bugs have been squashed in the past couple of months. Hopefully, version 0.9.9.96-9 won't be required before a stable branch is announced ;-)
triplesquarednine, I noticed you've been active on Launchpad - thanks for taking the time to prod the team on behalf on non-Ubuntu linux users!
"Its too big and too slow"
Offline
triplesquarednine wrote:[...]SIDENOTE: Compiz can be compiled with Link Time Optimizations with the latest GCC, but don't do this unless you've got 4-8gig of RAM, as it will suck up lots of memory in the process, and it takes much longer to compile. (not to mention CPU usage will be very high during LTOs) ~ but now, when i login - compiz seems to be up and running decidedly faster than without LTO
Out of curiosity, how do you enable these?
It's fairly straight forward. You just add these CXXFLAGS to the CXXFLAGS in your build script ( be that AUR, or otherwise);
-flto=1 -flto-partition=none -fuse-linker-plugin -fipa-pta
EDIT: You probably actually want -flto-partition=lto1 - I think i cut and paste, from the wrong line in my (compile) reference/cheat sheet.
As a quick warning, compiling compiz-core with LTO (at least master branch from lp:/bzr) will seem like it is about to hang, at around 40% finished. you'll see at least one core stuck at 100% (or bouncing between cores), don't worry, just give LTO time. lto1 (the process) will also suck up atleast 1.4-5gig of RAM, alone -while also gcc and others will be consuming memory.... I've seen llvm, ICC, openCC all show this kind of behavior (giving the appearence of "hey, i am about to die, and if you let me, i'm going to suck every drop of your memory"...lol, when doing heavy optimizations. However, sometimes in the case, at least with ICC and OpenCC - the compile had to be terminated, as it *was* stuck/hung/burnt toast. Which is why i mentioned that this optimization takes resources and additional time.
In fact, almost every time you hit linking, expect it to take some time (as expected, and compiz takes a while at the linking stage, anyway).
Here is also a few notes on LTO;
1. GCC-4.7 - changes/notes - just scroll down to the 'new optimizers' part. They explain LTO a little bit, with an example or two;
http://gcc.gnu.org/gcc-4.7/changes.html
2. Random guy talking about compiling Wine with LTO. I actually (just) recompiled wine-1.5.1-rt with -lto, but haven't really tested it out, yet. I'm also doubting the impact it would have being as the compile only hit 3-4 spots where lto was actually doing anything. But he also gives his own explanation, with examples. Someone might find it useful though.
http://www.eve-search.com/thread/1493881
anyway, let me know how it works out. ...and just to clarify, when i said 'faster' - i just mean at startup, LTO obviously shouldn't affect graphical performance.
cheerz
Last edited by triplesquarednine (2012-04-09 21:12:20)
Offline
It seems 0.9.x is now into the tidying-up phase; a shed load of bugs have been squashed in the past couple of months. Hopefully, version 0.9.9.96-9 won't be required before a stable branch is announced ;-)
triplesquarednine, I noticed you've been active on Launchpad - thanks for taking the time to prod the team on behalf on non-Ubuntu linux users!
Yeah, they are definitely smashing a lot of bugs, and reworking some code.
..and no problem, i wish more compiz users would participate on launchpad with bug reports and the like. It would definitely help the cause, and LP isn't hard to use, nor signup for. I also have my own interest of wanting compiz to not be engulfed by Unity, and stay usable on other distros, which is why i test it on CentOS, Fedora and Archlinux, and usually report building issues, as many times when i file a report on some plugin/GFX issue, it's already being handled.
Offline
Is there any change 0.8 and 0.9 can coexist in [community], though?
Stable versions go in the official repos, development versions are provided via the AUR. Why should Compiz be any different? However, you can install Compiz 0.9.x alongside 0.8. The old compiz-*-09 in the AUR did just that. Check the build instructions at compiz.org for further information.
I also have my own interest of wanting compiz to not be engulfed by Unity, and stay usable on other distros...
Indeed. Fingers crossed that they continue to apply fixes upstream where appropriate. And then hopefully come 1.0, Compiz will be taken up by the distros that have dropped it since the project was taken under the Canonical wing... Making 'Unity' a hard dependency would make a nonsense of Compiz anyway; why retain an extensible, modular codebase for a distro-specific, unity-specific window manager?
"Its too big and too slow"
Offline
hobarrera wrote:Is there any change 0.8 and 0.9 can coexist in [community], though?
Stable versions go in the official repos, development versions are provided via the AUR. Why should Compiz be any different? However, you can install Compiz 0.9.x alongside 0.8. The old compiz-*-09 in the AUR did just that. Check the build instructions at compiz.org for further information.
I guess you're right. It's just that it takes pretty long to build. I'm also interested in trying triplesquarednine's recomendations for LSO, and that would take even longer.
I've been setting up a repo to use accoss all my machines though, that should save me most of the build time.
triplesquarednine wrote:I also have my own interest of wanting compiz to not be engulfed by Unity, and stay usable on other distros...
Indeed. Fingers crossed that they continue to apply fixes upstream where appropriate. And then hopefully come 1.0, Compiz will be taken up by the distros that have dropped it since the project was taken under the Canonical wing... Making 'Unity' a hard dependency would make a nonsense of Compiz anyway; why retain an extensible, modular codebase for a distro-specific, unity-specific window manager?
Yes, I hope this as well... I've been pretty scared of this lately. Emerald has already died (even though it already wasn't 100% supported).
Offline
Indeed. Fingers crossed that they continue to apply fixes upstream where appropriate. And then hopefully come 1.0, Compiz will be taken up by the distros that have dropped it since the project was taken under the Canonical wing... Making 'Unity' a hard dependency would make a nonsense of Compiz anyway; why retain an extensible, modular codebase for a distro-specific, unity-specific window manager?
Well, I know from talking with Sam at the end of last year, that the plan is NOT to have Unity absorb Compiz. I also think Daniel (another *very active* Compiz-dev) committed fixes to non-ubuntu systems, and by his comment on my one report - i got the impression it is important to him that compiz can be used elsewhere, too.
I'm still waiting for them to commit 2 fixes that i haven't seen a notification update on yet - the 1st being the /lib64 build problem, which was *the bug* that got Compiz dropped from Fedora. :\ Basically, the compiz-devs never fixed it. So the (Compiz-Fedora) maintainer said screw it, and dropped it from Fedora's repos... All over one line, that statically linked /lib (which breaks it on all RPM distros as they use /lib64 .... So, after finding this out, i re-filed the bug on launchpad (at was on opencompositing.org originally). and obviously, the second bug is linked from your AUR comments - the one LDFLAG must be added (can't remember off-hand which one)...
I guess you're right. It's just that it takes pretty long to build. I'm also interested in trying triplesquarednine's recomendations for LSO, and that would take even longer.
I've been setting up a repo to use accoss all my machines though, that should save me most of the build time.
Compiz doesn't take too long to compile ~ what sort of hardware are you running???
Myself, i can compile compiz (all components), in maybe 10-15 minutes. - Im running a Phenom II x4 965 (3.4ghz quadcore). But with LTO it takes ages (well mainly compiz-core does) the rest compiles slower, but not painfully slow like -core.
cheerz
Last edited by triplesquarednine (2012-04-09 21:42:32)
Offline
It's the prettiest decorator on the market. Also by far the buggiest and crashiest.
I never had any issues with Emerald, but I rarely experience bugs and crashes where others tear their hair our.
Offline
Well, I know from talking with Sam at the end of last year, that the plan is NOT to have Unity absorb Compiz. I also think Daniel (another *very active* Compiz-dev) committed fixes to non-ubuntu systems, and by his comment on my one report - i got the impression it is important to him that compiz can be used elsewhere, too.
Good to hear! Long may Compiz eschew full union with Herr Führer Shuttleworth in favour of the bit on the side
I'm still waiting for them to commit 2 fixes that i haven't seen a notification update on yet - the 1st being the /lib64 build problem, which was *the bug* that got Compiz dropped from Fedora. :\ Basically, the compiz-devs never fixed it. So the (Compiz-Fedora) maintainer said screw it, and dropped it from Fedora's repos... All over one line, that statically linked /lib (which breaks it on all RPM distros as they use /lib64 .... So, after finding this out, i re-filed the bug on launchpad (at was on opencompositing.org originally).
Yes, the nature of his remarks regarding the issue in that stupid "Is Compiz dead?' thread on the Phoronix forums are, shall we say, illuminating... Although, his frustrations is of course understandable to some extent...
hobarrera wrote:I guess you're right. It's just that it takes pretty long to build. I'm also interested in trying triplesquarednine's recomendations for LSO, and that would take even longer.
I've been setting up a repo to use accoss all my machines though, that should save me most of the build time.Compiz doesn't take too long to compile ~ what sort of hardware are you running??? Myself, i can compile compiz (all components), in maybe 10-15 minutes. - Im running a Phenom II x4 965 (3.4ghz quadcore).
I've noticed it is considerably slower to build on an old Core Duo Macbook, as opposed to my desktop running a Phenom II x3 @ 3.2 GHz.
@Fritz: Are you still unable to get gtk-window-decorator working? I found time to test on a system without any Ubuntu patched packages and was fine. Animation bugs aside, I'm finding 0.9.7 to be very usable. Then again, I don't use many plugins. I wish Sam would just jettison all the exploding, wobbly cube bollocks!
"Its too big and too slow"
Offline
@Fritz: Are you still unable to get gtk-window-decorator working? I found time to test on a system without any Ubuntu patched packages and was fine. Animation bugs aside, I'm finding 0.9.7 to be very usable. Then again, I don't use many plugins. I wish Sam would just jettison all the exploding, wobbly cube bollocks!
I switched back to 0.8 after some hours of using 0.9. I crashed all over the place, was totally unusable for me.
zʇıɹɟʇıɹʞsuɐs AUR || Cycling in Budapest with a helmet camera || Revised log levels proposal: "FYI" "WTF" and "OMG" (John Barnette)
Offline
Yes, the nature of his remarks regarding the issue in that stupid "Is Compiz dead?' thread on the Phoronix forums are, shall we say, illuminating... Although, his frustrations is of course understandable to some extent...
Well, i do sympathize with Leigh on the matter. The fact is, Compiz-devs made a commit which broke building compiz on RPM distros. That bug is easily fixable and Leigh even provided the patch. He was the guy who made sure Compiz was available in Fedora - so the least the Compiz-devs could do, was commit the patch. But they never got around to it / bug report was lost in the shuffle, etc. I think i am going to comment on my bug report today, and add other (RPM) distros to the list of affected distros.
I've noticed it is considerably slower to build on an old Core Duo Macbook, as opposed to my desktop running a Phenom II x3 @ 3.2 GHz.
well, yeah. there is a pretty big difference between a Core Duo vs. a Phenom x3. lol Compiles are usually pretty quick on my Phenom II x4, i guess i have gotten to comfortable and forgotten the joys of compiling on older systems.
@Fritz: Are you still unable to get gtk-window-decorator working? I found time to test on a system without any Ubuntu patched packages and was fine. Animation bugs aside, I'm finding 0.9.7 to be very usable. Then again, I don't use many plugins. I wish Sam would just jettison all the exploding, wobbly cube bollocks!
I don't use any Ubuntu-patched versions of software with Compiz, so i can verify that gtk-window-decorator works. The animation bugs, are currently the most annoying thing (which i am barely affected by, as i don't use many animations). I've disabled most for now. I think closing menus, open/close windows are the only animations that i use (in my case, i am using 'glide 2'). I do use desktop wall (yes, it works in master branch), but disable expo (which i need to file a bug report about, or add myself to a bug, if it's already filed). I also don't use things like wobbly windows (which works fine), nor do i use things like 3d-cude (haven't even tried it).
...anyways, I still want to encourage all of you to join launchpad and help the non-ubuntu distros report problems with 'Vanilla Compiz'. There are very few of us, reporting from other distros. Just make sure, that you check for similar reported bugs before reporting. If you find one, add yourself to the bug report, and specify that you aren't using Ubuntu.
cheerz
Last edited by triplesquarednine (2012-04-10 15:44:12)
Offline
rufflove wrote:@Fritz: Are you still unable to get gtk-window-decorator working? I found time to test on a system without any Ubuntu patched packages and was fine. Animation bugs aside, I'm finding 0.9.7 to be very usable. Then again, I don't use many plugins. I wish Sam would just jettison all the exploding, wobbly cube bollocks!
I switched back to 0.8 after some hours of using 0.9. I crashed all over the place, was totally unusable for me.
I've only found that the previews in the static application switcher killed compiz (and, on a laptop, crashed the video drivers or something alike), but that's the only real bug I came across.
pogeymanz wrote:It's the prettiest decorator on the market. Also by far the buggiest and crashiest.
I never had any issues with Emerald, but I rarely experience bugs and crashes where others tear their hair our.
It was reallly buggy in compiz 0.9, until it was finally dropped. It works fine in 0.8.
rufflove wrote:@Fritz: Are you still unable to get gtk-window-decorator working? I found time to test on a system without any Ubuntu patched packages and was fine. Animation bugs aside, I'm finding 0.9.7 to be very usable. Then again, I don't use many plugins. I wish Sam would just jettison all the exploding, wobbly cube bollocks!
I don't use any Ubuntu-patched versions of software with Compiz, so i can verify that gtk-window-decorator works. The animation bugs, are currently the most annoying thing (which i am barely affected by, as i don't use many animations). I've disabled most for now. I think closing menus, open/close windows are the only animations that i use (in my case, i am using 'glide 2'). I do use desktop wall (yes, it works in master branch), but disable expo (which i need to file a bug report about, or add myself to a bug, if it's already filed). I also don't use things like wobbly windows (which works fine), nor do i use things like 3d-cude (haven't even tried it).
...anyways, I still want to encourage all of you to join launchpad and help the non-ubuntu distros report problems with 'Vanilla Compiz'. There are very few of us, reporting from other distros. Just make sure, that you check for similar reported bugs before reporting. If you find one, add yourself to the bug report, and specify that you aren't using Ubuntu.
cheerz
I have zero ubuntu packages; and it works perfectly fine. I've yet to come across an animation bug though.
And yes, I agree, we need a non-ubuntu compiz test team, otherwise, it'll eventually not-work outside of ubuntu. I've reported a few bugs, but they don't seem to get much attention though.
Offline
I have zero ubuntu packages; and it works perfectly fine. I've yet to come across an animation bug though.
And yes, I agree, we need a non-ubuntu compiz test team, otherwise, it'll eventually not-work outside of ubuntu. I've reported a few bugs, but they don't seem to get much attention though.
No animation bugs, eh? What is your setup (video card, etc). You are using the compiz-dev packages in AUR, right? (i'm not, i build directly from master - so that being said, i do expect the odd issue).
For me, the animation bugs are related to minimizing. I get 'failed to bind pixmap to texture' when repeatedly clicking on AWN/dock (ie: quickly minimizing/un-minimizing).
...and when using transitions like 'magic lamp', when you un-minimize a window the effect looks fine, but when you minimize it ~ it only draws metacity and doesn't draw the window's contents. It's also inconsistent, one time it might look okay, the next time it doesnt. weird.
Maybe i'll ditch all of my gconf/gsettings for compiz and start from scratch (i suppose there could be something in there screwing things up).
EDIT: Hobarrera, thank you for posting that you weren't experiencing issues with animations. - it got me motivated to sort out my issues... I just ditched all of my settings, recompiled Compiz and viola ~ animations seem to be okay, although i need to test further.
Also, i commented on my bug report that causes the build to fail with GCC-4.7 ~ i suggest any/all of you guys to do the same (you can add yourself to the bug and comment, if you like). Also, if you point me to your bug reports and i can reproduce them (locally), I will add myself to them and comment as well. ~ this is probably how us archers can get notice on Launchpad, by pooling our resources together
Last edited by triplesquarednine (2012-04-11 18:28:03)
Offline
Is there a simple way to build the compiz-dev packages with a different prefix, so that they don't conflict with Compiz from the repos?
Offline
Is there a simple way to build the compiz-dev packages with a different prefix, so that they don't conflict with Compiz from the repos?
IIRC, you can just change the following line in PKGBUILD
-DCMAKE_INSTALL_PREFIX=/usr \
The above becomes
-DCMAKE_INSTALL_PREFIX=/opt/compiz-dev \
You should also want to make sure that none of the files copied over in "package" with "install -m644" conflict with compiz 0.8 ones.
Offline
pogeymanz wrote:Is there a simple way to build the compiz-dev packages with a different prefix, so that they don't conflict with Compiz from the repos?
IIRC, you can just change the following line in PKGBUILD
-DCMAKE_INSTALL_PREFIX=/usr \
The above becomes
-DCMAKE_INSTALL_PREFIX=/opt/compiz-dev \
You should also want to make sure that none of the files copied over in "package" with "install -m644" conflict with compiz 0.8 ones.
Where should those files go then? In particular, the .desktop files will overwrite existing files.
Offline
hobarrera wrote:pogeymanz wrote:Is there a simple way to build the compiz-dev packages with a different prefix, so that they don't conflict with Compiz from the repos?
IIRC, you can just change the following line in PKGBUILD
-DCMAKE_INSTALL_PREFIX=/usr \
The above becomes
-DCMAKE_INSTALL_PREFIX=/opt/compiz-dev \
You should also want to make sure that none of the files copied over in "package" with "install -m644" conflict with compiz 0.8 ones.
Where should those files go then? In particular, the .desktop files will overwrite existing files.
You need to alter this in the PKGBUILD. Replace the first line with the second.
A quick hack to avoid the .desktop file colission would be to alter the
install -m 664...
lines, an have them install with a different name (or not at all if you don't need them).
You could also build all the packages locally, and download the 0.8 ones, so you can quickly uninstall one set, and install the other. That's what I did when testing. Not too clean, but got the job done. Installing takes <1m
Compiz 0.8 and 0.9 save their config in different places by default, so that won't be an issue.
Offline