[quote=142396:@Jeff Tullin]If you consider the overall image as a set of smaller tiles (maybe 64 x 64 or larger)
Then moving ‘the image’ becomes a question of ‘painting the visible bit’
There have been a number of coding examples of using OpenGL to do this kind of world mapping in recent months, but if you want to go pure Xojo, the technique is to know where each ‘virtual’ tile gets its ‘actual’ information from.
Then , having ‘dragged’ the image, or used the scrollbar, you can redraw the visible tiles in the paint event
This implies a ‘drag and wait for paint’ experience, but that seems to be exactly how most map viewers I have seen do the job too.
You could smooth the experience by creating an off screen image 9 times the size of the visible window, so that you can drag ‘the whole image’ smoothly.
Assuming the user can only drag a visible window to the left or right by the width of the window, then you redraw the 9 areas as soon as they let go of the mouse and reset your base co-ordinates[/quote]
I was pondering this exact method last night.
The ‘process’ being something like this:
Load initial map tile and display/centre it
Using this as a centre tile, load the 8 surrounding ones and create one larger one in memory
When the user has scrolled past what would be the edge of the original, display the bigger in memory image at the same coordinates as the last known ones
Whenever we get to within 2 canvas widths or less of the edge of the ‘large’ image, repeat the process of building a big image ready to swap them over.
When a swap occurs, destroy the original image.
If the creation of the new image can be completed in advance, then swapping from the existing one to the new one should be fairly smooth.
As for creating the larger images in memory, something along these lines:
Get the size for each map tile on disk
Create an equally sized memory block
Create a binary stream
Load the contents of the map tile to the memoryblock using the binary stream
Repeat until all 9 are loaded
Since the tiles are all exactly the same size in pixels, create a single in-memory image, 3 x 3 tiles in size, and paint the individual tiles onto it
Deallocate the 9 individual memory blocks to free up memory
Looking again at the map tile sizes this morning, they do vary depending on the content; the largest is 7.7mb.
So a single large image would be no more than 70 mb in size. That should be a doddle for Xojo to manipulate. So much so, that I think you could possibly even pre-empt to the extent of creating the large tiles in advance for all four directions, since the user could actually change their mind and scroll a different direction after all.
Creating 4 x large images in memory, total no more than 280 mb should be achievable; Ive seen some people manipulating single images much larger than this.
I think the trick here is making the right decision in determining when to create the next large image, based on the users scroll activities.
There are a maximum of 800 map tiles in total so far to cover the planned geographical region Im interested in. So whatever works for this, could easily work on a much larger scale too.