Sistema grafico Linux

[Tadde]

Siccome la scelta server-client non è la più efficiente per un uso desktop, mi chiedevo se esistessero progetti differenti da XFree86 per Linux.
Ne sapete qualcosa?

[Ikitt_Claw]

Originally posted by "Tadde"

Siccome la scelta server-client non è la più efficiente per un uso desktop,

Ma siamo comunque nel range di accettabilita`, e come bonus c'e` la facilita` di integrazione e di espansione sul fronte reti/server

mi chiedevo se esistessero progetti differenti da XFree86 per Linux.
Ne sapete qualcosa?

Ci sono un po` di tentativi, ma quando va bene stanno in planning stage.
Si parlava di berlin tempo fa, non so come sia andata avanti la vcosa.

Poi ci sono un po` di port di GTK/QT su framebuffer.

[Tadde]

Originally posted by "Ikitt_Claw"



Ma siamo comunque nel range di accettabilita`, e come bonus c'e` la facilita` di integrazione e di espansione sul fronte reti/server

Penso anch'io che sia tutto accettabile coi pc moderni (d'altronde se devono fare da "desktop" non saranno proprio ciofeche in generale).
Solo che mi dispiace leggere di tante features di KDE (ad es.) e di altrettante persone che consigliano di disattivarle per migliorare "i tempi di risposta" su molti pc ancora in circolazione.
Insomma credo che il mondo Linux non si dovrebbe mai "accontentare", dato che ha come avversario il mondo closed.

[ilsensine]

Originally posted by "Tadde"

Siccome la scelta server-client non è la più efficiente per un uso desktop

...infatti XFree usa tecniche diverse (non client-server) sul computer locale.
Come detto altre volte, una eventuale lentezza non è colpa di XFree, ma dei window manager/toolkit che usi.

[Pang]

Potresti spiegarci perchè xfree86 non sarebbe adatto ad un uso desktop, sono curioso.

Ciao

[HollowMan]

Originally posted by "ilsensine"


...infatti XFree usa tecniche diverse (non client-server) sul computer locale.

Mi sono perso qualcosa ultimamente ? quali sono queste tecniche ?

[jappilas]

ma.. in effetti... per quello che ho visto su basi generiche di GUI varie (gdi, X ecc) sembrerebbe che il concetto client server ha un suo senso ...

infatti , se si vuole avere che : le applicazioni non debbano gestire loro direttamente tutto il redraw delle finestre delle icone ecc , e quindi si appoggino a uno "strato" che astragga queste funzioni e le renda disponibili come funzioni ...
un server è la soluzione che se concepita decentemente offre la maggiore generalizzazione e versatilità crea la schermata partendo dal contenuto delle finestre, toolbar ecc , menrte il modulo client che può essere interno od esterno si occupa della visualizzazione e interazione via mouse e tastiera...

ora... 2 processi nel sistema ci dovrebbero essere comunque... l pesantezza non è intrinsica del concetto di server ma dell' implementazione (window manager , driver ecc)

l' alternativa al server quale sarebbe ? una libreria di accesso diretto al' hardware? secondo me in ogni caso bisognerebbe riprogettare del tutto le applicazioni con GUI
e mi pare di notare che nel mondo linux per tante applicaziuoni è già tanto avere delle gui figurati se gli sviluppatori buttano via quello che si sa su X già ampiamente diffuso e colludato da decenni per qualcosa di radicalmente nuovo... una cosa così magari andrebbe per applicazioni specifiche, embedded o giochi ma per cose generiche no

[Black imp]

Originally posted by "HollowMan"



Mi sono perso qualcosa ultimamente ? quali sono queste tecniche ?

mi associo alla domanda. puoi darci almeno dei link ?

a me onestamente la struttura grafica di linux col server X e il kde sopra non piace una mazza. è troppo pesante. bellissima per il controllo remoto ma se vogliamo cominciare a parlare di performance in ambito grafico... basta sta roba!

[AnonimoVeneziano]

Mha, non riesco a capire dove vediate il rallentamento, per me è solo un fattore psicologico , per quanto mi riguarda a me scheggia tutto alla perfezione .

Penso che una delle tecnologie alle quali accennava ilsensine fossero tipo la XAA (XFree86 Accelleration Architecture ) . Poi X integra diverse tecnologie quali DGA , Xv e anke DRI stesso intese proprio a bypassare il Protocollo X11 che effettivamente per certe applicazioni si rivelerebbe troppo lento , ma in locale per le finestre proprio no.

