Come mai le icone vettoriali di Haiku sono così piccole? Potreste aspettarvi chissà quale grande soluzione, ma attualmente HVIF (il nuovo formato delle icone vettoriali di Haiku) è abbastanza semplice. Quando vi dirò tutti i “segreti”, al massimo vi uscirà un “doh!” (l’ esclamazione di Homer Simpson). La cosa più importante è che il formato è ottimizzato per le icone. Una volta che assumete questo semplice presupposto e ci riflettete, troverete ogni sorta di soluzione per ridurre lo spazio di memorizzazione.

Coordinate

Ad esempio, ho deciso che le icone dovrebbero avere una risoluzione nativa di 64 per 64 pixel. Per ottenere icone vivaci, è bene spingere le coordinate del percorso del vettore ai pixel di numero intero. Ho pensato che non fosse una cattiva idea poter avere punti anche al di fuori dell’icona, così ho definito una gamma di -32 a +95 delle coordinate valide di numero intero – e ciò occupa solo 7 bits. Se una coordinata non è su un pixel di numero intero, o cade fuori della gamma -32 +95,sto utilizzando l’ottavo bit per indicare una coordinata di 2 byte, con cui può essere espressa una gamma molto più ampia. In questo caso, la gamma è estesa a -128 – +192 e la precisione supplementare è usata per codificare anche le coordinate non intere.

Percorsi

inoltre mi sono reso conto che conviene ottimizzare per le forme comuni dei percorsi del vettore. HVIF distingue tre tipi di base: percorso con comandi, percorso con le linee rette soltanto e percorso con le curve soltanto. Un percorso con tutte curve poteva rappresentare le altre due forma di percorsi, ma occuperebbe la gran parte dello spazio di memorizzazione, perché sei coordinate devono essere immagazzinate per ogni segmento del percorso. Se un percorso consiste di molti segmenti diritti, o persino di molte linee orizzontali e verticali, è meglio associare i comandi con i segmenti, che riducono notevolmente il numero di coordinate che devono essere immagazzinate per il segmento. Il formato SVG definisce di più, ma ho trovato che quattro differenti comandi di percorso sono tutto ciò che è necessario per le icone. I primi due necessitano solo di una coordinata per essere codificati (X o Y), poiché l’altra rimane la stessa per quanto riguarda il punto precedente. Le linee richiedono due coordinate e le curve sei. I quattro comandi possono essere codificati in 2 bits, e rendere le cose meno complesse. Ho deciso di scriverli separati dai dati delle coordinate, un byte che codifica fino a quattro comandi. Così un semplice rettangolo allineato ai pixel di numero intero ha bisogno di questo spazio di memorizzazione:

* 1 byte per dire quanti punti ci sono dal percorso (4)
* 1 byte per i quattro comandi di percorso (2 bits potrebbero rimanere inutilizzati, ma c’è un comando (linea) codificato comunque per il primo punto)
* 5 bytes per le coordinate (2 bytes per il primo punto, 3 bytes per gli altri)

L’implementazione HVIF analizza quale delle tre codifiche del percorso di base occuperebbe la minor quantità di spazio di memorizzazione. Così se un percorso è principalmente costituito di curve, o comunque di tutte linee rette, non deve immagazzinare una sezione comandi.

Flags

La maggior parte degli oggetti dell’icona sono codificati con un byte riservato per “flags”, che specifica quali aspetti devono essere memorizzati nel file. Ad esempio, se una figura non è trasformata in nessun modo, nessuna tabella di trasformazione è immagazzinata per esso. Così “etichette vuote” per cose non utilizzate vengono in gran parte evitate.

Matrici

Parlando delle matrici di trasformazione, queste possono prendere abbastanza spazio se non viene presa nessuna precauzione particolare. HVIF affina normalmente le matrici per le trasformazioni, che normalmente vengono codificate usando 6 double (48 bytes) o float se non vi interessa molto la precisione (24 bytes). Per ridurre ulteriormente le esigenze di memoria (poiché la precisione non è necessaria per le icone), HVIF usa il proprio floating point format che usa solo 3 bytes per valore, e così siamo scesi a 18 bytes per matrice. Molte volte, una figura viene soltanto tradotta, non viene ruotata, inclinata o ridimensionata. In quel caso, memorizziamo soltanto la traduzione usando per le coordinate lo stesso formato usato per i punti del percorso.

Stili

Ci sono due tipi di stile: colore pieno e sfumatura di colore. La sezione stile può occupare uno spazio significativo, così vengono prese un certo numero di misure per ridurlo. Un colore o una sfumatura che non usa alcun alpha non viene inserita,e i grigi vengono inseriti solo con un byte. Quale tipo di codifica per i colori viene usata è determinato di nuovo dai byte flags byte per ogni stile dato. Inoltre c’è un tipo speciale di sfumatura per ogni per sfumature con soli due colori, uno al 0% e uno 100% offset (un tipo molto comune di sfumatura). Qui, la compensazione ( offset ) dei colori non viene codificata.

I dati HVIF consistono di tre sezioni. Il primo codifica tutti gli stili, il secondo tutti i percorsi e l’ultimo tutte le figure. Gli stili ed i percorsi sono globali per un’icona Haiku, così possono essere riutilizzati da differenti figure. Non ci possono essere più di 256 stili o 256 percorsi in totale. Così le figure possono riferirsi a loro di nuovo solo con un byte, che rappresenta l’indice degli stili e dei percorsi nella lista globale. Le figure possono contenere trasformazioni, ad esempio un tratto trasformato può convertire un percorso in un profilo. Comunque non è stato inventato nulla di speciale per memorizzare i trasformatori.

Come potete vedere, davvero non vorreste usare HVIF per memorizzare generici vettori grafici. È realmente una soluzione adatta solo ad una particolare operazione. Ma come già detto, risulterà favorevole, alla fine in termini di responsività del desktop. Ciò comunque non accadrà automaticamente. Se le icone vengono progettate senza la conoscenza di come funziona HVIF, gran parte del potenziale è sprecato. Ad esempio, se i punti dei percorsi del vettore non sono agganciati a pixel interi o i percorsi non vengono riutilizzati come dovrebbero, allora un icona può occupare più spazio di quanto dovrebbe. Ciò è particolarmente vero se un’icona SVG è importata con Icon-O-Matic e semplicemente salvata in HVIF così com’è. Questa non è una buona idea. Resta un certo lavoro per rimuovere dall’icona le informazioni ridondanti o inutili, ma io spero che con le informazioni che vi ho appena fornito, ognuno trarrà vantaggio dai trucchi di ottimizzazione quando creerà icone per Haiku.

Stephan Aßmus (a.k.a. Stippi)

- traduzione di Giuseppe Gargaro dal documento originale: http://www.haiku-os.org/articles/2006-11-13_why_haiku_vector_icons_are_so_small