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

XFree86 heeft veel kritiek ontvangen voor het gebrek aan openheid dat het XFree86 developers team er op na hield. Doordat de ontwikkeling van XFree86 erg besloten was, was het vaak een langdurig proces voor externe developers om patches in XFree86 te krijgen.

Sinds enkele jaren (?) is hier een klein beetje verandering in gekomen, en nu lijkt er aanzienlijk meer verandering in te komen. Keith Packard (XFree86 core developer) zocht naar mogelijkheden tot een fork - iets dat de rest van het XFree86 team niet beviel. 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.

Dit conflict lijkt in ieder geval (direct of indirect) het gevolg te gaan hebben dat XFree86 development opener gaat worden. Meer developers laten zich nu horen en klagen over de geslotenheid van het XFree86 core team, waardoor zij hopenlijk hun development model wijzigen. Als ze dit niet doen, dan schat ik de kans dat Packard (of iemand anders) daadwerkelijk een fork start reëel in.

nieuwsartikel
KDE en Gnome developers' standpunt
Nieuwe, open ( :) ), XFree86 mailinglist voor discussie over X en XFree86
Discussie over X11 model

Heb je aanvullende informatie, of een (beargumenteerde) mening over deze affaire of X of XFree86 in zijn algemeen? Brand los

---

Ook is er in Kernel 2.5.x draadje.... een discussie op gang gekomen over XFree86 en het algemene desktop op GNU/Linux gebeuren. Aangezien die discussie nauwelijks nog aan de kernel gerelateerd is wil ik die discussie graag hierheen verplaatsen, want dit is een veel betere plaats om naar hartelust daarover te discussieren.

Ik zal hieronder de relevante posts uit het kernel-draadje herhalen, zodat de discussie makkelijk voortgezet kan worden.

Tot slot even het volgende: haal het X Window System (protocol) en XFree86 (implementatie) aub niet door elkaar, dat leidt altijd tot veel verwarring. Danku

---

link dikkebanaan schreef op Saturday 22 March 2003 17:50

quote:

Beelzebubu schreef op 13 March 2003 @ 19:22:
Like? .

XFree doet alle soorten acceleraties die er zijn, maar omdat de interface en structuur wat moeilijk lijkt vinden mensen het kut. Heb je nou al eens werkelijk tests gedaan of het sneller zou worden als je een directe local-only blabla windows-achtige GUI bouwt? Wordt het sneller? Ligt dat aan X?

Een van de manieren om dit sneller te maken is directfb, maar dat is geen optie voor een X server. Directfb zou een X extensie kunnen zijn, maar voor de rest kan X zoveel meer... Die tiende van een duizendste van een seconde kan mij dan echt geen ruk schelen...

Ik had dit nog niet gelezen maar zou hier toch nog even op willen reageren, ook al is het offtopic (misschien moet er een XFree86 draadje worden geöpend?).

Een paar die ik nu snel kan bedenken:

- Brakke muis deceleratie
- Geen ondersteuning voor bv andere kleurmodellen (blegh, 32 bpp fb wordt niet eens normaal ondersteund)
- XFree86 zal in dit tempo hopeloos achterlopen wanneer de rest van de wereld over gaat op een UI die gebruik maakt van de 3d hardware (zie OS X en Longhorn)
- Tekenen van wm/app is brak (ie. zoals al eens vaker is uitgelegd door Havoc Pennington zou XFree86 alles in 1 stap, of eigenlijk op een manier tekenen waarop de gebruiker niet ziet dat de wm + app 2 verschillende onderdelen zijn)

Maar het ergste vind ik eigenlijk toch wel dat de meeste van die zgn 'core developers' van XFree86 tegenwoordig alleen nog maar op hun reet zitten toe te kijken, zitten te zeiken over politiek spul en tegenwoordig nooit meer een enkele regel code schrijven voor XFree86.
Een van deze core developers is zelfs overgelopen naar Windows (!) ik begrijp echt niet wat die kerel (en de andere 'backseat developers') in zo'n team zoekt als ie toch liever andere software gebruikt (zoals is aangegeven door hem zelf) en ook al een hele hoop jaren *niets* meer heeft gedaan om XFree86 vooruit te helpen..

_{(hier wordt btw op dit moment ook over gediscussiëerd op een nieuwe mailing list @ xfree86.org, naar aanleiding van het eruit schoppen door het core team van de enige developer die _wel_ veel deed om XFree86 te verbeteren)}

Het gaat mij iig helemaal niet meer om de snelheid op dit moment, dat zit wel goed wanneer de (1-na-laatste) closed source driver van NVIDIA wordt gebruikt (ik weet niet hoe stabiel/snel die van ATi is?)

---

link Beelzebubu schreef op Saturday 22 March 2003 21:27

quote:

dikkebanaan schreef op 22 maart 2003 @ 17:50:
- XFree86 zal in dit tempo hopeloos achterlopen wanneer de rest van de wereld over gaat op een UI die gebruik maakt van de 3d hardware (zie OS X en Longhorn)

Dat is een applicatie kwestie, niet een X kwestie...

quote:

- Tekenen van wm/app is brak (ie. zoals al eens vaker is uitgelegd door Havoc Pennington zou XFree86 alles in 1 stap, of eigenlijk op een manier tekenen waarop de gebruiker niet ziet dat de wm + app 2 verschillende onderdelen zijn)

Double buffering, bedoel je? Eens.

quote:

Maar het ergste vind ik eigenlijk toch wel dat de meeste van die zgn 'core developers' van XFree86 tegenwoordig alleen nog maar op hun reet zitten toe te kijken, zitten te zeiken over politiek spul en tegenwoordig nooit meer een enkele regel code schrijven voor XFree86.
Een van deze core developers is zelfs overgelopen naar Windows (!) ik begrijp echt niet wat die kerel (en de andere 'backseat developers') in zo'n team zoekt als ie toch liever andere software gebruikt (zoals is aangegeven door hem zelf) en ook al een hele hoop jaren *niets* meer heeft gedaan om XFree86 vooruit te helpen..

Mjah, I know... Kutzooi aldaar... Zegt op zich weinig over X, meer over de XFree86 devvers... .

Waar ik bang voor ben, is dat bedrijven als ATI en nvidia heel lang zullen achteroverleunen qua commerciele driver development als de X standaard wordt weggegooid. Dat is toch het belangrijkste wat er nodig is om commerciele bedrijven zover te krijgen Linux te supporten...

En wees eerlijk, die opensource nv drivers zijn peanuts vergeleken met de nvidia drivers, geen discussie mogelijk...

---

link odysseus schreef op Saturday 22 March 2003 21:32

quote:

Beelzebubu schreef op 22 maart 2003 @ 21:27:
Dat is een applicatie kwestie, niet een X kwestie...

