Linux-specific performance, graphical, or crashing issues [MEGA-ISSUE]

Question

Linux-specific performance, graphical, or crashing issues [MEGA-ISSUE]

Opened this issue a year ago · 67 comments

malucard commented a year ago

Please confirm the following.

I checked the existing issues for duplicate problems
I have tried resolving the issue using the support portal
I have ensured my Modrinth App installation is up to date

What version of the Modrinth App are you using?

0.9.0

What operating systems are you seeing the problem on?

Linux

Describe the bug

I use an Nvidia GPU and Arch Linux. The app just updated to 0.9.0, but immediately I noticed that it's unusably slow. When interacting with it, like moving the cursor from one button to another, it freezes for about a second, although animations look smooth afterwards (if I stop moving). I see no errors or logs anywhere.
The GPU is relevant because, as with previous versions and even other apps, the app crashes on startup if run normally, so it needs the workaround of setting WEBKIT_DISABLE_DMABUF_RENDERER=1 (or WEBKIT_DISABLE_COMPOSITING_MODE=1), but that workaround worked decently in previous versions, so something changed now.
The Modrinth app seems to account for software rendering by providing the "advanced rendering" toggle, but even though turning it off is supposed to help with this, it doesn't improve the situation.

FeelipMar commented 4 months ago

yeah :p

aisyahpasirwaru-coder commented 2 months ago

fcfddxg

👎2

Answer 1 · 2024-12-24T01:28:32.000Z

same thing happening to me after updating. extremely annoying issue

Answer 2 · 2024-12-24T09:15:06.000Z

I'm also facing this issue on Arch with version 0.9.0 (modrinth-app-bin, aur). Although, I don't have a NVIDIA GPU; rather, my system uses an Intel iGPU. I've tried turning off Advanced rendering, however it doesn't resolve the issue.

2024-12-24.09-13-20.mp4

Answer 3 · 2024-12-24T09:18:53.000Z

I can reproduce this issue. Compiling from source and using this binary also doesn't help.

This issue is probably caused by WebKit - web view used by tauri on Linux. The tauri team is working on other alternatives like cef (chromium) or servo. For now we can only way and try to find bottlenecks and optimize them if we can.

Answer 4 · 2024-12-24T10:06:32.000Z

I'm running Manjaro and after updating I now get this when I run version 0.9.0

Could not create default EGL display: EGL_BAD_PARAMETER. Aborting...

** (ModrinthApp:2121): WARNING **: 19:50:50.282: atk-bridge: get_device_events_reply: unknown signature

Answer 5 · 2024-12-24T11:02:00.000Z

this is what i have tried and still getting

Could not create default EGL display: EGL_BAD_PARAMETER. Aborting...

** (ModrinthApp:12167): WARNING **: 20:49:54.234: atk-bridge: get_device_events_reply: unknown signature

one.txt

Answer 6 · 2024-12-24T11:09:43.000Z

I have a similar problem but with a AMD GPU, previous version seemed to run perfectly.

Answer 7 · 2024-12-24T12:31:28.000Z

I have a similar problem but with a AMD GPU, previous version seemed to run perfectly.

Depending on how you installed it, you might be unintentionally still using the workaround I mentioned. For me, /usr/bin/modrinth-app is a shell script that sets WEBKIT_DISABLE_DMABUF_RENDERER=1 and runs the actual app executable in /opt/, presumably to prevent it from crashing for Nvidia users. Can you try running the app directly, or changing that variable to 0 instead of 1?

Answer 8 · 2024-12-24T13:01:20.000Z

I have a similar problem but with a AMD GPU, previous version seemed to run perfectly.

Depending on how you installed it, you might be unintentionally still using the workaround I mentioned. For me, /usr/bin/modrinth-app is a shell script that sets WEBKIT_DISABLE_DMABUF_RENDERER=1 and runs the actual app executable in /opt/, presumably to prevent it from crashing for Nvidia users. Can you try running the app directly, or changing that variable to 0 instead of 1?

That fixes it for me, thanks.

Answer 9 · 2024-12-24T14:31:20.000Z

Manually compiling and setting WEBKIT_DISABLE_DMABUF_RENDERER=0 completly fixes this issue for me.

Answer 10 · 2024-12-24T18:06:13.000Z

That fixes it for me, thanks.

Welp, that confirms the idea that this is a problem for Nvidia+Linux users, since we can't change that to 0 or it will crash on startup

Answer 11 · 2024-12-24T20:37:14.000Z

