"linear" - NOT "bi-linear" ;-) yes, that's "normal" (linear down / linear up doesnt' look like blurred at all :) Could be that the filter setting is indeed ignored on your side but you should anyway use a 2 pass blurring (even when scaling) for better results. 3 pass is usually overhead. I'll add more configuration to only scale and not displace as well as scale factors for coming versions. The windows set the "to be shadowed" region themselve, please grep the property and compare it with the window dimensions (eg with xwininfo) However plasma is meanwhile supposed to use the same system as the bespin decoration and the oxygen popups to draw it's shadows, so ultimately if it works with them, it's a plasma bug ;-P

Oh, I understood the difference between linear and bilinear now. Would it be possible to (optionally) use a bilinear scaling? As i said previously, xrender performs pretty well when scaling translucent windows (resize effect, bilinear mode), at least on nvidia (asap i will test on an eeepc 1005ha with an intel gpu). About the shadow issue, it is strange that it doesn't happens with opengl blurring. Isn't the clock shadow "hardcoded" in the svg plasma theme file itself? Anyway, i could try to file a bug report to kde if you think it would be useful.

The function already uses the same filter (XRender doesn't specify things like GL_LINEAR but you can set the filter to an arbitrary char*: "good" and "fast" are supported by at least the nvidia driver. "fast" looks certainly like "GL_NEAREST" and smooth looks like a linear filter (but no way like GL_LINEAR) I tried to query supported filters here (to get an idea whether there's more possible) but the function returns a null pointer. So for now, i don't know about more filters. If you'd know that the nvidia driver would eg. support a "boxblur" or "lanczos" filter string, i'll happily add it :) Regarding the shadows: please post window geometry and blur region. Whether the new shadows are use or not afaik depends on the theme - no idea whether the gl blur code has some legacy support or so.

The function already uses the same filter (XRender doesn't specify things like GL_LINEAR but you can set the filter to an arbitrary char*: "good" and "fast" are supported by at least the nvidia driver. "fast" looks certainly like "GL_NEAREST" and smooth looks like a linear filter (but no way like GL_LINEAR) I tried to query supported filters here (to get an idea whether there's more possible) but the function returns a null pointer. So for now, i don't know about more filters. If you'd know that the nvidia driver would eg. support a "boxblur" or "lanczos" filter string, i'll happily add it :) Regarding the shadows: please post window geometry and blur region. Whether the new shadows are use or not afaik depends on the theme - no idea whether the gl blur code has some legacy support or so.

While stepping across my older code - there's an hardcoded padding to the blurarea which does not belong there. Since your plasma shadow is rather small, i guess this (4px) <strike>is</strike> was it...

I poped-up the calendar by clicking the clock: they are perfectly the same, nothing changes between opengl and xrender Xrender+bedistorted window dimensions: Width: 406 Height: 259 Xrender+bedistorted xprops|grep -i blur: _KDE_NET_WM_BLUR_BEHIND_REGION(CARDINAL) = 5, 5, 401, 5, 4, 10, 402, 2, 5, 12, 401, 245, 4, 257, 402, 2 Opengl+blur window dimensions: Width: 406 Height: 259 Opengl+blur xprops|grep -i blur: _KDE_NET_WM_BLUR_BEHIND_REGION(CARDINAL) = 5, 5, 401, 5, 4, 10, 402, 2, 5, 12, 401, 245, 4, 257, 402, 2

I poped-up the calendar by clicking the clock: they are perfectly the same, nothing changes between opengl and xrender Xrender+bedistorted window dimensions: Width: 406 Height: 259 Xrender+bedistorted xprops|grep -i blur: _KDE_NET_WM_BLUR_BEHIND_REGION(CARDINAL) = 5, 5, 401, 5, 4, 10, 402, 2, 5, 12, 401, 245, 4, 257, 402, 2 Opengl+blur window dimensions: Width: 406 Height: 259 Opengl+blur xprops|grep -i blur: _KDE_NET_WM_BLUR_BEHIND_REGION(CARDINAL) = 5, 5, 401, 5, 4, 10, 402, 2, 5, 12, 401, 245, 4, 257, 402, 2

yes, as mentioned it's very likely that hardcoded padding which dows not belong at this space neither fixes the remaining glitches. I'm working on the latter and in this of course removed that nonsense padding.

About the filters, what i can say for sure is that the resize effect (the one that 'stretches' the windows) seems to use a bilinear filtering depsite of the scale method i choose.

