MC-64581Game freezes a couple of seconds when changing mipmap level parameter
Mipmaps can take a while to recalculate when adjusting the Mipmap Levels slider in the video settings. Because they are recalculated as soon as you move the slider to a new position, the user interface becomes unresponsive, making it very difficult to set them to a specific level. On slower computers, the slider will sometimes jump back to the previous setting, or another setting entirely, because the mouse detection becomes erratic due to the lag.
Suggested solution:
Recalculate the mipmaps once the user releases the mouse button, rather than when they click on or drag the slider.
Linked Issues
is duplicated by4
- Fixed
Sylvain Garden![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png)
[Mojang] Nathan Adams- 21
- 14
- Confirmed
- gui interface mipmap performance rendering settings
14w31a - 18w50a
14w31a 1.8.3 1.8.7 1.8.9 16w05a 1.9 1.9.1-pre3 1.9.4 1.10.2 16w40a 16w44a 1.11 16w50a 1.11.2 17w06a 1.12.1 1.12.2 17w43a 17w43b 17w45b 17w46a 17w47a 17w47b 17w48a 17w49a 17w50a 18w02a 18w06a 18w20c 1.13-pre1 1.13-pre3 1.13 18w30b 1.13.1 1.13.2 18w45a 18w46a 18w48a 18w48b 18w49a 18w50a- 19w08a
Created Issue:
game freezes a couple of seconds when changing mimap level parameter
game freezes during several seconds when changing the mipmap levels parameter
Environment
win 7, java 1.7.0 64 bit (same on xp 32 bits and linux 32 by the way)
is duplicated by
is duplicated by
is duplicated by
Why should it crash? It rather really unnecessary to do this when the slider changes, because this creates these unwanted situations and I don't quite understand what is your problem?
You have seriously no reason to defend that and say it is good the way it is now
Or aren't you affected by the lag, if so it is more than unsocial to defend that position!
![[Mod] Torabi](../../../data/assets/gravatar/torabi.png){kind=small}
game freezes during several seconds when changing the mipmap levels parameter
Mipmaps can take a while to recalculate when adjusting the Mipmap Levels slider in the video settings. Because they are recalculated as soon as you move the slider to a new position, the user interface becomes unresponsive, making it very difficult to set them to a specific level. On slower computers, the slider will sometimes jump back to the previous setting, or another setting entirely, because the mouse detection becomes erratic due to the lag.
Suggested solution:
Recalculate the mipmaps once the user releases the mouse button, rather than when they click on or drag the slider.
is duplicated by
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
win 7, java 1.7.0 64 bit (same on xp 32 bits and linux 32 by the way)
Game freezes a couple of seconds when changing mipmap level parameter
[Mojang] Nathan Adams![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
relates to
Could this please be resolved as a duplicate of MC-64581.
It's calculating the mipmaps.
it still should calculate it when you click done, if not, when you just pass from mipmap 1 to 4 you are recalculating it 3 times, or vice-versa
Confirmed for:
Like pabloherrerapalacia says when you set it from 4 to 1 or from 1 to 4 it calculates it for every number even if you slide it directly without stopping
Lag is never intended. Should be reopened or "Won't Fix".
Nice now the resolution is ever worse than before...
OPEN THIS!
This is a bug, you sometimes can't even turn it off, because when you click on the left side it moves first to "Off", and then to 3 just because this lag is delaying everything!!
Marcono, shouting won't help.
@Marcono1234
While it is very annoying, it's just lag. It's making a large change to the rendering system, it takes time to calculate. The problem you are describing is happening because you are moving your mouse during the lag spike, and it thinks you are still pressing the button. Just don't move the mouse and it will work fine.
Are you serious Isaac King?
That is like saying (maybe this is a little bit too extreme, but it shows the problem):
Many children in developing countries have to search in the trash of industry nations to earn money. So the should just stop searching in the trash.What the hell?The solution would be even more easier, the industry nations have to stop sending their trash to these countries just because it is cheaper.Same here. The problem could be solved in 5 minutes. Cut the code which gets executed when the slider changes and paste it to the click "Done" event. Solved... (and maybe add a text box which says that it may lag now because the game has to render everything again and no one would ever have a problem with it).
So your solution is to just change when the lag happens? Meaning that if you make multiple changes, it could lag enough to crash the game? I don't see how that is better at all. Also, your analogy makes no sense.
Forget what I said, I am just saying this is not the optimal solution for it. And they should really think about reopening this report.
And please tell me why you thing it is good this way? In my opinion the current situation is relly no great.
I didn't say I like the current situation, I'm just saying that your way of "fixing" it would really make it worse. I would like it if it were fixed, but lag can't necessarily be fixed like other bugs, there are hard limits to how fast a computer can calculate something. Kumasasa, would you mind explaining why you think this won't be fixed?
The lag itself is most likely unfixable, unless someone comes up with a cheaper algorithm to perform the calculations. Certain operations simply require a certain amount of processing power. As for why it was changed so that it immediately recalculated the mipmaps, rather than when you click done, I'm not sure. Presumably to fix some other bug, one that was difficult to track down. Yes, it's not really ideal, but there are a lot of strange sacrifices Mojang has had to make in the past for compatibility's sake, especially when it comes to rendering. Sometimes graphics cards and drivers just plain don't make any sense - you have to do something the wrong way to make it work on some hardware.
Regardless, throwing a tantrum, shouting orders, and hyperbole aren't the way to get things done around here, or anywhere else. If anything, it will make people determined not to give you what you want, just to discourage you from acting that way. Sometimes you just aren't going to get what you want. Sometimes you just have to be patient. But you should always try to treat others how you want to be treated.
Well alright I am sorry. I behaved wrong I know, but I still really don't understand the reasons why it can't be done when you click "Done".
One reason why I am sometimes so angry here is that I have to comment multiple times to a report reopened or something similar. I don't even get a thank you when I state that a link is missing or a link is wrong and the attitude I get from the developers here is mostly the "We don't care" attitude. I mean I have 5 pages of issues I am watching or which I reported. You don't really know how much work that is if every version they get closed because of awaiting response or because since their creation no one confirmed them. And some of them are major issues like
MC-68458which shows that there is a major issue in the game with calculating string length.IMHO, the primary problem of the bad user experience is that the heavy computation should be triggered when the user releases the mouse button, not on every mouse move event as it makes this slider very difficult to manipulate even on a powerful platform.
It's as simple as that. I regret I didn't describe this bug in this way.
Marcono1234, I think you seriously underestimate the sheer amount of work necessary to maintain the bug tracker. The developers and moderators can be terse sometimes because they have so much to do, and spending extra time to explain every action, or respond to every comment would mean getting that much less work done. 5 pages of issues? People file twice that many new ones on average every week. So it's not that we or the developers don't care, it's that we're spread a little thin sometimes.
As for why the mipmaps are calculated immediately, rather than on clicking done, my guess is that trying to apply them at the same time as some other video setting changes caused a bug on some graphics cards. So making it apply immediately prevents that kind of problem. However, it's probably possible to move the recalculations to when the player stops moving the slider, rather than as soon as they start moving it. Fortunately, we can fix this report up and reopen it.
I've updated the ticket. No guarantees that the behavior will change, but at least now it's something that the developers might consider reasonable.
Well thank you
Reproduced in 1.8.7.
------
@KingSupernova
It would only do the calculation once, using the final value (and not do any recalculations if there was no change). So no, it wouldn't make the lag worse; it would just do the same amount of lag as 1 change, but only once.
The reason why the behavior is bad is not only because of the lag, but because moving the mouse during the lag causes the value to change again, leading to more lag and having the value unchanged. If anything, that part should be fixed.
Resource packs successfully do this delayed recalculation – it doesn't change everything immediately when you add or remove one; it waits until you exit the screen.
However, it doesn't seem like it would work here.
Due to the way that settings work, it's probably not possible to just do that. (The 'GuiOptionsRowList' and 'GameSettings' have no idea what a 'Done button' is). They simply update the setting, and if something needs updating, update it.
That's called whenever the mouse is dragged over the slider and the mouse is down, which isn't an issue most of the time but is when you're recalculating everything. (Of course, it does in fact only update the value if the value changed, which does mean that the lag isn't as bad as it could be
)
@[Mod] Torabi
Indeed, that's the best solution. There still would be lag, but it wouldn't be double-lag nor would it lead to accidental choosing.
However, the way the code is, it seems hard to do that as well. The slider works by setting the setting value and then updating its displayed text with the value from the setting (getting the display string is done in GameSettings.java), so if changing the actual value is delayed, it doesn't update.
It would be possible to move the formatting code into the slider itself, but that seems suboptimal. However, it's still a better solution than what's currently happening.
I'd write up some code for that, but... MCP's values for the settings are horrible and I don't want to deal with them.
This comment turned out way longer than I expected, and probably is a little confusing; sorry.
Still in 16w05a
FIXED IN THE LATEST VERSION 1.9
Please close this thread.
Anybody still able to reproduce in 1.9?
Still there
Confirmed in 1.9.1-pre3.
Confirmed in 1.9.4.
The cause of the issue is that the sound engine is being restarted as soon as the Mipmap slider is moved. This can be seen easily if the Launcher window is visible.
Try the following:
[11:54:47] [Client thread/INFO]: SoundSystem shutting down...
[11:54:47] [Client thread/WARN]: Author: Paul Lamb, www.paulscode.com
[11:54:47] [Sound Library Loader/INFO]: Starting up SoundSystem...
[11:54:47] [Thread-10/INFO]: Initializing LWJGL OpenAL
[11:54:47] [Thread-10/INFO]: (The LWJGL binding of OpenAL. For more information, see http://www.lwjgl.org)
[11:54:47] [Thread-10/INFO]: OpenAL initialized.
[11:54:48] [Sound Library Loader/INFO]: Sound engine started
[11:54:48] [Client thread/INFO]: Created: 1024x512 textures-atlas
Moving the slider should NOT cause the sound driver to restart.
The texture atlas is also being recreated. This should not be happening either. This should happen when the Done button is clicked, not when the slider is moved.
This is still an issue with 1.10.2
Adjusting the slider at all causes the client to do a "reload" sequence. As stated previously, the reloading should not be executing until the "Done" button is clicked, at which time all changes should be written to the configuration file, and then any reloading by executed. As it is currently, changes made to the video section for the MIPMAP setting are not saved before the reload happens. This causes changes to be lost if the client crashes during the reload process.
Confirmed in 16w44a
Confirmed in 1.11 and 1.12
Confirmed for 1.13.1.
Whilst it still may take a while to apply (hopefully a bit quicker though), it will show a loading screen and not completely freeze the client.