Map dragging is not as smooth as it could be

[tono]

There is a lot of processing on every mouse move during dragging. We should only move layers container until these caltulations are necessary. Current implementation can cause lags in map move not only on older computers. Particularly in IE6/7 browsers lags are quite big.
I tried to modify Control/DragPan.js to only move layers container via CSS until not-moving for 25ms or drag end. You can try:

•  current OL 2.6 dragging
•  modified dragging

Consider it only as a proof of concept and thing to discussion. I don't know OL source architecture deeply.

[euzuro]

See #1125

[tcoulter]

Had a discussion with tschaub & euzuro. Looks like I'm going to edit the drag handler to call drag after a timeout, but make that timeout configurable. As well, I'll edit the DragPan control to use a timeout that feels good (tono, the reporter, recommends 25; I'll look at timeouts above and below that).

[elemoine]

pgiraud also did some work towards improving dragging performance. IIRC his work involves caching values no to compute them on each move. May be worth checking with him what he's done. I would rather first seek code optimization before adding timeout-based "hacks". Just a thought...

[tcoulter]

Attaching a patch that incorporates the patch above but puts it in the Drag control instead. The timeout time is configurable (and set to 0 by default), but the DragPan control sets it to 25 milliseconds to increase panning speed.

I'm going to assign to crschmidt and set to Review.

[tcoulter]

Patch for review

[tcoulter]

Oops. 25 == 25; also added no timeout if interval <= 0

[crschmidt]

So, The Navigation control doesn't allow you to set dragPan options. We want to allow people to override this. So the Navigation control needs a dragPanOptions that results in being able to control that from the Navigation options.

[tcoulter]

Added dragPanOptions param in the Navigation control

[tono]

I would like to correct statement in new code (configurabletimeoutdrag.2.diff) where it says that interval is "The number of milliseconds that should ellapse before panning the map again." This is not right. The map is panned continually, only demanding coord2px/px2coord calculations are performed when user have not moved the map for 25ms (or custom interval now). I wrote it so and I believe only change in last patches is the option for setting the interval (I haven't study new code deeply). Anyway I'm lucky to see progress in this ticket.

[crschmidt]

(In [7608]) patch for improved mousedragging. We were able to test this on my eeepc and get a very obvious speedup in performance. This adds a configurable 'interval' to the dragpan control (and an interval to the 'drag' control, defaulting to 0px). Patch put together by tcoulter. (Closes #1509)

[euzuro]

(In [7612]) adding types to properties from the mousing improvements patch. No functional change, only documentation. (See #1509)

[crschmidt]

tono:

I don't think that's true with the current patch. Specifically, if you set the interval to '1000ms', and drag the map, it will 'lag' for 1000ms.

If you think this behavior is wrong, then that's okay: feel free to adjust the patch, but we don't do what you're thinking, I don't think.

[crschmidt]

(In [7615]) Change getMousePosition to only be called automatically *if* the 'includeXY' flag on the Events object is set to true. This ends up meaning that we save a lot of unneccesary getMousePosition calls because (for example) the layer doesn't need to include the .xy property. In addition, we add in speed improvements via caching to the getMousePosition, courtesy the work from pgiraud (which was worked on further by tcoulter) -- this results in significantly improved getMousePosition performance improvements in 'real life' situations that are more like the cases that people use OpenLayers, with a higher number of containing divs (and also clearly demonstrate a gain in performance even in the simple case.)

The end result is:

• In typical map movement over the map, (n / n+1) fewer calls to getMousePosition, where n is the number of active layers when dragging over the map.
• In the simple case, 40% faster getMousePosition performance -- and in more complex cases, significantly more performance improvements.

To drop the former improvement, which may affect some applications (as described in the includeXY documentation) simply set:

OpenLayers.Events.prototype.includeXY = true;

This will restore the 'every element has an xy property always' behavior that was the case beore this patch.

r=me,tschaub, work by pgiraud related to (See #1509), and (Closes #1459)