Bug 191329 - Windows resizing choppy with white borders
Summary: Windows resizing choppy with white borders
Status: RESOLVED UPSTREAM
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: Unlisted Binaries Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 192273 194257 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-05-02 11:30 UTC by Christian
Modified: 2010-10-11 18:32 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian 2009-05-02 11:30:45 UTC
Version:            (using KDE 4.2.2)
OS:                Linux
Installed from:    Unspecified Linux

When I resize a window, the performance are poor on my geforce 7400, with any drivers (lastest works better)
While resizing the borders of the windows become instantly white and after half a second the resizing complete and the window is showed in the new size

I can't notice the problem if I enter in kde (4.2.2) via root account
Comment 1 FiNeX 2009-05-02 12:00:16 UTC
Are you using desktop effects?
Comment 2 Christian 2009-05-02 12:06:11 UTC
I have effects enabled, disabling them the situations looks better, but the way to the perfection is so far!
Comment 3 Thomas Lübking 2009-05-02 17:41:57 UTC
nvidia-settings -a InitialPixmapPlacement=2 -a GlyphCache=1
you /don't/ have to restart X

you can place it in ~/.xsession to call it every time X starts
notice that especially the "GlyphCache=1" statement (not related to this issue, but nice option as well) may lead to artifacts (notably on beta drivers)

there's also some article on techbase.kde on this, but i lost the link -> gg yourself ;-P
Comment 4 Christian 2009-05-03 11:39:51 UTC
(In reply to comment #3)
> nvidia-settings -a InitialPixmapPlacement=2 -a GlyphCache=1
> you /don't/ have to restart X
> 
> you can place it in ~/.xsession to call it every time X starts
> notice that especially the "GlyphCache=1" statement (not related to this issue,
> but nice option as well) may lead to artifacts (notably on beta drivers)
> 
> there's also some article on techbase.kde on this, but i lost the link -> gg
> yourself ;-P



No improvements noticed
Comment 5 Thomas Lübking 2009-05-03 17:05:17 UTC
err, just to be sure: does it happen if you run sth. simple like e.g. "xterm"?
Comment 6 Thomas Lübking 2009-05-11 00:01:00 UTC
*** Bug 192273 has been marked as a duplicate of this bug. ***
Comment 7 Thomas Lübking 2009-05-11 00:16:08 UTC
X (usually, maybe check) runs with root permissions anyway.

what happens if you run 
kdesu "kwin --replace"
inside a normal user session?

if this doesn't help you, it's
- either some environment variable (/etc/profile, ~/.bashrc, ~/.xsession - notably stuff that changes nvidia-settings assignments) or 
- maybe a background process that sucks away your memory.
Comment 8 Martin Flöser 2009-05-27 09:58:02 UTC
*** Bug 194257 has been marked as a duplicate of this bug. ***
Comment 9 Christian 2009-05-27 10:06:01 UTC
In order to give you some other informations, I deleted every files in my home directory, so next time I started KDE I had a new and clean environment; but the problem remained!!

So I created a new user account, and the problem disappeared! The 2D performance are quite poor yet, but comparable with Windows Vista with desktop composition enabled. I know that now everything is vectorial, and svg images are everywhere, but I think that overall 2D performance could be improved again!

This weekend I'll try my new home pc with a Intel Graphics Media Accelerator X4500 HD... I'll give another tip  ;)
Comment 10 Martin Flöser 2009-06-04 23:17:38 UTC
alt+f3 -> settings -> moving -> Display content in resizing windows

