[OpenLayers-Dev] smooth pan (animated)

[Pierre GIRAUD]

Comments below.

On Jan 16, 2008 5:10 PM, Christopher Schmidt <crschmidt at metacarta.com> wrote:
> On Wed, Jan 16, 2008 at 04:42:06PM +0100, Pierre GIRAUD wrote:
> > One other problem though : while playing the animation, on each step,
> > the map.setCenter method is called. This way, map events (movestart,
> > move, and moveend) are triggered several times. This may be weird if
> > the application has listeners registered on those events.
> > In the map manual (with mouse) drag control, we prevent those events
> > to be triggered by calling setCenter with a specific boolean (and
> > optional) "dragging" parameter. Some may say, "what about using this
> > paremeter ?". Because, as already reported by Eric [1], this dragging
> > parameter is probably not well documented and it has other
> > implications. He's proposition to have a new 'noEvent' parameter suits
> > my needs.
>
> I'd say that the name 'dragging' is a poor choice, but that the idea
> isn't that different from 'noEvent': the goal is to say "Don't do a
> bunch of stuff that you could do, because we're going to send another
> setCenter Real Soon Now -- so don't call events, or move the foobar, or
> do that other thing, because you're just going to have to do it again,
> and it won't make much difference."
>
> With that interpretation, is noEvent really that different from
> dragging? I'd like to understand how, if possible.
>
> > With a new 'noEvent' parameter, I can continue to call setCenter on
> > each step without triggering too many events.
>
> I think a cleaner setCenter implementation is well deserved at this
> point, and we should ponder creating one.

This sounds good.

>
> > If this is clear enough, I would be pleased if you can give me your
> > opinion on that. If it isn't, don't hesitate to ask for more
> > explanations.
>
> I'm going to pull a Schaub here, and suggest something rather radical:
>
> We should split setCenter into two methods. We have all these various
> callers of setCenter, and we don't have a way to differentiate between
> 'external' and 'internal' at the moment. I think that we should split
> that into two functions:
>  * setCenter is the external API used by users -- it has only two params
>    (lonlat,zoom) and it then calls...
>  * moveTo, internally, which takes a cleaner set of args: probably
>    lonlat, zoom, {options} -- which has the current options embedded
>    into it, and allows us to add in options for, for example, 'tween' or
>    what have you.

I agree with that. It would help us add new parameters easily. I do
understand your arguments but actually, I don't think this helps me.

In fact, I'm still not in favour to put the tween in setCenter nor in
moveTo because I think that the animation needs to be launched only if
zoom level doesn't change.
To prevent events to be triggered in setCenter, I tried using the
already existing dragging parameter. It worked well. I only added some
code to trigger the "movestart" and "moveend" events as the animation
starts and finishes. That way, the "movestart", "move" and "moveend"
sequence is correct. Which is not the case with the dragPan control.

I then looked where setCenter is called with no zoom change elsewhere
in the API. The OverviewMap control can be updated. If you click on
the overviewmap or drag the rectangle, the main map may pan smoothly.
http://dev.openlayers.org/sandbox/camptocamp/panto/examples/overviewmap.html

Anyway, this shouldn't stop us working on a future map moveTo function.

>
> We then change all the internal callers to use moveTo, and the external
> callers can continue to use setCenter.
>
> Problems:
>  * If users have written their own pieces of code which use setCenter,
>    and depend on the stuff in the args, they will break.
>      * Possible solution: Allow the setCenter call to continue to have
>        the four args, and translate them internally to the new calling
>        structure of moveTo.
>
> Things this helps:
>  * Determining whether the caller is internal or external. steCenter
>    will set a flag in the options to say 'called externally', and we can
>    look at that -- so you don't have recursive issues, since you only
>    start the tween on things that were 'called externally' rather than
>    internally.

I definitely don't see how I can integrate the tween thing into this
moveTo method in a simple way. My main fear is the number of different
cases to test : dragging, zoomchanged, caller, etc ...
Once again, animation is, in my opinion, only worth for panning
(without zooming in/out) and I would like to have distinct methods for
simple panning and recenter, as GMap already does.

Last thing, I just wanted this panTo to be a concrete example of the
OpenLayers.Tween usage. Others can be found. The next one in my needs
is the google popup animated resize.

Regards,
Pierre

>
> Maybe this doesn't actually help, and it just seems like it does to me
> -- thoughts?
>
> Regards,
> --
> Christopher Schmidt
> MetaCarta
>