Well and i /know/ it's the very same texture filter, because i touched the kwin window scaling code quite a lot (the actual effect, where i btw added the texture scaling mode =) merely sets the window scale factor, the backend does the rest. You're however right in that the nvidia driver seems to ignore the filter setting - there's chance that the driver selects the method internally (make bigger -> smooth, make much smaller -> fast) As mentioned, that routine isn't any specified like OpenGL - you throw in sth. and get out sth. where sth. is sth. =D However, there's still a chance that you've a, well, "false", assumptions about the outcome of a plain linear down -> linear up pass (try with gimp, even bi-linear looks ... improvable - NOT boxblur, that's entirely different) Now use gimp to perform a 4x (or even 8x) bilinear scaledown, then perform a minimal gaussian blur (what's not really possible with xrender) - try a 3x3 kernel - and then perform a bilinear scale up. See the difference? (btw: use a desktop screenshot or sth. for this. surprisingly the result with a picture of say, clouds, is much better ;-) The XRender approximation is to displace the pixmap, in the next version you can try w/o, but you won't like it =)

Well, before opening this: https://bugs.kde.org/show_bug.cgi?id=288526 , I tried with gimp to scale an image to 'X' times smaller, then shifted it in 4 transparent layers to relative coordinates: -1,-1;-1,1;+1,+1;+1,-1 and then rescaled it to the original size. The scaling filter was a simple bilinear and the result wasn't THAT bad. Here is the original: http://wpage.unina.it/aorefice/sharevari/XrenderOrNot/Original.jpg Here is the 'faked' blur: http://wpage.unina.it/aorefice/sharevari/XrenderOrNot/Reduce.by.4X,translate.4.Times,rescale.to.4X.png http://wpage.unina.it/aorefice/sharevari/XrenderOrNot/Reduce.by.8X,translate.4.Times,rescale.to.8X.png But now i've had another idea. Make a copy of the picture and scale it to 1/2, copy the result and scale it by another 1/2 and so on. Do this -say- 4 times. Then rescale all the resulting pictures to the original size, make them translucent and compose them see the result, this is very good!: Final picture, new method: http://wpage.unina.it/aorefice/sharevari/XrenderOrNot/Other.method.png Gimp project, new method: http://wpage.unina.it/aorefice/sharevari/XrenderOrNot/Other.method.xcf I also tried by compositing only with 2 iterations, and the result is still usable, maybe not so good, but still usable for productive needs: http://wpage.unina.it/aorefice/sharevari/XrenderOrNot/Other.method_2_iterations.png try play with the gimp project! ...so if you can manage to tell xrender to scale and filter somehow the image, we can have a very good result!

Like promised, I just tried the resize effect on a poor 945gm+atom n270 1gb ram Intel driver is 2.17.0 and xorg-server is 1.11.2 resizing translucent windows IS smooth; well the resolution is just 1024x600, but there are no jerkyness at all, even when the window is big as the screen. Strangely enough, even with the intel driver, changing the xrender scaling mode seems to be ignored and i've always a filtered scaling.

I actually had suggested such approach for the gl bluring (in the far past) because it can heavily reduce the processed data amount. (Simple bilinear down / bilinear up however doesn't work at all, looks crap) However when i wrote this, only the nvidia driver was -more or less- capabel of somehow fast (and smooth, pixel repetition doesn't work at all) scaling - do presentwindows etc. work smooth for you (with "smooth" scaling which *has* to be "smooth", the driver may just ignore this)

On nvidia with binary blob i use resize effect (with scaling and translucency) with xrender compositing everytime and it is very smooth even on low end cards like Geforce 9500GT. I'll test on a poor gma945 asap and will tell you

