Numero 11 di Michael J. Hammel traduzione di Antonio Cartelli


Predisponete pure il vostro browser alla dimensione desiderata.
La Musa è stata predisposta per adattarsi allo spazio disponibile!



Barra dei Bottoni Musa: 
  1. v; per farsi assalire dai pensieri 
  2. n; [ fr. Una delle nove sorelle, dee delle scienze e delle arti nella mitologia greca ]: sorgente di ispirazione 
 Benvenuti dalla Musa della Grafica! Perché una "musa"? Al di là dell'aspetto delle sorelle, le precedenti definizioni sono la maniera migliore di descrivere il mio interesse nella Computer Graphica: questa disciplina mi fa sprofondare nelle mie riflessioni ed è una sorgente giornaliera di ispirazione. 

[ Novità nella Grafica ] [ Meraviglie del Web ] [ Riflessioni ] [ Risorse ]

Questo spazio è dedicato all'uso, alla creazione, alla distribuzione ed alla discussione di pacchetti per la Computer Grafica su sistemi Linux.
 
      Per questo mese non ho molto da dire, sono stato molto impegnato a causa di alcuni lavori per il Linux Journal oltre che per diversi altri progetti che mi sono ritrovato per le mani. Ho fatto tutto quanto era in mio potere per cercare di mantenere fede a quanto avevo promesso di fare il mese scorso e sono veramente soddisfatto: sono riuscito a portare a termine due cose su tre. È molto più di quanto non sia in grado di fare normalmente.

      Nel numero di questo mese mi occuperò dei seguenti argomenti:


 
La Musa della Grafica
     Avvertenza: Prima di addentrarmi eccessivamente nell'argomento devo far rilevare che ogni nuova informazione che inserisco in questa sezione ha solo ed essenzialmente un significato: quello di segnalazione di una novità. Ho avuto l'opportunità di venirne a conoscenza mediante alcune mailing-list cui sono iscritto, via gruppi di news Usenet, o infine, mediante messaggi inviatimi da lettori e curiosi. Certamente non garantisco questi prodotti (alcuni dei quali possono essere commerciali), faccio soltanto presente che ne ho sentito parlare il mese scorso.
 
indent

XFPovray 1.3

Robert Mallozzi ha annunciato l'uscita di una nuova versione (la 1.3) della sua interfaccia XForms per il programma POV-Ray di rappresentazione. Tutti coloro che hanno utilizzato almeno una volta il POV-Ray dalla riga di comando troveranno questo programma molto utile. Si veda:

   http://cspar.uah.edu/~mallozzir/ 

Il codice sorgente è disponibile nei formati tgz, bzip2 ed rpm.

Robert S. Mallozzi 
Università dell'Alabama 
http://cspar.uah.edu/~mallozzir/

indent

XMRM 2.0 (versione Alpha)

L'istituto austriaco per la computer grafica, presso la Vienna University of Technology (Università tecnologica di Vienna) ha annunciato il rilascio della versione alfa di XMRM 2.0.

XMRM (programma di morphing multi risoluzione in ambiente X) è un programma di morphing di immagini scritto per l'ambiente XWindow. Una caratteristica specifica di questo programma, che non si ritrova in nessun altro programma di morphing, concerne la sua capacità di controllare la velocità di morphing dei dettagli rispetto alla velocità di morphing dei tratti di grandi dimensioni.

Si veda la home page di XMRM: 
http://www.cg.tuwien.ac.at/research/ca/mrm/ 

Per vedere qualche GIF animato si vada al manuale on-line:
http://www.cg.tuwien.ac.at/~xmrm/ 

Per scaricare il software si vada al sito:
ftp://ftp.cg.tuwien.ac.at/pub/linux/xmrm/ 

Per inviare saluti, e-mail o messaggi al Team XMRM si scriva a <xmrm@cg.tuwien.ac.at
 

FREETYPE 1.0


Il generatore di Font True Type FREE (aperto)

Copyright (C) 1996-1998 Il Team per lo sviluppo di FreeType 

Il sistema di sviluppo FreeType è un pacchetto per la rappresentazione di font TrueType gratuito e trasportabile da piattaforma a piattaforma, disponibile in codice sorgente ANSI C e Pascal. Esso è stato sviluppato per fornire il supporto di font TrueType ad una grande varietà di piattaforme ed ambienti.
 
Si noti che FreeType è una libreria non un sistema per la generazione di font per il proprio ambiente di lavoro preferito, anche se è stato progettato per costituire il punto di partenza di molte librerie, di pacchetti e di sever generatori di font, tutti di alto livello.

Si tratta di un'implementazione asettica che non ha nulla a che vedere con l'originario sistema di sviluppo TrueType messo a punto da Apple e Microsoft, anche se di quest'ultimo condivide la stessa qualità di rappresentazione. Per quanto ne so è l'unico sistema di sviluppo TrueType completo accessibile senza dover pagare alcun diritto.

