Weil Xorg nicht weiß, was sich in einem Fenster befindet. Xorg arbeitet wie ein kariertes Blatt Papier. Einfaches Beispiel. Du scrollst 10 Pixel nach unten. Unter X wird das Bild neu aufgebaut. Unter Wayland wird das Bild verschoben und nur die 10 neuen Pixel werden aufgebaut. Das Verschieben kann sogar die Grafikkarte alleine, sodass das Verschieben dann sehr schön flüssig ist. Noch ein Beispiel. Du hast einen 4k Monitor neben einem gleich großem normalen Monitor stehen und verschienst ein Fenster vom einem Monitor auf den anderen. Das geht mit Xorg gar nicht, ohne dass die die Größe ändert.
"Unter Wayland wird das Bild verschoben und nur die 10 neuen Pixel werden aufgebaut.": Es spricht ja vieles für Wayland, aber das überzeugt mich jetzt vollends. Heute Abend probiere ich es aus.
Na ja. Bei aller Begeisterung. Den Unterschied siehst du bei normalen Programmen eigentlich nicht. Also ob es sich lohnt, Wayland auszuprobieren, weiS ich nicht. Im besten Fall ist alles wie vorher. Es ist wohl eher für die Programmierer ein Unterschied.
Ich habe es gerade auf Debian Sid installiert, mit KDE-Plasma, daher lässt es sich mit Xfce, was ich vorher ausschließlich verwendet habe, nicht vergleichen. Es braucht halt deutlich mehr RAM und es fühlt sich alles träger an. Aber gut, das ist wahrscheinlich nicht das Problem von Wayland. Ich teste mal weiter.
Noch ein Beispiel. Du hast einen 4k Monitor neben einem gleich großem normalen Monitor stehen und verschienst ein Fenster vom einem Monitor auf den anderen. Das geht mit Xorg gar nicht, ohne dass die die Größe ändert.
Das ist etwas woran auch Windows nach wie vor kläglich scheitert.
> Unter Wayland wird das Bild verschoben und nur die 10 neuen Pixel werden aufgebaut.
Hast du ne Quelle dafür? Soweit ich weiß stimmt das nämlich nicht. Das Scrollen innerhalb eines Fensters wird vom Toolkit (z. B. Gtk+ oder Qt) erledigt und die bauen den Inhalt neu auf bzw. haben ihre eigene Vorgehensweise um Renderergebnisse zu cachen, die sich nicht groß innerhalb von Xorg (mit Compositing) oder Wayland unterscheiden sollte.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 29. Jan 2018 um 15:36.
OK. Du hast eigentlich schon Recht. Hier ist eine Quelle: https://wayland.freedesktop.org/architecture.html Der Unterschied ist, dass bei Xorg X den Client bittet, sich zu rendern. Unter Wayland zeichnet sich der Client selber. Der Client teilt sein gerendertes Bild Wayland mit, sodass Wayland immer im Bilde ist, was auf dem Bildschirm ist. Auf der Adresse steht aber auch die Sache (wie ich beschrieben hatte), dass nur Änderungen übertragen werden. Du hast schon Recht. Wayland weiß nichts von Scrolling. Ich habe da etwas zu viel interpretiert. Für Wayland sind es einfach nur Pixel. Aber die Idee bleibt, dass Wayland/Weston ein Fenster nach Belieben Hin- und Her schieben (oder sogar verdecken) kann ohne, dass die Anwendung davon etwas mitbekommt. Weil eben Wayland weiß, was im Fenster ist. Bei OpenGL sieht aber alles ganz anders aus. Das muss man auch dazu sagen.
Aber die Idee bleibt, dass Wayland/Weston ein Fenster nach Belieben Hin- und Her schieben (oder sogar verdecken) kann ohne, dass die Anwendung davon etwas mitbekommt.
Das hat man doch unter X11 mit dem Compositor bereits abgedeckt.
Weil Xorg nicht weiß, was sich in einem Fenster befindet. Xorg arbeitet wie ein kariertes Blatt Papier. Einfaches Beispiel. Du scrollst 10 Pixel nach unten. Unter X wird das Bild neu aufgebaut. Unter Wayland wird das Bild verschoben und nur die 10 neuen Pixel werden aufgebaut. Das Verschieben kann sogar die Grafikkarte alleine, sodass das Verschieben dann sehr schön flüssig ist.
Noch ein Beispiel. Du hast einen 4k Monitor neben einem gleich großem normalen Monitor stehen und verschienst ein Fenster vom einem Monitor auf den anderen. Das geht mit Xorg gar nicht, ohne dass die die Größe ändert.
"Unter Wayland wird das Bild verschoben und nur die 10 neuen Pixel werden aufgebaut.":
Es spricht ja vieles für Wayland, aber das überzeugt mich jetzt vollends. Heute Abend probiere ich es aus.
Na ja. Bei aller Begeisterung. Den Unterschied siehst du bei normalen Programmen eigentlich nicht. Also ob es sich lohnt, Wayland auszuprobieren, weiS ich nicht. Im besten Fall ist alles wie vorher. Es ist wohl eher für die Programmierer ein Unterschied.
Ich habe es gerade auf Debian Sid installiert, mit KDE-Plasma, daher lässt es sich mit Xfce, was ich vorher ausschließlich verwendet habe, nicht vergleichen. Es braucht halt deutlich mehr RAM und es fühlt sich alles träger an. Aber gut, das ist wahrscheinlich nicht das Problem von Wayland.
Ich teste mal weiter.
Ist natürlich die Frage, ob man das braucht. Was immer schlecht war, muss vielleicht nicht immer besser werden.
> Unter Wayland wird das Bild verschoben und nur die 10 neuen Pixel werden aufgebaut.
Hast du ne Quelle dafür? Soweit ich weiß stimmt das nämlich nicht. Das Scrollen innerhalb eines Fensters wird vom Toolkit (z. B. Gtk+ oder Qt) erledigt und die bauen den Inhalt neu auf bzw. haben ihre eigene Vorgehensweise um Renderergebnisse zu cachen, die sich nicht groß innerhalb von Xorg (mit Compositing) oder Wayland unterscheiden sollte.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 29. Jan 2018 um 15:36.OK. Du hast eigentlich schon Recht. Hier ist eine Quelle: https://wayland.freedesktop.org/architecture.html
Der Unterschied ist, dass bei Xorg X den Client bittet, sich zu rendern. Unter Wayland zeichnet sich der Client selber. Der Client teilt sein gerendertes Bild Wayland mit, sodass Wayland immer im Bilde ist, was auf dem Bildschirm ist.
Auf der Adresse steht aber auch die Sache (wie ich beschrieben hatte), dass nur Änderungen übertragen werden. Du hast schon Recht. Wayland weiß nichts von Scrolling. Ich habe da etwas zu viel interpretiert. Für Wayland sind es einfach nur Pixel. Aber die Idee bleibt, dass Wayland/Weston ein Fenster nach Belieben Hin- und Her schieben (oder sogar verdecken) kann ohne, dass die Anwendung davon etwas mitbekommt. Weil eben Wayland weiß, was im Fenster ist.
Bei OpenGL sieht aber alles ganz anders aus. Das muss man auch dazu sagen.
Das hat man doch unter X11 mit dem Compositor bereits abgedeckt.