Arch users can try the modrinth-app-segfault-fix-bin AUR package for a quick fix, I've been using it myself ever since 0.8.0. Users on other distros can try setting these env variables:

export WEBKIT_DISABLE_DMABUF_RENDERER=1
export LIBGL_ALWAYS_SOFTWARE=1
export GDK_BACKEND=x11

Answer 12 · 2024-12-24T21:21:08.000Z

I am also having this issue (on pop os with Nvidia gpu), hope this gets fixed soon.

Answer 13 · 2024-12-25T05:58:20.000Z

Manually compiling and setting WEBKIT_DISABLE_DMABUF_RENDERER=0 completly fixes this issue for me.

Is this something we can edit in GH actions to generate a working build?

Answer 14 · 2024-12-25T06:58:14.000Z

Manually compiling and setting WEBKIT_DISABLE_DMABUF_RENDERER=0 completly fixes this issue for me.

Is this something we can edit in GH actions to generate a working build?

Unfortunately, if you missed this detail, setting that makes the app crash on startup on Nvidia. To be clear, that variable was always set to 1 by default as a workaround for Nvidia users, but the issue is that 0.9 lags when it's set. (Unless I'm missing something about what Norbiros did)

Answer 15 · 2024-12-25T20:20:43.000Z

I've run a bisect and c39bb78 is the main commit that introduced the issue. Previous commits already ran very poorly but were usable. That commit is really massive, though.

Answer 16 · 2024-12-27T17:39:23.000Z

My issue is not the same, but it is because of a default flag set, which fixes the black screen issue, but introduces lagging. The main executable in /opt/modrinth-app/modrinth-app launches without issue, does not lag and uses my gpu. However, the default /usr/bin/modrinth-app, runs the main executable with WEBKIT_DISABLE_DMABUF_RENDERER=1. Removing that flag, the app does not lag anymore. This is not the only issue, it fixes, but now the logs dont crash the app anymore. However, my friend has the same black screen issue now, so this is not the best fix.

Answer 17 · 2024-12-27T17:39:59.000Z

I have an amd integrated gpu, and i am on arch using the modrinth-app-bin package from AUR

Answer 18 · 2024-12-27T17:46:19.000Z

The app is completely unusable for me.

I have an nvidia-gpu and version 0.9.2. I am on arch.

The app crashes without WEBKIT_DISABLE_DMABUF_RENDERER=1 and GDK_BACKEND=x11.

LIBGL_ALWAYS_SOFTWARE does not matter.

env WEBKIT_DISABLE_DMABUF_RENDERER=1 LIBGL_ALWAYS_SOFTWARE=0 GDK_BACKEND=x11 /opt/modrinth-app/modrinth-app "$@"

I compiled it from source, used the modrinth-app, modrinth-app-bin and modrinth-app-segfault-fix-bin. All exhibit the issue.

Answer 19 · 2024-12-30T18:44:54.000Z

Same issue here. Very hard to use on POP OS PC with NVIDIA GPU.
Zero lagg on the same OS on my laptop without GPU.

Answer 20 · 2025-01-03T02:07:41.000Z

Just installed it for the first time, didn't work.
I'm using arch on hyprland with a nvidia card as well.

This is what terminal prints:

❯ modrinth-app
(modrinth-app:803815): Gtk-WARNING **: 21:02:32.228: Theme parsing error: gtk-dark.css:6691:68: Invalid name of pseudo-class

(WebKitWebProcess:803846): Gtk-WARNING **: 21:02:32.434: Theme parsing error: gtk-dark.css:6691:68: Invalid name of pseudo-class
/usr/bin/modrinth-app: line 2: 803815 Segmentation fault      (core dumped) env WEBKIT_DISABLE_DMABUF_RENDERER=1 /opt/modrinth-app/modrinth-app "$@"

Answer 21 · 2025-01-04T09:36:48.000Z

Arch Linux, Nvidia/AMD. The app is extremely slow, even though it should run on my iGPU. It also crashes very often

Answer 22 · 2025-01-05T18:56:40.000Z

Having the same issue on nvidia sadly, app runs at 0,7fps when moving mouse to different hover objects

Answer 23 · 2025-01-07T22:04:01.000Z

Use a 4060, same issue, thought my processed died already after seeing the horrendous fps and tried various packages on arch, still same behavior.
the one with the segfault fix gives os error about perms

Answer 24 · 2025-01-08T21:34:28.000Z