Als je elke applicatie zijn eigen communicatie met 3D-hardware wilt laten uitvoeren, dan mag je, maar mij lijkt het niet handig . Natuurlijk kan een programma indien nodig SDL en dergelijke gebruiken, maar dat is duidelijk iets anders. Om zoiets echt te integreren, zou ik het liever op het niveau van X geïmplementeerd zien dan binnen KDE of Gnome. Tenslotte heeft XFree86 de benodigde hardwaretoegang, die bovenopliggende programma's niet altijd even makkelijk krijgen.

---

link Beelzebubu schreef op Sunday 23 March 2003 03:51

quote:

odysseus schreef op 22 March 2003 @ 21:32:
Als je elke applicatie zijn eigen communicatie met 3D-hardware wilt laten uitvoeren, dan mag je, maar mij lijkt het niet handig . Natuurlijk kan een programma indien nodig SDL en dergelijke gebruiken, maar dat is duidelijk iets anders. Om zoiets echt te integreren, zou ik het liever op het niveau van X geïmplementeerd zien dan binnen KDE of Gnome. Tenslotte heeft XFree86 de benodigde hardwaretoegang, die bovenopliggende programma's niet altijd even makkelijk krijgen.

Maar die interface is er al lang. openGL.

---

link dikkebanaan schreef op Sunday 23 March 2003 14:03

quote:

Beelzebubu schreef op 22 March 2003 @ 21:27:
Dat is een applicatie kwestie, niet een X kwestie...

Ik heb het over een _widget toolkit_ die direct gebruik maakt van de hardware.
Dan bedoel ik dus dat Gtk en Qt dat moeten doen, niet de applicatie zelf ^[1]

quote:

Double buffering, bedoel je? Eens.

Dat zou idd een van de (beste) manieren wezen om dat probleem helemaal uit de wereld te helpen.
Voorlopig wordt er nog een hoop gehackt.. (zie xsync patches voor Gtk2/Metacity)

quote:

Mjah, I know... Kutzooi aldaar... Zegt op zich weinig over X, meer over de XFree86 devvers... .

Tjah.. het is te hopen dat er een fork komt.. die core developers lopen alleen maar uit hun (al dan niet virtuele) neus te vreten.

quote:

Waar ik bang voor ben, is dat bedrijven als ATI en nvidia heel lang zullen achteroverleunen qua commerciele driver development als de X standaard wordt weggegooid. Dat is toch het belangrijkste wat er nodig is om commerciele bedrijven zover te krijgen Linux te supporten...

En wees eerlijk, die opensource nv drivers zijn peanuts vergeleken met de nvidia drivers, geen discussie mogelijk...

btw. Lees dit stukje text van 9 Januari ook eens door (nog meer sappige roddels en achterklap ):
http://www.advogato.org/person/mharris/


[1] Meer:

quote:

Beelzebubu schreef op 23 March 2003 @ 03:51:
[...]


Maar die interface is er al lang. openGL.

Je dacht toch niet echt dat mensen hun progs allemaal gaan maken op de 'Blender manier'?

---

link Beelzebubu schreef op Sunday 23 March 2003 16:45

Hoe bedoel je? Er is een openGL extensie in X, er zijn GtkGL widgets (er is vast ook een QtGL widget)... Wat wil je nog meer dan? Een toolkit die jouw gedachten uitleest en daar automatisch bugloze code van maakt? Ik dacht dat we die academische prutzooi (Linus: "build a solution so much around the problem it addresses so, that it will face the same problems that the original solution did address") toch wel genoeg hadden bediscussieerd nu...

Wat willen jullie nou dan?

Ik vind sommige kritiek op XFree86 wel terecht. Een daarvan is de bloat factor. Het is iets van 70 MB en daarmee groter dan Win95. En wat is dat nou allemaal met die ingebouwde raster fonts? Compleet wazig als je het mij vraagt . Nee, waar ik mijn hoop op vestig is Fresco. Ondersteunt alpha transparantie, is netwerk transparant door gebruik van CORBA technieken en niet onbelangrijk: het is heel behoorlijk gedocumenteerd.

Ik zal eens een meninkje geven, wordt ook wel tijd dat ik eens minder vaag ben...

Allereerst, X is allerminst perfect. Het heeft grote tekortkomingen en die moeten worden aangepakt.

Echter, X is al jaren de standaard grafische platform van Unix/Linux. Elke applicatie draait onder X. Alles draait onder X. Alles is X. Alles - zowel closed-source als open-source. Met name die eerste groep zal een probleem worden als je van X afstapt, zoals elke move van A naar B problemen met zich meebrengt. Door de belangrijkheid van X is dit zo goed als onmogelijk. Ook gezien de groeiende groep aan closed-source drivers (anders gezegd: het groeiende aantal fabrikanten die eindelijk zelf drivers schrijft in plaats van het door de opensource community laat doen) zie ik een move niet gebeuren: je raakt het stabiliteitsvertrouwen van die fabrikanten kwijt, en hun drivers. Dat wil niemand. Kortom, van X afstappen is bijzonder ongewenst. Teveel negatieve zij-effecten.

Liever zou ik doen wat Havoc Pennington ook al langer voorstelt en implementeert: X extensies om de tekorten op te vullen, met behoud van API/ABI compatibility. Op termijn kunnen deze extensies hetzelfde als wat een volledig nieuw platform zou kunnen.

Het enige probleem wat dan nog overblijft is de bloat van de X API en de libs. Qua libs is dit onzin, omdat het dynamically loaded crap is, dus het neemt alleen HD space in. Qua API: get used to it, X is niet voor de random developer, X is voor experts. Kernel coden is ook niet voor iedereen weggelegt. Troll intended. Serieus: je moet niet verwachten dat iedereen low-level kan gaan coden, dat is veel te makkelijk gedacht. De meeste mensen hebben dat ook niet nodig, Gtk+ (Qt) of desnoods zelfs Gnome (KDE) app development biedt meer dan genoeg mogelijkheden. Zelfs met Glade kom je al een behoorlijk eind.

Kortom: X is verre van perfect, maar X afschuiven is onzinnig. X perfectioneren is veel handiger dan volledig overnieuw beginnen. Uiteindelijk kom je in je nieuwe design problemen tegen die X al jarenlang geleden heeft opgelost, als variant op Linus Torvalds' flame op academische professoren met hun nieuwe oplossingen voor problemen die zo gecentreerd zijn rond dat ene probleem dat ze in tientallen andere kuilen vallen die door de originele oplossingen netjes werden opgelost. Moraal van het verhaal: kijk eerst of je het met de originele oplossing en/of een uitbreiding daarop kan oplossen. Redesignen is meestal niet nodig.

