Faster move and resize (For people using current git...)

[gnumdk]

Here beryl resize plugin and bouge plugin for current git...

http://hibbert.univ-lille3.fr/~cbellegarde/Compiz/bouge.tar.gz
http://hibbert.univ-lille3.fr/~cbellegarde/Compiz/resize.tar.gz

ps: use bouge if you have performance problems with move plugin

[stjepan]

What's the diff between bouge and move?

[delfick]

What's the diff between bouge and move?

bouge is smoother :D

[stjepan]

Why is it smoother? What does move plugin do different?

[gnumdk]

It sync window position while moving and not at the end...
It should be fixed soon i hope...

[mikedee]

Just a bit more background info...

David believes that the correct way for things to behave is to sync the window position with the server on each move rather than when you finish moving the window. He recently changed the move plugin to do that but it is causing some performance issues with some (most) people. The bouge plugin is just an old version of move taken before those patches were applied. He is going to fix some OTHER issues which are affecting performance so that hopefully this hit will be less noticeable. The decorators are probably not helping much so they will be improved. Move will not be fixed from what I understand, other problems will be fixed instead.

Resize is a different issue, resize has always been slow (for similar reasons). The beryl resize included other modes which only hide the slow resize by not actually resizing the window but by showing an outline or a stretched texture. The compiz resize will soon have the outline modes but probably not the stretch mode (because its fugly), maybe something similar could be done for the move plugin (it would be very easy). An advantage of the compiz resize plugin is that it will allow each mode to have a window match so that you can use outline mode for only firefox windows (notorious for slow resizing), but normal mode for everything else.

P.S. I edited the title of the thread to be more descriptive :)

[maniac]

The compiz resize will soon have the outline modes but probably not the stretch mode (because its fugly),

I hope it will be included soon; I have sent an updated set of patches to David for review today (including stretch mode ;) ).


maybe something similar could be done for the move plugin (it would be very easy).

Would be easy, indeed ... in principle, this is what the move plugin did before ;)


An advantage of the compiz resize plugin is that it will allow each mode to have a window match so that you can use outline mode for only firefox windows (notorious for slow resizing), but normal mode for everything else.

Just as disclaimer: This part still needs to be coded ;)

[RYX]

Very useful information - thanks. And I can confirm that the decorator is heavily affecting performance during resize-operations. While experimenting with the decorator I tested a version which simply draws a non-blurred shadow and no fancy decoration (only a solid colored rectangle) - the resize immediately got MUCH faster. I assume the metacity-engine is a real performance-monster when it comes to resizing and most likely it also affects the move-operations with its slow drawing.

[gnumdk]

David believes that the correct way for things to behave is to sync the window position with the server on each move rather than when you finish moving the window.

It's not really true, here David thinking about this:

"so having support for only updating the server-side position when we're finished moving a window is useful and I'll add that back to the move plugin later in a more appropriate way. The old way it was done was bad."

[mikedee]

David believes that the correct way for things to behave is to sync the window position with the server on each move rather than when you finish moving the window.

It's not really true, here David thinking about this:

"so having support for only updating the server-side position when we're finished moving a window is useful and I'll add that back to the move plugin later in a more appropriate way. The old way it was done was bad."

Thanks for that, I think that the applications which are causing the problems are the decorators, hopefully once they are fixed it shouldn't be too urgent to update the move pugin back to the old way.

Did anyone with really bad move problems try killing the decorator and see if it fixes it? It does for me. It could be the same for resize but I did not test that.

[cornelius]

Here (Xgl+fglrx), there is 10-20% cpu usage difference between with and without decorators.

By the way, did Move get better recently (from around 90% cpu usage down to 50% or less), or is it just me? (this is with decorators on)

[ufoman]

Yeah, the main issue with these two is the decorator... emerald seems to be much slower than KDE decorator from compiz on my r300 open driver+AIGLX setup.

[gnumdk]

For me without any decorator, "bouge" plugin is much more faster than "move" plugin...

[mikedee]

The resize plugin in git has now been updated to be much faster, plus it has the extra modes Outline, Rectangle and Stretch

[andqso]

I've got the latest version checked out, but don't notice a difference. What is the name of the key to set the mode?

[mikedee]

As long as you check out recently the key is 'mode' and it can be set to any of these values

0 = Normal
1 = Outline
2 = Rectangle
3 = Stretch

[andqso]

Got it. I was using the old-style string key rather than ints.
Thanks.

[Fireblend]

I have a stupid question, I downloaded the douge plugin but I can't seem to compile it, gives me a ton of errors, what do I have to do to compile it? Thanks in advance.

[mikedee]

Please post the first error that you get, also tell us what version of compiz you are using.

[bob]

Here beryl resize plugin and bouge plugin for current git...

http://hibbert.univ-lille3.fr/~cbellegarde/Compiz/bouge.tar.gz
http://hibbert.univ-lille3.fr/~cbellegarde/Compiz/resize.tar.gz

ps: use bouge if you have performance problems with move plugin

Can someone please repost these (at least bouge)? The link goes nowhere for me, sits there and spins forever going nowhere. Thanks.

[gnumdk]

The issue is fixed in current git...
Just look at move options ;)

[bob]

I seen the check box, but no difference happens so I figured it was not yet done. But with as slow as Compiz Fusion is right now maybe I should not be surprised. I keep checking (git pull) back every weekend hoping one time it will run as nice as Beryl did, (actually does, it is what i use), but it only ever seems to get jerkier and jerkier, and with less options enabled than in Beryl. All the people that have helped me with my Xorg config and Compiz launch options, their advice usually makes it run even slower.

And now with cooler plugins like Shift I am getting more sad :\

[RYX]

I seen the check box, but no difference happens so I figured it was not yet done. But with as slow as Compiz Fusion is right now maybe I should not be surprised. I keep checking (git pull) back every weekend hoping one time it will run as nice as Beryl did, (actually does, it is what i use), but it only ever seems to get jerkier and jerkier, and with less options enabled than in Beryl. All the people that have helped me with my Xorg config and Compiz launch options, their advice usually makes it run even slower.

And now with cooler plugins like Shift I am getting more sad :\
Compiz is amazingly fast for me. The slowliness must be related to certain plugins or a bad startup-line. What graphics-card do you use? If you like you could post your problem in the Q&A section ... (please not respond here to avoid going more off-topic)

:)

[dagurasu]

I'm using ATI/AIGLX (XGL works better, but my wine (old codeweavers version) windows don't refresh typing :( in XGL ). Anyway, in normal KDE windows resize faster than my eye can detect and smoothly following the mouse as fast as I can move it and not with some jerky stretch-like behavior.

In compiz-fusion from gentoo xeffects svn overlay installed a few days ago (I don't know how this relates to git of July) normal mode is not only very slow and jerky, but I can't even move the mouse itself smoothly while resizing, making it difficult to resize to the size I want.

This is NOT a decorator issue. The results are reproducible with no decorator. Stretch resize is very fast, just not very nice.

[cerebro84]

I quote the last post.

[Alejandro Nova]

In my system, this relates directly to X11R7.3 and specifically to xorg-server 1.4. With xorg-server 1.3, the resize plugin behaves normally. With xorg-server 1.4, it started to show those problems.

[werner]

The 1.4 server has in fact errors; during compilation are accused about 10 C errors (in scancpi, hal etc) and looking in the source code it's really wrong at these places. I reclaimed this to the x people, but they didn't repair this. On the other side, currently Im continue using server 1.3 but all other files of X 7.3 (except of xf86-* and xkeyboard-conf, which are incompatible), but also on my sistem resizing dont work smoothly.