Gaat linux ooit sneller grafisch werk doen?

[MadEgg]

Op zaterdag 01 juni 2002 00:30 schreef areana het volgende:

[..]

hehe... ik vond m eigenlijk wel goed...

Wat stond er wat stond er???

[Anoniem: 53837]

Op zaterdag 01 juni 2002 01:01 schreef MadEgg het volgende:

[..]

Wat stond er wat stond er???

stiena heeft het niet voor niets weggehaald natuurlijk... wie ben ik dan om zijn post opnieuw (samengevat waarschijnlijk) te plaatsen? nee dus...

[deadinspace]

Op zaterdag 01 juni 2002 00:12 schreef stiena het volgende:
edit

lama, gefrustreerd moment

Ja nee! Nu ben ik nieuwsgierig!

[stiena]

het komt op wat gal spuwerij op windows _{en voornamelijk novah} neer

[MadEgg]

Op zaterdag 01 juni 2002 01:04 schreef areana het volgende:

[..]

stiena heeft het niet voor niets weggehaald natuurlijk... wie ben ik dan om zijn post opnieuw (samengevat waarschijnlijk) te plaatsen? nee dus...

Wel wel wel Ik wil het weten

[Anoniem: 6714]

Afgezien van de opzet van X, en allerlei andere zaken die X dan traag moeten maken, is het niet zo dat onder linux (en de BSD varianten) de load-verdeling per proces veel evenwichtiger is? Als je bij windows-hangers ziet hoe `responsief' de GUI soms is ten opzichte van X, dan krijg je het idee dat veel processortijd al dan niet daar nodig toegekend wordt aan de GUI, terwijl applicaties er onder gaan lijden. Ik merk onder linux bijvoorbeeld geen grote performeranceverschillen met bv/ consoleapplicaties of semi-realtime applicaties (zoals mp3 players of timing programmatjes zoals mijn eigengemaakte MIDI-sequencer in pre-pre-pre-pre alpha state) terwijl het performeranceverlies op de desktop juist wel merkbaar is: en da's maar goed ook! Een mooi voorbeeld: bij mij kraakte het MP3 geluid onder windows (XP; met alle drivers van toendertijd geinstalleerd) als ik bv. zo'n dom scrollmenutje omlaag haal met animatie, terwijl zoiets nooit voorkomt onder mijn linux (LFS). Een ander voorbeeld: trage KDE in een linux-distro zoals Redhat of Mandrake met een berg deamons en andere zooi waarvan je nog niet eens weet dat het bestaat (als je nooit van top gehoord hebt heet dat). Tuurlijk, geef mijn computer maar de schuld maar ik vindt dat zoiets toch niet moet kunnen. Wat moet dat geven als je CD's brandt?

Snelheid is maar relatief, in dit geval. Zou je X "sneller" willen hebben, vraag je je dan af?

[Anoniem: 53837]

Op zaterdag 01 juni 2002 13:07 schreef MadEgg het volgende:

[..]

Wel wel wel Ik wil het weten

mmm... hij heeft zelf al een beetje verklapt (laten we het erop houden dat het grotendeels een flame was richting Novah en ook een beetje richting windows )

[RG]

Op zaterdag 01 juni 2002 13:12 schreef chromisX het volgende:
Afgezien van de opzet van X, en allerlei andere zaken die X dan traag moeten maken, is het niet zo dat onder linux (en de BSD varianten) de load-verdeling per proces veel evenwichtiger is? Als je bij windows-hangers ziet hoe `responsief' de GUI soms is ten opzichte van X, dan krijg je het idee dat veel processortijd al dan niet daar nodig toegekend wordt aan de GUI, terwijl applicaties er onder gaan lijden. Ik merk bijvoorbeeld geen grote performeranceverschillen met bv/ consoleapplicaties of semi-realtime applicaties (zoals mp3 players of timing programmatjes zoals mijn eigengemaakte MIDI-sequencer in pre-pre-pre-pre alpha state) terwijl het performeranceverlies op de desktop juist wel merkbaar is: en da's maar goed ook! Een mooi voorbeeld: bij mij kraakte het MP3 geluid onder windows (XP; met alle drivers van toendertijd geinstalleerd) als ik bv. zo'n dom scrollmenutje omlaag haal met animatie, terwijl zoiets nooit voorkomt onder mijn linux (LFS). Een ander voorbeeld: trage KDE in een linux-distro zoals Redhat of Mandrake met een berg deamons en andere zooi waarvan je nog niet eens weet dat het bestaat (als je nooit van top gehoord hebt heet dat). Tuurlijk, geef mijn computer maar de schuld maar ik vindt zoiets toch niet moet kunnen. Wat moet dat geven als je CD's brandt?

Snelheid is maar relatief, in dit geval. Zou je X "sneller" willen hebben, vraag je je dan af?

Dat Linux daar beter in is komt gewoon omdat die scheduler veel beter in elkaar steekt. Zeker nu met die volledige pre-emtive kernel. Dat Mp3's haperen mag gewoon nooit gebeuren, maar ik heb daar in Linux ook wel eens last van gehad hoor (mp3blaster terwijl je aan het compileren bent). Dat ligt volgens mij ook aan de buffer die een applicatie bijhoudt.

Maar feit is gewoon dat XFree gewoon wat response betreft vrij traag is. Ter illustratie moet je eens met de muiscursor op de rand van het venster gaan staan zodat je het kunt vergroten. Dan moet je eens klikken en tegelijkertijd je muis een zwieper geven. In XFree heb ik 9 van de 10 keer dat de klik pas wordt opgemerkt als ik al lang weg ben met mijn cursor en dus ergens anders klik.
Voor de rest is XFree gewoon traag in het tekenen en beheren van 2D objecten (ik geloof dat het updaten van 1 vierkant 20 calls kost). Daarnaast wordt er maar weinig gedaan aan goede hardware acceleratie, er wordt erg veel softwarematig gedaan. Ik weet zeker dat een GUI voor Linux niet onder hoeft te doen voor die van Windows, maar het is vooral XFree dat het sloom maakt...

[deadinspace]

Op zaterdag 01 juni 2002 13:12 schreef chromisX het volgende:
Afgezien van de opzet van X, en allerlei andere zaken die X dan traag moeten maken, is het niet zo dat onder linux (en de BSD varianten) de load-verdeling per proces veel evenwichtiger is? Als je bij windows-hangers ziet hoe `responsief' de GUI soms is ten opzichte van X, dan krijg je het idee dat veel processortijd al dan niet daar nodig toegekend wordt aan de GUI, terwijl applicaties er onder gaan lijden.

De GUI, dat wil zeggen: het grafische subsysteem, zit in Windows bij mijn weten in de kernel. Dat houdt in dat het in principe erg direct aan interrupts e.d. gekoppeld zou kunnen worden, zonder dat andere processes daarbij 'in de weg lopen'.

In GNU/Linux heb je dus XFree86, een userspace process; daar zit een van de redenen dat een aantal mensen 'X traag aan vinden voelen', en dat is in sommige gevallen inderdaad ook merkbaar, omdat XFree86 een process is als alle andere en dus soms op zijn beurt moet wachten.
Maar XFree86 draait (in de meeste distro's standaard) wel met een nice value van -10, wat inhoudt dat het een hogere prioriteit krijgt van de scheduler (of feitelijk: langere timeslices krijgt van de scheduler).

Ik merk onder linux bijvoorbeeld geen grote performeranceverschillen met bv/ consoleapplicaties of semi-realtime applicaties (zoals mp3 players of timing programmatjes zoals mijn eigengemaakte MIDI-sequencer in pre-pre-pre-pre alpha state) terwijl het performeranceverlies op de desktop juist wel merkbaar is: en da's maar goed ook! Een mooi voorbeeld: bij mij kraakte het MP3 geluid onder windows (XP; met alle drivers van toendertijd geinstalleerd) als ik bv. zo'n dom scrollmenutje omlaag haal met animatie, terwijl zoiets nooit voorkomt onder mijn linux (LFS).

Klopt, die afweging zit er inderdaad een beetje in. Ondanks dat vind ik XFree86 op mijn Pentium II 448 MHz zo traag nog niet. Alleen als je heel snel Windows moved over andere heen of heel snel resized (waar RG© het over heeft) dan merk ik dat ja. Maar dan had Windows bij mij ook moeite met het redrawen.

Het mooiste zou natuurlijk zijn een GUI die snel is en niet hapert, en dat andere progs daar toch geen last van hebben.
DirectFB is een interessante project met indrukwekkende raw speeds, maar DirectFB levert een hoop praktische problemen op, en biedt niet de flexibiliteit die je met X / X servers hebt.

Qua praktische problemen bedoel ik onder andere dat het besturen van de videokaart specifieke acceleratie vanuit de DirectFB libs gebeurt, wat inhoudt dat je als app zelf die acceleratie ook zou kunnen doen. En fout zou kunnen doen, met als gevolg dat je bijvoorbeeld je videokaart over de zeik helpt (als in: je krijgt geen beeld meer tot een reboot), of zelfs je hele computer crasht.

Dit is met XFree86 niet mogelijk (althans niet de bedoeling), omdat XFree86 een priviliged process is (het draait als root) dat de hardware access doet. Gewone apps zeggen tegen XFree86 wat het moet doen, en XFree86 regelt dat.

Qua flexibiliteit bedoel ik voornamelijk dat je meerdere X servers kunt draaien, en dat alles netwerk-transparant is.

Een ander voorbeeld: trage KDE in een linux-distro zoals Redhat of Mandrake met een berg deamons en andere zooi waarvan je nog niet eens weet dat het bestaat (als je nooit van top gehoord hebt heet dat). Tuurlijk, geef mijn computer maar de schuld maar ik vindt dat zoiets toch niet moet kunnen.

Jep, dat is inderdaad een groot punt.
Vandaar dat bijvoorbeeld Debian, Slackware, Gentoo en LFS als sneller worden ervaren dan Red hat, SuSE en Mandrake.

Wat moet dat geven als je CD's brandt?

Mja, dat gaat waarschijnlijk gewoon goed... Die berg daemons enzo maken het vooral zwaar qua RAM usage.

[Anoniem: 6714]

RG:

Voor de rest is XFree gewoon traag in het tekenen en beheren van 2D objecten (ik geloof dat het updaten van 1 vierkant 20 calls kost). Daarnaast wordt er maar weinig gedaan aan goede hardware acceleratie, er wordt erg veel softwarematig gedaan. Ik weet zeker dat een GUI voor Linux niet onder hoeft te doen voor die van Windows, maar het is vooral XFree dat het sloom maakt...

Ja, inderdaad ook waar. maarja, die netwerktransparantie; hetgene dat medeverantwoordelijk is voor die aantal calls, is natuurlijk wel handig. Kiezen of delen. Afgezien daarvan heeft windows denk ik ook wel zijn eigen organisatie of aansturing die trager zal zijn dan een direkte toegang tot het videogeheugen ofzo, maar ik heb zo'n gevoel dat windows-applicaties meer controle hebben over de computer in het algemeen dan een linux-applicatie. (soms had je wel eens applicaties die je hele gui letterlijk verklootten) Daarom is win98 ook zo vreselijk onstabiel.

Linux biedt wel diverse dingen zoals directFB, SDL (redelijk snel vindt ik) of een soort dvips-iets (dacht ik), maar er moet eens een eenduidig iets komen dat standaard in xfree wordt opgenomen (in x 5.0 ofzo, wie weet) of iets wat xfree vervangt waarmee elke applicatie of dekstopsysteem (gnome, etc) gemakkelijk mee kan linken. Afgezien van desktop performerance, zou standaard videoperformerance wel gegarandeerd zijn denk ik. (als dat nu al niet zo is bij sommige hardware; fullscreen software DVD of divx kijken op 1600x1200 gaat vele malen beter in linux als onder windows op mijn systeem!) Ik ben benieuwd met wat voor grafisch systeem we over 5 jaar werken, trouwens.

Over of hardware acceleratie goed benut wordt.. geen idee, maar zou het niet mooi zijn als de grote videokaartfabrikanten zich zouden aansluiten bij het X-consortium of iets dergelijks? (als dat al kan heet dat) Afgezien van de 'drivers-moeten-open-source-discussie', krijgen op deze manier hardwarefabrikanten een soort grip op de interne structuur van X, dat mischien wel de performerance ten goede komt. Stel dat je bij elke videokaart ook een primitive snelle, "netwerk"'interface' zou hebben dat als X-server dient ofzo (naast de huidige interface uiteraard, want die wordt gebruikt voor een direkte toegang d.m.v. een speciale driver) Dit kan uiteraard alleen als er reden toe is, dus als er genoeg potentiele gebruikers voor zijn.

deadinspace:
(Wat moet dat geven als je CD's brandt?) Mja, dat gaat waarschijnlijk gewoon goed... Die berg daemons enzo maken het vooral zwaar qua RAM usage.

Eigenlijk doelde ik daarmee op windows, ipv linux Ik heb nooit problemen gehad met CD's branden onder linux, vergeleken met Windows. Er zijn bij mij in het verre verleden onder windows wel eens CD's mislukt omdat een (simpele) screensaver begon te draaien. Onder linux kan ik gewoon doorwerken, zelfs Quake doen, en de CD wordt gewoon netjes afgemaakt.

[2P]

Ik las net op slashdot een artikel over Review of Linux Gaming Using WineX 2.0.

Het artikel is een link naar Tom's hardware guide. Ze hebben daar wat benchmarks gedaan met Quake 3 onder Linux en Windows en natuurlijk benchmarks onder WineX en Windows.

Je ziet bij de resultaten dat Quake 3 (zonder WineX) sneller draait dan onder Windows. Maar bij het gebruik van WineX is er wel een duidelijk verschil te zien in dat WineX erg traag is. Maar dat was wel te verwachten.

Verder vind ik dat het grafische werk onder Linux wel steeds beter wordt. Quake 3 speel ik onder Linux minstens even snel als onder Windows. Counter-Strike moet ik met WineX draaien en daar is mijn PC helaas wat te traag voor. Dus dat is ook nog de enigste reden waarom ik soms nog Windows draai.

[RG]

Op zaterdag 01 juni 2002 14:27 schreef deadinspace het volgende:
Qua praktische problemen bedoel ik onder andere dat het besturen van de videokaart specifieke acceleratie vanuit de DirectFB libs gebeurt, wat inhoudt dat je als app zelf die acceleratie ook zou kunnen doen. En fout zou kunnen doen, met als gevolg dat je bijvoorbeeld je videokaart over de zeik helpt (als in: je krijgt geen beeld meer tot een reboot), of zelfs je hele computer crasht.

Dit is met XFree86 niet mogelijk (althans niet de bedoeling), omdat XFree86 een priviliged process is (het draait als root) dat de hardware access doet. Gewone apps zeggen tegen XFree86 wat het moet doen, en XFree86 regelt dat.

Ja en dat is nou juist wat het slechte is aan XFree. Met een kunstgreep toch hardware access doen vanuit userspace. IMHO slaat dat helemaal 3 keer nergens op. Dat DirectFB vanwege zijn opzet sneller crash is ook niet waar. DirectFB biedt gewoon een API waarvan alles door videokaart drivers geaccelereerd kan worden, anders zijn er software fallbacks. Bij XFree is dit in feite niet anders. Zowel XFree als DirectFB kunnen crashen omdat de videokaart drivers de mist in gaan en meestal gaat dan het hele systeem op zijn kanis. Heb ik vaak genoeg gehad metr brakke NVidia chauffeurs.
Omdat er voor NVidia geen acceleratiedrivers zijn heb ik DirectFB in softwaremode gedraaid in standaard VGA. Ding was vrij onstabiel, maar het systeem bleef perfect stabiel, kon die handel gewoon killen.

[deadinspace]

Op zaterdag 01 juni 2002 20:01 schreef RG© het volgende:
Ja en dat is nou juist wat het slechte is aan XFree. Met een kunstgreep toch hardware access doen vanuit userspace. IMHO slaat dat helemaal 3 keer nergens op.

Mja, als ik zie hoe 'geweldig' sommige XFree drivers zijn... Die zooi zou ik niet in de kernel willen hebben.

Dat DirectFB vanwege zijn opzet sneller crash is ook niet waar. DirectFB biedt gewoon een API waarvan alles door videokaart drivers geaccelereerd kan worden, anders zijn er software fallbacks.

Maar het punt is dat die libs full read-write access op je framebuffer device nodig hebben, en dat je apps dat dus automatisch ook hebben. En het probleem daarmee is dat je daarmee i/o poorten van de videokaart in je framebuffer memory kunt mappen, en zo de videokaart naar je pijpen laten dansen. Dus een enkele kwaadwillige app zou zo vrij makkelijk je hele systeem kunnen ophangen.

Bij XFree is dit in feite niet anders.

Dus wel, omdat XFree86 de hardware control doet... Gewone programma's mogen niet zo direct bij de hardware komen, wat met DirectFB wel mogelijk is.

Zowel XFree als DirectFB kunnen crashen omdat de videokaart drivers de mist in gaan en meestal gaat dan het hele systeem op zijn kanis. Heb ik vaak genoeg gehad metr brakke NVidia chauffeurs.

Mja, hier zijn verreweg de meeste X crashes geen complete systeem crashes hoor (is me pas één keer gebeurd dat mijn hele systeem plat ging daardoor).

[RG]

Op zaterdag 01 juni 2002 15:39 schreef chromisX het volgende:
Ja, inderdaad ook waar. maarja, die netwerktransparantie; hetgene dat medeverantwoordelijk is voor die aantal calls, is natuurlijk wel handig. Kiezen of delen.

IMHO sluiten ze elkaar niet uit. Een netwerktransparant systeem maken dat ook nog eens heel snel is, is best mogelijk volgens mij.

Op zaterdag 01 juni 2002 15:39 schreef chromisX het volgende:
Afgezien daarvan heeft windows denk ik ook wel zijn eigen organisatie of aansturing die trager zal zijn dan een direkte toegang tot het videogeheugen ofzo, maar ik heb zo'n gevoel dat windows-applicaties meer controle hebben over de computer in het algemeen dan een linux-applicatie. (soms had je wel eens applicaties die je hele gui letterlijk verklootten) Daarom is win98 ook zo vreselijk onstabiel.

Windows9x heeft een halfbakke co-operative soort multitasking, waarbij 1 programma de hele GUI bezet kan houden. KaZaA is daar bijvoorbeeld heel goed in. Die zet het systeem voor een aantal seconden gewoon compleet stil.

Op zaterdag 01 juni 2002 15:39 schreef chromisX het volgende:
Linux biedt wel diverse dingen zoals directFB, SDL (redelijk snel vindt ik) of een soort dvips-iets (dacht ik), maar er moet eens een eenduidig iets komen dat standaard in xfree wordt opgenomen (in x 5.0 ofzo, wie weet) of iets wat xfree vervangt waarmee elke applicatie of dekstopsysteem (gnome, etc) gemakkelijk mee kan linken. Afgezien van desktop performerance, zou standaard videoperformerance wel gegarandeerd zijn denk ik. (als dat nu al niet zo is bij sommige hardware; fullscreen software DVD of divx kijken op 1600x1200 gaat vele malen beter in linux als onder windows op mijn systeem!) Ik ben benieuwd met wat voor grafisch systeem we over 5 jaar werken, trouwens.

Jij vind SDL snel. Dat systeem werkt of op X of werkt via een simpele SVGA of VESA driver. Dat is dus best grappig. Goede software rendering, zoals die van SDL of de DirectFB MMX renderer, zijn veel sneller dan X, terwijl die wel aan hardwarematige acceleratie doet. X verbeteren zou op zich wel kunnen, maar er moet veel emer gebeuren... Misschien wel een compleet nieuw systeem...

Op zaterdag 01 juni 2002 15:39 schreef chromisX het volgende:
Over of hardware acceleratie goed benut wordt.. geen idee, maar zou het niet mooi zijn als de grote videokaartfabrikanten zich zouden aansluiten bij het X-consortium of iets dergelijks? (als dat al kan heet dat) Afgezien van de 'drivers-moeten-open-source-discussie', krijgen op deze manier hardwarefabrikanten een soort grip op de interne structuur van X, dat mischien wel de performerance ten goede komt. Stel dat je bij elke videokaart ook een primitive snelle, "netwerk"'interface' zou hebben dat als X-server dient ofzo (naast de huidige interface uiteraard, want die wordt gebruikt voor een direkte toegang d.m.v. een speciale driver) Dit kan uiteraard alleen als er reden toe is, dus als er genoeg potentiele gebruikers voor zijn.

Beetje raar verhaal. Maar videokaartfabrikanten in het X comnsortium lijkt me een zeer slecht idee. Dan krijgen we elk half jaar een nieuwe versie. Het X Consortium is ook niet interessant aangezien die alleen maar het protocol bepalen. Die hebben niks te maken met de implementatie daarvan in XFree.

Op zaterdag 01 juni 2002 15:39 schreef chromisX het volgende:
Eigenlijk doelde ik daarmee op windows, ipv linux Ik heb nooit problemen gehad met CD's branden onder linux, vergeleken met Windows. Er zijn bij mij in het verre verleden onder windows wel eens CD's mislukt omdat een (simpele) screensaver begon te draaien. Onder linux kan ik gewoon doorwerken, zelfs Quake doen, en de CD wordt gewoon netjes afgemaakt.

Klopt, al denk ik dat dat onder Windows2000 en XP ook wel redelijk kan. Dat is gewoon een kwestie van een goede scheduler en die heeft Linux wel. Windows9x dus duidelijk niet! Maar cd's branden gaat buiten deze discussie om aangezien dat niks met X te maken heeft. Ik zeg altijd maar zo: alles dat niks of weinig met X te maken heeft in Linux, gaat bere snel!

[ACM]

Op zaterdag 01 juni 2002 20:18 schreef RG© het volgende:
IMHO sluiten ze elkaar niet uit. Een netwerktransparant systeem maken dat ook nog eens heel snel is, is best mogelijk volgens mij.

Maar nooit zo snel als een in de 'kernel' geintegreerd systeem zoals bij windows...

Je hebt gewoon een heel stuk meer overhead, al is het alleen maar omdat tcp/ip niet zo heel erg geschikt is voor hoge snelheden en veel data.

[deadinspace]

Op zaterdag 01 juni 2002 20:27 schreef ACM het volgende:
Maar nooit zo snel als een in de 'kernel' geintegreerd systeem zoals bij windows...

Je hebt gewoon een heel stuk meer overhead, al is het alleen maar omdat tcp/ip niet zo heel erg geschikt is voor hoge snelheden en veel data.

Wat RG© bedoelt is een systeem dat, wanneer lokaal gebruikt, snel is, en bovendien netjes en flexibel netwerktransparant is.
Snel wanneer het over het netwerk wordt gebruikt is natuurlijk ook een pre, maar minder haalbaar (ivm bandbreedte-bottleneck en gebrek aan dingen als directe geheugen toegang).

En als je dat systeem fatsoenlijk ontwerpt, dan zou het lokaal best sneller kunnen zijn dan Windows (qua grafisch systeem).

En TCP/IP doet er niet toe zolang het om het lokaal draaien gaat. De snelheid als je het over het netwerk gebruikt is op dit moment van de discussie imho niet zo belangrijk.

En los daarvan, waarom zou TCP/IP ongeschikt zijn voor hoge snelheiden en veel data?

[Anoniem: 27915]

Op zaterdag 01 juni 2002 20:27 schreef ACM het volgende:
Maar nooit zo snel als een in de 'kernel' geintegreerd systeem zoals bij windows...

We moeten niet vergeten dat XFree86 een high priority proces is (dat kan als je als root draait) - Dus zoveel verschil tussen in kernelspace of userspace draaien qua performance is er niet eens, behalve in de gevallen waar de CPU druk bezig is. Maargoed, of de GUI nou snel of sloom is, het is uiteindelijk de applicatie die dan snel moet reageren, dus dan maatk het in kernelspace of userspace draaien toch niet uit voor de praktijk.

Alleen het redrawen kan eerder gebeuren (daardoor lijken windows apps soms wat meer responsive), maar uiteindelijk maakt het niks uit.

Je hebt gewoon een heel stuk meer overhead, al is het alleen maar omdat tcp/ip niet zo heel erg geschikt is voor hoge snelheden en veel data.

Erm, da's als je over een netwerk gaat. Op je locale computer gaat alles gewoon via shared memory of (beter nog) DGA/DRI. Dat scheelt een boel.

[ACM]

Op zaterdag 01 juni 2002 20:42 schreef deadinspace het volgende:
En TCP/IP doet er niet toe zolang het om het lokaal draaien gaat. De snelheid als je het over het netwerk gebruikt is op dit moment van de discussie imho niet zo belangrijk.

Dat doet er _juist_ toe
Er worden dingen de tcp-stack opgegooid en er weer afgehaald, compleet nutteloze stap, performance technisch dus absoluut niet te prefereren...
Als je die tcp/ip stack overslaat gaat het toch echt wel vlotter, vergeet niet dat bij de local interface ook alle (dan irrelevante) errorchecks etc ook uitgevoerd worden.
Splitsing van packets in kleine fragments (met lo niet zo heel klein, maar wel kleiner dan evt een struct dat nodig is voor de beelddata).

Dat zijn allemaal extra software lagen die niet nodig zijn (tenminste, windows draait redelijk stabiel zonder die extra lagen )

En los daarvan, waarom zou TCP/IP ongeschikt zijn voor hoge snelheiden en veel data?

Bekijk de highperformance protocollen maar eens, vereisten zijn eigenlijk het niet verplicht wachten tot het packet aangekomen is (ok gebeurt niet zo expliciet), de packetgrootte op het internet is veels te klein van tcp/ip (zelfs de 64KB die er max mogelijk is is nog te klein voor echte hoge snelheden) etc.
Betrekkelijk grote overhead, noem maar op.

ipv6 is al een stuk beter wat dat betreft gelukkig

Op zaterdag 01 juni 2002 21:37 schreef beelzebubu het volgende:
We moeten niet vergeten dat XFree86 een high priority proces is (dat kan als je als root draait) - Dus zoveel verschil tussen in kernelspace of userspace draaien qua performance is er niet eens, behalve in de gevallen waar de CPU druk bezig is.

Een userspace proces moet verplicht via de kernel met de hardware praten, een kernelspace proces kan ook gelijk naar de hardware toe.
Uiteraard is de dri(-interface) daarom ook gemaakt en dat scheelt natuurlijk behoorlijk

Erm, da's als je over een netwerk gaat. Op je locale computer gaat alles gewoon via shared memory of (beter nog) DGA/DRI. Dat scheelt een boel.

Helemaal niet meer via de tcp/ip stack?
Dan is dat een argument van me dat je mag schrappen

[deadinspace]

Op zaterdag 01 juni 2002 22:36 schreef ACM het volgende:
Dat doet er _juist_ toe
Er worden dingen de tcp-stack opgegooid en er weer afgehaald, compleet nutteloze stap, performance technisch dus absoluut niet te prefereren...
Als je die tcp/ip stack overslaat gaat het toch echt wel vlotter, vergeet niet dat bij de local interface ook alle (dan irrelevante) errorchecks etc ook uitgevoerd worden.
Splitsing van packets in kleine fragments (met lo niet zo heel klein, maar wel kleiner dan evt een struct dat nodig is voor de beelddata).

Connecties tussen X apps en de X server gaan bij lokaal gebruik niet over het loopback device, maar over een Unix socket: /tmp/.X11-unix/X0.
Hence geen fragments, geen TCP/IP, geen firewall enz, enz.

Bekijk de highperformance protocollen maar eens, vereisten zijn eigenlijk het niet verplicht wachten tot het packet aangekomen is (ok gebeurt niet zo expliciet)

Mja, garantie van data consistency is toch erg prettig als je er applicaties over wilt draaien

de packetgrootte op het internet is veels te klein van tcp/ip (zelfs de 64KB die er max mogelijk is is nog te klein voor echte hoge snelheden) etc.

Mja, de grens die op Internet gehanteerd wordt (meestal 1500 bytes, soms minder) heeft niks met TCP/IP te maken, maar met de lagen daaronder (Ethernet bijvoorbeeld).

Betrekkelijk grote overhead, noem maar op.

Typisch 40 bytes (20 IP en 20 TCP) op 1500 bytes. Dat is nog geen 3%. Is dat zoveel?

ipv6 is al een stuk beter wat dat betreft gelukkig

ipv6 heeft ook 64 KB als maximum packet size, en ipv6 headers zijn twee keer zo lang als een typische IP (v4) header (40 bytes vs 20 bytes).
Stukken beter ja

Een userspace proces moet verplicht via de kernel met de hardware praten, een kernelspace proces kan ook gelijk naar de hardware toe.

Nope, een userspace process kan ook direct met de hardware praten (mits priviliged), en dat is ook precies wat XFree86 doet.

Uiteraard is de dri(-interface) daarom ook gemaakt en dat scheelt natuurlijk behoorlijk

Mja, afaik wordt DRI alleen voor 3D-renderen gebruikt.

Op zaterdag 01 juni 2002 21:37 schreef beelzebubu het volgende:
Erm, da's als je over een netwerk gaat. Op je locale computer gaat alles gewoon via shared memory of (beter nog) DGA/DRI. Dat scheelt een boel.

De X11 Unix socket wordt wel nog gebruikt door apps die lokaal draaien. Shared memory, DGA en DRI zijn slechts hulpmiddelen (die overigens erg veel uitmaken).

[Anoniem: 27915]

Op zaterdag 01 juni 2002 22:56 schreef deadinspace het volgende:
Typisch 40 bytes (20 IP en 20 TCP) op 1500 bytes. Dat is nog geen 3%. Is dat zoveel?

Ja. Je werkt in hoeveelheden van megabytes per seconde!

Nope, een userspace process kan ook direct met de hardware praten (mits priviliged), en dat is ook precies wat XFree86 doet.

... Nog altijd via de kernel, geloof ik...

De X11 Unix socket wordt wel nog gebruikt door apps die lokaal draaien. Shared memory, DGA en DRI zijn slechts hulpmiddelen (die overigens erg veel uitmaken).

Zie het als een pointer naar een buffer en een buffer (van enkele megabytes) zelf. De pointer wordt nog steeds gestuurd, maar dat is 4 byte (op een 32 bit machine) versus enkele megabytes over een socket. Het is dus een hulpmiddel, maar maakt de enorme overhead van de socket wel miniem tot verwaarloosbaar. .

[deadinspace]

Op zondag 02 juni 2002 00:02 schreef beelzebubu het volgende:
Ja. Je werkt in hoeveelheden van megabytes per seconde!

Dan is het nog steeds 3%.
Weet jij een beter alternatief (wat betreft netwerk protocollen dan)?

... Nog altijd via de kernel, geloof ik...

Nee. Dan zou je ook je videokaart moeten kiezen in de kernelconfig, en dat is niet het geval (afgezien van fb en DRI, maar zonder deze twee werkt X nog steeds).
XFree86 zit direct aan de hardware (op GNU/Linux in ieder geval). Dit is een van de belangrijkste redenen dat XFree86 ook altijd als root moet draaien.

Zie het als een pointer naar een buffer en een buffer (van enkele megabytes) zelf. De pointer wordt nog steeds gestuurd, maar dat is 4 byte (op een 32 bit machine) versus enkele megabytes over een socket. Het is dus een hulpmiddel, maar maakt de enorme overhead van de socket wel miniem tot verwaarloosbaar. .

Daarom zei ik ook dat die hulpmiddelen erg veel uitmaken
Ik wilde er alleen mee aangeven dat die socket niet ongebruikt blijft als je dingen als Xshm tot je beschikking hebt.

[RG]

Op zondag 02 juni 2002 00:02 schreef beelzebubu het volgende:
... Nog altijd via de kernel, geloof ik...

hehe, "geloof ik" AFAIK heeft doodinderuimte gelijk. XFree gaat inderdaad direct met de hardware klooien. Volgens mij werkt muis support namelijk ook perfect als je in de kernel alles wat met een muis te maken heeft uitzet. Daarnaast werken die videokaart chauffeurs van XFree volgens mij direct met de hardware, maar dat weet ik niet zeker hoor. NVidia doet dat geloof ik anders...

[deadinspace]

Op zondag 02 juni 2002 00:39 schreef RG© het volgende:
Volgens mij werkt muis support namelijk ook perfect als je in de kernel alles wat met een muis te maken heeft uitzet.

Hmm, volgensmij gaat muis weer wel door de kernel (/dev/psaux, /dev/ttyS0 en /dev/input worden door de kernel afgehandeld).
Het gaat volgensmij alleen om de videodrivers.

Daarnaast werken die videokaart chauffeurs van XFree volgens mij direct met de hardware, maar dat weet ik niet zeker hoor. NVidia doet dat geloof ik anders...

De nVidia drivers gaan bij mijn weten ook niet door de kernel.
DRI support gaat wel door de kernel, ook nVidia's DRI, alleen gebruikte nVidia niet Linux' eigen agpgart (/dev/agp) implementatie, maar een eigen implementatie (wrom is me nog steeds niet duidelijk).

[ACM]

Op zaterdag 01 juni 2002 22:56 schreef deadinspace het volgende:
Mja, garantie van data consistency is toch erg prettig als je er applicaties over wilt draaien

Wat heeft dat met complexiteit van headers te maken enzo?
De meeste checks kunnen er op dat niveau echt wel uit hoor.

ATM bijv, weliswaar relatief veel header per kilobyte data, maar daar wil nog wel es een packet uitvallen, zonder notificatie en zonder herzending (op dat niveau, op hoger niveau zal er uiteraard wat aan gedaan moeten worden).

Mja, de grens die op Internet gehanteerd wordt (meestal 1500 bytes, soms minder) heeft niks met TCP/IP te maken, maar met de lagen daaronder (Ethernet bijvoorbeeld).

Het gaat niet alleen om de grootte van de header, maar ook om de complexiteit van het geheel.
Het kunnen fragmenteren van packets en weer samenstellen van die fragments is een hels karwij.

De header van ipv4 is 20bytes met 13 velden, die dus in theorie allemaal gecontroleerd moeten/kunnen worden door routers.

Typisch 40 bytes (20 IP en 20 TCP) op 1500 bytes. Dat is nog geen 3%. Is dat zoveel?

Die 3% is tot daaraantoe, maar allerlei overige complexerende (is dat nederlands? ) zaken maken tcp echt niet tot een highperformance protocol.
Er zijn trouwens ook protocollen met een payload van een megabyte...
En die payload van 64KB van ipv4/6 is voor _echt_ snelle netwerken nog steeds veel te weinig.

ipv6 heeft ook 64 KB als maximum packet size, en ipv6 headers zijn twee keer zo lang als een typische IP (v4) header (40 bytes vs 20 bytes).
Stukken beter ja

Een ipv6 header bevat maar 7 veldjes vs 13 van ipv4, das al een ding.
Sterker nog de simplificatie is een van de grote punten van ipv6.

Maar goed, ipv6 is beter niet het best.
TCP/ip is sowieso eigenlijk maar een slecht protocol (niet dat ik weet welke nou perse beter is )

Shared memory, DGA en DRI zijn slechts hulpmiddelen (die overigens erg veel uitmaken).

Het zijn allemaal hulpmiddelen om de afstand (in cpu-cycles gemeten) tot de videokaart flink verkorten en dat is nou eenmaal hardstikke belangrijk
DGA/DRI zou eigenlijk ook gebruikt moeten worden voor 2D, maar daarvoor weet ik te weinig van video-interfaces om te weten of dat mogelijk is

Op zondag 02 juni 2002 00:38 schreef deadinspace het volgende:
Dan is het nog steeds 3%.
Weet jij een beter alternatief (wat betreft netwerk protocollen dan)?

Voor LAN's is IPX geloof ik veel beter

Nee. Dan zou je ook je videokaart moeten kiezen in de kernelconfig, en dat is niet het geval (afgezien van fb en DRI, maar zonder deze twee werkt X nog steeds).
XFree86 zit direct aan de hardware (op GNU/Linux in ieder geval). Dit is een van de belangrijkste redenen dat XFree86 ook altijd als root moet draaien.

Daar twijfel ook ik aan, volgens mij is er _altijd_ een flintertje kernel tussen de hardware en de drivers, maar het kan best zijn dat dat niet het geval is.

[deadinspace]

Op zondag 02 juni 2002 01:19 schreef ACM het volgende:
Wat heeft dat met complexiteit van headers te maken enzo?
De meeste checks kunnen er op dat niveau echt wel uit hoor.

Ja, maar ik reageerde op jouw opmerking:

Op zaterdag 01 juni 2002 22:36 schreef ACM het volgende:
Bekijk de highperformance protocollen maar eens, vereisten zijn eigenlijk het niet verplicht wachten tot het packet aangekomen is (ok gebeurt niet zo expliciet)

Ik neem zo snel aan dat je daarmee bedoelde dat TCP stacks wachten met verzenden van een packet tot de bevestiging dat het ontvangen is is aangekomen. Dat is (bij mijn allerbeste weten) niet waar.
Goede TCP implementaties ( * deadinspace pokes at win9x ) doen dat afaik initieel wel, maar als de link van goede kwaliteit blijkt (weinig tot geen loss), dan wordt steeds meer parallel gestuurd (omdat het goed lijkt te gaan). Na een tijd wordt dus echt niet meer gewacht op bevestiging (maar als een bevestiging niet komt, dan wordt het packet uiteraart herzonden).

Dit verschijnsel merk je ook in de praktijk, als je wat downloadt. De downloadsnelheid 'klimt' dan gestaag, en blijft dan na een tijd op een bepaalde snelheid hangen (in typische situaties dan).

Het gaat niet alleen om de grootte van de header, maar ook om de complexiteit van het geheel.

Ok, daar heb je inderdaad een punt waar ik nog niet bij stil had gestaan (en waar ipv6 idd een edge over ipv4 heeft).

Het kunnen fragmenteren van packets en weer samenstellen van die fragments is een hels karwij.

Tsja... Maar dat is meer te wijten aan de fysieke links. Ethernet MTU 1500, modem MTU 560 oid (whatever de reden is).
De 'fragmentability' van ipv{4,6} is slechts een methode om daarmee om te kunnen gaan.

De header van ipv4 is 20bytes met 13 velden, die dus in theorie allemaal gecontroleerd moeten/kunnen worden door routers.

Jup, en daar zijn er inderdaad een aantal overbodig van.

Er zijn trouwens ook protocollen met een payload van een megabyte...

Mja, maar voorlopig zijn de fysieke lagen nog de bottleneck... Ethernet heeft een limiet van iets van 1500 bytes per frame, om wat te noemen.
Neemt niet weg dat ze inderdaad best 24 of 32 bits hadden mogen nemen voor payload length.

Sterker nog de simplificatie is een van de grote punten van ipv6.

Dat is inderdaad zo.
Als het goed is wordt ipv6 in ieder geval een stuk lichter te routen.

TCP/ip is sowieso eigenlijk maar een slecht protocol (niet dat ik weet welke nou perse beter is )

Bedoel je dan ipv4 of ipv6?
ipv4 is zo rampzalig niet (afgezien van de header complexiteit die jij noemde, waar ipv6 idd wat beter in is). Het is tegenwoordig zwaar om te routen, maar dat komt door het tekort aan IP-adressen, waardoor ipv4 niet gebruikt kan worden zoals het bedoeld is.
Daar maakt ipv6 als het goed is een einde aan met zijn 79,228,162,514,264,337,593,543,950,336 keer zo grote address space.

Het zijn allemaal hulpmiddelen om de afstand (in cpu-cycles gemeten) tot de videokaart flink verkorten en dat is nou eenmaal hardstikke belangrijk

Klopt, daarom maakte ik ook de opmerking dat 'die hulpmiddelen erg veel uitmaken'.

DGA/DRI zou eigenlijk ook gebruikt moeten worden voor 2D, maar daarvoor weet ik te weinig van video-interfaces om te weten of dat mogelijk is

Ik weet het fijne van DRI niet, maar DGA wordt afaik ook gebruikt voor 2D. Het punt van DGA is dat het directe hardware-access biedt (Direct Graphics Access), wat r00t-priviliges nodig heeft. Kleine drawback.

Voor LAN's is IPX geloof ik veel beter

Ok, qua complexiteit weet ik vrij weinig van IPX (weinig zin me erin te verdiepen ook), maar qua procentuele header/payload overhead is het ongeveer 2 keer zo erg als TCP/IPv4 (namelijk 30 bytes headers en een maximum payload van 546 bytes). Verder vind ik IPX erg messy qua routing (en zou het dus niet graag als internet protocol zien).

Daar twijfel ook ik aan, volgens mij is er _altijd_ een flintertje kernel tussen de hardware en de drivers, maar het kan best zijn dat dat niet het geval is.

Bij mijn weten niet in het geval van XFree86. XFree86 zit gewoon bot aan het memory en de I/O ports van je videokaart.
Daar moet het overigens wel eerst toestemming van de kernel voor krijgen, dat wel, maar als het die toestemming heeft, dan kan het gewoon zijn gang gaan (zie ook man 2 ioperm en man 2 iopl).

[ACM]

Op zondag 02 juni 2002 02:31 schreef deadinspace het volgende:
Goede TCP implementaties ( * deadinspace pokes at win9x ) doen dat afaik initieel wel, maar als de link van goede kwaliteit blijkt (weinig tot geen loss), dan wordt steeds meer parallel gestuurd (omdat het goed lijkt te gaan). Na een tijd wordt dus echt niet meer gewacht op bevestiging (maar als een bevestiging niet komt, dan wordt het packet uiteraart herzonden).

Vergelijk het met atm, die doet het gewoon nooit
Geen complexiteit extra, geen gedoe. Als het niet aankomt stuurt de server het later (na een verzoekje) nog maar een keer.
[/quote]
Tsja... Maar dat is meer te wijten aan de fysieke links. Ethernet MTU 1500, modem MTU 560 oid (whatever de reden is).
De 'fragmentability' van ipv{4,6} is slechts een methode om daarmee om te kunnen gaan.
[/quote]
Dat is een voordeel van tcp boven vele andere protocollen, het is veel flexibeler. Maar helaas, elk beetje extra flexibiliteit gaat veelal ten koste van (een beetje) performance.

Mja, maar voorlopig zijn de fysieke lagen nog de bottleneck... Ethernet heeft een limiet van iets van 1500 bytes per frame, om wat te noemen.
Neemt niet weg dat ze inderdaad best 24 of 32 bits hadden mogen nemen voor payload length.

Niet alle netwerken zijn ethernet
Ergens had ik gelezen dat de GB-ethernet kaarten vaak ook al grotere payloads nemen dan 1500 bytes, dat scheelde _enorm_ op de praktijk snelheid.

Als het goed is wordt ipv6 in ieder geval een stuk lichter te routen.

Gelukkig wel

Bedoel je dan ipv4 of ipv6?

Beide, vooral ipv4

ipv4 is zo rampzalig niet (afgezien van de header complexiteit die jij noemde, waar ipv6 idd wat beter in is). Het is tegenwoordig zwaar om te routen, maar dat komt door het tekort aan IP-adressen, waardoor ipv4 niet gebruikt kan worden zoals het bedoeld is.
Daar maakt ipv6 als het goed is een einde aan met zijn 79,228,162,514,264,337,593,543,950,336 keer zo grote address space.

Nadeel is dat ipv4 met het idee gemaakt is dat 4M adressen ruim voldoende is, helaas...
En er zijn meer nadelen aan verbonden aan de leeftijd. Slecht is het niet (dat zei ik ook niet) maar het moet eigenlijk ook niet als 'universeel overal toepasbaar'-protocol gezien worden wat nu (helaas?) wel gebeurt.

Het is wel universeel en compatibel, maar als we het over high performance gaan hebben laat het steken vallen (en daar ging deze thread eigenlijk wel over )

Ik weet het fijne van DRI niet, maar DGA wordt afaik ook gebruikt voor 2D.

_{*kuch* eerst lezen ACM, dan pas dingen zeggen}

Verder vind ik IPX erg messy qua routing (en zou het dus niet graag als internet protocol zien).

Zeg maar gerust dat het _niet_ te routeren valt, ik geloof dat ipx geen notie van 'meerdere netwerken' heeft (subnets enzo) leuk voor de complexiteit van het protocol, minder leuk voor de routering

Bij mijn weten niet in het geval van XFree86. XFree86 zit gewoon bot het memory en de I/O ports van je videokaart.
Daar moet het overigens wel eerst toestemming van de kernel voor krijgen, dat wel, maar als het die toestemming heeft, dan kan het gewoon zijn gang gaan (zie ook man 2 ioperm en man 2 iopl).

Ok, duidelijk

[deadinspace]

Op zondag 02 juni 2002 02:49 schreef ACM het volgende:
Niet alle netwerken zijn ethernet

Nee, maar op de route van een packet over Internet zit er meestal wel ergens Ethernet tussen. Dat houdt in dat een 4000 bytes packet dus wordt verstuurd, ergens (meestal bij de destination) op Ethernet stuit, en wordt gefragment (of erger: gedropped).

Ergens had ik gelezen dat de GB-ethernet kaarten vaak ook al grotere payloads nemen dan 1500 bytes, dat scheelde _enorm_ op de praktijk snelheid.

Ehm ja. 'Jumbo frames' heetten die dingen iirc, en die gingen tot 64 kb. Een of andere extensie op het Ethernet protocol.

Nadeel is dat ipv4 met het idee gemaakt is dat 4M adressen ruim voldoende is, helaas...

Tsja, ipv4 wordt ook niet echt meer gebruikt voor het doel waar het voor ontworpen is: namelijk een militair netwerk waar 2^32 adressen overkill is en dus prima te verdelen naar locatie en dus makkelijk routeerbaar.
ipv6 werkt overigens met zo eenzelfde assumptie, maar dan factortje of wat hoger (ipv4^4 ).

En er zijn meer nadelen aan verbonden aan de leeftijd. Slecht is het niet (dat zei ik ook niet) maar het moet eigenlijk ook niet als 'universeel overal toepasbaar'-protocol gezien worden wat nu (helaas?) wel gebeurt.

Nouja, voor het Internet vind ik ipv4 in ieder geval vrij geschikt, en ipv6 addresseert een aantal problemen die ipv4 heeft.

Het is wel universeel en compatibel, maar als we het over high performance gaan hebben laat het steken vallen (en daar ging deze thread eigenlijk wel over )

Nouja, deze thread ging eigenlijk over GNU/Linux' (en daarmee {Net,Free,Open}BSDs en nog wel meer OSses') grafische systeem, waar dit maar een zijstraat van was.
En nog eentje die er niet toe doet, want al die routerings-protocollen worden overgeslagen als je een X app lokaal draait

Zeg maar gerust dat het _niet_ te routeren valt, ik geloof dat ipx geen notie van 'meerdere netwerken' heeft (subnets enzo) leuk voor de complexiteit van het protocol, minder leuk voor de routering

IPX kent wel meerdere netwerken, door middel van zogeheten 'network numbers' (schokkend ).
Kijk maar in /etc/ipx.conf (of ergens in windows... kweet niet waar, maar het staat iig ergens).

Dit weet ik uit ervaring omdat GNU/Linux network number 0 beschouwt als 'unroutable', terwijl network number 0 het default is in Windows

Ik weet btw nog steeds niet welke van de twee 'gelijk' heeft (kortom: of dat 0 idd unroutable is volgens de RFC/standaard/whatever of niet).

[ACM]

Op zondag 02 juni 2002 03:12 schreef deadinspace het volgende:
Ehm ja. 'Jumbo frames' heetten die dingen iirc, en die gingen tot 64 kb. Een of andere extensie op het Ethernet protocol.

Ja, dat was het

Nouja, deze thread ging eigenlijk over GNU/Linux' (en daarmee {Net,Free,Open}BSDs en nog wel meer OSses') grafische systeem, waar dit maar een zijstraat van was.
En nog eentje die er niet toe doet, want al die routerings-protocollen worden overgeslagen als je een X app lokaal draait

]
Ach, ik riep ergens dat het (zelfs lokaal) via de tcp/ip stack liep, maar dat valt dus reuze mee

IPX kent wel meerdere netwerken, door middel van zogeheten 'network numbers' (schokkend ).
Kijk maar in /etc/ipx.conf (of ergens in windows... kweet niet waar, maar het staat iig ergens).

Klopt, maar daar houdt ook gelijk alle ondersteuning voor meerdere netwerken mee op meen ik

Humm, ik meende dat dat het grote nadeel was, maar deze quotes duiden op wat anders:

In IPX, designed by Novell, the names (and corresponding addresses) of ALL services available on the network are stored in ALL Netware servers as a SAP table (SAP stands for Service Advertising Protocol.) Netware servers will share SAP information with each other automatically. Unfortunately, since ALL servers must know about ALL services, SAP tables can get very unwieldy on large networks, and without the benefit of advanced routing/advertising algorithms (NLSP), can flood networks with SAP broadcasts.

*kuch* erg vervelend met meer dan 4Miljard hosts
en

The 4-byte "IPX Address" you define is actually a 4-byte "IPX Network Address." The other 6 bytes is the hardware address of your NIC.

Is ook niet altijd even handig natuurlijk

bron: http://www.ipprimer.com/ipvipx.cfm

[RG]

Op zondag 02 juni 2002 01:12 schreef deadinspace het volgende:
Hmm, volgensmij gaat muis weer wel door de kernel (/dev/psaux, /dev/ttyS0 en /dev/input worden door de kernel afgehandeld).
Het gaat volgensmij alleen om de videodrivers.

ow ja je hebt gelijk. De kernel gaat over de fysieke connectie en XFree gaat over het protocolletje van de muis.

Op zondag 02 juni 2002 01:12 schreef deadinspace het volgende:
De nVidia drivers gaan bij mijn weten ook niet door de kernel.
DRI support gaat wel door de kernel, ook nVidia's DRI, alleen gebruikte nVidia niet Linux' eigen agpgart (/dev/agp) implementatie, maar een eigen implementatie (wrom is me nog steeds niet duidelijk).

Nouja die AGP implementatie van NVidia is wel sneller schijnt, al heb ik dat eens getest en het maakte toen geen bal uit.

[RG]

TCP/IP mag dan wel niet overal geschikt voor zijn, het zorgt er iig niet voor dat XFree sloom is met het tekenen van 2D beeld. Daar heeft TCP/IP ongeveer net zoveel invloed op als het aquarium van de buurman...

DGA en DRI zijn wel dingen die helpen om XFree lokaal te versnellen, maar zolang je eerst 20 stappen moet doorlopen om daar te komen schiet dat natuurlijk nog niet op (wel als het er anders 40 zijn natuurlijk, maar dan nog).
Windows heeft gewoon een simpele grafische API (de GDI) die volledig geaccelereerd kan worden door videodrivers. Het probleem van XFree is, is dat die grafische API veel te ingewikkeld in elkaar steekt en dat het intern ook nog eens erg veel moeite kost voordat is gedaan wat er gedaan moet worden. Ik vraag me uberhaupt af of en zo ja hoeveel XFree aan 2D acceleratie doet. Ik heb het idee dat er veel te veel softwarematig wordt opgelost en dat kost erg veel CPU tijd. Helemaal als je met Alpha layers e.d. gaat werken...

[odysseus]

Op zondag 02 juni 2002 15:33 schreef RG© het volgende:
Ik heb het idee dat er veel te veel softwarematig wordt opgelost en dat kost erg veel CPU tijd. Helemaal als je met Alpha layers e.d. gaat werken...

Natuurlijk is XFree86 niet perfect, maar over het algemeen zit het toch niet echt slecht in elkaar. Voor dingen als transparantie en alpha-layers kun je de XRender-extensie gebruiken. Voor andere 2D-versnelling is er bijvoorbeeld DGA en natuurlijk kunnen de drivers op zich ook goed bij de hardware. Hoe denkt men dat de nVidia-drivers toch snel kunnen zijn terwijl ze net zo goed met dat zogezegd 'trage' XFree86 samenwerken? Zeker sinds versie 4.x heeft XFree veel aan modulariteit gewonnen en dat merk je gewoon bij dit soort dingen. De core van XFree is misschien traag, maar waar nodig kun je bijna alles op een snellere manier met extra modules en dergelijke oplossen, denk aan GLX, DRI, DGA, XRender en nog een stel van die dingen.

[ACM]

Op zondag 02 juni 2002 15:33 schreef RG© het volgende:
TCP/IP mag dan wel niet overal geschikt voor zijn, het zorgt er iig niet voor dat XFree sloom is met het tekenen van 2D beeld. Daar heeft TCP/IP ongeveer net zoveel invloed op als het aquarium van de buurman...

als het er niet gebruikt wordt niet nee, anders wel...

Helemaal als je met Alpha layers e.d. gaat werken...

schijnt windows ook wel vrij vlot te kunnen, dus das geen argument
En schijnbaar is de ergste reden tot verdenking van overhead (die network layer en de usertime/space gedoe) 'ongegrond'.
Oftewel, al dat X gedoe moet binnenkort maar eens flink sneller

[RG]

Dat X lokaal niet via een netwerk gaat wil niet zeggen dat het intern niet sneller kan. XFree is qua 2D gewoon traag. De beeldopbouw is absoluut niet om over naar huis te schrijven.

Windows 98 SE is bijvoorbeeld qua GUI op een AMD K6 166 met 64 MB SDRam zo ongelooflijk veel sneller dan Slackware 8.0 met XFree 4.1 en KDE 2. Xfree is gewoon log, dat is het juiste woord en of dat mog ooit beter wordt? geen idee...

[GeeMoney]

Op zondag 02 juni 2002 19:02 schreef RG© het volgende:
Dat X lokaal niet via een netwerk gaat wil niet zeggen dat het intern niet sneller kan. XFree is qua 2D gewoon traag. De beeldopbouw is absoluut niet om over naar huis te schrijven.

Windows 98 SE is bijvoorbeeld qua GUI op een AMD K6 166 met 64 MB SDRam zo ongelooflijk veel sneller dan Slackware 8.0 met XFree 4.1 en KDE 2. Xfree is gewoon log, dat is het juiste woord en of dat mog ooit beter wordt? geen idee...

kde2.x is traag de Xfree op zich valt mee te werken op zon machine draai eens een snellere manager zoals WM of dergeleijke, zal net zo snel of misschien nog wel sneller werken als die win98 SE denk ik..

[ACM]

Op zondag 02 juni 2002 19:02 schreef RG© het volgende:
Dat X lokaal niet via een netwerk gaat wil niet zeggen dat het intern niet sneller kan. XFree is qua 2D gewoon traag. De beeldopbouw is absoluut niet om over naar huis te schrijven.

Dat is juist precies wat ik bedoel
Doordat X lokaal niet via het netwerk gaat en er allerlei andere trucjes uitgehaald zijn _moet_ het sneller kunnen

Windows 98 SE is bijvoorbeeld qua GUI op een AMD K6 166 met 64 MB SDRam zo ongelooflijk veel sneller dan Slackware 8.0 met XFree 4.1 en KDE 2. Xfree is gewoon log, dat is het juiste woord en of dat mog ooit beter wordt? geen idee...

Mja, maar windows 98se is natuurlijk vergeleken met kde2 wel redelijk simpel qua werking. Maar je hebt zeker wel gelijk dat XFree vrij log is en zeker de windowmanager er nog eens los bovenop.

Heel leuk en aardig al die scheiding, maar performance technisch is dat natuurlijk niet het allerbest. "gelukkig" gaat alles langzaam maar zeker weer richting 'alles via het (inter)netwerk' waardoor XFree straks een grote voorsprong kan hebben.

[deadinspace]

Op zondag 02 juni 2002 19:30 schreef ACM het volgende:
...en zeker de windowmanager er nog eens los bovenop.

Heel leuk en aardig al die scheiding, maar performance technisch is dat natuurlijk niet het allerbest.

De scheiding grafisch systeem <-> Windowmanager heeft maar erg weinig (if any) impact op de performance hoor... De Windowmanager doet toch niet veel, beetje borders tekenen, cursortje bijwerken en doorgeven aan de X server of een window verplaatst moet worden enzo...

[RG]

Op zondag 02 juni 2002 19:30 schreef ACM het volgende:
Dat is juist precies wat ik bedoel
Doordat X lokaal niet via het netwerk gaat en er allerlei andere trucjes uitgehaald zijn _moet_ het sneller kunnen

Ow het kan zeker wel sneller, maar dan moet XFree denk ik voor een groot deel herschreven worden. En als X eenmaal snel is, dan blijft de GUI nog sloom, vanwege alle verschillede libs die in feite hetzelfde doen (GTK+ vs QT vs OpenMotif bijvoorbeeld). Dus heb je X eenmaal snel dan heb je pas 1 van de 4 problemen opgelost voor Linux op de desktop.

Op zondag 02 juni 2002 19:30 schreef ACM het volgende:
Mja, maar windows 98se is natuurlijk vergeleken met kde2 wel redelijk simpel qua werking. Maar je hebt zeker wel gelijk dat XFree vrij log is en zeker de windowmanager er nog eens los bovenop.

KDE 2 vind ik niet zoveel ingewikkelder dan Windows98 hoor. Ik vind ze qua GUI eigenlijk ongeveer hetzelfde, alleen KDE is flexibeler en doet meer met bitmaps dan Windows. Maar omdat Linux intern veel beter in elkaar steekt dan Windows 98 (dat is echt ongeloofelijk slecht), zou dat niet veel uit moeten maken vind ik.

Op zondag 02 juni 2002 19:30 schreef ACM het volgende:
Heel leuk en aardig al die scheiding, maar performance technisch is dat natuurlijk niet het allerbest. "gelukkig" gaat alles langzaam maar zeker weer richting 'alles via het (inter)netwerk' waardoor XFree straks een grote voorsprong kan hebben.

Die scheiding van Window Manager of Desktop met XFree is niet zo interessant. Het gaat erom dat deze dingen intern niet snel zijn en dat er bovendien veel dubbele functionaliteit is...

[Anoniem: 27915]

Op maandag 03 juni 2002 01:11 schreef RG© het volgende:
Ow het kan zeker wel sneller, maar dan moet XFree denk ik voor een groot deel herschreven worden. En als X eenmaal snel is, dan blijft de GUI nog sloom, vanwege alle verschillede libs die in feite hetzelfde doen (GTK+ vs QT vs OpenMotif bijvoorbeeld). Dus heb je X eenmaal snel dan heb je pas 1 van de 4 problemen opgelost voor Linux op de desktop.

Gtk+ en qt zijn helemaal niet zo groot, dat valt best mee. Wat groot is, is gnome of KDE eromheen draaien. Dan wordt het slomer. Daarom moet je in Gnome geen KDE apps runnen en omgekeerd. Het kan wel, maar dat is dus sloom.

Gtk+ en Qt mergen haalt het idee van opensource weg. Bovendien is het idealistisch gezien onmogelijk.Niemand wil dat.

* Anoniem: 27915 blijft bij wat hij al eerder heeft gezegd - hij vindt 't wel best zo, X hoeft niet herschreven te worden en Gtk+/Qt of Gnome/KDE hoeven niet gemerged. .

[Anoniem: 27642]

lomp idee hoor maar zou je dan Xfree niet kunnen compilen zonder die netwerk zooi?
en meschien ook wat andere 'handige' dingetjes ervan die ik echt noooit gebruik niet mee compilen.
zou het daar sneller van worden? zou dat mogelijk zijn?

[RG]

Op maandag 03 juni 2002 07:31 schreef beelzebubu het volgende:
* Anoniem: 27915 blijft bij wat hij al eerder heeft gezegd - hij vindt 't wel best zo, X hoeft niet herschreven te worden en Gtk+/Qt of Gnome/KDE hoeven niet gemerged. .

Ja dat kun je vinden, maar dan wordt Linux nooit populair op de desktop. Niet dat dat hoeft van mij, maar het is wel zo. Zonder standaard GUI kom je er gewoon niet. Er ligt zo'n groot gat op het gebied van een newbievriendelijk open source systeem. Het zou me niets verbazen als OpenBeOS bijvoorbeeld over een jaar in dat gat kukelt.

Op maandag 03 juni 2002 08:39 schreef StratoS_V2.0 het volgende:
lomp idee hoor maar zou je dan Xfree niet kunnen compilen zonder die netwerk zooi?
en meschien ook wat andere 'handige' dingetjes ervan die ik echt noooit gebruik niet mee compilen.
zou het daar sneller van worden? zou dat mogelijk zijn?

XFree is tegenwoordig al vrij modulair dus je kunt alsveel dingen uitzetten die je niet nodig hebt. Maar intern blijft het op veel gebieden gewoon sloom, daar veranderd je niets aan met compileren. Daarvoor moet je de coders opbellen ofzo

[Lethalis]

Op maandag 03 juni 2002 08:39 schreef StratoS_V2.0 het volgende:
lomp idee hoor maar zou je dan Xfree niet kunnen compilen zonder die netwerk zooi?

Nee.

Heel simpel omdat X zowiezo via sockets werkt .. dus je hebt in feite een verbinding met de localhost staan op het moment dat je X gebruikt. Sockets zijn slomer dan directe pipes, vandaar dat X niet de snelste is.