Op het moment heb ik even niet de tijd om mijn mening volledig te onderbouwen, maar waar het op neerkomt is het volgende: op zich is XFree86 niet verkeerd (en is X11 ook niet verkeerd, al zou een backward-compatible X12 waarschijnlijk geen gek idee zijn), maar het development model is fout. Er zijn een stuk of wat mensen die schrijftoegang hebben tot de sources en die mensen kunnen maar een bepaalde hoeveelheid werk verrichten. Voorheen was het niet eens mogelijk om mailinglists te bekijken en zelf een developer worden kon je ook wel vergeten. Hoewel het project in naam wel een Free Software-project is, heeft het *te* veel trekjes van de Cathedral-style ontwikkeling. Keith Packard probeert daar iets aan te veranderen, maar slaagt er niet in. Zelf heb ik het idee dat hij wat teveel op die board-structuur focust, maar voor de rest lijk ik het wel met hem eens te zijn...hij heeft in ieder geval de afgelopen twee jaar het meeste zichtbare werk gedaan, dus hij verdient krediet als hij zegt dat er iets mis is. De ontwikkeling van XFree86 schiet door het kunstmatig veroorzaakte tekort aan core-developers niet op. In zo'n sfeer krijg je nooit een echt goede, moderne implementatie van X11.

* odysseus zou een volledig open ontwikkelde XFree86 willen zien, ongeveer op een manier zoals de kernel ontwikkeld wordt...een stabiele tak, maar zodra iemand dat wil ontstaat er toch meteen een zijstroom die vernieuwing brengt .

_{Goed idee dit topic, hier is best veel over te discussiëren .}

Inderdaad, de voortgang is veel te traag. Voorbeeld: ati-driver patches, van ati nota bena, worden gewoonweg genegeerd.
tekst

Verder vind ik het als niet-programmeur raar dat er geen DRI gelijktijdig met Xinerama kan werken.
Dat doet mij vermoeden dat beiden hele vieze hacks zijn, en dat daar nodig eens naar gekeken moet worden.
Na alles wat ik heb gelezen ziet het er uit als XFree86 aan knulligheid ten onder gaat.
Ze zouden goed moeten kijken hoe andere grote open-source projecten te werk gaan, zoals Gnome, KDE, de Linux-kernel, en veel meer contact moeten zoeken met de bedrijven die open-source ondersteunen, want velen van hun hebben er veel baat bij dat er een goede X server is.

Ik vraag me af hoe een Longhorn-achtig iets zou moeten werken met X.
De textures zitten in de applicatie, aan de client-side, en de acceleratie-hardware zit aan de server-side.
Moeten alle textures dan van te voren maar de server ingepompt worden? Zo ja, hoe gaat het texture-management werken dan? De clients weten niets van elkaar, en de server weet eigenlijk niets van de clients...
Ik vind OpenGL op X al een enorme hack, maar dat is in de regel beperkt tot een enkele applicatie tegelijk...
Hoe meerdere (in principe niet-lokale) clients tegelijkertijd een accelerated UI moeten gebruiken, is me totaal niet duidelijk.
Ik denk dat een Longhorn-achtig iets niet mogelijk zal zijn met het huidige X-model.
Is hier al over nagedacht door iemand?

Ik dacht dat XFree ook gewoon onder de GNU Public License viel? Dan mag iedereen de code toch aanpassen en modificeren zolang de copyright info maar vermeld staat?

Ik kan het mis hebben, maar als dat zo is en XFree houdt zich daar op deze manier niet aan, vind ik dus dat XFree dit geen GPL mag noemen. Je kunt het inzien maar daar houdt het mee op.

Ik vind het een slechte zaak...

De meeste acceleraties werken alleen lokaal. . Die werken dus niet via het client-/server-model.

Mijn mening

Ik volg de de nieuwe forum@xfree86 mailingslist sins het op slashdot/linux today stond.

Die list heel intressant maar ik krijg de indruk dat bepaalde "core" devs het lieftst niks zouden veranderen, ze blijven maar het zelfde roepen, terwijl "honderdden" anderen ze probeeren om te praten.

Er gebeurd niks met de O zo belanrijke CVS-write acces, er staan ongeveer 10 posts van mensen die hun eigen CVS hebben draaien en zeker langer dan een jaar onderhouden en verbeteren. Het "core" team denkt er met niet eens aan om die CVS rechten te geven.

ik ben absoluut geen kenner en ook geen devver, maar waarom wordt er niet een nieuw initiatief gestart op basis van de huidige Xfree86 code door devver die wel willen ontwikkelen/verbeteren? want wat ik nu lees is gewoonweg dat de core developers niet meer willen developen... (of zie ik dat verkeerd?)

Ach sweet sweet XFree86. Iemand zei ooit tegen me dat glibc "the source of all things good and evil" was. XFree86 is net zo'n project. Gigantisch. Oud. Gebonden aan afspraken, standaards en protocollen. De hele Open Source wereld zit vol met erorme, organisch gegroeide superprojecten waar niemand meer zonder kan. Soms wordt er gesnoeid (mozilla) soms wordt het redelijk in de hand gehouden (linux kernel).

We kunnen niet zonder XFree86; Fresco draai ik wel op m'n Hurd bak en de "core developers" oid nemen deze halve ``revolutie'' heel serieus; d'r is nog nooit zoveel veranderd op xfree86.org in zo'n korte tijd ;-).

Ik heb trouwens een hele tijd losse xfree86 bomen uit de DRI-tree getrokken voor hardware acclde drivers voor m'n G400, ging prima. Toen gebruikte ik net 3 maanden Linux.

Hoe dan ook, het komt allemaal wel goed. XFree86 heeft z'n onhebbelijkheden (ladingen vage x progjes die niemand gebruikt, rare toolkits en vast nog veel engere dingen) maar om nu te schreeuwen dat alles drastisch anders moet vind ik ook wat overdreven (niet dat iemand dat hier doet hoor, maar je hoort op slashdot wel eens wat).

Het komt uiteindelijk wel goed met X, echt waar. Al deze aandacht heeft het project trouwens heel erg veel goed gedaan, XFree86 komt vast (net als mozilla) weer in de publieke gratie.

Ohja, voor LinuxUser en iedereen diie het niet met me eens is, hier is de licence van de code: http://www.xfree86.org/legal/licence.html

Ga je gang. Veel plezier.

quote:

De meeste acceleraties werken alleen lokaal. . Die werken dus niet via het client-/server-model.

Erm dat is mijn punt toch ook? Dat die acceleraties niet kunnen werken als de client en server gescheiden zijn (en dat zijn ze in feite ook op hetzelfde systeem, want X is een client-server model)... Of wat bedoel je nou?

