Newsgroup: it.comp.os.linux.development
Titolo: window manager

Avete notato che praticamente tutti i wm quando imposti il trascinamento
delle finetre opaco, lasciano una scia all'interno delle finestre e le
icone sul desktop ricompaiono dopo qualche secondo?
E' come se i wm non siano del tutto ottimizzati e quando sposti una
finestra, congelano il flusso dati tra X e le applicazioni e solo quando
fermi la finestra, il flusso riparte e le apps ridisegnano il loro spazio.
dopo vari esperimenti appurato che è prorpio colpa dei wm (se infatti
guardiamo il super-ottimizzato quartz-wm in osx non accenna ad
minimamente a ritardi di refresh) e solo in parte delle applicazioni e
dei loro specifici widgets.
qualcuno ha provato un wm veramente di qualità, magari da sostituire a
metacity (che abbastanza schifo) in Gnome.
I migliori finora che ho provato sono blackbox che si integra
parzialmente con gnome e sawfish e kwin che sono direi perfettamente
integrati.
Accetto anche proposte di wm non integrati, ma interessanti da provare.
Ho già visitato 
xwinman.org
 e chiaramente non li ho provati tutti, ho
postato sul news prorpio per evitarmi di provare tutti i wm.
Grazie e Ciao.

 icone sul desktop ricompaiono dopo qualche secondo?
non c'entra niente il wm , è probabilmente un problema del driver di X , non
ho problemi simili ne sul portatile ne sul fisso , mentre ho un problema
del genere su un server con una vecchia s3.
-- 
Bologna:
        Arrestate otto persone nella toilette di un autogrill.  Stavano
urinando in luogo pubblico.
                -- Panfilo Maria Lippi (Daniele Luttazzi), "TABLOID"

 fermi la finestra, il flusso riparte e le apps ridisegnano il loro spazio.
uso Windowmaker con i driver NVIDIA 1.0.7174 e il RenderAccel attivo, e
non ho questo tipo di problemi.
credo che dipenda dalla cpu e dai driver di X, ma anche dalla pesantezza
del WM, o nel caso di kde e gnome, della pesantezza di tutto il desktop.
con l'estensione XComposite di xorg le cose vanno meglio (con xorg 6.8.2
e' *quasi* perfetto).
ciao

 problema del genere su un server con una vecchia s3.
Suppongo che il problema nasca dalla mancanze del supporto alle estensioni
di X (es. il direct rendering) che accellerano la visualizzazione e tolgono
'carico' a X.

 window-manager fanno la loro parte.
si , ma non vedo problemi del genere dai tempi della rh 7.0 , ormai i
problemi sono o la scheda o il driver , dubito si possa minimamante
sospettare del wm.
-- 
C'e' una via d'uscita da ogni gabbia.
                -- Capitano Christopher Pike, "The Menagerie" ("The Cage"),
                   data astrale ignota

 window-manager fanno la loro parte.
Mah... il WM non ha praticamente nessuna giurisdizione sul contenuto del 
rettangolo della finestra, è tutto X. Infatti puoi usare app X anche 
senza WM (ma spostarle sarà dura :-) )
I problemi di refresh possono essere dovuti al driver, alla 
configurazione (direct rendering, renderaccel), e al toolkit.
-- 
Renato
--------------------------------
Usi Fedora? Fai un salto da noi:
http://www.fedoraitalia.org

 Mah... il WM non ha praticamente nessuna giurisdizione sul contenuto del
]zac[
Non è una cosa assoluta, anche le wm possono mettere il naso negli eventi
paint/repaint.
Se poi consideriamo (correttamente) parte del wm qualsiasi cosa che non sia
in X (mi sembra naturale considerare per esempio le qt parte del wm di kde)
direi che diventa certo che anche il wm può dire la sua.

Aggiungo i risultati di miei esperimenti empirici fatti.
Configurazione del mio catorcio:
PIII 800 - 256 Mb - matrox (chip mga) G200 - ris. abituale 1280x1024 16bpp
Non ditemi che è troppo poco perchè con Win il trascinamento opaco è 
perfetto anche con un PII 233 - 32 Mb.
Una nota: ho provato il desktop manager Athene 
(
http://www.rocklyte.com/index.html
) che sostituisce anche X con un 
server prorpietario sia su win(PII 233) che su linux(PIII800) ed ha una 
fluidità impressionante, tenuto conto che gestisce anche le trasparenze. 
purtroppo è ancora un po' acerbo, anche se una volta avviato mi ha 
riconosciuto Gimp e Mozilla e notare che trascinando una finestra 
diversa sopra a quella di Gimp o Mozzilla e muovendola velocemente, la 
compattezza del contenuto delle finestre dei suddetti non veniva 
minimamente intaccata.
Altre prove:
 > KDE - xmms(che gestisce autonomamente il suo spostamento):
   Sposto la finestrella di xmms sulle altre e il contenuto è perfetto,
   sposto quasiasi altra finestra gestita da kwin e il contenuto
   ricompare quando smetto di muovere le finestre.
 > GNOME- xmms o gmplayer(il dock di comando) - metacity avviato
   Sposto xmms o gmplayer  sembrano "zavorrati" (arrivano dopo un po'
   dietro al puntatore e il contenuto delle finetre al passaggio scompare
   o con le traccie della finetra appena passata finchè non mi fermo, a
   quel punto, con calma, le finestre ridisegnano il loro contenuto.
   in questo caso anche il bordino aggiunto dal wm sulle finestre si
   sbianchetta per poi ritornare quando smetto di muovere le finestre.
 > diverse finestre GTK QT e Firefox (che credo i suoi le widget)
	- nessun wm avviato - xmms e gmplayer
   Appena uccido il wm, qualsiasi esso sia, le uniche due finestre che
   posso muovere in autonomia sono xmms e gmplayer (si il dock che lo
   schermo). Bene, tutto quello che c'è sotto, qualsiasi applicazione sia
   non risente minimamente del passaggio delle suddette, il contenuto
   rimane perfettamente compatto.
Note:
Quando è in esecuzione un wm con xmms e gmplayer se trascino il dock
di gmplayer in qualsiasi punto dello schermo, ma senza passare sopra a 
xmms, il contenuto di questultimo si congela finchè non mi fermo e 
viceversa se trascino xmms si blocca il video in gmplayer.
Se nessun wm è in esecuzione eseguendo la stessa prova il contenuto 
delle finestre non si congela.
Questa osservazione dovrebbe escludere X e portare in causa il modo in 
cui vengono gestite le finestre, quindi il wm.
Ora uso una slackware, ma questo comportamento l'ho nontato su una 
miriade di macchine e di distro, anche su un Mac con una Debian 
installata sopra.
Ciao regaz.


		ciao e grazie, rz
-- 
http://mrzac.altervista.org