Also having this issue on debian 12, with deb, appimage and flatpak...
I know a big part of this issue is with webkit / tauri, and that they're planning to move to probs CEF, but from what I know theres no planned/soon release for that... it would be rly nice if there was an option to somehow make app use less animations or something (whatevers causing the fps drop) to return it to the performance it had before. I have no idea if thats possible, tho.
Cause yeah, app is unusable right now. :/

Answer 25 · 2025-01-09T04:14:24.000Z

I will try just downgrading the app. I didn't notice any functional changes, not anything I need for sure, so I hope it'll go well

Answer 26 · 2025-01-14T23:17:13.000Z

Installed flatpak version and it works perfectly fine

Answer 27 · 2025-01-15T12:21:23.000Z

@Damglador Flatpak version doesn't even start for me

Answer 28 · 2025-01-17T13:41:20.000Z

@Damglador Flatpak version doesn't even start for me

same

Answer 29 · 2025-02-06T16:20:17.000Z

Any update on this?

Answer 30 · 2025-02-07T11:28:54.000Z

Any updates?

Answer 31 · 2025-02-10T14:18:33.000Z

Any updates?

Answer 32 · 2025-02-19T21:19:17.000Z

I don't expect them to do anything about this as I've read somewhere on Discord that they're not interested in supporting Linux themselves, so I've switched back to ATLauncher. I am not sure if that info is outdated.

Answer 33 · 2025-02-20T06:44:29.000Z

I don't expect them to do anything about this as I've read somewhere on Discord that they're not interested in supporting Linux themselves, [...]. I am not sure if that info is outdated.

@cranberry3148 This is not about interest in support. It's about WebKit being mediocre, and waiting for the framework to update to CEF (Chromium).

I do a quick search on Discord and find this:

I understand linux support isn't the best right now, but it's primarily Tauri's fault (we are waiting for an option to use CEF instead of webkit which should fix 99% of issues)

Hmm yeah, linux has always been very unstable on the app because of webkit. Tauri is releasing a update soon which allows it to use CEF, which should fix this

Tauri, a framework that we use for the app, will switch to a better browser engine on linux, which should fix most of the issues users experience there

Answer 34 · 2025-04-17T22:15:28.000Z

I have a similar problem but with a AMD GPU, previous version seemed to run perfectly.

Depending on how you installed it, you might be unintentionally still using the workaround I mentioned. For me, /usr/bin/modrinth-app is a shell script that sets WEBKIT_DISABLE_DMABUF_RENDERER=1 and runs the actual app executable in /opt/, presumably to prevent it from crashing for Nvidia users. Can you try running the app directly, or changing that variable to 0 instead of 1?

I've been having the same lag issue using the AUR package on Arch (modrinth-app-git). I guessed it was for some reason using software rendering (because I noticed the blur effects weren't rendering). Your suggestion FIXED IT! Now it runs smoothly for me (using an AMD GPU btw) as it should. Gosh I LOVE Nvidia making the Linux experience worse (sry Nvidia users)

Answer 35 · 2025-05-14T09:57:57.000Z

lag with ubuntu 24.04

Answer 36 · 2025-05-15T13:09:36.000Z

Mentioning related issues for tracking purposes: #3115, #3353

Answer 37 · 2025-06-12T11:10:32.000Z

Are there any workarounds for this? I'm running arch with hyprland on an NVIDIA RTX 3060 and the app is unusable.

Answer 38 · 2025-06-12T18:29:20.000Z

@0PandaDEV if flathub version doesn't work - using Prism Launcher

Answer 39 · 2025-06-20T20:46:45.000Z

theres also a lot of Segmentation fault (core dumped) crashes for me

Answer 40 · 2025-06-20T20:47:49.000Z

export WEBKIT_DISABLE_DMABUF_RENDERER=1
export LIBGL_ALWAYS_SOFTWARE=1
export GDK_BACKEND=x11

this fixes it

but its still extremely laggy
im on arch + gnome + x11/xorg (idk) + nvidia

Answer 41 · 2025-07-11T20:12:13.000Z

Yeah, I also experience these issues when using Wayland + Nvidia. I have to fall back to software rendering in order to make it work so a fix would be greatly appreciated

Answer 42 · 2025-07-23T19:59:50.000Z

Could not create default EGL display: EGL_BAD_PARAMETER. Aborting...

** (ModrinthApp:10891): WARNING **: 21:56:26.248: atk-bridge: get_device_events_reply: unknown signature
Still happening with the appimage on cachyOS (arch)

