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

[Sam Spilsbury]

On 5/10/07, Erkin Bahceci <erkinbah at gmail.com> wrote:
> 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.


So you mean like a gripmap interface within compiz? That apps can plug in to?

> > > 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.


True



> > 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.


So you mean setting the duration and then the speed/timestep is
calculated from that. Ok, that works ;-)

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


Thx ;-)

> Cheers,
> Erkin
> _______________________________________________
> CompComm mailing list
> CompComm at Rock3d.org
> http://www.ubaight.com/mailman/listinfo/compcomm
>