Konkrete Zahlen zur Diskussion um Eingabeverzögerung bei Wayland vs. X11

 (mort.coffee)
2 Punkte von GN⁺ 2025-01-27 | 1 Kommentare | Auf WhatsApp teilen
  • In einer Umgebung mit Fedora Workstation 41 und GNOME 47 wurde die Cursor-Eingabeverzögerung mit 240-FPS-Slow-Motion gefilmt und Wayland mit X11 verglichen
  • Gezählt wurde vom Frame, in dem sich die Maus zu bewegen beginnt, bis zum Frame, in dem der Cursor an der neuen Position sichtbar ist; dabei wurden jeweils 16 Messungen der Frame-Verzögerung für Wayland und X11 aufgezeichnet
  • GNOME X11 wurde mit durchschnittlich 4 Frames, 16,7 ms und 2,4 Bildschirm-Refreshes gemessen; GNOME Wayland mit durchschnittlich 5,5625 Frames, 23,2 ms und 3,3 Bildschirm-Refreshes
  • Auf diesem System zeigte Wayland im Mittel eine um etwa 6,5 ms höhere Cursor-Verzögerung als X11; der Unterschied lag nahezu bei einem Bildschirm-Refresh
  • Die Ergebnisse zeigen nur den Unterschied bei der Cursor-Verzögerung für die Kombination GNOME/AMD und sind kein Beleg dafür, dass Wayland in Spielen oder normalen Grafikanwendungen eine höhere Eingabeverzögerung hat

Warum gemessen wurde

  • Angestoßen durch den Beitrag Wayland Cursor Lag: Just give me a break already... über Beschwerden zur Wayland-Eingabeverzögerung führte ein Linux-Nutzer ein Experiment durch, um statt subjektivem Eindruck konkrete Zahlen zu erhalten
  • Obwohl er Wayland insgesamt zufriedenstellend nutzt, war der Eindruck, dass es gegenüber X11 eine höhere Cursor-Verzögerung gibt, der Ausgangspunkt des Experiments
  • Die 90-FPS-Handykamera des früheren Beitrags wurde als nicht ausreichend angesehen, um Unterschiede in der Größenordnung eines Bildschirm-Refreshes zu beurteilen; daher wurde ein 240-FPS-Aufnahmemodus verwendet

Messmethode

  • Mit der Handykamera wurden gleichzeitig Bildschirm, Schreibtisch, Mauszeiger, Maus und Hand gefilmt, während die Maus wiederholt mit dem Finger angestoßen wurde
  • Zunächst wurden 16 Aufnahmen in einer GNOME-Wayland-Sitzung gemacht, anschließend wurde in eine GNOME-X11-Sitzung eingeloggt und auf dieselbe Weise 16-mal aufgenommen
  • Die aufgenommenen Videos wurden mit dem Befehl ffmpeg -i <input file> %04d.jpg in JPEG-Frames umgewandelt
  • Die Frame-Verzögerung wurde nach folgenden Kriterien gezählt
    • Beginn der Zählung beim ersten Frame, in dem sichtbar ist, dass sich die Maus bewegt
    • Zählung bis zum ersten Frame, in dem der Cursor an der neuen Position eindeutig bewegt sichtbar ist
    • Sowohl Start- als auch End-Frame wurden mitgezählt
    • Wenn sich die Maus beispielsweise in Frame 1045 bewegt und der Cursor in Frame 1047, wurde dies als Verzögerung von 3 Frames erfasst

Testumgebung

  • Die verwendete Hardware und Software waren wie folgt
    • Distribution: Fedora Workstation 41
    • GNOME-Version: 47
    • CPU: AMD Ryzen 9 5950X
    • GPU: AMD Radeon RX 7900XT
    • Monitor: Gigabyte M32U, 4K IPS, 144,99 Hz, keine DPI-Skalierung
    • Maus: Logitech G502 Lightspeed
    • Kamera: iPhone 15 Pro, Slow Motion mit 240 FPS

