Bewegen van vensters traag in XFree/KDE

[LollieStick]

Echt een probleem vind ik het niet, maar denk dat het toch meer CPU kracht vraagt.

Als ik een venster verplaats over het K Bureaublad, gaat dat zonder enige vorm van acceleratie. Het gaat dus echt heel haperig. Dit in tegenstelling tot Windows. Ik gebruik de nVidia drivers 29.60 met een GeForce2 MX200 (32MB geheugen) Systeemgeheugen is 512 MB DDR @ 266 Mhz op een Athlon XP 1700+. Dit moet toch gewoon vloeiend kunnen draaien lijkt mij. Weet iemand misschien wat het is.

Oh ja... heb het bij verschillende distro's gehad: SuSE, Gentoo, Red Hat en Mandrake ook. Debian heb ik wel gehad, maar kan me niet herinneren of deze het ook had.

Iemand die het weet?

bedankt

edit:

het stond overigens niet in de search

[Verwijderd]

Gebruik je wel de drivers van Nvidia zelf ?

De standaard XFree driver (die heet "nv") is niet bepaald snel en heeft soms last van grafische glitches.

Ik heb zelf RedHat 7.2 en 7.3 gedraait. Ging perfect. Heb nu Gentoo v1.2 en een "emerge nvidia-kernel nvidia-glx" haalde de drivers van Nvidia zo binnen. Makkelijker kan het niet.

[Verwijderd]

Waar jij waarschijnlijk last van hebt is het prehistorische render model van X..

_{gelukkig wordt er gewerkt aan iets nieuws (al 2 jaar door 1 persoon )}

[Verwijderd]

Paasklaas, Als je AGP en DRI goed hebt lopen in combinatie met die NVidia drivers loopt het echt als een speer !

[LollieStick]

Op vrijdag 12 juli 2002 22:49 schreef Bunny_Feet het volgende:
Gebruik je wel de drivers van Nvidia zelf ?

De standaard XFree driver (die heet "nv") is niet bepaald snel en heeft soms last van grafische glitches.

Ik heb zelf RedHat 7.2 en 7.3 gedraait. Ging perfect. Heb nu Gentoo v1.2 en een "emerge nvidia-kernel nvidia-glx" haalde de drivers van Nvidia zo binnen. Makkelijker kan het niet.

ja, de drivers van nvidia zelf en dat helpt helemaal niets

[Verwijderd]

Heb je in /etc/X11/XF86Config de module "glx" wel aan staan en heb je de driver "nv" wel vervangen door "nvidia" ?

Het moet lukken. Ik heb min of meer de zelfde hardware (dual 1700+ maar dat boeit hier niet).

[_JGC_]

Hier loopt zelfs een Kyro2 vloeiend, dus waarom een Nvidia niet zou je zeggen... Ook Savage4 heeft nergens problemen mee...

[Verwijderd]

Dit is mijn config:

Mijn monitor is een iiyama Vision Master Pro 450 19"

code:

Section "Module"

# This loads the DBE extension module.
    Load      "dbe"  # Double buffer extension

# This loads the miscellaneous extensions module, and disables
# initialisation of the XFree86-DGA extension within that module.
    SubSection  "extmod"
#   Option    "xfree86-dga"   # initialise the DGA extension
#   Option    "omit xfree86-dga"   # don't initialise the DGA extension
    EndSubSection

# This loads the Type1 and FreeType font modules
    Load      "type1"
    Load      "freetype"

# This loads the GLX module
    Load     "glx"

EndSection


Section "Monitor"

    Identifier  "iiyama"

# HorizSync is in kHz unless units are specified.
# HorizSync may be a comma separated list of discrete values, or a
# comma separated list of ranges of values.
# NOTE: THE VALUES HERE ARE EXAMPLES ONLY.  REFER TO YOUR MONITOR'S
# USER MANUAL FOR THE CORRECT NUMBERS.

    HorizSync   30-115

#    HorizSync30-64    # multisync
#    HorizSync31.5, 35.2    # multiple fixed sync frequencies
#    HorizSync15-25, 30-50  # multiple ranges of sync frequencies

