Die Zukunft von X



  • nman schrieb:

    Begründe: Die Architektur ist einfach, elegant und extrem flexibel.

    Ich würde gerne deinen Einblick in X verstehen, daher nochmal,
    was macht die Architektur von X einfach, elegant und extrem flexibel?

    Eine Anwendung direkt für die xlib zu programmieren ist IMO jedenfalls kein Spaß.
    Unter elegant stelle ich mir etwas anderes vor, z.b. so etwas wie QT.



  • X Frage schrieb:

    Eine Anwendung direkt für die xlib zu programmieren ist IMO jedenfalls kein Spaß.
    Unter elegant stelle ich mir etwas anderes vor, z.b. so etwas wie QT.

    Hu? Die Architektur ist toll, nicht das XLib-API. Im Video wird ja sogar vom frischen API erzählt. (Btw, Du kannst doch ohne weiteres QT unter X verwenden, oder etwa nicht?)

    Elegant ist das wunderschöne Layering von X und die damit einhergehende Netzwerktransparenz, die jetzt auch Sachen wie DMX etc. ganz leicht möglich macht.

    Sieh Dir einfach mal das Video an, wenn Dich das Thema interessiert.



  • nman schrieb:

    Ach, das ist doch FUD. Du bezahlst nicht für die Netzwerktransparenz sondern für jahrzehntelangen Entwicklungsstillstand in XFree86.

    Ok.

    nman schrieb:

    Das Ding ist nunmal ein Dinosaurier aus einer anderen Welt und eigentlich für andere Einsätze gedacht, was man z.B. daran sieht, dass es keinen grundlegendes ALT+TAB gibt

    Sowas ist einfach keine Sache des X-Servers.

    Sondern? Für mich stellt es sich so dar:
    Ein einfache Anwendung, z.B. ein Fullscreen-Spiel kann den Input "grabben", damit wird dann nichts weitergeleitet, nicht mal an den Windowmanager.
    Sollte sich also der Kernel darum kümmern? Oder die Software? Sie tut es oftmals nicht (z.B. ID Spiele). Jedes Multitasking-System sollte eine Möglichkeit außer dem Stromstecker haben, um unpreviligierte aber nicht-kooperierende Anwendungen zu beenden. Das gilt auch für die Benutzerschnittstelle.

    nman schrieb:

    oder eine falsch geschriebene Anwendung das ganze graphische System lahm legt.

    Dann ist das eine Fehlimplementierung die sich fixen lässt.

    Aber anscheinend nicht so ohne weiteres.

    nman schrieb:

    Selbst für RemoteDesktop ist VNC performanter als natives xlib.

    Nativ und unkomprimiert XLib übers Netz verwendet man ja auch nicht.

    Ok.

    nman schrieb:

    X.org wegzuwerfen wäre Wahnsinn, typisches "Wir reimplementieren jetzt mal alles, weil wir das auch besser können", das soviele FOSS-Projekte kaputtmacht. Altes zu erweitern und auszubessern macht zwar weniger Spaß als es einfach wegzuwerfen und neu zu beginnen, aber es ist in manchen Fällen trotzdem sinnvoller.

    Aber manchmal ist die Grenze des Sanierbaren auch einfach mal erreicht.
    Weil sich die Hardware ändert und der Einsatzbereich.

    Ich hoffe ja, dass die geplante Auslagerung in Linux nicht nur beim Modesetting bleibt, sondern möglichst viel Grafikbeschleunigung da reinkommt. Die größte Hürde für Alternativen ist ja nun einmal der Treibersupport.

    Das Video schau ich mir mal in Ruhe an.



  • nman schrieb:

    Elegant ist das wunderschöne Layering von X und die damit einhergehende Netzwerktransparenz, die jetzt auch Sachen wie DMX etc. ganz leicht möglich macht.

    Das mag ja alles elegant durchdacht sein in der Theorie, genau wie GNUs Hurd.

    Nur wäre es eben auch mal schön, wenn davon bei mir auf dem Desktop auch mal was leistungsmäßig bei rauskäme.



  • GNU-Fan schrieb:

    Sondern? Für mich stellt es sich so dar:
    Ein einfache Anwendung, z.B. ein Fullscreen-Spiel kann den Input "grabben", damit wird dann nichts weitergeleitet, nicht mal an den Windowmanager.
    Sollte sich also der Kernel darum kümmern? Oder die Software? Sie tut es oftmals nicht (z.B. ID Spiele). Jedes Multitasking-System sollte eine Möglichkeit außer dem Stromstecker haben, um unpreviligierte aber nicht-kooperierende Anwendungen zu beenden. Das gilt auch für die Benutzerschnittstelle.

    Ach so meintest Du das. Ganz ehrlich? Das ist so eine Kleinigkeit, dass ich mir darum weder Sorgen noch Gedanken mache.

    Aber anscheinend nicht so ohne weiteres.

    Mal abwarten, die X.org-Leute lassen teilweise ja wirklich keinen Stein auf dem anderen. Das Image von X.org als das neue XFree86 ist wirklich nicht gerechtfertigt.

    Aber manchmal ist die Grenze des Sanierbaren auch einfach mal erreicht.
    Weil sich die Hardware ändert und der Einsatzbereich.

    Ich hoffe ja, dass die geplante Auslagerung in Linux nicht nur beim Modesetting bleibt, sondern möglichst viel Grafikbeschleunigung da reinkommt. Die größte Hürde für Alternativen ist ja nun einmal der Treibersupport.

    Auch dazu wird einerseits im Video ein bisschen was gesagt, andererseits ist da auch Cairo recht interessant.



  • nman schrieb:

    GNU-Fan schrieb:

    Sondern? Für mich stellt es sich so dar:
    Ein einfache Anwendung, z.B. ein Fullscreen-Spiel kann den Input "grabben", damit wird dann nichts weitergeleitet, nicht mal an den Windowmanager.
    Sollte sich also der Kernel darum kümmern? Oder die Software? Sie tut es oftmals nicht (z.B. ID Spiele). Jedes Multitasking-System sollte eine Möglichkeit außer dem Stromstecker haben, um unpreviligierte aber nicht-kooperierende Anwendungen zu beenden. Das gilt auch für die Benutzerschnittstelle.

    Ach so meintest Du das. Ganz ehrlich? Das ist so eine Kleinigkeit, dass ich mir darum weder Sorgen noch Gedanken mache.

    Naja, es fällt schon auf, weil es ja der ganzen Idee von Rechtemanagement, Prozesslaufzeitzuweisung, Multitasking eklatant widerspricht.
    Bei MS-Dos hatte es mich auch nicht gestört 😉



  • GNU-Fan schrieb:

    nman schrieb:

    Elegant ist das wunderschöne Layering von X und die damit einhergehende Netzwerktransparenz, die jetzt auch Sachen wie DMX etc. ganz leicht möglich macht.

    Das mag ja alles elegant durchdacht sein in der Theorie, genau wie GNUs Hurd.

    Der Unterschied ist ja eben genau der, dass X.org fertig ist und funktioniert und GNU Hurd nicht. X.org hat eine handlungsfähige Administration und Hurd nicht. X.org hat Entwickler, Hurd nicht. Kurz: X.org lebt, Hurd ist allerbestenfalls untot.

    Dämliche Analogie: Würdest Du Linux jetzt wegwerfen, wenn die gängige (völlig fehlgeleitete Meinung) die wäre, dass Kernel-Module böse sind und abgeschafft werden müssen und irgendwas Neues verlangen? X ist nicht aufgrund seiner Eleganz nicht performant, der Overhead den X mit sich bringt, ist völlig vernachlässigbar.

    Nur wäre es eben auch mal schön, wenn davon bei mir auf dem Desktop auch mal was leistungsmäßig bei rauskäme.

    Eleganz und schönes Design wird Dir keine Performance bringen. Andererseits wird der Verzicht darauf auch nichts schneller machen.



  • GNU-Fan schrieb:

    Naja, es fällt schon auf, weil es ja der ganzen Idee von Rechtemanagement, Prozesslaufzeitzuweisung, Multitasking eklatant widerspricht.
    Bei MS-Dos hatte es mich auch nicht gestört 😉

    Ja, aber bei MSDOS war das ein riesiges konzeptionelles Problem, hier ist es ein Implementierungsdetail. Zugegeben, kein völlig triviales, aber auch kein Showstopper.



  • nman schrieb:

    X ist nicht aufgrund seiner Eleganz nicht performant, der Overhead den X mit sich bringt, ist völlig vernachlässigbar.

    Aber woran liegt es denn, deiner Meinung nach, dass z.B. das Bewegen eines mittelgroßen Fensters über den Bildschirm immer noch nicht so butterweich ist, wie es z.B. WinXP selbst auf mehrere Jahre alten Rechnern hinbekommt.
    Sind das alles Treiberfehler?



  • GNU-Fan schrieb:

    Sind das alles Treiberfehler?

    In den vergangenen Jahren wurde X ziemlich intensiv auf Durchsatz optimiert, wird eben Zeit fuer ein bisschen Latenz-Tuning.

    Aber dass unelegante Designs nicht zwangsläufig gut sein müssen, sieht man ja an Windows recht schön. Das stinkt nämlich diesbezüglich immer noch ziemlich gegen OS X ab. Fenster verschieben ist auf meinem Sub-GHz G4-Powerbook unter MacOS X flüssiger als auf dem hochgezüchteten Rechner meiner Freundin unter Windows. (Auch Exposé und Co. sind immer wieder ein gutes Beispiel.)



  • @nman
    Guter Talk! Wollte mir den eigentlich schon mal ansehen, aber irgend wie hatte ich keine Zeit und es dann vergessen. Hab es jetzt aber nachgeholt.

    GNU-Fan schrieb:

    nman schrieb:

    X ist nicht aufgrund seiner Eleganz nicht performant, der Overhead den X mit sich bringt, ist völlig vernachlässigbar.

    Aber woran liegt es denn, deiner Meinung nach, dass z.B. das Bewegen eines mittelgroßen Fensters über den Bildschirm immer noch nicht so butterweich ist, wie es z.B. WinXP selbst auf mehrere Jahre alten Rechnern hinbekommt.
    Sind das alles Treiberfehler?

    Neulich habe ich mich mit jemandem unterhalten, der sich mit X11 und dem ganzen Zeugs ein wenig auskennt. Ein Problem war wohl, dass die Fenster in X11 früher so gemalt wurden, dass das Fenster von der Anwendung auf den Bildschirm gemalt wurde und der Windowmanager hat dann die Dekorationen drumrum gemalt. Das kann vielleicht zu dem Problem beigetragen haben. Aber mittlerweile gibt es in X11 eben Buffer für die Fenster, in die der Windowmanager auch reinmalt.

    Aber schau Dir einfach den Vortrag an. X11 wurde eben 13 Jahre lang liegen gelassen und langsam tut sich ja auch wieder etwas. Außerdem erwähnen die auch, dass die Netzwerktransparenz nicht wirklich etwas kostet, da der X11 auch über shared Memory kommunizieren kann.

    Und naja, es gibt ja auch zahlreiche Versuche X11 zu ersetzen. Aber eine Jahrzehnte lang etablierte Software zu ersetzen ist eben nicht wirklich realistisch. Sowohl die Treiber- als auch die Anwendungsentwickler müssten halt sehr viel Knowhow und Code wegwerfen. Jeder wird versuchen die Kosten zu scheuen.

    Achso um mal wieder Ontopic zu sein: Das wird auch das Problem für Haiku sein, wenn die keine kompatible API haben. Wer schreibt Software für Haiku?



  • GNU-Fan schrieb:

    nman schrieb:

    X ist nicht aufgrund seiner Eleganz nicht performant, der Overhead den X mit sich bringt, ist völlig vernachlässigbar.

    Aber woran liegt es denn, deiner Meinung nach, dass z.B. das Bewegen eines mittelgroßen Fensters über den Bildschirm immer noch nicht so butterweich ist, wie es z.B. WinXP selbst auf mehrere Jahre alten Rechnern hinbekommt.
    Sind das alles Treiberfehler?

    Ich weis echt nicht was du meinst. Als ich deinen Beitrag durchgelesen habe, habe ich FF von meinem Laptop Monitor auf den zweiten verschoben und wieder zurueck. Alles laeuft wunderbar und fluessig. Ich hab eher das Gefuehl das die Fenster unter Windows traeger sind (hab die letzen 4 Tage unter Windows gearbeitet).

    Ich hab hier eine Intel Grafik und die neuesten Treiber.

    Grade auf meinem anderem Laptop mit Nvidia Go versucht, funktioniert auch alles super.

    GNU-Fan schrieb:

    Sondern? Für mich stellt es sich so dar:
    Ein einfache Anwendung, z.B. ein Fullscreen-Spiel kann den Input "grabben", damit wird dann nichts weitergeleitet, nicht mal an den Windowmanager.
    Sollte sich also der Kernel darum kümmern? Oder die Software? Sie tut es oftmals nicht (z.B. ID Spiele). Jedes Multitasking-System sollte eine Möglichkeit außer dem Stromstecker haben, um unpreviligierte aber nicht-kooperierende Anwendungen zu beenden. Das gilt auch für die Benutzerschnittstelle.

    Dies ist aber ein Fehler der Spieleprogrammierer. Jedes OpenSource Spiel funktioniert einwandfrei. Ein Spiel sollte halt den Input nicht "grabben", sind wir hier zu DOS Zeiten?

    Ein Workaround ist es einen neue X-Session zu starten und darin das Spiel starten. Alt-Strg-F1/F12 oder Alt-Strg-Back sollte immer funktionieren.

    On Topic: Hab mir die ersten 20min vom Haiku-Video angeschaut. Es hoert sich ein wenig wie Windows an: Einheitliches Look&Feel, alle Bibliotheken bereits integriert, kein Paketmanagment(?), es soll einfach zu benutzen sein. Die restlichen Features sind ja echt super.



  • DEvent schrieb:

    Dies ist aber ein Fehler der Spieleprogrammierer.

    Hier widerspreche ich vehement.
    Ein System darf niemals die Kooperation einer Nicht-Admin Anwendung voraussetzen, um störungsfrei zu arbeiten. Die Anwendung soll Laufzeit, ihren Speicher und auch Zugriff auf die Benutzereingabe haben. Aber eben nicht so, wie die Anwendung es für richtig hält, sondern das System weist es nach den Wünschen des Admins zu. Punkt.

    DEvent schrieb:

    Ein Spiel sollte halt den Input nicht "grabben", sind wir hier zu DOS Zeiten?

    Eben. Bis Win16 gab es ja das kooperative Multitasking, bei der eine Anwendung regelmäßig die Kontrolle an das System zurückgeben musste. Mit Umstieg auf 32S erhielt dann das OS immer mehr Authorität. Einen Bypass zum Taskmanager zu haben war dann nur die logische Konsequenz.

    Es ist natürlich etwas schwer, bei GNU/Linux die Verantwortung zuzuweisen, da ja Videosystem und Betriebsystem nicht untrennbar verbunden sind. Deshalb schrieb ich immer System. Wenn nun aber X für sich in Anspruch nimmt, unter root zu laufen, dann ist m.E. damit auch die entsprechende Verantwortung verbunden.
    Das darf dann nicht an normale Anwendungen blind weitergegeben werden.

    DEvent schrieb:

    Ein Workaround ist es einen neue X-Session zu starten und darin das Spiel starten. Alt-Strg-F1/F12 oder Alt-Strg-Back sollte immer funktionieren.

    Eben das funktioniert nicht, wenn gegrabscht wurde ohne loszulassen. Und dass das nicht einfach zu beheben ist, das stört mich.

    Hier ist übrigens ein Beispiel:
    Bitte mit einem blockierten System rechnen, falls ihr keinen SSH Zugriff o.Ä. habt.

    #include <X11/Xlib.h>
    int main() 
    {
      Display *disp;
      Window win;
      XEvent e;
      int screen; 
    
      disp=XOpenDisplay(NULL);
      screen=DefaultScreen(disp);
      win=XCreateSimpleWindow(disp, RootWindow(disp, screen), 10, 10, 100,
    100, 1, BlackPixel(disp, screen), WhitePixel(disp, screen));
    
      XSelectInput(disp, win, ExposureMask | KeyPressMask);
      XMapWindow(disp, win);
      XNextEvent(disp, &e);
      XGrabKeyboard(disp, win, True, GrabModeSync, GrabModeSync,
    CurrentTime);
      sleep(6);
      XCloseDisplay(disp);
      return 0;
    }
    

    @Mods:
    Vielleicht eine Threadaufspaltung? Da ich das Thema eigentlich sehr interessant finde.



  • GNU-Fan: Habe mal gesplittet, habe aber leider erst ab Mittwoch wieder Zeit was zu posten.



  • X darf doch meines Wissens nach sogar vom Usermode aus direkt auf die Hardware zugreifen, was vom Kernel aus als Ausnahme nur für X gestattet ist.



  • Das Modesetting soll ja wie gesagt in nächster Zeit in den Kernel kommen, zumindest beim Linuxport. Dann kann endlich das System schon beim Hochfahren in der gewünschten Auflösung starten und es gibt nicht jedesmal ein Flackern bei Anmelden.



  • GNU-Fan schrieb:

    DEvent schrieb:

    Ein Workaround ist es einen neue X-Session zu starten und darin das Spiel starten. Alt-Strg-F1/F12 oder Alt-Strg-Back sollte immer funktionieren.

    Eben das funktioniert nicht, wenn gegrabscht wurde ohne loszulassen. Und dass das nicht einfach zu beheben ist, das stört mich.

    Ganz dumme Frage, aber wie oft passiert Dir das in der Praxis? Ich hatte das bis dato noch nie (ehrlich). Ich sage nicht, dass das sehr schön ist, aber es ist kein Grund gegen X.



  • nman schrieb:

    Ganz dumme Frage, aber wie oft passiert Dir das in der Praxis? Ich hatte das bis dato noch nie (ehrlich). Ich sage nicht, dass das sehr schön ist, aber es ist kein Grund gegen X.

    Ich hatte das früher öfter. Meistens wenn man im Netscape Navigator (ich sag doch früher) ein Menü aufgemacht hat.



  • Mich störts insbesondere beim Zocken.
    Wenn ich mal zwischendurch was auf dem Desktop machen muss, ich habe nun mal keinen zweiten Monitor. Manche Spiele kooperieren, mal mehr, mal weniger -- viele tun es nicht.



  • nman schrieb:

    GNU-Fan schrieb:

    DEvent schrieb:

    Ein Workaround ist es einen neue X-Session zu starten und darin das Spiel starten. Alt-Strg-F1/F12 oder Alt-Strg-Back sollte immer funktionieren.

    Eben das funktioniert nicht, wenn gegrabscht wurde ohne loszulassen. Und dass das nicht einfach zu beheben ist, das stört mich.

    Ganz dumme Frage, aber wie oft passiert Dir das in der Praxis? Ich hatte das bis dato noch nie (ehrlich). Ich sage nicht, dass das sehr schön ist, aber es ist kein Grund gegen X.

    Noch nie ein Quake-3-Engine-Spiel gespielt? 😉

    Die grabschen dir sogar alles weg, wenn du das Spiel im Fenstermodus laufen lässt (was diesen irgendwie witzlos macht) und stürzen auch schon manchmal ab. War für mich kein Problem, als Xgl noch nicht so recht mit GLX wollte, weil ich dann den bereits angesprochenen zweiten X-Server benutzte, aber jetzt nervt's schon.

    Mir würde es völlig reichen, wenn man einem Programm dieses Verhalten explizit verbieten könnte. Hat jemand genug Ahnung von X um darüber eine verlässliche Aussage zu treffen?


Anmelden zum Antworten