Resource consumption in Windows Mobile version


Lynn Deffenbaugh
 

I have uncovered, and hopefully fixed, two problems in the Windows Mobile client. These fixes will be released relatively soon, but I'm hoping to get one or two more things from my (newly updated) ToDo list included. The problems were:

1) The client caches pre-loaded tiles in two levels. The first is an on-disk (flash) cache of tiles fetched from the OSM servers. These are stored under the OSMTiles directory tree. In addition, when a tile is needed for display, the PNG is loaded into memory as a device-independent bitmap. This process is non-trivial, so the client also caches these "recently viewed" bitmaps in RAM. The client has a calculated limit on how many of these bitmaps are allowed to be cached based on the size of the screen (number of tiles necessary for the current display) times the number of available zoom levels (so you can zoom in and out with cached bitmaps). If the cache gets full, the least recently reference bitmap is freed and a new one is created.

This was all working fine until I a) increased the number of tiles buffered on a single level and b) increased the number of available zoom levels from 18 to 24 (for close in zoom of expanded tiles for geocaching work). Well, Windows Mobile doesn't have the (nearly unlimited) resource of teh Win32 version. If you zoom in and out and pan around enough, the cache starts to fill, but before the limit is reached, ShLoadImage fails (with no discernible error message) and everything goes downhill from there

You will see a client that has patchy white areas where the screen was not repainted, double-clicking does nothing, but the X at the top still works. Once you restart the client, you're good for a bunch more panning and zooming. I've fixed it by reducing the size of the bitmap cache back down to what it reasonably was before the (a) and (b) increases. I've also added Cache: information to the double-click OSM information popup.

2) The second problem occurs if you zoom out and drag the map completely away from the center in a vertical direction. If you do it horizontally, the client automatically swaps hemispheres (this will get seemless in some future revision). Vertically, however, breaks and ends up putting the center coordinate of the screen to 180 90 and displays white space instead of maps. The other screen elements are there, but the maps and stations are gone and no amount of panning seems to bring them back.

It turns out that if you've set up a preferred view, double-clicking the scale number (or using View / Preferred / Restore) brings the maps back. An even more interesting point is that the scale number displays a steadily decreasing number as you drag the maps further out the top or bottom of the viewing area. As long as it hasn't gotten to zero, you can actually drag the white-space back and get the maps to be visible again. Once the scale number goes to zero, the only solution is to restore a saved preferred view.

I've fixed this by limiting the top and bottom coordinates to 85 and -85 degrees as corresponds to the available of map tiles from OSM and the limits of their Mercator Projection equations. Sorry, if you're going to visit the extreme North or South of our planet, please leave your APRSISCE/32 client at home (or make special arrangements with me in advance, prepaid tickets to join the expedition might provide incentive enough to work around this issue!).

Just wanted to give you all a heads-up in case any of you are seeing either of these issues. I believe some of you have in the past, but we've never been able to nail down what is going on. Actually, given the resource consumption of the bitmaps, this could conceivably cause other Windows Mobile components (like device.exe) to encounter difficulties on some platforms (thinking HTC Touch Pro here for G4ILO-12).

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

Join APRSISCE@groups.io to automatically receive all group messages.