[compiz] scaler plugin fixes

Robert Carr racarr at beryl-project.org
Wed Feb 21 11:21:39 PST 2007


On Tue, 2007-02-20 at 12:47 +0100, Anders Storsveen wrote:
> Hi
>
> I think this is mostly a question of preference for my part, but I
> think it would give an overall better quality feel. What I'm talking
> about is mostly the movement it uses. As I've come to understand, it
> uses velocity and direction, and a target point. This means that it
> updates it velocity and direction every X seconds (timestep), and
> gives it the possibility to be unaccuarte, like overshoot its goal
> and wobble a little. What my issue is though, is that even though you
> set timestep very low, it still is a little wobble present. What I
> would love would be another movement, like the one that is used in
> the animation plugin, where timestep is just how many times to redraw
> the animation of it, this makes it 100% accurate all the time, and
> makes it seem more professional in my oppinion.
>
> A second smaller issues I have with the scaler is that I have a
> feeling that the target point used is a corner and not the center of
> the window. or perhaps the center of original sized window, because
> the movement has a tendency to go in a curved line. this is hard to
> describe, but if you imagine a window attached (in the upper right
> corner of the window) to a straight line going from the top left to
> the bottom right, and you scale that window while moving it down. it
> will go straight when you look at the upper right corner, but curved
> when you look at the bottom left. If you attacht the window to the
> line via the center, it will always move straight. :)
>
> Hope that explanation was sufficient, and that you see the issues I'm
> talking about. My general intentions is making the compiz effects
> look more professional, so it could appeal to wider audiences.

>Yes, I'm perfectly aware of these issues and they should be fixed.
>There's some pretty bad code involved with this right now and I want all
>point-animation code to be replaced with some nice shared code that
>allow you to select which algorithm to be used for any point-animation.
>By point-animation a mean an animation that can be expressed as a
>transition of one or more points. I like to do the same for
>rectangle-animations as well eventually.

>- David

As I mentioned to you a few days ago I've been thinking about a very
similar system for Beryl.

I have quite a bit of work on outlines for a system like this with a
few ideas that I think would be interesting. Basically I would like to
do it with a constraints type system (such as akamaru). Then two
setups, one for just creating an animation and stepping it (stepping
would return a value in the 0.0f-1.0f range representing position, by
position I mean integral of the speed function from 0 to the current
time in a 0.0f-1.0f range. Essentially I imagine there would be a few
animation types AnimationTypeSpring, AnimationTypeQuadratic, etc and
you would create an animation like this with a few other attributes,
and it would return an int handle you can use to start/stop/step the
animation.

Also I would like some sort of other system that automatically handles
animation of windows, for things such as movement, attributes,
rotation, scaling, etc. With a constraint system it would also be easy
to say constrain the rotation vector to the opacity vector to the
scaling vectors, and then animate the scaling vectors which would have
an overall effect of scaling the window while spinning it and fading
it out. It would also be great if there were some way to allow
external apps to leverage this library.

It's rather hard to articulate what I mean, but I will be posting a
more specific outline of the implementation and API on the Beryl
mailing list within a day or two, I can post it here or CC you as
well.


More information about the compiz mailing list