Dietro le quinte di GNOME 3: Clutter

Tutti - o quasi - quelli che seguono lo sviluppo di GNOME sanno che la nuova interfaccia (Shell) introdotta nella versione 3 è basata sul toolkit grafico Clutter.

Quello che molti probabilmente non sanno è che il maintaner di Clutter è Emmanuele Bassi, un Italiano che lavora presso la Intel a Londra, per cui ho pensato che fosse interessante ed istruttivo fargli alcune domande sul progetto.

Ne è venuta fuori una conversazione piuttosto estesa e, in alcuni passaggi, abbastanza tecnica: tuttavia ho preferito evitare di riassumere e/o editare il testo proprio perchè ci permette di capire le origini, lo sviluppo e le prospettive future di questo toolkit, contribuendo inoltre a sfatare alcuni dei più diffusi pregiudizi.

Sono sicuro che arrivati in fondo, converrete con me che ne è valsa la pena!

Ciao Emmanuele,
parlaci di te, quale è stato il tuo percorso professionale e come sei arrivato a lavorare su Clutter?

Nel 2006 la mia allora ragazza (e ora moglie) doveva trasferirsi a  Londra per un master alla London School of Economics, e volendo seguirla, dovevo trovarmi un lavoro; avevo deciso di cercarne uno come sviluppatore, dopo un anno passato a fare il Junior System Administrator.

All'epoca ero già su Planet Gnome per il mio ruolo di co-maintainer delle Gnome Utilities, e ho scritto un post dicendo che ero alla ricerca di un posto in UK; qualche giorno dopo ho ricevuto un'email da Matthew Allum, il fondatore della OpenedHand, una piccola società di consulting nell'ecosistema di Gnome con clienti come la Nokia. Ho incontrato Matthew al FOSDEM, e a marzo di quell'anno ho firmato il contratto e ho iniziato a lavorare su quella che sarebbe diventata la seconda Internet tablet della Nokia, la N800.

Verso maggio, Matthew mi ha mostrato il codice di una piccola libreria che stava sviluppando per scrivere un media center che lavorasse anche su sistemi limitati. La libreria in questione era basata su OpenGL e  tentava di astrarre le complicazioni di quell'interfaccia con qualcosa di più appetibile: il nome che Matthew aveva scelto era "Clutter".

Per i primi tempi, ho lavorato su cose come pulizia del codice e delle API, e scrittura dei "binding" per poter usare Clutter in Python e Perl. Poi ho lavorato sul core, la scene graph, ovvero il modo in cui gli elementi si legano tra di loro, e quello in cui si determina quanto spazio richiedono e ottengono. Infine ho iniziato a fare le release, organizzare le roadmap per i cicli di sviluppo, e controllare Bugzilla per patch e contributi.

Dal 2008 sono stato praticamente identificato come il maintainer di Clutter, anche se non sono il solo a lavorare su questo progetto, specialmente per quanto riguarda la parte a basso livello.

Come spiegheresti cos'è Clutter in 20 parole?

Clutter è una libreria open source per realizzare interfacce utente interessanti, dinamiche e portabili.

Quali sono le origini del progetto?

Come ho accennato, Matthew ha scritto Clutter originariamente per imparare OpenGL e per scrivere un media center sfruttando l'accelerazione hardware della GPU invece della solita CPU; all'epoca, le GPU cominciavano a fare il loro ingresso nei sistemi embedded - sto parlando degli anni prima dell'iPhone - e Clutter era in investimento di ricerca e sviluppo per la OpenedHand.

Poi la Apple ha cambiato le regole del gioco; improvvisamente, tutti volevano uno smartphone con una GPU, e con un'interfaccia grafica in grado di sfruttarla; quindi, Clutter è diventato una grossa occasione per la OpenedHand di dimostrare di essere in prima linea nello sviluppo di nuove piattaforme.

Nokia voleva Clutter per quello che sarebbe diventato l'N900, e Intel voleva Clutter per l'UI della loro piattaforma, Moblin. Alla fine, Intel ha deciso di acquisire OpenedHand, e così siamo finiti tutti quanti a lavorare su Clutter e su Moblin, e abbiamo rilasciato Moblin Netbook UX. Poi si è complicata la situazione con MeeGo, Qt e quant'altro - ma quella, come si suol dire, è un'altra storia.

Per quali caratterstiche peculiari Clutter è stato scelto come base per sviluppare GNOME 3?

Durante lo sviluppo di Moblin 2.0 per Netbook, il team in Intel aveva bisogno di un window manager e di un compositor per sviluppare la shell integrata di Moblin. Come window manager in OpenedHand avevamo solo Matchbox, ovvero un window manager per sistemi embedded in cui le finestre erano automaticamente a tutto schermo. Ovviamente, questo non era sufficiente per un netbook; l'unico altro window manager e compositor disponibile era Metacity, il window manager di Gnome.

Il team di designer di Moblin voleva una shell che usasse animazioni fluide; il team hardware voleva una shell che usasse le risorse della GPU invece che la CPU (si parla di Atom, quindi evitare di usare la CPU per le animazioni era veramente un must); quindi il team di sviluppo della shell decise di scrivere un compositor che usasse Clutter per disegnare, animare e manipolare le finestre e l'interfaccia utente della shell: così nacque mutter (metacity-clutter)

Mentre rilasciavamo le prima beta di Moblin 2.0, gli sviluppatori di Gnome stavano lavorando sulla shell dopo la User Experience Hackfest di Boston nel 2008; usare Metacity e Clutter è sembrata immediatamente la scelta migliore: Metacity, come window manager, è sempre stato un progetto Gnome e Clutter è sempre stato sviluppato dal membri del progetto Gnome, con le stesse dipendenze e con lo stesso stile. Riscrivere qualcosa da capo era perfettamente possibile, ma avrebbe ritardato lo sviluppo iniziale in un progetto che già stentava nel nascere.

Come viene usato in GNOME 3?

Gnome 3 usa Clutter essenzialmente per la Shell, ovvero il componente che lega tutta quanta l'esperienza dell'utente con Gnome. Ogni finestra è un elemento della scene graph di Clutter, e ogni controllo della Shell (dai pulsanti ai menu, dalle notifiche al pannello in cima) sono elementi, o "actor", nel contenitore principale, o "stage".

Essendo tutto quanto gestito da Clutter, si ottengono due benefici: ogni elemento può essere animato facilmente, e tutto quanto è automaticamente accelerato dalla GPU.

Clutter viene usato sia implicitamente dal compositor per disegnare le finestre, che esplicitamente per gestire tutto il resto dell'interfaccia - e poiché Clutter è una libreria basata su GObject, è possibile usare i nuovi meccanismi di introspezione per scrivere buona parte della Shell in JavaScript invece che in C. Questo ha permesso tempi di sviluppo molto più rapidi.

"Pesante", "un mattone", "dal crash facile": in rete si legge un po' di tutto a proposito di mutter; ma cosa c'è di vero? e come stanno le  cose oggi?

Innanzitutto, mutter non è più pesante di metacity con il compositing attivato, in termini di memoria e di utilizzo della CPU; anzi, usando la GPU si ottiene un calo di utilizzo della CPU - e si salva energia.

Poi è vero: in passato mutter appariva più lento di Compiz, pur usando la stessa tecnologia (OpenGL); è saltato fuori che si trattava di un minuscolo bug che portava a eccessivi roundtrip con il server X11 e, una volta eliminato quello, mutter ha raggiunto Compiz in termini di performance.

Non esiste alcuna ragione, a parte bug nei driver in una delle estensioni che usiamo, per cui mutter sia più lento di Compiz; addirittura, dato che mutter usa Clutter, e Clutter ha un albero di ogni elemento sullo schermo che può essere usato per determinare cosa deve essere ridipinto e cosa invece può rimanere così com'è, gnome-shell dovrebbe essere più veloce di Compiz.

C'è un unico neo ancora da risolvere: Clutter usa il rateo di refresh dello schermo come un orologio per guidare le animazioni; questo ovviamente è la cosa giusta da fare per un'applicazione: nessuno dovrebbe ridisegnare quello che viene mostrato sullo schermo più spesso di quanto lo schermo non si aggiorni - si consuma la batteria, altrimenti.

Per un compositor è altrettanto valido, ma se le applicazioni non sono al corrente del fatto che il compositor funziona a 60 frame al secondo allora potrebbero trovarsi in una situazione in cui non riescono a tenere il passo oppure, peggio, non vengono ridisegnate per tempo e sembrano più lente di quanto non siano in realtà. Per correggere questo problema, che non è legato a Clutter o a mutter, ma alla sincronizzazione con il refresh rate del monitor, serve un sistema per dire ai toolkit usati dalle applicazioni che il compositor ha appena iniziato un frame, e quindi dovrebbero sincronizzare le loro operazioni al compositor invece che allo schermo.

