Version: unspecified (using KDE 4.7.2) OS: Linux If the magic lamp effect is used together with a side panel, then the effect is quite messed up when minimizing/restoring applications that are maximized. Reproducible: Didn't try Steps to Reproduce: activate the magic lamp effect put your panel on the left hand side maximize an application minimize it Actual Results: kind of goes away to the upper right hand side corner as if it were a page being folded, and not smoothly Expected Results: The usual smooth magic lamp effect Using OpenSUSE 12.1 RC1
Note: the voting interface seems broken. When I click vote it shows my list of votes, and a "enter your vote here ->" message, but no box to take the input.
First off: Bugzilla votes are completely ignored anyway (for being meaningless), we had a long thread on kde-devel or k-c-d, please don't open a new one. It won't change anyway. On topic: sounds a lot like bug #242772 which is regardless on the actual panel position or the window state, but derives from the fact that the taskbar suggests the wrong or no icon position (consequence of the latter case is to zoom to the mouse pointer, since the legal case here is that there is no taskbar at all) -> Can you confirm that it's a dupe? (try with slow speed, does it happen regardless of the window state and the panel position and does the lauch feeback thing have impact?)
Hi Thomas, The cause may well be related, but the "symptoms" are not the same. - In my case it seems to happen if and only if the panel is on the side, and for maximized windows. In this context it is always reproducible and it never happens in other circumstances. - The animation does not follow the mouse. It always goes to the side opposite to the panel. This is the case even if I minimise by using the mouse to click in the icon on the panel. Using slow speed and moving the mouse around also has no effect. Also the mouse icon appears to be fine. Let me know if there's more info I can provide. Cheers
Please open konsole, fire: xprop | grep _NET_WM_ICON_GEOMETRY and click the window you'd minimize Then post the output (and check yourself whether that's the correct position, top left corner is "0,0", printed values are x,y,w,h)
It appears to be correct. I got the following values: Firefox: 0, 25, 44, 49 Konsole: 0, 72, 44, 49 My taskbar is on the left, and it looks like: ------- Clock Firefox Konsole ... ------- Also I tried restoring the applications and the values didn't change, so it appears to be detecting the position of the corresponding icon properly.
Is it some multiscreen setup?
(In reply to comment #6) > Is it some multiscreen setup? Not at all, regular laptop. Asus N53S Nvidia Geforce GT540M
I experience similar issues and I'm not sure if I file open a new bug report for that. Here the magic lamp effect has some issues with maximized windows on my second monitor (I have a dual monitor setup with NVIDIA TwinView). One monitor stands left which is a small 19" SXGA and one stands right which as a big 27" WQHD. The big one on the right is my primary monitor. When I minimize maximized windows, the magic lamp effect only works on the left monitor (the small one). When I do it on the right screen, it looks more like the window is disappearing to the bottom edge of the screen but I guess it's more vanishing towards the left screen. When I set the animation duration to let's say 3 seconds I can see the window folding towards the (bottom?) left edge of the left monitor. The effect for minimizing windows that are not maximized works equally fine on both monitors. I have panels on both screens and both contain a task manager widget which only shows the windows of the current screen but this also happens when I set the task manager on the left screen to show windows of all screens. My system: Gentoo Linux AMD64, Kernel 2.6.39, KDE 4.7.3
Just confirming that it is still present in KDE 4.8 (Beta 1)
yes, is - it's however not related to the maximization state but the width of the window (~80% of the workspace seems the critical value here) so there's likely sth. broken in the calculation. Can you confirm the width fraction?
You're right. I can confirm that it happens whenever the width is large enough (not sure how to precisely estimate the fraction but it seems roughly those 80%).
Yeah. I can confirm this as well. As soon as the window has a certain size the magic lamp effect stops working properly. Windows are no longer animated towards the task manager but towards somewhere else (as described in comment #8). This actually has nothing to do with the maximization state. I'm still using KDE 4.7.3, but since it's the same bug, it should matter.
Ok, it's the cubic divisions, linear works: +++ b/kwin/effects/magiclamp/magiclamp.cpp @@ -278,10 +278,12 @@ void MagicLampEffect::paintWindow(EffectWindow* w, int mask, QRegion region, Win } else { quadFactor = geo.width() - quad[0].x() + (quad[0].x()) * progress; xOffsetLeft = (geo.x() k- icon.width() + geo.width() + quad[0].x() - icon.x()) * progress * - ((quadFactor * quadFactor * quadFactor) / (geo.width() * geo.width() * geo.width())); + (quadFactor/ geo.width()); +// ((quadFactor * quadFactor * quadFactor) / (geo.width() * geo.width() * geo.width())); quadFactor = geo.width() - quad[1].x() + (quad[1].x()) * progress; xOffsetRight = (geo.x() - icon.width() + geo.width() + quad[1].x() - icon.x()) * progress * - ((quadFactor * quadFactor * quadFactor) / (geo.width() * geo.width() * geo.width())); + (quadFactor / geo.width()); +// ((quadFactor * quadFactor * quadFactor) / (geo.width() * geo.width() * geo.width())); leftProgress = qMin(xOffsetLeft / (geo.x() - icon.width() + geo.width() - icon.x() - (float)((geo.width() - quad[0].x()) / geo.width() * geo.width())), 1.0f); rightProgress = qMin(xOffsetRight / (geo.x() - icon.width() + geo.width() - icon.x() - It turns negative for large geo.width() - qMax(xOffsetLeft, 0) is however no option since it just kills the effect for large windows. --- Devnote: The effect has GREAT potential for optimization in this section. There comes like a billion quad calculations and either the quads are the same or at least the x/yOffsetLeft/Right result is the same - 60(!) times in a row. Therefore a) some values should really be pre-calculated outside the loop b) ideally the branches are moved outside the loop c) last values should be cached and the very first operation should be to check to re-use them
(In reply to comment #12) > Yeah. I can confirm this as well. As soon as the window has a certain size the > magic lamp effect stops working properly. Windows are no longer animated > towards the task manager but towards somewhere else (as described in comment > #8). This actually has nothing to do with the maximization state. > > I'm still using KDE 4.7.3, but since it's the same bug, it should matter. Sorry, I meant "shouldn't" not "should". :-)
d'oooh! it's just a stupid integer overflow =) i'll write a performance improving & fixed version, but cannot promise it'll be included in either 4.8b2 or 4.7.4 (to be more precise: it's unlikely since tagging is tomorrow)
Ah! That's fine. If fixes and optimisations make it to 4.8 final that's excellent already. Thanks!
Git commit 6ae5be71165bb4961cf4a1f4427af296a8091b64 by Thomas Lübking. Committed on 01/12/2011 at 01:58. Pushed by luebking into branch 'master'. Magiclamp: fix integer overflow, cpu waste BUG: 284738 M +107 -93 kwin/effects/magiclamp/magiclamp.cpp http://commits.kde.org/kde-workspace/6ae5be71165bb4961cf4a1f4427af296a8091b64