warum ist X(free/org) so langsam? [Archiv]

Archiv verlassen und diese Seite im Standarddesign anzeigen : warum ist X(free/org) so langsam?

Gast

2006-03-06, 22:58:46

hallo,
um eins gleich vorweg zu nehmen: das soll kein flamethread sein. ich möchte nur den genauen, sachlichen, technischen grund herausfinden, der mich seit jahren von linux abhält. wer also dazu neigt in threads, in denen windows und linux beide erwähnt werden, böse wörter zu benutzen, der darf sich hiermit aufgefordert fühlen zu verschwinden.

ok, ich denke so ziemlich jeder hier hat schon des öfteren von beschwerden über die performance von x gehört. die "standard"-linux-jünger antworten dann immer mit "jaja, das bildest du dir nur ein" oder "bei mir läuft alles super" bis hin zu "windows ist bei mir langsamer". andere kommen dann mit solchen wischiwaschi-aussagen wie "liegt an deiner grafikkarte", "dein system is nicht optimal konfiguriert" und blaah blaaaah blub. das hatte ich zunächst geglaubt, hatte viele verschiedene graka-treiberversionen ausprobiert, mehrere module für den xserver nachinstalliert (unter anderem composite) und es hat sich in den meisten fällen kaum was oder garnichts geändert.

ok, contender1: windows 2000. kompiliert für 386? 486? keine ahnung, aber auf jeden fall alles andere als optimiert. einfach installiert, treiber draufgeschmissen, keine grossartigen gedanken weiter gemacht. "show window contents while dragging" aktiviert und einfach mal ein fenster so wirr und schnell wie möglich herumgezogen. maximale cpu-auslastung war 7% eines p4b 2,4ghz (mit fx5800). das wichtigste dabei: ich würde meine hand dafür ins feuer legen, dass das fenster bei *jedem* frame des monitors (100hz) neu gezeichnet wurde. ich habe eine ganze zeit lang sehr schnelle shooter gespielt und bin daran gewöhnt schnelle veränderungen auf dem monitor wahrzunehmen. und der abstand zwischen den neu gezeichneten fenstern war im vergleich zur bewegungsgeschwindigkeit sehr klein. wirklich klein. spaßeshalber hab ich dann nochmal ein browserfenster mit einem einfachen bitmaphintergrund gebastelt, dass 10x pro sekunde aktualisiert wird. das ganze maximiert und ich kam auf eine cpu-auslastung die sehr regelmässig zwischen 0 und 2% schwankte.

contender2: ein gentoo-system basierend auf dem 2.6.15 kernel mit ck-patchset auf demselben rechner, kompiliert mit -march=pentium4 -O2 (-O3 ist für p4s eher von nachteil). man kann also von einem sehr hohen optimierungsgrad ausgehen. treiberversionen für die fx5800 hatten keinen einfluss auf die performance, hab mich also mit dem aktuellsten begnügt. dri, glx und der ganze ramsch war aktiviert und voll funktionsfähig. zusätzlich hab ich dann noch das "performancewunder" composite installiert.
ergebnis des fenster-rumschiebe-tests mit dem light-styleset von gnome: 35% cpu. aber das wichtigste: das fenster wurde *nicht* mit 100hz aktualisiert. ich konnte mit blossen augen sehen, wie das fenster beim bewegen sprünge machte. die o.g. aktualisierungsseite forderte konstante 9% der cpu.

der test war übrigens nur für meine persönliche 100%ige bestätigung gedacht. ich hatte unter windows *noch niemals*, selbst nicht mit meinem alten p2-400 das gefühl, der desktop, bzw das reine zeichnen und aktualisieren von fenstern, würde *irgendeine* belastung für den rechner darstellen. im gegensatz dazu hatte ich auf *jedem* linux-desktop (es waren einige linux-rechner die ich sah...) bisher so ein ekelhaft schwammiges gefühl.

das ganze endet in 2 fragen:
1. wie kann es sein, dass ein verranzter 6 jahre alter windowsdesktop, der von einem steinzeitlichen compiler für steinzeitliche maschinen kompiliert wurde, so extrem übertrieben viel schneller ist, als die aktuellste version von xorg, von dem aktuellsten compiler mit sse2-unterstützung und diversen anderen optimierungen speziell für einen pentium 4 kompiliert, unterstützt von einem ebenso aktuellen, ebenso kompilierten "low-latency-preemptible" kernel. fragezeichen.
2. wie kann es sein, dass oben genannter, vergleichsweise gut optimierter xorg-desktop nicht in der lage ist, auf einem 2,4 gigaherz p4 mit einer fx5800, der in relativ komplexen 3d-spielen mehrere hundert vollbildframes pro sekunde auf den schirm rendert, ein behindertes kleines unverändertes fenster ohne grössere anstrengung 100mal pro sekunde neu zu zeichnen. fragezeichen.

sorry wenn ich ein bisschen polemisch werde, aber es will mir einfach nicht in den kopf. das ist kein performanceproblem mehr. da ist irgendwas ganz einfach kaputt. nur was? und wann wird es endlich repariert? genau an diesem tage werde ich nämlich endlich zu linux als hauptsystem umsteigen können. und ich werde glücklich sein. aber diese schwammige scheisse ertrage ich nicht. da schlage ich mich lieber weiter mit windows rum.

Spearhead

2006-03-06, 23:10:13

Nur mal etwas zu "Composite": Ich glaube im aktuellen Stadium ist das nicht wirklich performancefördernd, eigentlich mehr dafür gedacht, "Eyecandy" wie Schatten und so zu aktivieren. Ein teil der langsamen Performance wird sicher daran liegen. Denn diese "Sprünge" beim Fensterverschieben bemerke ich hier nicht. (A64 3500+ / 6800 GS)

The_Invisible

2006-03-06, 23:15:02

was ich weiß ist die "zeichen"-engine bei windows direkt im kernel integriert, wogegen es bei "linux" extern vom kernel ist... bei windows vista soll das ja auch ausgelagert werden, mal schaun ob man dort auch was im negativen sinne gegenüber den vorgängern bemerkt

die antwortzeit unter X ist sonst eigentlich nicht so schlecht

bzw
auch in WindowsXP ruckelt es im 2d betrieb wenn man die standard-VGA Treiber hat (das ist übrigens Fakt, sehr arg im explorer bei dateien scrollen bzw markieren mit dem transparenten rahmen)

mfg

Spearhead

2006-03-06, 23:19:21

@The_Invisible: stimmt, das mit dem Standard-Treiber unter XP kann ich bestätigen, auch wenn man das ja nicht oft mitkriegt weil die Graka-Treiber mit das erste sind was man installiert ^^

MadMan2k

2006-03-06, 23:20:36

1. GTK hat ein redraw Problem (zu langsam)
2. Composite macht Redraw unnötig
3. Composite ist aber noch unausgereift und es mangelt an Treibersupport
4. mit AIGLX/XGL steht schon die ablöse von Composite vor der Tür
5. wenn ich Zeit habe gehe in einem Artikel ausführlicher drauf ein

Gast

2006-03-06, 23:23:12

Denn diese "Sprünge" beim Fensterverschieben bemerke ich hier nicht.

dass du sie nicht bemerkst, sagt nicht viel aus ;)
mit sprüngen meine ich auch keine groben hängenbleiber. damit meine ich nur, das fenster wird nicht so oft aktualisiert wie unter windows. das resultiert unter win in einer "weicheren" bewegung. falls hier irgendjemand dem "man kann nicht mehr als 25fps wahrnehmen"-irrglauben anhängt: falsch, man kann bis zu 600fps wahrnehmen.

was ich weiß ist die "zeichen"-engine bei windows direkt im kernel integriert, wogegen es bei "linux" extern vom kernel ist...
die kommunikation zwischen userspace und kernelspace sollte aber eigentlich im nanosekundenbereich stattfinden. es geht ja hier nicht um komplexe rendervorgänge. ein fenster rumschieben, das sind trivialitäten.

auch in WindowsXP ruckelt es im 2d betrieb wenn man die standard-VGA Treiber hat
gute idee, daran hab ich noch garnicht gedacht. ich werd mir mal die windows-performance ohne hardwareunterstützung anschauen.

(das ist übrigens Fakt, sehr arg im explorer bei dateien scrollen bzw markieren mit dem transparenten rahmen)
das wiederum hat nix mit der desktopperformance zu tun, weil dafür daten von der platte geladen werden müssen.

Spearhead

2006-03-06, 23:28:04

dass du sie nicht bemerkst, sagt nicht viel aus ;)
mit sprüngen meine ich auch keine groben hängenbleiber. damit meine ich nur, das fenster wird nicht so oft aktualisiert wie unter windows. das resultiert unter win in einer "weicheren" bewegung. falls hier irgendjemand dem "man kann nicht mehr als 25fps wahrnehmen"-irrglauben anhängt: falsch, man kann bis zu 600fps wahrnehmen.

Mh, dann meinte ich was andres, ich dachte du meintest der Rahmen würde beim ziehen springen. Das sich der Inhalt der Fenster beim verschieben etwas komisch verhält, stimmt wohl

gute idee, daran hab ich noch garnicht gedacht. ich werd mir mal die windows-performance ohne hardwareunterstützung anschauen.

Am besten dann auch noch mal die Linux-Performance OHNE Composite probieren, da wie ManMan2k sagte das ja nicht gut unterstützt wird :)

das wiederum hat nix mit der desktopperformance zu tun, weil dafür daten von der platte geladen werden müssen.

Mh, doch, das hat sehr wohl was mit der Desktop-Performance zu tun wenn sich der Unterschied direkt bemerkbar macht im Vergleich normaler Grafik-Treiber <-> Grakatreiber ;)

Gast

2006-03-06, 23:37:00

Am besten dann auch noch mal die Linux-Performance OHNE Composite probieren, da wie ManMan2k sagte das ja nicht gut unterstützt wird :)

dazu habe ich keine zahlen, ich kann allerdings vom gefühl her sagen dass es sich durch composite doch verbessert hat.

Mh, doch, das hat sehr wohl was mit der Desktop-Performance zu tun wenn sich der Unterschied direkt bemerkbar macht im Vergleich normaler Grafik-Treiber <-> Grakatreiber ;)

hu? ;)
nein ich meinte folgendes: der explorer registriert ja nur die attribute der dateien, die sich im sichtbaren fenster befinden. wenn man jetzt runterscrollt, muss er die festplatte nach grösse, veränderungszeit etc. der bisher nicht sichtbaren dateien fragen.

Spearhead

2006-03-06, 23:43:17

hu? ;)
nein ich meinte folgendes: der explorer registriert ja nur die attribute der dateien, die sich im sichtbaren fenster befinden. wenn man jetzt runterscrollt, muss er die festplatte nach grösse, veränderungszeit etc. der bisher nicht sichtbaren dateien fragen.

uhm, die meisten der Daten frägt er eigentlich anfangs gleich ab, was meinst weswegen es etwas länger dauert wenn man in ein Verzeichniss mit viiiielen kleinen Daten geht ;) Das was er mit der Zeit abfrägt ist dann, wenn aktiv das Icon oder die Vorschau wenn es ein Bild oder ein Video z.b. ist.

Das sind aber normalerweise keine Sachen die irgendeine Auswirkung auf die Performance haben wenn das Verzeichniss eine normale Größe hat. Was in dem Fall eine Auswirkung hat ist eben das Neuzeichnen des Fensters wenn man durch ein Verzeichniss scrollt oder ein Fenster umherzieht. DAS macht sich eben doch bemerkbar im Vergleich Standardtreiber <-> Grakatreiber

Edit: Und ja, auch dieser transparente Rahmen ist halt ein Grafikeffekt der über den Standardtreiber lahmt :)

Gast

2006-03-06, 23:53:33

uhm, die meisten der Daten frägt er eigentlich anfangs gleich ab, was meinst weswegen es etwas länger dauert wenn man in ein Verzeichniss mit viiiielen kleinen Daten geht ;) Das was er mit der Zeit abfrägt ist dann, wenn aktiv das Icon oder die Vorschau wenn es ein Bild oder ein Video z.b. ist.

einerseits hast du wohl recht, andererseits versuche mal folgendes: öffne ein verzeichnis auf einem cd/dvd-laufwerk mit mehr dateien als im explorer pro seite angezeigt werden. lass das laufwerk ausdrehen und scroll dann nach unten. er wird hängen und das laufwerk wieder hochdrehen. irgendwas scheint er also nachzuladen. bei einer minimalen festplattensuchzeit von 9ms (was schon fast einem ganzen frame entspricht) für einen einzigen sektor muss man sich nicht über miese performance wundern, deswegen hatte ich das mal ausgeklammert. aber ansonsten werd ich morgen mal mit dem standardtreiber rumspielen ;)

ShadowXX

2006-03-06, 23:54:12

gute idee, daran hab ich noch garnicht gedacht. ich werd mir mal die windows-performance ohne hardwareunterstützung anschauen.

Die Grakas unterstützen Windows beim Bildaufbau...deshalb ist das bei Windows so smooth.
Guck die mal die Caps von unterstützten 2D-Funktionen deiner 5800 an...du wirst erstaunt sein, wobei die Graka unterstützend mithilft (und BitBlt (das ist fürs verschieben mit Inhalt wichtig) wird HW mäßig von so gut wie jeder Graka unterstützt (selbst uralten).

Wuzel

2006-03-07, 00:22:33

1. mal haben die Compiler Flags nur sehr geringe auswirkungen auf das Redraw ;) -> Vergiss es am besten ganz schnell.
2. Siehe ShadowXX Post.
3. Redraw Problem bei GTK (wenn auch nur halb so schlimm wies hingestellt wird) - siehe MadMan2k Post.

Und zu guter letzt: Meine Geforce 68'er sieht gegen den Intel Onboard Chip im Notebook eines Freundes überhaupt kein Land unter 2D Linux Betrieb .. das ist abartig, sollte man erlebt/gesehen/gespürt habe.

Ich bin aber mit dem Speed meiner gefurz soweit zufrieden, nichts was mich irgendwie grossartig im alltag behindern würde.

Spearhead

2006-03-07, 00:34:17

einerseits hast du wohl recht, andererseits versuche mal folgendes: öffne ein verzeichnis auf einem cd/dvd-laufwerk mit mehr dateien als im explorer pro seite angezeigt werden. lass das laufwerk ausdrehen und scroll dann nach unten. er wird hängen und das laufwerk wieder hochdrehen. irgendwas scheint er also nachzuladen. bei einer minimalen festplattensuchzeit von 9ms (was schon fast einem ganzen frame entspricht) für einen einzigen sektor muss man sich nicht über miese performance wundern, deswegen hatte ich das mal ausgeklammert. aber ansonsten werd ich morgen mal mit dem standardtreiber rumspielen ;)

Das mag ja so sein, aber irgendwie ging es hier nie um CD-Laufwerke oder ähnliches ;)
Und ja, das was er da lädt ist wohl unter anderem das Icon oder die Bild/Videovorschau, je nach Einstellung. Bei einer Festplatte hat das aber auf die grafische Darstellung nicht wirklich Einfluß, und darum geht es doch gerade...

EDIT: vielleicht etwas klarer formulieren: Wenn das markieren des Verzeichnissinhaltes mit Standardtreiber zum ruckeln führt z.b. wegen dem Rahmen und mit dem "richtigen" Grakatreiber eben nicht, ist wohl kaum der Datenzugriff schuld und eben doch die Desktopperformance gefragt oder? ;)

Hmpf, irgendwie wurde während dieser Diskussion etwas aneinander vorbeigeredet glaube ich ;)

Usul

2006-03-07, 08:20:27

Mal ein paar Gedanken dazu:

1. Windows 2000 ist aus dem Jahre 2000. Installier mal eine Distribution aus dem Jahre 2000 und vergleiche die Performance, sofern die alte Distri heute noch läuft.

2. Probier mal den quelloffenen nv-Treiber. So wenig Features der auch hat, ich glaube, in 2D ist der schneller als der CS-Treiber von Nvidia selber.

3. X ist netzwerktransparent, -fähig, wie auch immer. Ich könnte mir vorstellen, dass diese Softwarearchitektur allein schon für etwas mehr Overhead sorgt als eine auf ein Desktopsystem optimierte Oberfläche. Weiß ich allerdings nicht, reine Vermutung. Umsonst bekommt man die Netzwerkfähigkeit wohl kaum, fraglich ist nur, ob man den "Preis" heutzutage noch spürt.

piepre

2006-03-07, 10:10:20

Und zu guter letzt: Meine Geforce 68'er sieht gegen den Intel Onboard Chip im Notebook eines Freundes überhaupt kein Land unter 2D Linux Betrieb .. das ist abartig, sollte man erlebt/gesehen/gespürt habe.

Das kann ich bestätigen :)

JonSvenJonsson

2006-03-07, 10:29:02

X ist alt. Die verwendete Beschleunigungsarchitektur XAA ist alt. Das Problem ist, das die meisten Treiber nur XAA unterstützen. Wer mal Kdrive auf ner r200 gesehen hat, weiss das X auch schnell sein kann. Seit Xorg-6.9 ist eine an Kdrive angelegte Beschleunigungsarchitektur in X enthalten, nennt sich EXA. Leider existieren entweder zuwenig Dokus für die Chips um um EXA-Funktionen hardwarebasiert zu betreiben (r300 und r400), oder es finden sich nicht genügend Entwickler um die besser dolumentierten Chips mit mit dem passendem EXA-Backend auszurüsten. Deshalb läuft EXA im Moment nur mit r2xx und SIS wirklich zufriedenstellend.

Grüße Jon

P.s.: Der aktuelle EXA-Status kann hier abgefragt werden, sind wohl doch ein paar mehr Chips als r2xx und sis :rolleyes:
http://xorg.freedesktop.org/wiki/ExaStatus

Ganon

2006-03-07, 10:44:37

Ich hab's auf meiner Radeon 9250 hier auf Arbeit laufen (also EXA). Bin sehr zufrieden... Klar. Ohne Schatten und den ganzen Kram. Das brauche ich hier nicht...

Coda

2006-03-07, 11:18:34

Ich glaube nicht dass Vista langsamer wird von der GUI - eher im Gegenteil. Es ist gar nicht mehr nötig die performancekritischen Teile in den Kernel zu legen, da das dann die GPU direkt übernimmt.

Wuzel

2006-03-07, 11:24:54

Für einen guten Überblick: http://www.freedesktop.org/~jonsmirl/graphics.html
Da wird eigentlich auch geklärt warum MS desktops ein wenig schneller sind ;)

JonSvenJonsson

2006-03-07, 11:35:55

Ich glaube nicht dass Vista langsamer wird von der GUI - eher im Gegenteil. Es ist gar nicht mehr nötig die performancekritischen Teile in den Kernel zu legen, da das dann die GPU direkt übernimmt.

Ähnlich funktioniert Xgl, die kompletten Render-Befehle werden nach OpnGL umgesetzt, bei verfügbarem Hardware-beschleunigten OpenGL übernimmt dann die GPU die komplette Arbeit.

cu Jon

Coda

2006-03-07, 12:26:44

Ist das denn schneller? Ich konnte es bisher nicht ausprobieren, da leider mein Netzwerkchip vom offiziellen Kernel nicht unterstützt wird und die Indell-PCIe-Karte auf sich warten lässt...

Ganon

2006-03-07, 12:35:40

Gast

2006-03-07, 12:59:42

Für einen guten Überblick: http://www.freedesktop.org/~jonsmirl/graphics.html
Da wird eigentlich auch geklärt warum MS desktops ein wenig schneller sind ;)

danke für den link! sehr informativ.

Wuzel

2006-03-07, 13:47:45

Das Problem dürfte noch die Konkurrenz zwischen GTK und Qt sein.

GTK nutzt ja nun Cairo. Qt nutzt (das eigene) Arthur. Xgl benutzt wohl Cairo/glitz... Fragt sich wie da Qt "zwischen" kommt...

Ganz kapiert hab ich das ganze noch nicht. Irgendwie ist der Weg in OS X klarer. ;)

Warum reden den immer alle nur von XGL?
Aiglx ist auch ein heisser Kandidat http://fedoraproject.org/wiki/RenderingProject/aiglx .

Das ganze 'erweitert' den X-Server - es ist kein Problem das auch die Renderingengines von QT dann auf diese neuen Funktionen zugreifen, in der jetzigen Pre Alpha Phase hat man halt Cairo genommen für die ganzen Demos.

Ganon

2006-03-07, 14:32:52

Warum reden den immer alle nur von XGL?
Aiglx ist auch ein heisser Kandidat http://fedoraproject.org/wiki/RenderingProject/aiglx .

Weil es zu jeden OpenSource-Projekt 932784623874 verschiedene Varianten gibt. ;) Warum redet niemand von Y? Warum immer X?

Gast

2006-03-07, 14:40:19

Wuzel

2006-03-07, 15:36:54

zu den vielen "gleichen" projekten (allgemein)
jo teilweise verzetteln die sich da IMHO unnötig anstatt die manpower in andere bereiche zu stecken, wo sie dringender gebraucht wird. aber ist off-topic

'Manpower'?
Seid wann dürfen Frauen nicht an OSS mitwirken, ausser den Jungs das Essen kochen?

Spearhead

2006-03-07, 16:07:48

'Manpower'?
Seid wann dürfen Frauen nicht an OSS mitwirken, ausser den Jungs das Essen kochen?

Mit dem falschen Fuß aufgestanden? :| Den Begriff gibt es schon lange, was regst du dich so darüber auf?

SamStone

2006-03-07, 16:12:16

Also erstmal: Versuchs das ganze mal mit QT Programmen. Hat hier ja schon irgend jemand gesagt das das schneller zeichnet als GTK.

Dann: Ja die Langsamkeit resultiert zum Teil aus dem Netzwerktransparenten Design soweit ich weiß. Aber jeder der für dieses mal Verwendung findet, will es gar nicht missen. In dieser Hinsicht ist der XServer den anderen Systemen vorraus.

Und ja: Mit Xgl gibt es keine redraw Probleme mehr. Man kann da auch das Fenster so schnell rumschieben wie man will. Das verwischt nie in irgend einer weise.

Mir persönlich macht diese Trägheit aber eigentlich so ziemlich gar nichts aus. Es ist ja nicht so, dass das den Arbeitsprozess irgendwie verlangsamen würde oder so.

Wuzel

2006-03-07, 16:17:44

Mit dem falschen Fuß aufgestanden? :| Den Begriff gibt es schon lange, was regst du dich so darüber auf?

Das war ein uralter Witz, wenn ich 'Manpower' lese, kann ichs mir manchmal einfach nicht verkneifen :D

Ein bischen Spass muss sein ..

Aber jetzt genug OT.

Spearhead

2006-03-07, 16:23:30

@Wuzel: Mja, ok... nächstes Mal nen Smilie mit Bart bitte ;)

Mir persönlich macht diese Trägheit aber eigentlich so ziemlich gar nichts aus. Es ist ja nicht so, dass das den Arbeitsprozess irgendwie verlangsamen würde oder so.

Dem stimm ich auch zu, der Redraw is zwar langsam genug um ihn zu bemerken aber nicht so langsam als das er einen wirklich beim schaffen behindert ^^

Was QT-Programme angeht: Dummerweise gibt es halt auch noch durchaus Programme die GTK (1 oder 2) nutzen die noch kein entsprechendes Pendant mit QT haben, aber naja, das Problem wird sich mit der Zeit denk ich dann auch lösen, da es ja bekannt ist ^^

JonSvenJonsson

2006-03-07, 18:21:27

Warum reden den immer alle nur von XGL?
Aiglx ist auch ein heisser Kandidat http://fedoraproject.org/wiki/RenderingProject/aiglx .

Das ganze 'erweitert' den X-Server - es ist kein Problem das auch die Renderingengines von QT dann auf diese neuen Funktionen zugreifen, in der jetzigen Pre Alpha Phase hat man halt Cairo genommen für die ganzen Demos.

Weil Xgl hier und jetzt mit jeder GraKa die hardware-beschleunigtes OpenGL bietet funktioniert, wogegen Aiglx nur mit den opensource Treibern funktioniert. Und bis ATi und Nvidia neue Treiber für Aiglx rausbringen dürfte noch einige Zeit ins Ländle gehen.

Die Rendering-Engine von QT nutzt auch die Render-Beschleunigung von Xgl, fluppt wunderbar hier. Vom Benutzerstandpunkt aus ist Xgl einfacher, da für den Großteil der seit 2000 verbauten Karten sowohl closed als auch opensource Treiber existieren, die das ganze fantastisch beschleunigen.

Außerdem mag ich RedHat seit 7.2 überhaupt nicht mehr :P

Grüße Jon

MadMan2k

2006-03-07, 19:05:02

Das Problem dürfte noch die Konkurrenz zwischen GTK und Qt sein.

GTK nutzt ja nun Cairo. Qt nutzt (das eigene) Arthur. Xgl benutzt wohl Cairo/glitz... Fragt sich wie da Qt "zwischen" kommt...

Ganz kapiert hab ich das ganze noch nicht. Irgendwie ist der Weg in OS X klarer. ;)
XGL benutzt Glitz - Cario at damit erstmal nichts zu tun. Da XGL auch nur ein X11 Server ist, ist das Rendering mit Qt kein Problem.

Ich halte AIGLX übrigens auch für die interessantee Alternative, da es nicht so den "Hack" Charakter hat.
Zwischen AIGLX und XGL gibt es übrigens regen Codeaustausch und beide verwenden dieselbe von David Reveman entwickelte Technologie. (kein Wunder glitz war seine Doktorarbeit)

XGL hat übrigens dieselben Treiberprobleme, wie AIGLX - es umgeht diese jedoch indem es für die entsprechenden Extensions auf Mesa zurückgreift.

Ganon

2006-03-07, 19:20:29

Achso. Ich dachte glitz sei "nur" ein Cairo Backend... also "nur" für Cairo...

Gast

2006-03-07, 19:22:33

will sich jemand die mühe machen jemandem der keine ahnung von den beziehungen der ganzen x-module hat zu erklären warum die graka-treiber ein problem darstellen? wenn der treiber opengl unterstützt und ich damit quake4 zocken kann, wo liegt das problem statt dem quake-level einen desktop zu rendern?

MadMan2k

2006-03-07, 22:04:55

SimonX

2006-03-07, 23:35:08

Was langsam ist ist nicht X, sondern die Monster-Kits wie KDE oder Gnome. Auch mal checken was so alles defaultmässig im Hintergrund läuft (so beagle z.B.)

KDE und Gnome und selbst die anderen Standard-Windowmanager in SuSe 10.0 sind grotten langsam. Ich benutze deswegen den fvwm95-2.0.x, den ich selbst übersetze und benutze, da er ja nicht mal mehr auf der CD drauf ist. Damit habe ich 0 Performance-Probleme, und das selbst auf meinem P3-800 nicht.

Gast

2006-03-07, 23:43:34

Bei Gnome kann ich das nachvollziehen aber KDE 3.5 (unter Arch) und langsam? Häää

Gast

2006-03-07, 23:57:25

LOL..ich rate jedem von Linux ab..selbst Freaks und Experten

warum? NUR ÄRGER....

Gast

2006-03-08, 00:03:00

ein Desktop seht nunmal anders aus als ein Q4 Level. Allein dadurch ist schon ersichtlich, dass hier andere Techniken zum Einsatz kommen. (hauptsächlich Texturoperationen)

Das ganze läuft letztendlich wohl über irgendwelche OGL erweiterungen ab, die die Treiber erst bereitstellen müssen.

hmm also verstehe ich das richtig, dass das ureigentliche problem darin besteht, dass die treiber gewisse opengl-calls nicht zulassen und jene dann per mesa von der cpu berechnet werden müssen? das wäre allerdings hart, dann sieht die zukunft nämlich sehr düster aus.

MadMan2k

2006-03-08, 00:05:29

Lokadamus

2006-03-08, 02:23:05

LOL..ich rate jedem von Linux ab..selbst Freaks und Experten

warum? NUR ÄRGER....mmm...

Ich rate jedem mit so einer Einstellung vom Benutzen eines PCs ab. Warum? NUR ÄRGER ... eine Konsole wäre genau das richtige :uup:Was langsam ist ist nicht X, sondern die Monster-Kits wie KDE oder Gnome. Auch mal checken was so alles defaultmässig im Hintergrund läuft (so beagle z.B.)

KDE und Gnome und selbst die anderen Standard-Windowmanager in SuSe 10.0 sind grotten langsam. Ich benutze deswegen den fvwm95-2.0.x, den ich selbst übersetze und benutze, da er ja nicht mal mehr auf der CD drauf ist. Damit habe ich 0 Performance-Probleme, und das selbst auf meinem P3-800 nicht.Jup, wenn man unbedingt etwas schnelles sehen will, sollte man keine 0815- Distri nehmen, die bei der Installation alles bereitstellen will. Suse, Mandrive und Fedora wollen irgendwo alles auf einmal bieten, wodurch viele Sachen geladen werden, die man nicht braucht. Wenn man gewisse Geschwindigkeiten haben will, sollte man gucken, dass man eine Installation nimmt, wo kein X am Anfang gestartet wird, sondern man selber den Kram installiert und beim Start nur die notwendigsten Dienste gestartet werden ...

Skullcleaver

2006-03-08, 05:55:42

mmm...

Ich rate jedem mit so einer Einstellung vom Benutzen eines PCs ab. Warum? NUR ÄRGER ... eine Konsole wäre genau das richtige :uup:
Ich frage mich grade wessen Antwort jetzt dämlicher war.

Gast

2006-03-08, 09:45:05

Jup, wenn man unbedingt etwas schnelles sehen will, sollte man keine 0815- Distri nehmen, die bei der Installation alles bereitstellen will. Suse, Mandrive und Fedora wollen irgendwo alles auf einmal bieten, wodurch viele Sachen geladen werden, die man nicht braucht. Wenn man gewisse Geschwindigkeiten haben will, sollte man gucken, dass man eine Installation nimmt, wo kein X am Anfang gestartet wird, sondern man selber den Kram installiert und beim Start nur die notwendigsten Dienste gestartet werden ...

habt ihr euch meinen anfangspost eigentlich durchgelesen? ;)
es ist ein gentoosystem, und ich hab da ausserordentlich wenig drauf installiert. an daemons eigentlich nur ntpd. zumindest kann ich mich an keine weiteren erinnern.
es ist auch nicht so, dass wir hier von balkenlängen-penismark-üblichen 5-10% unterschied reden. es geht um einen FAKTOR von 3-5 oder gar mehr. das sind 1-2 komplette hardwaregenerationen. stellt euch vor ihr hättet mit eurer x19x00xtxxtx unter windows 150 fps und unter linux 40. würde euch das stören?
natürlich kann es sein dass euch der x-desktop trotzdem schnell genug ist. gut, eure meinung. ich habe allerdings das gefühl mit der maus in honig zu rühren und das mach ich einfach nicht lange mit.

MadMan2k

2006-03-08, 15:32:41

hmm also verstehe ich das richtig, dass das ureigentliche problem darin besteht, dass die treiber gewisse opengl-calls nicht zulassen und jene dann per mesa von der cpu berechnet werden müssen? das wäre allerdings hart, dann sieht die zukunft nämlich sehr düster aus.
jup, konkret gehts es um GLX_EXT_texture_from_pixmap, welches im Moment über Mesa läuft.
Nvidia und Ati haben aber untertützung angekündigt.

Bei Ati ist wohl auch zu erwarten dass es in den offenen r300 treiber kommt...

SamStone

2006-03-08, 17:16:31

Was langsam ist ist nicht X, sondern die Monster-Kits wie KDE oder Gnome. Auch mal checken was so alles defaultmässig im Hintergrund läuft (so beagle z.B.)
Das hat mit der "Verwischung" nicht das geringste zu tun.

stellt euch vor ihr hättet mit eurer x19x00xtxxtx unter windows 150 fps und unter linux 40. würde euch das stören?
Ja, der Vergleich hinkt aber.

Gast

2006-03-08, 19:24:17

Ja, der Vergleich hinkt aber.

hast du schön gesagt, erklärst du mir noch warum? ;)

SamStone

2006-03-08, 20:57:53

hast du schön gesagt, erklärst du mir noch warum? ;)
Weil wenn du sagst das man (ich gehe mal davon aus das du ein Spiel meinst) in Linux nur einen Bruchteil der FPS wie unter Windows hast, dann ist das eine Sache. Hier wird also das Reibungslose ausführen eines Programmes durch Leistungsminderung gestört oder gar unmöglich gemacht.
Bei dem Sachen die du an dem XServer bemängelst handelt es sich lediglich darum, dass eben dieser ein wenig reaktionsarmer ist, allerdings nicht so das es wirklich auswirkung hat (wie man sich so darüber aufregen kann kann ich beim besten willen nicht verstehen. Hab noch nie von jemanden gehört das das wirklich ernsthaft stört). Die Gesamtleistung des Systems wird dabei aber nicht beeinflusst.

Skullcleaver

2006-03-08, 21:20:18

Ich arbeite in Win mit Verzögerung 0 beim Startmenu da stört mich XFree/X.Org mit seiner Trägheit in der Tat enorm. Bin einer der wenigen die Linux zum Zocken (Quake/Doom) und Windows zum Arbeiten haben ^^

Wobei das Zocken dann direkt aus der Shell gestartet wird. Sprich der XServer ist exklusiv für den Zock offen.

SamStone

2006-03-08, 21:28:37

Ich arbeite in Win mit Verzögerung 0 beim Startmenu da stört mich XFree/X.Org mit seiner Trägheit in der Tat enorm.
Wie soll man das jetzt verstehen? Das Startmenü hat bei mir unter Linux nicht die geringste Verzögerung.

Skullcleaver

2006-03-08, 21:33:14

Sicher hat es das. Die ganze Oberfläche reagiert nicht so zeitig wie die von Windows. Das fällt auch auf das Startmenu zurück da ein Teil der Oberfläche.

Das mit dem Verzögerung 0 war ein Beispiel dafür das ich mit schnellstmögliche Oberfläche arbeite.

SamStone

2006-03-09, 15:34:53

Sicher hat es das. Die ganze Oberfläche reagiert nicht so zeitig wie die von Windows. Das fällt auch auf das Startmenu zurück da ein Teil der Oberfläche.
Bei solchen Sachen wie aufpoppen eines Menüs oder Reaktion auf einen Klick irgendwo darauf mit der damit verbundenen Aktion gibt es hier bei mir keine Verzögerung, auch auf meinem etwas älteren Rechner nicht.

Gast

2006-03-09, 16:11:58

Bei solchen Sachen wie aufpoppen eines Menüs oder Reaktion auf einen Klick irgendwo darauf mit der damit verbundenen Aktion gibt es hier bei mir keine Verzögerung, auch auf meinem etwas älteren Rechner nicht.

du irrst. es gibt immer eine verzögerung. auch unter windows. da liegt sie allerdings unter 10ms (=1 frame bei 100hz), unter linux liegt sie höher. wenn du das nicht bemerkst, glückwunsch. mich stört es enorm.

SamStone

2006-03-09, 17:21:52

du irrst. es gibt immer eine verzögerung. auch unter windows. da liegt sie allerdings unter 10ms (=1 frame bei 100hz), unter linux liegt sie höher. wenn du das nicht bemerkst, glückwunsch. mich stört es enorm.
Das es immer eine Verzögerung geben muss ist mir auch klar. Und das diese bei Linux höher liegt stimmt zumindest bei mir nicht. Im Gegenteil: Wenn ich unter WindowsXP da auf das "Programme" gehe, DANN dauert das ganze spürbar etwas, bis es endlich angezeigt wird. Bei der Gnome Leiste hab ich sowas nicht (wobei man aber sagen muss, dass ich mein WinXP in keinster Weise irgendwie warte oder auf geschwindigkeit optimiert habe, sondern nur ab und zu zum spielen benutze).

Skullcleaver

2006-03-09, 18:31:30

Solltest du bei deinem Windows mal machen dann weisst du was eine performante Oberfläche ist. Das geben selbst die eingefleischtesten Tuxer zu.

MadMan2k

2006-03-09, 18:47:36

X11 mit compositing ist schneller als Windows - prinzipbedingt.

Skullcleaver

2006-03-09, 18:51:44

benches? Belege?

MadMan2k

2006-03-09, 18:53:23

das prinzip von composite wirst du dir wohl noch selber angucken können?

Trap

2006-03-09, 19:05:40

Die Verwendung von xgl sagt aber nur was über die Rendergeschwindigkeit, aber nichts über die Latenz zwischen Eingabe und Reaktion und auch nichts über die Aktualisierungsrate.

Skullcleaver

2006-03-09, 19:20:47

das prinzip von composite wirst du dir wohl noch selber angucken können?
Theorhie interessiert nicht sondern Praxis also Benches. Darf ich also von ausgehen das du es nicht belegen kannst?

Trap

2006-03-09, 19:23:42

Benches sind nicht ganz einfach, Throughput messen ist einfach, Latenz ist viel schwieriger. Mich würde es positiv überraschen wenn es dazu unter Windows benches gäbe.

Skullcleaver

2006-03-09, 19:28:31

Gibt es in der c't wurde zu den Anfängen von XP mal Reaktionsbenches der Oberfläche durchgeführt. Wird es dann heute wohl auch noch geben.

MadMan2k

2006-03-09, 19:59:51

Die Verwendung von xgl sagt aber nur was über die Rendergeschwindigkeit, aber nichts über die Latenz zwischen Eingabe und Reaktion und auch nichts über die Aktualisierungsrate.
XGL läuft standardmäßig bei 60fps (lässt sich erhöhen) und fenster müssen nicht mehr wie bei Windows beim verschieben aktualisiert werden.

@Scullcleaver
was genau sollen dei benches denn aussagen? wie schnell ein menü aufpoppt hängt hauptsächlich davon ab, was darin enthalten ist -> Applikationsabhängig.

Skullcleaver

2006-03-09, 20:11:34

Die ms bis auf eine Aktion des User reagiert wird ganz einfach.

MadMan2k

2006-03-09, 20:32:30

und was soll das aussagen? ein komplexers menü zu öffnen dauert länger? man kann es nur selbst ausprobieren und dann urteilen ob es schnell genug ist oder nicht...

Skullcleaver

2006-03-09, 22:25:17

man kann vergleichbare komplexität schaffen und den speed vergleichen ganz simpel

Was einem jetzt schnell genug ist, ist natürlich subjektiv.