Dragging in VE is screwy

from cr5's email to dev list:

I think the reason for this bug is this:

• We call VE's 'setCenter' method
• We loop quickly again and do a diff between our position and the last time we called setCenter
• We find the current pixel location in geospace via getLatLonFromViewPortPx.
  • But the center didn't really update immediately, so it's calculated from our *old* Location, and therefore we have mouse drift.

I'm not sure what the solution to this is. I stared at it for about na hour before I gave up, and couldn't think of anything to fix it, because it requires more intimate knowledge of the internals of the mapping API than we have for VE or MultiMap. Essentially, I think that the setCenter call ends up being asynchronous in some way (Though I'm not sure how), and since this is a API-level difference -- you don't see the same bug in Google, but you do see it in MultiMap -- it's probably going to require some API level differences.

The thought I had was to store the previous offset -- which might not have actually been performed -- and if we find out we didn't actually move, then use that. However, I'm not sure about the feasability of that solution -- I didn't get far enough to actually write any code, so it may not work in practice even though it seems to work to me conceptually.

Feedback welcome.

When dragging, we currently use PanToLatLon. This means that the action is asynchronous: when we call the next getcenter, the pan operation hasn't completed yet. Instead, we should use SetCenter.

VE Patch to change from PanTo -> setCenter

Erik or Schuyler, can you review the attached patch and give it a go/no go for inclusion into 2.2? This significantly affects projecting WMS over VE, since our PixelFromLonLat calculations all are affected by its behavior.

this is a very straightforward patch. please apply it.

r1709.