Major framerate regression since 26.2 on some systems (OpenGL)

Thank you for helping us improve Minecraft! We saved your files:

My testing didn’t reveal any significant difference between these three versions (although my video settings and display dimensions are different than yours). Do you notice a significant difference in framerate in scenarios with more blocks or entities, similar to what I tested with?

This Google Drive folder shows my testing with these 3 versions, along with a backup of the world from 26.2 Snapshot 8.

Interesting. Yes, the framerate regression also occurs in more difficult scenarios. The flat world test is just for easier demonstration.

I’ve also tested it with your world and uploaded the results to this google drive folder.

You’ll notice that the difference is about 100 FPS in my case (~100 on pre-1 vs. ~200 on snapshot-8).

How strange. I’ll mark this as Plausible since you can repro reliably.

I'm not an OpenGL/rendering expert, so please correct me if I'm misreading any of this - but I compared the decompiled source (official mappings) between Pre-release 1 and Snapshot 8 and think I found something relevant.

com.mojang.blaze3d.opengl.GlCommandEncoder#submit() appears to create a GL fence sync object every frame, unconditionally, starting in Pre-release 1:

this.fences[this.currentSubmitSlot()] = GL33C.glFenceSync(GL_SYNC_GPU_COMMANDS_COMPLETE, 0);
this.currentSubmitIndex++;
[...]

In Snapshot 8, submit() seemed to only do:

this.transientMemory.rotate();

To test this theory, I wrote a small Fabric mixin that redirects just the GL33C.glFenceSync(int, int) call inside submit() to a no-op returning 0L, leaving the rest of the method untouched:

@Redirect(
    method = "submit",
    at = @At(value = "INVOKE", target = "Lorg/lwjgl/opengl/GL33C;glFenceSync(II)J"),
    remap = false
)
private long glFenceSyncNull(int a, int b) {
    return 0L;
}

With just that change, I get ~600 FPS again on my system, matching Snapshot 8 - and it seems to work the same way on the 26.2 Release jar, not just Pre-release 1. I also tried removing only the wait afterward (awaitSubmit) while keeping the glFenceSync() call, which made no difference - so as far as I can tell, it's specifically the glFenceSync() call that's costly here, not the waiting logic around it, though I can't really explain why from a driver/OpenGL perspective.

This may also relate to the profiler behavior noted in the original report — Snapshot 8 shows similar performance when the profiler is enabled — but that part is speculative.

I'm not confident this is the full picture, just sharing in case it helps narrow things down.

Performance regression in 26.2 compared to 26.1 (higher frame times and lower FPS on multiple systems)

I've been comparing Java Edition 26.1 and 26.2 because I noticed a significant FPS drop after updating. Before reporting it, I tried to rule out problems with my own PC by testing different hardware, launchers and rendering backends.

Test conditions

For every comparison I used:

• Same world

• Same location

• Same graphics settings

• Same render distance

• Unlimited FPS

• Vanilla Minecraft (no Fabric, Forge, Sodium or other mods)

I also tested with:

• Official Minecraft Launcher

• Prism Launcher

The results were the same across all launchers.

Desktop PC

Hardware

• Ryzen 7 5700X3D

• RTX 4060

• Windows 11

Results

26.1

• Around 400–500 FPS

• Frame time around 2–3 ms

26.2

• Around 200–350 FPS

• Frame time increases noticeably

The game still feels smooth (no constant stuttering), but the maximum FPS is much lower.

Switching back to 26.1 immediately restores the previous performance.

Laptop

Hardware

• Lenovo IdeaPad Gaming

• Intel Core i5 11th Gen

• GTX 1650

Results

26.1

• Around 150–180 FPS

• Frame time around 3 ms

26.2

• Around 140–170 FPS

• Frame time around 4–5 ms

The FPS loss is smaller than on the desktop but still reproducible.

Rendering backend observations

The new renderer selector offers:

• Default

• Prefer OpenGL

• Vulkan (Experimental)

I noticed something unexpected.

Default

F3 reports OpenGL.

Prefer OpenGL

F3 reports exactly the same OpenGL version and renderer as Default.

However, manually selecting Prefer OpenGL consistently improves performance by about 10–20 FPS compared to leaving it on Default.

Since both modes report the same OpenGL backend, I expected identical performance.

Vulkan

Using Vulkan (Experimental):

• Performance improves further.

• Average FPS becomes close to what I get in 26.1.

• However, chunk loading introduces noticeable FPS drops/stutters that are not present with OpenGL.

Summary

From my testing:

• The regression is reproducible on two completely different systems.

• The regression is present across different launchers.

• Returning to 26.1 immediately restores the previous FPS.

• Frame time is consistently higher in 26.2.

• "Default" performs worse than "Prefer OpenGL", even though both appear to use the same OpenGL backend according to F3.

• Vulkan improves average FPS but introduces chunk loading stutters.

This makes me think there may be a performance regression in 26.2 and possibly an issue with how the Default renderer path behaves compared to manually selecting OpenGL.

I hope these tests help identify the cause.

Thank you for your report!
After consideration, the issue is being closed as Won't Fix.

Please note that this is not the same as Working as Intended, as this bug report correctly describes behavior in the game that might not be the intended or desirable behavior, but it will not be fixed right now. Sometimes, this is because the issue reported is minor and/or impossible to change without large architectural changes to the code base.

Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support (Technical Issues) – 📧 Microsoft Support (Account Issues)
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki