Re: cache vignettes : images différentes entre espace public/privé

Comme ça va me poser problème, j'essaie de comprendre comment SPIP
fonctionne.

J'ai lu
https://code.spip.net/fr/archives/traitements-d-image/article/images-temporaires-images
...et je ne saisis pas vraiment les raisons de la mise en place de ces
mécanismes.

Ce que je crois avoir compris :

Il existe 2 dossiers de stockage des vignettes :
- cache_vignettes
- cache_gd2

cache_vignettes sert pour stocker les images qui n'ont subi que des
réductions (image_reduire/passe_partout)
cache_gd2 sert pour stocker les images qui ont subit des transformations
(image_recadre/rotation/etc.)

Lorsqu'on enchaine des filtres d'images, l'image finale est donc stockée
dans l'un de ces 2 dossiers de cache.
Cette image finale est appelée image permanente ou gravée. Cela signifie
qu'elle est utilisée, i.e "affichée quelque part".

Mais l'enchainement des filtres a également produit les images
intermédiaires, chacune associée à un fichier "de contrôle" (.src) qui
contient les "informations de reconstruction"...

Lorsque le processus grave l'image finale permanente, il supprime ensuite
toutes les images intermédiaires mais laisse les fichiers de contrôle qui y
étaient associés.

On a donc
- aucune image intermédiaire mais à la place : des fichiers de contrôle
- une image finale permanente sans fichier de contrôle.


Pour le cas, ou l'image subit une autre série de filtres dont certains sont
communs, les fichiers de contrôle vont servir...
En reprenant l'exemple de la doc :

[(#TEXTE|image_reduire{520,0}
>     |image_reduire{150}
>     |image_rotation{90}
>     |image_recadre{200,200,'center','red'}
>     |image_aplatir{jpg}
> )]
> [(#TEXTE|image_reduire{520,0}
>     |image_reduire{150}
>     |image_rotation{-90}
>     |image_recadre{200,200,'center','red'}
>     |image_aplatir{jpg}
> )]
>

Il est écrit :

Dans la deuxième série de filtres, les deux premiers filtres image_reduire
> ne font rien car les fichiers de contrôle sont là. Au moment de calculer le
> image_rotation, on s’aperçoit qu’il nous les faut. On reconstruit donc les
> deux images intermédiaires, et celle qui a manqué (la deuxième) est gravée
> car on sait qu’elle est commune à plusieurs séries.
>
> Le gravage automatique de l’image intermédiaire évite un recalcul
> systématique pour cause de dates a chaque hit.
>


Ce que je n'arrive pas à comprendre :
La 2eme série de filtre provoque aussi une image finale permanente.
Des lors, à quoi bon stocker l'image temporaire commune au 2 séries ?
La raison invoquée est d' "éviter un recalcul systématique pour cause de
dates à chaque hit"

Dans quel cas y aurait-il un recalcul ? qu'est-ce que cette histoire de
date ? un lien avec l'alea à la fin des urls d'images ?
Je vous remercie par avance.

Julien


Le 8 septembre 2017 à 16:52, Matthieu Marcillaud <[email protected]> a
écrit :

> Le 03/07/2017 à 14:15, Matthieu Marcillaud a écrit :
>
> Vu, merci. https://core.spip.net/projects/spip/repository/revisions/23633
>> Et du coup, c’est en attendant une meilleure correction (mais sur la
>> prochaine version de dev, on va attendre que la 3.2 soit branchée).
>> https://core.spip.net/issues/3971
>>
>
> Bon, on a du annuler ces commits car cela cassait la reconstruction des
> images intermédiaires dans l’espace privé.
> Le fichier .src de construction stockant les chemins relatifs aussi des
> images, qui est ensuite envoyé aux fonctions de traitement d’images s’il y
> a besoin de reconstruire l’image.
> C'est un peu trop compliqué actuellement pour corriger/améliorer ce point.
>
> https://core.spip.net/projects/spip/repository/revisions/23695
>
>
> MM.
> _______________________________________________
> liste: http://listes.rezo.net/mailman/listinfo/spip-dev
> doc: http://www.spip.net/
> dev: http://trac.rezo.net/trac/spip/
> irc://irc.freenode.net/spip
>