likely bug #282882
add a shellscript to ~/.kde/env

---- snip: qt-graphicssystem.sh  ----------
#!/bin/sh
export QT_GRAPHICSSYSTEM=native
--- /snip -----------------------

log out/in report the outcome.

Thanks, I've switched to QT_GRAPHICSSYSTEM=native but unfortunately with no success. https://bugs.kde.org/show_bug.cgi?id=282882 I was hurting from this issue but in 4.7.4, now everything is fine except menu shadows/tooltips (button tooltips, task manager shadows are fine - strange)

Ok, sorry. I clicked the link in the post and missed the attachment.
Looks more exactly like bug #280116 - still an NPOT issue :-\

The way the oygen decoration shadows and the popup shadows are generated differs a bit.
If you can install bespin and select it's decoration you will most likely encounter the same issue for the decoration shadows, yesno?

Yeah, bespin is all broken:

http://bayimg.com/gAMOMaadg

Oh gosh I messed up, i just realized that I had qt_graphicsystem=native from the begging, now with raster I have whole oxygen broken also just as it was in 4.7.4

to sum up:
native & oxygen = broken only tooltips/menus
raster & oxygen = all shadows broken + messed up decorations just like in Bug 282882

native & bespin = all shadows broken, but decorations ok
raster & bespin = same as raster & oxygen

They're probably all the same issue.

Unfortunately afaik we don't have access to an r200 chip and i can't try on the FX5200 unless nvidia releases drivers for the current X11 version (since nouveau does not suffer from this issue and "breaking" NPOT here had no effect, the nvidia driver probably treats NPOT and rect ARB textures the same internally :-(

fglrx does probably not support that chip anymore, does it? (so you could test whether it occurs there as well or rect textures are just broken in ati and legacy nvidia)

FTR: do we know whether this also affects R200 chips (since the 9200 is actually an RV280 chip and the RV significantly differs from the R series - cheaper design ;-)

@Martin:
maybe we can just check whether NPOT is supported and otherwise just prescale the shadow pixmaps to make the shadow texture POT and fix the offsets?

fglrx supports HD2xxx and newer Radeons afaik

You're right 9200 is rv280 chip, as we are on that - maybe some fund-raising? Older cards are fairly cheap - used & working rv280 card is <10euro so we could gather some older hardware to kwin team as play/test ground. Maybe working on optimizations for older hardware will bring some improvements on newer hardware also? - people just love that. I know this is not high priority so we need to decide if it's worth the effort. 

BTW if it doesn't make sense on r200/rv280 era of hardware maybe you need not-so-old cards for testing? I've finished Doom3 on GeForce2 MX 200 for crying out loud :D so I think that moving 2D windows on better cards shouldn't be so problematic ;)

> You're right 9200 is rv280 chip, as we are on that - maybe some 
> fund-raising?
> Older cards are fairly cheap - used & working rv280 card is <10euro
> so we could
> gather some older hardware to kwin team as play/test ground.
Getting the cards is not the issue. Getting them into the system is the 
problem. Even the oldest hardware I have around does not have an AGP or 
PCI socket any more. Using a system so old that it could carry such a 
card would be so slow on compiling that I would not even want to do it, 
even if I were paid to do it.
> Maybe working on
> optimizations for older hardware will bring some improvements on
> newer hardware
> also?
No, they are too special to have any advantage for newer hardware. More 
likely disadvantage due to additional code pathes

> @Martin:
> maybe we can just check whether NPOT is supported and otherwise just
> prescale the shadow pixmaps to make the shadow texture POT and fix the
> offsets?
That could work. IIRC we used to increase the texture size for non-NPOT in 
some places...

Ok, i probably have it.

The texture is prescaled anyway in the NPOT case and because of that and the packed format we cannot use the texture dimensions as divisor but MUST use the calculations used when creating the texture (before scaling)

The scaling apparently still causes some glitches (probably again because of the packed format resulting in false interpolation values - i'll test that tomorrow) but it's nowhere like just scaling the texture and using the texture dimensions.

@lukasas
can you try a patch (ie. have the kwin sources, apply the patch and recompile kwin)?

> @lukasas
> can you try a patch (ie. have the kwin sources, apply the patch and recompile
> kwin)?

Yeah, shouldn't be a problem but you need to guide me step by step as I never aplied a patch ;) (don't worry I not total noob)

get the kde-workspace/kwin sources

git clone git://anongit.kde.org/kde-workspace

next fetch this patch:
https://bugs.kde.org/attachment.cgi?id=68592

copy it into the kde-workspace/kwin directory and apply it
patch -p2 < __fix_NPOT_shadows.diff

leave the kwin directory and "mkdir BUILD" in kde-workspace, enter the BUILD dir
ccmake ..
press c [optionally deselect everything you don't actually  want to compile and press c again]
press g
wait ;-)
cd kwin
make && sudo make install

OK, on patched Kwin: oxygen + raster + compositing = very nice working windows shadows but crash and fallback when any kind of tooltip is about to show up

and backtrace (strangely short)

http://pastebin.com/FUcpvsPf

stack corruption

umm ... "git branch" - if "master" has a leading asterisk
-> "git reset --hard HEAD; git checkout KDE/4.8"
reapply the patch and recompile, sorry - didn't think of that...

OK, with new build:

oxygen + raster + compositing = very nice working windows shadows: http://bayimg.com/BAmNKaadH

no crash on tooltips :)

small glitches (on classic menu, firefox, dolphin menus etc, looks like buttons tooltips are not affected(?)): http://bayimg.com/BAmnLAaDH

no shadows under panel tooltips and kickoff menu

other than that: user experience way better than with broken shadows ;) (any performance hit because of patch?)

