a) be aware that the client has _vast_ impact on resizing performance, ensure you didn't test xterm against kdevelop

b) the fps counters are afaik not really comparable... (also you might vsync in one and not in the other)

c) which decoration do you use? (some are much slower than others...)

d) the geometry hint (little box with size info in the middle of the window) is known to sometimes cause trouble on resizes when compositing is active

e) try to set another pixmap allocation strategy

read: nvidia-settings -q InitialPixmapPlacement

write: nvidia-settings -a InitialPixmapPlacement=n | n = 0-4

reason: kwin creates an offscreen pixmap of the window size and renders the decoration into it, then pulls pixmaps from the actual frame, converts them to textures and renders the onto the scene. we're all aware that this ain't "optimal", but w/o changing the deco plugin API it is required.

allocatin ARGB pixmaps can be _very_ slow with some of the above settings, changes should apply (nearby) immediately, but you could suspend/resume compositing to (hopefully) force the strategy update

FWWI:
compiz + emerald resizes ("normal") much slower than kwin (bespin deco, tiny borders) on my gt7600... but equally fast if i set the bordersize > tiny what causes the offscreen pixmap to be FAAAAR bigger

a) Dolphin VS. Dolphin
b) I disabled VSync in KWin, still slow
c) GTK window decorator at Compiz, Redmond at KWin
d) No hint in Dolphin
e) Doesn't make any difference in KWin, 2 is best in Compiz

For me it's the same, even though I have an ATI raedon video card.

nb. that if it's _really_ laggy (like 500ms), you might face bug #243094 (there's a testcase attached)

I'm resizing with bitmap and it works very smoothly, so you can try this as WORKAROUND (it doesn't solve the problem!).

http://www.youtube.com/watch?v=tghx_th-u_Y I'm guessing that it's not as easy, as it seems to be, to solve this problem, because even after working on this, it's still laggy.

Actually I'm on 4.7.4, but I'll try beta of 4.8 (if I'll find it in Arch repo :P ).

By resizing with bitmap you mean the "resize" effect (ie. texture scaling) i assume?

The patch demonstrated in the video (prensent in 4.8, not 4.7) does NOT intend to make resizing "smoother" (miswording) but fix the XSYNC protocol, ie. make the WM wait until the client is done with resizing (though this lowers load on the client and effectively makes resizing faster and avoid glitches of eg. a bright decoration below a black konsole, the non-update can make it feel even more laggy)

We tried to cover the time while the client is not done with texture scaling, but naive attempts to do this have lead to judder (because of the scaled/resized texture swaps - it might work by crossfading between the textures -> 4.9)

I've never seen compiz resizing faster here (rather the opposite) but it heavily depends on
a) the window decoration (some perform better using the native graphicssystem, some prefer the raster graphicssystem)
b) the state of the nvidia pixmap cache (we somewhen figure that it was flooded, happened prefereably in kde sessions but unrelaed of the WM)
the cache can be flushed by dis/enabling it:

nvidia-settings -a PixmapCache=0; nvidia-settings -a PixmapCache=1

Don't try to be extra smart, "nvidia-settings -a PixmapCache=0 -a PixmapCache=1" is valid but will do nothing.

Also the latter blob drivers (290.x) have at least here added an enormous perfomance gain (related to the ARGB pixmap allocation, try to disable the titlebar for a window, eg. by selectiong the option in the alt+f3 menu and resize it with alt+rmb - if it resizes much faster, that pixmap allocation is your problem)
Since then the native graphiscsystem is slightly faster than the raster system here when resizing dolphin (where the "slow" internal part are the side panels - places, information, tree, etc.)

Yes, I meant texture scaling. Thanks for highlighting that I was wrong.

I checked how does resizing works on KDE 4.8 beta 2 on Arch. I works very strange, eg. when I want to make window x cm wider, is grows about 2x cm, when making it x cm smaller, it decreases 2x cm. I'll try to record this.

Qt4.8/beta && some Aurorae theme decoration?

