search

Podshot / MCEdit-Unified

Combined MCEdit & Pymclevel repository.
http://podshot.github.io/MCEdit-Unified/
ISC License
483 stars 109 forks source link

Working with large selections 1024x1024 or so, when saving changes it seems to be waaaay slower now #95

Closed TrazLander closed 9 years ago

TrazLander commented 9 years ago

This is a call to @skinny121 who put in the tile ticks stuff. Maybe you know what's up.

Quote from @threetwo :

I haven't posted an issue on the tracker because I haven't really isolated it yet but, working with large selections 1024x1024 or so, when saving changes it seems to be waaaay slower than the last codewarrior build. It also hangs and the program blue rings for sometime near the end of the operation. It seems to work out okay if you let it do what it's gotta do but, 'program not responding' is a scary thing to wait for.

@Khroki :

if I had to guess it might be related to tileTicks being handled now, not sure what else was touched in that code we can look to see what it does near the end

@threetwo:

ahh, the tile ticks might be it. All the chunks in my selection are marked as unpopulated meaning the game will decorate them when the map is loaded.

BenLewis-Seequent commented 9 years ago

I can's reproduce the difference between The last codewarrior's release 0.1.7.1 and the repo source. I get similar(slightly better) saving times on the repo using the same 1360x1360 map(generated by mcedit) after a fill and replace operation with stone. But after the lighting recalculates I do notice it becomes unresponsive(occurs in both version) This is when it does a lot of copying files and saving to file from memory. So having an unpopulated world with a lot of tile ticks will cause this to be slow just because of the inflated world size that causes. Although the issue remains that mcedit becomes unresponsive with large worlds.

TrazLander commented 9 years ago

Is the estimated time/loading bar not factoring in some stuff?

Khroki commented 9 years ago

The time estimator counts up atm, at least in some panels, not a good metric. It's more an issue of the program being unresponsive when processing a lot of data.

BenLewis-Seequent commented 9 years ago

The problem is for the "saving" bit there is no update to the indicator and (I think that) is making it not responsive as all of the time is spent saving. When the progress indicator is used a bit of time is given to the UI to make is responsive.

TrazLander commented 9 years ago

Closing this because of @skinny121's partial fix. Seems better now. If it still seems like a big issue later can reopen or open another ticket, but only do that if someone actually plans to look into it.