I can confirm this. It's maybe the same as Bug #158984

In order to reproduce:
o Start a GTK-Based window (e.g gimp, dia, inkscape,...)
o Resize the window - make it larger, then as small as possible, then larger again
=> The second enlargement happens step-wise 

Even the following simple program reproduces the problem:

#include <gtkmm/window.h>
#include <gtkmm/main.h>
int main(int argc, char* argv[])
{
  Gtk::Main app(argc, argv);
  Gtk::Window win;
  win.set_size_request(320,240);//not necessarily
  app.run(win);
  return 0;
}

For me resizing is slow for KDE and Qt apps as well, as long as compositing is active.

IIRC this was not the case with the betas of KDE 4.2.

Toggling off compositing makes resizing fast again.

I use the proprietary fglrx driver on kubuntu intrepid/amd64, with the KDE 4.2 packages from kubuntu.org

I confirm partly:
Qt4 programs resize normaly.
Opera, KDevelop3 somewhat slow.
Thunderbird very slow.

This happens to me also, with KDE 4.2.1 and 4.2.2.  The resizing speed in Firefox, Chromium pre-alpha, and Audacity drops from 30+fps to 2fps as soon as I try to make the window to small.

If I type "killall kwin", the resizing performance temporarily resets to normal.

This happens regardless of whether or not desktop effects are enabled.

Can reproduce. Comment #2 is a different bug.

(In reply to comment #4)
> Firefox, Chromium pre-alpha, and Audacity drops from 30+fps to 2fps as soon as

for the records, afaik non of the above is a plain gtk app (audacity uses wxwindows, firefox xul and google probably wine? dunno.)

i can - in a way - reproduce it with ff:
a) if you resize the window with alt+rmb: no problem
b) if you resize it using the deco (doesn't matter) or the FF resize handle, the problem occurs

i assume both use different instructions or flag clipping, as e.g. the deco cannot resize a window below it's self set min. size - neither can the ff resize handle while alt+rmb allows you to resize the window wherever you want (what will make some (real) gtk apps crash if you shrink them to a zero size ;-P )

cpu usage of ff/x/kwin keeps however "normal"

I was using Pidgin (Pure GTK+) and the problem occurs with both decoration and alt+drag resizing here.

ok, i /may/ have managed to trigger this /once/ with alt+rmb resizing lags, but it took more approaches (i resized gimp several times to /almost/ (0,0) (it segfaults on 0,0) and back. after 5 attempts or so it started to lag)

i could however not reproduce this so far (with or without composite, yes: i finish the moveresize in between...) so i might have deco-resized by accident.
deco resizing lags reliably ;-)

i tried with the pixmap and the nimbus engine (as aurora/murrine crashes X...)

gtk is
libgtk-x11-2.0.so.0.1200.11
libgtkmm-2.4.so.1.0.30

kwin --replace clears the situation
deactivating snapping and windowcontent doesn't help either, nor forcing kwin to ignore geometry requests

