Ce n'est pas un secret, c'est même public, Linden Lab a (depuis des lustres déjà) rendu public le code source de son viewer pour Second Life.
Scénario : vous venez d'aborder Second Life, dix jours se sont écoulés, vous apprenez que vous avez librement accès au code source ...

... et vous vous voyez déjà éditeur de votre propre viewer qui va montrer aux autres ce que vous savez faire en la matière. Quatre semaines plus tard, vous avez enfin compris comment récupérer ce source sur votre disque dur bien à vous ; une vingtaine de jours de plus et vous avez enfin compris que vous devez compiler ce source pour en faire un exécutable ; deux mois de plus et vous pigez qu'il vous faut installer un véritable atelier de développement logiciel pour parvenir à compiler et, enfin, au bout de six mois vous avez une compilation exempte d'erreurs pour ... vous retrouver avec le viewer de Monsieur Toutlemonde. Ah, quelle chance vous allez enfin vous plonger dans le source pour y mettre votre grain de sel!
{Tous les droits pour ce scénario sont entièrement réservés. Pour toute adaptation cinématographique, télévisuelle ou autre support média, ce sera pour le plus offrant - très cher, quoi!}

Dans le but de vous épargner une si effroyable perte de temps, je vous ai élaboré un simple test d'aptitude à mettre le bout du nez dans le code source. Pas difficile, vous lisez calmement ce qui suit et je vous retrouve à l'autre bout :

mOffset is actually the data that's reserved for the header in the formatted image buffer at creation *before* the readFromCache() is invoked (see LLTextureFetchWorker::doWork() in lltexturefetch.cpp).
This quantity is fixed and never changed. What we've read so far is *at most* TEXTURE_CACHE_ENTRY_SIZE from the header cache.

The cache system writes all the cached files "headers" in a special file so to access the basic image info rapidly. Each entry to that file is *fixed* and stores TEXTURE_CACHE_ENTRY_SIZE of data, header 
*and all*. So, sometimes that entry actually stores real data (pixels so to speak...) that needs to be read before we read the body. This is what the mState == HEADER section will actually do. Sometimes, the 
header is actually bigger than TEXTURE_CACHE_ENTRY_SIZE and part of the header of the file will leak into the body section and will have to be accounted for there. This is the reason of the mind boggling code you encountered...

So, the idea in the line of code ... is that, if the header (mOffset) is smaller than TEXTURE_CACHE_ENTRY_SIZE, then there is some data we'll have to get from here and that'll be done in 
the mState == HEADER section of the doWork(). Otherwise, we go to the BODY section directly.

Note that, in truth, the (mState == HEADER) section actually doesn't read the header (this is done in getHeaderCacheEntry()) but rather deals with the left over of body data in that buffer... (Merov Linden)

Bon, me revoilou (pas trop mal à la header?) ; alors est-ce que vous êtes encore en mesure de répondre à la question suivante :
Par quel tour de passe-passe a-t'on fait disparaître la partie de cache-cache?

Vous pouvez? Chapeau, alors allez-y!

Vous n'en pouvez plus? Laissez tomber, y a pas de honte, moi non plus!

Question de rattrapage : Si vous croyez que CMake est une autre manière de reproduire le bruit d'un bisou (smack!) alors prenez une bombe de peinture et repeignez votre ordinateur (surtout l'écran).

Garmin Kawaguichi,
Révérend Père Siffleur