[Compcomm] Animation depricating Minimize. There is one last thing that minimize can do

[Erkin Bahceci]

On 5/9/07, Sam Spilsbury <smspillaz at gmail.com> wrote:
> On 5/9/07, Erkin Bahceci <erkinbah at gmail.com> wrote:
> > We could ask David to consider such interactions between plugins while
> > he's working on or planning those changes. This could be done by
> > putting the grid locations of vertices (where each vertex falls on the
> > rectangular window grid) into the core just like the vertex positions,
> > so that different plugins (e.g. wobbly and animation) can manipulate
> > the vertices (depending on those grid locations) simultaneously by
> > "adding" their position/orientation changes for vertices instead of
> > setting "absolute positions" for them. The number of vertices (or the
> > grid resolution) has to be set in core options in that case. I don't
> > know if this is what you or others want though. Any comments on this?
>
> So what you mean is that the wobbly for example can animate the current
> state of the window during the magic_lamp animation? That would solve the
> problem so I think we need to talk to him about that. Thing is though, can
> we have 2 gridmaps manipulating one object? It would have to be like this:
>
> 1 The first Idea of having animation, fade and wobbly as "Gripmap providers"
> So they both submit "Their" gripmaps and compiz makes them into one gripmap
> which is then displayed. The problem with this is the overhead though....
>
> 2 The next idea of having either animation or wobbly control the gripmapp'd
> output of.. animation or wobbly. The problem with this is which one will be
> doing the "First" gridmap and which one will be manipulating the output of
> the "First" gripmap and displaying it as the final gripmap...
>
> 3 Finally, There is the minimize way, which translates and scales the
> current output of the window on the intended path. This would not work for
> anything other than zoom, sidekick and possibly minimize


Fade just changes opacity of the window, and minimizes just sets
window position and scale.

For animation and wobbly, you'll see in the code that both plugins
create vertices which are stored in CompWindow structure, and
therefore shared, and which the plugins set absolute positions for.
What I'm proposing is to make them "add" their "position changes" onto
the current positions of those vertices instead of setting absolute
positions for them. They just need to know what point on the window
each vertex corresponds to (it's a simple list of vertices). This can
be done by putting 2 more values (x, y) for each vertex in CompWindow,
so that every plugin can compute their "position changes" according to
where each vertex corresponds to on the window. Currently each plugin
only has this information for the vertices created by itself.

For plugins to request creation of vertices in a particular way, there
could be core functions like requestRectangularGridVertices and
requestRadialGridVertices (this one would be much better for, say, a
whirlpool animation), etc. with some resolution. The resolution could
be a core option.

No need to submit gridmaps or anything else.


> > For (1), the velocity model "dx = f(v)" (for some function f) used by
> > Minimize is not "much more flexible" than just using "x = f(t)" (for
> > some other f). It's just a different way of doing things. It's
> > actually more limiting in some ways, like not being able to accurately
> > control the positions of points. However, I do like the springiness of
> > Minimize's zoom. So I can consider the springiness for some animations
> > (Sidekick, Zoom, and the (future) minimize variants of the fold
> > animations).
>
>
> I agree that code-wise it is not much more flexible in the way it works, but
> for the user it is.
>
> With the current "time" system it works something like this
>
> Overall animation path/distance/whatever it is is calculated>Divide that by
> the time specified to give you your "Distance per ms/whatever the unit
> is">Play back each step until animation is finished
>
> Its static and does not allow for acceleration or total speed etc.
>
> With the spring model or acceleration, speed and resistance model it looks
> something like this afaik
>
> Calculate distance>Use speed to determine how fast the animation should
> go>Accelleration breaks it up into chunks like this ( |    |         |
>           |               |       |    |  | | etc) Resistance - does what
> resistance does (I'm not really sure what it does...) > Play back each
> chunk.
>
> ( Each (|) is a step)
>
> The only problem with the spring model is that you are unable to actually
> specify the amount of *time* you want something to take.

This is one reason why I avoided this velocity model in the first
place. With the velocity model, Minimize/Scale/etc. uses
speed/timestep parameters. If I do that, the duration you set will be
non-functional and it will look like there is a bug or something.


> You could have a
> box in ccs though called "Time taken" to give the user a rough idea.

You mean computing duration for the speed/timestep parameters the user gives?
I'm thinking of again using a duration option instead and trying to
finish the animation as close to the given duration as possible by
adjusting the speed.


> Also, I must correct myself, minimize does not use gripmaps but instead uses
> translation and scaling of objects

Yes.


Cheers,
Erkin