Laat ik es een voorbeeld geven...
Client a heeft een translucent window... Dit tekent hij op een texture, en upload het naar de server...
De server komt nu in geheugenproblemen... Hoe weet hij nu of hij de texture van client a uit moet swappen, of iets anders?
Hoe weet hij welke applicatie niet in gebruik is, en waarschijnlijk niet gebruikt zal worden?
En dan nog... Zal de server niet een enorme opslagplaats van redundant textures met UI-componentjes etc worden?
Of moet hij iedere keer de client opnieuw de zaak laten uploaden? En wordt dat niet teveel overhead van allerlei callbacks en geheugentransfers die niet nodig zijn? Etc....

Kortom, hoe ga je dat in godsnaam doen?
En als je het niet gaat doen, hoe ga je concurrentie met Longhorn, OS X etc aan?

idletoad wijzigde dit bericht 25-03-2003 01:02 (54%)

Beelzebubu bedoelde dat niet alles in XFree86 via een client/server model werkt en heeft daar gelijk in.

quote:

Beelzebubu bedoelde dat niet alles in XFree86 via een client/server model werkt en heeft daar gelijk in.

Ja, bv de OpenGL-hack, bedoel je?... maar daar heb ik het nu niet over... Ik heb het nu over een 3d-accelerated GUI, die compatible met X is... Hoe ga je dat doen?
Of waar hebben jullie het over? Jullie treden niet bepaald in detail ofzo...

Ja bv, of xvideo AFAIK.

OpenGL is niet zo'n hack hoor, ik kan nml. wel gewoon meerdere hardware geaccelde venstertjes draaien. Ik geloof zelfs dat tegenwoordig xinerama + dri werkt (maar dat weet ik niet zeker).

Anyway, het lijkt wel alsof je iets moeilijkers wil dan hoeft. Niemand *wil* een 3D-accelerated UI die netwerk transparant is. Gewoon allemaal local doen, zoals opengl gewoon al werkt met xfree86.

Ik geloof wel dat er ooit werd gewerkt aan netwerk transparante opengl dingen, maar geweldige framerates krijg je toch niet over je netwerkje.

Als je vraag is "Ik heb het nu over een 3d-accelerated GUI, die compatible met X is... Hoe ga je dat doen?" en met "compatible met X" bedoel je "netwerk transparent" dan is het antwoord heel eenvoudig: niet.

-[edit] typos

Misschien is dit meer wat je bedoelt? http://www.3dwm.org/frameset.html (3D window manager)

-[edit] link

bahsj wijzigde dit bericht 25-03-2003 01:25 (15%)

Ik bedoel niet dat het netwerk-transparant moet zijn... maar dat compatibiliteit met X betekent dat je vast zit aan het client-server model (in dit model wordt er geen onderscheid gemaakt tussen het al dan niet lokaal zijn van de client).

OpenGL werkt niet 'met xfree86'... OpenGL hackt een windowtje in xfree86 en tekent daar vrolijk lokaal doorheen... De server weet daar eigenlijk weinig of niets van...
Bij een 3d-accelerated UI is het verhaal dus behoorlijk anders.

Ik vraag me dus af wat de plannen zijn voor 3d-accelerated versies van X...
Want zoals het systeem nu werkt, zie ik geen mogelijkheid om het efficient te implementeren. Hooguit via een hoop redundancy en wat heuristics... maar dat gaat het natuurlijk niet redden tegen elegante oplossingen van Longhorn/OS X...

edit: Nee, 3dwm is niet wat ik bedoel... Ik bedoel een systeem zoals Longhorn, waarbij de gehele GUI via 3d-hardware geaccelereerd wordt (aa, scaling, blitting, scrolling, alphablend etc... alles kan met de moderne hardware). Het blijft echter wel gewoon een 2d-UI (specifieke 2d-hardware zal verdwijnen, en de 3d-pipelines nemen alle functionaliteit over... Longhorn wil dus ook maar meteen GDI door Direct3D vervangen, om overbodige drivers/emulatielayers te vermijden).

idletoad wijzigde dit bericht 25-03-2003 01:33 (24%)

idletoad, je bedoelt dus *wel* netwerk transparant. Misschien is mijn term wel verkeerd, maar "netwerk transparant" wil afaik zeggen dat het voor het werken van het gebeuren niet uitmaakt of er een netwerk zit tussen server en client. Wat dus hetzelfde is als "in dit model wordt er geen onderscheid gemaakt tussen het al dan niet lokaal zijn van de client".

Je kunt wel heel denigrerend zeggen dat "OpenGL een windowtje hackt", maar wil je het met enige snelheid doen, dan moet het voor zover ik weet ongeveer zo.

Waarom zou in hemelsnaam xfree86 zich druk moeten maken om een uitbreiding van het X protocol (wat jij in feite voorstelt) waar niemand op zit wachten, wat politiek veel te lastig is, en wat TOCH niet werkt omdat je netwerk daar ongeschikt voor is... (hoe jij je het voorstelt gooi je bv. vectoren/textures/etc/etc over het netwerk (of door een lokale socket) om daar aan de andere kant iets 3Digs van te renderen heh?)

Als MacOSX en Longhorn *wel* onderscheid maken tussen het al dan niet lokaal zijn van de client, waarom zou xfree86 dat niet mogen? Ja, als je het vergelijkt met hoe het tot nu toe ging bij X servers, dan is er een breuk ja. Nou en?

Of, als je hier geen genoegen mee neemt, dan wil ik best wel antwoorden dat ik werkelijk geen flauw idee heb of er plannen zijn voor een "3d-accelerated versies van X" (met "X", en "3d-accelerated" met een betekenis naar keuze) en al helemaal niet hoe dat dan zou moeten.

-[edit. Dit: (zou een nieuwe post moeten zijn) ]

quote:

(aa, scaling, blitting, scrolling, alphablend etc... alles kan met de moderne hardware).

Aah! Maar dan heb je vooral veel client side dingen! Dan hoef je helemaal niet het X protocol (totaal ;-)) om te gooien! Render clientside je fonts of je whatever aa-ed, of alphablended, op eventuele aanwijzingen van je x server...

Of je nu 8bits kleur doorstuurd of 24+8 (laatste 8 als aphachannel bv) maakt in feite voor je protocol niet uit, zolang je maar genoeg bandbreedte hebt... en dat wordt bij dat soort aantallen wel een beetje een probleem...

Hehehe, het is laat ja, het is laat. Maar nu begrijp ik eindelijk wat je bedoelt. Toch iets wat lijkt op http://www.fresco.org/.

