Rewriting LayerMap and MapChunk

Overnight i came to the conclusion that LayerMap and MapChunk needs to be rewritten.

- all image cache stuff must be inside LayerMap, so that precaching on loading can be achieved simply.
- the chunk layout must be defined starting from the center of the visible_area, identifiyng the center chunk
- MapChunk class is probably useless, just a complication, can be removed (the only two informations it holds are chunk position and chunk data, the first is needed also by LayerMap)
- The triple double-for currently in use to remap all the chunks is overcomplicated. I can simply by using a simple mapped list (QMap) where the key is a mix of x,y and zoom. This way with simply one iteration (plus a second minor only for chunks that needs reloading) (best case: 9-iteration loop, worst case: 18-iteration loop, better than current 27-iterations fixed + up to 9! worst case inner loop)

Update: it took a while, but the new LayerMap code works very well! I am waiting to do some real-world timings on my 5800, just to see if i need to cache also the other zoom-levels or if its fine caching only one zoom level from the image,,,

Now i am a bit lost fixing a bug in the LayerTrack draw code...

Stay tuned!

Drawing the map...

With the new dynamic map system i am facing some troubles in the old map paiting code...

I managed to make the code work... Its just a preliminary attempt to be refined... but it works.

The problem was this:
QRectF visible_area( translation_offset, scaled_size );
this rect has top/bottom inverted after applying the transformation matrix which mirrors the Y axe up/down...

Rebuilding the rect corner-by-corner fixes this. The point is, why do i have to do this? Shouldn't the way i create rectangles on the logical reference system be indipendent of the transformation mapping? When dealing with these things i always have the feeling something is missing... like now.

Update: Fixed for good. Now its clear my error! I was using one single point to identify both the translation offset and the screen starting corner! But since i am flipping the Y ax, actually those are two different points:
- screen starting corder: as usual, its the top-left corner
- offset: its the BOTTOM-left corner, due to the ax-flipping!

Fixed that, now to the map caching stuff!

First of all, i need to fix the chunk loading alghoritm, then i need to implement the caching stuff.

Weekend news...

Hi all!
Ok, as usual this past weekend i didnt coded anything... But my mind was working hard on FreeTrack! So here is what i am going to inmplement this week:

1) fix the tracking table map display for the new "dynamic loading" maps
2) implement caching feature for dynamic maps
3) implement OZI explorer claibration import feature

And, with these, some other tihngs like configuration options to manage map cache (automatic precaching on map load, enable/disable map cache and such).

Update: finally, the TrackTable draw&painting routine has been rewritten... I didnt had to, but as usual i like to improve things on the way. This took me almost one day and half, but its done, its much more clear and requires lett calculations. It should also be a bit more efficient now, by moving some checks and calculus outside the main draw procedure!

What is giving me toubles now is the LayerMap cohordinates translation required to map the image on the screen...

More on dinamyc maps...

Well people,
i have spent most of yesterday thinking about this. And the conclusion is that there is no wasy way, nor perfect solution.

This is the approach i am going to follow:
1) reduced chunks to 9 (3x3 matrix) and increased size to square chunks as big as the main window
 2) reload chunks from disk as in previous post

This will ensure that maps fitting into memory (about 1800x1800px on S60v5 devices, something more on Symbian^3) will still be as fast as possible (no reloads), bigger maps will be loaded albeit quite slowly.

One possible optimization is to cache the image chunks as uchar buffers (after reducing to 8bit and such to save disk), to avoid very slow jpeg decompressions...

I could use libjpeg, which has been ported to Symbian, but what about PNGs? So i prefer to avoid this right now. For very large bitmaps (above 3000x3000px) probably BMPs are faster?

Still, i have to implement the zoom...

Dinamic map loading...

Hi all!
Well, since you WANT to load bigger maps (and i mean BIG, like 16kx16k pixels...) then we NEED to rewrite entirely the image loading. This time, i want to go fully flexible, so i ditched the "one full map = one QImage" approach.

First of all, a few basic principles.
- No part of a map can be loaded bigger than the screen under the assumption that the bigger part of the image i can show is big as the screen.
- Any part of a map that is requested and its bigger than the screen will be scaled down to the screen (if i request a 2000x2000px area, it will be downsampled to, for exaple, 336x560px) since it will be displayed on the screen anyway.

This double approach will let FreeTrack minimize the memory required to load part of an image..

Of course the tradeoff of this approach is an increase in CPU time required to constantly reload from disk the maps... In order to minimize this, we will preload 16 smaller chunks of the image (each = to 1/4 of the screen real estate), so on average we will have to reload about half of the screen...

Update: initial tests on the new code shows good performance... What i did is define the map loadable by "chunks" sized 1/2 of the screen, i keep in memory a "matrix" of 16 chunks. When you want to paint the image on the screen, you give a rect (section of the image to be painted). If this rect is inside the already loaded area, i just paint the already loaded QImages... If part of the rect is outside the loaded area, well, i go at single chunk level, identify all the "still good" chunks and reload only the new ones, discarding the old ones!

Using this approach, on average i reload only 4 chunks (=half image size) with some peaks to 7 when moving a lot in diagonal...

Its a pretty speed boost!

There is more space for speed improvement, tough, by calibrating chunk size/quantity. Its a memory/cpu tradeoff.

Device test initial results: not too bad, but loading is still quite slow... I blame it to jpeg decompression... so i guess using bmp's for very large images is prerable?

Still to be implemented: support for scaling!

Stay tuned for updates...

Maximum map size issue...

Yes, up to version 1.2.1 it is not possible to load maps bigger than 2000x2000 pixel, more or less.

This is due to the maximum heap size set for FreeTrack... I have tried to increase that to 64mb and i was able to load a 3015x2100 pixel jpg.

What puzzles me is that loading that file took some 32mb of memory of my 5800... This is a LOT and almost the double of what is supposedly required to load that image. Why is this? I am already using a QImage, which is supposed to be better than QPixmap for this job...

Update:No, QImage its the best choice... QPixmap will not even load such a 3015x2100px image. But how about converting the image to 8/16bit after loading, to save memory?

Update: that helps... But since Qt will not (damn!) release the memory, i end up eating all the phone memory again soon. The only real solution is to create a class BuffereImage which internally uses QImageReader and some clipping/scaling before loading the image itself. In this way, we could teoretically manage ANY size of images.

With speed issues in mind, of course...

OVI store...

I am in the process of creating the official OVI store SIS package for FreeTrack 1.2.1...

1.2.1 will basically be 1.2.0 plus three updated icons! This will not be released on the website, only on OVI. The 1.2.1 is 1.2.0, so do not worry about updating!

The 1.2.1 SIS file is ready and posted... The only thing wating now are the two spotlight banners required and we are ready to submit to QA for publishing!

Tentative publish date is 1st December 2010. Will we make it?

Welcome to the FreeTrack blog!

Hi guys!
This blog has born today to show to the public what is going on behind FreeTrack development!

So, if you use or like FreeTrack (FreeTrack home page), stay tuned!!!