Rafael S. M. S.
- rafaelsms
- JIRAUSER517732
- America/Sao_Paulo
- Yes
- No
MCL-14499
MC-257225
Issue
Ran "minecraft-launcher" binary on the terminal and it immediately returned without printing anything or showing anything on screen.
I searched the internet for some minutes and encountered someone saying that it was a missing library (libXScrnSaver on fedora). Don't know how this guy knew it was this exacly library it was missing because my launcher said nothing.
I am using Fedora 30 (tested Gnome on X11 and on Wayland) on an old pc at my mother's. I installed OpenJDK 1.8, downloaded and extracted the most recent minecraft-launcher for generic linux on minecraft.net website.
Steps to reproduce:
1. Open terminal on the extracted minecraft-launcher folder
2. Execute minecraft-launcher binary
3. It automatically closes without any information:
$ ./minecraft-launcher
}}{{$What I expected
Any visual indication that something (with a name, such as libxscrnsaver or a file name that I can search on fedora's packages) is missing if it is absolutely necessary. If it isn't, I expected the launcher to work normally without this dependency.
I did not find anything about dependencies here on bugs.mojang.com, hopefully this is not a duplicate. Thank you!
Issue
Ran "minecraft-launcher" binary on the terminal and it immediately returned without printing anything or showing anything on screen.
I searched the internet for some minutes and encountered someone saying that it was a missing library (libXScrnSaver on fedora). Don't know how this guy knew it was this exacly library it was missing because my launcher said nothing.
I am using Fedora 30 (tested Gnome on X11 and on Wayland) on an old pc at my mother's. I installed OpenJDK 1.8, downloaded and extracted the most recent minecraft-launcher for generic linux on minecraft.net website.
Steps to reproduce:
1. Open terminal on the extracted minecraft-launcher folder
2. Execute minecraft-launcher binary
3. It automatically closes without any information:
$ ./minecraft-launcher
$
What I expected
Any visual indication that something (with a name, such as libxscrnsaver or a file name that I can search on fedora's packages) is missing if it is absolutely necessary. If it isn't, I expected the launcher to work normally without this dependency.
I did not find anything about dependencies here on bugs.mojang.com, hopefully this is not a duplicate. Thank you!
High allocation rates (more than 800 MB/s consistently, peaking 2200MB/s sometimes, for many seconds, a few minutes) are noticeable
- Open the game
- Load world
- High allocation rate for many seconds (a minute or so?)
- Quit world without closing the game
- Load world
- High allocation rate for almost 10 seconds (not much of an issue)
- Quit world
It is pretty annoying as the CPU is highly utilized. It happened both in 22w44a generated worlds and converted 1.19 worlds.
MacOS Ventura (Air M2), using default launcher (bundled JDK), default launcher flags except for max memory usage, set to 4GB, no mods whatsoever
High allocation rates (more than 800 MB/s consistently, peaking 2200MB/s sometimes, for many seconds, a few minutes) are noticeable
- Open the game
- Load world
- High allocation rate for many seconds (a minute or so?)
- Quit world without closing the game
- Load world
- High allocation rate for almost 10 seconds (not much of an issue)
- Quit world
It is pretty annoying as the CPU is highly utilized. It happened both in 22w44a generated worlds and converted 1.19 worlds.
It seems this is more noticeable when battery saver mode only. Allocation rate was 000MB/s probably because it was on its first seconds, but I could see GC running a few times. This did not happen for a minute, but for 15 seconds as expected. Not sure if this could be improved or if the solution is indeed turn of battery saver when playing or at least when opening Minecraft for the first time.
High allocation rates
(more than 800 MB/s consistently, peaking 2200MB/s sometimes, for many seconds, a few minutes) are noticeable
- Open the game
- Load world
- High allocation rate for many seconds (a minute or so?)
- Quit world without closing the game
- Load world
- High allocation rate for almost 10 seconds (not much of an issue)
- Quit world
It is pretty annoying as the CPU is highly utilized. It happened both in 22w44a generated worlds and converted 1.19 worlds.
It seems this is more noticeable when battery saver mode only. Allocation rate was 000MB/s probably because it was on its first seconds, but I could see GC running a few times. This did not happen for a minute, but for 15 seconds as expected. Not sure if this could be improved or if the solution is indeed turn of battery saver when playing or at least when opening Minecraft for the first time.
High allocation rates are noticeable when opening a single player world for the first time after launching the game. Second runs do not have this issue.
- Open the game
- Load world
- High allocation rate for many seconds (a minute or so?)
- Quit world without closing the game
- Load world
- High allocation rate for almost 10 seconds (not much of an issue)
- Quit world
It is pretty annoying as the CPU is highly utilized. It happened both in 22w44a generated worlds and converted 1.19 worlds.
It seems this is more noticeable when battery saver mode is on on macos. Allocation rate was 000MB/s probably because it was on its first seconds, but I could see GC running a few times. This did not happen for a minute, but for 15 seconds as expected. Not sure if this could be improved or if the solution is indeed turn of battery saver when playing or at least when opening Minecraft for the first time.
High allocation rates are noticeable when opening a single player world for the first time after launching the game. Second runs do not have this issue.
- Open the game
- Load world
- High allocation rate for many seconds (a minute or so?)
- Quit world without closing the game
- Load world
- High allocation rate for almost 10 seconds (not much of an issue)
- Quit world
It is pretty annoying as the CPU is highly utilized. It happened both in 22w44a generated worlds and converted 1.19 worlds.
It seems this is more noticeable when battery saver mode is on on mac
os. Allocation rate was 000MB/s probably because it was on its first seconds, but I could see GC running a few times. This did not happen for a minute, but for 15 seconds as expected.Not sure if this could be improved or if the solution is indeed turn of battery saver when playing or at least when opening Minecraft for the first time.
High allocation rates are noticeable when opening a single player world for the first time after launching the game. Second runs do not have this issue.
Steps to reproduce:
- Open the game
- Load world
- High allocation rate for many seconds (a minute or so?)
- Quit world without closing the game
- Load world
- High allocation rate for almost 10 seconds (not much of an issue)
- Quit world
It is pretty annoying as the CPU is highly utilized. It happened both in 22w44a generated worlds and converted 1.19 worlds. It happens on 1.19.2 as well.
- Issue demonstration video (more noticeable, battery saver mode)
- Issue demonstration video (still present, normal performance mode)
It seems this is more noticeable when battery saver mode is on on macOS. Allocation rate was 000MB/s probably because it was on its first seconds, but I could see GC running a few times. This did not happen for a minute, but for 15 seconds as expected.
Not sure if this could be improved by moving somethings to the init phase of the game instead of leaving it to when the world is loading.
High allocation rates are noticeable when opening a single player world for the first time after launching the game. Second runs do not have this issue.
Steps to reproduce:
- Open the game
- Load world
- High allocation rate for many seconds (a minute or so?)
- Quit world without closing the game
- Load world
- High allocation rate for almost 10 seconds (not much of an issue)
- Quit world
It is pretty annoying as the CPU is highly utilized. It happened both in 22w44a generated worlds and converted 1.19 worlds. It happens on 1.19.2 as well.
- Issue demonstration video (more noticeable, battery saver mode)
- Issue demonstration video (still present, normal performance mode)
It seems this is more noticeable when battery saver mode is on on macOS. Allocation rate was 000MB/s probably because it was on its first seconds, but I could see GC running a few times. This did not happen for a minute, but for 15 seconds
as expected.Not sure if this could be improved by moving somethings to the init phase of the game instead of leaving it to when the world is loading.
High allocation rates are noticeable when opening a single player world for the first time after launching the game. Second runs do not have this issue.
Steps to reproduce:
- Open the game
- Load world
- High allocation rate for many seconds (a minute or so?)
- Quit world without closing the game
- Load world
- High allocation rate for almost 10 seconds (not much of an issue)
- Quit world
It is pretty annoying as the CPU is highly utilized. It happened both in 22w44a generated worlds and converted 1.19 worlds. It happens on 1.19.2 as well.
- Issue demonstration video (more noticeable, battery saver mode)
- Issue demonstration video (still present, normal performance mode)
It seems this is more noticeable when battery saver mode is on on macOS. Allocation rate was 000MB/s probably because it was on its first seconds, but I could see GC running a few times. This did not happen for a minute, but for 15 seconds. Still happens, as opening the world again afterwards takes way less time (3-4 seconds).
Not sure if this could be improved by moving somethings to the init phase of the game instead of leaving it to when the world is loading.
High allocation rates are noticeable when opening a single player world for the first time after launching the game. Second runs do not have this issue.
Steps to reproduce:
- Open the game
- Load world
- High allocation rate for many seconds (a
minute or so?)- Quit world without closing the game
- Load world
- High allocation rate for a
lmost 10seconds (not much of an issue)- Quit world
It is pretty annoying as the CPU is highly utilized. It happened both in 22w44a generated worlds and converted 1.19 worlds. It happens on 1.19.2 as well.
- Issue demonstration video (more noticeable, battery saver mode)
- Issue demonstration video (still present, normal performance mode)
It seems this is more noticeable when battery saver mode is on on macOS. Allocation rate was 000MB/s probably because it was on its first seconds, but I could see GC running a few times. This did not happen for a minute, but for 15 seconds. Still happens, as opening the world again afterwards takes way less time (3-4 seconds).
Not sure if this could be improved by moving somethings to the init phase of the game instead of leaving it to when the world is loading.
High allocation rates are noticeable when opening a single player world for the first time after launching the game. Second runs do not have this issue.
Steps to reproduce:
- Open the game
- Load world
- High allocation rate for many seconds (annoying on old hardware?/battery saver mode)
- Quit world without closing the game
- Load world
- High allocation rate for a few seconds (not much of an issue)
- Quit world
It is pretty annoying as the CPU is highly utilized. It happened both in 22w44a generated worlds and converted 1.19 worlds. It happens on 1.19.2 as well.
- Issue demonstration video (more noticeable, battery saver mode)
- Issue demonstration video (still present, normal performance mode)
It seems this is more noticeable when battery saver mode is on on macOS. Allocation rate was 000MB/s probably because it was on its first seconds, but I could see GC running a few times. This did not happen for a minute, but for 15 seconds. Still happens, as opening the world again afterwards takes way less time (3-4 seconds).
Not sure if this could be improved by moving somethings to the init phase of the game instead of leaving it to when the world is loading.
High allocation rate after starting the game
High allocation rates are noticeable when opening a single player world for the first time after launching the game. Second runs do not have this issue.
Steps to reproduce:
- Open the game
- Load world
- High allocation rate for many seconds (annoying on old hardware?/battery saver mode)
- Quit world without closing the game
- Load world
- High allocation rate for a few seconds (not much of an issue)
- Quit world
It is pretty annoying as the CPU is highly utilized. It happened both in 22w44a generated worlds and converted 1.19 worlds. It happens on 1.19.2 as well.
- Issue demonstration video (more noticeable, battery saver mode)
- Issue demonstration video (still present, normal performance mode)
It seems this is more noticeable when battery saver mode is on on macOS. Allocation rate was 000MB/s probably because it was on its first seconds, but I could see GC running a few times. This did not happen for a minute, but for 15 seconds. Still happens, as opening the world again afterwards takes way less time (3-4 seconds).
Not sure if this could be improved by moving somethings to the init phase of the game instead of leaving it to when the world is loading.
High allocation rates are noticeable when opening a single player world for the first time after launching the game. Second runs do not have this issue.
Steps to reproduce:
- Open the game
- Load world
- High allocation rate for many seconds (annoying on old hardware?/battery saver mode)
- Quit world without closing the game
- Load world
- High allocation rate for a few seconds (not much of an issue)
- Quit world
It is pretty annoying as the CPU is highly utilized. It happened both in 22w44a generated worlds and converted 1.19 worlds. It happens on 1.19.2 as well.
- Issue demonstration video (more noticeable, battery saver mode)
- Issue demonstration video (still present, normal performance mode)
It seems this is more noticeable when battery saver mode is on on macOS. Allocation rate was 000MB/s probably because it was on its first seconds, but I could see GC running a few times. This did not happen for a minute, but for 15 seconds. Still happens, as opening the world again afterwards takes way less time (3-4 seconds).
Not sure if this could be improved by moving somethings to the init phase of the game instead of leaving it to when the world is loading.
It happens when joining servers, thus it is probably related to the client side.
High allocation rates are noticeable when opening a single player world for the first time after launching the game. Second runs do not have this issue.
Steps to reproduce:
- Open the game
- Load world
- High allocation rate for many seconds (annoying on old hardware?/battery saver mode)
- Quit world without closing the game
- Load world
- High allocation rate for a few seconds (not much of an issue)
- Quit world
It is pretty annoying as the CPU is highly utilized. It happened both in 22w44a generated worlds and converted 1.19 worlds. It happens on 1.19.2 as well.
- Issue demonstration video (more noticeable, battery saver mode)
- Issue demonstration video (still present, normal performance mode)
It seems this is more noticeable when battery saver mode is on on macOS. Allocation rate was 000MB/s probably because it was on its first seconds, but I could see GC running a few times. This did not happen for a minute, but for 15 seconds. Still happens, as opening the world again afterwards takes way less time (3-4 seconds).
Not sure if this could be improved by moving somethings to the init phase of the game instead of leaving it to when the world is loading.
It happens when joining servers, thus it is probably related to the client side.
High allocation rates are noticeable when opening a single player world for the first time after launching the game. Second runs do not have this issue.
Steps to reproduce:
- Open the game
- Load world
- High allocation rate for many seconds (annoying on old hardware?/battery saver mode)
- Quit world without closing the game
- Load world
- High allocation rate for a few seconds (not much of an issue)
- Quit world
It is pretty annoying as the CPU is highly utilized. It happened both in 22w44a generated worlds and converted 1.19 worlds. It happens on 1.19.2 as well.
- Issue demonstration video (more noticeable, battery saver mode)
- Issue demonstration video (still present, normal performance mode)
It seems this is more noticeable when battery saver mode is on on macOS. Allocation rate was 000MB/s probably because it was on its first seconds, but I could see GC running a few times. This did not happen for a minute, but for 15 seconds. Still happens, as opening the world again afterwards takes way less time (3-4 seconds).
Not sure if this could be improved by moving somethings to the init phase of the game instead of leaving it to when the world is loading. It also happens when joining servers, thus it is probably related to the client side.
I investigated this issue. It is related to building optimized DataFixer. Building an unoptimized DataFixer solves the issue, like LazyDFU mod does. Allocation comes back to normal right after the log message "Datafixer optimizations took {} milliseconds" (which in my case, was 77 seconds, a huge computational cost).
High allocation rates are noticeable when opening a single player world for the first time after launching the game. Second runs do not have this issue.
Steps to reproduce:
- Open the game
- Load world
- High allocation rate for many seconds (annoying on old hardware?/battery saver mode)
- Quit world without closing the game
- Load world
- High allocation rate for a few seconds (not much of an issue)
- Quit world
It is pretty annoying as the CPU is highly utilized. It happened both in 22w44a generated worlds and converted 1.19 worlds. It happens on 1.19.2 as well.
- Issue demonstration video (more noticeable, battery saver mode)
- Issue demonstration video (still present, normal performance mode)
It seems this is more noticeable when battery saver mode is on on macOS. Allocation rate was 000MB/s probably because it was on its first seconds, but I could see GC running a few times. This did not happen for a minute, but for 15 seconds. Still happens, as opening the world again afterwards takes way less time (3-4 seconds).
Not sure if this could be improved by moving somethings to the init phase of the game instead of leaving it to when the world is loading. It also happens when joining servers, thus it is probably related to the client side.
I investigated this issue. It is related to building optimized DataFixer. Building an unoptimized DataFixer solves the issue, like LazyDFU mod does. Allocation comes back to normal right after the log message "Datafixer optimizations took {} milliseconds" (which in my case, was 77 seconds, a huge computational cost). Maybe this isn't the only thing affecting it, because even with LazyDFU there's some higher CPU usage on first world open compared to the second world open.
High allocation rate after starting the game (first world load)
High allocation rates are noticeable when opening a single player world for the first time after launching the game. Second runs do not have this issue.
Steps to reproduce:
- Open the game
- Load world
- High allocation rate for many seconds (annoying on old hardware?/battery saver mode)
- Quit world without closing the game
- Load world
- High allocation rate for a few seconds (not much of an issue)
- Quit world
It is pretty annoying as the CPU is highly utilized. It happened both in 22w44a generated worlds and converted 1.19 worlds. It happens on 1.19.2 as well.
- Issue demonstration video (more noticeable, battery saver mode)
- Issue demonstration video (still present, normal performance mode)
It seems this is more noticeable when battery saver mode is on on macOS. Allocation rate was 000MB/s probably because it was on its first seconds, but I could see GC running a few times. This did not happen for a minute, but for 15 seconds. Still happens, as opening the world again afterwards takes way less time (3-4 seconds).
Not sure if this could be improved by moving somethings to the init phase of the game instead of leaving it to when the world is loading. It also happens when joining servers, thus it is probably related to the client side.
I investigated this issue. It
isrelated to building optimized DataFixer. Building an unoptimized DataFixersolves the issue,like LazyDFU mod does. Allocation comes back to normal right after the log message "Datafixer optimizations took {} milliseconds" (which in my case, was 77 seconds, a huge computational cost). Maybe this isn't the only thing affecting it, because even with LazyDFU there's some higher CPU usage on first world open compared to the second world open.High allocation rates are noticeable when opening a single player world for the first time after launching the game. Second runs do not have this issue.
Steps to reproduce:
- Open the game
- Load world
- High allocation rate for many seconds (annoying on old hardware?/battery saver mode)
- Quit world without closing the game
- Load world
- High allocation rate for a few seconds (not much of an issue)
- Quit world
It is pretty annoying as the CPU is highly utilized. It happened both in 22w44a generated worlds and converted 1.19 worlds. It happens on 1.19.2 as well.
- Issue demonstration video (more noticeable, battery saver mode)
- Issue demonstration video (still present, normal performance mode)
It seems this is more noticeable when battery saver mode is on on macOS. Allocation rate was 000MB/s probably because it was on its first seconds, but I could see GC running a few times. This did not happen for a minute, but for 15 seconds. Still happens, as opening the world again afterwards takes way less time (3-4 seconds).
Not sure if this could be improved by moving somethings to the init phase of the game instead of leaving it to when the world is loading. It also happens when joining servers, thus it is probably related to the client side.
I investigated this issue. It may be related to building optimized DataFixer. Building an unoptimized DataFixer (like LazyDFU mod does) partially solves the issue. Allocation comes back to normal right after the log message "Datafixer optimizations took {} milliseconds" (which in my case, was 77 seconds, a huge computational cost). Maybe this isn't the only thing affecting it, because even with LazyDFU there's some higher CPU usage on first world open compared to the second world open.
Hello! I am having the same issue in 1.19.2 without any mods or alternative launchers.
I am using a M2 MacBook Air and an external display (3840x2160). The issues happens only when MacOS is scaled by something off 100% (native display resolution) or 200% (which is the MacOS default and "looks like 1080p" on UHD monitors).
When I maximize Minecraft, it runs at 2 times 1440p (5120x2880), which is greater than 1440p and even greater than the native 2160p. I always need to set up fullscreen mode to any other resolution to fix this issue or set my display scaling to the default.
When not scaled, the game runs at native resolution, 2160p.
Thank you!
Yeah, it still happens. Video demonstrating this issue on a UHD monitor set up on 200% scaling (default of MacOS, "Looks like 1080p" according to display settings)
Duplicate of/extends/explains
MC-156077Affects 1.19.2
Can confirm: It is very noticeable if you scroll slowly, as when you try to change to the hotbar neighbor not to trigger a two or more slots jump. I have to either use number shortcuts or scroll the entire hotbar to get where I want to with precision.
Yeah, occurs in un-modded single player as well. Image was compressed so it could be attached.
For me, it happens only on pause screen, for other in-game screens (such as furnaces, chests) it does not happen... 1.19 on Monterey.
Edit: it does happen in other reported conditions as well, I just can't reproduce consistently enough to notice the pattern.
@Stop using my real name (I really don't get how to mention users here...) You can use Misode's data pack generator to produce a custom data pack that allows building only up to 128. Maybe this could indeed be the default in new worlds...
It is not much of a suggestion or feature request.
It is an issue since the clouds previously seemed to occupy the entire sky and now they doesn’t. I’ve left suggestions on the fix but the issue is still there: clouds right now looks unnatural because they just move them instead of fixing the way it looks for the new height.
MC-238931 seems to talk about by distance only, which does not fixes the unnatural look since it does not consider color, sky appearance and stuff like that which increments the game's visual, just clouds fading, like the vanillatweaks resource pack does.
We can close this and update the other CR's description if needed or the other way around too. Or keep both? Don't know.
It was! Thank you!! So happy to see this fixed
It still does happen on my Macbook Air with the latest snapshot (24w03b). Happens on external and internal displays.
Reproduction steps
If you want to test the native resolution, on the display preferences you can find "Advanced" and toggle to show a list of resolutions, than go back to the display preferences and toggle the "show all resolutions" button and select the native one (probably the first item). In this case, Minecraft renders in the correct resolution.
@clamlol I don't play in fullscreen mode because it is very annoying to alt+tab to another application. I've attached reproduction steps in the other comment.
In fullscreen mode, it seems that the game picks a resolution closer (but not exactly the same) to the "scaled" resolution that MacOS shows in the display preferences when it is on "Current" setting, which is less impactful than the non-fullscreen mode. Manually picking a resolution does work correctly in fullscreen.
Cannot reproduce on latest release 1.12.3 as well, at least not from a few minutes testing, I haven't played for long. Thanks
Sorry, it wasn't my intention to reopen the issue...
Not opening the launcher for a while, I was required to log-in again, but the gray screen appeared right after the Microsoft login page started to appear.
The cause was my DNS server intentionally blocked "vortex.data.microsoft.com" as it classified it as excessive ads/tracking, so I had to change networks for the login page to work, which is an undesired and unnecessary workaround.
I don't know why such a violent error (preventing sign in) for a single DNS query failure used for telemetry and tracking. I am able to login into Microsoft's services (including logging in into minecraft.net profile using a Microsoft account) on my browser using this same DNS server, so this one domain isn't essential for the authentication process.
Please, consider reviewing this DNS query failure exception handler so that we can log in without changing DNS servers. Note that the issue isn't my DNS server, the issue is an unnecessary domain lookup totally blocking the entire authentication page, this shouldn't happen unless the main domain address of the page being requested failed, which isn't the case.
Logs: launcher_log - dns query.txt