Fabric API "Breaking" In-Game Profiler
RacoonDog opened this issue ยท 5 comments
When running a bare-bones setup with only the Fabric Loader and Fabric API, 2 things are easily noticeable:
-
Any command entered (at least in singleplayer) will show up in the debug pie chart under
root.updateDisplay
(https://imgur.com/a/tJQYVkz) -
Exiting the game with the profiler active using the "X" button on windows will spam the logs with error messages relating to the tick profiler (https://imgur.com/0ghxxdk) (Already reported on #1521 )
First one is probably intended (client command is being profiled).
Second one is probably wontfix. Game should never be closed that way.
1, seems fine.
2, is this fabric causing it? Or does it happen in vanilla, I'm struggling to think how fabric is causing it?
First one is probably intended (client command is being profiled).
oh in that case its fine
though i think it should be in a separate category, something like root.updateDisplay.commands
cause it might clutter up root.updateDisplay
if someone adds profiling to something in there, like I was doing when I noticed it
2, is this fabric causing it? Or does it happen in vanilla, I'm struggling to think how fabric is causing it?
i haven't been able to replicate it without fabric, so im assuming it's caused by fabric
For the second one, I would guess this is some bad interaction with the shutdown of MinecraftClient?
The execution of (client) commands is ultimately done in response to an opengl event firing when the enter key is pressed.
This will normally happen in the render loop when the minecraft render system does a GLFW.glfwPollEvents() inside the render's profile context.
If you look at the registration of the key pressed callback GLFW.setKeyCallback() it says it can generate synthetic events when a window loses focus (e.g. the window is closed) for keys that are currently held down.
If you the look at MinecraftClient.close() there is a big list of things it does. With the render system (and presumably the profile context) being removed "long before" the window and its opengl callbacks get unregistered.
My guess is that within that gap between the render system getting closed and the opengl callbacks getting unregistered there is somewhere that key events are processed without the render profile context.
This causes the Fabric client command handling to barf when it tries to use the no longer existing context.
I don't know where/how exactly this might happen, but if the problem can be reproduced, it should be possible to find it with modified log statements that show the stacktrace?
The log for the second issue all mentions vanilla profiles, and does not mention client commands, which makes sense. @warjort I don't think that can cause client commands to be executed, since that requires at least pressing Open Chat, slash, and Enter in the exact order (or, potentially, F3+F4?)