Patch to smooth KDE minimize/unminimize animation

[piwacet]

Edit - for updated patch, see my post below at Wed Dec 07, 2011 10:38 pm.

Hi. I've made the following patch which seems to make the KDE4 minimize/unminimize animations a little smoother - i.e., less "linear" - when the windows are unminimized, the animation slows down as the windows approach their target size. I remember compiz doing this, and it seemed overall smoother.

[Shining Arcanine]

Reading the comments of kwineffects.h, I am not sure if this function is what you would want to patch. In order to make the window animation smoother, what you would want to do is modify the code to scale the area according to some function. Ideally, this probably should be a linear function to bring the area from some upper limit to some lower limit within the allowed time for the effect, but I imagine that you could use a non-linear function as well.

If time u is the start of the effect, time v is the end of the effect and t is the current time, then the area should scale according to the function f(t) = ((v - t) / (v - u))^k. Consequently, each dimension of the window will need to be scaled according g(t) = (f(t))^(1/2) or g(t) = ((v - t) / (v - u))^(k/2). This is where k is a tuning variable that can be used to get a linear effect when k = 1, an effect where the transition is slow when the window is large and quick when the window is small when k < 1 and an effect where the transition is quick when the window is small and slow when the window is large when k > 1.

Thinking about it some more, the right place to make this kind of change would be where the value of a is generated, because that is what you would want to replace with the equation g(t) that I provided above. How did you come upon the function that you modified in your patch? kwin is such a large piece of software that I am not sure where I would begin if I wanted to make a change, much less find a spot related to the area like it appears that you have done here.

[Shining Arcanine]

I found the spot where interpolate() is being called. It is in ./kwin/effects/minimizeanimation/minimizeanimation.cpp. Although I am not quite certain where it is being computed, it appears that a = (v - t) / (v - u). Unfortunately, it appears that each time kwin scales the window, it scales it from the current size, rather than the original size. Unless the value of a is not what I think it is and is being specially changed to counteract this effect, the window scaling will be smooth or laggy depending on the behavior of the kernel scheduler, which in my opinion is a bad way of doing things. To make matters worse, I am not sure where or if the original size of the window is stored and without either that information or how what the scaling factor was used previously on the window coordinates, doing proper window scaling seems impossible. Perhaps this is why KDE's minimization effect always seemed strange to me.

Anyway, I probably could fix this myself if I studied kwin's code more closely, but I think it would be best to file a bug report with upstream. I already described in my previous post how the window scaling should be done. It would probably best if upstream implemented it, because then the k constant could be soft-coded to give the user the ability to tune over how the window scaling works from KDE's control panel. I have my own things to do, so I will look into filing a bug report about this later, although it would probably be better if the original poster filed it, because he is the one who pointed out this issue.

[piwacet]

Thanks so much for looking at this. For anyone who is interested, here are the relevant chunks of code, I believe this is current HEAD (not 4.4.5):

The interpolate() function, in kwineffects.h, at line 513:

http://lxr.kde.org/source/KDE/kdebase/workspace/kwin/lib/kwineffects.h#513

[Shining Arcanine]

piwacet, I did not see your response to this thread until today. I just reread my post and what I said regarding k != 1 makes no sense. When k < 1, the effect will be slow when the window is large and quick when the window is small. When k > 1, the effect will be slow when the window is small and quick when the window is large. With what you are saying, I think you would want k > 1 in the equations I posted above.

Anyway, your patch will likely affect much more than just the minimization animation. It would probably be a good idea for you to inline your changes into the minimizeanimation.cpp file until someone comes up with a better solution. I am somewhat hesitant to do much with this because I do not know if this is still a problem in KDE 4.5.0. Did you ever file a bug report regarding this with upstream?

[Akkara]

Just to toss some ideas into the mix:

Here's some other functions that take a parameter from 0..1 that have zero slope at one end or the other (or both):

Zero slope at the a == 0 end:

• a*a /* this is the formula suggested above */
  
• 1 - cos(Pi/2 * a)

Zero slope at the a == 1 end:

• a * (2 - a)
  
• sin(Pi/2 * a)

Zero slope at both ends:

• a * a * (3 - 2*a)
  
• a = sin(Pi/2 * a); a = a * a; /* this one is so close to the one just above it's hardly worthwhile to use */

Also, sometimes things look nicer visually when they follow a power law. Use one of the formulas above and then follow it up with:

• a = (pow(2,a) - 1) / (2 - 1);

See if you like that better. Change the 2 to other numbers to push the effect faster toward one end or the other. If the fast end is not at the end it needs to be, use:

• a = 1 - a; a = (pow(2,a) - 1) / (2 - 1); a = 1 - a;

[Shining Arcanine]

The source has two issues in it at the moment. One is that the original window size is not saved between repaints, so each time it repaints, a new window size is calculated from the previous size, which is not the original size. That is a problem because it prevents the animation from behaving according to a specific mathematical formula and gives the animation a bit of randomness that in most cases will make the animation look worse than it should look. It also means that this effect is done slightly differently every time it is executed. The second is that the window animation does not appear to be mathematically defined, but doing that is impossible unless the animation obeys the formulae employed.

