Lect0r / osmdroid

Automatically exported from code.google.com/p/osmdroid
0 stars 0 forks source link

zoom in without cache doesn't look good #46

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Zoom in to an area that is not cached, using Android 2.1 (HTC Legend).
There's a smooth zoom to the new level first but then the screen is grey
until replaced with the new tiles. I think this worked better on my G1,
i.e. the scaled tiles were replaced by the new tiles, without any grey
"tiles" in between.

Original issue reported on code.google.com by misc2...@danielnaber.de on 25 Apr 2010 at 12:20

GoogleCodeExporter commented 9 years ago
See also https://bugs.launchpad.net/opensatnav/+bug/579473

Original comment by neilboyd on 22 Jun 2010 at 1:47

GoogleCodeExporter commented 9 years ago

Original comment by neilboyd on 8 Jul 2010 at 2:34

GoogleCodeExporter commented 9 years ago
Issue 88 has been merged into this issue.

Original comment by phr...@gmail.com on 29 Sep 2010 at 5:03

GoogleCodeExporter commented 9 years ago
So, it appears that we want to be able to retain the state of the "zoomed in" 
map tiles until the new tiles arrive. I see two possible solutions:

- One way to do this is to switch to a back-buffer style approach where we keep 
a bitmap in memory that represents what will be drawn to the screen. We draw to 
the bitmap and then draw that bitmap to the canvas. The bitmap is retained 
between onDraw calls and therefore we can paint the zoomed tiles to the 
back-buffer and not lose them. An ancillary advantage of going this route is 
that we can get rid of the in-memory cache which ultimately doesn't save us any 
memory since we need an equal sized back-buffer Bitmap, but it eliminates the 
need to constantly allocate new Bitmaps to put in the cache thereby reducing 
GC. However, it's a big change and unless others can see a greater advantage to 
using it, then we should consider the next suggestion.

- Using a SurfaceView appears to give us the ability to lock the canvas and 
retain what is drawn on the screen. It sounds like it is similar to a 
back-buffer, but wrapped for convenience and would be less implementation work 
against what we already have. It runs on a separate thread, so it may speed up 
draws and make the app feel more responsive.

Anyone have any experience with SurfaceView? Is it a good fit?

Original comment by kurtzm...@gmail.com on 15 Jan 2011 at 3:48

GoogleCodeExporter commented 9 years ago
I'm playing around with the SurfaceView and it's pretty easy, but it's not like 
a regular canvas. I think the drawing surface is fixed, because I have to use 
the ScrollX and ScrollY to offset where I draw to get it to scroll. I'm slowly 
figuring it out, but if someone has a quick explanation of how the drawing 
coordinates work when using a SurfaceView, that would make this easier.

Original comment by kurtzm...@gmail.com on 16 Jan 2011 at 12:08

GoogleCodeExporter commented 9 years ago
Okay, so a SurfaceView doesn't account for your scroll position - the clip 
bounds are always (0,0,width,height). So after trying a bunch of different 
things, the solution is actually easy - when we do our translate() in onDraw, 
we also account for x,y scroll values. So:

c.translate((getWidth() / 2) - getScrollX(), (getHeight() / 2) - getScrollY());

This translates the canvas for us into post-scrolled coordinates and everything 
works without further changes. The final step is to now get zoom animation 
working, which seems to have broken (along with flinging).

My initial observation is that performance is no better, and perhaps a little 
worse with a SurfaceView. This seems counterintuitive, but we are doing all 
that math constantly since the redraw happens continuously (rather than waiting 
for the screen to be invalidated). We probably have to implement logic to not 
redraw the screen if nothing has changed.

Original comment by kurtzm...@gmail.com on 16 Jan 2011 at 1:18

GoogleCodeExporter commented 9 years ago
So, it appears that animations don't work with SurfaceView (can anyone 
confirm?), so that's pretty much a dead-end unless someone can suggest a 
solution.

OpenGL anyone?

Original comment by kurtzm...@gmail.com on 16 Jan 2011 at 2:02

GoogleCodeExporter commented 9 years ago
Okay, so a little more investigation and it turns out that it isn't so hard to 
manually apply animations. We just start the animation, and call 
getTransformation() when we draw. Then we apply any alpha transformations to 
our canvas and we postConcat() any matrix transformations. Quite easy actually!

And after playing with this a bit, the performance actually does seem better 
most of the time - I think "flinging" is just broken so that makes it seem 
jerky at first. I think there might be merit in going the SurfaceView route.

Original comment by kurtzm...@gmail.com on 16 Jan 2011 at 5:50

GoogleCodeExporter commented 9 years ago

Original comment by neilboyd on 12 Nov 2011 at 5:58

GoogleCodeExporter commented 9 years ago
Attached is a patch that seems to work. When you zoom +/-1 it will rescale the 
tiles and use them until the real tiles arrive. It works better for zoom in 
than zoom out, probably because when you zoom out you need more tiles that are 
not in cache.

Original comment by neilboyd on 23 Nov 2011 at 9:39

Attachments:

GoogleCodeExporter commented 9 years ago
Attached is a new patch which seems to work quite well, including arbitrary 
zoom changes when pinch-to-zooming.
It still seems to have a bit of an issue of continuing to use the scaled bitmap 
and not requesting new tiles.

Original comment by neilboyd on 28 Nov 2011 at 10:19

Attachments:

GoogleCodeExporter commented 9 years ago
Here's another patch which has a hack that seems to fix the issue I described 
in the previous comment, although not in a particular elegant way.

Original comment by neilboyd on 28 Nov 2011 at 10:37

Attachments:

GoogleCodeExporter commented 9 years ago
Here we go again!
This is a much nicer fix that keeps track of whether tiles are expired.
This can be extended for tiles that are expired on the file system.

Original comment by neilboyd on 30 Nov 2011 at 6:18

Attachments:

GoogleCodeExporter commented 9 years ago
This issue was closed by revision r1010.

Original comment by neilboyd on 7 Dec 2011 at 6:07

GoogleCodeExporter commented 9 years ago
See also issue 279

Original comment by neilboyd on 7 Dec 2011 at 6:10