For me window resizing using decoration or alt+rmb, even if its not minimum size of window (after 1-5 times resizing) very sloooow. For example, applications what i use and affected by this bug: Firefox, brasero, thunderbird, avidemux, soundKonverter (QT3 !!!).
Only QT4 applications works normally with kwin... ;(

I usually have normal CPU usage when I re-size a window, no mater it's QT or GTK. 
The difference between GTK and QT windows comes when I re-size a GTK (or QT3)  window to the minimum allowed size (some programs define minimal width/height ) and then back to some wider size, the resizing is slow (as shown on the video clip).
I have this problem with every application which directly or indirectly depends on GTK (e.g pidgin, firefox) or QT3 (e.g old kile, basket). QT4 applications work normally.
When I do 'kwin --replace' nothing changes. Compiz and Metacity don't have this problem.
I have this problem, no mater if 3D is running or not, on both Fedora and Ubuntu, since the first KDE4 I've ever installed (I think even before the first beta).

I can reproduce this bug with every application uses GTK. 
Arch Linux:
Qt: 4.5.1
KDE: 4.2.3 (KDE 4.2.3)
KWin: 4.2.3 (KDE 4.2.3)
The cpu usage is the same, but it is really nasty :(

I can reproduce this on KDE-4.2.90, with both the intel and the vesa driver.
I've also experienced it with KDE-4.2.0 on older X releases.

It can be triggered by resizing a GTK or QT3 window very fast, suddenly resize performance drops to 1-2fps, however CPU consumption stays low.
This is rally annoying.

please vote for this bug if you want to get it fixed ;)

Btw. some videos I made:
http://www.youtube.com/watch?v=NSuasl4_vdc
http://www.youtube.com/watch?v=0uZT9Zdmvxw

Can reproduce here to. KDE 4 apps resize normally, while Firefox 3.5 and gvim ( http://www.vim.org/ ) have a very sluggish resize. I'm on Mandriva Linux Cooker with a Radeon HD 2600 card and the open-source radeonhd driver (in case it matters). Very annoying.

(In reply to comment #15)
> Can reproduce here to. KDE 4 apps resize normally, while Firefox 3.5 and gvim (
> http://www.vim.org/ ) have a very sluggish resize. I'm on Mandriva Linux Cooker
> with a Radeon HD 2600 card and the open-source radeonhd driver (in case it
> matters). Very annoying.

I should note that this problematic behaviour is not exhibited on IceWM, Enlightenment 17 and GNOME.

Same thing here on KDE 4.3 RC1 with a NVidia GeForce 7-series card and the proprietary nvidia driver, version 185.

Can confirm this on KDE 4.3 RC2 with nvidia 8600GT. This seems to be a regression - I had no such problem on any of KDE 4.2.x.

still present in 4.3.0, really annoying.

This bug still exists in KDE 4.3.0 (Arch)
PLEASE vote for it! 
Really really really annoying :'(

Just figured that i can get a window into the jumpy mode by disabling "Display content in resizing windows" (i.e. i disabled the setting, opened the "Mainwindow" from gtk-demo -> the xor rect jumps on resize. closed the window, enabled the setting, opened again -> no problem) If the window however once was affected the problem remains across "Display content in resizing windows" changes.

Compositing (enabled, disabled, suspended) doesn't matter.

Can anyone reproduce this?

(In reply to comment #21)
> Can anyone reproduce this?

Sure,by disabling "Display content in resizing windows" the GTK window acts "jumpy" while resizing.

Created attachment 36524 [details]
don't try to xsync if sync_counter_value.hi/lo is 0 or on contentless resizes

frankly:
i do not know whether the sync_counter_value.hi/lo part is really "the" fix or just a workaround - i just googles a comment that said some gtk+ patch would do a special treatment on this value (no sync at all)

- i can no more reproduce the issue
- the contentless resize part indicates that it's in XSync for sure.
- i can confirm that sync requetsts are still regularily fired on resizes with the patch

please anyone else test and/or clarify the gtk situation

It seems all applications/toolkits that support _NET_WM_SYNC_REQUEST for smoother resizing are affected by that bug.

Trolltech plans to integrate support for this into QT-4.6, and  - running the sample-binary they provide shows exactly the same sympthom.
So it seems when KDE switches to QT-4.6, this bug will show up anyway.

http://labs.trolltech.com/blogs/2009/06/10/smooth-and-solid-resizing-on-x11/

SVN commit 1030473 by lmurray:

Prevent KWin from sending out multiple sync requests before the client
has time to reply.
BUG: 183263


 M  +1 -1      geometry.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1030473

SVN commit 1030474 by lmurray:

Backport r1030473:
Prevent KWin from sending out multiple sync requests before the client
has time to reply.
CCBUG: 183263


 M  +1 -1      geometry.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1030474

Not sure if I should reopen this bug, as it says something about "minimum size", and probably is not related to rubberband resizing.

But I still have very slow "resizing without showing contents" (aka rubberband mode) with kdebase r1030691 and Qt from todays 4.6 branch.

The rubberband jumps in about 500 ms steps. For every window.

Sorry, not for every window, but for every Qt window, as "xterm" works fine. I do not have any GTK apps installed to try this, but I had this problem once Qt got xsync support. Since the timer in KWin (500 ms) is exactly the speed for my rubberband "jumps", I see this bug and bug 181800 highly related.

take a look at the attached patch, the value check is wrong (given there's a pending flag...) but the resize mode probably should be handled (there's no point in syncing when not displaying anything anyway)

SVN commit 1030921 by lmurray:

Don't send sync requests when using the rubber band for window resizing.
BUG: 181800
CCBUG: 183263


 M  +2 -1      geometry.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1030921

SVN commit 1030922 by lmurray:

Backport r1030921:
Don't send sync requests when using the rubber band for window resizing.
CCBUG: 181800
CCBUG: 183263


 M  +2 -1      geometry.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1030922

will this be undone for kde4.4 which uses qt4.6?

It is already fixed, and backported to KDE-4.3.3 :)

(In reply to comment #33)
> It is already fixed, and backported to KDE-4.3.3 :)

Forgive me if I misunderstood but this is the proper fix: http://labs.trolltech.com/blogs/2009/06/10/smooth-and-solid-resizing-on-x11/

and this fix here only a workaround?

(In reply to comment #34)
> (In reply to comment #33)
> > It is already fixed, and backported to KDE-4.3.3 :)
> 
> Forgive me if I misunderstood but this is the proper fix:
> http://labs.trolltech.com/blogs/2009/06/10/smooth-and-solid-resizing-on-x11/
this is additional goodess provided by Qt. So Qt 4.6 will make it faster. Nevertheless we should fix bugs in our own code. And if I am not completely mistaken lmurray was running Qt 4.6 at the time he fixed the bugs.

On Wed, Nov 4, 2009 at 3:13 PM, Martin Gräßlin
<ubuntu@martin-graesslin.com> wrote:
> https://bugs.kde.org/show_bug.cgi?id=183263
>
>
>
>
>
> --- Comment #35 from Martin Gräßlin <ubuntu martin-graesslin com>  2009-11-04 15:13:07 ---
> (In reply to comment #34)
>> (In reply to comment #33)
>> > It is already fixed, and backported to KDE-4.3.3 :)
>>
>> Forgive me if I misunderstood but this is the proper fix:
>> http://labs.trolltech.com/blogs/2009/06/10/smooth-and-solid-resizing-on-x11/
> this is additional goodess provided by Qt. So Qt 4.6 will make it faster.
> Nevertheless we should fix bugs in our own code. And if I am not completely
> mistaken lmurray was running Qt 4.6 at the time he fixed the bugs.
>
> --
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.

okay, so it won't have negative effects (like window content not
updating any more during resize)?
Anyway can the patch mentioned in the blogpost (this is a backport for
maemo: http://qt.gitorious.org/+qt-maemo-developers/qt/qt-maemo/commit/0565a98dda69fee09aee83e36655c9a9f4c90c56?diffmode=sidebyside
) be bbackported to kde's qt4.5 branch so, kde users wont have to wait
another six months for this qt goodness?

(In reply to comment #36)
> okay, so it won't have negative effects (like window content not
> updating any more during resize)?
no
> Anyway can the patch mentioned in the blogpost (this is a backport for
> maemo:
> http://qt.gitorious.org/+qt-maemo-developers/qt/qt-maemo/commit/0565a98dda69fee09aee83e36655c9a9f4c90c56?diffmode=sidebyside
> ) be bbackported to kde's qt4.5 branch so, kde users wont have to wait
> another six months for this qt goodness?
no. There's no need. No distribution would ship this. Kubuntu, Fedora and Mandriva just released, openSUSE is in hard freeze and I am not aware of any distribution which will have a release before Qt 4.6 will be released.

If you want to have this feature, just use Qt 4.6. Your distribution should have packages for it or just build from sources. Qt 4.6 is working fine with KDE 4.3 - I'm just typing this post in a KDE 4.3/Qt 4.6 combination of Konqueror.

Could somebody please re-open this bug?

I experience exactle the sympthoms described here with QT-4.6.1 + KDE-4.4.0 when resizing native KDE-4.4 applications.
Although it has become harder to triggert the slow-resize-mode, when its reached the app behaves exactly like under older versions of kwin.

(In reply to comment #38)
> Could somebody please re-open this bug?
> 
> I experience exactle the sympthoms described here with QT-4.6.1 + KDE-4.4.0
> when resizing native KDE-4.4 applications.
> Although it has become harder to triggert the slow-resize-mode, when its
> reached the app behaves exactly like under older versions of kwin.

Well, I've been using KDE-4.4.x (with libqt4-devel-4.6.1-4mdv2010.1 ) for hours and everything is perfectly fine in this regard. Can you try to provide a reproduction recipe?

Its now harder to trigger than in 4.3, but after resizing KDE4.4/Qt-4.6 apps for a while KWin again falls back to super-slow-resize mode.
I'll try to find a reproduction recipe, and record a video.

Still experience this problem with KDE-4.4.80 + QT-4.7beta, although its harder to trigger than before the "fix": http://www.youtube.com/watch?v=U6C4JW773O8

Please re-open, or should I create new report?

Can confirm that this bug isn't fixed.

KDE 4.4.5
Qt 4.6
Arch Linux x86_64

I was able to write a sample application which reliably triggers this problem on kde-4.5.0/QT-4.7-rc1 in Bug 243094.
Please have a look, and vote.

(In reply to comment #43)
> I was able to write a sample application which reliably triggers this problem
> on kde-4.5.0/QT-4.7-rc1 in Bug 243094.
> Please have a look, and vote.

Hi! I can now reproduce this behaviour with Clemens' "qclock" application. After I resize it to its minimal size, it gets resized very slowly. Mandriva Cooker on a P4-2.4GHz with an ATI Radeon HD 2600 Pro card, with the radeon drivers and without the desktop effects enabled.

I'm reopening this bug report.

Regards,

-- Shlomi Fish

Created attachment 51137 [details]
fix assignment of "sync_resize_pending"

f*** i forgot to attach the bugreport, sorry & see here:
http://osdir.com/ml/kwin/2010-07/msg00270.html

------------- Snip --------------
as clemens kindly provided a testcase on bug 243094 and after testing the code 
a bit i think i found the source of the issue and a fix.

disclaimer:
i've no knowledge about the protocol design at all, sorry

it turned out that if a second sync request is send to the client before a 
sync event is received this seems to mess up things in the client and no more 
sync events are received in kwin for that client.

the solution was to move the unconditioned "sync_resize_pending = false;" into 
the Client::syncEvent()

this fixes the testcase, it will no more fallback to the sync timer (notice 
that a 10 second block after 50 resize events in the testcase is intended and 
raises the issue)

i also tested a(n unsync')d wine client w/o any regression.

it would be great if whoever wrote the XSYNC code could have a look into this 
solution and merge it or give an Ok to commit.

Thanks,
Thomas
------------- /Snip --------------

i attached the patch as well  should still apply

SVN commit 1175748 by luebking:

fix pending XSYNC requests, bugs partially closed due to suggested relation by the reporters
please re-open them if this does not fix it

BUG: 178269
BUG: 183263
BUG: 241094
BUG: 243094


 M  +1 -0      events.cpp  
 M  +0 -1      geometry.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1175748