Changing or reloading Minecraft's texture pack, in any situation, causes an absurd delay where the client is entirely unresponsive. This applies to:
Changing texturepacks via the main menu, under Options
Changing texturepacks ingame via the menu
Server textures activating when you join a server
Server textures deactivating when you leave a server
Refreshing textures when pressing F3+T
The delay ranges anywhere between 7 and 15 seconds for me. The lower end of that range (viz. around 7 seconds) appears when activating a texturepack, even if it only modifies a single texture. The delay tends to be almost twice as long (viz. up to 15 seconds) when switching back to the default texture pack.
This is disruptive, if not altogether deadly, when joining a server with custom textures: the client is unresponsive for at least 7 seconds, during which time any number of bad things can happen (especially if you logged off in the middle of danger).
I should note that, in the past, texturepack changes have not caused client freezing in excess of 3 seconds for me (often as little as about 1.5 seconds), which is understandable.
Linked issues
is duplicated by 1
Comments 4
With the new launcher, I was able to catch a glimpse of what exactly the game is doing during this burst of freezing.
Client> 2013-05-11 21:04:34 [CLIENT] [INFO] Found animation info for: textures/blocks/lava_flow.txt
Client> 2013-05-11 21:04:34 [CLIENT] [INFO] Found animation info for: textures/blocks/water_flow.txt
Client> 2013-05-11 21:04:34 [CLIENT] [INFO] Found animation info for: textures/blocks/fire_0.txt
Client> 2013-05-11 21:04:34 [CLIENT] [INFO] Found animation info for: textures/blocks/fire_1.txt
Client> 2013-05-11 21:04:34 [CLIENT] [INFO] Found animation info for: textures/blocks/lava.txt
Client> 2013-05-11 21:04:34 [CLIENT] [INFO] Found animation info for: textures/blocks/portal.txt
Client> 2013-05-11 21:04:34 [CLIENT] [INFO] Found animation info for: textures/blocks/water.txt
Client> 2013-05-11 21:04:35 [CLIENT] [INFO] Found animation info for: textures/items/clock.txt
Client> 2013-05-11 21:04:35 [CLIENT] [INFO] Found animation info for: textures/items/compass.txtThat's the output when switching to Default. I should mention that it's possible time is being spent on other stuff too (I haven't got a profiler that I can use on Minecraft), but it would make sense that animation construction would be a bottleneck, particularly when considering the number of frames used by clocks and compasses.
With the new texture loading system, thankfully, the freezing period appears to have been cut in half.
I'm not sure what, if anything, could be done to alleviate this issue, as logically all rendering must be put on a halt if textures are being changed. One possibility could be to take inspiration from the concept of double-buffering, and load the texture data in an alternate texture buffer and swap all textures when ready - so the rendering, and thus client interactivity, never has to skip a beat. However, if the bottleneck occurs in the texture swapping, this would be pointless.
I've been getting better performance in the recent snapshots - it still takes 7+ seconds to load a resource pack for the first time, but subsequent changes now take more around 3 seconds.
OS X 10.7.5 running 1.5, this happens to me as well.