Patch for smoother zoom

[William MacKay]

I changed the way the map removes tiles from the display to make
zooming in and out smoother. With my patch, the map won't delete a
tile until either it's offscreen, or there's a
more-appropriately-detailed tile intersecting it. This way, the screen
doesn't fill with the load pattern when you hit a new zoom level.

I've tried to contribute code on the issue tracker online, but none of
my patches have been integrated into the main branch. Is there
anything I can do to try to get my code accepted? This patch in
particular is important, as it fixes a crashing bug:
http://code.google.com/p/route-me/issues/detail?id=31

Will MacKay

[Andreas Linde]

Hi William,

I tried it out and it looks very good so far. Thanks for the patch!

[Quazie]

Great patch. I would love to see this added to the project
officially. I would clean up some of the unnecessary comments and the
isLoaded function in MapView/Map/RMTileImage.m, as it doesn't need two
returns. But functionally the patch is exactly what I was looking
for. Thanks

[Andreas Linde]

I am having issues with tiles not getting loaded on the iPhone, while
it works without a problem in the simulator. Maybe this also gives
some trouble with releasing tiles and a crash I reported in another
thread. Back to SVN code for now.

[lepah]

Hi William,

Have you noticed the problems that Andreas mentioned below about your
patch? If this problem isn't due to your patch or you have fixed the
issue is it possible to get your changes added to SVN? Who's leading
this project now with regards to review and accepting commits?


On Feb 11, 9:16 am, Andreas Linde <linde.andr...@googlemail.com>
wrote:

[Brother]

Colin,

If there is a bug in the current map, could you revert your changes
until you locally figure out what is wrong with the code. If an error
is introduced, it should be fixed ASAP or get reverted so developers
are not affected.

Thanks

B-

[Colin Prepscius]

The code I committed had nothing to do with tile loading. Please have
a look.

[Vladimir Vyskocil]

Hi,

It works ok for me on the phone with the last patch.
I hope more patches will be tested and integrate in the code trunk !
keep up the good work !

Vlad.

[Tracy]

I am also seeing some problems with this patch. While it generally
works, I have seen cases where the higher-zoom tile is never
loaded and the scaled version continues to be displayed. No amount of
zooming or maneuvering fixes it.



On Feb 17, 1:42 pm, Vladimir Vyskocil <vladimir.vysko...@gmail.com>
wrote:

> Hi,
>
> It works ok for me on the phone with the lastpatch.
> I hope more patches will be tested and integrate in the code trunk !
> keep up the good work !
>
> Vlad.
>
> On 17 févr. 09, at 22:12, Colin Prepscius wrote:
>
>
>
> > The code I committed had nothing to do with tile loading.  Please have
> > a look.
>

> > On Feb 17, 2009, at 12:14 PM, Brother <obran...@gmail.com> wrote:
>
> >> Colin,
>
> >> If there is a bug in the current map, could you revert your changes
> >> until you locally figure out what is wrong with the code. If an error
> >> is introduced, it should be fixed ASAP or get reverted so developers
> >> are not affected.
>
> >> Thanks
>
> >> B-
>
> >> On Feb 16, 4:02 pm, lepah <mfarn...@gmail.com> wrote:
> >>> Hi William,
>
> >>> Have you noticed the problems that Andreas mentioned below about  
> >>> your

> >>>patch? If this problem isn't due to yourpatchor you have fixed the

> >>> issue is it possible to get your changes added to SVN? Who's leading
> >>> this project now with regards to review and accepting commits?
>
> >>> On Feb 11, 9:16 am, Andreas Linde <linde.andr...@googlemail.com>
> >>> wrote:
>
> >>>> I am having issues with tiles not getting loaded on the iPhone,
> >>>> while
> >>>> it works without a problem in the simulator. Maybe this also gives
> >>>> some trouble with releasing tiles and a crash I reported in another
> >>>> thread. Back to SVN code for now.
>
> >>>> On 10 Feb., 04:48, Quazie <Qua...@gmail.com> wrote:
>