Einschränkungen der Messung

  • Selbst 240 FPS liefern bei einem 144-Hz-Bildschirm weniger als 2 Kameraframes pro Bildschirm-Refresh, wodurch zufällige Schwankungen entstehen
  • Da Pixel nicht sofort umschalten, gibt es uneindeutige Frames, in denen der Cursor an der neuen Position zunächst nur sehr schwach sichtbar wird
  • Wenn der Cursor an der neuen Position eindeutig sichtbar war, wurde dies als Cursorbewegung gezählt, auch wenn er noch nicht vollständig hell war
  • Das iPhone-Video enthielt einige duplizierte Frames; die Ursache ist unbekannt
    • Duplizierte Frames wurden so behandelt, als wäre die Zeit eines Frames vergangen, und wie normale Frames gezählt
  • Diese Faktoren erzeugen Unsicherheit in den Ergebnissen, dürften aber Wayland und X11 gleichermaßen betreffen und sich bei genügend Daten im Mittel ausgleichen
  • Wayland-Compositoren außerhalb von GNOME sowie GPU-Treiber außerhalb von AMD wurden nicht getestet; bei anderen Kombinationen können die Ergebnisse daher anders ausfallen

Messergebnisse

  • Die 16 Messwerte für GNOME X11 betrugen 5, 4, 3, 4, 5, 4, 6, 5, 1, 4, 4, 4, 3, 4, 4, 4 Frames
    • Durchschnitt: 4 Frames
    • Verzögerungszeit: 16,7 ms
    • Bildschirm-Refreshes: 2,4
  • Die 16 Messwerte für GNOME Wayland betrugen 6, 5, 6, 5, 5, 6, 6, 4, 8, 6, 5, 5, 5, 6, 5, 6 Frames
    • Durchschnitt: 5,5625 Frames
    • Verzögerungszeit: 23,2 ms
    • Bildschirm-Refreshes: 3,3
  • Auf diesem System zeigte Wayland im Mittel eine um etwa 6,5 ms höhere Cursor-Verzögerung als X11
  • Es fehlt die Expertise, um sauber zu analysieren, ob dies statistisch signifikant ist; anhand der Messwerte wirkt der Unterschied jedoch klar und konsistent
  • Der Unterschied liegt fast bei einem Bildschirm-Refresh; ob das Zufall ist, ist unklar

Fazit und Interpretationsrahmen

  • Dieses Experiment zeigt, dass es auf bestimmter Hardware einen Unterschied bei der Eingabeverzögerung zwischen X11 und Wayland gibt und dass dieser groß genug sein kann, um von manchen Nutzern bemerkt zu werden
  • Um Umfang und Größe des Problems klar zu erfassen, sind weitere Tests mit unterschiedlicher Hardware und verschiedenen Bildwiederholraten nötig
  • Die Größe des Unterschieds kann von Faktoren wie dem verwendeten Compositor und der Bildwiederholrate abhängen
  • Weitere Experimente sind sehr zeitaufwendig und werden voraussichtlich nicht selbst durchgeführt
  • Dieser Test zeigt nicht, dass Wayland insgesamt eine höhere Eingabeverzögerung als X11 hat
    • Insbesondere ist er kein Beleg dafür, dass Wayland in Spielen eine höhere Eingabeverzögerung hat
    • Es ist möglich, dass die zusätzliche Verzögerung nur den Cursor betrifft
    • Nach dem Verständnis des Autors wird der Cursor sehr anders behandelt als normale Grafikanwendungen
    • Ob Wayland in Spielen eine höhere Eingabeverzögerung als X11 zeigt, müsste separat getestet werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-01-27
