View Full Version : lentezza di gnome
cicoandcico
08-04-2006, 14:34
ho provato la nuova 2.14 nella speranza della maggiore "velocità" promessa dagli sviluppatori, ma non ne vedo traccia.
sui pc (un p4 2.16, un xp 2400+ e un notebook) in cui ho provato il live cd di ubuntu, noto soltanto la scattosità di ogni operazione di redraw. provate semplicemente a muovere velocemente una finestra sul desktop, o a ridimensionarla. a me va tutto a scatti.
a paragone, kde (famoso per la sua pesantezza (?)) è liscio come una palla da biliardo. e sono uno gnome user.
non voglio aprire un flame, ma voi sperimentate la stessa lentezza o è solo una mia impressione? secondo voi da cosa dipende e come può / potrà essere risolto?
non voglio aprire un flame, ma voi sperimentate la stessa lentezza o è solo una mia impressione? secondo voi da cosa dipende e come può / potrà essere risolto?
imho non è assolutamente normale, sicuramente hai qualche problema.
di norma muovere velocemente una finestra sul desktop e avere scatti non esiste.
hai dato uno sguardo a top?
Ciao
Ho avuto anche io un problema di lentezza simile.... con la suse e con la debian. Uso un sacco il pulsante per tornare dal desktop, ecco c'era un sensibile ritardo del drawing delle icone sul desktop, e non dipendeva dalla loro quantità!
Tutt'ora non sono riuscito a capire da cosa dipendesse.... mi è capitato sia su debian etch che su suse, non mi è successo con fedora core e ubuntu... Boh!
Ciocco@256
08-04-2006, 14:54
Mi aggrego anch'io alla domanda, ho notato la stessa cosa (e anch'io gnome user).
Cosa si intende con dare un'occhiata a top :) ?
- Scusate l'ultima domanda, ho cercato su google ma il termine 'top' da un po' troppi risultati :D -
Mi aggrego anch'io alla domanda, ho notato la stessa cosa (e anch'io gnome user).
Cosa si intende con dare un'occhiata a top :) ?
- Scusate l'ultima domanda, ho cercato su google ma il termine 'top' da un po' troppi risultati :D -
top = display Linux tasks
digita top da terminale e vedi se ti salta all'occhio qualche processo che ciuccia molta ram o molta cpu, magari anche quando muovi le finestre veloce e ti provovano scatti.
- Scusate l'ultima domanda, ho cercato su google ma il termine 'top' da un po' troppi risultati :D -
bastava che invece di cercare "top" cercavi "man top" per restringere la ricerca ;)
cicoandcico
08-04-2006, 15:30
non ho sottomano il livecd ora, e top non l'ho guardato. ma stiamo parlando di 3 pc differenti, e inoltre il vecchio 2.12 che avevo sul fisso si comportava in maniera uguale a questo 2.14 su ubuntu. inotre provando la suse live (col 2.12) non ho notato miglioramenti sostanziali, quindi non è imputabile ad ubuntu.
provate ad aprire totem senza nessun filmato e a ridimensionare la finestra: a me va tutto a scatti (su tutti i pc) e con evidenti problemi di redraw. kde non lo fa assolutamente, è fluidissimo :confused:
tra l'altro questo problema si ripercuote su firefox, che ha uno scrolling scattoso al limite dell'inusabilità e anche un cambiamento di tab lentissimo.
poterbbe essere dovuto al fatto che sia la ubuntu che la suse che hai provato sono live, forse è più Anormale che non ti scatti anche kde :D
edit: imho comunque non è da sottovalutare visto che il problema lo hai con entrambe e in comune hanno anche il fatto di essere live :)
cicoandcico
08-04-2006, 15:48
ok, ma come ho detto la 2.12 (sotto debian) che avevo sul fisso si comportava in maniera uguale. se apri totem e lo risimensioni non noti anche te la lentezza?
io ho imputato il problema alle gtk... di cui ho trovato parecchie testimonianze di problemi di redraw.
ok, ma come ho detto la 2.12 (sotto debian) che avevo sul fisso si comportava in maniera uguale.
:boh:
se apri totem e lo risimensioni non noti anche te la lentezza?non uso totem/xine ma mplayer liscio senza gui, non uso gnome ma bensì fluxbox e puoi immaginare come va tutto fluido, ovviamente ho solo applicazioni gtk1/2 based e niente che sia Qt.
aspettiamo e vediamo se saltano fuori altri utenti che hanno il suo stesso problema :)
Dcromato
08-04-2006, 17:08
io ho imputato il problema alle gtk... problemi di redraw.
Quoto, il vero problema di Gnome continua a essere legato alle Gtk.Speriamo che le restaurino per bene.
Quoto, il vero problema di Gnome continua a essere legato alle Gtk.Speriamo che le restaurino per bene.
a sto punto mi chiedo perchè io non ho questi problemi :what:
bo, non so cosa me lo fa pensare ma sono ottimista e continuo credere che non tutti siano nel vostro stato :)
magari mi sbagliero :p
Dcromato
08-04-2006, 17:13
a sto punto mi chiedo perchè io non ho questi problemi :what:
bo, non so cosa me lo fa pensare ma sono ottimista e continuo credere che non tutti siano nel vostro stato :)
Che configurazione hai Piloz?Io ho un pc vetusto e Kde in tutte le distro mi risultava sempre piu veloce.Su pc piu recenti non ho notato però una ste gran differenza.
Che configurazione hai Piloz?Io ho un pc vetusto e Kde in tutte le distro mi risultava sempre piu veloce.Su pc piu recenti non ho notato però una ste gran differenza.
hardware: 2250Hz su un barton mobile, il disco dove sta il sistema è un normale Maxtor da 40 pata, 512 Corsair xms cas2, bus a 266 su kt400.
sofware: fluxbox , il resto da terminale o gtk1/2. Solitamente il programma aperto più pesante è firefox.
comunque gnomebaker o qualsiasi altro programma lo svolazzo come voglio sul desktop.
CiauZ
Ciocco@256
08-04-2006, 18:36
PiloZ, scusami per la domanda banale di prima...ero su win e avevo azionato la modalità cervello sbagliata :D
Comunque tornando al pratico:
- confermo i test effettuati da cicoandcico: aprendo totem e spostandolo velocemente sul desktop ha evidenti piccoli scatti (se trovo il modo faccio un filmatino per farvi capire meglio). Per Firefox stessa lentezza, che ho in parte risolto installando un Firefox compilato per athlonXP e -o3 (!).
Altro problemino di gnome che notavo io era la netta differenza nel visualizzare le icone di default oppure un altro tema di icone scaricato: sembrava che le andasse a caricare ogni volta dall'hard disk; per questo ho risolto creando la cache delle icone col comando
"gtk-update-icon-cache -f /home/ciocco/.icons/nometema"
(questo trucchetto è da mettere in gnome clan secondo me :) )
- ho provato con top: col sistema a riposo il processo che occupa di più è xorg, circa 1% / 1.3%, il resto pochissimo o nulla.
Con aperto totem, e spostando la sua finestra senza nulla in riproduzione, nel modo più fluido possibile (come movimento del mouse intendo), gli scattini sono presenti e da top ho Xorg che schizza al 73% :eek: , al 6% gnome-terminal (xkè sta aggiornando i risultati di top), al 4% metacity, 2% di totem, 1% gnome-setting, il resto meno.
Cercando di analizzare le cause:
- escluderei il fatto della live perchè io e anche cicoandcico hanno riscontrato il problema anche con distro installate. Inoltre xorg dovrebbe caricarlo tutto in ram, e anche totem una volta aperto è in ram, quindi sul cd non pesca mentre si sposta una finestra... (credo eh)
- pensiamo ai driver: ho i driver nvidia proprietari con l'opzione - Option "RenderAccel" "true" - quindi dovrebbero accelerare qualcosa, ma evidentemente non è così visto che Xorg schizza al 73% per spostare una finestra :eek: !!! Rimane il fatto che con Kde (stessi driver e stesso xorg.conf e stessa distribuzione) il problema è meno evidente [purtroppo non posso guardare top da kde che ora non ce l'ho installato].
Quindi li escludiamo o no? :boh:
- guardiamo le gtk: se su fluxbox è tutto ok, non dovrebbero essere neanche quelle. Inoltre avevo provato l'howto per accelerare le gtk (quello "famoso" di linux-help), usando cairo e glitz, ma non era cambiato molto. Quindi escluderei che la causa siano le gtk.
- a questo punto il problema potrebbe essere metacity, visto che in effetti gli scattini maggiori si notano di più guardando ai bordi delle finestre, ai ridimensionamenti, agli effettini di metacity per iconizzare tutte le applicazioni, etc. Ora, esiste qualcos'altro di alternativo a Metacity per gnome? Se esiste si può provare...
- Escluderei anche la distribuzione, dato che ho visto questo problema su Debian, Ubuntu, Archlinux, ed in misura leggermente minore su Suse e Fedora (comunque anche sulle ultime due si notava).
Che dite?
ps.: dimenticavo: il mio hardware è in firma.
:eek: :eek: :eek:
smonto da lavoro, forse è il caso che lo legga da casa con calma seduto in una poltrona con i popcorn :D
PuNkEtTaRo
08-04-2006, 19:01
ho provato la nuova 2.14 nella speranza della maggiore "velocità" promessa dagli sviluppatori, ma non ne vedo traccia.
sui pc (un p4 2.16, un xp 2400+ e un notebook) in cui ho provato il live cd di ubuntu, noto soltanto la scattosità di ogni operazione di redraw. provate semplicemente a muovere velocemente una finestra sul desktop, o a ridimensionarla. a me va tutto a scatti.
a paragone, kde (famoso per la sua pesantezza (?)) è liscio come una palla da biliardo. e sono uno gnome user.
non voglio aprire un flame, ma voi sperimentate la stessa lentezza o è solo una mia impressione? secondo voi da cosa dipende e come può / potrà essere risolto?
secondo me non hai installato i driver video...
che scheda grafica hai? ati, nvidia??
questo lavoro mi succede su windows, se non ho installato i driver grafici...
controlla con glxinfo che direct rendering sia su yes...
ciao
controlla con glxinfo che direct rendering sia su yes...
ciao
ottima idea :flower:
ottima idea :flower:
si ma perchè con KDE il problema non salta fuori? :(
cicoandcico
08-04-2006, 20:12
secondo me non hai installato i driver video...
che scheda grafica hai? ati, nvidia??
questo lavoro mi succede su windows, se non ho installato i driver grafici...
controlla con glxinfo che direct rendering sia su yes...
ciao
i driver video sono installati correttamente... l'ho addirittura fatto a manina con gli ultimi, per riprova.
Artemisyu
08-04-2006, 20:15
ok, ma come ho detto la 2.12 (sotto debian) che avevo sul fisso si comportava in maniera uguale. se apri totem e lo risimensioni non noti anche te la lentezza?
io ho imputato il problema alle gtk... di cui ho trovato parecchie testimonianze di problemi di redraw.
Debian con gnome 2.12 e nessun problema nè traccia della lentezza che dici :)
Anche Ubuntu e gnome 2.14, sullo stesso computer e anche sul portatile, nessun problema.
Fedora Core 5 sul portatile, con gnome 2.14, una scheggia :)
cicoandcico
08-04-2006, 20:15
- confermo i test effettuati da cicoandcico [...]
sottoscrivo tutti i tuoi rilevamenti. bisognerebbe provare con sawfish (il vecchio window manager di gnome), ma non so se è basato sulle GTK2. poi c'è compiz, ma è basato sul codice di metacity e nel resize si comporta alla stessa lenta maniera.
ps: quello delle icone è formidabile, ho cercato qualcosa di simile in lungo e in largo. perché non lo mettono di default???
PuNkEtTaRo
08-04-2006, 20:30
si ma perchè con KDE il problema non salta fuori? :(
a questo non avevo pensato...
sinceramente non ho una grande esperienza con kde...sono uno gnome user (anche se prima ero un fluxbox user!!!!!)...
mi viene da pensare che magari in kde, il rendering delle finestre sia gestito in maniera diversa...magari ottimizzando più l'uso della cpu...che della scheda grafica..boh...non mi viene altro...
ciao
mi viene da pensare che magari in kde, il rendering delle finestre sia gestito in maniera diversa...magari ottimizzando più l'uso della cpu...che della scheda grafica..boh...non mi viene altro...
ciao
se così fosse sarebbero tutti come cicoandcico e Ciocco@256 :stordita:
boh io mi guardo Sin City :D
Ciocco@256
08-04-2006, 21:58
http://listengnome.free.fr/img/screencast/playlist.gif
Ecco, qui c'è un altro esempio di lentezza: guardate quando vengono rinominate le playlist...quanto cavolo ci vuole a disegnare e far sparire la finestrella?!?!
Con un tema un pochino più semplice forse si nota un po' meno...ma forse.
A proposito :D : interessantissimo questo listen!!! Sembra l'equivalente di amarok ma per gnome!
per il glxinfo: anche per me tutto a posto, i driver funzionano correttamente.
per le icone: son contento che il trucchetto ti sia piaciuto cicoandcico ;) ! Anch'io ho cercato parecchio prima di trovare quel comando...
Siete d'accordo con le mie semi-conclusioni di prima? Cioè che il problema può essere metacity?
Siete d'accordo con le mie semi-conclusioni di prima?io sono con te :)
Cioè che il problema può essere metacity?
quà invece non ci metterei la mano sul fuoco :ciapet:
spulciavo le immagini in quel link
http://listengnome.free.fr/img/screencast/nautilus_burn.gif
per curiosità ma da quando è che nautilus masterizza? :what:
A proposito :D : interessantissimo questo listen!!! Sembra l'equivalente di amarok ma per gnome!
io mi ci butto con il .deb perchè sono curioso anche se sarà difficile che abbandonerò xmms :)
cicoandcico
09-04-2006, 12:56
davvero interessante questo listen...
con kde il problema non esiste perché cambiano sia librerie (qt invece che gtk) che window manager (kwin, credo, invece che metacity). se piloz mi dice che con fluxbox le applicazioni gtk2 non hanno questi problemi, a questo punto credo che il collo di bottiglia sia proprio metacity (che tra l'altro ha sollevato molte altre critiche).
bisognerebbe che provi fluxbox, per vedere se è colpa del mio pc, se no un altro wm per gnome. oggi farò qualche test :)
il trocco delle icone è assurdo che non sia default! :mad:
cicoandcico
09-04-2006, 13:18
qui ne parlano:
http://ubuntuforums.org/showthread.php?t=141755&highlight=resizing+slow
"Metacity is a mystery sometimes. First under SUSE 10 it was nearly as sluggish with redrawing like Dapper. Then I switched between different window managers and suddenly Metacity was really fast. Don't know why!? I had no redrawing artifacts any more although I had not enabled composite or sth like that.
I already asked in a Metacity post if someone knows how you can make Metacity faster. But I got no answer. If I have more time I try to figure out which trick makes Metacity so much faster..."
Sono passato da GNOME 2.12 e GNOME 2.14 su ARCH (quindi compilato per i686) e il salto di velocità è stato impressionante :p
...KDE IMHO non è lento e male organizzato :O
Dcromato
09-04-2006, 15:03
...KDE IMHO non è lento e male organizzato :O
:rotfl: :rotfl: :rotfl:
:rotfl: :rotfl: :rotfl:
Ma che ti ridi :sofico: ?!
IMHO il Centro di Controllo di KDE è una porcheria :O
cicoandcico
09-04-2006, 15:20
allora ho fatto un po' di prove:
1) damn small linux con fluxbox. se abilito "show window content while moving" (o qualcosa del genere) non ci sono miglioramenti rispetto a gnome. xorg mangia il 70% della cpu quando si muove una finestra e il tutto è lentissimo.
2) slax con kde. il movimento, e soprattutto il ridimensionamento delle finestre è fluido, anche se l'occupazione della cpu non cambia. boh?
3) slax popcorn con xcfe. lento come gnome, stessa occupazione della cpu.
la domanda è: perché kde è veloce anche se l'occupazione della cpu è la stessa?
piloz: ma a te fluxbox non va lento se selezioni quella opzione di mostrare il contenuto della finestra durante il movimento? :confused:
Dcromato
09-04-2006, 15:21
Ma che ti ridi :sofico: ?!
IMHO il Centro di Controllo di KDE è una porcheria :O
Certo che ormai non sapete piu a che cosa attaccarvi... :D il centro di controllo Kde porcheria...non te lo concedo assolutamente, e poi un corrispettivo simile cosi potente su Gnome ve lo scordate. :sofico:
...
Io non noto problemi, sarà che ho il Direct Rendering abilitato (NVIDIA RULES)
Certo che ormai non sapete piu a che cosa attaccarvi... :D il centro di controllo Kde porcheria...non te lo concedo assolutamente, e poi un corrispettivo simile cosi potente su Gnome ve lo scordate. :sofico:
Ma chi la vuole quella ciofeca, mi sono sempre trovato malissimo...
Ciocco@256
09-04-2006, 15:51
qui ne parlano:
http://ubuntuforums.org/showthread.php?t=141755&highlight=resizing+slow
"Metacity is a mystery sometimes. First under SUSE 10 it was nearly as sluggish with redrawing like Dapper. Then I switched between different window managers and suddenly Metacity was really fast. Don't know why!? I had no redrawing artifacts any more although I had not enabled composite or sth like that.
I already asked in a Metacity post if someone knows how you can make Metacity faster. But I got no answer. If I have more time I try to figure out which trick makes Metacity so much faster..."
Nella discussione che hai linkato qualcuno ha tirato in ballo anche nautilus come possibile causa :confused:
Comunque, seguendo questo howto sono passato da metacity a xfwm4
http://ubuntuforums.org/showthread.php?t=88393&highlight=metacity
Esteticamente si integra bene con gnome, ecco uno screen mio:
http://img465.imageshack.us/img465/7070/schermata9nl.th.png (http://img465.imageshack.us/my.php?image=schermata9nl.png)
Così va un po' meglio, ma riconfermo cicoandcico, non tanto. In realtà, se prima erano i bordi delle finestre ad essere disegnati con un po' di ritardo, adesso è l'interno che ritarda rispetto al bordo che invece è praticamente istantaneo :D Insomma, un po' meglio che con Metacity ma ancora non ci siamo.
E ora che si fa ? Non saprei più cosa provare...magari ora ritento il metodo cairo con backend opengl + glitz per accelerare le gtk...cosa non si fa per disperazione :D Oppure si aspetta con pazienza un xgl/composite/aiglx (ora come ora io li trovo troppo beta, anzi alpha).
Rimane il fatto che con Kde questi problemi sono meno evidenti (io li noto anche lì però).
Poi rispondendo ai semi-ot:
- per le icone bisognerebbe informare della cosa chi crea i set nuovi di icone, in modo che distribuiscano i pacchetti con la cache già creata! In pratica bisogna dirlo a gnome-look :)
A proposito di icone...ammazza quanto fanno schifo quelle che stanno preparando per ubuntu nuovo! mamma mia...ma perchè non usano le dropline etiquette? Sono anche giallone scuro, col marrone di ubuntu stanno benissimo. Per me sono le migliori in assoluto, e quantomeno di default sono sicuramente meglio di quelle che ha gnome adesso...Vabbè, al max ne riparliamo nella discussione degli screenshot.
- per la capacità di masterizzare di nautilus: mi pare ci sia dal 2.10 . Ora nel 2.10 e 2.12 però l'opzione è nascostissima, perchè bisogna aprire una finestra di esplorazione di nautilus, e poi fare vai->creazione CD/DVD :muro: Nel 2.14 lo hanno finalmente messo in bella mostra sotto il menu risorse.
- per listen: l'ho provato...fantastico! semplicissimo da usare, interfaccia chiara e pulita in perfetto stile gnome, gtk2, tira giù info sul gruppo da wikipedia, il testo della canzone da non so dove, la copertina dell'album da non so dove, da audioscrobbler i gruppi simili, e tutto a portata di mano...mi è piaciuto un sacco! una pecca: manca l'equalizzatore :cry: - ma perchè manca nella maggior parte dei player/jukebox? non c'è in rhythmbox, non c'è in quodlibet, non c'è in questo listen, non c'è in songbird (vabbè quello non c'è manco per linux ancora ::muro: ). Solo xmms (e beepmediaplayer) ce l'hanno...tra l'altro non è neanche granchè...ma è così difficile farne uno? bah...
- lasciamo perdere kde vs gnome che non mi sembra la discussione adatta...anche perchè se siamo qui a dibattere vuol dire che piuttosto usiamo gnome a velocità lumaca, ma kde mai :ciapet:
Ciocco@256
09-04-2006, 15:52
Io non noto problemi, sarà che ho il Direct Rendering abilitato (NVIDIA RULES)
Eh...anche io ho nvidia e il direct rendering abilitato :stordita:
se piloz mi dice che con fluxbox le applicazioni gtk2 non hanno questi problemi
garantisco :sborone: schizzano talmente tanto che se non sto attento mi partono dal monitor :D , passano attraverso il muro e arrivano sul desktop del mio coniquilino :D , il tutto senza un minimo scatto ;)
per il resto kcontrol sucks :O
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.