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

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

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:

quote:

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 ?

Cybarite wijzigde dit bericht 29-02-2004 22:10 (46%)
Reden: update

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

quote:

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

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

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

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?

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

Ohw iemand wasmij voor

Erhnam wijzigde dit bericht 01-03-2004 13:18 (18%)

quote:

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

quote:

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

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.

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.

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.

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:

quote:

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

quote:

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.

quote:

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.

quote:

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.

quote:

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 .

quote:

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.

Cybarite wijzigde dit bericht 02-03-2004 14:59 (2%)
Reden: [b]-tags

quote:

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 ?

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.

Cybarite wijzigde dit bericht 02-03-2004 14:55 (2%)
Reden: typo

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!

Beelzebubu wijzigde dit bericht 02-03-2004 18:34 (53%)

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

Cybarite wijzigde dit bericht 02-03-2004 19:04 (14%)

quote:

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

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]

quote:

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!

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?


code:

X -- :1.0

Ooit geprobeerd? .

quote:

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

quote:

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.

quote:

Beelzebubu 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?

quote:

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

quote:

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.

quote:

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:

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

quote:

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:

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

quote:

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.

quote:

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 ?

quote:

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

quote:

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

quote:

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.

Cybarite wijzigde dit bericht 02-03-2004 20:12 (2%)
Reden: typo's

quote:

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

quote:

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.

quote:

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

quote:

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

quote:

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.

quote:

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.

Cybarite wijzigde dit bericht 03-03-2004 17:39 (3%)