Questo ovviamente è specialmente legato a come X11 funziona; in un ipotetico futuro in cui le finestre sono gestite da Wayland, è il server stesso ad essere legato al refresh rate del monitor, e a dire a tutte le applicazioni quando devono ridisegnare il loro contenuto. Tuttavia, fino a che Wayland non sarà disponibile, dovremo collaborare con i vari toolkit per avere questi meccanismi di sincronizzazione.

Un'altra critica ricorrente è l'obbligo di avere disponibile una scheda con accelerazione 3D hardware. Quali sono i requisiti hardware reali per far girare un'interfaccia (come GNOME Shell) basata su Clutter?

Rispondiamo subito a una domanda: l'accelerazione grafica è davvero necessaria? la risposta è ovviamente sì, se si vuole competere non tanto con Microsoft oppure con Apple - quello è banale - ma anche solo con Google sugli smartphone, o con i browser e il Web; ogni piattaforma usa accelerazione hardware, oggigiorno.

Pensare di creare una piattaforma di successo nel 2011 usando i requisiti di un computer di 10 anni fa è impostare la rotta verso FAIL-land, per usare un'espressione dei Dannati Giovani d'Oggi.

Poi, quali sono i reali requisiti per avere un'accelerazione grafica decente? ogni GPU integrata Intel successiva alla serie i8xx - ovvero qualunque GPU rilasciata negli ultimi 5 anni, eccezion fatta per Poulsbo (GMA500, con cui noi dell'Open Source Technology Center in Intel non abbiamo mai avuto niente a che fare, e per la quale non abbiamo colpe :-)). Per AMD (ATI): dalle r300 in su, quindi GPU rilasciate negli ultimi 8 anni circa. Per NVidia, penso qualunque scheda supportata da nouveau, e dal driver binario (ndG: Nouveau sulle schede più recenti - GF100 e superiori - ancora non funziona)

In pratica, sì: esistono bug nei driver. Girarci intorno richiede, comicamente e contro-intuitivamente, più risorse che non risolverli ma ovviamente le fix richiedono tempo per essere integrate nelle distribuzioni, e arrivare agli utenti.

Vorrei far presente, tuttavia, che da quando Gnome ha deciso di muoversi in direzione dell'accelerazione hardware, il supporto per OpenGL in Linux è migliorato esponenzialmente. Cinque anni fa l'unica opzione per avere un supporto decente per GL era NVidia e il driver binario (il driver ATI era decisamente buggato, e si rompeva ad ogni release - lo so perché avevo un portatile con scheda ATI all'epoca); adesso i driver open source sono un'alternativa valida e perfettamente competitiva - una cosa che non sarebbe mai successa se progetti come Clutter non fossero mai esistiti.

Quali sono i prossimi obiettivi (sia immediati, che più a lungo termine) del progetto?

L'obiettivo a medio termine è fare in modo che Clutter sia ancora più performante e facile da usare, mutuando tecniche dalle librarie per scrivere giochi - come composizione di ruoli invece che ereditarietà, e analisi della scena per comprimere le operazioni di disegno dell'interfaccia.

Più a lungo termine, il mio progetto principale è mettere Clutter a metà tra Cairo e GTK+, e fare in modo che le GTK+ 4.0 siano basate su Clutter; esattamente come CoreAnimation su iOS e OSX è alla base del toolkit per le applicazioni Apple, o come Silverlight su WP7 e Windows 8 per le applicazioni Microsoft, voglio vedere Clutter come base per le GTK+ e le applicazioni Gnome.

A quali altri altri progetti stai lavorando?

Lavoro sempre su GTK+ e su GLib, nel tempo libero; in generale, mi trovo a mio agio negli "strati bassi" della piattaforma Gnome. Ho anche un interesse particolare nel sistema di introspezione e nei binding per linguaggi ad alto livello. In più, mi piace pensare di poter dare una mano al design team di Gnome, dopo l'esperienza di Moblin, nella quale ho lavorato a stretto contatto con un design team davvero dotato.

Grazie Emmanuele, per la tua disponibilità e in bocca al lupo per i tuoi obiettivi!