Per avere maggiori informazioni si visiti il sito web Freetype all'indirizzo:
http://www.physiol.med.tu-muenchen.de  
/~robert/freetype.html 
 

E questo è quanto, poiché non ci sono altri annunci questo mese. Ne avevo qualcun altro ma li ho persi tutti nel momento in cui ho cercato di trasportarli nel mio programma XPostitPlus. È vero che è la prima volta che è collassato in questo modo ma, nel contempo, ho perso tutti i dati. È stata un'esperienza deprecabile.
 

Lo sapevate?

... che c'è un programmino OpenGL per GTK? Si dia un'occhiata all'indirizzo: ftp://ftp.gimp.org/pub/gtk/contrib/glgtk-demo.971104.tgz.

Domande e Risposte

D:   Come si può utilizzare l'anti-aliasing con POV-Ray?  Valori molto alti delle grandezze possono causare un anti-aliasing maggiore?

R:   Ron Parker ad una domanda analoga ha risposto così sulla lista dell'IRTC-L:  Allorché POV-Ray rileva una variazione significativa, diciamo una soglia, nel passaggio dal colore di un punto a quello di uno vicino, provvede a calcolare il colore dei pixel compresi tra i due lanciando più raggi all'interno dello scenario, anziché lanciarne uno solo per arrivare a determinare il colore. Maggiore il valore di "+A" (comunque compreso tra 0 e 1), maggiore sarà il numero di raggi che verranno lanciati sulla scena, minore sarà l'esigenza di avere una differenza di colore tra un pixel ed il successivo perché venga richiesta l'azione di anti-aliasing. L'anti-aliasing viene lanciato quando viene raggiunto il valore di soglia tra due pixel. Il numero di raggi emessi è controllato da +R, e lo "spread" (diffusione) è controllato da +J. Se si predispone +A0.1 l'anti-aliasing viene lanciato per differenze di colore inferiori rispetto a quanto accade con +A0.3, ne consegue che l'anti-aliasing viene applicato molto più che non per alti valori di +A.  Tutto ciò è comunque relativo a +AM=1. Nel caso di supercampionamento adattativo (+AM=2) le cose vanno in maniera completamente diversa.

Per ulteriori e più approfondite informazioni si veda la sezione 6.2.5.4 della documentazione di POV-Ray.

Ron Parker * parkerr@mail.fwi.com * http://www2.fwi.com/~parkerr

D:   Oggi ho inviato un'immagine alla stampante e questa mi ha chiesto di inviare nuovamente l'immagine dopo aver incrementato la risoluzione da 72 pixel/pollice a 300 pixel/pollice. Con il GIMP non so dove mettere le mani. È possibile avere qualche suggerimento?

R:   Innanzitutto si può ridimensionare l'immagine, anche se in questo modo si ha una diminuzione della qualità dell'immagine stessa. La maniera migliore di cominciare a lavorare con immagini che si prevede di dover stampare è crearle utilizzando la giusta risoluzione. A titolo di esempio se si vuole un'immagine di 8.5" per 11" con una risoluzione di 300 pixel/pollice, si proceda settando le seguenti dimensioni:

All'avvio si avrà così una finestra di lavoro di 2550x3300 pixel dalla quale si potrà operare direttamente sull'immagine. Si tenga comunque presente che elaborazioni di immagini di questo tipo (di dimensioni così elevate) si effettuano con meno problemi se si dispone di:
  1. CPU molto veloci
  2. quantità considerevoli di memoria centrale
  3. volumi non indifferenti di spazio disco
In definitiva, alla domanda "posso effettuare una conversione della mia immagine originaria da 72 a 300 pixel"? La risposta è: SI, basta utilizzare l'opzione di riduzione (image->scale) e predisporre la grandezza corretta. Si ricordi però che gli ingrandimenti ridurranno la qualità dell'immagine soprattutto se si passerà da 72dpi a 300dpi.
 

L'angolo della posta

Un lettore rimasto anonimo ha inviato le seguenti informazioni: 'Musa:  Effettivamente devo aggiornare le pagine di LGH e UGU. Ad ogni modo se qualche lettore volesse provare questi script mi farebbe cosa gradita se mi facesse sapere cosa ne pensa. Anche se posseggo una lan sicuramente non ho un sistema multiprocessore e quand'anche l'avessi, ora non ho il tempo di testare questi script.

Syd Logan, Senior Software Engineer (Ingegnere Software anziano) della NetManage Inc., ha scritto:

'Musa:  Grazie per le osservazioni. Lavorando con XI Graphics ho avuto modo di leggere le specifiche XIE e mi sono meravigliato del fatto che il pacchetto non fosse molto utilizzato. Forse ci troviamo davanti ad un caso analogo a quello del sistema a finestre X - c'è soltanto bisogno di un mercato che conduca al suo utilizzo. Penso che la popolarità che Linux potrà dare ad X Window rappresenti esattamente la forza propulsiva che occorre. Dobbiamo soltanto aspettare e vedere.

Thomas Vaughan ha scritto:

'Musa:  Di fatto non c'è alcun supporto gratuito, ma Xi Graphics ha annunciato, da pochissimo tempo, che per i server X accelerati che commercializza fornirà il supporto alla scheda Virge 3D. 'Musa:  Non è che l'idea del CGI mi piaccia molto, in primo luogo perché ritengo che appiccicare il driver per la grafica al nucleo di sistema non sia una gran bella idea, ma anche perché non voglio vedere l'interfaccia del desktop frammentata in tanti campi separati. L'interfaccia X sta pervenendo ad un suo livello di maturità nella gestione del desktop e mi piacerebbe continuare a vederla evolvere. 'Musa:  Una richiesta simile mi è venuta da Anand Rangarajan: 'Musa:  Molto bene! Penso proprio sia che sia giunto il momento di passare in rassegna i vari tipi di schede grafiche. Si dia un'occhiata all'articolo riportato appresso su Aggiornamento sui Server X.

Marc S. Jensen ha scritto sulla mailing list dell'utilizzatore GIMP:

'Musa:  Se si presuppone che lo scanner sia l'unica unità collegata alla scheda scsi basta scrivere:
ln -s /dev/sga /dev/scanner

e tutto andrà a posto. Se invece ci sono più unità collegate al bus scsi (re: cavo) occorrerà verificare quale delle unità /dev/sg[x] corrisponde allo scanner e collegare quella a /dev/scanner.

Anche Joel Becker ha scritto alla lista dell'utilizzatore GIMP.

'Musa:  Non sono in grado di dire nulla sulla tavoletta grafica ma, recentemente, mi è capitato di dover installare uno scanner: ho acquistato infatti una scheda SCSI Adaptec 2940 ed uno scanner UMAX 1200S. La scheda Adaptec è andata benissimo sulla mia scheda madre dotata di un Pentium 200 MMX senza dover effettuare alcuna configurazione dell'hardware. La distribuzione RH 4.2, che ancora utilizzo ha il modulo scsi richiesto preinstallato in /lib/modules (il nome del modulo è aic7xxx.o) per cui ho dovuto soltanto mandare in esecuzione insmod aic7xxx per vedere il tutto funzionare senza problemi.

Per quanto riguarda lo scanner l'ho scelto dalla lista degli scanner che ho passato in rassegna l'anno scorso nel mio articolo per la Linux Gazette Edizione Italiana ora riportato in La Musa della Grafica. In un primo momento ho provato il 610s, che funzionava però soltanto a toni di grigio per cui ho optato per il più caro (circa $250) 1200s. Funziona abbastanza bene con i driver della Umax: la qualità delle immagini è eccezionale. Ho addirittura provato a scannerizzare degli oggetti, come un doppino, dei cavi RG58 per thin-net, e la mia mano e devo dire che le scannerizzazioni sono andate abbastanza bene anche se sono venute un po' scure. È bastato però rendere più luminose le immagini con xv e con il GIMP e tutto è andato a posto.

In ogni caso non ho provato lo scanner ed i suoi driver con il SANE.

Marco Iannacone ha scritto:

'Musa:  Non c'è neanche da dirlo. 'Musa:  È possibile, anche se la differenza avrebbe dovuto ripercuotersi esclusivamente sulla velocità di aggiornamento dello schermo; di fatto il grosso del lavoro di elaborazione del GIMP viene effettuato prima di provvedere ad aggiornare lo schermo. 'Musa:  Forse è il caso di definire meglio il senso di "più lento": riferito a che cosa?  Nel caricare lo stesso file? Nel calcolare una nuova brillantezza o un contrasto? Quanto più lento?

Forse il suo amico si riferiva all'uso dei ricoprimenti (piastrellature), il cui aggiornamento nel GIMP sembra avvenire con una certa lentezza, mentre in Photoshop può darsi che appaiano tutti più o meno immediatamente (preciso che non ho mai utilizzato Photoshop per cui non so se ciò corrisponde a verità oppure no). Ne consegue che prima che io possa dire "il GIMP è più lento di Photoshop" devo poter sapere rispetto a che cosa sono state misurate le prestazioni dei due programmi.

'Musa:  È molto probabile che non siano state installate le librerie giuste per la gestione delle immagini. Si scarichi il pacchetto libgr e lo si installi, quindi si provi di nuovo. Probabilmente converrà compilare il GIMP a partire dai sorgenti, dopo aver provveduto ad installare le librerie presenti nel pacchetto libgr. In alternativa, se si è installato il GIMP a partire da uno dei kit in distribuzione (Red Hat, Debian, ecc) conviene verificare che si siano installate tutte le librerie grafiche che vengono fornite con la distribuzione stessa.