Tsja, ik denk niet dat dat er ooit van komt. Ik denk eerder dat er een beetje doorgehannest gaat worden zoals het nu gaat. Gewoon, optioneel de font rendering over laten nemen door een bepaalde extensie, of optioneel de scaling laten doen door de 3d cap. van je video kaart. Voor een deel kunnen dit soort dingen al, ik kan met mijn G400 de XTexture extensie gebruiken voor xvideo dingen, ipv xvideo, dan scalet ie dus hardwarematig. Nadeel wel is dat dri dan niet meer werkt, dus het is vrij zinsloos als je af en toe opengl wil gebruiken.

Als je alleen wil aa-en, of scalen, of blitten, of scrollen, waarom haalde je dan die hele client/server dingen d'r bij? Dit soort dingen MOETEN toch clientside, en ALLEEN clientside? (Oef, tijd voor een link naar een rant van jwz over die achterlijke client/server nomenclatuur bij X, want ik geloof dat ik het nu heel erg fout doe, dus draai client/server maar om... )

bahsj wijzigde dit bericht 25-03-2003 02:54 (42%)

Ik zal op een aantal reacties reageren, maar eerst even mijn mening over dit hele gedoe:

Het X Window System kan nog prima mee. Eens zal het opgevolgd moeten worden door iets moderners, maar dat is op dit moment (of de komende 5 à 10 jaar) naar mijn mening absoluut niet nodig. Het X protocol is duidelijk flexibel gebleken, en extensies à la MIT-SHM, GLX, Xvideo, XRandR, XRender hebben bewezen dat X11 hiermee succesvol aan te passen is aan nieuwere hardware en software-eisen.

Maar dan is een fatsoenlijke X server natuurlijk wel een eis. En daar schort het af en toe wat aan. XRender belooft gaaf te worden, en heeft de potentie heel veel nieuws te bieden, maar een gedeeltelijke hardware-accelerated implementatie hiervan is gepland voor XFree86 5.0, waarvan het nog niet eens duidelijk is wanneer die gaat verschijnen. Dat schiet niet op.

XFree86 development heeft een schop nodig. Een fork zou denk ik zo slecht nog niet zijn. De fork wordt dan waarschijnlijk veel opener, en veel experimenteergrager. XFree86 kan zich dan aanpassen en meegaan (waardoor beide projecten van elkaar kunnen profiteren, desnoods via een experimental - production symbiose), of XFree86 kwijnt zachtjes weg terwijl de fork het overneemt.

quote:

dikkebanaan schreef op 22 March 2003 @ 17:50:
- Geen ondersteuning voor bv andere kleurmodellen (blegh, 32 bpp fb wordt niet eens normaal ondersteund)

Dat is niet waar, 32 bpp wordt gewoon ondersteund. Als je in XFree86's config "24" opgeeft voor de colordepth, dan zal XFree86 naar eigen inzicht kiezen of 24 of 32 bpp gebruikt moet worden. Hoe XFree86 dat beslist weet ik niet, maar ik meende dat 32 bpp werd gekozen waar mogelijk. Ook weet ik dat dit te overriden is (lees de manpages maar eens).

quote:

Maar het ergste vind ik eigenlijk toch wel dat de meeste van die zgn 'core developers' van XFree86 tegenwoordig alleen nog maar op hun reet zitten toe te kijken, zitten te zeiken over politiek spul en tegenwoordig nooit meer een enkele regel code schrijven voor XFree86.

Dat is een beetje oneerbiedig en kort door de bocht. Een aantal (niet allemaal nee) van de core developers doen _echt_ wel veel. Alleen die paar zijn niet genoeg om zo'n enorme source tree te onderhouden. Dat is ook één van de dingen die moeten veranderen: het aantal developers dat werkelijk aan de code mag zitten.

quote:

jointm1k schreef op 24 maart 2003 @ 22:49:
Ik vind sommige kritiek op XFree86 wel terecht. Een daarvan is de bloat factor. Het is iets van 70 MB en daarmee groter dan Win95.

Iets minder dan dat hoor
XFree86 + xlibs + allerlei fonts + xclients-base is 35 MB. Alleen XFree86 + xlibs (wat basaler) is 15 MB. En dat is dus inclusief drivers voor honderden videokaarten. Kon erger dus.

quote:

Nee, waar ik mijn hoop op vestig is Fresco.

Fresco is voor XFree86 wat de HURD is voor de Linux kernel.

Fresco is in design eleganter (al trek ik hun "wij dicteren de widgetset" idee in twijfel). Vooral het idee om alles zo vector-based mogelijk op te bouwen ipv pixel-based is zeer interessant en kan in de toekomst een belangrijke aanpak worden.

Maar op het moment zie ik in theorie voor Fresco's idee nog geen plaats op huidige computers. Laat staan in de praktijk met Fresco's huidige implementatie.

De HURD is technisch gezien ook eleganter en superieur aan de Linux kernel. Gebruik jij de HURD?

quote:

FCA schreef op 24 maart 2003 @ 23:55:
Verder vind ik het als niet-programmeur raar dat er geen DRI gelijktijdig met Xinerama kan werken.

Dat ligt dan aan jou of aan je drivers gok ik, want op een machine met een Matrox G450 en XFree86 hier werkt zowel Xinerama als accelerated 3D dmv DRI

quote:

idletoad schreef op 25 March 2003 @ 00:05:
Ik vraag me af hoe een Longhorn-achtig iets zou moeten werken met X.

Define "een Longhorn-achtig iets" ?

quote:

De clients weten niets van elkaar, en de server weet eigenlijk niets van de clients...

Je noemt ons verder in dit topic "weinig specifiek", maar zelf ben je ook een beetje vaag hoor Het zinnetje dat ik quote is juist heel erg van toepassing op X.

quote:

LinuxUser schreef op 25 maart 2003 @ 00:11:
Ik dacht dat XFree ook gewoon onder de GNU Public License viel? Dan mag iedereen de code toch aanpassen en modificeren zolang de copyright info maar vermeld staat?

Nee, niet GPL, maar hoofdzakelijk MIT X11 license, en deels andere (waaronder BSD-style, en vast ook wel stukjes (L)GPL).

Maar dat doet er niet toe; MIT X11 is net zo goed een Free license (anders zat XFree86 niet in Debian/main ).

quote:

Ik kan het mis hebben, maar als dat zo is en XFree houdt zich daar op deze manier niet aan, vind ik dus dat XFree dit geen GPL mag noemen. Je kunt het inzien maar daar houdt het mee op.

Ik vind het een slechte zaak...

Het is gewoon Free hoor. Als je wilt forken: ga je gang, het is volkomen legaal.

Het punt is dat een fork veel energie gaat verspillen. Een aantal van de XFree86 core members werken veel aan XFree86 en kennen de source goed. Als je XFree86 goed aan wil pakken, dan wil je liever met die mensen samenwerken dan direct met ze concurreren.

quote:

kroeske schreef op 25 March 2003 @ 00:30:
want wat ik nu lees is gewoonweg dat de core developers niet meer willen developen... (of zie ik dat verkeerd?)

Dat zie je verkeerd. Als de XFree86 core developers niks meer wilden doen, dan was er al lang een revolutie in het XFree86 development model geweest, of er was een fork gestart. Het grote punt is dat het XFree86 core team op een te gesloten manier werkt: slechts een paar (15 ?) man hebben cvs commit-access, dus als je iets aan de XFree86 main tree wil toevoegen, dan moet dat via één van die 15 man (waarvan de helft or so inderdaad niks doet).

Zelf bij het XFree86 core team gaan horen is vrijwel onmogelijk, omdat je daar zeer lastig binnenkomt.

quote:

idletoad schreef op 25 March 2003 @ 00:58:
Laat ik es een voorbeeld geven...
Client a heeft een translucent window... Dit tekent hij op een texture, en upload het naar de server...
De server komt nu in geheugenproblemen... Hoe weet hij nu of hij de texture van client a uit moet swappen, of iets anders?

Een applicatie moet pixmap alloceren, en die uploaden naar de server. Voor verdere acties refereert de client aan die pixmap (zonder hem opnieuw te uploaden). De server houdt die in het geheugen (een pixmap is gealloceerd voor een reden en mag niet zomaar weggeflikkerd worden).

quote:

Hoe weet hij welke applicatie niet in gebruik is, en waarschijnlijk niet gebruikt zal worden?

Wat boeit het of een applicatie "in gebruik" is?

quote:

En dan nog... Zal de server niet een enorme opslagplaats van redundant textures met UI-componentjes etc worden?

Niet direct redundant. Een X client alloceert een pixmap met een reden. Ze worden geacht die vrij te geven of te hergebruiken as they see fit.

quote:

Kortom, hoe ga je dat in godsnaam doen?

Is geen kwestie van "gaan doen", dat is minstens al een jaar of tien zo

quote:

bahsj schreef op 25 maart 2003 @ 01:18:
Ja bv, of xvideo AFAIK.
Ik geloof wel dat er ooit werd gewerkt aan netwerk transparante opengl dingen, maar geweldige framerates krijg je toch niet over je netwerkje.

OpenGL is al netwerk-transparant met XFree86. Tenminste, XFree86' GLX module werkt gewoon over het netwerk. Alleen DRI acceleratie werkt niet remote. Dat zou op te lossen kunnen zijn door XFree86' GLX module gebruik van DRI te laten maken ipv de clients zelf via xlibmesa3, maar er is om de een of andere reden (die mij even ontgaan is) niet voor die manier van acceleratie gekozen.

quote:

Als je vraag is "Ik heb het nu over een 3d-accelerated GUI, die compatible met X is... Hoe ga je dat doen?" en met "compatible met X" bedoel je "netwerk transparent" dan is het antwoord heel eenvoudig: niet.

Dat is onzinnig, zie boven. Mogelijk is het altijd.

quote:

idletoad schreef op 25 March 2003 @ 01:29:
(in dit model wordt er geen onderscheid gemaakt tussen het al dan niet lokaal zijn van de client).

Dat is niet helemaal waar. Het X Window System schrijft voor dat connecties tussen client en server geschied via TCP/IP of DecNET als de server en client op verschillende hosts draaien. Als de server en client op dezelfde host draaien, dan moet comminucatie via TCP/IP of DecNET mogelijk zijn, maar mag ook via een sneller locaal systeem gebeuren.

En dat doet XFree86 op GNU/Linux (en vele andere OSsen) ook. Als het allemaal lokaal draait worden Unix domain sockets gebruikt (aanzienlijk sneller dan een complete netwerk socket), en wordt shared memory gebruikt voor o.a. pixmaps.

quote:

OpenGL werkt niet 'met xfree86'... OpenGL hackt een windowtje in xfree86 en tekent daar vrolijk lokaal doorheen... De server weet daar eigenlijk weinig of niets van...

True, en toch niet helemaal. Als 3D via DRI gedaan wordt, dan klopt je verhaal. Maar XFree86 kan het zelf ook via GLX (zij het non-accelerated).

quote:

Ik vraag me dus af wat de plannen zijn voor 3d-accelerated versies van X...

Ik ook. Acceleratie van GLX lijkt me een interessante oplossing, maar ik ken te weinig van de details om te zeggen of dat (performance-) technisch haalbaar is. En ik weet al helemaal niet of ze het van plan zijn (voorlopig niet zou ik zeggen... Er zijn andere delen die aandacht verdienen).

quote:

edit: Nee, 3dwm is niet wat ik bedoel... Ik bedoel een systeem zoals Longhorn, waarbij de gehele GUI via 3d-hardware geaccelereerd wordt (aa, scaling, blitting, scrolling, alphablend etc... alles kan met de moderne hardware). Het blijft echter wel gewoon een 2d-UI (specifieke 2d-hardware zal verdwijnen, en de 3d-pipelines nemen alle functionaliteit over... Longhorn wil dus ook maar meteen GDI door Direct3D vervangen, om overbodige drivers/emulatielayers te vermijden).

Waarom is dit relevant? Het boeit niet door welke hardware het gerenderd wordt. De apps kunnen gewoon een 2D api gebruiken, als het OS dat rendert dmv de 3D hardware... Echt, het zal de applicaties aan hun reet roesten.

quote:

bahsj schreef op 25 March 2003 @ 01:52:
Voor een deel kunnen dit soort dingen al, ik kan met mijn G400 de XTexture extensie gebruiken voor xvideo dingen, ipv xvideo, dan scalet ie dus hardwarematig. Nadeel wel is dat dri dan niet meer werkt, dus het is vrij zinsloos als je af en toe opengl wil gebruiken.

Hmm, wat bedoel je precies? Hardware overlay + scaling + colorspace conversion kan gewoon via de Xvideo extensie, AFAIK zeker op de G400. En, what's more, tegelijk met DRI accelerated 3D.

quote:

(Oef, tijd voor een link naar een rant van jwz over die achterlijke client/server nomenclatuur bij X, want ik geloof dat ik het nu heel erg fout doe...)

De X server is het programma dat het eigenlijke tekenwerk doet (naar de hardware, of via een andere laag zoals een kernel) en de input events opvangt. X clients zijn applicaties die gebruik maken van een X server om iets op het scherm te zetten.

Het is heel logisch hoor: een server luistert voor inkomende connecties, en biedt clients die connecten bepaalde diensten aan.
Waarom snapt iedereen dat voor Apache + Mozilla, maar niemand voor XFree86 + gimp ?

quote:

idletoad schreef op 25 March 2003 @ 01:29:
Ik bedoel niet dat het netwerk-transparant moet zijn... maar dat compatibiliteit met X betekent dat je vast zit aan het client-server model (in dit model wordt er geen onderscheid gemaakt tussen het al dan niet lokaal zijn van de client).

OpenGL werkt niet 'met xfree86'... OpenGL hackt een windowtje in xfree86 en tekent daar vrolijk lokaal doorheen... De server weet daar eigenlijk weinig of niets van...
Bij een 3d-accelerated UI is het verhaal dus behoorlijk anders.

Nee nee nee, je snapt XFree86 maar half.

De standaard windowing werkt via client/server. Het zal je vast wel opgevallen zijn dat er geen gigantische dataload over localhost/lo wordt geschreven als je een X sessie opent. Dat komt omdat lokaal hele andere delen van X werken dan remote. Remote is simpel: TCP/IP over network sockets. Client ene kant, server andere kant, data transfer van elke pixel, klaar. Lokaal werkt dit al heel anders, daar wordt shmem gebruikt, dus server en client (die in principe dus nu hetzelfde zijn) sharen de data pointer. Dus, geen data transfer. Perfect efficient. OpenGL werkt 't zelfde. In 't geval van openGL moet zowel de client als de server openGL rendering ondersteunen, ik weet niet of 't ook dezelfde machine moet zijn (volgens mij niet). Echter, als dat verschillende machines zijn, dan is acceleratie natuurlijk onmogelijk (hoe wil je remote de PCI/AGP bus aanspreken?). XVideo werkt alleen lokaal - zelfde reden.

Nu op naar jouw vraag over translucentie e.d. en het static houden van bitmap data/textures. X werkt in het ideale geval met een layered opbouw, waarin elke window die zichtbaar is gevraagd wordt zich te tekenen, in zo'n volgorde dat uiteindelijk je desktop ontstaat. Stel nu dat je dus alpha gebruikt - dan wordt de window daaronder gevraagd zich te tekenen, en vervolgens de window-on-top. Overigens houdt X een cache van de laatste pixmap, dus als je geen windows verschuift maar alleen de top window groter maakt, dan vallen pixels van de onderliggende windows gewoon weg en wordt er geen redraw event ge-emit.

X werkt ongelofelijk simpel. .

quote:

jointm1k schreef op 24 March 2003 @ 22:49:
Ik vind sommige kritiek op XFree86 wel terecht. Een daarvan is de bloat factor. Het is iets van 70 MB en daarmee groter dan Win95. En wat is dat nou allemaal met die ingebouwde raster fonts? Compleet wazig als je het mij vraagt . Nee, waar ik mijn hoop op vestig is Fresco. Ondersteunt alpha transparantie, is netwerk transparant door gebruik van CORBA technieken en niet onbelangrijk: het is heel behoorlijk gedocumenteerd.

Je kan X niet vergelijken met win' 95. X is bedacht toen Gates nog z'n pampers volscheet, en draait op zowat alles wat er op deze wereld aan PC's bestaat. Windows '95 draait alleen op een Intel, en zonder patches draait het ook nog beroerd. Die bloat wordt mede veroorzaakt omdat alle videodrivers in de betreffende source zitten.

Een van de grootste problemen met X is de verkeerde architectuur, en de backwards compability. Het beste is gewoon van scratch af beginnen, zoals bv met een groot aantal delen van de 2.4 kernel is gedaan. Helaas zit je dan wederom met compabiliteit, dus het blijft eeb kip en ei probleem.

quote:

Als MacOSX en Longhorn *wel* onderscheid maken tussen het al dan niet lokaal zijn van de client, waarom zou xfree86 dat niet mogen? Ja, als je het vergelijkt met hoe het tot nu toe ging bij X servers, dan is er een breuk ja. Nou en?

Omdat je backward-compatibility wil (moet) hebben.
Je hebt niet zoveel aan een fancy hypermodern GUI-systeem als er geen enkele applicatie op draait.

quote:

Aah! Maar dan heb je vooral veel client side dingen! Dan hoef je helemaal niet het X protocol (totaal ;-)) om te gooien! Render clientside je fonts of je whatever aa-ed, of alphablended, op eventuele aanwijzingen van je x server...

Hoe krijg je die aanwijzingen dan? Niet via het huidige systeem.

quote:

Als je alleen wil aa-en, of scalen, of blitten, of scrollen, waarom haalde je dan die hele client/server dingen d'r bij? Dit soort dingen MOETEN toch clientside, en ALLEEN clientside?

Omdat X nu eenmaal zo werkt. De server en de client zijn compleet gescheiden, alleen verbonden door een socket (of evt. Shm, maar dat is ook niet fantastisch)... En dus is samenwerking tussen de twee een groot probleem.

quote:

Define "een Longhorn-achtig iets" ?

Je mag jezelf wel eens beter informeren... Maar goed, ik had het al ergens hierboven uitgelegd.

quote:

Het zinnetje dat ik quote is juist heel erg van toepassing op X.

Misschien wel, maar het had totaal geen informatieve waarde, en droeg niets bij tot de discussie.. Ik kan ook wel gaan roepen "linux is een opensource kernel".
Waarheid als een koe, maar het zegt niets. Beetje meer uitleg mag, samenhang, graag.

quote:

Een applicatie moet pixmap alloceren, en die uploaden naar de server. Voor verdere acties refereert de client aan die pixmap (zonder hem opnieuw te uploaden). De server houdt die in het geheugen (een pixmap is gealloceerd voor een reden en mag niet zomaar weggeflikkerd worden).

Maar die pixmap gaat nu op een texture gemapt worden, in videogeheugen met beperkte opslag.

quote:

Als de server en client op dezelfde host draaien, dan moet comminucatie via TCP/IP of DecNET mogelijk zijn, maar mag ook via een sneller locaal systeem gebeuren.

Ja dat weet ik ook wel. Maar aangezien je dezelfde API-calls maakt, heb je daar weinig mee te maken. Het is TRANSPARANT, zoals al tig keer geroepen is. Hoe het geimplementeerd is, maakt niet uit... Je krijgt niet ineens extra functionaliteit en extra samenwerking door een client lokaal te draaien... En daar zit het probleem.

quote:

Maar XFree86 kan het zelf ook via GLX (zij het non-accelerated).

Wat heb je nu aan non-accelerated 3d? Dan heb je meteen al de bovengenoemde voordelen niet meer (aa etc...).

quote:

Waarom is dit relevant? Het boeit niet door welke hardware het gerenderd wordt. De apps kunnen gewoon een 2D api gebruiken, als het OS dat rendert dmv de 3D hardware... Echt, het zal de applicaties aan hun reet roesten.