> >>>>> Greatpatch.  I would love to see this added to the project

> >>>>> officially.  I would clean up some of the unnecessary comments
> >>>>> and the
> >>>>> isLoaded function in MapView/Map/RMTileImage.m, as it doesn't
> >>>>> need two

> >>>>> returns.  But functionally thepatchis exactly what I was looking

[Darcy Brockbank]

Somewhat late to the discussion...

This sounds to me like it is maybe a cache problem. The current
functionality if the SQL cache does not work correctly in all
circumstances. Since you are using your phone and the simulator in
different patterns, they have different contents in the SQL cache.

I am not certain if this is what you are experiencing, but you have to
keep it in mind.

For instance, if you tell the map contents to change map sources,
sometimes it will update the on screen tiles, sometimes it won't. It is
different from phone to phone. I was experiencing this problem
frequently, and then it stopped for my phone, however when I sent out a
test build the tester complained that he was changing map sources and
the results on his phone did not update.

There is also no way to disable the database cache as-is in the code,
which I think is an issue. You can set the size to anything, but if you
set to 0 then the cache decides it is infinite. I would suggest allowing
for a -1 size in the config file to be a disable flag if not having a
disable flag explicit.

This replacement in RMTileCache.m will allow you to compile in or out
support for the SQL database, and that can let you quickly see if any
display issues are due to the dirty cache not being cleared. Note this
will cause a log message in your console about the database being unable
to start.

This is a debugging patch, this is not a functionality patch. I would
make the suggested changes for functionality:

1. add a database enabled flag to the config file to turn on or turn off
the cache completely
2. I would add an instance variable to the abstract superclass for map
tile sources that indicates whether or not the database cache should be
enabled for this map source... default is YES. Some licensed sources
have in their agreements that you may not cache the tiles, and this
would be the smart way of allowing implementors to specify caching
behavior on a per source basis...
3. I would have the TileCache check with the map source to check caching
properties, so that when a new tile source is taken in the cache will
configure itself correctly
4. I would fix the bug so that when the tile source is changed, the
cache correctly interprets this as a complete wipe/dirty of itself and
empties

Alternatively the cache should tag cached tiles not only for location
but for tile source so if someone is using multiple tile sources
flipping back and forth (i.e. a satellite view to a map view) that both
can reside happily in the cache without overwriting each other (as
currently seems to happen).

- darcy

