Speichern Dialog öffnen um 2 Sekunden verzögert. Bilder anzeigen um 2 Sekunden verzögert

Symptome

Ich habe lange gedacht, ich bilde mir das nur ein. Aber jedes Mal, wenn ich z. B. im Firefox etwas speichern will, braucht es 2 Sekunden, bis der Dialog dazu aufgeht. Genauso beim Anschauen eines Bildes. Ich habe die Ursache gefunden: es hat mit dem Energiesparen der GPU zu tun.

Ursache

Der Öffnen-Dialog von Snap-Apps wird nicht von der App selbst gezeichnet, sondern per xdg-desktop-portal von Nautilus – und Nautilus ist GTK4. GTK4 legt für jedes neue Fenster einen Vulkan-Renderer an, und der zählt beim Start alle installierten Grafiktreiber auf. Dabei greift er auf die dedizierte NVIDIA RTX A500 zu, obwohl der Bildschirm an der Intel-GPU hängt.

Im PRIME-Modus on-demand schläft die RTX A500 rund 21 Sekunden nach dem letzten Zugriff wieder ein, und sie aus dem Standby zu wecken kostet ~3 Sekunden. Weil das bei praktisch jedem Dialog erneut passiert, hängt es jedes Mal.

Das Ganze betrifft nicht nur den Dateidialog, sondern jede GTK4-App, die ein Fenster aufbaut – also auch den Bildbetrachter, die Vorschau und diverse GNOME-Anwendungen.

Nachgemessen

Zeit vom Start bis das Fenster sichtbar ist, jeweils mit schlafender und mit wacher GPU:

Faktor 20 – und der einzige Unterschied ist, ob die dedizierte GPU überhaupt angefasst wird. Am Bildbetrachter Loupe sieht man dasselbe Muster, hier an den geöffneten Gerätedateien:

Ein Treiber-Update hat übrigens kaum etwas gebracht: mit 595.84 statt 580.173.02 sank die Aufweckzeit nur von 3,56 s auf 2,97 s.

Der Fix

GTK4 auf den GL-Renderer festlegen. Der benutzt nur das Standard-Gerät, also die Intel-GPU, und lässt die NVIDIA in Ruhe. Das gilt sessionweit für alle GTK4-Apps, nicht nur für den Dateimanager.

1. Datei ~/.config/environment.d/90-gsk-renderer.conf anlegen:

mkdir -p ~/.config/environment.d

cat > ~/.config/environment.d/90-gsk-renderer.conf <<'EOF'
GSK_RENDERER=gl
EOF

Das wirkt ab dem nächsten Login.

2. Für die laufende Sitzung zusätzlich:

systemctl --user set-environment GSK_RENDERER=gl
dbus-update-activation-environment --systemd GSK_RENDERER=gl

Achtung, hier bin ich reingefallen: dbus-update-activation-environment --systemd GSK_RENDERER ohne =gl liest den Wert aus der aufrufenden Shell. Ist er dort nicht gesetzt, passiert schlicht nichts – und man wundert sich, warum der Fix nicht greift. Immer mit explizitem Wert aufrufen.

3. Laufende Instanzen beenden, damit sie neu mit der Variable starten:

pkill -x nautilus

Rückgängig: die Datei löschen, abmelden und neu anmelden.

Wichtig: In GTK 4.22 heißt der Renderer gl. Der alte Name ngl wird ignoriert – GTK gibt dann nur eine Warnung aus und nimmt weiter Vulkan.

Kontrolle

Nach dem nächsten Dialog oder Bild muss hier suspended stehen:

cat /sys/bus/pci/devices/0000:02:00.0/power/runtime_status

Und in der Liste der geöffneten Dateien der App darf kein /dev/nvidia* und kein renderD129 auftauchen:

ls -l /proc/$(pgrep -x nautilus)/fd | grep -E 'nvidia|renderD'

Bei mir bleibt dort nur renderD128 übrig, also die Intel-GPU. Ein Treffer auf nvidia-application-profiles ist harmlos – das ist nur eine Textdatei, die die NVIDIA-GL-Bibliothek liest, kein Gerätezugriff.

Schnelltest ohne jede Änderung, zum Ausprobieren vorab:

GSK_RENDERER=gl firefox

Was der Fix nicht macht

Am Energiesparen ändert sich nichts: power/control bleibt auf auto, PRIME bleibt auf on-demand, die GPU schläft weiter. Der Fix nimmt ihr nur den Grund, dauernd aufzuwachen. Unterm Strich wird sie jetzt sogar seltener geweckt als vorher.

Nicht abgedeckt sind Anwendungen, die nicht GTK4 sind, aber selbst Vulkan enumerieren – Electron/Chromium-basiertes und Qt6. Wer das auch loswerden will, kann die dedizierte GPU mit prime-select intel komplett abschalten. Dann ist die ganze Problemklasse weg, aber eben auch CUDA und Offload, und Monitorausgänge, die an der NVIDIA hängen, funktionieren nicht mehr.

System und Hardware

Article release date: (01.08.2026) / Last update: (05.08.2026)