Lag spikes when accessing or closing inventory, chests, menus, chat, etc. (Wayland)

Minecraft was originally built for Java 8. You're running a newer version. Force Minecraft to use this version as it renders no issues for me. https://www.archlinux.org/packages/extra/x86_64/jre8-openjdk/

Thank you for your hint. But it does not resolve the issue. I switched to Java 8 and the bug is still present. (See second screenshot.)

I could trace the issue back to Wayland. Somehow Gnome switched from Xorg to Wayland and I had no issues otherwise. This results is:

Xorg: Works as intended.

Wayland: Lagging as described above.

The issue could have something to do with Wayland, hope this helps anybody in the future.

I'm also using GNOME on Wayland and can confirm. This only seems to affect fullscreen mode, so I thought, a borderless windowed "fullscreen" (which many games offer as an option, but not Minecraft) would probably be unaffected, too. I tried putting the game window in such a state remotely, which didn't help as it seems GNOME or Xwayland detects such trials and puts those windows in the "real" fullscreen mode, or something. Except, if the window is made borderless before resizing it (then made borderless again, because otherwise the resize won't apply, not sure why), the problem magically goes away. The window becomes seemingly fullscreen, although Minecraft itself doesn't realize that (tbh it doesn't when using the wm's (i3, etc.) built-in fullscreen feature, either.) Toggling fullscreen in-game once does nothing except make the game realize that it's enabled, and after that it toggles between a broken fullscreen with the top bar visible ("windowed") and a normal fullscreen; windowed is broken, but fullscreen stays unaffected by this issue. Here's the Python script I used to pull this off (I have no idea why this works):

#!/usr/bin/env python

import sys
import os
from gi.repository import GdkX11

display = GdkX11.X11Display.open(os.environ["DISPLAY"])
window = GdkX11.X11Window.foreign_new_for_display(display, int(sys.argv[1]))
geometry = display.get_monitor_at_window(window).get_geometry()
window.set_decorations(0)
window.move_resize(geometry.x, geometry.y, geometry.width, geometry.height)
window.set_decorations(0)

This expects the window id of Minecraft as an argument. You can find that out using, for example, xdotool as shown here:

xdotool search -name '^Minecraft\*? [0-9]+\.[0-9]+\.[0-9]+'

Minecraft doesn't even start on a pure wayland system (swaywm, -Dxwayland=disabled), MCL-13763. MC-178267 is probably related to xwayland implementation. I think this causes the observed performance hit.

libcef.so is a pure X11 library, even though CEF supports wayland. It has to be compiled differently. See last comment there. I think there should be another binary, that works on wayland alone.

Xorg is expected to go into hard maintentance mode.

I just want to make you all aware that, from the launcher developer's point of view, Wayland is not supported. Please have a look at developer comments on MCL-13763 and MCL-15341.

This BUG problem still exists in 1.17.1. When pressing F1 to close the GUI, FPS will improve a lot

Slightly better with chat in 21w39a, but still a problem in other cases

I have been experiencing regular lag spikes while using 1.18.1 on a MacBook Pro (14-inch, 2021) running macOS 12.0.1 Monterey.

See the performance metrics I have attached. I reset all video settings to default before generating them.

The lag spikes appear as very tall red lines in the frame time graph. They seem to happen every 5-10 seconds and become more frequent over time. Varying the proximity to mobs or surrounding terrain has no effect. They even appear while standing still or running in a straight line in a fresh superflat creative world.

Frame rates seem to be unaffected, as I can usually get 100+ fps on this MacBook. I have tried disabling macOS Location Services, running the test on Ethernet vs. Wi-Fi, installing OptiFine, and using the default 8 chunk render and simulation distance. Nothing has helped.

Some actions that are guaranteed to generate a lag spike within a few seconds include turning in a different direction or activating the Chat window.

In theory this can be solved by porting to Wayland. Since the developers treat MC-92393 as a feature request, I've made a feedback request. Upvote it so the developers can see.