Development

Tra gennaio 2022 e marzo 2026, Ansel ha registrato 297 commit non di merge riguardanti la griglia del tavolo luminoso, le sue miniature e la loro pipeline di rendering e caching. Ho cercato di arrangiarmi con il trasandato codice del tavolo luminoso di Darktable, solo sgrassato, il più a lungo possibile, ma purtroppo era puro debito tecnico ed era penosamente lento.

In effetti, Darktable «gestisce» la scadente qualità del suo tavolo luminoso riducendone le dimensioni: i pannelli laterali di sinistra e di destra occupano molta superficie di visualizzazione, il che lascia ancora meno area da ridisegnare per il tavolo luminoso. Poiché Ansel ha rimosso il pannello laterale di destra, fondendone il contenuto con quello di sinistra e con il menu globale, c’era più superficie da disegnare, più lavoro per la CPU da svolgere, e il pessimo design del tavolo luminoso è diventato tanto più dannoso.

Da quando ho iniziato a usare Darktable, intorno al 2012, sono sempre rimasto sorpreso dalla poca RAM che utilizzava. La gente pensa che sia una buona cosa che un’applicazione usi la memoria con parsimonia, e questo è senz’altro vero se parliamo del tuo ambiente desktop. Ma parlando di un software di produzione che esegue un pesante rendering dei pixel su immagini da 12 a 54 Mpixel, questo significa che gli stessi calcoli pesanti vengono ripetuti più e più volte invece di essere salvati per essere riutilizzati in seguito. È a questo che serve una cache: evitare calcoli costosi. E dovrebbe usare tutta la RAM disponibile a tale scopo, perché calcolare significa sprecare energia, e questo ha un impatto concreto se stai lavorando a batteria. Inoltre, hai pagato per quella RAM e usarla non ti scarica la batteria. La CPU/GPU d’altro canto…

Memorie di un tizio che ha passato troppo tempo a ripulire la merda degli altri e a pagare per le loro cattive decisioni, episodio #troppi.

Copiare/incollare cronologie e stili sono funzioni fondamentali in Ansel, e quella che gli fa meritare (o meno) il suo titolo di «app per il flusso di lavoro». Ma è anche tra le più difficili da realizzare correttamente a livello interno. Gli utenti vedono un elenco di modifiche, ma sotto il cofano quelle modifiche dipendono dall’ordine della pipeline, dalle istanze dei moduli e dalle maschere. Se due immagini hanno topologie di pipeline diverse, copiare le modifiche in modo ingenuo può produrre incoerenze.

Già nel dicembre 2019, chiesi che qualcuno si occupasse di fornire pacchetti AppImage  per Darktable. Il vantaggio evidente sarebbe stato quello di consentire test anticipati, prima della versione, da parte di persone che non sono in grado di compilare da sole il codice sorgente, così da si spera fornire un riscontro anticipato e aiutare a fare il debug prima di rilasciare. Questo non è mai stato una priorità, il che significa che andava bene avere una corsa a correggere i bug sia prima sia dopo la pubblicazione.

Ansel eredita da Darktable la sua struttura portante di database: le cronologie di modifica non distruttive vengono salvate per ogni immagine in un database SQLite, insieme ai metadati e ad altri dati definiti dall’utente. Rendere il database consapevole di nuove immagini avviene tramite l’«importazione» delle immagini da un disco o da una scheda di memoria. È qui che entra in gioco lo strumento di importazione.

Purtroppo, l’importatore di Darktable è un’altra di quelle cose massacrate intorno al 2020 e trasformate in qualcosa di profondamente sconcertante, essendo un file browser che non somiglia a nessun file browser precedentemente noto, e che riesce a mancare di funzioni basilari (come Ctrl+F o l’anteprima EXIF) pur restando appesantito da funzioni inutili (vedi sotto). È qui che perdiamo molti futuri utenti, ed è solo lo step 0 del flusso di lavoro. Che magnifica vetrina di ciò che una «app per il flusso di lavoro» sa fare!

