Closed GoogleCodeExporter closed 9 years ago
See also https://bugs.launchpad.net/opensatnav/+bug/579473
Original comment by neilboyd
on 22 Jun 2010 at 1:47
Original comment by neilboyd
on 8 Jul 2010 at 2:34
Issue 88 has been merged into this issue.
Original comment by phr...@gmail.com
on 29 Sep 2010 at 5:03
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
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
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
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
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
Original comment by neilboyd
on 12 Nov 2011 at 5:58
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:
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:
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:
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:
This issue was closed by revision r1010.
Original comment by neilboyd
on 7 Dec 2011 at 6:07
See also issue 279
Original comment by neilboyd
on 7 Dec 2011 at 6:10
Original issue reported on code.google.com by
misc2...@danielnaber.de
on 25 Apr 2010 at 12:20