Answer 43 · 2025-09-02T21:27:00.000Z

I will be consolidating all issues related to Modrinth App crashing, displaying blank screens, or having poor performance into this issue since it has the most activity on it.

Answer 44 · 2025-09-03T05:22:38.000Z

I noticed that on my machine with Nobara Modrinth only works if I SSH my computer into itself (using ssh -X to enable X11 support through the SSH tunnel) and let it run through that. I also set DISPLAY=:0 in the default envvars inside Modrinth to make Minecraft connect to the Xwayland server directly (reducing display latency, thus improving performance drastically).
(Details in my comment on #2289)

Just mentioning it here incase that same method also fixes performance for some or blank screen/crash for someone else than me.

Answer 45 · 2025-09-03T05:41:57.000Z

I believe most issues could be addressed by the maintainers. For example, I maintain modrinth-app-bin on Gentoo, and based on user feedback it works flawlessly for everyone.

A few months ago, Tauri introduced support for Verso. While it may come with its own set of issues, it could still be worth experimenting with or even releasing alternative builds using it to potentially resolve some WebKit-related problems.

Answer 46 · 2025-09-03T09:31:00.000Z

Might be resolved via switching to chromium but wanted to have mentioned this (#3625): The RPM package is broken on Immutable distros.

Answer 47 · 2025-09-05T20:32:57.000Z

A few months ago, Tauri introduced support for Verso. While it may come with its own set of issues, it could still be worth experimenting with or even releasing alternative builds using it to potentially resolve some WebKit-related problems.

Servo:

Verso:

I dont think Verso is there yet.. everything is off

Answer 48 · 2025-09-12T21:38:53.000Z

Same problem, the UI is extremely laggy, and on then flatpak version the Modrinth interface does not even show up.
Using Linux Mint 22.2 Cinnamon, AMD Ryzen 7 5700X 8-Core Processor × 8 and Nvidea RTX 3060 12gb

Answer 49 · 2025-09-15T10:20:26.000Z

The problem is (i believe), Modrinth uses Tauri and Tauri uses its own cross-platform WebView rendering library called Wry. Wry only supports WebKit2GTK on Linux.

Because of that the Linux build is tied to whatever capabilities WebKit2GTK exposes. On NVIDIA systems in particular, WebKit2GTK’s DMA-BUF/GBM acceleration is still unstable, which is why the app either crashes with the default renderer or falls back to CPU compositing and feels like ~5 fps when launched with WEBKIT_DISABLE_DMABUF_RENDERER=1 GDK_BACKEND=x11 at startup.

The Tauri/Wry developers themselves are aware of this limitation and have been experimenting with alternatives like Servo to replace WebKit2GTK, but Servo is still at a very early stage and not production-ready. Until Wry can switch to a different backend (or WebKit2GTK improves its NVIDIA support), there’s no easy way for the app to get smooth GPU rendering on Linux/NVIDIA.

Answer 50 · 2025-09-15T10:26:37.000Z

Might be resolved via switching to chromium but wanted to have mentioned this (#3625): The RPM package is broken on Immutable distros.

Tauri/Wry cannot simply "flip a switch" to switch to Chromium on Linux. On Linux, Wry is tied to WebKit2GTK because there is no native, Chromium-based web view available for embedding. Switching to Chromium would require us to ship CEF/Chromium ourselves, rewrite the backend, and lose the small runtime footprint that differentiates Tauri from Electron.

For now, the plan is to stick with WebKit2GTK while we wait for improvements to upstream GPU/DMA-BUF support. In the meantime, the Tauri/Wry developers are experimenting with Servo as a future embeddable engine. Unfortunately, "switching to Chromium" isn't a quick fix for the current issues, including the RPM/immutable distro quirks.

Answer 51 · 2025-09-15T11:13:09.000Z

on then flatpak version the Modrinth interface does not even show up

@ChangedRuby Have you tried SSH'ing into your own computer with the -X flag and starting Modrinth through that X tunnel, like I detailed in this comment, as a stop-gap solution?

Answer 52 · 2025-09-26T14:02:01.000Z

I’ve been running into the same issue where the Modrinth App became very laggy and sometimes crashed. In my case the crashes were most reproducible when accessing the logs section of a modpack, or when opening dropdown menus (for example while selecting a download option).

While investigating, I saw that the error was actually a buffer overflow. After some debugging I confirmed it wasn’t coming directly from Modrinth itself but rather from a library it uses — libwebkit2gtk. I also found some reports online mentioning similar problems with this library.

I tried what seemed like the most reasonable next step: downloading and compiling the latest available version of libwebkit2gtk (webkitgtk-2.50.0). However, even after building and using the updated library, the crashes and buffer overflow still occurred.

The workaround I found that completely resolves the lag and crashes on my system is the following:

Open NVIDIA X Server Settings → PRIME Profiles.
Select “NVIDIA On-Demand” instead of “Performance”.

This forces desktop applications (including Modrinth) to run on the Intel iGPU. With this setting, the Modrinth launcher no longer lags, crashes, or triggers the buffer overflow.

Of course, this creates the problem that Minecraft itself would then also launch on the iGPU instead of the dedicated NVIDIA GPU. The fix for that is:

Go into Minecraft settings in Modrinth → Java & Memory → enable Custom Environment Variables.
Add:

__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia

This way, Modrinth runs smoothly on the Intel GPU, while Minecraft launches on the NVIDIA GPU as intended.

I still can’t pinpoint the root cause — the buffer overflow only occurs when Modrinth itself runs directly on the NVIDIA GPU. It could be a bug in libwebkit2gtk, in the NVIDIA drivers (I’m on version nvidia-driver-580-open, the latest provided by Ubuntu), or perhaps something in how Modrinth interacts with the library. I can’t say for sure.

But at least with this workaround, everything is stable: Modrinth is usable without lag/crash, and Minecraft still uses the dedicated GPU for performance. Hopefully this helps others until the underlying bug is fully resolved upstream.

Answer 53 · 2025-09-26T14:07:18.000Z

I’ve been running into the same issue where the Modrinth App became very laggy and sometimes crashed. In my case the crashes were most reproducible when accessing the logs section of a modpack, or when opening dropdown menus (for example while selecting a download option).

While investigating, I saw that the error was actually a buffer overflow. After some debugging I confirmed it wasn’t coming directly from Modrinth itself but rather from a library it uses — libwebkit2gtk. I also found some reports online mentioning similar problems with this library.

I tried what seemed like the most reasonable next step: downloading and compiling the latest available version of libwebkit2gtk (webkitgtk-2.50.0). However, even after building and using the updated library, the crashes and buffer overflow still occurred.

The workaround I found that completely resolves the lag and crashes on my system is the following:

Open NVIDIA X Server Settings → PRIME Profiles.

Select “NVIDIA On-Demand” instead of “Performance”.

This forces desktop applications (including Modrinth) to run on the Intel iGPU. With this setting, the Modrinth launcher no longer lags, crashes, or triggers the buffer overflow.

Of course, this creates the problem that Minecraft itself would then also launch on the iGPU instead of the dedicated NVIDIA GPU. The fix for that is:

Go into Minecraft settings in Modrinth → Java & Memory → enable Custom Environment Variables.

Add:
__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia
This way, Modrinth runs smoothly on the Intel GPU, while Minecraft launches on the NVIDIA GPU as intended.

I still can’t pinpoint the root cause — the buffer overflow only occurs when Modrinth itself runs directly on the NVIDIA GPU. It could be a bug in libwebkit2gtk, in the NVIDIA drivers (I’m on version nvidia-driver-580-open, the latest provided by Ubuntu), or perhaps something in how Modrinth interacts with the library. I can’t say for sure.

But at least with this workaround, everything is stable: Modrinth is usable without lag/crash, and Minecraft still uses the dedicated GPU for performance. Hopefully this helps others until the underlying bug is fully resolved upstream.

The issue may be with both libwebkit2gtk and Modrinth itself. I use Tauri to build desktop applications, and none of them have lag/crashing issues.

Answer 54 · 2025-10-20T09:25:41.000Z

For anyone having this issues, you can try to set this environment variable :
__NV_DISABLE_EXPLICIT_SYNC=1
The flatpak version is really fluid with it for me on Fedora KDE Plasma with an Nvidia card.
The app still sometime randomly freeze with this settings and need a restart, but it is at least usable.

Answer 55 · 2025-11-01T01:16:02.000Z

Tauri/Wry cannot simply "flip a switch" to switch to Chromium on Linux. On Linux, Wry is tied to WebKit2GTK because there is no native, Chromium-based web view available for embedding. Switching to Chromium would require us to ship CEF/Chromium ourselves, rewrite the backend, and lose the small runtime footprint that differentiates Tauri from Electron.
_{#3057 (comment)}

Why not try if maybe embedding Servo could work? It's far from ready for basically anything, but they've just reached their first tagged release and AFAIK are intended to be used as an embedded web renderer. And I'm only half-joking with this suggestion. At least you could keep an eye out for it.

Answer 56 · 2025-11-01T05:21:16.000Z

Hi, I did a little bit of profiling, and found nearly 80% of frame time is being spent applying blur filters.

This type of performance issue is not inherent to using tauri and webkitgtk, but of course just down to how you use it, there are plenty of tauri based linux apps that do not have these performance issues after all.

I did a quick and dirty fix Airyzz#1, removing blurs, shadows and gradient which very quickly showed massive performance improvements.

I might do a little bit more investigation to find out which of these changes exactly caused the improved performance, as I'm sure I removed a lot of things that are not entirely necessary

I don't know if this will have improvements in terms of crashes, but the UI is considerably smoother to navigate

Answer 57 · 2025-11-01T05:48:28.000Z

After a little further investigation, i found removing this single box-shadow had a huge performance gain

Airyzz#2

Answer 58 · 2025-11-01T08:01:14.000Z

Tauri/Wry cannot simply "flip a switch" to switch to Chromium on Linux. On Linux, Wry is tied to WebKit2GTK because there is no native, Chromium-based web view available for embedding. Switching to Chromium would require us to ship CEF/Chromium ourselves, rewrite the backend, and lose the small runtime footprint that differentiates Tauri from Electron.
_{#3057 (comment)}

Why not try if maybe embedding Servo could work? It's far from ready for basically anything, but they've just reached their first tagged release and AFAIK are intended to be used as an embedded web renderer. And I'm only half-joking with this suggestion. At least you could keep an eye out for it.

Currently tauri's dev team working on something called cef-rs. Basically to implement chromium

Answer 59 · 2025-11-01T08:03:20.000Z

Hi, I did a little bit of profiling, and found nearly 80% of frame time is being spent applying blur filters.

This type of performance issue is not inherent to using tauri and webkitgtk, but of course just down to how you use it, there are plenty of tauri based linux apps that do not have these performance issues after all.

I did a quick and dirty fix Airyzz#1, removing blurs, shadows and gradient which very quickly showed massive performance improvements.

I might do a little bit more investigation to find out which of these changes exactly caused the improved performance, as I'm sure I removed a lot of things that are not entirely necessary

I don't know if this will have improvements in terms of crashes, but the UI is considerably smoother to navigate

It was clear that this performance issue was either caused by the visuals or some rare case bug in gtk.

The "disable advanced rendering" option does not do what it's supposed to do, basically. If I had known Vue, I would make a PR now.

Answer 60 · 2025-11-03T20:37:25.000Z

Can confirm that i fixed it by going to /usr/bin/modrinth-app
and chaning the bottom line where it actually runs the program from opt and changing the line to this:

env MODRINTH_EXTERNAL_UPDATE_PROVIDER=1 LIBGL_ALWAYS_SOFTWARE=1 GDK_BACKEND=x11 /opt/modrinth-app/modrinth-app "$@"

these extra env's fixed it for me and im on hyprland (wayland) with nvidia on arch with the modrinth-app package from the aur

With these arguments, app launches but it stays gray. But i can click to stuff? Its just not rendering.

Im on Arch with RTX 4060

Answer 61 · 2025-11-07T18:45:35.000Z

0.10.17 lets you disable the the main app frame box shadow by toggling off Advanced rendering in settings.

Let me know if that helps with some of the performance issues!

Answer 62 · 2025-11-07T19:35:16.000Z

it's usable now!!
but it's still kind of poorly optimized, it still has some fps weirdness, but I digress

Answer 63 · 2025-11-08T05:12:25.000Z

would it be worth considering having 'advanced rendering' disabled by default on linux? it seems like this is not an uncommon issue, and would leave a bad impression on new users, who wouldn't know that this option fixes it, or even exists

Answer 64 · 2025-11-08T06:23:31.000Z

If you really want to do that, please use an env variable (like MODRINTH_DEFAULT_ADVANCED_RENDERING). On Gentoo Linux this app works perfectly well, so there is no need to disable any features.

Answer 65 · 2025-11-08T11:20:19.000Z

it fixes some laggy ness when hovering over stuff but clicking on menus still crashes quite alot and is very laggy. it is lots better though.
arch - wayland - nvidia