Hi, For some time now I was puzzled about why without the wobbly windows effect windows movements were slower and I think I finally figured it out: It's the mouse! (or trackball in my case) With wobbly windows, the movement is extremely smooth because it's animated, so regardless of the pointer movement (i.e. whether it's smooth or it's jumping around) windows flow over the desktop. Without the effect the windows are just "repainted" on their new location without having a movement animation. As such, this is a request to add such an effect. I.e. an effect like wobbly windows but without the wobbly part. I believe the easiest way to do this is to be able to completely disable wobblyness from the effect and let it just animate the movement over the desktop. I find the animate-window-movement result extremely pleasant to the eye and I believe that an effect where the movement between two points will be animated instead of just "done" can greatly contribute to the perceived feeling. Thanks for kwin! Reproducible: Always
Thank you for your feature suggestion. Unfortunately bugzilla is not the best place to discuss feature requests. We hardly have any users here, so we don't get an evaluation whether the feature is needed. We therefore recommend to use http://brainstorm.forum.kde.org to suggest this idea. Users are able to up/down-vote the feature request and by that we get an idea whether it's something our users wish to see and whether it is worth to invest time into it. If the feature request is supported on brainstorm it will automatically be recreated here in the bug tracker. Given that I'm marking this feature request as WONTFIX for now. This has nothing to do with whether we think this is a good or bad feature request. I'm very sorry that our software does not allow to send users to brainstorm in the first place.
Two notes regardless: - if the pointer generates "random" and jumpy positions, it should be fixed in the first place. Composited movement (esp. after rem. the roundtrip) of windows should be extremely fast. - interpolating window positions (what is required) will lead to a rather viscous dragging behavior - the window rather follows the cursor than sticking to it. This also happens with wobbly windows, but only for a part of the window (leading to the wobbling)
Hi again, First of all thanks for your immediate responses. I'm reopening this as I now have a patch. I modified the wobbly windows effect to support what I proposed by removing the wobbliness when the wobbliness level is set to zero (I extended the wobbliness levels by one to be 0-5). The effect needs some polishing on the configuration window but please excuse that. Most probably it would need a separate switch for that. The results are somehow extraordinary on my desktop. I'm using it for the past half and hour and I've to say that disabling it makes my eyes hurt. My favorite values are Stiffness:10, Drag: 60, Move factor: 1 Here are some notes: * I'm using a non-laser trackball that's most probably causing the jumping cursor. I believe all mice without very high DPIs would have the same issue. * When setting the wobbliness level to 0 it completely disables transformations. * Enabling wobbliness with resizing give a surprising but pleasant effect. I believe that it would look very nice on a touch screen. Try resizing a window with alt+mouse giving some acceleration and then releasing the button Please test that for yourselves. I truly believe it's worth accepting, even without further improvements. Thanks, Stefanos
Created attachment 80269 [details] Patch against kde 4.10.2
Just to make it clear: To test that you need to set wobbliness to zero and then fiddle with the advanced settings, although the defaults should be a good start.
Created attachment 80277 [details] v2 of the patch Previous patch was buggy: it was changing the bahavior even when noWobble was not in effect.
To get the patch reviewed -> git.reviewboard.kde.org From a quick look, please also explain what this is but a certain parameter set and a flag to ignore wobble constraints. Also please explain why you think this is *any* necessary. The windows move in 1,1px steps - there's simply no "jumping" except when your input device would generate random coordinates (in which case you would not go for hyper-expensive tesselation, but just create a animation between the two positions, except that when your input device creates random coordinates, the only proper fix is to dump it and get a new one - what if you click and suddenly the pointer is somwhere else?)
For the record: we are currently in soft-feature freeze state. This means only new features which were listed in the planned feature document two weeks ago are allowed to go in. On Wednesday we will have the hard feature freeze which means we are no longer allowed to add new features. I consider this change as a new feature.
Ok, here goes nothing: https://git.reviewboard.kde.org/r/110813/ Martin, I can only say that it's a non-intrusive change that introduces just one string: The word "none". It does change the semantics of the existing wobliness levels though. Please note that I'm not asking for this to skip the soft freeze. That's your call. However, I *do* want to see this functionality in KDE and that's why I worked on it even though I was not familiar with KWin effects. Thomas, I'm not sure about the technical details but I know that this happens and I've proof of it :-) Here's the output of xev using by my trackball (Logitech TrackMan Wheel) (xev | grep root:): root 0x160, subw 0x0, time 165363910, (617,83), root:(2061,665), root 0x160, subw 0x0, time 165363934, (630,87), root:(2074,669), root 0x160, subw 0x0, time 165363950, (637,89), root:(2081,671), root 0x160, subw 0x0, time 165363974, (648,90), root:(2092,672), root 0x160, subw 0x0, time 165363990, (683,90), root:(2127,672), root 0x160, subw 0x0, time 165364014, (744,90), root:(2188,672), root 0x160, subw 0x0, time 165364030, (794,88), root:(2238,670), root 0x160, subw 0x0, time 165364054, (831,88), root:(2275,670), root 0x160, subw 0x0, time 165364070, (850,86), root:(2294,668), root 0x160, subw 0x0, time 165364094, (856,86), root:(2300,668), root 0x160, subw 0x0, time 165364126, (857,86), root:(2301,668), root 0x160, subw 0x0, time 165364390, (863,86), root:(2307,668), root 0x160, subw 0x0, time 165364414, (891,86), root:(2335,668), root 0x160, subw 0x0, time 165364430, (938,88), root:(2382,670), Here's the output of xev using MS wireless mouse 1000: root 0x263, subw 0x0, time 949103342, (630,81), root:(2560,135), root 0x263, subw 0x0, time 949103350, (649,81), root:(2579,135), root 0x263, subw 0x0, time 949103359, (668,81), root:(2598,135), root 0x263, subw 0x0, time 949103367, (687,81), root:(2617,135), root 0x263, subw 0x0, time 949103374, (706,81), root:(2636,135), root 0x263, subw 0x0, time 949103382, (725,81), root:(2655,135), root 0x263, subw 0x0, time 949103390, (742,81), root:(2672,135), root 0x263, subw 0x0, time 949103398, (759,79), root:(2689,133), root 0x263, subw 0x0, time 949103406, (772,79), root:(2702,133), root 0x263, subw 0x0, time 949103415, (789,79), root:(2719,133), root 0x263, subw 0x0, time 949103423, (806,79), root:(2736,133), root 0x263, subw 0x0, time 949103430, (825,77), root:(2755,131), root 0x263, subw 0x0, time 949103438, (842,77), root:(2772,131), root 0x263, subw 0x0, time 949103446, (859,77), root:(2789,131), root 0x263, subw 0x0, time 949103454, (878,77), root:(2808,131), root 0x263, subw 0x0, time 949103462, (895,74), root:(2825,128), root 0x263, subw 0x0, time 949103470, (908,72), root:(2838,126), And here's from MS Wireless Mobile 3500 (laser): root 0x160, subw 0x0, time 165621334, (544,119), root:(2181,259), root 0x160, subw 0x0, time 165621343, (556,122), root:(2193,262), root 0x160, subw 0x0, time 165621349, (568,122), root:(2205,262), root 0x160, subw 0x0, time 165621357, (582,122), root:(2219,262), root 0x160, subw 0x0, time 165621365, (596,122), root:(2233,262), root 0x160, subw 0x0, time 165621374, (608,124), root:(2245,264), root 0x160, subw 0x0, time 165621383, (621,124), root:(2258,264), root 0x160, subw 0x0, time 165621390, (635,125), root:(2272,265), root 0x160, subw 0x0, time 165621399, (647,127), root:(2284,267), root 0x160, subw 0x0, time 165621406, (660,129), root:(2297,269), root 0x160, subw 0x0, time 165621414, (676,132), root:(2313,272), root 0x160, subw 0x0, time 165621423, (691,132), root:(2328,272), root 0x160, subw 0x0, time 165621430, (707,134), root:(2344,274), root 0x160, subw 0x0, time 165621438, (722,137), root:(2359,277), root 0x160, subw 0x0, time 165621446, (742,139), root:(2379,279), root 0x160, subw 0x0, time 165621454, (759,141), root:(2396,281), root 0x160, subw 0x0, time 165621461, (780,141), root:(2417,281), root 0x160, subw 0x0, time 165621469, (798,141), root:(2435,281), root 0x160, subw 0x0, time 165621477, (812,141), root:(2449,281), As you can see all of them are jumping and none is reporting sequential coordinates. This causes all window movements to be jumpy. Try xev and the patch yourself and you'll see. Also, there's no way you can achieve that smooth window resizing without such a kwin effect. If this becomes a different effect then it won't have the nice resizing capability and it will have to reimplement and duplicate the acceleration stuff. I believe that this patch eliminates a lot of the processing of the wobbly windows already and thus it's not that expensive. After all it's just additional functionality that does not affect current performance. Finally, this is definitely not necessary, just like all kwin effects and many kde things. However it's nice to have and its functionality is not already available. Again, please try the patch for yourselves.
looks less random and more like pointer acceleration: What's the output of xset -q | grep -A1 "Pointer Control" (The gaps look quite huge, though)
Indeed, I've messed with pointer acceleration. That's the output: Pointer Control: acceleration: 35/10 threshold: 6 Note that the pasted values are from two different PCs and I'm pretty sure one of them has the default values.
If you still got this issue of jumpy input events (and while i'd severely recommend to fix *that* issue - such mouse seems unusable to me) and are still interested in covering that by a kwin effect, we can guide to through writing an effect to do this in a half-wise sane way (animated interpolation of the moving window - no tesselation overhead or abuse of other effect)