Het gaat erom dat het efficient moet gebeuren.
Verder is dat 3dwm volgens mij gewoon een extra layer... waar eerst de windowtjes gerenderd worden in software, op een texture, en dan in 3d geprojecteerd... dat heeft dus ook niet de voordelen.

quote:

Lokaal werkt dit al heel anders, daar wordt shmem gebruikt

Ook alleen maar als je zelf de code met Shm-APIs schrijft... En dan nog is de snelheidswinst zeer beperkt.

Naja, ik hoor het al, kennelijk heeft nog niemand hierover nagedacht...

quote:

X is bedacht toen Gates nog z'n pampers volscheet

Nee. Het is in begin jaren 80 ontwikkeld, en volgens mij was de eerste bruikbare versie er in 1984... Windows stamt uit omstreeks 1985... Dus zoveel verschil zit er niet...

quote:

Windows '95 draait alleen op een Intel

En wat heeft dat ermee te maken?

quote:

en zonder patches draait het ook nog beroerd

Ga jij eens een XFree86 uit 1995 draaien zonder patches? Dan praten we verder.

quote:

Die bloat wordt mede veroorzaakt omdat alle videodrivers in de betreffende source zitten.

Uhh, WAT?

quote:

deadinspace schreef op 25 March 2003 @ 03:40:
Ik zal op een aantal reacties reageren, maar eerst even mijn mening over dit hele gedoe:

Het X Window System kan nog prima mee. Eens zal het opgevolgd moeten worden door iets moderners, maar dat is op dit moment (of de komende 5 à 10 jaar) naar mijn mening absoluut niet nodig. Het X protocol is duidelijk flexibel gebleken, en extensies à la MIT-SHM, GLX, Xvideo, XRandR, XRender hebben bewezen dat X11 hiermee succesvol aan te passen is aan nieuwere hardware en software-eisen.

Maar dan is een fatsoenlijke X server natuurlijk wel een eis. En daar schort het af en toe wat aan. XRender belooft gaaf te worden, en heeft de potentie heel veel nieuws te bieden, maar een gedeeltelijke hardware-accelerated implementatie hiervan is gepland voor XFree86 5.0, waarvan het nog niet eens duidelijk is wanneer die gaat verschijnen. Dat schiet niet op.

XFree86 development heeft een schop nodig. Een fork zou denk ik zo slecht nog niet zijn. De fork wordt dan waarschijnlijk veel opener, en veel experimenteergrager. XFree86 kan zich dan aanpassen en meegaan (waardoor beide projecten van elkaar kunnen profiteren, desnoods via een experimental - production symbiose), of XFree86 kwijnt zachtjes weg terwijl de fork het overneemt.

Dat ligt dan aan jou of aan je drivers gok ik, want op een machine met een Matrox G450 en XFree86 hier werkt zowel Xinerama als accelerated 3D dmv DRI

Hmm... Inderdaad, hier werkt het ook inmiddels, maar volgens mij gaf 4.2.1 nog gewoon de melding dat er Xinerama gebruikt werd, en dat daarom DRI werd uitgeschakeld. Of misschien lag dat aan die brakke ATI proprietary drivers die niet met Xinerama werkten ofzo.
Afijn, ik werd misschien wat boos omdat ik nu al een paar maanden zit te kloten met 3D support met m'n Radeon 9500Pro op een nForce 2 onder Linux, en niemand dit nog aan de praat heeft gekregen. In mijn woede heb ik nu alle mogelijke bronnen beschuldigd.
Ik ben er nu achter waarom het niet werkt:
Een combinatie van proprietary drivers voor de nforce, de radeon, die niet geupdate worden of alleen werken met bepaalde dingen en een gebrek aan medewerking van XFree86 devvers met ATI.

Al met al geen prettige situatie, en ik vrees dat in de toekomst hierdoor nieuwe hardware alleen maar moeilijker ondersteund zal worden. Maar dat ligt natuurlijk ook aan de hardware vendors.

quote:

idletoad schreef op 25 March 2003 @ 10:11:
Omdat je backward-compatibility wil (moet) hebben.
Je hebt niet zoveel aan een fancy hypermodern GUI-systeem als er geen enkele applicatie op draait.
[...]
Hoe krijg je die aanwijzingen dan? Niet via het huidige systeem.

Weet jij wel hoe X werkt?

Dit doet X al lang!

quote:

Wat heb je nu aan non-accelerated 3d? Dan heb je meteen al de bovengenoemde voordelen niet meer (aa etc...).

3D en AA zijn volledig onafhankelijk. AA kan ook remote, afhankelijk van de server rendering.

quote:

Ook alleen maar als je zelf de code met Shm-APIs schrijft... En dan nog is de snelheidswinst zeer beperkt.

Naja, ik hoor het al, kennelijk heeft nog niemand hierover nagedacht...

Dan mag je met bewijzen komen. Ik verzeker je dat via Shm X net zo snel draait als het zou draaien als het lokaal-only was.

Ik vrees dat jij de structuur van X nog niet helemaal kent... Heb je al eens in de X sources rondgewroet? X applicaties (dus straight op de X API, geen toplevel shit a la Pango, GDK-X11 ofzo - laat staan Gtk/Gnome/Qt/KDE) geprogrammeerd? Verdiep je er eens in voordat je zomaar iets roept!

quote:

Weet jij wel hoe X werkt?

Dit doet X al lang!

Hoe dan?

quote:

3D en AA zijn volledig onafhankelijk. AA kan ook remote, afhankelijk van de server rendering.

Daar gaat het niet om... je gaat geen AA in software doen... Dat schiet niet op. Dat doe je met 3d-hardware. Of had je dat nog niet begrepen?

quote:

Dan mag je met bewijzen komen. Ik verzeker je dat via Shm X net zo snel draait als het zou draaien als het lokaal-only was.

Ben ik het niet mee eens... Mijn geanimeerde windowtje ging met Shm van 14 naar wel 16 fps... In Windows draaide datzelfde geanimeerde windowtje toch zeker 20 fps.

quote:

Ik vrees dat jij de structuur van X nog niet helemaal kent... Heb je al eens in de X sources rondgewroet? X applicaties (dus straight op de X API, geen toplevel shit a la Pango, GDK-X11 ofzo - laat staan Gtk/Gnome/Qt/KDE) geprogrammeerd?

Ja dat heb ik, zowel met als zonder Shm, en geen speciale libs/widgets... alleen X.
Waarom meteen daarachter proberen te verschuilen?

quote:

Verdiep je er eens in voordat je zomaar iets roept!

Kijk jij zelf liever uit wat je roept, altijd meteen maar roepen dat de ander er niets van begrepen heeft... Irritante kwaal in de linux-community. Ik stop met deze discussie. Als we zo gaan beginnen, dan hoeft het niet meer... Arrogante drol.