Tero Auvinen ha scritto:

'Musa:  Se il link che si trova nella pagina di Larry (la home page di BMRT) non funziona, non so veramente dov'è che si possa andare a cercare questo pacchetto. Si provi con il Renderman Repository: http://rmr.spinne.com/. 'Musa:  No, finora non c'è stata alcuna terza parte. Avrei voluto tanto realizzarla ma ritengo di non avere il livello di competenza richiesto per farlo e, nel contempo, mi trovo sempre più impelagato in una miriade di cose da fare. In effetti non ho più avuto l'opportunità, di tornare ad occuparmi di BMRT e rivisitarlo per approfondirlo. 'Musa:  Non esistono modelizzatori in ambiente Linux che esportano primitive RIB. Tutti quelli che conosco permettono di esportare esclusivamente poligoni. 'Musa:  Si può esser certi che non manderei in esecuzione MS su alcun tipo di macchina. Ma questa è una cosa che riguarda solo me. 'Musa:  credo che si sia procurato delle macchine di grosso calibro, probabilmente SGI o Sun. Sono sicuro che la Pixar gli procura tutto ciò che gli occorre. Su Linux dovrebbe utilizzare AC3D (così come faccio io). È un modellizzatore abbastanza buono anche se esporta ogni cosa esclusivamente sotto forma di poligoni. D'altro canto esso importa file 3DS e Lightwave. Questa caratteristica è piuttosto utile per poter accedere ai modelli riprodotti dai vari siti su cui li si può trovare e dai CD che attualmente sono disponibili. Per AC3D si veda: http://www.comp.lancs.ac.uk/computing/users/andy/ac3dlinux.html.

Marsel Osipov ha scritto:

'Musa:  Non ne avremo mai abbastanza di modellizzatori.
 




XeoMenu 1.1

Uno dei problemi che si incontrano nell'uso di pagine che utilizzano esclusivamente i costrutti di base dell'HTML è connesso alla difficoltà di modificare in maniera agevole i collegamenti proposti per facilitare la navigazione. Uno di questi collegamenti può essere un insieme di righe di testo con i relativi link, un insieme di immagini ciscuna con il proprio link oppure una mappa cliccabile che utilizza delle zone sensibili come collegamenti. Grazie all'utilizzo di questi collegamenti il lettore di una pagina web può muoversi facilmente all'interno di un sito e, qualora i collegamenti stessi siano realizzati in maniera appropriata, egli si ritrova ad operare su un vero e proprio ipertesto, essendo stata rimossa quella struttura gerarchica e lineare propria dei documenti a stampa.

L'aggiunta di collegamenti testuali è abbastanza facile da realizzare ed il loro aggiornamento richiede esclusivamente l'editazione della pagina HTML. Si dà il caso però che i link testuali siano piuttosto anonimi. Se si utilizza un'immagine in luogo di un collegamento testuale si ottiene un risultato sicuramente migliore anche se, al di là di quanto si può fare con JavaScript per realizzare lo scorrimento di un'immagine su un'altra, anche l'utilizzo di immagini fornisce uno scenario che è piuttosto statico. In effetti quello che manca è la possibilità di realizzare una vera e propria interfaccia d'utente. Non è che con le mappe cliccabili le cose vadano meglio in quanto anche in questo caso non si riesce a realizzare facilmente scorrimenti o variazioni ed alla fine l'effetto complessivo è forse anche più statico che con le immagini singole utilizzate come link.

Fortunatamente è anche per risolvere problemi come questi che è nato Java. Grazie a questo linguaggio, infatti, si possono realizzare interfacce d'utente molto più articolate e programmabili, in particolare è possibile realizzare le familiari interfacce a menu alle quali un lettore può essere abituato. Sebbene anche la soluzione di tali interfacce non rappresenti, com'è facilmente intuibile, quanto di meglio si possa realizzare, perfino rispetto alle stesse mappe cliccabili così statiche, per coerenza con quanto riportato nell'articolo assumeremo che i sistemi a menu siano comunque una buona cosa.