I have produced a patch that addresses the first issue. I would have had it address the second issue as well, but when I tried to change the code, I could not understand how the existing code functioned unless data.xScale and data.yScale varied between 0 and 1, which suggested to me that the code determining the calculation of the window's dimensions was elsewhere. While I can likely work around that, that would require a bit of trial and error on my part to verify my assumptions and it is late, so I am only patching the first issue.

Here is the patch for anyone interested:

http://paste.pocoo.org/show/254569/

The first issue I described at the top of this post meant that the animation had an annoying inconsistent jerkiness to it. This patch fixes that. At the same time, it does not address the original poster's issue, which is what I outlined as the second issue at the top of this post.

Akkara, although I have not checked your math, functions that have zero slopes at both ends are ideal for this kind of animation. I will look into implementing such a function tomorrow provided that I find time.

[Shining Arcanine]

I spent several hours today trying to modify the behavior of this effect and my theory as to what various variables meant was incorrect. While I now think that it is possible that my above patch does nothing, I am not able to say that for certain because the documentation on the return value of KWin::EffectWindow::geometry() is nonexistent. The return value could be the geometry before the effect or the geometry during the effect and it is not clear to me which of the two it is. I knew no quick and dirty way of saving messages to a log file, so I tried doing things without logging variable values and with what I know now, that is the first thing I should have done.

I filed a bug report with upstream regarding the documentation issues I encountered:

https://bugs.kde.org/show_bug.cgi?id=249288

I am still waiting for piwacet to file a bug report with upstream regarding the effect, because this is his complaint.

[piwacet]

Wow, this thread got resurrected. Thanks everyone for looking at this and for the suggestions.

I would like to try out the new math to see how it runs, and to spend some time reasonably soon playing with this.

I have hesitated to file an upstream bug report because I'm not a computer programmer, and feel like my input would be more on the level of "feature request" as opposed to bug report. Although if a patch that works well does come out of this, maybe I should rethink that.

Let me try to work out a slightly improved or better patch and I'll post back here if I have any success.

Thanks!

[piwacet]

Edit - consider just skipping this post and going to my next post with the updated patch.

OK, just a quick update. First of all, in order to not break other things that might call interpolate(), I created a new function interpolate_nonlinear() and added it to kwineffects.h, and then updated minimizeanimation.cpp to call this new function instead. An on-line search of the current KDE codebase does not reveal any hits for "interpolate_nonlinear" so I think this has successfully isolated this change to this specific place in the code. These are all against KDE-4.4.5.

Here are the patches:

[piwacet]

OK, well, a new approach. I think this approach will not break anything, as it only creates two new variables "progress_nonlinear_geometry" and "progress_nonlinear_opacity," and an on-line search of the KDE code shows these terms are not used anywhere else. The patch works by computing the values "progress_nonlinear_geometry" and "progress_nonlinear_opacity" from the original "progress" variable in a non-linear way, and then uses these new variables in place of the "progress" variable. This approach only involves patching one file, and although I'm not a programmer, this patch may actually be technically correct.

It uses math from Akkara's post above. I noticed that the animation's linear change in opacity was distracting with the non-linear geometry changes, so the patch also provides math to tweak the way the opacity changes as the animation progresses. The opacity can be tweaked independently of the geometry.

These functions behave correctly in that they will return 1 if given 1, return 0 if given 0, and if given a value between 0 and 1, they will return a value between 0 and 1. My understanding is that the original "progress" variable is a variable that ranges from 0 to 1. The math can be tweaked as per Akkara's descriptions above. Replacing "progress" with the product "progress*progress" or vice-versa in the pow() functions can further tweak the math. Specifically, you would tweak 'n,' and the second parameter of the pow() function. The higher the value of 'n,' the more "non-linear" the animation will be.

[piwacet]

Actually, cubing the variable "progress" instead of squaring it has worthwhile effect as well, i.e changing:

[piwacet]

I'm thinking I may submit this patch upstream, see if there is any interest. I'll link this thread.

[Shining Arcanine]

You are computing (50^(progress^3) - 1) / 49. Are you sure that is what you want?

[ppurka]

[piwacet]

Actually the version of the formula that I'm currently using (and like) is:

(50^(progress^2)-1)/49

But yes, the math may be too compute intensive and I could easily see developers not liking that.

[Shining Arcanine]

[Akkara]

[piwacet]

Thanks. I don't know how many distinct values 'progress' takes on; I really don't understand the code that well. I suppose with a look-up-table we could make the animation do exactly as we want, but I wonder if the number of values that 'progress' takes is a constant, or if it is a function of screen size or other settings.

I wonder how this patch would work on an older, slower machine. I wonder what KDE regards as the "minimum requirements" that they are coding for.

I've noticed that other animations include the math.h headers, so there must be somewhat complicated math in those, but perhaps these are the animations not meant to be used on older hardware.

Thanks everybody!

[Shining Arcanine]

[Akkara]

[piwacet]

Here's an updated patch for 4.7.3. (I built it using 4.7.4 sources, but it applied to my 4.7.3 without problem - I'm using gentoo stable.) Again, I'm not a programmer, but is working so far: