📝 Provide a description of the new feature
Feature Request: Official launch flags support + GPU-accelerated rendering
TL;DR
Spicetify has a spotify_launch_flags config field but it appears to have no effect. As a result, users on Linux who need to pass Chromium GPU flags are forced to manually edit system .desktop files — and even then, Spotify's renderer and GPU subprocesses still fall back to x11, wasting CPU on machines with a dedicated GPU sitting idle.
The problem
Spotify is an Electron (Chromium 146) app. On Linux + Wayland, its renderer and GPU subprocesses are hardcoded to --ozone-platform=x11, which means they run through XWayland instead of native Wayland, bypassing GPU compositing.
Even with GPU flags passed to the main process, the subprocesses override them internally:
# Main process (gets our flags ✅)
/opt/spotify/spotify --ozone-platform-hint=auto --enable-gpu-rasterization ...
# GPU subprocess (falls back to x11 ❌)
/opt/spotify/spotify --type=gpu-process --ozone-platform=x11 ...
# Renderer subprocess (falls back to x11 ❌)
/opt/spotify/spotify --type=renderer --ozone-platform=x11 ...
Result on my machine with an RTX 4060 at ~33% utilization:
gpu-process: ~50% CPU, 477 MB RAMrenderer: ~57% CPU, 963 MB RAM- Spotify does not appear in
nvidia-smi process list at all — the GPU is not being used
Why Spicetify is the right place to fix this
Spicetify already has a spotify_launch_flags config key — but it's undocumented and has no visible effect on my setup:
spotify_launch_flags ← empty, no documentation
If this field actually worked and was documented, users could set:
spicetify config spotify_launch_flags "--ozone-platform-hint=auto --enable-gpu-rasterization --enable-zero-copy"
Instead, the only workaround is manually editing /usr/share/applications/spotify.desktop or ~/.local/share/applications/spotify.desktop, which:
- Gets overwritten on Spotify updates
- Is not portable across systems
- Is not obvious to most users
Proposed solutions (any would help)
-
Fix / document spotify_launch_flags so it reliably injects flags into the Spotify launch command.
-
Add a performance_mode preset in Spicetify config that applies known-good GPU + Wayland flags automatically on supported platforms.
-
Expose a WebGL rendering path for extensions: allow extensions to opt into
➕ Additional Information
No response
📝 Provide a description of the new feature
Feature Request: Official launch flags support + GPU-accelerated rendering
TL;DR
Spicetify has a
spotify_launch_flagsconfig field but it appears to have no effect. As a result, users on Linux who need to pass Chromium GPU flags are forced to manually edit system.desktopfiles — and even then, Spotify's renderer and GPU subprocesses still fall back tox11, wasting CPU on machines with a dedicated GPU sitting idle.The problem
Spotify is an Electron (Chromium 146) app. On Linux + Wayland, its renderer and GPU subprocesses are hardcoded to
--ozone-platform=x11, which means they run through XWayland instead of native Wayland, bypassing GPU compositing.Even with GPU flags passed to the main process, the subprocesses override them internally:
Result on my machine with an RTX 4060 at ~33% utilization:
gpu-process: ~50% CPU, 477 MB RAMrenderer: ~57% CPU, 963 MB RAMnvidia-smiprocess list at all — the GPU is not being usedWhy Spicetify is the right place to fix this
Spicetify already has a
spotify_launch_flagsconfig key — but it's undocumented and has no visible effect on my setup:If this field actually worked and was documented, users could set:
Instead, the only workaround is manually editing
/usr/share/applications/spotify.desktopor~/.local/share/applications/spotify.desktop, which:Proposed solutions (any would help)
Fix / document
spotify_launch_flagsso it reliably injects flags into the Spotify launch command.Add a
performance_modepreset in Spicetify config that applies known-good GPU + Wayland flags automatically on supported platforms.Expose a WebGL rendering path for extensions: allow extensions to opt into
➕ Additional Information
No response