giovedì 25 novembre 2010

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...

Nessun commento:

Posta un commento