Pour ceux qui n'ont pas eu la patience de lire la partie 1 jusqu'au bout :
- Linden Lab a fait un sac de noeud pour rendre difficile le "vol de texture" via le cache. (securité par l'obscurité)
- Ce sac de noeud impacte très peu sur les performances, totalement negligeable.
- Un maximum de temps est perdue dans la decompression jpeg2000 et c'est deja optimisé a mort.

A quoi sert le cache ?
Le cache permet de stocker des textures sur le disque dur, plutot que de les retelecharger a chaque fois.
Un gain de temps, de bande passante, et de ressource CPU pour les serveurs SecondLife.

Pourquoi faut il le vider regulierement ?
Il ne faut pas le faire regulierement !

Pourquoi faut il le vider, parfois ?
Parce qu'il peut etre corrompu pour diverses raisons.


Qui sont ?
- un plantage pur et simple de l'application pile au moment ou elle etait en train d'editer le cache. Ce qui rend le fichier "inconcistant". A savoir : ce qu'il y a ecris dans le fichier A ne correpond pas a ce qu'on est sencé trouver dans le fichier B. Ou alors l'application n'a pas eu le temps d'ecrire la totalité du fichier entete par exemple, et au redemarrage l'application est toute embrouillée parce ce qu'il lui manque des informations pour utiliser le cache. 2 raisons parmis d'autres.

- Beaucoup plus frequent : l'application a "freezé" au moment ou elle etait en train de reorganiser le cache. Elle freeze justement parce qu'elle est en train de le reorganiser et qu'elle a besoin de stopper certaines operation pendant cette reorganisation. (typiquement : Empecher l'acces au cache pendant cette reorganisation).


Pourquoi reorganiser le cache :
C'est lié a sa taille. (il n'y a pas que la taille qui compte, mais ca aide ;) ).

Nous n'avons pas un espace disque illimité. Et afin que SecondLife ne remplisse pas l'integralité du disque dur
 nous pouvons indiquer une taille maximale que nous voulons consacrer au cache.
Plus le cache est gros, plus l'operation "est ce que cette texture dont j'ai besoin est stockée sur mon disque ? ou dois-je la telecharger ?" prend du temps.

A chaque fois que SecondLife telecharge une texture, il la transforme en sac de noeud (voir partie 1) et la met en cache.
A ce moment la il en profite pour verifier la taille du cache. Si la taille excede la taille maximale qui lui est autorisé, il va faire un nettoyage de printemps en virant 10% des textures stockée.