There is/has been a bug regarding position mapping in Qt 4.8 every now and then since January (they've added, removed, added, removed that code ;-)

No idea whether it will hit other decorations as well, but Aurorae is prone to this because it uses a QGraphicsScene.

Also at least some themes have (here) a really horrible performance when it comes to resizing.

sounds to me like the scaling bug I fixed the other day

http://www.youtube.com/watch?feature=player_detailpage&v=DAk7cUKBmL4 here you can see what I meant.

Qt 4.7.4, default Oxygen in KDE (but not default colour scheme).

Yupp, is - from the description i thought of superscaling.

@Wiktor:
The window resizes correctly but by removing the empty resize feature the texturescaling was tied to the sync events as well, so you've basically synced texture scaling ;-)

Is there any option to have back resizing only by texture?

It's a bug, texturescaling will work as ever in 4.8rc1
Right now you have to compile current git master.

Thanks for your help :)

do people here still think that resizing is laggy?

I have this problem with kde 4.13.1 and nvidia binary driver 337.19

Frame rate drops to under 15 while resizing any windows.

- Also w/o compositing?
- Also for resizing xterm?
- please attach the output of "qdbus org.kde.kwin /KWin supportInformation"

Created attachment 86746 [details]
qdbus org.kde.kwin /KWin supportInformation

The problem happens with all windows including xterm.
It does not seem to occur when desktop effects are turned off.

Does it change
- for a singlescreen setup?
- with the "laptop" decoration?
- when disabling borders on the oxygen decoration?
- for a completely undecorated window (Alt+F3 -> More Actions -> No Border; you can use Alt+Right mouse button to resize the window)
- when disabling the blur and/or translucency effect?
- with XRender compositing?

Single screen: Bad
Laptop decoration: Bad
Oxygen, no borders: Bad
for a completely undecorated window: Bad

Disable blur: Bad
Disable translucency: Bad
Disable both: Bad

Xrender(both native, raster): Good

Additionally, the FPS drops to ~50 while maximizing windows or snapping out maximized windows(Only with opengl)

(In reply to comment #22)
> Additionally, the FPS drops to ~50 while maximizing windows or snapping out
> maximized windows(Only with opengl)

you are aware that the FPS effect is not a good way to validate any problems, right?

I doubt that would be visible. Most clients can't resize  @60Hz and those not supporting XSYNC are capped at 30Hz anyway (because humans cannot reasonably resize at that precision)

The issue will likely be the texture re-allocation for the window.

@Keerthan
Can you please try:
- to set vsync to "none"
- OpenGL 1.3
- force down buffer age: "export KWIN_USE_BUFFER_AGE=0; kwin --replace &"

If that all doesn't help, as a workaround, there's a resize effect that performs texture scaling.
Do you recall recent version transitions for kde-workspace and nvidia? (Which then caused this)

(In reply to comment #23)
> (In reply to comment #22)
> > Additionally, the FPS drops to ~50 while maximizing windows or snapping out
> > maximized windows(Only with opengl)
> 
> you are aware that the FPS effect is not a good way to validate any
> problems, right?

I was not. I just used it cause I thought it was better than just saying it 'feels slow'. What would be a good way to validate problems?

> @Keerthan
> Can you please try:
> - to set vsync to "none"
> - OpenGL 1.3
> - force down buffer age: "export KWIN_USE_BUFFER_AGE=0; kwin --replace &"

This seems to make it better(However, there is only opengl 1.2, not 1.3). 

> If that all doesn't help, as a workaround, there's a resize effect that
> performs texture scaling.
> Do you recall recent version transitions for kde-workspace and nvidia?
> (Which then caused this)
I beleive nvidia drivers were recently updated in my distro. I'll try reverting and seeing if it helps.

(In reply to comment #25)

>  What would be a good way to validate problems?

You should be able to resize xterm @30Hz - unless you're an insect or bird, that is "fluid".

Temp. framerate losses for eg. maximizing are usually caused by the window decoration (for oxygen, disable animations) but if the GPU is generally slow on allocating texture, that will oc. impac any resize (inc. maximization)

The major problem with the fps counter is that it triggers full resizes itself, ie. it severely impacts measuring (esp. if blurring is active)
Unlike games, KWin does not operate on a constant or "fast as possible" framerate (it repaints what and when it becomes necessary)

(In reply to comment #26)
> > @Keerthan
> > Can you please try:
> > - to set vsync to "none"
> > - OpenGL 1.3
> > - force down buffer age: "export KWIN_USE_BUFFER_AGE=0; kwin --replace &"

> This seems to make it better
Which of those? Any? Or did you just try the combination?
(Iirc we require ARB_texture_border_clamp, ie. 1.3 - but the setting actually just means "fixed function path, no shaders")

This problem has been fixed with Nvidia 337.25 (opengl 3.1, raster).