Poi ormai X è uno standard, tutte le librerie sono scritte per X , e i programmi sono scritti per usare quelle librerie, un cambiamento di standard provocherebbe un obbligo di riscrittura di tutte le librerie grafiche , e poi probabilmente anke dei vari programmi che fanno uso delle librerie stesse , un lavoro troppo grande e impensabile .

Ciao

PS= COmunque devo ammettere che sono di parte, perchè X è un componente che mi ha sempre affascinato, e sarebbe una grande perdita sostituirlo , e inoltre la sostituzione con qualcosa di Embedded porterebbe a un integrazione tra interfaccia grafica e kernel , e se l'interfaccia si dovesse inchiodare probabilmente anke il kernel si inchioderebbe . Per non parlare della impossibile varietà che otterremmo. Oggi abbiamo KDE , GNOME , Wmaker, XFCE..... domani avremo interfacce grafiche stand-alone , che comprenderanno tutto, questo provocherà che le librerie scritte per uno non è detto che funzioneranno per l'altra, e il programma X scritto per uno non è detto che funzionerà con l'altro, e inoltre ci vorranno drivers diversi per ogni interfaccia.......

[Ikitt_Claw]

Originally posted by "Black imp"


mi associo alla domanda. puoi darci almeno dei link ?

link no, qualche keyword tipo
dri, dga, xv (sull'ultima non sono sicurissimo) si.

XFree86 e` _molto_ meno "lento & brutto" di come lo si dipinge.

[/quote]
a me onestamente la struttura grafica di linux col server X e il kde sopra non piace una mazza. è troppo pesante. bellissima per il controllo remoto ma se vogliamo cominciare a parlare di performance in ambito grafico... basta sta roba! [/quote]

Hai qualche dato, rilevazione o confronto o si va ad impressioni?
Perche` la mia, di impressione, e` che un kernel preempt+Xfree4 tenga ormai benissimo il confronto con windows, quanto a reattivita` e prestazioni pure.

[ilsensine]

Originally posted by "AnonimoVeneziano"


Penso che una delle tecnologie alle quali accennava ilsensine fossero tipo la XAA (XFree86 Accelleration Architecture ) . Poi X integra diverse tecnologie quali DGA , Xv e anke DRI stesso intese proprio a bypassare il Protocollo X11 che effettivamente per certe applicazioni si rivelerebbe troppo lento , ma in locale per le finestre proprio no.

Aggiungo la tecnica più "comune", la XShm (shared memory): in sintesi, le informazioni vengono passate dal client al server scrivendo direttamente su una zona di memoria condivisa con xfree, senza passare per i socket.
La Xv è molto utilizzata per scrivere direttamente sulla memoria video (ad es. i player video usano questa tecnica).
Queste implementazioni sono molto veloci, tanto che uso un "server" X relativamente completo sul mio iPaq aziendale, e con IceWM ottengo ottime prestazioni.

[HollowMan]

Originally posted by "ilsensine"


Aggiungo la tecnica più "comune", la XShm (shared memory): in sintesi, le informazioni vengono passate dal client al server scrivendo direttamente su una zona di memoria condivisa con xfree, senza passare per i socket.

Ah, ma allora lo vedi che una struttura client-server c'è sempre .... non importa il mezzo di comunicazione ... sempre client-server è
Conosco anch'io queste implementazioni, ma quando ti ho visto scrivere si tecniche non client-server ho pensato che fosse venuta fuori qualche versione di X "embedded" di cui mi ero perso notizia ...

[ilsensine]

Originally posted by "HollowMan"


Ah, ma allora lo vedi che una struttura client-server c'è sempre .... non importa il mezzo di comunicazione ... sempre client-server è

Se vuoi disegnare una immagine sullo schermo, non si scappa. O la passi al sistema tramite socket (protocollo X11), oppure tramite le API di windows, oppure tramite shm, in qualche maniera la dovrai pur passare no?
Il termine "server" si riferisce all'abilità di soddisfare richieste di client remoti, indipendentemente dalla loro collocazione all'interno della rete. Qualora non sfrutti questa caratteristica, ma ripieghi sulla shm, non usi la struttura "server" di xfree in quanto la shm esiste soltanto sul computer "locale".

Conosco anch'io queste implementazioni, ma quando ti ho visto scrivere si tecniche non client-server ho pensato che fosse venuta fuori qualche versione di X "embedded" di cui mi ero perso notizia ...

Esistono alcune implementazioni embedded a livello di toolkit (ad es. le Qt embedded), che ti fanno risparmiare qualche ciclo di clock, ma non mi piacciono in quanto impediscono l'utilizzo di applicazioni scritte con altri toolkit.

[HollowMan]

Originally posted by "ilsensine"


Se vuoi disegnare una immagine sullo schermo, non si scappa. O la passi al sistema tramite socket (protocollo X11), oppure tramite le API di windows, oppure tramite shm, in qualche maniera la dovrai pur passare no?
Il termine "server" si riferisce all'abilità di soddisfare richieste di client remoti, indipendentemente dalla loro collocazione all'interno della rete. Qualora non sfrutti questa caratteristica, ma ripieghi sulla shm, non usi la struttura "server" di xfree in quanto la shm esiste soltanto sul computer "locale".

Ho il sospetto che io e te diamo al termine server un'interpretazione leggermente diversa ....
io sono sempre stato abituato a definire "server" un qualsiasi processo in attesa di comandi da un altro processo definito "client" ... a prescindere dalla locazione dei due processi e dal fatto che la comunicazione avvenga attraverso socket o pipe o memoria condivisa.
Ma questo penso sia dovuto al fatto che per me client-server è un concetto prima che un'implementazione

Originally posted by "ilsensine"


Esistono alcune implementazioni embedded a livello di toolkit (ad es. le Qt embedded), che ti fanno risparmiare qualche ciclo di clock, ma non mi piacciono in quanto impediscono l'utilizzo di applicazioni scritte con altri toolkit.

Queste implementazioni sono molto utili nel caso di apparecchi tipo i palmari, che hanno un parco software dedicato (anche free)
Mi è capitato di incontrare in treno un signore che aveva uno Sharp Zaurus (che purtroppo al momento non è importato in Italia) ... l'interfaccia di sto gioiellino è realizzata proprio in qt embedded ... non l'ho potuto provare ma l'impressione visiva è stata molto positiva.

[ilsensine]

Originally posted by "HollowMan"


Ho il sospetto che io e te diamo al termine server un'interpretazione leggermente diversa ....

Ok allora nella tua asserzione anche il sistema grafico di Windows ha una struttura client-server

Queste implementazioni sono molto utili nel caso di apparecchi tipo i palmari, che hanno un parco software dedicato (anche free)
Mi è capitato di incontrare in treno un signore che aveva uno Sharp Zaurus (che purtroppo al momento non è importato in Italia) ... l'interfaccia di sto gioiellino è realizzata proprio in qt embedded ... non l'ho potuto provare ma l'impressione visiva è stata molto positiva.

Certo, poi arriva il sottoscritto di turno, che deve programmare dei palmari, ma che non usando né volendo usare le Qt, rimane fregato
Fidati, X+wm funziona egregiamente anche sui palmari

[HollowMan]

Originally posted by "ilsensine"


Ok allora nella tua asserzione anche il sistema grafico di Windows ha una struttura client-server

ma Windows non ha il sottosistema grafico integrato nel kernel ?

Originally posted by "ilsensine"


Certo, poi arriva il sottoscritto di turno, che deve programmare dei palmari, ma che non usando né volendo usare le Qt, rimane fregato
Fidati, X+wm funziona egregiamente anche sui palmari

Si lo so che funziona egregiamente, dicevo solo che anche le qt non sono male come toolkit, e lo dico da utente gnome

[ilsensine]

Originally posted by "HollowMan"


ma Windows non ha il sottosistema grafico integrato nel kernel ?

...e perché, il kernel non è un "programma"?

[HollowMan]

Originally posted by "ilsensine"


...e perché, il kernel non è un "programma"?

Si, ma il kernel a runtime è un singolo processo che ingloba il sottosistema grafico ...

[ilsensine]

Originally posted by "HollowMan"


Si, ma il kernel a runtime è un singolo processo che ingloba il sottosistema grafico ...

?
XFree a runtime è un singolo processo che ingloba il sottosistema grafico

[HollowMan]

Si, ma se lo fai partire da solo (intendo l'eseguibile /usr/X11/bin/X che è appunto il server grafico) ti da una bella schermata grigia e un cursore a forma di X ... nient'altro ... se vuoi fagli disegnare qualcosa (da locale o da remoto che sia) devi usare, o meglio eseguire, un client come ad esempio un window manager.

Nel kernel di windows queste due classi di operazioni sono appannaggio dello stesso processo.

Quello che voglio dire è che il sottosistema grafico di windows è un singolo processo tutto incluso nel kernel, mentre il sottosistema grafico di linux è composto da diversi processi e prova ne è che li puoi eseguire separatamente, mentre il kernel di windows è un monoblocco