XeoMenu è un semplice programma Java realizzato da Patrick Chan della Xeo (www.xeo.com) che sovrappone un sistema a menu ad un'immagine all'interno di una pagina Web. Il programma viene eseguito come un applet ed utilizzato ponendolo all'interno del codice sorgente HTML. Chi lo desiderasse può scaricarne una copia dal sito http://java.sun.com:81/share/classes/menu/source/source.html. Nel pacchetto è compreso il codice sorgente Java, con un file di esempio in HTML, delle immagini di prova, un manuale d'utente (una sorta di manuale in una pagina HTML) ed il codice oggetto Java compilato. C'è anche una seconda versione del software, denominata horizMenu, che consente di realizzare dei menu che si aprono orizzontalmente anziché verticalmente. Poiché mi sembra di non riuscire a far funzionare il compilatore Java sul mio sistema RedHat 4.2 (né mediante il compilatore javac né mediante la mia versione di Vibe - ritengo che ci sia qualcosa che riguarda il mio percorso di ricerca delle classi CLASSPATH che non è settato correttamente) non sarò in grado di fornire, in questo articolo, alcun tipo di informazione sulla compilazione dei sorgenti. Qualora dovessi riuscire a far funzionare javac e/o Vibe prometto che comincerò a descrivere come si compilano programmi Java. Se qualcuno ha sentore di ciò che devo fare per far funzionare il complesso del sistema costituito da RH 4.2 e dal compilatore Java, mi farebbe cosa molto gradita se mi scrivesse qualche riga per mettermene al corrente.

Per utilizzare XeoMenu si deve innanzitutto creare un'immagine costituita da due parti: la parte che potremmo definire menu, che deve apparire così com'è allorché il mouse non viene a trovarsi sull'immagine ed un'altra parte contente l'immagine così come la si dovrebbe vedere allorché il mouse viene a trovarsi su diverse parti della figura originale. A titolo di esempio utilizzeremo l'immagine riportata di seguito:

L'immagine è divisa in due parti (all'incirca a metà). La metà di sinistra rappresenta l'immagine come viene vista quando il mouse non si trova su di essa. Questa immagine si può pensare suddivisa in due parti: una superiore (Linux) e l'altra inferiore (Gazette). La parte destra dell'immagine invece, sarà quella che si vedrà allorché il mouse passerà sulla parte sinistra. A titolo di esempio vediamo cosa succede allorché si fa passare il mouse sulla parola Linux all'interno dell'immagine: viene visualizzato il testo di colore blue, mentre chi osserva l'immagine usualmente vede il testo scritto con i caratteri di colore rosso (la metà sinistra dell'immagine).

A questo punto, per non annoiare i lettori che non godono del supporto per applicazioni Java, chi è interessato può passare alla sezione dell'articolo all'interno della quale viene illustrato come utilizzare l'applicazione Java e come si presenta il risultato allorché la si esegue. Per poter vedere la seconda parte dell'articolo si dovrà disporre di un browser Java compatibile.



Sommario

Quello presentato è soltanto un esempio brevissimo e semplicissimo. Lo stesso XeoMenu viene fornito con un esempio molto più sofisticato, anche se non c'è alcuna vera spiegazione (manualistica) di ciò che accade all'interno del programma. È auspicabile che grazie a questo esempio, al manuale d'utente ed a questo articolo, chiunque lo voglia possa essere messo in grado di realizzare qualcosa di utile con XeoMenu. La pagina principale degli applet sul sito Java.sun.com mostra un esempio della versione "orizzontale" di XeoMenu in esecuzione ed è veramente eccezionale. Sebbene l'interfaccia utilizzi un numero piuttosto grande di parametri opzionali ed il formato della descrizione dei menu non è proprio l'ideale, si tratta pur sempre di un pacchetto molto utile che richiede abbastanza poco per essere utilizzato al fine di ottenere un'interfaccia a menu molto accattivante per le proprie pagine web.


 
Musings
 
 
 
 

Aggiornamento sui server X

    Ho lavorato per questa rivista per oltre un anno ed ho scritto tanti articoli per il Linux Journal per un periodo più o meno uguale, ma in tutto questo lasso di tempo non mi sono mai occupato di uno degli argomenti più ovvi e banali connesso alla grafica in ambiente Linux: il server X. Il motivo fondamentale di una tale "dimenticanza" va ricercato soprattutto nel fatto che non dispongo delle risorse necessarie a testare una quantità accettabile di configurazioni di server. Se fossi pagato per farlo sarebbe, ovviamente, tutta un'altra storia, ma ci ò che scrivo vien fuori esclusivamente da quel po' di tempo e dalle risorse di sistema che riesco a racimolare mese dopo mese.

    Un motivo per decidermi a realizzare questo articolo mi è venuto dalle innumerevoli richieste di informazioni che ho ricevuto relativamente ai vari tipi di schede video 3D che vengono supportate da Linux ed a quelle tra esse che supportano ulteriori estensioni hardware quale l'X Input Extension (cui d'ora in poi ci riferiremo come X IE: estensione input X). La maggior parte delle domande che ricevo chiede specificatamente: "quali sono supportate da XFree86?" anche se alcuni lettori richiedono, più in generale, informazioni sia sul supporto gratuito che su quello commerciale.

    In virtù di tutte le considerazioni appena esposte ho deciso di inviare una richiesta di informazioni ai vari rivenditori per sapere come stavano attualmente le cose. L'e-mail che ho inviato era piuttosto generica ed è riportata di seguito:
 

