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

[Sam Spilsbury]

On 5/9/07, Erkin Bahceci <erkinbah at gmail.com> wrote:
>
> Hi,
>
> David is planning some changes on how vertices are generated and animated:
> http://lists.freedesktop.org/archives/compiz/2007-April/002020.html
> http://lists.freedesktop.org/archives/compiz/2007-April/002040.html
>
> Therefore for (2), I would wait for those changes, otherwise anything
> done now about that will probably have to be rewritten when he changes
> how things work.
>
> 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


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. You could have a
box in ccs though called "Time taken" to give the user a rough idea.


And about the replacing thing, the core is going to stripped off of
> plugins anyways (as David said). So what do you mean by Animation
> replacing Minimize? Do you mean that Animation will be distributed in
> the composite community package/distribution by default instead of
> Minimize? I thought that already was the plan :)



Well, I meant that the Animation plugin will be shipped by default and the
minimize plugin will be gone like miniwin is now history ;-).


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


Cheers :)
> Erkin
>
>
> On 5/8/07, Sam Spilsbury <smspillaz at gmail.com> wrote:
> > Hi. Recently there has been some discussion about the animation plugin
> > replacing the minimize plugin. Most of the feature deprications are
> going to
> > be handled or have been handled by the animation plugin itself. However
> > there are two more issues.
> >
> > 1 Spring Model. Minimize used a spring model to control the way its
> > animations worked. The animation plugin is one of the only plugins that
> does
> > not use this. I'm not too sure what the benefits of a spring model is,
> but I
> > know it is much more flexible than the current 'Time' system being used.
> >
> > 2 Minimize can transform windows that are being transformed already.
> This is
> > pretty much essential if you don't want a conflict between wobbly and
> > animation. The old minimize plugin used to be able to transform windows
> that
> > were still wobbling (A good example of this, have :animation" and
> "minimize"
> > on at the same time and set the minimize animation to "magic_lamp.",
> Also if
> > you have wobbly on a low spring_k, then this happens too). The current
> > animation plugin cannot do this and with ccs, the wobbly plugin is
> loaded
> > before the animation plugin, so if focus_effect for normal windows is
> > enabled, then when unminimizing windows, they appear on the screen and
> > "bounce" first then if the animation is not finished it ill suddenly
> play
> > from where it is at. I'm not too sure if solving no 1 might solve no 2.
> >
> > Regards
> >
> > SmSpillaz
> >
> > _______________________________________________
> > CompComm mailing list
> > CompComm at Rock3d.org
> > http://www.ubaight.com/mailman/listinfo/compcomm
> >
> >
> _______________________________________________
> CompComm mailing list
> CompComm at Rock3d.org
> http://www.ubaight.com/mailman/listinfo/compcomm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.RiverGorgeSolutions.net/pipermail/compcomm/attachments/20070509/d4912cf7/attachment-0002.htm>