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

[PipoDeClown]

XFree86 4.4 is released. Welke distro's gaan deze wel voeren?

[Anoniem: 73385]

Wonderbaarlijk !

Juist NU !

En de nieuwe features zijn, laat me raden:

• Alpha Translucency
• On the fly resolutie veranderingen
• Kleinere footprint
• Wat dies meer zij...

update:

After tremendous testing and community feedback, the 4.4.0 Release is now available for seveteen (yep that's 17!) popular platforms and with more coming in the ensuing week

Wel genant om juist op zo'n overduidelijke locatie een spelfout te maken...
Hadden ze misschien tóch meer haast dan ze willen doen overkomen ?

[ Voor 46% gewijzigd door Anoniem: 73385 op 29-02-2004 22:10 . Reden: update ]

[Anoniem: 73385]

Alhier vindt men de Release Notes.

Wat de inhoud daarvan is kan ik nog niet melden, aangezien xfree86.org lijkt te lijden onder een niet kwaadaardige DoS ...

[Apache]

Anoniem: 73385 schreef op 29 februari 2004 @ 20:06:
En hoe weet die server wanneer hij dat moet toepassen ?

Ik neem aan dat niet alles in en uit fade...

de server kent volgens mij wel het onderscheid tussen een main window met windowhandle ed en een popup menu en kan die dus transparant weergeven (onder popup menus valt dus ook dingen als bovenaan in een applicatie)

en anders geeft hij effectief het hele venster transparant weer (borders kan natuurlijk weer gewoon blijven omdat dat ook door de wm gaat)

in 4.4 zitten niet zo'n spectaculair grote wijzigingen, niks dat dicht in de buurt komt van freedesktop, xouvert of directfb.

een vraag uit het publiek was trouwens of freedesktop niet hetzelfde als xouvert probeerde te bereiken, waarop Keith Packard zei dat xouvert meer research achtige richting opging, minder stabiel ging zijn omdat er sneller en grotere veranderingen werden doorgevoerd dan bij freedesktop die voor een stabiele X gaan maar die wel voldoet aan moderne eisen.

[Anoniem: 27915]

xouvert lijkt vooralsnog dood... Ik gok vooralsnog op FDO's X server. .

[HarmoniousVibe]

Ik denk dat we op de korte termijn het meest gebaat zijn bij de fork van RC2(laatste GPL-compatible release) door fd.o.

[TWBMS]

hmm als ik zo de reacties lees van o.a. de bedrijven etc, dan lijkt het er op dat Xfree86 hun graf hebben gegraven met de verandering in hun licentie..

Of zie ik dat verkeerd?

[Erhnam]

Xfree 4.4 is uit.. Ben benieuwd welke distro deze in gebruik neemt

Ohw iemand wasmij voor

[ Voor 18% gewijzigd door Erhnam op 01-03-2004 13:18 ]

[Anoniem: 73385]

Anoniem: 27915 schreef op 01 maart 2004 @ 05:17:
xouvert lijkt vooralsnog dood... Ik gok vooralsnog op FDO's X server. .

Volgens hun mailinglist zijn ze dood ja...

[Anoniem: 73385]

de server kent volgens mij wel het onderscheid tussen een main window met windowhandle ed en een popup menu en kan die dus transparant weergeven (onder popup menus valt dus ook dingen als bovenaan in een applicatie)

Dat is dan niet zo mooi, die taak zou bij de Windowmanager moeten liggen lijkt mij...

[Anoniem: 27915]

Window managers of applicaties (via de UI toolkit) geven een "status" aan een window, zoals "toplevel", "popup", "embedded", etc. Daarmee weet de X server dus wat 'ie ermee moet doen, ook w.r.t. transparency.

[Anoniem: 73385]

En daarmee zijn de mogelijke widgets al direct beperkt door de X Server.

Natuurlijk, je kan het laten weergeven hoe je maar wil, maar in essentie is het beperkend, en bovendien is het het vertroebelen van verantwoordelijkheden.

Wat dat betreft is Fresco een stuk consistenter.

[Anoniem: 27915]

Hoezo dat? In feite is transparency een property van de window type. Net zoals appearance, plaatsing, parenting, etc. Dit werkt ontzettend goed. Een set properties definieert een window type. Wiskundig gezien kun je het ongetwijfeld als een set flags zien, zo jij wilt.

[Anoniem: 73385]

Juist.

Maar wat bedoel je met een window type ?

Impliceert dat dat je dus zelf die types kan ontwerpen, aangezien ze worden onderscheiden door de properties ?

Dus dat de widgets een soort objecten zijn, die de X Server in dit geval zelf construeert (maar dat is logisch gezien voorspelbaar als je die server bepaalde properties voert). Ik heb verder totaal geen verstand van de techniek achter het X protocol hoor, dus hoe die properties exact technisch gezien worden doorgegeven weet ik niet, maar is dit wat je bedoelt ?

Zo niet, verklaar je aub nader ..

Mijns inziens is Y Windows geen goed alternatief. En wel hierom:

In-server implementation of widgets
Y specifies a core set of widget classes. Objects of these classes are stored in the server, where they are closer to the user and thus more responsive from the user's point of view.

Haha, dat draait een beetje om mijn punt heen. Allicht zal het sneller zijn als alle mogelijke widgets, en dus ook de classes daarvan (afhankelijk van de technische implementatie van die widgets natuurlijk) al in de X Server (Y Server in dit geval ) vast staan.

Het is echter wel inflexibel. Natuurlijk is die inflexibiliteit geen ramp voor real world situaties, de desktopuser geeft er simpelgezegd geen reet om. Maar ja, ik blijf de eeuwige perfectionist ...

Modularity (plug-in style: dynamically unloadable and reloadable)
Unload an old video driver, load a new version. On the fly. No restart in sight.

Weer een schijnvoordeel. Natuurlijk is dit mooi en aardig, maar je kunt niet ontkennen dat het symptoombestrijding is, en persoonlijk prefereer ik eerlijkgezegd wat meer structurele oplossingen .

Oftewel: X Server en videodriver gescheiden houden. Ik begrijp dat dat mogelijk complicaties geeft, vooral voor de (hardware-) optimalisaties. De videodriver is dan immers niet op de hoogte van de precieze structuur van alle elementen op de desktop (zoals welk window on top ligt etc; zelfs uberhaupt welke windows er zijn). Wat de verdere gevolgen daarvan zijn kan ik ook niet zo uit m'n mouw schudden, ik denk dat iemand als Beelzebubu daar meer over weet te vertellen, met zijn kennis op dit gebied. Het gaat er maar om dat duidelijk is wat ik bedoel.

Consistency and Themeability
Y widgets use the currently loaded theme to render themselves. Since all server widgets are using the same theme, all widgets appear consistent throughout the desktop.

Is niet meer dan logisch en een vereiste om serieus te worden genomen als alternatief.

Client applications can also use the theme's drawing operations, allowing specialised widgets to make themselves fit in with the look-and-feel.

Wat hij hiermee wil zeggen is mij niet geheel duidelijk. Allereerst verwacht ik dat dit reeds het geval is met de themes voor de bekende windowmanagers op XFree86.
Wat nu precies het voordeel of het bijzondere aan dit is zie ik ook niet in.

Support for hardware acceleration
The Y design can make use of hardware acceleration to speed up rendering operations. This can even include the use of 3D-accelerators' textures to draw windows with (someone has already implemented a prototype of this which is very smooth).

Hmm, tja. Is ook al het geval bij XFree86, alhoewel dat veel te wensen over laat , zoals reeds geconstateerd.

Hoe dit technisch precies is geregeld is onduidelijk, maar ik sta iig voor dat de hardwarefabrikant de hardwareoptimalisaties in zijn drivers regelt, niet de auteur(s) van de Y Server. Dit om alles niet wederom spaak te laten lopen, door eventuele bureaucratie bij het team wat aan (in dit geval) de Y Server werkt. Ook lijkt mij dat de mogelijke optimalisaties en/of speciale features per kaart (sterk) verschillen, en dat de fabrikant ook de beste kennis heeft hoe die mogelijkheden zo goed mogelijk te benutten.

Maar ok, dat is weer een heel andere discussie .

Better internationalisation, localisation, and accessiblity
In-server widgets means there can be exactly one current language, one complex input method system for languages that require them, and one set of accessibility features.

En wat betekent dat ? Dat zou wel eens tot gevolg kunnen hebben dat je voor iedere taal een apart theme moet maken (en bovenal: de user moet dat weer downloaden/installeren). Dat ligt voor de hand als het om de strings etc gaat, maar de grafische elementen zullen niet zozeer verschillen (meestal).

Ook is onduidelijk of je nu wel de taal on-the-fly kunt veranderen. Dat lijkt mij nogal elementair, zeker als je wél de resolutie en zelfs de videodriver op die manier kunt veranderen ...

Als je themes on-the-fly kunt veranderen, zou dat dus ook met de taal kunnen als dat theming systeem zo elkaar zit als ik nu schets (afgeleid van wat ik begrijp uit de info op die site).


Nu zullen velen zeggen: maar dit is helemaal geen X Server, een Y Server. Ik weet niet precies in hoeverre dit het geval is, naast de andere naam (). Ik zie de features van die Y Server niet als dermate baanbrekend en positief dat ze (praktisch) niet in een X Server, als XFree86 zouden kunnen worden verwerkt.

Daarom ben ik van mening dat dit project alleen maar meer diversiteit (in negatieve zin) zal zaaien, iets wat niet bevordelijk zal zijn voor de adoptie van een *nix (Linux lijkt vooralsnog de meest kansrijke kandidaat) Desktop voor de normale user.

Als er een oligopolie ontstaat van oplossingen voor die desktop (inclusief alternatieven voor X als Fresco) zullen hardwarefabrikanten waarschijnlijk ook hun vingers niet aan *nix drivers willen branden.

En last but not least is mij onduidelijk of deze Y Server gebruik maakt van het X(11) protocol of niet. Als dat niet het geval is zal dat behoorlijk tegen de Y Server werken, want veel applicaties zijn op X gericht, alleen al de grote (en dus wat meer volwassen) windowmanagers als Gnome en KDE.

Nou, zo kan ik natuurlijk nog wel een hele tijd doorgaan met het puntsgewijs becommentarieren van de technische eigenschappen van die Y Server . Het lijkt me dat mijn punt wel duidelijk is; die Y Server is verre van ideaal.

Fresco lijkt mij zoals ik al eerder zei erg interessant, maar ik begrijp dat er voorlopig niet naar uit ziet dat dat een succes op grote schaal wordt, niet in de laatste plaats door het onconventionele karakter daarvan (met alle gevolgen van dien)....

Ik mag dan misschien over komen als een pessimist, ik hebt op zich best vertrouwen in een verbeterde X Server zoals die van FreeDesktop.org. Voorlopig houdt ik het daar dan ook maar bij.

Maar ik ben niet bekend met de technische eigenschappen van het X protocol (dat is de enige echte beperking, alhoewel het natuurlijk praktisch erg moeilijk wordt als men grote delen van de fork van XFree86 over moet gaan doen), en kan dus ook niet oordelen over de mogelijkheden en onmogelijkheden daarvan.

[ Voor 2% gewijzigd door Anoniem: 73385 op 02-03-2004 14:59 . Reden: [b]-tags ]

[Anoniem: 107036]

dingstje schreef op 29 februari 2004 @ 17:20:
Waar wacht je nog op? Freebsd Porters Handbook en de sources is all you need

Tja ik ben nog niet zo'n guru die dat 1,2,3 port.. misschien wel een keer interessant om te bekijken maar ik las al een paar mailings, van iemand die het aan het porteren was naar FreeBSD, met technische opmerkingen die me werkelijk van A tot Z niks zeiden dus ik denk dat ik m'n tijd beter kan besteden aan iets kleinere projecten

Was er niemand van NOS op FOSDEM die een paar leuke foto's of movies heeft geschoten?

Owja was er op FOSDEM nog gezegt wanneer de eerste echte release uitkomt ?

[Anoniem: 73385]

offtopic:
Porten voor FreeBSD is trouwens wonderbaarlijk gemakkelijk, alleen wat met de makefile rotzooien, gcc is verkrijgbaar voor FreeBSD dus dat zorgt ervoor dat alles meestal netjes compiled.

Alleen als mensen programma's gaan schrijven die speciaal op Linux gericht zijn (bijv. assumpties over locaties van bepaalde bestanden) dan wil het nog wel eens mis gaan. Vaak zijn de auteurs van dat programma echter wel bereid om een door derden gemaakte kleine patch voor de source te accepteren, dus dat loopt wel los.

[ Voor 2% gewijzigd door Anoniem: 73385 op 02-03-2004 14:55 . Reden: typo ]

[Anoniem: 27915]

Tenzij je system calls doet...

Een keer raden wat X doet. .

edit:
Ik kijk zo naar je post. Ik heb niet superveel tijd, doe dit tussen de experimenten door, maargoed... Kom d'r zo op terug!

[ Voor 53% gewijzigd door Anoniem: 27915 op 02-03-2004 18:34 ]

[Anoniem: 73385]

Ja, en die system calls zijn dus speciaal op Linux gericht .

Maar Beelzebubu, ik ben benieuwd naar jouw commentaar op mijn X post, ik neem aan dat jij meer verstand van zaken hebt hieromtrent....

offtopic:
LOL Experimenten altijd leuk

[ Voor 14% gewijzigd door Anoniem: 73385 op 02-03-2004 19:04 ]

[Anoniem: 27915]

Anoniem: 73385 schreef op 01 maart 2004 @ 20:54:
Maar wat bedoel je met een window type ?

Impliceert dat dat je dus zelf die types kan ontwerpen, aangezien ze worden onderscheiden door de properties ?

Dus dat de widgets een soort objecten zijn, die de X Server in dit geval zelf construeert (maar dat is logisch gezien voorspelbaar als je die server bepaalde properties voert). Ik heb verder totaal geen verstand van de techniek achter het X protocol hoor, dus hoe die properties exact technisch gezien worden doorgegeven weet ik niet, maar is dit wat je bedoelt ?

Zo niet, verklaar je aub nader ..

Nee, widgets en types zijn niet zo close gerelateerd. Vanuit Gtk+ gezien (heb ik meer ervaring mee) is bijna elke widget een GdkWindow (abstraction van een XWindow). Nu kun je je voorstellen dat een 'button' en een 'venster' niet hetzelfde zijn. Beiden zijn echter een GdkWindow, en voor de X server dus in zoverre gelijk. Nu heeft elke window een set properties die zijn type aangeven waardoor het eindresultaat er uitziet zoals het er uit ziet. Voorbeelden van zulke properties zijn width, height, parent window (voor embedding), toplevel (zo ja, dan krijgt 'ie een WM border, tenzij andere properties dit weer niet willen), root window (je desktop), etc.

Voor de X server is alles een XWindow. Veel meer dna dat weet ze ook niet, want alle drawing operations worden asynchroon uitgevoerd. De opbouw van je desktop werkt dan zo: teken root window, get list of childs, if visible, teken van achter naar voren. En dat dan dus recursief. Elke draw wordt aan de client gerequest, en de client voert dan weer tekenoperaties op de server uit (blit).

De client (Gtk+, de toolkit) is verantwoordelijk voor opbouw van widgets, theming, uiterlijk, dat soort dingen.

Mijns inziens is Y Windows geen goed alternatief.

Y is niks. Y is zo'n leuk leuter-universiteits-projectje waar niks uit zal komen. [/troll]

Haha, dat draait een beetje om mijn punt heen. Allicht zal het sneller zijn als alle mogelijke widgets, en dus ook de classes daarvan (afhankelijk van de technische implementatie van die widgets natuurlijk) al in de X Server (Y Server in dit geval ) vast staan.

Het is niet sneller! Iedereen denkt dat, maar iedereen verwart runtime code ook met protocol. Het X protocol is ontzettend complex, dat geef ik onmiddelijk toe. Echter, lokaal draait alles via localhost unix sockets en shmem, en dan is er geen snelheidsverlies t.o.v. serverside beeldopbouw. Sure, op details kun je veel verbeteren, maar algemeen genomen is X echt wel goed opgezet.

Het punt van protocol vs. runtime code is als volgt: X client (Gtk+) geeft opdracht aan X en die wordt "asynchroon" uitgevoerd door de server. Complex! Bloat! Eng! Oi! NOT! Want in werkelijkheid betekent dit slechts dat ik een bitje door mijn unix socket gooi, de kernel doet op gegeven moment een taskswitch (en die doet 'ie aan de lopende band) en mijn X server leest een bitje. Dit heet asynchroon maar door de manier van taskswitchen in moderne 32bits OS'en is dit in realiteit zo goed als synchroon. En als je - buiten de taskswitch om - kijkt naar de werkelijke operaties die worden uitgevoerd, dan zijn ze hetzelfde.

X kan - wat dit betreft - dus niet langzamer zijn!

Is niet meer dan logisch en een vereiste om serieus te worden genomen als alternatief.

Ah welnee joh, dat moet de client doen. Hoe kun je anders meerdere desktops runnen op 1 server?

code:

X -- :1.0

Ooit geprobeerd? .

Hoe dit technisch precies is geregeld is onduidelijk, maar ik sta iig voor dat de hardwarefabrikant de hardwareoptimalisaties in zijn drivers regelt, niet de auteur(s) van de Y Server. Dit om alles niet wederom spaak te laten lopen, door eventuele bureaucratie bij het team wat aan (in dit geval) de Y Server werkt. Ook lijkt mij dat de mogelijke optimalisaties en/of speciale features per kaart (sterk) verschillen, en dat de fabrikant ook de beste kennis heeft hoe die mogelijkheden zo goed mogelijk te benutten.

Hardware optimilisaties horen alleen om deze reden al in de kernel thuis. Gelukkig snapt het DRM project dat, en volgt nvidia die trend (alhoewel de scheiding tussen X driver/kernel driver daar wat vaag is omdat men niet weet welke wat doet).

En wat betekent dat ? Dat zou wel eens tot gevolg kunnen hebben dat je voor iedere taal een apart theme moet maken (en bovenal: de user moet dat weer downloaden/installeren). Dat ligt voor de hand als het om de strings etc gaat, maar de grafische elementen zullen niet zozeer verschillen (meestal).

Ook is onduidelijk of je nu wel de taal on-the-fly kunt veranderen. Dat lijkt mij nogal elementair, zeker als je wél de resolutie en zelfs de videodriver op die manier kunt veranderen ...

Als je themes on-the-fly kunt veranderen, zou dat dus ook met de taal kunnen als dat theming systeem zo elkaar zit als ik nu schets (afgeleid van wat ik begrijp uit de info op die site).

Taal is een sessie eigenschap; hoe wil je anders taal per sessie op een multi-user OS instellen? Om dat onderdeel te maken van een server is vrij onnozel, de server moet juist door de client gedreven worden om strings te renderen. En wie bepaalt de content van de strings? Juist! De client. Dus moet de client dit soort dingen regelen, niet de server.

Door dit soort functies in de server te integreren maak je het syeteem meer en meer afhankelijk van de specifieke grafische implementatie. Dan krijg je dus iets als win32, waar de UI onderdeel van de base system is. en dat hoort niet. Want mijn terminal moet ook i18n'ized zijn. Vim ook; make ook.

Anyway, again: Y is een unversiteitsprojectje van een student die nog veel moet leren. X is opgezet door de beste mensen ter wereld op de beste opleiding ter wereld. Ik zeg niet dat X perfect is, maar d'r is wel over nagedacht. Veel dingen kunnen beter, maar je moet het niet anders doen om het anders doen, maar om de verbetering. en dat mist Y.

[mOrPhie]

Anoniem: 27915 schreef op 02 maart 2004 @ 19:05:
Het is niet sneller! Iedereen denkt dat, maar iedereen verwart runtime code ook met protocol. Het X protocol is ontzettend complex, dat geef ik onmiddelijk toe. Echter, lokaal draait alles via localhost unix sockets en shmem, en dan is er geen snelheidsverlies t.o.v. serverside beeldopbouw. Sure, op details kun je veel verbeteren, maar algemeen genomen is X echt wel goed opgezet.

Het punt van protocol vs. runtime code is als volgt: X client (Gtk+) geeft opdracht aan X en die wordt "asynchroon" uitgevoerd door de server. Complex! Bloat! Eng! Oi! NOT! Want in werkelijkheid betekent dit slechts dat ik een bitje door mijn unix socket gooi, de kernel doet op gegeven moment een taskswitch (en die doet 'ie aan de lopende band) en mijn X server leest een bitje. Dit heet asynchroon maar door de manier van taskswitchen in moderne 32bits OS'en is dit in realiteit zo goed als synchroon. En als je - buiten de taskswitch om - kijkt naar de werkelijke operaties die worden uitgevoerd, dan zijn ze hetzelfde.

X kan - wat dit betreft - dus niet langzamer zijn!

Afgezien van het feit dat ik het alleen maar eens kan zijn met jou verhaal en ik verder dus weinig met Y heb, wil ik toch nog even wat kwijt.

Ik ben met beide protocollen (X en Y) maar een beetje bekend (X meer), maar is het niet zo dat bij Y de data (de bitjes) die de client naar de server stuurt uiteindelijk -minder- is, omdat themes en widgets door de server worden berekend... en de client dus niet meer een hele widget hoeft te sturen naar de server, maar alleen de "vraag" een widget te tonen? (compleet afgezien van het feit, dat ik die benadering lichtelijk krakkemikkig vind)

Zeker over een netwerk zou dat in snelheid schelen toch?

[Anoniem: 27915]

mOrPhie schreef op 02 maart 2004 @ 19:31:
Ik ben met beide protocollen (X en Y) maar een beetje bekend (X meer), maar is het niet zo dat bij Y de data (de bitjes) die de client naar de server stuurt uiteindelijk -minder- is, omdat themes en widgets door de server worden berekend... en de client dus niet meer een hele widget hoeft te sturen naar de server, maar alleen de "vraag" een widget te tonen? (compleet afgezien van het feit, dat ik die benadering lichtelijk krakkemikkig vind)

Zeker over een netwerk zou dat in snelheid schelen toch?

Over een netwerk. Maar in 99,9% van de gevallen praten we over lokaal, en Y ondersteunt volgens mij uberhaupt geen network transparency. En lokaal gebruikt X shmem, waarbij server en client dezelfde geheugenadressen gebruiken en er dus geen datacopy plaatsvindt. .

[Anoniem: 73385]

Nee, widgets en types zijn niet zo close gerelateerd. Vanuit Gtk+ gezien (heb ik meer ervaring mee) is bijna elke widget een GdkWindow (abstraction van een XWindow). Nu kun je je voorstellen dat een 'button' en een 'venster' niet hetzelfde zijn. Beiden zijn echter een GdkWindow, en voor de X server dus in zoverre gelijk. Nu heeft elke window een set properties die zijn type aangeven waardoor het eindresultaat er uitziet zoals het er uit ziet. Voorbeelden van zulke properties zijn width, height, parent window (voor embedding), toplevel (zo ja, dan krijgt 'ie een WM border, tenzij andere properties dit weer niet willen), root window (je desktop), etc.

Dan is het al stukken beter, maar toch vind ik nog steeds dat de X Server alleen maar met pixmaps ed dient te werken. Maar ok, dat zal wel praktisch onwerkbaar zijn.

Elke draw wordt aan de client gerequest, en de client voert dan weer tekenoperaties op de server uit (blit).

Hoe bedoel je ?

Ik neem aan dat de client alleen de droge parameters doorgeeft (zoals die XWindows en properties) en dat de X Server daar iets moois van bakt, adhv die properties etc.

quote:
Mijns inziens is Y Windows geen goed alternatief.

Y is niks. Y is zo'n leuk leuter-universiteits-projectje waar niks uit zal komen. [/troll]

Hehe, dat vind jij dus ook ...
Nou ja, ik had geen voorkennis over dat Y, en aangezien er nu zo'n gedonder is rond XFree86 wilde ik ff alle genoemde alternatieven langsgaan.
Wie weet was het nodig dat ik sommigen uit de illusie moest helpen dat Y wat is...

Het is niet sneller! Iedereen denkt dat, maar iedereen verwart runtime code ook met protocol. Het X protocol is ontzettend complex, dat geef ik onmiddelijk toe. Echter, lokaal draait alles via localhost unix sockets en shmem, en dan is er geen snelheidsverlies t.o.v. serverside beeldopbouw. Sure, op details kun je veel verbeteren, maar algemeen genomen is X echt wel goed opgezet.

Haha, niet dat ik daar zelf zo stellig van overtuigd was ...

Ik heb er zelfs geen bezwaar tegen als de X Server ook lokaal via het loopback adres communiceert, is snel genoeg hoor.

quote:
Is niet meer dan logisch en een vereiste om serieus te worden genomen als alternatief.

Ah welnee joh, dat moet de client doen. Hoe kun je anders meerdere desktops runnen op 1 server?

Ik doelde op consistentie van widgets. Nogal wiedes dat die er altijd en overal hetzelfde uit moeten zien ! Daarom begrijp ik niet dat de programmeur van de Y Server dat als voordeel aanprijst.

Dus volgens mij haal je je quotes een beetje door de war ...
Ik zie nergens iets wat over X Servers vs Clients gaat rondom dat fragment...

Taal is een sessie eigenschap; hoe wil je anders taal per sessie op een multi-user OS instellen? Om dat onderdeel te maken van een server is vrij onnozel, de server moet juist door de client gedreven worden om strings te renderen. En wie bepaalt de content van de strings? Juist! De client. Dus moet de client dit soort dingen regelen, niet de server.

Ja hehe, maar het theme is dat ook, en de taal is (in de opzet van de Y Server) een deel van het theme.

Anyway, again: Y is een unversiteitsprojectje van een student die nog veel moet leren. X is opgezet door de beste mensen ter wereld op de beste opleiding ter wereld. Ik zeg niet dat X perfect is, maar d'r is wel over nagedacht. Veel dingen kunnen beter, maar je moet het niet anders doen om het anders doen, maar om de verbetering. en dat mist Y.

Ben ik het zeker mee eens.


Wat ik dus nog niet helemaal begrijp aan je post is het client/server verhaal.
Bij mijn weten geeft de X client de 'parameters' door (continu), zoals cursorpositie, input etc. Hieronder zou ook het aantal en de staat van de Xwindow objecten kunnen vallen, of dat momenteel ook zo is weet ik niet maar dat doet ook niet echt ter zake voor de theorie erachter.

De X Server processed die parameters, en output daarbij een 'plaatje', al dan niet in de vorm van een soort pixmap, en displayed die op het scherm van de client. Als die server lokaal draait dan stuurt ie het gegenereerde beeld toch eerst op naar de client, ipv het direct naar het display device te tekenen.

Deze opzet geeft op één punt toch wel te denken. Als je nou de grafische calculaties aan de client over wilt laten, bijvoorbeeld omdat die een veel betere videokaart heeft, kan dat niet zomaar. Ik wil niet zeggen dat je dat moet willen, en dat het een vereiste is dat dit moet kunnen, maar het zou toch wel beter zijn.

Maar hoe bedoel jij bijv. dat de client die widgets van bijv. de GTK tekent ?

[Anoniem: 73385]

Ik ben met beide protocollen (X en Y) maar een beetje bekend (X meer), maar is het niet zo dat bij Y de data (de bitjes) die de client naar de server stuurt uiteindelijk -minder- is, omdat themes en widgets door de server worden berekend... en de client dus niet meer een hele widget hoeft te sturen naar de server, maar alleen de "vraag" een widget te tonen? (compleet afgezien van het feit, dat ik die benadering lichtelijk krakkemikkig vind)

Zeker over een netwerk zou dat in snelheid schelen toch?

Dat is inderdaad zo, maar wat hebben we daaraan (zoals je zelf al in twijfel trekt) ?
Er valt trouwens maar te bezien hoeveel dat oplevert aan dataverkeer(-besparing), wie weet wel méér, door al die poespas die die maker van plan is te integeren...

Maar in 99,9% van de gevallen praten we over lokaal, en Y ondersteunt volgens mij uberhaupt geen network transparency.

Hehe, dat is wél zo, maar niet dat dat het beter zou maken ...

En lokaal gebruikt X shmem, waarbij server en client dezelfde geheugenadressen gebruiken en er dus geen datacopy plaatsvindt. .

Volgens mij was dit eerder al door een ander ontzenuwd, bijster veel voordeel zou dat shmem niet opleveren...

Maar dat maakt niet uit, data via de loopback zenden is echt wel snel zat hoor, responsiveness kun je ook op andere manieren bereiken.

[ Voor 2% gewijzigd door Anoniem: 73385 op 02-03-2004 20:12 . Reden: typo's ]

[Anoniem: 27915]

Anoniem: 73385 schreef op 02 maart 2004 @ 20:03:
Dan is het al stukken beter, maar toch vind ik nog steeds dat de X Server alleen maar met pixmaps ed dient te werken. Maar ok, dat zal wel praktisch onwerkbaar zijn.

Dat doet ze in principe ook, alleen gerenderde pixmaps, en dat noemen we dan drawables.

Hoe bedoel je ?

Ik neem aan dat de client alleen de droge parameters doorgeeft (zoals die XWindows en properties) en dat de X Server daar iets moois van bakt, adhv die properties etc.

De client geeft een soort pixmap en de properties door. Denk je nu in dat een window volledig verborgen is achter een andere; deze zal dan niet refreshen als er iets binnen die applicatie gebeurt. De buffer blijft dus "oud", dat scheelt CPU cycles (hey, elke cycle is d'r eentje. ). Als de window weer (partially) visible wordt, krijgt 'ie een signaal voor een redraw, zodat de pixmap weer 'vers' is.

Ik heb er zelfs geen bezwaar tegen als de X Server ook lokaal via het loopback adres communiceert, is snel genoeg hoor.

Oooeeee, daar vergis je je in. .

Wat ik dus nog niet helemaal begrijp aan je post is het client/server verhaal.
Bij mijn weten geeft de X client de 'parameters' door (continu), zoals cursorpositie, input etc. Hieronder zou ook het aantal en de staat van de Xwindow objecten kunnen vallen, of dat momenteel ook zo is weet ik niet maar dat doet ook niet echt ter zake voor de theorie erachter.

De X Server processed die parameters, en output daarbij een 'plaatje', al dan niet in de vorm van een soort pixmap, en displayed die op het scherm van de client. Als die server lokaal draait dan stuurt ie het gegenereerde beeld toch eerst op naar de client, ipv het direct naar het display device te tekenen.

Deze opzet geeft op één punt toch wel te denken. Als je nou de grafische calculaties aan de client over wilt laten, bijvoorbeeld omdat die een veel betere videokaart heeft, kan dat niet zomaar. Ik wil niet zeggen dat je dat moet willen, en dat het een vereiste is dat dit moet kunnen, maar het zou toch wel beter zijn.

Maar hoe bedoel jij bijv. dat de client die widgets van bijv. de GTK tekent ?

Je hebt verschillende types client/server interacties. Je hebt display<->renderer (X server, X client), en je hebt applicatie<->backend (toolkit, X server). Jij noemt nu de eerste, ik ging met name op de tweede in. De eerste werkt grotendeels zoals jij aangeeft. .

[Anoniem: 73385]

De client geeft een soort pixmap en de properties door. Denk je nu in dat een window volledig verborgen is achter een andere; deze zal dan niet refreshen als er iets binnen die applicatie gebeurt. De buffer blijft dus "oud", dat scheelt CPU cycles (hey, elke cycle is d'r eentje. ). Als de window weer (partially) visible wordt, krijgt 'ie een signaal voor een redraw, zodat de pixmap weer 'vers' is.

Ja maar hoe zit de taakverdeling nu precies ?
Je slaagt er goed bepaalde praktische voorbeelden te geven, maar de theorie erachter begrijp ik zo nog niet direct.

Je hebt verschillende types client/server interacties. Je hebt display<->renderer (X server, X client), en je hebt applicatie<->backend (toolkit, X server). Jij noemt nu de eerste, ik ging met name op de tweede in. De eerste werkt grotendeels zoals jij aangeeft.

Ja maar een combinatie van datalles is een werkend raderwerk. Hoe zit de verdeling nu precies want ik zie door de bomen het bos niet meer.

Met theorie bedoel ik natuurlijk niet de technische werking tot in detail, maar gewoon wat nu wat doet en waarom. Niet waarom iets dat doet, in plaats van die ander, daarom en daarom.

[ Voor 3% gewijzigd door Anoniem: 73385 op 03-03-2004 17:39 ]

[Anoniem: 27915]

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.

[mOrPhie]

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.

[CyBeR]

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

[Anoniem: 31357]

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.

[MadEgg]

Anoniem: 31357 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.

[Anoniem: 31357]

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.

[CyBeR]

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.

[Anoniem: 27915]

Anoniem: 31357 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.

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.

[Anoniem: 31357]

Anoniem: 27915 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?

[Anoniem: 27915]

Anoniem: 73385 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? .

[Erhnam]

http://slashdot.org/artic...2&tid=185&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...

[Niek]

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.

[sebas]

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.

[Anoniem: 73385]

@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

[sebas]

"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.

[Anoniem: 73385]

Het is voor de early adaptors...

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

[mOrPhie]

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.

[Anoniem: 27642]

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)

[Anoniem: 73385]

@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 ...

[mOrPhie]

Anoniem: 73385 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.

[slager]

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?

[Anoniem: 27915]

Anoniem: 73385 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. . * Anoniem: 27915 zou dit voor de grap eens een tijdje full-time moeten doen bij een of andere distro-bakker...

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. .

[Erhnam]

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!!!

[Anoniem: 4417]

Van de topicstarter:

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)!

[ Voor 4% gewijzigd door Anoniem: 4417 op 22-04-2004 17:19 ]

[Anoniem: 73385]

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.

[ Voor 7% gewijzigd door Anoniem: 73385 op 22-04-2004 19:04 ]

[mOrPhie]

Mja cybarite, maar in de nabije toekomst gok ik het er toch op, dat de fork, die nu zoveel chaos en hype brengt, toch positieve gevolgen gaan hebben. Zij het, dat x.org goed en wel geadopteerd wordt en gebruikt, anders wordt Xfree86 wel wakker geschud.

[Anoniem: 73385]

Dat is toch precies wat ik zeg?

edit:
Ah I understand, verradelijke zin.
Lees het deel rondom "waarvan" nog maar eens aandachtig...

[ Voor 63% gewijzigd door Anoniem: 73385 op 23-04-2004 15:17 . Reden: update ]

[mOrPhie]

Ik dacht dat je met de zin bedoelde dat er dan nooit een fork nodig had geweest, maar ik snap waar je heen wilde

Affin, back ontopic

[Anoniem: 51493]

Anoniem: 4417 schreef op 22 april 2004 @ 17:18:

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!

Op FOSDEM beweerde meneer Packard dat meneer Dawes zijn eigen licentie in de XFree86 source verspreide dmv zijn code daaronder te laten vallen. Dat samen met de paranoia-praat welke meneer Dawes verspreid ("een groot complot") en tenslotte de vooruitstrevende ontwikkelingen van FD.O leidt bij mij tot de conclusie "mazzel XFree86!".

[Anoniem: 4417]

Anoniem: 51493 schreef op 23 april 2004 @ 18:12:
[...]


Op FOSDEM beweerde meneer Packard dat meneer Dawes zijn eigen licentie in de XFree86 source verspreide dmv zijn code daaronder te laten vallen. Dat samen met de paranoia-praat welke meneer Dawes verspreid ("een groot complot") en tenslotte de vooruitstrevende ontwikkelingen van FD.O leidt bij mij tot de conclusie "mazzel XFree86!".

Ik vind het nog steeds frappant dat David Dawes kennelijk de enige is die openbaar namens het XFree86-project mag spreken. Is die man een dictator of zo? Waarom horen we nauwelijks iets van de andere ("niet-dissidente") XFree86-ontwikkelaars?

[Erhnam]

Ik kreeg laatst een slide van SUN onder mijn ogen. Blijkbaar werken ze samen Keith mee aan de implementatie van de SUN Glass desktop.

http://freedesktop.org/Software/XDevConf/LG-Xdevconf.pdf

[ Voor 24% gewijzigd door Erhnam op 30-05-2004 15:52 ]

[Anoniem: 27915]

Anoniem: 4417 schreef op 25 april 2004 @ 12:47:
Ik vind het nog steeds frappant dat David Dawes kennelijk de enige is die openbaar namens het XFree86-project mag spreken. Is die man een dictator of zo? Waarom horen we nauwelijks iets van de andere ("niet-dissidente") XFree86-ontwikkelaars?

Omdat niet elke hacker een goede publieke spreker is.

[Niek]

BTW, Slackware (de enige grote distro die XFree 4.4 gebruikte) is nu ook overgestapt naar X.org (zie http://osnews.com/comment.php?news_id=7210). Ik denk dat we XFree onderhand wel dood kunnen verklaren

[Zym0tiC]

The_Surfer schreef op 31 mei 2004 @ 18:30:
BTW, Slackware (de enige grote distro die XFree 4.4 gebruikte) is nu ook overgestapt naar X.org (zie http://osnews.com/comment.php?news_id=7210). Ik denk dat we XFree onderhand wel dood kunnen verklaren

grrrrr dan mag ATI nu langzamerhand wel eens drivers gaan releasen voor X.org

[Niek]

Zym0tiC schreef op 31 mei 2004 @ 22:57:
[...]


grrrrr dan mag ATI nu langzamerhand wel eens drivers gaan releasen voor X.org

Wat is het probleem? De ATI (XFree 4.3) drivers werken perfect in X.org. Het schijnt zelfs dat ze beter werken dan in XFree 4.4:

Patrick Volkerding:
I also noticed that the ATI Radeon binary drivers designed for XFree86 4.3.0 do not work with XFree86 4.4.0, but do work with the X.Org release.

[mOrPhie]

Erhnam schreef op 30 mei 2004 @ 15:45:
Ik kreeg laatst een slide van SUN onder mijn ogen. Blijkbaar werken ze samen Keith mee aan de implementatie van de SUN Glass desktop.

http://freedesktop.org/Software/XDevConf/LG-Xdevconf.pdf

Doel je hiermee op de referentie naar de Composite-extention in het XServer gedeelte? De verwijzing naar Keith zie ik namelijk nergens.

[FCA]

The_Surfer schreef op 01 juni 2004 @ 08:00:
[...]

Wat is het probleem? De ATI (XFree 4.3) drivers werken perfect in X.org. Het schijnt zelfs dat ze beter werken dan in XFree 4.4:
[...]

1. Ze werken niet helemaal perfect. Vanaf XFree 4.4 RC2 ofzo (dus ook in X.org) heb ik het probleem dat de Xvideo niet werkt, of alleen in het begin. Is een bekend probleem, met meerdere drivers (ook de SiS dingen geloof ik). Dit probleem zit trouwens net zo goed in XFree 4.4
2. Het probleem met XFree 4.4 was redelijk triviaal op te lossen door ergens in een Xversion.h o.i.d. te zeggen dat het om XFree 4.4 RC5 ging ofzo, dan werkte het allemaal net zoals in X.org.

[Erhnam]

Hoop dit topic nieuw leven te kunnen inblazen.

Weer een tijdje geleden maar iedereen weet dat X.org 6.8.2 er aan zit te komen.

Candidate 2 is uit:

http://cvs.freedesktop.or...RG-6_8-branch&view=markup

Voor de mensen die het leuk vinden om te testen:

Een howto hoe je de laatste CVS aan de praat krijgt en up2date houdt!

http://www.neowin.net/for...php?showtopic=204593&st=0



Wie heeft er nog nieuwe updates?

[ Voor 15% gewijzigd door Erhnam op 14-01-2005 15:19 ]

[Anoniem: 31491]

ATI brengt binnenkort (de 17e dacht ik) eindelijk nieuwe drivers uit. MET support voor Xorg 6.8.

bron

[irondog]

JA! Nieuwe drivers.

http://www.ati.com/suppor...&submit.y=11&submit=GO%21

Heeft iemand ze al getest?

[c0deaddict]

Hoe zit het nou met de nieuwe X.org
Er zou toch een versie 7.0 komen waarin grote delen van de oude X Server herschreven zouden worden ?
Want nu is X.Org niet veel meer dan XFree86 met een paar extra extensies ... (toch ?)

[dawuss]

KLEI_j0s schreef op maandag 17 januari 2005 @ 22:24:
Hoe zit het nou met de nieuwe X.org
Er zou toch een versie 7.0 komen waarin grote delen van de oude X Server herschreven zouden worden ?
Want nu is X.Org niet veel meer dan XFree86 met een paar extra extensies ... (toch ?)

Als het goed is wordt in de nieuwe X.org de hele boel netjes gemodulariseerd. X.org is zeker meer dan een fork van XFree86 met wat extra's. Op het moment wordt vooral nagedacht over de toekomst van de architectuur rond X zelf. Ze zitten daar heus niet stil

[Anoniem: 27915]

Jullie bedoelen KDrive? Da's de opvolger van X.org waar Keith Packard en dergelijke aan werken. Flink alpha, maar te volgen via de freedesktop.org repositories. Enkelen durvals hier op GoT hebben het geloof ik zelfs draaien...

[Erhnam]

Anoniem: 27915 schreef op maandag 17 januari 2005 @ 23:19:
Jullie bedoelen KDrive? Da's de opvolger van X.org waar Keith Packard en dergelijke aan werken. Flink alpha, maar te volgen via de freedesktop.org repositories. Enkelen durvals hier op GoT hebben het geloof ik zelfs draaien...

freedesktop.org repositories... Heb jij een url voor mij? Ben wel benieuwd!

[Anoniem: 27915]

http://www.freedesktop.org/wiki/Software_2fXserver
http://www.freedesktop.org/wiki/Software_2fxlibs

[Erhnam]

http://blog.drinsama.de/erich/en/linux

Nog wat kleine probleempjes in de laatste releases. Ziet er naar uit dat het allemaal wat langer op zich laat wachten.

[dawuss]

Wat mij wel erg tegenvalt in de huidige releases van de X.org XServer, is dat de composite extensie niet tegelijk geladen kan worden met GLX driver. Ik hoop dat ze dat snel gaan implementeren, want het is een behoorlijke tegenvaller.

[Bananenplant]

Misschien een open deur, maar weet iemand of x.org ook tzt in debian gaat komen..?

[sampoo]

ucchan schreef op woensdag 26 januari 2005 @ 14:06:
Misschien een open deur, maar weet iemand of x.org ook tzt in debian gaat komen..?

Tzt komt x.org om debian. Maar reken maar niet dat het vlot zal zijn. debian's eigen patches op Xfree86 maken het retestabiel en x.org zal voorlopig te unstable zijn om zelf in debian "unstable" een plekje te vinden.

[Anoniem: 27915]

Wat een gelul. . Debian is simpelweg te traag, en da's niet voor 't eerst...

[dawuss]

Anoniem: 27915 schreef op donderdag 27 januari 2005 @ 00:15:
Wat een gelul. . Debian is simpelweg te traag, en da's niet voor 't eerst...

Volgens mij was het een bewuste keuze X.org niet in debian op te nemen voor het helemaal gemodulariseerd is, omdat er anders veel overbodig werk gebeurt.

[mOrPhie]

dawuss schreef op donderdag 27 januari 2005 @ 00:26:
[...]

Volgens mij was het een bewuste keuze X.org niet in debian op te nemen voor het helemaal gemodulariseerd is, omdat er anders veel overbodig werk gebeurt.

Getuige de vele discussies hieromtrend op de x.org mailinglist, is het nog helemaal niet zeker dat X.org modular gaat worden. Er zijn nog veel voorstanders van de monolitic tree en veel verschillende meningen over een een modular x.org. En als het modular gaat worden, zal dat zoveel werk gaan kosten, dat met het aantal developers nu, het nog wel een tijdje zal duren voordat de modular-release het daglicht ziet. Misschien praten we dan over R6.9 of wellicht zelfs R7. R7 zal immers ingrijpende veranderingen ondergaan en een modular tree past daarom in dat rijtje thuis.

Of dat dus de exacte reden is waarom debian nog niet is overgestapt op X.Org betwijfel ik dus. Ik ga nog steeds mee met de theorie van beelzebubu.

[Erhnam]

mOrPhie schreef op donderdag 27 januari 2005 @ 00:58:
[...]


Getuige de vele discussies hieromtrend op de x.org mailinglist, is het nog helemaal niet zeker dat X.org modular gaat worden. Er zijn nog veel voorstanders van de monolitic tree en veel verschillende meningen over een een modular x.org. En als het modular gaat worden, zal dat zoveel werk gaan kosten, dat met het aantal developers nu, het nog wel een tijdje zal duren voordat de modular-release het daglicht ziet. Misschien praten we dan over R6.9 of wellicht zelfs R7. R7 zal immers ingrijpende veranderingen ondergaan en een modular tree past daarom in dat rijtje thuis.

Of dat dus de exacte reden is waarom debian nog niet is overgestapt op X.Org betwijfel ik dus. Ik ga nog steeds mee met de theorie van beelzebubu.

De reden waarom Dabian nog niet is overgegaan is omdat er nog te veel veranderingen en wijzigingen plaatsvinden op de x.org tree, met gevolg dat er nog te veel issues en bugs in de tree zitten... (zie de blogs/planet) Dabian vernieuwt onderdelen pas als gebleken is dat ze echt stabiel zijn. Ik verwacht dat ze niet tijden lang kunnen achterblijven (omdat andere onderdelen gnome/kde wel vooruit gaan) en op een bepaald moment moeten ze wel een versie uit de tree accepten. Deze zouden ze dan eventueel zelf kunnen verbeteren met patches om zo meer stabiliteit te brengen.

[Erhnam]

Alan Coopersmith: Xorg 6.8.2 release candidate 3

http://blogs.sun.com/roll...50125#xorg_6_8_2_release1

Overige newsbronnen:

http://planet.freedesktop.org/

http://www.technorati.com/tag/Xorg

[ Voor 31% gewijzigd door Erhnam op 27-01-2005 10:56 ]

[DeMoN]

Anoniem: 27915 schreef op donderdag 27 januari 2005 @ 00:15:
Wat een gelul. . Debian is simpelweg te traag, en da's niet voor 't eerst...

Beetje offtopic, maar waarom zou Debian nou weer te traag zijn?
Omdat alles binary is?

[ Voor 7% gewijzigd door DeMoN op 27-01-2005 13:18 ]

[Erhnam]

DeMoN schreef op donderdag 27 januari 2005 @ 13:17:
[...]
Beetje offtopic, maar waarom zou Debian nou weer te traag zijn?
Omdat alles binary is?

Trager != snelheid.

Dabian is wat 'trager' op het gebied van vernieuwing. Ze geven de voorkeur aan stabiliteit boven vernieuwing. Om die reden nemen ze niet het nieuwste van het nieuwste op in hun tree's en zijn dus wat trager met het oppakken van de laatste releases.

[DeMoN]

Erhnam schreef op donderdag 27 januari 2005 @ 13:26:
[...]


Trager != snelheid.

Dabian is wat 'trager' op het gebied van vernieuwing. Ze geven de voorkeur aan stabiliteit boven vernieuwing. Om die reden nemen ze niet het nieuwste van het nieuwste op in hun tree's en zijn dus wat trager met het oppakken van de laatste releases.

omg, ja dat weet ik.. verkeerd opgevat en dat zelfs na het hele topic gelezen te hebben.

* DeMoN gaat koffie halen

[Anoniem: 27915]

Erhnam schreef op donderdag 27 januari 2005 @ 09:28:
De reden waarom Dabian nog niet is overgegaan is omdat er nog te veel veranderingen en wijzigingen plaatsvinden op de x.org tree, met gevolg dat er nog te veel issues en bugs in de tree zitten... (zie de blogs/planet) Dabian vernieuwt onderdelen pas als gebleken is dat ze echt stabiel zijn. Ik verwacht dat ze niet tijden lang kunnen achterblijven (omdat andere onderdelen gnome/kde wel vooruit gaan) en op een bepaald moment moeten ze wel een versie uit de tree accepten. Deze zouden ze dan eventueel zelf kunnen verbeteren met patches om zo meer stabiliteit te brengen.

Volgens mij haal je een aantal dingen enorm gruwelijk door elkaar. De blogs die je aanhaalt, gaan over de CVS versie van X.org, evenals de "vele veranderingen in de tree". Dat is een goed iets, dat geeft namelijk aan dat het project actief ontwikkeld wordt. En inderdaad, dan kan er veel instabiliteit inkruipen. Daarom zul je weinig gekken vinden die CVS draaien.

Daarom heeft men het fantastische moderne concept van releases uitgevonden. Zo is er bijvoorbeeld een X.org release gedaan, welke keurig goed werkt op bijvoorbeeld Fedora. Die release zou evenzogoed in Debian kunnen. Echter, Debian wil graag compatibiliteit behouden (legacy) met XFree86, en wil daarom graag met een generiek provides-systeem gaan werken. Dit betekent feitelijk dat je XFree86 en X.org beiden kan draaien en dat een van beiden genoeg is om als depends: voor enig ander pakket te dienen zonder intern te conflicteren. Dat blijkt echter niet zo makkelijk. Fedora is simpelweg overgestapt (de simpele approach).

Dat Debian moeilijk doet is begrijpelijk, ze supporten een enorme tyfuszooi aan vage obscure hardware, maar consequentie blijft staan: ze zijn traag. .

[Erhnam]

Hier weer een kleine update:

XGL: Draai X met een opengl backend:

http://lists.freedesktop....2004-November/004358.html

http://nat.org/2005/february/

source:

http://cvs.freedesktop.org/xserver/xserver/hw/xgl/

Goede blogs:
http://www.technorati.com/tag/Xorg
http://blog.drinsama.de/erich/en/linux
http://planet.freedesktop.org/

[ Voor 21% gewijzigd door Erhnam op 10-02-2005 09:34 ]

[mOrPhie]

Xgl is alweer een paar maanden geleden hoor.

Overigens is Xgl verre van ideaal. De complete output wordt naar een fullscreen glx-window gegooit. Dit is te verhelpen natuurlijk, maar heeft als nadeel dat hij een eigen custom windowmanager heeft moeten hacken.

Ik heb het toentertijd ook geprobeerd te builden, maar heb het na 3 avonden klooien opgegeven.

[_JGC_]

Anoniem: 27915 schreef op donderdag 27 januari 2005 @ 16:12:
[...]


Volgens mij haal je een aantal dingen enorm gruwelijk door elkaar. De blogs die je aanhaalt, gaan over de CVS versie van X.org, evenals de "vele veranderingen in de tree". Dat is een goed iets, dat geeft namelijk aan dat het project actief ontwikkeld wordt. En inderdaad, dan kan er veel instabiliteit inkruipen. Daarom zul je weinig gekken vinden die CVS draaien.

Daarom heeft men het fantastische moderne concept van releases uitgevonden. Zo is er bijvoorbeeld een X.org release gedaan, welke keurig goed werkt op bijvoorbeeld Fedora. Die release zou evenzogoed in Debian kunnen. Echter, Debian wil graag compatibiliteit behouden (legacy) met XFree86, en wil daarom graag met een generiek provides-systeem gaan werken. Dit betekent feitelijk dat je XFree86 en X.org beiden kan draaien en dat een van beiden genoeg is om als depends: voor enig ander pakket te dienen zonder intern te conflicteren. Dat blijkt echter niet zo makkelijk. Fedora is simpelweg overgestapt (de simpele approach).

Dat Debian moeilijk doet is begrijpelijk, ze supporten een enorme tyfuszooi aan vage obscure hardware, maar consequentie blijft staan: ze zijn traag. .

Mja, is Xorg net zo portable naar alle architecturen waar debian op verkrijgbaar is als de huidige XFree86 4.3.0 dat is op dit moment?

Wat betreft het provides systeem: ik zie problemen bij debian als ze xorg en xfree86 tegelijk gaan supporten: Xorg heeft een paar nieuwe libraries en extenties waar programma's tegen gaan linken. Deze programma's werken dan niet meer op de oude XFree86. Op Archlinux hebben we dat hacky opgelost door gewoon die libs uit Xorg te lichten en in de XFree86 tree te patchen en vervolgens een rebuild te doen. Alle maintainers bakken tegen Xorg, terwijl arme zieluge ATi users destijds aan XFree86 vast zaten.

[Erhnam]

x.org 6.8.2:

http://linux.slashdot.org...0/1735240&tid=104&tid=106

[Niek]

Erhnam schreef op donderdag 10 februari 2005 @ 20:50:
x.org 6.8.2:

http://linux.slashdot.org...0/1735240&tid=104&tid=106

Torrentje: klik
Changelog: http://x.org/XOrg_Press_Releases/X11R6.8.2.html

Ziet er uit dat het vooral een paar bugfixes zijn

[Erhnam]

Misschien nog wat leuks:

http://linuxreviews.org/features/3ddesktop/

3d-desktop:

http://fedoranews.org/tchung/3ddesktop/
http://desk3d.sourceforge.net/

[mOrPhie]

3Ddesktop heeft niets met X11-development te maken. Het is een desktop-switch tool, puur voor de eye-candy.

[Erhnam]

XDevConf 2005 overview:

http://primates.ximian.com/~federico/news-2004-04.html#30

[Erhnam]

http://www.freedesktop.org/Software/Xgl

Om dit aan te zetten:
http://gentoo-wiki.com/TIP_Xorg_X11_and_Transparency

Xgl ontwikkelingen!

[ Voor 40% gewijzigd door Erhnam op 01-03-2005 16:32 ]

[mOrPhie]

AllowGLXWithComposite != Xgl

Mensen moeten hun mailinglists en documentatie beter lezen.
Er was ooit een probleem met composite, dat OpenGL-applicaties composite deden crashen. Deze vrij nieuwe optie heeft dit probleem opgelost. Dit heeft echter helemaal _niets_ met Xgl te maken.

Xgl is een interpratie van X11 naar OpenGL. Hierdoor ontstaat een heavy geaccellereerde XServer die op dit moment niets meer is dan een fullscreen GLX-window in een bestaande X11-Server. Gezien de vele discussies op de mailinglists is wel te veronderstellen dat een hoop mensen interesse hebben in de techniek. Dat is waarom developers nu bezig zijn met "GL" als ware backend voor x.org te gaan implementeren. Hiervoor zal waarschijnlijk GLX ontzien worden en een apart iets bedacht worden (of al bedacht zijn?). GLX richt zich namelijk op windows binnen een X11-implementatie, terwijl het doel is de hele X-Server met opengl-technieken te renderen. De echte mogelijkheden zijn mij nog niet precies duidelijk, maar dat de mogelijkheden waarschijnlijk koel zijn voor het oog is een ding wat zeker is.

[Anoniem: 27915]

De echt interessante zaken zijn hedentendage de integratie van Cairo in de X client toolkits. Hierdoor gebruik je voor geavanceerde drawing materie (bv. curved lines, alpha, RGB scaling, ...) gebruik van je videokaart z'n hardware functies (mits ondersteund). Dit maakt bestaande zaken soms sneller, maar is vooral interessant voor nieuwe snufjes. Denk bijvoorbeeld aan het zien van een window terwijl die minimized wordt (animatie), het hebben van een directe window overview als je alt-tab doet (en instant switch als je window wisselt), en nog wat van dat soort dingen. Basically wat Apple in OS X doet. Ik verwacht dit in GNOME 2.12 of 2.14 voor 't eerste op de user desktop te zien.

[mOrPhie]

Helemaal mee eens beelzebubu. Ik heb verschillende gtkcairo-dingen gecompileerd om te testen en ik ben zeer onder de indruk. Cairo gaat zeker een belangrijke innovatie in X betekenen.

Om dat aan te vullen. Arthur, de painting-engine van Qt 4.0, zal zeer waarschijnlijk ook cairo gaan ondersteunen, naast OpenGL en Xlib.

[BoAC]

mOrPhie schreef op dinsdag 01 maart 2005 @ 21:55:
Helemaal mee eens beelzebubu. Ik heb verschillende gtkcairo-dingen gecompileerd om te testen en ik ben zeer onder de indruk. Cairo gaat zeker een belangrijke innovatie in X betekenen.

Om dat aan te vullen. Arthur, de painting-engine van Qt 4.0, zal zeer waarschijnlijk ook cairo gaan ondersteunen, naast OpenGL en Xlib.

Alleen zonder glitz is cairo 10x trager. Maar glitz is nog een library die bovenop X11 draait zoals beelzebubu al zei..

Hoewel: Cairo backends

[ Voor 5% gewijzigd door BoAC op 02-03-2005 08:04 ]

[mOrPhie]

Even een kick om te melden dat http://www.xfree86.org/ ons hetvolgende nieuws brengt:

Solid like a Rock: 4.5.0 goes Live
It is on our website and ready to download. 4.5.0 was born yesterday and the delivery I hear wa smooth. Get a copy now. It's just terrific....details to follow.

Ik houd de maillinglists van XFree86 niet bij en heb dus geen idee wat er zo "terrific" aan is. Eén ding is zeker: Ik ben best wel benieuwd naar de details.

[laurencevde]

http://www.xfree86.org/4.5.0/RELNOTES3.html

[Erhnam]

Hele zooi fancy stuff! Spinnende windows, Draaiende desktops met filmpjes spelend rechts onderin het overzicht! Dit mag je niet missen:

K00l Luminocity OpenGL Videos

http://www.gnome.org/~seth/blog/xshots





http://www.gnome.org/~set...ey-hoot/WobblyWindows.avi
http://www.gnome.org/~set...ot/WorkspaceSwitching.avi
http://www.gnome.org/~set...key-hoot/MovieOfMovie.avi
http://www.gnome.org/~set...ot/TransparentWindows.avi


http://www.gnome.org/~seth/blog/relations
http://galaxy.osnews.com/email.php?blog_id=672

[BoAC]

Erhnam schreef op donderdag 24 maart 2005 @ 09:50:
Hele zooi fancy stuff! Spinnende windows, Draaiende desktops met filmpjes spelend rechts onderin het overzicht! Dit mag je niet missen:

K00l Luminocity OpenGL Videos

http://www.gnome.org/~seth/blog/xshots

[afbeelding]

[afbeelding]

http://www.gnome.org/~set...ey-hoot/WobblyWindows.avi
http://www.gnome.org/~set...ot/WorkspaceSwitching.avi
http://www.gnome.org/~set...key-hoot/MovieOfMovie.avi
http://www.gnome.org/~set...ot/TransparentWindows.avi


http://www.gnome.org/~seth/blog/relations
http://galaxy.osnews.com/email.php?blog_id=672

Heb ik vandaag ook toevallig gezien via gnomedesktop
Ik denk dat deze fancy 'toys' niet geschikt zijn voor de gewone desktop omdat het vermoeiend is, maar voor presentatie-doeleinden zeker interessant