Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bulk processing issues #12

Open
manuuuu400 opened this issue Dec 19, 2020 · 3 comments
Open

Bulk processing issues #12

manuuuu400 opened this issue Dec 19, 2020 · 3 comments

Comments

@manuuuu400
Copy link

manuuuu400 commented Dec 19, 2020

When using the tool for larger tilesets, I ran into some easily fixable issues.

Rendering problems

During downloading the process gets appended in the textarea in the sidebar. This causes lagging until the page reacts very slow or even freezes complitely after some time. The issue here is a very long text inside the textarea.
You can work around it, if you limit the content to a certain length, which can be achived with a small call to a substring function like so:
function logItemRaw(text) {
var logger = $('#log-view');
var value = logger.val() + '\n' + text;
var maxLength = 10000;
if(value.length > maxLength){
value = value.substring(value.length - maxLength, value.length);
}
logger.val(value);
logger.scrollTop(logger[0].scrollHeight);
}

Out of memory

When downloading for longer periods of time, I ran into an issue, where the tab in Chrome crashes, with an 'Out of memory' message. I noticed that the time until this happens it is related to how large the image tiles are.
The problem is that every request with its result (which also contains the base64 tile) is stored in an array but never removed again. This causes a constant memory increase over time.
You can fix this by removing the data from the array, when it is not necessary anymore.
This can be achived by these lines inside the 'always' function of the ajax request:
var removeIndex = requests.indexOf(request);
if(removeIndex >= 0) requests.splice(removeIndex, 1);

The complete part sould look like this:
.always(function(data) {
i++;
removeLayer(boxLayer);
updateProgress(i, allTiles.length);
done();
var removeIndex = requests.indexOf(request);
if(removeIndex >= 0) requests.splice(removeIndex, 1);
if(cancellationToken) {
return;
}
});

All in all I have to say that your tool is great! Not only by getting the job done, but doing it in a beautifully visualized way!
I could watch it download all day long :)
Thanks for publishing it 👍

@aavesh1
Copy link

aavesh1 commented Dec 23, 2020

Hey , Can you help me with how to set this up on a windows PC .

@manuuuu400
Copy link
Author

@aavesh1 Sure! I was using Google Chrome when i noticed these problems.
The memory issue is also present on Microsoft Edge. No other browsers tested.

Make sure to select a download source with images, that are not optimized too much - just check the file size of a tile. The larger it is, the faster you will encounter the memory issue.
Rendering in x2 under "More options" is also a way to increase the memory usage.

Then identify the process of the chrome tab in your task manager (you can see it very easily if you keep zooming in and out on the map, the process should use some CPU power during that).
While the download runs you should be able to see an increase in memory usage, which is constantly getting more an more.
With my fix applied, the increase should stop after the download of the first couple of tiles is finished.

The first problem should be noticeable in the same way, although you might run out of memory before you start noticing that.
You could set up a test case with a loop just constantly appending text to the textbox and the chrome tab should get very laggy at some point.

I hope this helps :)

@FarisSquared
Copy link

can confirm this issue in chrome, ran out of memory.

downgrading zoom level is bandaid fix (reduce the number of images downloaded)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants