[discussie] X.org en Linux-Graphics - de toekomst

Dat is niet makkelijk hoor! . Ik kom er vanavond (mijn tijd, voor jou dus vannacht/morgenochtend. ) uitgebreider op terug. Voor nu zul je 't ff met wat websites moeten doen:

• Kort specs over X protocol op X.org zelf: http://www.x.org/X11_protocol.html
• Uitleg, voorbeeldjes: http://www.freesoft.org/CIE/Topics/113.htm

Bedenk dat wat jij een client noemt (display) volgens de specificaties een server heet. De client is datgene die de eigenlijke applicatie runt, de server is datgene die het eindresultaat weergeeft. Beetje verkeerd om.

Da's niet verkeerd om. Dat is het aloude idee van presentation-managers. Het feit dat het een "server" genoemd is wellicht wat verwarrend, maar het is absoluut niet verkeerd om.

de clients zijn de applicaties _zelf_ 't is gewoon een client-servermodel: client connect naar server. Applicatie connect naar display, zogezegd.
Persoonlijk vind ik 't verdomd handig, zo met die netwerktransparantie erbij

quote:

CyBeR schreef op 03 maart 2004 @ 22:33:

Persoonlijk vind ik 't verdomd handig, zo met die netwerktransparantie erbij

Handig is het soms wel maar de Windows oplossing dmv "rdesktop" of VNC werkt over een aanzienlijk drukbezet netwerk veel vlotter naar mijn gevoel dan X forwarding. En dat was dacht ik toch wel één van de hoofdredenen van implementatie van de netwerktransparantie, beperkte network load en sneller reageren ipv domweg screenshots over te pompen. Van mijn part mogen ze die droppen, ik ben niet tevreden over het resultaat. Ik ben er geheel niet van overtuigd dat werken dmv localhost met shared mem dezelfde responsiveness oplevert....

Waarom schuiven venstertjes in Windows anders veeeeeeeeeeel vloeiender over het scherm. (Testcase: P4 met HT 2.6Ghz/800FSB, 512DDR400, ATI Radeon 9200/128DDR) Zowel in Windows als Linux gebruik ik official ATI drivers. In linux de laatste nieuwe FireGL X drivers alle X optimalisaties, nieuwste X versie etc... De beeldopbouw is vrij snel, maar hapert toch wel in Linux, waar in Windows een venster sneller dan het oog lijkt te glijden. Het lijkt wel of er een delay ingebouwd is of een maximum framerate. Ik zou niet weten hoe ik het anders moet omschrijven. Probeer zelf maar eens een venster van pakweg 640x480 snel heen en weer te verslepen op een Windows of Linux desktop op dezelfde hardware.

In het verleden werd er steeds met de vinger naar X gewezen, en hier verkondigen jullie dat het anders moet zijn, wie of wat is dan de schuldige want er is toch wel een duidelijk verschil?
X? Kernel? Drivers? WindowManager? Combinatie van alles? Het moet toch ergens vandaan komen? Vroegers was een argument om Linux te gebruiken dat het sneller draait dan Windows op oudere hardware.... Ik heb geleerd dat de realiteit helemaal anders is wanneer er X aan te pas komt. X vreet geheugen en CPU cycles en dan nog komt het niet in de buurt van de responsiveness van Windows. Spijtig genoeg, maar ik zag in Y toch wel ergens een stap in de goede richting.

quote:

Zagato schreef op 04 maart 2004 @ 00:00:
[...]
Handig is het soms wel maar de Windows oplossing dmv "rdesktop" of VNC werkt over een aanzienlijk drukbezet netwerk veel vlotter naar mijn gevoel dan X forwarding. En dat was dacht ik toch wel één van de hoofdredenen van implementatie van de netwerktransparantie, beperkte network load en sneller reageren ipv domweg screenshots over te pompen. Van mijn part mogen ze die droppen, ik ben niet tevreden over het resultaat. Ik ben er geheel niet van overtuigd dat werken dmv localhost met shared mem dezelfde responsiveness oplevert....

Waarom schuiven venstertjes in Windows anders veeeeeeeeeeel vloeiender over het scherm. (Testcase: P4 met HT 2.6Ghz/800FSB, 512DDR400, ATI Radeon 9200/128DDR) Zowel in Windows als Linux gebruik ik official ATI drivers. In linux de laatste nieuwe FireGL X drivers alle X optimalisaties, nieuwste X versie etc... De beeldopbouw is vrij snel, maar hapert toch wel in Linux, waar in Windows een venster sneller dan het oog lijkt te glijden. Het lijkt wel of er een delay ingebouwd is of een maximum framerate. Ik zou niet weten hoe ik het anders moet omschrijven. Probeer zelf maar eens een venster van pakweg 640x480 snel heen en weer te verslepen op een Windows of Linux desktop op dezelfde hardware.

In het verleden werd er steeds met de vinger naar X gewezen, en hier verkondigen jullie dat het anders moet zijn, wie of wat is dan de schuldige want er is toch wel een duidelijk verschil?
X? Kernel? Drivers? WindowManager? Combinatie van alles? Het moet toch ergens vandaan komen? Vroegers was een argument om Linux te gebruiken dat het sneller draait dan Windows op oudere hardware.... Ik heb geleerd dat de realiteit helemaal anders is wanneer er X aan te pas komt. X vreet geheugen en CPU cycles en dan nog komt het niet in de buurt van de responsiveness van Windows. Spijtig genoeg, maar ik zag in Y toch wel ergens een stap in de goede richting.

Ikzelf heb er geen problemen mee met een Nvidia GF4 Ti4400. Op Linux werkt het zelfs beter dan in Windows; voornamelijk bij het afspelen van DVD's; alles blijft gewoon perfect werken i.t.t. Windows. Volgens mij is het toch echt voornamelijk een driver kwestie. Als je de render extensie geactiveerd hebt en goede drivers werkt het volgens mij echt prima. Als je echter geen goede drivers hebt dan is het huilen met de pet op is mijn ervaring tot nu toe.

Toch niet, versta me niet verkeerd, Bij het afspelen van films of OpenGL apps oid geen probleem. Alles is snel genoeg. Alle X rendering settings zijn geactiveerd etc. Met haperen bedoel ik het feit dat bij het verslepen van een venster de beweging niet vloeiend is maar meer in schokken, precies of er een aantal frames wegvallen. In vergelijking met Windows.

Ehm. Op mijn Powerbook's Mach64 gaat dat gewoon vloeiend hoor. Het enige dat niet vloeiend gaat is het redrawen van de inhoud van windows. Maar dat is niet iets dat de X server doet.

quote:

Zagato schreef op 04 maart 2004 @ 00:00:
Ik ben er geheel niet van overtuigd dat werken dmv localhost met shared mem dezelfde responsiveness oplevert....

Dan mag jij mij bewijzen dat dat hieraan ligt. Totdat je bewijst is hetgeen je hier verkondigt complete onzin.

quote:

In het verleden werd er steeds met de vinger naar X gewezen, en hier verkondigen jullie dat het anders moet zijn, wie of wat is dan de schuldige want er is toch wel een duidelijk verschil?

Het ligt deels aan XFree86, maat nier aan het X protocol. XFree86 heeft veel te weinig optimalisaties op welk front dan ook. Een stukje assembler hier en daar of een code-updateje zou niet verkeerd zijn.

Vandaar dat ik ook zo veel verwacht van FDO X.

quote:

Beelzebubu schreef op 04 maart 2004 @ 16:12:
[...]


Dan mag jij mij bewijzen dat dat hieraan ligt. Totdat je bewijst is hetgeen je hier verkondigt complete onzin.

.

Mja dat kan ik niet, je hebt gelijk. Ik wou eigenlijk alleen maar de vraag stellen waar het fout loopt. Ik hoop ook stilletjes dat het met FDO beter zal werken, maar daar is het nu nog te vroeg voor spijtig genoeg. Veel heb ik niet te klagen maar het mag van mij zeker sneller gaan als de hardware niet de beperkende factor is, niet?

quote:

Cybarite schreef op 03 maart 2004 @ 17:39:
Ja maar hoe zit de taakverdeling nu precies ?

Okee... We beginnen bij wat men het X protocol noemt. Het is mij compleet onduidelijk welke van de twee client en server zijn, maar ik noem de toolkit altijd de client en de renderer server (zoals op die X protocol plaatjes van x.org in de link die ik hiervoor gaf). Dit is het eigenlijke X protocol. De applicatie, toolkit of wat dan ook heeft hier een set vierkantjes (Drawables of XWindows) die elk een positie, size en data-array hebben. Hierbij horen ook nog een stuk properties die het geheel ingewikkeld maken dus die laat ik lekker weg hier. .

De applicatie/toolkit en renderer communiceren via een systeem wat je een beetje moet zien als een messaging systeem als SOAP (SOAP is een XML messaging systeem; het is natuurlijk geen SOAP, want dat bestond toen nog niet, maar dat vind ik wel een goede parallel). Overigens is het X protocol een stuk platter dan SOAP, maar basale XWindow objecten kan je doorgeven. Dit messaging systeem loopt over network of unix sockets (remote vs. lokaal) en is bidirectioneel.

De applicatie/toolkit kan messages naar de server sturen waarin een Drawable verplaatst, geresized wordt of waarin nieuwe data wordt gestuurd naar de Drawable. De server reageert hierop door een nieuw beeldframe te redenderen, en doet dit door recursief Drawables bovenop elkaar te stapelen van achter naar voren (dus Drawables op hetzelfde level worden op zo'n manier gerendered dat eerst de window die half-verborgen is achter een andere fully exposed windown wordt gerendered, en dan pas de fully exposed window) en van top (Root window, je desktop) naar bottom (knopjes in applicaties e.d.). Dit gebeurt allemaal asynchroon. Fully hidden windows worden niet gerendered en hoeven ook geen refresh data naar de server te sturen (immers: geen effectief verschil). De server kan ook messages naar de client sturen voor dit soort doeleinden.

De server rendert, zoals gezegd, Drawables recursief naar het beeldscherm of een tussenbuffer (double buffering). Dit resultaat wordt op het beeldscherm getoond. De server draait dus altijd op de machine met beeldscherm, muis e.d. De client kan op remote (application) servers draaien (en dan praat je dus over remote X). Dit is ook de reden dat rendering op de (X; niet applicatie! ) server moet gebeuren, niet op de client (X; de applicatie server dus). De uiteindelijke resultaten worden alsnog naar de display gestuurd en gerendered, en alles werkt dan dus zoals je zou willen.

Input devices (joystick, muis, keyboard, drawboards, etc.) werken via dit X protocol en sturen events van de X server naar de X client. De client gebruikt deze om de applicatie hierop te laten reageren (bijvoorbeeld door een tooltip te laten zien of een button op te lichten als de muis eroverheen gaat, etc.).

Zo duidelijk? .

http://slashdot.org/artic...5&tid=187&tid=189

Fedora Prepares For Xorg Instead of XFree86

Ziet er naar uit dat de massa toch gaat voor de X van keith...

Even voor de duidelijkheid: het gaat hier dus niet om de FDO Xserver, maar om een fork van XFree86 4.4 (met de oude license + sommige nieuwe patches) die ook op FDO wordt gehost. Volgens deze blog komt er voor het eind van deze maand een release.
Waarschijnlijk is deze fork niet meer dan een tussenstap in de overgang van XFree86 naar de nieuwe FDO Xserver, zolang de laatstgenoemde nog niet uitontwikkeld is en goede driver support heeft.

Kewl, Redhat is dus de eerste die een andere X Server shippen. Ze zullen ook wel bereid zijn om er wat werk in te steken, en dat komt FDO ten goede.

Ik ben benieuwd wanneer de andere vendors een keuze hebben gemaakt. Lijkt me aan de ene kant niet verkeerd om allemaal hetzelfde alternatief te ondersteunen, echter was dit ook de situatie met XFree86, een alternatief was / is er niet, dus er was ook sprake van een soort "lock-in".

Ik denk dat dit wel een goede ontwikkeling is. Er is zeker nog wat werk nodig aan de FDO Server, dus een tussentijds alternatief lijkt me niet verkeerd. En men kan richting integratie met een nieuwe X Server werken.

@sebas:
Fedora is dan ook een "proefjes"-distributie ...

@Beezlebubu:
Aangezien het icoontje in MyReact geel bleef, dacht ik dat je geen reactie meer had gepost !

Ik zal zo spoedig mogelijk reageren, bedankt voor de moeite iig

"proefjes" distributie zou ik't toch niet echt noemen, althans, naar mijn weten was het niet de bedoeling om er een soort 'unstable' van te maken, maar om zakelijke / commerciele en particuliere markt wat beter te scheiden.

Vooruitstrevendheid betekent niet proefjes, imo. Ze zijn gewoon moedig om als eerste een 'nieuwe standaard' te adapteren.

Het is voor de early adaptors...

Ik wist niet zo snel een Nederlands equivalent te vinden ...

FDO XServer van keith zul je de eerst komende maanden, zo niet een jaar, niet in een distibutie meegeleverd zien worden imho. Daarvoor is het nog niet af genoeg zeg maar. De driver-ondersteuning en Hardware-accelleratie zijn daar voornamelijk de reden van.

ik draai nu zelf ook de FDO Xserver en heb daarbij redelijk wat in de source zitten kijken.
maar er zitten meer "kappote" dingen in dat dingen die werken.
Zo is er b.v. nog niet eens support voor GLX. of DRI. (of enkel minimaal eigen kleine hacks. maar de modules zelf zijn nog lang niet te compilen. (tot en met missende includes ) )
naast kdrive zijn ze nu ook al begonnen aan het poorten van xizzle.
maar uiteraard niet verwachte dat die werkt ofzo. (het was zelfs zo erg dat ik twee directories en files moest aanmaken omdat de complete xserver anders niet wou compilen. (flb_fixed,flb_first uit mijn hoofd en daar een makefile.in in die hij toch niet gebruikte)))

xserver is nu leuk speelgoed. maar ik zou het eigenlijk nog niet eens beta software noemen.

(voor de rest heb ik overgenst geen verstand van de interne werking van X'n of een complete kennis van FDO's xserver. dus wat ik hier zeg is puur ervaring van de afgelopen week)

@Beelzebubu:

Je begint weer een uitgebreide technische beschrijving te geven van wat er in de praktijk allemaal gebeurt ..

Maakt niet uit, je bent nogal bevlogen natuurlijk van je werk uit ...

Dat document waar je naar linkte is al heel verhelderend, ik lees mezelf wel wat beter in ...

quote:

Cybarite schreef op 19 maart 2004 @ 17:39:
Je begint weer een uitgebreide technische beschrijving te geven van wat er in de praktijk allemaal gebeurt ..

Client: Widgets, skinning, core-messages ontvangen van xserver, X-messages terugsturen naar X-Server.

Server: Recursief renderen, tonen en updaten van X-Windows aangeboden door een client, core-messages doorsturen naar client, hardware-accelleratie.

Zoals het verhaal van beelzebubu al doet vermoeden komt er veel meer bij kijken, maar jij wilt een simpele taakverdeling, hier hebbie 'm.

Om het verhaal niet offtopic te doen laten gaan: Omdat zaken zoals transculentie en alpha-blending rekening moet houden met alle clients getoont op het scherm, zoals motif, QT, java, GTK, ooO (en dus niet alleen z'n eigen haggie moet redden ), kunnen dit soort features (shadows van windows en transparantie dus bijvoorbeeld) lastig bij de client worden ondergebracht. Vandaar dat -dit- soort eye-candy, in tegenstelling tot widgets en het skinnen daarvan, -wel- door de server wordt "verzonnen". Zo blijf je de vrijheid van client houden, maar houdt je wel eenduidigheid in de server-side features.

Slackware gaat wel XFree 4.4.0 gebruiken. Quote uit de changelog van slackware-current:
code:

x/xfree86-4.4.0-i486-1.tgz:  Upgraded to XFree86 4.4.0.
x/xfree86-devel-4.4.0-i486-1.tgz:  Upgraded to XFree86 4.4.0.
x/xfree86-docs-4.4.0-noarch-1.tgz:  Upgraded to XFree86 4.4.0.
x/xfree86-docs-html-4.4.0-noarch-1.tgz:  Upgraded to XFree86 4.4.0.
x/xfree86-fonts-100dpi-4.4.0-noarch-1.tgz:  Upgraded to XFree86 4.4.0.
x/xfree86-fonts-cyrillic-4.4.0-noarch-1.tgz:  Upgraded to XFree86 4.4.0.
x/xfree86-fonts-misc-4.4.0-noarch-1.tgz:  Upgraded to XFree86 4.4.0.
x/xfree86-fonts-scale-4.4.0-noarch-1.tgz:  Upgraded to XFree86 4.4.0.
x/xfree86-xnest-4.4.0-i486-1.tgz:  Upgraded to XFree86 4.4.0.
x/xfree86-xprt-4.4.0-i486-1.tgz:  Upgraded to XFree86 4.4.0.
x/xfree86-xvfb-4.4.0-i486-1.tgz:  Upgraded to XFree86 4.4.0.

Volledige changelog

Zou dit ermee te maken hebben dat slackware eigenlijk alleen maar 'vanilla' sources compileert? Dus eigenlijk niet zoveel wijzigt aan de sourcecode? Of is het alleen maar omdat XFree de enige technisch afdoende en stabiele oplossing is?

quote:

Cybarite schreef op 19 maart 2004 @ 17:39:
Maakt niet uit, je bent nogal bevlogen natuurlijk van je werk uit ...

Dat document waar je naar linkte is al heel verhelderend, ik lees mezelf wel wat beter in ...

Thanks. . 't Is gewoon leuk werk om te doen. . * Beelzebubu zou dit voor de grap eens een tijdje full-time moeten doen bij een of andere distro-bakker...

quote:

Quasily schreef op 25 maart 2004 @ 01:30:
Slackware gaat wel XFree 4.4.0 gebruiken. Quote uit de changelog van slackware-current:
[..]
Zou dit ermee te maken hebben dat slackware eigenlijk alleen maar 'vanilla' sources compileert? Dus eigenlijk niet zoveel wijzigt aan de sourcecode? Of is het alleen maar omdat XFree de enige technisch afdoende en stabiele oplossing is?

Mjah, de X mensen hebben meerdere malen herhaald dat de libs (dus datgene waar je naartoe linkt als applicatie) niet onder de nieuwe licentie vallen. Alleen de server (die standalone runt) valt daar momenteel onder. Dus er is momenteel nog geen "echte" reden om over te stappen behalve de combinatie van "puurheid" willen en een soort van aversie tegen de praktijken. Puurheid moge duidelijk zijn: Debian zal nooit XFree86 4.4 shippen. Aversie lijkt me ook duidelijk, met name vanuit RedHat en Suse: zij "gebruiken" opensource als een soort drijfbootje naar geld, en de filosofie van de nieuwe X licentie past daar niet tussen. Nogal logisch dat zij liever de fork van X 4.4-rc2 gebruiken, of anders de FDO X server. .

http://www.osnews.com/comment.php?news_id=6646

X.Org Foundation Releases X Window System X11R6.7

X.Org Foundation today announced their first release of the X Window System since the formation of the Foundation in January of this year. The new X.Org release, called X Window System Version 11 Release 6.7 (X11R6.7), builds on the work of the X.Org X11R6.6 and XFree86 Project Inc.

Ziet er dus naar uit dat de gehele fork nu eindelijk zijn vruchten gaat afwerpen.

Verder: http://www.xwin.org/Software/XDevConf

Met leuke presentaties:

Current presentations for the X Developer's Meeting include:

Keith Packard and Jim Gettys: "The (Re)Architecture of the X Window System"
Deron Johnson & Hideya Kawahara "Looking Glass"
Dave Reed & Dave Smith: "Croquet: Integrating X with 3D Immersive Environments"
Eamon Walsh: ""Fine-grained Access Control for X"
Owen Taylor: The Widget Toolkit Developer's Perspective on X

Current discussions and/or hacking sessions include:

The big picture of X and a plan to get the necessary pieces done (Stuart Anderson)
Network security and X (Jim McQuillan and Ted T'so).
What can be learned from Longhorn and OS/X? (Jon Smirl)
X on OpenGL (Keith Packard and Jon Smirl)

Dat wordt smullen!!!

Van de topicstarter:

quote:

deadinspace schreef op 24 maart 2003 @ 22:32:
Toen Packard op eigen houtje zonder overleg met de rest van het team een bepaald deel van XFree86 aanpaste is hij uit het XFree86 core team gezet.

Met die zin wordt wellicht het idee geschept dat Keith Packard de schuld heeft aan de fork. Laat duidelijk zijn dat we juist die weinige opvallende verbeteringen in XFree86 aan hem te danken hebben!

De schuld van het gebeuren ligt dus niet bij Keith Packard (die zichzelf uiteindelijk genoodzaakt zag om Xfree86 te verlaten), maar bij David Dawes, die zich al jaren gedraagt als een elitaire klootzak. Ik vind het lullig om dit van iemand te zeggen, maar het is waar.

Ergens heeft Dawes met zijn arrogantie juist voor iets goeds gezorgd: anders was de community waarschijnlijk blijven aanrommelen met XFree86. Het nieuwe X.org-initiatief geeft daarentegen een zeer grote impuls aan de hele community om met prachtige innovaties te komen wat betreft de meest gebruike user interface onder Linux (en andere Unix-varianten)!

motown wijzigde dit bericht 22-04-2004 17:19 (4%)

offtopic:
Hehe, goed?

Als die Dawes niet zo arrogant was, was er uberhaupt geen aanrommeling, waarvan de negatieve gevolgen door een fork teniet zouden kunnen worden gedaan.

Hehe, wel grappig zo'n stelling, een soort van dubbel-gelaagde paradox.

Cybarite wijzigde dit bericht 22-04-2004 19:04 (7%)