After the transition to GDK on Windows (starting in 1.21.120), mouse camera movement in Minecraft Bedrock is no longer processed smoothly.
Symptoms:
Mouse input feels jittery, uneven, or quantized, even though the game maintains stable high framerate (300–800+ FPS).
Severity increases in server environments, entity-heavy areas, or during chunk loading. (Not really as much now its just constant).
Keyboard input, controller input, and touch input remain smooth.
Clicking actions (e.g., opening chests, doors, combat) can be harder to aim onto.
Issue occurs on multiple mice and systems, independent of DPI, polling rate, V-Sync, frame limit, or graphics settings.
GDK Issue Clearly Being Ignored Due To Lack Of Care Of The Game Essentially leaving the game to die.
Steps to Reproduce:
Launch Minecraft Bedrock on Windows (GDK-based versions 1.21.120+).
Set a high refresh rate (144–240 Hz) and ensure FPS is stable.
Enter a world or server.
Move the camera continuously with the mouse, especially while chunks/entities are loading.
Have an actual trained eye that actually sees lag. Hopefully you can find someone at Mojang.
Also this had 40 votes on other reports and the only way people are going to find this is by reporting the same thing.
Expected Result:
Camera movement using the mouse should be smooth and consistent at all times while framerate is stable, matching pre-GDK Bedrock behavior.
Actual Result:
Mouse camera movement is stuttery and laggy at very high FPS. Severity is sometimes context-dependent; the camera is constantly laggy. FPS counters remain stable. Also with v sync off and legit testing every single setting in all official software I have.
Additional Notes:
Downgrading to Bedrock 1.21.114 resolves the issue.
Issue started immediately after GDK migration.
Touchscreen and controller input are unaffected.
Recording with OBS/ShadowPlay sometimes masks the issue but does not resolve it, obviously.
This is reproducible on high-end systems with no background load.
Linked issues
Comments 3
This is an expected response. I understand clearly that Mojang doesn’t like duplicate reports. But that only makes sense to be bannable in certain contexts. I think making a duplicate issue after you failed to update the current ones version (Aka, your job). Fail to give any update. Fail to tell us you are going to prioritize this. Mojang failing to have fixed this after 3 months of people stating this and giving information about a game breaking bug is much worse than creating a duplicate report. Making a duplicate report is much better 😀 . Also it would be nice to not be banned, so people who bought the game can report bugs- which is intelligent. Maybe give me a break instead of Mojang, who didn’t fix something for three months. Making the game unplayable. Sorry, a duplicate report is too far.
Here is the friendlier one.
I understand the policy regarding duplicate reports, and I’m not trying to ignore it.
However, from a user perspective, the frustration comes from the fact that this issue has been reported repeatedly for months, with substantial technical detail, votes, and confirmations — yet there has been no visible update, prioritization, or acknowledgment of progress.
When an issue that makes the game effectively unplayable for mouse users remains unresolved for this long, and existing reports are not updated with status or communication, it creates the impression that the problem is being deprioritized or overlooked.
Duplicate reports are not created out of disregard for the rules, but out of a lack of feedback and visibility on critical issues. Clear updates or confirmation that the issue is actively being worked on would likely prevent most duplicates.
I’m not asking for special treatment — only for transparency and acknowledgment that this regression is known, reproducible, and being addressed.
Oops, I guess I just made a duplicate response. 😘
Thank you!
As I have already told you, do not create any more duplicate reports of this issue. Continuing to do so will result in being banned from the bug tracker.