no, actually it might get faster - i'm not sure why we pot scale the texture if GL_ARB_texture_rectangle is supported though.


While at it, you could try what happens if you manipulate the end of the patch file

delete m_texture;
- m_texture = new GLTexture(image);
+ m_texture = new GLTexture(image, GL_TEXTURE_RECTANGLE_ARB);


This patch should also resolve the remaining glitches
http://git.reviewboard.kde.org/r/103888/

After new patch: everything seems fine :) window shadows ok, no crashes whatsoever, tooltips and menu shadows ok, no glitches on menu shadows but they remain in logout/shutdown popups: http://bayimg.com/mAMcEaadi

I noticed sluggish window moving if windows are big, small windows moving very fast/responsively, the bigger window the slower it becomes to move (it could be due hardware limited powers, I'll test this on official kwin from repos later)

New patch with edited last lines: I would say the same as above, maybe sluggishness of big windows is more noticeable (but it can be autosuggestion)

PS should I uninstall/make clean or something like that before installing kde workspace from repos? Also I didn't do anything like that before each of next tests - just new compilation and installation + reboot to be sure - hope this doesn't messed up results(?)

PSS on applying edited patch I get: 

patching file scene_opengl.cpp
Hunk #9 succeeded at 1684 with fuzz 2.

don't know what this mean, but everything went fine without errors

OK I got this, about sluggishness:

it's matter of refresh rate, this PC is hooked up to CRT display, with 60Hz window moving even big ones is always responsive, on 85Hz big windows can be sluggish to move (tested with or without v-sync enabled through KCM)

this tests can be inaccurate cause this PC need more RAM for KDE (512MB is not enough and a lot of swapping occurs but this refresh thing seems to be always reproducible)

(In reply to comment #18)
> remain in logout/shutdown popups: http://bayimg.com/mAMcEaadi
I'm not sure whether this are already "new" shadows or stuff painted into the ARGB window by the plasma theme. It's afaik however intended to ultimately pipe all shadow rendering through the affected code.

> I noticed sluggish window moving if windows are big, small windows moving very
> fast/responsively, the bigger window the slower it becomes to move
Because more of the screen has to be updated - it's a matter on how powerful your system (GPU) is. You should probably rather disable effects like blur (if that is supported on that GPU at all)

> New patch with edited last lines: I would say the same as above, maybe
> sluggishness of big windows is more noticeable (but it can be autosuggestion)
The rect textures might be considerably slower than the POT ones on old GPUs, yes (i guess that's why it's not used)

> PS should I uninstall/make clean or something like that before installing kde
> workspace from repos?
No, the files should just be overridden by the packager.

> tests - just new compilation and installation + reboot to be sure - hope this
> doesn't messed up results(?)
No. Indeed restarting "kwin --replace &" would have done ;-)

> patching file scene_opengl.cpp
> Hunk #9 succeeded at 1684 with fuzz 2.
i don't know what you edited, but if you edited the patch file by just adding that string it likely didn't work (those outer lines are only for the patch system to identify/ensure the correct location) - best look up kwin/scene_opengl.cpp and inject the string there.

(In reply to comment #19)
> it's matter of refresh rate, this PC is hooked up to CRT display, with 60Hz
> window moving even big ones is always responsive, on 85Hz big windows can be
you can attempt to force a refreshrate (in case it's misdetected/reported)

kwriteconfig -file kwinrc -group Compositing -key RefreshRate 85
qdbus org.kde.kwin /KWin reconfigure
qdbus org.kde.kwin /KWin toggleCompositing
sleep 1
qdbus org.kde.kwin /KWin toggleCompositing

BE WARNED that this hardcodes the refreshrate, it will not adapt to further changes anymore.
To deactivate the hardcoded refreshrate, set it to "0" or remove the key from ~/.kde/share/config/kwinrc (kwriteconfig has no delete option)

Git commit 7355a9ad14e24ca1eb4088430950bc88f03fb4de by Thomas Lübking.
Committed on 08/02/2012 at 19:31.
Pushed by luebking into branch 'KDE/4.8'.

fix NPOT shadows

a) fixes the texture offset calculation
b) arranges he shadow pixmaps as border in the texture to avoid interpolation issues.
Related: bug 280116, bug 282882, bug 291161
REVIEW: 103888

M  +33   -53   kwin/scene_opengl.cpp

http://commits.kde.org/kde-workspace/7355a9ad14e24ca1eb4088430950bc88f03fb4de

Git commit 4281fd09be344bfa99b0450eae384b49b55db152 by Thomas Lübking.
Committed on 08/02/2012 at 19:31.
Pushed by luebking into branch 'master'.

fix NPOT shadows

a) fixes the texture offset calculation
b) arranges he shadow pixmaps as border in the texture to avoid interpolation issues.
Related: bug 280116, bug 282882, bug 291161
REVIEW: 103888

M  +33   -53   kwin/scene_opengl.cpp

http://commits.kde.org/kde-workspace/4281fd09be344bfa99b0450eae384b49b55db152

(In reply to comment #20)
> Because more of the screen has to be updated - it's a matter on how powerful
> your system (GPU) is. You should probably rather disable effects like blur (if
> that is supported on that GPU at all)
I thought so, but this refresh thing is interesting. Of course I've disabled almost all effects, no heavy effects, transparency etc. Blur is not supported but I don't like it anyway ;)


> i don't know what you edited, but if you edited the patch file by just adding
> that string it likely didn't work (those outer lines are only for the patch
> system to identify/ensure the correct location) - best look up
> kwin/scene_opengl.cpp and inject the string there.
I "manipulated the end of the patch file", but I will try direct way tomorrow

> you can attempt to force a refreshrate (in case it's misdetected/reported)
I wasn't clear enough: I use openbox and KDE on USB disk, so refresh rate is often reseted to default 60Hz, I have no problem to set 85Hz, but with 85Hz sluggishness occurs - no such effect on 60Hz

How to test this pop-ups? different plasma themes?

The reported issue is fixed, isn't? (i really can't say about the plasma thing atm)
Please do not turn this into a "kwin is  sluggish" report but in doubt open a new one.