Ce qui  mene a un "leger freeze" de l'application. Car pendant le nettoyage, toutes les operations necessitant un acces au cache sont bloquées. Et comme secondlife est multithread ca n'arrange pas les choses (beaucoup plus difficile a coder, plus de bugs et de "bloquages" possible.

Bien sur, plus le cache est gros, plus le nettoyage est lent.
Je ne detaillerai pas le precessus du nettoyage car je ne suis pas absoluement certain de la methode employée. (visiblement les textures les plus anciennes sont supprimée du cache, d'ou le fait que la "date de stockage" fasse partie de l'index des textures (voir le post sur la structure de texture.entries)

Malheureusement, ce "freeze" qui peut etre plus ou moins long peut etre assimilé a un plantage de l'appli et elle est fermée violament par l'utilisateur. La reorganisation est laissée en plan, le cache est inutilisable ou, pire, mal utilisé (ce qui fait remplenter l'application et qu'on soit obligé de vider le cache).


D'ou l'interet de ne pas mettre un cache trop gros quand l'ordinateur est un peu faiblard.
A cela on pourrait rajouter que le FileSystem  de Windows est une grosse merde qui rend les operations encore plus lentes. Il y a enormement de reécritures et les fichiers finissent horriblement fragmentés. (et c'est vraiment specifique a windows).
De plus windows n'apprecie pas trop quand il y a trop de fichier dans un meme repertoire. C'est pour cela que les fichiers de textures sont dispersée dans des sous-repertoire.

Il y aurai des solutions un peu plus optimales pour cacher ces textures rapidement, mais l'optimisation ne serait efficace qu'avec un OS utilisant un filesystem digne de ce nom (linux, macOS X, ...) alors que cela empirerai les choses sous Windows.


Il y a vraiment beaucoup de discussions sur SLDev a propos du cache, car c'est vraiment un point qui impacte fortement les performances. Etant donné que c'est la decompression du format jpeg2000 (les textures sont stockée dans ce format) qui prend le plus de temps, l'idée évoquée est d'utiliser un autre format, plus rapide. (les plus rapides etant les format sans compression tels que le TGA).

Vous pouvez trouver un bref resumé des discussions et propositions ici : http://wiki.secondlife.com/wiki/Talk:Texture_Cache

(au passage vous remarquerez que j'y ai pas mal participé, en particulier en évoquant et soutenant l'utilisation du format TGA).

En parallele avec la discussion sur le format d'image stockée, il y a aussi une discussion sur la facon dont les fichiers sont indexés/stockés. Une source de problemes venant du "nettoyage" de la base de stockage des textures, il est evoqué l'idée d'utiliser une autre facon d'organiser le stockage des textures. Anfin d'eliminer, sinon diminuer, ce probleme de nettoyage/maintenance.

Fin de la partie 2, j'ai essayé de faire court, si si.

Pour ceux qui ont eu la patience de lire l'article precedent jusqu'au bout, il se seront peut etre demandé : "Ok, c'est bien joli tout ca, mais elle est ou la texture dans tout ca ?"

Et bien elle n'y est pas. Enfin, pas la en tout cas.
Ce fichier texture.entries est un fichier très simple, petit (assez petit pour etre stocké en permanence en memoire pendant l'execution de SL) et donc... rapide a utiliser.

Dans secondlife la vitesse d'execution est importante, ca rame deja assez comme ca non ?
Ce fichier est simplement un index qui est tenu a jour par le logiciel pour repondre rapidement a : "Est ce que la texture que je dois afficher sur ce prims est stocké dans mon cache, ou est ce que je dois la telecharger depuis les serveurs de secondlife ?".
Avoir un index des fichiers present dans le cache est donc tres utile et doit etre rapide.
Et avoir un fichier du type de celui du precedent article EST rapide, simple, leger, donc efficace :)


Mais au final ? Ou est la texture ?
C'est ... compliqué.
Linden Lab aurait put appliquer la methode suivante :
- un fichier qui indexe les textures cachées sur votre disque dur.
- un ou plusieurs repertoires contenant les dites textures.

Mais du coup les fichiers seront des textures directement lisible, editables avec photoshop et pouvant etre reuploader dans SL. Et ca va pas du tout du tout ! Parce que les fameuses textures qui sont stockées sur votre disque dur, dans le cache, ne sont pas forcements (et meme pratiquement jamais) des textures sur lequelles vous avez les droits de copie/modification/transfert. Hors, s'il y a un moyen de les recuperer puis les reuploader, vous vous retrouvez avec des textures full perm, a votre nom, dans votre inventaire. Horreur, scandale, abomination, vol de contenu, emeute et 5000eme mort annoncée de SL et son economie.

Vous connaissez la musique je suppose ? ;)
A propos de musique justement, Les majors de l'industrie du film et du disque depensent des millions, peut etre même des milliards afin de tenter de proteger les contenus. Sans succes, c'est peine perdue. Et bien c'est pareil dans secondlife. Quelle que soit la methode il y aura toujours moyen de "voler des textures", en utilisant le cache, ou par d'autres moyens (comme les recuprer dans la memoire video de la carte graphique par exemple).

Ce que font les majors, et ce que fait secondlife, c'est "la securité par l'obscurité". Autrement dit il font en sorte que le contenu a proteger soit stocké d'une facon qui rend compliqué le "vol". Par la cryptographie ou par d'autres moyens.

Linden Lab n'utilise pas la cryptographie car c'est lent et consommateur de precieuses ressources CPU. (on en a jamais trop avec SL).

A la place, ils stockent les textures d'une facon un peu bizzare... que je ne detaillerai bien evidemment pas.
Grosso modo il y a un fichier contenant les 600 premiers octets (a quelques details près ;) ) de toutes les textures stockées. Tous entassés les un derrieres les autres. (s'il y a 100 textures, ca fait un fichier de 600*100bytes (a quelques details pres, encore))

Une serie de fichier dont le nom est l'UUID de la texture, et qui contient la texture elle-meme *moins* les 600 premiers bytes (a quelques details près) qui sont, eux, stocké dans le gros fichier cité juste au dessus.

Un ficher permetant de savoir a quel endroit du gros fichier se trouvent les 600bytes qui interessent. Car il n'est pas possible de retrouver l'UUID de la texture directement dans le premier fichier, simplement parce que ca serait "trop simple" de les recuperer. Sans ce 3eme fichier, le 1er fichier est un gros tas de n*600bytes completement inutilisables.

C'est pour cela que quand on ouvre le ficher de texture directement dans photoshop, il n'arrive pas a l'ouvrir, car il manque (a quelques details pres) les 600 premiers bytes du fichier, qui se trouvent etres les plus importants car il contiennent les "entetes" qui permet a photoshop de decoder le format j2c puis de l'affichier.

Ce n'est pas si difficile que ca que d'assembler tout ca, et de finir avec une texture utilisable. Et d'avoir au final reussi a "voler" une texture. Ca demande de savoir programmer, de prendre le temps de defaire les sacs de noeuds que Linden Lab a mis en place pour rendre la chose plus difficile et de ... vouloir le faire.

Et, visiblement (et j'en suis heureux), ce qui peuvent le faire ne veulent pas perdre du temps a voler des textures.
Et ceux qui voudraient bien, n'en n'ont pas le talent (ca c'est pas une surprise) ;)

Au final, est ce que ce sac de noeud ne ralenti pas le systeme de cache ?
Un peu, tres peu, car la plus grosse partie du temps n'est pas dans la recherche/assemblage de la texture, mais dans le format de compression utilisé. Le format j2c est tres pratique, très bien, mais... lent a decompresser. Et c'est cette decompression qui prend la majorité du temps.
Aucun interet a rendre la recherche/assemblage du fichier 2x fois plus rapide si 99% du temps est passé dans la decompression du format j2c. Il faudrait plutot optimiser la decompression, mais la... C'est deja optimisé a mort.

J'ai trouvé un editeur hexa sympa : "010 Editor".

Il permet en particulier de creer des templates et des scripts dans un langage assez similaire au C pour la lecture et l'edition de fichiers binaires. Il n'est ni libre ni gratuit et fonctionne sous windows, mais rien n'est parfait dans ce bas monde ;)

A titre d'exemple j'ai fait 2 templates pour lire le fichier texture.entries.
La structure du fichier est la suivante :
- l'entete du fichier qui fait 8 octets : la version du fichier + le nombre d'entrée dans le fichier. (pas de "magic number")
- le corps du fichier composé d'un tableau de 24 octets : UUID de la texture + taille de l'image + date

L'UUID fait 128bits, comme il n'existe pas de type de base de 128 bits, je decide de creer un type perso de 16x8bits. J'aurai pu faire 4x32, mais il y a une bonne raison pour ne pas le faire (plus tard) ;)

typedef ubyte LLUUID[16];

Les premiers 32 bits du fichier donnent la version de la structure du fichier. Un nombre a virgule flottante (float).
Les 32 bits suivants representent le nombre d'entrées dans le corps du fichier ou, d'une facon plus pratique, combien de fois on va trouver dans le corps du fichier le tableau : UUID+taille+date. Ce nombre est un nombre entier non-signé de 32 bits (uint32).


Pour faire ca propre je definis la structure de l'entete du fichier dans une... structure ;)

struct FileHeader
{
    float mVersion;
    uint32 mEntries;
} monEntete;


Le corps du fichier est un poil plus complexe, mais très peu.
De la meme maniere on va definir une structure pour donner un sens aux 24 octets suivant.
A la difference près que cette structure sera repetée un certains nombre de fois, ce certain nombre etant tres exactement celui indiqué par "mEntries".
Ce qui donne un tableau de structure de "mEntries" elements.

La structure est la suivante :
- 128 bits representant l'UUID de la texture (de type LLUUID qu'on a defini au debut)
- la taille de l'image, un nombre entier sur 32 bits (int32)
- la date a laquelle la texture a été inserée dans le fichier. Cette date est representée par un entier de 32 bits representant le nobmre de secondes ecoulée depuis le 1er Janvier 1970. Ca parrait bizzare mais cette methode  de representation de date est tres pratique, prend peu de place et est tres utilisée. Tellement utilisée qu'elle a son propre type predefini : time_t. En indiquant time_t le logiciel saura que cet entier de 32 bits represente une date et nous affichera la date dans un format "lisible" plutot que d'afficher betement le nombre de secondes ecoulée entre 1/1/1970 et la date de creation de la texture en question.

C'est parti :

struct FileBody
{
    LLUUID mID;
    int32 mSize;
    time_t mTime;
} mesElements[monEntete.mEntries];

la derniere ligne indique que "mesElements" est un tableau composé de "mEntries" elements. Et qu'on peut trouver ce nombre "mEntries" dans "monEntete".
Par exemple, si mEntries = 100. On aura un tableau de 100 Elements. Soit 100 fois les 24 octets de "FileBody".

Ensuite... bein c'est fini. On lance tout ca dans 010 Editor et il nous affiche une jolie fenetre dans un format humainement lisible, plutot qu'un ensemble insipide de 0 et de 1.

Bonjour,

j'ai pris la décision toute personnelle de me retirer du programme "community gateway" et du devant de la scène de la communauté francophone. Ce n'est pas tant Linden Lab que toute une série de comportements et d'évènements qui m'ont fait prendre cette décision.

Je vais faire mon possible pour conserver tout ce qu'on a créé ces 2 dernières années. Essayer de voir avec les owner francophones et autres "grands acteurs" ( ) s'il est possible de parvenir a un accord pour conserver les principales sims. Dans le cas contraire, si on n'arrive pas a s'entendre, les sims seront vendues au détail sur le marché des sims de 2nd main. Un repreneur unique de toutes les sims serait bien sur une situation idéale.

Perso, je vais retourner aux sources : scripting, coding, et administration systeme. (conception de logiciel, de serveurs, et la Francogrid).

Tout cela ne sera pas fait dans l'urgence, donc inutile de paniquer pour ceux qui ont du terrain chez moi.

Je ne m'abaisserai pas a designer des coupables ou a regler mon linge sale en public, ni a me la jouer "après moi la fin du monde". Ce n'est pas le plaisir sadique de le faire qui me manque, mais ca ne desservirai personne, et surtout pas moi. Je suis simplement fatigué de jouer les don-quichotte et j'en suis le seul responsable. Je m'en vais retourner a des activités lucratives et bien plus reposante.

Je reste dans secondlife, mais en simple resident.

Merci tous ceux qui ont rendu ce monde possible et vivant pendant les 2 plus longues et difficiles années de ma vie.
Merci à tous ... et mort aux cons.