[MC-12257] Texture changing/reloading causes client-side freezing for 7-15 seconds Created: 17/Mar/13  Updated: 07/Sep/15  Resolved: 23/Oct/13

Status: Resolved
Project: Minecraft: Java Edition
Component/s: None
Affects Version/s: Minecraft 1.5, Minecraft 1.5.1, Minecraft 1.5.2, Snapshot 13w19a, Snapshot 13w21a, Snapshot 13w25a, Snapshot 13w25b, Snapshot 13w25c, Minecraft 1.6, Minecraft 1.6.1, Minecraft 1.6.2, Minecraft 13w37a, Minecraft 13w37b, Minecraft 1.7
Fix Version/s: None

Type: Bug
Reporter: WolfieMario Assignee: Unassigned
Resolution: Works As Intended Votes: 2
Labels: freeze, lag, menu, pack, resource-pack, server, texture
Environment:

Windows 7 64-bit Professional
4.00GB (3.75GB Usable) RAM
3.00 GHz AMD Athlon(tm) II X2 250 Processor
124GB Unused Hard Drive Space
64-bit Java 1.7.0_11


Issue Links:
Duplicate
is duplicated by MC-18282 Takes very long time to change resour... Resolved
Confirmation Status: Unconfirmed

 Description   

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.



 Comments   
Comment by Dylan Rivers [ 18/Jun/13 ]

I think this cannot be fixed as it takes time to change all the UI which you see on that screen, but it is better with new resource packs

Comment by WolfieMario [ 18/Jun/13 ]

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.

Comment by WolfieMario [ 12/May/13 ]

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.txt

That'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.

Comment by Evan McClane [ 18/Mar/13 ]

OS X 10.7.5 running 1.5, this happens to me as well.

Generated at Sun Jan 12 12:30:19 UTC 2025 using Jira 9.12.2#9120002-sha1:301bf498dd45d800842af0b84230f1bb58606c13.