È in grado di fornirmi informazioni che io possa riportare nei miei articoli, relativamente al supporto che attualmente siete in grado di fornire, o che avete pianificato, nei confronti dell'accelerazione grafica hardware 3D (in maniera più specifica connesso con openGL/Mesa, ma non esclusivamente)? Cosa mi potete dire sul supporto ad unità di input alternative mediante l'X IE? Il GIMP ed il suo pacchetto X Gtk, fanno entrambi uso dell'X IE, se disponibile, e prevedo che molti altri pacchetti si apprestino a fare altrettanto nell'immediato futuro.

Ho spedito questa richiesta di informazioni intorno al 12 di questo mese (Febbraio) alle seguenti società: Xi Graphics, Metro Link, SuSE ed ai responsabili del progetto XFree86. Tutti hanno risposto alla mia richiesta anche se per quanto riguarda la Metro Link devo dire che non hanno ricevuto la mia richiesta immediatamente per cui la loro risposta è arrivata troppo tardi per essere inserita in questo articolo. Riporterò quanto mi hanno riferito il mese prossimo. Un'annotazione a margine: questo articolo intende presentare un elenco dei server che supportano determinate caratteristiche/unità e non intende entrare nel merito del come utilizzare queste caratteristiche.

Le risposte sono state "modificate" per rimuovere quelli che sembravano puri e semplici commenti editoriali, ove facilmente riconoscibili. Per quanto mi riguarda intendo anch'io, allo stesso modo, astenermi dal fare "commenti editoriali" sulle risposte.

    La prima risposta, pressoché immediata, mi è venuta da Dirk H. Hohndel della SuSE, che mi ha inviato due risposte: una come Vice Presidente del Progetto XFree86 Inc. l'altra come capo progettista della S.u.S.E. GmbH. Dirk ricopre, infatti, in entrambe le strutture incarichi di responsabilità per cui ritengo che le sue risposte vadano considerate come risposte ufficiali di ciascuna delle organizzazioni. Entrambe le risposte sono andate dritte al nocciolo del problema. Vediamo prima quella relativa al progetto XFree86: 
 

Innanzitutto è opportuno notare che XSuSE e XFree86 sono pressoché identici. Nei limiti di quello che saranno i vincoli legali, tutto il lavoro fatto in ambiente XSuSE viene integrato nella versione XFree86 successiva. XFree86 di per sé stesso pone l'accento sul sistema X Window e sul supporto bidimensionale per i differenti tipi di schede. Sebbene allo stato attuale nessuno dei due progetti si stia occupando del supporto tridimensionale sono entrambi in contatto con diversi gruppi che stanno lavorando in quest'ambito.

Non sono il portavoce ufficiale della Metro Link ma posso dire che questa società ed XFree86 cooperano fattivamente nell'ambito della determinazione delle caratteristiche bidimensionali dei server. La Metro Link ha donato ultimamente enormi quantità di codice sorgente ad XFree86 e Metro Link ed XFree86 stanno cooperando su molteplici aspetti di progettazione dei futuri server X.
 

Siccome la risposta di Dirk è arrivata per prima e quelle degli altri fornitori riportavano informazioni più dettagliate, ho ritenuto opportuno offrire ad XFree86 la possibilità di fornire una risposta più ricca ed articolata, ho chiesto pertanto di fornire ragguagli e commenti sulle differenze architetturali e sulle relazioni tra XFree86 ed i prodotti commerciali. La risposta di Dirck è stata:
 
Perché dovrei annoiare Lei o qualcun altro con dettagli architetturali che non interessano nessuno?
 
Ha poi fatto seguire questa risposta data in nome di XFree86 con una risposta a nome di SuSE:
 
SuSE sta lavorando sul supporto all'hardware 3D anche se, al momento, non si prevede alcuna data per il rilascio di un prodotto commerciale.

I driver 2D elaborati da SuSE verranno integrati dell'XFRee86-4.0, nel frattempo stiamo cercando di risolvere qualche problema di carattere legale emerso da uno di questi (GLINT di 3DLabs), in quanto alcuni dei documenti erano redatti in NDA e non siamo ancora riusciti ad ottenere il permesso di rilasciare i sorgenti. In ogni caso ci stiamo lavorando. Tutti gli altri driver SuSE sono stati già inclusi in XFree86-3.3.2

Altre risposte sono venute da Xi Graphics. In particolare hanno risposto sia Thomas Roell, presidente di Xi Graphics e progettista tecnico dei loro server, che Jeremy Chatfield.

Thomas ha scritto: 
 

La nostra prossima generazione di server X fornirà il supporto a diverse unità di input aggiuntive per mezzo dell'X IE. L'estensione stessa è supportata fin dalla versione del server Accelerated-X 4.1. Le unità che si prevede di supportare sono, per lo più, quelle utilizzate come sistemi di input per il CAD, come tavolette, touchscreen e mouse tridimensionali. Alla stessa identica maniera si può essere certi che la prossima generazione di server supporterà anche hardware tridimensionale.

Jeremy Chatfield ha integrato quanto scritto da Thomas con la seguente missiva (parzialmente modificata per ridurne la lunghezza):
 

I server Accelerated-X 4.1 supportano l'X IE, mediante l'utilizzo di un numero piuttosto piccolo quanto predeterminato di periferiche, le cui unità vengono gestite in maniera piuttosto limitata. Future versioni dei server supporteranno un numero molto più ampio di unità.

Noi abbiamo fatto evolvere i nostri server Accelerated-X, per trarre vantaggio dall'accelerazione hardware 3D, fin dal lontano 1994. Esempi delle tecnologie introdotte e delle motivazioni che hanno indotto all'utilizzo del supporto 3D sono state le seguenti:

  • Allocazione della memoria e gestione dei buffer. La grafica 3D utilizza una gran quantità di memoria. La funzione standard malloc() (quella del 1994, quando abbiamo intrapreso quest'attività) non consentiva ai programmmi di liberare memoria, tendeva infatti a perdere del tutto la memoria quando questa veniva liberata e talvolta perfino quando veniva allocata, oltre a mostrare altri comportamenti piuttosto sgradevoli durante l'esecuzione di processi di lunga durata che utilizzavano parte di memoria temporanea e parte di memoria di lungo termine con una grande varietà di grandezze di dati. Noi utilizziamo cose come allocazione di buffer lazy (pigri), allocazione di buffer stencil (di riproduzione) solo quando estremamente necessario, ecc. Tutti questi accorgimenti consentono di incrementare la velocità e ridurre l'impatto sul sistema, visto sia in termini di grandezza totale del Server che di richiesta di paginazione della memoria.
 
- Continua all'inizio della colonna accanto -
Approfondimenti ...  
  • VRWave 0.9

  • --
    • Bloccaggio del coprocessore. Quando si utilizzano processori host, generatori grafici e generatori tridimensionali, tutti che scrivono nelle stesse aree di memoria, e allorché si utilizzano sia la memoria di sistema (via AGP) che la memoria della scheda grafica, è essenziale disporre di bloccaggio mutex veloce e corretto. Per altra via [senza utilizzare il bloccaggio] si potrebbero avere problemi quando tutti e tre i processori (o più) tentano di gestire la stessa area di memoria. Devo dire anche che abbiamo lavorato per anni ad affinare il nostro meccanismo di bloccagio mutex, sebbene, allo stato attuale, non sia visibile in alcun prodotto se non in multihead.
    • I/O asincrono. Quando i server X con alti livelli di accelerazione hardware gestiscono richieste di disegni bufferizzati l'input da tastiera e da mouse vengono posti in coda agli altri processi. L'effetto che si percepisce è quello di un rallentamento nelle risposte date dal server e di una gestione a sobbalzi dei dati provenienti da tastiera e mouse. L'accelerazione del mouse può essere pilotata in maniera inappropriata per cui diventa difficile controllare il suo movimento e può anche accadere che pressioni successive del tasto del mouse vengano interpretate in maniera errata come un doppio click. Al riguardo si è introdotto il meccanismo del "Velvet Mouse" per consentire l'input anche quando il server è impegnato in un pesante lavoro di rappresentazione grafica, come può essere il caso tipico di applicazioni dinamiche tridimensionali.
    • Sovrapposizioni. Molte applicazioni tridimensionali che operano su workstation sfruttano al massimo la presenza di possibilità di sovrapposizioni che a loro volta traggono grande beneficio dalla gestione della memoria e da altre variazioni architetturali presenti nei server X accelerati.
    Xi Graphics ha recentemente annunciato il supporto per la scheda ViRGE 3D da parte dei suoi server (si veda La Musa della Grafica di Febbraio 1998).

    Al di là di questi due fornitori esiste poi anche supporto hardware 3D per la libreria Mesa con il seguente hardware video:

    • 3Dfx Voodoo - Schede basate sul chip 3Dfx Voodoo (come la Diamond Monster 3D e la Orchid - Righteous 3D) che sono supportate sia in ambiente Linux che Windows 95. Per avere informazioni più aggiornate si veda questa pagina. Al momento risulta essere l'harware 3-D meglio supportato in ambiente Linux.
    • 3Dfx Voodoo Rush (rappresentazione all'interno di una finestra) - supportato in ambiente Windows. Per quanto riguarda Linux ci si sta lavorando.
    • Schede basate su GLINT - Per informazioni aggiornate si veda questa pagina.
    • Cirrus Mondello - Non è più supportata - chi fosse interessato a questo driver deve provvedere a scaricare Mesa 1.2.8.
    Quest'ultima informazione è stata presa direttamente dalla pagina web della Mesa. Per quanto mi riguarda ho volutamente ignorato ogni tipo di scheda per la quale Linux non è stato menzionato esplicitamente, esclusa la Cirrus Mondello, per la quale non sono in grado di dire se è per Linux o per Windows. In maniera del tutto analoga non so come Mesa possa far uso di questo hardware senza che, allo stato attuale, esso venga visto integralmente dal server X. Chi volesse saperne di più dovrà provvedere a scandagliare le pagine Mesa ed i loro link.

    A questo punto dovreste saperne almeno quanto ne so io a proposito di grafica 3D e supporto X IE da parte di XFree86/SuSE e Xi Graphics. In sintesi sembra che la maggior parte del lavoro in ambito 3D sia in fase di pianificazione e sviluppo, anche se nessuno si spinge a prevedere quando questo supporto (almeno nel caso di una reale diffusione del supporto 3D) sarà disponibile. Né XFree86/SuSE, né Xi hanno fatto esplicito riferimento ad alcuna scheda 3D supportata, anche se, come già detto Xi ha annunciato il supporto per Virge 3D proprio il mese scorso. Dalla Xi hanno anche detto che supporteranno l'X IE nei loro server X accelerati a partire dalla versione 4.1. Sebbene XFree86 non l'abbia detto, so per certo che l'X IE viene supportato alla stessa maniera dai loro prodotti. Si tenga presente che mi occuperò delle risposte della Metro Link alla comunicazione che le ho inviato il prossimo mese.

    Devo dire ancora, per correttezza e completezza, che in passato ho lavorato per Xi Graphics, quindi sia con Thomas che con Jeremy alla Dell Computer ed infine con Jeremy alla Information Foundation (una licenziataria di codice sorgente USL intorno al 1993 o giù di lì). In ogni caso ho fatto tutto quanto era in mio potere per rimuovere da questo articolo ciò che mi è parso un commento editoriale, sia che fosse mio che di coloro che mi hanno risposto.

    Informazioni utili per contatti

    XFree86: S.u.S.E.: Dirk ha precisato:  In entrambi i casi cerchiamo di mantenere aggiornate le pagine Web e nel caso di XFree86 abbiamo un servizio di FAQ on line che riportano indicazioni su come ovviare a ben noti problemi o l'esito di lavori in corso per rimediare ad eventuali errori.

    Xi Graphics:

    • Annunci: accelx-announce-request@xig.com cui ci si può iscrivere inviando il messaggio contenente la sola parola "subscribe"
    • Sito Web: http://www.xig.com
    • Mail list User-to-User:  accelx-users-request@xig.com cui ci si può iscrivere inviando il messaggio costituito dalla sola parola "subscribe"
    • Email:  sales@xig.com   - con risposta automatica, seguita dal messaggio di un operatore.
    • Telefono:  +1 800 946-7433 (US), +1 303 298-7478 (Int'l).
    • Fax:    +1 303 298-1406
    Jeremy ha aggiunto:  Ci preoccupiamo di tenere aggiornato il sito web.
     
     
     
    Risorse
    I riferimenti che seguono rappresentano esclusivamente il punto di partenza per l'acquisizione di ulteriori informazioni sulla computer grafica e, più in generale, sulla multimedialità, per sistemi Linux. Se disponete di informazioni specifiche su qualche applicazione e me ne mettete al corrente le aggiungerò alle mie pagine o, se lo preferite, potrete contattare qualche altro amministratore di siti web e prendere accordi con lui. Prenderò in considerazione la possibilità di aggiungere qualche altro riferimento di carattere generale qui di seguito, ma informazioni specifiche su applicazioni o siti troveranno sicuramente una migliore collocazione nei riferimenti di caratter generale riportati di seguito piuttosto che qui.
     
    mini-Howto della grafica su Linux
    Programmi utili per la grafica su Unix
    La pagina della Multimedialità per Linux

    Ecco alcune delle Liste di posta elettronica e dei Newsgroup che tengo sotto controllo e da cui traggo la maggior parte delle informazioni presentate in queste pagine:

    Le liste dell'utente Gimp e dello sviluppatore Gimp.
    La lista di discusione su IRTC-L
    comp.graphics.rendering.raytracing
    comp.graphics.rendering.renderman
    comp.graphics.api.opengl
    comp.os.linux.announce

    Sviluppi Futuri

    Per il prossimo mese: Buio totale.
    Devo innanzitutto saldare dei debiti (nel senso di pagarli) non più procrastinabili e che avrei già dovuto provvedere a saldare. E devo farlo al più presto.

    Fatemi sapere di cosa volete che mi occupi!


    Alla Home Page

    Per l'articolo originale: © 1998 Michael J. Hammel - Pubblicato sul n. 26 della Linux Gazette
    Per l'edizione italiana: © 1998 A. Cartelli - Pubblicato sul n. 3 anno II di LGEI a cura del LUGBari