Versions of KDE after 4.5.x don't seem to have a rubber band resize (or move) option for KWin. I've seen this discussed in a few places. Usually the following things have been said:

"Composite resize effects accomplish the same thing."

There's some overlap, but not enough to get the job done.
- Many video cards (or video drivers) don't properly support OpenGL compositing.
- Many computers are not fast enough to do software compositing well.
- Compositing doesn't work at all over VNC, which is where you really need rubber band move/resize.

"Rubber band resize is bad because it grabs the display."

Not necessarily.
- Most KDE multimedia applications can handle display grabs without audio getting out of sync.
- More importantly, there are implementations that don't grab the display; see for instance Fluxbox and especially Openbox.

"KWin already uses the X SYNC extension."

This just means that windows resize more choppily, but look a bit prettier while they rerender. It doesn't help much when rendering is slow.

So I'm wondering why these options were removed from KWin, because they definitely qualify as useful IMHO. Was the removal due to bad quality code, perhaps? Is a non-compositing resize effect due to be reimplemented at any point?

Gullible Jones wrote:So I'm wondering why these options were removed from KWin, because they definitely qualify as useful IMHO. Was the removal due to bad quality code, perhaps? Is a non-compositing resize effect due to be reimplemented at any point?

IIRC the rubber-band was just broken and no there are no plans to reimplement this feature.

Many video cards (or video drivers) don't properly support OpenGL compositing.

KWin has an Xrender based compositor. I just revived a dead notebook with an r100 (on XGA) and it works like charm (seriously)

Many computers are not fast enough to do software compositing well.

KWin does no "software compositing" and i don't suggest trying llvmpipe.

Compositing doesn't work at all over VNC, which is where you really need rubber band move/resize.

The idea once was to run a local compositor (equal to WM or not) to prevent all pointless exposureevent caused repaints.
Done right, it will make remote clients less painful.

"KWin already uses the X SYNC extension."
This just means that windows resize more choppily, but look a bit prettier while they rerender. It doesn't help much when rendering is slow.

This is wrong. The extension limits the resize events to what the client (and protocol) can keep up with, therefore preventing request overloads, thus leading to less traffic.
Whether the extension is sufficient to allow remove resizes is another question.

Thanks for the information, luebking...

luebking wrote:This is wrong. The extension limits the resize events to what the client (and protocol) can keep up with, therefore preventing request overloads, thus leading to less traffic.
Whether the extension is sufficient to allow remove resizes is another question.

So the SYNC extension may actually be useful on remote desktops? Interesting.

However, I will say that on local desktops it slows things down a lot, or at least appears to. Compare resizes on current Fvwm (no SYNC) vs. Openbox (SYNC) on a computer with an Intel GPU, for instance.

It doesn't slow down things.

What you observe is that the WM can (often resize the decoration at some hundred FPS, but most clients cannot resize at nearly that pace.

For a somewhat fair comparism try with a naked 24bit (no translucency) Qt window (no content but sync) with windows or cde style. (you simply need the client being resizable as fast as possible)

Whatever you observe beyond this just means that the WM resizes as fast as it can and spams the client with resize events which it cannot keep up with.
Since the client has to deal with many resize events which are obsolete at the time they're handled, it looses too much time doing so - effectively resizing slower (and being the bottle neck in the operation)

=> whenever you encounter a client resizing to slow, encourage its developers to accelerate this
eg. the decoration kcm used to resize at a *horrible* pace since it deals with plugins of which only one can be loaded at a time and also the now used graphicsview hates the native graphicssystem.
=> we made it keeping & stretching the cached pixmap for a while and repainting "threaded" across the eventloop. before that it could easily take up to a second for every resize step.

Thanks again.

At the moment I'm running the Plasma desktop with a custom build of Openbox, compiled without XSync support; and the apparent difference is staggering. Both windows and Plasma widgets appear to resize faster than with XSync-enabled Openbox, and KDE applications seem to launch faster. I guess most of this is an illusion? i.e. window frames moving out of sync with window contents, or appearing before the contents finish rendering, and thereby creating the erroneous impression of better performance.

OTOH, I've seen some stuff on how keeping things synchronized can itself be a bottleneck on some video cards, e.g.
https://bugs.launchpad.net/compiz/+bug/1049214
But not sure if this applies here (although all of my computers have rubbishy Intel video cards).

I can say that there's definitely a bit more CPU usage. OTOH, interaction with the desktop feels so much smoother and less jerky that I think I'll stick with this setup. This is probably pure psychology, but half of "desktop performance" is psychological anyway.

Plasma widgets have absolutely *nothing* to do with the XSYNC extension.
Any performance impact in that regard could be due to compositing - at best.

In the composited environment, applications which support it are not shown before reacting on the initial sync.

https://bugs.launchpad.net/compiz/+bug/1049214 is completely unrelated.
Calling "XSync(dpy, False)" is "The evilish Roundtrip"
It's a requirement of the X11 protocol and basically ensures that every request has been performed (by the server) - eg. if you want to use an image, you have first upload that to the server and ensure the server has it set up before you can start using it for graphical operations.
This /is/ the bottleneck in X11 and kwin therefore started to use the asynchronous communication via xcb. (Do not expect some epic boost out of this, though)

The XSYNC protocol only allows the WM to tell the client: "Resize!", have the client at some point reply "Done!" and prevent the WM from issuing more "Resize!" commands in the meantime.

Please don't ask who or why picked that name here - even some developers were confused about this relation.

This allows but actually does not require the WM to throttle its own resizes to the pace of the client. Doing so prevents you from seeing glitches between the WM background and the Client contents, but by this of course makes resizing seem less reactive.
We tried hybrid approaches where the compositor would cover the inresponsive time of the client by a scaled texture (as is available as plain effect) but this just gets you sea-sick.

luebking - I believe you, but I also can't argue with the SYNC-less desktop's much more responsive feel, especially on my very low-spec netbook. This "solution" works for me, even if it technically offers worse overall performance and more CPU usage; so for now I will stick with it.

(I will note also that Openbox has its own version of "rubber band resize," which resizes the window frame, but doesn't redraw the window until the resize stops. It looks shabby, but is probably saner than disabling SYNC; those using KDE on computers with poor graphics cards, and willing to replace KWin, might take interest.)

In case you've compositing enabled, try activating the resize effect.
It doesn't resize the client (until you end the resize) and should be by far faster than either synced or unsynced resize.