Ho pensato, per moltissimo tempo, che ci fosse qualche meccanismo di kill-switch sulla pipeline dei pixel. Il caso d’uso è il seguente :

1. stai modificando il parametro di un modulo,
2. le anteprime (quella centrale della camera oscura e la miniatura nel pannello di sinistra, usata anche per l’istogramma e i selettori di colore) ricalcolano la loro pipeline per tenere conto di quella modifica,
3. una delle anteprime finisce il rendering prima dell’altra, e il risultato non è ovviamente ciò che volevi,
4. modifichi di nuovo il parametro del modulo, senza aspettare che il ricalcolo finisca.

In quel caso, vuoi terminare tutte le pipeline attive perché il loro output non verrà usato, e iniziare immediatamente a ricalcolare tutto con i nuovi parametri. Solo che Darktable non fa questo, lascia che la pipeline finisca prima di riavviarla e, guardando i commenti nel codice sorgente, sembra essere una regressione piuttosto recente e non il comportamento originariamente previsto.

Darktable ha una propria libreria di widget per la GUI, per gli slider e le combobox (ovvero i menu a tendina o caselle di selezione), chiamata Bauhaus (nel codice sorgente si trova in src/bauhaus/bauhaus.c). Sebbene usino Gtk come backend, i Bauhaus sono oggetti personalizzati. E come molte cose in Darktable, personalizzato equivale a marcio.

Nel 2022 ho notato ridisegni parassiti e latenze  usandoli, che portavano a un’esperienza utente frustrante: il ridisegno del widget sembrava attendere il completamento dei ricalcoli della pipeline, il che significava che gli utenti non erano davvero sicuri che la loro modifica di valore fosse stata registrata, cosa che poteva indurli a riprovare, avviando un altro ciclo di costoso ricalcolo e di fatto congelando il loro computer per diversi minuti molto frustranti di inutili ricalcoli intermedi della pipeline.

Ho scoperto per caso che lo script di build per Linux usava una build «package», il che significa che le ottimizzazioni della CPU sono limitate a quelle generiche per produrre binari portabili installabili su qualsiasi piattaforma x86-64. Con «usava» intendo che la build package non era esplicitamente disabilitata, quindi era abilitata per impostazione predefinita.

Comunque, ora è disabilitata per impostazione predefinita, dato che i pacchetti veri e propri (.exe e .appimage) non vengono compilati tramite quello script, che è pensato principalmente per aiutare gli utenti finali. Per ripristinare il comportamento precedente, dovresti eseguire:

Il 2022 è stato talmente pessimo in termini di email spazzatura e rumore che ho avviato la Virtual Secretary , un framework Python per scrivere filtri email intelligenti incrociando informazioni provenienti da diverse fonti per indovinare cosa siano le email in arrivo e se siano importanti/urgenti o meno. Quando parlo di email spazzatura, intendo anche le notifiche di Github, i ping su pixls.us (grazie al cielo ho chiuso il mio account su quello stupido forum), YouTube ed email dirette da persone che sperano di ottenere un po’ di aiuto in privato.

Sono passati all’incirca 3 mesi da quando ho ribattezzato «R&Darktable» (che nessuno sembrava capire correttamente) in «Ansel», poi ho acquistato il nome a dominio e creato il sito web da zero con Hugo (non avevo mai programmato in Golang prima, ma si tratta perlopiù di codice di template).

Poi ho impiegato un totale di 70 h per far funzionare le build dei pacchetti nightly per Windows e Linux ai fini della distribuzione continua, qualcosa che Darktable non ha mai fatto bene («puoi compilarlo da solo, non è difficile»), solo per vedere il tracker dei bug esplodere dopo il rilascio (niente di meglio che concatenare lo sprint pre-rilascio con uno post-rilascio per ridurre la propria aspettativa di vita).