[ 60%] Built target kwin4_effect_bedistorted_automoc Scanning dependencies of target kwin4_effect_bedistorted [ 80%] Building CXX object CMakeFiles/kwin4_effect_bedistorted.dir/kwin4_effect_bedistorted_automoc.o In file included from /home/symbianflo/Scaricati/bedistorted-kwin-fx/build/kwin4_effect_bedistorted_automoc.cpp:4:0: /home/symbianflo/Scaricati/bedistorted-kwin-fx/build/moc_bedistorted.cpp:48:8: error: ‘staticMetaObject’ is not a member of ‘KWin::Effect {aka KWin::Effect}’ /usr/lib/qt4/include/QtCore/qobject.h: In member function ‘virtual const QMetaObject* KWin::BeDistorted::metaObject() const’: /usr/lib/qt4/include/QtCore/qobject.h:296:33: error: ‘QScopedPointer<QObjectData> QObject::d_ptr’ is protected /home/symbianflo/Scaricati/bedistorted-kwin-fx/build/moc_bedistorted.cpp:58:21: error: within this context /usr/lib/qt4/include/QtCore/qobject.h:296:33: error: invalid use of non-static data member ‘QObject::d_ptr’ /home/symbianflo/Scaricati/bedistorted-kwin-fx/build/moc_bedistorted.cpp:58:21: error: from this location /usr/lib/qt4/include/QtCore/qobject.h:296:33: error: ‘QScopedPointer<QObjectData> QObject::d_ptr’ is protected /home/symbianflo/Scaricati/bedistorted-kwin-fx/build/moc_bedistorted.cpp:58:50: error: within this context /usr/lib/qt4/include/QtCore/qobject.h:296:33: error: invalid use of non-static data member ‘QObject::d_ptr’ /home/symbianflo/Scaricati/bedistorted-kwin-fx/build/moc_bedistorted.cpp:58:50: error: from this location /home/symbianflo/Scaricati/bedistorted-kwin-fx/build/moc_bedistorted.cpp: In member function ‘virtual void* KWin::BeDistorted::qt_metacast(const char*)’: /home/symbianflo/Scaricati/bedistorted-kwin-fx/build/moc_bedistorted.cpp:66:12: error: ‘qt_metacast’ is not a member of ‘KWin::Effect {aka KWin::Effect}’ /home/symbianflo/Scaricati/bedistorted-kwin-fx/build/moc_bedistorted.cpp: In member function ‘virtual int KWin::BeDistorted::qt_metacall(QMetaObject::Call, int, void**)’: /home/symbianflo/Scaricati/bedistorted-kwin-fx/build/moc_bedistorted.cpp:71:11: error: ‘qt_metacall’ is not a member of ‘KWin::Effect {aka KWin::Effect}’ In file included from /home/symbianflo/Scaricati/bedistorted-kwin-fx/build/kwin4_effect_bedistorted_automoc.cpp:4:0: /home/symbianflo/Scaricati/bedistorted-kwin-fx/build/moc_bedistorted.cpp: In member function ‘virtual void* KWin::BeDistorted::qt_metacast(const char*)’: /home/symbianflo/Scaricati/bedistorted-kwin-fx/build/moc_bedistorted.cpp:67:1: error: control reaches end of non-void function [-Werror=return-type] /home/symbianflo/Scaricati/bedistorted-kwin-fx/build/moc_bedistorted.cpp: In member function ‘virtual const QMetaObject* KWin::BeDistorted::metaObject() const’: /home/symbianflo/Scaricati/bedistorted-kwin-fx/build/moc_bedistorted.cpp:59:1: error: control reaches end of non-void function [-Werror=return-type] cc1plus: some warnings being treated as errors make[2]: *** [CMakeFiles/kwin4_effect_bedistorted.dir/kwin4_effect_bedistorted_automoc.o] Errore 1 make[1]: *** [CMakeFiles/kwin4_effect_bedistorted.dir/all] Errore 2 make: *** [all] Errore 2

Errr..., sorry :s The version (0.2) I just uploaded today is only for 4.7 and up. 0.1 should have compiled on < 4.7 - if you drop me a mail (check source code for address) i'll reply a tarball of the prev. version.

Something seems to block blur under translucent windows, but it works under translucent popup menues and panels. tried with bespin and qtcurve. (in opengl blur works)

The window type is not taken into consideration - only whether the client is currently moved. Does it happen with _all_ "Normal" windows? What window decoration do you use and what does "xprop | grep -i blur" and clicking on such client print?

Nope, after further testing, i found that some windows get blurred (konsole background, effects window...) Other simply don't (kwrite, dolphin, probably others) But if i disable bedistorted, and then enable it again, all is blurred as it should! Example:i open a dolphin window, it is not blurred, i disable and enable bedistorted, dolphin becomes blurred. Then i open another dolphin and it is not blurred, so i have 2 dolphin(s) one blurred, one not. This happens with bespin and qtcurve too. But Xprop reports the same on both! Gozer ~ # xprop | grep -i blur _KDE_NET_WM_BLUR_BEHIND_REGION(CARDINAL) = 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 815, 72, 0, 72, 144, 474, 0, 546, 815, 44 Gozer ~ # xprop | grep -i blur _KDE_NET_WM_BLUR_BEHIND_REGION(CARDINAL) = 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 815, 75, 0, 75, 144, 467, 0, 542, 815, 48 -------------------------------------- Also, there are some glitches aroud blurred plasma widgets. In particular, the shadow blurs the background too. See links: xrender: http://ompldr.org/vYnBlNQ/xrenderblur.jpeg opengl: http://ompldr.org/vYnBlNg/glblur.jpeg

Yes, my bad - the propertyNotify is still a virtual and no slot (and the region is updated _after_ the client is shown, ie. added) Easily fixed. I'll do some more (behaviour with Highlight effect sucks; try scaling - i've an nvidia chip here annd yes: as mentioned it scales pretty fast. Might be even better performance since it's not that fast at allocating pixmap memory ;-) and make an update tonight or tomorrow. Sorry for the trouble