(In reply to comment #23)
> > you can attempt to force a refreshrate (in case it's misdetected/reported)
> I wasn't clear enough: I use openbox and KDE on USB disk, so refresh rate is
> often reseted to default 60Hz, I have no problem to set 85Hz, but with 85Hz
> sluggishness occurs - no such effect on 60Hz
the setting in kwin is not directly related to the xrandr setting. esp. if you change the refreshrate after starting KDE you maybe should attempt to enforce this value (in case the change is somehow not catched)

Also notice that the GPU needs to pump out the framebuffer ~1.41 times as often with the higher refreshrate what -depending on the architecture- might simply drain resources from other buffer processing (same goes oc for higher resolutions) - the GPU also might be "optimized" towards typical LCD rates and it's eg. rather common that throughput drops a lot when accessing two screens (and esp. with different clocks, ie. refresh rates)
Ie. if this is a notebook and the internal display has 60Hz and you attach it to an external @85Hz and the internal is not unregistered from the GPU (so it actually still supplies both) this causes heavy load (more than if the two screens run at equal clock speeds or one is a full multiple of the other, ie. eg. 60Hz & 120Hz)

> How to test this pop-ups? different plasma themes?
Do an " xprop | grep _KDE_NET_WM_SHADOW" on that window. If there's no output, you need to file a bug against (lib)plasma - tell them texture packing is evil if one uses some (bi)linear scaling somewhere =)

I applied this patch: http://git.reviewboard.kde.org/r/103888/ , recompiled, and yes, no glitches, not even traces (like after the last patch I tried). Thank you again, Thomas. Good to see the old hardware is not abandoned. By the way, I had to recompile all kde-workspace again :( and therefore I have a debian package for kwin here: http://dg.lapas.info/share/kde-window-manager_4.7.4-0ubuntu0.2_i386.deb (it installs only using command dpkg -i --force-depends kde-window*.deb , because I messed unsuccessfully with version numbers..)

(In reply to comment #24)
> The reported issue is fixed, isn't? (i really can't say about the plasma thing
> atm)
> Please do not turn this into a "kwin is  sluggish" report but in doubt open a
> new one.
I don't want to do that, just want to be sure that there is no regression.

> with the higher refreshrate what -depending on the architecture- might simply
> drain resources from other buffer processing 
You are right, after some more testing it seems that GPU is running out of juice (still it's crazy, it should be able to handle window moving, I know its old card but if someone would tell me 9years ago that card which is capable of many 3D games like UT2003 is to slow to display 2D windows... - end of personal opinion)

> Do an " xprop | grep _KDE_NET_WM_SHADOW" on that window. If there's no output,
> you need to file a bug against (lib)plasma - tell them texture packing is evil
> if one uses some (bi)linear scaling somewhere =)
Yeah, it didn't return anything, I'm gonna fill report and because I don't understand this technical stuff to much I'll link to this thread also

Anyway, that was my best bug report so far and very pleasing dev-user experience, thank you for your patience and guidance :) Much appreciate your work (and not only yours), regards.

(In reply to comment #26)
> You are right, after some more testing it seems that GPU is running out of
> juice (still it's crazy, it should be able to handle window moving, I know its
> old card but if someone would tell me 9years ago that card which is capable of
> many 3D games like UT2003 is to slow to display 2D windows... - end of personal
> opinion)
Different demands. Shooters need fast T&L, Z buffer clipping, maybe shaders while the WM needs  much memory and fast memory throughput (esp. when you played @ 1024x768 but run the desktop @ 1920x1200)

It probably also doesn't help that the texture_from_pixmap conversion (that maps between X11 and OpenGL) creates rectangular textures when "supported" (while games will always come with rather small POT textures) - even if that doesn't mean "supported to be fast"

Eg. get kmquake2 - will certainly run nice. Then get the hires texture pack ....

(In reply to comment #27)
> Different demands. Shooters need fast T&L, Z buffer clipping, maybe shaders
> while the WM needs  much memory and fast memory throughput (esp. when you
> played @ 1024x768 but run the desktop @ 1920x1200)
> 
> It probably also doesn't help that the texture_from_pixmap conversion (that
> maps between X11 and OpenGL) creates rectangular textures when "supported"
> (while games will always come with rather small POT textures) - even if that
> doesn't mean "supported to be fast"

Everyday something new to learn, thanks :)