You mean like GPSDrive? Yeah, I thought about keeping GPSDrive's original 1024x1024 (or was it 1280x1024?) tile size, but downloading maps 256x256 at a time and storing them 1024x1024 at a time introduces complexities that increase both the CPU and memory requirements:

1. 1024x1024 tile size means that, although fewer tiles are loaded in order to draw the full 800x480 screen (up to 4 tiles instead of up to 12), each of those tiles is 16 times larger. The net difference is that I'd have to read 4.2 million pixels instead of 0.8 million. The amount of memory required to keep those pixels in memory also means a larger memory footprint (unless you want me to re-parse those mostly-same 6.3 million pixels every time the map is panned even a slight bit).

2. There would be two possible paths for retrieving an image: either directly from disk (1024x1024) or instead from HTTP. Two separate paths introduces additional complexity and thus increased CPU usage (and bugs). This isn't that big of a deal, until you consider the HTTP path on its own, which leads to #3.

3. In the case of HTTP, currently, Maemo Mapper uses libcurl to directly transfer the files from remote location to memory card. In order to store 1024x1024 tiles, Maemo Mapper would instead have to read and interpret the 256x256 PNG (or JPEG) data in-memory, then stitch the 256x256 tiles together, then write the data to memory card. This process is not only CPU and memory intensive, it reduces the quality of the original images because they are re-compressed using a lossy compression algorithm.

No, if I'm going to conglomerate multiple 256x256 tiles into a larger file, I might as well go the whole 9 yards and put them all into the same file.

That said, jpj, I appreciate your line of thinking. Your suggestion was good in theory, good enough for me to have considered it long and hard myself, but it doesn't work well with the way Maemo Mapper is implemented). And now, you'll have to excuse me as I go off on one of my typical little tangents (some would call them rants). The following comments are rather unrelated to your suggestion, so please don't consider it any form of disrespect toward you. (And while we're at it, don't consider any of my preceding rebuttal as disrespect, either. )

The whole reason I started writing Maemo Mapper was because GPSDrive was extremely inefficient with CPU and memory, especially on the Nokia 770's limited hardware. Let's face it, GPSDrive was designed for the desktop, and on that platform, it is very versatile. On Maemo, however, you could not even start GPS Drive if you had any other applications open.

I have tried pretty hard to make Maemo Mapper as CPU- and memory-efficient as possible, to the point where some of my optimizations would not work as well for a different screen resolutions or for different behaviors (e.g. smooth tap-and-drag panning). Yeah, it's the classic "optimize before you even know you need it" blunder, but after seeing GPSDrive struggle so hard, I thought I'd address the performance issues first and foremost.

And as an even further tangent, while I'm on the subject of performance... Regarding the n800: The added memory and CPU power of the n800 is not an excuse for an application to be more liberal with memory and CPU. Maemo Mapper was written for the 770, and it will stay usable on the 770, no matter what. In fact, my personal opinion is that, in general, the added CPU and memory capabilities of the n800 should be used not to support hungrier applications but to better support existing applications (*ahem* Opera) and to better support running multiple applications at a time. 90 MB of available memory (when no other apps are running) is not justification to use all of that memory - other applications need memory, too.

Sure, if the demand is there, then maybe (in the distant future) a "higher end" version of Maemo Mapper could be released with the n800 in mind, but I will make sure that it also runs on the 770 (albeit more slowly), and I will strive to make it just as efficient on the n800 as it is now on the 770. Who knows, maybe in the future, there will be two versions (or runtime-configurable modes of operation) of Maemo Mapper: one for lean, mean, efficiency; and one with a slightly larger memory footprint. The latter will be aimed both for 770/n800 users that don't mind allocating more memory and sacrificing some responsiveness.

But until then, I'm ruling out "enhancements" that will inordinately increase memory or CPU requirements.