# VertRefresh is in Hz unless units are specified.
# VertRefresh may be a comma separated list of discrete values, or a
# comma separated list of ranges of values.
# NOTE: THE VALUES HERE ARE EXAMPLES ONLY.  REFER TO YOUR MONITOR'S
# USER MANUAL FOR THE CORRECT NUMBERS.

    VertRefresh 50-160

EndSection


Section "Device"
    Identifier  "gf3"
    Driver  "nvidia"
    #VideoRam    65536
    # Insert Clocks lines here if appropriate
EndSection


Section "Screen"
    Identifier  "Screen 1"
    # Device    "Standard VGA"
    Device  "gf3"
    Monitor     "iiyama"
    DefaultDepth 24 
    Option     "NvAgp"  "1"
    Option     "NoLogo" "true"
    Subsection "Display"
      Depth  8
      Modes  "1280x1024"
      ViewPort    0 0
    EndSubsection
    Subsection "Display"
      Depth  16
      Modes  "1280x1024"
      ViewPort    0 0
    EndSubsection
    Subsection "Display"
      Depth  24
      Modes  "1280x1024"
      ViewPort    0 0
    EndSubsection
EndSection

[Verwijderd]

Op vrijdag 12 juli 2002 23:02 schreef Bunny_Feet het volgende:
Paasklaas, Als je AGP en DRI goed hebt lopen in combinatie met die NVidia drivers loopt het echt als een speer !

Zucht.. AGP.. kon dat maar.. daar moet ik helaas eerst een nieuw mb voor gaan halen (heb VIA Savage Pro chipset die niet wordt ondersteund door agpgart)
_{weet iemand toevallig of er voor die borden met nForce chipset ook AGP ondersteuning is onder Linux?}

Maar dat neemt niet weg dat het render model van X prehistorisch traag is en nodig aan vervanging toe is..

[LollieStick]

glx heb ik draaien ja en nv heb ik zeker vervangen door nvidia. (zo vergeetachtig ben ik nou ook weer niet ). Ik zal het straks met de config hierboven proberen. Bedankt imho.

[edit]
ik zie dat je nvagp gebruikt, maar ik dacht dat dit niet zo stabiel draaide op een VIA chipset. Ik gebruik AGPGart van de kernel, kan ik die dan uitzetten?

[LollieStick]

Op vrijdag 12 juli 2002 23:44 schreef paasklaas het volgende:

[..]

Zucht.. AGP.. kon dat maar.. daar moet ik helaas eerst een nieuw mb voor gaan halen (heb VIA Savage Pro chipset die niet wordt ondersteund door agpgart)
_{weet iemand toevallig of er voor die borden met nForce chipset ook AGP ondersteuning is onder Linux?}

Maar dat neemt niet weg dat het render model van X prehistorisch traag is en nodig aan vervanging toe is..

Alle VIA borden worden door AGPGart ondersteund toch? (uitgezonderd de nieuwe KT333)

[Verwijderd]

ik zie dat je nvagp gebruikt, maar ik dacht dat dit niet zo stabiel draaide op een VIA chipset. Ik gebruik AGPGart van de kernel, kan ik die dan uitzetten?

Wat stabiel is moet je achterkomen door ervaring. Ik heb een Asus A7M266-D (dus AMD sjipset) en daar draai nvagp subliem.

Op mijn oude Asus VIA 133 plank draaide AGPGART weer beter. Maar ook dat kan per plank verschillen. Prio 1 is stabiliteit. Als ze allebei stabiel zijn kan je de keuze op basis van performance gaan maken. Gewoon Kweek drie in timedemo mode draaien en loeren welke het rapst draait

AGPGART in de kernel uitzetten is een kwestie van:

A. Het ding niet mee compilen.
B. De module sneaky weghalen (wel ergens backuppen) en "depmod -a" draaien. Daarna nvagp aanzetten en hoppa

[deadinspace]

Op vrijdag 12 juli 2002 23:44 schreef paasklaas het volgende:
Maar dat neemt niet weg dat het render model van X prehistorisch traag is en nodig aan vervanging toe is..

X heeft wat beperkingen qua protocol, en XFree86 heeft wat brakke implementaties van het een en ander (valt over het algemeen wel mee).
De snelheidswinst die je haalt door een ander protocol oid is maar heel erg klein, en het is de vraag of je een alternatief kunt maken dat niet de implementatie-tekortkomingen van XFree86 heeft (met dezelfde hardware support uiteraard).

