Development

Between January 2022 and March 2026, Ansel landed 297 non-merge commits regarding the lighttable grid, its thumbnails, and their rendering pipeline and caching. I tried to make do with the scruffy Darktable lighttable code, only degreased, for as long as I could but unfortunately, it was pure technical debt and it was painfully slow.

Indeed, Darktable “manages” the crappiness of its lighttable by reducing its size: the left and right side panels take a lot of display surface, which leaves even less area for the lighttable to repaint. Since Ansel removed the right side panel, merging its content with the left one and the global menu, there was more surface to paint, more CPU work to do, and the terrible design of the lighttable became all the more harmful.

Since I started using Darktable, circa 2012, I have always been surprised by how little RAM it used. People think it is a good thing that an application uses the memory sparingly, and that is surely true if we talk about your desktop environment. But talking of a production software that does heavy pixel rendering on images from 12 to 54 Mpixels, this means the same heavy computations are done again and again instead of being saved to be reused later. That’s what a cache is for : avoiding expensive computations. And it should use all the available RAM for that, because computing is wasting power, and that has a concrete impact if you are working on battery. Also, you paid for that RAM and using it doesn’t empty your battery. The CPU/GPU on the other end…

Memoirs of a guy who spent too much time cleaning other people’s shit and paying for their bad decisions, episode #too many.

Copy/paste history and styles are core features in Ansel, and the one that makes it deserve (or not) its “workflow app” title. But it is also among the hardest to get right internally. Users see a list of edits, but under the hood those edits depend on the pipeline order, module instances, and masks. If two images have different pipeline topologies, naïvely copying edits can produce inconsistencies.

En décembre 2019, j’ai demandé à quelqu’un de s’occuper de fournir des packages AppImages  pour Darktable. Le bénéfice évident aurait été de permettre des tests anticipés, avant la sortie, de la part de personnes qui ne peuvent pas construire le code source elles-mêmes, afin de fournir espérons-le des retours précoces et aider à déboguer avant la publication. Cela n’a jamais été une priorité, ce qui signifie qu’il était acceptable d’avoir une ruée avant et après la sortie pour corriger les bugs.

Ansel hérite de Darktable son infrastructure de base de données : les historiques de modifications non destructifs sont sauvegardés image par image dans une base de données SQLite, avec les métadonnées et autres données définies par l’utilisateur. Pour intégrer de nouvelles images à la base de données, il faut « importer » ces images depuis un disque ou une carte mémoire. C’est à cela que sert l’outil d’importation.

Malheureusement, l’importateur de Darktable est une autre fonctionnalité qui a été massacrée autour de 2020 pour devenir quelque chose de profondément déroutant : un navigateur de fichiers ne ressemblant à aucun navigateur connu jusqu’alors, qui parvient à manquer de fonctions de base (comme Ctrl+F ou un aperçu EXIF) tout en étant encombré d’options inutiles (voir ci-dessous). C’est ainsi que nous perdons beaucoup d’utilisateurs potentiels dès l’étape zéro du flux de travail. Quel bel exemple de ce qu’une « application de workflow » peut faire !

J’ai pensé, pendant très longtemps, qu’il y avait un mécanisme de bouton d’arrêt sur le pipeline de pixels. Le cas d’utilisation est le suivant :

1. vous modifiez un paramètre de module,
2. les aperçus (celui de la chambre noire central et la vignette dans le panneau de gauche, également utilisé pour l’histogramme et les sélecteurs de couleurs) reconstruisent leur pipeline pour tenir compte de ce changement,
3. l’un des aperçus finit de se rendre avant l’autre, et le résultat n’est évidemment pas celui que vous vouliez,
4. vous modifiez à nouveau le paramètre du module, sans attendre la fin de la recomputation.

Dans ce cas, vous souhaitez annuler tous les pipelines actifs car leur résultat ne sera pas utilisé, et commencer immédiatement à tout recalculer avec les nouveaux paramètres. Sauf que Darktable ne fait pas ça, il laisse le pipeline se terminer avant de le redémarrer, et en regardant les commentaires dans le code source, il semble que ce soit une régression assez récente et non le comportement initialement prévu.

Darktable a sa propre bibliothèque d’objets GUI, pour les curseurs et les comboboxes (alias menus déroulants ou boîtes de sélection), appelée Bauhaus (dans le code source, c’est dans src/bauhaus/bauhaus.c). Bien qu’ils utilisent Gtk en tant que moteur arrière, les objets Bauhaus sont des objets personnalisés. Et comme beaucoup de choses dans Darktable, personnaliser signifie pourri.

En 2022, ‍j’ai remarqué des redessinages parasites et des lenteurs , lors de leur utilisation, conduisant à une expérience utilisateur frustrante : le redessinage des widgets semblait attendre la conclusion des recalculs de la chaîne, ce qui signifiait que les utilisateurs n’étaient pas vraiment sûrs que leur changement de valeur était pris en compte, ce qui pouvait les amener à réessayer, déclenchant un autre cycle de recalcul coûteux, et gelant effectivement leur ordinateur pendant plusieurs minutes frustrantes d’intermédiaires coûteux recalculs de la chaîne.

J’ai découvert par accident que le script de build Linux utilisait un package build, ce qui signifiait que les optimisations CPU étaient limitées à des optimisations génériques afin de produire des binaires portables pouvant être installés sur n’importe quelle plateforme x86-64. Par ‘utiliser’, je veux dire que le build package n’était pas explicitement désactivé, donc il était activé par défaut.

De toute façon, cela est maintenant désactivé par défaut, puisque les packages réels (.exe et .appimage) ne sont pas construits via ce script, qui est principalement destiné à aider les utilisateurs finaux. Pour revenir à l’ancien comportement, vous devrez exécuter :

2022 a été si mauvaise en termes de courriels indésirables et de bruit que j’ai commencé la Secrétaire Virtuelle , un cadre Python pour écrire des filtres de courriels intelligents en croisant des informations provenant de plusieurs sources pour deviner ce que sont les courriels entrants et s’ils sont importants/urgents ou non. Quand je parle de courriels indésirables, il s’agit aussi des notifications Github, des pings sur pixls.us (heureusement, j’ai fermé mon compte sur ce forum stupide), YouTube et des courriels directs de personnes espérant obtenir de l’aide en privé.

Cela fait environ 3 mois que j’ai rebrandé “R&Ddarktable” (ce que personne ne semble comprendre), en “Ansel”, puis acheté le nom de domaine et créé le site web de zéro avec Hugo (je n’avais jamais programmé en Golang auparavant, mais il s’agit principalement de code de modèle).

Il me reste alors un total de 70 heures pour faire fonctionner les builds packaуs nocturnes pour Windows et Linux pour une livraison continue, ce que Darktоrque n’a jamais bien fais (« tu peux compléter toi-même, ce n’est pas difficile »), seulement pour voir le traqueur de bugs exploser après la sortie (rien de mieux que de chaîner le sprint pré-sortie avec un sprint post-sortie pour réduire votre espérance de vie.)