Hacker-News-Kommentare

  • Ein großartiger Ansatz. Viel zu oft ersetzen Leute Dinge, die sich experimentell überprüfen lassen, durch Vermutungen. Seit ich die wissenschaftliche Methode gelernt habe, zieht es mich immer zu „Lasst uns ein Experiment entwerfen“.
    Ich weiß nicht, warum Wayland zusätzliche Latenz verursacht, aber als jemand, der schon zur Anfangszeit von X11 in der Computer-Community war, kann ich sagen, dass es von Anfang an ununterbrochen Beschwerden über Display-Latenz gab. Ob Cursor-Reaktion oder xterm-Scrolling, das war überall so.
    Als „Workstations“ aufkamen, gab es teils sogar separate Anzeigehardware nur für die Maus, um die Latenz beim Rendern der Maus innerhalb des Frames zu verringern. Und es gab das berüchtigte XOR-Patent: https://patents.google.com/patent/US4197590
    Wegen solcher Beschwerden wurde der Codepfad von Tastatur-/Mauseingabe bis zur Darstellung auf dem Bildschirm ständig daraufhin überprüft, wie man ihn „schneller und mit geringerer Latenz“ machen kann. Wayland ist im Vergleich zu X11 relativ „neu“ und daher nicht annähernd so lange überprüft worden, aber hoffentlich beheben die Leute das nach und nach.

    • Display-Geräte, meist als Teil der GPU, haben noch immer explizite Anzeigehardware nur für die Maus, heute in Form einer Cursor-Ebene (cursor plane). Später kamen auch verallgemeinerte Overlay-Ebenen hinzu.
      Ebenen lassen sich aktualisieren oder verschieben, ohne den Rest des Bildschirms neu zu zeichnen. Das normale Bildschirmbild liegt auf der Basisebene, und das Bewegen des Cursors ist eher ein Commit der neuen Ebenenposition.
      Die vom hier verwendeten Wayland-Server GNOME Mutter hinzugefügte Eingabelatenz dürfte wahrscheinlich ein Problem der Strategie für Input-Sampling und Commit-Timing sein. Jeder Server hat andere Strategien und Prioritäten, mit entsprechenden Vor- und Nachteilen.
      Wayland ist ein Protokoll und greift nicht in den allgemeinen Ablauf der Cursor-Positionierung ein. Daher liegt dieses Problem vollständig im Bereich interner Implementierung und Optimierung des Display-Servers. Auf Protokollebene passiert im Wesentlichen nur, dass der Client das Cursor-Bild setzen darf und dem Client die Cursor-Position mitgeteilt wird.
    • Früher aktualisierten XFree86 und Xorg den Pointer direkt innerhalb des SIGIO-Handlers. Das ist inzwischen aber sehr lange her, und heute würde ich nicht erwarten, dass sich Wayland und Xorg in diesem Bereich stark unterscheiden.
      Soweit ich mich erinnere, begann es bei Xorg mit dem Aufkommen von glamour schlechter zu werden. Der Cursor-Rendering-Pfad war dann nicht mehr sicher innerhalb eines Signal-Handlers ausführbar, was bei einer OpenGL-basierten Lösung auch kaum anders zu erwarten war, und die Latenz wurde schlimmer.
      Früher blieb der Mauszeiger selbst dann reaktionsfähig, wenn eine Linux-Maschine gerade am Thrashen war, und war ein verlässlicher Indikator dafür, ob der Kernel festhing oder nicht. Wenn der Pointer nicht früh genug reagierte, musste man auf IDE-/PATA-Hosts mit hdparm oft unmask irq einschalten. Ein nicht reagierender Pointer in XFree86 war ein sehr nützliches Signal dafür, dass etwas schiefgelaufen oder falsch konfiguriert war — ich vermisse diese Zeit.
    • Wie alt ist Wayland inzwischen? In diesem Tempo wird es im Grab noch „Frühlingstraum“ lesen.
      Ich weiß, dass es seltsam ist, sich über freie Software zu beschweren, aber hier wird seit viel zu langer Zeit eine erzwungene Umstellung auf etwas Schlechteres betrieben. Die Einführung von Wayland hätte auf der Annahme beruhen müssen, dass es bei praktisch allen Eingabe- und Display-Anforderungen allgemein überlegen ist.
      Intel, AMD, Nvidia und Arm-Hersteller sollten sich in einem Konsortium mit voller Kraft für ein brauchbares Desktop-Linux einsetzen. Dasselbe gilt für Regierungen. Ein sicheres Linux-Desktop-System ist tatsächlich möglich, und zwar der schnellste Weg, CPU- und 3D-Fähigkeiten sowie fortgeschrittene Vektor-/Computerhardware zur Geltung zu bringen.
      Wayland hat damit die Verzögerung des Linux-Desktops noch vergrößert — in einer Zeit, als Windows sich mit einer schrecklichen Kacheloberfläche selbst ruinieren wollte und Apple sich hartnäckig weigerte, die zusätzliche Marktkapitalisierung mitzunehmen, die ein macOS für normales x86 gebracht hätte.
    • Dass es „explizite Anzeigehardware nur für die Maus zur Verringerung der Latenz“ gab, gilt auch heute noch. Der Mauszeiger wird als Sprite/Overlay gerendert, unabhängig von der Swapchain des Window-Compositors. Andernfalls wäre die Latenz besonders bei 60 Hz sehr auffällig.
      Knifflig wird es, wenn man Fenster oder Icons zieht, denn dann beginnt die Swapchain-Latenz sichtbar zu werden. Manche Window-Compositors kümmern sich darum nicht mehr weiter und verweisen darauf, dass hohe Bildwiederholraten die Latenz weniger sichtbar machen; macOS ist zum Beispiel so ein Fall, und Windows scheint beim Ziehen auf einen Software-Mauszeiger umzuschalten.
    • GNOME unterstützt Unredirection, daher lässt sich dieser Test kaum direkt auf echte Spieleleistung übertragen.
      Vollbild-Apps sollten einen schnellen Pfad nehmen, der den Compositor durchläuft oder umgeht.

  • Wer für solche frameweise Analysen ffmpeg nutzt, kann mit ffmpeg -skip_frame nokey -i file -vsync 0 -frame_pts true out%d.png die Anzeigezeit jedes einzelnen Frames eines Videos erhalten. Das ist genauer, als einfach nur Frames zu dumpen und die Zeitstempel auszurechnen.
    Ähnliches geht auch im Webbrowser, wenn man ein Video abspielt und requestVideoFrameCallback() verwendet. Wenn der Computer allerdings nicht schnell genug alle Frames dekodieren kann, muss man eventuell .playbackRate senken.
    Dass Wayland auf einem 144-Hz-Bildschirm im Durchschnitt etwa 6,5 ms langsamer ist als X11 und dieser Unterschied fast genau einer Bildaktualisierung entspricht, muss kein Zufall sein. Wenn die Latenz fast 1/144 Sekunde beträgt, könnte sie auf einem normalen 60-Hz-Monitor 1/60 Sekunde betragen. Ohne Training ist das bewusst schwer wahrzunehmen, aber die meisten können es trotzdem „fühlen“, auch wenn sie es nicht erklären können.

    • Meine Vermutung ist, dass die „echten“ Werte eher bei 2,5 Frames und 3,5 Frames liegen. Wegen der zufälligen Phasenlage zwischen dem Moment, in dem die Maus bewegt wird, und der Bildaktualisierung kommt im Mittel ein halber Frame hinzu, dazu dann 2 oder 3 Frames bis zur Cursor-Bewegung. Nimmt man in jeder Gruppe die niedrigen Ausreißer heraus, liegt man ziemlich nah an diesen Werten.
      Natürlich ist für viele Nutzer auch eine Maus-Abfragerate von 125 Hz ein Störfaktor, aber hier wurde eine 1-KHz-Maus verwendet.
      Ein Unterschied von 7 ms ist nicht schön, aber 16,6 ms werden schon ziemlich erheblich. Ich persönlich finde, Computer sollten auf 1,6 Frames Latenz hinarbeiten: ein halber Frame zufällige Phasenlage, ein Frame und ein wenig Verarbeitungszeit.
    • Terminals mit niedriger Latenz bringen selbst bei einfachen Dingen wie Tippen spürbare Verbesserungen.
    • Es wirkt fast sicher so, als wäre zwischen Mausbewegung und Bildschirm eine zusätzliche gepufferte Frame eingefügt worden. Vertikale Synchronisation kann so etwas verursachen, aber auch mit Double Buffering sollte vertikale Synchronisation möglich sein.

  • Die Ergebnisse werden je nach Compositor, GPU und Einstellungen unterschiedlich ausfallen. Unter X11 gibt es faktisch nur eine einzige X-Server-Implementierung, die auf Linux-Desktop-Systemen verwendet wird, daher sind solche Unterschiede dort geringer.
    Bei vielen Compositor-/GPU-Kombinationen kann es weiterhin Probleme geben, keine Hardware-Cursor-Ebene zu bekommen, und dann können solche Latenzunterschiede durchaus auftreten.

  • Heute habe ich gelernt, dass Wayland schon 16 Jahre alt ist. In ein paar Jahren wird Wayland so alt sein wie X, als Wayland erschien, und trotzdem scheint es noch immer als mittelmäßig oder schlechter als X zu gelten.

    • X wurde erstmals im Juni 1984 veröffentlicht und Wayland erschien erstmals 2008, also wäre Wayland erst im Jahr 2032 gleich alt. Wenn Leute sich darüber beschweren, Wayland sei mittelmäßig oder „nicht so gut wie X“, meinen sie damit meist, dass Wayland $very_specific_feature nicht unterstützt oder dass der proprietäre Treiber ihres Grafikkartenherstellers unter Wayland nicht ausreichend getestet ist und sie das frustriert.
      Etwa 99,999 % dieser Beschwerden kommen von Leuten, die 1) nicht selbst daran arbeiten, 2) weder Interesse noch Fähigkeit haben, daran zu arbeiten, und 3) nicht verstehen oder nicht akzeptieren, dass Wayland- und X-Entwickler größtenteils dieselben Personen sind und diese keine Lust mehr haben, an X11 zu arbeiten.
      Ich habe in dieser Debatte kein besonderes Eigeninteresse, aber ich bin es leid zu sehen, wie Leute sich über Wayland beschweren, während sie Software benutzen, die ihnen kostenlos gegeben wurde. Wenn es wirklich so viele Beschwerden über Wayland gäbe, hätte man sich längst zusammenschließen können, um X zu warten und zu verbessern, und falls die Beschwerden und Theorien zuträfen, hätte man Wayland vielleicht hinter sich lassen können.
      Seltsamerweise ist X Open Source und kann jederzeit geforkt werden; mit X.org aus XFree86 gibt es dafür sogar ein Beispiel. Trotzdem lassen die Befürworter es verstauben und tragen nichts zur Wartung bei.
      Ein Ergebnis nach dem Motto „Wayland ist nicht so gut wie X, deshalb haben wir einen modernisierten X-Fork gebaut, den jeder nutzen kann“ würde ich mir durchaus mit Interesse ansehen.
    • Nein, stimmt nicht. X stammt aus dem Jahr 1984: https://www.talisman.org/x-debut.shtml
      Das heißt, Wayland ist erst bei etwa 66 % des Alters angekommen, das X hatte, als Wayland erschien, und bis zum gleichen Alter braucht Wayland noch einmal 50 % seiner bisherigen Lebensdauer.
    • Wenn X 40 Jahre alt ist und Wayland 16, dann beträgt der Unterschied 24 Jahre. Also haben Wayland-Compositoren noch 8 Jahre Zeit, die Probleme auszubügeln.
      Ich nutze aktuell Wayland unter Plasma 6 und es funktioniert für mich gut genug, aber ich habe keine besonderen Anforderungen und weiß daher zum Beispiel nicht, wie gut Screenreader funktionieren.
    • Anders betrachtet bedeuten diese Zahlen auch, dass in ein paar Jahren der Zeitpunkt für einen Nachfolger von Wayland gekommen sein könnte. Er könnte aus demselben Grund entstehen wie Wayland, nämlich weil es zu wenige Leute gibt, die Legacy-Software warten wollen.
      Bis dahin wird der Browser-Frontend-Stack den Desktop meiner Einschätzung nach vollständig verschlungen haben. Es war ja ohnehin nicht so, dass für Linux besonders viele neue Desktop-Apps erschienen wären.
    • Wayland erschien ungefähr zur gleichen Zeit wie der Compositor von Windows Vista. Wenn man großzügig annimmt, dass es erst mit der nächsten Version, Windows 7, einen „guten und stabilen“ Compositor gab, dann liegt Wayland gegenüber Windows 13 Jahre zurück.

  • Es überrascht mich nicht, dass Versuche, eine funktionierende Lösung neu zu schreiben, weil sie „moderner, leichter zu warten und zukunftssicher“ sein soll, meistens nicht so ausgehen. In der Regel wird es langsamer, die Latenz steigt, und nur schnellere Hardware trägt das Ganze, nicht eine schnellere Software.
    Es wirkt, als würde alle 20 Jahre eine neue Generation immer schwächer werden, weil sie sich verwöhnt auf Abstraktionen stützt, die die vorige Generation unter großen Mühen geschaffen hat. Nach etwa drei Generationen von Softwareentwicklern bleiben dann nur noch Bibliotheks-/Framework-Aufrufer übrig, und fast niemand versteht noch wirklich etwas von Performance und Optimierung.

    • Meine Erfahrung ist anders. Nachdem ich mehrere Rechner auf KDE 6 aktualisiert und dabei auf Wayland umgestellt habe, haben sich die allgemeine Reaktionsfähigkeit und die Spritzigkeit des Systems spürbar verbessert.
      Wayland fehlen im Vergleich zu X11 zwar noch Funktionen, aber wegen seiner anderen Vorteile bin ich bereit, diesen Kompromiss einzugehen.
    • Früher hatten Computer zwar geringere Latenzen, dafür führte auf vielen Betriebssystemen schon ein abgestürztes Programm dazu, dass das gesamte OS nicht mehr reagierte und man den kompletten Rechner neu starten musste.

  • Mehrere Wayland-Compositoren haben große Probleme mit Tastaturen, Mäusen und anderen Eingabegeräten. Das liegt daran, dass die Wayland-Spezifikation und die Referenzimplementierung beschlossen haben, solche Dinge nicht zu unterstützen. Deshalb wählt jeder Wayland-Compositor andere Lösungen.
    Gängige Optionen sind libei und libinput, aber oft werden „fortgeschrittene“ Maus-/Tastatureingaben überhaupt nicht unterstützt. weston ist so ein Beispiel. Man kann überhaupt nicht wissen, ob bestimmte Linux-Software in einer bestimmten Wayland-Umgebung funktioniert, und die Fragmentierung ist gravierend.
    Unter X gibt es tatsächlich eine starke X11-Referenz, die praktisch alles implementiert, sodass man sicher sein kann, dass etwas, das an einer Stelle funktioniert, auch anderswo funktioniert.
    Sogar nach 12 Jahren gibt es immer noch keinen einzigen Wayland-Compositor, der Screenreader für Sehbehinderte unterstützt. Das ist Spielzeugniveau.

    • Ich habe gehört, dass auch die Unterstützung für Farbkalibrierung fehlt. Soweit ich gelesen habe, gibt es für Kalibrierungs-Apps nicht einmal eine Möglichkeit zu steuern oder zu wissen, welche Kalibrierung angewendet wird, während gemessen wird. Außerdem gibt es weiterhin Client-Side-Window-Decorations, womit die Chance vertan wurde, ein altes Sicherheitsloch zu schließen.
      Daher ist es nicht gut für Spiele, nicht gut für professionelle Grafikarbeit und nicht gut für Menschen mit Sehschwäche. Am Ende heißt das: Für Nutzer, die sich auch nur ein wenig von den Erstellern unterscheiden, ist es meist nicht gut.
      Aber vielleicht hat es immerhin Screen Tearing reduziert, das ich selbst nie bewusst wahrgenommen habe.
    • Nachdem ich von macOS zu Windows gewechselt bin, bin ich letztlich bei Windows geblieben und nutze meine Freizeit als Entwickler nun dafür, die Power-User-/Entwickler-Erfahrung im Ökosystem der Tiling Window Manager unter Windows zu verbessern: https://github.com/LGUG2Z/awesome-komorebi
      Eines der großartigen Ergebnisse dort ist, dass Leute auf diesem Ökosystem Workflows für Barrierefreiheit aufbauen. Eine Person steuert ihren gesamten Desktop per Sprachsteuerung über einen Tiling Window Manager: https://youtu.be/fiPJLmhnnXM
    • Dass „fortgeschrittene Maus-/Tastatureingaben überhaupt nicht unterstützt werden“, klingt eher so, als würde man die falsche Seite beschuldigen. Man sollte sich die Unternehmen ansehen, die solche Peripheriegeräte herstellen und keine Linux-Treiber bereitstellen.
    • Was fehlt bei Orca unter Wayland in GNOME?

  • Wenn die GPU stark ausgelastet ist, zum Beispiel bei Aufgaben wie Stable-Diffusion-Inferenz, entstehen große Latenzspitzen. Ich habe keinen A/B-Test mit X11 gemacht, aber ich kann mich nicht erinnern, dass das früher so war
    Eine zusätzliche Verzögerung von nur einem Frame ist schon nicht gut, aber die gelegentlich auftretenden Latenzspitzen sind wirklich extrem nervig

    • Besonders in Situationen, in denen es zu Thrashing zwischen VRAM und Systemspeicher kommt, kann das offenbar immer noch passieren. Ich frage mich aber, ob versucht wurde, die Priorität des Stable-Diffusion-Prozesses zu senken

  • Cursor-Eingabelatenz ist ein Störfaktor, der die Zufriedenheit mit einer Anwendung oder einem Betriebssystem ständig untergräbt
    Latenz beim Textcursor in der IDE? Inakzeptabel
    Latenz beim Textcursor in der Shell? Inakzeptabel
    Latenz beim Mauszeiger in der GUI? Inakzeptabel
    Alles davon ist ein sofortiges Ausschlusskriterium

    • Das ist einer der Bereiche, in denen macOS schon immer herausragend war, und das reicht bis zum klassischen Mac OS zurück
      Selbst System 1, das vor über 40 Jahren auf nahezu unvorstellbar schwacher Hardware lief, stellte Cursor-Reaktionsfähigkeit über alles andere und war damit der Konkurrenz voraus. Die Grundlage von heutigen Betriebssystemen und UIs ist zwar zu 100 % anders, aber diese Priorität gilt weiterhin
    • Es ist erschreckend, dass das so schlecht ist. Gerade unter Linux umso mehr. Sollte Mausbewegung nicht selbstverständlich Vorrang vor allem anderen haben? Nicht einmal das Hervorheben des Elements unter dem Mauszeiger sollte den Mauscursor selbst langsamer machen
      Ich hatte kürzlich eine extreme Verlangsamung des Mauszeigers mit der Kombination aus KDE/Plasma 6, X11 und NVidia. Mir fiel besonders auf, dass es über Browser-Tabs schlimmer wurde
      Für alle mit demselben Problem: Die Lösung war, OpenGL flipping zu deaktivieren. Ich habe absolut keine Ahnung, was OpenGL flipping macht, aber nachdem ich es in nvidia-settings und in /etc/X11/xorg.conf deaktiviert hatte, war das Problem behoben
      Es wäre schön, wenn jemand erklären könnte, warum das so ist oder warum das nicht die Standardeinstellung ist

  • Tolle Arbeit. Es wäre vermutlich sinnvoll, das Experiment mit einer sehr niedrigen Bildwiederholrate des Monitors zu wiederholen, zum Beispiel 30 Hz
    Wenn Wayland tatsächlich immer einen Frame langsamer als X11 ist, müsste sich das viel leichter beobachten lassen

  • Ich habe noch eine etwas andere persönliche Beschwerde. Als ich anfing, Linux zu benutzen, wurde der Desktop per Software composited. Vermutlich zeichnete die CPU die UI in den RAM und blitete sie dann in den GPU-Framebuffer; ich nehme an, so wurde das schon sehr lange gemacht
    Mit Compositorn, inklusive X11-Composite, und als GPU-Renderer in Mode kamen, wurde die Latenz schrecklich und lag buchstäblich im Bereich von mehreren hundert ms. Das erschien mir seltsam, weil ich mit DOS-Spielen aufgewachsen bin und solche Probleme dort nicht hatte
    Mit der Zeit wurde es besser, aber ich bin mir nicht sicher, ob wir jemals wieder zum goldenen Zeitalter des CPU-Renderings zurückgekehrt sind