That said: het enige wat je voor windows moven hoeft te doen is blitten en dat kan XFree86 echt wel in hardware (mits de driver het snapt uiteraard). Ik heb hier dan ook geen schokkerigheid met het moven van windows (sterker nog, kheb maar heel weinig te klagen over XFree86's snelheid).

Ik zou het toch zoeken in de drivers of misschien nog iets anders... Gaat het afspelen van mp3s enzo bijvoorbeeld ook schokkerig?

[Verwijderd]

Op vrijdag 12 juli 2002 23:47 schreef LinuxUser het volgende:

[..]

Alle VIA borden worden door AGPGart ondersteund toch? (uitgezonderd de nieuwe KT333)

Was dat maar waar.. dan had ik nu geen nieuw bord hoeven kopen

Op zaterdag 13 juli 2002 00:54 schreef deadinspace het volgende:
X heeft wat beperkingen qua protocol, en XFree86 heeft wat brakke implementaties van het een en ander (valt over het algemeen wel mee).
De snelheidswinst die je haalt door een ander protocol oid is maar heel erg klein, en het is de vraag of je een alternatief kunt maken dat niet de implementatie-tekortkomingen van XFree86 heeft (met dezelfde hardware support uiteraard).

Ik heb het ook niet over een ander protocol.. maar sinds 2 jaar (ofzo) is er een persoon bezig met het schrijven van een ander render model voor X wat waarschijnlijk geimplementeerd zal worden via de RENDER extensie.
Dit nieuwe model zou wat sneller moeten zijn en ook translucente (hoe je dat ook typt in ABN) vensters zouden mogelijk zijn (compositie mbv de hardware -> snel)
Nou weet ik hier niet veel van, maar dit is wat ik zo'n beetje heb gelezen op de mailing lists..
_pcmiiw

Ik heb hier dan ook geen schokkerigheid met het moven van windows (sterker nog, kheb maar heel weinig te klagen over XFree86's snelheid).

Ik heb het al vaker gezegd (en niet alleen ik); probeer eens een venster te resizen (probeer het snel en langzaam), en probeer een groot venster maar eens snel te bewegen over het scherm (haper, haper..)
_{en dat ligt niet aan m'n hardware of drivers en ook niet aan de gebruikte DE en/of WM}

Ik zou het toch zoeken in de drivers of misschien nog iets anders... Gaat het afspelen van mp3s enzo bijvoorbeeld ook schokkerig?

Nope, dat gaat allemaal achterelkaardoor zonder gehaper.

_{en het ligt ook niet aan m'n huidige systeem of Red Hat of Mandrake of LFS want ik heb het op 3 totaal verschillende systemen (en distro's) gezien en allemaal haperen ze..}

[deadinspace]

Op zaterdag 13 juli 2002 01:26 schreef paasklaas het volgende:
Ik heb het ook niet over een ander protocol.. maar sinds 2 jaar (ofzo) is er een persoon bezig met het schrijven van een ander render model voor X wat waarschijnlijk geimplementeerd zal worden via de RENDER extensie.
Dit nieuwe model zou wat sneller moeten zijn en ook translucente (hoe je dat ook typt in ABN) vensters zouden mogelijk zijn (compositie mbv de hardware -> snel)

Ik wist van het (toekomstige) bestaan van XRENDER ja, maar ik dacht dat deze wat features zou toevoegen aan X, waaronder translucency (translucency is idd een probleem met X/XFree86).

Magoed, dat is dus een aanpak van de gedeeltelijk gebrekkige implementatie van XFree86.

Ik heb het al vaker gezegd (en niet alleen ik); probeer eens een venster te resizen (probeer het snel en langzaam), en probeer een groot venster maar eens snel te bewegen over het scherm (haper, haper..)

Een groot scherm snel verplaatsen of resizen gaat hier met weinig schokken... Alleen het redrawen van windows loopt aanzienlijk achter op het moven/resizen bij zwaardere apps zoals Galeon (het snel moven van een terminal over gkrellm, Enlightenments iconbox en XMMS gaat perfect).

Nope, dat gaat allemaal achterelkaardoor zonder gehaper.

Ik had het eigenlijk tegen de topicstarter
Die lijkt er namelijk ietsje meer last van te hebben.

[Verwijderd]

Ik had het eigenlijk tegen de topicstarter
Die lijkt er namelijk ietsje meer last van te hebben.

Ik vond het al zo'n vreemde vraag..

[SvMp]

Ik gebruik ook de XFree nv-driver voor m'n TNT2 M64, maar daar gaat alles prima, ook het bewegen van vensters in XFree/KDE.

[Verwijderd]

Op vrijdag 12 juli 2002 23:02 schreef Bunny_Feet het volgende:
Paasklaas, Als je AGP en DRI goed hebt lopen in combinatie met die NVidia drivers loopt het echt als een speer !

Heu?! NVidia die DRI ondersteund?! Dat staat toch niet als optie in de kernel?! Doe effe uitleggen hoe je dat geregeld heb dan? Ik heb wel de AGP zooi draaien enzo, maar dat DRI volg ik toch effe niet?

[Fatal-Error]

Weet niet of het voor veel snelheidswinst zorgt, maar heb je mtrr support in de kernel aan staan? Staat onder 'Processor type and features'. Ik kan me herinneren dat dat bij mij met films kijken veel uitmaakte.

[Fatal-Error]

Op zaterdag 13 juli 2002 00:54 schreef deadinspace het volgende:
That said: het enige wat je voor windows moven hoeft te doen is blitten en dat kan XFree86 echt wel in hardware (mits de driver het snapt uiteraard).

Maar de 'onderliggende' windows moeten wel opnieuw worden getekend toch? Dat verklaart de hoge cpu-load bij het verplaatsen van windows.

[Verwijderd]

Het zou me wederom niet verbazen als dit weer eens te maken heeft met de goede kwaliteit van de VIA chippies. Met een BX doet ie het bij mij verder zonder probs, niks schokkerig.

[RG]

Op zaterdag 13 juli 2002 02:04 schreef deadinspace het volgende:
Een groot scherm snel verplaatsen of resizen gaat hier met weinig schokken... Alleen het redrawen van windows loopt aanzienlijk achter op het moven/resizen bij zwaardere apps zoals Galeon (het snel moven van een terminal over gkrellm, Enlightenments iconbox en XMMS gaat perfect).

Galeon gebruikt GTK+, GTK+ gebruikt een mainloop en is niet multithreaded. Daarom gaat redrawen altijd pas gebeuren als je klaar bent met resizen volgens mij (kun je goed merken in the GIMP met veel vensters open op een wat ouder systeem). In Nautilus merk je het ook als je de preferences dialog opstart.

Een tijdje geleden was er hierover een flinke discussie op Slashdot. Wel heel interessant overigens. Gister nog met iemand een discussie over gehad trouwens XFree is dus erg sloom in het gebruik van de zogenaamde tekenobjecten (gaat via sockets). Verder schijnt de Windowmanager wat resizen betreft enzo vaak roet in het eten te gooien. Daarnaast zijn er nog de mainloop-toolkits zoals GTK+ en QT die het er ook allemaal niet sneller op maken (of liever: sneller laten ogen).

OS'en als BeOS en AtheOS gebruiken zware multithreading op de GUI, zodat het gehaal erg vloeiend loopt, mits er een goeie scheduler in de kernel zit. Daar hoef je bij Linux straks in 2.6 iig helemaal niet meer over te klagen...

[RG]

Op zaterdag 13 juli 2002 14:37 schreef janjanjansen het volgende:
Het zou me wederom niet verbazen als dit weer eens te maken heeft met de goede kwaliteit van de VIA chippies. Met een BX doet ie het bij mij verder zonder probs, niks schokkerig.

Wat heeft een chipset nou weer te maken daarmee? Dat ie nog niet ondersteund wordt is niet meer dan logisch (in 2.4.19 wel trouwens). Ik had juist super veel problemen met mijn systeem met BX chipset, maar aan die chipset heeft het echt niet gelegen...

[Verwijderd]

Op zaterdag 13 juli 2002 14:43 schreef RG© het volgende:

[..]

Wat heeft een chipset nou weer te maken daarmee? Dat ie nog niet ondersteund wordt is niet meer dan logisch (in 2.4.19 wel trouwens). Ik had juist super veel problemen met mijn systeem met BX chipset, maar aan die chipset heeft het echt niet gelegen...

Verklaar dan eens waarom met een bijna identieke Geforce2MX kaart, zelfde hoeveelheid geheugen (SDRAM) , p3 -1000, zelfde drivers, zelfde X versie vermoed ik, het hier NIET schokkerig is ? Ik gebruik dan wel Slackware maar so what?
Ik gebruik overigens XFS sindskort, maar dat zal het toch wel niet zijn.
Die pc van mij doet dus op de videokaart na onder voor degene van de topicstarter. Mijn videokaart is een MX400-64 MB met AGP 2x (overclocked op 89 Mhz)

[RG]

Op zaterdag 13 juli 2002 14:51 schreef janjanjansen het volgende:
Verklaar dan eens waarom met een bijna identieke Geforce2MX kaart, zelfde hoeveelheid geheugen (SDRAM) , p3 -1000, zelfde drivers, zelfde X versie vermoed ik, het hier NIET schokkerig is ? Ik gebruik dan wel Slackware maar so what?
Ik gebruik overigens XFS sindskort, maar dat zal het toch wel niet zijn.
Die pc van mij doet dus op de videokaart na onder voor degene van de topicstarter. Mijn videokaart is een MX400-64 MB met AGP 2x (overclocked op 89 Mhz)

Omdat de chipset niet ondersteund wordt. Dat zou best kunnen, daarmee zijn VIA chipsets nog niet brak. De KT333 is nieuwer dan de 2.4.18 kernel. Gek he dat ie niet ondersteund wordt Koos Korswagen In 2.4.19 overigens wel, ook de southbridge met U133 controller (die werkt ook niet in 2.4.18).

[LollieStick]

Op zaterdag 13 juli 2002 02:04 schreef deadinspace het volgende:
[...]
Ik had het eigenlijk tegen de topicstarter
Die lijkt er namelijk ietsje meer last van te hebben.

sorry ik was vandaag niet thuis dus kon niet eerder reageren. MP3's enzo gaan niet sloom, maar redrawen, bewegen (snel en langzaam) van vensters weer wel.

op een pentium 400 (AMD K6-2) had ik het zelfs zo dat ik nog geen videoclip kon afspelen. nu denk ik dat dat een ander probleem is en dat ben ik nu (hoop ik) aan het oplossen met gcc 3.1 maar op de pc waar ik het nu over heb is al athlon-xp optimized met gcc 3.1.

Op zaterdag 13 juli 2002 14:56 schreef RG© het volgende:

[..]

Omdat de chipset niet ondersteund wordt. Dat zou best kunnen, daarmee zijn VIA chipsets nog niet brak. De KT333 is nieuwer dan de 2.4.18 kernel. Gek he dat ie niet ondersteund wordt Koos Korswagen In 2.4.19 overigens wel, ook de southbridge met U133 controller (die werkt ook niet in 2.4.18).

euh... had ik er niet bij vermeld maar het is een KT266 (no-A).

Verder heb ik: Xfree 4.2.0, KDE 3.0.1 (3.0.2 komt als ie klaar is )

[Verwijderd]

Probeer in je /etc/X11/Xf86Config dit een toe te voegen

load "extmod"

Ik hoor het wel effe al het werkt

[deadinspace]

Op zaterdag 13 juli 2002 12:06 schreef Shoikan het volgende:
Heu?! NVidia die DRI ondersteund?! Dat staat toch niet als optie in de kernel?! Doe effe uitleggen hoe je dat geregeld heb dan? Ik heb wel de AGP zooi draaien enzo, maar dat DRI volg ik toch effe niet?

Ehm, de nvidia drivers die je zelf compiled produceren toch ook een kernel module? Dat is als het goed is dus een DRI module, zodat je DRI support hebt voor je kaart.

Op zaterdag 13 juli 2002 14:29 schreef Fatal-Error het volgende:
Maar de 'onderliggende' windows moeten wel opnieuw worden getekend toch? Dat verklaart de hoge cpu-load bij het verplaatsen van windows.

Ja, die moeten opnieuw getekend worden, maar afaik is dat in alle OSsen zo (in Windows in ieder geval... Het redrawen kan op mijn vaders PC in Windows af en toe tamelijk langzaam gaan).

Op zaterdag 13 juli 2002 14:41 schreef RG© het volgende:
Galeon gebruikt GTK+, GTK+ gebruikt een mainloop en is niet multithreaded. Daarom gaat redrawen altijd pas gebeuren als je klaar bent met resizen volgens mij (kun je goed merken in the GIMP met veel vensters open op een wat ouder systeem). In Nautilus merk je het ook als je de preferences dialog opstart.

Hmm, nee. het gebrek aan multithreading zou hier geen rol mogen spelen. Immers, op het moment dat je resized is GTK's mainloop aan het idlen. Dan ontvangt het een event van X, waardoor het gaat redrawen. Maar dat kan dus tijdens het resizen gebeuren (probeer maar met Abiword, die lukt het wel).

Een tijdje geleden was er hierover een flinke discussie op Slashdot. Wel heel interessant overigens. Gister nog met iemand een discussie over gehad trouwens XFree is dus erg sloom in het gebruik van de zogenaamde tekenobjecten (gaat via sockets). Verder schijnt de Windowmanager wat resizen betreft enzo vaak roet in het eten te gooien. Daarnaast zijn er nog de mainloop-toolkits zoals GTK+ en QT die het er ook allemaal niet sneller op maken (of liever: sneller laten ogen).

http://slashdot.org/comments.pl?sid=35705&cid=3859702 bedoel je? Dat was een interessante post ja.
Maar zijn argumenten lijken mij op op het moven van windows niet zo van toepassing... WM zegt tegen X dat window moet moven, en X doet dat. Het blit de inhoud van het window naar een andere plaats en klaar. De app hoeft afaik pas te redrawen als je het window definitief naar zijn nieuwe plaats hebt gesleept. Als je hierbij over andere windows heen komt, dan krijgen zij een expose event en ze worden verteld welk deel van hun window opnieuw getekend moet worden, wat ze dan doen.
En ook dat is in overeenkomst met mijn ervaring... Een aterm moven over E's iconbox, gkrellm en XMMS gaat perfect en kost hier (pII-448) iets van 30% CPU.

Resizen is inderdaad een groter probleem, zeker qua redrawen.

Op zaterdag 13 juli 2002 18:06 schreef LinuxUser het volgende:
sorry ik was vandaag niet thuis dus kon niet eerder reageren. MP3's enzo gaan niet sloom, maar redrawen, bewegen (snel en langzaam) van vensters weer wel.

op een pentium 400 (AMD K6-2) had ik het zelfs zo dat ik nog geen videoclip kon afspelen.

Raar.. Je hebt het dus al met een relatief simpel window dat je over je achergrond beweegt?

[Verwijderd]

Ik denk dat het aan je geheugen ligt.
Er wordt gewoon minder gebruikt dan er beschikbaar is.

1. Kijk in je BIOS naar memory hole: schakel dit uit.
2. Geef LILO de optie ''mem=128mb'' mee, dit kun je na succes ook toevoegen in ''/etc/lilo.conf'' door de regel append=128mb te gebruiken. Voor meer informatie: ''man lilo''.

[RG]

Op zaterdag 13 juli 2002 23:19 schreef deadinspace het volgende:
Ja, die moeten opnieuw getekend worden, maar afaik is dat in alle OSsen zo (in Windows in ieder geval... Het redrawen kan op mijn vaders PC in Windows af en toe tamelijk langzaam gaan).

Bij Windows kan redraen idd ook niet altijd even snel gaan. Voor zover ik weet doet Windows niet aan kernel pre-emptive multitasking (Linux ook niet, tenzij je die patch van Robert Love over de source heengooit). Daardoor kan onder zware IO het redrawen sloom gaan, of MP3's gaan haperen.

Op zaterdag 13 juli 2002 23:19 schreef deadinspace het volgende:
Hmm, nee. het gebrek aan multithreading zou hier geen rol mogen spelen. Immers, op het moment dat je resized is GTK's mainloop aan het idlen. Dan ontvangt het een event van X, waardoor het gaat redrawen. Maar dat kan dus tijdens het resizen gebeuren (probeer maar met Abiword, die lukt het wel).

Dan denk ik dat de Gecko engine roet in het eten gooit (weet ik niet zeker). Galeon is niet echt veel zwaarder dan Abiword lijkt me. Feit is dat GTK+ ook sloom redrawed in Windows (check GIMP maar eens uit op een slome bak!) Beweeg de filedialog maar eens over het hoofdvenster...

Op zaterdag 13 juli 2002 23:19 schreef deadinspace het volgende:
http://slashdot.org/comments.pl?sid=35705&cid=3859702 bedoel je? Dat was een interessante post ja.
Maar zijn argumenten lijken mij op op het moven van windows niet zo van toepassing... WM zegt tegen X dat window moet moven, en X doet dat. Het blit de inhoud van het window naar een andere plaats en klaar. De app hoeft afaik pas te redrawen als je het window definitief naar zijn nieuwe plaats hebt gesleept. Als je hierbij over andere windows heen komt, dan krijgen zij een expose event en ze worden verteld welk deel van hun window opnieuw getekend moet worden, wat ze dan doen.
En ook dat is in overeenkomst met mijn ervaring... Een aterm moven over E's iconbox, gkrellm en XMMS gaat perfect en kost hier (pII-448) iets van 30% CPU.
Resizen is inderdaad een groter probleem, zeker qua redrawen.

Die post bedoelde ik niet, is al een paar maandjes terug. Was nogal een flinke discussie over waarom een mainloop uiteindelijk wel sneller is, maar niet zo vloeiend werkt. En daar gaat het uiteindelijk toch om.

[deadinspace]

Op zondag 14 juli 2002 02:57 schreef RG© het volgende:
Bij Windows kan redraen idd ook niet altijd even snel gaan. Voor zover ik weet doet Windows niet aan kernel pre-emptive multitasking (Linux ook niet, tenzij je die patch van Robert Love over de source heengooit). Daardoor kan onder zware IO het redrawen sloom gaan, of MP3's gaan haperen.

Dat klopt. Als ik op mijn vaders PC iets over het netwerk kopieer (10 MBit, SMB... pak-em-beet 800 k/sec dus) hapert het onwijs, en het redrawen gaat echt traag. Bij diezelfde snelheid heeft mijn desktop zoiets van *gaaap* (minder dan 10% CPU usage). En mijn desktop is maar 60% sneller dan die van mijn vader.
Maar in GNU/Linux merk je hetzelfde vrij goed bij veel disk I/O.

Dan denk ik dat de Gecko engine roet in het eten gooit (weet ik niet zeker). Galeon is niet echt veel zwaarder dan Abiword lijkt me.

Galeon is stukken zwaarder dan Abiword als je mozembed meerekent. Die zal het redrawen flink trager maken.

Feit is dat GTK+ ook sloom redrawed in Windows

GTK+1.2 is ook maar so-so op win32 (GTK+2.0 zou beter zijn).

Die post bedoelde ik niet, is al een paar maandjes terug. Was nogal een flinke discussie over waarom een mainloop uiteindelijk wel sneller is, maar niet zo vloeiend werkt. En daar gaat het uiteindelijk toch om.

Mja, als het een afweging is die positief uitpakt voor performance, dan vind ik het eigenlijk niet zo erg.
Maar het mooiste zou zijn als je kon kiezen (soort afweging snel <--> vloeiend).

[LollieStick]

Op zondag 14 juli 2002 01:47 schreef zune het volgende:
Ik denk dat het aan je geheugen ligt.
Er wordt gewoon minder gebruikt dan er beschikbaar is.

1. Kijk in je BIOS naar memory hole: schakel dit uit.
2. Geef LILO de optie ''mem=128mb'' mee, dit kun je na succes ook toevoegen in ''/etc/lilo.conf'' door de regel append=128mb te gebruiken. Voor meer informatie: ''man lilo''.

wordt er minder of meer gebruikt? minder lijkt mij heel erg vreemd omdat ik altijd geleerd heb zoveel te meer (niet overdrijven natuurlijk) geheugen je hebt, zoveel te beter en sneller het werkt

de pentium 400 bak heeft 328 MB geheugen (VESA driver) en de Athlon XP 512 MB DDR (nVidia 32 MB)