mojira.dev
MC-62177

Lag in 14w29b, potentially caused by multi-threading

Despite claims in the 14w29 snapshots, the lag issue persists. The world seems to generate notably faster than before, but this has not impacted the lag for me. Every couple seconds I experience lag-related freezes that render the game impossible to play. I was able to remedy the issue by reducing the render distance below 10 chunks (anything 10 or above had no noticeable impact), but my computer has never had an issue running at maximum settings with 30-40 fps.
Lighting and other graphical settings had no impact on framerate.

Related issues

Comments

galaxy_2alex
Steve Blouin

Upgraded from 14w28b (which had a framerate bug, supposedly) and my frame rate slightly decreased in 14w29b! I thought that issue was fixed.

galaxy_2alex

Not for everyone, as you can see in the Strawpoll

Joona-M Heikkilä

I didn't have time to test this, the A -> B transfer brought too much change and too fast.

On 14w29b using VBOs lovered my FPS from 28 -> 16 while, 0 chunk updates view distance maximum, on server side and client, all chunks where loaded.

Bob Saggot

Mouse stuttering might be caused by game trying to use all CPU power (in my case at least). Setting priority in Task Manager to below normal pretty much fixes the issue, but I can't tell if it affects performance of the game. Chunks are still loading faster than they did before 29b.

Gerottinho

In my computer, everything related to block updates are laggy. A water for example, takes 30s to spread, a tnt will display the animation normally, then will disappear and 30s later will explode (particle effect and deleting blocks)
This is the worst lag, IMPOSSIBLE to play.
Please don't do that mojang D:

jonathan2520

It (or just one of the performance issues) seems to be MC-61451, even though it was claimed to be fixed and eagerly closed. Let me quote it:

The only reason I can find for this is when you press F3 in the upper part the C (which i suppose is chunks) says C: 3400/8464 and that number kept on rising. For me it usually stays in the 800s/8464.

To make it most obvious, disable Advanced OpenGL. Create a new world or load an existing one. Don't move or turn yet. Open the F3 display. Wait for C (or C+O with Advanced OpenGL) to stabilize. Turn around little by little, waiting for C to stabilize again. Notice it's only ever going up. Once you've looked in every direction, apparently the game is drawing everything all around you, not culling sections that are out of view. If Advanced OpenGL is enabled, C is pretty stable, but O is ever increasing, which also slows things down.

anubis1101

Actually, Advanced OpenGL seemed to improve things slightly for me, as did VBOs. It was very slight though, so it may have been coincidence.

michael

Please don't use the bug tracker as a discussion board.

George Hayes

Not sure if it is all lag or bad timing. The biggest issue I notice is the doors sometimes makes the sound and it is a second before the graphics catch up. If I move around a good size town it will happen. Once I stay in an area possibly a chunk it doesn't happen again.

It tends to say that the engine is giving priority to loading the chunks when moving around more than it is to what should be immediate events.

jonathan2520

@unknown: That's MC-62166, which gets enough flak as it stands. You'd think those 128 duplicates would cover every imaginable search term.

George Hayes

jonathan2520: I am betting the two issues are actually related. Since they went to multi-threading if they locked the threads updating some data and force the primary thread to wait for the second to complete that would cause such an issue. It would cause the lag some are complaining about along with what I am discussing.

In this case I suspect the primary thread is waiting on the one dumping the Pushing the VBO. Vertex buffer objects are usually meant for objects that are not changing greatly. However, in this case the game has to update it continually because you can make block changes. You would get more lag if you run a video card with a more narrow bandwidth and then get issues like the blocks not going away and so on. The smaller issues like the door would be only apparent for those running a faster system.

When I say changing I mean adding and removing vertices.

But it could be a number of timing issues with multi-threading that could cause similar symptoms. After all I haven't taken the time to go through their code. I have my own I am working on. I primarily looked at it because my nephew had issues lately so decided to take a look at what was going on.

anubis1101

michael

Unconfirmed

Minecraft 14w29b

Retrieved