search

udoprog / c10t

A minecraft cartography tool
Other
225 stars 50 forks source link

Reimplement cache system #205

Closed uap-universe closed 12 years ago

uap-universe commented 12 years ago

This is not a real duplicate of #132 but it is highly likely a consequence of this issue.

Note these lines: renderer.hpp - L57f.

There seems to be a very good reason why this is comment out, but it should not stay commented out. With some more information about why this has been commented out and what should be done to get the caching working again, I can start working on that.

udoprog commented 12 years ago

The reason is that the cache system was implemented before mcregion, and it is based on modification times of the separate files. Now many chunks are stored in a single file and no modification time is available for the individual chunks, therefore a change to a single region will invalidate the cache for all regions.

Could be solved somewhat, but a major rewrite of the procedure seems necessary to get good performance.

udoprog commented 12 years ago

Please try out https://github.com/udoprog/c10t/tree/cache-test

It's an experimental approach, perhaps not so effective given that the number of files greatly outnumbers the number of regions.

uap-universe commented 12 years ago

Yeah, that's true, but it might be very effective on large maps. The thing is, that c10t tries to store the complete image in memory. That means for my map over 4 gigabytes of memory for one isometric rendering with the google maps api. Unfortunately I haven't studied c10t's caching system well enough yet, but I want to use that to reduce memory usage dramatically as some greater parts of the image can stay on hdd and the split parts are computed separately (instead of having the whole bitmap in memory).

Of course I hope, that c10t does not try to load anything from the cache into the memory anyway to render the complete image, I might have missunderstood the purpose of the cache, then.

I'll study it the next weeks :)

uap-universe commented 12 years ago

By now I don't see any better technique as provided by 822a1c1aeac24d4e13e6b06c9cee0455158efef3. So this is closed.