// override to check if the database is on, if it is not, this returns
// nil which should prevent any further attempts to use it
#define DATABASE_ENABLED 1
- (id<RMTileCache>) newDatabaseCacheWithConfig: (NSDictionary*) cfg
tileSource: (id<RMTileSource>) theTileSource
{
if (DATABASE_ENABLED) {
return [super newDatabaseCacheWithConfig:cfg tileSource:theTileSource];
} else {
return nil;

[Hal Mueller]

Will et al: Both Will and Tracy now have commit rights. Could you please apply this patch to the current trunk, and then commit the changes to a branch? It sounds like we might have to do some tweaking before incorporating it into main branch.

Thanks!

Hal

--
Hal Mueller
halmu...@gmail.com
Seattle, Washington

[James Gregory]

Hi all,

Just a quick bugreport on this patch. I've found that it doesn't play nice with a loading.png image -- see the attached screenshot to understand what I mean. I've had a quick look through the patch to see if I can easily see the issue, but I'm afraid I don't fully understand it.

Apologies if this has been fixed in a newer rev, this is from the initial patch that was posted to the list.

Thanks,

James.

[Eric Redlinger]

My experience with the smooth-zoom patch echoes others' - it generally works, but gets stuck fairly regularly.  I suspect it has to do with the way tiles are cached in the sql db, as Darcy has suggested...

<loading-bug.png>

[Hal Mueller]

So are we better off with the smooth zoom patch? or without it?

Hal

[Tracy]

I don't think it should go in the main branch until we at least fix
the tile-loading issue.

I'm pretty sure it had the same behavior w/o the cache, too.

It is really nice functionality, though. I personally haven't had a
chance to investigate it further.

/tracy

On Mar 3, 10:51 pm, Hal Mueller <halmuel...@gmail.com> wrote:
> So are we better off with the smooth zoom patch? or without it?
>
> Hal
>
> On Mar 2, 2009, at 8:02 AM, Eric Redlinger wrote:
>
>
>
> > My experience with the smooth-zoom patch echoes others' - it  
> > generally works, but gets stuck fairly regularly.  I suspect it has  
> > to do with the way tiles are cached in the sql db, as Darcy has  
> > suggested...
>
> > On Mar 2, 2009, at 8:05 AM, James Gregory wrote:
>
> >> Hi all,
>
> >> Just a quick bugreport on this patch. I've found that it doesn't  
> >> play nice with a loading.png image -- see the attached screenshot  
> >> to understand what I mean. I've had a quick look through the patch  
> >> to see if I can easily see the issue, but I'm afraid I don't fully  
> >> understand it.
>
> >> Apologies if this has been fixed in a newer rev, this is from the  
> >> initial patch that was posted to the list.
>
> >> Thanks,
>
> >> James.
>

> >> On Mon, Mar 2, 2009 at 3:01 PM, Hal Mueller <halmuel...@gmail.com>  

> >> wrote:
> >> Will et al: Both Will and Tracy now have commit rights. Could you  
> >> please apply this patch to the current trunk, and then commit the  
> >> changes to a branch? It sounds like we might have to do some  
> >> tweaking before incorporating it into main branch.
>
> >> Thanks!
> >> Hal
>

> >> On Tue, Feb 17, 2009 at 2:52 PM, Tracy <tracy.har...@gmail.com>  

> >> halmuel...@gmail.com
> >> Seattle, Washington
>
> >> <loading-bug.png>

[Matt Farnell]

I'm using the smoother patch, its a much nicer user experience but it does have intermittent issues with not replacing the tiles, this is rare and I'd personally prefer this to the current implementation that 'blanks' the screen every time the user pinched, I showed a few users the original 'blanking' version and it was very off putting and distracting for the users. I think with all our heads we could fix the issue it has. Maybe the developer of this patch has a solution for the outstanding issue? 

[Tracy]

I agree I definitely want this functionality. It is very slick and a
much better user experience.

I was just expressing my preference of "works" over "looks pretty" for
the main branch. ;)

On Mar 4, 9:24 am, Matt Farnell <mfarn...@gmail.com> wrote:
> I'm using the smoother patch, its a much nicer user experience but it does
> have intermittent issues with not replacing the tiles, this is rare and I'd
> personally prefer this to the current implementation that 'blanks' the
> screen every time the user pinched, I showed a few users the original
> 'blanking' version and it was very off putting and distracting for the
> users. I think with all our heads we could fix the issue it has. Maybe the
> developer of this patch has a solution for the outstanding issue?
>

[Quazie]

What happened to this patch? Anyone still working on it/should there
be a branch made for this code?

On Mar 4, 1:36 pm, Tracy <tracy.har...@gmail.com> wrote:
> I agree I definitely want this functionality.  It is very slick and a
> much better user experience.
>
> I was just expressing my preference of "works" over "looks pretty" for
> the main branch. ;)
>
> On Mar 4, 9:24 am, Matt Farnell <mfarn...@gmail.com> wrote:
>
> > I'm using the smoother patch, its a much nicer user experience but it does
> > have intermittent issues with not replacing the tiles, this is rare and I'd
> > personally prefer this to the current implementation that 'blanks' the
> > screen every time the user pinched, I showed a few users the original
> > 'blanking' version and it was very off putting and distracting for the
> > users. I think with all our heads we could fix the issue it has. Maybe the
> > developer of this patch has a solution for the outstanding issue?
>
> > On Wed, Mar 4, 2009 at 7:28 AM, Tracy <tracy.har...@gmail.com> wrote:
>
> > > I don't think it should go in the main branch until we at least fix
> > > the tile-loading issue.
>
> > > I'm pretty sure it had the same behavior w/o the cache, too.
>
> > > It is really nice functionality, though.  I personally haven't had a
> > > chance to investigate it further.
>
> > > /tracy
>
> > > On Mar 3, 10:51 pm, Hal Mueller <halmuel...@gmail.com> wrote:

> > > > So are we better off with thesmoothzoom patch? or without it?

>
> > > > Hal
>
> > > > On Mar 2, 2009, at 8:02 AM, Eric Redlinger wrote:
>

> > > > > My experience with thesmooth-zoom patch echoes others' - it

[Hal Mueller]

On Mar 14, 2009, at 7:25 PM, Quazie wrote:

>
> What happened to this patch? Anyone still working on it/should there
> be a branch made for this code?

I tried (not very hard) to apply this patch a couple of weeks ago a
and couldn't get it to go. I didn't have a good sense of what it was
doing or what it was supposed to look like, so moved it to my "too
hard" box. If someone wants to take another stab at it in a branch
that would be grand.

Hal

[Darcy Brockbank]

The problem with this patch is that there are about 3-4 major bugs in
RMTileLoader.m. Fixing bugs in this object is difficult because it is very
hard to understand, and it's hard to understand because the approach
doesn't make a lot of sense.

The overview is that:

- it's using a counted set datastructure to house the tiles

Which means that:

- you have to do linear searches for most kinds of access to this datastruct
- you have to allocate an object to use as a key and throw it away any time
you want to test for membership
- membership tests don't return the object you may be looking for, so go
back
to the first bullet item

Furthermore, some accesses to the datastructure in their linear search
attempt to search the whole datastructure and do comparisons between
objects.

This is an exponential complexity task then, increasing with the square
of the
number of tiles. There is no good reason for this, it is something that
should
be accessed by key and be O(1).

If this is replaced properly, then the smooth zoom patch can be more easily
applied.

It's a struggle though. I would suggest getting a good handle on the
tile loader,
understanding what it's doing, and then ripping the guts out while leaving
the API intact.

What the smooth zoom patch is intending to do is to leave tiles in place
and as tile updates come in, compare them against the existing datastructure
and throw away any tiles that are further away from the ideal zoom
differential
(which is 0... if the map is set to zoom 15, ideally you want all zoom
15 tiles,
15-15 = 0).

This is where all the iterating and comparing is going.

What needs to be implemented I think is a tile stack.

The datastructure needs to simply index by a virtual grid, which can be
indexed
as follows:

grid position = { vx, vy }

vx = ( tile.x << (18-tile.zoom))
vy = ( tile.y << (18-tile.zoom))

Any tiles that share a grid position are on top of each other. They form
a stack.

So that is the first step in the proposed datastructure, to look up the
stack for
every virtual grid position. O(1). The next step is to insert a tile
into the stack.
Its position in the stack should be relative to its zoom differential.
Since a tile
stack should have one of 0, 1, or 2 members in it, but never more, it is
fine
to do a linear search here. Basically this thing is functioning like as
simple hash
table where the "virtual grid" is just a hash function that is designed
to force
tiles to clash that belong on top of each other. To resolve the clash,
you compare
their zoom differential.

So the tiles then get displayed from top down, where top is the closest zoom
differential to 0.

The next step here is that on insertion you check the load status of the
current
tile, if it is unloaded, then it makes no changes to the stack on
insertion. If
it is loaded, it compares its load status against the other items in the
stack, and
any items below it on the stack are deleted. So basically any loaded tile
causes any existing loaded tile that is worse for the current zoom, to be
deleted and removed.

The last step is that when any tile receives an update, as the data is
written
into the tile, all tiles below it on the stack are unceremoniously removed.

This then means that for any tile stack, the best tiles are on the top,
and the
tile that has data and is being drawn is on the bottom. The ideal situation
arrives when bottom == top, and you have one tile, with data, at the
existing
zoom level.

That is now this datastruct needs to work, and if it works like that,
integrating
the smooth zoom becomes a snap.

No time to implement but that is the required datastructure I think to
replace
the obscenity that is currently there hehe.