Closed fcapano closed 11 years ago
Regarding rendering tiles on drag - that's something you can easily implement yourself with the public API. Just add a MapEventListener/Implementation
and override onDrag
with a call to requestRender
. That said, my personal opinion and experience are that the widget feels far less responsive - even when decoding the bitmap off the UI thread, rendering tiles while dragging feels shaky. You can use downsamples to provide lower quality visual feedback while the tiles render.
In response to your first point, I think google maps and osmdroid do that because there tiles are generally fetched over http and require a lot more time than is required with bundled assets. I have implemented this feature before, and even with a single adjacent tile it can get to be a pretty heavy and expensive operation (a 2x2 tile viewport with 1 adjacent tile would go from 4 total tiles to 16, a 400% increase). That said, it'd be fairly trivial to add an offset (fixed pixels, or multiplier) to the viewport Rect that's passed (rather than an number of tiles), and wouldn't threaten the existing API, so I'll consider it as an enhancement / feature request.
Thanks for your input.
The first point (padding the viewport) has been included and will be available with the next minor update. Thanks.
Other applications such as google maps and osmdroid usually render the tiles which are not shown on screen but are "close" the the ones shown. It would be very useful to provide with an option to choose how many adjacent tiles should be rendered.
I also noticed that if the user drags around the map, unrendered tiles are not rendered until the user lifts the finger. Probably the application should check which tiles should be rendered while the map moves, and not when the user completes the drag. It would greatly improve the responsiveness feeling.