Bug 244253 - Resizing is very laggy
Summary: Resizing is very laggy
Status: RESOLVED UPSTREAM
Alias: None
Product: kwin
Classification: Unclassified
Component: compositing (show other bugs)
Version: unspecified
Platform: Unlisted Binaries Linux
: NOR normal with 2 votes (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-11 21:39 UTC by Nikita Churaev
Modified: 2014-05-31 18:26 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
thomas.luebking: NVIDIA+


Attachments
qdbus org.kde.kwin /KWin supportInformation (4.98 KB, text/plain)
2014-05-21 16:10 UTC, Keerthan Jaic
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nikita Churaev 2010-07-11 21:39:48 UTC
Version:           unspecified (using KDE 4.4.4) 
OS:                Linux

When I resize a window, it feels very jerky and FPS fall to 20. I have NVIDIA GeForce GTS 250, lastest drivers and Compiz with --sm-disable and --loose-binding feels smooth and gives like 40 FPS. 

Reproducible: Always

Steps to Reproduce:
Enable composite and try to resize a window.

Actual Results:  
It feels very jerky

Expected Results:  
Should be smooth
Comment 1 Thomas Lübking 2010-07-11 22:02:42 UTC
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
Comment 2 Nikita Churaev 2010-07-11 22:43:32 UTC
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
Comment 3 Martin 2010-07-19 08:41:59 UTC
For me it's the same, even though I have an ATI raedon video card.
Comment 4 Thomas Lübking 2010-07-19 16:23:54 UTC
nb. that if it's _really_ laggy (like 500ms), you might face bug #243094 (there's a testcase attached)
Comment 5 Wiktor 2011-12-13 12:04:42 UTC
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 ).
Comment 6 Thomas Lübking 2011-12-13 13:20:53 UTC
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.)
Comment 7 Wiktor 2011-12-13 13:54:21 UTC
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.
Comment 8 Thomas Lübking 2011-12-13 14:00:13 UTC
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.
Comment 9 Martin Flöser 2011-12-13 14:13:11 UTC
sounds to me like the scaling bug I fixed the other day
Comment 10 Wiktor 2011-12-13 14:13:56 UTC
http://www.youtube.com/watch?feature=player_detailpage&v=DAk7cUKBmL4 here you can see what I meant.
Comment 11 Wiktor 2011-12-13 14:16:42 UTC
Qt 4.7.4, default Oxygen in KDE (but not default colour scheme).
Comment 12 Thomas Lübking 2011-12-13 14:32:26 UTC
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 ;-)
Comment 13 Wiktor 2011-12-13 14:39:16 UTC
Is there any option to have back resizing only by texture?
Comment 14 Thomas Lübking 2011-12-13 14:54:17 UTC
It's a bug, texturescaling will work as ever in 4.8rc1
Right now you have to compile current git master.
Comment 15 Wiktor 2011-12-13 14:58:06 UTC
Thanks for your help :)
Comment 16 Martin Flöser 2014-01-08 13:58:36 UTC
do people here still think that resizing is laggy?
Comment 17 Keerthan Jaic 2014-05-21 02:41:28 UTC
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.
Comment 18 Thomas Lübking 2014-05-21 07:07:26 UTC
- Also w/o compositing?
- Also for resizing xterm?
- please attach the output of "qdbus org.kde.kwin /KWin supportInformation"
Comment 19 Keerthan Jaic 2014-05-21 16:10:22 UTC
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.
Comment 20 Thomas Lübking 2014-05-21 16:15:20 UTC
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?
Comment 21 Keerthan Jaic 2014-05-23 23:38:40 UTC
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
Comment 22 Keerthan Jaic 2014-05-23 23:41:21 UTC
Additionally, the FPS drops to ~50 while maximizing windows or snapping out maximized windows(Only with opengl)
Comment 23 Martin Flöser 2014-05-24 06:36:40 UTC
(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?
Comment 24 Thomas Lübking 2014-05-24 12:04:59 UTC
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)
Comment 25 Keerthan Jaic 2014-05-25 01:09:18 UTC
(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?
Comment 26 Keerthan Jaic 2014-05-25 01:14:11 UTC
> @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.
Comment 27 Thomas Lübking 2014-05-25 09:11:10 UTC
(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)
Comment 28 Thomas Lübking 2014-05-25 09:15:58 UTC
(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")
Comment 29 Keerthan Jaic 2014-05-31 18:15:15 UTC
This problem has been fixed with Nvidia 337.25 (opengl 3.1, raster).