Unsetting this checkbox should improve the performance, but doesn't look so nice.
Comment 11 Christian 2009-06-04 23:34:49 UTC
(In reply to comment #10)
> alt+f3 -> settings -> moving -> Display content in resizing windows
> 
> Unsetting this checkbox should improve the performance, but doesn't look so
> nice.

that's not a solution

on an Intel Graphics Media Accelerator X4500 HD things go better but still not smooth
Comment 12 Thomas Lübking 2009-06-05 00:05:24 UTC
1. (and in the first place) i thought the problem disappeared (due to a new account - what likely means you had some entry or lacked some entry from a carried over b.c. account and your distro sets proper environments as new account defaults) yesno?

2. you didn't answer whether this happens on windows with lightweight content.
the reason is that whatever you use in a window may perform extremely expensive operations on resizes (scale an image w/o HW support, re-render complex svg's, relayout a page, ...) and that's beyond KWin at all.
(i.e.: what's your situation on resizing a simple xterm)

3. your "new home pc" with the intel chip does not happen to have a more powerful CPU, does it...?
Comment 13 Christian 2009-06-05 00:21:17 UTC
(In reply to comment #12)
> 1. (and in the first place) i thought the problem disappeared (due to a new
> account - what likely means you had some entry or lacked some entry from a
> carried over b.c. account and your distro sets proper environments as new
> account defaults) yesno?
> 

the problem disappeared when I created a new account, and the things run much better, but now the environment seems going slower and slower in time; I can't understand wtf could cause this... Root account always runs quickier. I use Arch Linux, no strange environment settings, no strange applications sucking (video)memory

> 2. you didn't answer whether this happens on windows with lightweight content.
> the reason is that whatever you use in a window may perform extremely expensive
> operations on resizes (scale an image w/o HW support, re-render complex svg's,
> relayout a page, ...) and that's beyond KWin at all.
> (i.e.: what's your situation on resizing a simple xterm)
> 

I tried resizing Konsole, and it's quite good. Okular and dolphin are (obviously) much slower

> 3. your "new home pc" with the intel chip does not happen to have a more
> powerful CPU, does it...?

mm... actually you are right, the cpu is more powerful... I believed the principal componente involved in resizing (and geometry transformations) wer the video card

I opened this bug because I tried a not so powerful Macbook, that has a composite desktop, and the environment runs much MUCH better. (I don't know if the desktop components are vectorial)
Comment 14 Thomas Lübking 2009-06-05 15:39:44 UTC
a) OSX vs. X11 is not quite comparable. (built on different purposes, background & assumptions in different decades (as for Quartz eXtreme: centuries/millenniums ;-)

b) the only thing on a KDE desktop where vector graphics really painfully hurt you are plasma (and a skinnable vector style that can be found on kde-look.org)

c) resizing has multiple layers and afaik no X11 toolkit yet makes use of HW T&L or even vector shaders.

1: the X11 window needs to be resized and in consequence (on a composited) desktop the buffering pixmap
-> trap 1: nvidia drivers - and - others - used to be quite slow on this, bad pixmap mem allocation strategy, see #3)

2: the window "content" need to be resized
-> trap 2: the toolkit may gather resize requests and perform them at once to save cpu cycles (this is most likely why you can observe "white" artefacts. the window is resized but the content not (yet) - even on konsole (as e.g. Qt and gtk+ indeed collects resize events) -> try xterm, nothing's gathered there
-> trap 3: the resize may trigger massive relayouting inside the application, costing a lot of cpu and thus blocking visual updates

d) as for the environment "goes slower" and "is faster for root": 
(in general) do /NOT/ feel tempted to run a root system. never. /NOTHING/ is worth that.
there may be some (background) process(es) running wild - nspluginviewer (flash...) is a great candidate -> monitor your cpu usage (open a terminal and type "top", ksysguard is a nice GUI variant, but of course takes resources itself as well =D
Comment 15 Christian 2009-06-05 16:27:28 UTC
(In reply to comment #14)
> a) OSX vs. X11 is not quite comparable. (built on different purposes,
> background & assumptions in different decades (as for Quartz eXtreme:
> centuries/millenniums ;-)

ok


> c) resizing has multiple layers and afaik no X11 toolkit yet makes use of HW
> T&L or even vector shaders.

maybe developing a so powerful toolkit won't be a bad idea

> 
> 1: the X11 window needs to be resized and in consequence (on a composited)
> desktop the buffering pixmap
> -> trap 1: nvidia drivers - and - others - used to be quite slow on this, bad
> pixmap mem allocation strategy, see #3)

resizing spins my cpu up to 80-90%, not nvidia's fault

> 2: the window "content" need to be resized
> -> trap 2: the toolkit may gather resize requests and perform them at once to
> save cpu cycles (this is most likely why you can observe "white" artefacts. 

aaaaahh... :) 

> the window is resized but the content not (yet) - even on konsole (as e.g. Qt and
> gtk+ indeed collects resize events) -> try xterm, nothing's gathered there
> -> trap 3: the resize may trigger massive relayouting inside the application,
> costing a lot of cpu and thus blocking visual updates

ok, I undestand, I only say that a video card could do this work hundreds times faster

> d) as for the environment "goes slower" and "is faster for root": 
> (in general) do /NOT/ feel tempted to run a root system. never. /NOTHING/ is
> worth that.
> there may be some (background) process(es) running wild - nspluginviewer
> (flash...) is a great candidate -> monitor your cpu usage (open a terminal and
> type "top", ksysguard is a nice GUI variant, but of course takes resources
> itself as well =D

I know, I tried it only because I had the suspect of wrong permissions on my user. Anyway root account runs faster, what can you say about this? on my user account I have nothing active and cpus run at 1-7%
Comment 16 Thomas Lübking 2009-06-05 17:16:22 UTC
(In reply to comment #15)
> maybe developing a so powerful toolkit won't be a bad idea

just for the records (this is slight OT, but i guess s.o. would bring it up otherwise)
Qt 4.5 has an (experimental) OpenGL render backend, but it's not really fast in this regard, as the geometry calculations are still performed on the CPU (and mostly by the styles)
For some reason the raster backend seems to do better on this, but has other drawbacks... :-(

> resizing spins my cpu up to 80-90%, not nvidia's fault
interesting question: in which process?

> ok, I undestand, I only say that a video card could do this work hundreds times
> faster
problem is that X11 (needs to) support(s) a WIIIDE range of systems including cross network ones (what it was designed to do in the first place back then)
apple introduced Quartz with the knowledge: "will run on an opengl capable system" and before Quartz eXtreme, Quartz still used to be eXtremely slow...)
 
> user. Anyway root account runs faster, what can you say about this? on my user
> account I have nothing active and cpus run at 1-7%

a) how's the cpu usage on actually resizing compared for root and non root?
b) your experience sounds like running processes nice'd* (i.e. either kwin has a higher priority or your processes a lower one by default on user accounts
e.g. try running "nice konqueror" from your root account. does the behaviour align?
b2) another option would the kernel scheduler setup - choose another one

(*) 4th entry in the top list "NI", bigger values mean "nicer" i.e. get less cpu time. 0 is the default
Comment 17 FiNeX 2010-10-10 22:31:22 UTC
Hi Christian, is this performance issue still reproducible with more recent video driver and KDE version?
Comment 18 Christian 2010-10-11 09:47:35 UTC
Hi! I'm using Kde 4.5.2 on lastest drivers on two different machines: the first runs on an Intel 4500HD and the resizing works like a charm, even with composition enabled (anyway disabling it the overall performances get a huge speed up); the second machine has a geforce go 7400 with lastest drivers and the resizing is MUCH better than the situation that stroke me to open this bug, but this old video card is more powerful then the Intel one above mentioned, but even if the resizing and 2D performances are acceptable, the are not comparable with the fluidity of the Intel platform of the first machine
Comment 19 FiNeX 2010-10-11 11:46:58 UTC
So this is clearly a video driver problem, thanks for the feedback!
Comment 20 Martin Flöser 2010-10-11 17:59:42 UTC
so let's mark it as a driver bug. There is not much we can do about the NVIDIA driver except recommending nouveau (resizing is much faster there). The proprietary driver is known to be slow on initial texture from pixmap and it will hopefully improve in future driver releases, though it is possible that it will not improve the situation for "legacy" cards.
Comment 21 Thomas Lübking 2010-10-11 18:32:53 UTC
<advert> try the resize effect (>=4.5), works great with XRender and OpenGL, is as fast as emty resizing and might be sufficient </advert>