<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> In any case: We providedd getLonLatFromPixel as the main 'API' property<br>
> > so that people wouldn't have to use a funky-named property: it's a<br> > > wrapper around getLonLatFromViewPortPx.<br> > ><br> ><br> > Just a suggestion. Considering that the "getLonLatFromPixel " is a<br>
> wrapper around "getLonLatFromViewPortPx", why not renaming it as<br> > "getLonLatFromPixel", and use this in the rest of the library?<br> <br> <br>The biggest reason is the same reason we maintain a difference between<br>
getPixelFromLonLat and its underlying function call: in that case, we<br> (just today) changed the underlying method to not round numbers, but we<br> can change the API wrapper so that it continues to behave the same, with<br>
no affect on existing applications. If, for example, we wanted to change<br> the library in the future so that getLonLatFromPixel could, as an<br> option, transform from the map projection to an actual lon/lat, we could<br>
do this in tis function without affecting the rest of the library.<br> <br><br> > As JavaScript is a interpreted language, all function calls has a cost,<br> > and because of this, is not recommended to use wrappers and getters<br>
> since they will just call another function, with a higher performance cost.<br> <br> <br>This performance cost is not important in the big sheme of things. A<br> single DOM reflow can be hundreds of times more expensive than a<br>
function call. There is no real reason to change this from the way it<br> currently is.<br> </blockquote></div><br>Yeah, you're right. Such change would require a lot of work, and the<br>befenits would be almost imperceptible, since the bottleneck of<br>
performance in web applications is more related to DOM operations,<br>as you stated. So, looking more carefully to it, I also think that it <br>wouldn't worth doing this.<br><br>But, anyway, I was just sharing my thoughts with you developers.<br>
<br>Thanks for your considerations.<br><br>regards,<br><br>Pedro Simonetti.<br>